BusyBox contains GNU software

BusyBox contains GNU software

Posted Jan 9, 2007 17:06 UTC (Tue) by nix (subscriber, #2304)
In reply to: BusyBox contains GNU software by landley
Parent article: New special purpose distributions - Firmware Linux and NSLU2-Linux

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.

---

to post comments