 So we have Robert Schiele talking about ERPM thing and who the N-Line cells will be talking about some download.openSUSE.org stuff, how to improve the mirror situation, and things like that. So just go head forward. Okay, you will all know the most important part of the talk is the advent of the interesting one. I want to talk today about what, in my opinion, when does not work, the current ERPM thing, everybody that has tried it outside of SUSE has experienced some problems, and I will explain what the reasons are for that, in my opinion, and how can they be solved. So, because I used this logo, I have also this legal disclaimer, I was asked to add some information about that, and now listen and repeat, this is only my opinion and not an official opinion of any of those mentioned people, so here we continue. So what's wrong with the current protocol of ERPM thing? So if you try it, you find that it does not scale. That does mean if you run it on your computer, you get somewhat about 10 kilobytes per second, and if you look at the size of the repository, it's about 30 gigabyte, and then you can calculate how long it might take until you have completed the same. Even if you have deltas, well, then it's a bit faster, but it still needs some about three days or something like that, and SUSE can produce new packages faster than you can download them, even if you only don't download deltas. So, this is not really a problem of the protocol, but of the tool acceptance. The tool acceptance is especially by mirror admins. If there were enough mirrors of this ERPM thing service everywhere around, that should work, but actually they aren't, and so there's only one mirror server or only one server, the official server of SUSE in public, and this server is pretty low, because it also provides other services and it has a certain bandwidth limit, and so it can only provide about 10 or 20, sometimes 20 kilobytes per second. So, the protocol, as it is currently, is not ready for the real world. It works in a special situation where we have good bandwidth connections, but it does not work outside. So, how can we solve that? Here I will tell how I did solve that with the tool I have written. The first thing I did, I was telling the annoying Christoph, and was whining about the fairness of the world, but unfortunately that did not help. So, next step, I tried to teach the ERPM thing to fetch the deltas from an alternative server, but Mika is somewhat mixed to document some functions and so it was a bit difficult. It's probably a little bit difficult. It never needs, yeah. The semantics were not that clear for every function, so I thought I will first try to do an alternative proof of concept implementation, and I thought that might be the ERPM thing, because it's mine, but we can change the name if you don't like it. So, now what is about that tool? The first thing, I think, is you can use all async servers that have the deltas mirrored from the ERPM service, and there are some. And so, we can use the established mirrored infrastructure and we don't rely on other ERPM service being around all over the world. Should we need the META information from the main server, but only META information, not the deltas themselves? The second thing is I made the client multi-threaded. That means I can use multiple processes for applying the deltas and I can use multiple network connections, to guide some mirrors or something, to have a better bandwidth connection. And then, another thing is that many people don't need all the packages. The standard ERPM service just mirrors the whole repository, and if someone has only a 20-32-bit internal machine at home, he doesn't need the PowerPC packages, and he doesn't need the 64-bit packages for the AMD system, and so he can just deselect them. Or maybe he doesn't need the sources, he doesn't need the debug-info packages, and all that stuff, he just deselects them, or he can use a custom filter to filter out some packages he doesn't want to. For example, if someone likes KG, he doesn't want no packages or the other one, and another thing I did is that the client is quite robust. The problem with the other client is if there is a problem with the server, he stops with an error message. And if you have large data to collect, I think it's more useful to just skip the step first and download the other stuff, and later you can then look at the problem and fix that so that the download isn't broken because there are some problems with the server. So are there other alternative solutions to solve these problems? What I also thought about is the reason why MagnumMirror admits that they want this tool is that they say, ah, we're seeing for everything and so we don't want another tool. So what could be done is first to make this set to clean, implement the primary infrastructure in housing to handle specific files with specific algorithms. Normally housing just checks, doesn't check some calculations, and only mirrors that parts that differ if you have already an old version of that file. The problem is that this does not help very much with RPM because in RPM the payload is compressed and thus these checks and calculations are almost every time incorrect and it doesn't work. So if you did that, you could implement the algorithm that the RPM is using as such a topic for housing and then housing will only handle the normal files as it did every time before and it will handle these packages with the algorithm as the current RPM simply does as well. And then the first step which is also important is that this all helps only if you manage to convince the mirror admins to use this new version of us if you don't manage to do that, it won't help. So how to improve the current protocol? In my opinion, if you have only a very low number of RPM service, they should have a mode where they only distribute the meta data and the other stuff is taken from other servers. For example, R-Swing, FTP, or whatever you like. And there is a problem which META also mentioned to me, there might be inconsistency between the mirrors. It might be that one mirror has to catch up to the RPM server and so you can't fetch the deltas from this mirror. And this is a real problem, but I think Christoph will tell something about that. There is download.oc2c.org server which knows which mirror servers have already mirrored some files in. Maybe that could be used in connection with the system to check which mirror server does have this and you can ask this, especially with the RPM server, I want this delta and I want it from any server and this service does give you a hint where you could download this patch. And then you can collect it from a fast mirror and only have to ask the central server about the location of the patch, which is then much faster at least I think. So finally you may want to ask some questions, give some comments, or some rents or something, you can either do that here or you can do that by sending me an email. So rather than convincing all the mirror maintainers to switch to your favorite method of replicating copies, why don't you set up your own kind of mirror somewhere at an ISP and do it the proper way, the way you want it and just get it done? Well the problem is if you need a mirror with high bandwidth, you either have to pay very much money or you are at an institution where you have the infrastructure. For example, you in Germany, you know me at home, when I come from Germany, the universities have very good bandwidth and I think it's maybe the same in Belgium or anywhere else. So what you've been trying to convince mirror maintainers to switch to that system, send them an email, send an email to ftp at ftpadmin. I think it does only work if you know these people. Exactly, that's my point. So get them together, do a conference, invite them, give them a free t-shirt, make them happy, give out cookies, warm milk and yeah, do it from there. This is a step that must be taken, but I think it's easier to do that if you have some tools that are similar to those tools they are used to. Definitely, but you need to get at them. I don't think sending an email or hoping they might come to this conference and hear your talk is working. Well we are working with our administrators to use DRP M-Sync but it's not that easy. I have talked to, you might go back for example, we used to do an FTP GBB for a couple of times and he refused to use it. So there's one out, but... Yeah, he's not out, but I think maybe sooner or later he will use it but it needs lots of time to convince him that it's good idea. I think you should get them in and do a workshop and maybe ask them to present their side of the whole thing to you. I mean, get in a beemer, let him sit down, log in, show his kind of work environment and I guess that's the main thing that you need to know about this. I mean, switching some part of the system takes a lot of talking. So rather than talking, let them do the talking and maybe you see how you fit in to that kind of system. Okay, that's right, what you say. What I wanted to do here as well is to show that there is a tool and I hope that some people try this tool I have written and you see what is better or what's better with the other tool that is there. Adaments don't test. Adaments work. Yeah, but other uses... Currently we have the situations that we don't have mirrors for that system and so currently we have to use another tool because the other one does not really work because it's slow. And so if some users are interested in mirroring the factory distribution they could use that tool and give feedback and that's also helpful for improving this tool or for merging it with the tool that ETI has made. The point is probably that the admins tell us that the tool isn't used and the users don't use it because... They use it. Yeah, but because if they use it it's slow because we don't have a good mirror structure. So kind of deadlock here. And so we have to start with something that does not rely on having an infrastructure in the first place because we have to start that process somehow. Another problem is that in a lot of institutions you cannot add an extra service without going through a security review or something like that. So this is an extra service and the admins will have to convince their bosses to actually have it running on their service and stuff like that. So it's not that easy. There it is. So how many more speedtops do you have because one third of the time is gone, I guess? Yeah, we have two. But we'll manage. Because we have... Stefan told me we'll have more time because it's tall and it's big. It's shorter. Yeah. So no time to work. Good. Any questions on Expo? Expo. Do you want to know what that is? Okay.