Busybox 1.37 is tiny but capable, the way we like Linux tools to be Busybox is tiny, unobtrusive, and runs quite a lot of routers and other key bits of the internet – somewhat like Linux itself used to be. The Busybox developers have released version 1.37.0, with some 50 changes. It's now Year 2038-ready, its implementation of the late Dave Mills's NTP is Year 2036-safe, and it includes a …
As it happens, I've just migrated my laptop and desktop from busybox's mdev device manager to eudev. This was prompted by the Thinkpad suddenly deciding that it had found a new, removable SATA drive of zero bytes, which it assigned to /dev/sda replacing the actual SSD. mdev doesn't provide disks by label or by UUID so I had no way of making the kernel find the right drive.
eudev was looking dodgy for a while after Gentoo dropped it, but Devuan and Alpine developers have stepped up.
"I'm not sure that Busybox fits into the UNIX "Do one thing well", as it does lots of things,"
Arguably BusyBox does do one thing, and does it well... it packages a customizable set of core tools (including init and mdev, amongst other things) in as minimal a footprint as possible. Kinda handy in embedded work, and other low memory situations. Remember, you would need/want those capabilities even without busybox, but in a much larger footprint.
"What trips me up sometimes is that some of the commands it provides are missing options that I use"
So compile 'em in ... should be easy enough to figure out how for someone with you credentials. Busybox is nothing if not highly customizable.
./busybox lists the programs that it implements.
A lot of router/embedded Linux devices using busybox don't (sym)link all the programs that they built busybox to implement. Can be very useful if you need a program busybox provides - ./busybox program args...
These days the likes of Poettering &co would have had a daemon busyboxd and and a client busyboxc that passes commands etc via IPC to the daemon. ;)
I’ve not used busybox for a while but as far as I remember, it has bugger-all to do with Linux
You can use busybox with many different kernels (or no kennel at all).
Why does everything have to be described as “Linux” these days? I’ve lost count of the number of times BSD seems to be described as “a sort-of Linux”. It’s annoying. BB is NOT Linux
Yeah, under the "Swiss Army knife" link in TFA, one finds the statement:
"To create a working system, just add some device nodes in /dev, a few configuration files in /etc, and a Linux kernel"
But it can actually be used with FreeBSD (at least) and possibly Hurd (or port abandoned?) as well.
> But it can actually be used with FreeBSD (at least) and possibly Hurd (or port abandoned?) as well.
Huh. OK then. My bad; not only did I not know that, I read a comment elsewhere that strongly implied that it _was_ just a Linux thing and xBSD didn't directly have anything like it, and I did not follow that up and investigate.
I defer.
Remember when /sbin was for statically linked binaries, thus the name? Pepperidge Farms remembers.
Now everything is dynamically linked, so if something steps on libc6, it's a really bad day. Seeing "-bash: /bin/ls: cannot execute: required file not found" sucks.
Having a statically linked busybox squirreled away somewhere really gives you a fighting chance to fix things without too much pain.
However the version supplied with Debian is dynamically linked, which makes it about as useful as tits on a boar hog and forces you to compile it yourself.
However the version supplied with Debian is dynamically linked (...)
Debian does provide a busybox-static package which does exactly what it says on the tin. Although by the time a system is that far gone, I personally go straight to PXE, my Ventoy pendrive (complete with SystemRescueCD and the latest WhateverBuntu LTS), and/or (for RPis and similar), an SD reader + systemd-nspawn + qemu-user-static-whateverArchitectureTheImageUses.
FreeBSD /rescue is statically linked. It contains many-binaries-as-one-binary concept like BusyBox does, covering the command you'd typically need in a rescue.
The difference is that the source for each command is actually the full source that is used to create the individual dynamic commands, so it's not small. (almost 17Mb)
What was the problem with the BusyBox license that spawned toybox?
BusyBox is a standalone binary. Android can surely include that in the same way it includes the kernel - nothing propriety is linked to it without source code being available, and there would be no need to keep BusyBox tweaks (if any) private.
Two things, neither completely justified. The first was that, until version 1.3.0, its license was GPL 2 or later. As of 1.3.0, it became GPL 2 only, same as the kernel. Before that, people didn't like the ambiguity involved in letting whatever might show up in GPL version 3 (then unreleased) to be a core part of their system. This was only partially justified because the clarification came in 2006, so it's not like there was much need to deal with it.
The other reason was even less justified, namely that Busybox was a project well-known for pursuing their license rights. If you used Busybox, they would demand the source be released and sue you if you didn't. This rarely if ever gave the community useful code because anyone using Busybox didn't have much of a need to improve it, but it did certainly penalize people who don't comply with a really easy license. This shouldn't really be a problem, and it really wasn't, but some companies can't be bothered to release the source code they haven't changed and contains no secrets. I'm not sure why they find this so difficult, but having tried to get source code from them, I know they exist.
In general, one of the maintainers of Busybox got annoyed at another one and went off to create Toybox. This was in 2006, so before Android really went anywhere. Android had to choose between the BSD-licensed Toybox, run by someone who had added a lot of stuff to Busybox, or the GPL2 Busybox which had lost a maintainer but still had more people working on it. There wasn't an obvious good and bad answer, and it probably isn't that surprising that they went with Toybox. Having done so, Toybox has focused on keeping itself functional for Android, so it's not surprising that they're still using it.
@ognissanti: very interesting thanks but that nix stuff looks complex.
@jake: would I be a) untaring the source tars and compiling (hence installing gcc or clang itself built to use musl)?
or
b) would I be cross-compiling somehow from a musl based host system and untaring binary tars?
Icon: the dawn of a possible project is visible dimly between the clouds
The post they replied to linked to this GitHub repository with instructions for building a minimal distro using mostly just busybox, but those instructions do indeed involve installing bash too. As far as I can tell, not for any reason other than preferring bash to busybox ash, which I certainly do.
It goes on to also demonstrate adding nix, xorg, and tools for WiFi, but those are optional. The bash step is not written separately so even if you stop at the first bootable thing, the system they specify has bash in it. You don't have to do that.
I have now moved the bash part to its own chapter and have made it optional. Thank you for pointing that out! I tested to follow the first chapters yesterday and got a running system up in no time (on a machine that already had a bootloader and a linux distro with the dependencies to build the kernel)
Pretty sure that busybox is a key component in the wonderful Raydon firmware upgrade for the Humax FoxSat satellite receiver that I will big up here at every opportunity. Full on web server for admin and channel listings, FTP server, utilities all crammed into that little ROM. Mind you, the end result is a film collection currently around the 6,500 mark spanning 32Tb of storage - you have been warned.
The Register 
Biting the hand that feeds IT
Copyright. All rights reserved © 1998–2024
