FLOSS Weekly 706 Transcript

Please be advised this transcript is AI-generated and may not be word for word. Time codes refer to the approximate times in the ad-supported version of the show.

Doc Searls (00:00:00):
This is FLOSS Weekly. I'm Doc Searls. This week, Katherine Druckman and Jonathan Bennett together talk with me to one of the most important people in all of Linux, Greg Kroah-Hartman. He's an alpha maintainer of so many things inside the kernel, and he talks about, it's just a fabulous show, and it goes fast. Even if it takes an hour, it'll go faster than that because this is a great show. And that is coming up Next.

VO (00:00:31):
Podcasts you love From people you trust. This is, TWIT

Doc Searls (00:00:38):
This is FLOSS Weekly, episode 706, recorded Wednesday, November 9th, 2022. Secrets of the Linux Ker. This episode of FLOSS Weekly is brought to you by code comments, and original podcast from Red Hat that lets you listen in on two experienced technologists as they describe their building process and what they've learned from their experiences. Search for code comments in your podcast player and buy Collide. Collide is an end point security solution that gives it teams a single dashboard for all your devices, regardless of their operating system. Visit collide.com/FLOSS to learn more and activate a free 14 day trial today. No credit card required. Good morning, good evening. Good whenever it is, wherever you are. I am Doc Searles, and this is FLOSS Weekly. I am joined this week by Oath <laugh> at Katherine Druckman and Jonathan Bennett, who we pulled in here at the last minute, <laugh>, cause we've been talking so much because of his hair together. On about, about our guest, about, about Greg Kroah-Hartman, who's on the, who's on the show today. So, um, I wanna get into it, but any quick words for either of you about how, how you, how you prep for this, what, what made sense to you about it, why it's so important for you guys?

Jonathan Bennett (00:02:06):
I was gotta say, I was excited about the interview, but it was a lazy morning for me. And, uh, you know, I was kind of getting ready to run to the post office, but I hadn't done everything. And then about five minutes before the show, doc says, Hey, why don't you come on? It's like, well, I'd really have to scramble the, the camera's over here instead of over there and just, nothing's ready. I haven't done my hair or anything. And doc's like, no, no, you're on with this. Start scrambling. It's like, okay, fine. Get everything in place and sit down and look. And it's like, oh my goodness, I've got the Einstein hair going on. If you're not watching the video, you're really missing out. If you are watching the video. I'm sorry,

Doc Searls (00:02:38):
<laugh>, so people may not know who, only listen. Uh, Jonathan has serious hair. He is the hair that, that I envy I had when I was like five, you know, <laugh> was like, Catherine there. You're still in in Houston. Yeah.

Katherine Druckman (00:02:54):
Yeah. Yes, I still here. I'm very excited to talk to Greg for a lot of reasons. You know, we're gonna nerd out about the Linox Colonel, but also the three of us have Linox Journal in common, which is kind of fun. And really, I'm excited to be here because of Jonathan's hair. I've gotta be on it. <laugh> Linux.

Doc Searls (00:03:14):
So, yeah, <laugh>. Okay. Well, I, I wanna get into it. So I wanna let everybody know here that, um, our guest, Greg Kroah-Hartman, um, uh, is a fellow of the Linux Foundation. Uh, he's currently responsible for the stable Linux kernel releases and is a maintainer of the US B T T Y and driver course subsystems in the kernel, as well as other portions of the code base that he wishes he could forget about. He says he's the author of two books about Linux Colonel Development, both free online and as many as written, many papers and articles about the Linux Colonel. Um, the main thing is he's important. <laugh> Linux depends on this guy. So we is the show. Greg,

Greg Kroah-Hartman (00:04:00):
Thanks

Doc Searls (00:04:00):
For

Greg Kroah-Hartman (00:04:00):
You're, it's great to be here.

Doc Searls (00:04:02):
And, and you were in, so we are in, uh, California, Oklahoma, and, and Texas. And you're in the Netherlands. Yes. Late the day. Netlands late in the day for you. What, what, what brought you there? I've, I mean, I just an a pre-show, but,

Greg Kroah-Hartman (00:04:17):
Um, I moved to Paris a couple, six years ago, uh, to work with one of the universities there. Um, they have a really good research team, um, that do a lot of open source work, uh, really good tools and system design stuff. And, um, it was a chance to go and work with them. They, uh, um, I say one of the people there, Julia Lu, who's created some tools that we use for static analysis and security stuff, has fixed more security bugs in the kernel than anybody else because she's fixed 'em all and then prevented them from ever coming back in, which is great work. And then I was living there for a couple years and, um, my daughter got into medical school in the Netherlands and my son wanted to go to high school in one, one place for four years. And then he got into really good school in the Hague. Uh, so we were there and now we've been here ever since. And now my son's in the university in Amsterdam. So it's a

Doc Searls (00:05:05):
Good place. Well, and so did you speak any Dutch before you went there?

Greg Kroah-Hartman (00:05:09):
I did not, no. I am learning Dutch. I am doing very badly <laugh>. Um, Corona took a big hit on that cuz you didn't speak to anybody. Uh, my daughter is now fluent. My son is at a couple years. He's pretty good. Um, my wife and I are, my wife is better than me. I'm still learning. It's hard when you work from home, you don't see anybody. And 95% of the people here speak English. The second most common, let, let's see, England is the next comp country, 98%. Um, so everybody knows English. If you try and speak Dutch to somebody, they'll just switch to English cause they want to get the job done and move on. Um, so it's a little bit hard

Doc Searls (00:05:44):
<laugh> and, and, and worse, and I found this at Denmark too, I don't know why. Not in other Scandinavian countries, but in Denmark and, and in and in Netherlands is that you'll be talking to somebody and you'll think, think they're from the US and they're not, they're native Dutch people, <laugh>, but they speak per un

Greg Kroah-Hartman (00:06:04):
Or they're, uh, they're, they've learned it from British tv. We found out a lot. So there's a lot of people with heavy British accents because they learn from British tv. Uh,

Doc Searls (00:06:11):
It depends on what TV you

Greg Kroah-Hartman (00:06:12):
Watch. Yeah, it depends on what TV you watch growing up as a kid. But the Dutch actually are really good is, and I live in The Hague, which is only 40% Dutch because of all the international here. There's all the embassies for all the countries here and, um, lots of nonprofits. And so it's a really, really good multicultural area to live in. So we're happy.

Doc Searls (00:06:31):
So, so how'd you get into the Linox colonel? I mean, you've been I as long as I can remember, but I have a feeling it doesn't go all the way back. So when, where did you pick that up and why, and how do you get stuck?

Greg Kroah-Hartman (00:06:43):
<laugh>? I had been, I had used it at a job a long, long time ago when it first came out. Uh, when Oracle first worked on it. Uh, we did a, we did a system, I did embedded programming and then, uh, a couple jobs later I was doing, um, USB devices. I was writing firmware for USB barcode scanners and I had to plug my device into all different operating systems to verify it. I plugged it into Linux and it came up instead of a mouse, a keyboard just showed up as 128 key mouse. So that was my fault. Not Linnux is fault <laugh>. Um, windows handled it fine, which is funny. Um, and then I started contributing cause I saw, hey, we can contribute this, uh, I can write, write some code for this. And then my wife, um, went, took our new newborn daughter and went on vacation to visit some family for a weekend.

