On Tue, Aug 27, 2002 at 11:26:30PM -0400, Greg A. Woods wrote:
> [ On Tuesday, August 27, 2002 at 10:44:45 (-0400), Bill Sommerfeld wrote: ]
> > Subject: Re: HEADS UP: migration to fully dynamic linked "base" system 
> >
> > This change *reduces* complexity; instead of having half the system
> > statically linked and half dynamic, everything is dynamic.
> 
> Hmmmm... I don't think that holds water....  especially not with /rescue
> still in the mix on your supposedly "everything is dynamic" system.  :-)

Sure it does.

Currently, /sbin and /bin programs have to be 'special', and have to be
maintained that way. After this change, everything that the system runs
in normal operation can use the same subsystems, libraries, and
resources.

/rescue is very similar to an idea that I believe I first heard from
Andrew Brown - keep a sysinst 'boot floppy' kernel image in /, so you
can boot from an mfs-backed crunchgen'd set of repair tools if you ever
need to.

Sure /rescue is 'different' from other parts of the system, but just as
init prompts you with /bin/sh in single-user mode, even if root's shell
is csh (or something worse ;-) - /rescue is different in the sense of
being simpler, to make it usable in a wider set of recovery
circumstances.

Many tools on the boot floppy have #defines that cause them to build
with a more limited functionality, and to save space. Yes, that means
maintaining two 'targets' to build from those sources, but each has a
different set of requirements driving it. Likewise, here, /rescue isn't
used often, just when you need it, and its binaries are different from
the system as a whole, for a very good reason.

> > If a security patch for libc is released, you need only update libc
> > and /rescue; you need not run in circles rebuilding all the statically
> > linked binaries in /bin and /sbin and wherever else they might be
> > hiding.
> 
> Well, it's not really /bin and /sbin which are the problem now is it
> (unless you happen to be the guy stuck rebuilding them for the patch
> kit).
> 
> The issue is of course all the other stuff someone might have installed
> on their system -- stuff that the person preparing OS patches cannot be
> expected to re-link, even if they do have access to all the sources.
> 
> Yes, this is a big issue for some folks.
> 
> (It's not a big issue for me -- I'm the guy who ends up rebuilding both
> my system binaries and my applications when important fixes to things
> like libc are necessary on production systems.  I don't mind though.
> Really.)

Yes, some of us enjoy doing that, but it doesn't scale. It doesn't scale
to a large installation of machines, and it doesn't scale to providing
the best service we can to every NetBSD user.

-- 
David Maxwell, david@vex.net|david@maxwell.net --> Mastery of UNIX, like
mastery of language, offers real freedom. The price of freedom is always dear,
but there's no substitute. Personally, I'd rather pay for my freedom than live
in a bitmapped, pop-up-happy dungeon like NT. - Thomas Scoville