In association with heise online

ToyBox future

The H: So far, you've got 47 commands up and running. What's on the agenda for implementation next?

RL: I have a roadmap, although like everything else it needs work... I want to do all the non-crazy susv4 commands, plus the commands needed to make Aboriginal Linux able to rebuild itself from source code in a chroot, run its own boot scripts, and build Linux From Scratch under itself. Plus some obvious stuff like dmesg and less that you need to seriously use a Linux system.

I also need to make ToyBox work built against bionic (which may involve adding a lot of supposedly standard libc functionality to ToyBox's lib directory), and add in all the toolbox commands in Ice Cream Sandwich so you have the option to actually replace toolbox instead of just supplementing it. (Although some of that's crazy too: I have no idea why the Android developers felt porting the Windows registry to Linux was a good idea. Oh well.)

The H: What's the difference for a developer between say implementing a command on ToyBox compared to BusyBox?

RL: I wrote a new command walkthrough for ToyBox. I'm not entirely sure how BusyBox does it these days. It used to be that in ToyBox you'd add a single file to the "toys" directory and the build would handle everything else from there, where BusyBox had to touch five different files to add a new command. Then I met Denys Vlasenko in person at CELF in 2010 and explained the advantages of this to him, and he implemented something like that for BusyBox (in a less aesthetically pleasant way, in my opinion, but more or less functionally equivalent).

There are still some conveniences unique to ToyBox, such as my option parsing infrastructure which can automatically digest the command line arguments into a set of global variables before the command's main() function even runs. I dunno, I like ToyBox, but then I would. It may not always succeed in being simple, but it tries.

The H: The licence change on ToyBox did generate a lot of discussion. Do you think any of it shed any light on the issues around licensing, the commons and the way manufacturers work with free software and open source?

RL: Nope, which is sad. I wrote up some of my thoughts on this in a recent blog entry.

The H: ToyBox is a very gently matured project, when do you think you'd be putting a 1.0 badge on it?

RL: That's in the roadmap. My goals are:

  1. Supports all the SUSv4 commands that aren't crazy obsolete stuff like sccs.
  2. Supports a self-hosting system capable of rebuilding itself under itself, and building Linux From Scratch under that.

The H: How much time do you put in on ToyBox and is there a development community growing around it putting in anything like similar hours?

RL: I'd say I'm putting about 10 hours a week into it. Mornings, evenings, weekends. The development community grew significantly thanks to the Streisand Effect. My development time the past couple weeks has been devoted entirely to reviewing, merging, and cleaning up new code from contributors. It's great.

The H: Is there anything you would have done differently with ToyBox?

RL: I should have started focusing on Android sooner. Back in 2002 I wrote an article for a now-defunct web site called Linux and Main about how smartphones would displace the PC. Last year I wrote an extensive blog entry on the topic. But it never occurred to me to relicense ToyBox until Tim Bird asked me about extending toolbox and I went "Oh I can do that, I've got this thing, years of work in it already, going totally unused..."

The original trigger for a clean restart with scrupulously tracked code origin was because I was mad at some troll for stealing credit for my work, but coincidentally it put me in a position to have a year or so headstart on doing something useful. Go figure.

And I get to have fun working on it again. That's a big plus.

Print Version | Permalink: http://h-online.com/-1447494
  • Twitter
  • Facebook
  • submit to slashdot
  • StumbleUpon
  • submit to reddit
 


  • July's Community Calendar





The H Open

The H Security

The H Developer

The H Internet Toolkit