 Hello, world. Okay, so what is Toybox? Toybox is a fresh implementation of the Linux slash Android command line. It's BSD licensed. It draws from POSIX, the Linux standard base. It's good enough to build Linux from scratch. It needs to be able to replace Android's toolbox. It picks some stuff up from the Bashman page, and so on. That's not the interesting question. The interesting question is why is Toybox? The smartphone is replacing the PC. Mainframes were replaced by mini computers, which were replaced by micro computers, which are being replaced by smartphones. It's a standard disruptive technology cycle. The 8 to 16 bits to 32 bits to 64 bits things are sustaining technology changes within each cycle. But each time, the PC wasn't good enough that the mainframe and mini computer people initially paid all that much attention to it, and they did a standard upward retreat as described in the Innovators to Limit by Clayton Christensen. It becomes more general purpose as it matures. The PC started out booting into ROM basic. It didn't run native code. It didn't even have a real operating system. It grew out of ROM basic. The smartphone needs to grow out of Dalvik. Dalvik is this generation's ROM basic. Note that successful tablets are big phones, not small PCs. So attempting to move the previous generation's technology down into the new space, if you know anything about disruptive technologies, that tends not to work well. Last time around, the MicroVax was an example of mini computer makers who made a PC form factor mini computer that didn't help. In terms of ergonomics, the main objection to, you know, I can't use this, the keyboard's tiny and scrunchy, and I can't use it to replace a PC. It's got a USB hub on the end of it. Sorry, it's got a USB connection on the end of it. You plug it into a USB hub to charge it. Add a USB keyboard, a USB mouse, and a USB to HDMI converter, and you've got the hardware of a workstation. It's got a gigahertz processor, a gigabyte of RAM, and several gigs of storage in it already, and you can trivially add network mounts or USB drives or whatever else you want. Up here somewhere, I pre-opened several tabs that I would use and then lost track of which ones they were. Here we go. Oh, I have them in order the other way. This is an example of a USB display that's 1024x768 plugs in USB, vanilla kernel has support for it now. There will be better ones coming along. But that just gets you the hardware side. And yes, the hardware will improve. I'm sure that wireless charging is coming and the ability to associate with things via Bluetooth or something will happen eventually, so you don't have to actually plug it in, although that raises fun security issues. But right now you can do it through USB. But that doesn't give you the software side. The phone is not independent of the PC until it becomes self-hosting. The PC itself was initially cross-compiled, the software on it was cross-compiled from mini computers, and then it grew out of ROM basic to GW basic and QuickBasic and all those, and that gave us Turbo C and QuickC until the OS itself could be built on the device and it was self-hosting, and that's the point at which it no longer needed the mini computer. I note that this disruptive technology cycle that we've seen several times before, it's not that the old platform goes away, it's that it's not what you have in front of you. People initially used to go stand in line to submit their punch cards to the mainframe operators and wait around for their printout to come back, and when you could sign up for a time slot at the mini computer terminal down the hall, you didn't need to do that anymore. You submitted your jobs to the mainframe through the mini computer, then you didn't need the terminal down the hall when you had a machine on your desk, and now you don't need the machine on your desk when you have a machine in your pocket. But the software that Android needs to become self-hosting, by the way it's, I'm jumping ahead, the software it needs to become self-hosting is four things. It needs, the smallest self-hosting system is a kernel, a set of command line tools to run configure and install and make as a bunch of shell scripts it calls out to. It needs a C library and it needs a toolchain. These are the four things. If you saw the LLVM talk a couple of sessions ago, EGCS2 is LLVM. That's the new name of EGCS. That's probably the toolchain we're going to. For the C library there's a project called the Musil Lib C that's about to have its 1.0 release. It's a BSD license C library that already builds the Linux from scratch project. And for command line, I'm writing Toybox, which we'll get into. So these are not yet solved problems, but they are solvable problems. Why not just extend Android's toolbox and Android's Bionic C library? And the problem is there's nothing there. They're pretty much stubs. It's an intentionally locked down system because the smartphone is a billion unadministered fully powered Linux systems with broadband access. From a security standpoint, they wanted to reduce their attack surface down as small as possible and shoehorn everybody into a Java VM sandbox. Which is nice, but we have to outgrow that. And as we outgrow that there are going to be issues that I'll get to. The compiler is still a bit of a problem, but after seeing the LLVM talk from earlier and if you didn't see it, go watch the video, I think that's probably what's going to win for now. I'll just skip that bit. Do we really care if Android or iPhone wins? Imagine if Microsoft was competent. That pretty much answers that thing. Apple sues bloggers who leak details about their upcoming things. Steve Jobs' first act when he came back was to put power computing out of business. They had licensed clones and that stopped. Apple does not see Linux as an existential threat, but the Apple versus Franklin decision is what created proprietary software in the first place in 1983 by extending copyright to cover binaries, which were previously considered just a number. That's not copyrightable. That was open source because source could be copyrighted and binaries couldn't. The whole founding of the Free Software Foundation in 1983 was actually a conservative reactionary movement to changes in the industry. Yes, it was a good thing to oppose, but that doesn't necessarily make them a visionary. What's happening right now is that there's something in business called an S-curve where if you chart the market share of something, or the number of units, it looks like a big S. Even if you plot it on log paper, it looks like a gradual thing, and if you don't plot it on log paper, it just shoots up off the top of the thing. This is pretty much what happens when you get a period of exponential growth. Periods of exponential growth are always finite because you will run out of atoms in the planet. We will run out of people who could benefit from a smartphone who don't already have one in a finite number of doublings because there's only so many people on the planet. It does turn out that there are more pockets than desks though. We're definitely going to have more phones than PCs could potentially ever have grown to. When the S-curve flattens out again, this is standard business stuff, when the S-curve flattens out again, whichever platform has the largest market share at that point is probably going to continue to grow to become the de facto standard because there's a positive feedback loop to being the biggest one in any platform that has substantial network effects. The telephone is the standard example of network effects. One phone is useless, two phones can only call each other, but when you have three phones, each phone can call two other phones. Every phone you add to a connected network makes every other phone slightly more valuable. There is an exponential growth in value to the size of the network. It's not squared, it's slightly larger than one, but it's still really cool. This positive feedback creates de facto standards that are natural monopolies and you can be as sucky as Windows 3.1 and still be nailed to 90% market share just because everybody wants what everybody has. People write software for whatever has the most seats, people buy whatever has the most support. There are, you can argue that putting everything in the browser that Java's write one everywhere will save us. People have been trying to get away from that for a long time, but I'm not counting on that. So question, Android is not vanilla Linux and we've all been doing vanilla Linux. Do we want to oppose that or do we want to accept it? There are several reasons vanilla Linux didn't succeed on the phone and isn't going to. One of them is that it's probably too late for a new entrant because we do have established leaders with a significant lead and it's most likely to be a winner-take-all thing when the music stops. This is the third generation of Mac vs. PC. The first generation was the Apple II vs. the S100 CPM systems. Then we had Mac vs. PC, now we have iPhone vs. Android. We've had purists before who said that DOS isn't CPM 16 or Linux isn't a real Unix and that hasn't really been a winning argument. I mentioned that the MicroVac shows that disruption goes up market, not down. Unity and Windows 8 suck both at being desktops and at being phones and that's a real problem. OpenMoco was out, was our Windows CE. It was out before iPhone and Android and Linux in the phone didn't really take off there. There's a significant problem with pre-installs which is that you need channel partners and they're all basically claimed and getting your thing through a channel partner has some serious latency of multiple years. Steve Jobs was dealing with AT&T to do the iPhone back around 1995 and it's been a decade and almost two I think. Other thing, there's a major problem. The open source development model cannot do user interfaces. I actually have a longish write up about this part that I don't have time to go into. But essentially anytime shut up and show me the code is not the correct response to the problem at hand the open source development model melts down into one of three distinct failure modes. We either have endless discussion that never resolves. We have everybody goes off and implements their own idea and then we can't unify them after the fact either. Or, and this is my favorite one, delegating the problem to nobody where you separate the engine from the interface and concentrate on the engine and hope that some glorious day someone writes an interface that's nice or you make it so configurable that the fact that you still don't know everything it can do after a week of study and still has no sane defaults is now somehow your fault. Open source doing user interfaces is like Wikipedia trying to write a novel. It doesn't work that way. We have solved portions of Brooks law but too many cooks still make the soup taste bad. We've solved the nutrition aspect but the aesthetic thing, our model is built around defeating Brooks law with distributed disconnected development nodes that feed together and then have empirical tests where everyone can agree this is the best way to go. When you're dealing with aesthetic issues and there aren't empirical tests saying this is the one true superior approach out of all of these when it just matters that you pick something and be consistent and pull it off well. Chinese food isn't better than Mexican food but if you can't pick which one you're cooking the end result may not be fun. I could spend a lot of time on this but I don't have it. Let's just say that Linux on the desk, we've had the year of the Linux desktop 20 times now and the fact that we still haven't broken one or 2% market share is a systemic problem. Android doesn't have that problem because Android does have one novelist dictating the plot. Android does have somebody in charge. We've had several projects that had somebody in charge in open source development. I remember Mozilla wasn't considered particularly useful. Galleon forked off of that. Mozilla rebased on it and went okay the committee is in charge of the decisions again. Firefox forked off of that and then Mozilla went okay, we like what you're doing but the committee is going to be in charge again and well committees produce beige. If you're lucky committees produce beige. If you're unlucky they produce the DMV. Okay so enough of that. So trying to replace Android with vanilla Linux given what we have now and given that precluding the iPhone from becoming the new de facto standard helps us avoid a world of lockdown hardware and software we probably want to get behind Android and push and do what we can to clean up later because Android is at least salvageable. Android is not open source development. It's regularly updated abandonware but we can fork at any time if we need to and we may be able to get stuff through Google's not invented here naval gazing if we shout loud enough maybe. Okay so Android is not copy left. Is this something we're going to oppose or something we're going to accept? Well there's a problem. The GPL was a category killer. It was synonymous with copy left the way GCC became the de facto standard compiler the way Exchange became the de facto standard spreadsheet and so on. There's no the GPL anymore. GPL v2 was a terminal node in a directed graph of license convertibility. You essentially all you had to know as an engineer is is this license GPL compatible or not? If it's not, ignore it. If it is, treat it as GPL. And we're good, we don't have to be a lawyer. Well there's no the GPL anymore. The Linux kernel and SAMBA can't share code even though they implement two ends of the same protocol. QEMU is stuck between wanting to suck in code from the Linux kernel to implement its virtual devices. It wants to suck in driver code and it wants to suck in platform definition code from binutils and GCC to implement its virtual processors and it can't take code from both. There's no universal receiver license anymore. People say well just do GPL v2 or later. Then you can't take code from either one. That's not an improvement. So what a lot of people have done is they have jumped in the absence of a universal receiver they've jumped to the other end universal donor. That's BSD or similar licensing staying as close to public domain as you can. There are a lot of people who are actually going the most common license on GitHub is not specifying any license at all because they're taking the Napster approach and going copyrights to dumb to live. It's like the patent law. The only thing you can do is civil disobedience and hope it goes away. I'm not convinced that's a good idea. I mean there's other people who are saying that maybe this will be a replacement for GPL 3. Additional fragmentation that's going to help. So you have a bunch of incompatible terminal nodes. What's essentially happening is copy left is dying. And androids no GPL in user space that's not necessarily their original reason for doing it but at the same time attempting to to solve the problem of copy left now being badly fragmented into incompatible camps. I don't think we can. I think going with okay we need a BSD licensed user space is pretty much our option given the tight time deadline of we really want to steer this transition we want to capture this transition so we don't get locked out of future generations. So in the absence of universal receiver people are going with universal donor. Okay so why not extend Toolbox and Bionics instead of replace it. I mentioned that a little bit. The security issue I talked about as as the phone outgrows Dalvik the way the PC outgrew ROM basic and runs native code that it can build itself that opens the can of worms of security issues now that we have broadband internet access. The solution that looks like the best thing is Linux containers because that's a generic solution to making the system nest attempting to break up root into a bunch of capability bits while it's nice a bunch of people have pointed out that about half those capability bits are equivalent to having root because from there you can crack root as it is now. It's kind of like saying we had one fireplace that we were paying very close attention to make sure that it didn't burn the place down but we decided that was bad so we gave everybody their own handheld canned heat thing so everybody has a little fire and that makes everything much more fire proof now. I'm not convinced about that. My problem with SE Linux is that you don't get watertight by plugging the holes in a colander. I don't like the direction of the approach. It increases the complexity of the system and we're talking unadministered systems so if you need 20,000 SE Linux rules in a stock Red Hat Enterprise install or whatever the number is these days are you sure you've guessed everything and are you sure that this won't be your own security system performing a denial of service attack on new software that you attempt to install that you do want to work? These are unadministered systems making them more complicated. I'm not convinced is the best approach but this is an area that the problem with Linux containers is that I can't really do an analysis of is this sufficient or is this not because it's not done yet. It's still cooking. Linux container shows an awful lot of promise and it's something that the kernel guys are pushing really hard and it's something that Android can get by re-syncing with upstream. The thing about the Android kernel is it's the vanilla kernel plus stuff. They didn't remove anything they just added stuff. So if vanilla solves some of these problems Android has a history of taking that if they didn't already implement their own solution that they feel like doing. But anyway, this is why in the one-pointer release of Toybox I'm not really paying attention to SE Linux. I am paying attention to containers. If it turns out necessary to add SE Linux I can be talked into it but that's a huge amount of work that I'm hoping to be able to avoid and I'll get into the reasons why in a bit. As I said, that one's a judgment call. So, what we need out of all that earlier here's the problem set we're trying to solve. Musil is being developed by a guy named Rich Felker. He's Dalius on FreeNode. He's doing a very good job at making a very competent C library that should be able to replace Bionic. The LLVM guys are going full bore at making a GCC replacement that could actually be pre-installed. The problem with GPL licensed software, GPLv2 or GPLv3 is you'll never get pre-installed through the vendors unless they violate the Android policy of no GPL in user space which most of them don't want to do. So, if you get BSD licensed ones it can actually be a vendor specific install on top of the base Android thing or it has the potential of being integrated into base Android either by come up with something like Cyanogen Mod that is a rebuild with extra work, a layer on top of the Android open source project and the Android open source project is a Google internal consumer of the Android development whose job is to export it. And if vendors like Samsung or something wanted to rebase on essentially something like the Alan Cox kernel instead of the Linus kernel if they wanted to rebase on Cyanogen Mod instead of the raw Google thing I don't know, that's a whole political layer that can be dealt with later, how you get these things upstream but I do know what the constraints are that will prevent it from being upstream. So we need a BSD licensed command line implementation that has to be simple, readable, security audible and minimize the attack surface but provide more than Android toolbox does now by a couple orders of magnitude, well, order and a half. The simpler and more readable it is the easier it is to security audit and if you have a billion Android devices out there worms and viruses going through them if people start doing online banking through this thing you don't want anybody installing key loggers and packets and stuff like that it is an enormous issue and the way to deal with security is make it so everybody can understand exactly what the code is doing at first glance. Spot single point of truth means you only need to change it once a thing about code reuse it's good if it accomplishes single point of truth and making code simple and readable and not redundant and things like that it's bad if it makes you pull in code you don't need a lot of people go code reuse is good therefore I'm going to reuse code I never had a first use for so they suck in 12 different dependent libraries that it's like okay I'm only using 3k of this library and it's 70k library so there's a lot of code I'm pulling in that needs to be installed on the system that could potentially be called but I'm not actually using it minimizing your build dependencies minimizing your environmental dependencies is actually a good thing and these are lessons from raw busybox I maintained the busybox project for a couple of years I put out the 101 through 122 releases you probably already knew that so I'll get into when I get back to the toy box specific parts I'll talk about why I started toy box but a lot of this I learned on busybox busybox already does some of it but it's got the wrong license and it's lost a lot of the simplicity okay another thing ifdef considered harmful the linux kernel guys already know this there's a famous paper called ifdef considered harmful busybox is full of ifdefs now you don't want your code to be full of ifdefs because it makes it really hard to audit see what it's doing we need good support for linux containers although this is mostly transparent from within so it's possible that if we don't have time the upstream LXC project if they get that working on android the correct response may be just okay use that and then run toy box in the containers it doesn't have to be integrated it should be a drop in replacement for android toolbox just on general principles it should be sufficient for self hosting a development environment remember a significant part of the point of the exercise is so that the smart phone can be independent of the PC so that it can replace the PC so that we can actually use smart phones as workstations if it can't rebuild the OS that's on the phone itself your development environment is not real it should be standards compliant it should have no external dependencies I mentioned not even endcurses and zlib to avoid the code reuse that isn't actually reuse because there's no re there's just use it should probably be a multi-call binary that can be statically linked and dropped on a system in part this basically just allows you to add it more easily to a system that doesn't have it it's generally a nice thing to have you can multi-call binary versus non-multi-call binary is just a packaging step you can change that later I note that I did try making some of these commands shell script snippets that gets into a little detail we're not going and it should be portable between Linux and Linux by which I mean Android Linux versus vanilla Linux versus different distros if there's ever a 4.0 release it should still build cleanly I'm not particularly worried about portability to all the strange unixes that the GNU tools have this huge configure step for where they're probing for the existence of the same header three times because is the header does the header exist is the header usable and then the third one just says probing for the header in a way that what are the first two doing the huge configure steps of the wide variety of environments that this builds in well you want to depend on your build environment being compliant with POSIX 2008 and if it isn't fix your build environment you want to your tool chain to be C99 if it isn't fix your tool chain we do want to try building with GCC and LLVM and PCC and stuff if possible but special casing a bunch of different platforms rather than relying on standards is not necessarily a good way to go okay so now we've gotten through the first main part of the why we get back to what is toy box what is the one quarter of this problem that I have bitten off and determined to solve for myself you know someone else is taking the C library someone else is taking the tool chain and the actually Tim Bird the founder of self has an android upstreaming project where he's attempting to bring the android kernel and the vanilla linux kernel closer together both by adding stuff to the android kernel that it doesn't do but most vanilla systems do and the android user space and pushing patches upstream into vanilla that have been languishing in android for a long time other people are doing that part I'm doing toy box so toy box started in 2006 when I left busybox I decided that I could do a better job than busybox by starting over I had other reasons for leaving busybox Bruce Perens but the reason I started toy box is I believe that I could do a cleaner simpler version than what busybox had become busybox had explored its problem space experimentally and by the time the project was 10 years old busybox had a pretty good idea of what it should do and a lot of scar tissue left over from finding its way so a lot of what I did on busybox was actually clean up work and there was still so much more clean up work to do and as a large user base was pulling it in many different directions it was developing scar tissue faster than I could clean it up from conflicting users Alan Cox said that a maintainer's job is to say no I like to use the analogy of I submit my short stories to a magazine and the editor picks a small subset of them and mostly bounces them back with a letter saying you know I'm rejecting this but if you make these changes I'll look at it again and a personalized rejection letter is a good thing open source development works that way a lot a maintainer has to do an awful lot of saying no to clearly define what is part of this project and what isn't and how do I want the design to look and how do I want the implementation to look and it's really hard and your users are always pushing in different directions than you necessarily want to go it's hard I mothballed the original toy box project starting around 2008 it tailed off for a long time because I proved that I could do a better job than busybox but busybox was there it had a 10 year head start it was good enough it had years of my own work in it it had essentially a dozen full time developers a very large established user base you couldn't displace it by being incrementally better and I really didn't want to sabotage my handpicked successor who's a great guy with pretty reasonable technical judgment he just doesn't keep the code as clean as I like but pretty much I had many other things to do with my time and the toy box worked tailed off and I actually tried to push a significant amount of it upstream into busybox busybox is using the toybox patch command for example the changes to busybox so that all the definition of one command was in one C file and you could just drop one C file into the busybox source code and the build would automatically pick it up and offer you the menu config option and it would generate the help text for you from that thing and you know the command would show up in the multiplex just from one file completely separate that was toybox stuff that I explained to Dennis Flesenko himself in 2010 we finally got to get together and go okay here's what I was going for and he added it to a busybox in a way that I consider less clean than toybox but a lot of the infrastructure went upstream toybox was relaunched in November 2010 when Tim Bird looking you know okay we need to extend vanilla kernel to better support android we need to extend the android user space to better be a you know linux system came to me talking about his proposed bento box project which was going to extend android's toolbox to be to do a lot of what busybox did and I pointed out to him that I spent years working on toybox I have a significant head start here and I've done the research for everything else I need to do I just haven't implemented it yet I've done the copyrights to all this code I only had like five other contributors so I could contact four of them I couldn't contact the fifth so I had to remove his code which I feel bad about but I could triage it I could relicense it to something compatible with the android user space licensing guidelines and I could take it from there and the reason I got involved in busybox development in the first place was due to a project that's currently called aboriginal linux aboriginal from the beginning where basically I was creating the smallest self-hosting development environment I built linux from scratch and then I went well can I replace all these GNU tools with busybox and uclibc and stuff the answer at the time was no so I fixed it and I spent years fixing it and I can do it again a lot of those commands I wrote all of the code of with no external contribution and others you know I wrote the busybox mount implementation it wasn't all my code but I know exactly what's involved when I get the time to do that one and he was actually thinking maybe I can rustle up some corporate interests in helping out here and some of the FSF guys who were totally unwilling to accept that gplv3's main effect was to undermine gplv2 freaked because one of the things I had done as busybox maintainer was to start a round of license enforcement lawsuits because Eric Anderson the previous maintainer had left me the hall of shame which was a list of these people are shipping busybox and never gave a source code and it was years old and he was trying to publicly shame them which yeah that'll work really well with the for profit corporation and I went okay I can't maintain the hall of shame so I asked Pamela Jones of groc law can I get some legal representation pro bono and she pointed me at this new thing the software freedom law center where ebb and moglin the co-author of the original gplv2 had started distancing himself from the FSF he used to run the FSF legal arm he now spun it off into an independent entity and I went okay fine contact these people and see if you can take source out of them and over the next year we got source releases from a dozen or more different companies and not one line of code went into busybox as a result of this because the code that they had was useless I mean okay yeah they took a random SVN snapshot ported some more stuff back from a future SVN thing commented out a bunch of line we were using subversion at the time for source control we got out a bunch of stuff hardwired in some constants because they didn't know how to use the config system and made some comments that made no sense none of it we wanted in our tree we just wanted to see what they'd done so I actually since then posted some mails to the list that went into the busybox web page about okay the policy of busybox with regard to the gpl we're not going to sue you like the FSF sued the MEPIS distribution considering with Debian and not mirroring the Debian source tar bowls that they hadn't modified the FSF actually took legal action against MEPIS for not mirroring unchanged code and I went okay we're not going to do that all we want to know is what are you shipping what did you do with it if it's vanilla unmodified just tell us and we're fine Bradley has since removed that from the busybox fact his only actual patches to the get repository that it's in were clarifications that took out the safe harbor provisions I'd added because well they got lots of money every time they sued one of these guys so no code but a self financing legal machine that continues to sue people to this day as far as I know and wouldn't stop when I asked because there were other people with copyrights who signed on yeah part of what I was doing with toy box was undermining the ongoing busybox lawsuits that I had started and couldn't stop and that freaked out a lot of the FSF guys and that basically scared away open corporate contributions you know I get contributions on the mailing list from individual Japanese developers who may work at companies in their day job and I'm not asking so but yeah I can't you know like do this is my day job or anything it's all hobby programming but I still want to change the world so that gets us through what is toy box why is toy box now we're going to get into the meat of what does toy box actually implement what is the task of coming up with a command line that actually you know meets this need of making Android self hosting it needs to support POSIX 2008 but not all of POSIX 2008 POSIX 2008 has a lot of obsolete crap in it it still it still specifies the SCCS control system which predates CVS and makes it look good it still specifies it still has a dozen batch processing commands like Qdell and stuff so I triaged POSIX 2008 and there is a road map is one of these tabs I have open well so there's a road map that explains goals and use cases of POSIX 2008 the Linux standard base the standard isn't scare quotes for a reason what it takes to be good at development environment what's actually in android toolbox and then various other packages that do similar things like Caleb see stand alone shell S base S6 red hats old Nash project which apparently died in 2008 having looked at it they had good reason to kill it and Beastie box which was some BSD guys vented some busy box envy for a while into Github in 2008 and then stopped and haven't touched it since but all of these have a selection of commands that they thought were important to include so I triaged all of these and put together a status page of okay POSIX commands LSV commands things that are needed by development environment that aboriginal Linux needed to rebuild itself under itself and build Linux from scratch under the result commands that are in Android commands Caleb see sash S base Beastie box things that were requested by you know various people emailed me and said I would like to use this but I really need blah and the crossed out ones are the ones that already implemented so there's you know all commands I break it up into the things that are still to do and the things that are done you know so these are implemented so let's go back to here so on the web page you can actually get a lot of the stuff that I'm going over now so POSIX is a very good standard it's failure mode is a mission or having things in it that should have been deprecated it hangs on to stuff for a while once it's standardized and it doesn't mention the existence of mount or init so if you have a system with nothing but POSIX in it it will boot LSB 4.1 the Linux standard base supplements it to give you a system that will mostly actually boot although it still doesn't specify a init but it is a deeply crappy standard half of it is deprecating is reversing deprecations in POSIX things that POSIX did manage to get rid of after hanging on to them for too long LSB puts back the Linux standard base documents what's there without a whole lot of judgment about what should be there it has pointy hair disease in certain cases but it's still a good source of information if you're implementing amount command you might as well make it conform to LSB 4.1's command line things Android Toolbox lives in the Android Core Git repository so breaking it out of Android you know Android has a fairly significant not invented here syndrome and this is one of their sort of background jewels so the easy thing to do is just put toy box first in the path and leave toolbox there for now I triaged it I mentioned making sure we have good container support for security what's involved in a development environment I gave a talk here in 2010 that's still online and the slides are the slides are online as well all 260 of them basically I have a new wrapper that appends the command line it's called with to a log file and then calls the next thing in the path with the same name it was called under so you make a directory with this wrapper in it sim link every binary name in the path to this wrapper and stick it at the start of your path and it logs everything that's called out of the path after that and then I have some scripts that will walk against this to give you a list of these are all the commands that were actually called and what stage called them so I've been looking for years at what's involved in a minimal self hosting environment I got that one down and I also have enough for it to build Linux from scratch natively on target I don't separately have to look at busybox because the reason that I became busybox maintainer was so that Aboriginal Linux could rebuild itself under itself and build the whole of Linux from scratch with busybox providing all of its command line utilities that weren't actually the compiler or the linker and I did that and busybox def config has about twice as much stuff as I actually need and I've already triaged that down I looked at the other packages klibc and so on and if you go to the roadmap there's actually specific triaging of each of the packages if you're interested in this first list is everything that it provides the second list is what's still on the to do list that before I can say to the users of sash toybox does everything that sash did if you wanted to switch because as always when you attempt to replace things in a heavily fragmented environment there is the danger of just fragmenting it further if you can't convince anybody to move off of what they're already doing so things it should have it should have good container support and unfortunately I can't tell you today what good container support means because it's still moving target it should have network administration stuff because you need that that's not in POSIX and that's not really an LSB it should have file system support because android tool box has make fat FS and I already did make swap and once that can of worms is opened maybe it should have some of the others I could be talked out of including it but they're actually not very hard because they're essentially just more archavers and I want to implement them as archavers so that you can do a makey 2 FS on a directory pipe the output to GZIP and SSH it to another machine you can't do that with the Jenny 2 FS right now because it's a big M map that does random seeks M dev I designed it in the first place toy box should have it but it should be based on dev temp FS because some of that stuff went upstream and it is one big unsolved problem there's sys 5 in it there's androids in it there's upstart system D needs to die I'm not opening that can of worms because again I couldn't tell you what the edges of it are the catamari de macy theme plays in my head whenever I read about it toy box has something called want it there's also run it in busy box I have to do more study here to figure out how I want to handle in it I'm probably going to lean towards whatever androids whatever androids doing I need to implement that because the main use case is replacing that it needs a shell that's a reasonable bash replacement I could go into why ubuntu replacing bash with dash was the worst technical decision they have ever made and I can back that up but we don't have time some things are more complicated than they seem and should not be in toy box a lot of maintaining a project well is say is what can I say no to what what are the edges of my project if I can't say what shouldn't be involved I don't know where the edges of my project are and it's going to turn into a giant unmaintainable mess various blue sky would be nice things like a hex editor a nine piece file system server io top linus's copy of micro emacs if I can clone that maybe I can get him to start using it that would be nice I doubt it but you know I don't know netcats UDP mode microterm rsync who is kex screen ntp slash rd8 htpd or dnsd maybe memory technology device stuff this is all maybe after 1.0 things or if I you know get bored and then there's a bunch of things that are in like posix for example make is in posix lex is in posix posix specifies a c99 command that belongs in the toolchain that does not belong in toybox if I was going to add strace I'd add it to a toolchain package if I was going to re-implement expect which is a nice thing because killing off tickle would be nice but that doesn't belong here the record commands raptor so that's basically my indexy thing and I probably don't have any time left but at this point questions yes yes in fact I have I've been tracking that and keeping the size down busybox does some tricks to keep its size down that are like weird linker flags to remove elf sections and stuff and I'm focusing on simple first and speed second and size and all that I actually have if you go to landly.net slash toybox there's a what is toybox thing that includes a bunch of goals and things and the standards and stuff and the design docs actually explain that it needs to be fast it needs to be simple it needs to be small and stuff like that but simple is the simplest implementation that provides the necessary feature set and then a little bit of extra complexity to reduce size or increase speed but complexity is a cost and we want to spend as little of it as possible because complexity essentially reduces auditability and we really need security okay we need this code to be as transparent as possible so that lurking bugs that you know cause the smartphone equivalent of the Morris worm aren't aren't our fault did that answer your question okay other questions none? okay well thanks for listening