(00:07:26):
She said, go write that driver you've been talking about all the time. So it kinda weekend wrote a driver for a device I had and I submitted it and sent it to the mailing list. And it was like instantly it was like, oh no, this is wrong, this is wrong, this is wrong, this is wrong. And oh, have you ever heard of SMP Multiprocessors? I'm like, what <laugh>? Um, and I'm like, this is awesome. This is a great way to learn. This is a great, uh, environment. Um, technically it was wonderful and I learned so much. And then over time, more people were using those code I had written for free in the USB stack than anything that I got paid for. My company was, that worked out was okay, but they weren't doing that well. And I got a job doing Linux full time, I think in 99 or 2000. And I've been doing it full-time ever since.

Katherine Druckman (00:08:08):
So speaking of that, um, and we're gonna ask some really juicy, nerdy questions pretty soon, but, but I have this kind of burning one and, and it's, um, I wonder, you know, remember back to those days when you first started working with Linux and back when you were writing for Lennox Journal I mentioned earlier. Yeah. Um, and we were still convincing the world that Linux and open source was viable and legitimate. Um, and now the entire world and and beyond our world, uh, depends on Linux. Do you ever just pause for a sec and let that kind of blow your mind? And, and how do you deal with the pressure of that, as Doc mentioned in the, in the beginning, this is, you're, you're very important now. How does that work?

Greg Kroah-Hartman (00:08:45):
It's totally scary. I mean, we used to joke, total world domination is our goal, but it wasn't really a joke. <laugh>. Um, it's kind of funny. I mean, about the decade ago we kind of realized we were, we beat everybody else. Um, about 10, 15 years ago, we had implemented everything else everybody else had done. In fact, we implemented stuff that people had never done. We were just implementing stuff off of marketing bulletins. And there's a fun story about that. But, um, so we were way ahead of everybody else. So then I had, I had even talked to Microsoft and Apple and they're like, yeah, we're never gonna catch up. Have fun. Um, so it's just, it's actually hard coming up with new things. It's easy to copy stuff. Um, but yeah, it's kind of weird. Um, but yeah, we're everywhere. We're like in my washing machine or, um, all over the house everywhere. All over the house. Um, all

Katherine Druckman (00:09:35):
Over is crazy off of the planet as well, right?

Greg Kroah-Hartman (00:09:37):
Yeah. Uh, phones, I mean, Android phones was at four or 5 billion devices. Linux on servers is a rounding error compared to Android. So <laugh>, it's like everybody forgets that. So, um, yeah, we're, we took over pretty much every market. I keep joking, what's the next market we need to take over? Um, we just took over medical pretty much. I think we're, I think that's pretty much in the bag. Um, but after that, yeah. What, let's see, what else is next? I mean, telco was the first big one that put us on the map and it was like, okay, this is, this is real. We can actually, Linux can be used for real things and we went from there.

Katherine Druckman (00:10:12):
Yeah. I feel like I increasingly though I feel like I, I find myself a answering that question again. And I wonder if that's your experience too, or like, did, didn't we have this conversation 15 years ago? And yet again, I think maybe because of some recent security concerns or something, um, I, I find people asking the questioning and being skeptical about open source and, uh, you know, I hear the problem with open source or, um, you know, something like that. Or there's still this misperception that, uh, open source is for hobbyists and, and ends up with abandoned repos. Do you, do you get that a little bit or are you still very much in your open source bubble? I feel like I am, but every time I leave it, I, I run into these questions and I, it always, I get a little deja vu.

Greg Kroah-Hartman (00:10:57):
Yeah. At stage vu, it's there. I mean, I used to joke we needed a marketing department and then we got one with the Linux Foundation and that's pretty much went away. Um, but I mean, all Linux is, is a tool that other people can use to solve their problem, right? Nobody's forcing you to use Linux. So people are picking up and using Linux because it solves a problem for them. And we're creating Linux and we're contributing to Linux cuz this solves a problem for us. So, I mean, from a technical point of view, this is pretty, um, we're not pushing anybody to do anything. We're not forcing anybody to do anything. So they're choosing it of their own free will. They're using it of their own free will. Cause this solves a problem for them. And that's good. I want, I wanna solve a problem for somebody else.

(00:11:35):
Um, I mean, cow milking machines and satellites and helicopters on Mar. I mean, and I'll, um, mega super mega yachts balancing things so they don't tip over. I mean, that's all running Linux. It's crazy <laugh>. Um, but nobody likes writing operating systems and device support. We support all the devices in the world and then some. And that's the key. The fact that we support all the hardware that you have is what made Linux succeed. Uh, it's what stops other operating systems. Everybody forgets about it. It's easy to write a kernel. It's hard to write 50,000 drivers.

Jonathan Bennett (00:12:08):
So you have this list of places you want to take over. Uh, has the desktop made the list? You know, the joke for the longest time has been the year of the Linux desktop. And I've kind of told people not, it's been the year of the Linux desktop for me since like 2003. Um, but what's the deal?

Greg Kroah-Hartman (00:12:25):
<laugh>? It was a Lin, yeah. Linnux desktop for me since 1999. Um, we did, and nobody noticed Chrome OS number one and selling laptop in the top 10 for the past 10, no, maybe not 10 years, eight years, nine years, 10 years. That's all Linux. Mm-hmm. <affirmative>, we won. I know that's Linux on a desktop. Um, we had Linux, I mean, on the phone, it's more devices out there than any other phone out there. It's Linux on a desktop and we won there. Um, you want traditional Linux on a desktop. Um, I mean we won with that as well if vendors want it. I mean, red Hat makes a very good business selling Linux on the desktop workstations to all Hollywood and all the rendering farms and on other companies do it. HP sells Linux on all other laptops that they sell to businesses. Um, forward infamously, entire forward engineering division is all running Linux.

(00:13:14):
And then they have Windows in the car. So <laugh>, that was the funny one. <laugh>. Um, I think they finally got windows out of the car. Um, but so I mean, it's on the desktop if you want it then that's about it. I mean, you have to want it and you have to have a company that wants to sell it at, when I was working at Nove, we sold Lennox Preinstalled on lots of machines if people wanted it. And it was possible too. Canonical still does it. I bought Dell laptops with TU on it and it works. Mm-hmm. <affirmative>, it's there.

Jonathan Bennett (00:13:44):
Uh, yeah. So speaking of the desktop, there is a, I think I'm allowed to get into some nerdier stories now. Uh, there's a couple of things that I've been tracking. One might make a big difference to desktop users. And that is, uh, Invidia, uh, the, the company that, uh, you know, famously got to vault's ire back a few years ago and that, that great clip from it, a talk he gave to I think university somewhere. Anyway, um, has announced it's been a few months back. Uh, and open source kernel driver, they're finally throwing some code for their desktop GPUs eventually into the kernel. Uh, what's the, what's the status of that are, did, did you guys' minds explode when that happened? Like the rest of us? And what, where's that at? Now

Greg Kroah-Hartman (00:14:27):
That is not a GPU driver. Like you think of a GPU driver, <laugh>, let's just say that that is the GPU driver you use on in the cloud. So GPUs in the cloud for AI stuff is huge, right? Huge market, huge number of stuff. Um, you have to have open drivers on there because vendors enforce it. So Nvidia is wonderful in that they don't make, they don't break the gpl, they force you to break the gpl <laugh> the way that's just the way the code is set up. So, um, vendors who are not willing to break the GPL ask for an open version that they can put in their render forms, that's the open version that they can put in the render forms. So it's great. So I mean, that's nice. Some wonderful, that's workshop great. But I mean, I mean people love Nvidia for graphic stuff, but I mean, I been using AMD's graphic stuff, wonderfully steam deck, that's Linux gaming wonderful stuff.

