FreeBSD Update is the binary update solution [Re: HEADS UP: Release schedule for 2006]

[Jo Rhett]

On Thu, Jan 05, 2006 at 10:47:38AM +0100, Patrick M. Hausen wrote:
> > > > 1. modified kernels are foobar
> > > >   ..yet are practically mandatory on production systems
> 
> > Look around.  Every major commercial OS does it just fine.
> 
> While I agree with much of your reasoning, I know exactly zero
> people running a modified kernel of any version of Windows,
> Mac OS X or Solaris, to name just three commercial OS's.
 
You're tickling a different subject here.  All three of these operating
systems have loadable kernel modules that work.  I mean, they dynamically
load the modules they need, and you can disable kernel modules in
configuration files.  FreeBSD has loadable kernel modules, but they don't
autoload (you have to modify rc files) and you can't trim down the kernel
to minimize unused memory without recompiling.

To give you a specific example: if we could remove NFS and the 3ware
driver from the kernel in a configuration file, we could probably run
GENERIC.  (we do *a lot* of other modifications, but NFS is the main memory
hog we have to remove on small footprint systems, and the 3ware driver we
have to update independently, which requires that it be a loadable module
and not compiled in)

So yeah, this is a different problem.  However I wasn't going to tackle
this issue in this thread because the -core team appears to be very aware 
of this issue and it seems to improve a bit in every release.

> And third party drivers (which one could count as "kernel modifications")
> did fail and will fail sometimes in weird ways even for minor
> version upgrades/patches. BTDT - Windows Services Packs, Solaris patches,
> Mac OS X updates, reboot, *boom*, because some hardware suppliers
> driver didn't adhere to the OS manufacturer's standards or because
> the latter silently changed something undocumented.
 
I don't know what you're trying to say here.  I don't disagree, I'm just
not sure what you mean.  It almost sounds like you're trying to make my own
point about having the ability to backout patches, which we don't have
today.

> While I would appreciate a packaged core system or at least a
> better definition of "core system" at all, I strongly believe
> that binary updating a custom kernel is impossible.

If the kernel is consistent across the enterprise (but not, say GENERIC)
then binary updates would be trivial.

> With "better definition of core system" I mean, if you have a
> long lived production system that you might have upgraded
> from 4.x to 5.x to 6.0, you will have a lot of cruft lying
> on your filesystem that once was part of the "core" and now
> isn't. And there is no simple and automated way to find out
> what to delete ...

That's another good point for having file revisions.  We don't have that
particular problem, but I can easily imagine how having versioning of the
core OS would be useful to help isolate these orphaned files.

-- 
Jo Rhett
senior geek
SVcolo : Silicon Valley Colocation