[ On Tuesday, August 27, 2002 at 20:10:28 (-0700), Jason R Thorpe wrote: ]
> Subject: Re: HEADS UP: migration to fully dynamic linked "base" system
>
> On Tue, Aug 27, 2002 at 10:29:26PM -0400, Greg A. Woods wrote:
> 
>  > [ On Tuesday, August 27, 2002 at 01:29:56 (+0200), Johnny Billquist wrote: ]
>  > > Subject: Re: HEADS UP: migration to fully dynamic linked "base" system
>  > >
>  > > Oh, I don't argue that a (hopefully) working /rescue will do the
>  > > trick. I'm just very opposed to having /rescue, since it will do exactly
>  > > what /bin was for, as opposed to /usr/bin.
>  > 
>  > Very good point!
> 
> No not a very good point, and here's why...
> 
> The fact that we have a static /bin and /sbin *now* is nothing more than
> an historical accident.

I'm not saying it's a good point because of any historical nonsense or
"tradition" BS either.

/bin and /sbin are already what /rescue tries to be.

Why mess with a good thing?

If people want locale support for the programs in /bin and /sbin then
there's some related precedence in other systems for using some other
path entirely for the "different" programs.  eg. /usr/i18n/{bin,sbin}.

I think the performance issues further reinforce this idea of pushing
dynamic linked versions of key system binaries off into a place where
only those who need them will have to use them.

> When NetBSD's shared libraries came along originally, they were not always
> that stable, and because of the tendency to have separate / and /usr, it
> turned out to simply be more convenient *at the time* to do with a static
> /bin and /sbin and dynamic /usr/...

In my mind shared libraries are always less than stable  :-)

Well anyway here history does have a very strong lesson and I'd be
extremely surprised if it were not also the impetus for the decisions in
NetBSD, particularly given the origin of our shared library support.  I
speak of course of SunOS.  I don't know about the origins of SunOS-4's
own choice to static link most things in /sbin and many things in /bin,
but I do know it was sold to users as a reliability feature to help make
it easier to recover fat-fingered systems.

> I wouldn't exactly say there was any purposefulness in the current scheme,
> and certainly wouldn't make the assertion that /bin and /sbin are "for"
> single-user system recovery.

Regardless that's the way they've come to be, and it's the way hier(7)
describes them too.  I don't think it really matters whether the chicken
or the egg came first in this case -- the current documented practice
and rationale make sense (as if they didn't people wouldn't have put so
much effort into this /rescue thing).

-- 
								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>