[ On Tuesday, September 3, 2002 at 16:43:53 (+0700), Robert Elz wrote: ]
> Subject: Re: /rescue, crunchgen'ed? 
>
> Requiring just / /rescue and /rescue/big-binary to actually exist (after
> booting, which isn't being changed of course) is certainly not worse.

I'm stil not so sure.

There are any number of ways to screw up any static-linked binary,
including a single crunchgen'ed binary, and many more of those
"mistakes" will _completely_ hose the system if they are made to one
lone static-linked binary, but in today's system they'd have only a tiny
chance of making the system unbootable if they're made to just one of
the many static-linked binaries we have today.

So if all the really essential single-user programs are kept
static-linked and installed in their "normal" places, then it takes
significantly more effort/mistakes/failures to screw up enough stuff
that you can't reboot into single-user mode and unravel the mess.  Only
three or four binaries out of over one hundred are needed to get to a
point where files from other partitions or media can be used.  I think
one in twenty odds of a mistake being catastrophic are a lot better than
100% guaranteed catastrophe for a single mistake.

I believe we need separate and stable and static /sbin/init and /bin/sh
(or /sbin/sh) at the very least.  Keeping all of /sbin static and
separate binaries is even better, and all of /bin too is our current
"ideal".

It's easy, trivial even, to allow individual end users to select dynamic
linked programs from places like /usr/i18n/bin if they desire the
features they feel such dynamic linking affords, and if static linking
of those features is too much of a resource burden for them to bear on
the platform in question.

Meanwhile it seems that with a minor patch it really is trivial to
static link all the features for at least full multi-byte locale support
without such major impact that any modern machine would notice.

-- 
								Greg A. Woods

+1 416 218-0098;            <g.a.woods@ieee.org>;           <woods@robohack.ca>
Planix, Inc. <woods@planix.com>; VE3TCP; Secrets of the Weird <woods@weird.com>