Inside the ToyBox: An interview with Rob Landley
by Dj Walker-Morgan
A recent controversy about the legal aspects of software licensing put Rob Landley in the middle of an argument, but Landley says his real focus is on code, especially his ToyBox project – a reworking of the concepts of a project he once maintained, the Swiss-army knife of commands that is BusyBox. The H had a chance to talk with him about ToyBox, BusyBox and why he likes to work on these multifunctional monolithic utilities.
The H: For background, what does your day job involve? Is it all embedded development?
Rob Landley: I've done a bit of everything, but right now I'm doing board bringup. The team I work for takes prototype hardware derived from a reference implementation some upstream supplier once got Linux booted on, and then we try to reproduce what the vendor did and make all the new peripherals in the prototype work. There's not a whole lot of new code to write, because the hardware guys design the boards around parts the vendor already wrote a Linux driver for. Half of what we do is figuring out how to configure the existing drivers the right way, and most of the rest is proving that some wire doesn't go to the right place yet and they have to fix the hardware.
It's all debugging, really. Writing new code is just debugging an empty screen...
The H: Looking back, how did you get involved with BusyBox?
RL: An old floppy distribution called "tomsrtbt" introduced me to it. Back when floppies mattered, they fitted an entire Linux distro on a specially formatted (1.7 megabyte) floppy. I was amazed how useful a system they crammed on there, and the secret was BusyBox linked against uClibc.
What got me modifying BusyBox was my Aboriginal Linux project, the history of which I once wrote up at http://landley.net/aboriginal/history.html. I switched my desktop from OS/2 to Linux in 1998, and started looking for instructions on how to build a complete system from source code almost immediately. I spent most of Atlanta Linux Showcase in 1999 pestering people about "installing Linux with a compiler and a pair of tweezers", and after I got back, somebody I met there emailed me about the Linux From Scratch project. I got around to trying it in 2000, and by 2001 I was writing scripts to automate it.
By around 2003 Red Hat had figured out how to steal all of Sun's customers and got sucked right out of the desktop business, going from just over half the Linux desktop to "we're no longer interested in doing this" in about two releases. That left a huge vacuum, and during this period SuSE was going bankrupt, TurboLinux gave up on the US market, Debian was paralysed by infighting, Gentoo prided itself on being impossible for normal people to install, even Patrick Volkerding (the Slackware guy) was laid up by a toothbrush-related illness. Until Ubuntu came along around 2005, the only distro still trying to do Linux on the Desktop was Knoppix, so I ran Knoppix (from my hard drive) for a couple years.
Knoppix was a bit like tomsrtbt in that they fit as much Linux on a CD as they could, making clever use of a constrained space. But they wasted about 1/6th of the CD on GNU tools that could be replaced by BusyBox and uClibc, and there was clearly a huge amount they could do with that space.
So I relaunched my automated Linux From Scratch builder with the goal of replacing as much of the GNU bloatware as possible with BusyBox and uClibc. My first goal was to get it to rebuild itself under itself, since I was using it as a development environment and knoppix couldn't switch over if that didn't work.
This was a huge task but I made steady progress, almost all of it by modifying BusyBox. I'd pick a GNU package that had to die, get a list of all the commands it installed, iteratively remove one more GNU tool from the $PATH and replace it with the busybox version, try to build, figure out how to fix it, and so on until the non-BusyBox package was no longer needed.
Along the way I wound up completely rewriting a bunch of commands, little stuff like sed, sort, mount, bunzip2... and when Erik Andersen declared a 1.0 release of BusyBox and moved on to other things I wasn't done yet. Five months after 1.00 I collected together a bunch of bugfixes and sent him the tarball to bless as the 1.01 release. When I put together a similar release out of the development tree a few months later, he handed over root access to the server and said I was maintainer now.
For a while I maintained a tinycc fork for similar reasons: at the time it was one of only three compilers to ever build a bootable Linux kernel, and if I could upgrade it enough I could get my simplest possible self-bootstrapping Linux down to just four packages: tinycc, linux, BusyBox, and uClibc.
The H: So what was the genesis of ToyBox? Was it coder frustration or just a desire to work on a clean sheet of paper?
RL: I announced the ToyBox project at the end of my resignation letter from BusyBox maintainership. I left BusyBox when someone who hadn't touched the project since before I even discovered it showed up out of nowhere to claim credit for all my work and tell me how to run things. This took all the fun out of working on it, so I stopped, but BusyBox still didn't do everything I needed (it didn't completely replace all the GNU tools in a self-compiling system), and I really liked that kind of programming, so I started a new project from scratch which nobody could possibly mis-attribute to that guy.
I never really made a big push with ToyBox because undermining my own hand-picked successor seemed impolite, and competing with a project that had a ten year headstart (including several years of my own work) meant no matter how technically better I made the code it would never displace the "good enough" existing project. I just needed things for my Aboriginal Linux project that BusyBox couldn't do, and once I'd implemented the major missing functionality I actually mothballed ToyBox and started pushing its code into BusyBox.
So Toybox's original goal had run out around 2008, and I mothballed the project soon after.