The current state of the BusyBox project

My name is Rob Landley, and I'm the new maintainer of BusyBox.

BusyBox is a small and simple implementation of a set of standard Linux command line utilities. A minimal system built from BusyBox, the uClibc C library for embedded Linux and a stripped down version of the 2.6 Linux kernel known as Linux-Tiny provides a complete Linux command line environment that can boot in 4 megabytes of ram from less than 2 megabytes of disk space. This makes BusyBox very popular for use in embedded Linux systems.

A Linux system built from just six packages (BusyBox, uClibc, Linux, GCC, binutils, and make) provides a build environment that can recompile itself from source code. In its default configuration, the 1.2.x versions of BusyBox will provide at least minimal replacements for twenty-one standard packages: bzip2, coreutils, dhcp, diffutils, e2fsprogs, file, findutils, gawk, grep, inetutils, less, modutils, net-tools, procps, sed, shadow, sysklogd, sysvinit, tar, util-linux, and vim. All of these utilities are provided by a single executable that is less than 1 megabyte in size.

BusyBox's "swiss army knife" design is one of its most noticeable space-saving features. One binary file has many symbolic links pointing to it, named for the commands that Busybox replaces. Busybox determines which applet to behave as by examining argv[0] to see which name it was called under.

A lot of BusyBox's appeal beyond the embedded world is simplicity. For example, the gnu coreutils version of cat.c is currently 772 lines of C code, while the busybox version is 40 lines of C code. Which one would you rather try to read through and understand, port to a new environment or audit for security holes?

BusyBox applets are smaller than other implementations because code size is the primary design goal. Many BusyBox applets are fresh implementations starting from the SingleUnix Specification version 3, with various GNU-compatible extensions added from the man pages as desired. Other applets have been derived from NetBSD or elsewhere, but we constantly rewrite and re-implement everything we feel we can make smaller, simpler, or less memory intensive. This means that existing applets can actually shrink over time. The project has also adopted the rule that any new feature that adds size has a configuration option to remove it at compile time.

Building BusyBox is fairly straightforward, the process has been modeled after the Linux kernel build method. The build process involves extracting the source, configuring with a linux-style "make menuconfig" command, then running make and make install. Other make options include: "make defconfig" to enable all standard features, "make allnoconfig" to start with everything disabled, and "make oldconfig" for dealing with previously used .config files. From menuconfig, each applet is independently selectable. Many applets have sub-features that can be disabled to save space. Cross-compiling is regularly tested with targets set to popular embedded processors and the x86-64 platform.

Project History

BusyBox was started in 1996 by Debian's then-maintainer Bruce Perens, as part of the Debian boot/rescue floppy disk project. In 1999, Erik Andersen saw potential for BusyBox beyond the Debian boot disk, rewrote the project extensively, and over the next few years built an active development community around it. During this time Erik similarly rewrote and built a development community around uClibc. As embedded Linux grew in importance, both projects became more time consuming. After the BusyBox 1.00 release, Erik focused on uClibc (which is still pre-1.0) and handed off BusyBox maintainership to me, I am currently trying to take over the world with it.

Taking over the world involves making BusyBox a good choice for use in general purpose Linux servers and workstations as well as its traditional role in embedded systems. For example, our completely rewritten bunzip2 code is not only 1/10th the size of the standard implementation, but also 10% faster. Our udev replacement (mdev) is much easier to configure, and in some cases can be used without any configuration file at all. Our mount command was the first to autodetect attempts to mount image files, so specifying "-o loop" became optional. Space-constrained environments like bootable CDs, or the One Laptop Per Child project could especially benefit from BusyBox.

The future goals of BusyBox include making the code even smaller, improving support for systems with no memory management unit, adding a test suite and adding the ability to make standalone versions of individual applets.