BB growth and shrinkage; musings

[Cathey, Jim]

>perfection is achieved not when there's nothing more
>to add but nothing more to take away...

Linux/BB gets heavier and heavier, and it's not really
BB's fault.  I blame the tools/environment.  :-)

I did a quick peek, and the old DNIX system I used to
spend all my time on was pretty lean.  (SVR2 work-alike.)
Here are some of the /bin entries:

  dr-xr-xr-x   2 jcathey  root        0 Dec 26  1997 .
  drwxrwxrwx   2 jcathey  root        0 Dec 31  1969 ..
  -r--r--r--   1 jcathey  root      892 Oct  3  1993 basename
  -r--r--r--   1 jcathey  root     9560 Mar 31  1994 cat
  -r--r--r--   1 jcathey  root    13116 Jul  3  1995 chany
  -r--r--r--   1 jcathey  root    13116 Jul  3  1995 chgrp
  -r--r--r--   1 jcathey  root    13116 Jul  3  1995 chmod
  -r--r--r--   1 jcathey  root    13116 Jul  3  1995 chown
  -r--r--r--   1 jcathey  root     9472 Sep 13  1995 cmp
  -r--r--r--   1 jcathey  root     8452 Nov  2  1995 cp
  -r--r--r--   1 jcathey  root    17640 Mar  7  1996 date
  -r--r--r--   1 jcathey  root    10716 Jun 19  1996 dd
  -r--r--r--   1 jcathey  root     9584 Nov 19  1993 df
  -r--r--r--   1 jcathey  root      892 Oct  3  1993 dirname
  -r--r--r--   1 jcathey  root    14152 Mar  9  1995 du
  -r--r--r--   1 jcathey  root     6092 Oct  6  1993 env
  -r--r--r--   1 jcathey  root     6600 Apr 12  1996 hd
  -r--r--r--   1 jcathey  root     6528 Mar  9  1995 head
  -r--r--r--   1 jcathey  root     2616 Aug  2  1994 kill
  -r--r--r--   1 jcathey  root     8452 Nov  2  1995 ln
  -r--r--r--   1 jcathey  root    30700 Jan  1  1996 ls
  -r--r--r--   1 jcathey  root     4384 Oct  1  1993 mkdir
  -r--r--r--   1 jcathey  root     8452 Nov  2  1995 mv
  -r--r--r--   1 jcathey  root     2664 Apr 13  1994 nice
  -r--r--r--   1 jcathey  root     1768 Jul  8  1996 nkill
  -r--r--r--   1 jcathey  root    18908 Mar 23  1996 ps
  -r--r--r--   1 jcathey  root     6428 Mar  9  1995 pwd
  -r--r--r--   1 jcathey  root     3460 Mar 19  1996 renice
  -r--r--r--   1 jcathey  root     6924 Jul  3  1995 rm
  -r--r--r--   1 jcathey  root     4204 Oct  2  1993 rmdir
  -r--r--r--   1 jcathey  root      988 Dec  2  1993 sleep
  -r--r--r--   1 jcathey  root     5040 Apr 20  1994 sum
  -r--r--r--   1 jcathey  root      788 May 26  1995 sync
  -r--r--r--   1 jcathey  root     8760 Sep 20  1994 tail
  -r--r--r--   1 jcathey  root     3856 Jan 26  1995 tee
  -r--r--r--   1 jcathey  root    11228 Mar  9  1995 time
  -r--r--r--   1 jcathey  root     6236 Sep  1  1993 tty
  -r--r--r--   1 jcathey  root     5596 Sep 28  1995 uname
  -r--r--r--   1 jcathey  root     5040 Apr 20  1994 wc

The hard links (like the cp/ln/mv triad and ch* quartet)
don't appear right because this was extracted from a CD,
not a live system.  Likewise the permissions and ownership
are wrong.

I bring this up because this system was also the target of
an extensive squeezing effort, but rather than the swiss army
knife approach of BB I spent effort on eliminating unnecessary
code.  (There was a lower barrier to entry this way.)  Chiefly
this meant getting rid of printf where it wasn't really necessary.

This system was 68K-based, with a non-shared highly granular
libc.  (Original Unix in structure, in other words.)  Removing
printf in this world got rid of the buffered I/O library, and
the floating point library, neither of which are of any real
use for something like sync, say.  What was left was usually
interestingly small.  The tools themselves were not really
'stripper' versions of larger tools, like BB vs Gnu now,
but they did tend to be on the lean and mean side, feature-wise.
(The full development system had less resources than the usual
embedded 'toaster' now.  My, how things have changed!)

The drive for this was to get a 1.44MB rescue floppy that had
a pretty full toolset as well as a full kernel on it, and that
project was quite successful.

I wonder how a BB would fare against this other approach,
in that environment.  In this one, too, except that as
shared glibc is nigh impossible to ditch it really skews things.
The more I use shared libraries the less I like 'em.  This
system had two: a graphics imaging library and a WAN link
data compressor.  They were trials in that sort of line, at
a time when everyone was experimenting with them, and weren't
entirely successful in that they really didn't buy much.
(Typically only one client program each used them.)  Fortunately
the runtime overhead was very lightweight, unlike now.

In that environment I think a hybrid approach of the existing
shrunk utilities, combined with a BB for all the ones that
_did_ need printf et al., would probably yield the best overall
shrinkage.  It's hard to see how utilities that mostly only
use libc(2) can benefit a great deal from a commune executable.

Well, my ramble is over.  I just enjoy thinking about different
ways to do things.

-- Jim