 Well, then let's start. Welcome to everybody for our Debian Live talk. This is Marco. He does some stuff. I'm Daniel. I do also some stuff in Debian and together we do Debian Live. The outline of our talk is today that the talk is very simple. You do not have to worry about anything. If you don't understand something, just shout because my English is very bad. In the first step we show you why we do Debian Live, why it's needed, and then we talk about how it works and then we show it to you. First of all, a live system is not very different from a normal system. Basically, it is booting without having to install the operating system before. Most of the time you have a read-only medium. Nowadays you can also use USB sticks, which are quite on fashion. Typically, because we don't have read-write medias, the installation is non-persistent. That means if you are on your route, you can boot again and everything is back. The most important thing about live systems is that they do not alter the installed systems. You can do it on your production server for rescue purposes or everything else. It doesn't kill your hard disks. As you can see, there are a lot of use cases for live systems. For example, for end users, if they want to see the newest and greatest bling-bling, it's great for teachers because they can give it for free to students, for example, to show or distribute photos. Developers can use it too for having consistent and not changing test environment. For system administrators, it's great to have a rescue system and basically just everyone needs it. But what is wrong with current live systems? One last year in February 2006, we started to make thoughts about live systems and most of the points you see here were valid then. Nowadays, some points of them change it, but not all. From a very Debian-specific point of view, all these live systems are developed outside of Debian, so Debian does not have an official live distribution or live system. Most of the live systems out there do mixed distributions because they, for example, based on testing, but include new stuff from seed to fix breakages. We don't do that. Most of the live distributions only support I386 or nowadays also AMD64 because it's the one the most mainstream users use. Often they change some package behaviors like they said they're custom wallpapers or they change fancy in its systems colors, they're stripping packages, for example, by removing documentation so that they have more space on the live system. They're including unofficial packages. Most importantly, they're almost always not using the Debian kernel. They package and maintain their own kernel tree, which is crap. Due to that, every live system you will find is for a specific purpose. Since you can't use Knopix very well for rescue purposes or you can't use Knopix, there is no Knopix for, let's say, Spark or Alpha architectures. Most of the live distributions are not available as a USB stick or they only ship on DVD media or they don't offer network technologies. At the end, you see there is no one size fits all. You need to customize your own live system. If you want to do that, you can buy books which teach you about remastering Knopix. Just the fact that such books exist should tell you that it's a wrong way to remaster a system if you have to read a book first. Now, as I said, Debian needs a known live system because it should be an official sub-project so that it reflects the official state of the distribution. It means if someone wants to know, does Debian testing today support whatever hardware, you can say test this live CD. If it works for you, it works in Debian because it's the same. We want to have it run on as many architectures as possible. We do not change packages. We buy the Debian maintainers to fix their packages so that they work on a live system too. We do not include unofficial packages. We want to tame Debian. And most importantly, we use the normal unchanged Debian kernel. It means if you go to your local hardware vendor, boot the system and see it works with that kernel, you can trust that if you buy it and install it at home with Debian, it works too. Okay, now it comes to the how part. My English is a worster than Daniel. We will see the typical boot system process. All system, both live and not non-live, just power-ups. Try to boot the BIOS. The BIOS, try to boot from some media like Rdisk, recent BIOS from network, from USB sticks. Then the bootloader, try to boot Linux. Try to because it needs to find the right partition where Linux is stored. Then Linux should execute an initial program, the first process from the media found by itself. It was. Now the things are a little different. Because Linux boots a small root file system, previously called initred. Now it is an initram FS, which is a CPIO archive of a small root file system compressed that have the duty to find the real root file system. Okay. When the initram FS could found this real root file system, it executes the real init on it. This applies for both types of systems. In the BIOS system, what does of different? Linux loads the initram FS, then the initram FS scans all the devices connected to the system, all block devices, so also optical devices, to a particular configured directory. Finds what is the real only file system. You could imagine a file image on the CD, for example. But not only that. Then the trick is to produce a variable file system from this image, this read only image, and RAM disk. This is the union FS working. So union FS can provide us a variable root file system from a read only media using a RAM disk. Then our system, live initram FS package, does some little magic to configure users, to configure hardware, prepare the network. Okay. All it's ready, it launch the real init. The in live initram FS package is a fork of Casper, which were used formally on the first, the second live CDs from Ubuntu. We took some extended, then it was recently forked. And in seed and testing, there is this package in H. It's still called Casper. It's under development because not all the features are so stable or so beautiful. But some features permit to boot from a compressed file image, like squash FS, and not compressed file image, like an X2 image file, or plain directory. Plain directory, it's mainly suited for network booting, is not with the optical media in mind. It can boot a system from all the block device, so RDS QSB sticks, also anything that could be recognized by the kernel at the start. Then two different methods of network device are provided, but more can be added. Formerly, NFS and CIFS, that was implemented because we found some buggy routers that doesn't couple well with NFS, strange thing. Then encryption could be used. So the image file could be encrypted. And the people who use it at the beginning of the boot process must provide the password to access the whole system. Also, all the features are persistence. So if we boot the system, we modify it, change maybe in a desktop environment where the icons are, the desktop background, install some other software. If we have on the system writable device, like USB sticks or partition, we could, in the next reboot, have the system as we modified it. So all the work could be made be some way permanent. If you do that on a USB stick, you could bring the stick with yourself, go on another machine, boot the same system with the same sets of windows open, maybe also. See the difference between persistence snapshots and multiple root FAS images are just how does a problem is resolved. So persistence means that all the right, all the modify you do on your system are written directly on media. Snapshots means that you decide or the reboot decide when your modify should be written on media. And multiple root FAS image means that you could add on a remaster of the CD just the difference of your system. And then in maybe a multi-session CD or DVD, you could bring with yourself your modify. OK, it configures that boot some hardware. The keyboard, it permits you to read some boot parameters at the boot loader. So you could have a live system that is well tailored for different languages, different kind of setups. Also, it supports at the boot to choose a particular set of live image to boot. So with the same media, you could have a KDA desktop, a rescue system, or a more complex system. And then you could also accept proceeds like Debian Conf proceeds. So you could pass them a file or a list of variable content spare and have some Debian packages reconfigured before the boot of the real system. And that's how. And Daniel will tell you how to create. OK, live init.rmfs is the black magic used at the boot time inside the boot live system. And live helper is the set of scripts you use on your host system to create the live system. At the moment, it's split it up to 65 individual shell scripts. So it's pretty flexible. The standard way is to run all the four stages means. In the first stage, you bootstrap. This is done by just calling CD bootstrap or Debootstrap. You can choose it as an option. In the Chainshoot stage, all packages you want to have on your live system are installed. We support local packages. That means you can throw all your third-party dev files into a directory, and they get automatically installed into the live system. We support a set of predefined package lists, means if you want to say, oh, I just want KDE and just one package in addition, you say, build me KDE, and that's very easy. You don't have to know which KDE packages you all need to include. In the binary stage, we built the final ISO image if you want a CD-ROM or the USP image or a Netboot tarpaul. And optionally, you can do a source tarpaul or a source image. Doesn't matter. This is particularly important because most of the live distributions you find out there do not provide this possibility. Means if you want to redistribute this binary image and you are obliged to the GPL, you have a problem. Where do you get the source from? And since Debian always distributes binary and sources at the same time, we do it, of course, too. So this is a very easy possibility to comply to the GPL. Although LifeAlper is a framework to build your own live city and you're very welcome to try it, we have set up an auto-builder on life.debian.net where we auto-build KDE desktop images, GNOME desktop images, and XFC desktop images. These are from the package selection point of view the same as you would do a regular DI install and select desktop environment. For Edge, they are built manually once we do a new LifeAlper upload, because there are some improvements always. For Lenny, we do weekly builds. And for SIT, we do daily builds. This is mostly because the server has too few storage. As soon as we get some more, we could do daily builds of Lenny too. We also have not-so-fancy CGI script, which allows an end user, which has no clue about Linux or Debian in general, to get his own customized life system. He can go to the website, click there, select Options, press the button, wait some time, and he gets an email with a new URL where he can download the image. At the moment, it offers just the basic functionality means about 50 out of maybe 80 options you can specify, but for the website, it's enough. Although Debian Life is already one year old, we still have some plans. And that means, for example, that we really try to arrange the upload of official images to CDImage.debian.org really soon now. At the moment, the only architecture-specific part of the whole thing is the bootloader magic used to create the ISO image. As Life Helper is independent from Debian CD, we needed to reinvent the wheel there. That's why, at the moment, just and AMD64 are working reliable. On PowerPC, I fixed it almost, and Spark and Alpha are really soon to come. The really bleeding edge now is that Otavio prepared UDEP, which hooks into DI, so that you can create a live CD, including DI, which does not fetch the packages from the internet or from the CD, but just unpack the SquashFS image to the hard disk. As Life Helper is the back end of everything, it's not very useful or handy for real, dumb end users. That's why Chris Lamp will implement a graphical application, which is very easy for end users. He does it on behalf of Google Summer of Code, and he has already done some mock-ups, which are quite promising. Unfortunately, there are some inconsistencies in Debian, meaning some applications to rely on having some specific paths they can read out in Proc. That's why, for example, some GnuStep applications do not work in Edge without recompiling them. We contacted the maintainer of those packages, and they are going to be fixed. So in the future, we hope that almost every software is fixed upstream so that they work good in a live environment. Depending on the further development of the InitramFS tools, we maybe are able to add also looks into live InitramFS. And something very beautiful is if it could support resuming. I don't have looked into it much, but it's possible that you can resume a full KDE session in 10 seconds after you press Enter on the bootloader. But this is still future. And now I can show you how we build the images. At the moment, you need to be rude, because if you are not rude, X-term does not support larger fonts than this. I'm sorry. I did already. It's on huge. I'm sorry. Yes, you need to be rude. That's the problem, because CD Bootstrap does not allow to bootstrap as a user. It tries to mount root and would fail. These are all the helpers you don't want to know about them. That's why we have a short wrapper about them. And now let's launch it. As you see, by default, you don't need to configure anything. It just builds you a standard image. Standard means every package of priority standard or higher. If you want to include KDE, you can add that with a flag. If you want to include your own very special package, you can include these two. As you can see, CD Bootstrap is already nearly done. And the next stage would be to install the kernel. By using CD Bootstrap and Debootstrap extensively, we found, by the way, a few bugs in them. And it's quite hard to rely on them, because if CD is broken, you lose everything. So a lot of users always report, Life Helper doesn't work because it fails to bootstrap. And they can't see the difference. That's a bit hard. Now it fetches the kernel. As you can see, it installed Casper, because I'm building an edge image at the moment. Now we installed a few required packages by Casper, like e-checked, so that once you shut down your life system, the CD, if existing, gets thrown out automatically. And now the SquashFS image is done. This is almost the longest sub part of Life Helper, because it needs a lot of disk. IO and CPU. And yeah. Here, our image is an unaltered Debian system means there is still some stuff in the user share doc and the main pages. And that's why it's pretty large for a just basic standard image. It is about 80 megabytes of size. Of course, we also include memtester for those who need them. Now the ISO image was created. And we can boot it. By default, we have configured that the SysLinux boot loader is used on I3D6. But with a simple flag, you can use Grap, which is more handier, but doesn't work on some old crappy biases. That's why it's not the default. As you can see, it has already booted into Life InnerDramaFS. Now it loads the SquashFS image. At this point, your usual hard disk would be mounted. Because QMU is pretty slow with disk IO, this takes longer than, of course, in real time on real hardware. And now, just the normal SysV init boots, like a regular Debian system. And since I didn't include the XORG, it just goes to the console with an autologin. Of course, you can disable autologin or XORG autologin with boot parameters. We have a list of cheat codes like you maybe know from Knopix. And now we would be at the end. And if you have questions, comments, and suggestions, we are very welcome to say that. We don't see both so good. What's on the green sheet, please? OK. If nobody has questions, you can attend tomorrow a buff. And in that buff, Marco will teach you how to build your own life system with Life Helper, which is very easy. OK, I say just a last sentence. And any time you're welcome to join the mailing list, it's very friendly. And you can also join the IRC channel. Is it a release goal to release Lenny with a live CD? For me and for us, yes. You asked if it's a release goal for Lenny, right? Yes. OK, for me personally, yes it is. But as the release team just submitted a mail-to-project or release, I don't remember how to submit release goals. I need to read that through and try to submit it. Is Debian Live already used in some larger environments as a productive system, or is it just still experimental? In the United States, it is used by the safe desk that is a firm that sells distributed systems. They have hotels like for clients as hotels. They sell small diskless systems that boots from Debian Live. And it is used at the University of Padua for their development laboratories. So the students can have a network boot system that is the same that the teacher can give to them on a live DVD. And they use the persistence of USB key to do some work at the classroom and then bring a network at home having the same environment with the same windows opened. Regarding the fact of being able to deliver with Lenny, is it possible to have a DVD actually where the user could either boot Live CD or have Debian Installer regular CD source? So it can be convenient to distribute in the exhibition? Yes, it is the work in progress that he and Otavio did at this DEB camp. And the major has Debian Installer that could be booted straight on, like standard Debian Installer images. The Debian Installer, the same media could boot Debian Live and the same media could install Debian Live. And about the question before, I forgot to mention Web Converger. It's an application by KE to do the internet kiosks. Just in addition, with Live Helper 1.0 till A15-1, which I upload after the talk, you can have a regular live session and a regular DI, which does the normal stuff. Within one media, and you can select at the boot time which one you want to boot. This has just the disadvantage that it consumes a bit much space. Because if you have 650 megabyte CD-ROMs and you lose 50 megabyte for the installer, that's a bit much. And that's why we try to push that live installer thing. But you're always free to use the regular Debian Installer, which fetches packages from the net. And it's just a different flag. If you say, live installer enabled, you get live installer. If you say, live Debian Installer, you get the regular Debian Installer enabled. Just to further comment on, basically, I've based my business around Daniel's work. And Web Converger is a web kiosk system. And I have customers which include banks. And because I didn't really see, I thought my product would be for internet kiosks in libraries and museums. But people see these live systems as a very secure way of getting onto the internet. So banks are interested in other security-type stuff. Military. I've had inquiries from something with a dot mill address. It's all pretty exciting. So I want to thank Daniel and Marco for that. And if you need a web kiosk system, please look at my system. And it's great because my business model is just customizing, building with live helper CDs for my customers' requirements. So they pop in the CD and they get the right locale, the right home page they want to go to. So it's fantastic. So thanks. You too. Question for you now. Well, also for you. But usually with live systems, well, one of the problems I see with sending them to users is that the installations are, well, CDs are a slow menu. So I mean, if you are working with this in real situations. The real situation, for example, if you want to get, if you want to boot up your MacBook and run Firefox, it's going to take away more than a boot from a CD and get into Firefox, which my product does. It's really fast. If you do USB stick, it's like one minute. It beats the hell out of Windows and MacBook or Apple software. So it's a better product for speed performance already. So I don't have too much to worry about. It's true that CDs are, of course, not that fast as hard disks. But since we have SquashFS, which is compressed, you don't need to... The speed is not the importance, just the seek time. And if you have a machine which has a lot of RAM, you can cache the whole image in the RAM by a boot parameter called toRAM. And then it's open office starts in three seconds. My question is, every country's users makes a live CD. This means, do you have an IATN framework, internalization framework? We don't have an internationalization framework. We just permit if the user of choose the right options or the right list of packages that includes also internationalization packages to have at the boot, at the boot time, select one type of languages, keyboard, locale. I can't help but add that I have versions of Web Converger for the Korean, Japanese and Chinese markets. It's just a question of setting the right locale and putting extra packages for the font and the keyboard switching. It's really easy. So you can meet the requirements of internationalization. There is a question over there. I'm sorry, I arrived a little bit later, so you might have already answered this, but I've heard also Kai saying that he has custom images. How easy it is to create such an image if you just want to have some additional packages added on that image. You do have to have your own repository which duplicates the Debian repository? It is really easy because if you just want to add some bunch of packages that is not present in Debian, you could just put them on a directory which it is created at the moment of the first launch of Make Live and created a config directory and you will find a place where to put your packages. That sounds okay if you have only one or two packages but does that scale well for let's say a set of packages which I have in the repository which have... Yes, you can express your private repository with the GPG keys too, or your keyring package. So it is easy to do Debian derivatives. It is also easy to add the software that is not in Debian and not yet packaged. There is some helpers to do that too. There are not so difficult to use. You can just throw in your source list snippets for whatever repository you want to use and say, get me these packages and it fetches them. It's not different. The whole build process is just as you would install a normal system. It's just in a change route but everything else is just the same. And as you can see here, in the config directory we have... What does it say? It's too small. Okay, thank you. In the config directory you can see we have different directories for the helpers. If you put something in change route local packages, then this package will be installed in your live system. If you put a file with package names in change route local package lists, these packages get installed. If you put something into change route local hooks, this script gets executed at the end of the change route phase. It's really flexible. It's just the shit that there is no man page for it. But if you know Depp Helper, I don't want to say that Life Helper is as far as perfect as Depp Helper but if you're familiar with Depp Helper, you won't miss so much. All right, so quick comment before my question. I've already made a few live CDs and live DVDs but I'm really impressed by the toolset that you've created. It makes it a lot simpler apparently. If you could expand a bit more on the auto-builder you have, is that part of the toolset or is that something else? Thank you. It's basically just a cron script which calls Life Helper in a given interval and all the cron shops are in the package under user share, Life Helper examples, cron. So you can easily set up your own. There's another Linux distribution who have live CDs and they have a tool to report and to test the hardware on the computer or laptop server or whatever. Have you planned in some way to try to have this feature that is to evaluate the compatibility of the local device present on the computer and to use this kind of database? Have you used this kind of? No, because Depp in Life is not a distribution, it's just a framework. It means everything which works with Depp in, works with Depp in live CDs too or whatever you use. Yes. The idea is to help you to evaluate the compatibility of the laptop, the boot, the live CD on. And of course, if it boots, it boots and understood. On a related note, there is a project LHCP, which means Linux hardware compatibility projects from Fedora, they initiated this. And it's a set of Python scripts which you run on a computer and it works basically like popcorn just for hardware. And it would be really nice if you can include that in Deppion and also in the live CDs so that you're going to be asked after the installation or whatever. Do you want to submit the hardware report to this site? And I think that's the way to improve hardware lists that you can say it's compatible or not. Because most of the Linux systems are much identical and we should do it in common. Do you support persistent storage on, for example, a new USB stick? Yes, persistent storage could be any block device recognized by the kernel in some file systems. Not all the file systems supported, but it's easy to extend it. We support Windows file systems and most common Linux file systems. But we plan to extend it to some file system in user space type of flexibility. I think we have two minutes. So if there are some more questions here. Do you plan to support running Debian inside of, for example, a Windows system using, say, QMU or other stuff like VMware or whatever? I think there are some Linux distributions supporting that now. We have some Windows Linux integration in our to-do. But for now, it's at the bottom of our to-do list. And we plan to investigate CEO Linux to our different ways of ship Debian have easy for a Windows user to look at what is alive, the system, what Debian boot and the user could looks like. Just a short addition, QMU images are basically hardware images, means if you build a Debian live system for USB HDD, then you can boot it in QMU. As you know, you can boot them on Windows too. For VMware, you can boot them too. VMware does use QMU image types, but has an additional file. That's a file with about 15 configuration options. And that's really easy. And I'm looking forward to implement this that we have automatically created this file. And then for the user, it's like download and click and it runs. Then we thank you. And maybe we see you tomorrow.