wojtek@wojtek.from.pl writes:

>please count just size of very-often-used programs - sh, mv, ls,
>init, etc...at least 500kB saving in MEMORY

Text segments are cached in memory anyways, so there would be no
noticable speed improvement over dynamically linked programs, except
in extraordinarily tight memory situations (and very much depending
on the situation then), in fact, static programs load faster and
execute a bit faster than dynamically linked ones.  The only
advantage would be that, for example, ls and cp would share the
few dozen kilobytes of libc text they otherwise would have a private
copy each but that certainly doesn't make up for the gross
disadvantages in a disaster situation when having dynamically linked
libraries (I've had a personal experience there, when some dork
"upgraded" the libncurses library on a linux machine in /usr/lib
and /lib, which /bin/sh (which really is a dynamically linked bash on
lignux) depends on.  Basically, we had to boot from CDROM to solve
this, which was rather unnerving, considering the server machine
wasn't equipped with a CDROM drive at the time of "failure".  Since
the BSD libc is so much smaller than the bloated Gnu libc that
haunts linux, there isn't much to be gained from putting dynamically
linked programs into /bin and /sbin[1], imho.

mkb

[1] HP-UX for example goes a third way, /bin is dynamically linked,
many things absolutely required in emergency cases, like a copy
of sh, are in /sbin, where stuff is statically linked, which would
probably be an acceptable compromise.  However, even on HP-UX,
I can't find a static ed(1) in /sbin, which means that the actual
implementation of that policy isn't perfect here either.