Fwd: Re: [klibc] klibc and what's the next step?

Paul Fox pgf at brightstareng.com
Thu Jul 27 03:17:41 UTC 2006


 > > i would have thought that ash and dash were pretty much on par, since
 > > one is derived from the other, and has been synced fairly regularly,
 > > until recently, anyway.
 > 
 > Our ash is 13,000 lines long.  The smallest it can compile down to (with all 
 > features disabled so it's basically unusable and "optimize for size instead 
 > of speed" enabled which is a backwards option by the way) is 48k, which is 
 > _still_ one of the largest applets in the tree (and about 1/20 of the total 
 > size of "make defconfig"; enable all the features of ash and it bloats 120k 
 > which is well over 10% a defconfig busybox).  2000 lines into ash.c it's 
 > still primarily declaring global variables and function prototypes.  It's 
 > full of brain damage like goodname() and exerror().  It's also full of 
 > #ifdefs, everywhere.
 > 
 > It's _crap_.

but which bugs, specifically, are you referring to?  there are certainly
bugs in ash, but in terms of usefulness in day to day scripting, none
of the other busybox shells even come close, and if any other
non-busybox shell came close in terms of quality per byte, busybox
would probably already have switched to it.  

in any case, i'm not sure what part of "ash and dash are pretty
much on par" you're disagreeing with.  do you think dash is
better for some reason?  we do some fairly complex scripting in
ash, and it holds up pretty well.

i know you have plans for bbsh, but i suspect it will be some
time before its quality is (or, at least, is perceived to be) as
high as that of ash.  so we've got to continue maintaining what
we've got in the meantime.

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



More information about the busybox mailing list