Deja-vu all over again

[donallen]

I've got 10.1 installed on a desktop machine that I built -- Asus motherboard, AMD processor, 4 GB memory, 500 GB 7200 rpm disk.

I really like the BSD concept, which is why I've been a glutton for punishment for a number of years. I started with the 7 series, discovering the hard way how bad the USB stack was, plus getting burned by a serious bug in the ext2 support. I've tried every major release since and every time there has been a show-stopper.

So now I'm at 10.1 and it seemed to be good. The 'pkg' system is very well done, the system has been stable (with the exception of one total freeze; I can't remember the last time I've seen something like that with Linux). But it feels like a lot of the rough edges are gone, so I thought maybe there was hope.

Now we get to today. A friend gave me some Windows stuff on a USB key with a FAT32 file-system on it. I stuck the key in the machine and mounted it on a newly created directory in /tmp. After mounting, I did an ls to verify that what I expected to be there was there, and it was. Among the contents was a .iso file that needed to be copied to another USB key. I inserted that key and began typing the dd command, while cded to the directory where I'd mounted the first key. When I hit 'tab' to complete the name of the .iso file, it would not complete. So I backed out, did another ls and got nothing! No files! But the file-system was still mounted, confirmed with df. I suspect that the insertion of the second USB key confused the system somehow and it lost track of the first. At that point, I shut the system down, removed the keys and repeated the whole thing on an Arch Linux system without difficulty.

So again, I'm faced with the little guy sitting on my shoulder saying "Hey dummy! What do you have to gain from running FreeBSD instead of Linux?". The environment above the low-level userland is the same -- same window managers, same compilers (except I have to do stuff outside the package manager to get the latest Glasgow Haskell compiler, which I use a lot, whereas Arch just supplies it via pacman), same editors (except not sublime_text, since they don't support FreeBSD). And the stuff below that level has, time after time, been unacceptably buggy. My little man is very annoying, but he's right -- there's no point to this, at least not for me.

 

[gofer_touch]

I am not sure what kind of response were you anticipating to this from the FreeBSD community. FreeBSD 10.1 is rock solid and does all of what its users could want it to do and more. If you are looking for something pre-configured, with minimal effort, you might want to try PC-BSD. It is FreeBSD under the hood and has a lot of very useful features.

 

[drhowarddrfine]

In the meantime, I've been running FreeBSD as my sole desktop for 11 years and dozens of client web site servers for my web dev company. So does Netflix but they're bigger than me.

 

[donallen]

I am not sure what kind of response were you anticipating to this from the FreeBSD community. FreeBSD 10.1 is rock solid and does all of what its users could want it to do and more. If you are looking for something pre-configured, with minimal effort, you might want to try PC-BSD. It is FreeBSD under the hood and has a lot of very useful features.

I'm afraid you didn't read my message too carefully. When a mounted file-system just vanishes with no failed hardware explanation, that is not "rock solid", by my standards. Providing reliable file-system service is one of the most basic things an operating system does. Why you concluded from my report of this that I might want to try PC-BSD, because it's pre-configured, is a bit of a mystery.

As to your valid question about the kind of response I was expecting from the community to my message, it's more what I was saying to the community and I've been saying it for years, as I try each major release and find a show-stopping problem. I've been a Linux user since Slackware appeared in the early 1990s and have used Debian and Arch over the years in addition to Slackware. I have also used OpenBSD extensively. I have never encountered the QA problems I see persistently in FreeBSD in Linux or OpenBSD. And OpenBSD is a small project, both in terms of number of developers and number of users, which argues against the possible explanation that FreeBSD just doesn't have critical mass.

And to drhowarddrfine: FreeBSD (and Linux and OpenBSD) are huge systems. They can have bugs in them that you never run across, because you don't exercise the cases, the code paths, that fail. If you are getting good service from the system, then congratulations. The same applies to your Netflix example. Your message contradicts nothing I've said. I'm not saying this system can't do the job for anyone; it simply hasn't done the job for me and my usage pattern. The issues I've had with FreeBSD are fact and I don't think any of them constitute unusual demands, e.g., mounting a USB key with a FAT32 file-system on it and expecting it to be there until I umount it.

 

