On Mon, 26 Aug 2002, Johnny Billquist wrote:

> On Tue, 27 Aug 2002, Noriyuki Soda wrote:
>
> > - it consumes more disk space than what we have currently.
> >  (c.f. the diskspace will decrease with the luke's proposal.)
>
> This is really nonsensical, I think. If we really were concerned about
> size, I can probably think of a 1000 things we shouldn't do.
> Unless you can really show me some case where size really matters, I would
> appreciate if that argument was dropped (I've even worked at a place where
> we flashed the whole NetBSD system, and had plenty of space left. Even
> flash memory is cheap).

It's mentioned because when the thread first came up, "it will take more
space" was a common complaint. Since folks wanted some sort of /rescue
support, and were concerned we'd have both the static and dynamic versions
of everything in root.

> > - if there is another way for booting on a system (e.g. booting from
> >   cdrom), /rescue directory can be removed on the system with luke's
> >   proposal. but the duplicated binary in your proposal cannot be removed.
>
> I'm *not* concerned that much with a few extra megabytes of space in
> root. I *am* concerned that my root will be non-functional, which is
> definitely a rather probable event, given time.

non-functional in what (specific) manner?

/ taking a dive (well dynamic libs taking a dive) is why we have /rescue.
And why you can (now) tell your kernel to ask for init's path, so you can
tell it /rescue/init.

/ filling up because you formatted it way-back-when when we defaulted to
100 MB / is why we talk about size.

> I still (and always will) think that dynamically linking /bin and /sbin is
> a very lousy idea. If people want locale support I don't object to
> that. What I object to is dynamic linking in the root. It plainly
> stinks.

We can't do both. As other posts have indicated, programs need to be
dynamically linked in order to safely/sanely dlopen() things. locale
support really means dlopen() of locale code.

> The bottom line is: find a better solution, and wait until that is
> implemented.
> You're taking the easy (and lousy) way out right now.

This _is_ the best solution. It's not the easiest, it is the only one.

In order to do what we want to do, we have to be able to dlopen() in
programs in /{,s}bin. dlopen() means dynamic. Thus to do what we (the
NetBSD project developers) want to do means /{,s}bin dynamic. It really is
that simple.

We looked for other solutions. There are none (well, all the ones we found
are worse than this one).

Suggestions on how to better do this are appreciated. But, "This is
stupid," won't cut it, since we think the things this change lets us do
aren't stupid. :-)

Take care,

Bill