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
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
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
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.
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.
to post comments)