 Hello, we're old. So my name is Rob Landley. I used to be the busybox maintainer, and then I created Toybox. I know rather a lot about both of them. I'm here to compare and contrast them and tell you why I'm doing Toybox now instead of Busybox. Description, I gave the program committee. So why would you use Toybox instead of Busybox, the new tools, or something else? When you build an embedded system, what are your options and what do they mean? Let's talk in time to survey, compare and contrast, and they gave me 35 minutes. So let me set the timer. Timer, timer, timer, okay. I'm going to run out of time. So brief outline of what I'm gonna try to cover. My motivation and goals, why am I doing this? What am I trying to accomplish? What did I do? My timeline to work with Busybox, the licensing issues that made me Gearshift, and timeline to work with Toybox. The technology, a quick look at the code of both projects and a quick look at using each project, and then some talk about build systems I built around them. So I was a maintainer of Busybox, and let's create Toybox. I've experienced with both. So obviously I would say to use Toybox, because that's what I'm working on now, but let me explain why. The reason I got into Busybox development in the first place, and there's a longer version of this online, is that I was using Nopix as my distro, circa 2001 or so. The dot-com crash took out a lot of Linux distros. Red Hat fled screaming from the retail market and went off into the enterprise space. Susie went bankrupt. The guy who did Slackware was sidelined for a couple of years with a health issue that turned out to be related to his toothbrush. There were Linux on the desktop crashed and burned, and the only thing that was really getting Linux in the hands of new users was the first boot from CD distro, Nopix. It had a hard limit of 700 megs of space on the CD, and 110 megs of that was basically the same packages in the Linux from Scratch project. Linux from Scratch, so Nopix, yay, there's a Wikipedia page on it. Linux from Scratch, which there's also a web page on, is basically a how-to online book saying if you're going to build a Linux system entirely from scratch, build these packages in this order, do these steps, and you come up with a conventional system based on the tools everybody was using at the time. The problem is the resulting system was over 100 megabytes, Nopix had 700 megabytes total, and there was another system that I bumped into called Tom's Root Boot. Tom's Root Boot was a specially formatted three and a half inch floppy disk, if you remember those, that had it booted to a Linux command line with everything. People would boot these and use them as system recovery and stuff, and it was amazingly powerful for the tiny amount of space it had. And the secret is it was built on Busybox and UCLibc. So I started looking into Busybox, and I was going, if I can replace the 100 megs of Linux from scratch packages, the GNU packages with Busybox and UCLibc, if I free up 100 megs of space for Nopix, what wonders can they work with that space? So I set about trying to do it and it didn't work. It spectacularly didn't work. Even the commands that were available in Busybox tended to have missing options when I attempted to run the autoconf of binutils, which was the first package you built at the time under Linux from scratch. It segfaulted, and then when I fixed that, it hung. It's like, great. So I spent a lot of time, I have a timeline I'll just skip ahead to. So my Busybox timeline, my first Busybox bug report was March, 2001. My first patch to the list was September, 2003. The first patch actually committed by me where they basically went, you gotta learn to use the source control system, use the source control system, 2004. Busybox's 1.0 release was October, 2004, at which point the maintainer, Eric Anderson, said, Busybox is done, I'm gonna go do other stuff. And he went off and spent time on Buildroot. I put together a 1.01 accumulated bug fixes release and sent him the tar ball and he blessed it and uploaded it. And if you cut the releases, you kinda are the maintainer. And well, for the next development release, I became Busybox maintainer. Eric basically went, you're doing all this work on this, I'm not doing it anymore, here's the keys to the server. In one of the things I inherited was the Hall of Shame, which was, I could pull it up out of archive.org. It was a page of reports that Busybox binaries have shown up in these various projects with no corresponding source code. And that's a violation of the GPL. And Eric Anderson's father was a lawyer and he could basically send out cease and desist letters for free, but if the company didn't respond to the cease and desist letter, Eric didn't have any follow up. So they just accumulated and there were dozens of them on this page and when I inherited it, I went, what am I gonna do with this? And I had worked a couple of years earlier helping defend IBM from SCO. And so I knew Pamela Jones of Grocklau. I hadn't met her in person, she's very shy, but I'd spoken to her on the phone. And so I poked her and I went, do you know of any pro bono legal representation that I can give a pile of license violation reports to that might do something useful with it? And she went, yes, the co-founder, the co-creator of the GPL, Eben Moglin, has distanced himself from the FSF recently and created this thing called the Software Freedom Law Center where he's got some grant money, opened some offices and is trying to get his students at either New York University or the University of New York, I can remember. His legal grad students, some real world experience with open source licensing. So the two of us hooked up and I dragged Eric Anderson back in because he'd been the one who'd gotten all the actual reports and had the actual emails from people in his mailbox. And we gave it to those guys and they launched a bunch of lawsuits against companies and the end result was that not one line of code was added to the busybox repository. We kept getting, here's a tar ball of their source. Great, it's a random subversion snapshot between two different releases of ours where they backported a few things that we already have in the tree from later on, commented some stuff out because they didn't know how to use the configuration system and added some debug printfs that shipped. Bravo, we don't want it. But then I couldn't get them to stop. In 2008, I was working a contract at Cisco that had done Linksys and been legally brow beaten five years earlier. And as a result, they had ended all Linux development and outsourced the Linksys routers to Taiwan and they were just getting over that and they went, okay, how do we do it right this time? And the Free Software Foundation got in touch with the SFLC or it might have been the Software Freedom Conservancy. They were forking at the time. There was politics I wasn't really involved in. And basically went, we want to do one of these suits. We want to sue Cisco over this exact same tool chain from five years ago because they never got the source from Broadcom which was their vendor. The vendor never gave the source to Cisco. So we're not gonna sue Cisco, sorry, we're not gonna sue Broadcom. We're gonna sue Cisco. And the Cisco executives went seriously and ended Linux development again for another five years and outsourced it back to Taiwan. And I went, you just screwed up. I was teaching them how to do it right and now it's being counterproductive. So I couldn't stop these lawsuits. Once I'd started the ball rolling, there's a whole bunch of other people who have copyrights on, who have contributions to the code and they wanted to use Busybox as a club to beat hardware specs out of vendors. They don't actually want their kernel source, they want hardware specs because obviously the forced ETH driver could not have been created by reverse engineering. Obviously we don't have, you know, Nvidia drivers created by reverse engineering. I mean, clearly we have to do this through the courts and that has no downsides of making Busybox seem kind of toxic to a lot of companies. The other thing that happened is that GPLv3 shipped and as part of this legal stuff, I had been going, okay, I need to clean up our licensing so that we can have the SFLC run the experiment to see if there's any actual code that comes out of this and we have incorporated GPLv2 only code. Our licenses GPLv2 are later, that's essentially a dual license, GPLv2 and GPLv3, but we have GPLv2 only code that came from kernel developers that's been incorporated into our tree and we just got a large hot plug patch submitted with more GPLv2 only code and it's like okay, do we go back and audit all the existing code or do we admit that our license is GPLv2 only and just change it to say that? And Bruce Perens, the guy who had named Busybox and abandoned it in 1998, he declared his version complete most of a decade before Eric Anderson declared his version complete, piped up on the list first time he'd ever posted to the list in the history of the list. His webpage still said that Busybox was at lanaro.org that had gone out of business three years earlier. He piped up and said, you will be going to GPLv3 because I say so. You know, I have moral authority over this thing. It turned into an argument that we had already been discussing on the mailing list for half a year. What should we do about this? We had come to a conclusion. He stepped up to override the conclusion that the current maintainer and the previous maintainer had come to and it turned into a big fight and I basically went, I'm the one actually doing this, it's GPLv2 only, I'm going on, I've locked it down and then it was no fun anymore because he was taking credit for everything I was doing even though I did some forensic analysis to prove that none of his code was still in the thing and he hadn't touched it in 10 years and when I started working on it I hadn't even been aware that he'd ever been involved but he had invoked this authority and it's like, I just don't want to do this anymore. I'm not being paid for this, it's stopped being fun. So I wandered away from the project and the most recent commit I did to the busybox repository was in 2011, I still sent them stuff but I was no longer remotely a full-time developer but I still had all this work that I was doing and the motivation of freeing up space for nopics had turned into I want to create the simplest Linux system capable of rebuilding itself under itself from source code. I want something simple, I want something small, I want something auditable. When I was maintaining busybox I got an email from one of the people who worked at Cheyenne Mountain before they closed that where NORAD was, the big war games display, was running busybox and I went, I'm not actually comfortable with my code helping defend the country from nuclear attack, why? And they went, these are highly secure systems. Every line of code they run has to be audited and we would much rather audit half a million lines of busybox than tens of millions of lines corresponding GNU code that do the same thing and I went, oh, you have a point. And that's when I started to realize that security and reproducibility and these kind of things are good in and of themselves. One of the things that first got me looking at busybox in the first place was I made the mistake of looking at the GNU cat source code, all 833 lines of it. How do you spend 833 lines of C implementing cat? Busybox's cat was 65 lines and half of that was the license boiler plate at the top. It's like, okay, it's cat, it's a for loop. So I had a project that was replaced by a couple of projects and that history page goes into detail, but it was eventually called Firmware Linux where I was replacing 20 something packages and I have a tab up with the old page for when the project was called that. I replaced, come on, here we go. I replaced Bzip2 core utils, E2FS progs, file find utils, Gawk grep, Inet utils, less tar, util linux and vim with busybox. At this point, which was 2006 when this project ended and that webpage got snapshot. So I replaced about 20 packages with one package that was less than a megabyte. That was pretty cool. By the time Aboriginal Linux ended, I had the whole system down to seven packages. It could rebuild itself under itself from source code and I could build Linux from scratch under the result and I built about half of beyond Linux from scratch to prove I can bootstrap up to arbitrary complexity from this base. And what I was doing is I was cross-compiling these seven packages to create a minimal native development environment for all sorts of different targets that I could then boot under QEMU and natively compile whatever I wanted to inside the emulator so that all the cross-compiling was done. The motto of the project was we cross-compile so you don't have to. My goal was to make cross-compiling go away, basically as a concept. And in order to speed it up, QEMU didn't really do SMP well. It was all simulated. It was basically one thread on the host emulating multiple threads on the target. So what I did is I installed DCC in there and had it call out to the cross-compiler on the host to move the heavy lifting of compilation outside the emulated environment. But as far as the native compile was, as far as inside the emulator was concerned, it was 100% native and autoconf could run all the binaries it was building. There was only one set of headers to include only one set of libraries. There weren't multiple build contexts to keep straight and get confused with each other. It was very simple, very straightforward, and it worked. Modulo, I refused to upgrade after the, you know, you will do GPLv3 with busybox thing. My response to GPLv3 basically became death first and I refused to upgrade off of the last GPLv2 releases of things like GCC and binutils, which meant the things became increasingly stale and that's why the project eventually rolled to a stop and I stopped doing it. So when I left busybox, I started work on toybox because I had a lot of leftover ideas that I still enjoyed poking at this for fun. I didn't really expect anybody else to use toybox because busybox had a 10-year headstart, three years of which was my own work. I had handed it off to the best maintainer and I could find just because I can't motivate myself to work on it anymore, didn't mean I wanted to be a bottleneck and I was just doing toybox purely for fun. And then, I'm skipping around a bit, my prepared thing, and then Tim Bird, who founded this convention, poked me and basically reminded me that Android's command line was crap. It had a thing called Toolbox and a library called Bionic, which back in 2011 were basically a folded over piece of tinfoil stuck in the slot to complete the circuit to just enough where we can boot into the Java VM and everything else runs in Java. And their user space wasn't really there at the time. It had had no effort whatsoever. And I had written a paper I had written in 2012 when I was helping IBM fight SCO, I had written an analysis of SCO's second amended complaint called, which this is back before Eric Raymond went crazy. I was working with him. We, it was the Halloween nine document, which was line by line, their complaint and here's the reality, here's where they were wrong. And one of the appendices had a table of explaining why hardware changes were made and why things were going to 64 bit because they were fighting over UNIX's move to 64 bit was because Moore's law kept doubling the amount of memory in machines along a fixed schedule where the manufacturer were colluding, but if it's exponential growth, nobody really cares. So that you knew exactly when we have just exhausted the eight bit machines address space. So we have to go to 16 bit machines. We have now exhausted the 16 bit machines address space. We've now exhausted the 32 bit machines address space and so on. So I was studying transitions where we have to obsolete the previous thing and do the new thing. And I realized later on, these three things are basically, you know, my stuff on it. The third one there, which I haven't gotten the network association thing here right and there's no cell phone in here so I can't actually pull up more pages. Let me see if I actually pulled up that page. No, I did not. The third one there was basically going the transition from 32 bits to 64 bits is dwarfed by the transition from PCs to smartphones because main frames were replaced by mini computers which were replaced by micro computers which are in the process of being replaced by smartphones. And each time the previous generation of technology gets kicked up into the server space, this time getting kicked up into the server space is called the cloud. It has a marketing budget, great. But it's the exact same big iron space and each time the definition of big iron is it's the machine I'm not sitting in front of. I submit jobs through another machine if I ever talk to this machine. And, you know, people stop taking boxes of punched cards to the main frame priesthood to have them wave the knives over it and with the hoods and everything to give them their printouts back when they could get a time slot on a terminal for a mini computer so they could sit and actually interact with a keyboard. And then nobody needed a time slot at the machine down the hall when you had a machine on your desk. You would just submit jobs through the local area network to the big iron. You didn't care which of the two and so the two of them fought to the death and IBM cut off digital equipment corporations head and Queen played and there was lightning but the mini computer technology is what won because it's all time share, not batch job stuff. And now IBM and Amazon just fought to the death with Amazon EC2 and IBM's death looked like doing a reverse acquisition of Red Hat the same way AOL bought Time Warner. Yeah, it really went that way. Okay, so IBM is now, you know, Red Hat bought IBM but the money went the other way. So going through all that, it's like, okay, but there's a problem here though. The phone is, it's a giga, okay, we've got a gigahertz processor. My current phone has SNP gigahertz processor. It's got a gigabyte of memory and multiple gigs of storage space. The hardware is fine, but the software is all cross-compiled from PCs. And the PC itself didn't become independent until it stopped being cross-compiled from PDP 10s back in the day. When it got its own compiler and DOS development happened under DOS, that's when the PC really took off. And my goal now with Android is the mental model I have is if a 10-year-old girl in rural India inherits her mother's old phone and can fish a USB hub out of the trash with a USB keyboard, a USB mouse and an old HDTV with either a USB to HDTV adapter or Chromecast or something like that, you got a big display, you got a real keyboard, you got a real mouse, you can hook in USB drives and stuff. The hardware's not a problem, but the software has to be there so that you can natively compile Android under Android. Having an Android device should be able to make you a first-class Android developer. There shouldn't be a better environment that some people have a PC and some people only have an Android device and the people who have an Android device are second-class citizens in terms of being a developer. I need to fix that. So, I waved Toybox at the... Oh, right, no, no. So I waved Toybox at Google's Head of Open Source Development and went, are you interested? And he went, no, we already have Toolbox, we kind of don't care. But I kept working at it anyway and two years later, I gave a talk here in 2013, laying out, this is all the stuff I wanna do. And then two years later, Android did merge Toybox in 2015. And I'm gonna gloss over the rest of that, but that's kind of what I've been working towards. I was doing Aboriginal Linux, I now have a new one called Makeroot, which I just merged into Toybox that is a much smaller and simpler build. Here we go. Makeroot is 509 lines of bash script that builds a, it basically builds a Toybox root file system. And then the second half of it is a big if-else staircase of are we building for ARMv5L, are we building for PowerPC, are we building for all these various architectures, so I can put together a kernel config so I can build Linux that will then boot under QEMU to boot it to a shell prompt. And this is building on all that work I did for years for Aboriginal Linux that was driving the work I did for Busybox, where I was extending Busybox to try to get that seven packages down as small and simple as possible so that I could replace those 20 GNU packages. Well, what I'm doing with Toybox is I'm trying to do the same thing to Android only more so, because now I think I can get it down to four packages. Basically you need a Linux kernel, you need a C compiler, you need a C library, and you need a set of command line utilities. And I'm pretty well along the way. The thing I am working on now is I am making a bash replacement shell script. The Busybox ash is 14,000 lines of code and is not a full bash replacement. I think I can get one in about 3,000 to 3,500 lines of seed, but I'm still working on it. I've got about 1,300 lines written so far. I've finished syntax checking and am working on flow control. Anyway, so let me skip because I've only got, I have about 10 minutes left. So I did that, I did that, I did that, licensing. Basically I switched from Busybox to Toybox because of licensing. I try not to care about licensing anymore. I ran the experiment, copy left did not help add code to Busybox. We tried, we enforced it, and then when I had run the experiment and proven the negative, I couldn't get them to stop. I sort of yodeled and the avalanche happened and about three times in my career I have yodeled and set off an avalanche I could not then steer. That was one of those three times. So the thing about the GPL is there's no such thing as the GPL anymore. Linux and Samba can't share code. The kernel and Samba implement two ends of the same network protocol. They're both GPL, but one of them's GPL v2, only the other one's GPL v3 or later. Those are not compatible licenses. And a project like QEMU that wants to be GPL v2 or later can't accept code from either source if it is. That's fragmentation. And once you have copy left broken into warring camps, you tend to get GPL next, an Afro GPL, and you tend to get additional fragmentation. The other thing that happened is the response to GPL v3 on the part of every corporation everywhere was the same death first I had, but worse, they threw out the GPL v2 baby with the GPL v3 bathwater. When GCC went GPL v3, Apple froze on GCC 421 and Binutils 217, the last GPL v2 releases for five years in Xcode, while they sponsored the development of a replacement LLVM that they could move over to. And then Google went, oh, what a good idea. And Android is built exclusively with LLVM these days and they've actually removed GCC from the Android native development kit. It's not involved in Android builds at all anymore. Google's no GPL in user space policy is enforced through its trademark licensing guidelines where if a phone vendor adds GPL code, adds additional GPL code that's not in the stuff that was grandfathered in to the Android image, they can't call the result Android anymore. Apple wrote a Samba replacement because Samba went GPL v3, so they yanked it and it's not in macOS 10 anymore, Apple wrote its own. Google wrote its own Bluetooth daemon to replace the GPL Bluetooth daemon. I mean, they're continuing to do this because GPL v3 was so bad, it destroyed the idea of the GPL, not only for all these corporations, but who under the age of 25 still thinks copy left is a good idea. We are riding down the half-life of the installed base of not only copy left code, but copy left developers. And I had to go through the Kubler-Ross stages of grief to come to terms with this because I thought GPL v2 was really, really cool. So what, you know, the GPL was a terminal node in a directed graph of license convertibility. All us developers needed to know is, is it GPL compatible or not? If it is, we can use, treat it as GPL. If it's not, don't use it and we're done, we don't have to be a lawyer. It let us not care. The, you know, it was a universal receiver license. The other end of that is universal donor, which people have put on a GPL versus BSD axis for years, but it turns out that the universal donor is actually public domain. The problem is the Apple versus Franklin decision in 1983 extended copyright to cover binaries. That's what created modern proprietary software. It was a specific legal decision. Before that, a binary was legally just a number. You couldn't copyright it and afterwards it was. And what that meant is there was between 15 and 50 years of public domain software out there that was the main competitor of this gold rush of software, the shrinkwrap software, and they all did all the marketing they could to fud it. They basically went, the public domain is terrible. The same way bottled water vendors insist that tap water is somehow harmful for you in a way that does not show up on any scientific testing. It's the exact same, don't do that, do this. And the problem is the people who grew up there internalized it to the point where OSI's lawyer, Larry Rosen, wrote a hit piece in 2002 comparing releasing code into the public domain to abandoning trash by the side of the highway, literally. He basically said, public domain is littering. And it's like, no it isn't. But it's been thoroughly fudded. And there's also a generation of lawyers who don't really believe that the public domain is a thing. And if it was, it would be a bad thing because lawyers don't like anything that prevents lawyers from being paid in the future. And that's a bit of a problem. But, BSD is a good license because AT&T and BSDI sued each other over it for years and lawyers got paid a lot for a long time. That's a great license. Use that in future. So what I did is I created BSD zero, zero clause BSD. I took the open BSD suggested template license, removed the half sentence that said, copy this license text into all your derived works, which is the problem with public domain adjacent licenses like two clause BSD, three clause BSD, four clause BSD, MIT, ISC, EIEIO, all these Apache variants and stuff that are basically doing exactly the same thing, do whatever you want with this code but drag around this specific blob of text. Well, the problem with dragging around the specific blob of text is busybox's ping command. At the start of the command, it says, this is GPL. At the end of the command, it says, here's the BSD license. And it's like, wait, doesn't the GPL say no additional terms? And this says drag around the specific blob of text. Okay, so no copyright troll has actually sued anybody over this yet, so it's not actually a problem. There's nobody out there who's gonna try to make trouble with that. Great. Toolbox, the thing I was replacing in Android, had something like 33 concatenated copies of the same BSD license in a file one after the other. And I went, what are you smoking? And they went, the copyright dates changed and a strict reading of the license says, thank you. The Kindle Paperwhite had 325 pages of concatenated license text and it's about licensing pull down. It's like, this is crazy. If you ever actually do have to use this license in any kind of legal context, well, which one is it? What does apply to your code when you have this stuttering problem? And plus, the biggest problem is that all those people under the age of 25 who went, okay, copyrights, you know, copy left is a bad idea. It turns out copyright is a bad idea. They lumped software licenses in with software patents and they went, this is too dumb to live. We're just gonna opt out until the boomers die. And this is a problem, because in the meantime, we can't use this code. It's like, you know, what was that mail server, not QEMU, the one starting with Q? Q mail. The guy who did Q mail refused to say what the license terms were for many years. He was doing a similar opting out and it meant people couldn't use it. So there are public domain equivalent licenses. I'm out of sync with these things. I have a lot of notes on this. There's public domain equivalent licenses, the most prominent of which are, there's one called the unlicense, which is, it's a career limiting move of a name. I can't use that code, it's unlicensed. That's the problem we're fighting against. No. There's Creative Common Zero, which people who recognized, oh, this is a public domain license, you know, hit with FUD. And there is, there's WTFPL, which it's kind of hard to use the name because it's expanded in the license in a corporate context. They're a little unhappy about that. And there's just, the just plain drop bear is based on LibTom math and LibTom crypt, which are, they have a public domain statement. One sentence, this code is placed in the public domain where people are happy to use drop bear where someone took this code that says it's placed in the public domain and released it under an MIT license or whatever drop bear is under. Great, you can stamp another license on it and then the lawyers are happy, but using it straight is weird. Okay. So what I did is I took the OpenBSD suggested template license, removed the half sentence that said, copy this license text into all your derived works and just, you know, permission to use, blah, blah, blah, blah, is hereby granted, period. That's the only change I made. I got permission from Marshall McCusick, the BSD maintainer who took over from Bill Joy to call it a BSD license. Technically, OpenBSD was recommending an ISC license, but since OpenBSD suggested template license and Marshall McCusick said it's okay, I'm calling it a BSD license because all those lawyers who say public domain bad, BSD good. This is a BSD license. There's two clause BSD, three clause BSD, four clause BSD, now there's zero clause BSD. Right, rubber stamp. It's being shipped in Android. Muscle Lib C had some public domain files in it. The Chrome lawyers, the Chrome OS lawyers, different part of Google came to him and basically said, we can't use this public domain stuff. You have to track down the original things and get an actual license from them on these things. They gave him guff for public domain stuff. I have a public domain equivalent license that is fine. So basically I have made a corporate friendly public domain equivalent license where I can go to all the people who aren't licensing their code and go, how about this? Is this good or not? Is this an okay way of opting out that doesn't inconvenience the rest of us for the next 15 years? So that's the thing I'm doing. I am actually over my time and there's a whole section on actually comparing the code of Toybox and Busybox. Basically, Toybox has much simpler code. It's not an if-deaf forest. Let me just compare one file before they kick me out of this room. Toybox Clean, okay. The main function of Busybox is, it's not at the top level. It's in LibBB, Applet Lib, oh, sorry. Busybox, Busybox, Busybox Clean. LibBB, Appletlib.c, which starts with a bunch of if-defs for various architectures. In Toybox, I have lib slash portability.h, all those kind of if-defs go in one place. They're not in any of the actual commands. They're not in the library. We then have, you know, another thing Toybox tries to adhere to is single point of truth. Every actual piece of information that's a decision of any kind should exist in one place. So you change it in one place and that's the only place. Here, they're marshaling, you know, this thing implies that thing, you know, in a file, I try not to do that. There's a bunch of other stuff where they have like, you know, you see the if-deaf forest, they have if-zeros, where they have basically commented out code where we could micromanage this for speed or we don't trust the compiler's optimizer to get this right so we write it in a different way. And it's like, compilers completely change how their optimizer works every five years. It's just, you know, give it something small, give it something simple, trust it to do its job, and if it doesn't work, use LLVM instead. So anyway, skipping all that, we don't have time. Going down to the bottom here, here is the main function in line 1033 of lib bbb slash applet lib in the else case of an if-deaf. It has unused param, which is more micromanaging of the compiler. It starts with an if-zero, and then the rest of it is compiler micromanaging, compiler micromanaging, another if-zero. If we're not using a, no MMU system. You know, just if this is my first thing where I'm gonna go, okay, where does execution start in Busybox? I wanna drill my way down. This is a bit of a headache. Here's the corresponding toy box code. Okay, ls-lastris.c. There is one C file at the top level. It is 259 lines long. The last function in it is main. It starts with, technically speaking, you can exec something where argv zero is a null pointer. Don't let that segfault it. Give it good error return code for that. So this should never happen, check. This is save the current stack position so I can figure out how many times to recurse running commands internally rather than doing out. I have an explanation of why I do that. This one is going away soon. This was an Android bug where they had their signal handling set up wrong in Bionic, which they fixed. I was poking Elliot Hughes, the number two contributor to toy box is the Android Bionic maintainer. He syncs my code every Friday from the public repository and has a policy that he sends me patches and then pulls from me. The only things that diverge in Android's version of toy box is the build system because they're using Ninja and I'm not. So they have off to one side some build files but all the changes to the actual toy box code that goes in the binary go to me and then he pulls it from GitHub. So this whole block is going away in about a year and a half. I have a policy that I try to maintain backwards compatibility for seven years but for Android we're probably gonna do five on that. I don't have to go, I don't have time to go into that, ask me later. This is my no MMU block because I need the same kind of thing but it's not an if deaf, it's just an if on a constant. And then if the toy box binary is built into this thing, call the multiplexer that figures out which command we're running and all it's doing is basically shift the arguments one to the left and call the toy box main function because toy box's first argument is now the name of the command we were run. So reusing the existing code, single point of truth. Else call the init function myself to set it up and call the main function for that command. So basically you can then, and then the rest of this file is this is the setup code that figures out that sets up for a command and figures out what command needs to be run. All the setup code goes in main.c. So I try and notice there's a lot of comments in here. In a lot of these functions there's more comments than code and it's still only 259 lines. Let's see, tty.c is a nice small one. So whole thing, 23 lines. By the way, I pushed this concept upstream into toy box in 2010. I met Dennis Vazenko here and I explained to him that when I'm adding a command to toy box I drop one new file in a directory and it's just picked up automatically by the build and everything about that command is in that one file and to add a command to toy box at the time I had to touch five files. And he did a more complicated version of this idea but a lot of this did actually make it upstream into busy box because it was before 2011 when I did the Android relaunch and started seriously focusing on this. I was still, I pushed toy box patch into busy box. Into busy box. I sent them a network block device client implementation. I fixed the fact that their VI, if you cursed up and down on a serial link it would delete lines because it was decoupling the escape sequences and treating them as individual characters. I was still contributing to busy box and now I'm not. But basically, and then the main function is just three lines in a main. And then if we go over to busy box, let's see, asterisk, probably TTY.C, 68 lines. This is their version of that thing I had and this is their TTY main function. That's a tiny one. That is not, well, I mean this one probably is three times the size but a lot of them, I am seriously looking at, I think I can write a shell that's a proper bash replacement that does the curly bracket syntax and less than parentheses arguments to redirect the thing of command to treat it as a file kind of thing. I think I can do all that in 3,000 to 3,500 lines. Their ash is 14,000 lines. And the thing is asterisk ash.C, 14,000 lines. Hush.C, 11, or almost 12,000 lines. Those don't, those are two different shell implementations. There's a lot of stuff in busy box. I am constantly polishing toy box. I am constantly trying to clean stuff up. I have a page. Can't access the web so here is my, let's see, toy box, clean, www, cleanup.html. I have an entire page devoted to things like the if config command. When it was submitted to me as an external contribution, it was 38 functions in 1,500 lines. When I was done, it was four functions in 520 lines and this is all the changes it went through to get there. I actually described that one in great length. I am constantly doing cleanup on toy box. I document compulsively. It's not just the cleanup, it's there's a code.html that documents a bunch of library functions and how my argument parsing works and stuff like that. There's a design.html, which is the design goals of toy box, the philosophy behind the project, how we treat 32, there's 64 bit, why we basically always use unsigned cares so that we're UTF-8 clean and everything. Error messages and internationalization, toy box mostly it's error messages when it can get away with it is bad space percent sign S with whatever the actual thing that failed was so that people who don't have English as the first language have to deal with the smallest amount of vocabulary that they can. Shared library policy and stuff. I have explanations of it all here. And I do not have time to go through, oh yeah, this is just a file I was looking at in Busybox. Mini PS, this is one that they basically, they admit they shouldn't have, but they couldn't say no. You know, it's just weird stuff. Okay, I tried to save some time for questions. I am over time and they're being very nice. I will take two or three questions if they don't throw me out, but they gotta be fast. Okay, does anybody here have questions? Zero clause BSD, it's actually a public domain equivalent license. It's approved by SPDX by the way. Zero BSD is the SPDX short identifier. Yes, copy left. Yes. Remember how I started the first GPL enforcement suits? And they went on, if you include the ones in France and stuff, for something like five years. And now, okay, one line of code was added to Busybox. The lawyers asked me to put a copyright notice when you ran the Busybox command saying copyright, Eric Anderson, Rob Landlie, Dennis Flesenko, and others, you know. That was the only line of code added as a result of everybody we sued combined. There was never any code we actually wanted that wasn't submitted upstream. In the cases where they did do something, it was literally faster for us not even looking at their code to go, oh, that concept and write a new one from scratch. Anybody else? Oh, yes. Sometimes, I mentioned that they're micromanaging to get the smallest compilations and stuff. So if you build just false as a standalone binary, they're about 5K smaller because they've convinced the compiler not to include some health tables and stuff like that. But on net, yeah, my binaries are generally smaller than theirs. It varies, depending on what you're looking at. Okay, really quick, I'm over time. Who is the person who's kicking me out of this room? You, okay, I am so sorry. 30 seconds. Okay, ls-lastris.clsr. So, hello, oh, .c. Seriously? What? Oh yeah, I'm sorry, I'm a little fried right now. Okay, so they've got lots of things that 300K, 80K, 50K, 60K, lots of big things. And if you wc them to see how many lines they are, sort-dashu, n, n, you know, we're getting 3,000 lines, 3,000 lines, 2,000 lines, 11,000 lines, 14,000 lines. Same thing for Toybox. Largest file in there, okay, these are in pending. I have a directory of external contributions I haven't cleaned up yet, so let me pending. The largest one is PS, which is actually five different commands in one file. That's ps, top, iotop, pgrep, and pkill all in one file. I keep meaning to break that up. The next biggest one is sed, which is 34K, tar is 29K, bzcat 23, and then everything, file and below is 20K or less. And if I do the same wc on that to see how many lines they are, sort-n, again, no pending. PS, as I said, is almost 2,000 lines, my bad, I need to fix that. Sed is just over my 1,000 lines that I try to keep everything under. And the thing is half of sed is comments in white space, so I could make it smaller, but that would make it less readable, and then everything else is 1,000 lines of code or below. I implemented find in 683 lines. I implemented mount in 407 lines, and a lot of that is comments in white space. Go read the code, okay? Thank you, I am so sorry.