 Um, so our second session this morning about, uh, boots, uh, we'll involve James Hunt, who's been working for chemical, uh, on that start for the past, uh, three years. And also Steve Langashek, who also is working for clinical, but he's a, most of us know him for his long time commitment for the, on DBM for the past 13 years. Uh, this morning together, they're going to tell us why DBM needs to have start. Please welcome them. Yeah. Thanks very much. Thanks for the introduction. Yeah. As, as uh, Lunar mentioned, I'm Steve, many of you know me already. I've been around here and there in Debian for a few years. Vorlon. Yeah. Uh, and James Hunt is the, uh, upstream maintainer for upstart. So we've come here today to tell you about, uh, everything upstart and why we should have upstart, uh, in Debian and why we should be using upstart in Debian. We had discussions yesterday about, uh, system D and what it has to offer. And so we'd like to show you today a little bit about, um, upstart and why, why it is, uh, the thing you should use instead of system D for PID one. And with that, I'll turn it over to James for the first part. Great. Thanks, Steve. Yeah. Apologies. Uh, we've got a fortified session. I'll be talking for the first 15, given over you design and architecture and some examples of facilities that upstart is allowed. We've had to pack a lot in today. Uh, like, in fact, other speakers said for us, um, if we're talking too fast, please slow us down and have a chat afterwards. Please grab us cause there's a lot more we could be saying, but okay. Um, so what did start? It's, it's, uh, what is the mic? It's a revolutionary event based in a system. It was written by KeyBuck. It's now maintained by Canonical and developed by sales in the community. It's been PID one of every system, every bunch of systems. It's 2006. Of course it handles boot, shutdown, service supervision. Um, we also provide support for six, five jobs transparent. And of course upstart is now first in Debian. As you can see, there's no point in reading out the names here, but it runs on pretty much all the major players, all the major systems right now. Um, and the important one of course is the bottom one. It has excellent platform presence. Uh, it runs on desktop servers, embedded devices, thin clients, cloud tablets and most recently phones. Just touch on cloud for a second. I mean, upstart is the number one in its system in the cloud due to Ubuntu's dominance in that realm. And it's no point in reading out the names, but there's some examples of big companies that are using Ubuntu in the cloud and Ubuntu on service. Um, it's very important for us to point out that upstart's a very simple program. It's simple, but it's also very versatile, very flexible. Um, the, the Indian team itself really understands two concepts, only two concepts, events and processes. So it doesn't dictate run level policy. The Indian team even know what a run level is. We'll show examples of this later on. So when we talk about run levels, this is currently specific to Ubuntu and Debian. So I had a funny room yesterday, uh, just to clarify, upstart is actually written in C, not Python. Um, we attempted here to the UNIX philosophy of doing one thing and doing it well. Um, as I said, the core of upstart is simple. It does include a diva server as well, and we'll see why that is later on. Um, but we only provide methods that are sort of core to management. Additional functionality is handled by bridges. They run out of process. They enhance the facilities, the abilities of upstart. And we do that to provide resilience against system failure. We'll cover bridges in a little bit in a few slides time. The way they're handled again is very elegant, very simple, very Scott. Um, of course one of the unique selling points of upstart is the fact that it's event based. This is revolutionary. Okay. Um, again, we'll come on to that in a minute. Uh, but it's also seeing this, this bottom point here upstart makes use of the NIH library. Yes. It might, might stand for not invent here. It's a very cut down, um, safe, small library. Uh, you can, um, it was written specifically for early boot systems such as upstart. Thank you. So the core of upstart itself really, apart from the 18 is one command in a CTL. So with that, you can actually control jobs. You can query certain aspects of, uh, the jobs themselves. And, uh, thank you. Um, in it CTL itself being a D bus client that basically talks directly to in it, which runs a D bus protocol on its own endpoint. Right. The D bus interface is very well defined. I mean, you can write, you know, your own, uh, your own applications to make use of that. Um, after I had the same declarative jobs, job syntax, uh, we'll see examples out of the second. We read job files, meet, you see in it. It's a, uh, but I was common. We lost it again. We support override files, which, uh, um, media to W news. I'm sure we can actually change the behavior of a job without touching the pristine files. That's a very, very powerful facility. Um, fast system mounting. Yep. It says here it's handled by another helper. It's not a bridge per se, but it's a, it's another helper application called mount tool, um, amount, amount fast in parallel. Um, this is by design. This was not a mistake. Um, again, it's out of, it's out of the core, uh, P1 name space. Um, when mounting these file systems that happen to say in parallel, we have a very rich, uh, uh, pallet vents that are available to jobs. Um, and we've got some references to demand pages. So if you can find it a bunch of some, take a look at those. So I'll start the vent based, um, jobs, as we'll see, start very naturally. They start at the right time. They start when it's time for that particular job and all of its, uh, it's, it's, it's, it's, uh, it's, uh, it's, uh, it's, uh, it's a start conditions are satisfied. So it, it's very much, it's unlike system five where, you know, you have a sequential start to sign a number, set the order. It doesn't have complex dependency resolvers. Um, And one further point I would add there is you're probably used to thinking of sys5 in it as a thing that runs at boot time, boots the system and then gets out of the way. Well, that's okay if you have a very static system, but if you're in a dynamic environment where you have hardware that comes and goes, if you have network devices that come and go, you want something more dynamic, you want a system that will continue to understand what the state of the system should be overall throughout the life cycle of the system. So the fact that it's event-based rather than dependency-based means that it responds to events that happen anytime during the system, systems boot time and throughout the uptime of the system. So it's not just a job starts once and runs forever and that's it. It's a very expressive language where you can have jobs that come and go in response to hardware events throughout the uptime. Yeah, that kind of leads to one of Scott's favorite phrase, I think, where prived-up starters is a system where the system just keeps on booting effectively, keeps on reacting to events as they're emitted, keeps on reacting and starting and stopping jobs as appropriate. So here's a very simple job in the box here, we've got four lines, four lines of account. We specify when the job started. So here we're saying start when the D-Bus service has started. You can guess what the stop-on line is doing, stop when the system is shut down, I think we use the mode reboot. Exact line, what we've got running here, what is the service? And expect demon, well we're saying that my demon here is a real double-forking demon. So the start and stop-on conditions here are very simple. They should only be very simple. However, we do support, you know, object complexity, logical operators and that kind of thing. But overall, if you've got more than three events, because this is worth pointing out, the started event, the started there is an event, more than three events in the start and stop-on condition, you need to think quite carefully because all jobs should be simple like this. So what does that actually give you? Well, it obviously tells us how to start and stop the service. It also allows an administrator to manually, forcibly stop or start the job. What isn't shown is the fact that upstart provides automatic logging, that's all handled kind of transparently. And of course, a minimal environment is provided for each job. It's very human readable. I mean, this is upstart specific syntax, but you can guess what that's doing, right? But there's no, you know, there's no particular magic in understanding what that's saying. And of course, crucially, unlike system five, you don't have huge chunks of boiler plate LSB code. You know, you let upstart do the heavy lifting. So this is probably not going to come across very well to you guys at the back there, but this is attempting to show some of the events that are omitted when a job is started and stopped. So I'll just run through it briefly. The sort of purpley boxes here are showing the event. So when a service is starting, we omit an event called starting. And that event can be used by other people and start on starting through and you can have a job react to that. Further down, you then, you see the PID box and right here, we run the exec line. So if we go back to the example, we exec my demon, because when that demon is running, we omit the started. Because obviously, you know, we realize that state now. But again, when you stop the demon, it's a stopping event and a stopped. The other black boxes are sort of optional job processes, as they're called. So in the example we support, we're showing exec here. You can have a script. You can actually have some shell code if you like. So in fact, the standard, the keyword, is called script. So you can have a script when exec, that's known as the main process, but optionally you can have these other types of pre-start. So you can run something before the main job starts. You can do whatever you like. You can run something after the main process, post-start, and again, pre-stop, post-stop. They're all optional. In fact, even the main exec and script is optional. You can have a legitimate job that doesn't actually fork anything at all. And they're very useful. They're called abstract jobs. But we don't have time to discuss it today, unfortunately. So we mentioned early on, upstart, support, Sys5, you don't have to modify your services anyway. It reads the fast and the user location. It provides the usual set of commands, shutdown, reboot, telling it and so on. But what's really interesting about upstart is the fact that it emulates the run level. The commands will do exactly what you expect them to do. But if we just look at how that works, it's quite fascinating, I think. So to reiterate, the initDemon knows nothing about run levels. It just knows about event. So how does this work? Well, it's actually very simple. There are two jobs. There's an RC-Sys init job, and this is pretty much it in the first spot. And you can kind of guess again, it's human readable. Upstart on file system and starting network up. There's actually saying, start when all the file systems are mounted. That event file system is coming from Mountain. So basically, start when your system is in a sort of reasonable state. You've got networking, you've got writable disks and so on. And then, exec telling it, default run level 2. Okay? So telling it runs, passing a parameter 2. Telling it itself emits an event called run level. Really obvious, very natural. And then we have another job called RC, which starts on run level. This is actually a sort of map, a sort of pattern match here we can do. So this RC job will only start in, you know, recognized run levels. And what that does is it execs etz init.d RC, path and run level. So that basically is it. That allows upstart to support system 5. And it even knows nothing about it, nothing about run levels. If you want more details, look at the man page, run level 7. So bridge it. They're really cool. They're one of my favorite aspects right now. They allow you to extend upstart in whatever way you want. They run out of process. What's really cool about bridges is that they actually run as upstart jobs. So they're extending upstart and they're running as a job. Managed by upstart. So heaven forbid, but I mean, if a bridge were to crash, that's not a problem because upstart will restart it. And the whole point of a bridge is that it basically enriches the the palette of events in some way. It injects new events into the system. So unfortunately, we don't have any time to talk through all this stuff, but here's some examples of the bridges we have. So we have a Udev bridge. So all the Udev events are ejected into upstart. So you can have jobs which do crazy cool things. In fact, I think Steve's got an example of this coming up. We've got a file bridge. We can react and have jobs start on when a file is modified in a particular directory and when a debuff signal is emitted or something like that. It's very, very clever. And there's a very detailed manual page called Upstart Events which summarizes the well-known events. There's actually a lot of parity between those events and the LSB defined conditions, I guess. There's the magic LSB headers. It's worth looking at that page. But if you can't find what you want, if you want a job that reacts to some specific part of the system that's not detailed in Upstart Events, what do you do? Well, you can talk to us. We're quite approachable. We're happy to write new bridges. If you'd like to write a bridge yourself, it's not a major piece of work. Skeleton Bridge is only 300 lines of code. You can actually write a program which just makes the use of LibUpStart. Again, that will just allow you to generate events. You can just call in its CTL, Amit event. And that is in no way a second-class citizen. You can just let me write a bridge in Shell Script if you like. Just have a loop that emits. That calls in its CTL, Amit. And that's creating new events. Put them into the system. There's one event namespace. So all jobs have access to all of these events. So just briefly, we've got some utilities that Upstart provides. There's a graph as you can see. How events relate to start and stop-on conditions. Which is actually quite interesting. You look at the way this is some boots. Upstart Monitor. If I say Debuss Monitor, you'll understand it's pretty much the same thing. You can watch event flows in real-time. That's the GUI's ShitScreenshot. It runs on the console as well. And the all-important init check comp. So that'll basically syntax check your job. It'll also check the source code. The shell code isn't in there as well. So run that. Run it, check comp before deploying your job for testing. So just briefly, we're going to give you some examples of some enablements. Some of the things that Upstart's allowed due to its design really. The first one cloud in it. I think it was mentioned at the Google talk yesterday. It's written by Scott Moser of Canonical. It's a very clever application which sort of solves the problem of how do you configure a generic cloud guest? Because these guests are extremely minimal. They're a server image. Minimal package set. As it says here, initially, you can't log into them. They didn't do anything. They'll boot, and that's it. So cloud init kind of fills that space. If you imagine you wanted to deploy 100 guests, 25 web servers, 10 database backends, proxies, caches and that kind of thing, cloud init will do that for you. So it's not just doing the same boiler print setup for every single guest. Yeah, were people here for the talk? I think it was yesterday morning, James Romberger was talking about AWS and cloud init. Are people familiar with cloud init and what that enables, and have you guys seen that? So it's been kind of an issue with getting Debian enabled in Amazon on account of the fact that cloud init was written to leverage and it has been ported now into Debian. Toma Guaran has done a port of cloud init to work with sys5 init systems. Personally, I'm somewhat skeptical that it's going to provide the same functionality because cloud init very heavily leverages some of the functionality of upstart in terms of being able to interpose jobs that hook into different points in the boot sequence and stick themselves in between on arbitrary events, which to a certain degree you can do with sys5 init with LSB sequencing. I don't think it actually gives us the same flexibility that we have in upstart and cloud init, and so it'll be interesting to see how well that actually works for people in practice, but cloud init is a huge... It leverages upstart very well and really speaks to upstart strengths. Yeah, so here's an example of pretty well. It's showing you how cloud init's actually working. The box at the top shows you the main cloud init job. The way cloud init does work is it deploys a number of upstart jobs that are within the cloud init package in this cut-down guest. Those three lines are extremely important, extremely clever. Again, it's pretty readable. Start on mounted, mount.equal.slash, so this job is going to start when the root part is mounted. Task means run this as a single-shot program. It's not a demon, it's going to run an exit. That's it. What is it going to do before it exits? It's going to run the cloud init program, specifying a parameter there. Task one, mounted, is a blocking event. Upstart will not free up that event. It will not discard it until this job has finished, until this task has actually finished running. What cloud init is actually doing is it's saying, well, upstart is going to start this job very early in the boot. Cloud init is then going to set the hostname, set up SSH, talk securely to management and determine what type of guest this should be, what package set, what configuration it needs, handle installing all those packages and configuring them. Interestingly enough, one thing cloud init does is it actually out-get upgrades in early boot. Of course that could result in upstart itself being upgraded in early boot. But that's fine, because upstart supports state-for-exec, it just works. Once cloud init at the top, the job has finished, the system is now a database server. It started off as a clean slate vanilla server, the job runs, suddenly it's a database server and the boot continues. Absolutely brilliant, I think. Again, some references to man pages there to look at. Yeah, Scott Moser, have a look at the documentation on cloud init, very clever. This is very clever. Friendly recovery, okay, here it is. Friendly recovery allows even an IE user to fix their system. Some users might log in as root and delete a lot of files, whoops. So what do you do? Well, Ubuntu provides this facility, so if you select recovery from the grub boot menu, you end up being dropped into this menu. You can select an appropriate option, fsdk or fixdpackage or something. And yeah, it'll all just work. So it makes a clever use of upstart to temporarily subvert the system boot. So let's see how it does that. So the user selects recovery from the grub boot menu. That results in the init wrap the fs, starting upstart in the box at the top there, specifying this option to basically change the initial event. Normally upstart will emit the startup event, that is the first, that's the way that the system starts to boot. That one event has to be reacted to, but here we're changing it to recovery. And unsurprisingly there's a job called friendly recovery, which specifies start and recovery. So the user selects recovery from the grub menu, upstart starts, emits that event, runs the friendly recovery job, whoops, wait, which drops the user into the menu. They fix their system, they tab down to OK, pressure turn, and then what happens is at the end of the job, we run a post-stop here. The post-stop runs an xt element start-up, which as I just said is normally the way the system boots. So the overall result being, the user is dropped into the menu, they fix their system, the menu exits, now with the fixed system, and the system can boot as normal. Ah, right, this is Steve's very clever example. So I get to talk about this one. I couldn't resist putting this together in preparation for the presentation. This is actually something I've been meaning to do with my own GPG setup for a while now. And since there were some questions coming up on the mailing list just before Dev Comp about best practices for GPG, I thought this would be an opportune time to do something about that. So nowadays lots of people use, with their GPG keys, they have sub-keys, and you might put your sub-key for your daily use on your laptop or on a different machine so that you, it's always online, it's convenient for you, but it's also revocable without too much hassle. Well, then that means that you have a master key somewhere that you're putting somewhere more secure. Well, what does more secure mean? It means it's offline, but it also means it should be resilient to failure and not stealable. And so the best way to actually have your master key offline is if you do, who here has actually used GF Share? Are you familiar with this? A few people, a few people, yeah. It's a great little tool that Daniel Silverstone, I don't think he's currently active in Debian, but he, at one time, was a Debian developer, which he wrote which allows you to take, you know, an arbitrary piece of data and split it into, well, split it into different pieces, any one of which or any, you can split it into M pieces, requiring N of them to reconstitute the thing, and if you have N minus one piece, it gives you no information. So, I mean, the math behind this is actually fairly simple, but I won't go into that here, but what I really want is, okay, I have a master key, I want to split it into, say, three parts. I put one part in escrow, somewhere safe that I don't touch, but there's a backup in case I have a hardware failure in one of the other pieces. I put one on my laptop and I put one on a USB key, so that when I need to reconstitute it, I just plug my USB key into my laptop and reconstitute it there. Well, I don't want to have to reconstitute it by hand because that's just annoying. So here, for example, is a simple upstart job which leverages the fact that this is currently Ubuntu specific. Ubuntu in 13.10 is using upstart, not just for managing the system, but also managing user sessions. The graphical login in Ubuntu 13.10 upstart runs as a user session manager. Starts all the related processes instead of using GNOME session and running .desktop files. It makes use of the fact that upstart has its process supervision and everything to run through the jobs, start them in the correct order, and also ensure that they shut down correctly when the session ends. So that's actually one of the things we saw certainly with GNOME session is sometimes jobs and I think system D has dealt with this problem in a similar way. So you guys use C groups to make sure that processes don't escape the end of the session. In this case, we're not using C groups. It hasn't been necessary for the things we're trying to accomplish, but just the fact that we have process supervision means we're successfully capturing things and shutting them down at the end of the session that weren't being shut down before. But it also means that you can easily extend the behavior of your user session by keying on hardware level events because using upstart in the user session means you have basically the same view of system events all the way through the stack from the kernel to Udev to the system upstart to the user upstart. So for example here, we have a job which starts on colensys block-device added, which is just the upstart translation of the event equals, what is it, event equals add, et cetera, et cetera, that you would see if you were running a data monitor or something. And we pattern match and say, well, look for the first partition that shows up on the device that has the serial number because I want to specify to only do this when my particular USB stick is installed and then we want it to go ahead and combine things. Now, this is not ideal here. This one, you know, we have a timeout in here. I'm saying wait five seconds because we're not getting events for Udisk. When Udisk mounts the device in the user session, we're not getting any events off of that. So we get the Udub event, but we don't actually get anything telling us that the file system is mounted. So that's not ideal, but in terms of implementation difficulty, it's not too shabby. And so we just have this here that, you know, call gf combine with targeting, this is xdg runtime dir, which is, if you're using upstart in the user session, upstart respects the xdg spec to ensure that that's a a user-only writeable share on basically a RAM disk, so it's not persistent across boots. So that's safe for us to write this kind of data to without it getting written to disk. I mean, it may be swapped out, but for the most part this is safe, safer than writing it out to a disk somewhere and having to worry about deleting it later. So this shows this is an example of a job that has a pre-start script, a post-stop script, and no main exec line in between. So the job is considered running with no process associated with it once the pre-start script has completed, and then this job is running and upstart keeps track of that, so when it gets the event that triggers the stop, which is you pull the USB stick out, it goes ahead and runs the post-stop script to make sure it cleans up your data automatically for you. It's a clean little way to it's a nice little trick for managing GBG keys, so I figured I'd show this here. And the key thing here, you can key on any UDIV event at all, any attributes of the event that's all exposed, the upstart monitor helper, which James showed earlier, it's a nice GUI that you can just run it and see what events come through, plug your USB stick in for a test, see what events happen, copy paste from the GUI and build some upstart jobs around whichever events you want to. Great, thanks Steve. So just to finish up my section, the enablements we've covered really are allowed, they're facilitated by the fact that upstart allows any job to hook into any part of the boot process. Just think about that. Whatever your use case is, this will do it for you. But also the fact that we have blocking events. This is all documented in the man pages, so we can pause, essentially pause an event. And finally, friendly recovery makes use of the fact that you can essentially subvert the system boot temporarily. As long as the start-up event is emitted at some point, your system's good. So friendly recovery switches to a recovery path, does its recovery, and then switches back to the main boot path. And yeah, as we've got the last point here, the fact that with 13.10, you can make use of upstart running as a user as well. And as Steve's example showed, you get the CIS, Coding CIS column prefix. So you can write a job which makes use of system level events. That's kind of namespace stuff, so you can have your own events as well, of course, your level. You can react to any system level event you'd have identified, whatever you want. And with that, I'll pass over to Steve. Follow-up comment on the GPG job that I showed there. Of course, I say that this is something that I wrote just in preparation for this talk. Interesting story. In the process of that, I had previously been keeping my master key on a USB stick. Which when I went to go prepare this talk, I found that the media had degraded. So I only just managed to recover my master key off of that media and implement this for it just in time for the talk. So this is a good idea to do this. Don't just keep your master GPG key on a USB stick and expect the media will last forever. Apparently the lifespan of some of these is, you know, six years or so. So we've shown you a little bit of the architecture of Upstart and some of its features. So it's an unexpected event. I'm not handling that. I have no jobs to start on that. So we've looked at the architecture of Upstart, shown some of its features, some of what makes it distinct from other internet systems, but really the question we want to address here is why should Debian use Upstart? What is it about? Why is Upstart the right system for Debian? So the first point is that your system is in fact event based. Whether you like it or not, this is how the kernel has been working for the past decade. This is how Udev works. Any system that runs Udev is an event based system. There are events related to hardware. There are events related to network changes. All of this is event based. And so what Upstart does is it provides a system that's low impedance with respect to how the underlying kernel and Udev architecture works. It provides an internet system that works along with that and provides a consistent view all the way up the stack. Even in the case of Upstart user it's all the way up to the user session where users can write jobs without any privileges and react to hardware events. So it's symmetric. The Linux kernel is event based. Udev is event based. D-Bus, anything that happens on D-Bus, these are events. We live in an event based universe and this is the internet system for an event based universe. Furthermore it's the IS. It's simple. It doesn't require a dependency solver like dependency based systems. It means that there is obviously complexity in the system. We move that complexity out of PID 1. We're not doing dependency resolution in PID 1. Granted, so for Sys5 the dependency resolution doesn't happen in PID 1 either. You have Startpar and Insert for Sys5 and it is an overlay that provides that functionality. I mean that we provide an awful lot of power in PID 1 without having to have a whole lot of complexity. Upstart just deals with events and it deals with processes and there's some nice features around that regarding how you start the processes and truiting, set UID limits, those kinds of things but it's managing processes, handling events and that's it. So any complexity about building up chains of events allows you to write jobs that key on events. It's also reliable. Mountall, there was I believe we have a philosophical disagreement with the system D developers regarding whether Mountall was a hack. I did have a look at system D's source code and I do see there are references to FS check in the system D PID 1 source code. So the fact that FS check is handled somewhat specially and in the case of Upstart happens to be handled out of process. It's a design decision but in terms of what Mountall gives you it's a lot of power that manages to successfully handle all kinds of boot scenarios. We have correct implementations for LVM, crypt setup software raid NFS is handled fine was tricky to get right, I'll be honest but it is implemented and that code is available and tested today in Ubuntu. Jobs can react immediately they will block the boot. When we say to block the boot, one of the things is Mountall will mount file systems in parallel we are running over time so I'm just going to actually speed this along here so we can take some questions at the end. So Mountall will block emitting general file system events. So like there's an event that Mountall emits which is local file systems and file system and virtual file systems and a few other things like that, remote file systems which are events that say yes I'm done mounting the local file system and those events don't happen until anything that keys on a mounted event is finished. But the other nice thing is that you can trigger on mounting. So one of the things like I mentioned NFS specifically, one of the problems is getting all of the RPC related services to start up in the right order and also to start up quickly so you're not waiting around. So if your network happens to be racing your file system and the network comes up and something says I've got a network let's go ahead and get all the network file systems and you don't have your RPC services ready to go and you're trying to mount NFS on boot everything falls over and a heap was as five in it. In fact there's some lovely hacks in the NFS common package in Debian right now which I just learned don't work with Startpar because Startpar outsmarts the NFS common package and so it's not actually doing what it's meant to do. Mountall avoids all that and makes sure that we run everything once in the right order and you know flexibility so you can stick another job in in front, behind, whatever wherever it might go but you know that talks in general terms about why we think Upstart's design is good. I also wanted to point out specifically this solves real problems including some very long standing problems in Debian. There are some very old bugs that we have never dealt with. We keep papering on layer after layer of work arounds and if you've ever actually looked under the hood at things like etsynetworkifup.d some of the crazy stuff that's in there etsyrcs.d the stuff that's in these directories that's papering over race conditions that's dealing with restarting things it's really quite messy and Upstart lets us get away from all of that gets a simple system that does the right thing once instead of having races including races that have gone unsolved for years. You know here's a few examples that we have here I have a few more here for instance apparently Upstart improves Debian's compatibility with token ring interfaces so it's not just about new hardware it's about old hardware too you got rid of token ring in the kernel didn't you so regardless the point is this is not a new problem it's not a problem that's specific to futuristic corner cases this solves a lot of problems we've had for a lot of time and solves them in an elegant fashion this one in particular how we start network interfaces on boot up is a real ongoing problem here's a bug that's been open for seven years last touched four years ago and this is a problem that using sys5init is not getting solved Upstart solves it this is a non-issue whatsoever with Upstart couple more can't un-mount file systems cleanly getting the ordering right wrong on shutdown where we're trying to un-mount file systems network file systems after we've already turned out the network doesn't work so well with some of our network file systems that's a problem that Upstart solves not I wouldn't say that it's solved inherently it's just that Upstart gets the ordering right in a way that has been difficult to do with sys5init and I even found while I was trolling the BTS there was an example of yeah system debugs so system de-implementation still has some issues in Debian LVM Crypt boot hangs so but also I mean Upstart shares Debian values the principle of doing one thing and doing it well is core to the design of Upstart we only put in PID1 what has to be there and we always support upgrades we will not implement features in Upstart we will not make Upstart depend on features that are not available in the previous kernel for the previous release we are very conservative about extending features we want to make sure that upgrades continue to work they are important to Ubuntu just as they are to Debian and this is a guarantee we will make it also is coming from a Debian and Ubuntu mindset it's handling of configuration files is actually very natural for Debian and so we have the config files themselves are editable and so you can use traditional comp file handling there if you need to but it also supports this override mechanism where you can support user configuration in a separate file and an overlay and we've had some philosophical discussions on DebianDevel about which one you actually want to do in all cases because sometimes if you have an overlay that means you have a silent conflict that you've not dealt with at upgrade time but the functionality is there the capability is there where you can do that both ways and it's proven technology it's used in millions of systems already it's been shipped in the long term support releases for Ubuntu the the first one was in sys5 compact mode the second one had some bugs that managed to make it into the LTS and so upstart kind of had that reputation for being new code that was not quite battle hardened but we've shipped Ubuntu 1204 now and in 1204 the kinks have been worked out this is proven technology there's no question about whether this is going to meet the needs of anybody who's running Debian to use this as a system it will handle all the corner cases just fine so other than that we have some links up here which we are now short on time the slides will be posted on the penta they're not posted yet but we are down to less than five minutes so I think that's time for questions so just one thing is one thing I want to comment on is your example with the the G key on the USB key you're hooking into the wrong event there you're not hooking into the mount event you hook into the device event and then you have to sleep 5 that's a bit of an indication that you're not doing things right because you have all these sleep 5s it doesn't indicate we're not doing things right it indicates you discus isn't doing things right because that's not talking down to start so if you look at what systemd does in that area it's too totally sufficient to just there's an event generated in systemd for the mounting and you can just snip it into the dot mount whatever your mount is called dot once a directory and then it's executed as soon as it happens but the mounting is not handled by by upstart in this case because we're using udisks which is upstream free desktop technology and udisks is not talking to us that's a nice thing so you would argue the init system should synthesize events in response to udisk taking the action no systemd doesn't know nothing about udisk you talk about all the event stuff but you don't actually generate those events because you get a kernel event if you mount the stuff so you should be hooking into that if you look at it from the other way you have this mount-all thing that we already talked about yesterday the problem about mount-all is that it only runs at boot time that is a problem so the event system the actual event system of upstart is not useful for either the native stuff like the best case I'll freely acknowledge the limitations of the example that I have there I think there's more work to be done regarding the event system especially relating to mounting events and mount handling throughout the system mount-all you're right it is currently a one-time at-boot solution so anything that gets mounted later it's not currently handed through mount-all and so there is a disconnect there where we do not have a consistent vision so I think I'd like to you know, system D had their promo talk yesterday this is upstart's promo talk so I think there are other things that I want to talk about the most significant obstacle it seems to me from a Debian point of view is the contributor agreement I notice you didn't mention that at all is there any possibility of movement on that because that's going to be a big problem for Debian there are many people here always about the licenses with you Ian what is it with Debian and licenses? I don't understand you bloody well ought to sorry? you bloody well ought to by now I didn't see you on Debian legal helping out that's not the place that decisions get made isn't no, so to make sure everybody understands the status of upstart Canonical has a policy requiring a contributor license agreement which is not the same thing as copyright assignment but we do require in terms of upstream contributions anything that's going to be contributed upstream to upstart does have to be granted that a contributor license agreement has to be signed giving Canonical as the copyright holder of the overall work the right to for instance re-license you know, it provides for certain capabilities of making sure they can deal with any litigation that may come up and various other aspects it's not something that is actually negotiable in terms of whether upstart as an upstream is going to change that license agreement this is not actually altogether different from lots of other projects that Debian ships of course we can compare and contrast with the FSF's position particularly in that FSF is of course a non-profit software where as Canonical is a corporation and so I know I recognize that people are not necessarily okay with this but I will point out there's lots of other people in the ecosystem doing this sorry but we are running out of time so I suggest we continue this question in the hallway try the FSF's contributor agreement the copyright license the FSF legally bindingly promise not to take anything that you sign over to them in that way non-free Canonical specifically intend to be able to do that we've heard Mark Shuffleworth tell us that that's the purpose and that this is a thing that you know companies like Canonical should be allowed to do so I think he was speaking in a general philosophical sense that the CLA that companies that it is something that companies should be allowed to do well it's a thing that the Canonical contributor agreement allows Canonical to do and when Mark who is in charge of Canonical tells us he thinks companies should be allowed to do it when the FSF tell us not only do they not think it's a good idea they also promise in a legally binding way not to so that's a very clear distinction okay so submit your patches for upstart don't sign the CLA and we'll see what happens well well submit them to the Debian maintainer so we are out of time thanks please thank please thanks Steve and James for their presentation and we'll continue the discussion later I'm pretty sure of it