On Wed, Nov 3, 2010 at 7:58 PM, Cathey, Jim <[email protected]> wrote: >>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. :-)
It does not. Really. See my other mail. > 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, busybox wouldn't use libm if these two options are off: CONFIG_FEATURE_AWK_LIBM=y CONFIG_FEATURE_DC_LIBM=y Getting rid of printf means avoiding bb_error_msg(). Which is everywhere. Currently, even in xmalloc. > neither of which are of any real > use for something like sync, say. What was left was usually > interestingly small. Currently, if you limit yourself to these applets only: CONFIG_BASENAME=y CONFIG_FALSE=y CONFIG_TRUE=y CONFIG_PIPE_PROGRESS=y CONFIG_VOLUMEID=y CONFIG_BBCONFIG=y then bbox wouldn't use printf. This list can be extended, but it seems like it is not worth it. Very many applets want at least print error messages: # ./busybox cp qwe rty cp: can't stat 'qwe': No such file or directory and this needs printf machivery. Open-coding it without printf will quickly make code bigger and harder to understand. > (The full development system had less resources than the usual > embedded 'toaster' now. My, how things have changed!) That is one reason why things get bloated: programs tend to fill all available storage. IIRC it's one of Murphy laws. > 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. Yep, let's see. Your files total to 243284 bytes (counting hardlinks only once), and have 37 executables. I built busybox with 34 applets from that list (I don't know what are chany, hd, and nkill). Result on x86-32 with uclibc, shared and static: # ls -l busybox.shared busybox.static -rwxr-xr-x 1 root root 60624 Nov 6 02:46 busybox.shared -rwxr-xr-x 1 root root 69560 Nov 6 02:46 busybox.static # size busybox.shared busybox.static text data bss dec hex filename 55692 1394 8416 65502 ffde busybox.shared 65477 1574 8440 75491 126e3 busybox.static config is attached. -- vda
.config.bz2
Description: BZip2 compressed data
_______________________________________________ busybox mailing list [email protected] http://lists.busybox.net/mailman/listinfo/busybox
