 Good morning Welcome to the road map session Linux kernel 2014 to 2019 detailed information This is fun this room apparently holds 1,250 people and my guess is 1,232 a year Welcome My name is Dr. Kondl. I'm Intel's chief Linux and open source technologist and this guy is Hi, I'm Linus and I don't do speeches. So that's why we usually do some kind of Q&A style session or Fireside chat or whatever you want to call this. Yes, we we have I was gonna say microphones, but I see Singular one microphone So if you have questions just scream Yeah, well screaming is not gonna work. There's no way we're gonna hear people So if you have questions, I'll start it off a little bit But then hopefully later we'll get questions from the audience to make this more interesting First question is always easy Where are we? What are we doing? Oh and not not geographically but merge window stuff like that so Right now. I mean the middle of the merge window for 3.18. We've As mentioned since 2.6. We've done this Release schedule where we do a new release every two to three months and It's actually been holding very stable for the last six years or so and sadly this time around The first two weeks, which is when I take all the new stuff and Where I have to actually read email all the time and have to compile the car and all several times of day just to make sure that None of you developers broke anything for me have been during the time I was traveling for here and and earlier for For my mini vacation before but everything looks good The speed of development has not really slowed down the last few years we've had Generally over 10,000 patches every release from More than a thousand people Greg usually does statistics on on the exact details but it's it's been remarkably stable and End result is also I think being very good I mean we our new development model, which isn't that new anymore has actually meant that we never regress a lot because we keep doing these small smallish incremental changes and At no point do we let the system get out of control like we used to back in the 2.5 days a Small 10,000 patch update. Yeah But an interesting question. How much does travel affect this so bon air didn't really have All that great internet and you had to open your screen door to to get to the Wi-Fi So how bad is that I was actually afraid that it would be much worse than then it ended up being It turns out so the other project I'm involved with get or not so much involved with anymore is very network efficient So I don't need a lot of network what I actually the biggest pain point for me while traveling is that I travel with Just laptop and I don't want to push out my changes publicly until they've been tested So while there are a lot of public test machines that do builds and verify everything Even before they hit those public test machines I want to make sure that things work reasonably well and my laptop is a bit underpowered compared to my home setup So the biggest pain point for me during travels tends to be having to wait for an hour or two in between Pulling changes from other people to verify that they still compile and yes, I'm looking at you James It was all good. It was all good Yeah, it's always disturbing when Linus comes to breakfast and says ah after four pulls something broke So the reason I asked about this whole impact of travel and and all this you said something Interesting the last time we did this in Chicago wherever it was I can't remember last time we did this panel you said you wanted subsystem maintainers To consider following the x86 model and have more than one maintainer kind of Share that role. So how about applying your own advice at the top? I'll probably have to do that someday right now I'm not getting a lot of complaints for not being Responsive and I think being responsive is one of the most important things any Colonel developer at any level can be so I actually strive to make sure that if I expect to not be able to pull within Reasonable time reasonable time for me means usually three days or so I at least warm people beforehand So this time before I traveled I said next week I might not be able to pull at all and it turned out to not be true But but I really think in an open-source project the biggest thing a maintainer can do is make sure that the work that The real programmers do I'm not a real programmer anymore that the real programmers feel like They don't have to wait for the maintainer so So far partly thanks to get I have I think being able to keep up And and if my sub maintainers feel like I'm not Responding to them fast enough then you guys need to actually speak up about that and the same goes for Sub-sub maintainers and for for actual developers if you feel like your Maintainer is not responding to your needs Speak up about it We do have I feel a very strong Maintainership network for the kernel we have a ton of developers, but we also have a lot of maintainers And I think it works really well, but if there are weak spots Let's make sure we fix them and and eventually We may have to go to a model where we have a few top-level maintainers We haven't I don't think reached that point yet, but it's something I think our model Supports conceptually and we have seen trees were where people do exactly that the x86 tree the arm trees picking that up Discussy trees picking that up So there it's definitely happening and maybe it will happen at the top most level too at some point I mean we talked a lot about about the process about how this works. Where do you think are the challenges? Continuing such a massive project. There is no other software product at this scale that has, you know 50,000 patches come in every year. It's insane. We are the challenges of testing and that's a Lot of people talk about automated testing and automated testing is all good But about 60% of the patches are to drivers and automated testing is Just not going to catch those apart from the really obvious problems This is I mean a lot of people want to have Market share numbers lots of users because that's how they view their self-worth, right? But to me one of the most important things for Linux having a big community and having a community that is actually Actively testing new kernels is that it's the only way we can support the absolutely insane amount of different hardware We deal with It's not only drivers. We have something like 35 different file systems, but File systems tend to be easier to test in right try 85. I don't think it's quite that bad. I think so So so there are a lot of other areas that have a lot of code The good news is most of this is very modularized. So when we say we have 10,000 patches in every release More many of those patches really just touch a particular driver or a particular Subsystem and that makes it much easier to manage. There are not people Generally stepping on each other's toes very much I'm I'm shocked by the shy and introverted Germans. Yeah Germans are known for being. Yeah, exactly No one dares to speak up. That's a cultural value. We do have a microphone. So if you have questions for Linus, you know Push the people next to your side be German about it and come to the front I Have I have a slightly different question that but that in many ways goes to the same point If you could change a single decision you've made in the last 23 years Excluding your family I Was gonna say I Know you Which would you change or would you make do differently? Or was everything you did perfect which also would be an expected answer. I mean Um So for a technical standpoint no single decision has ever been that important Technical issues even when they're completely wrong and they happen you can fix them later Some of them are very painful to fix because you've done something Incredibly stupid at an interface that people start using and then three years down the line You realize that okay that interface was really badly done and it's a major pain for everybody And we need to rewrite it, but at the same time You need to support all those old applications that use this stupid interface while you're creating a better Version of it and that can be painful, but it's not something I would say is a major mistake in the big picture The problems tend to be When it comes to development in this big kind of environment where there are thousands of people around The problems tend to be alienating Users or developers and I'm pretty good at that I I use strong language But I again there is not a single ish instance that I'd like to fix There's a there's a Metric shitload of those So at the same time hey, I am who I am You can't go back and fix it and we're doing really well. I mean we have a very lively community Most people even if they don't necessarily always like each other do tend to respect what? the code they they generate and and in the end for Linux I think that's the important part is that as a what really matters is that people are very involved in Generating the best technology we can and what's important is that they enjoy being called monkeys on crack Some people seem to I mean There's there's a certain amount of Stockholm syndrome where when you abuse somebody enough they start kind of liking it and I Say that jokingly, right? Hi James Another really sure is I Actually think it is important to be on the internet Nobody can hear you being subtle and it's really easy to get Your wires crossed and not really understand what the person on the other end feels and especially if you're being gentle about this and saying Yeah, your patch. I don't like it. Could you maybe change it a bit? The other end is kind of encouraged to go along and continue doing the same thing When sometimes you really need to say no no really that is horrible. You cannot do this go away and come back with a completely different approach and and So I do think that one of the reasons we have This culture of strong language that admittedly a lot of people find off-putting is that when it comes to Technical people who have strong opinions and have a really strong drive to do something That really is technically superior you end up having these strong opinions show up as As Sometimes pretty strong language We have a question I recently saw a statistics in LWM that the release cycle is going shorter from like Approximately three months to we're approaching two months and my question is is that intentional and from an egoistic point of view Can we go back to three months because I'm I'm a maintainer I get more patches I get more and more patches and I hear you saying get another maintainer But sadly in drivers that there is none And so it seems to be a bit paradox to me to get more and more patches and the release are shortening the release cycle so the release cycles Have grown slightly shorter originally when we tried this new Development model we were aiming for two months. That was kind of the original goal and everybody was this is that at the Colonel Summit back in 2007 or something right and Everybody said he had two months in your dreams Because our previous release cycles had been two and a half years so So the original goal was two months and everybody knew we'll push it and we used to push it usually to to about three months Right now for the longest time the standard release cycle has been two weeks of Merge window followed by eight weeks of release can and the Or seven weeks. So what would be the eighth release candidate ends up being the real release? So so about nine to ten weeks so two and a half months But it really ends up being dependent on One of my issues is at the end of the release Things quiet down a lot and that's good, but it also means that I get pressure from Developers saying hey, I have all these new code to send you, but I can't send you anything old because I Don't have any important fixes pending So I don't want to drag out releases longer than I feel necessary Because that just delays the deluge of patches that is pending I Feel that two and a half months has been good the good part about a short release cycle is if you miss it Two and a half months later You you can push all the stuff you missed So we're actually having these conflicting goals that we want to make them short enough that missing a release It's not a big problem. It's not a problem for distributions and it's not a problems for for developers But we want to make them long enough that we actually have time to go in and find the Not all the bugs because you never find all the bugs, but but enough bugs that my base releases are good enough that then When Greg comes along and does a stable kernel He doesn't get completely overwhelmed Greg Yeah The other part here is and you say you already get so many patches as we've seen when the Infrastructure issues three years ago made a release cycle of longer The longer the release cycle is the more patches come in and the harder it becomes to stabilize them So there really is this sweet spot where going to 13 14 15 weeks Just creates so much pressure on Linux next that the merge window becomes a disaster and RC 1 is very Instable and this just I I actually that definitely happens. I mean we had RC. I think 3.16 was the biggest release we've ever had and I think 315 was longer than usual so I Mean I I realize everybody wants Changes, but but there are conflicting conflicting pressures So that's completely switch gear What would you tell a student at some university today? Let's say University of Helsinki just random example Who wants to become the next Linux? Well, what should what should they think about? No, I mean, that's not how it works and that's not how it should work I mean you shouldn't want to become the next Linux you want to find something that you're passionate about and just do it and In fact, one of the mistakes. I think some people do is that they aim way too high And they they aim at something that is so big and so complicated that Long before they reach it. They realize. Hey, this will take me 20 years to get there or 30 years and I only I only come this far so and and that Makes you frustrated So all that I mean all these motivational speakers that say aim for the stars and maybe you'll hit the moon There it's that's not at all true. I mean what you should do is have something that really Makes you feel this is what I want to do for the next two weeks, right? And I will get it perfect and you have these small incremental goals And then after the two weeks are over and you say wow, I really I really nailed that and now I'm bored What should I do next? Right, that's the kind of model that that I think I know I took with the kernel And I think our current development model kind of is all about is Don't have these lofty goals of of trying to reach for some very important next pinnacle Instead have a much more pedestrian view of making sure your next two weeks or two months Is full of interesting technical problems. Yeah, it's interesting a little over 20 years ago the first Linux conference happened not too far away from here in Karlsruhe the room was a little smaller there were about 55 of us I think and The golds back then were really a lot more pedestrian than today The records was talking about having the first stable scuzzy driver And we were still fighting to get the complete TCP IP stack into the kernel that took longer than we really expected By about a year. Yes So if you say Small goals make it achievable How hard is it to become a Linux kernel developer a sub maintainer a maintainer the next God? Each step is slightly harder, but it's actually fairly easy to become a kernel developer You need to have a certain mindset and you need to enjoy a certain amount of Tain Because usually the way people get involved is as driver developers That's the it's not the only way to get involved But it is the common way where we're because there's such a plethora of Different hardware out there you can always find something that either doesn't have a driver at all Or it does have a driver, but let's face it the driver was not a Work of art and it has a few warts and it can be improved both performance wise and just code quality wise So there's a lot of these kinds of places where it's easy to get started in the kernel and pretty much all major Kernel maintainers and developers started out as driver writers Some people are more interested in in file systems some people are interested in in other areas So there are other things, but usually the way to start is being a driver writer Becoming a maintainer is really easy the only thing you need to do is have infinite amounts of time and respond to email from random people and I Mean some people seem to think that being a Linux kernel maintainer is some kind of lofty thing No, no it's it's great about that. Yeah I think Greg can tell you all about how much It's about lofty things versus how much it's about getting 5,000 emails in a month and having to I People I don't answer emails because quite frankly I from very early on learned to not encourage people to email me So so when I talk about being a responsive maintainer To me responsive means Responding to pull requests and making sure that people see that their code goes upstream and and does not necessarily mean responsive in the sense of responding to emails But becoming a kernel maintainer if you've been around for a while and you've been doing a few drivers and people start Recognizing your name becoming a maintainer tends to be really easy as in asking another maintainer Hey, can I help you and the other maintainer will just Say yes, please And and there are levels of maintainerships and it does get harder to go up that ladder because It's not about technical Skills so much as you need to gather the trust of people and that just takes a long time I mean you need to show that not only can you answer 5,000 emails in a week You can do that for three years running and And at that point people say, okay This guy is clearly not a flake or this gal He or she is Follows through and really you can rely on that person and that's a big deal So and that takes time And effort in the sense that you really have to keep going at it So the angry blinking numbers seem to tell us to be out of time But it would be a miss to let you get up the stage without Following through on the title of our talk, which is Linux. Where are we going? So my quarterly question to you make a bold prediction about the future of Linux the boldest prediction I can say is I will probably release RC one in about a week and and Prediction about the future of Linux. Yeah here in front of you only here and if you're really Excited about all the new features you can go and get the current git tree and help me test it because I'm running. What is the current git tree as of yesterday? I haven't compiled that today's tree other than making sure it all compiles, but I haven't booted it yet So please go and help Test that we're still on the right track Thank you