←back to thread

Linux kernel 6.12 has been released

(lwn.net)
147 points nitinreddy88 | 8 comments | 18 Nov 24 03:12 UTC | HN request time: 0.996s | source | bottom
Show context
rurban[dead post] ◴[18 Nov 24 06:03 UTC] No.42170111[source]▶
[flagged]
bonzini ◴[18 Nov 24 06:41 UTC] No.42170298[source]▶
There's no minor and major. All releases are equivalent but the first number is bumper when the second becomes large enough, which happens every 2-3 years.
replies(2): >>42170403 #>>42170988 #
yjftsjthsd-h ◴[18 Nov 24 07:04 UTC] No.42170403[source]▶
In fairness, that is a weird versioning scheme, and I really do wish that Linux either switched to full semver (in which case it'd be version 2.9000.0 or so by now) or just drop the leading digit and go full build number kinda like NT does. But as cousin comments note, not my project not my call:)
replies(4): >>42170564 #>>42170621 #>>42171003 #>>42171115 #
1. nolist_policy ◴[18 Nov 24 07:47 UTC] No.42170564[source]▶
I like qemu's version scheme were the major version increases every year (since version 4.0). So x.1 the first release in a year and you can see from a quick glance how "old" a version is.
replies(2): >>42170617 #>>42170847 #
2. yjftsjthsd-h ◴[18 Nov 24 07:59 UTC] No.42170617[source]▶
I don't mind date-based versions, though if you're going to do that I feel like it'd be easier to go all the way? I can't tell how old qemu 4.0 is, but even without knowing details I would feel pretty confident in roughly when a hypothetical qemu-2024.1 had been released.
3. dessimus ◴[18 Nov 24 08:58 UTC] No.42170847[source]▶
I would think most if not all of the enterprise distros would object as generally they lock their kernel versions for the duration of a "release" lifecycle and backport security fixes from newer kernels to the version they chose.

They wouldn't want users thinking they were still using a "2024" kernel in 2032, for example, when they have 10+ years of support to provide.

replies(1): >>42171214 #
4. RandomThoughts3 ◴[18 Nov 24 10:27 UTC] No.42171214[source]▶
Note that the world would be significantly better if entreprise distros stopped doing that and just shipped the latest kernel. I understand freezing user space because most developers don’t care about shipping stable software and break compatibility all the time but the kernel takes its pledge to never break user space very seriously.

The backporting is very much hit and miss.

replies(2): >>42172294 #>>42176199 #
5. bonzini ◴[18 Nov 24 13:55 UTC] No.42172294{3}[source]▶
Regressions in upstream kernel exist; they may be security issues, assertion failures, performance regressions, and so on. It's just too much work to validate a whole new kernel every six months, and also much harder to pinpoint a regression. People have tried shipping the latest kernel; it's the same in all environments, from enterprise distros to network appliances to phones, people end up sticking to an upstream release and do backports on top.
replies(1): >>42176866 #
6. yjftsjthsd-h ◴[18 Nov 24 19:51 UTC] No.42176199{3}[source]▶
The one difference is that in at least some cases RHEL freezes things to provide a stable kernel ABI - https://access.redhat.com/solutions/444773
replies(1): >>42176837 #
7. RandomThoughts3 ◴[18 Nov 24 20:49 UTC] No.42176837{4}[source]▶
Sure but the world would also be better without out of tree patches which don’t track the mainline.
8. RandomThoughts3 ◴[18 Nov 24 20:51 UTC] No.42176866{4}[source]▶
I have been using upstream kernels on multiple machines including network equipments for more than a decade now. I will take the risk of regressions over back ported patches any day.

Apart for regulations mandating vulnerable (we can call them outdated if you prefer being coy) versions, the elephant in the room is obviously non mainlined drivers but I wouldn’t touch that with a ten feet pole anyway.