Why was FreeBSD 5.x so bad?

N

neel

Developer
I have heard from many veteran FreeBSD users that FreeBSD 5.x was the "worst" FreeBSD release after a relatively solid 4.x.

But what made 5.x so bad, when compared to say 4.x if not later releases?

For reference, I am young (only 23!) and was a child during the FreeBSD 5.x days. I started using FreeBSD daily during my high school days (at 15).
 
Good question. One part I remember was that 5.x was the first version where the kernel became SMP-capable, meaning multiple threads could be in the kernel at once. I suspect that this caused lots of hilarity: locking is hard.

Just to make you feel too young: I just logged into a 4.x machine that is still running. The kernel was last recompiled in February 2008. Works fine.
 
I think this was around when Dillon made his tantrum fork as well. What was that all about anyway? I can’t seem to find the mailing list thread about it.
 
Hmm, Matt Dillon. The version of the story that I heard (admittedly from BSD people, who were on the other side) was that he had a big ego, big ideas about how the kernel should be structured (threads versus fibers, locking granularity, who controls the blocks of the file system, parallel access to files), and was unwilling to listen to reason, or to the opinion of other people. Fundamentally, he thought that he was much smarter than everyone else, and insisted on committing code that was done "his way". That caused a split, where he either lost or voluntarily gave up commit privileges on FreeBSD. I know that he was either talking to or working with the BtrFS people (who have their origins in the big computer companies). And I heard that the people who actually implement super-fast file systems (in the massively parallel systems community) were laughing their heads off about these rank amateurs (like the Hammer or BtrFS people). But a lot of this could be parochialism and us-vs-them.
 
FreeBSD 5 was bad because it *had* to be released no matter how incomplete the changes were, otherwise waiting for everything to be fixed would mean no release ever.
 
Good thread. I wasn't aware of all of these. FreeBSD 6.22 was my first installation. Good to know what was going on.

xtouqh said:
it *had* to be released no matter how
Click to expand...
This part I can't understand this part. Why they *had* to release a dubious product? Does release dates are set in stone?
 
ralphbsz said:
Hmm, Matt Dillon. The version of the story that I heard (admittedly from BSD people, who were on the other side) was that he had a big ego, big ideas about how the kernel should be structured (threads versus fibers, locking granularity, who controls the blocks of the file system, parallel access to files), and was unwilling to listen to reason, or to the opinion of other people. Fundamentally, he thought that he was much smarter than everyone else, and insisted on committing code that was done "his way". That caused a split, where he either lost or voluntarily gave up commit privileges on FreeBSD. I know that he was either talking to or working with the BtrFS people (who have their origins in the big computer companies). And I heard that the people who actually implement super-fast file systems (in the massively parallel systems community) were laughing their heads off about these rank amateurs (like the Hammer or BtrFS people). But a lot of this could be parochialism and us-vs-them.
Click to expand...

So much hostility and fragmentation over pride. That’s really sad. Thanks for this.
 
There's a bit about the developer departure here: https://lwn.net/Articles/712308/