(00:15:21):
Amd great little chip, great, a great little device. I mean, it works great. I don't know, just don't buy Invidia if you don't wanna mess with the drivers. It's that simple. <laugh>. I mean, it's just like, don't buy a certain vendor of a mouse that, you know, doesn't work. It's just the same thing. So, um, and then Vidia has another half of the company that does tons of open source work. They're embedded ships are all up upstream. They have a ton of really good engineers that work with the community. Strong stuff. It's just, I mean, it costs money to keep code out of the kernel. And Vidia has decided to spend that money to keep the code outta the kernel. And now maybe they're not, that's a business decision on their point.

Jonathan Bennett (00:16:02):
Yeah, and that's a valid point. Some of us there, there's this temptation to go down the road of making some of these open source things, moral issues. And I guess in some cases there are, but for the, for the most case, that's, that's not really the right way to look at this. Is it, it's, it's a, it's a business decision. It's about economics more than more than morality. And uh, that's probably something you guys have to remind yourselves about from time to time. Eh,

Greg Kroah-Hartman (00:16:23):
Well, there's legal issues involved, of course, right? I mean, let's not get legal issues. But again, and maybe on their own do not break the gpl. So they're not, they're biting by the license, it's fine. They force you to break the gpl <laugh>. So, um, you can talk about intent and all fun stuff like that. So, um, yes, there are moral issues if you wanna do crime, go down the moral issue path. But I mean it's just, it's just, let's talk about the technical issues here involved. So, um, technically it's a pain in the butt to get that thing to work. So <laugh> and it's a business decision, it's cheaper. I mean, IBM and Intel said years ago, I think there's some Harvard Business School review of it. It's cheaper to get your code, work with the community, get it upstream, and have it maintained there than it is to keep it outta the tree. It's a business case to get it up the stream. Some companies make the business case they're willing to pin the money. Qualcomm inly spend the money to keep it out of the tree until the very last possible moment because they wanna hold off in the way they do their releases, but then they do upstream and eventually it costs them a little bit more new money. They're willing to spend it. That's fine. It's a business decision.

Jonathan Bennett (00:17:26):
Uh, speaking of technical things, we actually had a question from the chatroom. And this, this is interesting with AMD's announcement of their epic, uh, their epic OA CPU tomorrow, which is potentially up to 96 cores per cpu, is the thread scheduler and the kernel optimized for 96 plus cores per CPU and maybe up to 1 28 for the next chip.

Greg Kroah-Hartman (00:17:48):
Yeah, I mean, I'm getting bug reports of issues when we're hitting 4,000 and 5,000 right now. <laugh>. So we've been, we've been, we've been, and and that's in some really weird conditions. Yeah, we've been scaling that big for a long, long time. Um, yeah, that, that's, that's nothing small. That's, that's not a big deal <laugh>. So I think my system has more than that right now or pretty close to that. Um, that's not a big deal. There's a curve on how well they scale after a certain point in time. But that's, I mean, that's Linux big success is we had access to the algorithms that we're allowed to do scaling well and that's why we succeeded in the end. Cuz we could do multi-processing really, really well. I'm the only other person that could do that was Windows and we kind of beat them on of the other people didn't have access to the ability to take advantage of those algorithms, which was kind interesting, maybe not, but it's data centers.

Doc Searls (00:18:48):
So let me take this time to have a little break so I can let our listeners and viewers know that this episode of FLOSS Weekly is brought to you by Code Comments, an original podcast from Red Hat. Uh, you know, when you're working on a project and you leave behind a small reminder in the code, a code comment to help others learn from your work. They'll, this podcast takes that idea by letting you listen in on two experienced technologists as they describe their building process. There's a lot of work required to bring a project from whiteboard to development, and none of us can do it alone. The host Bur Sutter, is a red hatter and lifelong developer advocate and community organizer in each episode verse sits down with experienced technologists from across the industry to trade stories and talk about what they've learned from their experiences.

(00:19:39):
And by the way, I listen to, uh, their first podcast, which is all about AI and ml, especially in the, um, in the enterprise, uh, space. And they actually don't do everything inside of Red Hat. They went to Intel in this case to talk to people about what they were doing with, uh, open source and uh, and artificial intelligence and the rest of it. Good show. So episodes are available anywhere you listen to podcasts and at red hat.com/code comments, podcasts, that's all one word, code comments podcast red hat.com/code comments podcast, search for code comments in your podcast player will also include a link in the show notes. My thanks to code comments for their support. So Catherine, I know you had from our back, you had a question queued up.

Katherine Druckman (00:20:33):
I watched a talk that you gave a while back about trust and the process of Linux Colonel development and, and the processes you go go through. And I think probably most people listening have some vague idea of the process and that your patches, um, are still come over email, which I thought was interesting. And I wondered if you could talk a little bit about why email is still the best option for the Linux kernel. Um, and, and I, and actually I, you know, I wondered if you could speak a little bit about this idea of trust and why the process is trustworthy, because obviously it is. I mean, it's everywhere, but, but the, I I, I found, um, the conversation around that pretty interesting.

Greg Kroah-Hartman (00:21:14):
Sure, I'll talk about it. Um, I get a lot of flack for this, but email actually is the lowest common denominator that everybody in the world has access to. It's that simple. Um, it's also really, really good what English is not in your native language. And we want to have people with English is not their native language contributing. And as someone who lives in another country, it takes, it's good to read a language text in another language process, it take the time to do it back. I know some open source projects want IRC face to face meetings and whatnot, and that puts that at a huge disadvantage for people that aren't, don't know English really, really well. So great English, our email, lowest common denominator works everywhere, works for everyone, um, works remotely, um, store and forward works everywhere else. We have one of our core security people lives in, somewhere in the middle of Africa.

(00:22:03):
I don't really know where. I think he moved countries and he was doing store and forward and worked really great and nobody really realized where he was. Um, it works great. And also plain text HT or no HTML email works great. It's also provides a really good way to prove who you are. You can sign, we sign our patches and you can see any patch I send out, it's cryptographically authenticated. I can verify that it comes from you. Um, we've actually had some cases where people spoof what company they're working for, and we've got that because it's like, oh no, you obviously are not coming from so and so.com because your email says it's not coming from that com that, so it's easy to detect that, things like that. And then usually that's the o r it department doesn't work. We have to use Gmail, which is almost always the <laugh>.

(00:22:49):
So, um, all the, all the Linux companies usually have a Linux box in the corner so they can go around the exchange server. Even Microsoft, who's a big contributor to Linux, has a Linux box in the corner so it doesn't hit the exchange server and they can send their patches out. Um, yeah, email, it works out really well. Um, the trust issue is interesting. Um, I, I have a friend who, um, contributed to the colonel a while back and he was like, he said it was terrifying the first time he contributed to the colonel because all of a sudden the work that he's putting out there is gonna be viewed by the world with his name on it, right? And that's a good thing because you do really good work when your name is on something. You can't hide anonymously behind something and you do better work because it's out there for everybody to see.

(00:23:31):
And it's fine if you do things wrong, you get things buggy and whatnot. I mean, I joke I've probably ridden more bugs than anybody else. Um, and that's, that's true. So, um, as long as you acknowledge your mistakes and learn from it and go forward and that's great, but you're out there in the world contributing with your name as far as trust goes. I mean, we had the problem where the University of Minnesota tried to submit some patches anonymously and claimed that they were sending false or buggy known buggy patches to us. And they wrote a paper up and said that we accepted them. It turns out we didn't accept them and they accepted one of the patches, but because their patch that they tried to write was buggy was actually correct, <laugh>. So, um, they really didn't do a good job about that. Um, the ethics people ripped them, really, really got mad about that because they lied in their paper what they had done.

