Monsters, Ghosts, and Bugs: How to choose a kernel
summary
Explains the kernel release schedule: a two-week merge window then weekly release candidates until a stable release, with stable updates shipped until the next kernel; warns a Fedora-style rebasing policy gives new features but risks regressions (4.19 caused block-layer filesystem corruption); describes LTS trees, enterprise “Franken” kernels that pick patches selectively, and the CC: stable tagging workflow. Recommends tracking an upstream LTS branch, not running custom kernels on production without steady backport maintenance.
AI-written summary · about
chapters (21)
- 0:00Start
- 1:04What kernel is running on your system?
- 1:19Why are you running that kernel?
- 2:06The Upstream Kernel Release Process
- 6:58Find the bugs!
- 7:23When will my patch go in?
- 9:22What exactly is going into stable updates?
- 10:33Machine learning for stable patches
- 13:21What kernel do distros run?
- 13:53Stability vs. Features
- 15:14Unexpected bugs (less awesome)
- 16:25LTS = steady performance
- 16:56Kernels that don't track LTS?
- 19:34Stable kernels test the limits of review
- 23:36Android: success story
- 25:39Learn how to engage the community
- 26:37Open Source means you can do this!
- 27:32Distributions usually give good kernels (100% biased)
- 28:16What do kernel maintainers do all day?
- 34:11Distributions are not perfect
- 34:56What do you want your kernel to do?
related talks
41mChallenges Around Long-Term Kernel Maintenance
34mAn SRE Guide to Linux Kernel Upgrades
25mLinux: Where Are We Going
39mThe Life of a Kernel Bugfix
34mAn SRE Guide to Linux Kernel Upgrades
27mAn SRE guide to Linux Kernel upgrades
35mKeeping the linux kernel secure across 10+ RHEL releases
41mThe Kernel Report