 Okay, so welcome to the Debian Derivers round, or not as quite as round table. So let's see how this works. To kind of do a little bit of an introduction, there are 100 and there are 129 Debian Drive distributions listed on the DistroWatch webpage, which means that they're based on Debian, which is more than, which is the most, they're only 86 that are based on Red Hat, which can be a little bit of a mixed blessing. It means that more people are using Debian, but it means that many people are developing on top of Debian, but it means that many of them are doing it at a little bit of a distance. They're not doing it directly on the project. Some of these are pretty heavy distributions. They're things that look a lot more like forks in the traditional sense, and many of them are extremely minor, maybe extremely minor derivations. I think that it may be interesting to look at derivations in terms of the types of changes that are made. There are a number and we'll talk about some of this stuff. I think that they happen on the level of package selection in terms of choosing which software to select. They happen on the level of customization and configuration, very often in people that are configuring packages in different ways. They happen on the level of custom environments for installation and for use in terms of different environments like live CDs, like Knopix, and a number of these derivatives. They happen on the level of code level changes, and there are loads of those changes as well. It's kind of my belief that in the near future, most people who are using Debian are going to be using Debian not directly, but through a derivation. I think that eventually most people who are doing development will also not be doing development directly in Debian. At the moment, much of the work, I don't know, maybe most of the work that happens in derivations in all those derivative distributions. We haven't heard back from most of them. Debian the project doesn't have good healthy relationships with most of those derivations. This panel of people is, in some ways, this is the panel of people we do have good relationships with. These are the people that are Debian developers that show up at DebConf, that are willing to engage in this conversation on Debian lists, at Debian conferences. In some ways, this is exactly the group of people we don't need to reach. Then again, we are in a position, as people that are working both inside Debian and outside Debian. These are people that each have a foot in the project to foot outside of the project. We are in a position to educate each other and the larger project and the larger world of derivations on the best ways to work with Debian while working apart. I think we need to help find out what that is. I have a number of goals for this session, perhaps too many, we'll see. The first goal is that, and not just for this session, also for moving forward, one of my goals is to help Debian understand why there are so many derivations. This is the whole, one size does not fit all. A lot of times you hear, why don't you just do your work in Debian? Why don't you just work on Debian? For 130 people who have the technical capacity to derive and to build the derivative distribution and the need to do it, some of those may be redundant to each other and to work that could be done in Debian and some of them can't. I suspect that everyone up here who understands the value of working with Debian and working inside the project and still finds the need to derive in one way or another. So helping people understand that this is a fact of life is important. We need to wake up to the fact that in terms of the Debian community, distributions are a way of life and they're going to be an increasingly important way of life. And that kind of leads into the second issue, which is that I think we as Debian need to ask ourselves what it means to be a project in an ecosystem of distributions, right? To no longer be the one place where everything happens, but to be a single point in a larger network. I also want to help put drivers in touch with each other because I think that working with each other is something that will happen. In working with Debian and working with each other, we can all benefit more and we can help share knowledge with each other and help kind of create common solutions to common problems because I think that we'll find that a lot of the problems that people are faced with here are shared ones. I'd also like to create an open kind of venue where we can help document the processes for people who are not here to help each other. I think that if we can make it easy to derive and give back to Debian, most people will, or many people will, including those people that maybe don't want to come all the way to .com. Yeah, and then I just want to have these groups, both kind of like the Debian project and the drivers, start talking about some of the tricky issues and kind of start thinking about what kind of solutions we have to those. So, in that way, the way that I want to structure this is that I'm going to try to give each person about 7 or 8 minutes and I'll try to be the clock fascist to talk about a number of questions. I'm going to want everyone up here to give a brief description of their project in terms of what they do and how they do it and also to kind of describe the nature of their relationship to the Debian project. I then want people to kind of answer this question briefly of why didn't you just use Debian, right? What is it that made you want to or need to diverge in whatever way that you did? So then I'd like to kind of, then maybe I think it would be good to talk about perhaps the greatest frustration in terms of building a derivation, in terms of working with the Debian project, in terms of kind of building this kind of system. And then if anyone, and then if people would like, maybe they could share a mistake or a lesson learned or something that they can help share with other drivers and with the project. So I think that I've got a list of a couple things that I want to be brought up and if they're not brought up I will bring them up afterwards. So I'll probably just try to work down the line and we'll start with Dan who's here with the HP Debian enablement, right? Okay, so I'll let you take it away and I'll kind of watch the clock and make motions at you. How's the mic working at all? Yes? No? It's okay. So I work in a group in HP that's called OSLO, which stands for Open Source Linux Organization, we do a project called HP Debian enablement. The goal of this project is to provide a Debian distribution as much as it can be a Debian distribution, but also have special features mainly around hardware support for customers that have come and asked for the service. So I would say that probably 90% of the work we do up front is just adding support for new hardware, which, you know, make this question about why we can't just do it all within Debian is, you know, we want to support SARGE and we want to have SARGE security updates. We also have support for the latest I-64 processor, so we'll often do like right now we're working with a, we have a custom version of DI, which we just swap out the kernel, add a task package, and, you know, it works with a new chip that's just come out for I-64 platforms. Then the distribution beyond that, we have stuff for specific vertical markets like telco environments where, you know, SCTP support, user space packages, some stuff around IPMI, stuff like that. It's mostly around hardware support or specific markets. And then we'll, over time, a lot of the stuff like EV logging and stuff like this isn't stuff that we think the open source community really wants, stuff that wants to go back into Debian. We just have one or two customers that need it. So we don't think it's good for the overall user community in a lot of cases because it would require a fork. Some other cases is stuff that we do development for and we push back, like if we add new hardware support, we of course want the next Debian port at least to support it, so we'll put those patches back into the Debian kernel project. Let's see, so I took notes on my hand on the questions Mako was asking. So that's why we do it. And now I can't read what I wrote. That's a brief description. Why didn't you just use Debian? Yeah, why didn't we just use Debian? It's mainly we're just always a little bit ahead of Debian. So we need to add patches, stuff to the kernel, and then, you know, a lot of the stuff we did during the woody timeframe. We fed back in and now we can use it in Sarge, but now we have a new platform. So now we have to do a version of Sarge that has a few things that are different. But there's many, many reasons we want to stay working with Debian as much as possible. Getting free security updates, stuff like that is definitely something that's good for us. You know, it saves a lot of maintenance on our side. So your greatest frustration in terms of working with there have been any frustrating situations in terms of building your derivation? Um, release cycle. I mean, it's definitely the most frustrating thing. If we could put a patch into Debian and we knew, like, three months from now we'd have any release out, that would be awesome. So it's predictability and frequency, or both? I would say personally for me, yeah. Okay. Both of those, too. Okay. So difficulties. I have a question. Yeah. It is often asserted that I've made this assertion myself based on some conversations Jeff and I have had with potential customers approaching that the enterprise, users of Debian are interested in a release cycle that's fairly long, 18 months. Do you feel that to be true in your experience, not just personally, but in your dealings with the customers that get your enabler product? So you're at your question. Yeah, can you repeat the question? Maybe you can make it more concise, too. I'll try to rephrase to make sure I understand what you're asking. So you're asking about the length of maintenance of a release, if how long a release is maintained? Yeah. So essentially he's asking with the customers we've had an experience with what they kind of expect in terms of length of a maintained release cycle. And actually, since we do a lot of work with telco people, 18 months or whatever is very minimum. We're expecting to support people like probably 10, 15, 20 years on woody bits. So we don't really know what that means in terms of security support for a lot of customers. It changes in different environments, 15 years of supporting woody bits is going to be... So the three-year release cycle is way too short. Well, it's way too short if you're thinking... We have new customers coming on board all the time. So we need new hardware at all times. So you're going to have to pick up security support for woody for the next 10 years? At some level, yes. At some level, okay. It won't be as much as the security team does, but yeah. Yeah, hold on, there's another... Okay, do you want to... Can we do a follow-up first? Just a comment that when I first heard those kinds of numbers, they blew my mind. I was trying to draw you out on that particular kind of information because I think it's something most Debian developers have not heard or thought about before about that kind of length of time. So that's really all. And I don't know that everybody's that way, but we'll push BDAL onto the stack. I'll yield back. Yeah, is it okay? I mean, you can defer to BDAL. Yeah, and I got to point out that one thing that makes Brandon probably nervous about this is that Prodigy is doing a lot of the security support for this. So from my perspective, it's not that big a deal. So we're the ones that are on the hook for that 10 to 20 years. Just point it off on Indianapolis. Right. Yeah, so Dan started to say this, but I want to make sure everybody's really clear on this. It's not that they want you to release less often and have a longer release cycle time. What customers really want is that when they're in the process of deciding to adopt something, they always want the latest, greatest and freshest stuff, but then they want to have control over when they have to leave that. And if it's a telco customer that's deploying a lot of machines on private nets as part of deploying mobile phone infrastructure, they don't want to touch the machines at all. Updates are anything for like five years after they turn them on. And so it's an entirely different set of expectations, but all over the place, embedded systems developers are even worse. When they're building a new product, they want the absolute, latest, greatest bits, and then they don't want those bits to change until they do another product cycle. And so the length of the bit, the life cycle of bits has to be the life cycle of their product or their deployment or whatever. And this is where, for a company like HP, there is actually a business opportunity around the notion of, you know, people are sometimes willing to pay for that length of support and for the stuff that goes with it. Okay. So I want to yield back to the mission. So you said, and correct me if I'm wrong, you're going to be supporting Woody for more or less than other eight years? Subsid of Woody with some bits changed and we'll be supporting it at some level for, you know, probably 15, 20 years. On what level would it be possible to make this available to the general public? It is available to the general public, but what's available isn't usually desired by the general public. So I'm going to do a server called hpde.linux.hp.com, which has these bits there. Right now they are mostly IA64. Actually, everything we've put out so far is IA64 based. So for example, Woody, when it shipped, when IA64 had a 2417 kernel and stuff like that, and we've upped it to 2425 in one flavor and a 2420 that's heavily patched in another. So this stuff works very well for the customers that want it, but we haven't had many requests for things beyond this type of environment. Okay, so we won't be announcing Woody's security support for another 10 years tomorrow? No, no. Thanks. And in fact, you know, we have a specific set of customers mapped to each release. So if a set of customers say, we don't want security anymore, well, we're probably going to drop security support. It's not generally available in that sense. So just one other thing that you said that I kind of maybe want to draw out is that you mentioned that it was a subset of Woody's. So you're not supporting, so how big of a, so selection in terms of what you're supporting is an important aspect. So you have longer release cycles, but smaller subset. How big is your subset? Do you have any packages? Brandon might know more about this in the Woody subset. How much of it is actually Woody, do you know? I would say like... How many total packages? Maybe 50% of it. You're talking about HPD-1, right? Yeah, so... Oh, it's an obnoxious hybrid of Woody and Sarge as of 2003. So you've got a... Okay, so you've got Quasi Woody. How big is it total, just to get an idea? I'd probably say 700 packages. 700, okay. Yeah, it was just over one CD's worth, I think. Okay. So in terms of megabytes, it's probably about 700 or 800 megs. Okay. And we were actually moving to keep that smaller as releases go. Yes. So the new stuff based on Sarge is probably closer to 300 packages. Yeah, it's considerably leaner. Okay, all right. Well, just before I cut you off, is there any mistake or lesson to learn or something that you would want to share? Yeah, there's a lot of process mistakes that we made inside of HP as far as just maintenance. So we, like, porking off all these... We have, like, a 1.0 release based on Woody, a 1.2 release based on Woody, or when I say release, I mean streams. And over time, we just let it balloon too much and Brandon would probably agree with me that we started backporting a lot of stuff from Sarge because we thought it would make more sense. So, you know, maybe in short, the biggest mistake was splitting off too much from Debian. And how many people do you have working on the project? Within Progeny, I don't know. Within HP, most of the people we have is doing development of features in, like, the kernel. And I would say probably, you know, 10 people there. Okay. And as far as release maintenance and side of HP, two of us. And then working with Progeny to do a lot of the rest. Okay. All right, great. We can come back for questions for the whole group. So, we should try to keep things moving. So, I'm going to move to the next one. We're going to talk about embedded Debian. Hi, I'm Wookie. I've actually done this twice. Once was Alapharm Linux, which is one of these micro incredibly trivial derived distributions. So, that was just making things work properly on the Acorn RIS PCs circa 2001, I think. And that's easy. There are a few packages because they currently don't work like the installer was broken and used Debian CD to make a slightly different unofficial CD. Basically, all those changes can go back into Debian. But, like you said, in the interest of getting something released now, you just do your version and then you worry about shoving them back upstream in due course. And they work their way through the system. So, that's fairly painless. But these days, that's defunct. And I'm interested in embedded Debian. Now, it's not actually a distribution at the moment. We haven't got that far. It's a load of tools that sort of work and some principles which we'll talk about later today. But, the idea is that we can use the multiple architectures Debian supports and the consistent code base to make nice neat small distributions as opposed to massive desktop and server distributions. Why can't we just use Debian as it stands? Well, because it's designed for desktops and it's fat and huge and monstrous and full of stuff that you don't want on embedded systems, like documentations and 57 languages and all sorts of stuff. We want 64 meg system images, not a gigabyte. So, it's quite different. Now, it may be the case in fact that it's so different that trying to derive from Debian isn't practical but this isn't fully determined in the process of trying to do it to see whether it makes sense or in fact it's just a dumb idea. The things that we need to kind of deal with Debian about is basically persuading all you guys that cross compiling matters. Obviously, Debian is entirely natively compiled at the moment and built because that works. But, in embedded land, people need to cross compile for our existing stuff, especially some of the more ancient architectures that are unbelievably slow. It might actually be useful to cross build those so you didn't have to wait four days for open office to build an arm and that kind of thing. So, in the same way that we've made everything work across lots of architectures and fixed an awful lot of bugs over the years because of that, we could in principle make everything cross build properly. So, all the technology exists and it's all horribly complicated and it would probably improve everybody's code and it would improve Debian and it would go back upstream to fix everything else. So, that's the kind of that's why I think it will be it will be fun to do but for that to work there has to be quite a lot of buy-in from everybody that this is actually worth doing. What else? Debian installer is in effect one possible instance of embedded Debian. It's a small distribution for a particular purpose derived from the Debian code base. That's exactly what everybody wants to do for whatever their particular purpose is. Obviously, Debian installer is particularly closely tied to Debian and most will be less so but the idea is that we could do lots of things like that. The biggest problem at the moment is that with this work we have to mess with the tools like d-package and d-package cross and d-package dev and debhelper and all that kind of stuff and so we go all we want to do is this and we change all our tools and then while we're all sitting around not doing anything fast enough everything changes in Debian and it stops working. So, as I've explained this afternoon we all had it working in February and that's the biggest problem is that there aren't enough people working on it fast enough to keep up with Debian and that makes us go even slower. I think that's probably all I... You mentioned so to kind of reiterate something else that I thought I heard was that perhaps our frustration is convincing lots of people in the project if you've got a major change that you think would be a good idea that would enable you to do more things, something like making cross compiling more easier. What else did you mention? Actually, one thing I forgot to say is that the reason why we can't use Debian is that the embedded things are very different. We want smaller package granularity in a lot of cases because you don't always want... Debian basically by default compiles builds things with everything that it can do built in and often on an embedded system you want to build it with some of the things it can do built in. You might want the X version and you don't want both and often those are all in the same package so to make it work you need to split things up into more packages and always split the docs off and all that kind of... basically a finer package granularity works a lot better and a lot of those changes are quite intrusive. So we either have to maintain them separately, which makes embedded Debian very different or we have to persuade Debian that this is generally useful in which case it's a lot easier to maintain but it affects every package you're out there. I think that's a problem that we'll probably hear more of and say how do you persuade the project that something would be a useful thing even to a large group of people so maybe that's a problem that we'll hear again. Yeah, there's a question. As far as I remember there were a lot of bugs about making some packages able to cross compile Do you have any insight how the experience was with this? Is this working good? Or has there been some regulation from above to keep the maintainers applying these patches that they were... I'm not aware that people have been sending in lots of patches I know for example the new TILS cross compiling patch which was... various iterations have been submitted over the last year and a half hasn't actually made it into the main package yet for no particularly obvious reason so now we get the impression that people aren't particularly inspired and to be fair I can see why it's not something that really concerns them at the moment it's not a big issue for Debian and we need to make it so if we're going to succeed so everyone is... there's this situation where everyone is welcome to file as many patches with wish list bugs as you want but that doesn't mean that anyone will need to apply them and in situations where the benefit isn't directly obvious to the Debian maintainer I guess perhaps something that I'd like people to realize is that sometimes a closer relationship with a derived distribution can ultimately be a very beneficial thing in situations where it doesn't change the default behavior or alter things maybe applying that patch to minimize that delta over time is going to be a useful thing in and of itself so if you want to... was there another question? one more question, sorry that's a comment yeah do you hear me? could you please people introduce yourself because I'm not sure I mostly know yourself but I'm not sure everyone around knows about your names and so on and so on I think it would be nice of you I apologize for not doing that before so I'm Benjamin Mako Hill I worked on Ubuntu and on Debian nonprofit and probably had my hands on some other trouble making I'm Dan Frazier I work at HP most of everything I've done has been around the debian and ailment stuff as far as CDDs are concerned I'm Wookie I work at Aleph1 we basically do armlinux consulting and on my personal main interest known as embedded debian my name is Geoff Laquia I work for Progeny and I'll get more into what that means in a few minutes my name is Peter Reynoldson I'm involved in the school linux debian EDU effort and a few other projects my name is Andreas Tiller and I initiated the Debian Mids project which is basically supports medical application inside Debian I'm Matt Zimmerman and I'm representing Ubuntu here my name is Roger So I work for Sanma Linux which is in Hong Kong and in China we focus on a desktop there have been distribution there's one here you want to introduce yourself quickly apart from being late I'm Simon Holman I work for VIA Linux amongst other things we're doing a bunch of application servers based on Debian push this it works first I'll speak slower now I work for VIA Linux in Japan and we do application servers based on Debian we also do a lot of other things thank you okay so Jeff now I'll let you have the floor as I mentioned my name is Jeff Laquia I work for Progeny in Indianapolis Progeny's relationship with Debian is pretty strong the founder of Progeny Ian Murdoch is also the founder of Debian and if you will the Ian in Debian so obviously we have a long and pretty strong relationship with Debian and a strong affinity towards Debian as well in the beginning we did a Debian derived distribution called Progeny Debian that went as well as seemed to go pretty well nowadays our business is focused on customizing distributions in general doing custom distributions for various of our customers we found that a lot of people out in the world are interested in using Linux for various applications but most of them tend to want to focus on one particular part of the problem so if you're if you're doing say a media center you might be really really really interested in your in your video codecs and audio codecs and mplayer and myth TV and stuff like that but core utils and libc and stuff like that oh you know whatever yeah I guess I have to deal with that one of the things we do is we allow people to outsource those parts of their their efforts things like security updates and making sure that all their stuff works together they can allow us to do it we provide them with the basic pieces of a distribution that's customized to meet whatever their particular need is and then they put their stuff on top of it I think HPDE was mentioned as one example of someone who we've been successful in doing that with um let me think there's been a lot in some cases of what I'll call a negative perception towards Debian or a negative sort of attitude about Debian I think a lot of people are a little bummed about the serge release process and so I want to take a minute and instead of talking about something where you know something that irritates me about Debian I want to talk about something that's actually really good that Debian does well that other people would do well to emulate because of the nature of the market we not only do Debian distributions but we also do distributions based on Red Hat and other RPM based systems for some of our customers and I have to tell you that whenever you know obviously we like customers and we like we like the relationships that we have and of course we'll do whatever people will pay us to do because we're all familiar with how that works but when we find out that there's another Red Hat RPM based distribution that we have to do we all kind of grown, yes because of the unique nature of Debian the fact that we do not have some grand overlord brand and accept it of course we do not have some grand overlord standing over us telling us that we must cooperate in certain ways who can walk in and say I want this done now darn it and who can threaten our paychecks if we don't Debian has been forced to create an infrastructure that in my opinion is second to none in terms of building distributions in a transparent and open and scalable way for all of the problems that we had in the Sarge release and for all of the difficulties they would not first if we were forced for example to use the publicly available infrastructure that is out there for RPM based distributions most of which is non-existent, non-documented or very klugey and otherwise thrown together by people who are just trying to duplicate whatever it is that Red Hat does internally to themselves so that was, that's something that I think is important for us to keep in mind is that while our processes are not perfect they certainly have their advantages and I think that will continue to be the case at least that's been my experience in terms of lessons learned I think it would have to echo what Dan said to the extent that any derivative deviates from the Debian from real live Debian it is usually to their disadvantage they'll end up paying for it later it's been our experience that while of course obviously if we didn't have to make any changes we would just use Debian so if we so obviously if we use so we have to make some changes but to the extent that we make changes sort of gratuitously where we cannot identify an actual need for an actual patch to a package that is in Debian that later tends to bite us we tend to end up having to maintain it over a long period of time and that ends up taking a lot of time that we could probably put to more productive use so one of the things that we've learned inside progeny is that whenever we do make changes that we have a very clear documented need for it I think I've covered why we do why we don't just use Debian I think that the reason that we don't just give people Debian is that most people take a look at Debian and they see this 14 CDs worth of binary packages and they say oh my gosh what is this and they tend to get overwhelmed one of the services that we can provide is that we can tell people okay look you got 14 CDs worth of binaries but really all you need all you absolutely have to have is this very small subset and then you can pull the rest the stuff that you need out of the rest as you need it do you have anything that you didn't cover any lessons learned hard lessons learned you've covered the rest lessons learned communication is very important being in touch with the people if we're if progeny is taking a bunch of stuff and we're sort of making a business out of taking all your stuff and selling it to people there's I think a bit of an explanation that we have to keep our communication open and to give back to the rest of the community to the extent that you do that to the extent any derivative does that I think that that will make it's been our experience anyway that that will make your relationship with Debian a lot better so you know telling people that you're doing something to their package sending them a patch explaining why you did the patch and what benefits that patch gives you putting a package out there anonymously that's changed and the package maintainer hears about it later because some poor soul has got a bug and they go to the Debian people instead of the us and you know the maintainer is like what the heck is this what this guy do what are these progeny people smoking you know so to the extent now obviously we're not perfect and we have our communications issues as I'm sure everyone does but to the extent that we can we think that communication is essential right so communication with the project that sounds good something else that you kind of said that I maybe want to highlight is that it sounds like you guys are you've got kind of a derivative of Debian and then you're also doing derivatives of that which you are would so I mean is that kind of accurate or yes that's correct I should have propped that up before we have sort of two two a two pronged front to this first of all we do right now we do custom distribution sort of on ad hoc basis you come to us you tell us you know you give us like maybe you've already derived the distribution and you want you need help maintaining it and we'll do that for you we also are starting an initiative to make it easier for people to derive off of Debian called componentize linux which you can find out more about it componentize linux.org we're also building a tool set to try and make it easier to do derive distributions and other other efforts basically aimed at making customization of Debian and also possibly in the future of RPM based distributions a lot easier. I just kind of wanted to highlight that because I think that we'll hear about this again and it's this interesting idea of so when I talked about that ecosystem it's easy to think of it as like a wheel with Debian in the middle and then lots of spokes out there but I think that increasingly often it's becoming much more complex and now derivative distributions with derivative distributions and who knows maybe there'll be derivative distributions and then and kind of I mean in some ways that makes your role increasingly important in this ecosystem and in some ways it kind of just makes this a little more complicated in ways we should think about definitely. Alright so maybe Petter I'll with you Yes as I said I'm Peter Reynolds and I work with the school Linux DBNEDU project we are trying to make a Debian distribution for schools targeted for the pupils network in schools. Actually we are trying to spread Linux into the schools we are not really one wishing to be a distribution maker but we had this vision of out of the box solution for schools and it was not available so we had to make it ourselves we are heavily involved in the Debian installer effort in Debian we took over the project when well just after Puddi was released we have been doing one release based on Puddi and are now working on a search based release we try to put everything we need back into Debian but when we don't succeed we need to add some extra packages the reason is of course we don't want to maintain software we want to spread Linux we have also been involved in the testing security team effort and also have provided a few fixes and patches to a lot of packages we started with the Vuddi based version with approximately 900 packages where I think 30 or 40 where special packages not in Vuddi and I think when we get the search version out we should have approximately the same number of packages but only less than 10 special packages for school Linux and I guess the answer to the question why not Debian is that Debian was not doing what we wanted we provide a set of services 15 services that work out of the box preconfigured and they integrated together on simple installation or from a simple installation CD we also provide a workstation profile that will connect to this server and work flawlessly with home directories mounted on all the workstations with email working with clock synchronization centralized logging common user database single sign on and all that kind of thing that's working out of the box this was not possible to do with Debian without a lot of manual work and when you want as I do my related teacher to be able to install Debian preconfigured to work out the box in the schools you cannot give them a 200 page manual go through all these configuration files and fix this stuff and then it works nicely because they will just find something else to do as for our work within Debian we have 7 Debian developers I think on the project and approximately 200 contributors in one level or another we have been working quite a lot on translations and most of the contributors are translators we have tried to push our changes back into Debian as far as we can of course some project participant project members are better than to do this than others and we also have experienced that some Debian developers are easier to approach and get them to include our fixes than others I think that's the main issue we have with Debian talking to Debian maintainers and well getting response from Debian maintainers if you actually get them to talk it's a lot easier to get communication going but when you send off a bug report and try to explain why you need things and nothing happens at all for 2 or 3 years it's a bit painful it's a bit painful even when you're not a driver I think luckily that's not the common case but in some cases that's an important part we need to have fixed and we don't get any communication going another thing we would really like to get more help on is to make the packages install time configurable we are configuring at install time we do not want to modify the configuration file after installation and the methods we have come up with so far is preceding which is in the normal Debian installation system and multi level configuration which is another feature that has to be coordinated with upstream of course so it's more complicated to get it in and as the last resort we just modify the configuration file of other packages to get them to do what we want but then we break upgradability so it's not the preferred option so we would really like to get all you Debian developers to make your packages more configurable at install time and don't say oh the system administrator can just modify this when the system is installed because it's not an option when you have two machines to tell one system administrator with two to four hours a week to work on computers to do configuration of these machines that doesn't work another problem we have experienced is not really a Debian problem as such but it's a problem with free software we are missing a few key free software pieces Java and Flash that seem to be the highest profile software missing we in Norway at least have all the national tests in schools done on Flash and we would really like to provide a complete solution with free software and when we have to tell the schools to use Macromedia Flash it's not really a good feeling the same with Java Java applets are used quite a lot in schools to demonstrate smaller educational topics and when there is no free applet viewer that works and there is no free secure applet viewer that works it's not really convenient to tell them to use free software so please help the Java community and help the Flash community to get free tools available another minor issue is that we have 900 packages we want to put on our CD some of them do not make it into the stable release and we have continuously needed to keep track of all the packages and find out oh it's been thrown out by the release team and try to find out why and try to get it back in and it's we've missed a few packages Celestia was a really nice packet that was thrown out of Sarge we didn't discover it before Sarge was released so it's not in Sarge yeah so that's at least one point where we need to do a better job in the future keeping track of the packages and make sure they actually make it into etch at least one problem we also discovered was that we spent a lot of time talking to maintainers of packages got them to include the configuration options we needed to get them installed properly and then the maintainer changed and the configuration was thrown out again and we didn't discover until a bit later and never had time to actually try to get it back in again so we need to keep track of all the packages we need to have configured and make sure they stay configurable if we have been so successful to get them configurable at install time and we haven't done a great job there either because it takes a lot of time to talk to talk to maintainers do you have anything I think that's a pretty good cover so we can probably fill in any gaps here oh yeah there's a question are there two questions where was the other one oh three questions okay should I begin just yeah let's do are there any obvious or kind of trivial ways in which Debian could improve the trackability so you said you had problems to keep track with packages and with changes and when they get thrown out of the release and is this mainly a problem of manpower on your side or are there really some tools missing in Debian to make this easier or are there tools missing but you don't know really how they should look so it's we have made a few tools to keep track of the packet lists and I don't think the main problem is lack of tools of course better tools to make sure we get more faster notification of the packages going being thrown out of the testing and stuff like that would help but the main problem is when we do discover that the packet has been thrown out we need to put man hours on our side to get in touch with the people on our side like the maintainer side and get man hours from the maintainer side and talk together and try to get it fixed so it's a man power question more than a technical question At a certain point a lot of these problems come down to conversations with the maintainer or working with people on a maintainer by maintainer basis and the problem with that is that even if you're maintaining 800 packages we may be talking about 400, 500 with 500 people the I don't know the balance there is a little off 500 people can each spend 20 minutes of their day emailing that but the five people to 500 can be really, really tricky and maybe finding ways to streamline this so that we should maybe be thinking of ways to stream on this so that small groups of people can kind of communicate with the debbie in trying to solve problems that maybe can avoid a lot of these conversations as well and to put in more comments on that the latest effort we are doing is to get a better thin client support or actually a different thin client support into debbie on call LTSP and this involves kernel work, X work and hardware detection work and if we don't have some features in the kernel that affects like 10 other packages which need to do redirectional files which can no longer be in ETC because they are put into a temp file system or something like that so it's like coordinating work with 15, 20 maintainers in debbie and convincing them that this is a good idea it's a lot of work especially if one person can stop hold up the show so can you hear me? yeah a little bit being a high school student and a debbie in developer at the same time I've had to encounter many of the obstacles that are associated with only using Linux on your laptop which has been the case for several years for me so there's for example at my school I had a bunch of textbooks where they came with CDs that required stuff like Internet Explorer specific stuff they would block out Netscape and Mozilla and things that used macromutus director to demonstrate things and I'm wondering first of all how school Linux is prepared to approach that kind of problem because it's kind of hard to petition the people who make textbooks and stuff like that to not do that kind of thing and present a more architecture independent solution and secondly are there any ways you can get around those kinds of problems like the Internet Explorer stipulations that many things like these require I can only talk about this briefly because we got to keep going but yeah I don't think it's that hard to get the let's call them creators to change their behavior because when you have a lot of schools we have approximately 200 schools I think in Norway at the moment and then we are major force factor in the educational sector they can no longer ignore 200 schools not being able to use their software not being able to look at their web page and not being able to do the national tests so the vendors have to modify their pages to get them working with Linux and it's just a question of numbers if you have your big enough minority behind you they can no longer ignore you so we have thanks okay so we got another question I'm wondering do you think it's feasible to use debconf to configure all the packages on the system for your customization needs and do you think it's a tool that was designed to do that because that's what you want to do right yes I believe it's possible and quite feasible to actually quite well designed tool to do configuration at install time yes even for complex even for complex things like complex configuration you think you can fit everything in debconf questions yes to some degree I would add on multiple level configurations so you redirect the configuration to a different file that has been provided by the installation overrides okay thank you alright moving on Andreas from the kind of there's a school of Linux meeting on Thursday at 18 o'clock and the hack lab in the room behind the hack lab so everybody who wants to join us is invited excellent excellent thanks so now Andreas maybe you can kind of give us a little bit of the custom W distribution angle okay I'm Andreas Tiller I'm just initiated the Debian made project which leads many people to the conclusion that I'm a doctor or whatever no I'm not I'm a physicist and I was Debian developer before I entered the medical institute where I'm working now and I'm just hoping to convince my colleagues that medical software is available under Linux and it is a good thing so I also do some general custom distribution stuff and might like to say something before because you might conclude it from my accent I'm a German and German people are known as always be whining about things which do not work this is not a problem because the things which work are fine there is no task to do because it is fine we have not to change it we have to change the things which are not good and that's why I'm talking about things which are not good and don't think I'm an off-putting person I see the good things and I know the good things but I will not talk about them so Germans are seeking new jobs for instance if you look at the 129 derivative from Debian and only 68 from Retard or whatever and say oh it is good Debian is flexible well I can say oh it is bad because 129 people think Debian is not good enough for me but only 68 people think Retard is not good for me and so there are more people who think Debian is not good because they have a reason to enhance it and so I want to reduce the reason to enhance Debian in making it better so it's no whining I'm just looking for things we can do better inside Debian so my reason to go to Debian met was that I learned that there is no critical mess of developers of this special field the people don't know each other they are working in separate and I think they got not really the idea of free software how to work with it they just thought oh it's free I can do it and do whatever I wanted it is possible but it's not a good thing and my idea is to be that the Debian developers should be the missing link between upstream and the users so there is a missing link because all these developers of free medical software were able to use their own software perfectly but they had no users because there was no usability the programs even were not known in the world and so people reinvented the wheel over and over that's why I started the Debian met project we are one of the first custom Debian distributions only the Debian junior was before Debian met and my intention is now to find out which projects could be come back to Debian I was very happy with the idea that I was in Oslo there was a scholar linux and Debian edu something different and I had my cdd talk and I was asked why scholar linux doesn't work with Debian edu and he said well Debian edu is dead they do not working and so I told him well take it over it's yours and so we have somebody stepped in and took the right step to make Debian better instead making a separate distribution and so I think this is the main purpose we should only derive from Debian if there is really a reason and if the reason is that Debian is bad this is no reason it would be better to make Debian good for this what I want to do with Debian so it's a special purpose it might be serving teachers or serving even children for Debian junior or Debian made for the medical stuff or whatever we have and so my idea of custom distribution is make Debian better and make it in the same technical fashion as I said I'm a physicist well physicists have two main things in common they are lazy on one hand and they are not really technical skilled as informaticians I can say it I know I can make something working but if a informatician looks at it it looks bad I know that so what I did is I started writing the CDD toolkit and I know I have to make it good enough that people work with it but I have to make it better enough that some informaticians said oh I want to make it better and it worked and people helped me and the stuff became better now and it will even become better because Sergio Talens Oleg is now rewriting it to make it a really good tool to have a common technical base for all custom distribution it is a very important thing to unify on a technical basis because reinventing the wheel is always a bad thing and that's why I hope many people try to get the idea of the custom distribution and use these technical tools to enhance them together because as I said I'm a lazy person I do not want to make to build this custom distribution for my deviant mid stuff I hope other people will do it for me who are more skilled than me I just want to have the workload to those people who can really do it and I want to concentrate on what I can do trust care for the medical applications and once this CDD toolkit is ready you will perhaps not see me on the CDD front anymore but only on the deviant mid stuff and on Saturday is the deviant mid day I want to get this more involved with people who are interested in so thanks for the kind of talk about the deviant med and also about the CDD stuff in the space because they are trying to work fully within the deviant project in a way that not all derivatives can do but that when derivatives can work in that way it certainly seems like the ideal way to do it and kind of unifying around tools is maybe useful not just for providing a common basis in the CDD world but maybe creating tools that derivatives outside of deviant can use as well to kind of help merge their changes back cool alright are there questions about that one no there's pointing but I don't see where it's quite in the middle over there yeah can you raise your hand if you have a question no I think there's just pointing to nowhere okay alright so I'll point to the next speaker Matt Zimmerman from Ubuntu hello hello again I'm Matt Zimmerman and I'm going to talk a little bit about our experience with the Ubuntu distribution building it and working with the community and with Debian I'm sure a lot of you have already heard quite a bit about the project and are quite familiar with it but I'll try to give a brief outline of what we do for both for those of you who are not familiar and maybe to stimulate some discussion around those points we have a distribution based on Debian unstable all of the packages in Debian unstable are also part of Ubuntu however we make independent time based releases based on those packages so every six months there's a new release of Ubuntu and it's supported for 18 months after that we have a lot of visibility within the desktop community because that's where we do some of our work but it's really a general purpose distribution we've received a lot of attention in the community recently because there's been a lot of activity in the user and developer communities around Ubuntu it's something that has caught a lot of people's interest and we're very happy about that but at the same time it's it can be a challenge to manage very fast growth like that especially when you're trying to collaborate with other projects within the open source community some of the things that we do are different to the way that other Debian derivatives work and custom distributions so a few of those things are a bit technical for example we have a complete separate package archive where we keep all of our packages and work with them rather than using the Debian archive and perhaps layering some additional packages on top of that and we have an independent build infrastructure where we build all of our packages and sort of parallel the same infrastructure that Debian uses for their own work so we bring in source code from Debian occasionally it's modified and it's built and provided in a package archive in the same way that Debian does some of the reasons to answer I guess the why not Debian question a big part of that is our release process which I just described it's very important to us to be able to provide a predictable release cycle the community has spoken very strongly on this in the past something that a lot of people are interested in seeing and especially for a distribution based on Debian and it's also important to us to be able to kind of push new features in some sometimes without interfering with the work that Debian is doing so while Debian may be stabilizing for a release we may be in a period of aggressive feature development leading up to a release after Debian in order to do what we do we accept some trade-offs relative to what Debian is doing Debian is obviously very large collection of software very general purpose distribution that a lot of people are able to apply to what they want Ubuntu on the other hand we tend to focus the work that we do on a smaller subset of the package archive so while we provide all the same software that Debian does we do most of the things the work that we do independent of Debian has to do with a relatively small subset of that which is also true for a lot of derived distributions we also support a more limited range of hardware architectures which enables us to be more efficient in some ways and focus on where we think what we think our users want the most we in terms of some of the frustrations I guess that we've experienced obviously the they also kind of fall into the general category of communicating with Debian Debian has shown itself to be while a technically excellent community in a very valuable organization to the open source world very difficult to communicate with Debian is not just not have one mind or one voice they're all independent developers all of us are and there's a lot of opinions about the way that things should work so it's very difficult for a derivative distribution to really approach Debian with an idea unless it's very compartmentalized and it's something that we can talk to a specific person or team about and in terms of getting consensus across an organization about a big idea that can be a very challenging process as anyone who has participated in the Debian development list knows a lot of strong emotions around both technical and social issues it's also been and this is with Debian, I mean these are all Debian people bringing things to in the case of Ubuntu the people that are bringing maybe suggestions or something maybe with Debian people I mean I'm just thinking in terms of distributions that have no people involved as Debian at all the person comes on the mailing list and maybe suggests something well to the controversial that could be even that much more difficult we're in a position where there's quite a bit of overlap between Ubuntu and Debian communities several developers are involved with both projects and so are accustomed to some of the peculiarities that Debian has in this way and even so it's been a great challenge to try to do the right thing by the community and get things happening in the way that we all want lessons learned people have very strong opinions about their desktop artwork but apart from that it's been we've definitely learned that there are a lot of people out there who really who love Debian very much are very passionate about it but they want something that's a little bit different a little bit closer to what they want and I want to re-emphasize what about this idea of an ecosystem of distributions I don't think that derivatives should be seen as a criticism of Debian necessarily they're not bugs it's by creating places like this where more specialized work can happen or where new ideas can be tried out I think we stimulate development a lot and if we say that derivatives shouldn't exist or that we should minimize derivatives I think that stifles development by forcing everything through the same channel so I think by opening things up this way allowing many more things to happen at once we can accelerate the pace of development within Debian much more okay so if there are questions for Matt or for them we can do that a few now and then we can come back a little bit at the end so there are a few so Anand has one yeah there's Anand up in the corner so one of the key phrases you just said we shouldn't view Ubuntu as essentially a bug or he said derivative distributions in general but to me in particular the Ubuntu distribution is different because it seems to view for example the new maintainer process as a bug and it has its own masters of the universe procedure where you can also be a maintainer of a package that's in Debian but you can have a separate maintainer for the same package in the masters of the universe program how do you sort of resolve that if you don't think that's a bug in the new maintainer process obviously the new maintainer process does have some problems but I don't think that necessarily we need to say that because different projects decide to try out different approaches to the idea that it's a reaction to it as a problem in Debian I mean sometimes the best way to see a better way to work is to try it and that's a lot of what we're doing with various social aspects of Ubuntu is to try something different, see if it works we have some freedom to do that being a much younger organization that Debian with less momentum and so we can put an idea out there and just put it directly into practice without disrupting a lot of work that people are already doing and see whether it works out and maybe certainly some things things don't always work better but we have found in some cases that that's a very successful way to discover new processes for open source development and it's an interesting idea that we're talking mostly about code and how we can share things in code but maybe we as Debian can learn things from some of the kind of organizational aspects that are very different derivative distributions kind of explore. In the particular case of the Masters of the Universe team in Ubuntu, they're very interested in collaborating closely with Debian and Debian developers there have been a few mailing discussions about this where there have been specific points of contact on that team for anyone who is interested in that type of collaboration So we have two, three I think I saw Brandon first Yeah, let's go to Brandon first Maybe kind of a strange question but something I'm kind of compelled to ask given many of the conversations I've had over the past few months is from Ubuntu's perspective what does Debian do better than Ubuntu and are any of those things important? Debian does so many different things and has been successful at so many of them for a long time I think Debian is has been the center of so much positive activity in the open source community that is something that Ubuntu as a project is only about a year old at this point and we've done certain interesting things but Debian represents a body of work that goes back many years and it's so many people I think that most of what Debian does I think it does excellent I think it does a great job of it and the areas where we choose to do things differently many of them are experiments or certain specific needs that we want to address that come up in our user community and again I want to emphasize that difference does not imply criticism if a derivative decides that they need to do something differently than Debian that doesn't mean Debian is wrong certainly not as a follow up do you have any ideas along the lines of how we could come up with a kind of actually this is a question for the whole panel it strikes me that what we need is a kind of change advocacy process a derivative distribution that makes a change every particular change is something Debian needs to do for instance many of the localized distributions that were spoken about during Debian Day a couple of days ago I realized not everyone was here but I've actually forgotten who made the presentation there is a mention of a great many distributions that were localized so not every change that is made in a derivative needs to come back to Debian I would like to distinctly recognize those that an organization such as Ubuntu or Progeny or anyone doing embedded Linux work wants to actually try to advocate and really seriously push into Debian as opposed to us just treating all deviations from Debian as being kind of equally either suspect or inherently superior what are your thoughts on that I think oddly enough to a logic study I think that's a technical problem if we can find ways and build tools and things to manage all these changes better it becomes much easier to keep track of them attach better data to them and things like that in Ubuntu we're moving toward using distributed vision control very heavily and we hope to use that as a tool to ease collaboration with Debian in a lot of ways if we can make it very easy for everyone to be looking at the same to be on the same page and see what's there and why it's there and be able to easily start a conversation about it I think we'll go a long way toward getting the changes into Debian which belong there and doing all the things that no need to be done thank you I think we had Martin Crafts oh and then one here too okay I'll try to keep this quick I think Ubuntu is one of the Debian derivatives and it's a special one in that it actually managed to get up to top position in DistroWatch in one year only and it has established from what I can tell a very vivid community one that is similar to Debian in some ways because there are a lot of people that are excited about contributing now actually some of the problems that have arisen have recently affected me because people came up to me and brought to my attention that somebody is trying to package something for Ubuntu that I've already packaged in Debian so I think there is a bit of a lack of communication here but that's really a side issue I actually wanted to get to another point which is is there are there any plans to possibly change the name of Ubuntu such that it isn't Linux for humans but it might be Debian for humans you don't like the name Ubuntu you don't like the name Ubuntu I have no problem with the name Ubuntu I think the problem comes more from the fact that Ubuntu really came in separately people didn't really know that it was Debian and that was some of the cause I think of some of the frictions that caused the Ubuntu people to think they're better than we've seen it all the stuff from the past year I think that the two Debian and Ubuntu together can be a really powerful combination because Debian does the basis for every derived distribution and Ubuntu then actually takes care of the users and with that I also addressed what Andreas said earlier on I don't think that Debian developers should be the missing link between upstream and users I think Debian developers should be the link between upstream and the distribution world and then Ubuntu should be the link between Debian and the users First let me say that well there may be some cases where people aren't aware of the heritage of Ubuntu but I think by and large the community is that's one of the things that people tend to like about Ubuntu they like the fact that it's based on Debian as I was said there's a lot of goodwill in the community toward Debian and there are a lot of people out there who would like to use Debian to strongly agree with its ideals and its processes but don't feel that it exactly fits their needs and I think that's a gap, that's where derivatives a gap that derivatives can fill very well and take all of the good things about Debian and present them to a group of people who might not otherwise have access to them Or to people that just want different things in different uses I think that a lot of people up here may use a derivative and Debian or multiple distributions or something in different situations I would like to add something to Martin because in Germany the Knopix I say Knopix distribution is well known but people just use Knopix and think it is a single distribution it was absolutely not intended by Klaus Knopper he just wanted a live CD and people regarded it as distribution because well it works so Martin is completely right our users, the users of Knopix or whatever do not recognize that are using Debian and think it is something different and I think we could profit if the users would at least a little bit educated about this fact what is behind this scene and this would bring all projects something forward If I can address a little piece of that also there are two sides to the problem of a derived distribution there is the technical side where obviously the bits are different Abun Tu is different from Debian Progeny Debian Componentized Linux is different from Debian and then there is the social aspect the question of community the question of how users relate to each other how they relate to their parent in the case of derived distributions how Abun Tu and Progeny relate to Debian it is I think the social problem may be a little bit more of a difficult thing for derivers to deal with it is a little bit more intractable to the extent that a derivative distribution creates a community of its own it sort of seems like it subtracts from the Debian community and there can be a little bit of attention there the question that I think a lot of people seem to look at is if Abun Tu has got this vibrant awesome cool community that is doing all these great things and has all these experiments that are succeeding so well why do we need a Debian community and from a Debian point of view that is a very threatening thing to think because we think well is Abun Tu taking over Debian is and I am picking on Abun Tu here but this is not specific to Abun Tu it is something that we deal with all the time at Progeny as well to what extent does Progeny take away from Debian when we toot our own horn and talk about all the great stuff we are doing especially since Progeny is also in the business of doing RPM based distributions it kind of can be a threat I think the I don't know that there is a really good answer here except to emphasize again the fact that cross communication is vital to ensuring that the social aspects of deriving a distribution and creating communities around changes and in a sense implicit criticisms of Debian do not turn into a reason to drive wedges between people if we can do that I am not sure that we have all the answers I am not sure Abun Tu does or really anyone else but it is something that should probably be thought about more clearly cool all right well we have a we are running a little short on time and there is a couple people that are going to reiterate a few points if you can make a quick point or question that would be excellent my point is related to what Mandak said about calling it Debian for humans I think there is a problem also in that particular point of view because right now I am receiving mails and box asking me to update my packages in Abun Tu which I don't work for so I would like to ask everybody in Roundtable what can we do to either strengthen the links between derivatives and Debian so that packages from Debian get into those derivatives quickly or what can we do to actually differentiate them so that people know where to address a concern instead of going to the mail that shows up in the package I mean attribution is a tough subject because you have gotten on the one side you want to give everyone credit for the work that they have done but you don't want to imply a relationship that doesn't exist you don't want to give them too much credit and I know that I have seen in a couple of communities I have seen people upset because of both things so getting that middle ground can be a little tough I don't know if someone wants to answer that quickly I would have said a lot of the same things the same issues have been discussed on Debian develop in the past there is a difficult problem if you have a specific suggestion that we can discuss here I would like to talk about that okay so we have really quickly we have a really short comment and then I am going to allow these guys to say a couple of things quickly and then I am going to throw out something in just a minute and we will be done just a quick comment basically we have already heard a few people complaining about their packages being out of sync between Ubuntu and Debian now the funny thing is that looking at my own packages already the way things are repackaged and mostly basically strictly rebuilt wouldn't it be more convenient for everybody if Ubuntu and Debian had a common input care incomingsies and then basically share the exact same packages except in cases where there is customization being done I mean from my perspective as far as I can tell the main difference with let's say the standard GNOME setup we have on Debian and the one on Ubuntu is the human team aside from that okay during warranty things were grossly out of sync but now with Hori we pretty much have the same desktop now Xorg is also entering GCC4 so at this point both distributions are seeing the main difference is the teaming and the fact that Ubuntu focuses on the very smaller pool of packages that they guarantee will go on that CD so my suggestion basically is can we have Ubuntu be that customer front end that ensures that we always get Debian CD1 ready with the packages that are most desirable from the user's point of view not the developers and have Ubuntu market that basically that's if I understand you correctly it's a complex issue do maybe we should have a discussion later about that one because I know that Mako has other things he wants to talk about oh yeah there will be another session about Ubuntu specifically so we don't have to answer all of the Ubuntu questions right now we do have to answer all of the derivative distribution questions now we should focus on the issues that affect all right so I'm going to give two more people maybe if we can briefly reiterate the stuff it's different since we're running a little short on time sorry to cut you off but yeah yeah my name is Roger so I work for someone in Hong Kong which is started in year 2000 2001 and been involved in that since very near the beginning we right now we have a distribution based off Debian and Stable focused on the x86 desktop why do we use Debian it's technically superior I think everybody here agrees so why don't we just use Debian I think can be summed up into one word usability for our users I think it's shared the problems are shared among other distributions as well like Ubuntu and Skolinix usability in terms of the installation in terms of sensible defaults in terms of things like having the right input methods for users and many input methods that are in common with the most popular input methods in use in China are unfortunately patented and most of the really usable and pretty fonts that are used in Chinese fonts are unfortunately non-free and we have to pay licenses to use those and so on and installation we have we're based off a very early snapshot of the new Di we created a GDK front-end for DevCon for it and removed many questions during the installation so now it only asks three questions before it installs sensible defaults little things like the fonts displayed users want fonts from point sizes 12 to 16 to be non-anti-aliased little things like that so customized so that's the only reason we're not using Debian as it is and another thing because we are focused on x86 desktop having 14 CDs for our users is not very impressive for our users well yeah it's impressive we have 14 CDs for only like $200 but yeah lessons learned communication I don't think we have done at someone's we haven't done enough to communicate with the wider Debian community but also the Debian community itself it's I don't know it doesn't seem very receptive from it's not very easy to communicate to Debian I think that's that's about it great okay so I'm going to if I can cut off questions right here we'll just give a little bit of a reiterate the parts that you can speak so most of the things I would have liked to speak about have already been spoken about so I won't repeat them many times we chose to use Debian because we think it's an excellent platform for us to deliver our solutions we're primarily looking at server-based solutions rather than desktop issues such as fonts and usability and input methods which would be relevant because I work in Japan are actually not a problem for us one of the main issues I guess we saw initially was configurability being able to for instance use debcon universally across all packages which is just not possible right now for instance partly through our development cycle we the NTP package had had debcon stripped out of it because it was not working on the other hand things like the Debian installer and being able to precede it that's excellent for us one of the reasons we decided to derive was was touched on by Roger is to basically have less questions as people install also to have it default into the Japanese language at the install to basically to make that experience much less painful for the user and we've been pretty successful in doing that with very few modifications to the packages themselves things like pre-seed allows to do that without having to in a very uninvasive manner moving forward to where we are today I guess the two major issues that we have is firstly the release cycle about the beginning of this year it became apparent that we weren't going to be able to get very many customers excited about using a woody base distribution because it's too old because of that we've basically been shipping SAJ or SAJ pre-releases since the beginning of the year SAJ has come out now and we're very happy about that but the cycle is just a bit too long and also far too unpredictable I mean at the time I started working on this was about the time that we thought SAJ was about to come out I think it was nine months later when it actually came out and the last thing which is a bit of a hot topic but clearly an issue for us and probably all derives as security updates so being able to do that on a more timely basis we have taken a fairly extreme approach towards only supporting a very small number of packages so security issues are less frequent for us but it's still very important for us that's all I really wanted to speak about thank you so before I turn the server I mean I think this has been a really good conversation we are getting close to being out of time and I got my red sign Q the sign so this is a conversation that I'd like to continue both among these people and among people who couldn't be here I'd like to bring in some other people and in the Debian community I think that the place to have this conversation is in the Debian project I think that because Debian occupies a unique space in this distribution even Ubuntu which is probably the most I don't know the most diverged derivation up here the amount of work that's being done by the amount of stuff that's going on in Debian and I think that we all have a lot to gain from working together and from continuing to bring these up these issues there were a lot of people mentioned communication problems that it was difficult to bring a problem to Debian even if you're involved it's often difficult to bring a major issue to the project and I've got an idea of maybe continuing this conversation in creating a space in the project maybe a I don't know a list or something a space for I've tentatively called it the Debian Derivers Council but the idea is that maybe creating a space in the project for the people up here for derivers that are working inside the project for derivers that are working outside the project to kind of create best practices amongst themselves to document the process for other people who are maybe less involved in Debian so far and to kind of communicate as a group to the project because I think that working together we can kind of make our demands demands known or at least our common problems known to the project you will do this or else right so we're all going to get together and we're going to maw and we can beat up on the rest of you together so I have a kind of proposal for I don't know a more formal space in the Debian project to continue this conversation and I'll send that to I guess Debian project in the next week or so and then hopefully we can maybe continue some of this conversation about how that should or should not work in the near future so there were a few questions that people have been kind of itching to do we'll do that quickly and then call it a day so maybe we don't have time to take new questions but there will certainly be spaces within the rest of this within the rest of the conference to talk about it we won't call it a day we'll call it lunch we'll call it lunch so Enrico I think was first on the stack which is rather like an issue I want to bring up many of the questions that have been asked to CDD is like how the CDD wants to contribute back and then people fearing that they do something better and they would like hide Debian in the dark and stuff like that I was asking myself I mean I was realizing kind of that that we start having an attitude in Debian which is like expecting other people to do things like people posting and it's like hey this should be solved this should be done like that but actually there's like as much smaller percentage of people who's actually trying to fix stuff I see it with DebtEx like I was like I can't find packages so let's try to find a solution and two years later well something starts showing and there's so many people like telling me oh I would really like to see that in DebtEx and I'm like do it that that's I mean I'm just trying to get it together right and and this do it is kind of missing and so what I'd like to see more is like if a CDD does something right well let's pick it up and do it ourselves without like hoping like hey you made a patch could you like upload it in Debian as well or something well no I mean you made a patch I pick it up and I put it in my package and my package is better and I'm happy because I didn't have to figure out the patch myself so rather than asking what the CDD can do for Debian like ask what Debian can do for itself I mean and use that I mean we could suck it proactively what they are doing I mean they are doing stuff let's pick it up like steal it and we should be aware that there is at least four different points of view from the Debian derivatives that I've observed at least we have the Debian is upstream we don't talk to them we just take the packages and keep quiet we're doing whatever they are doing I think that's the Knopix and Linspire kind of way of behavior then you have the we are Debian derivatives where Debian med for example is a good example they don't want to derive or they want to they don't want to walk too far away from Debian they want to have everything in Debian to work within the Debian community to improve the packages Debian and Edu want to be there but they are not at the moment then you have the Debian is upstream let's talk to them and communicate and try to get our changes back that's like the progeny and Debian Edu approach and then you have Debian is a friend which I get an impression from if we can't cooperate that's good if you don't have time to work with me we'll do whatever we want to do if we want to share if you can share information and knowledge let's do that if you don't have time to look at it my stuff we'll just do it anyway and these are different approaches to the derivative process and we should be aware of the differences another thing I wanted to say is that a lot of problems in Debian have been exposed by the recent derivative from Ubuntu I think that's not a bad thing as such because the problem was in Debian already we already had bottlenecks we had too much dependency on individual developers who was too overworked and too overloaded and had different priorities and we needed to solve those issues sooner or later and we are hopefully in a position where we can try to solve them now because they are very visible and we have done quite a lot the last year to fix a lot of these issues but there are still some left and we shouldn't complain that Ubuntu is bad because they exposed these problems these problems were there already another thing Matt mentioned all the noise on the mailing list I've experienced from the school in UxEfort that the people writing a lot on the mailing list do not do much work in the project and there is a saying in Norway about this empty barrels make the most sound and I think this is true in most projects so even if there is a lot of strong opinions in the mailing list that doesn't really mean the active participants in the projects share these opinions or I think they are really that important so keep that in mind and yeah Jeff quickly I wanted to bring up in contrast to Enrico's point I wanted to bring up the flip side of it how we in sometimes have a problem and in doing this I want to sort of highlight something Matt Taggart sent to me an email some of you know I am working on the LSB work and I had made a proposal about something regarding that and Matt basically posted back and said you know what I really don't like this attitude because you know you are the guy working on the LSB stuff and you are telling that you are going to present this for approval and who is going to approve it you know why do you feel like you have to be separate from us and do this all separately and differently just because you are a progeny I think you had a good point a lot of us in the derivative world sometimes feel a little bit separate you know we can debate whose fault that is or if it is anyone's fault but again this sort of highlights the important point that we do need to deemphasize the fact that we are all derivatives which means we are us and you are you and never the need and emphasize more the point that we are really collaborating and working together on things if we can do that I think that would be a good improvement we are like over already so okay quickly this is one point I want to add to what Enrico said because I didn't know that the packages of mine in Ubuntu well I should have but I got a report for one of my package that was saying yeah it's fixed in CIT already but not in Ubuntu I just could reply well thanks for telling me that I'm doing a good job but the thing I want to address is what Enrico said we often don't know that the custom that the distributions are using our packages there's a lack of communication but not only in that way but I think there's often not really a communication with our own upstreams so it's not only lack of the derivative distributions but also of ourselves to our upstream maintainers right this is a very good point we never told the maintainers that we use their packages so that's finding out how to do that is maybe something we can talk about later so but Enrico and others were absolutely correct part of my goal here is to complicate the idea of responsibility and shifting this responsibility of derivation is something that we all have to a strong ecosystem where people give back to Debian and where people give back to Debian and Debian can take from them is something that benefits all of us we all can benefit from all of these users and people and developers who are using derivative distributions we just need to figure out how so there was one can I take your one word you don't want to do your one word then the last one from Jesus hi again it's working? well I would also like to say that I'm representing in a way the Nokia people that came here today we're trying to build the Debian based tablet for internet browsing and we have also derivative thing we should have been on the table but I don't want to be there on time and I just want to stress that one of the things that makes the Debian so strong that it's like the diversity of people that are collaborating in it it's also the thing that sometimes makes it really difficult we're not a company so we're not a single point of failure or success so every one of us has its own opinions, its own ideas on how to create a package how to upload the package and how to convince other people to do the things they wanted the things to be done and that's the thing that we have to stress for my point of view is one of the things that makes this project so amazing and so powerful but at the same time so worrisome that when you want to get into that project you're going to have to face lots of problems, lots of different opinions and lots of different variety of packages that you have to then tweak and go and modify because there is no common thing to work with and that's one of the things that we actually found in the process of creating this product in Nokia and that's well thank you everybody for showing up and thank you to the panel for sharing your experience give everyone a round of applause let's continue this conversation on project and over lunch