I agree with David Schultz that dynamically linking
/bin and /sbin is playing with fire.  I, too, have had
ugly experiences on systems that did this:
When /usr won't mount, it is not pleasant to be
stuck with no tools.  (Consider a network environment
where /usr is NFS-mounted as an extreme example.)

As for the disk space concerns, I spent a couple of

hours with some of the smaller utilities.  Identical
functionality to the originals, still statically linked.
Compare with 'ls -l /bin' on your system:
  * echo: 3k
  * sleep: 3k
  * sync: 3k
  * cat: 40k with setlocale, 12k without
    (cat uses setlocale for non-standard -v option)
Total savings: over 150k just from these four.
This is under 4.x, though; last I checked, -CURRENT still
had some ugly bloat in crt.  (crt requires atexit, which
requires malloc, ugh.  Maybe this has been fixed?)

Easily-commitable details on request.

As for the resolver issue, maybe there's
another way to separate the resolver?  For
example, a simple command-line resolver utility
(something like a stripped-down 'dig') could
be invoked.  That would leave one utility
with the resolver libs statically-linked,
and remove it from many other places.  There's
an obvious performance hit, but resolving is a
fairly high-overhead operation in any case.

Alternatively, some sort of simple resolver
daemon could be implemented.  The BIND
folks are already moving in this direction
because of IP6 resolver bloat, I understand.
Either approach would shed resolver bloat from
a lot of places without the headaches of
dynamic linking.

Tim Kientzle

To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message

Reply via email to