 Welcome. It's it's fun to be here. It's clearly the year 2013 because about a third of the people here holding up a cell phone trying to take pictures of us. It's always fun to do these these little conversations and see where it gets us. This session is basically your session. I've brought a few questions that I will pepperliness with, but I actually really want questions from the audience. We have a few runners here with microphones and if you have questions raise your hand and and we'll take it, but I'll start out with a couple that I brought and I'll start with the obvious one. What about world domination? No, forget that. 312, where are we in the process? So right now we're pretty late. I timed this well. I actually tried to time the releases so that when I'm traveling, we're not in the middle of the merge window because that just makes it really annoying. And having said that, the next merge window I will be traveling. But we're getting fairly close. The last few releases have been fairly easy. I mean, we had some issues, but we've used this whole process with merge windows now for several years, six, seven years, and we're getting the process down and there's still every time there's some issue that comes up, but I think we are getting much better at just handling things. Right now 312 is one week away, roughly a week and a half away, and things are looking good. So you say the process is working well. I wonder, are we focused too much on speed, too much on adding new features? Should we maybe take a step back and say we're doing a release with nothing but stability and bug fixes? At the kernel panel yesterday, there was a mention of 4,000 known bugs in the latest stable kernel. What's your take on that? So, I am so personally happy with the fact that we don't worry about features. And I mean that both in the sense that we don't try to do releases by new features, but also in the sense that we don't have these long freezing periods when we don't have any new features, and we do all the releases purely based on time, because whenever you have something that is based on, okay, now we have to have for the next three or four months, we're not adding any code at all, we're only fixing bugs. That gets everybody really frustrated and what ends up happening is people will stop caring, work on the next version when you can start adding features, and then we have this huge backlog. So one thing that I think has been working really well for the last several years is that we have been purely based on, hey, if it's ready now in the merge window, we will merge it. If it's not ready, you can wait, and it's not that long of a wait. And not worrying about the feature creep or lack of feature creep too much, and instead worrying about getting the process to be smooth and making sure that everybody is okay with the fact, but okay, if you don't make it, it's going to be only another three months, right? So don't hurry your code, make sure it works well, make sure it's well designed, make sure people are all on the same page, and you don't have to worry about timing. And that makes things so much easier for me as a release person, but I think it also ends up, well, I'm pretty sure it also makes it much easier for all the developers and all the companies that they don't have to really worry about, hey, we need to hit this particular date because they know that if they miss that date, it's not that big of a deal. Well, it's actually, for the last many kernels, it has been less than three months. It's usually like 10 weeks. It's usually about 10 weeks, yes. I mean, we aimed for two months originally knowing that will slip, and three months is kind of my, that's the longest it should ever take, and usually it's nine, 10 weeks, yes. But what about adding a week delay after the release before you open the merge window, just to let things settle a bit, let people start using it, and maybe give Greg a head start? Greg is doing fine. I didn't say he was. Greg is okay. Are you here, Greg? He might be, oh, he's over there. I'm not seeing any gray hairs, right? You're not seeing any hairs is what you wanted to say. We've tried that never actually a week, but I sometimes want to have a couple of days, especially if I'm slightly tentative about a release, and we had some late minute issues, I want to say. I am not going to merge stuff. I want all the developers to really now be on the release, and if something comes up, because people are starting to use it more, because we just made a release, I want you to work on that. But that's only happened a couple of times, and I think it is counterproductive because it just means that people will still, I mean, the way developers work, I don't know how many of you are actually developers in the audience, you know. Developers have the attention span of a slightly moronic woodland creature. There's not a lot going on. They want to work on next thing, right? They're not going to work. I mean, giving them another week is just going to add frustration to everybody. So now that you called developers slightly moronic woodland creatures, I hope someone wrote that down. I actually had a young college age developer ask me a couple of weeks ago, so how do I become a maintainer? I guess the first answer is don't be a moronic woodland creature, but beyond that... I don't think that's the first answer. The first answer is be reliable and let people know you are reliable. A lot of it is about technology, but at the same time, looking at my personal experience, one of the most important things for a maintainer is not that he's this super engineer that knows to solve all problems. The most important thing for most maintainers, I would say, is that you're responsive and people can just rely on you being there 24-7, 52 weeks a year, and if you're going away for even just two weeks, let people know that they don't get taken too much by surprise. That doesn't mean that you have to answer every single question. I don't answer email unless I feel it needs to be answered by me, which means that most email I get I will not answer because I think, hey, guys, you should have sent this to the correct maintainer or you should have sent it to the mailing list. If you send random bug reports to me directly, I'm saying you're doing something wrong. I'm not going to be responsive to that degree, right? But I do think that the most important thing for a maintainer is to make sure the developers you work with don't end up hanging. And that tends to be the biggest problem we have is if the maintainer for some subsystem goes away for a month and nobody knows what the hell happened to them. So being reliable and trustworthy is the biggest thing. And for a new young person, the biggest issue is to get trust, it's not that people don't deserve trust on their own. You have to show that you are there for people, and that takes time. So it's very hard to become a maintainer these days without having been around for a few years and having shown people that, hey, I'm around. But if you actually have been around for a few years and have shown that you are responsive and responsible, it's actually really easy to become a maintainer because it's a shit job. It's a horrible, horrible job. You are going to be there 24-7. And it's fun and it's interesting, but it is a lot of work. And I'm seeing somebody nod in the background, right? So it's not hard to be a maintainer if you have the right qualities, but you do have to be there for people. Any questions from the audience? Or is everybody still asleep? We can keep going up here, no problem. So what keeps you up at night besides your children? I don't worry about technical issues usually. The good thing about technology is we do something really stupid and we can fix it, right? I don't actually sleep pretty well. Occasionally we have things flare up and then things get stressful and they are invariably not about a particular bug. They are about social issues, process issues, people wanting to kill each other and email doesn't work for that, but it works well for development. That doesn't happen that often, but when it happens it can be very stressful for a few days. I get really excited about things for a couple of days and say whatever, I don't really care. So I have flare ups and that works fine for me. Other people tend to then mull over things. I don't know, I mean I sure you all at least know somebody who just eats at them for weeks and weeks and end and those kinds of issues tend to be the painful ones when you know there are bad things happening, not on a code level, but people aren't happy. So do we have issues in the kernel right now on a technical level where you say, oh I wish we would fix that. Is there a feature that you desperately wish or a change that you hope that would finally make it? No, I mean the situation that I really, I think my concerns are not technical concerns. My concerns about maintenance issues, to be honest Linux does or has done everything I personally wanted it to do for about 20 years now. So any new feature I go, wow there are some crazy people out there who need this, right, because everything I do we saw a long time ago. Like working suspended as you? No, it works. So I don't worry too much about features or things I want to happen. I worry more about meta issues, so for example one of the issues we constantly have is our new hardware, right, and some manufacturers are really good about it, I'll name Intel and some manufacturers are not really good about it and I won't name other companies. So what I really wish for is not that somebody would come up with a certain new feature or code up a new thing what I really wish for is that sometimes some companies would learn to work better with the community. I mean sometimes we're not always easy to work with, don't get me wrong. So sometimes we need to help companies too, but that's the kind of thing I worry about. Questions from the audience? There you are. One question I have is how do you propose those helping, educating, enabling some of these new hardware vendors primarily out in places like China who are pushing out hundreds of thousands of devices a month and have the most obscure kernel support possible? Having discussed with one of their engineers over some noodles, their fear was well if we push our kernel code upstream then our competitor will see what we're doing and trying to educate them over some noodles is a bit difficult especially seeing as my Chinese is really poor. Yeah, I mean this is a problem and this is exactly the kind of issue where with certain hardware manufacturers are simply hard to work with and I don't think the solution is to try to educate everybody. I don't think you can. There are processes in place. There are companies who know how to do that and then they try to often educate their subcontractors. There are Linux Foundation and one of the things Linux Foundation is doing is talking to companies. This is how you do license compliance and things like this. So there are processes in place at the same time. We're not out there to make sure everybody does the right thing. The reason I do open source is A, it's fun and B, it works. I think the thing that really educates companies about being members of the community and really participating is not us going out to them. I'm more of a live and let die kind of Darwinistic person and I think the companies who learn to work with the kernel and learn to get things upstream are going to waste a lot less time with new releases and just getting things done and they will just work better. So in a very real sense, I'm like, okay, if somebody doesn't learn, I'm not going to bother with them. I want to make sure people at least comply with the license and in some places you can't enforce even that. But at the same time, I'm not so worried because I do think that the companies who do learn are the companies who will win and the problem will sort itself out even though it's going to take some time and it's going to be somewhat painful. I can certainly see this from our perspective at Intel that we see this as a huge advantage for us and we actually see other companies mimicking our behavior in many ways which is kind of flattering and it's a good thing for the community. So I completely agree with that. And quite frankly, if you're a company that thinks that your tiny little change to the kernel is what gives you the competitive edge, you may need to rethink your economic plans because I think you need to have something bigger that keeps you afloat in the long term and you'd be much better off making sure you make the best damn hardware for the lowest price and don't worry about the fact that other people can compete and see what you're doing. Just make sure you compete so well that you win. And it's sometimes hard. I mean, not a lot of people want to be in that situation where it's actually open competition and the best man wins but that is what open source is all about. One of the things. What are your hopes for the Linux and open source ecosystem in the longer term, so perhaps 5 or 10 years? Personally. This keeps coming up. I started doing Linux because I wanted to use Linux on the desktop. And Linux is doing so wonderfully well in so many different areas and I am still somewhat disappointed and people have heard my complaints about the fact that the Linux desktop is this morass of infighting and people who do bad things. And it's not so much on the kernel side, I think. I think we're actually doing a reasonable job in enabling people to do a Linux desktop. And there are commercial issues that make it much harder so yes, you can sell a billion cell phones but selling a billion Linux desktops is harder. Don't get me wrong. But I do hope that the desktop people would just try to work together and work more on the technology than trying to make the logging screen look really nice. At the same time, I am very optimistic. I really don't have a five-year plan. I've never had it for the kernel. I don't think we need it for the kernel or for open source in general. I do believe that open source is the correct way of doing complicated systems and getting things done right. And it just turns out takes a lot longer than you sometimes wanted to take. More questions right here in front. And then there's one there. So it's matter of community. Basically you say I don't want basically to educate all of the hardware enabler or whatever on the chain. Can we just educate the communities in those places? It's very hard. How do we reach to those audience? We discussed that. I remember in the next one in Japan, is there going to be a Linux account, for example, in China and trying to get masses there and things like that. That's important. We do try to reach out to conferences and I'm just thinking back three, four, five years ago when people were talking about how do we expand the kernel community or the open source community in general from being very western Europe and U.S. dominated and the fact is, and people were saying how do we reach Japan and Asia? And these days we have tons of developers from Japan and Korea and Asia and we are reaching them and part of it was I mean part of it was just economic issues and Android in particular just taking over but we also did actively try and by we I don't mean me. I mean the kernel community and companies involved try to actively engage Asian developers and had like these conferences where you were talking about how the process needs to work and things like that and we're continuing that. I mean we're not going to reach everybody. The Linux Foundation has events in Japan and Korea and we've had those in the predecessor organization. We've been going to Japan for a decade now. We Intel have been hosting a Linux kernel forum every year in China for the last eight years. There are events popping up in Vietnam, in India. There is massive outreach happening absolutely. There was another question over there. Hi Linus. Hi. I don't know if I'm going to get beaten up for asking this question but I don't know if you kept up with any of the Apple announcements last night. I did not but go ahead. Well they're offering the new desktop OS as a free upgrade. I wondered if you had an opinion on that or whether that might have any impact on the next whatsoever. We've done that for 22 years. Yeah well. So I actually one of the reasons I use the term open source and not free software, one of them is purely political and one is that in the English language people get confused about the whole free word. It's not the fact that Apple gives their OS away is completely irrelevant plus you actually pay for it in the hardware anyway. So it wasn't like it was expensive before. I don't think that impacts Linux at all. No. There was another question over here. Josh. Leaving aside stability and bug fixes, what's the biggest feature that you feel like nobody out there is working on for the Linux kernel that would excite you know-in to see in your inbox? If I knew it would be that exciting. Right. I really wish. And it's not really happening anymore. Let's be honest. We have been doing this for 20 odd years. The kernel is kind of... I wouldn't say it's a known problem but at the same time the really core functionality is not that surprising anymore. And we used to have these things where people came up with new really exciting core ideas and they were big issues and they really affected the whole experience. And these days the new and exciting ideas tend to be in the periphery. They're not really that core because the core really works fairly well and the core does what the core needs to do. And when people say, hey, we need to re-architect everything for this major new feature, they're usually wrong. Like we need to make all file systems be database file systems. Right. There are... You can make huge changes for the sake of changes but it's not how the world works. And our core is there. I think if you look for new excitement where people are doing crazy things, you either need to look at like periphery in the kernel with new devices or new features of new CPUs or things like that. If that excites you, we've got you covered. But otherwise I suspect you want to be doing work outside the kernel and work on exciting new devices that ubiquitous new things you can do with computers that people haven't been able to do before and doing good user interfaces and things like that. I think that's where the excitement is and I've said that for over 10 years. As a kernel person, I think the kernel is kind of... It's really exciting from a technical standpoint but it's not a place where you should go look for new features. But it's kind of interesting because for the first decade in Linux development, we pretty much played catch-up. We were trying to implement POSIX. We were looking at features that were out there in other OSes. We were trying to basically meet the bar and now for the second decade of Linux, I thought that we were much more taking the lead and we were implementing things that maybe weren't there or have never been done that way. So do you perceive this shift as being now less exciting because it's fewer new features coming because we're no longer playing catch-up or is it not more exciting because we're actually implementing things that haven't been there before? So the excitement for me has always been just the technical side, doing things really well. And I am perfectly happy with... Literally, and this is what I personally do. When I write code, which is not that much anymore, when I write code, I look at the assembly generated by the compiler, I look at the profiles of the kernel and say, hey, this thing, we're doing things badly, our calling convention means that we're spending 15 extra cycles doing nothing. And that gets me excited just doing something really, really, really well. And I'm okay working on that level and I think a lot of kernel developers end up being people who are a bit OCD and they're looking at the details because it is about details. Sometimes it's about CPU details and worrying about the compiler. Most of the time, it's details about devices that have bugs or interesting features or things like that, but it's still very much about details. And we have had issues where we create these wonderful new exciting interfaces for people to use and I have almost always been disillusioned by the fact that nobody uses them. It's like we make these clever new things for people to do really clever things, but then when I actually look at what programs do, I say, Christ, that wasn't very smart, was it? They do most software out there is badly written doing stupid things and they want to use the minimal amount of features they can because that's the way you get portability, that's the way you don't get NASA surprises when you use the exciting feature that nobody else uses that turns out to be buggy. So I don't get excited about features anymore. I get excited about supporting new hardware. I get excited about doing the job the kernel does really, really, really well and making sure our process works for doing all that support. That's what I care about and I may be a bit OCD sometimes. More questions right here in front again. Raise your hand higher. So Dirk's already said about how the first ten years was playing catch-up with POSIX. Now, do you think that kernel 310, 312 onwards is building the next house of Linux because you've got much more advanced support now for QMU and KVM in the virtualization world? You said yourself that you want the cloud companies to play nicer together so that they're actually building platforms rather than WYSIWYG features, login screens, et cetera, et cetera. It's more important now that we have that stable virtualization support coming really from the mothership. I wonder what the question is. Well, if you think... From my perspective, I work at Red Hat. So a lot of my technology that we put out has a reliance on what's coming down through the mainstream kernel. And sometimes it's nice to see leadership coming down from the kernel itself in the respect that we see the changes in 3.10 for QMU and for KVM, which we rely on for that kernel support. Yeah. I mean, we do have situations where kernel features end up being very important to a subset of the market. And the subset can be very big for companies, right? It'll be depending on what you end up being... Like, which market you end up selling to. I do think that what the kernel's job is is to be a really stable platform for getting real work done. And the real work is never the kernel. The kernel doesn't do anything on its own. The real work always comes from outside. And if we're doing something on our own, we're almost certainly doing something really, really wrong. So I do want... This is the kind of mindset I come from is I want to make sure our base support is something people can rely on. This is why I, for example, have very strict rules about no regressions, because that ties into the whole thing where you should be able to rely on us as the kernel. And sometimes there are particular features where people do need to expand on things. And I think we're filling in the details at the edges rather than doing core things. That was what I was trying to get at in my previous answer. That's a question over there. Hello. What do you think of game coming on Linux and do you think it will bring manufacturers to add better support for Linux, like NVIDIA or IMD? What do I say? Who's coming for games? Sorry? Oh, games. Games, yes, yes, games. I actually... I love the Steam announcements. I really... I think that's an opportunity to maybe really help the desktop. And also it's... What I like about the Steam announcements in particular is that Steam is this one company that has a vision for how to do things. And I think that will force a lot of the other vendors around them. And I'm not just talking about the hardware vendors. I'm not just saying that it will help us get traction with the graphics guys. I think it will also force the different distributions to realize, hey, if this is the way Steam is going, we need to do the same thing because we can't afford to be different in this respect because we want people to be able to play games on our platform, too. So it's the best kind of model for standardization. It's not... standards should not be people sitting in a smoky room where the smoke is usually drug-related from what I can tell, right? Because... and then writing papers. That is not how good standards get done. I think good standards are people doing things and just saying, this is how we do it and being successful enough to drive the market. And I think it is interesting to see the Steam announcements from that standpoint and see where that goes. All the way in the back. We're making a workout for our runners. Linus, I'm having some problems with my graphics card. It's an NVIDIA. So that's a bad joke. The licensing of the kernel, I believe when you originally released the Linux kernel, you had a different kind of license. And then, I think a couple of iterations later, you changed to the GPL V2. Is the licensing of the kernel likely to change in the future? No. I say that both because I really love the GPL V2. I mean, I'm not saying that as the language of the license, it's not beautiful pros. I'm not claiming that we're talking about Shakespeare here. But I really like the concept and I really believe deeply in this whole enforced quid pro quo kind of tit for tat model where, hey, you can do whatever the hell you want with this, but you should kind of do the same thing we did. We give you source, you give us source back. So I very fundamentally agree with the version 2 model. Also, from a purely practical standpoint, changing the license now for the kernel is basically impossible because I never ever wanted to do all the crazy copyright ownership paperwork. And I always felt that people should retain copyright in the code they write. And the thing that matters is not that there is some single entity that owns copyrights. The thing that matters is that lots of people own copyrights in the code, but they all agree on the license. So in a practical sense, we're in the situation where there are thousands and thousands of people who have copyrights in different parts and trying to get people to agree on a license change is just not going to happen. But I also feel there's no real reason to try to make that happen even if we could get people to agree. Over there. I'm aiming this way, sorry. I think I remember reading that pretty early on in the project, a bunch of people got together and contributed to pay off the loan on your first X86. I was wondering whether the volume-free stuff that people offer to give you has gone up in line with the growth of Linux? Well... I have to say, that's still one of those warm memories. I think Peter Anman is somewhere in the room, and he ended up being the person who collected checks in the U.S. so that they could send one large check to me. Well, large. It paid off my first machine, at which point I immediately bought a second one, right? I get paid for doing Linux these days. I don't know how I conned people into doing that, but I have a wonderful contract that says that I get to do whatever I want to do as long as it's open source. More of the contract talks about what the Linux Foundation must not do to me. They cannot force me to give public speaking. They ask very politely, because they know that my contract says that if I say no, I just don't go. So yes, I still... Well, still, I now get paid for doing Linux. For 10 years, I didn't. For 10 years, I very consciously wanted to avoid being employed by a Linux company because I did not want to be in the situation that I was seen as biased towards a particular company. And now I'm at the Linux Foundation which doesn't worry the commercial companies because they don't see me as competition. They see me and the Linux Foundation as a whole, kind of third party that everybody is pretty happy to work with. So I think people are good with this whole situation. I'm not the only one, obviously, who is in that situation these days. But you still do get the occasional large prices like the Millennium Prize and... Well, it has helped to make sure I can get my kids through school and I have owned my own house and the companies have given me pre-IPO stock and it used to matter more than it does now. And I have gotten prices too. So yeah, I didn't... I know Bill Gates, but I really don't miss that at all. There was another question right there. Notice later on today there's a session on getting women into the Linux community. That should be tomorrow, I think. Is it tomorrow? I just wondered, as essentially the leader of that community if you felt there was anything about that community that could be better on that front? It's a hard question and I don't have any easy answers for that. And it's clearly something we want to solve. And at the same time, part of it is I'm convinced cultural. And that is not something we necessarily can solve. We can try to do as good a job as possible giving that constraint. And when I say cultural, I don't mean our culture but that's also an issue. I just mean the bigger culture of the western world and Asia and everywhere. And at the same time, I do want to say that despite the fact that we have very few women I'm not very pessimistic because we used to have this exact discussion 10 years ago about the fact that we had very few Japanese developers. We can fix it. It takes a long time. And it's still the case that we are predominantly western Europe and the US. And I am convinced that we will be predominantly male dominated for a long, long time. But I think it will improve. And I think we're doing a lot of very good things. We have the outreach program, the internships for women that have created a tremendous amount of new contributors and new code. And I think the fact that we're talking about the fact that there is a lot of awareness that's helping us. So there is no easy fix. There is no easy solution. But I certainly think we're making progress. So I have a completely different question for you. And you talked about how harsh your life is. I did. Yes, yes. I was talking about other maintainers. I don't. Greg gave this whole talk a couple of weeks ago about how I do nothing. You nodded and said yes. Well, I wasn't there, but I read the news reports for the next few days and it was not good for my ego. Let's put it that way. So the next question will certainly be good for your ego. So what needs to happen for you to retire? It's the first part of the question. And B, how will you be able to tell the difference? And we're out of time. What needs to happen for me to retire? I don't know. It needs to get not interesting. And that hasn't happened yet. It's very different from what it used to be. And I do very different things than I used to do. But I still like what I do. And what I do doesn't tend to be a lot of programming anymore. I'm the kind of... People just know who I am. I send this to Linus, it's Dan. And then they can ignore it because the one thing I do try to be is very responsive. I've been merging things early this morning before I took a shower because I do try to make sure that developers and maintainers don't get hung up on me. But if it ever gets boring or if I get the feeling that I can't cope that's when I'll retire. When the doctor tells me that, hey, it's not working all right up there. I'm sure we can find somebody else. As to how I'll know the difference? Well, by then I probably won't know the difference because there's not a lot going on anymore. So let's turn this around. And this is the question that I remember vividly you being asked in the late 90s by Larry Augustin at Linux World Export. When he said what happens if you are hit by a bus. And I liked your first answer, which was, will I care? That's still the answer. I mean, if I get hit by a bus, will I care? No. But maybe the rest of us do care. The thing is, as far as the kernel is concerned we really have a very, very deep and wide set of kernel developers. I mean, we are unique in the open source world for having thousands and thousands of people involved. And we also are unique in having people involved, not just me, who have been involved for more than 20 years. Literally. I mean, we have... I recognize the names from back in 91 and 92. Some of them are still around, not all of them, right? Some of them went on to do other things. Some of them had accidents and died. It's not like everybody's around. But we have an incredibly deep set of developers. I'm not necessary in that respect. I am the person who people know, and they know how I work. And by know how I work, that means that they may not always like what I do and how I present things, but they can trust me to act in a certain way. And that's really important. You want to have that kind of knowledge that whatever else happens, Linus will be an asshole, but he will take my patches if I can convince him there are the right things to do. And that's a big thing in the end, even if that may be the only thing I do. But there are other people who can be impolite and can take patches. I'm serious about being impolite because I do think one of the jobs of a maintainer is not just to be responsive and take patches. It's also to say, no, this is not how it works. I mean, you need to fix your code or you need to fix how you're working, right? So we have people like that. Some of them are in the audience here. I don't think people need to worry about the whole development process. We are very stable. Okay, so we have 40 seconds left. The title of the session is as always fueling the future where we are going. Where are we going? 33, 32. Well, we never had a plan. I never had a plan. I still don't have a plan. It's kind of like evolution in biology. There's no end plan. It's just that what works is what survives. And if you keep doing that and the things that don't work, keep getting called every once in a while, you will improve. I don't know which direction we'll improve in, but I don't worry about, I don't need, and I don't feel like I need to worry about the future. I don't feel like I need to have this laser focus on where we're going to be in five years, because I think our process means that we can avoid it. And that's important. Thank you very much. Thank you.