> If it's good enough for installation, it must at least be OK for
 > normal use.
 > 
 > Pros:
 > 1) reduced disk space
 > 2) reduced VM consumption (you pay for init, everything else is free)

That's true for the code, but not for the data.  You do have to map the
large data segment into every process.  This is not shared, since it is
writeable.  The net effect on VM consumption is probably to increase it.

 > Cons:
 > 1) non-standard build/install process
 > 2) small time penalty because the crunch-generated wrapper code has to
 >    compare argv[0] to all of the sub-binary names
 > 3) possible security problems with setuid/setgid binaries.

If (2) ever really became an issue we could switch to a binary search for
the binary name search.

And (3) is fixable, if I ever make another pass at crunch.  The conf file
could specify which binaries need to be setuid/setgid to which
users/groups, and this info could be stored in the switch table with the
binary names.  Then you make the crunched binary setuid root, and have the
wrapper do the work to set the permissions properly for a given
sub-program.  Since the wrapper is very small, it should be easy to verify
as secure.

I've played with putting as many of the full system's binaries as possible
into a single crunched file, and it _is_ surprisingly small.  But I agree
that it's really not appropriate to do that to save space in /bin and
/sbin, since the whole point of linking those binaries static is for
increased reliability.

Jaime
..............................................................................
:  James da Silva  :  UMCP Computer Science Dept  :  Stand on my shoulders,  :
:  jds@cs.umd.edu  :  http://www.cs.umd.edu/~jds  :  not on my toes.         :