(00:24:21):
Um, they lied to us. They, when they were caught, it was a whole big nightmare. And the big thing that I, we take can take from that is open source software is more trustworthy. Not necessarily because it's written better, but because you can go back in time and audit it. So what we did is we looked at all the contributions that that university had ever contributed to the colonel for forever. We audited everything. I had a whole bunch of interns at the moment, so we just let them loose and we audited everything we had. And turns out they didn't really, they weren't that good of developers at the time, so we ripped all their old stuff out, fixed up the bugs and pushed out new updates. So you can't really do that with close source stuff because you can't go back in time and see who contributed what, where it came from and changed it and see how that works.

(00:25:05):
Um, so since then we've worked with the university and they're, they have a, a very core kernel developer working with them to try and fix their procedures and how they work together and how they work in the community and teach 'em how to do things. But another thing that came out of that was everybody's like, oh no, you need to have verification of who's contributing to the ker, who's all the, who's doing all this work? Who's, who's doing all this crazy stuff. And the question is, why, why do we need that? Because your name's on there. We're not, we don't take anonymous things, no anonymous things. Um, and they're like, oh, well we can't have people sneaking things in, sneaking bugs in. It's like, well, you do realize who writes the most bugs? Oh no, who writes the most bugs? I'm like, your core developers write the most bugs.

(00:25:46):
So <laugh>, I'm literally, it's just a matter of the odds. I mean, x you say you write one, one outta 10 changes is bad, right? So we're all human. So if I write a thousand changes, I wrote more bugs than somebody who just contributed two changes, right? Um, so the people you need to worry about the most are your core developers, <laugh>. So you need to put processes in place to catch everybody, all the bugs. So I want my, I want our testing tools and processes and infrastructure to catch all the bugs that I write because infamously, I have ridden some pretty bad security bugs over the years, <laugh>, um, and fix them later. It's just the way it goes. We're all human. Um, so I want you to catch my bugs. I want our tools to catch our bugs and if they're gonna catch the bugs of the core developers that catch the bugs that are submitted from any developer, and that's the key. You need to have the tooling and the infrastructure in place in order to catch the problems that anybody can create, because we're all human. So we're all gonna make mistakes. So just do that and then you're okay. And a lot of, a lot of open source projects have that, which is key. And that's all you really need to know. You don't need to know, verify who is doing what, because your core people are the ones doing the most problems. <laugh>.

Jonathan Bennett (00:26:55):
So I, I have a question. Something I've, I've wondered about for a while now, but I think it tags well onto this. And that's the, the work with the Sahi Linux, uh, putting Linux on the Apple M one, which is really cool, by the way. We, we've been following that and think that's great work. One of their developers is, uh, obviously writing under a pseudonym, a Sahi Lina working as a v YouTuber, which is cool. Um, I'm just curious, how is that going to work when there is a patch sent into the from Asaki as some, someone that's obviously working under a pseudonym. Is this going to, uh, cause some issues with the Colonel's real name policy?

Greg Kroah-Hartman (00:27:31):
Um, the only patches that I've accepted for that kind of hardware have come in with a real name. So look and see is actually submitted into patches.

Jonathan Bennett (00:27:42):
Okay. That's, that is a <laugh> That is a fair answer.

Greg Kroah-Hartman (00:27:47):
Um, I dunno. I can go back and audit. I'll go back and audit and, and look. But um, that being said, we do have a few contributors. Um, there are some exceptions that we do know who they are. Um, they just for legal reasons, we know who they are. They have to use a certain name. The best is I, I mean, infancy. I ask everybody who, when they contribute to the colonel who they work for, right? And hilariously about once a year, I guess somebody's saying, oh, I work for this company, but don't tell anybody because we're not allowed to contribute to the colonel. And oh, by the way, I'm the person in charge of that policy. It's like, what <laugh>? Um, so we have a few people like that. That's an interesting one. We, we get that a lot. Um, anyway.

Jonathan Bennett (00:28:29):
Goodness. Okay. Well that, that answers that pretty nicely. Uh, if I've still got the ball, I wanna ask about Rust. Uh, this, this is another thing that I'm pretty thought you excited about. Yeah. So there are apparently two very polarized opinions on this. I've seen a few people claiming that this will be the death of the ker and uh, then the rest of us are pretty excited about the potential. And I dunno, are you somewhere in the middle or are you on, on one team or the other? <laugh>,

Greg Kroah-Hartman (00:28:56):
I'm in the middle, right? I have the rest book back there. I need to learn it some better. Um, I'm in the middle. Um, the word, I mean, Jonathan Corbat talked about this on your own podcast a couple weeks ago, right? And he gave a really good description of it. Rust and Linux is gonna be unique and different from rust and user space. Mm-hmm. <affirmative>, because our environment is very, very different. We have a very constrained environment, lots of different problem. So rust, traditionally when it causes, when you detects the problem, it will just kill the program. Well, you can't do that when you're the colonel. So you have to have some bounds in place. Um, there's some good things that we do in Linux that would be, Russ would be nice to like writing parsers to parts, USB devices, uh, descriptors and things like that.

(00:29:36):
That would've been cool. Um, and everybody said, oh, we'll just use Russ to write a driver. Um, people don't realize that drivers actually consume the whole kernel, right? They consume resources from everything. They're the, the tip of the leaf and they do everything. They need memory management, they need timers, they need schedulers, they need that, they need everything. So you have to write bindings between rust and sea for all of the interfaces, right? And that's gonna be a lot of work over time. Um, it's cool. I I like it, I like the idea and it'll solve a certain subset of the problems that we have in see. And there's some areas that it'll prevent from ever happening. Those just won't allow it to happen. That being said, there is a mismatch between how the kernel handles things like objects and devices and how rust handles things like objects and devices and meshing those two is an interesting, interesting thing.

(00:30:26):
I've had a lot of discussion with the rust developers. I think we can come to some good solutions. But even if we were to stop today, the work that the rust developers have caused us to reevaluate and think about has actually benefited in the C side of the kernel. I've made changes to the core driver model to benefit the rest people that have benefited everybody that prevent things from happening and being done wrong. So having new ideas and, and models that are coming in from the rest developer community is great. It helps everybody out that way. Um, it'll be interesting to see how it goes. Um, it's in the kernel today, it does a hello world and that's it. There's some great examples of some, uh, of drivers out there, um, on how to, where to go forward with this. We have people doing file systems in there when file systems might be like the sweet spot for doing in Rust.

(00:31:13):
Um, because there's some cool things you can do. File systems do not consume much of anything from the kernel as far as resources go. So, um, you can write it small buy binding layer and away they go. Uh, they can do some cool things. Um, it'll be interesting to see and it's fun. I mean, it's a fun thing to do. And that's in the end, we're all engineers. We're cool program, we're programmers. We like having, playing with cool toys and fun things and let's do that. And remember, some of the core Rust developers are longtime and external developers. So they know our environment, they came from our environment so they know our issues and evolv and that'll help, that's helped rust the language out by providing interfaces and cool things. It's a great synergy and it's fun. I dunno. Let's see what happens.

Jonathan Bennett (00:31:54):
Yeah, so you, you point out that rust and user space is much different than rust and Kernel space. And I just have to say in fairness, see in user space is way different from C and Kernel space too.

