The treadmill is real Posted Aug 9, 2026 21:36 UTC (Sun) by gray_-_wolf (subscriber, #131074) [Link] (3 responses) > All users [..] must upgrade. I am not even done testing the previous one and new one is out already. One would hope for a stable series to be somewhat... stable. Getting new one every what, 3 days, is kinda nuts. The treadmill is real Posted Aug 9, 2026 23:05 UTC (Sun) by himi (subscriber, #340) [Link] It's a bit nuts, but it's not like the devs have a whole lot of options when there are significant vulnerabilities being published so regularly . . . At my day job we're looking at defining a policy that's pretty much "all systems must be running the latest kernel no more than X weeks after a new release is available" (with X varying depending on the type of node, its exposure, the impacts/risks of rebooting, etc) - so the clock starts when the first new release comes out, the upgrade targets whatever the latest release is when time runs out (with some allowance for testing and validation), and the clock stops when all systems have rebooted into the new kernel. The only exceptions would be if a new vulnerability that specifically impacts us, in which case we'd pull forward the next deadline for the impacted systems being up to date. No arguments about whether each new kernel is worth bothering with, no debates about every single CVE, no pushing things back because rebooting everything is too hard - we decided we needed to track an LTS branch for good reasons and this is what that means in practise. It's not wonderful - it means a significant amount of churn that takes time from more productive work - but it's hard to see an alternative that doesn't leave us running with known and exploitable vulnerabilities. And sadly, that seems to be the reality we're living in right now . . . The treadmill is real Posted Aug 10, 2026 3:48 UTC (Mon) by yodermk (guest, #3803) [Link] (1 responses) Yeah but in virtually all cases, I think it's fine to install and reboot on your own schedule. Unless you have potentially hostile local users or running some untrusted software, then it might be a bit more urgent. How many people actually update production systems straight from the upstream anyway? As opposed to just following your distribution updates and using their kernels. The treadmill is real Posted Aug 12, 2026 0:37 UTC (Wed) by richarson (subscriber, #74226) [Link] From my experience with AlmaLinux and Ubuntu (I work for a web hosting company), there's not much difference tracking upstream or distro kernels. The new kernels just keep coming and we have to update and reboot, or risk our users and/or systems. For shared hosting we have kernelcare which fortunately helps us avoid some reboots, or at least delay them. For the rest of our infra, most of it is using some sort of HA so rolling upgrades and reboot without downtime is possible. YMMV
Posted Aug 9, 2026 21:36 UTC (Sun) by gray_-_wolf (subscriber, #131074) [Link] (3 responses)
I am not even done testing the previous one and new one is out already. One would hope for a stable series to be somewhat... stable. Getting new one every what, 3 days, is kinda nuts.
The treadmill is real Posted Aug 9, 2026 23:05 UTC (Sun) by himi (subscriber, #340) [Link] It's a bit nuts, but it's not like the devs have a whole lot of options when there are significant vulnerabilities being published so regularly . . . At my day job we're looking at defining a policy that's pretty much "all systems must be running the latest kernel no more than X weeks after a new release is available" (with X varying depending on the type of node, its exposure, the impacts/risks of rebooting, etc) - so the clock starts when the first new release comes out, the upgrade targets whatever the latest release is when time runs out (with some allowance for testing and validation), and the clock stops when all systems have rebooted into the new kernel. The only exceptions would be if a new vulnerability that specifically impacts us, in which case we'd pull forward the next deadline for the impacted systems being up to date. No arguments about whether each new kernel is worth bothering with, no debates about every single CVE, no pushing things back because rebooting everything is too hard - we decided we needed to track an LTS branch for good reasons and this is what that means in practise. It's not wonderful - it means a significant amount of churn that takes time from more productive work - but it's hard to see an alternative that doesn't leave us running with known and exploitable vulnerabilities. And sadly, that seems to be the reality we're living in right now . . . The treadmill is real Posted Aug 10, 2026 3:48 UTC (Mon) by yodermk (guest, #3803) [Link] (1 responses) Yeah but in virtually all cases, I think it's fine to install and reboot on your own schedule. Unless you have potentially hostile local users or running some untrusted software, then it might be a bit more urgent. How many people actually update production systems straight from the upstream anyway? As opposed to just following your distribution updates and using their kernels. The treadmill is real Posted Aug 12, 2026 0:37 UTC (Wed) by richarson (subscriber, #74226) [Link] From my experience with AlmaLinux and Ubuntu (I work for a web hosting company), there's not much difference tracking upstream or distro kernels. The new kernels just keep coming and we have to update and reboot, or risk our users and/or systems. For shared hosting we have kernelcare which fortunately helps us avoid some reboots, or at least delay them. For the rest of our infra, most of it is using some sort of HA so rolling upgrades and reboot without downtime is possible. YMMV
Posted Aug 9, 2026 23:05 UTC (Sun) by himi (subscriber, #340) [Link]
At my day job we're looking at defining a policy that's pretty much "all systems must be running the latest kernel no more than X weeks after a new release is available" (with X varying depending on the type of node, its exposure, the impacts/risks of rebooting, etc) - so the clock starts when the first new release comes out, the upgrade targets whatever the latest release is when time runs out (with some allowance for testing and validation), and the clock stops when all systems have rebooted into the new kernel. The only exceptions would be if a new vulnerability that specifically impacts us, in which case we'd pull forward the next deadline for the impacted systems being up to date. No arguments about whether each new kernel is worth bothering with, no debates about every single CVE, no pushing things back because rebooting everything is too hard - we decided we needed to track an LTS branch for good reasons and this is what that means in practise.
It's not wonderful - it means a significant amount of churn that takes time from more productive work - but it's hard to see an alternative that doesn't leave us running with known and exploitable vulnerabilities. And sadly, that seems to be the reality we're living in right now . . .
Posted Aug 10, 2026 3:48 UTC (Mon) by yodermk (guest, #3803) [Link] (1 responses)
How many people actually update production systems straight from the upstream anyway? As opposed to just following your distribution updates and using their kernels.
The treadmill is real Posted Aug 12, 2026 0:37 UTC (Wed) by richarson (subscriber, #74226) [Link] From my experience with AlmaLinux and Ubuntu (I work for a web hosting company), there's not much difference tracking upstream or distro kernels. The new kernels just keep coming and we have to update and reboot, or risk our users and/or systems. For shared hosting we have kernelcare which fortunately helps us avoid some reboots, or at least delay them. For the rest of our infra, most of it is using some sort of HA so rolling upgrades and reboot without downtime is possible. YMMV
Posted Aug 12, 2026 0:37 UTC (Wed) by richarson (subscriber, #74226) [Link]
For shared hosting we have kernelcare which fortunately helps us avoid some reboots, or at least delay them. For the rest of our infra, most of it is using some sort of HA so rolling upgrades and reboot without downtime is possible.
YMMV
Copyright © 2026, Eklektix, Inc. Comments and public postings are copyrighted by their creators. Linux is a registered trademark of Linus Torvalds
LWN