Monsters, Ghosts, and Bugs: How to Choose a Kernel
summary
Explains the kernel release cadence (two-week merge window, weekly RCs) and shows that most regressions land during merge window; stable updates accept only small, self-contained fixes (typically <100 lines) tagged CC: stable; LTS is chosen roughly once a year and receives maintenance until the next LTS; Fedora rebases to mainline quickly while enterprise kernels backport specific features (the so-called Franken kernels) which reduces churn but requires many experienced engineers; warns that running a custom kernel forces responsibility for security backports and merge conflict resolution.
AI-written summary · about
chapters (24)
- 0:00Intro
- 0:21What kernel is running on your system?
- 0:35Why are you running that kernel?
- 0:49Monsters, Ghosts, and Bugs
- 1:31The Upstream Kernel Release Process
- 3:44Merge Window
- 3:59Busy for maintainers
- 6:27When will my patch go in?
- 8:34What exactly is going into stable updates?
- 12:39Stability vs. Features
- 13:08Features! Hardware! Awesome!
- 14:24Unexpected bugs (less awesome)
- 16:29"Frankenkernel" (Scary monster!)
- 17:33Actually, Frankenstein was the name of the creator
- 18:40Stable kernels test the limits of review
- 20:30Embedded
- 22:28Android: success story
- 24:01Learn how to engage the community
- 24:49Open Source means you can do this!
- 25:28What do kernel maintainers do all day?
- 27:18Backports are effort
- 30:08Distributions are not perfect
- 30:29Wrapping up
- 31:05Thank you! (come see me at the Red Hat booth)
related talks
35mKeeping the linux kernel secure across 10+ RHEL releases
17mSustaining Yesterday’s Linux: Delivering Security for Today’s Workloads
34mDelivering Security Fixes Continuously Into Your Embedded Linux
36mStatus of Embedded Linux
28mKernel CVEs are Alive, but Do Not Panic!
41mKernel Live Patching at Scale
20mPrioritizing the Linux OS Hardening and CVE Mitigation
44mBackporting is so 1993
