BusyBox 1.36 Released With SeedRNG, Many Other Additions

[phoronix]

Phoronix: BusyBox 1.36 Released With SeedRNG, Many Other Additions

It's been one year and a few days since BusyBox 1.35 was released while today it's been succeeded by BusyBox 1.36 for this software package that is common to embedded Linux environments with the lone executable providing a plethora of commands and functionality...

https://www.phoronix.com/news/BusyBox-1.36-Released

[milkylainen]

Here I was, just discussing the imminent death of Busybox and eventual consequences.
Turns out, there is still life in the project. Glad to see.

[caligula]

Here I was, just discussing the imminent death of Busybox and eventual consequences.
Turns out, there is still life in the project. Glad to see.

Isn't it kind of obsolete ? The original author moved to Toybox. Busybox is built using legacy C. It should be Rust based in 2023. Some GPL zealot tried to hijack the project. Also the utilities don't support all advanced (GNU) features. Does it even support decompression of zips from a curl pipe?

[dev547]

It should be Rust based in 2023.

Brokenbydesignbox?

[milkylainen]

Isn't it kind of obsolete ? The original author moved to Toybox. Busybox is built using legacy C. It should be Rust based in 2023. Some GPL zealot tried to hijack the project. Also the utilities don't support all advanced (GNU) features. Does it even support decompression of zips from a curl pipe?

Obsolete? Compared to what? Toybox?

Also. Who cares if it's written in C? Is this like language racism?
Do you measure the software by the solution it's providing or the language it's written in?
You're free to go rewrite the entire interwebz in Rust, I won't be stopping you.

Piping data between programs is usually provided as shell function (at least that's what you seem to be referring to?).
Busybox carries it's own implementation of shells. ash is one of them.
Being ash in a condensed form, and not bash, it has very few "normal requirement" issues.

[archkde]

Busybox carries it's own implementation of shells. ash is one of them.
Being ash in a condensed form, and not bash, it has very few "normal requirement" issues.

Bash (the GNU Bourne again shell) is not related to ash (Almquist shell) in terms of code lineage. And to be very pedantic, BusyBox ash is itself a derivative of dash (the Debian Almquist shell).

[gavron]

...
It should be Rust based in 2023. ..

As it is open-source, if you and others are of that opinion, why not either take on coding it in Rust, or form a project and encourage others to do it. If you're half-serious I'd be happy to pitch it to embedded-system mfgs for sponsorship. I just don't want the project management headache, and I'm not a Rust coder (yet).

E
Tucson AZ US NA SOL-3 MW-1

[MastaG]

For each foss project not written in Rust, God kills a kitten.

[Rallos Zek]

Isn't it kind of obsolete ? The original author moved to Toybox. Busybox is built using legacy C. It should be Rust based in 2023. Some GPL zealot tried to hijack the project. Also the utilities don't support all advanced (GNU) features. Does it even support decompression of zips from a curl pipe?

The Rust Evangelism Strikeforce strikes again!

[DrYak]

The original author moved to Toybox.

Bruce Perense (the actual original author) hasn't been touching any CLI tool box for year. There has been many other main developers over the years.
The one you're thinking about is Rob Landley, the previous Busybox main dev, who then moved on to write Toybox but has still exchanged ideas and code with Denys Vlasenko, the current one.

Busybox is built using legacy C. It should be Rust based in 2023.

And so is toy box.
On the other hand, such GUI tool box have very small codebases which makes it easier to audit (Rob tells anecdotes that back when he was developper for BusyBox, guys from NORAD told him they where using busybox instead of gnu coreutils, because of smaller code base to audit).
Toybox itself is written on purpose in a style that has as simpler code as possible.
(No clever optimisation trick unless strickly necessary).

Some GPL zealot tried to hijack the project.

Funnily, this was accidentally set off by Rob himself.
He got in touch with Eben Moglen's Software Freedom Law Center.
The idea was to use Busybox (which is widespread in embed system) to push manufacturer to follow the copyleft spirit and release their source code.
According to Rob this devolved into a thing to keep lawyer busy and insure them a regular revenue, but didn't really lead to more open devices nor additional code into Busybox, hence his next project got licensed under a public-domain like license (the "0-clause" BSD).

Also the utilities don't support all advanced (GNU) features.

...which is the whole point of GUI tool boxes like busybox and toybox:
a minimalistic subset that's still standard-compliant and good enough to perform basic tasks (boot systems, build systems, etc.)
not all the bells-n-whistles of GNU.

Does it even support decompression of zips from a curl pipe?

Piping ZIP files is at best a hack (same as streaming AVI and MOV files), as the official on-disk format doesn't support streaming, require lots of random seeking, and starts by reading at the end of the file (contrary to most other formats, the "central directory" header comes after all the compressed files, and the "end of central directory record" comes completely at the end after that).
That made it easier to write everything in one go back in the early days, and made it easier to append files, too.
But it means that the canonical way to access content of ZIP requires the whole file to have already been downloaded.

It's technically possible to already start decompressing stuff as the data arrives, and only apply the file properties afterwards, once the central directory arrives, but it's not following the standards.

In short, it's not possible to pipe into a simple unzip command, pipe support needs some special extra custom code, and this is exactly what Busybox, Toybox and similar tool boxes try to avoid: no special weird cases for rarely used non-standard features.

This is different from piping tarballs: those are just plain compressed stream (so it's possible to pipe them straight into a decompressor like gunzip, bunzip2, xzcat, etc.), which then in turn contains a tar file which is a format where each file is stored together with its metadata, one after the other (so it's possible to extract the file, without needing to first jump to the end of the tar to get metadata).