Greg Kroah-Hartman (00:32:05):
<laugh>, that's true. I mean, we are very restricted in what you can do in the kernel. C in the kernel is very simple. I mean, the kernel code is overall very simple because we have to do everything ourselves. So we do everything ourselves and we do it in very tiny, tight constrained ways. And you can't really do things wrong that way. So Russ is, is turning out to be the same idea. There's a lot of things, fancy things you can do in Russ that you're not gonna be able to do in the Cardinal. Like, people are like, oh, we wanna have cargo and import all these different things. I'm like, no, that's just not even gonna work. <laugh> even I have a meeting with some people at Google and I think after this later tonight, uh, to talk about that <laugh>. No, that's not how this is gonna work. Um, but for the most part, the people working on the rest code in Ker know what they're doing. They're really smart people, they're brilliant people. And in fact, what the work that have done, and I'm encouraged and if nothing else, again, it's helped us out. So that's the best thing to do and it's made people excited and we always like people being excited about criminal development.

Doc Searls (00:33:06):
Okay, so actually I have a, a question which is, um, about, it seems like every few months somebody with a podium. Uh, one recently is somebody who used to write for Linux Journal comes out and says, oh, the Linux Foundation is funded by all these giant companies and therefore it must have, those companies must have some influence on Linox says, oh, money always corrupts corrupts. Absolutely. And all this things, and and you've actually tackled this question like every 10 years or so in the past is

Greg Kroah-Hartman (00:33:37):
I tackle it every couple months when somebody ask me this and I laugh because, right. So Linux Foundation is, is a trade organization because legally it has to be trade organization, right? For companies to come together and work on, on a project together. They can't, unless they do an auspicious of a trade organization, otherwise it runs into anti monopolistic laws. So legally they have to do this, right? If HP and IBM wanna talk about a networking issues, they can't unless they do it in a training organization. So Lin Foundation provides that. That being said, nobody, I mean, anybody who says that doesn't actually understand how Linux is developed, I mean, look at John Cor and I do the numbers every couple months. Um, and he writes I the database, he do, he writes articles, um, what do we, um, it's, it's all these different companies.

(00:34:22):
We have 500 companies last year that contributed to Colonel. Um, Lennox Foundation only pays for three kernel developers. You know, Lena, me and Shah. Um, and our contracts say they can't tell us what to do and we can't tell them what to do. <laugh>. So I mean it's, it's, it's pretty simple. I mean, we have enough other work to do, but I mean, we're just three people reading code and stuff from other people. We're not doing much on our own. Um, everybody contributes to Linux in a selfish way given that. So everybody contributes to solve a problem that they have. The fun part is everybody has the same problems. <laugh>. So, um, I mean famously, I mean I give this talk this, this example all the time, years and years ago, the embedded people came to us and said, oh, power management's really important. We wanna run Linux on devices with batteries.

(00:35:07):
Here's the special ways to do this. We're gonna add these special hooks and stuff. And we're like, no, why don't you make it generic? Make it work for everybody. They're like, oh, that's too much work. Nobody cares. I'm like, we're like do it right for everybody. So we went back, did the work, right? And now data centers say billions of dollars in money because power management matters for servers, <laugh>. So everybody has the same problems, they just don't realize it. So as far as corporate influence goes, I mean like John and I have said, or like 10% of the car contribution happens from people not associated with a company. And that's only because they haven't been hired yet. Um, somebody at the plumber's conference, I used to joke five patches and you get a job. Um, somebody gave a talk and said, no, it took me 20 patches before I got a job <laugh>.

(00:35:49):
Um, so if you get a job works out great. We have an intern program that's packed. We have like 200 people apply for 10 slots. Um, everybody that goes through that either gets a job or they stay in academia or they decide not to do it. Um, it's so if you get a job, if you do this type of work, you'll get a job. There's so many jobs out there. That being said, we have tons of people, more people are doing ker development now than ever have been doing ker development in the world. So it's really nice. 4,000 people a year. Um, I don't think the world's ever seen that many ker people. <laugh>

Doc Searls (00:36:23):
<laugh>. How long? And I, I remember, yeah, I just wanna finish this thought a little bit because um, I remember when uh, Dan Fry, when he was at IBM told me it took IBM six years to realize they couldn't tell their colonel developers what to do then. In fact, it was more like the other way around. And then, uh, and then Andrew Morton said, everybody working for the colonel has to work for everybody. How can you possibly be working for one company when you're working for everybody? So, and, and that, and that's sort of as has a little question about that. How is it possible to, to do something that is for everybody? But it seems to have been, you know, the early thing we talked about embedded earlier in real time. I dunno if you touched real time exactly, but it was, oh no, can't do real time. You can't, there are all these things the lakes colonel can't do. Then it ends up doing it anyway. And I think it's because you need it for everybody. Maybe that's why it's, you know, at one 10 years ago.

Greg Kroah-Hartman (00:37:18):
Well, it's also interesting cuz everybody has a problem and they're like, oh, I'm not gonna write a whole operating system, but if I change this little tiny thing, it'll work for me. And we say, go make that little tiny thing be generic enough to work for everybody. And they do. It saves them time and money to do that. They get a solution and away they go. I mean, yeah, Linux has been real time in John Deere tractors and Ikea laser welding robots and Volkswagen assembly lines for decades now. Um, so I mean it's, it, it solves a problem cuz it, you just have to put a little bit of effort into it, solve your problem, and it happens to work for everybody. Um, and it saves your time and money to work upstream. I mean, infamously Lennox drivers are one third the size of operating other operating system drivers because we can see and help you and review this stuff.

(00:38:02):
We have experience. I mean people, people make fun of us for, oh, you've been doing this for so long. It's like, well, do you, don't you want people with lots and lots of experience doing this type of stuff? Um, I mean the networking developer's been doing networking course stuff for 25 years. I've been doing USB for 25 years. Um, that's good, right? I mean, the other operating systems company, you traditionally move around from different divisions to do this with us. If you're a maintainer of something, you get stuck doing it for forever. Um, and ibm, I was, I worked for Dan Fry for a while. We learned that the hard way. We had somebody, a new graduate come in and he took over a portion of the kernel and he was the maintainer of a certain timer subsystem, whatnot. And then he was, he finished his job that he was assigned to IBM and he was gonna work on something else.

(00:38:44):
So we're like, no, you have to still give him time to be the maintainer. And they're like, what? What? Like, yeah, he's the maintainer of that and that person is taking that position with him to other, other companies, right? It doesn't stay of the company, it stays with the person. And that's a really important thing. Cause there's a lot of good depths of knowledge in people and we can learn and teach other people and whatnot and just doesn't disappear. Linux has a really, really deep history of knowledge, which is awesome. And we've gotten people from other operating systems. There's a lot of ex-Microsoft people working on Linux, which is great. Um, when I was a Novell, I won the network people and they weren't really around that much, but we had a few network people working on Linux and that's all good. I mean, we want that history and that, that depth of knowledge there.

Doc Searls (00:39:27):
Okay, Katherine has a question queued up, but first I'll have to let everybody know. This episode of plus weekly is brought to you by Collide. The challenge with device security has always been that it's difficult to scale. The bigger you are, the more edge cases you introduce and the easier it is for significant issues to escape. Your notice when remote work took over, the challenge got exponentially harder. Whether you're in a fast growing startup that needs to graduate from managing device inventory and Google Sheets, or an enterprise trying to speed up service desk issues, you need visibility into your fleet of devices in order to meet security goals and keep everything running smoothly. But how do you achieve that visibility? When your design team uses Max accounting is on Windows and your most talented developers are on Linux, you get Collide. Collide is an end point security solution that gives it teams a single dashboard for all their devices, regardless of their operating system.

