On the first morning of Open Source Summit Europe 2026 in Prague, the week Linux turned 35, I sat down with Greg Kroah-Hartman for a Udienza interview. Greg maintains the Linux stable kernels, which are the releases most of the world actually ships. He was generous with his time: our “ten minutes” ran to almost fifteen.
These are the highlights. Quotes are from our recording, lightly edited for clarity.
What he works on
When I asked him to introduce himself, Greg listed a lot more than the stable kernels:
“I maintain the stable kernel trees, and lots of parts of the driver core, and the security team, and lots of different parts of the kernel. And I also work with the EU on the CRA, and legal issues, Linux Foundation stuff, lots of things like that.”
AI tools are finding bugs, and that is “boring but important”
I asked what is interesting in his work right now. His answer was the most honest description of AI in kernel development I have heard:
“Well, it’s not very interesting. It’s boring. AI or pattern-matching tools found bugs in our code. So just another tool is finding bugs in our code, and we’re grinding through them all and fixing them. So it’s not interesting. It’s important. But it’s just a lot of work.”
He explained what these tools actually do, without any hype:
“The simplest thing they do is: here’s all the bugs we’ve fixed in the past, where have we not fixed them today in our code? It’s fuzzy pattern matching. And it works really well, by the way.”
Most of what they find are “small, tiny bugs all along the way”. This is the same wave the security keynotes in Prague described, seen from the maintainer’s chair, and it is part of why the kernel now issues thousands of CVEs a year.
How big is “the kernel” on your device?
I asked how many lines of code they work on. The answer was a lesson in how little of the kernel any one machine runs:
“Millions and millions. 25 million, 30 million lines of code in the kernel. But you don’t run all that. Your servers are actually really simple: maybe 2 or 3 million lines of code. You’ve got a disk, a network, and that’s it. Your laptop may be 3 to 4 million. But phones are the most complex beasts out there, like 4 or 5 million lines of code, because there’s all the different chips and all the sensors and all the graphics.”
That is a useful reminder for anyone triaging kernel CVEs: most of the code they apply to is not in your build.
RISC-V and the hardware-agnostic kernel
I told Greg I am a fan of RISC-V. His view is that the Linux abstraction is exactly what gives a new architecture a chance:
“The nice thing about RISC-V is you can replace the processor and everything that works on Linux works on it. So a RISC-V company can come out with a really good chip and compete on equal ground with everybody else.”
He added that the ecosystem has “some growing pains” in getting chips working properly, but now that there is a standard, he has good hope for it. And he described how the kernel community works with Intel, AMD, Arm and other chip vendors on a very long horizon:
“CPU design cycles are long. If you work on something today, it’s going to take four to six years before it comes out. So we complain about something now, and maybe in five years we’ll see it. But we’re in it for the long haul.”
For more on the hardware side, see my notes on RISC-V on the show floor in Prague.
The CRA is an ingredients list
Greg spent much of 2025 working with the EU on the Cyber Resilience Act, so I asked how policy and sovereignty affect the kernel. His summary of the CRA is the clearest I have heard:
“Basically, it’s just like an ingredients list of all the software that’s in the device. And it has to be kept up to date for all known vulnerabilities for a number of years. It’s the same thing you have to do for food or paint. It’s a good thing to have.”
And on what it means for open source:
“The EU commissioners know that open source is important. The requirements on the open source communities are very minimal. And it’s actually good: they’re forcing people who use our software and ship it to send us the bug reports, which they haven’t always done.”
On sovereignty, his answer was about choice, not politics. Linux lets you run your own systems without depending on another company, and kernel developers work with governments, including the Dutch, French and German ones, to show them how:
“We’re not forcing anybody. If you want to, you can. You can own your own systems and work that way. And that’s very important for everybody.”
This is the practical side of the State of Open Source in Europe report, which Greg wrote the foreword for. For the CRA details, see my notes on CRA SBOM requirements.
Advice for new talent: contribute while you study
I asked what he would recommend to someone entering the job market today. He works with universities, including one in Amsterdam, where master’s students this summer researched security bugs found by AI tools. His advice:
“When you’re at university, you’re writing programs for the first time: solve this problem, solve this problem. But in the real world you have to work with an existing code base and work well with others. When you contribute to an open source community, it shows you know how to work with other people and how to modify code that’s already there. Those are skills university doesn’t really teach you, and that sets you apart from other candidates.”
He pointed to Google Summer of Code (the kernel has participated “since the beginning”), Outreachy, and the Linux Foundation’s mentorship programme. One of the speakers in Prague started in the LF internship programme and now speaks at conferences around the world and has a job at a Linux company.
AI in code review: a bot as the first reviewer
On AI and the kernel (and Rust, which he noted is “independent of AI”), Greg described a tool the community runs on submitted patches:
“When you submit a change to the kernel, it runs a whole bunch of checklists and sees whether it’s right or not. It’s a bot that says: you forgot this, and this might be a problem there. It’s public, everybody sees it, and it’s the first step of a code review. I submitted some patches a week or so ago, and it found problems that I forgot about.”
He also pointed out that none of this is new to the kernel: the community has used the ideas behind these tools to pick fixes for stable backports “for 10, 15 years now”.
No master plan
My favourite answer was to “how do you see the future?”:
“I don’t know. Linux responds to what is sent to us. We don’t have a plan for it. If you have a problem with Linux, or you want it to solve a different thing for your product, send us a change, and we’ll iterate from there. I don’t have a plan, except I want to see Linux keep working for everybody.”
On scale, he described how the work is split among roughly 700 maintainers responsible for their own areas, merged and tested together every day, with thousands of developers from hundreds of companies each year. Maintaining that for 35 years is, in his words, “a whole different skill” from writing a project once. The kernel community has shared those lessons with younger projects, including Kubernetes when it started to scale.
His favourite part of the job
“Seeing Linux in places I didn’t expect. It’s in my washing machine, it’s in satellites, it made it to Mars. We’re a tool that people use to solve their problems, and it’s fun seeing it used in unexpected ways.”
Thank you, Greg. The full episode will be published on udienza.com.
