 I'm very excited to start with our our first session. We'll be a fireside chat with Greg Corhartman, so I'd like to welcome him to the stage right now. Yeah, while he's taken the long walk over there, I'll introduce Greg. He kind of seems like he needs no introduction. He's been around the Kernel community for forever, basically. He's a fellow at the Linux Foundation. He's been a USB maintainer and well maintainer of all kinds of stuff. We can we can talk more about that, but we're going to just have a little bit of a fireside chat. Towards the end, if we have some time, I would like to open it up for questions and there's going to be a mic somewhere, but we'll get to that. So let's go ahead and have a little chat. Where's the fire? Where's the warm fire? Or the background? I mean, was it last week or Lenaro Connect? They had a little fire rolling in the back. Oh, did they? Oh. Yeah, it's a Netflix screen. So actually, so I lied, this is not a fireside chat at all. This is just a chat. So I saw, and the intent of this is just to be kind of a casual casual thing, hopefully get some information from you as if we were just chatting in the hallway. I saw that you did a talk at Kernel Recipes and it was not your standard talk. It was technical. Well, it was, but it was all there was a, I don't know. I'd say that. Well, okay, let me say what it was. Tell me what tell us about the talk you gave at Kernel Recipes. I gave two talks. Okay. The technical one was the Linux driver model, what it looks like, why you should never care about it, what's all broken with it, things like that. And then the second one was, what was the title? Stone. Oh, email on carved stone tablet. Yeah, something like that. Patches carved on the stone tablets. Why email still works, why these old technologies is why the Linux kernel uses and what is so wrong with things like specifically Garrett. Okay. I can't leave that alone. So, and I know I think you even said this in your talk notes. So doesn't the reliance on dusty old email, doesn't that just make us look like a bunch of old gray beards, you know, like get off my lawn type. So why, you know, it's 2016. I mean, come on, Greg, email. That's our patch review system. Can we do better? Give me the 30 second pitch. 30 second pitches, there's nothing else better. There's nothing else faster, there's nothing else more in use by the whole world. Email, plain text works great for people who can't use GUIs, have intermittent email access to the internet. English is not their first language and connectivity issues again. And for review, I mean, as proof in the talk before mine, I reviewed 53 patches and accepted 13 of them in 15 minutes and Garrett, there's no way. Okay. So speed and ubiquity. Speed and ubiquity, it's the best thing. And it's everybody has email. Email is also free. There's free providers. So it's the lowest bar of entry and it works best. But you can put on top of email, you can put really good tools up. I recommend patchwork. Patchwork is awesome. So a lot of, I mean, David Miller, who does almost as many patches review as me, uses patchwork. Patchwork also can tie into the back end of continuous integration and testing and other fun things like that, which people use Garrett for. Okay. Well, that sounds pretty good. Speaking of the age thing, this question gets asked a lot and I think it will probably continue to get asked. Are kernel developers too old? If you look at the list for the kernel summit, well, I don't know. Have you seen the list for the kernel summit? I'm on the committee. Yes. I don't know how old everybody is. Yes, we are getting old. But it's better than the alternative, right? Yes. It beats the alternative. So, I mean, age is a dual factor here. I mean, one thing you can say, I mean, I'll point on David Miller again, you have somebody who's been doing networking for 20 some years maintaining the network stack. That's knowledge. That's depth. That's information there. I've been maintaining USBs since the 1990s. Something like that. I mean, I know USB for a long time. I mean, the joke was Microsoft when USB 3 came out that a big article about how they've put a whole brand new team on it and they're reintegrating everything and writing a whole new stack. And we had one developer who was really good, Sarah Sharp, implement USB 3 for us and half the time they did. So, knowledge is good. History is good. But we also get new developers. I mean, Jonathan Corbett shows that we get 200 brand new developers every kernel release. And age isn't there. Outreach has students coming from universities. I have a Google summer of code student every year. We have universities. I work with lots of universities. I'm working with the university right now. We have students streaming out of the schools doing Linux work. Interns are getting hired by companies to do Linux work. But the fun thing is there are students, somebody at Facebook now, realize that he's hiring interns that were born before or after Linux started. Yes. Okay. That's sobering. I think I heard this from James Bottomley. He said something, though, about old people tend to value experience more than young people. Maybe that's obvious. But is there a bias, you think, in the community towards, I mean, like maintainer positions? Maintainer positions don't come open very often, right? We have empties. We have subsystems that nobody maintains, still. Well, yeah. But they're crummy subsystems. I'm sure they're good subsystems. So, I'll point out, I mean, I look at, we had a something parallel port. People still use parallel ports. Parallel port has had not had a maintainer for 12, 13 years. A new developer started, said, what do I want to work? I'm like, hey, convert the parallel port to the driver model, something nobody want to do. He did it and got a job. Oh, hey. There you go. And so, I mean, we have subsystems that are not maintained. We have loads of subsystems. We have file systems. People are adopting old file systems, finally maintaining and fixing, cleaning them up. We have tons and tons of work, if people want to do that. So, youthful ignorance and blind ambition is great. I was there. So, we need that too. Maybe you have to be youthful to decide to agree to be a maintainer. Yeah. You have to have a little bit more optimism than you should. So, you have been, speaking of your talk, okay, you said the first technical talk for a while. I know, I talked to you about this in Japan. You have given the same kernel talk a lot. But you shared with me something your wife said. I don't know if you remember. You want to share that? So, I gave a kernel talk on how we do the kernel, how the development process works and things like that. It's been 15 years now, I think. I was at a company once and somebody said, I was giving the talk and they, afterwards they elbowed me and pointed, look, here's the slides. 10 years ago, you gave to me at a different company. It's the same talk. And it is the same talk. But I'd update the numbers and I'd develop it and everything. But like my wife said, she said it's, there's always a new class of kindergarteners every year. I prefer to say freshman. But we have high school students working on the kernel. So, yeah. But I mean, there's always new people, our community, again, 200 new developers every three months. That's huge. So, we have people coming in. Yeah. And it's not, I mean, we're not just talking about young people, people who switch from other industries, right? There's a whole, there's a learning curve, no matter where you're coming from. Oh yeah. I mean, if you look at Seattle, so that's where I used to live. I mean, Seattle is filled with X Microsoft developers working on Linux right now. Amazon, Facebook, Google, Valve, all X Microsoft developers contributing to Linux, which is great. We want those engineers. We want those people. And they're doing really good stuff there. Good stuff. So, I know that you travel a lot. How many, this is just kind of a personal question. How many miles are you putting in planes a year? How many events do you get to? I do them all. I think I'll hit 100K. I don't know if I'll hit 100K this year. I haven't been traveling as much as I have in the past. Oh, wow. So, I don't know. That's actually surprising to me. Yeah. I know you're at everything. I mean, yeah. So, yeah, last year over 140, I think, 1000 miles. Okay. Yeah. It's good for the frequent fliers. Not so good for the family life, right? Speaking of family life, I heard that you just recently moved. So, tell me about that. I now live in Paris, France. We moved from Seattle. Why? Yes. Wow. You're making my job easy. So, I will give the glib answer of why not. I mean, the food and wine is good. My daughter thinks I'm having a midlife crisis. Then I claim, well, you're along the coattails of it. She worked LinuxCon last week. She's along with us. So, the whole family. I worked with the university there last year for three months. Julia Lurell and Lipsix and the Whisper Research Group there at the university, Pierre Marie Curie University. Really good research and operating systems and system design that is applicable to the real world, which is odd for academia. So, I did a three-month thing there last year, and now they want researchers and people. So, I'm working with them on some fun stuff. Okay. Oh, good. Okay. So, that's kind of an adventure for the family, though. That's pretty so kids like an editor. My son's in school and my daughter graduated college, so she's being a 19-year-old in Paris. What can go wrong? Okay. So, I would be remiss if I didn't bring up the topic. There was a healthy discussion on the Colonel Summit mailing list on the topic of licenses, and how can I describe it? You're going to let me go here? I'm going to let you go. Well, as much as you want. There are some interesting points raised. Do you want to describe the discussion? I think you probably remember it. Yes. So, the discussion came up about GPL enforcement and what to do about that, and people's statements saying, making the claim that if we don't enforce the GPL, it's the same as the BSD license, and I called bullshit on that, because that's not true. That's flat out false. And what we're seeing these days, I mean, yes, people violate our license. That always happens. It's gotten better. I don't know if anybody remembers the 1990s when people were shipping closed source Ethernet drivers, SCSI drivers, controller drivers, everything. It was crazy. We are a lot, lot better. One of the biggest violators of the GPL used to be Intel, and now there are biggest supporter on more ways than one. Financial code, contributions, everything else. And that happened due to us working with them. And so my main point about GPL compliance is everybody owns their copyrights. You're free to do however you wish with those copyrights and enforcing them and getting the code, but use your judgment. The judgment should be not necessarily you have to get the code, because if you go into a company with lawyers knocking on the front door, you're going to get, the walls are going to come down, and you're going to alienate everybody in that company that was using Linux. Because inside every company, when you start using Linux, you have two camps. One is like, oh, those hippies and punks. We can't use this crazy stuff. And then you convince them and you finally get that. And if one of those people, those crazy hippies and punks shows up the front door with a lawyer, boom, you prove them right. You were wrong. Doors come down. Everything works bad. But if, as a developer, you go to that same company and contact the developers in there and say, hey, why don't you get, what can I do to help you get your code merged into the kernel? And that's a totally different way of working with them. That says, hey, the community is willing to work with you, willing to invest their time with you, willing to make your product better, and that's the best way to work forward. We have seen it time and time again that when you go in with lawyers or representatives of the developers and not the developers themselves, the walls come down, all contact gets shut off. I'm working with a silicon company today that has been shipping Linux on their product for eight, nine years. No code has ever come out of them. The developers side, the company reached out. I met some of them and they're saying, help us. I'm like, okay, great. We'll work with you. And the thing is, the code from this company is usually almost always is crap. We don't want that code. We really don't. I mean, you want to get that one device working, but you really want is that company and those developers in that company to become part of our community and label us to grow? Because the only way we're going to survive is if we continue to grow and continue to bring more people in, we're going to age out. We pass away. We move on to other things. We need more people in our community in order to survive. So you work with that company. You make them reliant on Linux. You make them realize that working with the community actually saves them time and money, which has been proven over and over and over. And then they're now reliant so much on Linux that they have to invest. They're part of the community. They rely on it. And it works. Look at all the sponsors and look at all the people who've been contributing to Linux over time. Again, I'll point out as Intel is the perfect poster child for this. They now do everything on Linux and they used to be our worst violator. It can happen. Things can change and we're in for the long haul. We don't want just the instant code dump. We want you to work together and become part of our community. So, Linus said something in that exchange that actually I found really interesting. And that was that you want the corporate lawyers acting on behalf of the community instead of against the community. And that was like a really different insight, I thought. That it's like, you know, I hadn't thought about that. There's always been kind of a, it's terrible, but there is kind of an us versus them mentality and it's like companies need to realize us is them as well. Yes. I mean, I used to joke at, I used to not joke at Red Hat or when I worked at SUSE that Red Hat was SUSE's engineering department. And make the companies realize that the other companies are part of their own development process and they need to work on it. And lawyers as well. When you get the company on board, they're enforcing their license, they're producing the code properly. They turn to their partner companies and say, why aren't you doing the same thing? Do you want to get visited by IBM and Intel's lawyers? No. They are the largest copyright holders in the kernel. I mean, come on, you don't want that. And they have done that. Look, I mean, Microsoft. Microsoft is now an active contributor to us. They produce code and I got that code by knocking on the door nicely with the developers and saying, hey, I see you have some kernel code over here. Need some help? And that was actually a test, a proven case. Their initial code dump was 12,000 lines of crap. We added to the kernel to the staging directory. It took about a year to clean up. It finally got merged out of the staging directory. It was only 7,000 and it supported four new types of devices. So we showed them that, hey, if you work with us, make your code smaller, your stuff runs better and your customers are happier because more devices were supported. And now, look, they have a, I mean, when is in charge of their Linux division? Did anybody ever think that would happen? We have Stephen Heminger works for them. Linux division at Microsoft. Yes, Matthew Wilcox, KY. I mean, we got a lot of really, really talented people there. And they're using Linux internally because their customers want it and because people need it. So speaking of compliance, okay. So there are, I mean, there are companies who are not complying. So what is, what is one thing, you know, not pressing upon people legally, but when you approach companies about, participate about mainlining their code and stuff, what is one thing you'd like to see kind of improve in general? I mean, what could companies be doing better in terms of compliance? Is there any kind of major thing that a lot of companies are missing that they could do better? Well, lots of companies comply properly. I mean, the majority, the huge majority do. I mean, so that even by, even by complying, I mean, I will pick on Amazon as somebody who perfectly complies with the license is great, but they, all they do is throw this random tar ball on this random website. It's the old source forge that's buried somewhere, crap. And that's not a good, it's cost them money. It's a pain for us. We just ignore them. They're not receiving any of the benefits of using Linux and being part of the community there. So that's the problem, just engage with us. We want to work with you. We want to help things get involved. Talk to us. Everybody knows our email addresses. I mean, based on my inbox. So, so even, even if you're still, if you're tossing stuff over the wall, even if it's just a Git repository versus a tar ball, that makes a difference, I think. Yeah, but then you look at, I mean, look at Qualcomm's 2.5 million lines of code. That is a Git repository. And that's, that's crazy. I mean, It's still impossible to mine. That's impossible to mine. And I don't think we want to mine that. And it is getting better. It's 1.5 million lines now. And it's, oh, the new chips are based on 318. Good job, guys. Oh, I think they're in the fours. I know they're not. No, the new phones have just shipped this. But the phones is, well, anyway, anyway, they're getting better. Yes, it will be four, four just in time for me to obsolete that kernel. That's the big problem we have today. We have these huge giant patch sets. I mean, I talked about this in the past. I joked 2.5 million lines, 1.5 million lines. Remember, your laptop runs 1.6 million lines of code. So these embedded devices that are running these crazy patch sets, it's Linux-like. Entire SoCs, entire graphic drivers that nobody's ever seen and touched. So last, last question before we turn it over to the audience. I hope we have a little bit of time, but do you, so we've seen this year the rise of other IoT RTOSs, right? So, Zephyr, Google announced something called, I think it was Magenta. So, do you worry that Linux is losing the battle in the low-end space or is that, is that something we should care about? The fun thing, what do we have? I mean, Formegg is great for Linux, right? Formegg is great for Linux. Two is pushing it, right? Two is tough. At LinuxCon in Toronto, some of us were drunk and we came up with ways that we think we can get into 5.12, but won't do anything. Maybe a Bluetooth backup. Well, 2Meggy are pretty much not doing anything. 2Meggy are not doing anything. So my Google summer code student this past year got Linux running up on a Cortex ARM M3. M3-0 or 3? 3, I think. And he had like, all the room in the world. So, I mean, chips, again, chips, Formegg and under, there's still a lot of them out there and there's still a need for some tools out there. NetX is a very common one. So now Zephyr is a really good alternative to NetX. Sometimes you just don't have any space and you need to use these tiny chips and stuff like that. Stripping Linux down to there would be awesome. I'd love to do that. It's a fight between chips getting bigger just every year and cheaper every year versus taking the effort to cut it down. Where do you draw the line? Sometimes, I mean, there's so many really good tiny operating systems. Just use those. Okay. Okay, we're about out of time, but I think I could take one or two questions. Anyone have a question for Greg? We've got a mic that will come over to you. There's one over here. Oh, go ahead. Just shout your question. Anything to say if the new approach, have you been involved in the bus one? I don't know how it's called. Yeah, I want to repeat the question. The question was KD bus. It was an interesting way to submit patches to the kernel. It didn't go very far. It went a long ways for a while. We've dropped it. Bus one is the alternative. People stepped back and took a lot of the review comments seriously and are implementing something that's even more generic IPC that people wanted. Bus one, there was a talk last week or the week before at the system D conference. It's also going to be talked about at the kernel summit. There's a talk about it. The code is online and it looks good. We took the review comments. That's normal part of the process. Took the review comments to heart and redid it. Okay. Unfortunately, we're out of time. I want to thank Greg. Greg is literally, I believe, one of the hardest working open source developers out there. I've never seen Greg not working. The amount of patches he reviews is just unbelievable. He takes the time to come and visit the conferences. He's had a lot of them. I just want to say thank you on behalf of the rest of the community.