 Ni Hao, Wojiao Dirk, and I will stop trying to speak Chinese now. And I won't even start. So, it's a huge pleasure to be here. Linus and I get to go to a lot of conferences, and this is one that I really enjoy a lot coming to China. I think this is your first time in Shanghai? This is my first time in Shanghai. Third time in China, I think. Yeah, for me, it's more like the 20th time in China, and I don't even know how many times. I think most of the times I get to go to Shanghai. So, it's wonderful to be back. For me, this format of having a conversation with Linus on stage is something that grew out of a necessity originally, because Linus does not like presentations. I don't think anybody really likes doing presentations. I do not like doing prepared talks, especially when I don't know the audience that well. So, what happens is I feel stressed out by the situation, and now I have somebody to blame when he asks me questions. And if they're not relevant to you, it's not my fault anymore. So, basically, if this session is good, it's Linus' result if it's bad, it's my fault. So, let's start with something really easy. The state of Linux, you just released 5.2 RC6. Where are we? So, I have to say, Linux in the last... It's almost 15 years. We've had a very good model for doing development. It took us a decade to really figure out how to do things. But these days, we don't worry about individual features anymore, particularly not me. I worry about the process of getting those features out and making releases. And that really hasn't changed. I don't know how to really explain that to you. It's one of those things where if you get smart people together and you motivate them with a common goal, good things happen. And that is really... That's the only way I can explain it, because we don't... I don't even have a five-year plan. I don't have a plan that spans more than roughly six months. I want to make sure that we have a smooth road and then we have a... Every release, we have about 1,500 people that all work on their own individual parts and maybe 100 people who end up being maintainers who take those parts together and then send them on to me and I make a new release roughly every three months. So RC6, the latest release last weekend, was pretty big, which is unusually that late in the cycle. How come? So we usually hope that all the major work gets done or gets integrated during the two-week merge window and then we have usually six or seven weeks of release maintenance and fixing bugs and just making sure everything works. And, sadly, reality does not always work with our schedule and we end up having security issues sometimes that just have deadlines that come at the end of a release schedule which is very painful for us. We also end up sometimes just being unlucky and having people find some new issue that doesn't really mesh with our timing. And it's something we've learned to deal with. It's not a big deal anymore. Right now we're in the... We're supposed to be in the latter part of the calming down period and, yes, last week was actually much more painful than it should have been, but at the same time this is something that over the last 15 years we've learned to deal with. So it's not something that makes me worried, it's just that, oh, well, it happened again. But so we are still on track for five to two release in two, three weeks? We have been very consistent in hitting usually... RC7 tends to be the last release candidate and then I do a release the week after. It actually looks like we're on track for that right now. The most likely cause of maybe delaying a week ends up being whether I have internet access next... over the next seven days or not. And that might actually shift things by a week, but it actually has been very consistent. And I think we are on track now too. So how much do people outside of the core Linux community still care about the intricate details of how we develop Linux? Has this plateaued? Is it declining? It's still growing, but we have... I mean, it's maybe not growing at quite the same speed it used to be. And I don't think people outside the Linux kernel community should necessarily care. What they really should care about is how consistent we have been. And what most users of the kernel should care about is that they can feel confident in moving to a new kernel and knowing that there's a lot of people who spend a lot of time making sure that when you move to a new kernel, your processes will not break. And then there are the other people, the people like me. How many kernel developers are in the audience? There's probably not... There's one. There's one there. That's okay. I'm sure there are others with the lights I can't see. Kernel people are strange people sometimes. You need to have a certain kind of detail-orientated person who really wants to know exactly how the machine works and really wants to control every single detail of that piece of hardware in front of you. And it's a rare breed, but one of the things about being on the Internet is even if you're a rare breed and you have a very specific interest, when there are 3 billion people with Internet access in the world, even a rare breed ends up being many thousands of people. And that's, I think, the real strength of open source and the Internet is that it allows us to get all those strange people who like tinkering with hardware together and make a product. But it's interesting what you say. So this idea of engineering excellence, of truly understanding the details of the code versus what I somewhat derogatorily call click-and-drag programming of people just throwing together big blocks, not knowing what they do, isn't there a danger in that? Shouldn't we want to understand the code that we actually run? I think that was a derogatory remark towards the click-and-drag people. People are different, right? And I'll be very upfront. I don't understand all of the kernel either. Kernel is roughly 30 million lines of code or something like that. And honestly, no single person understands every line. This is why we all specialize. And some specialize in maintaining kernel code. Others specialize in doing UIs. I cannot do user interface to save my life. And that's okay. And again, this is one of the things that Open Source allows you to do, is we all have things we're interested in, whether they are making pretty interfaces or whether they are tinkering with the small details of the hardware. And I don't think there's us versus them, right? Although sometimes we do end up having fights about how things should be done. So you mentioned security as one of the big things in RC6 with fixes for the ASAC problem. But if I look bigger picture at the IT infrastructure, where is the major focus for security? Is it the kernel? Is it in user space? Where do we need to focus? So I'm of the opinion that when it comes to security, you should not focus because it's everywhere. I mean, over the last two years in particular, we've seen in kernel land very painfully how sometimes the focus is not on software at all. It's on the hardware. And the way to have a secure system is not to even believe that you have one entirely impenetrable wall between you and this evil world. You need to have secure hardware. You need to have secure kernels. You need to have secure libraries. You need to have secure software at every stage because everybody makes mistakes. Whether you're making hardware, whether you're making operating systems, whether you're making applications, there will be bugs. And the true path to security is to have multiple layers of security where even if one layer gets compromised, we then have another layer that picks up that problem. So in the kernel we obviously take... we end up being some of the more security-conscious projects because if the kernel has a security problem, it's a problem for everybody. So we do take it maybe more seriously than some other projects, but I do think that everybody needs to always keep security in mind regardless of what you do. You mentioned hardware and the surprises that hardware maybe isn't as secure. The other thing that has happened in the last few years is that we've clearly seen the end of Moore's Law. We've seen the end of the doubling of performance every 18 months. And so you have always been very performance-conscious in the way you look at software and the way you develop the Linux kernel. Is this something that will be more important up and down the stack in the future in order to be able to write more complex software in a stagnating performance environment? So I think it's going to be interesting. I've been saying this for the last five years already, that I actually think that when hardware performance stagnates, that's going to put pressure on a lot of software people to improve in performance in ways they have not had pressure before. And it hasn't maybe quite hit a wall yet, but I do think that it's going to be very healthy for the software ecosystem to no longer be able to depend on hardware improving. And hardware is not just CPUs, it's obviously every piece of the hardware spectrum, including networking and I.O. And for a project like the kernel where performance has always been one of the primary goals, I don't think will be taken by surprise, but I suspect some other projects may have gotten a bit used to the fact that they can keep growing their code every year and the hardware will improve to the point where nobody cares. I think it's going to be interesting. I think it's going to be a shock to some projects. Are there learnings from the kernel that these other projects, I mean, Kubernetes, the whole cloud-native world, can take from the kernel? I'm not sure how much the kernel development model really translates to other projects. We've had a somewhat different approach to maintenance that a lot of other projects have had, and we've had a more unified picture of where we want to go maybe than some other projects. One of the things I would like to be a teaching moment for other projects, actually two things. One is don't break your users. This has been a mantra for the kernel for a long, long time, and it's something that a lot of other projects seem to not have learned. In order for a project to really flourish in the long term, you want to not have your users worry about upgrades and worry about new versions, and you want to make them aware of the fact that you are a stable platform. And that's true of whatever you do, but so many projects forget about that. And the other kind of important message I will have is Kubernetes is a fairly young project. We've been doing the kernel now for... I've been doing it for 28 years. I know some in the audience have been doing it for more than 20. In order to have that kind of long life, you really want to create a community and have a kind of common culture. Not necessarily a language, because people work together even across language barriers, but having a common goal is important in order to work together for a long term. And the goal cannot be something very specific because that goal needs to change. So what we in the kernel community kind of have is a culture of not what we aim for, but what kind of things we aim for. So those two things I would like to spread further outside the kernel because that's something I've seen other projects have issues with. I want to shift gears a little bit and talk to you about a more generic question. So if you look across the different domains, so enterprise, embedded, desktop in the work world, consumers, gaming, what do you think are the important, the relevant platforms from hardware perspective and OSs from a software perspective? So where is, Jim said wherever Linux goes, Linux wins? I think it's a little more differentiated than that. Can you rephrase that question? Absolutely. So when you look at, say, the enterprise space, we've seen Linux on x86 was the huge leader. When you look at something like the desktop, especially consumers and gaming, I think it's other platforms and other OSs who are leading. And I wanted to get a feeling where you think this is going. So the reason I maybe have problems with that question is that's not the kind of question I end up, that's not the kind of question I worry about. When I think about Linux and where I want Linux to go, I worry about the technology. I don't care so much about what the market is and who is going to win. I'm not in it for winning. I'm in it to do the best technology I can. And I think that if you do the best technology, you often will do well. You will not always win. We've seen that in a lot of areas of technology. Being first is more important than being best because if you get a huge community around yourself, you have already won. But at the same time, I don't care. So when you ask me that question, I'm like, that is not relevant to what I want to do in my world. What I want to do is, regardless of the platform, we'll do the best we can. And I think most of the time, it means we win. And I guess that was the answer I was looking for. But you are a gamer. You like VR games? I'm not a gamer. Trust me on this one. You don't want me to see me gaming. Unfortunately, I don't have a video to show that. But is that something where as a platform, you think open source is going to be relevant? I think it is, actually. When you look at one of the big things about open source is you can do new and exciting things. And what Dirk is alluding to when he says a gamer, I'm a fat person. And what I've tried to do for the last couple of months to kind of not be as fat, I played a game called Beat Saber. I don't know if anybody here knows about it. Where you just swing your arms around in rhythm games. And I've actually been doing it also on an Oculus Quest. And it's a self-sufficient VR environment. And it's actually running Linux. And the reason it's running Linux is when you do a new technology, you care about your goals and you want to take as much existing infrastructure as possible to make it easy to get to your goals. And Linux has obviously been a huge part of that in almost every setting. So the only places where Linux isn't completely taking over tends to be places where there was a very strong established market already and you had an established code base. If you do something new and exciting and interesting, you will almost inevitably use Linux as the base. And that includes new platforms for gaming. And that was really where I was trying to go with this. Because in so many of these spaces, there are perceived established proprietary winners that you assume will just continue to rule the world. If you had asked someone in 2002 who would be the smartphone platform number one, they would have said Windows Mobile. And maybe that didn't work out quite that well. So one of the things I always try to do is I always try to make you make predictions about the future. It's, I know, your favorite thing. You already hedged your bet saying you never look more than six months into the future. So I'll make it easy for you. 2021, 30 years of Linux. It'll be a big party. I'm looking forward to it. I hope it will be somewhere where we can dive, Jim, if you're listening. What do we expect for Linux for the second 30 years? Will it continue just as today? Or where do you think we're going? So I actually don't think technology moves that rapidly. I mean, realistically, if you look at what Linux does today, it's not that different from what operating systems did 50 years ago. 60 years ago. What has changed is the hardware. The hardware has changed enormously. The use has changed enormously. Linux is right in between those two things. What an operating system fundamentally does is it acts as a resource manager and as the interface between software and hardware. And I don't know what software and hardware will look like in 30 years, but I do know we'll still have an operating system that acts as that resource manager and interface between software and hardware. And I do believe it will probably be called Linux, right? Because that's one of the other things about open source. Once you have this incredible platform, this base, why would you then go and try to rewrite everything when you already have access to it? I may not be around in 30 years. I will be around in 2021 for the 30-year anniversary. And here I was hoping to invite you to the reunion in 2051 to talk about 60 years of Linux. We are out of time. Thank you very much. I hope this was fun.