FreeBSD has serious problems with focus, longevity, and lifecycle

Royce Williams royce.williams at
Tue Jan 17 08:24:19 UTC 2012

John's trying to manage risk.  Switching from RELEASE to CURRENT adds
a lot of risk and churn, when most folks in this class of use case
just need a few very specific drivers and bugfixes (what some OSes
call "hotfixes".)

John sounds willing to trade a little bit of local risk (and testing
time) in exchange for a way to self-serve a hotfix without abandoning
RELEASE.  How can we enable that?

There are simple cases -- the ones that just need a few files and a
kernel module -- that seem within easy reach.  For example, the eRacks
guys generated these handy binaries for mps(4) for 7.4, 8.0, 8.1 and

For me, this was perfect: I got to have my cake (tracking 8.1-RELEASE,
and using freebsd-update) and eat it too (support for specific newer
hardware).  If security updates break my mps(4), I'm on my own -- but
it's still a much better balance of risk for me than switching to

I know that some fixes are harder than just adding a kernel module.  I
know that the standards for releasing errata are high, and they should
be.  But I wish there was a way to optionally lower that threshold and
say: "Yes, I know this might eat my data.  Let me judge and test that
for myself without otherwise abandoning RELEASE."  If there was a way
to mark hotfixes as "worked for me" (to let the better ones bubble up
to the top), we non-coders could even help manage the list.

I can't do it myself, but I would happily help brainstorm, test  --
and commit $100 or more, Kickstarter-style, to fund someone else's


More information about the freebsd-hackers mailing list