 I have the big pleasure to introduce to you the author of Debootstrap and several other important utilities in Debian. Long time Debian developer. FTP master, member of the couple team and whatever. So please welcome Anthony Towns. Okay, so is this working? Okay, that's excellent. Okay, so as everyone who reads Planet Debian will know, I was not very impressed with having to give a talk right now. So I thought about what else I could do just to, I don't know, annoy the organisers a bit. And so I thought, well, it's at 11 o'clock. So the obvious thing to do is death of Debian predicted. News at 11. Okay, so the first half of this talk is going to be basically that and the second half is going to be a general kind of casual Debootstrap chat, which isn't kind of suitable for a thousand billion person audience at like 11 a.m. on the first day. So Debian doomed. That's my title for this part. And I've gone through and looked at some of the things that attracted me to Debian in the first place. And I came up with four. So it's a community based district, which I think is great. It's got really good technical quality, which I think is brilliant. It runs everywhere and runs everything. And it's all about the freedom. And okay, I'd like to say up front that none of this is Brandon's fault. Okay, so this isn't going to be a Brandon hate session. And I know that's what you're expecting, no doubt. There's still time to schedule a one. In fact, I think in formal buff sessions during the week. The only thing in this that actually mentions Brandon has Brandon doing about the only thing right in all of this. So yeah. Okay, so the community based stuff. Back in the late 90s, Debian was kind of the only community based distro. Now there's a couple more of those. There's Gen 2 and there's Fedora and there's now Ubuntu as well. So we've no longer got creators, the only one of those. So we need to do it well if we want to keep that as a bin. The project lists have always been great, I thought, except not so much now. I did a survey on what the Debian project list, what happened in that during June. There were three threads that came up. One was a 96 message thread about the default KDE install showing porn. That was an open bug that then got followed up on the mailing list so that it would be fixed by the release, which it wasn't. The bug's been marked pending since the 3rd of June. It's not yet fixed. The next biggest thread was a 59 message thread on Brandon's mail policies. Brandon posted to that on the 23rd of June saying, as of the 10th of May, as in before the thread started by a month or so, when I find myself blacklisted when sending mail is leader.debian.org, I fall back to a host that's not blacklisted. So that's a 60 message thread that was kind of already resolved before it started. The other one was a 32 message thread on Sarge in the Wall Street Journal, which was saying that we don't get enough press about Sarge releases, and then we got some press about Sarge releases, and we didn't like that either. Some of the other things about the community that kind of worry me a bit is that we're not kind of integrating all the various derived sort of things that we could as well as I think we should. So things like Nopix, we still don't really have a live CD. Everyone else on the planet does. And kind of the first one was pretty much Debian based. So I think we could do a bit better job there. And a couple of other examples are the Debian women. We've got barely two actual developers, I think, that are in Debian women at the moment, and about four or five in the NMQ. And I really think we should have a few more of those accepted by now. And I think there's a problem there that we don't. A couple of other things are the AMD64 thing. It's kind of official. It should be completely official by now. And whatever's holding us up there is kind of a problem. And likewise, I think the putting all the projects on Aliath is a bit of a problem because that's not getting it into the mainstream of Debian. Okay, so technical quality stuff as well. So one of the greatest things about Debian I think is the policy stuff. So we've got 10 billion packages, and they all kind of conform to a kind of single policy. And of late, and hopefully that's going to change with Brandon's actual policy team that we have now, but up until recently at least there hasn't really been much policy development that we've done. So one of the threads on policy last month was the FHS version for Edge. And that was a five message thread. It ended pretty much with... I'll get around to summarizing the discussion in the next week or so if there's actually an interest in getting resolution at this point. But I'd like to determine if there's any real issues with the FHS before we modify policy. And we're about two versions behind the FHS at the moment. And that sort of stuff's not really good enough in my opinion. And yeah, the other threads were the upstream field in the package description and upstream URL when you're just browsing and deselect. The response to that was you're putting the cart before the horse, get the packages to change, and then we'll consider changing policy to match. We've had a 10 message thread on readme.source to tell you how to actually build packages. We've had a four message thread on scheme implementations. That one actually got a result in policy. We've had a 26 message thread on incorrect directory for web applications, and yet have a result. Had a five message thread on etch-a-mal name. And we've had a five message thread on adding a status option to init.descripts. And yeah, but I think doing initial design by policy is not such a great idea with the response to that one. And so I'm a bit concerned that the policy stuff's not going as well as it could. So I mean, a lot of these things are problems that can easily be fixed at the very least. And I think it's kind of important that we don't get too much on Debian's in space. Debian's the basis of everything. Debian's great. Debian's got a huge community. Debian's getting lots of money. Debian's great, great, great, great, great. And kind of saying, oh yeah, these are problems that only slash.trolls will worry about. Okay, so one of the other things about the technical stuff is that at least in theory in the old days, and I'm not sure how much this is rose-colored glasses or not, is unstable stuff used to be really unstable. So we'd get CVS versions of this and we'd get the latest, basically the latest of everything if you're out on stable. And in comparison, nowadays we've got even things like apt, getting into Ubuntu before into Debian. We haven't had a graphical installer ever, really. We've had Piggy, we've had the Stormix installer, but none of those have actually made it into Debian proper. Ubuntu is working on one as well now. We haven't really had very good, we haven't got XOR yet. We haven't got the 2.6 kernels yet. Or we have, but we don't have them everywhere. And that's kind of, I mean, there are obviously explanations for all those things, like the apt stuff, we tried to get that in just before the release, but there are other problems actually syncing it with stuff and there was a trade-off to be made and it went that way. But it kind of adds up and it's not really the best. And yeah. So I'm going to complain about some bugs that I filed that haven't been fixed. I was going to complain about a whole bunch of others, but no. So I've only chosen three, so it's not that bad. 62529, you'll notice the lack of digits there. It's five years old. It's the binary recompilation versioning support, which I think I've talked to Scott about and he's going to fix, right? The B1 stuff? You're going to fix that, right? Is he here yet? Typical. Yes. Excellent. 102213, this one's four years old. It's a policy bug about not taking policy too literally. It's been open for four years. I assume it's never going to get applied and it's been marked fixed since March 2004 by Andy, who's probably not here. Andy Bath. Abba. Yeah, he was going to see Helsinki instead of come to my talk, so I'll bitch about him while he's not here. That's great. He marked that as fixed for no apparent reason back in March last year. Sorry. And my other bug, which I'm really bitter about, is 293.096. That one's against Bash. Does everyone remember the flame war on Debbie and Devela about how scripts that are going to be sourced but can't be executed shouldn't be in user bin? That's the one with the patch to that. It's had no response. I'm very bitter. Hello. Hello. Is this working? There's a switch on the bottom. Hello. That sounds better. Okay. Is that all right? Hello. Hello. Hello. How's that? Hello. Okay. So, yeah, as of this morning, I think we've got 700 open release critical bugs, and we've already bounced back to 150 open release critical bugs against testing. We've got, I think, 56,000 active bugs. So that's bugs that are currently open or fixed but not closed by the maintainer or have been closed in the last 28 days. And we've got about 46,000 actually open bugs. And I kind of think that's pretty crap. Back in, when, 2000 or so, there was a great big slash dot story about how Windows has got 64,000 bugs and how Debian was so much better than that because we don't have anywhere near that number of bugs. And sure, half the Windows ones are actually closed bugs, but they just got counted in the stats. And, yeah, hello. Okay. Okay, that's good. So, the obvious thing is if you're pushing stuff... Sorry. The question was, if you're pushing stuff into unstable all the time and getting new stuff, then that's obviously going to mean lots of bugs. But if you don't want lots of bugs, then what's the trade-off and how do you choose one, and aren't I just being a real prick by making you try and lose each way? And, I mean, there is an aspect. There is a lot of that. I mean, I'm sure there's a couple of release-critical bugs about the recent debut-strap changes still. But the key thing there is not so much that there are bugs, but that they get fixed quickly. So, the couple of examples that I did skip over, which I'll go back to, was bug number 46,709, which was filed in October 1999. It's been marked as critical since May 2001. And it's the Herd Mark kernel lets processes right to IO ports. And there's another one which was 126471 December 2001, Grave as of August last year, which is Chidrav Freezers terminal on startup. So, I mean, sure, if you're uploading stuff, you're going to have lots of bugs, but you fix them in less than four years. And, yeah, the examples of my bugs were more of a thing that if I'm spending my time fixing stuff, but I'm filing bugs that don't get fixed for ages, then my motivation is going to go down. And I'm sure everyone here has had something that I've screwed up that's lost their motivation. And I don't have an answer to that, but it's kind of something that if we're not going to die completely, then it's something we have to come up with an answer to. And so, yeah, the other two points I don't have, actually, very much to say about, but the runs everywhere stuff is also kind of screwed up because we've had really crap support for a bunch of architectures, had lots of difficulty getting the installer working on it, and then that's resulted in the Vancouver Prospectors, which is going to say we're going to reduce support of that, and we've obviously got AMD64 people who are not necessarily the ones maintaining the AMD64 port at the moment, but have been pissed off because we haven't been able to get it integrated and haven't been able to give good answers and whatever else. And yeah, we've got 2,800 bugs against WNPP, so there's a fair bit of software that we don't package still. We don't have any LSB support. We've had problems with the X stuff running on the latest hardware that we release. I was very annoyed when I released Woody. I bought a new computer straight after, and Debian didn't work on it. And so, yeah, we're kind of screwing up the technical stuff. We're screwing up the community stuff. We're screwing up the runs everywhere stuff, which leaves the freedom stuff, and I don't actually have much to bitch about there. The only thing is the GFDL stuff, which actually started in 2001, hit slash dot in 2003, and as far as I know, we still haven't actually got an official thing on it yet. That's right. That's pretty crap. Yes, it's now your fault because you can fix it. The alarmist's face, it didn't turn out so well. Yes, well, that's why slash dot works as an intermediary, isn't it? You've got a lovely audience reaction shot here now too. Okay, and yeah, there's also the dropping non-free stuff or supporting it well or something that we should kind of actually do better at or something, but yeah, that's my crap notes. Okay, so to bootstrap. I'm sorry, questions. No, to bootstrap. What about my own bugs? I don't have any bugs. I have non-maintainer uploads to solve those. Have you looked at your own bugs? For example, if up, what is it, if down, if up? If up down. Yeah. What happened? It doesn't kill its children. That's sort of critical, isn't it? It doesn't reap its children, do you mean? That's right. Okay. Well, you've bitched about our bugs. Why can't we bitch about yours? You can, but I think you should have to do a talk to do that. You've got a talk schedule, don't you? Fine, be in the audience and I'll do it then. I don't think I've bitched about any of your bugs. I had a Linda bug, I'm sure. No, it was a Lintian bug, it's okay. Okay, so after all that, to bootstrap. Everyone here has used to bootstrap, right? Like, has installed since woody. Okay. You get a new box. Yeah. So, to bootstrap is a shell script, it's not very elegant at all. In theory, it does one job and does it well enough. It was based on the old bootfloppies code. So, the bootfloppies code, when you built bootfloppies, it had grabbed devs off the archive and would build a base system and then it'd upload the base system as a tab all. And it was kind of crap because you'd have to rebuild bootfloppies every time you change the package in base. And that's like libc and dpackage and they change all the time. Okay, so it's used by pbuilder, it's used by debbin installer, it's used by buildd's, it's used by bootfloppies, it's used by fai. Actually, this isn't meant to be so much a talk, it's kind of a discussion. So, this is kind of the background sort of context for those of you who haven't hacked on the bootstrap or whatever. One of the differences between those things is that when it's in debbin installer, it needs to be kind of more interactive. So, pbuilder and fai, it just runs a script, flats some stuff to disk, gives you some output, you don't care about it. With the bootfloppies and with debbin installer, it's needed to have a bit more of an interactive thing. So, one of the things for that is that you don't actually just want to have text dumped everywhere on debbin installer. So, we've got a, we have a kind of API or kind of interface for the translation stuff. And this was one of the things that we worked on or we decided on back in Oslo in 2003. And it's kind of, it's got a, it's separated into three things. It's got the actual code that gives you the message that you're talking about so that none of the actual debutstrap message stuff has to be in DI. You can just code up your own stuff. It has the arguments for it and it has a default format string. So, the basic idea of the translation stuff is that, is that you can basically do all the translation stuff in debbin installer. So, kind of the moral of debutstrap is that it needs to work for, yeah, I know I'm rambling, sorry, is that it needs to work for the things that use it most. So, it needs to work from the command line so that it can be used by the buildies and it needs to interact with debbin installer in a satisfactory way. So, if other people actually need to use debutstrap like that, then in theory the debbin installer stuff's fine, otherwise we're happy to add stuff like that. Some of the problems actually getting a base system, getting a base system set up. Have any of you looked, how many people here have actually looked at the debutstrap code? And how many people have looked at the sort of grungy stuff some of the seed and woody scripts have to do? And how many of you hate it? Yeah, in theory it was meant to be so that, I don't know, packages would eventually get fixed so they could just be bladded to disk and then you could run the pre-instance and post it straight away, but it turns out that doesn't really work. One of the problems is, orc on debbin is set up using the alternative system, which is awesome because you can get rid of morc and put gawk on. And so, yeah, whenever you try and put morc on without actually kind of running the post-ins, which of course you can't until you've got orc available because it's essential, you don't end up with orc available so you have to hack around it. There's a similar couple of things where you have to hack around d-package, but it's getting reasonably decent and generic. And reasonably decent and generic is good because that means we can get away from actually hard-coding all this crap. So how many people have looked at the code for the new debut strap that I uploaded that broke everything recently? Okay, so the new debut strap's got heaps of new features. One is that it makes some C debut strap redundant, which I'm very pleased about. And that's with the resolve depths option that now is, and that's kind of half-documented. So as part of that, you can kind of say, all right, I want d-package, and I'll tell the bootstrap to resolve the dependencies so that I'll bring in libc and morc and whatever else that it actually depends on. And as well as that, there's a... And obviously to actually work out what you download for that, what to download for that, you need to analyze the packages file first. And if you're going to do that anyway, you might as well not hard-code anything at all. You might as well just look at the priority field to work out what's required, or you might as well look at the base yes or section base, or in actual case, priority important to work out what stuff should be in base. Does everyone know the difference between required and base? Does anyone not stick your hand up? Okay. Joey doesn't know the difference. Wonderful. Hey, do you want to maintain base, by the way? Yeah. Anyone want to maintain the base pseudo-package? Please? Anyone? Yula? Talk to me later. Oh. You're volunteering, right? Okay. So for a Maya's benefit in particular, the difference between... We've got the base system is split into two halves, required and important, basically. Required and base. Required is basically essential yes, and the things those packages depend on. So they're the things that you can't remove from a Debian system without having it break terribly. So core utils, libc6, mock, and all the stuff like that. Depackage, not apt. So if you can't... If it's essential yes, which means if you can't remove it and basically recover your Debian system using depackage and vkshapt archives, then it's required. All the other stuff is just general base stuff. It's just generally important. And so what that means is that things like apt are only important, they're not essential, because if you've just got a copy of depackage, you can get apt reinstalled and go from there. And so yeah, required is very limited, base is a little bit larger. One of the particular differences between them in the way that Debootstrap works is that it just unpacks all the devs in each section and then tries to configure them using depackage's automatic methods. What that means, though, is that having unpacked all of required, it's fine for stuff in base to pre-depend on required stuff, but because Debootstrap doesn't do any ordering itself, it just relies on depackage for that. You can't pre-depend from one base package to another. And as a consequence of that, Debconf is being considered required rather than just in base. Okay. And so yeah, the first option is the resolve depths, which will actually resolve dependencies, get all the required stuff into required, get all of the extra base stuff into base. And in theory, that'll make DI hacking really easy once Debootstrap works again enough that DI hacking can actually happen. And the other thing is actually resolving, actually working out required in base just from the packages file, so just from the priority-required and priority-important stuff. And that's what you'll get if you try and Debootstrap sit now. Yep. Why did you choose to use the important priority instead of section base in the packages file? Because section base sucks and because the section base was further out from correct than priority-important. Happy to change it. Basically, the priority-important stuff isn't used for anything else at the moment, whereas the section stuff is used for other things. So some of the base stuff will be in section lib, section net, section whatever. So the priorities we have are required, important, standard, optional, and extra. Required is fairly... Sorry. The question was, is it still useful to have that many distinctions in the priority field? Those were the priorities we have. There's only five of them. In the past, required and important haven't been any different at all. As of kind of Debootstrap making use of them, they kind of have some sense now that's about it. Standard, obviously, is the stuff that deselect or task cell will add in for you when you run that and just want to get a default install. Optional is, in theory, the stuff that you can install none of it or conflict. In practice, that kind of sometimes works. And extra is all the other garbage. One of the oldest ftp.debian.org bugs is optional packages that should be extra. Technically, all the packages that are listed in that bug are actually fixed now, but the bugs kept open because the whole priority system is kind of crap, as in... So it's optional that it's like 7,000 packages. Is that really any help? And extra is, I don't know, only a couple of thousand, so it doesn't really distinguish very well. And yeah, I don't know if there's a talk planned for actually kind of reorganizing the sections and stuff at this conference, but people keep talking about it and it's a good thing. The actual sections that we've got aren't incredibly useful. The priorities are okay, but aren't incredibly great either. And as far as Debootstrap's concerned, there's about those two, the required and important ones. Okay, so the other cool feature that we talked about that I talked about with the herd hackers in Oslo 2003 was the ability to do a Debootstrap from an architecture that isn't the one you're installing to. So that's important for herd because they at least were doing boot floppies for I386, for Linux I386, and then trying to cross herd onto an actual herd I386 install. And Debootstrap in the past hasn't worked for that because it would just try and run de-package straight in the charu, which isn't going to work if you've got a herd de-package in a Linux kernel. And so just kind of generally from that, there's now a double-dash-foreign option to Debootstrap. So you say Debootstrap, double-dash-foreign, I have 15 minutes left. You say Debootstrap, double-dash-foreign, Sarge, some directory, and you give an architecture that's perhaps not your own. And that will then just unpack the packages and won't actually charu into the charu and try and run anything. So that can be quite happily done from PowerPC onto I386 or from I386 onto herd or whichever thing you like. As part of that Debootstrap can't actually unpack the correct devices for you, it's never been able to for herd because they've got weird devices, but it now can't unpack the correct ones for Linux architectures because they differ between architectures for Debian. So instead of that, it now just gives you null and a few basics like that. And so once you've unpacked stuff and you've got some devices, if you copy the charu over to a system with a correct kernel and correct architecture or whatever else, you can then charu it into it and run really basic stuff. So in theory, you've got a libc that works, maybe an ash that works, or sorry, maybe a bash that works, ls and dpackage isn't really set up yet, and all this stuff doesn't work. So what you can then do to finish it off is just charu it into it and run slash-debootstrap, slash-debootstrap. And that will give the second stage in store which actually sets up dpackage to work, actually runs dpackage and stores base. And at that point, you only needed a kernel. You already have a charu. So you don't actually need as much. You can do this just from an NFS boot on your target architecture rather than actually having to have a CD or whatever else to actually boot it up. Okay, how long do I have left? 10 minutes? 10 or 15, fine. So, okay, the other feature is that it now has release.gpg support if you pass it a keyring and you've got gpgv installed. Are there any questions before I go on? Are there any plans to support gpg-debootstrap? Yes, there are. Do you use some gpg-deboot by default by default? So you can't do gpgv by default. The question was, do you have any plans to support gpg-deboot by default? You can't do it by default because you need to tell the bootstrap what keyring to use. So you need to say that, all right, if the release file is signed by this key, then it's okay. If it's signed by a different key, it's not okay. Maybe it, in theory, has to be signed by multiple keys or something. The bootstrap doesn't support that and neither does that at the moment, I think. I wanted to ask, there are people who want gpg-deboot support in P-Builder. And I was wondering if the bootstrap was going to do it, and I wondered if I'm going to do that or you're going to do that. I have a better answer to that in the next section after the questions on the stuff that's already done. Anything else? Yep. This is good. I was wondering how the changes you made to the slash dev effect, just to bootstrapping regular systems, it looked like you might have something eventually maybe need UDev or something along those lines to get a useful dev. Yeah. So the changes to the devices are only actually in the dev at the moment. The UDev stuff still does the same thing as it did before, which is the full devices that make devs says that you need and the bootflop is used to use. And it's thousands and thousands of devices and takes ages to actually run. And it's a real pain. In theory, BDEL is going to have a new make dev that fixes stuff up, but before BDEL gets around to that, we may well be using UDev everywhere anyway, which is cool. And so in theory, if you're using UDev, then the bootstrap stuff doesn't matter because has everyone heard of UDev and tried it out and seen it? Has anyone not? UDev rocks. It's like DevFS except not crap. Compared to DevFS, it's not crap. Compared to DevFS, everything's not crap. Yeah. So is that enough of an answer? Okay. So how many people here have run the bootstrap by hand? Now put your other hand up if you think the argument format really sucks. The bootstrap argument format with the options that have to be up the front and the strange comma arrangements and the equals that sometimes have to be there and sometimes don't. Yeah. It was... He would have read the man page and then got it right first go. So it was a really short period of time but hundreds of implications. Okay. So the argument format particularly sucks for things like Debian installer. And it's just really painful. So in theory, the next kind of new feature that will probably break everything is having a config file format for the bootstrap. So instead of just passing out a lot of arguments, you'll pass it a configuration file. And the one that I wrote ages ago and then probably lost the source for was kind of windows.ini format. And the idea is kind of that you have a few sections. It gives you put in the options. If you don't want to have a particular option, you just don't put it in. The ordering doesn't matter so much because it's just windows.ini format or samba.org format or whatever it is that uses it in Linux. It's not sucky. Why not EmacsLisp? Why not XML? It's like a Zencone or something. Yeah, I wrote a parser for that and it worked without too much effort in shell which is kind of the key requirement. Why not XML? It's because I don't really want to write an XML parser in shell and we don't have lubexml available everywhere. In theory, the foreign stuff, by the way, should also let you do an install from Solaris or maybe an install from Windows that has a POSIX SH. I'd be very interested if anyone's in a position to try that out. So, yeah, the configuration file format should, in theory, let you just dump all this stuff to a file, pass that to the bootstrap and not have to worry about it so much. The one that I specced up originally let you do things like, say, include sources list lines to kind of specify a few alternate mirrors and stuff like that. Basically, the idea is to get something that isn't just all in one crap line at a prompt that can actually be expanded and do a little bit clever stuff. And in theory, the bootstrap's all ready for that now. The actual code inside's changed so that you can actually cope with multiple mirrors or some mirrors that don't actually have all the components or some mirrors that you only want to choose one component from that you don't want to look at on the other mirrors and other stuff like that. And that's kind of waiting on someone to convince me of a format that I can come up with or kind of talk me through that so that it doesn't crap, so that it's not a crap format that's unusable and I'm getting distracted by the video people. Okay, so if people just want to accost me about that later or I guess we don't really have time to talk it through now, but what sort of configuration file stuff is really cool, that'd be great. Okay, any other questions? Otherwise, I'm done. One question for me. I was wondering, well, first of all if you make the configuration file, please make it optional so I can keep my scripts working with a lot of configurations to the script to the program instead of making a configuration file. Normally when I do the bootstrap runs, I want to add a few more packages and I want to configure them as well during installation. Are you going to add support for preceding or running scripts after the base system and before you add the extra packages so you can for example, configure the kernel settings before you install the kernel packets or similar things for extra packages. This is very convenient when you want to be able to download packages from the same CD without loop-mounting it or remounting it within the change route to get things working. So everyone heard the question? Cool. The theory, well, my theory ages ago was that for additional packages, I'll just let people run apt in the to route and that's kind of what DI manages to do for its extra packages that it needs to do later so I've been kind of not worrying about that. So, yeah, basically the answer is that I've been ignoring it and not worrying about it. For the configuration stuff the bootstrap kind of really relies on you just configuring, pre-configuring the to route how you want it to be so populating, et cetera with anything special that you want either before or after. Populating var with anything special that you want before or after. And there's no real plans for that but if you've got some good ideas on how to do it then sure, that's fine. This may be the stupid thing but the resource file format support classes and I see that it's much better than Windows in file format so you can define that some class if it's not better stated for some particle application it takes the default value for that class what you state there and that way it's better than in file format. So the classes for which packages get installed, right? It's independent so you can define class and use it in configurations. Right, so the way FAI works is to have different classes which let you choose packages to go into and also lets you configure them, that's correct right? Is that an accurate summary? It's like if you define the window background blue it could be blue for everyone every application if not stated that some clock is like a green background background and that way you can much easily make settings which are one line for bigger group and Windows doesn't support that Windows in file format. So the Windows in file format in theory is just meant to be simple enough that it doesn't need extra support like classes and stuff and the actual passing configuration stuff through to actual packages is something that I'm trying to avoid as much as possible from the bootstrap to keep it I mean it's already complicated enough so to keep it as simple as it can be which is very so that's kind of a pass the buck to someone else if at all possible on that. I wonder if you've ever considered allowing the bootstrap to install over top of an existing system and basically work unless something's really wacky. I know that if you try to run it on any system that contains awk it'll just die with a simulink error for example. That's no longer correct. Well okay great. Do you mean Debian system or in general? Let's say a Debian system. Yeah I've never. Or maybe a red hat system. I've never looked into the installing over the top of a Debian system because I don't really see the point. If you've got a Debian system you should be able to just use d packages fixer stuff and do that. I've looked at, well thought about more than looked at trying to do it on a red hat system which would in theory look through the contents file and see what files you've got installed have a guess what packages they should be and kind of do a cross install over a red hat. Where this comes up is in DI where some people would like to not format their partition and just install one and they do try to do this and we have to special case into it and say this isn't going to work and it'd be nice if it could be simple enough so that it could just work somehow. Yeah I guess that's possible. I haven't looked at it. Craft is good. And it really is now too. Okay any other questions? Okay thanks very much.