rwatson at FreeBSD.org
Mon Sep 12 11:16:00 UTC 2011
On Mon, 12 Sep 2011, Adrian Chadd wrote:
> I've heard this many times, and here's my (paraphrased) stock response:
> People remember FreeBSD 4.x fondly. They likely don't remember 3.x fondly.
> They remember 2.x fondly - because it was rock stable for a lot of users.
> Then 3.x came along, with (new!) softupdates, and VM changes, and some other
> stuff I was too young to understand. It was stable for me, but unstable for
> a lot of much more serious and larger users. 4.x was when that matured.
> People see 8.x as stable. Not in all situations, but in a lot of them. 9.x
> may not be as stable for some, but there's a lot of good stuff going into
> it. If the developers play their cards right, 9.x will be the cycle where
> those bugs are shaken out and later 9.x releases will be rock solid. The
> only way that (and hopefully, 10.0) is going to be rock stable and be
> remembered like 4.x was remembered is if users actively use it, report bugs
> and work with developers to fix it.
> Rather than, you know, staying on FreeBSD-4.x :-)
The other rather interesting thing I've observed is that people often remember
the same releases quite differently, depending on their environment and
workload. I know of several companies that have quite happily deployed early
5.x pre-releases in products that have now been in the field for years --
whereas I tend to remember the early releases as a bit shaky (especially as
background file system checking shook out its bugs).
The best general strategy is what many companies do: begin early deployment of
.0 releases so that you can gain experience, and in particular, help identify
critical bugs. Do widespread deployment with .1 and .2 releases, and as you
begin to reach .3 and .4, think really hard about how to upgrade!
For appliance vendors, it's particularly important to be tracking
in-development FreeBSD while building a product, since you want to maximise
overlap between FreeBSD's support lifetime for a release and your own. This
is particularly critical so that you can avoid backporting drivers yourself
when the FreeBSD Project (effectively) de-supports an old development line,
but you still have to provide in-the-field hardware upgrades that necessarily
involve newer parts that aren't supported by the old release.
At least in my own deployments, multi-year uptimes of all our major releases
are common. I have one box doing quite active service based on a FreeBSD 7.1
prerelease that has just shy of 900 days uptime.
This isn't to say that there aren't problems, but rather to point out that a
lot of our intuitions depend on our own quite specific perspectives. A lot
depends on the hardware you select -- some of it down to good choices of
vendors and avoiding discount parts, but some of it is pure luck -- did you
get a generation of disks that was particularly poor, or end up with a BIOS
revision that seriously harmed stability. You can often significantly improve
OS stability by disabling lots of random BIOS features, regardless of the OS,
reducing use of features like SMM that are beyond the OS's control.
More information about the freebsd-arch