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

Me too. I think "a few" might be a little misleading. In a simple hello 
world dynamically linked app, the amount of function calling going on is 
truly horrendous. Assuming nothing has changed since I wrote my dinky 
"Adventures in Assembly" stories. gdb'ing through a dynamically linked 
executable was extremely painful, as I mentioned there. Surely complexity 
of that order is logically enough to impact performance in *some* way. :)

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

Mmm..  Magic recipes. Now *this* is the kind of stuff we should slap into 
the FAQs and NetBSD howtos. Ah, there it is. mk.conf manpage. :)

> : 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...?

Not a clue. It's never happened on a NetBSD machine under my supervision. 
Ever. Which is neat. Not that I haven't I've had some pretty nasty 
problems--one fs problem where the filesystem got to a state that panic'd 
the kernel when a certain file was accessed... something about a duplicate 
node..? I wish I had recorded the failure a little more diligently... 
(ramble ramble)

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

:)