There are reports all over the net about free-software projects that are scrambling to keep up with the LLM bug flood. But perhaps we should also spare a moment's thought for the hidden people who must be running hard to keep the enterprise-distribution frankenkernels secure in the face of all this. They cannot be having much fun trying to figure out what to backport and how to do it. That, perhaps, is why certain enterprise distributors have yet to ship a fix for CVE-2026-98432, while Debian patched it almost two weeks ago.

I have long wondered how long the frankenkernel model would be sustainable ... the answer has been "a lot longer than I would have ever thought". Even so, I have to wonder how likely the deluge is to make this whole model fail catastrophically. Those kernels are far from the mainline at a time when it seems clear that one wants to run as close to current mainline kernels as one can get.

@corbet

Backporting is fraught with gotchas.

You must make sure all of the header files used at the time match the header files at build time of kernel.

Fortunately, this is not a major problem with #Debian

@corbet great point.

@corbet

Going off piste can be fraught with excitement, right up to the point when the cap of snow over a crevasse collapses under you and you discover that 9.81 ms^-2 can be really unpleasant when combined with too many m.

@corbet As someone who works on embedded Linux stuff... there's nothing I would rather do than run the latest mainline all the time. But so often, the "official" solution to doing something I need is to patch the kernel. Want to speak SPI? Write a kernel driver; spidev is deprecated. Wanna play audio over your I2S interface? Fuck you, write a sound card driver, we don't support exposing I2S interfaces to userspace. The result is a kernel that's hard to keep up to date.

@corbet This would've been perfectly fine, FWIW, if there were stable kernel APIs I could write a driver against. But as you know, the kernels APIs are explicitly unstable, and in practice, they change enough that this becomes an obstacle to upgrading kernels.

Then there are vendor kernels. And the fact that the Yocto version and the kernel version is usually tied together and upgrading Yocto is a pain sometimes. But those things aren't the kernel's fault at least

@corbet LLM flood feels tame compared to when the "everything is a cve" thing started. At least when you're drowning in work you tune out all the AI crapola and current dread in our minds resulting of where the industry is heading right now

@corbet Machines are telling us where mistakes were made. Apparently, we made a lot of 'em, but on a project such as Linux - it's no wonder. I've compiled my first one when it had 1M lines of code, and it allowed me to find, understand and fix any problem I knew I had with it ever since. I ran mainline on server distros when I was bored. Kept it simple when I wasn't. To be efficient and free, develop and fix upstream or start over - but then you shouldn't even try to be everything to anything.

@corbet IMHO the whole "enterprise software" concept with no updates has failed.

@gurubert @corbet The model has always been built on the attempt at bridging goals that are often in opposition with each other.

The effort would have been better spent at overcoming the (unfortunately quite real) "updates suck" in the software/UX world.

But that would have yielded results only much later and people needed to deploy somewhere closer to schedule.