>>> AND WE'RE DYNAMICALLY LINKING /bin/df?
>> There is still a static /rescue/df.
> excuse me, but, why is there a /rescue AND a /sbin?

Good question.  Near as I can figure, the answer is "history", with a
subnote that /rescue is, comparatively, crippled with respect to the
kind of functionality that drove this insane push to link everything
dynamic.  (Yes, I think it's insane, largely bceause it's fragile.  See
below for more.)

> isn't /sbin there for the purpose of Statically Linked Binaries for
> Critical Tools?

Historically, there was /bin and /usr/bin, with /bin containing stuff
that was likely to be needed when filesystems were not mounted.  I'm a
little hazy on this era myself; while I have used Unices as old as
BSD 4.1c, that was a long time ago.  This was long before dynamic
linking, and in this era /usr was separate from / often because one
spindle simply couldn't hold it all.

There's /sbin and /usr/sbin.  Exactly what the paradigm here originally
was I've never seen clearly stated; as near as I can figure, sbin is to
bin as root is to a normal user - /sbin and /usr/sbin have held stuff
that would normally go in /bin or /usr/bin but which is of no use to
normal users, only admins.  The difference between /sbin and /usr/sbin
is that between /bin and /usr/bin: stuff that is to be accessible when
booted single-user without filesystems mounted versus stuff that it's
OK to have to mount /usr to get.  (This is still linked with the
paradigm that makes /usr a separate filesystem.)

There's /etc.  Yes, I've seen executables in /etc; /etc/fsck comes to
mind in particular.  I don't know how far back this goes, but NetBSD
has as far as I can tell eliminated executables from /etc (well, except
for shell scripts, if you consider them executable).

This is complicated by dynamic linking.  In early implementations,
dynamic libraries lived in /usr, so anything that was supposed to be
usable without /usr mounted perforce had to be linked static.  That
this made them work when dynamic linking was hosed for other reasons
was a handy side effect, but I suspect was not really part of the
intent.

So no, I don't think /sbin is *intended* to be statically-linked
critical tools.  That's just a side effect that falls out of "/sbin
stuff needs to work without /usr" and "shared libraries live in /usr".
Now that NetBSD has libraries in /lib, the second part of that is gone,
so there is no longer any need to link /sbin stuff static based on the
original intent.

/rescue arose because there *is* a need to recover from shared-library
hosedness; there are reasonably plausible forms of damage that break
dynamic linking but are fixable with a little careful work with
statically-linked tools.

I don't entirely see the point of insisting on having dynamically
linked versions of tools that are kept around in statically-linked
versions anyway.  The usual concern I've seen cited is i18n, but (a) I
don't see how dynamic linking is crucial to i18n (locale processing
could be driven off data files much as timezone processing is) and (b)
in any case, the need for an executable to be dynamically linked in
order to use the dynamic linker is an implementation botch, not
anything fundamental.  If nothing else, the executable could be
dynamically linked but with an empty list of (dyanmic) libraries.
(There are some issues surrounding sharing data structures between
static code and dynamic code, with stdio as the poster child; while
they are real, I am confident they are fixable.)

/~\ The ASCII				der Mouse
\ / Ribbon Campaign
 X  Against HTML	       mouse@rodents.montreal.qc.ca
/ \ Email!	     7D C8 61 52 5D E7 2D 39  4E F1 31 3E E8 B3 27 4B