 So, Debian installed an update for Edge and what we are going to do for Leni. And actually, I shouldn't really be standing here anymore as I resigned a couple of weeks ago from Debian. And we need a new release manager. So any volunteers to step up here and take over for this presentation? Yeah. Why not? But it is a real issue and I will be coming back to it later in the presentation. So I guess I'll do it myself this time. So the main thing I think that we have achieved for Edge is the graphical installer, which has been worked on very, very hard by one guy, Atelier of Fiamtotti, an Italian guy who basically revived a project that had been dead for a couple of years, did all the work by himself. And at some point, it got good enough that other people got interested. And we said, okay, we will set up a build environment and integrate it in a regular installer. And from that point on, people got more and more involved, more and more enthusiastic as the bugs got finished. And basically a month before the final release of Edge, we fixed the last few crashes in the installer and stuff like that. And it was ready just in time. But I think that what we managed to release with Edge was really release quality. The main advantage of the graphical installer is, of course, that we can now support a number of languages that we could not support otherwise because they have scripts that you just cannot render in a text display. There's also some usability improvements. The one that I like myself is that when you enter a password and a confirmation for a password, that you can enter both on the same screen. While in the new front end, you have to enter one, then you get a new screen with, again, one input box and you have to enter the next. But with the graphical installer, there's still a lot of improvements possible, and I'll come back to that later. And we got rid of base config, which is mostly thanks to Joey Hess, which means that installation takes place completely before the first reboot. And that also means that when you reboot, the system is really set up correctly, including stuff like the time zone and passwords, which gets rid of a tiny security hole where in the first reboot, you basically had a passwordless system so anybody could log in as root. So although that this may not seem like a huge issue, it is a real advantage. A few very nice improvements for partitioning, and I think the killer feature for Edge and an advantage it really has a competitive advantage over other distributions is that we support setting up encrypted partitions out of the box during installation basically by pressing three or four keys. And that's thanks to David Herrmann, who is not a Debian developer but has worked very, very hard on this issue in Debian installer and on a few other partitioning-related things, and Max Fosler, who is the maintainer of the crypto packages in Debian. Colin Watson implemented a feature, the rescue mode. That's something that could be extended quite a bit still. It is modular, so you can add extra menu options. And one thing we would like is to enable RAID and LVM and crypto if it's present on the system by default instead of kind of having to switch to shell and back and do it manually. Automated installation, a fair number of improvements there as well. One being the option to proceed a RAID configuration. Some general improvements like the fact that you can now enter shortcuts instead of having to enter the full template name, you can now enter a short name to enable some features at the boot prompt. And Philip Hans implemented the hands-off installation method, which is a fairly complex collection of scripts that allows you to proceed an installation using classes. So you can say, I want a web server in German, for example, which would be using two classes. But you could also say, I use the same web server class, but I will choose another localization. So that's really flexible. It takes some time to get used to it, to understand how it's set up. But it has great potential. And of course, Christian PA has been busy trying to get people from all over the world to translate Debian again. You must be sick of those little maps at the bottom in the meantime. But, well, they do show what's happening, so it's still worth it. You can also see that I've split the new language into two groups, and the second group would not be possible without a graphical installer. Martin Mikkelmeier has been tirelessly working on supporting a number of new ARM sub-architectures. And as you all know, the NSLU2 support is a really great success. It has promoted ARM in the list of popcorn rankings from somewhere down the bottom to third, I think, at the moment, which is excellent. Because that is certainly where the future for Debian is in part. There's been some other more general improvements. We have switched to UTF-8 as default for all installations. We have had to do a lot of work to support the new 2.6 kernels, which required UDef and different in-it-RD generators and to switch the installer to use that and support it properly was a lot of work during the edge development cycle. We have also gotten rid of the need of what we did in SARTs. We sometimes select kernels, including the ABI revision, which meant that when there was an ABI update in stable due to security updates, we would also have to update the installer to be able to get those and not get, sorry, I can't find the kernel you want, because it's not available anymore. And we've gotten rid of that, which makes the whole release process for point releases a bit more simple. We also now install the source list using code names instead of suites, so we use edge instead of stable, which makes for a much more controlled upgrade experience for users. They do not get confronted with a huge list of updates as soon as a new release hits the mirrors, but instead they can choose their own time. And it also has some advantages during installation itself because you really have better control over what gets pulled in both in UDefs and for the installed system. We also have support for secure opt, so the installation is basically as secure as your installed system is. There is an option to install a system with a disabled root account and use sudo instead for administrative tasks. Now users resize iNote and there are index by default, which means you can do online resizing and stuff like that. And we have support for installations using PPP over ethernet, which is a very common broadband in some countries. And something that's not really DI, but is still worth mentioning here is that we have got a new set of CD images, thanks to Joey Hasegan and Steve McIntyre, who is the Demian CD lead. There are two multi-arc CD images, which are basically the net-inst CDs for three architectures put onto one CD, which is useful for people who have those architectures in one environment and have to run around installing them or just for people who just want to carry something in their back pockets all the time. There's also, I don't know what that eye is doing there, a multi-arc DVD for i386, MD64, and PaoPC, which automatically selects the right architecture at boot time. The main advance of that one is that it also includes source, so it's very easy to distribute at fares and so on because you know you will be covered when it comes to GPL requirements, stuff like that. And there are two alternatives to the default GNOME desktop installation, the KDE and X-Force CD, for people who need it or want a lighter desktop than KDE or GNOME. So that's basically what we've been doing for Edge. Are there any questions, remark, comments about that before we switch to like the plans for the future? Can you use the microphone, please? Hey. My name is Peter Reynolds and I'm working on the Debian EDU custom Debian installation for Edge. And we ran into a small problem with the source architecture. It's missing all Udebs and a few other packages. Have you actually verified that the source included on the DVD is the complete source for all the binaries on the DVD? Sorry, could you repeat the last bit? Have I verified what? I'm wondering how do you verify? Have you have the Debian installer, Debian CD project verified that the source included on the DVD is the complete source for all the binaries on the DVD? If you have, what have we made wrong? I think you should ask that to Steve McIntyre, who has done the work. I haven't actually really looked at this myself. I would expect that all sources for all packages are included on the DVD. If you say that source for Udebs are missing, yes, absolutely. I believe that immediately. Especially for Udebs that are included in the inner-card, I'm not sure if they would be included for Udebs that are used during the installation. They might be included, they might not be. I'm not sure. That could be worth a buck report to Steve, to Debian CD. No more questions, I think. Let's continue with what we'd like to do for Lenny. And actually we have loads of plans. I've listed the main goals here on this sheet. There's a wiki page where we try to keep track of what we'd like to do, which also has more extensive explanations and stuff. Our main task basically is just to keep up with Debian. There are so many changes which affect the installer. There are library changes, which mean ABI changes. There's also regularly uploads that break the installer in minor ways. At the moment we have an issue where the width of Chinese characters and Japanese characters is not calculated correctly, which means the progress bar or the scroll bars and borders of dialogues are not displayed correctly. So there are lots of minor things that you have to keep track of just to be able to maintain the installer. Then we still have a fairly important issue which is if someone has multiple hardest controllers in their system, you run the risk that during a boot the hard drive identification will be swapped around. And we need some kind of persistent naming scheme to do that, but that's fairly tricky to implement and we've kind of been dragging our heels to really get going on that. But we really should fix that for Lenny. Then we have a problem at the moment actually with all the work Christian has been doing. Every language adds about five megabytes to, what's it, five, to the memory usage of the installer, which is a bit much. It means that you need bigger and bigger machines just to install Debian and we would really like to reduce that. And it is possible because there's some very obvious waste of memory in CDEP conf, but we would like to get people who are really fluent in C to get involved in that. We need help with that. Then we are still using an edge DevFS naming scheme for some stuff. Although it's been, it's no longer supported in the kernel, Udev still has compatibility layer which allowed us to kind of put this issue forward, but we should get rid of it now because, well, it's obsolete, so why keep it around? And it will simplify a lot of code as well because currently we support both naming schemes like the real DevSDDA and HDA names and the Dev disks, DevFS stuff. And it's crossed out because actually we've managed to achieve that during this Devcamp. I realized that I kind of skipped a slide, this one, I don't know how that happened, but this is a nice slide because this is actually a slide that Joey presented during Devcamp 5 with the to-do list we had at that time. And as you can see, quite a bit of that has been realized in the meantime. So back to what we are going to do. Another important thing we would like to do is at the moment you can only install from the CD or the DVD you boot with. So the whole rest of the set, you can only add to your sources list after you've rebooted into the installed system which also means that when you're installing GNOME or something huge like that, you get only a subset of what is actually, should actually be included because of the task definition. And it would be nice to be able to just swap the CDs during the installation and get the full set of programs and packages that's available. IPv6, it was a real lease call for Edge. We've not managed to get it done for the installer but it would be very nice to be able to support that. And this is again an issue where we need some help from people who are willing to hack on NetConfig and Busybox and probably other stuff and just keep going at it until it works. And a last and very controversial issue is support for non-free firmware and drivers. I'm not actually sure if we're going to be able to do the end thing about that because it will require a huge discussion first about what's allowable and in what form it's allowable and what we can include in the default in-it IDs and what we cannot and why and so forth. So this is not going to happen overnight. This is going to require some careful thought and discussion. Some other goals, minor things. We're still using version two of the HP Client which is basically obsolete in the distribution but we cannot switch to the HP version three because it's just too damn big. So especially for floppy installations we cannot fit it on the floppies where we would need it. So we would like to use a smaller alternative like Pump or maybe the DHP Client that's included in K-Lib C. There are alternatives but they have to be studied and we have to test whether they support all the options we need and so on. There's a new package or new method to select keyboards and support the console and for keyboard selection it uses the XORG, the same key maps as XORG does so it would provide better consistency that's called console setup. And it would be great if it could replace console data and keyboard chooser in the installer with console setup but again that's a fairly complex task and unfortunately the people who have been working on console stuff in Debian are fairly inactive at the moment. Fake ATA rate has been on wish list for a lot of people for some time and I'm happy to say that's another thing that we managed to do during DebCamp. It's still very ugly but at least it works now so we can start from there or work from there and improve it gradually. Some new architectures. Well there's not a complete list obviously because you never know what will turn up and I suspect that Martin Mikolamier will have a few more arm sub-architectures and installation methods that he's going to be working on but these would be nice to have, especially MacBook. It's kind of supported at the moment but it's never been done in a structured manner. It kind of works because basically the old stuff for i386 works and currently you cannot use the 64-bit AMD64 ARC on MacBook. That still needs work. The same guy who worked on the Graphical Installer has been working on something else again completely solo. He's developed a web frontend for the installer which means that basically you don't have to touch the system to be installed at all except insert CD, you boot it and then you go to another system and you start a web browser and you install from the web browser which would be a nice option. But that needs work especially some kind of authentication scheme so that not just anybody can log on to that web server and do all kinds of strange stuff. We'd also like to extend accessibility support for special blind people. We already have some of it. We have also with Edge to both in the Graphical Installer and in the new frontend special themes for not blind people but people with visual problems like color blindness and so we have larger font and more contrasting colors. But it would be nice to have and we have bright support in the installer but it would be nice to extend it. There's a lot of things that are possible. And the last one was something I picked up out of a video I saw of LCA, the Linux conference Australia. And well, we have volunteered to implement it. Why not? As I mentioned earlier in the presentation there's still a lot of issues that could be fixed for the Graphical Installer and a lot of them need some serious debugging skills and C coding skills. So if anybody wants to dive into that you're very, very welcome. There's a few stability issues. You can safely switch to other virtual consoles at the moment, for example, to work in a shell or to view the debug log but not if the installer is running. For example, if net configuration is started or apartment is started while you're on another console the Graphical frontend will crash. So it's not a major usability issue because it only happens if the installer is active and most people will switch if they want to sort something out while it's waiting for input and then it's no problem but still it would be great to have that fixed. There are also various issues with input handling. Touchpads work but are not really configured optimally. Speed and double tapping and stuff like that does not work with all types of touchpads. And there are problems with UTF-8 input so accented characters and things like that. And that's mostly a Direct-of-B issue in the Direct-of-B library. It's not really a Debian installer issue but still it does affect us. The encrypted partitioning option in the Graphical installer is not complete. You currently cannot use random passwords for example for a swap partition. You can only use the typed in key phrases to encrypt partitions. And that's because the installer has no way to generate enough entropy and we need to plug in the frontend to be able to do that. For new we have such a frontend but not yet for the Graphical frontend. Having a Graphical installer and then still having to switch back to other consoles to see the logs and to get a shell is somewhat ridiculous. If you have a Graphical environment, why not also have a Graphical or shells in separate windows in that Graphical environment? So that would be nice. A Graphical partitioner, people who have used it and are familiar with it know that the partman, the partitioner we use at the moment is really powerful. You can do a lot of stuff with it. Almost anything you would like to set up is possible. But for a lot of users it's not really intuitive, especially for newer users. So it would be nice to have a simple Graphical frontend that you could use for partitioning something comparable to G-parted maybe. And actually a French guy, Xavier Oswald, has already started to port G-parted to C, which is needed because we don't want C++ in the installer environment. But that work has stalled, so somebody needs to pick that up. And of course we always want games in the installer. We have not yet been able to do that for the new environment and for the Graphical environment. Well, there just hasn't been time but it has always been a silent goal of us to have some option to play a game while waiting for the base system to be installed. And of course we basically only have support for i386 and AMD64 at the moment. PowerPC is experimentally supported but only for a limited number of systems and we know their issues on some of them. So some porting work for PowerPC and for other architects would be great. Partitioning, it is a very first thought tool but it's also a tool that can be improved in a lot of ways. The partitioner is basic, a huge amount of shell scripting, very modular, but that also makes it quite slow in some cases and for example some core parts could be replaced by C code which would speed up the process a lot. And as it is a huge amount of shell code there are obviously places where the shell code is not optimal, where error checks could be improved. And one of the things that could be improved is the way translations are currently being handled. Which is basically because there was no other option to do it at the time but we now have a different mechanism that can be used and we should switch to that but that's a fair amount of work. One option that's missing in the guided partitioning menu is the option to say, okay I've got a Windows installation and I want to keep that. Please resize my Windows partition and install Debian in the space that becomes free through that. Madoc has suggested that we should implement support for rate 10 and rate six and he's even offered to work on it once he's done with NetConf I guess. And as I said there's plenty of other stuff that can be done with regard to partitioning. So the basic message that I wanted to give to all of you is that the installer although it works and it's an excellent installation system for Debian it needs quite a bit of maintenance and the current team basically is a bit on the small side to be able to maintain it properly and do all the new stuff that's possible and that we have listed. So we would like to get the general Debian community to get a bit more involved especially people who maintain packages that are used in the installer. It would be great if they would sometimes just look at how it is used and see if it's still optimal or if changes are possible that would improve how it is used. Maybe extra compilation of options that reduce the size. Disabling of features that are not used to reduce the size. It's often fairly small things but they are very important for us. But it's stuff that we cannot really do ourselves. And as I say also just extra hands even helping processing installation reports, testing regularly, fixing minor issues that annoy you when you use it. That's another thing I would like more DDS to use the installer because sometimes we hear hey this is the first time I've installed a new system using DI. It's been available for three years for God's sake. So if you're interested in getting involved please come to the booth on Friday. And that's basically what I had to say. So now if there's any questions we'll be happy to answer them. Just a simple question. Who in this room did ever try to, I don't know, see what was in the DI subversion repository and eventually hacked it? Okay. That's a fair number of people but it could be a lot better. Because the DB installer is basically shell scripts, deep comp, things like every DD should know how about. So try do it. It's fairly easy actually. Yes, that's true. It really is easy. Otherwise I could never have been a DI hacker. Yeah. Even the non-programmers, DD can do it. Yeah. That's not exactly a question. Two things. I think we have the duty and I will do it in name of a few people to owe some apologies to France for the some lack of support we showed during the recent issues and we failed to measure how it was affected by these events. And for this, I think we owe you an apology. And second, I think I want to in name of the whole DI team express my respect for the whole work that France did during the release of the Edge installer. And without France work, we wouldn't have released such a good installer. So thank you, friends. Thank you very much, Christian. I'm not going into the whole thing here. I'm happy to talk about it to anybody who wants to discuss privately, but I don't think it's really something that should be discussed publicly. Yes, it has been, as I wrote in my resignation mail, it has been fun mostly. The last year has been quite stressful for me because this issue gets dragging on and on and on. And it just reduced the amount of fun I had working for Debian to the point that say that I had to conclude, okay, this is not worth it. But I will be around. I still enjoy working on the installer and I will continue hacking on it. But I won't be as involved as I have been as I have been over the past two years or so. Steve. Follow-up question. Why have you not named Christian as your successor? I'm afraid you haven't been reading the mailing list properly because you already sent a mail that he wasn't available, so. I'm a little bit concerned about the Debian installer for a very small system, in fact, because I own a computer that has not a lot of memory at all, less than, I think, 16 megabytes, so in RAM, and it's very complicated to install it. So I just want to know if it's only a question of CDepconf and unlink languages or if it's larger than that. If you, just to say what I did say, it's because I think that DPKJ when installing package also take a lot of memory, so if you need to fix CDepconf and also DPKJ, it's a huge task. So I just want to know if it's only a CDepconf issue or if it's more general. It is more general and the problem starts with the kernel, which has grown and grown and grown over the past years. Our current boot floppy for I386 basically only contains the kernel and we couldn't even fit USB modules on it, so we cannot support installation from USB floppy at the moment. That's something we cannot change. That's something that the Debian community has to work on. We could probably fix some of it by using a custom compiled kernel for Debian installer or for bootfloppy, but that has other issues like you could run into issues, new issues when you reboot the system because it was a different kernel when you were installing. So it's unlikely that we are going the way. Keith, I just see you come in and I want to go back a bit in my presentation because basically this was my first slide. Okay, that's a good excuse. But 16MB, I think we won't be able to ever get down back to that level again. What I said about CDEP Conf is actually not an issue so much for the really low memory installations because we already have mechanisms to not load all translations which reduce memory usage by a huge amount. It would make a small difference, but not really significant. But yes, any work to reduce memory on the installer is very useful. Every 10K saved will help us install all the system that have limited amount of memory. I think that for really small systems you will have to end up with something like just the bootstrapping manually. And of course, once you get to package installation you have swap available because you have your partitioning done in that stage. So it becomes less important, although yes, if you have to swap huge amounts of memory out during package management, that's not good. But again, that's not something we can fix in this installer. It's totally outside of the scope. Yeah, I have a few comments about your prospective list of features to implement for Lenny. Mostly shameless advertising for the talk I have today and later next week. First of all, hardware detection wasn't on your list. I believe we can do a lot better and I hope we can get it installing hardware specific packages automatically when you install it, like the video card configuration tools for laptops and the RAID controller monitoring systems for servers and that kind of thing. And I hope to attract more developers for that idea of my talk later next week. And also I suspect we should switch to a dependency-based boot system to make sure that the boot sequence in Debian is really correct and not as it is at the moment, fairly correct. It is, so. The first issue is an installation issue. And I know you've been working on that. I know it's a pet issue of yours and if we get something working, we will of course include it in the installer. I've replied to your initial proposal about that on the list where I think I said my main concern would be how do you build your database of what hardware needs what and how do you make sure that you don't install stuff when it's not really needed because hardware looks similar during hardware detection but isn't really. But yes, definitely. It's a worthwhile thing to work on and to implement. The second issue is a general Debian issue and has nothing to do with the installer, I'm sorry to say. So you'll have to bang that drum somewhere else. Okay, if there's no more questions, I'd like to thank you all for your attention and see you all soon.