New special purpose distributions - Firmware Linux and NSLU2-Linux

[Posted January 3, 2007 by ris]

Two highly specialized Linux distribution projects were added to our Distribution List over the holidays and they are worth a closer look. These aren't your typical desktop distributions, or LAMP server distributions, but they do scratch a particular itch.

The first one we'll cover is Firmware Linux. It was introduced in this comment as an example of a Linux system that does not rely on GNU software, although it's not quite there yet. "Currently, building it still requires four gnu packages (gcc, binutils, make, and bash), but replacements for all four are in the works. (The replacement for gcc/binutils is tcc, which still needs some work, and I'm writing my own shell and when that's ready, my own make.) If your final system doesn't need to be a development environment, then it doesn't have to have any gnu code in it at all."

Firmware Linux is designed to be a build system that produces a bootable single file Linux system for various hardware platforms. Along the way, the build produces a relocatable cross compiler for the target hardware, and also a native build environment. This is a very young project, with only a few months of development so far, however, according to the news page as of changeset 68 it does build a native build environment with a working toolchain.

The second project is a bit more mature and has a family of Linux systems in development. The NSLU2-Linux project exists to discuss, develop and modify the firmware and hardware of the Linksys NSLU2, the Synology DS101, the Iomega NAS100d, the D-Link DSMG600, and other ixp4xx-based devices with large attached storage. SlugOS is the collective name for a group of firmware distributions which are derived from a common source base. The post to the NSLU2 mailing list summarizes the current state of the project. Here are some highlights:

Unslung - a distribution which is targeted to those who wish to continue using the vendor firmware, but add the ability to install Optware packages. Unslung is stable at version 6.8.
Optware - the ever growing set of packages available to users of Unslung and SlugOS.
SlugOS - a distribution based on OpenEmbedded, which completely replaces the vendor firmware with custom firmware and packages designed from the ground up for devices with limited memory and storage. The current stable version is 3.10 and work progresses on SlugOS 4.
NSLU2 is also a fully supported target for Debian Etch.
OpenWRT - work is underway to provide support for the NSLU2, NAS100d, DSMG600 and FSG3 in OpenWRT kamikaze.
Improved infrastructure with a move to OSUOSL for the main project server machine.
Look for NSLU2-Linux at the Fifth Annual Southern California Linux Expo (SCALE 5x).

LinuxDevices covered the Debian etch support in is this November article: "Now, the newly available RC1 release of debian-installer for Etch makes installing Linux on the Slug much easier, according to Debian ARM hacker Martin Michlmayr. For one thing, the generic IXP4xx kernel in Debian ARM now appears to support the device."

There's also an article on SmallNetBuilder, Hacking the Linksys NSLU2 - Debian and more with a look at the project's history.

BusyBox contains GNU software

Posted Jan 4, 2007 4:39 UTC (Thu) by JoeBuck (subscriber, #2330) [Link] (3 responses)

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, or does he just dislike RMS and tired of the FSF taking credit for everything? If the former, the use of BusyBox is no problem, 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.

BusyBox contains GNU software

Posted Jan 5, 2007 19:34 UTC (Fri) by landley (guest, #6789) [Link] (2 responses)

> 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.

BusyBox contains GNU software

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

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

New special purpose distributions - Firmware Linux and NSLU2-Linux

Posted Jan 4, 2007 9:03 UTC (Thu) by joey (guest, #328) [Link]

The article on smallbuilder is quite nice, just a few comments on the Debian installation part of it:

Looks like his terminal wasn't utf-8-enabled, probably, thus the ugly screenshots.
Debian's kernel for the nslu2 already uses the free ethernet driver. However, that driver still needs some non-free firmware, so the installation image will still not be distributed directly from debian, but still via slug-firmware.net, which can do the clickthru license thing.
I highly recommend reading /usr/share/doc/nslu2-utils/README.Debian on a debian slug system. It has some tips for making the system much more robust by, for example, enabling logging of the entire boot process (which would have saved some ugly debugging described in the article).
The issue with /etc/network/interfaces is probably netcfg bug #403706, and I'd love to hear a bit more details about it, since we're still working to solve that bug.