 So I guess I'll just start. Yeah, my name is Keith Curtis. I titled this talk to Ubuntu. It seems like anytime anybody does anything with Ubuntu, you come up with your own acronym. So that was mine. That's titled An Outsider's Perspective on Ubuntu and Debian. And it's mostly based on the talk I posted on my website. I worked at Microsoft for 11 years as a programmer. I worked on Windows, Office, MSN, Fox, Chrome, and Mobility. I think Free Software case S. I worked on Text Engine for Rob. And this is the musings of someone who's been tracked in the dark sea at home, so we've been tracking them here. I went to Microsoft because I wanted to learn the craft of programming. I knew you can read a book about how to do programming, but that's not enough really. I felt and I believed that you need to work with people, see code, and yeah, I think it's a craft. I realized the issue of Ubuntu and Debian are both emotional and old issues to many of you. And I appreciate your patience and both accounts. I have no agenda. I didn't know what Ubuntu and Debian were three years ago. I'm already in the book, and this is on the pages of my books. So the question is, can Ubuntu and Debian work better together? I think the answer is yes. But of course, why and how? I think, I personally think Ubuntu threatens Debian, and there are many examples of facts that he could use. One is, for example, there are a few news articles about Etch's release. And another is that I think somebody asked Eric Raymond what he thought about Etch and said he didn't care. So I think Ubuntu needs Debian's help. I think it's buggy. I want to talk more about that in a minute. And I believe that the creation of Ubuntu was not meant to hurt Debian. But I do believe in the law of unintended consequences. And I think now that Ubuntu has been out for several years, there is data available. So there's the theory, and then there's data once something exists. So I'd like to talk about two issues. The first one is efficiency, and the second one is can you build the universal OS? One of the things that surprised me when I went to work at Microsoft was that I was a 21-year-old guy working in FoxPro that was my first group. And I was junior, and my boss actually was genius. And he had written huge parts of the product. And I mean, basically, there are two or three people. I don't know if you guys have heard of FoxPro. But for one point in time, it was like the fastest PC database that was faster than the last server shopper. And my boss actually was one of the two people responsible for doing that. And he had just done huge parts of the code base. And I was this new guy. But sometime during the bug fixing phase, he would kind of jump into my code to help me make bug fixes. And one of the things I found was that he actually did make the right bug fixes. Because I had built these subsystems, and I was the only person who really understood them. So even though this guy was much more senior than me, he couldn't make the right fixes. Another interesting thing that happens at Microsoft is that when somebody's given a feature, they're given full responsibility for a feature. So for example, if you were to work on Word and your responsibility for the footnotes, you'd be responsible for the file format code, the UI code, and then the engine layout code. And they did this basically for two reasons. One is it gave that person the holistic perspective on the code. And of course, also it made it very efficient for bugs. If any bug in the footnote code came in, then you knew exactly who to hand the bug off to. So and one of the things I think that I see in the Ludger Devin community is basically that you've got, because you've got these separate teams, you have basically split up the division of labor. And so one of the things that you see happen right now is that I think one example you can use is the X or the modular X changes. And basically the work was done in Ubuntu and then thrown over the wall to a person who basically doesn't really know anything about what the changes were. So this person has to get up to speed on all this code. And it's this, and so you find in, for example, that you have multiple, in separate teams, you've got multiple people working on X, on the kernel, on OpenOffice, on Mozilla, and on KDE, and so forth. And you find lots of duplicate work and duplicate expertise being built up because the division of labor has been separated because the teams have been separated. So and in fact, I talked to the Devin modular X maintainer, he told me that the patches were just a starting point for him. Even though, of course, the person who did these patches was both an X expert and a Devin, a former Devin developer, because he had to get up to speed, pretty much had to start over. So, and I believe this is the biggest reason for the efficiency between Ubuntu and Devin. So today, Ubuntu does a feature, throws it over the wall to Devin where it gets re-understood and likely improved. And now you have two people that bother to learn the exact same thing. And oftentimes what you'll find is that Ubuntu will take their patch and throw it away and then accept the Devin patch. So, and then of course, even worse is when Ubuntu does a feature, this is expertise that Devin is not necessarily getting. And so that you find that over time, the center of gravity is basically shaking away from Devin. And then Ubuntu's current list of features means that they're not waiting for any features from Devin. And it did a bunch of come to this conference with any list of work items for Devin. And I believe Ubuntu is on course to completely grab the center of gravity of the community. And I say that by looking at the set of, the set of specs and work items that are posted on the launchpad. So, another example is the bug process. According, this is the bug process according to DCT. Ubuntu will find a bug, maybe file a bug in the Devin database, maybe Devin reduces the bug and now who's responsible for it? And will patches work unchanged between the two code bases? So, and then there's some other impacts. Like Devin is often playing catch up and not seeing Ubuntu's changes. The departure of Ubuntu developers robs them of Devin's expertise, which I believe is one of the reasons why Ubuntu is buggy. I've heard and I've talked to various people and they tell me that Ubuntu will make a hack fix. And then they'll basically wait for Devin to do the job. And I think if there was one community that wouldn't have happened. And then the other thing is that I think many choices are arbitrary and eventually that will lead to divergence over time. If it's supposed to Devin work, for example, not to adopt off-start. You can look at standards like HTML and the HTML stocks, but why it's good is the fact that basically every computer on the planet can display it. And so really what's not so important is how good the standard is, although it obviously doesn't matter. What's more important is that that people have the same standard and that whatever we decide HTML is that we all use the same one. So next I'm talking about bugs, efficiency related to bugs. So my personal opinion, the only thing that's holding up world domination of Linux is bugs. I don't think it needs any bolt of lightning features. Donald Rumsfeld says, uses the phrase a long hard slog talking about the war on terror. And I personally think that's what, for Linux to have world domination basically, that's what I think needs to have happen. Just keep working away on the bugs and fixing bugs faster is only going to get there faster. So, and Ubuntu is swamped in bugs. In May 2006, they had 10,000 active bugs. In May 2007, they had 30,000 active bugs. And I think if Ubuntu had 1,000 contributors, where could they get 1,000 contributors? They could make progress on that a lot faster. I think the first distro with 10,000 contributors will win. So, and one other point is, I think the current situation has challenges in this, to the extent that the Ubuntu LTS snapshots Debian unstable. So I, it's kind of an interesting question. What does it mean if you're gonna make the long term release based on code that Debian doesn't think is stable. So either it's stable or it's not stable. And then of course you have the other issue, which is that many of the bugs I believe, that Ubuntu is finding existent Debian. But they're not in a Debian database and nobody knows about that. So I kind of questions what's the point of shipping at zero bugs. If there are a bunch of bugs that exist in Debian, it just happened to be another bug database and nobody's tracking them. And then of course, efficiency relates to brand. I saw the talk, I mean many of us saw the talk yesterday about HP support of Debian. And then you have to ask yourself, oh, was HP gonna support Ubuntu? And, you know, if they were to support Ubuntu, they could say could do that. They have to ask themselves, okay, well, what are the financial agreements? What's the SLAs escalation protocols? What releases they're gonna support? And basically if HP were to support Ubuntu, it would be a bunch more work. And it's basically, it's increased, it's attached to that. Now given, of course given the fact that the code is 99.9% the same, you wouldn't necessarily think you would be a big deal for HP to just support Ubuntu as well, but obviously there are many other little details that we had tonight. And then another table is do Dev files work across one OS to the next. There was some time a year ago where Zimbra made this announcement that they were going to support a, they're gonna build some Devs for their collaboration suite. Now of course, do those Devs work on Ubuntu? Now maybe they do, but anyway, it's an increased tax. Now we can argue about how big the tax is, but it is, it does decrease efficiency. And then there's of course a bunch of other infrastructure, there's bug tracking systems, security bug fixers, people are, I don't know, I guess monitoring in the system, 25 hours of data, push out bug fixes. And then there's source control systems, forums, build servers, et cetera. And that is again just additional taxes. And then one other thing that I wanted to make is that you don't really need to build new infrastructure to add a feature. One of the things I've heard about for why Launchpad was created was because they wanted the ability to work basically with upstreams or to basically link bugs between bug tracking systems. Now I don't know if Mozilla supports that, but if it doesn't, then that feature could be added. You don't necessarily need to build something from scratch to add particular features that would kind of be like creating a new Linux kernel if it doesn't support your particular network. And then one other thing about efficiency has to do with the community. I think Ubuntu is very exciting and I think this brings in more people and positive people to work harder. And I think to the extent that Ubuntu is kind of sapping the excitement from the Debian community, it decreases the efficiency of Debian. And if Debian's perceived as a relevant and existing Debian developers will eventually over time quit working early. So that my next, I'm almost done. My next little issue has to do with can you build Universal OS? So Mark Shudderworth has a line which is it's hard to know what Debian's goals are. And I think that's a very good question to ask because goals create a vision and bring people on board. Mark said that Ubuntu is a few specific use cases. So Debian's motto I think, which is a good way to figure out what Debian's goals are is build Universal OS. I think that's a very good goal, supporting 15 platforms and 18,000 software packages is an incredible achievement. And I love my computer because I can just so much stuff as one bit away, built to work together. Now I'm sure he has to use a code of polish but I think ultimately that will happen when Linux gets going in the desktop. So, and of course in terms of whether or not it's possible to build Universal OS, one could look at Wikipedia and Linux kernel as a couple of other case studies. Now there are a number of Debian's derivatives. In fact, the creation of Ubuntu has precedent because there are 100 other Debian derivatives. But most of these are region specific and don't really disturb the center of gravity. And one of the little points is Ubuntu's motto obviates Debian's motto. If you're creating a Linux for human beings, it really doesn't need much left over for Debian and guess that would be Linux for robots. So, and another point is that software is infinitely malleable. So, basically anytime you wanna make a change to a code base, you can generally do it and you don't need to go up and create a different code base to make that happen. So, another way to attack this question is to ask yourself what feature other than orange has Ubuntu added that Debian doesn't want? If you look at the various investments that Ubuntu's made around ease of use in the 3D desktop, everyone has its kernel faster startup. Those are all, in my mind, examples of things that Debian wants. I think if there were things that Ubuntu's doing that Debian didn't want, that would be an interesting point. So, and then another issue that you have is that I think one of the things Ubuntu's added is better power management. And I think nowadays, anybody who's using a laptop wants good power management and wasn't Debian users, probably now using Ubuntu and the interest really in adding good power management to Debian has dropped off because anybody in the last two years who wants good power management is just using Ubuntu. So, and one of the things I find is the power management for laptop support and Debian is several releases behind Ubuntu. So, one thing that I talked with Sam about yesterday was he mentioned that there are certain things that Ubuntu wants that Ubuntu doesn't want that Debian is doing. And the example he brought up was support for multiple platforms. So, and, but one of the things I find is that the kernel really hides 99% of that work. So, the amount of arm-specific code you find in a random package is actually very small. And second of all, if you support one 64-bit platform that really gets you 99% of the way to supporting other 64-bit platforms. I mean, basically I did the port for my code base, one of my code bases at Microsoft in 1999, support itanium, and pretty much all you had to do was make it so that your pointers were, you didn't use integers when you meant to use pointers. And as long as you do that, then your code pretty much is compatible across all 64-bit platforms. Thirdly, actually it's the upstream responsibility to maintain, to make this code. So, the idea that Ubuntu isn't adding a feature because it's too much work is kind of in my mind wrong because ultimately it's upstream responsibility to build clean 32-bit code that works on 32-bit and 64-bit. And then of course, furthermore, you have platform maintainers. So, inside Debian there are various people whose job it is to make sure that the code runs on a daily basis for AMD64 and so forth. So, in other words, if you basically can just have a couple people inside your team making your system work on AMD64, then you, Ubuntu basically can get that for free because you just need a couple people. And there are some about there already. So, in other words, I think the cost of supporting multiple platforms has not been quantified as I think overstated. But I don't know if there might be some others. Might have some other features that Ubuntu doesn't want from Debian. And I'd be interested to hear what those are. So, I believe that Ubuntu is exploiting a loophole in the GPL. I think the Ubuntu, we can argue whether or not it's a fork or a spoon or whatever, a branch. But I believe it's a fork. We can talk about that if anybody wants to. But anyway, I believe it goes against the spirit of GPL and cooperation. I wanna talk about that. Okay, so actually what I was hoping we could do is let me just finish my slides and then we can open it up. So, generally speaking I think that changes that when you make a change you should put that change back upstream and take ownership so that somebody else doesn't have to learn that code. You know, again as an example, nobody hands a bunch of code to Linus and says, hey, if you've got any problems with it, well, here's the code, look at it, you can fix it yourself. And so yeah, there are obviously many ways to work better together. And this is where you guys can come in. I propose a couple of solutions. But one of the things I think is interesting is Debian could consider switching to time-based releases. I don't know if anybody read Martin Michel Mayer's thesis. But I took a quick scan at it and it's kind of an interesting paper. Okay, I've got a couple of miscellaneous points I thought I would just cover. So yeah, so I got a little bit of advice. I think one, it's really important to focus on the out-of-box experience. Oftentimes I meet Debian people and they believe that they don't care about Ubuntu, Debian is for smart people and Ubuntu is for, you know, news. And I think that's the wrong attitude. I look at Appget and I look at Debian installer and I think they're both powerful and easy to use. I think it's possible to do both, but I agree it's hard. I think Debian should keep doubling the number of Debian developers. I think one of the primary responsibilities of the DPL is to increase the size of the team and make everybody happy and productive. Wikipedia has a motto of, don't scare the newcomers. I think that's a good motto. One other thing to keep in mind is the competition, Microsoft has 5,000 full-time programmers. So it's, you know, it's gonna take focus and it's gonna take hard work. Also, spend your two hours or eight hours per week productively. You know, whatever time you're volunteering to this community, make sure you're spending more time coding than sending emails. And then also, I have new software that's better than old software. I think, I'm not sure how confident Linus Torvald would feel that his 2.6 kernel is good if Debian isn't using it. So Debian benefits from the changes of the new kernel and the new kernel benefits from Debian using it. So yes, I have a couple list of challenges. A few questions for you guys to think about. One is, are Debian developers still passionate? What does the dev mean in a managed world? So if you've got a system where basically it's all written, suppose you had Debian and it was all written in Perl, PHP or Java, then, you know, those systems each have their own sets of repositories. And so, what does a dev mean? What does a dev repository mean in such a world? So if you could imagine that all that code was written in those languages. Is it possible to install Firefox off the web? Do I have to upgrade my kernel when I install a new hardware? And is it possible to build a system where I can never have to upgrade my OS? Okay, yeah, I've got a state of a bunch in one slide and I call it buggy. My computer resumes nine out of 10 times. I have ATI drivers, but I can't enable copies or barrel. Sometimes my 2D graphics per person is slow. It took me an hour to enable playing DVDs and caffeine basically doesn't really work. Wine did not enable clicking on Xs. I was able to install I6 but it does not run. I can't double click on a dev which has uninstalled dependencies. And few apps are as polished or as reliable as Firefox. All right, so that's it. My, just want to say, man, there are many ways to work better together. I think the goals should be one tree, one bug database, one conference schedule and one FAP, happy community. And I think when it's connected to your world domination, faster if we want. Thank you for your time. So that was all I had to say. I don't really know if anybody wants to comment or... Just be something, where do you work about? You used to be at Microsoft? Actually, I am just writing basically. And you didn't develop it? No. Yeah, I hadn't used any Debian or I hadn't used any pre-software so I left Microsoft. Basically, I quit. I was like looking for something new to do when I stuck in a red hat CD and I was like, wow, this thing stuck, it's pretty cool. Microsoft were pretty much discouraged from using pre-software. So, because of the viral nature, because it was communist. So, you know, obviously that's the opinion. I have a different opinion now. So, yeah. Did they use that word, communist? Well, Steve Ballmer has used that word. I'm not sure where, if I heard it inside the company or not. Okay. I have a lot of points. Okay. So, please feel free, anyone, to interrupt me if you want to talk as well. But you covered a lot of ground in that and made a lot of criticisms of Ubuntu in particular that I'd like to talk with you about. Very early on, you sort of gave Ubuntu credit for error-brainment not being a bad patch, which I think, well, prior to becoming a public supporter of Ubuntu, which was relatively recent, I heard that Ubuntu was the supporter of Fedora. There's never historically been someone who was a great supporter of Debbie in the middle of coming to that. I don't think that Ubuntu can take the blame for a particular high-profile person in the open source community not supporting Debbie. Okay. If, I don't know, the event that is, as you mentioned that the context of Debbie are getting a large amount of press for... Yeah, I don't, yeah. I guess that's one way of working at it as to how it goes, though I think it's, I think it's always been the case that Debbie has received a lot of positive coverage within a relatively narrow segment of the press that's focused on technology in a very technical audience. And it's not perceived as much of mainstream press coverage. I think there are many reasons why that's the comfort of Ubuntu. There's a lot of sort of community activity and corporate activity around communicating with the press that I think Debbie doesn't get to. Though there are teams established for that and it will be great for Debbie to see that more of that type of communication. But I don't think that the fact that Ubuntu, it receives a lot of publicity, detracts from the value of Debbie in fact, a very, very high proportion of the press coverage that Ubuntu receives, credits Debbie as its base. Yeah, as a footnote though, you'd say, wouldn't you? Sure, and a hyper only. Okay. Yeah. So... 20% to put it that way. And in fact, it's often highlighted as one of the things which people like about Ubuntu. People who usually appreciate that it's based on Debbie and they often have moved to it because they appreciate many things about the Debbie system. They realize, you know, come from the Debbie system, but I had some value for them, I don't know about that. And so... I mean, the larger question though is, is Ubuntu taking away, in essence, some of the excitement from Debbie in basically, that's whether or not Eric Rayman is kind of, that was just an anecdote. That's a difficult question to answer. And if Debbie were doing all of the same things that the two were doing, would people be as excited about Debbie? Or another question, if Ubuntu were closer to the Debbie community, would... Would more of that excitement... Yeah. ...to go over into Debbie? Yeah. That's a question. I think that's what you said. I think a great deal of the excitement that Ubuntu gets is you're finding the user community as opposed to the developer community. And I think that's an area where Debbie is very strong. Debbie has a lot of new developments in Ubuntu. She has a lot of new appeal in that community, I think. And so I think there are two different sorts of tension around the world. But you guys are growing your Debbie developer community. I mean, you'd like to have a thousand developers, and you're moving to the internet right now. Developers are great, yeah. I mean, basically, developers are what make the system. And we'd like Debbie to have 10,000 developers. In our case, it's Debbie developers who make most of the system. Yeah, right. And that's why I had a strong reaction when people painted Ubuntu as a threat to Debbie. Because Ubuntu could not access to the web. But if Ubuntu were to damage Debbie to the point where it couldn't function, then Ubuntu itself would die. I don't think that some of it could be an unintentional consequence of the work that you're doing. Your goal isn't to hurt Debbie, but it could happen. And indeed, if it did happen, that would be something that we would see as a problem in response to. And how would you know when it's going to happen? Well, I mean, we do pay attention. But what measures are you looking at? In pre-software community, and spending some time in it, this is an observation over the years, we run the risk of being our own worst enemy. In that, we very easily slip into creating conflict where there doesn't have to be conflict. And those tensions can very easily escalate because people select a set of words which highlights what they are afraid to see in somebody else. And then put that out there to prove that that person is what they're afraid that they are. And I see this all the time. I see it happen between other communities. We're seeing it right now, for example, in the Linux community around GPLv3, where someone will say something in a long paragraph and a small portion gets pulled out and turned into a headline. And the guys on the other side respond to the headline, not to the paragraph. So I think it's very important within the pre-software community that we recognize that differences are normal, that those differences shouldn't prevent us from collaborating, shouldn't prevent us from seeking opportunities to make things better. So in that spirit, I mean, I think this is a very informative perspective. Thank you. And I find it difficult to agree with everything you said because I've seen quite a lot of the water under the bridge from different sides. And I feel obliged to make it absolutely clear that there is absolutely no desire on the part of any Ubuntu developer that I know of to undermine data. In fact, most see their contributions to Ubuntu as carrying the dead-end system forward and realizing many of its benefits in new areas. A good concrete example of the thing is that what you see because it spans many packages is the fact that there are a few people within Ubuntu who make a major project of adding desktop files to all the packets where it's appropriate. And many of those patches have been submitted absolutely through DevOps and applied by the delivery maintainer. It's carrying that data as carrying that data between the dead-end and Ubuntu or something like that. Doesn't make any sense. And that does feel just as well, in many cases. So unfortunately, I started making notes quite late during the talks. I can't respond to everything to which I had a sort of thought of time. And it's a little inconsistent to suggest that everything that Ubuntu does, which therefore sort of represents the things that are important to Ubuntu and to the Ubuntu community, right? Which really manifests itself in changes to packages, right? Every single one of those changes is published. We try to do this in, and we've evolved the system effectively, but we've tried to do it in all the ways we can think to make it as likely as possible that that delta is as meaningful as possible to other people in the ecosystem. To Fedora, to upstream, but particularly to dead-end. To the extent where, I think I'm right in saying that every single change made to every single Ubuntu package is emailed at the time the change is made to the dead-end package practices. Wait, hold on. Now, it's easy to criticize the, you know, to say, well, that patch wasn't done right. Or to say that I didn't get a detailed explanation of why that patch was done. But the important thing is that if every change that Ubuntu made was relevant to dead-end, then you would expect that every change would be accepted by the dead-end. Well, but the point I was making that was several slides is the idea that it's important to take ownership. Nobody hands code to Linus and says, here you go, if you got any questions, well, the code's on there. Actually, that's exactly how it happens. People in the kernel community focus on things that are important to them, right? And they publish those changes, and there are sort of places where those changes they publish, and then they get aggregated and fed up through the system of maintenance and ultimately hopefully make it into Linus. But if there's a problem with those changes, then the person who made the change originally is responsible for fixing it. No. The kernel community isn't, I mean, there are a lot of people in this room who can maybe be able to comment on this, but I know it happens even that developers in the kernel can really encourage, for example, hardware developers, to submit their code to the kernel, get it in a unit that's not perfect, because the kernel community will support them and they will take ownership of that code. Okay, well, yeah. There's, what you're getting at drives, there are I think two fundamental concepts, and we could nitpick around the edges all day, but I think there are two fundamental concepts. One is relates to your concept of ownership and responsibility, right? And I think the important thing to realize is that, first, people do the work that they're passionate about. And second, that any kind of collaboration requires interaction and two-way communication. I would be very surprised, for example, if a patch was generated in the Ubuntu system sent to a devian developer, and a devian developer then responded and said, what you're doing is interesting, but if you do it slightly differently, then we would include it. I would be very surprised if that response didn't then generate a conversation with a relevant person who was doing that work. But I think this is the case. I think it's fallacious to think that that any party in this collaborating ecosystem can sit back and say, well, I expect everybody else to do the work to the point where I am happy. Collaboration is an engagement. Well, okay, but what we're talking about though is do you do the work in the, I mean, basically you've got two code bases and they're 99.9% the same. And so you can say, well, I'll do it in this code base and here you can take it. If you've got any problems, you can just do it on your own. I mean, are you saying that people in Ubuntu aren't passionate about getting a code into devian as well as that one? Quite the reverse, devian, I mean, sorry, Ubuntu developers generally care quite a lot about getting stuff into devian. And it hurts them quite deeply when stuff comes back, saying we're just not interested in stop sending us this, which is the sort of comment that you might well get back. So I think there won't be good results if any one group thinks that it's okay to sit back and demand that everybody else do things to their satisfaction. I could make a very long list of things that make Ubuntu's life more difficult, but it's extremely difficult to, the reaction here would be unpleasant if I was just sort of standing up at that list. I chuckled when you said, did you come here with a list of workhouses for devian? And I can tell you that it doesn't work that way, right? You don't show up at DevConf and tell people what they need to do in their volunteer time. You don't. Well, you say, these are the things we are passionate about. These are the things we care a lot about. These are the things we're talking about. Well, okay, but basically, if devian didn't, I mean, your kind of assumption is, I believe that if devian didn't provide another patch, then you guys have no problem with that. You guys would just move forward and improve Ubuntu in any way that you feel like it needs to. Which is not really any collaboration about, okay, let's take this problem more than this. The process that you described, which does happen sometimes, where Ubuntu will have a patch on something, and then the devian folks will take a different approach on that, and then we will review those and sometimes drop the Ubuntu patch in favor of the devian patch. What you should read into that is that the Ubuntu developers actually take time and put in effort to merge, right? It's hard work. It takes a lot of time, particularly if you think of the balance of probabilities. You've got a couple of 100 Ubuntu developers and 1,200 devian developers. They actually shoulder a much greater burden per developer to conduct that merge process. But it is so important that we actually, we do every six months, we set aside time to do that process, and it's painful, but we do. If we didn't, then increasingly, it would get harder and harder to do and the risks of the definitions would get ever greater. And that's what happens with most devian developers, as you mentioned, there aren't many, many of them out there. Yes. The usual pattern for them is that they are branched off from the peculiarities of devian, and they really, really, really go from, again, as if we do put a lot of them in. Well, we put a lot of effort into taking away its changes, but you don't put the effort into putting this back. I think if you want to talk about the fork versus branch, I think you can look at kind of Andrew Warren's tree as a canonical example, and he's got his own, you wouldn't call it really a fork, I think you'd call it a branch because periodically, he pushes his changes back. And so, and that... I see Linus pulls from him. Okay, well, okay, but the point is that the changes, I'm not sure where the question is. But it's extraordinarily important, because Linus cares enough to pull from Andrew, and has to do a certain amount of work in thinking through, when there's conflict with Linus's branch, whether he's going to drop them, right? Or, and hope that, you know, his changes make a back jet to Andrew, so that Andrew picks up the work of merging them, or whether he's going to do the work to merge them himself. It's extraordinarily important that the difference in those... Okay, well, that was different. It's not purely that way either. You know, there's both sides negotiating which patches are going to go as well. Of course. Part of the important reason why that relationship works is that Linus trusts Andrew and ultimately will pull things without having to do a substantial amount of review. And I think that we don't have that trust between the Debian and Ubuntu communities. Well, well, I think that, well, Ubuntu does trust Debian to that extent. We've pulled a huge amount of code from Debian completely blind and just fixed whatever it brings. But we don't have that trust in any other direction. And that brings me to the point I wanted to touch on, where you made some remarks about the perceived quality of Ubuntu, which, firstly, you disclaim Tiles being, you know, information that you would earn through other sources. But that is, I do hear that kind of assessment coming from the periphery of the Debian community. And personally, given that I've got a great deal of that effort into making Ubuntu a quality product, I can accept that this is a personal person that is using the way that the community works. I think that's really toxic to paint that picture and to create that perception and promote it because it makes Debian developers not care about when do not want to look at it to want to just discard it and not to collaborate to see it as something which is not what they want but does not value it. Well, yeah, okay. I meant that point. I mean, a couple of different context. One is I just heard it yesterday. So, and second of all, it's because I think when you split the teams up, then you split up the expertise. So there's Ubuntu guys just doing his work and he doesn't have the benefit of the expertise of the much larger team. And so invariably, you're just gonna find that he's not gonna be able to make the changes as well as he would make it if he had the benefit of the other 1,000 people. So. We're only 4,000 people work on the same. Yeah, okay. Well, benefit, okay. But benefit of the particular soft set of 1,000 people who could provide feedback. Sometimes, yeah. But in Debian, I don't know the source in general. I think a great majority of the work that's done is done at an individual level. That the great power of Debian is that it's able to aggregate all those conferences together. Yeah, sometimes you have technical discussions where you can exchange ideas. Yeah, that's right. It's a solution, but generally, it's one person who has... Well, there's no question one person has to do the work, but it's also true that you send email to various people. They're thinking about doing this and you send it to an email LAS and you get five responses from different people from both those 1,000. Saying, yeah, we'll go, forget this, don't forget this, don't forget this. And when you split up the email LASes and split up the teams and split up the... Yeah. And you've been collaborating across, there will always be different places where work has happened. Upstream Debian service. And it's a very hard problem to reach the right set of people who talk about a particular problem, right? There are people who have posted to Debian online lists saying, I'm working on this feature in Ubuntu and I want to talk about it, who are flamed to a crisp and discouraged from communicating at all. And it's the way that the open-source community has these bubbles where they were working within a particular area and those are the people that you're discussing with. And it's very hard, we find, to bridge across those, even between Debian and its upstreams. If you want to talk about a lot of feature that you have in the box, it's not entirely upstream feature, not entirely Debian feature with Man, and it has to go to. And that determines whether you succeed at that. And so I think it's much more complex than just saying that Debian is excluded. Okay, okay, it's not, okay. Well, I wanted to talk about something that I heard both Mark and Matt say, and the most recent one was Matt saying that Ubuntu developers get flamed to a crisp and I think that's something that we need to discourage in Debian, but I think there are a couple cases. If it's the case that you were talking about, like they were talking about implementing a feature or something, this is something we're doing in Debian, that's certainly something we want to discourage. Although I think there's also the broader case of Debian project-related stuff that isn't specific to Debian, stuff that would be considered off-topic being brought up and you shouldn't be flamed, but you should just point out that he's off-topic and talking about it somewhere else. Mark, a few minutes ago you said that there are cases where Ubuntu maintainers have prepared a patch that they thought would be useful to Debian and send it into Debian and told go away. And I guess that I hadn't encountered that or heard much about that happening. So does that happen? And whether more details are in that, because it seems like that's certainly a bad thing. And also, it depends on how you interpret it. So we have two huge projects. Two huge projects. And so we should assume that every form of human social dysfunction under the rainbow is going to show up. And so we can find cases to illustrate any argument. And I think it's just extremely dangerous to poison the beautiful possibility of strong collaboration across two big projects with instances and cases. To me, it really was down to focusing very strongly on what is the leadership, what are we trying to achieve and how do we get that done. Yes, there are cases where Debian developers have been extremely hostile towards Ubuntu developers and where it really bites. See, a lot of the earlier Ubuntu developers were actually DDs, so they knew how to work the system. And they had personal relationships. But there are now literally hundreds of developers in Ubuntu. They want to, we say that they should engage with Debian and so on. But it doesn't take many bad experiences for them to develop a bit of an allergic reaction to that. We will slap down any time we see somebody internally complaining about Debian. We'll say, you know, you really should, you know, try a different way. Try finding someone else and so on and so forth. We don't let that turn into a festering wound within Ubuntu, right? But it genuinely makes it extremely difficult when a new developer, a new contributor, gets that kind of experience. But I don't want to, if we go tit for tat on cases, we'll be here all day. I think we have the same goal. And I'm approaching it from the other angle, which is if the Ubuntu people are doing the right thing and trying to submit things back to Debian and Debian people are flaming them, we as Debian need to fix that. But in my experience, what I see occurring more is that there's the automatic, I can't remember what the system is that automatically generates patches, but you know, there's the automatic patch generation thing, yeah. But I haven't seen more of what you'd see on the Linux kernel mailing list where, you know, somebody writes a patch and gives it a nice description on top of, you know, a split out into a logical unit of this is a logical patch that provides this feature that we added and here's why you would want it. I've seen a lot of things. One of them is a comprehensive, like the entire delta between Debian and Ubuntu and it's broken down a little bit, but not very much. It probably depends on if it's a normal package or using other packaging, you know, CVS, and so on and so forth. And also it tries to split out, like, you know, some changes, which are obviously only specific and things like that in an automated way. Also we provide incremental patches for each artwork. So as soon as the turn is made, there's only that change, accompanied by the change block. It's a very nice, nice, nice. So, and the only point I sort of just kind of, my point here is not necessarily what this, what particular mechanism is good or bad. My personal opinion is that it's the best thing is if you take ownership of your patch. So obviously that would increase the cost for Ubuntu, but I think it's much, you know, somebody in Debian is going to get a change and he's not going to understand it, right? Well, the bunch of persons understand it because he made the change. That's not what my cost is. So yeah. So you take an Ubuntu and maybe just make that a little bit of a student, they've written a patch and they want to take ownership of it. Well, that's right. So they take ownership of a bunch of, I guess, and so the question is, you've got this code base that's 99.9% the same. But that means becoming a, realistically means becoming a developer. It's very difficult to make a direct contribution to that end and take ownership of something that's there without being able to actually affect that change and it's, I mean, the maintainer processing domain has been through its ups and downs, but overall it's been difficult for the developers who do pursue that to get through. So I contribute to lots of packages that I don't maintain and it's not through NU's. I can send patches to any package now. My packages, or my patches might be because I'm sending from a dev.org mailing address, maybe they pay more attention to me, but my experience has been that, you know, if I have a patch, I can send it in the BTS and generally it will get picked up without having to be in the package. So you send your patches on behalf of NU2W, which are sitting in the BTS two years ago, among those of patches on which stacks are all functionalities. And do you think that's maliciousness or incompetence or, I mean, because I have that case, too, but. In the case I'm thinking of, which I've illustrated, but the maintainer question has made very disparaging public comments about it, too. They may not be related, but I enjoy them pretty much. And that cascades, you know, as I said, although it depends on those patches, which can never be reimbursed to be developed. And I told you, maybe two remarks, possibly. One is, you told me for the perception of Ubuntu by devian developers. If devian developers evaluate Ubuntu's quality by patches, it's usual that they have sometimes bad feelings because, as you said, the patches are not always useful and they contain some kind of quick acts. When you guys saw a package maintained by young Jax and our colleague Watson and everyone, when they feed patches back only, patches that they know are good, we have, of course, they never have a good image of the Ubuntu containers. When they have nothing, no ways, and they have to look up and finally they find out lots of auto-tools generated stuff and a few acts because it was a change mainly in the last week during your freeze and the required, because you wanted to read it in time and you had lots of possibility to write fix. It's happening quite naturally, this perception problem. I forget my second point, no, but yeah. Oh yes, you say it's difficult to contribute back today and it's less and less difficult. We have big teams, I mean, career teams, Nome teams, paired team, Python teams and lots of YouTube, your new developers are contributing in those teams currently and I don't see why concrete can go further. I mean, we are at the point where we have the first different developers, we are Ubuntu developers first. We have Ruka, we have Cyertraut and more and more such people are integrating them so I don't think we have that many people who are hostile to Ubuntu. We have, of course, we, historically, we have, we are known to have half people but you can't know them at all. We don't have to work with them on their, their packages, you know, all the packages where things are going quite easily. I think that's a very good point. I mean, people are motivated by what they want to work on and you can say, well, it's very difficult to contribute to a difficult package but they can't be engaged in that personally successful career and just do something else and they really want to do that and if they have the opportunity to work on that and they want to work on things that interest them most then that's what they'll naturally do. But, okay, just, my point real quick is that when you separate your code base, you basically, you're creating an arbitrary boundary. So these people are not, these people are passionate about adding a feature but they actually don't care about what code base it belongs to. So it just so happens they're using Ubuntu so they contribute to Ubuntu. So by forking the team, you fork the, so people are passionate about their work, they're not so passionate about what code base it goes into. So moment you are. Well, okay. And also, and yeah, there is absolutely a cost to having two communities rather than one. It really costs that kind of a perfect world that wouldn't happen. But in, you know, realistically, there are a lot of communities working on the same code as there's a division, you know. Yeah, pretty. And there's a division, maybe, between Jenny and upstream, which, you know, is not perfect and often there's not great communication between them but in the end, they will produce something useful. And it works pretty well. Question? A question. So we're talking about the development process there. What did you say, maybe Ubuntu is a threat to the game? So you could maintain everybody's switch from the game to Ubuntu and taking the desktop, the servers to the game, the Ubuntu switch. What is going on in the marketplace? Are you a, in terms of installation and don't know the US data? Is Ubuntu taking over, is Ubuntu down, and Ubuntu taking over? What's going on? Well, I think... What does Ubuntu think? I think it's safe to say Ubuntu is extremely popular, right? And I think that's a very... Here's the fundamental question. Is Ubuntu's popularity bad for Debian or good for Debian? I would say that much of what people love about Ubuntu would have been achieved if Ubuntu, we had chosen to derive off Fedora, which are the drive of Gen2 or drive of OpenCV or with Android. So the real question folks should ask themselves is, are we better off, you know, that we have that 99.9% commonality and we have this capability to set up effective processes to collaborate? We chose Debian because it is an extraordinary community and we were all Debian developers for a reason. But I think it's dangerous to, again, to create the sense of division where there doesn't have to be a sense of division. So what is the meaning of universal OS? Is it one set of packages, one set of binaries? I don't think so. I think the extraordinary thing about Debian is how people are usually using it means pairing it to your purposes, right? Although those guys are embedding it on set-top boxes, do they ship the same Debian binaries that are on the Debian archive? I highly doubt it. I think they tailor it and they customize it. They tweak it. That's what, to me, is the universality of it. It is, to the whole distro, what kernel.org is to the kernel. And as soon as you take the view that universal means that it should work one way for everybody, you get into an extremely difficult place. And in fact, I think if Debian took that view, there are large sums of people who currently contribute to Debian who would struggle. Why is that? Because if they felt that they were discouraged from actually changing it and customizing it, I think of all the people who work in a place where they take Debian and customize it. So they're extramodero guys, right? How is what they're doing different to what Ubuntu is doing? The guys who embed it, how is what they're doing different to Ubuntu? Well, most of those cases are like, if you look at damn small Linux, right, that's a Debian derivative, but that's like what, three guys? So, and they don't have 10 million users, basically. None of those guys have 10 million users. Right, but so this is a profound thing. If you see those 10 million users as a threat to Debian, which I've done, I think those 10 million users who are now using app get instead of the app, 10 million users who are asking ISVs to think about their face packaging, right? The values and the tools, the tools stream the tool chain are getting propagated. And I think there's an enormous amount that's coming back to Debian. And to miss that is just to poison the well when it comes to collaboration. I think you mentioned Zimbra, you took it up to be able to get it back in this. If I remember correctly, they did that at, you know, but the result of that is that guys at Zimbra like I was doing packaging and dev format. Well, actually their announcement, this was a year ago or so, their announcement was that they were going to support Debian. So, and my point was simply that if you got, you're just, there's just increased tax by having incompatibilities between the two formats. So it's not necessarily the biggest point, but it is a tax. That's what a lot of these things, I think go down to taxes, you know, that you can argue about how much they are or how significant they are. But there are incompatibilities between packages from Sarge and Edge, for example. And it's essentially, it's exactly the same reason why there are incompatibilities between Edgey and Feisty and Edgey and Edge or whatever. You know, those incompatibilities are the effect of life of the binary stuff underneath changes and so the packages are incompatible in a lot of cases. But it's just, you just increase the tax by having more, I mean, you know, you just increase the tax. Even all the Linux distributions have that. Yeah, that's right. And that might be one of the reasons why Linux hasn't taken off is all these taxes. No, but I also believe, I mean, people are giving away their time. So as they mentioned multiple times, it's what you're passionate about. And I think Ubuntu took a different approach or a specific approach that Debian wasn't taking so strongly. And I mean, I don't think you mentioned having one tree for everybody. I don't think that's necessarily good because everybody has to have the same vision which I don't think the universal operating system can have because then it's not universal anymore because not everybody has the same vision. So I don't think it does duplicate work but it also opens up a lot of possibilities like what Ubuntu has done to have more and more, like you said, power managing, maybe lots of stuff that wasn't particularly important can get focused on. And I think many times duplicating work can actually end up building much more even if you're doing some things twice, you're doing a lot of things that wouldn't have been done if you would have, everybody would have gone. But the question to ask yourself is could you have just added better power management or modular X to the Debian code base directly? And what would have been the impact of that? Well, I think could we have, could we have? Well, yeah, whoever wanted to do that work, yeah, basically. As far as I can see X in the Debian code base at the moment is bleeding edge. I mean, I'm running the absolute latest X drivers. When I got a new laptop and wanted to actually compile from source, I was only about five commits away from the head of the tree. I don't find that far from the pace, you know? Competing things like Sarge will basically just isn't there because of the edge difference. Yeah, well actually I was talking about the power management. I'm not sure what you're talking about I was just wondering what you were comparing with between what versions of Debian or Versions. Yeah, yeah, I was comparing edge power management too. Ubuntu works for core management and has been integrated in Edge. It's basically the ACP support package on the... Actually the UI, the UI isn't there though. Like, when I used a beta of Edge, I wasn't able to tell it to suspend. There wasn't a UI there. You didn't install the packages. Well, I just did an edge install. So I just wanted to categorically speak for Ubuntu as I sometimes can in an error capacity and that is to say that Ubuntu wants Debian to be successful. So anything that you can think of that we can do to help that, you know, we will do. We expect that in that kind of engagement that that's a genuine collaboration part of the development. We want Debian to be successful. And I will apologize if anybody's had a negative experience with Ubuntu, that's not the end of it. We love the values of Debian and we want to carry that as fast as possible to a very wide audience and that's why we do this. Likewise in Debian, which I can't speak for Debian as a whole, but if there are situations where Ubuntu maintainers are trying to contribute their changes back to, you know, effectively your upstream, which is Debian, you guys are trying to contribute things back and Debian's being a pain in the ass about it, then that's something Debian needs to solve and needs to be brought up to people in the project who's like, look, we're trying to help you here and you're... It's not always necessarily a personal conflict. There is a sense of, no, it's just a difference in goals. Yeah. Ubuntu, we may have a change in which we should be working to support a future that's going into the world, but in Debian, that's just another wish that's brought and it's not a priority for a person. And I guess if we get to the point where we realize that and it's a difference of technical opinion or priorities, then we can look at that and say, okay, it's all right to work there. And you guys have a wonderful system to keep your differences such that it still allows you to carry them forward and use Debian as an upstream and so that's okay, in my opinion, at least. And Steve, another point I want to address was the fact that Ubuntu is based on Debian unstable. I've seen that at often levels, criticism of Ubuntu, which doesn't make very much sense to me, much more... Debian is based on Debian unstable. Exactly. Yeah, but Debian seems when it's at zero bugs, whereas Ubuntu LPS was just a snapshot. I mean, I argue about whether or not that means anything. Essentially all the packages that ship in Debian stable at least came from the stable as well. But the bugs are off base. I think they go through a process of what difference as Debian, Ubuntu chooses to make that... But you guys... ...and then sets certain goals for it, whereas Debian takes a different approach. We freeze very recently. We stop taking changes and stabilize it at some point. We put a lot of effort into purely interesting cases. And basing off of one's... I mean, when it's... If you're doing new work on a code base, you work off the code. You don't have to go back to what I said when I said we're working there, because we want to bring our changes forward. We want to stay close to that. We want to work to your level. Yeah, I mean, I think it was smart in many ways. I just was pointing out that there's a downside of creating Ubuntu LPS. I think you were. Yes. Yesterday, in this room there, there was a guy talking about the basaur system. And it was interesting for me and for... I'm an outsider and I'm an anthropologist, so I don't really know anything about the technicalities. But what I experienced more like an atmosphere at that meeting was that some of the basaur people, and I think most of them used their... Have their Ubuntu tag on their chat up, they spoke about basaur and the rest of them, of the audience were more or less Debianites. And there was no mentioning of the conflict. It was just a talk where there was no difference. And it was very different from now that people bring up different than it. Difference is placed in the middle of a room and everybody's concerned about difference rather than just doing the stuff. And then that was nothing struck me. Now, right now, could it be possible if you think in a long-term future to have something like a basaur and have Debian and Ubuntu in the same distributed relation control system? Is that the good thing? It's completely... More or less why are we building basaur? That's more or less why are we building basaur, yes? Yes? You probably have no way to go, but... We do, yeah, I mean, we do it. It also depends on the cooperation of the two main heads again because if you have a bunch and the other main head has a bunch and doesn't even commit to that bunch or doesn't update the copy with the effects of it, you can't even measure it anymore. So you have to sort to some disk-sets reading or whatever. But if I have my basaur branch and the person should have been able to have another basaur branch and if they don't get updated in months, I have to read the disk-sets or look at the bootcrum, which is secretly useless. Even when the tools work perfectly, there are always consistent tools that are not a substitute for it. We still need that communication and relationship. The technology trying to solve a social problem, yeah. It can ease the friction, but ultimately there has to be a willingness. Look, people, we're social animals, right? And one of my biggest concerns, since we've expressed the number of concerns, one of my biggest concerns is that within Debian, it is uncool to take a posture of saying we should look at ways that we can collaborate more effectively. Absolutely. You've been through this, right? You've put in a lot of work trying to create systems whereby places where this collaboration could happen. And it's a painful process. And I think a really thing is important that leadership in a project, and there are probably a lot of leaders in this room within Debian, think seriously about that and encourage people to take a positive view, right? Find ways to collaborate and find ways to resolve conflicts rather than dwelling on things that didn't work. There's, we can all develop a shopping list of things we don't like. Rather, develop a list of things we'll work together to fix. So speaking of leadership, I'd kind of like to say about the talk and the growing discussion. Now, one thing that has not been much talked about is my insurance, because the winter has roughly 60 motors and about, I don't know, 40 global developers. Well, it won't be, and Debian has one fuzzle, not many of which are really active nowadays, but a good majority of the Debian developers are still active. Well, it's already difficult to have them work together. And they have the same goal, which is make Debian better and even then, it's difficult. So if you also add to these people, people who have slightly different goals, even if they're close, such as the Ubuntu maintainers, you're very likely to have disagreements. Not necessarily fives, but disagreements. Those disagreements are really enough to slow down things. So I don't think it's really a problem to have different teams with different people working on the same thing. It can be healthy because different approaches don't always solve the problems in the same way. So when I find it usually very good when the same people take care of the packages in Debian and in Ubuntu, because they know what they're doing in both distributions, but it's not necessarily a drawback to have different people take care of the packages. So that's about our story to see my notes, because... But when we have two teams, two separate teams, it's good when they can at least agree to share a common source control system so that one can effectively merge with the other. And I think we have several occasions where Debian developers offered this to Ubuntu because we have alias of our collaborative system where we can grant access to outsiders. And for various reasons, not always really clear. It was refused sometimes, but because it's a bit more raw for Ubuntu developers and they are stuck tight on schedule and doesn't want to invest in that. And sometimes we don't know. And maybe that's something you could push a bit further on your side. I mean, encourage your employees and the other Ubuntu developers to accept such offers. And I don't know, do you have a policy for them to use official canonical or Ubuntu infrastructure or can they do their work on our AIOS system? We prefer folks to use Bazaar, for example, because it's distributed and it gives people the ability to work where they want to work and where it's most efficient for them to work. Same is true of Git, same is true of McEriel, Docs, MonoTone, you know, pick the tool. We definitely don't, you know, CVS and Subversion make it harder to have constructive engagement while maintaining different views because, you know, there is one and only one tip and it's very difficult to merge or maintain a delta. Anyway, ultimately, we have to inspire people to want to collaborate. And if anything, that's where we break down. To two remarks, we have a different revision, we have support of Git, Bidder and other, Arch, HL, McEriel and everything you want. We have McEriel, MonoTone, if you want, if you can do it. And in some cases, your teams don't use the revision control system at all. It's the case, for example, for the video team. It's Sébastien, Bashi and Daniel Robach who are uploading packages without any system, so we can't really track what you're doing even if you want to. They have been offered access to the Subversion because it's already in the demo, but they never use it. I think that's, it's not problematic, but it would be really better if we could make that bit of effort so that we can track, close it more closely what you're doing. What's interesting to me there is that your experience there is our experience everywhere else, right? There are many packages now where Ubuntu does the primary, does do primary packaging, not all of them. There are many packages like that. In some cases, that the Ubuntu maintainer is also maintaining the same package or it's part of the team that maintains it in the video. But, so your difficulties and frustrations dealing with that are the difficulties and frustrations that we deal with all the time. So it's good to see that it is challenging when you're on both sides of this thing. Yeah, sure, but I have no problem with that. You can ask me to put my package in the, in fact I've already done that, so my package is the, I mean, I'm just asking you for those cave, I know, but feel free to ask the same to all the maintainers. I mean, we have good infrastructure and there's no reason for them to refuse, I guess. I don't know if you have specific experience where people refuse to use the VCS, but... Are we supposed to be out of this room now? Or does that go on? There's a type on the open fonts, so we can give you a few extra minutes, no problem. Maybe I can quote the example of what we're trying to achieve with the fonts team. So there's a fonts team on the winter side and there's a fonts team on the other side, and we're really trying to do it together. But it's really easy, it's really easy. So if you need a few more minutes, go ahead. No, thank you very much. Thanks. So I would just leave you with one question, which is, there's only one meeting in one minute's current. Somehow, those guys managed to put it all into one code base and one bug list, one, excuse me. Do you think there should be only one minute's suspension? Well, I think moving in that direction would be a good thing. I mean, I'm not, you can do it step by step, but you know, you could try not make the final decision. Ultimately, yes. But of course, I realize that's a long-term proposition. Thank you very much.