Why was FreeBSD 5.x so bad?

1 - It was released before ready, schedule coming ahead of quality.
Rather the opposite, there was no real schedule (at least none that was adhered to), and it was delayed far too long.
But at least they learned their lessons: stricter schedules were introduced, and the decision was made to fork new stable branches more often.
2 - It made major architectural changes, moving from a single CPU mode to multi CPU model, if I remember at the time it was aiming to be one of the first OS to make this change, to be a leader in the market.
No, FreeBSD already supported SMP much earlier, as did the “competitors”. I ran FreeBSD 3.x with SMP on a dual Celeron-466 in 1999. However, the old kernel threading model did not scale very well, this is why they did major changes to it in 5.x.
 
The first release of FreeBSD I used was 4.7, just before 5.0 came out. And boy do I feel lucky that I didn't start a few months later, or I might have dismissed the great OS that is FreeBSD as unstable and unusable.

I did try to move to 5.0 when it came out, and all of a sudden things that had worked flawlessly before were less stable than a house of cards. Kernel panics became a regular occurrence. When I looked into it, I learned all about the M:N threading model they had chosen for 5, which has now all but completely vanished. A quote from Ingo Molnar still sticks in my head to this day: "I'm no wimp when it comes to scheduler complexity, but a coupled kernel/user scheduling concept scares the *hit out of me." (source) In short, I went back to the 4.x release for as long as I could.

So yes, FreeBSD has made mistakes in the past. But, they've acknowledged and corrected them, and now it's a rock solid system that still offers great performance.
 
For me the worst release was 9.0, I remember jumping early to it, and it had a nasty UFS bug that caused data corruption. I posted on here about it, it was was fairly quickly patched and forgotten about, but filesystem corruption is about as bad as it gets. Not jumped to a .0 release since.
I had problems with 9.0. not that specific problem, but as a result of the switch to GPT. My old motherboard BIOS at the time couldn't get a along with it and it would freeze on the POST screen (had to dd the disks from a different box). I had to install FreeBSD 8.x and upgrade to 9.0, just to get it installed. It wasn't fixed until a 9.2 RC3 as I recall:

Fix a boot issue caused by some GPT partitioning tools.

Caused me no end of headache at the time.
 
On "Dillon vs. the rest" I'd like to note that the storm has waned since. DragonflyBSD periodically imports driver code & other (e.g. network related) from FreeBSD, and IIRC there's a project proposal to port HAMMER2 to FreeBSD.
 
Not jumped to a .0 release since.
Wisdom is the fruit of the tree of suffering. I don't do .0 in any system that has data I care about either.

Unfortunately some folks don't listen, and still jump on the latest shiny from Cupertino despite my warnings to the contrary. The wisdom from that tree is don't try to help people who don't listen.
 
In the old days of the Amiga, Mat did a news spooler that was very fast. Only drawback was it used crc16 to see if an item was present and then not fetch it. Hash collisions were something that could wreck your threads. I guess he is not as hot headed today as back then, but that was some fireworks.

Having HAMMER2 would be nice, real nice - as would be process checkpointing. Something we might want to port over if possible.
 
On "Dillon vs. the rest" I'd like to note that the storm has waned since. DragonflyBSD periodically imports driver code & other (e.g. network related) from FreeBSD, and IIRC there's a project proposal to port HAMMER2 to FreeBSD.
That’s true. Matt continued to be present in some of the mailing lists, even right after he started DragonFly BSD, and sometimes gave hints and tips, e.g. when he fixed a bug in DF that would also affect FreeBSD. I’m not sure if he’s still on those mailing lists today, as I look at them only very rarely myself.
 
Rather the opposite, there was no real schedule (at least none that was adhered to), and it was delayed far too long.
But at least they learned their lessons: stricter schedules were introduced, and the decision was made to fork new stable branches more often.

No, FreeBSD already supported SMP much earlier, as did the “competitors”. I ran FreeBSD 3.x with SMP on a dual Celeron-466 in 1999. However, the old kernel threading model did not scale very well, this is why they did major changes to it in 5.x.

Yes the developers felt it was delayed too long so just released it, hence the problems. For me i have the opposite attitude, if it isnt ready dont release even if it takes 10 years. Or back out the incomplete features.

Also thanks for clarifying on the multi cpu stuff, it is what I meant in terms of making the underling threading model optimised for multi core, but I was wrong in saying it introduced multi cpu capability.
 
As another example, if you look at Windows Vista, Microsoft released an slow, buggy OS incompatible with existing software. Many stayed with Windows XP.

Microsoft thought they would have a major upgrade but instead they cancelled the original Longhorn, re-done it and still got something beta-grade. The issues have largely ironed out by SP1 but by then people simply didn't want Vista, period.

Not that Vista's legacy is all dead, modern versions of Windows (7-10) are largely based on Vista (Windows 10 can run on most Vista-era hardware) bringing forward many features and design decisions, but significantly refined and the bugs ironed out. From what I read online, FreeBSD 6.x and later have largely ironed out the 5.x-era issues.

I'll admit, I was a Vista user and didn't have many issues, but never was a FreeBSD user prior to 9.x.

In short: Windows Vista is to XP what FreeBSD 5.x is to 4.x: a botched successor to a great OS.

My worst FreeBSD release was 10.1, mainly because whenever I ran freebsd-update on UFS with Soft Updates, the system wouldn't reboot, period. It would somewhat hang but still respond to pings. This issue once meant I couldn't access my home email server until my brother power cycled the PC. But as I mentioned earlier, I never ran 5.x.

I do get some issues from time to time with CURRENT on my desktop, but that doesn't count since it's bleeding-edge code, bugs are expected.

Disclaimer: I work at Microsoft, not on Windows (or any Linux efforts) however.
 
Thank you
Now I only need to pull that complete repo, with history, and see if the tools from that book do anything. Now where did I put that book?
 
I started with 5.x (5.4 to be precise) when I moved from Linux so I never had a chance to rally know 4.x series. Maybe that is why I do not see anything 'tragic' in 5.x series.

I started with 4.x series, but used 5.3 for a long time (by 5.3 they had fixed some things). I'd guess it depended what you were using it for, relative to having problems or not having them. There was some turmoil involved enough so that I delayed the move to 6, thinking it would be rinse/repeat. I used 5.3 mostly for computer programming, and that's likely not considered a very intensive use of the system ...

I used 6.x briefly, and then jumped to 7 (and thusly right into the infamous race condition bug).
 
Back
Top