 Great, we're here today to talk about a new project called the LTSP Moocow. It was specifically a LTSP Moocow study. I'll start off by kind of explaining the differences between the Moocow and more traditional LTSP implementations. I believe the current release of LTSP is 4.2. And the main fundamental difference between a pile that we're working on and how that works is the current LTSP implementations are essentially their own Linux distribution. It happens to reside on a file server served over in a press. All the binaries are compiled specifically for LTSP. All the packages are specifically designed for LTSP. What we've been working on is essentially building a similar environment using standard Debian packages. This has the huge advantage of being able to use Debian security update system. Any package available for Debian is less available for the LTSP Moocow implementation. And it gives you a lot more flexibility. And we're reusing less code. We're wasting less code. The Debian Edu project is using the LTSP Moocow implementation because before the packages for the old style LTSP took up something like 15 megabytes, I think, whereas this can reuse almost all of the codes from the installer CD so that the CD, it's just a less than a megabyte of code that they have to add because it's reusing most of the packages. So that's the fundamental core difference. The LTSP Moocow project was initiated by Matt Zimmerman, I believe, first implemented in Ubuntu, and I put a write-ins in and myself worked on making it available and functional with Debian. So maybe you'd like to explain the current status of the packages in Debian? Well, after Ubuntu did the first version, we started to see a lot of problems on it because we had a lot of features that were used by Moocow's users and we started to make a group to work on together with all the problems in Debian. After some time we didn't really work with them to try and have them work and now we have our solution which is disabled and works very well. But the problem is that when it started and they called it, they did it for different reasons and they see it clearly. So all of it was part of the code for Ubuntu. And this is very, very bad for Debian and how other metal that can meet the use of this computer. So I and the other people of the team started to search for alternatives. So I made a meeting at that camp before they called here and we started to read all the autospeed from the page. I will show how was the code for it all, I knew what it really had, it was not in full screen. This is for Ubuntu stable code that will be the schedule for the client. And as you can see here, it's simple, it's very simple because in this bootshare script it runs a lot of things in order and a lot of things inside. And the problem is it's very, very difficult to extend it. The problem is very, very long and half is not important for Ubuntu. As you can see here, they use this flash, this is Ubuntu. And then we try to think another design for it. Well, this same script now on the version that we are working on is this. We have a player name sitting now. So the code with all the player name functions for Ubuntu and I don't know if you can see the text in the lines because of all the system. So the boot client is completely just this code. Because of all the things that we made last week. It's very easy for us now, we can extend it. Well, it's a lot of time for us to think about how it works for Ubuntu. We need to discuss the problems, what features we have now and what we can do. Basically, we refactored the code and split it up into smaller pieces. That makes it much easier to have an Ubuntu specific section and a Debian specific section. Even though the majority of the code is actually identical. So we've basically re-implemented the features that we had in the old version. It essentially appears to be working, but surely there's bugs. We'll hopefully have an upload into Debian sooner than later. We really want to try and make a plea to the Ubuntu developers to help adopt this new way of working. Because otherwise we've got two different code bases, it'll be harder to share code. The other thing that we want to do now is that the code has all the features that we can provide for that money. If you often see it here, this is how the code is using the design. We'll have a version of the script that I wrote in order. Each one has some more books that I will show. The parser, I'll upload the evidence. And then each proving can manage all kind of stuff that it can need to deal with. Which one do you think you'll use? So now this is one clue. This code has an object out there to be. That you can use when building the scene. We'll just look back at it for installation. So is there a SQL to extend Autosphere right now? We can see all the things here. For example, before we had all, I think. And for distribution inclusive support, have put them. And now we have one more code that's very simple. It's very, very simple to write. Because we try to keep it flexible as possible. Also, very, very, very simple tools. Anyone who needs to change the way that Autosphere works, do it. This is the, for example, the Canon Detection code. I think it is the most complicated thing that we have now. And it's too simple. Yeah, and this would probably be even simpler if we didn't want to support Sergeant as well. But we'd like to try and keep it back for at least some of the people. So that adds a certain amount of complexity. Yeah. Right. To try to work with someone together. What we did is a code that's coming to any gather. And here we have a lot of code and a lot of difference on the word. The word or any other language. We have the things on form directly. These plugins are included. How is the thing on them? The things that are formed for a given and given basic distributions. We put inside a given directly. So how? And one of that was wrote for a given. And we put two on the other side. There's one thing for the models that they have home with us. And it's basically our model. There are a few that are different. Two models are different right now. The basic configuration where they set up the defaults for attackers and others. And the kernel selection that is different. So we reduce the code multiplication. We make it simple for any member of the building to be able to use it. And also we now have a great right to make it available. It's one of the things that I work on right now. And we put all the features like help.js.ps. And all the things that we start with home. TSPPS is support for local devices. Such as the USB stick or the CD ground. How do you do that? How do you do that? Does anybody have any questions or do you want to get involved? I don't know if you have a documentation about each step in the sequence of building. I think you can do it. I think you couldn't understand what you're doing. Yes. Right now the process is very simple. But it takes a long time to understand how the whole thing works. Because it's a lot of work pieces of the whole thing that work together. But yes, we should implement it. But before that we were focused on making it work. And now we're starting to make it more simple for all the people working here. How many people in this room are familiar with LTSP? How do you use it? What are your experiences? It's insane to be able to work with LTSP. It's insane to be able to work with LTSP. Yes. And you know what I'm hearing here about the new problem? We are trying to make use of the base of LTSP. And I think it will be possible because it's very flexible. And to work on how many windows we need. And maybe we'll try to make it work for other people in this room. Sorry, we're trying to make it work without having to deal with LTSP. And that will be great. We can have help for them to run out. So one thing that would be really helpful to us is when we upload the new packages. People can test them out and experiment with it. Report bugs. That's always invaluable. Because we run through these tests and stuff like a hundred times. We might do something the same every time that other people will do. It's always invaluable. What do you think of the LTSP of this? My understanding is that the LTSP FS that was released was 4.2. A lot of that code they've actually made into packages for O2. That presumably wouldn't be too much of a network with W. So I think that's definitely a feature that people are really excited about and want to work on. But until we developed this plug-in system we felt like it was hard to code everything into the core of the code. And also we had part of the whole code for the liquid and choosing for the liquid to work in and track the link. But now that I think we're starting to come to an understanding of how we want the overall design and how modular it is, I think it'll be a lot easier to have those features in. And it'll also be really easy for individuals to make a package that adds another feature on. Whereas before that was more or less impossible. So I think that's the really exciting part for me is that it opens the door for people to experiment with new features without forcing us to include it in the main distribution. And then we can incorporate stuff as interesting stuff comes along. And also one of the things that we think we've got a lot of people here, is that what the feature is that we should not be motivated. But if you go to the user, just be right now, please. Because now we already have some support on client, great support on client. But we should... Oh, that's... No, no, this one. Ah, I get it. How are you? Ah. Team development. Basically, we've set up a wiki page for this development. I'll show it to you. And this is where this page probably needs some updating. But it's kind of one of the points for which we coordinate a lot. We've tried to have links to all the information we need to know to try and experiment with LTSP WCAG. We have mailing lists, ALIA, mostly for development purposes. But we're using VZR for the revision control system, which is really flexible. It allows us to maintain many separate branches in each of the American patches. As long as a decent version is available. Thankfully this morning, I noticed the new version of VZR was uploaded to Debian. And that makes me very happy because it's been really frustrating. But anyway, so there are all of our... That's not even all of our branches. That's only a small portion of them. So we can work on many different features or aspects of it and then we're able to change it between. So... And now to do this is... We still haven't touched on it. We definitely need the update. But we use L for the project and we have a mailing list called that will be used to coordinate the project. And if anyone seems to be active for trying this, we'll be very, very, very useful. Yeah. And even just having people to test new code is really helpful for that. Any more questions? You already have a feedback from the people. We've had a little bit of feedback. One of their concerns is that by splitting everything up into small pieces it does become a little overwhelming to get an understanding of the whole picture. Which I agree with. It's definitely a little harder. But I think as we try to integrate more features and more functionality it's going to be essential. Especially if somebody wants to come out of their door, distribution, or SUSE or whatever. It's basically... The way it was done they would have to reinvent everything from scratch because we're trying to make it more so that we can increase the capability to share code between different distributions. Even though there might not be a lot of code sharing, but it's still, I think, always better to try and be flexible. I'm just going to hold on more to say it. I just want to give you the nitty gritty details. Thank you. I'll give you a spin on the cherry of cake. Thank you.