Landley said in one of his talks (I think it was the linked one) that his goal with Toybox was to enable Android devices to function as a Linux-like development environment.
Toybox provides the shell utilities. You can plug in a keyboard and mouse via the USB charging port. You can screencast to a TV via a Chromecast. Somehow you'd need to get a compilation toolchain on there.
It's an interesting idea IMO. For many people an Android device is their only computer... though I'm not aware of anyone doing this for real in the wild?
To be a little pedantic, that's not exactly what he meant. I only say this because his true vision is a lot more beautiful than that.
He wants to reduce the barrier to entry for tech and empower anyone with the drive to build not be limited by their resources. This is particularly why he focuses on Android smartphones because they're the most popular in the developing world. Also since smartphones are full fledged computers with touchscreens as their primary input method it's the perfect tool for this.
Furthermore, his baseline for this is any such device should have the tools necessary to build a working version of Linux from start to finish on itself. Which is why he's built toy box; it should, by the end of it, have all the tools necessary to building a working build of Linux with a single binary.
This sounds really cool, however, reading the status page ( http://landley.net/toybox/status.html#done )is near impossible. I have no clue what the difference between `#command#` or `@command@` is. Are they both usable? some are links to man pages, some are not, but are listed in the done section.
Deeply appreciate people rewriting and polishing up stuff lower down in the stack. Its work like that that makes sure the house of cards our digital infrastructure has become doesn't just collapse.
So I was reading the background on Toybox and it’s definitely…interesting? Seems like the author used to work on BusyBox, had a falling out, then in a fit of pique wrote a permissively licensed version?
IIRC busybox became part of some GPL enforcement lawsuit(s) because it was being packaged in a lot of embedded situations without the necessary source-publishing.
So the author split off to work on toybox instead, a new implementation under permissive licensing.
I guess it just goes to show you should pick licenses that actually reflect what you want to happen to your code.
Busybox was written by Bruce Perens. The goal was to fit a whole Linux system onto a floppy disk for rescue disks and installers. Busybox licensed under GPL was not an accident. The kernel was GPL of course, but the rest of the userland was either GNU or largely GNU-inspired. Bruce Perens was heavily involved in early Debian development and even led the project for a while. "Copyleft" is at the core of how Debian operates.
Busybox being GPL licensed was in no way an accident or frivolous decision. It is still licensed under GPLv2 to this day.
I don't know when Rob Landley became involved in Busybox, and I don't know what drama resulted in the reimplementation of Toybox but I do remember he started it with hope that it would eventually ship on Android smartphones. I guess it worked out okay for him, because now he gets paid by Google to work on Toybox.
> Busybox being GPL licensed was in no way an accident or frivolous decision. It is still licensed under GPLv2 to this day.
I realise that my comment is quite ambiguous now. The author I referred to was the author of toybox, Rob Landley, and he was the maintainer of busybox in the early 00s. It was him I meant should pick licenses carefully, but honestly reading more about the situation, my take was too simplistic.
And that's about the time Rob resigned and went off to do toybox on his own. Having read that I'm honestly much more sympathetic, it seems like it was a real mess.
I think I'm missing context on what you're referring to. Does AOSP include a lot of GPL'd software or something? Do they not comply with the GPL license? (are you talking about the linux kernel or something?)
Toybox combines many common Linux command line utilities together into a single BSD-licensed executable. It's simple, small, fast, and reasonably standards-compliant (POSIX-2008 and LSB 4.1).
busybox seq does not have -f unlike toybox seq
busybox sed has fewer features than toybox sed, e.g., -E
busybox mv does not have -v but toybox mv has it
toybox base64 has an -i option, busybox does not
toybox hexedit has some useful features not found in busybox hexedit
toybox nc has some useful features not found in busybox nc, e.g., -U and -f
Overall, busybox has more available utilities than toybox.