 Okay, ladies and gentlemen, welcome. Good morning. Nice to see all of you there at this early time on Sunday. Well, we're just starting with this screen. The comment you see here is from a teacher in America saying, hey guys, what you're doing is absolutely illegal. It can't be true that software is free. And that's why we do this one. Just to tell you, we are doing free software. And yes, we want to tell children about it. We want the children uses free software and something, somebody told me it's good to use free software and to free your mind. My fault, sorry. Okay, sorry. Good morning. I am Andrea Florio, also known as Anubis G1 in the OpenSUSE community and here my mail. I am a packageer science 2007 and I'm proud to join the education project last year. I started as a normal packageer, but later, thanks to Lars, I became one of the four administrators. Right now, I maintain several packages in our repository. I lost the count, really. And my job is the technology teacher in the QSI International School. That is a school for the international where sons of a united nation employees go on several states. He is Lars Vogot and he can talk. Okay. Welcome. My name is Lars Vogt. I'm formerly known as Lars Rupp. And my nickname is Kleiner Ice Bear. It's a special name for the Germans under us. And currently, I'm working for the alter-build or distribution team for SUSE and joined the education team around 2006 before I worked on a special product called SUSE school server. And therefore, I have some knowledge about the education thing. I'm currently maintaining around 250 packages in the education repository. And as you might see, that's far too much. And I hope I can give away some of those packages to the upstream developers in the near future. Okay. So that's our goals. The main goal is wherewith do you teach tomorrow? The first goal and currently the main goal is to get open SUSE in schools and to support those schools using open SUSE and help them to get it spread around all pupils. Of course, we want to provide the best integration between open SUSE and our application for both server and desktop. That's why for us, clients are important like servers because without them, we can't provide a good environment in schools. You know, lots of schools work using Active Directory. And we think that we can completely substitute Active Directory with open SUSE education. That's why we provide both. We also try to contribute to improve open SUSE. That's why Lars told that hopefully we can send upstream our packages. What else? You can see here two goals, half green and half blue. That goals are still a kind of work in progress. In fact, we will try to build a cross distribution education community but it's not really easy right now. The same work is the same thing is to work together with developers. Even if we have some examples like Salome developers and took spined ones and lots of others. What else? Last point, support home users means if anybody of you has a kid, perhaps you might know what's the critical aspects letting kids working alone on your PC. That's one other task we have. One is to work for schools and get educational applications in schools. Another one is to help home users with their kids so they can even use the same applications. It's really simple or even get something like a filter software for Firefox and so on. What does we have right now? We have a very, very big project and it's growing day by day. We have something like 800 packages for both. It's 32 and 74 bits. We released the 1.0 add-on for open SUSE 10.2, 10.3, 11.0 and 11.1 and also for SUSE Linux Enterprise 10. We provide on our Wiki description for not all the software and now, but we are working to do that for lots of them anyway. We have our bugzilla and we have to say thanks to Novel for providing us that. We have an NSF1 repository, a developer Wiki and our own page. You can see some URL on the bottom of the page. We have also maybe the most important things to repositories, the developer one and the frozen one. There are two, why? Simply because one is intended for end user, the other one of course not. Let's see why. The build service repository we wrote as developer one is not for end user. We can't add a license dialogue. We can't write everything on that license dialogue, but we can't add into the build service repository. No just features. We can't add control files. We can't add package translations and everything else. We tried to install all education software using the standard control file provided by the open SUSE DVD and simply doesn't fit. Using the build server repository, we can't work with it. It's not available without an internet access because, you know, a single package sometimes triggers several packages to rebuild, so you need an internet access to download any time the latest package. To enhance the third point, it's not available without internet access means at least if you have schools with 50, 60, 100 PCs, you don't want each PC to connect directly to the internet to get all the packages. That's one point why we release an add on ISO image so people can just burn it on the DVD and use this DVD instead of connecting each PC to the internet. Okay, next point. Zipper add repository as non-refresh. Well, yes, it's simple. Just use the command line tool zipper and add the open SUSE build service education repository. We'll notice that zipper adds this repository with a marking non-refresh. So what can happen? You try to install one package one or two hours later and in this time the build service rebuilds the whole repository. The package zipper has in the cache is version 1.0 and release 35. No, the build service has to build with the complete repository. Zipper has the cached repository and says, hey, I want release 35, but the build service has 36. And that's when Zipper tells you, sorry, this package is not available. Refresh means download at least the metadata. Even if you have an internet connection to refresh all the time, you have to download at least four megas. So it's a waste of time, it's a waste of internet bandwidth and everything. No end user information. Why packages as an Iger version or release number? This is maybe one of the most important points. In fact, using a build service repository, we can't provide information before install a package. Before install a package, you can have information only after you install that, reading the package change log. It's not a good thing. You want to know what we changed we made before install a new version. Packages can be broken during testing. That's a development repository. We changed, we patched, and sometimes packages are broken. And even if a test is always welcome, an end user don't care about broken repository. Otherwise, it wants only a stable one. So, no, one second, please. Okay. That's our reasons for using the build service for developers and for testers. That's our reasons at the moment why we can't use the build service for end users. And hopefully, in the next future of the build service releases, all these topics will be gone. But until then, we stay with these seven points to tell people, if you want stable packages, if you want packages that just work, please use a frozen repositories. So, this is a short overview of how we work at the moment. I have this one. So, on this side, you see what we as developers do. It's just simply the same process every developer knows. We get the sources, put them in the build service. The build service builds the package, hopefully. And afterwards, we can test the package. We have additional testers around the world, testing packages from the build service repository, and add Buxillar entries to our Buxillar. Afterwards, we can just restart the process, fixing the packages, rebuilding them, testing them again, and so on and so on. So, at the moment, once a time when we decide that we are in a stable enough state, we say, okay, now it's the time to create a frozen repository ready to use for end users. That's when we begin to sync the build service repository outside. We start just putting down the packages on a separate server and re-sign them with our own GPG key to make it clear that this package has nothing to do with the original build service. It just has another GPG key. It has another signing. If you test such a package in the frozen repository, you will notice that these packages are already signed with the GPG key from the open-source education team or not with a build service one. Another one is building this repository enables us to use all the just features. So, if you add this repository, you get a license dialog that tells you how you can reach us, how you can talk to us, how you can add Buxillar entries, and so on. If you enable this repository, you have pattern files, which means a group of packages which are useful for small kids, for bigger kids, for really universities, and so on, and even for servers. That's why we use this step to sync the packages outside of the build service repository. And well, it's a called beep happens and sometimes always packages in this frozen repository are broken. Well, the same is for every distribution, I think. And for this case, we have also a frozen, let's call it frozen, it's just outside of the build service update repository. So, if we detect a broken package in this frozen repository, we are already have enabled and installed an update repository in your zipper. If you install the frozen repository and look at zipper, you will get an additional update repository which is per default disabled. Because if you have a school with 60 or more PCs, you don't want even to search for updates in this repository. That's the reason why it is disabled per default. But if you enable it, you can get updates for these packages in the frozen repository. And these updates are coming, for example, with patch infos, so you can see before you install a package what has changed. And of course, we don't have to forget our community. In fact, using mailing list, IRS, and the bugzilla request, we can have all information we need to provide new packages to fix the bugs we can find. And everything works with our bugzilla. Everything will be moved there. Without it, our work is very, very difficult. So our community is maybe the core of our work, of our team. Without it, we can't work. We are talking here, mailing list, IRC, forums, and so on, all your possibilities where you can talk to people outside, talk to the community, and often the community tells us, hey, I want this package or this package could be a better package or so on. And to not get lost this information, we currently just use bugzilla. So we have, for example, an own wish list in our bugzilla. So people can just add new package wishes. Yep. Going on. Okay. We talked about that yet, but we can't review again. So we have updates and frozen repository. But what are benefits? Using a frozen repository, you don't need to refresh it. It's frozen. We follow the same policy as OpenSuser repository. We have a frozen one and an updated one. The first one is not need to be refreshed. It's well tested and packages are stable. We have one GPG key that can fully control everything and is an add-on media. We provide an ISO and everything starts automatically. It's easy and easier to document. We, in fact, usually provide documentation about the most important packages with the repository and the ISO image. And it is easier to file bug reports because you know exactly which version, which release of a package is buggy. Using the OpenSusableService repository, you know the package is built anytime and maybe you file a bug report that has been fixed on the next release. Using the update repository instead, yes, is added automatically and is not refreshed, is not set as how to refresh. You have to enable it. But most important things, as we told before, is it contains patch info. You see in the OpenSusupdater applet what kind of change has been made on the package. If you agree with that change, you can install the package. It is something you can compare before the installation. And it's really smaller than the main repository. We saw the metadata and it was just 150 kilobits. It's 4 megabits for the whole repository. Okay. We have to say thanks to lots of people starting from OpenSuse, Nouvelle, my Linux user group, the Linux, the Brilog, sorry. Xt is for kids and didaska is an Italian group that provides OpenSource ACL. And all the others which have no logo, of course. Like communities and our developers and so on. But if you can see at this slide, what we want to do is to try to work together with upstream, work together with other partners to get OpenSusup education spread around the world. That's why HP and Nouvelle started an education project. And last week, maybe, they fire news telling thanks to us for our work. They and Nouvelle looks like that would work together with us to improve our packages and provide anytime a best and better add-on media for education. Just for your information, currently we have around 20 packages alone in the Education Build Service Repository, which does not mean that these are all. We have many more people around the world starting testing, by testing they are helping us or helping people with their packages. So if you look at the forums and search for education, you find many, many requests about packages for the Education Repository and already people in the forums helping each other to get this running. And even upstream developers are now starting to work with us. So if upstream says, hey, it's a good tool, we can start something. For example, we have already packages for Fedora and some people already ask us to build also their packages software for Debian and Ubuntu. The only reason currently that we don't have such packages for Debian and Ubuntu is that we are not Debian packages at the moment and we just have to learn it. So if somebody is able to package Debian... Link it, okay. Join us. Great, great journey. Okay. Kiwi LTSP is maybe the most important server project we are working on. And it's been awarded in 2008 of free open-source software in India. What's Kiwi LTSP? Well, Kiwi LTSP is based on Linux Terminal Server project called LTSP-5. It provides simply a way to use from the... from team clients, that means clients without an hard disk and without an hard disk, application from the main computer. Lots of terminal server and many team clients, that many team clients means also very obsolete computers in schools. Supports PXE support. They are able to PXE boot. They can boot from the internet then. Well, we use also Kiwi to build our system PXE client. We create an image of the whole operating system and a benefit using Kiwi is that Kiwi is widely used. It's a stable resource right now. It's used with... Well, sorry. It's used to the studio on build service. It's integrated into YAST. It's easy to a local application and going on. How does Kiwi LTSP works? Simply as told, it uses LTSP to send a single image. But the single image is not a single application. It's the image of the whole operating system. So team clients, computers without an hard disk, very obsolete computers are able to start the whole operating system with all applications installed on the main computer. Right now with the computer with 4G of RAM, we are able to boot something like 30 team clients or something like that. So with a very good PC, you can create a nice computer lab in your school with just few money. Just by reusing old hardware, which obsolete normally and doesn't run the current applications. And I forget to tell that Kiwi LTSP is not limited to PXE boot. You can also, thanks to Kiwi, boot using live CDs, USB images, and everything else you have in your mind. We also provide an integration with etalk and with ice cream to provide a kind of build farm. One moment. That's one reason why we use Kiwi. It's really easy at the moment even if there is no GUI for it. But you just have to edit some configuration files, restart the build, and for example, if you have an old hardware, you have, for example, a Pentium 3 or something like that, and you said, okay, running this as normal think client without really using the processor is not really useful for me because then everything runs on the terminal server. So we can try to find a way-to-way solution just saying something like, okay, I integrate a Firefox in the Kiwi image. It's just by adding the package name to the configuration file, rebuild the image, and now you have a Firefox running on your local client if you started from there. So the terminal server doesn't have to run Firefox or the clients run Firefox. And so you can test how much your hardware works and you can find the best solution for your setup by just adding packages which can be run locally. For example, I don't think you want to have open offers run on your local client, but other apps maybe are useful for that. And we have also Cyberorg and other developers that build a kind of GUI for Kiwi LTSP called Easy LTSP. It's an easy configurator that allows you to set up just a few things and press OK. Stop, everything is working. But how can you install Kiwi LTSP? Well, the easiest way is to use the one-click install or maybe use our patterns provided on our frozen repository. And that's all. Install the packages, start Easy LTSP and you have to configure at least the server IP address and ADXCP range. These are the minimal requirements for ever Kiwi LTSP working. You can, of course, also add the packages you want to install. You can customize your configuration, but that's the simple things you need to work. Once you did it, just press on OK. Easy LTSP will start the setup process, will start the TFTP server, the ADXCP server and nothing else. You simply have to boot your ThinkLiance from Network maybe or using CDs or USB sticks and, whoa, you have now your ThinkLiance working OpenSUSE with educational software, of course. Yeah, so I think this is the time where everyone can ask questions. Yeah, no? Okay, so, yeah. I'm going to close here, so... Hello, I'm the author of GCompre, software in education. So you're talking a lot of infrastructures that you built to deliver OpenSUSE and you didn't talk a lot about the content itself. So where are we in terms of content? Are the teachers or the school can already find everything they need in OpenSUSE or in the free software community? Or do we still have some big myths in the application stack? Yes, by the time I come through. Yes, question about applications that are there or that are missing, it's not easy to answer because we have, as I told you already, over 800 packages. GCompre is one of the things, PhysiCache or the other applications for small kids are also there. So if you like to compare the OpenSUSE release and other releases like Fedora or Debian, we are currently at the same stage. So this is not the problem. The problem is that we need feedback from schools, from the users. That's the really reason that we have because we can package thousands of packages if nobody uses it or better, nobody tells us which packages are useful. It's not worth the work, at least. So for us, it's really nice to see as HP starts and tells us, hey, here are 40 applications. We need those 40 applications. That's when I start to ask, why? And HP tells us, yeah, we have a marketing and marketing tells us that people want these 40 applications. That's why we want to work together with other parties because if you can get more information about what people outside need, outside our developer brain, let's say so, we can just easily work for them. And if I told you in the beginning that we are trying to work for home users, every time I talk to people having kids at home, they say, hey, yes, my kid want to get a PC, but I'm not sure if the internet is the right thing for my kid. And that's where we should start thinking about why is this so and how can we solve this. And so in this process, it's very important for us to get the feedback out of the community, out of our users and start adding such feature wishes to our Baxilla to don't get them lost. So it's really important. I hope this is answering your question or not. So yes, there are plans already for the next version. We are currently releasing OpenSUSE Education 1.0, which for us means at least we have all the packages that we think that are worth to have in our repository. The next version will be at least 1.1 or something like this, having additional packages and the first applications developed especially for schools and for home users. So for example, the Kiwi LTSP is one of those. As we talk to teachers, they tell us, yeah, terminal servers, wow, great, wonderful, but it's really difficult to set up and maintain it. So we are going closer and said, okay, how can we reach us to make it easily to be installed by people not having the tech knowledge background. So they just should, well, at least take these three steps and everything is up and running. So I really appreciate the Fedora success providing an USB stick where you can say, okay, put it in, boot it, and your terminal server is ready. Well, okay, that's the next step. OpenSUSE will follow. But yes, with such simple, simple assessments, it's really easy to reach the people outside and show them that it's really easy to use and that the packages that we have are also useful for them with the problems that people have tons of applications, but no description. And please talk with teachers if they tell you, hey, it's a wonderful application. You can get your vocabularies learned automatically with an result at the end. They tell you, hey, where's the documentation in my language? And that's the main problem that we and I think every other project has at the moment. Okay, my company does quite a lot of... My company does a lot of internal training. So it's not only for schools, I would say. And I'm an application engineer. Sometimes we do training on Linux. So we get the live CD and we can't store any of the results. So that would be one of the key benefits of having a live CD that could directly connect to a server where you could generate automatically a home directory so you could retrieve the data. That would be a big benefit, I would say, if you had that type of function. Okay, thank you. That's one of the features for our Baxilla. And it's not easy, not really complicated to implement because we have already such live ESOs you can put in that are booting via PXE and don't touch your hard disk. So what we have to do is integrate that into the domain. Okay, thanks. We also forget to say that we provided some month ago the first educational live CD, build it using MSUSA Studio, and allow you to try open-source education without installing staffs on your PCs. What you also could consider is also instead of storing it into the server is that you boot from the live CD and then you have a USB key as your hard disk. That would also make life a lot easier. Sure. Oh, just give it. Okay, I think Debian has popularity contests which when you sign and you say, okay, use no afterwards, Debian will collect how many programs and which programs you used. I think something could give you automatic feedback from your users. Just put it into the one-click install and add, okay, you may send it and you get information. Yeah. One suggestion. The other one is I'm from old PCs Switzerland. Do you package also sugar on it? Yes, we have packages for sugar, but they're currently in our development repository. We don't say they are ready for use. Okay. But you are working on it and... Yeah, I have a question about your development model. When you are seeing your... I mean, do you froze the build service repos? It's the same thing we have in the frozen repositories. So if I look for an application on your build service, it would be the same version as in the frozen? Yeah, kind of. When we reach the frozen state, we disable building and sometimes also updating on the build service repository. Then we go to download everything we have packages, all that one we consider stable enough. And then with a simple bash script that Lars wrote, we are able to resize everything. They are simple. The same package coming from the build service for compatibility reasons, sorry, because it must be built using the open source software repository and stuff like that. So we go to download and resigning, adding on the frozen repository. Then we go to recreate the whole repository structure using tools like create repo. The repository is ready for use, right? Yes. They should be the same. They are this really big pack, yes. Do you have... You talked about open-school server, I don't know exactly what it is. Disaster rate with a school tool, the system that made Ubuntu to administrate a school laboratory or the school infrastructure. And how could we work with the application? Because many schools don't have a login per user. Some have, some don't have. And they want anyway to get, or they may be interested to have feedback from the application to the user to save the data in the user directory, even if there is no login, because they don't want to... So there are a lot of questions around this. I don't know if you have some ideas or investigated or how can we work in this area? Well, currently we are working on a YAS model that should be able to manage rights on clients, on students and teachers' PCs. And using QLTSP, you are also able to create one single user and allow login for everybody. Or also if your school is integrated into an active directory domain, if you install an SSH server on your Windows server, you are also able to login in QLTSP using active directory accounts. So one thing I have in mind, thinking about storing results of tests and so on for users is something we already evaluated with a school server. We have two options at all. One option is to use the LDAP. So what we have to do is patching each application to allow using LDAP and to tell the developers how to patch so it works. Another option is to use a generic database back-end. And that's something the KDE developers are already working on it with their KDE EDU applications. But it's in a very, very early state. They are currently just talking about the API and so on. So it's not really that kind of stuff that you currently can say outside users, they can use it. But there are discussions about this already. But not a real solution. And I just want to wait until we have one or two solutions which can work before we start a more generic discussion with our people to get these things working for all applications, hopefully. But it's in the discussion, yes. Do you think that this is usable for remote education? You have a server in Stockholm and you're running your training here. Yes, absolutely. But depending on your bandwidth. That's the reason we have already in Germany. Germany schools have normally a free internet account. But this account is very, very limited in bandwidth. So schools can download nearly everything. But if people sitting at home and trying to reach the school server, they're sitting there and saying, hey, my modem is faster. So at least I think, theoretically it should be possible and I know already schools are working like this. I know at least one school in Germany have a 10 megabyte or something like that bandwidth. And teachers working at home just connecting their webtof to their home directories on the school server. So yes, even that's possible, but it's a point-to-point decision. It depends on your users. It's not really unique to say, OK, you need at least this bandwidth. Depending if you want to start with video editing or audio editing, don't try this. But for the normal user trying to work with open opus or something like that, it's really a small bandwidth. It works. But transferring the whole application or making an X connection something like this, it's sometimes kind of funny, but free in X and so on already works. So if no other question, I think we can. OK, can we have one question? Sorry, I'll try myself. Just a single one. A couple of years ago at the introduction of educational software, you mentioned that the software education part was written with the Spanish language and English language. How easy is it at this day to translate it to other languages? That's the developer question. We're working on a web front end to translate at least the package description and so on, but translating the packages, the applications, it's hopefully something we can do together with upstream. So every distribution will benefit of it. OK, so if you have further questions, please contact us at the booth. We will be there at least until we go to sleep. Thanks.