Being initially developed for use on a floppy-sized bootable system, busybox was designed with a small memory footprint in mind. Today it is used not only on actually small systems like routers and maybe washing machines and microwave ovens, but also on high powered NAS, Smartphones and rescue systems for Desktop Linux Distributions. (On the latter maybe for ensuring it fits in some boot loader images?)But being a single binary it also is a single point of failure. Why don't just use a standard user land instead of busybox on such machines?
Reasons for Busybox on Current Systems
busybox
But being a single binary it also is a single point of failure.Even a standard user land has tons of those. Corrupted libc? Missing dependencies? Too bad.Why don't just use a standard user land instead of busybox on such machines?The beauty of busybox (and its alternatives such as toybox) is that it's small, simple, and quite sufficient for the task. It works, so why use something else?It's used on any desktop PC too, as part of the initramfs, again for simplicity. While you could duplicate a real userland there, it would just blow the kernel/initramfs size beyond proportion. And a larger initramfs means longer load times and a slower boot process.For firmware vendors, it's also easier to keep track of a single project, instead of doing what Linux distributions do, trying to make various components fit and work together and tracking bugs for each of them...Of course busybox also has its limitations, for example it's difficult to compile a Linux kernel in a busybox environment, since some functions are simply missing (ar for example is lacking some options the kernel wants to use). But for initramfs or smartphones, such limitations don't matter.