 Okay, I really don't have to say anything real since you can see everything on there. It's about a deviant-based distribution for schools in Switzerland that I saw in the program. And here to talk about that is Gauldens Steinlin. Yeah, thank you for the introduction. It's hard to be the one speaking about after check-up at Applebaum. I think people are still out, so maybe a few more will join us later, but I'll start anyway. My talk will have kind of two parts. First, I will give you an overview about Lernstik. I think most of you haven't heard of it at all, so I will tell you what it is. And I will briefly talk about how deviant could help improve Lernstik and what we try and want to improve to be better citizens in the deviant community. What are the project goals? The project goal is described as providing a mobile and secure learning environment. We want to run everywhere, so Lernstik should be able to run on old computers, maybe 10 years old computers or even older. Some schools have really really old hardware. They get hardware donated from somewhere that others already thought it's too old to use anymore. It should have a low administrative overhead for the schools, so no administration basically should be needed. They shouldn't need any servers. They should be able to use it with minimal Unix and Linux knowledge themselves. They shouldn't have to also need to have user management and stuff like that, so they have to enter all their students in a system that all shouldn't be needed. We want to be ready to use so all the software that they might want to have should already be installed. So they don't have to deploy it and afterwards install additional software for them to be useful, for it to be useful. That's not necessary, but it should enable kind of bring your own device scenarios where students can bring their own computers and work with the system in their school, and that's not exactly bring your own device, but it comes with it. They should also be able to take the system home and use the same system they use in school at home. We have a focus on non-technical end users, so we're trying to build a system that is good to use for non-technical users. Not only the students, they're sometimes just also too young, so they have to learn to become technically competent first, but also most teachers are not very technically proficient. And we want to have a stable-based system plus more or less latest up-to-date applications. So how does the project look like? We don't have much project structure at all. The project is funded by the University of Applied Science of Northwestern Switzerland. The university or the one person employed by the university that does this project provides free support for the schools in Northwestern Switzerland, so if Switzerland is grouped in canteens and this university is funded by several of those canteens, if schools inside those canteens want to use it, they don't have to pay anything for support. I mean it's free software anyway, you can download it and use it at no cost, but if you want support from us, others have to buy support contracts. It's usually done on a basis where you pay something per year per student. We're two people working part-time on the project. The founder of the project is Ronis Janker, he's also employed at this university, but doing lunchdeck is only part of his job. And the second one is me, I was kind of brought in like I think three years ago and my involvement is roughly working one day a week on it. And we don't have much infrastructure, we have a package repository, we have a download site where you can download the ISO image and we have our git repositories on GitHub. We have two variants of the system, so the standard learn stick is about 4.3 gigabytes big, it's the size that just fits on a DVD. It includes various desktops, we want to offer people a choice of desktops. So we have GNOME, KDE, XFCE, and even the smaller ones for those that really run on low-end hardware where the big desktops don't work. This is an open and unrestricted environment, so people can tamper with it, they can play with it, they can learn with it, and it has passwordless root access. But we don't have any network services enabled on it. Then the second variant is the learn stick exam environment. This is about two gigabytes, it's a restricted environment you can use for exams. It disables all access to your internal drives and to external devices that are not the learn stick system itself. It has a firewall network and it's used so schools can do exams where the students bring their own computers but they can't bring their own materials with the computers. And we do custom builds for our support contract customers. There's lots of proprietary learning software, some of which is even mandatory or a school decided that for their school this software will be used in this class and stuff like that. And as much as we can, we try to include this into their builds and make it easy for them to use. So our philosophy about non-free software is a bit like we have to do compromises to at least bring people to use our free system. We hope that in the process of getting to know the advantages of this free system they will see the disadvantages of their proprietary software. So what is it? Technically it's mostly Debian. We use Debian stable plus Debian back ports. Plus we do our own back ports of some stuff. Plus some third party packages. Plus some learn stick specific packages. Third party packages is for example if upstream projects build newer versions of Debian packages of newer versions we tend to use those if they're half way reasonably done. But it's based on Debian live so it's a live system. And we have in our latest version the Chessi based version we'll have GNOME as a default desktop but all this are available. As you can see here also in this mix it's also a compromise of the resources that are available. We just can't, we just don't have the time to redo packaging that was already done somewhere else. So because the options then are just either not include this or include the package that exists we mostly prefer to just take what exists. Our main distribution method is still to have an ISO image and this ISO image includes a highly compressed SquashFS. As our users are not very technical many of them still burn really physically the ISO image to DVD and prefer that to then create USB sticks from it. So the usual way you use it is that the software that the live system does is on the ISO image you copy it to a USB stick and we have a special program to make this process really easy. The more advanced users know how to use virtualization and don't burn the ISO image anymore. We're on E386 as the architecture just because it's more universally usable. It runs on all AMD64 computers while AMD64 doesn't run on all the computers that currently still are using Lensstick. We're planning to move to AMD64 if the last E386 users will have moved to our newer hardware. And we're trying to keep the Delta to Debian as small as possible. So I will quickly show you some specific hardware software we've done. The first is this program we call DL Copy. It originally stands for Debian Live Copy. You can't install a copy with all possible Debian Live systems. It has quite some assumptions that are specific to how we build our images. And with this you can install on storage media, you can repair or upgrade your sticks and you can even have a stick and convert it back to a new ISO image. And the installation looks like this. You will see all the sticks that are connected to the system and you can say how big the so-called data partition should be where the modifications to your file system are stored and you can see set or no, that's the SquashFast partition is kind of fixed. And you can have something called an exchange partition which is that is Windows accessible so if you want to still use it on other operating systems. Then we have LearnSpeakWelcome, that's a small wizard that runs on first boot. You can do like download additional non-free software like Google Earth. You can configure the teaching system which is a system that allows the teacher to see the screens of their students and some other things. Then one nice thing we developed is XML Boot. XML Boot is a GFX Boot payload. GFX Boot, I don't know if you know it, is a graphical interpreter to have graphical boot screens for mainly these Linux. And it uses a post script like language and Ronnie implemented this nice boot menu in this post script like language with like very few registers and stuff. So on boot you see this, you can select the language, you can select the desktop you want to boot, you can select if you want to use your data partition or if you don't want to use it or if it should be read only. It's kind of usable by non-technical users because it's easy to select but I always see people trying to use the mouse and obviously the mouse doesn't work here. It's just keyboard only. Then we have a few more additions which don't have good screenshots. I developed something I call Lunchstick Guest. The use case for this is you have Lunchstick installed on a computer on its hard drive and you don't want that the students have to reboot it all the time to work with their stick. So they can plug in their stick, remount their system so that their home partition on the stick is the home partition of the Lunchstick user on the system and then automatically lock them in. So the software is on the computer but the home is from the stick. Then we have the firewall we use in the exam environment. It's a very simple thing with IP tables and tiny proxy and it's denied by default and it allows you to whitelist some stuff. And that's an old project of Ronny. JBackpack is a simple backup GUI to Arif backup. So why we're a Debian derivative and why we're not just a Debian blend or Debian itself? Where do we deviate from Debian? So we have some non-free packages in the base install. It's basically hardware support. We pre-install the non-free graphics drivers because for many schools 3D graphics for games or Stellarium or other these things are quite important and the performance of the non-free drivers is still better. That's one point and the more important point is that there is still hardware that just doesn't work with the 3D drivers. And we install firmware because I mean you can't live without some firmware on most computers nowadays unfortunately. We do some optimizations for non-technical users which are mostly small things but some of them are not really generic enough to go to Debian. We do bug reports for these if it's applicable but as we have Debian and KDE, GNOME and KDE installed side by side because we want users to be able to choose but we want only the KDE applications to show up in the menu if you choose KDE and the other way around for GNOME but that's not something you actually want in Debian because in Debian you would just say if you don't want this application just don't install it but as we're a live system we don't have that option. And there are some live specific customizations it's mostly fixed up for hardware assumptions. One example is that some programs store sound card configurations in home and stuff like that. Some of this is upstreamed if the Debian live maintainer accepts our patches. And we have secure boot support. We did that not because we really like secure boot or we think as we do it now it's also not a security improvement at all but our users don't know how to modify their BIOS settings. So we would have been kind of just not being able to run on all these Windows 8 shipping computers where secure boot is enabled by default because of Microsoft policies so we went to the process to get our shim signed by Microsoft. I learned quite a lot about how this works and the policies around it by doing this and if there's interest in Debian I'm willing to help but I'm a bit wary of the political side of it so I didn't push it hard. So where could we improve collaboration with Debian? Currently there's not much collaboration with Debian Azure. I mean we profit from the work they do in terms of learning software that's packaged and stuff like that but we don't have any direct contact. I think that would be interesting to have. I don't know if someone's working on Debian Azure is here in the audience. We should try harder to upload all our stuff to Debian where possible. These are some of the packages that I think could perfectly well go to Debian. There are others, mostly those that are written in Java that need some cleanup first. They don't build cleanly currently. They have packages that are not really policy compliant but they're free software. It's doable. It just needs to be done. Some packages are really only useful on a learn stick system so we have something called learn stick config that is our additional live config script. If you know live Debian live, live config is the last component that runs of Debian live. It's run after the unit started first and it does all the customizations one needs for a live system. We have some additional scripts for us. I'm not really sure if it would be appropriate to upload those to Debian or not. Some of our packages are just hacks and I don't think they should go to Debian. One example is that we do quite a lot of file diversions for small files. Like I said, we're changing desktop files and instead of having to, if we change the desktop file of LibreOffice, having to rebuild LibreOffice, we just have a package that diverts the desktop file, which is not something you want to have in Debian, but it solves two problems for us. We don't have to wait hours to build LibreOffice and if LibreOffice gets an update, our diversion will still be there. And we're thinking about uploading some or even all of our own backports to backports.debian.org. And there are two things that currently stop us from doing that. One is that I'm the only DD on the team, so I will have to do that all. The other thing is that the expectation for backports is that you kind of try to maintain them through the lifetime of the stable release and we're not really sure if we're capable of doing that in a satisfactory way. And the third is that currently we don't contact package maintainers about doing backports and I think that's something that's advised for backports. It's usually not a big deal, but it still needs to be done. And we're in the process of making our development process more transparent, so we will have a week soon. We already have the to-do list in our Git repository, but it's kind of probably still hard to find. Yeah, stuff like that, so it's possible too. Okay, yeah. That's my last slide. How can Debian help? We always appreciate backports. We're very happy if people that do, maintain desktop applications do backports to stable. You can advertise it in your school, in your community, wherever you see it fit. And we have some nice ideas for the future if people would want to take an interesting, challenging project, like replace XML boot by an Excel program running in the Inetadi, so you can really use your mouse and do all the fancy stuff. Liveboot currently has lots of loops where it waits for devices to appear. It would be really nice to have this that ported to Dracut or some other event-driven model. And the SquashFS plus overlay approach has its own problems. It would be really nice to move to something that's more snapshot-based, but SquashFS had the one big advantage that it does really, really good compression. I'm not aware of anything snapshot-based that can do that much compression. I don't know if you have time for questions. Not really. Not really. You have to take them during lunch directly, I think. Okay. I will be outside, so if you want to ask questions. Thank you.