avoiding the kitchen sink (was Re: Dropbear...)

[Paul Fox]

 > 
 > the point is to build dropbear into busybox, not as a standalone executable

does anyone have numbers on the average amount of "overhead"
saved by taking a standalone program and putting it into busybox? 
while i'm sure there's always some savings, it's pretty clear
that the bigger the original program, the less you'd save as a
percent of the total just by using libbb routines instead of the
standard libc stuff.

i guess the point i'm getting at is this:  i don't think the
intent of busybox should be to be "all of linux in a box".  i
think it should be a convenient, efficient, way of getting most
of what one needs for a base-level (and that's the important
part:  base-level) functional embedded system.  i don't see
busybox as a kitchen sink, and it feels a little like that's what
it's becoming.  what will really be gained by adding dropbear? 
if the space savings aren't absolutely huge, is it really that
hard to build two pieces of software instead of one?  busybox
will never replace a system like buildroot, which integrates a
more complete system, so at what point do we stop trying?

it sort of seems to me that when the notion of "drop in"
integration comes up (as for udhcp, and as proposed for
dropbear), then it's not clear there's such a big win. 
maintenance certainly doesn't get easier -- witness having to sync
the standalone and busybox versions of the udhcp svn trees, which
i still haven't done.  and i'd bet that much of the savings of
making something an applet could be had simply by making libbb
available for external programs to link against.  i'd think this
(making libbb available) would be a good tradeoff for packages
that are really too big to add to busybox, but small enough to
make it worth doing the common busybox downsizing tricks.

paul
=---------------------
 paul fox, pgf at brightstareng.com