(00:40:25):
Collide can answer questions, MDMs can't. Questions like, do you have production data being stored on devices? Are all your developers SSH keys encrypted, and a host of other data points that you'd have to write a custom Michelle script in order to learn about? Think about it. If a Linux vulnerability is exposed tomorrow, how do you figure out how many machines are at risk? File a ticket with a team that manages your MDM and wait days to get a report back. Send a mass email and hope the Linux users open it with collide. You have real time access to your fleets data and instead of installing intrusive agents or locking down devices, kaly takes a user focused approach that communicates security recommendations to your employees directly on Slack. You can answer every question you have about your fleet without intruding on your workforce. Visit cole.com/FLOSS to find out how. If you follow that link, they'll hook you up with a goodie bag, including a t-shirt just for activating a free trial. That's k O l ID e.com/FLOSS. Okay. Catherine <laugh> your turn.

Katherine Druckman (00:41:35):
Yeah, so picking up a thread actually, uh, from Doc earlier about corporate participation in open source projects, um, and actually kind of ties into the, the email, uh, verification and identity verification a little bit because, or at least in my mind it does. But there is a, there is an emphasis a lot on, uh, crediting systems and open source projects. I, I come from a DR perspective. You know, there's a very intricate system of tracking where contributions come from and I, I appreciate the value having been lucky enough to be one of the people paid to contribute. So my company name, you know, went along with my contributions and, um, I just wondered how you felt about these type of corporate ranking systems. Everybody wants to be at the top of, of, uh, you know, listed contributions for whatever project, especially something like Linux. And, and I wonder, you know, what you thought about them and, and what's the right way to do it and what, you know, what people are, are doing right and wrong in in that arena.

Greg Kroah-Hartman (00:42:29):
I think I'm the one who caused all that to happen. So, I'm sorry,

Speaker 7 (00:42:33):
<laugh>. Well,

Greg Kroah-Hartman (00:42:37):
18, 18 to 20 years ago I gave a talk that I, I showed who was contributing to the kernel and what, who they worked for, what companies contributing. And ever since then we've had to do a report sewing who is actually contributing and sponsoring them. Um, so it's an interesting thing. Um, that being said, I mean, yeah, we all work for, we work for somebody. We help them do what their company wants. Um, but like, as John Corbit said, we need more maintainers to review stuff, but we also track who's doing the reviewing as well. Um, but it's good. I mean, and the numbers are so large that you really can't game them. It's kind of fun to watch when companies try to game 'em. Right? Um, that being said, even if you're trying to game them with, um, oh, I'm just gonna submit a whole bunch of spelling fixes or code cleanup, coating style fixes.

(00:43:23):
Well that's good. We want those. So those are valid contributions. Yeah. So, um, inadvertently, if you look at our top 10 contributors every year there's a like two or three or four people that are doing really good janitorial work. They're sweeping the tree and they're cleaning up old crufty stuff. They're picking up old patterns, they're deleting drivers that don't, aren't even being used because nobody has the hardware anymore. They're doing other stuff. And that's good. That's, you need that for the lifeblood of your project. So if you're trying to think that, oh, companies are gonna gain it, I'll take it because those are contributions you want. Contributions, right? Right. Um, we are lucky in the kernel that we have a ton of participation and a ton of contributions. Any other open source project would be so lucky to have what we have. Um, so we don't turn things away, but we're, we're very welcoming and we accept them.

(00:44:05):
But everybody wants help, right? So if you're gonna send spelling fixes to Kubernetes, they'll be glad to take it. Um, more power to you. And then the interesting thing is that's how you learn the code base and you learn the development process. We have a whole portion of the ker that we encourage people just to do coding style fixes and cleanups cuz then you learn the process, you learn how things get involved, and then you mm-hmm <affirmative> trip trip over something and you're like, oh wait, I can really go fix this for real. And then you go off and stumble into another part of the carnival and become a a subsystem maintainer. We have a load of people who've done that over the years and it's a good like, little bait and hook or way to get into the kernel. So by doing that type of effort, and it's important to give recognition to companies that are sponsoring open source work because it's good stuff.

(00:44:46):
And it's also on the other way. I mean, infamously, I gave a talk at Intel years and years ago showing how nobody contributed at Intel to the ker except for specifically one person who was somebody's manager, <laugh>. And, and you gotta say, Hey guys, if I could do this, you can do this. And infamously also in Japan, another company, a manager, higher up manager at, at Japan and a very large company, got it, translated the documentation into Japanese and became the maintainer of that. And then he went to his engineers and said, if I can do this, why aren't you doing this? Um, so it was actually a really good good stick to show that, um, people, other people are doing things and everybody should be able to contribute. And also it is interesting, some companies don't realize that they're really contributing to the kernel at all when they are. So I gave a talk that's online saying, here's all these people at Google, they're doing this work, and people are like, who are these people? So, um, that was an interesting thing too.

Jonathan Bennett (00:45:43):
So, all right, I've gotta jump in and ask a couple questions that Katherine maybe can't because they're Intel related. And then I've got kind a meta question about that. Hashtag hashtag hashtag I am Intel. She's an employee.

Katherine Druckman (00:45:55):
She's, I'm an Intel employee. If I had not mentioned that already, yes, <laugh> plug

Jonathan Bennett (00:46:00):
Away. There's

Greg Kroah-Hartman (00:46:02):
Your, I'm not an Intel employee, but they owe me a lot of liquor for all the security.

Katherine Druckman (00:46:07):
Hey, you know, next time I see you, I will happily price <laugh> <laugh> <laugh> or wine. I like wine. I

Greg Kroah-Hartman (00:46:13):
Dunno. Wine's good too. I'll take

Jonathan Bennett (00:46:15):
That. Uh, so first off, uh, the, the, the performance and efficiency cores from the latest, uh, Intel CPUs, um, how much of a headache has that been? And, and this may be a dumb question, but why was that not easier? Because we already have big dot little over an arm

Greg Kroah-Hartman (00:46:37):
<laugh>. Um, first off, I'm not a scheduler person. I am not a scheduler person at all. Um, that is not my area. I do drivers little tiny things over side. I make your mouse work, things like that. Um, keep your serial report alive. It's been alive for forever. <laugh>. Um, big Little is scary, big little is a nightmare. And if you look at what Intel did with their cores, it isn't the same as big little, um, it looks a little different. That being said, arm is coming out with cores that are like a 32 and a 64 bit core on the same ship, and we're supposed to migrate between them. Talk about a scheduling nightmare. Um, the things that Intel did was kind of like that. They were radically different cores from what I remember. I could be totally wrong. And it just took more logic. It took a lot more work and a lot more effort to do this type of stuff in a way that will work for everybody.

(00:47:24):
Remember, we're a general purpose operating system. We have to have something that works in a scheduler that works for everybody. And that's a hard thing to do to tune to process and make things work well over time. Big Little took us a long time to get working right? Mostly because the hardware didn't work very well. Um, the first couple rounds of Big Little made no sense at all because you all, the power was in the ram. So it kept all the power to keep the ram shutting off A big core saved no power at all. Um, turns out CPU designers don't talk to the RAM designers. Anyway, <laugh>, um, um, that being said, so the Intel stuff, I'm, I've, what I know of, it's just, it's a radically different design, so it just took a while to get there. Okay. It's getting there. Um, but it, it's getting better, so

Jonathan Bennett (00:48:05):
Oh, yes, no, we, we've been, we've been following that story too. You know, the, okay, the new Intel CPUs, they'll work under Linux, but maybe wait for a couple more criminal releases before they get really good. So I, I want, I wanna go to something else that I've been following. So we're running out of time, so I'm gonna go through these real quick. Something else that I've been following, and that is the actual real time patches. And of course that's being done by Linux Trons, who got bought by Intel, which actually way to go Intel because Linux Tronix was having a funding problem. And so Intel kind of, as far as we can tell from the outside, kind of scooped in and saved the day to keep those things going. Um, I saw a comment from Linus on one of these, one of these threads that essentially said, well, there's, there's not very many people that care about this, and it's only for, you know, these, these very, very specific instances. And I'm over here going, wait a second, I do, I do audio like musician work on Linux. I care about trying to get low latencies, want the real time patches help with that. And so I'm curious, and I know there's a bunch of driver