My recollection of that time (wasn't a FreeBSD user then, but kept an eye on things) was more along the lines of the comment here:

taosecurity.blogspot.com

FreeBSD Quality

Richard Bejtlich's blog on digital security, strategic thought, and military history.
taosecurity.blogspot.com taosecurity.blogspot.com

Regarding the mail thread: FreeBSD 5 was a revolution in many areas comparing to 4 and as such was not as polished around the edges as people was expecting. As Scott Long stressed many times, FreeBSD 6 release management will be diferent that 5's, having less features, more testing, more refinement.

So my recollection - very well might be faulty! - is that FreeBSD and especially 4.X - had a reputation of being rock solid. 5.X incorporated a lot of changes and the quality (and reputation) slipped.
 
anonymous9 said:
Nobody is laughing at Matt Dillon as a rank amateur for creating HAMMER.
Click to expand...
At the time of its inception, Hammer was considered very amusing (in a bad sense) by some people. And those are not random people, but they write file systems for a living (get paid for it).

And the rank amateurs who thought of and began development of btrfs were IBM (proposal) and implementation began by a SUSE engineer ...
Click to expand...
You are correct about one part: the person who first suggested the modifiable B-tree technique is not a rank amateur at all, and I do respect him (and know him well, having worked directly with him). I did express myself rather badly above, and apologize. The actual implementation of the file system is a different story ... still today, I refer to it as "a machine for destroying data", but at least it doesn't murder wives.

And just to be clear: There are lots of good file systems, even single-node single-volume file systems, with smart people who are good engineers working on them. That definitely includes ZFS, UFS, ext<n>, XFS. It's just that not all file systems that being written are good, and when you look inside you see too much hype, derivative work, and bad judgement.
 
vigole said:
This part I can't understand this part. Why they *had* to release a dubious product? Does release dates are set in stone?
Click to expand...
AFAIK, it was endlessly delayed for one or another feature to be finished, and even if release dates are not set in stone, not releasing something for extended periods of time would only mean death of the project, so there was a choice, bad as it was.
 
neel said:
I have heard from many veteran FreeBSD users that FreeBSD 5.x was the "worst" FreeBSD release after a relatively solid 4.x.

But what made 5.x so bad, when compared to say 4.x if not later releases?

For reference, I am young (only 23!) and was a child during the FreeBSD 5.x days. I started using FreeBSD daily during my high school days (at 15).
Click to expand...
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.
 
The short of it is that getting rid of GIANT_LOCK was difficult and 5.x "had to" be released.

Has nothing to do with HAMMER or CoC.
 
I started using FreeBSD with 5.x and I didn't know what I was doing. I really liked FreeBSD 6.x. I remember compiling KDE 3.5x on my old IBM 300PL that had 256 MB RAM. That was painful and it took several days. Heh.
 
vigole said:
This part I can't understand this part. Why they *had* to release a dubious product? Does release dates are set in stone?
Click to expand...
Once upon a time I worked at a company that didn't release a product from the main branch in the 2.5 years I worked there. Work was done on the main branch, but then the changes that were deemed not too risky were backported into the two supported release branches and released periodically.

What happens then is you wind up with a branch that has all the major, important, and necessary changes, but is not thoroughly vetted through the release process; and one or more release branches full of old bugs and design flaws, but with the latest important medium to minor fixes.

You then have two choices: bite the bullet, release the main branch and buckle down for months or likely years of pain & suffering, or decide one of your release branches is the new main branch and abandon all the work done in the old main branch.

There's really no clearly best choice in this situation, it really depends on the particulars of the code in question. Door 1 is the correct choice given no more information about the code base under discussion, and this is the option Freebsd chose.

In case you're wondering, I heard from friends the company I used to work for also chose door 1, but they did it in the worst possible way. Thanks to input from marketing, the main branch was released as a dot release. Countless customers, some of them very large, installed it as a dot-upgrade in production systems. I wonder how much more market share the company lost thanks to that genius move.

It wasn't like there were a lot of options in that niche field, though. Our only real competitor chose door number 2. This led to some pretty hilarious bugs being perpetuated for years. I wonder who's laughing now, but don't care enough to find out.
 
anonymous9 said:
Thanks for a bunch of opinion based admittedly on what was heard from one side and opinion without facts on filesystems? Okay, whatever.
Click to expand...
So give us the other side. Curiosity is my only agenda. I was busy paying a mortgage and raising little kids at the time. I had no time to keep up with these events.
 
  • Like
Reactions: a6h
Jose said:
You then have two choices: bite the bullet, release the main branch and buckle down for months or likely years of pain & suffering, or decide one of your release branches is the new main branch and abandon all the work done in the old main branch.

There's really no clearly best choice in this situation, it really depends on the particulars of the code in question. Door 1 is the correct choice given no more information about the code base under discussion, and this is the option Freebsd chose.
Click to expand...
Wasn't this, or similar, the case with MS and Windows Vista / Server 2008? As I recall they had to release, in order to "move on" or they would have been stuck with patching Windows XP / Server 2003 for many years to come.
 
If I remember correctly, FreeBSD 4 was the longest branch ever, with 12 releases (4.0 to 4.11) made from a single branch. The problem with that was that the “current” branch at that time (which would eventually become 5.0) diverged farther and farther away from 4.x, making it increasingly difficult to throw the switch while maintaining upgradability. Making things worse, 5-current had serious stability problems at that time. The new SMP code (mentioned above in this thread) was part of the problem, but also several other subsystems were rewritten or got major changes (e.g. WLAN, USB, CAM, PCCard), requiring significant amounts of testing and bug-shaking. It was a difficult situation. When 5.0 was finally released, many (most?) users preferred to avoid 5.x altogether and stick with 4.11 while waiting for 6.x.

Regarding Matt Dillon and DragonFly BSD, several things came together. Most importantly, Matt and other developers disagreed on how to proceed with the SMP code, kernel threading and locking. Another point was that Matt is a “hardcore” programmer and software engineer. Working full-time on FreeBSD, he produced such massive amounts of code, that it was impossible to keep up with reviewing all of that, which was (more or less) mandatory for getting it committed. Matt felt thwarted and getting slowed down, which was frustrating. He finally took what he assumed to be the last “usable” version of 4-stable and created the DragonFly BSD project. Since then I’m running DragonFly BSD inside a VM, just out of curiosity, and I think it works surprisingly well. It has some very interesting and useful features that are lacking from FreeBSD, for example variant symlinks. I also quite like the HAMMER2 file system – while you can’t really compare it with ZFS, it also has some very interesting features, e.g. the fine-grained snapshots and history for point-in-time recovery.
 
There are some cool things you can do with HAMMER2. For example, a developer explained in a blog how to create a time machine for backups: Set up a journal stream from an active file system, buffer it for – say – one hour, and feed it into a backup file system (locally or on the other side of the planet). The result is that you have a “delayed mirror”, so to speak, a “live backup” that represents your file system as of one hour in the past, like a time machine. When you accidentally rm a file, use your time machine to copy it back. Just don’t wait longer than one hour, because then the file disappears from your backup, too. (Or stop the journal stream if you need more time in case of an emergency.)
 
Combination of two things.

1 - It was released before ready, schedule coming ahead of quality.
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.

I didnt especially hate it though, although I did wait until 5.3.

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.
 
Mat Dillon locked in a room with Poettering... and I think Mat is one hell of a software engineer. But stubborn as a brick.

Is the BSD available as, sadly preferable, a git repo back to 4.x? I would like to suggest to you all the book "Your code as a crime scene" and the tools in it. Maybe one can unearth some stuff still lurking around and waiting to bite us in the you-guess-what.
 
You must log in or register to reply here.
Back
Top