for historical (Arm didn't used to have an enumerable bus to find devices, in the way the PC has PCI) and economic (vendors want to do as little work as possible, so they hack up one kernel version to run on their hardware then move on to the next hardware) mainline kernels haven't been able to boot on Arm devices. some absolutely heroic work has happened over the last fifteen years or so and it's now much better and we're now reaping those benefits - hardware can run normal mainline kernels and so expect to get "security updates" and "features" over time instead of being frozen on one version or carrying massive invasive annoying decaying patches against mainline.
The kernel newbies link in TFA is usually worth reading, albeit a bit technical / low level. (Haven't done it yet and haven't followed the kernel recently, so cannot comment how complete it is this time / at the moment)
FYI, this release adds supports for the networking chip in the X870E Taichi motherboards. If you're building a new AM5-based workstation, this release might be specially useful.
A new major release of the Linux kernel happens every ~8 weeks. There are usually 7 or 8 release candidates (-rc1, rc2, etc) released on successive Sundays during that period, followed by a release of the major version. That's the workflow the Linux kernel has used for years.
> Each major version – identified by the first two numbers of a release version
For the last decade, the first number gets bumped once the second number reaches 19 or 20. This has been consistent since 3.x.
> So decades of work to make it finally real-time safe is not worth it.
Haha you can't actually be serious? Thomas Gleixner's goal was to get Real-Time patches merged, not to get an aesthetic version bump, because nobody cares about the version number.
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.
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:)
Full semver is an illusion. It's often debatable what is a new feature (we support a previously unsupported functionality) vs. what is a bug fix (it did not work correctly before).
Also what is a non-compatible change is not always clear. Did the user do it wrong in their existing code or did the project make an incompatible change?
The kernel has said for long times that they don't make
incompatible changes. We don't break user space as they say. So you could prefix their numbers with an imaginary "1.". Of course sometimes opinions vary, whether a change breaks userspace or breaks wrong code.
That said the kernel numbering scheme is weird. Increasing the first digit after 19 *or* 20 is less logical than imperial units.
> The kernel has said for long times that they don't make incompatible changes
Which is also not entirely true, as sometimes bad or obsolete functionality is dropped (e.g. /dev/mem). Given how big the kernel is, probably all versions would be a semver bump for one of it's many subsystems.
What for? Every kernel release is equal as far as maintainers are concerned, the list of features that go in depends on what is ready in time. They would have to change release processes significantly to accommodate "major versions", and I don't think they would want to do that.
Also, the kernel doesn't really have an external kernel API, the user API is supposed to be 100% stable, and its internal kAPI is nobody else's business, so there's one less reason for semver.
Why then confuse users with the first dot? The second dot having a meaning makes it even more confusing. Just drop the first dot like Chrome and Firefox did.
But why does that matter? They are as large as they are, a dot in between doesn't change that.
The only thing I can imagine is trying not to break scripts looking at the kernel version and expecting two dots. If that's the case it makes more sense to use the OpenBSD way and increase after 9.
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.
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.
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.
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.
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.
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.
For regular releases without semver, I'd slightly prefer a version number that contained the year (and possibly month), like Ubuntu does it. Gives immediate feeling for how old (or young) a version is.
This will also be an LTS (Long-Term Support) release.
Really good podcast on why this is an exciting release: https://youtu.be/6J3Ym0XkZDw
Is there something I could read instead of listening to an hour plus long podcast?
Linux 6.12 Preps For Release With Real-Time, Sched_Ext, Stable Xe2 & Raspberry Pi 5:
https://www.phoronix.com/news/Linux-6.12-Feature-Reminder
I don't get the Raspberry Pi part. Prior kernel versions already run on that device?
Not mainline. Distros that support Rpi ship a fork of the kernel
for historical (Arm didn't used to have an enumerable bus to find devices, in the way the PC has PCI) and economic (vendors want to do as little work as possible, so they hack up one kernel version to run on their hardware then move on to the next hardware) mainline kernels haven't been able to boot on Arm devices. some absolutely heroic work has happened over the last fifteen years or so and it's now much better and we're now reaping those benefits - hardware can run normal mainline kernels and so expect to get "security updates" and "features" over time instead of being frozen on one version or carrying massive invasive annoying decaying patches against mainline.
Will this help fix hardware longevity for any of these legacy google device uses?
- android / any forks out there nowadays?
- chromeos device linux
there's two separate problems:
1. Qualcomm doesn't give a fuck about mainline linux
2. technical issues that have been worked on as described above
as far as I know, 1) is as yet unsolved for this issue
The kernel newbies link in TFA is usually worth reading, albeit a bit technical / low level. (Haven't done it yet and haven't followed the kernel recently, so cannot comment how complete it is this time / at the moment)
https://kernelnewbies.org/Linux_6.12
eBPF powered custom schedulers aka SCHED_EXT and the preempt RT stuff sound really nice.
FYI, this release adds supports for the networking chip in the X870E Taichi motherboards. If you're building a new AM5-based workstation, this release might be specially useful.
[dead]
[flagged]
A new major release of the Linux kernel happens every ~8 weeks. There are usually 7 or 8 release candidates (-rc1, rc2, etc) released on successive Sundays during that period, followed by a release of the major version. That's the workflow the Linux kernel has used for years.
[flagged]
What a strange comment. Are you trolling?
Yes, projects can use their own version scheme.
The Linux kernel has been using this version scheme for over a decade. If you think it's inconsistent then that's a you problem.
My problem is that Linus didn't bump it on this major change. His versioning scheme is that he bumps whenever it feels like it.
So decades of work to make it finally real-time safe is not worth it. This shows his precedences. It's not latencies. The industry will recognize
No, the versioning scheme is that the first two numbers are the major version.
From https://en.wikipedia.org/wiki/Linux_kernel_version_history :
> Each major version – identified by the first two numbers of a release version
For the last decade, the first number gets bumped once the second number reaches 19 or 20. This has been consistent since 3.x.
> So decades of work to make it finally real-time safe is not worth it.
Haha you can't actually be serious? Thomas Gleixner's goal was to get Real-Time patches merged, not to get an aesthetic version bump, because nobody cares about the version number.
Linus Torvalds can do whatever he wants. Fork it if you don't like it.
Actually, yeah, everyone in the world can pretty much go and invent their own random version numbering scheme if they want to.
And Linus Torvalds particularly.
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.
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:)
Full semver is an illusion. It's often debatable what is a new feature (we support a previously unsupported functionality) vs. what is a bug fix (it did not work correctly before).
Also what is a non-compatible change is not always clear. Did the user do it wrong in their existing code or did the project make an incompatible change?
The kernel has said for long times that they don't make incompatible changes. We don't break user space as they say. So you could prefix their numbers with an imaginary "1.". Of course sometimes opinions vary, whether a change breaks userspace or breaks wrong code.
That said the kernel numbering scheme is weird. Increasing the first digit after 19 *or* 20 is less logical than imperial units.
> The kernel has said for long times that they don't make incompatible changes
Which is also not entirely true, as sometimes bad or obsolete functionality is dropped (e.g. /dev/mem). Given how big the kernel is, probably all versions would be a semver bump for one of it's many subsystems.
What for? Every kernel release is equal as far as maintainers are concerned, the list of features that go in depends on what is ready in time. They would have to change release processes significantly to accommodate "major versions", and I don't think they would want to do that.
Also, the kernel doesn't really have an external kernel API, the user API is supposed to be 100% stable, and its internal kAPI is nobody else's business, so there's one less reason for semver.
Why then confuse users with the first dot? The second dot having a meaning makes it even more confusing. Just drop the first dot like Chrome and Firefox did.
As the comment above stated - so that the numbers don't grow too large
But why does that matter? They are as large as they are, a dot in between doesn't change that.
The only thing I can imagine is trying not to break scripts looking at the kernel version and expecting two dots. If that's the case it makes more sense to use the OpenBSD way and increase after 9.
Kernel version scheme has been bikeshedded for decades already, See LKML if you want to contribute further
So what new feature set would be more major than PREEMPT_RT? Anybody will remember the great 6.12 for years, whilst 7.0 will be forgotten in a month.
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.
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.
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.
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.
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.
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.
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
Sure but the world would also be better without out of tree patches which don’t track the mainline.
Yeah, I wish they have just used dates for user-facing releases. At least, it would contain some useful information.
For regular releases without semver, I'd slightly prefer a version number that contained the year (and possibly month), like Ubuntu does it. Gives immediate feeling for how old (or young) a version is.
Linux uses their own versioning scheme of Version/Patchlevel/Sublevel. See their Makefile.
Despite the sibling comments (and wikipedia), the major/minor terminology is not used.