 So, good afternoon everyone. My name is Medial. I recognize most of you, but I'm actually really pleased to see a number of faces in the audience of people I don't know. Out of curiosity, how many of you in the room have never heard me give a talk before? Wow. That's really cool on one hand, a little scary on the other. It makes some of what I'm going to talk about today probably really good for me to spend some time talking about. As long as I'm asking questions, a couple of others. How many of you have joined the WN project or community, whatever you think your most significant sort of threshold was like in the last couple years? You've had a couple? Two. You don't count, do you know? The last five. Ten. Fifteen. Since the fall of 1994. Out of curiosity, how many of you were born since the fall of 1994 and are willing to admit it in public? Yeah, okay. Well, there's at least one person in the room that's been working, who's been alive less long than I've been working on Debian, which is kind of amusing. At least to me. So, what's the point of talking about the early history of Debian? The simple answer would be, I don't know, I was asked to do it. But more honestly, as I step through the things that I think are important to talk about regarding the early history of this project, I hope it becomes apparent that part of what's important is that we all sort of understand deeply and intrinsically what makes Debian interesting and different and special and why we should care about it. And that's all sort of tied up in this notion of the project having a set of common core values and sort of committing to each other to live by and work by and collaborate under that shared set of core values. And one of the ways we can do that is to make sure that we understand sort of where we came from, what the original motivations for the project were, how we ended up with some of the procedures and processes and foundational documents that we have, what motivated those, what caused us to have the flavor in those documents that we ended up with. And so what I hope that we can do today is let me trace through a little bit of early history and give you what I think were some important milestones. And in the process, talk a little bit about how I came personally to be involved with the project. And then I guess in the sort of popular way of putting these days we'll switch into the ask me anything mode. And I'll be happy to answer questions as long as we have time. And I believe if I read things correctly that they've scheduled us for an hour and 45, so even with my tendency to get long-winded answers, there's probably a chance for us to get quite a bit of stuff. Since not everybody has heard me talk before, let me start with just a brief, I guess the speed a little bit. I mean, some of you can laugh, any of you've known me, you know, for as long as you've been involved in Devian, but I talk people quite seriously. I mean, my first contribution to what we later started calling free software in 1979, it was a piece of assembly language code for a then obscure and now almost completely forgotten microprocessor architecture. It's a long story. As a consequence of that contribution, I was invited to attend a users group meeting in Canada, but I wasn't old enough to drive yet, much less travel independently to another country to hang out with a bunch of computer people. This was the point in history when my grandfather, who'd been a machinist and a welder and all that sort of thing, decided that an important thing for me to do one summer when I was staying with them for a couple of weeks was to learn how to weld. In case this computer thing didn't turn out to be real, I'd at least have a skill. So, you know, this was a long time ago. I started, it turns out, I first discovered Devian in 1994, but my first personal actual contribution to the project was in about October of 1995. How do I know this? I spent several evenings in the last week spelunking ancient backups, looking at emails I didn't think I still had. And to my great sorrow, I have not yet discovered the two that I think are the most interesting and most important. When Bruce's parents introduced me to Ian Murdock, he thanked me for joining the project. That's what the new maintainer process for me was like. But, you know, very shortly after officially becoming part of the project, I got very involved in a lot of things. And over the time, I served as Devian project leader for a year as tech community chair for a long time. Might have been involved in a decision or two while that period was going on. And then, you know, other things around the project. Those of you who attended the SPI Boff yesterday will have heard that I served on the board of directors of software and public interest for about twelve years and for the last ten as it's present. I stepped down about a year ago and I'm really pleased that other folks have picked up and are carrying on while there. SPI is the organization that provides legal and financial existence for the Devian project in the United States and elsewhere. And then, one of the things that I guess I'm probably best known for is that I also worked for a really long time for HP, a part of Hewlett Packard that became HPE. And the interesting thing is no, I'm not the guy who talked HP into doing things with Devian. The moment HP decided it wanted to do things with Devian, they decided having me around was maybe not such a bad idea. But over the course of almost 30 years at HP and what became HPE in two separate stints, I had the opportunity for a number of years to serve as the chief technologist, sort of the CTO for the open source and Linux business. And then when I went back, I went back and as an HPE fellow in the office of the CTO for about 25 months. But since the end of September last year, I am now thoroughly enjoying early retirement 2.0 and patches, et cetera. And we'll see how things go. In terms of things I'm doing now, probably most relevant to many of you in this room, I recently, as in about six months ago, joined the Evaluations Committee of the Software Freedom Conservancy. And it's really cool because here's another fiscal sponsorship organization that in some ways does a lot of what SPI does, but in a very different way with a different relationship with its projects. And so it's actually kind of fun for me to be looking at a bunch of potential free software projects that want to associate with the conservancy and having a different set of selection criteria that need to be considered. I'm also on the board of directors of Elephobjax, which is the parent of Lawspot, 3D printer maker. I'm very proud to be in that position because they were the first company to achieve the free software foundation's respects and freedom brand for all of their hardware and their business practices. And, you know, of all the for-profit companies I could be on the board of, that's a pretty cool one to be associated with. And if you want a 3D printer, you can't find a better kid. Okay, so as I said, I want to talk a little bit about what attractive needed to be in a few key moments that I think are important in the early project history. And then whatever you want to hear about, as you can tell, I've been around this project for a very long time. As you'll see from some of the moments that I think are interesting, particularly some of the ones that I was personally sort of more involved with than others, there are a lot of things we can talk about. That requires a caveat though. What I'm going to talk about is the history of the project as seen from where I was standing and where I was sitting and what I was thinking about. When this talk session was originally proposed, Ian Jackson was also part of the inviting list. And I would have loved to have tag-teamed this with somebody like Ian. Unfortunately, circumstances caused him to be somewhere other than Doug Conn right now, which is cool for him and not so great for me, but we'll carry on and I just want to make sure you understand that as we go through, I'm not trying to make this be all the cool things B Dale did for Deleon, but it's impossible for me to not mention a few of the things I think were important that I had something to do with in the process of talking about this. So I know many of you would be disappointed if I didn't throw a gratuitous rocket photo or two in. And the interesting thing is the way I found my way to Deleon isn't actually through rockets. That's something that came after I was playing with Deleon. It was something sort of rocket related though. I was working on an amateur radio satellite project and so what happened is I was working on with a number of other people. By the way, this is a slide that I cut from a presentation deck I used in 2003. This was done in Magic Point. I don't know if anybody remembers Magic Point. It owed a hideously horrible system, but for a while I had a devium template that I used it for all of my presentations including the corporate ones. It's got me lots of certain kinds of attention. So I was working on a GPS receiver. This was before GPS was real, but the GPS system was being built and we were going to fly a GPS receiver on a satellite and see what we could learn about on-orbit use of GPS for navigation. And the problem was that we needed a development platform. And I at that time was a user of BSTI which was a commercial derivative of Berkeley Unix that I was running on a PC at my house. And the problem was nobody else working on that project could afford a BSTI license. It was a thousand bucks or something. Which in the annals of Unix history had seemed pretty cheap to me but in sort of the context of people in eastern European countries who were contributing to the project, that was a hell of a lot of money. And so what I discovered after a while is that every time I built a new cross compiler tool chain for the AMD 29000 series processor we were using for that project I would make these copious notes and create a notebook file of exactly what commands I had issued and what order to successfully build the GCC cross compilation suite. And I would make that file a part of this monstrous tar ball of all the binaries and such that I had built on my BSTI system that I made available for download over in modem and you know dial-up speeds. And people in Europe were downloading that entire tar ball just to get that one file that had my recipe. And then they were replicating that recipe on Linux machines. And I had heard about Linux but that's when all of a sudden it's like ah, I'm doing the wrong thing. If I want to collaborate with these people I should figure out how to use the same stuff they were using. And somewhere in that same time frame Bruce parents had this great idea of creating a Linux distribution for ham radio people and he had started a project called Linux for Hams. It's one of those lovely virtual projects that involved a description and never had any deliverables that I'm aware of. Because Bruce went looking around to see what to start with and he discovered Devian and he thought ah, this is cool, we should start with Devian and put some ham radio software on top of it. And so when I knew that he was working on this thing for Linux called Linux for Hams I poked him and said hey Bruce, I'm working on this AMSAT project what about this Linux for Hams thing. And he sent me some emails suggesting I go grab these bits from this thing called Devian and see if I can make it work on some hardware that I have. Not surprisingly, within a couple of days of stumbling my way through an installation, which was before bootflop is really existed, I realized that there were a couple of little utilities that I thought were really important that weren't part of the system. And so what did I do? Well, one of them was really simple watch. The thing that would tail, you know, a command's output and sort of re-display it on the screen. And I wrote one of those from scratch and offered it to the project and Bruce sent this message to Ian saying this is kind of cool, we should take this. And Ian sent a note back saying cool, upload it. It's not quite that simple but very close to that symbol and boom, I was contributing to Devian. So over the year I've done a lot of things. Yeah, so you can say more recently, he's from 2003. So here's from an email I sent, actually in October of 1995. But right now I have exactly one Devian system up in the middle of several B.S.D.I. machines, two HP Workstations and Microvax too. I have full 1000 machines, what a mess. Running vets that are current, blah blah blah, working on GPS. I've just finished building my AMD 29 kit cross compilation environment under Devian dot dot dot. I don't know, when I read this, this sort of portends or fortals so many things I ended up doing in Devian over the next few years but whatever. I thought it would be interesting though to point out that Devian at the time was really really different and I'll talk about where some of the changes occurred in a couple of minutes. When I say really really different, when you got permission to upload things to Devian, you were given the login name and password of the FTP site that you uploaded the files into a particular directory. Kind of like an anonymous FTP thing but not generally available. And Ian Murdock would personally go look at what you'd uploaded decide it was okay and move the files into the file system that represented the public view of what Devian was. There was nothing but what we would now think was unstable. It was, you know, people uploaded stuff and if Ian thought it looked okay it went in the archive. And so we also, this is before when I first started, DPKG was just starting to appear and it didn't work quite the way it did today. One of the things was when you made a change to something you would actually manually craft an email and send it to this Devian Changes mailing list. You'll notice that that was hosted at pixar.com. That's where Bruce worked at the time. Those of you who understand will understand that that association is what's led us to have toy story related code names for releases for a whole long time since. And it's like okay I've done this and oh by the way you know there's this bug in Dchanges where it gets upset if you're doing a native package instead of normal package so I hacked and put in a zero-length diff.gz file that made it work. And then the rest of that message was the output of the Dchanges tool at that time. And a couple things I thought were worth pointing out. First of all, file sizes man. This is back when men were men and software was small. So it's zero.dif.gz and a 52.6 kilobyte.dev file. I don't know if it's possible to make a dev file that small anymore. If it is it's kind of interesting. And this was before we had DSCs and before we had all of this source packaging, format, choice stuff that we have these days. But a lot of things that you probably think of as being sort of important to show up there. There's difference between source and binary packages and priorities and all those sorts of things. But you know, it's sort of what we had and that was kind of the way things worked at the time. And we did real work with it within a year or so. We had finished developing the module for AMSA Oscar 40. This was a shot in the year 2000 in Peru, French Guiana when we were preparing the satellite to go on an already on fire launch vehicle. That's me sort of on the left side sitting there with a bright blue beanie thing on. It was tight enough to compress my brain cells. Anyway, I spent a summer in French Guiana doing that spacecraft on a satellite. Much of the software that was running on the processors embedded in that satellite was developed on Debian systems. Okay, so back to sort of Debian milestones. If we think about the early history of Debian in terms of releases, all of this stuff is actually documented in our Debian history, project history, depending on which way you look at it, document. But, you know, August 1993 was the first supposed release of Debian. And I'll be honest and tell you, I don't have any idea what that looked like. I was not involved with the project that early, but that was Ian Murdoch's first snapshot of the work that he'd done. By January of 1994, he had written the Debian Linux Manifesto. How many of you have read that? What's wrong with the rest of you? Seriously, I hope by the time I'm done you'll understand that it's really important, I think it's really important to not just read these foundational documents, but to sort of understand them and think about what they meant. If we think about what was going on at that time, there were in the world nothing, no other examples of something you would today think of as a Linux distribution. My apologies to anybody that might have been involved with things like SLS back then, but what we think of today is like distribution with packages and a package management system and installation tools and all that. It really just doesn't exist before Debian. And part of what Ian Murdoch brought to the table was this recognition that it ought to be possible for us to do this better. It ought to be easier to install, you know, a free software operating system and use it. And, you know, by the time he got to 1994, he'd written the Debian Linux manifesto, which was his articulation of what he thought he was trying to accomplish and what was going to be interesting and different about Debian. And I'll pull the key points of that out to talk about in a couple of minutes. That was also the first time Debian had anything like a package manager. It was not DPKG, it was the processor. Again, I don't remember whose call, it's been too long. But Ian said a couple times, there were about a dozen contributors at that time, and it was the last time he did what he thought of as a one-man release. So by the time you roll forward a few more months and get to March of 1995 that, the ODOT 9.3 R5 release and personally I got involved sort of around ODOT 9.2 if I remember correctly. But by the time we got to March of 95 all of a sudden we had this concept of explicit package maintainers. One of the things that I really remember about that time period was that before that, if you were someone like me and you stumbled over a bug or a misfeature in some piece of software in Debian the process was you'd go grab the source files associated with that package, you'd unpack them, you'd look at them probably unpack them, you undid the tar and then manually overlaid the def that sort of power. And you'd go take a look and you'd see whose name was the most recently listed one in the change log file and if there was a clearly indicated somebody who most recently changed it, the polite thing to do was to contact them and say I want to go fix this bug and upload it or do you happen to be about to do another upload and I might conflict with what you're work on or can I go ahead and do this and you'll pick it up and it'll be okay. This is because we didn't really have revision control systems in general like widespread use at that time. Some of us didn't have enough to be using them ourselves but in some sense the way the whole concept of packages and uploading versions of packages came into being was this sort of way of having something like a revision control system working at the granularity of packages and allowing people to work in a fully distributed, not always internet connected way because the internet was young the web was really young. The idea of a web page about this and have all this dynamic content, ha ha ha didn't exist yet, right? So the concept of having explicit package maintainers originally came around because of the bug tracking system as far as I can tell and the notion that if you were going to let people file bugs in some kind of central bug tracking system who was going to read them? The project had already gotten to the point where there were so many packages that everybody like seeing all the mail about all the bugs all the time wasn't going to scale very well and so the idea of designating a particular person to sort of be responsible for reading the bugs and being responsible for that package made sense but the key thing I want to convey is I at least never saw that as sort of taking away my ability or empowerment to go fix something. If there's a bug and you had time to work on it, you were supposed to fix it and of course you should talk to the other people who are involved in that piece of code and coordinate some but the idea that somebody else was responsible therefore I shouldn't be allowed to work on it and never entered my mind at all and it's kind of strange that in the years since then I've seen flurries of activity on mailing lists and you know, tip for tap bugs, bug wars and BTS where there are clearly people who think that somehow because they're the designated maintainer that somehow that makes them God and I push back on that concept and if I were to sort of exhort everyone to do something differently slash better going forward it's you know, figure out how to collaborate better and don't be afraid to jump in and work on things when it looks like something needs to be done. The other thing that's really important is that's the release where DPKG first showed up and sort of publicly visible kit and everything changed. DPKG predates RPM. It was the first real package manager used by a Linux distribution later when we added explicit dependencies to the Debian packaging system it was the first package management system for any kind of operating system anywhere that I was aware of that had that sort of capability. I worked for HP at the time we had this crazy tool for managing packages in HPUX and it certainly didn't have anything like Debian style package, intro package relationship dependency management. So you know, there was a lot of innovation going on here a lot of things that all of a sudden made Debian really pretty cool the first release I personally had code in was the November 95, 0.93 or 6. That's where deselect first showed up. How many of you still use deselect? I do. At least don't take it away. The problem is when Ian Jackson first built the prototype of that he thought it was a prototype. He uploaded it and said I'm really not good at designing user interfaces. Somebody please fix that. And the problem was that after it had been around for a couple of days many of us like knew the keystrokes by heart and the driver of their eyes closed. We didn't want to change it. So, whatever. Other people came along and murdered things later. And app, oh my god app it fixed a huge scalability problem with deselect. And deselect on top of app whatever. Amazing things that changed. By that point there were about 60 people involved in the project. And I was immensely proud to be one of them. That was a really cool time in history. And it meant that a couple years later the project kept growing. More people were showing up because it became easier to install Debian. Easier to use Debian. Updates worked. You could actually update across release boundaries and not have to reinstall which is sort of a novel concept to a lot of people. More people came and wanted to play. And then what happened is we had so many people joining the project. It wasn't possible just by word of mouth and casual conversation. For everybody to sort of learn what the project really was about and what it meant. With that incorporation of our core values to happen automatically. And there was starting to be some disagreements amongst developers not just about how to do technical things but about what our responsibilities were and how we were supposed to interact with each other. And that's what led to the creation of the DFSG and the associated, well the social contract and the associated DFSG. Because the social contract was in effect an expression of our project's core values. And those core values were things we were all going to agree on and they would help to guide our decision making on all of these soft boundary topics going forward. And one of the things it said is that we're going to do free and we had to define what free meant. And the moment the Debian free software guidelines were out people looked at it and went wow that's cool, that's articulate it's crisp, it's concise. And all of a sudden sites like SunSight do people remember SunSight? Yeah. All of a sudden SunSight said henceforth the DFSG is the litmus test for what will allow on SunSight. And you know a couple years later the open source definition appears and it's a copy and edit of the DFSG. Everybody understood that. And then the last sort of early milestone that I think is really significant was the release of WM2.0 in July of 1998. And the reason I think that's so significant is it's the first time we had a non 32-bit x86 architecture. And that's in my mind in a lot of ways is the moment Debian really became what many of us had thought about it being ever since. It was ooh. Yeah. Right. Stay. I have to admit recently I have one of those moments you don't like to have. Keith and I designed little bits of USB attached electronics. For the first time I designed one that actually needs to have like a 12 volt car battery attached to it for running pyro channels. In order to make development easier I put a jumper into the board's design so that when we're first turning along we can power the USB power. The hardware folks that probably know exactly what happened next I forgot to take the jumper off when I hooked it to a 12 volt battery and I jumped 12 volts into a laptop and I had one of those releasing the magic smoke to that so this laptop is like my last working laptop. Yeah. Right. Okay. So if I look at it from sort of the standpoint of release milestones everything that's happened since Debian 2.0 has been cool but it's been just like yeah turn it back. We added more architectures. We added a lot more packages. We added a lot more people. People went MIA. All sorts of things have happened since. These are some of the sort of early transition points but I have another view. A few other things and these were sort of things that either I was really involved in or really got my attention for some other reason. As I mentioned in the fall of 1995 that's when I first sort of made a technical contribution to Debian almost immediately when I was sort of officially part of Debian Bruce parents reached out to me and he says I have a real concern and I think you can help me with this. Would you be willing to? And I said well that's what it is Bruce. It turns out that up until that time FTP.Debian.org which was like the only publicly visible Debian machine was a PC under a guy's desk at Central Michigan University and that had been working pretty much okay but apparently every time Ian Murdoch uploaded a few things and put an email out about another update to the archive Central Michigan University which had a finitely sized connection to the internet saw their internet pipe get really busy for a while and there was great concern about how long this particular individual would be allowed to keep FTP.Debian.org under his desk. Some interactions with him about this and his parent not really understanding what the problem was left Bruce and Ian Murdoch both very concerned that we could all of a sudden one day find the only Debian.org associated machine just not being there anymore and since Bruce knew that I was running large FTP mirrors of some other projects inside HP he said would you please set up a mirror of FTP.Debian.org and just grab a copy of the bits in case something bad happens and I said sure I can do that and then I realized that none of the machines I had sitting around had enough space and all of a sudden the messages from Bruce got much more urgent but could you do this quickly please and so I scrunched around I found a cast off for 66 megahertz 486 HP vector tower and I found an ADAPTAC 1740 ESA scuzzy card and two hard drives to put in it. A 330 megabyte drive for the system disk and a 660 megabyte drive for the archive and we actually did multiple releases off of that machine where the entire release fit well within 660 megabytes well thanks to Noodle's lunch yesterday we pulled some stats out of the database today there are 404 packages in the Debian archive that are bigger than 330 megabytes and there are 80 packages in the archive that are bigger than 660 megabytes and guess what one of the ones that we would have had trouble fitting is the Linux kernel so it just to me you know when I tell people look my first computer had down 256 bytes of RAM they all look at me and go back to whatever it is old people do but this is a Debian it was the major Debian server and the one thing I said was look from a corporate networking security standpoint I'm happy to run this machine I'm happy to keep this mirror what I can't do is make it be the publicftp.debian.org so the reason we created master was this notion that this is where all the uploads will go we will craft the distribution here and we'll let all comers volunteer to provide hosting space for copies of the archive and all the public access will be through that layer of mirrors and so you know I guess in some sense I'm the one that sort of suggested we needed to have a mirror network and it was entirely for self-motivating reasons I didn't want to get fired and then unfortunately in March of 1996 that was where it came to an end because I was about to be visited by corporate internal auditors and I was the guy managing the department that owned the data center that was hosting that machine but I knew we were going to have other things we'd have to deal with with the auditors to explain this and so I sent a couple emails around that month and said to people I thought might be able to help and said is there anyone else who can host master.debian.org and Simon Shapiro and Mike Neufert I connect stuck their hands up and volunteered I ended up cutting a dat tape to send them with a copy of the mirror contents and they put it up and that sort of ended my directly running master.debian.org and then also in that same month something that not many people realize is that that's when Ian Murdoch himself left the project and it wasn't because there was a problem in fact things were going great it's because Ian wanted to go finish his degree I think he was working on a graduate degree at the time I don't remember the exact details I think he was at Arizona State, not sure. Anyway he said several years later in an interview that he felt fine about leaving it in the capable hands of Bruce Ian Jackson myself. I feel immensely sort of gravified by that because I wasn't doing much. I was busy working on an amateur satellite project. Bruce kind of took over by de facto as the visible leader of the project Ian Jackson was doing DPKG and the bug tracking system and various other things and I guess I was kind of trying to help keep infrastructure running. I remember being the DNS guy for a while this is we didn't have to like find a manager for the key ring because we were not yet using keys to manage uploads yeah, yeah really. Then the next sort of huge milestone from my perspective was in March of 1998 when Bruce Panans left Debian. That was a whole different kettle of fish what had happened is that we had all sort of come to the agreement that hey this being the leader of the project thing now that it's not the founder Ian Murdock we should probably like vote for that. We should pick somebody from amongst the developers. And so we came up with this voting mechanism and the original thought that people had was gee the three of you guys are kind of it why don't you run against each other and we'll pick one of you to be the project leader. And I said not me, I'm heads down working on this satellite project and I have young kids at home and I don't have time for this right now. And so Bruce and Ian were going to it was going to be an election to pick which one of them was DPL. And in the middle of the run up to that vote Bruce for various reasons decided he had enough of Debian and disappeared. And the reason that was such a big problem is that we hadn't thought about that but all the mailing lists were running off of config files in his home directory at Pixar and he just armed Dashard the whole subtree not intentionally trashing the mailing list he kind of forgot that the mailing list stuff was there but he eradicated our mailing list infrastructure in one command line command. And I think honestly that's probably the closest Debian ever came to just ceasing to exist because there was a huge scramble for those of us who were sort of around the project to kind of get in touch with each other and figure out what to do if we didn't have each other's phone numbers and all that kind of stuff and within a day or two somebody had gotten in touch with Bruce and he apologized and found a backup tape and pulled the mailing list stuff back and put it back up until we could move it somewhere else and oh that was a huge criff level but we survived it. And I sort of I took a deep breath and said okay we need to do better than I'm going forward and then the last thing I'll mention is sort of my personal sort of big moments in Project History was I think it was first and about March or April of 1996 that somebody sent an email around I don't remember who it was and said Debian's getting so big maybe we need to split it into a core something other than core and have sort of a different set of rules about how we manage the archive and got shouted down because there was no clear reason to do that and creating a second class citizenship among some of the packages but that whole idea came back up again in early 1998 and you know by then we were starting to think about wanting to have more than one copy of Debian, more than one distribution available and I stuck my hands up and said look I don't think sort of arbitrarily fracturing the set of packages is the best thing to do but I threw out an idea of treating our archive as more like a cache and over time that evolved into what Anthony Towns and James Truth and others eventually implemented as package pools and the interesting thing is before that it is literally true that the way we did a stable release of Debian is that we copied unstable and spent as much time as it took bug fixing it until we thought it was okay to release it and is Brandon in the room? I don't see him. I remember at least one early release where we sat up and I was waiting for Brandon to rebuild all of X so that we could fix that one last nasty bug in X and get it released. I don't remember which release it was but I'm so happy that we don't do things that way anymore. Okay, so the Debian Linux manifesto, I'm not going to spend a lot of time on these things but you really should if you haven't go read Ian's manifesto. It's one of the clearest articulations of sort of what he thought the point of Debian was and these were the key points that Brandon kind of distribution developed openly in the spirit of Linux and Canary. He was really impressed by the Linux kernel maintainers development process and he really liked the GPL and when you intersected those two that's what he was thinking he was trying to create with Debian but he told me and other people at various times that he had no idea that Debian would ever become what it is that he didn't have that much vision really. He knew something that he could do that would make an incremental move in the right direction and the rest of it is all because of the rest of us and all the things we've done over the years that have made it really happen. Carefully and conscientiously put together, Linux is not a commercial product, never should be but that doesn't mean that it can't be able to compete commercially. I thought that was really interesting and sort of pressing it and giving lots of things that have happened since. As I mentioned, one of the things that happened is that as the project grew, it became harder to ensure that everybody knew coming to the project had a uniform sense of what it meant to be part of Debian and that's what led us to create the social contract and its core articulation of what our core values were. And we've argued over time about would we write the same thing today if we were starting over? I hope at least on the core values level we wouldn't have a very different set of opinions because this still reads pretty well to me. And then as we continue to grow and particularly after the events surrounding Bruce's departure it became really clear that in a constitution some means of having sort of pre-thought out formal processes for deciding how to resolve things when stuff got weird was important and that's how we ended up with the Debian constitution. While Bruce had acted as the editor and sort of co-later of the content for the social contract, Ian actually was the principal author of the constitution. And there are a couple things about our constitution that I think reflect the experiences we've had and the circumstances involved. You know, our constitution does this interesting thing of leaving explicitly, leaving the vast majority of responsibility in the hand of individual Debian developers. And it reserves only specific sort of carefully bounded responsibilities for the technical committee, for the secretary, for the Debian project leader. And I think at least in part that structuring and that sense of prioritization was informed by the sequence of events including Bruce's abrupt departure. But in any case an awful lot of interesting stuff came about as a consequence of the creation of this constitution. And it's certainly true that over the years an awful lot of people have looked at our use of a preference based voting system and said in particular that was a really cool choice and it's made things possible that otherwise would have been really, really difficult for us as a project as we continue to scale. Of course it wasn't just the project it was scaling that was one of my favorite airframes. It's unfortunately one of the ones I lost on the fire. But that was about 260 millimeters in diameter. And while you can see that's me holding it up in the Pawnee Grasslands in northern Colorado. I had fun flying that the highest ever wind was a little bit over three kilometers above ground. It was a heck of a lot of fun flying a rocket that was big and fat. I'm building one now that's a little bit bigger in diameter and will be about twice as long. And I had thought maybe I'd have that ready in time to fly this year but not so much. Too many other fun things going on. I wanted to mention a couple of other things that I think have been really, really important to why Debian has continued to work. And it has to do with the way we capture best practices and turn those into an articulated policy. I think that's been absolutely essential for us to be able to scale to where we are today with so many different people working on so many different pieces of software and having them all kind of fit together as a distribution. We've done a lot of discussion here at this DEB conference about whether in fact we have some big problems on the horizon. We've talked for years about oh my god can we actually package Java applications using the same kind of policies in the same approach. And in some ways Java is a whole lot more like seed in some of the other languages and programming environments people are using today. And as we talk about how we're going to deal with containers and flat packs and all sorts of other stuff I think it's really important for us to sort of stay bounded or stay tied to what our original fundamental core set of values were and look for innovative ways to package it and aggregate things so that we can continue providing the best collection of software possible. I also think the public bug tracking system, the fact that every bug is reported in all of our packages with a couple of weird exceptions related to security embargoes is just out there where everybody in the world can see it is an immensely important thing. In my professional career I had the opportunity to do things like try to console customers who were working with a particular commercial distributor and they would report a bug and one of our field engineers would root cause it trying to fix and submit a patch to the distributor and that patch would disappear into the distributor's internal distribution mechanisms and bug tracking things and sometime later it out would come a new kernel and the assertion that your problem is fixed in this new kernel and particularly for our customers in places like Japan who demanded that we be able to demonstrate to them what change was made to fix their problem and that lack of transparency was really challenging and it was always just so much easier to work with them where all these things were right out there where we could see them and so I think that remains really important. And also to wrap up the me standing here talking part by throwing out a few thoughts about what I think really matters about them it starts out with being about freedom, it ends up being about freedom too but I think the fact that we have a stable functional community has been immensely important and what I mean by stable functional communities even though we've had some huge pissing matches amongst ourselves over the years, a couple of which I'm really familiar with the non vocal majority of maintainers and DDs just keep doing their thing and on any given day even in the middle of some of our biggest flame wars package updates have been getting updated, we've been updating our archive and everybody downstream of us has kind of gone yeah you guys will figure it out and in the meantime we'll keep using the DDs and I think that that's been really pretty cool. There's an awful lot of architectures, an awful lot of packages, they wear us out sometimes and you know it takes some personal responsibility for how many architectures we had at one point and I think there are at least three I can point to that if I started the ports of all but one of which are completely gone and it's going to be dead soon so whatever mistake that might have represented is self-correct. But the fact that we're sort of open to contributions and anyone who wants to come join our community and has an idea about something new they want to support we have mechanisms to make it possible for them to do that has just been immensely enabling and then finally there is this huge downstream dependency chain I don't know if you've noticed, you've heard if you've been sitting in talks here and people have said it, I hope you all understand it and realize it and know that it's true an immense number of people in the world use the bits that we work on in the company. When we craft something it doesn't matter whether the end user gets it through OSR through Ubuntu or through I don't know any of the number of other through Tails or through all these derivative distributions there are companies that take all kinds of things. It was fun when I was sitting on HP's internal open source review board and I would see a proposal come through that was nothing related to Debian but where they needed to grab sources from somewhere and I would recognize a Debianified version number in the thing they were asking us to approve and why did they do that? Because they knew that we got the source package from Debian Main and it came with a certain set of assurances and so we're embedded in an awful lot of really interesting places and I think that's pretty cool. So a bunch of you asked me what have I done recently with rockets that was my most recent project. The picture on the left is the last time I saw the airframe intact because we have such lovely telemetry from the airframe and flight I know that it did mock 3.1 on the way to just under 10 kilometers above ground. Also with the shovel was able to find the back end of it about a half a meter below ground and what I really wanted to know was could I build the fin can assembly such that it would survive going faster than mock 3 and the amazing thing is that yes I could because you can't really see it very well in this photo but of the 3 fins two were completely intact not even really scratched, no cracks yes the paint was partially scraped off digging down through the dirt after it hit the ground and the only reason the third one failed was there was a rock about the size of my fist in the ground so it would not have gone to 32,000 feet above ground if it had not remained intact and stable through the mock transitions and this is simultaneously there for really cool because I proved to myself that I could build something that would go that fast and stay together and really depressing because after getting those photos we filled in the hole and walked away that was really hard to clay and it was really hot and humid and in a way we were going to stand around long enough to ok with that I'm going to stop just talking and open it up for questions I hope that some of you have some, I think we have a whole bunch of time left like almost another hour and I would be happy to talk about almost anything from Debian's history or anything sort of around that that you'd like to hear about right so early in the history of Debian in 97 I think is when SPI was created I don't remember exactly, Debian started out just being like a lot of other free software things and amorphous group of people contributing to a technical work and there was no legal or financial structure around it got to a point where various folks thought it was important that there be some legal existence for the project, somebody that could hold trademarks and main names and in the inonic states at least there was an opportunity if you had the right IRS recognized status to take donations from individuals for which they can claim a tax deduction and that seemed like a reasonable way to attract financial support for the project and the sort of prescient or cool thing that happened was that instead of creating like the Debian Foundation the folks involved created this thing called software in the public interest and its original charter sort of said that it would support and enable the development of free software and related open hardware stuff. Now over time it's never actually done much that was useful in the hardware space but on the software side you know over time the model under which SPI operates has allowed a large number three or four dozen over time different projects to associate with SPI and become part of that legal and financial umbrella so today software in the public interest is still in existence it's still providing legal and financial services to Debian and to a bunch of other projects and as of the SPI buff yesterday it was reported that for the first time SPI's held assets are now above a million bucks and that makes it kind of real so there's a lot of work amongst the current board there to ramp up the sort of formality of some of their processes and become an even better fiscal sponsoring organization that's been in the past I'm certainly pleased that after spending about a decade as president of SPI that it's still not just a going thing but a thriving thing. Yeah, Tom. So beyond the words in the documents looking back over time in Debian what is the is the intention of Debian towards users in particular I come to Debian as a developer it's fantastic as a developer but what was the thought about Debian for users originally and also how do you see what a user looks like in the past, present and future? I think it's evolved. I mean I think when we first started the notion that there's really a distinction between developers and users isn't something that many have thought about very much because if you run the clock back to that time I mean this thing called the web was really new public access to the internet was still at least in my mind kind of a new thing I mean I remember when I got my first email access when I was an undergraduate student at Carnegie Mellon it was on this thing called the ARPANET it was the side order of usenet well the UCP usenet was just the news distribution part and you know it was a very very different thing it was very elite it was very clickage only people who had either you know were part of the university that was on the net or had a DARPA contract or something could use it and then you know the commercialization of the ARPANET happened and it became the internet and over time evolved into this amazing chaotic weird thing that we all use today and so at that point in time there weren't that many people who had computers who weren't geeks and so when we talked about users what I really thought about in the early days were people who wanted to do things like write software build hardware for like an amateur radio satellite there were certainly people in my circle of friends who didn't want to work on Debian they wanted to use it to go do something interesting and if you look back at what packages were included in like the O.93 release the reason it fit in you know 660 megabytes of hard disk really could be distributed on a set of floppies without sources is that we didn't have huge big pieces of software in there I don't remember if we had a web browser at all in that time period we probably did but I don't remember I know we had GCC I know we had Emacs and you know if you have Emacs and GCC you know the world is yours right so I don't know being completely blunt about this having grown up in the era of like old Unix on 16 bit processors spending an awful lot of time on early commercial Unix on early 32 bit processors Linux was this huge breath of fresh air but I laughed when my daughter at about age 9 asked why she couldn't have a Debian machine too and I said well of course you can and I had to explain to her what would and wouldn't work and she decided to go ahead with it and we installed Debian for her on the desktop PC and the very first thing she wanted to know I think it was Star Office at the time that we had installed for the first thing she wanted to know was how to change the font and the text editor and I don't believe I had ever personally cared about the font and you know what the second question was how do you change the color of the text and oh my god I certainly never cared about the color of the text I didn't really like green I actually bought monitors that were amber phosphor cause I was into amber not really but the 310a is that the right kind of I really remember that yeah with the anti-glare sign microterm ergo 4000 terminals cause they were 80 columns by 66 lines and we did 19 too yeah we did ourselves I really didn't see a huge distinction between users and developers over time thanks to my daughter and I had some really interesting experiences actually the first time I met Gunnar in Mexico we were attending a conference in Veracruz and one of the things that happened at that conference is someone someone local was teaching a how to install Debian workshop thing on the side and I went and sat in the back of the room and there were a bunch of high school or college age kids in there I mean to me they seemed like kids and there were a lot of female participants I don't know how they got through what the context was but they were what I noticed is they were taking this incredible number of notes and I stumbled over the fact that they were simultaneously trying to deal with the language translation cause at that time Pumfloppy's only worked in English and so it was sort of here's this thing it's going to ask you during install what does that mean how do you want to answer it and how do you do that in English and it was an incredible mental load and that was one of those epiphanies I had about oh man these people just want to use a computer and they want to use cool software on it and we're making it really hard and that's why when I ran for DPL in 2002 and successfully well 2001 and successful in 2002 my platform was full of stuff we needed to do a better job at internationalization particularly in the installer cause I sat in that room and watched those poor kids taking pages of notes to remember how to answer the questions dealing with the language translation and everything so I gradually personally came to an understanding that there was a broader base of users but I will not pretend that even today I care very much about people who want to drag and drop things in a GUI I just don't understand why anybody could do that Enrico Thanks for putting some more history with Debian on record at least on video It occurred to me recently that Debian is starting to have such a long history that people who joined it recently can feel daunted by not really not really feeling a part of it because whatever whatever happens somebody around will say yeah you think that's a tough transition A out to Elf Oh yeah and man the day bash stopped working and unstable Right and so and it's got to mean that Debian is getting old enough that it might make sense to have some document somewhere that can be a little history lesson because well I guess one of the reasons I was told history when I was in primary school is that I knew how the environment around myself came to be and I guess Debian's getting there so great for this and I wish for more and even that teens could have a little bit of history of teens so that people can join can kind of grab it up to speed on the major past events and instantly how did you manage to pull out the A out to Elf transition and hit behind the sofa and when I came out the system appeared and it kept working Oh it was a lot of work so like so many things that happen in Debian it has to do with being careful about how you name things and what you choose for paths and sort of not trying to do things entirely in place you know you could it's like so many things you have to have the proper requisites in place you have to have a kernel installed that understands both the new and the old and then you have to have the right new libraries installed and then you have to start installing binaries that depend on the new libraries and not the old ones Can you also add a bit of an introduction of what is A out What is A out? It's the thing we had before Elf Yeah so if you look back in history the thing that I think was probably the most significant of all that was the transition from static to shared libraries and that's when I sort of remember things changing a lot it wasn't a hugely difficult transition because since by then we had dependency management in our packaging system you could do things like say and by the way we didn't have Delta Helper back then so we had to manually craft the dependencies to say I depend on this version of libc and oh lord the bug there are reasons we built tooling for this stuff people and use it because it's the right thing to do I don't know what we do these days without lentian to help remind us that oh something changed since the last time you uploaded this you lazy guy two years ago or in the case of gzip since the last stable release a decade or so ago but yeah those trying to actually talk about any specific one of those transitions I don't know if it's all that intimidating but it's the same thing we have had to do a number of times since then where somebody has to sit down and plan it out and you have to think about okay how do I make sure that the old menu can kind of coexist during the transition period and it's hard but I mean if you really want to talk about specifics of something I guess we can but that seems like it's getting a little gnarly a quick comment and a quick question I don't even care about fonts and colors all of the rockets are beautifully painted and your presentation uses like this modern sans serif font which looks stunning on screen so I guess a modern font? Yeah Keith what has your vintage of ITC been doing at Gothic? I always know anyway by the way the reason I'm using this font is that Keith gives me crap with my slides on one font I used to cut and paste things all the time and just didn't care about changing the fonts and I'm told they look really ugly but I don't know consistent typography just makes all the difference I've been told this as long as I can read it I'm good The question I have is how did Pixar.com got involved because for me it was a bit of a surprise to see how they did it I worked there and Bruce worked there and that's the only connection I mean the reason Master.devian.org was hosted by HP when it first started is because I worked there and I didn't ask permission I'm not kidding I mean I had a brief moment as I was waiting for it to install a floppy but I was going huh I wonder if I can get in trouble for this and the entire time Master.devian.org was hosted in the little data centers that I ran at the time I was the technical computing manager for the manufacturing organization within HD Colorado Springs I had about a dozen people working for me and we maintained several thousand systems on site and this is one of our you know computer rooms and nobody really cared it was on our it was one more server we were backing up in our mega backup system and it was using our unenourable power and it was on our internet connection and internet was built kind of in big clumps and it didn't actually put us across the threshold so nobody knew and I'm sure that initially things were similar in Pixar it was really really funny many years later when HP decided to officially support Devian and started publicly talking about how proud they were to have been the hosters in the original Master.devian.org I want to step back for just one second because Enrico I didn't address the other thing you talked about which was capturing history I realized a bunch of years ago that that was someday going to seem important and it's the reason I personally sort of took ownership or responsibility or whatever for trying to keep this thing we call depending on how you look at it either Devian Industry or Project History it's one name and the web and the other one in the packaging system alive and try to keep that up today I don't know why but that's something that despite my best intentions I've never done a very good job at keeping that up today it exists only because other people look at it and go dude we have a new DPL here's a patch they add them to the history so I would encourage all of you it doesn't matter how long you've been around I'll take a look at that document there's something you go hmm doesn't mention this write it up I mean preferably in the form of a patch but even just an email would be great I have realized in the last couple of weeks the linking through I found backups of laptops that I was using in like 1998 that had copies of email that dated back to the mid 90's that I'd forgotten I had and so I've had the pleasure the last couple weeks of reading the emails where we did things like move to master.devian.org and who the people were involved and all that I don't know you'd think being retired again now that I'd have time to do more of this stuff but who knows if I'll ever get around to writing more I made the mistake during my return to HP of committing to be co-author on a significant update of an existing book I'm so glad they told me to go away so I didn't have to finish that I'm just being serious it turns out I love to write things the problem is when I sit down to write something it's a laborious process because I have a minor in poetry and I care about words and it's hard just to get things to where I'm actually happy reading in this heart so I encourage all of you who have a few minutes go read that document and please send patches to the BTS with suggested additions or improvements because I think that's one thing we can do to try and capture more of this a bunch of the things I've thrown in here are things I went back and pulled out of there so if you care about when things happened and you know who we memorialized and which releases there's a lot of that sort of stuff that's around Yeah, I agree. Right, so while running by people in corridors here I've heard the idea of establishing a Patreon for the people to be able to pay money to the packages they're using so that developers can be paid and maybe going forward with that up to upstreams could you enlighten people about the history of developers being paid and maybe expose them to the idea for the future? So in terms of being publicly paid there was this thing that affectionately became known as Dunk Tank where there was an explicit attempt to raise money from companies that cared about Debian to be able to pay stable release managers to do their job and that was tried for at least one release cycle and I thought it actually helped because I thought it allowed people to put more time and attention on a task that nobody in the project really wanted to do and I thought generally that was quite positive the unfortunate consequence is there were a number of important people to the Debian project who were really upset that somebody else was getting paid to do their part of the work and they weren't getting paid to do their part of the work and I thought that was grossly unfair and so I think that if you want to run some kind of a public system like that it has to be structured in such a way that everybody involved in the project has at least some opportunity to participate and that's the thing that I think would be really important is that it isn't picking one or two people to publicly fund and everybody else kind of and keep doing what you're doing because that's the thing that I think really hurt at that time full public disclosure I thought it was an interesting experiment to run and I made sure my employer kicked up some money to be part of that the other thing many people don't know is when we were trying to get the PIRisk and Itanium ports of Debian done HPCent spent a few million dollars getting that done we led contracts with more than one consultancy who did a lot of work for us specifically working on patches to packages in Debian the interesting thing about Itanium is it was not the first 64 bit architecture in Debian but it was the first 64 bit architecture where the actual machines spread the physical memory out across the entire address space those smart hardware guys in Fort Collins realized that if they used high order address bits to pick which bank of sims it made the machine ever so slightly faster and as a consequence it was the first time we actually using high order address bits in the 64 bit address space and oh my god we break a lot of software I don't know how many of you remember but when James Truett was the FTP master he actually approved something called the zero tolerance reporting problems policy which was permission to do non-delayed in amuse of anything if the only changes were adding include lines to the headers of the things that configure was trying to run because back then things were lazy and they created a little program source code to test some feature on the system but they wouldn't bother to hash include STDIO or malloc.a or malloc.a or any of that sort of stuff and the consequence was that the compiler would make an assumption that things were a certain size and that didn't sort of match what it needed to be and you end up getting set faults when the tests ran and so configure would fail and it turns out this is because we had RAM that was actually in parts of the address space that they had never been in before and so we had addresses with non-zero bits in the high order half so truncating it to 32 bits kind of messed up the address and so I forget what the final total was but it was like 5 million bucks or something that was spent directly on having people work on improving that part of deviant. I don't think most people ever even knew in that or if they did they thought we were just you know maybe we had people working for us or something but the weirdness for me was that we were spending immense amounts of money getting the thing we cared about done in deviant and nobody had a problem with it. In the moment a tiny little bit of money got paid publicly to a couple people who had a really critical role to getting a release done and it was done in a way where people felt like they were being disadvantaged and broke horribly. So if I have any advice for the future it's make sure that whatever system gets put in place is something where everybody can choose whether they want to participate or not and has the ability to be part of it and if you do that it might work. It certainly won't work if somebody else decides who gets to participate which packages are important which ones aren't that sort of thing. Yeah. So you lectured us about the milestone queue so while working along with deviant in the past years and that made a difference in your opinion. But that's looking backwards. If you look in the future what are the milestones you wish would happen in the next 20 years so that we continue to make such a big leap forward. Please don't break the things that matter to me. You know that sounds a little facetious but I fully recognize that my personal needs for a computing platform are not like a lot of other people. Not like a lot of other developers. Certainly not like a lot of non-developer users. And this has come up a number of times. I've been dropped on my head as a child on a number of desktop systems and that means there are certain things I will probably never go try again. I struggle constantly to sort of reduce the number of bits installed on my machines both to reduce the attack surface and they keep from having all this code to understand. Drives me nuts when something that seems simple doesn't work and I can't figure out where to find the piece of source code that might be broken to go fix. And I admit it. Look you know the first programming language I learned was it's funny. My first computer was based on the 1802 microprocessor and when I was first programming it I thought that the opcode mnemonics or excuse me that the hexadecimal versions of the binary values were assembly language because there were numbers that you know they had A's through F's so there couldn't possibly be numbers, right? It wasn't so much wider that I realized that oh that was still like machine code that wasn't even assembly language. And having started there and sort of been dragged kicking and screaming up through becoming a moderately competent shell and C programmer I just don't understand some of the things that some of you seem to think it's really great to write code in these days. And you know I took a class at Carnegie Mellon years ago and taught by Mary Shaw of Wolf's Shaw Clubfinger and Flan fame called comparative programming languages in which she sort of gave you rules for rapidly figuring out what the shape and nature of the new programming language were. And I thought a couple times recently that she just didn't have the ability to anticipate some of the things people have ended up deciding would make good languages in recent years This goes to some of the things I was mentioning earlier I think one of our big challenges going forward is to figure out how we're going to handle applications that are written in languages that have expectations about how source code is handled and do they even have the concept of a binary that gets distributed or a separate library that has versioning or you know high management so numbers and that sort of thing because it becomes more clear over time that the model for which a lot of our policy was designed is the model that's espoused by C and languages like it and there's an awful lot of stuff people want to run on computers today particularly in the web application space that doesn't really quite work like that and so I don't know what I think but the problem is I think my personal history in Debian has been really sort of tied up in this notion that things evolved on their home and because amongst our community there were enough smart people when we reached some point where there had to be an inflection there had to be a change somebody was smart enough to stick their hand up and go we got to do something different and we were all willing to sort of listen argue out the boundary conditions and actually change things and go do something differently and whether that was a out to Elf or whether it was I don't know moving from the whole FSS T&D to the FSG's file system hierarchy standard there's been a lot of times that we've had to do things and we figured out how to make those transitions and the fact that the system basically kept working for users through those transitions is the kind of thing that I think was really important and I hope we don't screw up. I was thinking through the presentation what amazes me most that I have seen have been almost 15 years in the project and the social transition is something that I would really highlight for this period that starts basically when you finish your presentation recorded history starts more or less but I enjoyed it nice. So you can write those chapters the thing is when I joined I knew I was aware everybody knew that getting into the I was getting into a fighting boys club having a high testosterone levels and having a thick skin was expected and was required everybody knew about it and well we made a huge transition into a project where we explicitly have to be excellent to each other where we have to include everybody and at least I don't feel that it feels artificially politically correct like in many cases it happens so I understand that's natural from growing up most of the people I knew that were 20 something back then around the 40s by now they were and they are and they will be younger and older people I am very happy I started counting generations now and yet there is still it's not like we are all getting older we are getting new people joining younger people joining contrary to what some of us have talked about in the past but well this strong shift of attitudes I think it's the only thing that allows us to continue functioning as a group into a future I totally agree and I think it's been really really important and I have loved being part of this community as we sort of evolved in that way the only thing I throw out there I unfortunately wasn't in Enrico's talk I guess on Sunday was the one where you talked about the importance of the social relationship we have versus technical things or something I hadn't arrived I came in, are you laughing? I came in I came in later that night and the one reaction I had to the report that someone gave me of that talk was I think it's really important that we all remember that it's really important to be excellent to each other but being excellent to each other doesn't mean not disagreeing with each other it doesn't mean holding back when we think there is something that's true that's not part of the conversation and what I mean by that is that I think personally that embracing diversity requires that we actually know what other people think and that we should trade ideas and that we have disagreements that we in a collaborative sort of convivial way talk to each other about how we feel and what's different between your opinion of how the world should work and mine and what that means and how that translates into Debian and only when we're actually open and communicated with each other are we actually embracing that diversity otherwise we're kind of don't ask, don't tell and that's not a good way to live having said all of that I think one of the key things that we really have to stay focus on is that we are an association of individuals who have made common cause to create a free operating system the reason we're here the reason we come to Debian is to help make Debian the technical deliverable as great as it can possibly be there are all sorts of things that happen along the way I have so many friends here I love coming to Debian because I get to see all my friends in person again but the reason it's important that we're friends is that when we have built those sorts of interpersonal relationships it allows us to work more effectively the rest of the year online through the internet and other crappy communications tools to very effectively deliver an outstanding technical result and so we should do all the things to be open and inclusive but we should also always remember what the point of doing that is and what we're trying to accomplish at the end of the day Neil. So you talked about the core documents the stage the internet was at at that point and how small everything was how do we extend those core documents to actually consider users who are a step away from Debian we don't even know they're running Debian, they're just using a website and that website might be running on Debian, might be running on Windows, they don't know and possibly they don't even care so how do we embrace that how do we allow ourselves to offer the best service when we are dealing with software as a service we are about to fall away from the users we have problems at the moment where it's very hard to judge that kind of software because we don't have any idea how this is the really are, we'd see a couple of installations but then there's hundreds of thousands of users per instance and then you've got all these other it might be a container, it might just be a camera maybe it can be back as a different OS as far as the user's concerned they've got no idea how do we protect those users, how do we communicate with those users and what do we need to change to give them a better service Well it's sort of interesting that you asked this and I'm glad you sort of filled in a few details about the kinds of things you're thinking about because I was immediately going to throw it back at you and say what do you think we're missing and so thank you for talking a little bit about the software as a service case and the indirection of the relationship with our users that results from that. I don't think there's like a really simple answer to this. One of the things that I think is important is really sort of being willing to think about other use cases that are brought to us that we don't intrinsically use ourselves it's funny in building rocket avionics with Keith. We try very hard to not build things we wouldn't use ourselves put differently most of the stuff that we make and sell to other people in that hobby is stuff that we actually wanted ourselves and that helps inform things that are really cool and it's certainly true to Tom's point earlier who are the users well the users I've always cared about have been me and the people I know personally my wife's a graphic designer they're off doing their own cool things and technical and social policy arenas that are you know outside of my personal real direct experience and yet I want to make sure that they're all taken well care of. I guess on some level we have to assume that some amount of proxing will happen on behalf of the people that are standing up those sorts of services on behalf of what they care about for their users certainly if somebody here has a great idea, lovely people that we should invite to come help us figure out how to do these things better then let's figure out who they are and invite them but from my perspective it is interesting in listening to Matthew Garrett's talk the first one not the second one the non security one. One of the things that I sort of in the middle of it had as a gut reaction was who died and left us responsible for all of these problems some of us like okay there are a lot of things that ought to be done better and you know as others tried to point out this week maybe we are the people with the positional authority and the gravitas to actually go drive some changes but in this particular case I don't know that sort of solving all the problems of you know how software is a thing that's consumed itself versus a software enabled service that's the thing that's consumed itself. I don't know that that's completely within the scope of our ability to do something good about Our scope of that as from my perspective is that there are themes that are principles that are rules within Devin that are getting in the way of actually delivering those kinds of services because of the things like the faster lease cycles so there are lots of ideas about how do you actually maintain these kind of web services when yes if you want an open call but actually you want the top level to be updated much more rapidly for the security fixes and everything else that happens but web is so risky so on the one hand you've got this yes everybody uses the web because you've been with us now but it's also a security nightmare and you've got to keep on top of those things so quickly how would we manage to keep what we think of as a release as one big object able to support these kinds of services where we've already got a few exceptions and say well this package needs to go through quicker than it would normally go into the last stages of the release or updates during pipeline releases just because of these security implications So let me ask a question how many of the people in the room run Devin stable on anything other than a server What do you do with a stable on something other than a server You use it? You use it everywhere? It's not, it's 2017 So already you can see That's stable too well I'm impressed, I couldn't do that Most of the people are going to be using backboards to get I run unstable with bits of experimental on an upstream kernel that I build myself and everybody around me runs testing Keith jokingly once called stable stale and unstable usable and I don't know how jokingly it really is because that's certainly the way I use them I have to admit that personally it's always bothered me that we put so much emphasis on the stable release process I really really care about the improvement thresholds that we demand in order to allow packages to promote from unstable into testing the fact that we don't let things sort of get out of unstable unless they meet some sort of obvious structural requirements and aren't adding new heinous bugs and all that sort of thing but it's interesting because somehow it seems like so much of the rest of the world looks at us and thinks of us as like the original enterprise distribution with an enterprise distribution ask release cycle and I think of this as the distro that releases what's it now four times a day you know every time the unstable packages files are updated so that's a really interesting question I have no huge insights here because I have you know my professional career a lot of that was helping people understand how they could sort of pick the level of intensity of change they were willing to deal with and you know we built some products that were built on stable with some strange stuff bolted in that went to a gazillion places and at one point were touching one sort of all mobile phone calls in the world every day and then another contact and by the way those machines had to have like many kinds of reliability because they were not going to be rebooted for like five years well that's a weird thing to think about and at the other end of the spectrum you know helping people understand how to grab the latest greatest bits and try to aggregate them to create something that would support their needs and expectations higher up the stack and I always thought it was hugely challenging it's interesting how rarely the discussion of what the stable release was actually came into the conversation so I wonder sometimes if we just need to rethink all of that part of the conversation that we had in 1998 that led to the creation of package goals was my assertion that many users would actually want to have this thing that was somewhere between unstable and stable and because it was implemented by Anthony Towns in support of the stable release process that middle thing became called testing which doesn't really sound like the most attractive thing to an end user but if you go back and read that email thread from 1998 which I actually did like night before last I was making a point back then that I thought that was what most people would actually probably want to be running and this leads to this interesting situation where I want to push back on some of the fundamental assumptions about oh Debian release is really slowly and we have to be bound by that as fundamental assumptions in that whole discussion I don't know that that leads us somewhere terribly useful and I certainly don't want anybody involved in this stable release process to feel like I don't appreciate them because my servers run stable and I really like them being really really stable but it's interesting that I think this is another place where many of us within the Debian community may be very different ideas about what's really important and I don't know that we've ever really had a great overt conversation about it I don't know if that helps or not, I don't have immense wisdom about that I was trying to get your perspective on how things like maybe our view of users in sort of contract has to change or maybe the DFSG needs to have some idea of this separation. So I don't think the DFSG ought to be touched for this because unless somebody has a specific suggestion that we can think about because I still believe that the fundamental assertion of core values is pretty much the right one. Now how we translate that into deliverables is a place where I think we can have some discussion. I've heard some ideas floating around this week about how maybe we think about DFSG compliance a little bit differently than we have in the past particularly with respect to the difference between binaries and sources. I hope there's a robust discussion about some of the challenges we face and how some tweaks and how we think about those and process the software that we package that might lead us to a better state. But I don't have a whole lot of... I don't have much to interject there. Our friendly camera operator in the back, if you have any insight on how Devian was used at Pixar How Devian was used at Pixar I know much more about how it was used at Dreamworks because they were one of my customers at Dreamworks it was okay, what can I actually talk about? I do know that there are multiple rendering farms run by different digital content creators where large clusters of servers are running Devian as the base OS for the rendering of the final product. I don't think I can mention which companies are using what. There's one well known company that has been involved with Devian in the past and it's a very conspicuous Red Hat user. There are also many Devian people working at Red Hat and run Devian on their own laptops. So that's an interesting little factoid on when RPM first emerged and Red Hat was first getting started. There were multiple conversations amongst conversations between key folks in different parts of Devian and some of the founders at Red Hat about wouldn't it be neat if what Red Hat did was use Devian as its base and then sort of build its thing on top of it and unfortunately I think they'd become too invested in the idea that RPM was a thing that they could sort of attach stickiness to from a business standpoint for that to ever actual work but wouldn't the Linux standard space problem have been really different if just everybody used Devian as their base? Oh well. Yeah, so I just wanted to come back to your comparison of stable and unstable and you said well we release four times a day or whatever. I think that's not kind of true as we release four times a day 75% of the time. I'm like the other quarter of the time we're in freeze and unstable is doing very little. So it's like there is a tension there between the needs of a distribution that has a process of stable releases and the needs of a rolling release model. Yeah, there are probably people in the room that still feel hurt by some of my victory all over the years about how horrible long freezes are to the project as a whole because the idea that I can't upload something unstable when I want to is always just sort of driven me nuts. Having said that, this is where I think to some extent I think a lot of the freeze delays have had to do with how we think about our deal with these really large complex interacting suites of stuff. And the funny part is I don't really use any of those and so it does cause me sometimes to wonder whether that question which was first being asked in like March of 96 and has come up a number of times since about should we really be thinking differently about some core set of things and some non-core set of things keeps coming up and I keep trying to not have a different answer because I really hate the idea of sort of separating it into first class and second class software somehow and yet I don't think any of us in the beginning, even when I used to joke about the fact that at the rate we were patch gudging things essentially all software would be packaged for deviant even when I was saying that 12, 13 years ago I don't think any of us ever anticipated that we would have as many packages with as many lines of source code in the archive as we do today and in the past every time we've hit crazy scaling boundaries we've been willing to step back and say okay what do we have to do to get past those the new maintainer process, putting that in place was one of those becoming more formal in the way we communicate and sort of inoculate incoming people with the virus of our core values as another one maybe it's time for us to have that conversation not to figure out how to fracture the archive but how to think about this are there ways we can package and integrate stuff that doesn't cause as many of these crazy transition hassles as we seem to have stumbled through in the last couple of release cycles I would love for a stable release to be a much faster process I'd love for there to be more automation in the promotion of packages what we have now seems really good and yet it's interesting that at the scale and at the complexity we've gotten to it still seems like our release managers go nuts massaging those you know hints files to get everything to work something that might make like a split more palatable is if we are thinking like not in terms of the core and the bits we don't care about so like the number two main university but instead the bits that make sense to freeze and the bits that move fast we've done like experiment that has no way to think of it yeah that's a good point and we've experimented with that the whole volatile thing was sort of one thought about that but we tried very hard to sort of minimize the amount of stuff that was some volatile things like virus scanner rules files and stuff like that and I think there's a fertile opportunity here for people to think about our pose and begin discussion on ways that we can change the way we do things it was really interesting sitting in Joey Hesse's talk about you know leaving Debbie in the other day I was struck by the fact that something he said other people seem to have talked about it too that somehow Debbie was sort of too big to change or that was hard to get big things to change or hard to get big changes implemented or something like that I guess I just reject that on the face because we've never been afraid to change things we just have been afraid sometimes to open the discussion about changing something because we didn't want to deal with it we just want to play more and you know maybe that's the same thing on some law we do we don't play more anymore so maybe that's the right time oh cool I unsubscribe from so many lists I don't know what they're like famously when I was running for DPL I was subscribed to all the mailing lists and everybody in the project knew that because I sent a resubscribe message to all of them to make sure I was and it went to the lists not to the lists I guess the name awareness that came from that and everybody's inboxes helped me get elected yeah ways to screw up and become DPL really good point I don't know what the answer is but that seems like an interesting way to do it we have about five minutes left so let's move and get a couple more questions I guess we should wrap up one of the things the food you hipster distributions do out there is have something that they release every day and then college rolling I think you can say that arts is a bit more extreme than that but I think maybe we should just remake and testing this really and then say this is what we've been doing for years I don't know what's the name yeah but Rose by any other name still sticks yeah but I mean essentially the thing is we've been doing the same thing as some of the more basic distributions are doing that's my point really and yes it's not that strange really well so I've tried suggesting a couple times that we could even have so multiple dynamic flavors there somewhere between unstable and a real stable release and every time I say this the archive managers cringe because even though theoretically having a package pool means that you never have sort of more than the number of versions of any given thing that are referenced from different places at one time adding another sort of list of references has the potential of increasing the size of the archive significantly and so they cringe every time I suggest this but I've wondered Andreas probably remembers we've had lots of discussions over the years about how we should be crafting flavors of Debian which have been through many different names over time custom Debian distributions whatever and I keep wondering if this is an opportunity for creating more dynamic subsets of the whole distribution where we aren't calving things on the basis of you know core versus not but more on the basis of this is what actually matters to somebody who wants to work in this particular problem to me maybe a medically oriented distribution and a ham radio maybe we could actually do Linux for hams I mean if it hadn't installed you know and Keith and I talked for a while about something we were going to call Baked Media on Keith's Excellent Desktop yeah I know with all the conversations and yeah we just never got around to it but this notion of somehow creating lighter weight subset distributions that could have dynamic more dynamic properties than a full stable release I'm not suggesting that for realsies today I'm not going to back it up with a write up or anything but those are the kinds of ways of maybe changing how we think about the process that I think we ought to all be engaging in and talking about in order to be able to scale Enrico, the name change you know propose it and we'll see the next time Enrico You mentioned long friezes what do you remember of Sarge I'm sorry You mentioned long friezes Yeah What do you remember if I remember correctly Sarge Oh my god There is a lot to remember How long did that release process take? Three years Yeah and the freeze period was like six or eight months or something No it was like over a year Over a year I think I was sufficiently distracted by other things going on my life that I did not quite get to the point of sticking a gun to my table and pulling a trigger Man It's interesting when we started talking about this idea of doing time to releases There's pros and cons One of the things we've always said is that a distinguishing feature of deviness will release when we're ready But I've also personally been one of those people for whom without the eleventh hour nothing ever gets done and there's something to be said for putting milestones in the sand and saying okay we're going to target this, we're going to target this so that you get people to coalesce their activity to all occur in sort of a finite period of time I keep wondering if there aren't yet more ways we can improve the coalescing of energy around our release time so that those processes could be shorter I don't know if that's useful or not We could also just not change as much software and the release process would be easier but who wouldn't want that I don't know I hope that this meandering through some of the early history of the project has maybe helped provide a little context about where we came from and what some folks care about I know that in the last year the loss of Ian Murdock our project founder based on conversations I've had this week that different people have been emotionally affected by that more or less as one of the people who had the opportunity to interact with him quite a bit directly via email and in person back in the early days of the project Yeah, hearing about that right at the time other things were changing in my life certainly didn't help my mood for a while but I think it's really important for us to remember that he helped sort of set us up for an immense amount of success and since he had not directly been involved in the project since, you know, sometime in 1996 the reason Debian is what it is today is because of all of us and I know because he told me a bunch of times over the years that he was immensely proud of what we had accomplished and would certainly hope we would keep figuring out how to collaborate excellently with each other to keep this Debian thing going for a long time in the future so thank you very much for your time and attention enjoy the rest of Debian