Re: [bug-inetutils] More of a feature request than a bug fix

[David Horton]

>    > For a root/boot disk set I would not even recommend using inetutils,
>    > let alone things like the GNU C Library, they are not suitable for
>    > such specific systems.  Inetutils is written to be feature rich.  If
>    > you really need such featureless programs then there are far better
>    > alternatives.
>
>    Why *shouldn't* we make inetutils sufficiently modular to be suitable
>    for this?
>
> There is a big difference between making something modular, and making
> something small.  If making something small is the goal, then we
> shouldn't use nice functions likes argp/error etc, which make things
> modular.
>
> And anyway, if one is going to make a boot/root disk then one will
> need ls/cat/etc anyway, and coreutils is surely not the best place to
> get those programs.  Just to make a point ls compiled on my system is
> 281kb unstriped, and 65kb striped.  The whole busybox suit, including
> uClibc is proboly something inbetween.

I would like to shed a little light on why I made my suggestion:


Freedom, Baby

I wanted to use inetutils because it comes from GNU.  I respect GNU 
software because I believe that it will always remain free.  If I only 
wanted a lightweight "ping" I could have easily used net-kit instead. 
However, I believe that net-kit is now being maintained by Redhat. 
While I think Redhat does a great job promoting GNU/Linux software to 
the average end-user, I think if push came to shove, they would rather 
make a buck than be the guardian of software freedom.  The same goes for 
busybox, although I believe Debian maintains that one and I find them to 
be much more benign.


A Tight Root FS

Forget about the boot disk example for a minute and think about the root 
filesystem on a hard disk installation.  What sysadmin wouldn't be happy 
to have a small, tight root fs, free of clutter?  I have been building 
my own GNU/Linux system using the Filesystem Hierarchy Standard as a 
guide.  FHS says that if you have "ping" on your system it needs to live 
in /bin, so I put it in there.  Before doing that, a quick "ldd" on /bin 
told me that only glibc and ld-linux were required for all of the 
binaries that live there.  Placing "ping" in /bin now ups the 
requirements for libraries to include libm, libresolve, etc.  It just 
doesn't seem right to fill up the /lib directory only to support "ping". 
 As Spock said, "The needs of the many outweigh the needs of the few or 
the one."


Using Standard Software

In my boot/root project I chose to use GNU software because it is 
relatively standard.  I used BASH with the --minimal-config option 
rather that switch to some other micro-shell that is unfamiliar to most 
people.  This is the same reason I chose to use fileutils, sh-utils, 
textutils and possibly inetutils over something like busybox.  With a 
little planning you can actually fit a lot of this "standard" stuff onto 
one compressed rootdisk.  Take a look at the project at 
http://my.core.com/~dhorton/linux/pocket/html/index.html


Thanks for considering my suggestion and once again, thank you for 
taking the time to work on GNU software.