On Fri, 21 Dec 2001, sudog wrote:

: > Another pro you haven't mentioned is that the memory usage of programs in
: > /sbin and /bin will decrease in this scenario.

: Not so noticeable. How many copies are running simultaneously and impact
: the memory of critical server software that this would make any useful
: difference in large-scale system?

NetBSD runs on much more hardware than "large-scale" systems.

The memory/space win is most noticeable on NetBSD's slower architectures --
vax, all the m68k's, pc532, arm26....

However, the real problem that this proposal was trying to address has more
to do with making it possible to have bootstrap tools (such as those which
get access to network resources in order to mount /usr, like mount_*) with
the ability to have access to rune locales, external authentication systems,
and so forth, that are simple to implement as shared objects.

: Besides, if static copies are noticeably faster, then why would I (as a
: rhetorical virtual hoster of masses of websites, for example) want to
: take a performance hit just to save a few megabytes of RAM?

Depends on how you define "noticeably faster" here.  If you have a lot of
memory (which you imply here), the needed pages of libc.so and ld.so should
be in-core, so the only startup overhead is linking perhaps a dozen symbols.
I'd be interested to see benchmarks on this....

The argument doesn't hold up well, given the fact that only /bin and /sbin
are static.  If you want "static binary speed increases", then you can
simply rebuild the whole system yourself statically.  You can do it with one
mk.conf switch:  "MKPIC=no".  8-)

: And I can't count on my hands and feet the number of times that busy
: (millions of hits/day) Linux systems under my care have died because
: something went bad and puked all over either libc, or libc and the dynamic
: linker, making the entire thing useless until someone arrived on-scene
: with a boot-disk.

And how is this situation different from something puking on NetBSD's
/sbin/init binary...?

The argument about the shared libraries being "the" point of failure doesn't
hold up.  On NetBSD, if *any* of the following are missing, you can't boot
to single-user with the standard boot disk and do anything useful.

* /sbin/init
* /dev/console
* /dev/{yourdiskdevices} and /sbin/mount_mfs simultaneously

Moving to shared libraries doesn't change this situation much.  It may add
another /bin and /sbin dependency, but a Reasonable sysadmin knows how to
take precautions with critical files such as these.  'chflags schg'.  8-)

On a related note, if you're paranoid about trashed critical files, you
should have a netbsd.INSTALL.gz located on at least one of your partitions
(hopefully all of them).  That helps catastrophic recovery a lot -- take it
from experience.

-- 
-- Todd Vierling <tv@wasabisystems.com>  *  Wasabi & NetBSD:  Run with it.
-- CDs, Integration, Embedding, Support -- http://www.wasabisystems.com/