Hacker News
points by kccqzy 1 day ago | 0 comments
In the age of AI, there are only more and more security vulnerabilities to be discovered, and backporting all of them to outdated kernels will be nigh impossible. I’d not rather make such security patches dependent on the timeliness of backports especially if it is done by a distro rather than upstream. I suggest you use a rolling distro rather than anything with LTS kernels. The CVE in the original post CVE-2026-98432 is fixed since 7.3. If a distro doesn’t offer kernel 7.3.1 today, rule it out. (7.3.3 is also out today.)

In general I find distros using old kernels annoying because Linus treats compatibility seriously and “don’t break use space” has been a mantra for many years. On desktops in particular, GPU driver improvements like https://www.phoronix.com/news/Linux-7.3-DRM make it super worthwhile.

As for exactly which distro, it matters less than you think. I use openSUSE Tumbleweed but plenty of my friends prefer Arch.

[–] 1over137 1 day ago
>...I suggest you use a rolling distro

This doesn't seem to be popular with linux though. It's one thing I like about FreeBSD, everything is easy to keep very bleeding edge.

Maybe Debian 'testing'?, is that commonly run in prod?

[–] jolmg 1 day ago
>>...I suggest you use a rolling distro

> This doesn't seem to be popular with linux though.

Nobody ever got fired for buying IBM.

Nobody ever got fired for choosing Java.

Nobody ever got fired for choosing Debian.

It's a bandwagon effect. Though, it can also be a matter of common familiarity if you're not the only admin.

[–] SahAssar 1 day ago
That is a wild take, especially consider the GP asked for a server use-case. Do you just assume that all new versions should be taken as soon as possible for all packages?

There is a balance: too outdated is bad, too eager for new versions is bad. The tradeoff that LTS tries to take is older, proven versions but with relevant security fixes quickly.

[–] kccqzy 1 day ago
Not a wild take at all. Most server use cases already use containers to precisely specify what the server workload depends on, and can only access what's in the container. I see no reason for the base system to move slowly with proven versions. Even if you don't use containers, you most likely already use language-specific tools to lock in your dependencies. Leave these to the app developers and the sysadmin can move at any speed.