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
