 So, testing. Hi. Okay, it works. So, hello, everybody. Nice to see you again. Thanks for being interested about YAST. I can introduce myself. My name is Duncan. I work for SUSE as a team lead for the YAST team in Nuremberg. Yeah, we are in charge of all the installation configuration modules and also quite a lot of base libraries for the system. What I want to share with you today is mostly what are we working on right now. Last year, I did also a presentation here, and I share with you mostly the improvements we did across the distributions. We are going to do a quick review of those in case you were not here last year, and then I will show you what we are working on, and let's see if you can get excited to also help us. So, the talk is mostly three parts. I think you can ignore the timings there because I'm really bad with timings, so I'm pretty sure it won't work. I'm going to talk about where are we now? What were the latest improvements in the development, and then later show what were the, what are the challenges and opportunities we have, and what are we doing about that. And then I will do a small demo about one small technology we plan to release, I hope in the next version, at least as a preview or first early version. So, where is Yast right now? It's difficult to define Yast because it's a program, it's also a development environment, it's also knowledge, and it's tied to almost every part of the distribution, but today you have basically an environment where you can configure the system in almost any area. Not all the modules are known by the people because quite a lot of them are shipped only, for example, for SLES, while they are still open source and they are still in our repository, not much users cares about that, about them. The areas we have include file sharing, we can configure clients and server for NFS, Samba, I'm going to talk exactly about a problem about, for example, these modules. We have quite advanced partitioning, that means we are able to partition the system on installation, and also we provide a tool to do quite advanced partitioning with LVM cryptographic. You can basically build your own stack of storage with it. We have, of course, really, really important, one of the most used task software management. All the modules are integrated between them, and that's what makes different the approach SUSE has for configuration to, for example, Fedora is doing. I was just in a talk about the August project, and they want to expose these services for configuration, but they are exposing the configuration files to the applications. That means you get the knowledge among all applications, and that's the knowledge just captures. For example, if you configure a web server, the web server module will be called, you will be asked to, if you don't have the Apache installed, it will talk with the software module to actually get the package there first, and once the Apache is configured, it will talk with the security, the firewall module, to open the port, so you make sure that the port 80 is open. That's quite important in Linux, we can't see configuration as just, let's open this configuration file and let's change the value, because that usually doesn't work. Apart from that, we have support to configure hardware. This is actually becoming less important, because in the latest time, this is like a commodity, almost everything works out of the box. Things like printing configuration is also not much needed anymore, but there are stuff that needs also knowledge from different parts. For example, if you want to configure fingerprint scanner, then yeah, you need to set up the desktop environment, so it actually uses the password or something with the fingerprint scanner. And we also got a new module, this is new in the last release, we added a nice overview of all the security, so you don't need to know or be a security expert, just can tell you more or less how secure your system and what settings you can change. So that's where we are now. Here, I put a special part of help, why this does important, because we maintain so many modules. A lot of modules doesn't have much audience, but they are for specific customers that need some solution. In the case of Herbit, we need more people involved with the use cases, because some people complain that it's not very complete, but we don't have actually the knowledge to say what kind of features the people using Herbit needs. So that's a nice project if you're interested in clustering and monitoring. So what are the things we accomplished last year? We become pretty. Some magazine even said we are like the most sexy installation and stuff like that. And actually, if you look at Windows 7 installation, we are still pretty also. The nice thing here is that we are not pretty by default, but you can, if you are building appliances, for example, you can see SUSE Studio. SUSE is going in a direction where you can build your own distribution. And we make also easy that if you want to set up your own branding here in the installation, it's quite easy to do. This is based on CSS QT4. So it's quite standard style sheet. You don't need to be a developer to change this. We got a little bit simpler. That means if you look at the installation, this is the code 10 or the 10 series installation steps to get distribution installed. And this is how the 11 looks like. It was accomplished by different ways, like mixing a lot of screens in one screen. You don't want a screen just to agree the license and then to select where you are and then to select what's your language. You can just ask those in one screen. But also a lot of the functionality was moved to the desktop. Like registering to get an update repository was really not something you, you can discuss it but it's better to do the installation. But our goal was to get a simple installation so we move everything to the runtime. The first time you log into the desktop, the distribution will ask you, hey, if you want updates, please click here, open your browser and get just open and register your system. Also, other things like, well, small was not there but small was also moved to the desktop. If you want to submit your hardware, so to contribute to the small community. The first time you log in, it will ask if you want to contribute to the small community and send your hardware profile, which is quite important for business actually to prioritize which drivers should we invest in. We also got simple not only the installation but also doing modules that get permanently reviewed. Like I think the most important case was the partitioner. Also some of the modules are being continuously reviewed by usability people and doing drastic redesigns. In the case of the partitioner, people liked the new redesign, I think because the old one was not very, not much loved. Still, we are not in the perfect, there are a lot of complaints about some small details but much more progress as the first one. And we got fast. The worst nightmare from code 10 was about speed and then we got fast and I think 11.1 was a stage of maturity of the package management. We were fast already, it was nice to use and that allows us to focus not in basic things but on different stations. And that's the stage where we are now. In 11.1, we introduced a little bit of new infrastructure. We were not able to finish all the final features, actually present them to the user but it was, we are going to release less 10, is less 11. We had to put all the infrastructure for product management, other management and decide those things before. So for OpenSUSE, it's not that critical infrastructure is there and now for 11.2, we want to actually introduce some value in there. The Satsolver also was mentioned at the talk, it's not only used by Lipsip now but it's also used in SUSE Studio. So SUSE Studio has like a real-time REST server that does dependency resolution. Actually, there was a kind of Fedora was also trying to do a project in the same direction called Razor but it's really, really underground because they also have this political problem that Yam is official one so they have some project externally but they are, I haven't seen much activity there. It would be nice if they also will leverage this project. As you can see, the difference in some things like memory usage were much better. I don't put Debian here to compare because Debian is a complete different use case. They do dependency resolution in a complete different way. They depend on packages, they don't depend on binary libraries, for example. So if a package breaks the libraries it provides, Debian will just break. The difference of the problem you are solving is Debian is solving thousands of dependencies while we are solving millions. That's why it's better to compare with other RPMs solution that are basically solving the same problem. And we are integrated. Yes, it's not a program but it's actually a citizen of the distribution. We are present from the moment you take a CD you use YAS to install the distribution in your computer and from there you can create a profile to clone, to clone the installation and use a normal web server and use auto YAS to and define profiles for every department or every son of your company and automatically install the distribution in computers. But even if you don't want to get the computer completely installed and you would like people in not laptops, for example, to personalize some aspect of the auto installation, you can also use First Boot to allow them in the First Boot to set up more things. Open SUSE has made enormous progress with, for example, the build service, now SUSE Studio also providing repositories. And we also integrate somehow in this chain because Novel Customer Center provides supported updates for enterprise products. We have now Novel SMT, which is Novel Customer Center as a proxy you can use inside your enterprise. It's also GPL. It's not package in Open SUSE, I think, but it's GPL code also. And we allow with the YAS product creator also to take repositories from Open SUSE defined products and get the updates back to the enterprise. So we are not a program. We are in every place and that's the complexity. So what are the challenges and opportunities we have? Let me synchronize myself with my okay. So there are basically three kind of challenge. One was we are introducing a lot of functionality in the base system that is not visible for the user. Sometimes because, as I say, we have needs like we have to release less and this infrastructure has to be there. Sometimes it's because the Open SUSE cycles are really short when the next release is coming and we have a lot of things to do. And the other challenge is the community. We would like YAS to be used as a platform for development. People actually consuming and contributing to it. Also, we would like to outsource everything that we don't want to focus on. I mean, there are a lot of modules. We really, inside the team, we don't have anyone interested in those modules because nobody, I don't know, I don't have a mainframe in my office. We sell mainframes configuration to other companies. So we cool that actually the same people that use the mainframes contribute to YAS to add more expertise. Otherwise, the features only come directly from the customers and nobody else. So we need to enhance the community. Another topic is distributions to make YAS part citizen of also other distributions. We set a lot of rules like in the past, especially in the package management area, to leverage technologies used by others. For example, the patch format is now the same as Fedora uses. We have a package kit provider that works pretty well. And this makes really more strife forward to use the YAS or pieces of YAS in other distributions. But there are still a lot of problems because you have three stages. First, I need to get the code built, which is already hard. I mean, try to compile Lipsip on Mandriva and they use a completely different RPM headers and it just doesn't build. And we don't have the time to, every time we do make in our system to actually test if it builds in Mandriva. But we can solve that with some automation and quality assurance like we have, for example, now automated builds for the software stack and when a developer makes a change in the code, we automatically trigger a rebuild run the compete test case and if the test case pass, we create an RPM and send it to the build service. So in the build service, the SIPP head project has RPM's that are from the latest chicken of a developer that didn't break anything. We think we can follow the same approach to integrate with other distributions. Once it builds, you need to actually work that things work and YAS still has a lot of code that assumes a lot of things about the system and you don't want to end in a position like web mean that claims to support every distribution but nobody dares to try it because it can break everything. So one of the things we have to, we can add value, for example, we introduce package history and this is a quite interesting feature because the infrastructure is really, really simple. YAS, Lipsip writes the history of everything that is happening to your system like installing packages, removing, and why it's so important, why you can just look at the RPM database and see the timestamps. Because the infrastructure is there. We are missing the viewer, which is something probably Yano will implement for SIPP. I'm not promising for you, but we'll also get in the packet selectors some kind of viewer to see what have you done to the system. And also it's the first step to try to do a rollback. We have dream with rollback for ages. It has been a feature that is every cycle over we want rollback. We will try to approach it with realize that it's really hard. But then why try to solve the hard problem? Let's try to start with a simple one. Let's why not rollback the last package you installed or the last group of transactions you did. So we are going to try that. And also there is some feature which is called system cleanup. You install things to try and especially Linux is just install, install, install, and then you don't know what is in there that actually you need, what not. And getting rid of things you don't need is basically looking all the packages that are not required by other packages, which is called the lift packages. But it's not true that every lift package is unused because you can have a program that you install yourself. So you need to know if actually you install the program or the program was triggered by as a requirement for other. So that information is actually there when we write this lock. We know that it was the user or if it was the solver who triggered the request. So if Michael Freders, that solver was the author, that's the algorithm he told he will do. We could fit the solver with this information and actually create some kind of algorithm to clean up the system. That would be really, really nice. Just in case the lock is now there, it's a simple text lock so you can use it as a system to see what happened to your system. All the output of the script is there. We will invest a little bit in the partitioner because we already started investing in it. The storage area is growing quite fast and people need to understand what the complex stack of how the storage system is built. They need to understand it easily. So from the code, from the experience, we will learn what will be the feedback of the customers about the new redesign. We will work a little bit there, especially with some less features using tempFS, probably x4FS, we will be also that even if we don't have to do it, we will need to do it at some point because everyone else will have it. That's for example how it looks the storage now in trunk, which is already much nicer with all the different icons for every kind of storage device and also some kind of overviews. We are doing usability tests there with usability equipment to follow the eyes of people, how much they need to switch the eyes from here to here and try to adapt that. I think the area where we are most investing in usability. What about the community? I present you the YAS community. The current situation is actually not good. The mailing list, a lot of people participating in it. We have a lot of bug reporters. I think that position is completely filled already. And we have a couple of people that do pretty nice contributions, like Benjamin Bever who invented one click install and other guys doing modules. We have people contributing to the live UI, which is you know that YAS has this library, can you do QT and curses, GTK, and you can use that library in your own software development if you need to do software without depending on YAS, competing dependent on YAS. And we have some people using this library in the company to create multi UI software. We need to grow that part. And I think that can be done also, moving YAS, stopping thinking that open source is the world and moving YAS more to other distributions also. Then you will get people automatically because open source is also not the biggest community out there. If you look at the people, we need to lower the barrier because we can't expect people to help if they can't, they need to learn. I mean, there are projects that people doesn't help you, doesn't mean that your software is bad. There are a lot of communities out there including open office for example. It's a great software. But they also complain that they don't have developers. Try to build open office. You need a day if you want to learn how to build it. If you want to do a change, you need probably more time. But if you look at other projects like Firefox, in Firefox you can create an extension in five minutes by reusing the same knowledge about HTML and JavaScript you have. So they did really nice there. I haven't seen, for example, as many extensions for Conqueror. Even if I am a KD developer, I would prefer to use Conqueror. But why do I need to learn all this stuff just to make the extension? You are not that important to waste my time on that. And we have to learn also that we are not so important to actually get all the people to learn or APIs or YCP languages and so on. So we are doing, we need to open the YAST for other kind of knowledge out there. And also help participation using the build service. We moved some projects to get repositories to allow easily cloning and forking of a project. Let's see if that works. And we need to reduce complexity. I don't know if anyone has seen this complexity with all the build service repositories. For us it's a nightmare. I mean, we have repositories that build any kind of unstable project on every architecture or any distributions. Well, the first example is actually fake. I made it up. But the second one is actually real. There is a repository called Level Language Ruby Extensions compiled for OpenSUSE 11.1 built on top of the repository, Level Language Ruby, which is not the official Ruby that you find in distribution. And if people that has to do long with users in a long time, they understand what that means and they can understand the distribution. But other people don't. And they just report bugs like, I am a user. I got KD4. I don't like it. I want the new one that is out there. And I install it and it doesn't work. So what was the problem? It needs another repository to be added to fulfill the dependencies. But why do we need to waste time explaining that it should work out of the box? For that we can leverage some new infrastructure we have also seen the last version like Jan explained it. We have the SIP services. SIP services are used, how I am with time? Okay. We have, it is less used as that because it is less talked with another customer center and knows which customer has which products. So when you add another repository in the enterprise, Susie, it sends the idea of the client. And in the server side we know which customer it is and which repos he can use for updates. So we send him a service totally customized from him that has a list of repos that changes every time he refreshes this list. And if we someday want to merge two repos we can do it on the server side. This can be used in open Susie to reduce a lot of complexity of repositories. Because the user is already interacting with the build service. He has an account there. He has a list of favorite repositories. So he could put all this information in the server which already is. And then the machine could just say other service URL from the build service that has the login of the user or something like that. And also pass as a header the distribution and get back all the reserve repos he needs. Even with dependencies. Then if he wants to go more risky and say I want one more level of instability, he could just set it in his account and he could get back a different list of repos the next time. And at least we will also solve problems for example of distribution upgrade. Right now we do the distribution upgrade and we need to disable all the repositories and try to see which one will work in the next version and then re-add them again after. It's a mess we can solve with infrastructure we have now. I'm not sure if this one will be a priority for the next version but we will surely work on it later. And then we have this problem. I'm pretty sure that more than one of you had this problem with trying to upgrade OpenSUSE. The problem is that if you want community to actually get involved they need to easily follow the distribution in the latest state. And if it's frustrating they just will say, oh in Debian everything works and I will go just to Debian. Actually in Debian it doesn't work, I have used Debian. But we can still make it easy. There are a lot of reasons why this doesn't work. One of the reasons is of course, as Peter mentioned in his talk before, not everybody has connectivity that allows you to download the terabytes we mentioned before. So we are working on this right now and it will be almost sure in the next version. Which is leveraging the mirror brain we have in OpenSUSE and we are going to switch LiveSIP to stop using curler stupid HDB client to use ARIA, which actually understand these metalings, can record information about how was your connections using the pass or this mirror was faster and can then reload these rankings of mirrors and reuse them again, combine it with the rankings the mirror brain suggest and so on. Always download the most efficient things. Also if it fails it doesn't tell you immediately this failed press cancel continue but it will try a little bit harder to get the stuff down. So that's one of the things that can make a better experience for people. And the next things are factory has to push less RPMs. If RPMs doesn't change it doesn't make any sense to send out an RPM with a time stamp but the same content and this is mostly done. It was done last week you can see the blocks out there. We could use delta pms in factory and that's part of the infrastructure we have since 11.0. You can use delta pms in any repository even if you don't have patches in that repository. And we could use that for delta at least from the latest factory state we could offer delta for the people. And this thing we are also working on right now which is change the commit policy of live saving a more flexible way. Here installing is fine to download one RPM, install it, download one RPM and install it. If you are doing this upgrade maybe you want first to get all the RPMs and then start because if it fails in the middle or if you are in some place where you don't have good connectivity or something you can basically scrub your machine and then you are. This is for sure coming for the next one. We also have Bagon. I'm going to be a little faster so I can show you the demo of the next part. Bagon is a tool to do the upgrade. The same thing as this upgrade but in graphical just. And it will be used also in SLES for doing the migration from one to the next service pack. It's basically this upgrade in a graphical way. And then it's all the just use cases we have. Just talks, people want to use the just functionality from a lot of different scenarios. And that's what we are trying to find a common way for developers to use just. We have for example the Dibas desktop people example. And that is the example of the Samba sharing. If you want to share a folder with a network where do you expect to find the functionality that says share this folder? You expect just to right click on the folder and find share this folder. But nobody expects to open just as root and then go to Samba client and add a share folder. So that's the use case we are trying to enable for the desktop people. Which is basically provide some functionality like sharing a folder or open a file port via Dibas. You can see similar interfaces like package kit for example. In the enterprise we have different requirements. People want to talk with just via sim. Anybody knows what team is? Okay. Who doesn't have heard about it ? But it's a really complex enterprise language which is used by some really proprietary stuff storage. They claim to be open but it's a committee designed technology. But we need to support it and we have to use cases for them and we will support it. So what do we have in common if you want to use people as developers to help us? What do you know that everybody actually can do? I mentioned the file port example before. I think the only way that we could talk in common when developing is actually the web. It's the only thing everyone knows. Every language we have out there knows how to use HTTP. Almost every people can write HTML or some JavaScript. And not everyone wants to get involved in just in the deeps inside of just. Some people just don't know how to use it. So that's something we are working on. It's a just web service. It runs in the system. Provides a rest style API. The same kind of API you find on Twitter, Flickr and all these nice websites that will be bankrupt in one year. This running your system as a normal user doesn't require a route and uses PAM and policy kit to actually set up different access write for different tasks. And it also uses packet kit for the software management and uses some other just functionality using the SCR of just as a service. This allows you basically to configure just using crawl if you want. I will show a small example. And also we are working in a web UI that is a race application. This is a free template. We looked in Google for free templates and that's what we got. If you want to help us to create a nice UI, you are welcome. This is not something finished. We wanted to show that we could write this functionality with 600 line of code. And that's what it has. So that's our strategy for the next versions. We want to provide for all the people that have access. And I think those technologies access to the use cases. And I think the most important for us will be the web in the next time. To leverage the same success other tools have. For example, the build service providing REST APIs, the OSC client and all those tools. So let's see if we are of course wanting help. Any people with web skills can also help us now. We are going to show a small demo how this works. If I still have the time. So if you have the REST service installed and running, you just go to localhost and this port and you find the documentation. It shows all the modules that are available. And you have some documentation about how you can configure it, how you can log in. You can log in using a normal htp authentication. It does all the power, but if you want to use your own account, you only need to set up some policy kit rights if you want to allow some tasks to be done. It uses SSL to protect the logging. I don't have SSL configures, so I will just do a normal htp authentication. So for example, the logging request, I will show this. This is how a login request is. I'm not going to pass the false one because this is not my password. But so let me find the right. Yeah. So this will be how I can do a curl post request to the local server and I'm passing there the XML you saw before with my password. If you do this you just will try to create a cookie with policy kit and will give me back authentication token in a cookie. And then I can use this cookie. For example, let's show if we post this to the user namespace of the htp, we can create a new user for example. I will show you that I don't have a password. There is nobody. And it's everything right. So if I pay this and I pass the same cookie I got before, I'm passing the cookie there, that's authentication. Don't worry about the speed because of course it's a prototype right now. We are using even with a database to get use of some XML functions but we are working on a much faster implementation. Usually the requests are quite slow. The get requests are quite fast. So we got everything okay. So now there is the new user for example and you can do this as a normal user. This will be cool when for example SUSE Studio could configure an appliance without even using their own UI or you could write command line clients. So that's the presentation and now let's use the five minutes for some questions. Sorry, sorry. How mature is that? How mature is the web client? How long do you think it will take to be stable? Okay. Do I have the novel disclaimer here? Because everything I say is not a schedule promise. We are targeting it for the 11.2 and SP1 of SLES as a preview, technology preview. That means from, till that moment the API will probably change a lot. But after that we will at least release system time configuration, language configuration, patch management and what else? Here you can see all the modules. All those modules will be probably in the next version. Users, permissions, patches, language, system time, service enable and disabling and logging of course. We are going to focus in the small things, appliance need and then we will not probably develop audio configuration in a long time. It's not our priority. Just a question. This base of sort of web front could be the base for a future remote automated management. That's the idea that once you have a rest interface from one system you can create another rest interface that actually talks to a lot of systems which is the same that SIEM aims to do. But the only thing is that everyone here speaks web. Who speaks SIEM here? My next question was that one because I knew that SIEM tries to do some sort of like this. And my next question was if you are starting a alternate way for non-corporate users or... I would say let's see how much success we have with the first version and maybe it might be that by default as a Linux management a cheap way to do it. We are not competing against SIEM because we also support SIEM, we are writing providers for storage and software management. But this is for the community. We want everyone to be able to configure the system, not only experts basically. All right, thanks. If I only have one minute left so I can answer one more question and if then someone has any question you can reach me at the booth outside. Well, okay. I'm going to ask you something about the package management. You said something about implementing cleanup functionality that would enable the user to get rid of leaf nodes he doesn't need. I think I get the question. I said about implementing which functionality in the package management? Cleanup functionality which would enable the user to get rid of leaves he doesn't need. The information whether a package was installed by the user or it was installed to satisfy dependency will be kept in some logs. How about if I write my own program to install RPMs? It wouldn't be able to use the IPM database and wouldn't it be better this information to be in the very RPM database so that any tool could use it and not in the logs created by it? I understand your question. The ZIP log has all the information for programs going through Lipsip. If you use another program that just called RPM or you use RPM in the command line we don't have the information going to the log. That's true. But the problem is that the RPM project is in a really strange situation. They have like two forks conflicting people the main developers of someone are people that is not famous to be nice and so on. To short the answer, if now you install the program with RPM we actually realize that but we assume that that program was installed by the user. Because in RPM you cannot get this program installed by dependencies. The time is over sorry I can't reach you out if