 Of course, you all know that one of the big new features with the last release of D.B. and Sarge was a new installation system called D.B. installer and well, if you're some guys who are pretty much involved in the development of those nice stuff and who will tell us a little bit. So please welcome Joey Hess and his dancing apes. We have 45 minutes to do a talk. We're going to talk about the past, present, future of D.I. and how you can help with it. And we do have four people giving the talk, so wish us luck. I'd like to introduce everybody who's up here. We're going to start off with Holger, who has contributed to D.I. on the manual German localizations, other things in that area. He's been working in D.I. for a couple of years. And he's going to talk about the general overview of D.I. and then we have Christian, who is basically our internationalization coordinator. He basically gets lots of people to translate D.I. and does it really well. And he's going to talk about that. Over here we have Franz Popp, who's mostly been involved in working on the manual builds, that kind of thing. And is now taking over as a D.I. release manager. And he's going to talk about mostly the manual and I'll wrap up with future items and questions. I'd like you to hold your questions to the end, if you could, in case we don't run out of time. So, that's about it. I just wanted to ask anyone who's in the audience who has contributed to D.I. as a translator, as a developer or anything to please raise your hand. Loads of you. Well, I think we should just give you all a big round of applause because D.I. has made Bevian great. I'll hand things over to Holger now. Sorry about that. Microphone working. Hello? Hello? Hello? Oh, yeah. Now it's working. Yeah, start with the retrospect of the boot floppies. As far as I remember, I've always used boot floppies to install Bevian and it really always worked. It was the partitioner. It was not so easy to use, but after some years you got really used to it. The problem with boot floppies was that they were not maintained anymore since the end of the 90s. Nobody wanted to work on them. And for Woody, they were really a pain designed for I-386. There was no hardware detection. Localization was not really well included. It was made for Woody, but yeah, it sucked. And yeah, they were designed for floppies and so CD on that boot was also hacked into it. And the graphical installer was also not really possible with boot floppies. DI, the design is based on Depthcon mostly, which makes different frontamps very easily so we can have a graphical installer in Edge with, yeah, we'll have it. Also it's easy to translate. So internationalization and localization, as you already know, is part of DI. And also Depthcon gives preceding. So it can be used for various grades of automatic automation and with UDEPPS, DI is also modular. So the DI team does not work on the whole installer, but there are different people working on different parts of DI. UDEPPS are basically deviant packages, but they are smaller so that they fit into RAM disk and they don't have to comply with policy that's also because of the size constraint. Another design aspect that was used is the main menu, which is normally hidden from the user in the basic install. In cases of errors, the menu pops up and you can redo steps or do other steps like enabling SSH for network console or other things. The UDEPPS have one special control header, which is read by main menu and defines the order by which those functionalities are put into main menu. And this is basically it, the most important parts of the design. There are other parts like the partitioner, but those can be exchanged for another partitioner. This is basically what DI is based on. As you know, DI is teamwork. There are different people working on different areas. There is no real leadership, no formal leadership, but there is, of course, Joey is very much involved in everything. So it's very wise to get his advice, but it's only his advice that we discuss things on the mailing list or on ISC channel or in real life meetings. Yeah, for the code, we use the subversion repository on alias. The commit messages go on the mailing list and on the ISC channel. So you can see in real time, if somebody commits something, if you're on ISC. There's a trunk for new development. Experimental stuff is done in people branches. And there's the search branch for maintenance now. During the release, there were also release branches, which were used to branch the development from the trunk, basically. Yeah, this is how the development processes. And now, Christian will get some details of localization. Do you hear me? Is that fine? Okay, thank you. So it's again about localization and internationalization. Sorry about this. So what are the drawing IDs of DI localization? Well, the first one. Okay. So before all the English people come around and just kill me, what is this ID about? This is about all displayed text have to be translated. This is the main ID behind English sucks. Actually, in DI, English does not suck. It is very well written, very well reviewed by many people to be of the best quality possible. And of course, the translation also. Other drawing IDs, Olga said, we are based on Depcon for all our interface. So every translation goes through Depcon, and especially for the use of get text in PO-Depcon by using the PO-Depcon. The wonderful PO-Depcon system introduced by Danny Barbier over there just after the release of Woody. All translatable material go to Depcon templates. There are some enhancements to Depcon, in C-Depcon, to handle this. And there are some text templates, which are not very used in your packages, but are used in DI. So everything is in Depcon. So first of all, what is about interlocalization? This is what we covered with potato. OK, get a picture. Only English. This was Woody, pretty nice improvement. This is what we have in Sarge. And hopefully, this is what we will have in Edge. Not a big part, but I haven't seen you the small part in Asia. Yes, we expect to cover India, actually. So let me do it once again. Yeah, yeah, yeah. And yeah, yeah, yeah. Well-domination. And actually, I'm just doing a commit because I have an agency. I'm just committing 10 more languages in the DI repository. And we will add Vietnamese, Malagasy, Indian, Macedonian, Tagalog, Berarussian, Punjabi, Esperanto, Wolof, Cosa, and Estonian. That's the point. Cosa thanks to the Ubuntu people. Thank you, Mark, for giving the Cosa translation. There seems to be a question over there, but. That's basically, yeah, the question was about why are some countries not covered? Well, this is mostly to get you a picture. Many of this country actually have either English or French, especially in Africa, as official language. But I don't consider this country covered because their main language is not covered. This is also special for India because there are so many languages. There are like 20 languages over India. So I just put India in red because I expect these 20 languages to enter. Okay, so. Sorry, Christian? Yeah. And another red space to your slide. You might be getting some correspondence from somebody who wants to be Mongolian. The old script of Mongolia. Oh, yes, probably, yes. You're puzzling me a little bit, actually. So don't be too nitpicking these white spaces in this world map, actually, please. Okay. So how do we proceed? We have the concept of levels. So we go levels from DI translation down to world domination, okay? So first of all, what we call core DI package. This is what we call DI. Actually, this is all what happens before the first reboot. The second level is called level two, of course. This is the default base system install when you only install the base package. Everything that is used to input users has to be translated, only input users, not displayed text. Level three is any kind of base system install. Any user prompting has to be translated. Level four is all DI is translated for a base system install. You don't see any word of English except the kernel messages, hopefully someday. Anyway, and we will soon add a few more levels up to world domination. Probably level five will be the default desktop installs, all the prompting of x.org probably, and a few more things. Level six is translating every depth const templates all of the standard packages, and level seven is world domination. Of course, everything is Debian is translate. So I got seven points. All right, it was more like kidding, including kernel messages. I think it's a bit hard work. But you know, windows speak French to me, so we should do it. Okay, what's the future, except translating the kernel? We of course need to add new languages. I just added 11 languages, sorry. Some very small languages, very few spoken, and some quite white spoken, such as Indy. We need for this more locales for people who attended Dennis Talk just a few minutes ago, which is not easy to do. We need probably for this to have an easier to use framework, because most of the new translators are not very skilled to our SVN commit, and so on, and so on. So we need very simple framework. So I put a little thoughts, but there are already, ideas are not very clear, not matter, in my mind at least. But it's not a word clear in my mind. New languages, we need a graphical installer. This is probably the main point in localization for the well-combining languages. We talked a lot with Jalda about the support for Indy and all other languages from Indy. They are very tricky to support. We need to start depending on unicode text mode phones, the one we show because a lot of characters are missing there. We need better right to left and bidirectional languages display. Actually, we made a big progress during that conflict because now, Hebrew is right aligned. And before we had Hebrew right to left, but left aligned, which was silly. And of course, we need to final to universe domination and support Klingon to France for the installation guide. Thank you, Christian. So let me start off by asking a few questions. Who has actually done installations using DI? Well, that's both people. And who has used the installation manual while he was doing that? A while? While or before or whatever. Well, quite a few people, but absolutely a minority. And that's part of the problem with manual, I think. So these are the areas I will cover during this part of the talk. For technical aspects, I've covered some of them in the paper. So if you're interested in how the installer is written, how it's built, how it's translated, then please read the paper and visit the manual website pages because there's some more information there. The basic thing about how the manual is written is that there is only one source for all architectures. And there's a heavy use of conditions that makes some paragraphs appear in the build for one architecture and not in the build for other architectures. This makes it fairly hard to work on the manual because you have to keep all those relationships in mind and you will be confused by text that concerns an architecture that you may have no knowledge of. The manual is available in four formats, mainly published in HTML and is available from several sources. The official website has the current manual for the Sarge release and that is still being updated. So if you're looking for the latest version of the manual, please don't use the ones included on the CDs, but go to the official website. There's also a package Debian installer manual, but that has the same drawbacks that was built at the time of RC3 release of the candidates of DI. And so it's somewhat outdated. The development version of the manual has recently been updated so that it now reflects the edge version of the installer and that's between quotes because well, we may backport some of the new developments that are in there at point releases for Sarge. So then they will of course go into the Sarge version of the manual. So here's the status of the manual and as you can see, it's still largely based on the manual for Woody and as that was made on bootfloppy, or based on bootfloppies and there's a really big change from bootfloppies to DI, that's not a good thing. It's also not very well balanced. There are few areas that are covered fairly in depth like how to set up a a net boot server for net booting, while other areas like the details, the more specific stuff you can do with the DI, like details of preceding are not covered at all except by means of an example file, but it's not like written out what your options are and where stuff starts to happen if you do it a certain way. The big black border is there for a good reason. For a number of architectures that are listed, the manual includes this warning and that's because, well, since Woody, it has not really been checked for that architecture. So the information in there may not be accurate and what we really need is people involved in ports to care about the manual for their port and help us to check the manual against actual installations, tell us what's wrong there and if at all possible, help by submitting patches to the manual. And I'm, of course, willing to help you find your way around the XML source or even if you don't want to bother with that, take the HTML page, copy stuff of that, change it, submit the change text and I will worry about how to get it into the XML source. That's no problem, but we really need help in that area. So for translations, originally we used docbook.xml and originally the only option translators had was to take an English XML file, copy it and just translate the text that's in there. And at that time we had seven to 12 languages, seven languages were fully translated, the others were in various stages of progression. Last year we made a big improvement by adding support for PO file translation and that's drastically increased the number of languages languages that we now have for the manual. It's, we have currently 13 full translations and another six are being worked on. Besides English, you can see which languages are supported and especially I think the oriental languages are very well involved here. So what are we, what do we want for the future? If possible, more translations. There are also a few languages for which we currently can't build the PDF version of the manual, mainly the oriental languages, Russian and Greek or rather everything that really uses different characters set or font rather than letter type, then English and Western languages. I really hope that we can get there by also getting more work done together with the DDP project. I've heard that they would like to switch from Debbie and Doc, which they're currently using, to Docbook XML, well we are already doing that so I guess we could learn from each other and I also hope that for example the people in the oriental communities can help work out the PDF problems because they must have solved that already, probably. And the last thing is that we should think about restructuring or splitting the manual. Maybe into a guide for newbies, people installing Debian for the first time where we cover just the basic flow of an installation and a second guide which goes more in depth into the features of the I and how you can use it to customize how, for instance, derived distributions can work with it. So your help is very welcome in this area. That's the end of my part, I'll now hand over to Joey. I'd like to finish up the talk by talking a little bit about the future of DI and how you can help and get involved if you're interested in doing that. So I thought, first of all, I'd look back a little bit. These are two graphs. The topmost graph is how many people have committed to DI each month in the five years since the project was founded and the red commits or most are just everything that isn't a translation, green is translation commits. Then actually a number of people who've committed translations each month. So as you can see, we've grown the team quite a bit. Over the past, over mostly of this year, it's fallen off a little bit as we just tried to settle things down and just get everything stabilized for Sarge. You can see on the bottom graph here this is the actual number of commits each month by translators and by developers. And you can see that we did have some big peaks and things have again settled out there. If you look at these graphs in detail, which I probably shouldn't do, you can find all kinds of interesting events in here, which actually I should probably ask Christian for, because I'm forgetting them. But for example, you can see when we began to add lots of translations here, you can see a peak, which is, I believe this little peak here in 07, 2003 is around the DebConf in Oslo when it really began a lot of work and then we have several beta releases and so on. And anyway, the interesting thing from this graph from my point of view is that it definitely was up until the right, which is a marketing term, I believe, pretty well until we started stabilizing things out for Sarge. And I think it'd be good if we could pick development back up and really get some energy back in here and start doing lots of cool things again. So to that end, here is a slide which is very much not Zinni compliant. I believe it has 14 items on it, so I don't expect you to remember at all. But it is just some, very few of our to-do items. You'll find most of these in the paper. A couple of them have been added during DebConf here just based on feedback from people and things that have been brought to my attention and bumped up the to-do list a little bit to see if you can see them here. So I don't know if I have time to go over the whole thing, but I'll do a few of them. The topmost one sort of affects Debian as a whole. We would really like to move over to using UTF-8 by default as far as the installed system. DI already uses UTF-8 throughout, but you end up with a Debian system that isn't in UTF-8, which can be a little bit of a problem if your native language does need UTF-8. Next two items here. DI updates for Sarge and support for installing Sarge using the Edge installer are basically two different ways that we could attack the problem of having Sarge out there with a 268 kernel and no newer kernel version and lots of new hardware coming out. We would like to come up with some way to get newer kernel versions available using the Sarge installer. That's probably pretty technically difficult, but we at least need to do it for security fixes. As far as supporting installing Sarge using the Edge installer, that's something that we expect will happen and we'll just continue to support the installing Sarge throughout the lifetime of the installer, hopefully. The Sarge installer actually supports installing Woody to some extent due to the works of school Linux who actually use it to install Woody, so it shouldn't be a big deal. Next one is a big one, of course, the graphical installer. We do have a graphical installer, but very few people have actually managed to build it and get it to work and we do a lot of work in that area and once we get it working, a lot of work on polishing it and making it nice and actually taking advantage of everything you can do with a GUI. And I do think that's an important thing because it'll pull in a lot of new users who may be a little bit scared by the current text mode interface even though most people do find it fairly easy to use. Also, well, next one, improving automated installation. We do have a fairly good automated installation at Debian already using the installer, but there are some little areas which make it sort of difficult. The fact that you have to pass a whole lot of kernel command line parameters when you're booting, just to get it up to the point where you can automate the rest of the install can be a big problem. It makes it really hard for people who aren't intimately familiar with that stuff to get it working and I'd love it if we could just have some very simple documentation that walks you through every step of setting up an automated install so you can have your own CD image that automatically installs Debian exactly how you like it or you can have your network like we have here, netboot, DI as soon as somebody plugs their machine in, it'd be great. And so that's an area we want to work on. One of the ideas along those lines is to use DHCP for sending all the pre-seed information across the wire. There's some other ideas which could be worked on there. Next one is one that I threw in for the fun of it, encrypted file system support. I think it'd be great if you could just boot up DI and install your system with encrypted root file system on your laptop. And I don't know why nobody has worked on this yet but as far as I know nobody is. And I think it'd be a wonderful thing and our partition was actually designed with this as a specific feature in mind from the very beginning. So I'd love it if somebody out there did that. Another area where we need some work still is in hardware detection. Some of the big problems that we know about are the serial ATA drives pretty much. You know, they work sometimes. A lot of the hardware doesn't work. Apparently some of them that should work as far as the kernel support still don't work in DI. We need somebody or quite a few people probably to figure out individual cases why these drives don't work and get back to us with all the details of what we need to just load the modules up in the right order or whatever so they work. Which should be pretty simple if you actually have a SATA drive that doesn't work. I'd really encourage you to pound on it until it does. Other issues as far as hardware detection are currently we're using Discover in DI. We're thinking about using Hot Plug. We're thinking about moving to Discover 2. Haven't really decided what to do there. But we probably can't stick with Discover one forever and Hot Plug and Udev sort of go hand in hand and we're probably gonna have to move to Udev pretty soon because they're dropping DevFS out of the kernel. They don't think anybody uses it. Another issue in hardware detection is that if you have two network cards right now, it's fairly common that you'll install and get one of them as F1 during the install and then after you reboot, you get it as F0 during the install and after you reboot it will be F1 which completely screws up the rest of the install of course. That's really fairly difficult to solve completely just by loading the modules in the right order because it's basically just an ordering issue. Which whichever order you load the modules and you have to make DI and Debian exactly the same. So an alternative is to use Ethernet device naming so that it doesn't really matter if it comes up as F1 or F0 because you've given it a nice sane name which is something I'd love to see rolled in the DI. I think that Ubuntu already has code in this area and we just haven't gotten around to doing it and it's also to some extent, this like UTF-8 support is something that Debian has to decide they wanna do. It's not something that DI can just foist on Debian. So a lot of these issues come down to what Debian wants too. Next one is another good example of that because we are in the process of splitting out non-free firmware and drivers from the kernel and that means that DI is gonna have to deal with it somehow and probably requiring that users load it from a floppy or something isn't gonna make a lot of people happy. So we have to come up with better ways to deal with that. We've already done a little bit of work with using the NIT-RAMFS which lets you basically append the modules to the end of your DI boot image but we haven't figured out what to do about CD installs and all this is still fairly up in the air. We haven't figured it out. So the next issue here is an issue which I don't know if anybody in the room could help with but we would dearly love some help from people who can help us support people who are blind using the installer. Right now we do support it but only if you install from Floppy's which is pretty weird. Another one which since I'm in Europe I thought I'd mention is installed from PPPoE. Seems to be pretty big over here. There's even still some people here who use ISDN and we occasionally get requests for that and that's definitely possible to add to the installer at this point. It's a simple matter of coding and it's probably not even that hard. We already have all the modules there. We even have PPP in the installer if you need it. You just need a little bit of glue code to make it all work. So let's see. Yeah, the next one I think I'll skip for right now because it's something that's just my pet peeve but when after that, disk space checking for tasks would be really nice if when you went to install a desktop task you didn't download a gigabyte of data, unpack it all and run out of disk space in the middle. So if someone would like to work with me to develop a patch for that, that'd be great. I haven't quite figured out how to figure out how much disk space a task uses at runtime without being excessively slow or ugly or something. So I really appreciate some help there. Next one, there's a lot of work that we could still do to make it easier to customize the installer to let people put their own kernel into it and that kind of thing. We need more documentation along those lines and so on. So in the final one, which is I think probably one of the most important things we can do right now is just find a way to find a single question during the install and make most people not see it. And repeat, until done. So that's my enormous checklist of a few to-do items. And I think I'll open it up for questions now. So questions from anybody here. And I thought I'd also mention that we're gonna have a meeting today at seven. It's over in the glass walled room. And everybody's welcome to attend, especially people who've already worked on DI but anybody who's interested or would like to help or whatever, welcome to come. So questions? Anyone? Jodor? Jerry, yesterday I heard that Ubuntu is also working on a graphical installer. Are they working with the Debian team or this is a separate project of their own? I actually haven't heard much about Ubuntu's plans for a graphical installer. I bet it looks like Mark's gonna tell us all about it. Colin continues to hack. I think he did the GTK stuff for DI. That's right, he did do that. But we're mostly likely to sort of do a copy from live CD thing like Nopex. So we'd have two ways to install graphically effectively, either the industrial strength DI one, which would let you configure it in more detail or the kind of copy from live CD approach. And you're gonna use DI for the copy from live CD approach or something still sort of. Okay, so the live CD uses DI, he said. Got a question? Yeah, if I've seen about what, which areas of Debian you've talked about, I think it really touched most of the areas of Debian, so have you had the feeling that the Debian installer was something like a push in many areas of Debian to bring new things in or did it just take things that existed and integrate in this installer? And how is your relation to, for example, package maintainers of a DHC client or something like that? Well, you know, one of the things about DI is that it's sort of like a little miniature Linux distribution based on its own package format and all that. But the fact of the matter is that all these little packages are maintained by people in Debian. Our DHCP client, you'd have this maintained by the same people who maintain your DHCP, your DHCP DEB. And so we do have fairly tight lines of communication there. Of course, there is a lot of work that we've done to push changes into Debian that make it easier to install, you know, things like people just have to use Debconf now and we had to go through and make sure that was true. And as far as things like UTF-8 support, you know, we have to let Debian know that it's a problem that the installer has to fall back to non-TF-8 at the end. And so I think there's an ongoing process there of just communicating ideas back and getting things from Debian as soon as they become available, of course. You know, we work closely with a lot of different areas of Debian at this point. I hope that answered it. Next question? Yeah, I was curious about what you guys are thinking about how you're gonna go about doing graphical installers, because I know some of the issues with doing that and why it hasn't been done so far is because it's very architecture-dependent. And I suppose, like you can't use the Piggy installer from Progeny because it's I-386 specific, but if there was some initial architecture detection at the very beginning to figure out if you can use that, would you use something like that, or what are your thoughts for dealing with that? Okay, as I understand it, the current graphical installers that exist is a GTK front-end for CDebconf, which then runs on top of either X or a GTK frame buffer interface. And we haven't quite settled on which of those to run it on because that's one of the harder parts of the problem, of course, just to get a display up there. As far as hardware detection for getting the graphical installer going, and ripping something out of Piggy or something like that, we found it's really hard to take very much from another installer. We can definitely take ideas and we can take small pieces of code, but it's just the way these things work. It's very hard to take larger chunks, fortunately, which is actually something that DI aims to solve to some extent. So I hope that answered. I also wanted to remind everybody that we do have three other people here who could have specific questions addressed to them if necessary, or if y'all have anything that you would like to add to any of my answers, please. Okay, so who's next? Okay, Sapphire. Let's try to get one over there next time. My name is Sapphire Cicero, which I come from Bosnia and Herzegovina. I work as a DI translator. I just have one question regarding the development of DI. That is the speed of the development. I know that we have had the problem so far in relation to kernels in DI. I mean, in relation to updating kernels, especially 2.6 ones, to a new revision. That's why we have a 2.68 in Sarge, and not some more recent kernel. Because it was very hard for us to keep up with security updates and supports with kernels in Sarge and likewise, other kernels which are in the archive. I'm just wondering if there are any changes being made now or are planned for the future so that we can avoid such a mess because we have so many kernel packages. Okay, thank you. That's a great question. Part of the answer to that is we've already started work to address the issues that made it very hard to update to new kernels toward the end of the Sarge release process. And we were working with the kernel team pretty closely because they were very interested in this question too, of course. I do think it's important to note that this was the first time that we did it and we've learned a lot and we were very cautious about some areas as far as getting DI out there for Sarge. So for example, I believe that the kernel team still intends to upload 2.6.12 today. And I intend to update DI to that within like half an hour of their upload. It's already, as soon as they give me a dip. So I do think we can improve. I think that we're going to, okay. Anybody else? Yeah. It's important there is also a need to have creative testing when a new kernel is implemented in the installer. Because it will break for people who have previously had successful installs. Yeah. One question I guess mostly for France about the documentation. I've heard about preceding for a long time. I've sometimes read that blog entries about preceding, I have yet to find documentation about preceding. How do I get preceding done? Is there any basic documentation to get me started or do you need help on further documenting it? What is the current status? Well, there is basic documentation. There is a section in the manual about preceding and there is an appendix that has an example precede file. And you can take a lot of tips from that on how to get started. The problem is that the more advanced features of preceding are not documented there. Like if you used early command or late command where exactly does that command happen? You really need to test it out a bit. And also for some questions you will just need to get into the code or get into the DEPCON database to see what values are being used and such. There's no full list of values that can be preceded. But I don't think that's going to happen anyway because there's just too many options. But a little bit more documentation about the possibilities you have with preceding would be very good to have, yes? On that subject. I've got a worked example of preceding which makes it fairly easy to get up and running pretty much instantaneously with how to and how to set up your media for CDs, USB sticks and PXC booting. And it's at hands.com slash D minus I. I'm quite happy to move that into the manual and I'd really like to get some features. So there are a couple of features. I'm doing it against the SOG Debbie Installer at the moment and I was trying. So I've got a few nasty hacks that patch into the image because I was trying to use a stable base to build my stuff on rather than building on a moving platform. So if people want to have a look at that, I'm perfectly happy to take recipes from people and add that into there or have a central repository for recipes that we put into the main subversion. But I think it'd be really nice to be able to get it down so that you've only got one or two parameters on the boot line will make it into a preceder and say, I want that sort of a machine and get you there. So that was my vision and I'll hopefully try and get that into the main subversion fairly soon. There are a couple of features that I need to work on and I've been utterly useless at getting anything to boot because I haven't got a spare machine this week. So as soon as I get that sorted out, I'll work on that. Related to that, I was wondering what criteria we're going to use for back porting features into the SOG. So that was hands.com slash D minus I and it's got a sort of read me and a few how tos and it's a spelling mistake, so I imagine. Let me just say that I think it's great that Phil's here pimping his preceded files and I want to see more of that and I do think we should work to get it all merged, get the documentation and merge back in and so on. That's great. You asked about back porting stuff in the SOG. Our criteria right now are fairly strict but I think that we do have the potential to make another point release a SOG with a new version of DI and we just have to work it out with a stable release manager and all that. So it's still sort of up in the air at this point. So I think that I should probably stop now. Do we have time for one more? No, sorry? I think that's true. There is information about preceding on the wiki. There is some more there. Well, I don't, okay, since we don't have much more time I'd like to thank you all and remind you that we do have a meeting today at seven. So if you have more questions come there. Thank you.