There is something
important to say about Busybox. It is a stagnant project in which upstreming is extremely difficult and this is mainly because Denis Vlasenko leadership. The previous maintainer, Rob Radley moved away and created toybox which is the default "busybox" of Android. So, it should be the reference rather than Busybox which should be considered a legacy.
So, how Open-Source and Software Libre achieve to work-around these kinds of empasses? Not always a skilled and good-willed person like Rob Radley get into the scene and decides to create a brand new project bringing a change that someone needs. So, the main idea is that many others can contribute to a fork. A successful fork, it is not just another repo but it is something that aims towards something different.
To be clear, Busybox is at this time the legacy - stable reference - for embedded systems. Fortunately, the concept of embedded system is changing and by now everything like a container, an AppImage a FlatPack or whatever like a small bootable USB system aka net-installer can be considered an "embedded system" for which coherence is
WAY MORE important than features.
Which is the main reason for the Danis leadership success. But it was in 2008, now we are in 2025. Nothing lasts forever. So, when I am referring to busybox -
EVERY TIME, I do - I have in mind a fork of it. And in particular this one (or the one from the original author of the patches):
So, why does this fork (or the original patches author) matter? Because at this time Denis' Busybox is requiring a set of libraries which are not easy to provide in a "micro" version and this is the reason because TinyCore can fulfill what is missing. Finally some arrived and proposed a large patchsets that can move Busybox towards the self-contained static binary, NadavTasher, actually.
In the past, I added contributions to Busybox when sponsored by a company BUT when I tried to add a layer for easy shell script debugging like bash has and some easy to achieve compatibility. That contribution was partially accepted, strongly rewritten (which is good, in general) but also missed completely the final aim: using a busybox ash for an advanced scripting debug.
Who cares? Few, actually. BUT an advanced debug shell script system allows us to consider Busybox ash as a full-fledged script interpreter. United to the possibility to have it as self-contained static binary (without external dependencies apart the kernel obviously, or any OS which is a Posix-like) make it a great start for something that INSTEAD is currently taken by micropython.
Problem solved? No. Because micropython is great for app/user land application included GUI combined with uTk or similar libraries with a limited footprint. While the shell script with all the applets included into Busybox, remains the best way to deal with a system. For this reason, it is time to switch to NadavTasher patchset, or a fork based on that.
Why? In order to develop a new Busybox which I renamed NT in honor of the author of the patchset, which will completely fulfill the needs related to
embedded system concept. Will it happen tomorrow? Hard to know, sometimes changes happen overnight but usually take their own time.
Moreover, it is fine that a legacy Busybox remains to sustain those who are feeling not ready for a change, a jump into the unknown. Or simply, trading stability for features. Which means that legacy embedded systems will continue to stay on legacy Busybox and those which will be developed within a modern fashion will take Busybox NT.
Also because the "modern" embedded system is MUCH MORE independent from the hardware and hence MUCH MORE easier to update. Which means a greater appeal to trade stability in exchange of features. So, Denis is not wrong. He has decided to sit on the top of Busybox for more than 15 years and made it a legacy HENCE created the condition for which is more easy and efficient to do a fork (Busybox NT) rather than battling for upstreaming features.
Guess what? Life does the same parents fork into their children, and so on. Nothing is forever, but the changement. Please, do not tell me that 15+ years to feel the urgency to make a change is TOO fast. In terms of IT, it is 10 generations. So, when I say Busybox, I am intending to go with Busybox NT, because someone had to take a new way.