Specular

I've often stumbled upon BusyBox, but only after noticing Alpine, by default, has wget installed did I start to investigate where it comes from. Except the wget version was "BusyBox Wget".

But what's that?

docker run --rm -it alpine sh
/ # which wget
/usr/bin/wget
/ # ls -lah /usr/bin/wget
lrwxrwxrwx    1 root     root          12 Apr 15 04:51 /usr/bin/wget -> /bin/busybox

After running ls -la /usr/bin, my mind was blown: nearly 130+ executables are from a single binary!

That explains the name "multicall binary". But... how? How does BusyBox work?

How does a single binary know which executable to run? Well, I guessed it right:

applet_name = argv[0];
if (applet_name[0] == '-')
  applet_name++;
applet_name = bb_basename(applet_name);

So, an explicit invocation would also work:

/ # busybox ls -1
bin
dev
etc
home

/ # busybox meheh
meheh: applet not found

So, to run wget, we find it by name and run it:

int applet = find_applet_by_name(name);
// ...
run_applet_no_and_exit(applet, name, argv);
// ...
xfunc_error_retval = applet_main[applet_no](argc, argv);

Each applet has its own C file, wget being wget.c. Each applet also appears to have some sort of "config" defined in code comments:

//config:config WGET
//config:	bool "wget (41 kb)"
//config:	default y
//config:	help
//config:	wget is a utility for non-interactive download of files from HTTP
//config:	and FTP servers.
//applet:IF_WGET(APPLET(wget, BB_DIR_USR_BIN, BB_SUID_DROP))
//kbuild:lib-$(CONFIG_WGET) += wget.o

And eventually, we invoke the wget main:

int wget_main(int argc UNUSED_PARAM, char **argv)

Other interesting bits: BusyBox also supports hard links.

busybox --install -s

-s creates symlinks.

You can also list what commands it has compiled in:

/ # busybox --list | wc -l
304

So, Alpine is more like an interface to BusyBox-based binaries. Each binary seems to be a bit stripped-down version of the actual full-blown one. I'd still be interested to know if these are reimplementations or just the original source code of the utility shrunk down.

So BusyBox is a potpourri of software reimplementations bundled into a single binary.

I've been thinking a lot that this era is the best possible time to learn the more fundamental pillars of software development, to figure out how the basics really work at a deeper level, and to aim for the top ranks of IT professionals while most of the industry is busy drinking Altman's Kool-Aid.

Maybe that's just my imagination, or maybe it's a fear that comes from watching people in my bubble let their skills rust by handing off their thinking to language models.

Of course that doesn't apply to everyone, but a number of people I know have completely shifted architecture and coding onto Claude, Codex, or whatever tool happens to be hot at the moment.

I'm not sure whether LLMs will ever be able to make use of depth of expertise in quite the same way, but depth of expertise is unlikely to go out of fashion anytime soon.

Developers who have spent years studying the field can learn to use today's most popular LLM in a matter of weeks.

Developers who have spent years doing development with nothing but an LLM are not going to gain a very deep understanding of the current state of the field and how things actually work in a week.

It will be interesting to see what companies that plan to build all their code with LLMs will look like five years from now.