 quarter foot UDS. One of the, I'm going to start at the beginning actually. It's probably a good place to start. So, for a while now, A bun two has obviously derived from Debian, but we have a tendency to do some of our own projects either for commercial reasons or for technology reasons. And one of the projects we've been working on for quite a while, is sorting out boot. We're trying to do a Linux distribution that's actually usable by the majority of masses who do just think they have to reboot something to get it to work again. We're obviously dealing with the fact that I know that when I boot my computer that plugging things in and unplugging things in is not a general idea. My mother doesn't, in fact my mother's usual approach to booting is half way through the boot, pulling out everything that's connected to the computer booting is halfway through the boot, pulling out everything that's connected to the computer just in case it causes it to go wrong. This didn't work on Ubuntu for some reason. And also the commercial reasons right now, netbooks, tablets and little tiny computers are kind of the fashion and if they take a minute to boot, you may as well just go up and use the desktop or go up and use the laptop. So fast booting is kind of important. So we've had very much sort of a project to take and look at this boot problem and solve a lot of the problems. At the same time, we've been dealing with the Linux 2.6 kernel. When we started Ubuntu six years ago, we actually made a very early decision at that time that the Linux 2.6 kernel was going to be the best kernel for us to base our distribution off. At the time it was just starting to get support for hotplug, which later became Udev and how and all that. It's the idea that you can actually plug a camera in and it appears on the desktop and you can drag your photos from it and you can unplug your camera and plug another one in. The hotplug stuff, which didn't even exist five, six years ago, just ten years ago, was now coming to be important. And at the time everyone else was still on 2.4, I think we were on the first to go 2.6. So we've also been dealing with the distribution where previously we could make assumptions about the computer. The kernel had drivers compiled into it or it didn't. Everything was a module it wasn't. You'd have an Etsy modules file to load up the necessary modules on boot. You may have had a script that tried to figure it out by the old fashion way, but generally it was all hard coded in those days. In some ways we were starting from Debian, in other ways we were starting from scratch, because the great thing about Debian is there's so many packages to choose from, you get to choose which ones you're actually going to put into a smaller CD distribution. So we very much had to choose some of this stuff from scratch. So we very much chose to go the hotplug router, which became Udev later on, which is this kind of modern Linux system sort of approach we have today. So these kind of projects have been ongoing. I mean I was, when I started at Ubuntu, I was the d-package maintainer here at Debian, and I was doing sort of package management stuff for about six, nine months, and then sort of got involved with the boot stuff back in, it was like October, November 2004, so very early on and we sort of ported Ubuntu over to using Udev and all this kind of stuff. And we kind of started there and have been building up on that ever since. So with all these projects kind of going on, and with all of these kind of little bits, we've ended up with a situation where we took a look at, right, this is how everything boots. You know, your computer boots up, you get your BIOS, your kernel, you're in it, RemFS, whatever, and then your init system comes up, and in sys5 init, that starts a, it works at about 10, 11,000 lines of shell script. I actually overheard somebody the day before yesterday into the hack lab looking at Debian's boot system for the same reason, and they came up with 10, 11,000 lines of shell script. And, you know, you're running all this stuff just to boot the system, there's a dependency and ordering system written in shell on top of this, or nowadays at least in servers written in C. And, you know, basically you're going to have this, you've got this very, very complex system to bring up a system, which you would think, because of its complexity and number of lines of code, is bulletproof. And it actually kind of turns out it's not. And it turns out, you know, let me take the most simplest example I can come up with, because it's a real world example, and we have to deal with it, is that, you know, removable hard drives, USB hard drives, we all kind of have them to put, you know, storage on. I know my sister has one and she's got episodes of the OC and anything else, really, that kind of, I think, Elkharnet, you know. Everyone has these removable drives. So, you know, you've got your removable drive, you can put it in your FS tab, or, you know, use your little GUI configuration tool to make sure it's on the file system somewhere, and you boot. And you've forgotten to plug in this USB enclosure. And, well, it turns out that kind of that doesn't always work and you end up with a, you know, sometimes everything after it in FS tab doesn't come up, sometimes it doesn't come it mounted, and sometimes the boot just sort of hangs for a little while and then carries on. Worse still, you know, that's just an example if it's a data drive, if it's an external drive or even just a separate drive, like a RAID or an LVM device, which is your slash user partition or your slash bar partition, and that takes longer than usual to come up, you know. The array it's on might take longer than usual to spin up. You may have turned on your laptop or your desktop and forgotten to switch on the enclosure so lean over and switch it on and just time it out differently. You can end up with all sorts of things falling over and collapsing on top of each other repercussions. And that's also true of networking and everything else. So we knew we had this Udev system, we knew we had events from the kernel when devices came up. We knew that we wanted to sort of pare down the boot system to be run just what we need to run, not everything else. And we knew that if, you know, it allows us to remove race conditions because we know when things are available, we know when a network device is there, we know when a hard drive is there, so we can take action on that, we can synchronize these things together. And that's pretty much where app start came from. We started it in 2006, so it's quite a long time ago now and been steadily kind of plodding away at it ever since. And it's an init system, it replaces the sys5 init package in Ubuntu, but Ubuntu we don't have, we don't build sys5 init's binary package now, we still build init scripts from it. There's a couple of bits in the source package we disable, but we certainly disable building of init from sys5 init source package. The init, the spin init binary comes from the app start package in Ubuntu and we are able to then build up a completely different boot system. So it's been very much a slow gradual process. We didn't start out with a flag day. We didn't say, right, today we're going to boot with upstart and everything must be converted over. And this was quite deliberate. We started off with a super set of sys5 init functionality. So sys5 init has these init scripts and everything else, but that's actually sys5rc, we can ignore those for now. Sys5 init itself just has that init tab configuration file. And there's only a very limited amount of stuff you can do in that init tab configuration file. So it turned out it was really easy to write upstart jobs to do exactly the same things as that init tab configuration file and encapsulate in its own internal logic put towards run levels in just a little bit of code. So what we did was we replaced the init demon, wrote a couple of jobs and some support utilities, like shutdown and telling it and so on, to sit along with the init demon and provide run level support and make sure Wtmp and Utmp are updated and all that kind of fun jazz. And then based on those, you can then run the sys5rc scripts, which in Debian would be in-serve, in Ubuntu we're still using sys5rc. And that still allows you to then replace the init demon while still booting exactly as you did before. But at least now you've got the ability to move on and experiment with the new init system and say, right, okay, well, we're booting with the old stuff, that all still works. And then we run bits over to the new stuff. And over the... Sorry, that's my throat. Over the last year or so, we've been very much attacking this. And in fact Ubuntu now is out of the box, probably three quarters upstart now and only about a quarter init, sys5rc init, sounds about right. So we've gradually been able to convert over our boot system to this new system. So that's kind of a little bit of history and tour on sys5rc init. And that's why we wrote upstart. Now, obviously, so I said I was talking to Zach at UDS. Now, for us, this is quite a major piece of work that we've done for Ubuntu. And we've very much convinced we've got a right approach here. And it's something that, obviously, it's a big delta for us from Debian. We've replaced the init system. That means anything with an init script is ultimately likely to be replaced, or at least forked, or not forked, branched. It's the right word I'm looking for in Ubuntu. We're going to have to, at some point, take every single package that's got an init script. We're going to have to modify that to use upstart, which is going to build a huge branch between Ubuntu, a huge delta between Ubuntu and Debian. And we like collaborating with Debian. And we like being able to get all of our upstream changes in Debian. It's great. It means we don't have to go about them again. Maintaining patches and merging them every six months is a pain in the ass. And also it's nice to do this kind of thing and get things back into Debian. And this is something where we would like to get this back into Debian. We would like Debian to adopt upstart and be able to collaborate with you. So please just shout out, because I do want to talk with this. There are mics here. I do want everyone to shout out. I don't want to go above the media's talking. So I have a kind of narrow interest. I kind of like upstart. I would love to be able to use it. I am also interested in AC Linux and security in general. And even though I have had a hair test with Debian for the last six months and AC Linux, I have had a hair test. I got a new job and things take time. However, I think I'm going to be able to come back to Debian in a short order. And I would like to at least create maybe a KVM image where people can run out of the box strict policy and running Debian and be able to run a really secure system. One of the concerns in something like that for people who actually want to run strict policy as opposed to the old targeted policy only part of the system is secured is you want to minimise the amount of code that actually runs or that is variable. One of the things that is anathema is an IT ID. If you really want a secure system you turn off modules, you build everything into your kernel and you make sure that nothing else loads because that way there are fewer chances of a bad guy adding a module. The other thing is you don't want to divert in it away in order to provide the wrapper around abstract. So the system in it has been running a patch for over 607 years now I think or longer where in early boat it goes and loads the security policy. It's a small patch about 50 lines or so or there about when I wrote it and there is a similar patch for upside. So the complexity of the patch isn't high but it does add LibSE Linux 1 as a dependency and the more code you add to an script I can understand that there is some concern about whether that leads to it becoming unstable or source of bugs. However, since I added the patch to 6V in it I think it was 2003 or 2004 so it's been about at least 6 years. I have never had a bug report that LibSE Linux caused any problem with a deep package bar in it. So it's a mature library, it's minimalistic, it's been looked over by some very smart people smarter than me who deal with systems running in three-letter agencies in the United States where you can't have your machine go down while you're halfway over Afghanistan for example. So I paused it that the risk introduced by LibSE Linux which is transitively essential in Debian is going to be minimal. However, there has been very little movement on the patch that I submitted to Upstart. So can I just get the projector on as well? I just want to demo some things on the projector while I'm doing it. Okay, so, yeah. I see a Linux in Upstart where I can just summarise for you there's two things for where do I see a Linux in Upstart. So Upstart, the upstream project doesn't have support directly for SE Linux because no one's actually submitted it. I know you've said you've submitted it but when I was talking about this it developed a few weeks ago actually looked into it and you submitted it to the Debian so the Debian maintainer has never submitted that patch to me. And there was a discussion way back when we started about SE Linux support in Upstart and my response was pretty much yeah, please. So in Ubuntu we use app armour and that means that and I tell you what I do not care about app armour either. At your leisure I've just written my hand for a mic. Yeah. Michael Bebalon IRC says please let Manoj know that Upstart in Debian has been shipping this patch for the past two months. Right, yeah, so I was just going to come to that. Hi Michael. Sorry, I've been out of touch with Debian for six months so I didn't know. I want to do two things, I want to talk about it. What do you mean era of Michael has submitted it to you? He has now. Okay, the other thing I might add LSMs there was some discussion way back when about choosing one particular security model. So ever since LSM came about there have been three LSMs that have been accepted is SE Linux, Tomio and app armour. Out of this exactly one which is SE Linux needs a patch to the init system to bring up. Now actually I was just going to talk about app armour as well. So app armour we actually do do some stuff with upstart and app armour where upstart's model allows you to say have a service and it allows another job or a service to hook into that service being started. So we use this for app armour to apply the app armour policy for that service before it comes up and we're able to do that in the app armour model because app armour is all about load of configuration for our cat into the kernel. So app armour has been relatively low touch for me. So I take that care about it. The security team would have been too care about app armour and apparently my laptop doesn't care about projectors anymore and I've not been able to worry about it. SE Linux I understand needs to be a little bit more to worry about it. Oh you had it for a second? Yeah I know. Maybe if you want to check on the table. It should work now. There we go. I have to sometimes reboot this laptop. It's Maverick's ex-server. Hang on. So I want to talk about one thing. So I know with SE Linux we're going to have we need a patch to the init system that loads the default system policy then reexacts the init daemon to make sure that it takes effect for the init daemon. That's the patch Michael's got and I have no upstream concerns with that patch. I'd like to include that upstream. I've gone back to Russell Coker. Unfortunately we have a copyright assignment policy so I've gone back to Russell Sopers to install to make sure we've actually got the permission to include it in source code and all this kind of stuff. So that long track. I know it's in the daemon package now. So daemon should be free to use SE Linux with upstart in that manner. The other thing with that pharma we're doing is flexible policy loading in hook. With SE Linux my understanding is that needs to be a little bit more in code. So actually I just wanted to show one difference. One thing you talked about was the amount of code that you have to debug. So if I bring up the debus package here we can look at the debus init script. Let me get out of the way. So this is the init script to start the debus daemon which is a very simple daemon. It's a modern daemon. It's written for a bunch of things that just does everything the right way. It forks off into the background and this is the init script for it. There's a lot of code there. There's a lot of stuff that you're going to have to audit with SE Linux. There's a lot of stuff you're going to have to care about. There's a lot of stuff you're going to have to worry about what Starstop daemon does if an update Starstop daemon does something that opens a different file in proc. You're going to have to care about it for SE Linux. All of this stuff it makes it complicated for you to audit in SE Linux. We don't use this in its script. We're an upstart system. We have an etc init debus.com which is fit actually in one terminal. That is exactly the same thing. We always talk about this idea that we know 10,000 lines of init you can't take a thousand line init script and get rid of all that code. Actually we didn't. That is still doing exactly the same thing as the init script. The difference is the actual bringing up the process putting it in the right environment adding limit resource limits and stuff like that can be handled by the init daemon in Upstart. The Upstart job format is not a description of how to start a service and how to stop a service. It's a description instead of what to start and what to keep running. From a SE Linux point of view should make it much easier to audit. The other thing I actually when I write that way at the beginning when someone came to me about SE Linux apparently I could have be more than done that way around. Doesn't really move it. Okay. Right back when we started this I actually said I'd love to do SE Linux and I'd like to make sure it's done right as well. So for example it occurred to me that the Upstart code to start a job it occurred to me that you could do have some sort of SE Linux code in there as well so it allows you to be flexible in defining the job more policy restrictions and so on. I don't know whether that's appropriate or not but someone who knows about SE Linux should certainly have a look and see whether there's more useful stuff and be done there. So I guess that kind of answers your question in that sense of I'd like someone to do SE Linux in Upstart. With Upstart being different we as I said I would be happy to work with you to figure out additional things that we can put in there. Policy loading is just one of the things that we can do and policy loading unfortunately does have to go in early into the kernel before you do anything else because unfortunately you can't run any of these scripts before policy is loaded because by default it will be denied if you are running strict policy. So you do need to load policy early but there are all kinds of other things that so far we haven't done because it is not easy I don't want to write init scripts for every single package that I think can benefit but this might be something that I can do but this seems a lot simpler and I would be happy to work with folks in Ubuntu because I think you guys might be doing things slightly differently at this point than Debian does. Yeah we do, we use APRMA but I mean another way of looking at it would be I'm from an upstream point of view of Upstart I'm quite happy to support APRMA and AC Linux It should be the choice of the user and anything that we do in AC Linux makes it totally optional if you don't want AC Linux it has less than what was it like one ninth of one percent overhead at startup and nothing afterwards Okay cool thank you I just wanted to well I think the good occasion of this buff is actually looking at the upstart issue from a higher point of view so I think the main question is are there any specific and substantial technical objection of having upstart in Debian so I know there are some I know we cannot answer in this room but this is a good start and then I think the way forward is posing the same question in the upstart place like developed I'll let Steve answer that one Yes Okay I'll go ahead and proxy the main concern that I know with upstart and the reason why when we talked about this with Petter last summer things haven't moved forward since then it's because as soon as we drop upstart into Debian as the default in its system on the Linux ports our FreeBSD port which is a release architecture for this cycle is in a world of hurt because once these facilities are available even if you give them a policy mandate not to people are going to be eagerly converting to the much simpler system and then packages are just not going to work on FreeBSD anymore so that's a significant problem that we need to resolve this incompatibility between upstart and FreeBSD in some fashion So okay, are there plans to actually how to attack this kind of problem? So it actually comes directly to the question that I was going to ask which is that I have a whole bunch of packages that have init scripts and I would love to provide upstart scripts for people who are using upstart is there any way that but one of the problems that I'm running into right now is I don't know I haven't been able to figure out some way where I can ship an upstart script for people using upstart using the init system and that seems like that would also partly address that problem because if we require every package you have both, the upstart script can do anything exciting and fancy that it wants to do and the init script is still there you know over time we may get the BSD folks may still be somewhat unhappy because fewer people will be testing the init script but at least they're not completely screwed We kind of ruled out that particular migration path We ruled it out in the bin too Well we ruled it out as well for Debian Well first of all because the migration path involves continuing to run sysfi init scripts on a transitional basis where upstart will call into RC I'm happy to add something to the beginning of my init script that says if I am actually already run under upstart go away Yeah that makes sense What would it take to port upstart to other channels? I have no idea I'm just going to be pretty open here So why is upstart a problem for free BSD? The simple reason is when you go and write an init system you start looking at it becomes bonded to the kernel You can write a really simple init system which isn't bonded to the kernel but as soon as you want to do one thing it's actually on the screen So upstart exact debus demon system fork so that forks off into the background and everything else So debus forks, it actually forks twice because it's a demon status debus and it's still got the right PID so it's doing tracking of the PID even after forks and execs and upstart uses that information all the time So that I only know how to write for Linux Upstart also has a rich event sources, the idea that's event based in its system means you kind of want to be able to do things when events happen when drives appear and drives disappear and hit network cars appear and disappear So what would it take to someone to port upstart to FreeBSD it needs to be a FreeBSD developer who knows the FreeBSD kernel well enough to be able to do these kind of functionality in a FreeBSD kernel That's kind of the problem I would say that as Ross said if we can have a way to have both that can motivate people from the FreeBSD site to actually do the port more than it's motivating now to do that I mean if it's not used anywhere people just don't care Yeah, I mean one thing to consider is that we have this so right now in Ubuntu we're doing it differently we've transitioned from init scripts to upstart scripts and only the upstart scripts go into the binary package and a sim link gets dropped so people to learn the difference but that's because we don't support switching init systems in Ubuntu but Debian for example is one of the realities we've mooted The first one is that as Steve said, the one that's kind of simplest is probably as you say, ship both and in the init script just don't run if the upstart's running and that would be really easy to do I can think of about 20 different ways to tell whether the init system is actually upstart or not and that's probably easiest one is just do that if it's not running upstart so that will turn an error I was just going to say that the OpenSSH packages in Ubuntu ship both upstart and init scripts and that's because so for most things it's not too important but people very often run SSHD in a true route for one reason or another and upstart can't yet supervise that so I ship the init script just so that it's not posing people who are running in a true route and you could it's kind of slightly awkward at the dev helper level right now but it's not too bad that would also solve that problem for Debian temporarily I think in practice in Debian the only way we would ever get upstart in Debian is if there was the ability to switch back and forth we ran into that with in-serve we're not going to be able to do a transition we're going to have to support multiple init systems for some period of time and then hopefully people will converge but what I thought about was this idea of having a support library or support binary which could run could read an upstart job and basically do it as if it was init script but a year later no one's actually been able to write this thing it turns out to be really hard I'm not sure how much effort has actually been put into that between myself and Michael several weeks I've had a go at it and I didn't manage to get it to work either you can't get it to start the processes again upstart relies on being init to find where the process is synthesising PID files I assumed all along you were going to synthesise PID files for this you don't know what the PID is if it forks you lose the PID exactly and then you may as well just use the init script but you don't want to use an init script because then you can't migrate maybe that's the right way to do this maybe the right way to do this is instead to say we can transition the upstart we can have to transition the has been init binary to upstart tomorrow in Debian very easily and we'll continue to run everything exactly as it does today and then allow packages to ship both disabling the init script if upstarts the sys5 init it's the init daemon and that would allow you to switch backwards and forwards you could install sys5 init reboot and still come up with the init script so you could put upstart and reboot come up with the mixed job format we have today it would allow you true routes to work if you did that clause properly so I can't really see any downsides here at the moment so regarding the somebody said we can have policy mandates or move it to Steve we can have policy mandates all we like but people will upload things we do have auto-rejects on certain lintian tags and I and if we wanted to say we'll ship the init daemon as long as nothing dies on it alone then we could have a lintian tag that's auto-rejected by FTP master don't we already have a policy must directive thing that if you want to do something init you've got to run provided sys5 init all we need to do is said that if you also want to support a style this is recommended optional not recommended now I wish you'd change it back I mean, yeah in practice we do because the init tab init tab is a configuration file which is owned by a different package so you don't get to go modify it so if you want something to happen during boot you have to do that the first step for me would be before we went down this path we'd write a policy we'd add something to policy that says if you ship an upstart job you must also ship an init script because you're not running and if upstart is running it's kind of up to you because you might want to do what Colin's doing with ssh but for the most part you want to not run and then you may also have later on you may decide that for example linux systems like udev and stuff could just choose not to ship an init script later on but that would be a later on I think what Russ said we don't actually need to change policy we already have something that says we want to run something in it init script and it has to be you invoke something about run so what the couple people said here is we could stand to be more explicit I suspect that policy because it was never anticipated the idea that you would not have a sys5 init system probably doesn't ever somewhere explicitly say you must use the sys5 init system the same way it doesn't explicitly say you must use RM to remove files it was written with that assumption so curiously it does seem to say the etc init directory contains the scripts executed by init at boot time so technically it's a policy violation for upstart to run jobs out of etsy init so yes in fact I think we need to make somehow explicit that there is technical agreement that we want to support also upstart in IBM so it seems that there is this kind of agreement in this room we need to check if there is this agreement also the fact that policy people agree with that is a very good start of course so having it written explicitly in the policy that it is supported and what you need to do to use it it's kind of needed I think so I'm taking notes for the session I have a gobby document open on gobby.debian.net and I'm recording everything I'm not going to file the book right just yet is it possible to have a reliable lintian error about this that we can auto reject on? yeah if the package ships something in etsy init well yeah I think that if it includes an upstart job and doesn't include an init script then there are some cases where you might want to override that lintian override an upstart package I was going to say can auto rejected tags be overridden so upstart itself then that one needs to do that rise in this particular case lintian should have whitelist upstart because I don't like having the obvious candidates have to write overrides but yeah there's two classes of FTP master reject tags one of which can be overridden and one of which can't and for this purpose I think there's enough reasons why you might possibly want to override in weird cases where the upstart job is doing something that's unessential for an init script system that it should go into the overridable section I just wanted to make a plea from the user perspective sysadmin perspective I mean I live and die by these init scripts a lot of times sysadmin is writing their own so if for squeeze plus one or whenever this is going to happen this is really the way Debian is going to go it'd be nice if basically it were all or nothing from a sysadmin perspective so they're not yeah I mean the all or nothing is kind of complicated it's a lot of work but I mean the Debian let me be nice the Debian release timescale is such that we could use a Debian release cycle partnered with Ubuntu to do the migration I mean we can if that's important to Debian to migrate you know if not all but majority or whatever then we can work with Debian to do that I mean we've got a plan so one thing that's been done in Ubuntu to try to mitigate that concern is identifying suitable higher level interfaces that we can recommend to administrators that they use so rather than invoking init scripts directly when you want to manage things calling service for managing jobs being running or not there was some plant yeah and if you run sudo service debus status what does that give you Scott? I don't remember because that one's like that yeah there we go and then there's also so unfortunately unfortunately the wrapper doesn't point you at service which is the generic interface if you do that scene at dd debus status you get use the service utility oh you may also use the status right yeah you may also use status which is the so we've done both ways when we've migrated we've also tried to provide education about the new way so about that I think the next step is deciding who's going to do the work because essentially so you very honestly pointed out that for Ubuntu it would be better for Debian to have that in kind of compatibility so on one end we need technical backing of the choice on the other end we need the patches because I mean a lot of Debian maintainer will probably not know about upstart and we need the patch to have both to have the support for both services so are you willing to you know submit the patches yeah so something we were talking about yesterday before yesterday before everyone got killed on Coney Island was that about having teams there were teams that worked between Debian and Ubuntu where they've had members of both Debian and Ubuntu in there seem to have worked very well for collaboration so my suggestion here would be that we create a team with Debian folk and Ubuntu folk so everybody interested in this migration can be on there I'll be on there people from Ubuntu will be on there Justin will be on there he did the service utility and so on and people from Debian who are interested can join the team and then as a team together we will do the conversions both in Debian and Ubuntu side by side so we'll treat them as a cross distribution project to do both that I think would be the best way to do this so one thing that we've not talked about yet but which is going to come up the moment we start discussing this on DebianDevel is SystemD I believe is the name of it What? I've never heard of that I mean there's going to be a technical question as to whether upstart if we're going to be changing a net systems whether upstart is the unit system we should change to or whether we should be looking at something else Can I give you two answers to that? I think the answer to that is pretty simple I mean we are not saying that we are going to migrate from system 5 into upstart we are saying that we are going to support both you can have the same answer for systemd and if no one does the work for systemd you have the answer That's exactly what I was going to suggest I think if we do this as a team then a group of people can work together to do the upstart migration and if the systemd folks would like to do the same work that's up to them I would say having known systemd pretty well it's going to be much harder for them because they haven't built in support for actually still running intscripts alongside and so on there are technical reasons I think upstart is better systems is very narrow focused on one way that all services should work upstart is much more takes a much more liberal approach and says that we've got to support existing services we've got to you don't just want to do socket based activation we're going to socket based activation time based activation actually activating it on boot regardless activating it when hardware comes up so upstart is a lot more flexible than what it lets you do and I also said there is a political reason I mean yes fedora and red hat are going to use systemd now systemd is now the default in fedora upstart is the default in Ubuntu which means now Ubuntu and fedora are incompatible you may as well consider them to be different operating systems if you're a system administrator and you learn red hat and fedora you do not now know how to admin an Ubuntu system likewise if you know how to run an Ubuntu system you do not now know how to admin a fedora system though I would say if you know how to admin a Linux Unix system today you do know how to admin an Ubuntu system systemd is so different you have to relearn how to admin it the one thing I would say politically is you know Debian and Ubuntu have this special relationship I think it would harm that special relationship if Debian also chose to be incompatible with Ubuntu but that's a political one but I still stand by my technical design I think upstart is better than systemd I think systemd is elegant but I think that upstart is better when it comes to policy however we might if we put in policy about how upstart is supported there might be pressure to also create a similar policy for systemd I would word policy loosely enough that it said alternate you may support alternate systems in your package provided you also support in it and that a group works to do the upstart migration and makes it so the upstart migration is more complete than the systemd demigration so therefore it becomes then a simple choice we have this alternate in its system it's already done 75% of the work there's another alternate in system which is equally open within the Debian project that's only done 25% of the work it becomes a much more easier technical decision if you've done the work first that would be my approach to that actually I like that because it's kind of a longstanding policy tradition that when you start creating a policy that varies widely from the current policy you create an auxiliary document which gets polished and ultimately included so we can say that okay we'll start an auxiliary document for any alternative in its system and whichever one gets polished will get included so Steve was just going to jump in first but if you want to start I have another topic to bring up I was just going to follow up on that that does suggest that just to be explicit we should write an upstart mini policy and that could probably be largely based on the existing upstart docs some of which are quite policy oriented but would it be worth trying to distribute that with Debian policy or should we be distributing it with upstart or something initially I would say you should start distributing it with upstart that's usually the way we do this once it's in the Debian policy package we would be able to both consider it to be mostly policy for Debian and also follow the policy change procedure which you don't want to do for your bootstrap okay so apparently I had a similar topic to bring up which is that we don't have a policy written upstart jobs are supposed to be invoked from maintainer scripts and before we start seeing lots of adoption of this in Debian we should probably sort that out especially given that the relationship between in-it scripts and upstart jobs is going to be different in Debian than what it's been in Ubuntu to date that was actually exactly the question I was going to ask which is what is the invokerc.d and policyrc.d equivalents for upstart there isn't one today in Ubuntu I have been beating the drum and I continue to use invokerc.d and policyrc.d because those are specified and we have a wrapper that can do the right thing but that won't work when we've got both an init script and an upstart job and it has to know which one to do My technical feeling right now is I think invokerc.d works reasonably well as an interface for maintainer scripts to do this I think that the policy.d layer and what we expect of administrators who want to make use of it is really hard to understand so I'm not a big fan of the exact way in which invokerc.d is currently implemented but I think having an interface which does what it is intending to do is very important So depending on where we land with this in Debian versus some of your upstream plans for additional features how's that coming this cycle? We'll worry it will I think we should make sure we land 06 in Debian because it's the stable supported one that's in our LTS The current version Which doesn't have the facilities for administratively enabling and disabling jobs Well we can Am I turning my mic off? We can fix that Sorry so one of the things that's not quite what you do is enable disabled jobs but we can fix that in 06 It's never really been a burden for us If there is a pressure we can put that code into 06 We can add code to let you do that to 06 without having to jump to 010 That's possible I think it's going to be important Just speaking as a Debian user for a moment we will want that facility and we will want puppet to understand the upstart in that system and be able to do that enable, disable without just deleting the upstart job It's hard to recover from when you want to put it back So we've got five minutes left Does anyone want to say anything else? Any different topics of concern? That can only require a copyright assignment for patches to upstarts Is that going to change? Is that going to be a problem for Debian? Well except that Debian is not upstream for upstart Debian is packaging upstart So the fact that upstream for upstart requires copyright assignment does not imply that the Debian package of upstart requires copyright assignment So basically we will be in the exact same situation we're in with GCC If you want to know why system D exists that's pretty much the reason I was actually planning on breaking that news and I was gently after the session The fact that in order to get the SE Linux patches upstream they have to be copyright assigned to Canonical and you are currently having enough trouble with your contributions to Debian I believe with your employment However they can go in the Debian package Would you like to explain to me in general terms what's involved and then I'll go and write a patch The other thing as well to bear in mind I'm hoping that much that worth is still on this private island is that we can always carry patches in the Ubuntu and Debian packages which aren't in the upstream code while we sort this out in the code from palm existed in both packages for a while in the state because So just quickly we think we've got one minute so is there any other concerns or cool So we'll take some actions we'll form a team we'll get this together Thank you very much everyone sorry I'm late