Open Source Summit Europe 2026 shared its week in Prague with the Linux Plumbers Conference and the Kernel Summit. For a media partner, that meant one thing: the people who actually maintain the kernel were all in the same building. On the first day I spent my Udienza slots with them.
Udienza is my ten-minute video show with the people who build what the rest of us run on. No panel and no product pitch, just one engineering idea on camera. Here is who I met, what I wanted to ask, and why each conversation matters if you run Linux in production. That is everyone.
Greg Kroah-Hartman: what keeps the kernel sustainable
With Greg Kroah-Hartman in the registration hall on Wednesday morning.
Greg Kroah-Hartman maintains the Linux stable kernels, which is to say the releases most of the world actually ships. When I wrote to him before the event, he said yes within the day, and we met near the badge desk late on Wednesday morning.
Greg also wrote the foreword to the new 2026 State of Open Source in Europe report, which was presented in the keynotes that same morning. That report found that Europe writes about 44% of the kernel’s code. That makes the kernel’s sustainability a European question as much as a technical one.
The angle I brought was the less visible side of maintaining Linux at scale:
- What keeps the kernel sustainable after 35 years?
- Where is maintainer workload becoming dangerous?
- Which habits from contributors and companies make the biggest difference to long-term project health?
These questions matter more in 2026 than ever. As the security keynotes showed the same morning, AI tools are producing bug reports faster than maintainers can triage them. The kernel is a CVE Numbering Authority and assigns CVEs to its own fixes, so every stable release now carries a long list of them. If you consume kernels, the most useful thing you can do for Greg is simple: run a supported stable or LTS kernel, and update it. Do not cherry-pick fixes into a frozen tree and hope.
Arnaldo Carvalho de Melo: 20 years of pahole
Arnaldo Melo (Red Hat), still wearing the lavalier mic, with Marcin Czupryniak, who filmed the Udienza interviews in Prague.
Arnaldo Carvalho de Melo maintains perf tooling and pahole, and works at Red Hat. I had seen the “20 years of pahole” session he gave with Alan Maguire at Linux Plumbers, and asked for ten minutes on it. He was one of the quickest yeses of the week.
If you have never heard of pahole, you have still used it. It started as a tool to show the layout of C structs: where the holes and padding are, and how fields map to cache lines. Today it produces BTF, the BPF Type Format, during the kernel build. BTF is what makes BPF CO-RE (compile once, run everywhere) possible: an eBPF program can be built once and adapt to different kernel versions at load time, because the kernel describes its own types. Every modern eBPF-based tool, from Cilium to the observability agents in your cluster, depends on it.
That is the story I wanted on camera: how a small developer tool becomes infrastructure. My questions were:
- How did pahole evolve from data-structure analysis into something essential for BTF and BPF CO-RE?
- What lessons come from maintaining the same tool for two decades?
- How is AI-assisted development changing work on perf and pahole?
At the end of the day, Arnaldo suggested I also reach out to Steven Rostedt, the ftrace maintainer, while we were all in Prague. That is how the hallway track works.
If you work with eBPF, my notes on eBPF for Kubernetes security and Cilium networking show where BTF ends up in practice.
Konstantin Ryabitsev: b4 and maintainer workflows
Konstantin Ryabitsev runs kernel.org infrastructure at the Linux Foundation and is the author of b4, the tool that makes the kernel’s email-based workflow bearable. We planned a Wednesday afternoon slot, tied to his Kernel Summit session on b4’s maintainer-oriented features.
The angle here is one that every large project will face:
- How is Linux’s email-based development workflow evolving under maintainer overload?
- What can good tooling automate without damaging the social review process?
- What does b4 reveal about the future of large-scale open source maintenance?
The kernel still runs on mailing lists, and people outside it often assume that is nostalgia. It is not. Email is decentralised, works offline, and keeps review in plain text that anyone can archive. b4 keeps those properties and removes the drudgery: fetching a patch series, applying it, collecting the review trailers, sending new revisions. Making maintainers faster without centralising the process is a design choice worth studying, especially for projects that are about to be flooded with AI-generated patches.
What I take away for production teams
- Stay on supported kernels. The stable maintainers do the backporting so you do not have to.
- Know your BTF. If you deploy eBPF tooling, check that your kernels ship with BTF enabled (
CONFIG_DEBUG_INFO_BTF). CO-RE depends on it. - Respect maintainer time. Send fixes upstream, test release candidates, and do not dump unreviewed AI-generated patches on mailing lists.
The Udienza episodes from Prague will be published at udienza.com. In the meantime, the first Udienza episode, with MariaDB creator Monty Widenius, shows the format. My Open Source Summit Europe 2026 recap has the rest of the week.