[getopt]

When I would mess with dd my ego won't allow me lamenting about the OS running the command. Perhaps a very good friend I might tell how beautifully I failed today...

 

[donallen]

When I would mess with dd my ego won't allow me lamenting about the OS running the command. Perhaps a very good friend I might tell how beautifully I failed today...

I never ran the dd command. That's what I meant in my original post by "backed out". And if you are implying that I switched 'if' and 'of' (which wouldn't matter in this case, since I never ran dd), yes, that would tend to wipe out the file-system on the input key. Except lack of careful reading comes up again -- as I explained in the original post, I moved the whole operation to a Linux system, the input key file-system was intact, and I did the dd successfully there.

 

[ANOKNUSA]

When a mounted file-system just vanishes with no failed hardware explanation, that is not "rock solid", by my standards.

Nor by my own standards. Good thing it's something I've never experienced on any operating system, and something that almost certainly should be reproducible. But judging by your original post, you stopped the second you thought something was wrong and jumped ship. You made no attempt to confirm the problem was real and identify it, which is Step #1 in the "How to Solve Basic Problems Handbook." Maybe this is a genuine bug in the FreeBSD code, but the sheer number of people inserting and removing various USB keys on FreeBSD systems all day every day virtually guarantees someone else should have come across this by now.

And to drhowarddrfine: FreeBSD (and Linux and OpenBSD) are huge systems. They can have bugs in them that you never run across, because you don't exercise the cases, the code paths, that fail.

Again, I agree, and again, "insert a USB key" is hardly a corner case.