Greg Kroah-Hartman (00:49:02):
Things. No, they won't, they don't, they don't, they don't help with that. Remember, real time is not low latency. Real time is deterministic agency. So it can be really slow determinism <laugh>. So it's not low latency

Jonathan Bennett (00:49:16):
<laugh>. When, when, when you tune your audio interface though for really low latency, one of the problems that we see is most of the time it can handle that. But every once in a while you'll have an X run. And so I've always seen the audio guy saying, well, if you can actually go into a real time mode, you can prevent those X runs because you know that the kernel is gonna be ready for each of those packets.

Greg Kroah-Hartman (00:49:35):
Yes. And, and you can do that. And that, that is a good thing. If you can to tune that thing to say you cannot overrun this type of stuff, then yes it will. But real remember, real time on its own doesn't guarantee latency issues. Now if your system, it can handle the guarantee that it will give you that most audit consumer, his, um, hardware can't because like the, the CPU smp, um, msi, there's some other crazy stuff underneath the CPU that takes it away from Linux and we have no ideas even gone and comes back. But, um, there's some really cool things you can do with Linux. Um, now you can take Linux off all the CPU or office CPU and then run all your audio stuff on just that cpu. So then you don't even have Lins evolved. And I know a number of people do that, but real time.

(00:50:19):
I mean, traditionally laser welding robots, um, very, very like John Deere tractors. There's some things where latency really, really matters. Um, audio, most consumer hardware can do audio. I have a raspberry pie that I can do massively fun audio stuff with. Perfect, no, just a normal kernel news has their guitar that they play in concert has a raspberry pie inside it running Linux to do a audio, um, NPI interface out. No real time kernel. Um, the giant systems with the sound and the things like that with audio, those are not using the real time kernel. But that being said, the real time kernel is cool. Um, I'm really happy about it, is cleaning up a lot of problems that we've had UX over the years. Um, and it's almost done. It's almost done.

Jonathan Bennett (00:51:03):
Okay. So I've, I've gotta ask kind of a, a meta question about those two because those, those have been two things that have been well, and all, all the rest of the questions I've asked on the show really have been kinda like burning questions. And sometimes I've had comments or thoughts about things that have happened on the mailing list. And I've always had this thought of, I'm just an outsider and this is probably a dumb comment, I'm not gonna send this into the mailing list. Is there a way or a place that kind of these outsider comments make sense to as, as feedback or as questions? Is, is there a way that, that we should be handling these? Or do do you prefer for kind of a, the, the, and I I will put myself in this category, the uninformed observer. Should we just kind of stay outta the way unless we have a patch to submit? Like where, where's the, the balance on that?

Greg Kroah-Hartman (00:51:50):
Well, if you have a problem, let us know. I mean, that, that's being said. If you have a bug and you see a bug and the latest version of Colonel, let us know. We're more than willing to help you fix with that. Um, that being said, if you have a problem that isn't addressed, let us know. But I mean things like, oh, wouldn't it be nice if this did this? No, that's not gonna really bad. Cause my to-do list is huge. We, we need patches coming in. Um, but I mean, even the audio people, we deal with a lot of audio, like there's a whole bunch of audio routing products and synthesizers and stuff, and those have run with a stock Linux kernel today. There's open source projects that do that. We inter we interface with 'em a few times. There are a number of kernel developers working for those companies that contribute to the kernel.

(00:52:29):
So, um, especially in the audio area, I just got an email from some audio company in Germany that wants to driver for one of their devices. Um, so they're out there and they, they contribute to Linux and they do good stuff. So, um, work through that. If you have hardware that doesn't work, let us know. You have a bug that doesn't know, but just to speak up saying, oh yes, they really do care about real time. Well maybe you don't and you don't realize it <laugh> like, I've tried to help explain here. Or it just doesn't matter to you. So it, it doesn't, that's not gonna, that's not gonna help get a patch accepted. Now, if you tested a patch, wonderful. If you say, Hey, this solves my problem for me, I would love, love, love, love for that to be there. You can put your name on it.

(00:53:06):
I would love to have a path of blame in case something goes wrong, <laugh>. Um, but that's, that's perfect. And but I mean, cuz we don't have all the hardware to test stuff. If you test something for me, that's, that makes my life much, much easier as a reviewer. Yeah. And that's the best way to get involved. Just start reading changes from other people. When you learn music, you don't start writing music before you read music. Right? Yeah. And the same thing with programming. You should read lots of code before you start writing code. It's not really taught that way, but it's really, really helpful that way. So start reading changes coming in by pop to people and just ask questions. If you have a question saying, why did you do it this way? I, everybody has to justify their changes, right? There's no reason why I, I would knock it upset if somebody said, why are you doing this way? I'm like, oh because of this and maybe I didn't document it good enough cause it wasn't obvious and that's fine.

Doc Searls (00:53:51):
Sure. You know, it's funny talk about, um, real time. I remember we bought this new Sony television in 2006 for our, the New House. And, and it comes, it came with a thing that said, this is, there's Linux in here and we, our lawyers are making us show you the entire gpl. So there was like a five page thing and it so didn't flatter, flatter linox. Cause you could go out and have a smoke or mix a drink or something while you waiting for this TV to come up. And I remember thinking, can I go in and fix this thing? Apparently I couldn't. So I guess that's <laugh>.

Greg Kroah-Hartman (00:54:25):
They've gotten better. It's usually in the box now. It's a little link somewhere buried in there. I mean, look at what Android does, the GPOs in there. You just, it's provided, it's not shoved in front of your face. There's a lot, I've been, a lot of people were worried about that to start with. So I mean it was nice that they were airing on the side of we want you to know and be, they want to follow the license explicitly, which was great. I really appreciate that. Sony is one of the people that have done the right thing for so long. They're really, really good at that. Linux has been in their cameras for forever. Um, they've done some really cool stuff with power management. They just shut off the whole kernel and started it back up again right where it was really fast. And they do cool things like that. Um,

Doc Searls (00:55:01):
I didn't know that. So, so this, this is my new Sony, uh, a seven four camera. There's Linux in here. That's cool.

Greg Kroah-Hartman (00:55:08):
I don't know which ones have it, but there are some internal developers that, that do have it. It might be, it might not. I don't, I don't know.

Doc Searls (00:55:15):
<laugh> we'll see. We're find out. Yeah. Yeah. Right. Um, so I, I wanna ask a, uh, the diversity question, which is, it may be unanswerable, you know, there, I mean Linox Journal itself had was for a while entirely staffed by women while the readership was 100% male. Um, and we, there's nothing we could do about that. And I don't know whether, it seems to be the way Linox Curl development works, it's, it's basically just who shows up. But have you thought much or talked much among your cells or Alpha maintainers and so forth about, about getting more women and other folks, uh, involved?

Greg Kroah-Hartman (00:55:57):
Yes, we talk about this all the time and we've talked about this for years. Um, I know John Corba talked about this as well. I mean, we are at the mercy of the end of the supply chain, right? <laugh>. So there's not much we can do, but there's work we can do to feed the top of the supply chain. So we do a lot there. Um, we have produced even a report saying at our best guess here is what our numbers are. And it looks like we are even better than Python when python's pretty good as far as contributions. So we're a little bit above the corporate average on contributions. It's hard to guess what we are on. That being said, we have, we work with Outreach e we work with, um, another Lennox Foundation intern project. Uh, we work with another couple, um, Google Summer of Code.

