BusyBox contains GNU software [LWN.net]

BusyBox contains GNU software

Posted Jan 5, 2007 19:34 UTC (Fri) by landley (guest, #6789)
In reply to: BusyBox contains GNU software by JoeBuck
Parent article: New special purpose distributions - Firmware Linux and NSLU2-Linux

> I'm not sure what the motivation of the Firmware Linux guy is: does he
> want to avoid GNU software because it's too bloated for embedded
> systems,

I initially started looking at BusyBox, years ago, when I made the
mistake of looking at the source code for the gnu implementation of cat,
which at the time was 833 lines of C code. There's just no excuse for
that.

A development environment using glibc and coreutils and gnu tar/gawk/gnu
sed etc is over 30 megabytes _compressed_. One using busybox and uClibc
is 12 megabytes, and 90% of that is gcc/binutils. (A surprising part of
the rest is /usr/include.)

Using tcc, I might be able to get it down under 2 megs.

> or does he just dislike RMS and tired of the FSF taking credit for
> everything?

I find them taking undeserved credit for stuff annoying, yes. (Linux
forked off of _Minix_, the GNU project was already dead.) But the fact
they regularly produce _crap_ is what motivates me to actually do
something about it.

FSF-sponsored projects tend to bloat until they stagnate and die,
although it's not always obvious. (The original gcc died, forked off
egcs, then egcs inherited the name (gcc 2.95) and was suckered into
letting the fsf take over again at 3.0. A similar thing happened with
glibc->glibc2 (another "fork inheriting the name from the FSF's failed
attempt"). The most _successful_ gnu ones are the ones like tar that go
5 years between releases (tar 1.13 1999, tar 1.14 2004. And don't tell
me "there was nothing that needed doing", tar 1.13 didn't support -j to
do bzip2 and everybody who distributed it patched that in.)

> but if the latter, much of the BusyBox code is copyrighted by the Free
> Software Foundation; many of the BusyBox applets are just stripped-down
> versions of the corresponding GNU programs.

Hi, I wrote my first busybox applet in 2003, and was the de facto BusyBox
maintainer by 2005, and official maintainer in 2006. BusyBox has well
over 100 commands, and a quick grep shows that the only files with FSF
copyright notices are ash, printf, uname, expr, fold, gzip, stty, sum,
uuencode, state, md5, xgetcwd, time, our built-in copy of the shadow
support code, and some of the menuconfig infrastructure taken from the
linux kernel. Most of the busybox applets are our own implementations.
I personally wrote lots of 'em: sed, sort, mount, bunzip2, netcat, df,
dmesg, halt, losetup, mkswap, umount, seq, switch_root...

Being FSF free someday is to prove a point (GNU/Linux/Dammit is a
misnomer), but it's also a todo item rather far down on the list.
Working well in 4 megs of ram on a NOMMU system _and_ an x86_64 laptop
with 16 gigs is a lot more important. And having simple clear code you
can read and understand, with minimal environment dependencies... That's
what keeps me going.

(Log in to post comments)

BusyBox contains GNU software

Posted Jan 9, 2007 17:06 UTC (Tue) by nix (subscriber, #2304) [Link]

The glibc environment is a good bit smaller if you leave out the immense _g.a and _p.a files --- or, better, leave out all the .a files except for libc_nonshared.a and libpthread_nonshared.a. (glibc doesn't support static linking to any real degree anyway: if you want a tiny environment with all-statically-linked binaries, well, you use uClibc, but this is where we came in ;) )

But uClibc is definitely much smaller. glibc's bloat is pretty much ignorable when you consider the size of modern hard disks, but there's no way it would fit in embedded environments (nor, given Ulrich's much-publicised distaste for minority platforms, that it would work on most such embedded environments at all.)

I don't think `the GNU project' has ever been `dead' as such, because it's never really been a coherent-enough entity to `die'. It's a bunch of vaguely-ideologically-connected free software maintainers writing software that at one point RMS either started or asked someone to start. As such, large bits of it are dead or dying or long-term moribund or just plain obscure (the GNU Interactive Tools, for instance, or the HURD); other large bits are utterly crucial; all of them go through cycles of activity and inactivity (GCC was rather moribund in the mid-90s, when glibc was going quite strong, for instance).

I tend to consider RMS's various statements about what does or does not `comprise GNU' to say nothing whatsoever about the `ownership' of the packages in question, any more than RH saying that RHEL will ship GNOME means that RH now `own GNOME'. Of course they don't: it just means that they might devote developers to it. (RMS has been clear about this at times, e.g. regarding X11, and rather less clear at other times...)

GCC was never `suckered into letting the FSF take over again'; GCC/egcs never left the aegis of the FSF, and the primary maintainer of GCC-2.7.2.x was also an active maintainer of egcs (and eventually gave up merging anything back into GCC 2.7.x, after which the egcs fork was de facto identical to what GCC had been except with a more open development model).

tar went moribund because, well, nobody wanted to be its upstream maintainer, as far as I know. (So did diffutils). Now tar is alive again and diffutils shows spurts of activity. autoconf was moribund for ages but then came back to life with an astonishing flood of work from Akim `a2ps' Demaille... lots of non-GNU projects show similar stop-and-start activity patterns (X11, to give a really extreme example).

The nice thing is of course that because this is all free software it doesn't have to die when nobody's interested in maintaining it, and it can be reanimated (by eating some new maintainer's brain!)

Making changes just to be FSF free strikes me as an astonishing waste of time. Most FSF projects have very robust and comprehensible code: you attack coreutils, but compare its implementations of tools with the awful arbitrary-limit-filled crashy crap that comes with proprietary Unixes, and it becomes plain that coreutils isn't all that bad after all.

BusyBox contains GNU software

Posted Feb 26, 2007 1:50 UTC (Mon) by landley (guest, #6789) [Link]

> I tend to consider RMS's various statements about what does or does not
> `comprise GNU' to say nothing whatsoever about the `ownership' of the
> packages in question, any more than RH saying that RHEL will ship GNOME
> means that RH now `own GNOME'. Of course they don't: it just means that
> they might devote developers to it. (RMS has been clear about this at
> times, e.g. regarding X11, and rather less clear at other times...)

Red Hat never insisted that Ubuntu or Debian call their distros "Debian
Red-Hat-Linux". But RMS insists that there's no such thing as a Linux
that isn't GNU/Linux/Dammit.

Rob