 Good morning. There will be about 450 videos of this event, I believe. That's pretty impressive. I hope you're not all live streaming because they will kill the internet here. So my name is Dirk Hoondl. I'm VMware's chief open source officer. And I'm Linus and I hate giving speeches, which is why over the last few years what we've done is basically do these chats where I don't have to prepare slides and I don't have to prepare a talk. And instead, we try to make it more dynamic with an interview style event. So Beijing, Linus, this is your second time here? This is my first time in Beijing. I was in Tianjin five years ago for three days. And after this, I will have a total of four days in China. So this is, I think, my 15th or 16th visit in Beijing. I love the place. Maybe not the air quality, but everything else. I have a lot of personal history with China, but I enjoy coming here a lot. Let's talk a little bit about this Linux thing. You released 4.12 RC6 last night at a very unusual time. So can you talk a little bit about this? Where are we? There is the security thing that I've heard about. So yeah, usually I release my RC kernels every week on a Sunday afternoon because it turns out that normal people work during the weekdays and then they send me their work, usually Thursday, Friday, sometimes Saturday morning. So Sunday is when I release the weekly progress. And this time I was traveling, which was part of why it got released on Monday evening instead. But we also had a very annoying security issue really in user land that we had a kernel patch for. And security issues are always interesting. We take them very seriously, but sometimes the process is very annoying and you have embargo set. And this time the embargo was set for 3pm in Europe, which meant that my release of the kernel workaround for this user space security issue happened at basically midnight China time. So that made my normal release schedule of trying to do it on a nice, calm Sunday afternoon. Now I had to do it basically in the middle of the night on a Monday evening after the dinner here at the hotel. So sometimes you have to kind of work with external issues and time your releases with them too. But other than that, so what's interesting, what are the highlights in 412? The highlight for me, I don't actually, I don't know how many of you realize, I don't code myself very much. I send out code snippets in email to developers and say maybe do it this way, but my job is really integrating work from sub-maintainers who then integrate work from thousands of developers. There's hopefully quite a few of you in the audience right now. So for me, the big issue tends to not be the code details but the flow and how well the whole process works. And I think what I'm personally particularly happy about is that it has worked so well, not just for 4.12, but we seem to have found a code flow and a process that works and has worked for a decade now where we can make incremental releases and we can actually have a very stable release schedule and things just continue to work and we seldom have these big panic issues. And I mean, if the biggest inconvenience for workflow is that I have to wait until Monday night instead of Sunday afternoon, that's a sign of a release schedule that works really well, I think. But so from the feature side, nothing you wanna highlight? We always have new hardware. We always have architecture support for new chip versions. We always have, what I find interesting is that code that I thought was stable continually gets improved. Code that is really legacy code that I would have thought, hey, we wrote that 10, 15 years ago and we haven't needed to touch it for many years. And then suddenly somebody comes along and says, hey, I really care about this code and starts improving on it or starts making bug reports on something that I thought nobody actually ever used. So one of the things I found interesting in 4.12 that nobody else should care about is that we've had a lot of fixes to the UFS file system. That's the traditional UNIX file system that the BSD people use and that Linux people tend to never, ever use. And for some reason some random, excuse me, some random person started using UFS. I think maybe he's migrating for BSD, maybe he just wants to run them at the same time. And as a reason this file system that I thought was basically done has been seeing a surprising amount of changes. So I find it interesting that we do have new hardware, new features, new things that we get developed. But even after 25 years, we also have these old very basic things that people still care about and still improve. So I have a little quiz for you. What do these things have in common? Terminator 2, Judgment Day, the Silence of the Lambs, Brian Adams, everything I do, I do it for you, and Madonna, Justify My Love. And I'm not gonna sing. Have you been taking a medication lately? So these are the top two movies and top two songs of 1991 and the fact that no one in the audience knows the songs or the movies makes this even more funny. So you have been doing the exact same job since these cultural highlights were created. Have you considered taking a sabbatical? Not really. So I really like what I'm doing. I like waking up and having a job that is technically interesting and just challenging while not being too stressful. So I can do it for long stretches. You don't want to have the job where you think you're burning out. But at the same time, also something that I feel like I make in a real difference and I do something that is meaningful, just not just for me. And I think everybody, I hope everybody in the audience really would like to have that kind of job where they can do it because it's interesting and because they like it, but also because it matters outside your own little sphere. And I've occasionally taken breaks from it. Jim mentioned the two or three weeks I was working on Git to get that whole project started. But every time I take a longer break, I get bored. So I mean, even when I go diving, which is my only real hobby, and I might be away for a week, I actually look forward to getting back to doing Linux. I don't look forward to the thousand emails waiting for me, but I look forward to the job. So I mean, if that ever changes, maybe I'll need to find somebody, some sucker to take over my job. But I've never had the feeling that, okay, now I need to take a longer break. So I'll talk about this a little more. And I look at this from the perspective of sustainability. So is the development model that we have sustainable? It certainly is in the sense that you just said you love what you do, and you think the process that we've arrived at is fantastic. But if I look at this 20 years from now, if I look at this really long term, is there anything in that question of how we as a community can continue to be this successful that you are worried about? Not really. I used to get the question, what happens if I get hit by a bus? And I don't actually get that question anymore because our process not only has worked for 25 years now. I mean, it's changed over the years, but still. But we have a very strong maintainer group. I mean, we have, we complain about the fact that we don't have enough maintainers, and it's true. We only have a set of a few tens of really top maintainers that do the daily work of merging most stuff. But at the same time, for an open source project, a few tens of really top technical lead people is a very strong team. And at the same time, as we have these maintainers that are getting older and fatter, we also continually have new people coming in. I mean, it takes years to go from being a new developer to being a top maintainer, but it still happens. And there are lots of new people coming in. So I don't feel like we should necessarily worry about the process and Linux for the next 20 years. I mean, who knows? Maybe some new and aggressive project comes along and shows that they can do what we do better, but that doesn't look very likely either. So I don't worry about that. We've had situations where we needed to change how we work and they are very, very painful. And if we hit that again, I mean, we had to do a change, it's over 10 years now. And it was acrimonious and there was a lot of stress involved when you change how you work. If we have to do that again, now that we're so much bigger, that's going to be very painful, but so far we've been scaling very smoothly. One of the things that I find fascinating about Linux is that there has never been a successful fork. There has never been a challenge to your leadership. Why do you think that is? I actually disagree to some degree. I think there's been lots of very successful forks and one of the things that made them, makes people not think of them as forks is that they weren't acrimonious. I've always said that if somebody has a new feature that I don't believe in, it happens all the time. People say, I want to do this and it's going to change everything and it's going to make the kernel so much better. And my feeling was always, hey, go ahead, do it, prove yourself. I think it's a bad idea, but you can prove me wrong. And that has actually been fairly different in the kernel from a lot of other projects. And I literally designed, I mean, when I sat down and wrote Git, one of the prime design rules was that the whole, you're supposed to be able to fork and it should be really easy to go off on your own and do something on your own. And the thing is if you have these kinds of forks that are friendly and are on the type where, hey, prove me wrong, show that you are really doing something new, really doing something interesting, doing something that really improves the kernel. If you're in that situation, then when the person who may, or the company who made the improvement, comes back and say, hey, look, I actually improved the kernel, there's no bad feelings. There's like, okay, I was wrong. I will take your much improved code and we'll merge it back. And I think that's the big deal that you actually want to encourage forks. You want to encourage these forks that happen all the time when people do development. But you also want to make it easy to take back the good ones. And the fact is you don't see a lot of the forks because most of the time I'm right and most of the forks are bad and they never go anywhere. But when I'm wrong, I'm like, wow, good job, I'll take the credit for your work now. So that's how pretty much all development gets done. But I think you said you disagree but then you proved my point. Because it is about the leadership. It is about the approach of saying, go as hell, prove yourself and I'll take it if it's successful. And to me that is the secret of the fact that there isn't a differently named Linux clone with a different leader. And that was my point. But you made a very interesting comment here about the role that Git plays in this. And I have a somewhat controversial question for you. Linux obviously had a huge impact. But if I think about the transformational nature of Git and what it has done to software development, not just in open source, but I mean companies like Microsoft or VMware use Git for software development internally. So do you think that Git maybe had a huge, a larger impact than Linux in that sense? I'm actually very surprised about how widely Git has spread. I'm pleased, obviously. And I feel like it validates my notion of doing distributed development. At the same time, just looking back at most source control versions, it tends to be a huge slog. And it tends to be really hard to introduce a new software control system. And I expected Git to really be limited mostly to the kernel because it was tailored for what we needed to do. And I don't know how many of you actually have followed Git, but for the first three, four years, one of the main complaints about Git was that it was so different and it was so hard to use because people were used to the CVS model or the subversion model or there's a ton of these commercial source control management systems that people also used. And Git was very different and Git took a different kind of mindset to get used to. And then about five years ago, something changed. And I think it was just that enough projects and enough developers had started using Git and suddenly Git wasn't different anymore just because now Git was what they were used to. And people really started taking advantage of the development model and of the just security and the feeling of security that when you have something in Git, it will not get corrupted. I mean, using strong hashes and making sure that we actually track everything and we never lose data. So it was kind of interesting to see how the project that I thought was kernel-specific really spread very widely. And when my daughter went off to college, my oldest daughter went off to college, like a month or two later, she sent me an email back and said she found it hugely amusing that she was known as the daughter of the person who created Git, not as the daughter of the person who created Linux because they all used Git inside of Duke. And some of them used Linux too, but Git was very widely known among the computer science students. And I always also found that interesting because to me, Git was this short, I actually ended up maintaining it only for about three, maybe four months. And for the last 10 plus years, Git has been maintained by Junior Hamano, who's done an outstanding job and should really get all the credit for how well Git works. But despite that, in certain circles, Git is the more well-known one and the one you actually interact with daily. And it's probably because quite often Linux is hidden. If you have an Android phone, you are running Linux, but you don't think of it as Linux. But if you're running Git, you are very aware of the fact that you're running Git. So sometimes it's a perception issue too. So outside of Git and Linux, what other open source projects? OK, you're fishing now. No, no, I'm not talking about subsurface. Outside of the projects that you started, let's phrase it this way, what other open source projects do you spend time on? Surprisingly few. I used to be, I've always been interested in low-level details. So I used to be mostly, I mean, this is why, obviously, I do a kernel, but I used to be very into compilers and editors and things like that, like low-level programming tools that are not really user-focused. And maybe it's just because I'm a fairly focused kind of person. I don't like being distracted by different things. I prefer to concentrate on one project. So all my time is spent on Linux. And there's almost no time to look at other open source projects outside of that. We sometimes have incidental issues, like we find compiler bugs. But then it's still my Linux work that is involved. And then the fact that I talk to other open source projects because we have issues with them or they have issues with us is still related to Linux for me. So we talked about this earlier. The world has changed dramatically in the last 26 years. If you were starting today, what do you think you'd be working on? One of the things I find interesting and that I probably would have been really excited about when I was a teenager and then early 20s when I started Linux is you can tinker with hardware so much more easily than you could when I was growing up. And I was dangerous with hardware. I would try to build things and I would destroy computers because I was not very good at it, but I always found it very interesting. And now getting involved with FPGAs, if you're actually interested in chip design, it used to be expensive to get involved. Now you can get an FBA development board and free tools to play around with it for reasonably low cost. All these Raspberry Pi, random small things that you can build up with yourself, I think that's something that I would really have enjoyed. And if I was starting out now, that's probably where I would be looking. But let's look at the audience. If you were a young Chinese developer and you wanted to use open source as a way to build your career, what do you think? Where should they look? What is Linux's advice to success? I get the question, what should I do quite often? And I have a really hard time answering it. Partly it's because for me it was always I was very self-motivated. I pretty much always knew what I wanted to do. And the question feels kind of odd to me. It's like I was never told what I should look at doing. And I'm not sure my example is necessarily the right thing to follow. There's a ton of open source projects. And if you're a programmer or you are a beginning programmer and just want to further your career, find something that you're interested in and find something that you think you can actually follow for more than just a few weeks. Find something where you can get to know the code well. I mean, you can spend enough time and effort that you get to know the code so that you get to the point where you are an expert on that code piece. It doesn't have to be the whole project. Like for the kernel, nobody. And I mean really nobody, not me. Nobody is an expert on the whole kernel. Everybody has areas that they know well enough that they can be an expert on that. And once you're in that situation where you know a small project or a part of a bigger project and you can really be part of the community and send out patches, it's not just about the coding. It's a lot of this is about the social aspect of open source. You get connections. You are improving yourself as a programmer, but you also are showing, you're basically showing off. You're showing the world, hey, look, I made these improvements. I am competent. I am worthy of going far in my community, in my job. And the showing off part of open source is actually to a large degree why I released Linux originally as open source. It was like I do programming because I think it's fun and it's challenging and it's basically the best mental gymnastics you can do in the modern world, I think. But then I released it because I wanted to just show people, look, this is what I worked on for six months. It's not big yet, but it's doing something interesting. And in fact, the social commentary and the fact that we grew a community around it came as a surprise to me and it was a very pleasant surprise. It is why I still do Linux 25 plus years later. The technology is still interesting and our problems have evolved and we still do new things. But at the same time, the thing I really enjoy about open source is the interaction with people. They're not all friendly. We have a lot of bickering. We have a lot of arguments about the right way to do things and things like that. But I actually think that's also part of what makes it interesting. So find something you're interested in, get involved. You will first have to spend a certain amount of time to learn the project, but there's a huge upside, not just from a career standpoint, but also from a satisfying project in your life. I think you're giving an amazing answer to this question because that is exactly what I think matters. Find something that you're interested in, that you want to do and then keep doing it. Stay with it. There's one other aspect when talking to an audience here in Asia. I think English skills, the ability to express yourself in English, if you want to be successful in the global project, are quite important too. And I want to use this to thank our wonderful translator who has been diligently trying to keep track with us and please give a round of applause to our translator who helped us here. And I think on that, we'll have to stop. We're out of time. Thank you very much for your attention. I hope this was interesting and fun for you. And I hope we'll see you next year. Thank you. Thank you.