(00:56:39):
Um, we get lots and lots of interns in. And the big problem, well it's a problem is that these people go through the intern project and then they get hired and that helps them a lot because then they're often, they get a better job and they do really good work and they are often other companies and sometimes those companies don't give them the chance to contribute back to the colonel, which is fine. That's up to them what they wanna do. But, um, so we're helping the betterment for on individual level, whether we're helping the betterment for the project or level, if that's, that might be a second additional bonus someday in the future or not. I'd rather take the first, you know, help these people out. Um, some of the stories we have of people, um, changing their lives because they've made it through the intern project of outreaches is just amazing.

(00:57:22):
So if you go back and look and see what that's been done, um, and that's great and I really encourage that and support that. I have been a mentor many, many, for many, many years. Been a mentor for Google Summer Code since the beginning. And, um, strongly encourage working with students I work with. That's what moved to Europe, uh, work with the university here in the Netherlands. That they're the people that found Spectrum Meltdown. They do really good systems work. It's the university where 10 Mountain's from, um, and it's all Linux all everywhere in there. Um, and one of their graduate students just spoke at the plumber's, um, conference the other day, or a couple about a month ago. Uh, so they're doing really good system level research with the university's students and that's where you get involved. That's where you show them that kernel development is not some special scary thing and everybody can do that and then that helpfully will trickle down and do better.

Doc Searls (00:58:11):
So we're basically at the end of the show. Where, uh, is there anything we haven't asked you yet that you'd like to answer in a short, in a short way?

Greg Kroah-Hartman (00:58:20):
I can't think of anything. No. Always email me and ask me or have me on again. This is fun,

Doc Searls (00:58:26):
<laugh>. Yeah, no, this is fun. I I wish we had an hour and a half or two hours. Um, the, uh, so we always answer end this with, with two questions, which are, um, this kind of our controlled questions. What are your favorite text editor and scripting language?

Greg Kroah-Hartman (00:58:41):
Favorite X Editor is via Vim Viam. Um, I've used it for forever. Um, I, that being said, university, I to learn EMAX and use it there, but then I got into the real world and it was nowhere, but VI was everywhere so I, um, and then, um, I'm sorry, what was the second question?

Doc Searls (00:58:59):
Oh, I text, uh, scripting language.

Greg Kroah-Hartman (00:59:01):
Scripting. Uh, I still have a fondness for Pearl <laugh>. So, um, I got insulted. I got insulted once by somebody at a company saying, you write Pearl Code like a C programmer. And I was like, yes, <laugh>. Um, so that being said, I do write, I do write some ba a lot of Bash. Um, I have been forced to learn Python thanks to Constantine, our colonel.org Toman who writes a lot of our helper scripts and Python, so helping him out. So, um, I'm slowly converted over to a dark side of Python, but I still rely on a bunch of pearl stuff.

Doc Searls (00:59:34):
<laugh>. That's fantastic. Well, well Greg, it has been absolutely awesome having you on the show. Um, we should have had you on sooner. We'll have you on again cuz things will change <laugh>. Sure, glad to. This is fun and we didn't talk enough. This is great. This is the, I think possibly the fastest hour we've had <laugh>, it seems. Yeah,

Katherine Druckman (00:59:55):
For sure.

Doc Searls (00:59:57):
They're all about the same, but this is, this is faster. So thank

Greg Kroah-Hartman (01:00:00):
You for thanks a lot for having me. This was fun. I I really enjoyed it.

Doc Searls (01:00:03):
<laugh>. Great. So guys, um, how was that for you?

Katherine Druckman (01:00:09):
It was great. I I, yeah, I think we could, we could talk for several hours, but, uh, yeah. Are we, are we officially in the post show? I don't know, <laugh>. I can't

Doc Searls (01:00:18):
Remember how this works, but not yet. No, we're not, we're not in a Okay,

Katherine Druckman (01:00:21):
Okay. Are in

Doc Searls (01:00:22):
A PO show. No, we're not in a po show.

Jonathan Bennett (01:00:24):
Where, where are we? But

Katherine Druckman (01:00:25):
I feel like I

Doc Searls (01:00:26):
Could ask, we're the,

Katherine Druckman (01:00:27):
I dunno where we're,

Doc Searls (01:00:28):
We do the plugs and then I talk about next week the plugs of course, and say goodbye. So do your plugs while I see who's going on next week. <laugh>.

Katherine Druckman (01:00:36):
Oh, okay. Well, I can, I can do a plug. I, um, well there's the first, there's, there's our other podcast that's Reality 2.0. Uh, you can find us on podcast Players everywhere. The other is, uh, open.intel.com. I've started writing a few things there. Uh, you'll, you'll see, you'll see my name pop up more and more I hope. And, um, yeah, I just posted something about Eeb p f and so yeah, watch that space.

Doc Searls (01:01:04):
Mm-hmm. <affirmative>.

Jonathan Bennett (01:01:06):
All right. So that was a lot of fun to have, have Greg on. And, uh, we thank him for humoring our, our questions. Some of them got very nerdy, but that's, that's part of the fun. I love that. That was No, that's, that's always, that's always fun to talk to him and it's always fun to get to talk to somebody, you know, in the know. And, and like I said, there's some of these questions that it would be really weird to ask on the mailing list, but we, we, we got him here just to ourselves for an hour and got the nerd out about them and that was great <laugh>.

Doc Searls (01:01:32):
Yeah, it was, it was good having on the show, um, we, uh, I think I've only seen Greg at conferences. I was once talking to somebody who said, I didn't know you existed where there was an industrial flooring, you know, because that was the only place we we ever met. Uh, but I, I, you know, but it's, it's great. It's great to have him on a show. He's always, always been fun to talk to. So, okay, so next one I'm gonna ask a lot more. Yeah, I know. We'll think of all kinds of questions later. Um, next week we have on Alex Belo and I'm hoping I'm pronouncing that right, Belo and I don't have the next thing that tells me what <laugh>, what he does. Trust me, anybody with a hard pronounced name is good to, to have on the show. So <laugh>. So that's coming up next week and uh, and until then, stay tuned and, uh, I

Jonathan Bennett (01:02:26):
Need to, I do need to jump in, doc, I just got whispered into my ear. I've got an ask me anything coming up on the 17th on the Club Twit Discord. So anyone that has any burning questions for me, hopefully not Tim many gotchas, but we'll do those two. Uh, make sure to get 'em in and then catch that on the 17th. Uh, gotta be part of Club Twit to get in on that. Uh, and then while you're there, make sure and check out the Untitled Linux Show, where we talk about the Linux News from the week. And that goes, uh, we, we do that live Saturday afternoons. Have a lot of fun there,

Doc Searls (01:02:59):
Right? It's, it is a great show too. So <laugh>. Okay guys, thanks so much. Um, I'm Doc sles, we will see you next week.

Ant Pruitt (01:03:08):
Hey folks, I'm Ant Pruitt. I have a question for you. How do you think your hard working team with a Club TWiT corporate subscription plan? Of course, show your appreciation and reward your tech team with a subscription to Club TWiT. Keep everyone informed and entertained with podcasts, covering the latest in tech with the Club TWiT subscription. They get access to all of our podcasts at free, and they also get access to our members only Discord, uh, access to exclusive outtakes and behind the scenes footage and special content like the fireside chats that I enjoy hosting. Plus, they also get shows like Hands on Mac, hands on Windows, and the Untitled Linux Show. So go to twit.tv/club twit and look for corporate plans for complete details.