"On the other hand, the strongest argument for some people advocating 4.0 seems to have been a wish to see 4.1.15 - because "that was the version of Linux skynet used for the T-800 terminator"."
No, I think it is from the awful mess that was "Terminator:Salvation" based on the file name (I can't recall the screen from the film, but then again it's a film that it is best to just forget. Go watch Terminator: The Sarah Connor chronicles instead while waiting for T5):
Nah, that's the CPU the Terminator used because it's the only design that can survive time travel. Skynet probably uses something a lot more modern. The Terminator himself runs his consciousness routines on bare metal.
It's a feature that makes the kernel to lie to old userspace programs that insist on only supporting Linux 2.6.
By calling personality(2) with PER_LINUX | UNAME26, uname(2) will from then on pretend that you're actually running linux 2.6.something.
This is meant as a workaround for software you don't have the source code to and which does some crazy checks for the version, assuming it doesn't support anything but 2.6.
Here's the source of a little wrapper utility you can use to invoke such broken software with:
The switch from 2.4 to 2.6 had a lot of changes and a lot of programs needed to check the version to see which behavior to use. There are two ways to do that shown below in psuedo-python. This first way has no trouble with 3.x versions.
if kernel_version.startswith('2.4.'):
DO_A
else:
DO_B
On the other hand, if you check for 2.6 instead of checking for 2.4... Well when it encounters 3.0 the code falls back to 2.4 behavior.
if kernel_version.startswith('2.6.'):
DO_B
else:
DO_A
Sadly a number of binary only RAID tools don't really get updated much and have these problems. There is a program in util-linux named uname26 that you can run these tools under which gives them the 2.6.40+ version numbers.
This is just one of those tricks operating systems have to resort to from time to time, its like how Microsoft is skipping Windows 9 because of how many programs execute version.startswith('Windows 9') and assuming that means Win95/Win98.
Basically, some programs had issues working with Linux 3.x version numbers, so the kernel can lie to these and say that its version isn't, say, 3.0, but actually 2.6.40. This was implemented by just taking the kernel minor version number and adding 40 to it and tacking that on to "2.6."
So, the problem here is that version 4.0 has that same code, so it's also going to fake-report its version as 2.6.40 when using the UNAME26 personality.
A surprisingly large amount of code still works. If your code is statically linked the syscalls have not changed, due to Linux's backwards compatibility guarantees, and if it was dynamically linked against glibc the glibc compat may work, or you can just use the old glibc and linker.
How much useful code there is that cant be recompiled I dont know, but I am sure people have some, and they probably dont want to run it in an old unsupported distro.
As others have chimed in, while working extremely well for _libraries_, which I believe Semantic Versioning was really proposed for in the first place anyways, it does not work or necessarily make sense for Kernels which are kind of a very special kind of library.
Once matured, kernels tend to never break backwards compatibility (or try very hard not to), and rarely track bug fixes with individual numbering. Often many changes are lumped into a single version update, because so many changes are already happening across many different subsystems.
I suppose also, now that I think about it, Semantic Versioning works much better for smaller scoped and smaller scale projects (like well scoped and designed libraries). The kernel is such a large piece of software almost like a collection of libraries hidden behind a single set of matures APIs that incrementing counters for every bug fix or tiny change doesn't make sense---and as has been established, major numbers would just never bump.
This makes sense, but then why have a version number that looks like semantic versioning? If they are randomly jumping major versions (2.6 -> 3, now to 4) they might as well drop the major version altogether.
Why not go for a release number (e.g. r85) and a patch number for hotfixes (e.g. r85.2)?
There are no hotfixes (from Linus, the stable branches are a different matter). And basically the release is just a snapshot of updates that happen to build together with some nudging and silly letters from Linus.
Best would be to just go and use a year.month number. 2014.12, 2014.02, 2015.04. But ultimately, it's just a semi-unique identifier with a lot of context that one should be aware of. (And it's not like you can go and buy a Linuks 4 in stores right now, or just put it into your requirements.txt. So confusion is very minimal, it's just a "tag".)
"Well, that's a span of 15 years right there. 2.what?"
"Uh, 2.6.something."
"Okay, that's a start. That narrows it down to a span of 8 years, almost a factor of two in improvement."
If they were to adopt semantic versioning, they'd NEVER bump the major version number in a hundred years. Think about this: when was the last time that changes to the Win32 API broke your application? Linux is also like that.
With this scenario in mind, could it make more sense to adopt a version scheme incorporating the initial release date (or considering the kernel workflow, merge window date), similar to ubuntu? "I'm running linux 15.2.4, aka. the 4th update to the kernel from Feb 2015"
Plenty of Linux changes have broken my system - removal of devfs, breaking of not only binary module compatibility but even source compatibility (e.g. I can't build my qc-usb webcam driver any more).
There is no in-kernel API/ABI. The Kernel team is very vocal that the only interface that exists for the kernel is the userspace systemcall/filesystem interface, and any code that wants to use anything beyond that really should live in the kernel tree. Things like the nvidia closed-source driver that hooks into the kernel itself are not using any API/ABI, they are basically just hooking into structures where the people maintaining those structures don't just not care about being compatible, but are actively hostile to people relying on their code remaining same across versions.
Yep, if we were to say that in kernel struct changes mean a major release in semantic versioning, there would never be anything but major releases.
Even though for all of them the user space api wouldn't break. So yeah, I think the people harping on semantic versioning don't quite understand the reason its not a good fit for an os kernel.
So far, the arguments against it seem to have been "major numebr
should go with a major new feature or breaking of compatibility",
which just shows how little people know. We don't break compatibility,
and we haven't done feature-based releases since basically forever.
Because Kernel changes should never break backwards compatibility, so that would mean the major version number would never change, making it worthless.
And you'd end up with very large numbers for the minor numbers, which Linus seems to dislike.
Linux used to version in a different way which was somewhat semantic, but actually moved away from it because it's significantly less useful for kernels, as explained in other replies.
The latest mainline 3 version of the Linux kernel is: 4.0-rc1
The latest mainline 3 version of the Linux kernel is: 3.19
The latest stable 3.18 version of the Linux kernel is: 3.18.7
The latest longterm 3.14 version of the Linux kernel is: 3.14.33
More like, "Every time Linux begins to converge on perfect, the outside world changes what 'perfect' means, and Linux has to evolve towards that, instead."
Linus has emitted the most elegant description of the Internet that I've ever seen.