There's nothing wrong with criticizing FreeBSD. To each their own; personal taste is a major factor in choosing an operating system, and if Slackware and such suit you better then that's great. What's more, constructive criticism is how people grow and improve things. But obvious logical inconsistencies a ten-year-old could see through annoy the everlovin' crap out of me, and claiming that software bugs are simultaneously unavoidable and unacceptable (while doing nothing to confirm the "bug" actually exists and isn't merely a fault in one's perception, or caused by one's ignorance) is certainly an obvious logical inconsistency par excellence. Ask for help, or file a bug report, or quietly leave. Publicly complaining like this is undignified.

 

[kpa]

Nor by my own standards. Good thing it's something I've never experienced on any operating system, and something that almost certainly should be reproducible. But judging by your original post, you stopped the second you thought something was wrong and jumped ship. You made no attempt to confirm the problem was real and identify it, which is Step #1 in the "How to Solve Basic Problems Handbook." Maybe this is a genuine bug in the FreeBSD code, but the sheer number of people inserting and removing various USB keys on FreeBSD systems all day every day virtually guarantees someone else should have come across this by now.

Again, I agree, and again, "insert a USB key" is hardly a corner case.

But the reality is much more complicated than that. USB is supposed to be a widely adopted standard and well followed by manufacturers. In reality the manufacturers of USB hardware are only interested in MS Windows (and rarely OS X) compatibility and they take every possible shortcut in their firmwares to cut down development costs. Their produts are almost never tested with any of the more exotic OSes like FreeBSD by the manufacturer. This leaves the burden of testing to the users of the OS, that's us here. Linux gets away from this mess by simply having so much many more users compared to FreeBSD that are unwittingly testing just about everything new on the market and the problems get reported more quicker and there are good chances that the problems get fixed in timely manner.

 

[donallen]

Nor by my own standards. Good thing it's something I've never experienced on any operating system, and something that almost certainly should be reproducible. But judging by your original post, you stopped the second you thought something was wrong and jumped ship. You made no attempt to confirm the problem was real and identify it, which is Step #1 in the "How to Solve Basic Problems Handbook." Maybe this is a genuine bug in the FreeBSD code, but the sheer number of people inserting and removing various USB keys on FreeBSD systems all day every day virtually guarantees someone else should have come across this by now.

I can see how you would conclude what you did from my post, in which I didn't take the time to detail everything I did. I did confirm, several times (because I was amazed), that I was looking at the correct directory and that the system thought the key was mounted (df). I didn't tell you, and perhaps I should have, that I re-booted the system sometime later, after I got done what I'd originally set out to do, and tried to reproduce the error and could not. But I don't agree with your near-certainty about reproducing this. Operating systems can and do have race conditions, particularly when I/O devices are involved, which implies interrupt handling. In addition to the fact that all our computers today, even our phones, are multi-processor systems.

Again, I agree, and again, "insert a USB key" is hardly a corner case.

There's nothing wrong with criticizing FreeBSD. To each their own; personal taste is a major factor in choosing an operating system, and if Slackware and such suit you better then that's great. What's more, constructive criticism is how people grow and improve things. But obvious logical inconsistencies a ten-year-old could see through annoy the everlovin' crap out of me, and claiming that software bugs are simultaneously unavoidable and unacceptable (while doing nothing to confirm the "bug" actually exists and isn't merely a fault in one's perception, or caused by one's ignorance) is certainly an obvious logical inconsistency par excellence. Ask for help, or file a bug report, or quietly leave. Publicly complaining like this is undignified.

I did file a bug report earlier this morning.

 

[getopt]

This case is becoming increasingly interesting. Aren't we all eager to get this "bug" tracked down?

What information do we need to replicate this failure?
1. Vendor of the USB device
2. Name/Type of the device
3. Firmware version if known
4. uname -a
5. A recorded session using script(1) showing dd command used

Anything else?

PS:

Link of the bug-report filed?

Test environment for race conditon?

 

[donallen]

But the reality is much more complicated than that. USB is supposed to be a widely adopted standard and well followed by manufacturers. In reality the manufacturers of USB hardware are only interested in MS Windows (and rarely OS X) compatibility and they take every possible shortcut in their firmwares to cut down development costs. Their produts are almost never tested with any of the more exotic OSes like FreeBSD by the manufacturer. This leaves the burden of testing to the users of the OS, that's us here. Linux gets away from this mess by simply having so much many more users compared to FreeBSD that are unwittingly testing just about everything new on the market and the problems get reported more quicker and there are good chances that the problems get fixed in timely manner.

All true. This is why USB drivers have the "quirks" concept. I don't think we will find the word "quirks" in the USB standard.

I earlier mentioned the possible lack of critical mass in the FreeBSD project (I was referring both to the development group and the user community), essentially the same idea you mention above. You are certainly correct that the probability of the larger Linux community stumbling over a quirk in a device is greater than that in the case of FreeBSD. But FreeBSD can benefit from what is learned by the Linux people, even to the extent of reading changes to driver code. Yes, there aren't as many FreeBSD developers, but if they are selective about the devices they devote their time to, the chances of problems like this would be reduced, in my opinion. The device in question here, by the way, is an 8GB Sandisk Cruzer Facet. So this was not made by Joe's USB Key Co., Inc.

 

[ANOKNUSA]

In reality the manufacturers of USB hardware are only interested in MS Windows (and rarely OS X) compatibility and they take every possible shortcut in their firmwares to cut down development costs. Their produts are almost never tested with any of the more exotic OSes like FreeBSD by the manufacturer.

Yes, granted; I've been bitten by shoddy firmware before, with a cheap USB hard disk enclosure. But no such thing is either said or implied in the original post. It's just a rant boo-hoo-ing about how much FreeBSD sucks compared to Arch Linux. I'll admit that my 4+ years using Arch myself have left me conditioned to that community's expectations, where a thread that starts the way this one did is closed very quickly.

EDIT: Re-reading my own posts, they come of as unnecessarily snide. I apologize for that. I'll back out of this conversation and let the folks setting a more constructive tone do there thing.

 

[wblock@]

Speaking for myself, I feel that such threads can have value. They can show whether the community is able to respond productively even when there is a great temptation to go the other direction.

As far as the subject of the thread, I'd point out that most FreeBSD developers are unpaid volunteers. This limits the type of work that gets done. However, most developers are willing to work to solve reproducible problems, at least if the person experiencing them is willing to put in some effort to help.