Whew!! These trans-globular discussions are exhausting!

Count me as one a bit nervous about this change.  I'll tell you why.

I'm a bit new to U*NIX's in general, and NetBSD specifically.  I'd
only seen my first U*NIX-like operating system in 1992, and been
following NetBSD only from about early 1995 -- most of my time has
been in embedded systems.  So I might not know precisely what I'm
talking about.

So, one day in the last few years I stumbled across the fact that all
the stuff in /bin and /sbin were statically linked. I slapped my
forehead, and said to myself, "Self, how elegant! how simple! what a
straightforward and nearly bullet-proof set of tools if most of your
system gets blown away! (Well, as bullet-proof as I could expect,
anyway.)"  That is, I liked it, because it was a set of tools
exercised every day (or, more nearly, every second or two), which
would be (mostly) available in a degraded system.  My feeling --
simpler is better, and software that isn't used gets cranky, and
develops rust.

So that's it.  I was really, really impressed to discover this.  I
submit that potentially many newbies to NetBSD may be similarly
impressed.

Now wending to the negative, the performance issues associated with
making these oft-used programs in /bin and /sbin dynamically loaded
worry me.

And parenthetically, the notion of adding a /rescue thingy made me go
"whoa!!!" To me, /rescue seems to be a combination of reaction to
change of long-standing structure, a visceral reaction to the word
itself (rescue? Is this NetBSD thing dangerous?), and what seems to be
a blatant program redundancy.  But, except that others might react the
same way, I'm really not sure that my adverse reaction should be
counted for very much.  (I not on the list where this was originally
discussed, so this hit me cold.)

On the other hand, I've heard some good arguments from people I've
come to respect in favor of the notion.  In particular, I'm impressed
by the language argument.  But frankly some of the other arguments
went over my head.  Might'n someone with a handle on this give a poor
bit-twiddler an "executive overview" on the goodies you're trying to
achieve?

So, I'm dreaming of a compromise position.  Isn't a -static'ally
linked program really just a rigorously degenerate case of a
-dynamic'ally linked one?  And, isn't every -dynamic'ally linked
program simply a trade-off between how many instructions are included
in the program, and how many are "shipped" off to load-time library
land? At one extreme, we could have a program that merely called a
library routine, then exited, and at the other, does entirely
everything within itself, having no need to call a load-time
library. (Whether the necessary support comes from linked modules --
I'm trying to stay away from the term static library, which is a
distracter -- or from freshly written programming is irrelevant.)

If this is correct, then, it seems to me, we change the concept of
-static and -dynamic to simply throw out the concept of -static: _all_
programs are -dynamic, it's just that some are "less -dynamic" than
others, to the degenerate case. From there, the trick is 1: to "load
up" /bin and /sbin programs with enough support routines that they
require an "optimal" level of assistance from load-time library
routines -- with "optimal" tending toward "minimal" with an eye toward
performance and robustness.  And 2: change whatever dynamic load
processes are in place to ensure that /bin and /sbin programs (and
potentially all programs) to "fall back" to a degraded mode of
operation if the desired load-time library or support is missing.

For example, ls might be compiled with language support from load-time
library routines and tables, but, other than that, not require any
other run-time library support.  We have support for Chinese, but if
we lose the libraries, or ld.so itself, (perhaps a special case of)
single-user mode, for example, ls loses Chinese and speaks in a
degraded mode.  Perhaps English, perhaps Esperanto, perhaps a
dreamed-up Oeuthkakmp -- take your choice.  But the important point is
that it is the same ls as before, just not able to access the language
libraries.

Now, I realize that run-time library lossage robustness is not
infinitely regress-able, and a lot of run-time library lossage is not
easily handled.  On the other hand, I believe that in the long run
it's really not acceptable to core-dump a program for any trivial
run-time linkage failure -- as I suspect, but don't know, is the case
now.  So, operating a critical program in "degraded" mode must be
planned for, sure, but, it seems to me, in any case the run-time
support for that "degraded" mode would happen sooner or later in the
normal evolution of improvement.  Sooner, I think, would theoretically
suit everyone.

So, I'm arguing for:

1.  Dump the rigid distinction between -static and -dynamic;  the
    effect of -static is subsumed as as special (degenerate) case of
    -dynamic.

2.  Keep the overall directory structure pretty much as it is, with
    the addition of /lib if you must.

3.  Craft the programs in /bin and /sbin for an optimal balance
    between them and their run-time support.

4.  Ensure that the programs in /bin and /sbin run if run-time library
    support is lost.

The advantages:

1.  We gain essential support.

2.  We don't add in a redundant set of programs in an (eye-blinking)
    location, (mostly) unused.

3.  We retain performance of commonly used programs.

4.  We regularly exercise the programs needed in an emergency
    situation.

5.  We have the possibility of retaining the enhanced features in our
    essential tools in emergency situations.

The disadvantages are (and feel free to add to this list -- I haven't
given it a whole lot of thought):

1.  The ">     + Reduction in disk space usage in `/'." won't happen.
    In fact, it may rise a bit.

2.  Trade-offs may squelch someone's (read: a lot of someone's)
    favourite features (read: a lot of everyone else's PITA).

3.  Doing this might not be easy, either logistically or
    programmatically.  In particular, inventing the mechanism to
    decide what pre-compiled routines will and will not be
    incorporated into the body of a program, and how this is to be
    carried out.

4.  The time frame for doing this now may extend far into the future.
    We want enhanced features now.

Well, I hear the argument for action now, and, after waiting for so
long, I can understand your desire to get moving.  So, I say,
reluctantly, (Johnny, I sympathize with you, I really do), go for it.
After all, this thing, once done, can be undone.  But, if you can hold
your horses, I'd be much pleased.

But, I truly would like to see an evolution toward what I've outlined
above.  I'd like to see /rescue deep-six'd sooner rather than later.

Well, this is a sketch, and there are loose ends.  That's my
.00000000002B. (1)

Comments, anyone?

-Mike

(1) "A billion here, a billion there, soon you're talking real money"
     -- With apologies to Sam Rayburn, whom I've just misquoted (and
	probably misspelled).