FreeBSD has serious problems with focus, longevity, and lifecycle

Devin Teske devin.teske at
Tue Jan 17 23:08:58 UTC 2012

> -----Original Message-----
> From: owner-freebsd-hackers at [mailto:owner-freebsd-
> hackers at] On Behalf Of Garrett Cooper
> Sent: Monday, January 16, 2012 4:07 PM
> To: WBentley at
> Cc: freebsd-hackers at
> Subject: Re: FreeBSD has serious problems with focus, longevity, and lifecycle
> On Mon, Jan 16, 2012 at 3:32 PM, William Bentley <William at>
> wrote:
> > I also echo John's sentiments here. Very excellent points made here.
> > Thank you for voicing your opinion. I was beginning to think I was the
> > only one who felt this way.
> >
> > I also have several FreeBSD installations spread across different
> > development/production systems and it is not feasible to always
> > upgrade to the latest and greatest. Part of why FreeBSD is difficult
> > to adopt into more of the commercial/government sectors is because of
> > this fast paced release cycle and most of the important patches/fixes
> > are not backported far enough. This is why most of my customers decide
> > to use Solaris or RedHat and not FreeBSD. (Not looking to start a
> > flame war about the OS choice/etc just pointing out the Release cycle
> > model). I would love to push FreeBSD harder but it is becoming
> > increasingly difficult as of late.
> >
> > We seem to have lost our way around the release of FreeBSD 7. I am all
> > in favor of new features but not at the risk of stability and proper
> > life cycle management.
> >
> > Are me and John the only people that feel this way or are we among the
> > minority?
>     You aren't. There are other people like Devin Teske's group that feel the
> (they're upgrading from 4.x to 8.2! Brave man.. and godspeed to him),


Actually, we're jumping from 4.11 to 8.1 (not 8.2 -- reason as follows).

A lot of the problems we're having in 8.1 still exist in 8.2 (but will go-away
in 8.3, according to what we're seeing already-committed to RELENG_8 tag beyond
the RELENG_8_2_0_RELEASE tag -- that is, if 8.3 ever gets produced!). Therefore,
we've seen no need to push 8.2 (in-fact, we've internally black-listed it
because it doesn't fix anything we care about). So far, we've made over 10
patches to FreeBSD-8.1, and not a one of them would have been needed for 8.3,
but all of them would still be needed for 8.2.

I might add that we're doing an in-place binary migration from 4.11 to 8.1 using
a very sophisticated sh(1) script named "host_rebuild" which we'll be releasing
later this year. It allows binary migration both forwards, backwards, and even
stationary (re-installing the same OS, to either migrate architecture or simply
rebuild the OS).

> along with
> some development organizations that depend on long release cycles (IronPort,
> Isilon, etc).

I brought this up in last weekend's BAFUG meeting...

We're _very_ interested in replicating the long-lifecycle of the 4-series with a
newer series. But which one?

Right now, we're jumping to the 8-series, but after seeing that one of the major
focal points for 9 is McKusick's SU+J (SoftUpdates Journaling -- tunefs -j
enable), I'm ready to say that the 9-series should instead be the "chosen
outlier" when it comes to picking one single release to have an ultra-wide

The 9-series represents the first release to integrate a journaled filesystem
by-default into the system (aka boot) filesystem(s). We were pleasantly
surprised to see that the default installer enabled SU+J by-default when
choosing "guided" and "auto" for disk partitioning.

NOTE: We hated gjournal -- too clunky as a "bolt-on" solution. SU+J is a breath
of fresh-air as it's truly integrated into the filesystem and recognized at the
base FreeBSD level.

>     That being said. More people, more likelihood to succeed with what you
> like julian@ suggests. I like long release cycles too for stuff that I find
critical and
> "in production", like my router. My fileserver is a slightly different story,
but I just
> got off the CURRENT bandwagon off on to the 9-STABLE bandwagon :).
> Cheers,
> -Garrett
> _______________________________________________
> freebsd-hackers at mailing list
> To unsubscribe, send any mail to "freebsd-hackers-unsubscribe at"

The information contained in this message is proprietary and/or confidential. If you are not the intended recipient, please: (i) delete the message and all copies; (ii) do not disclose, distribute or use the message in any manner; and (iii) notify the sender immediately. In addition, please be aware that any message addressed to our domain is subject to archiving and review by persons other than the intended recipient. Thank you.

More information about the freebsd-hackers mailing list