Linux 4.0-rc1 out | Hacker News Reader

Linux 4.0-rc1 out

lkml.iu.edu

254 pointsakerl_50 comments

"the people have spoken...most of it was complete gibberish"

Linus has emitted the most elegant description of the Internet that I've ever seen.

I have tears in my eyes.

"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"."

Makes total sense :)

I propose that the kernel version asymptotically approach 4.1.15 until all the features of skynet is supported by the kernel.

I think it's systemd, one day it becomes self aware.. and wants to run humanity.

Much in the same manner as the AI in I, Robot.

Nah, 4.1 will be a LTS release and embedded systems are notorious for using ancient kernels.

Looking forward to seeing the 6502 as a supported architecture in Linux 4.x!

For anyone unaware of the aforementioned reference, in the first Terminator movie, the code visible in the terminators HUD was 6502 assembly.

Images and more reading: http://www.pagetable.com/?p=64

We got to add that for linux 4.1 someone get on that.

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.

Reference: http://www.reddit.com/r/linux/comments/2vyhr6/apparently_ter...

Is that screenshot taken from the upcoming Terminator: Genisys film?

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):

mate_2015.02.15.051456.utc-smplayer-2009-terminator-salvation-mp4_16-9.jpg

So with the release of 4.1.15, that will truly be the year of Linux, hitching a ride with the much bigger year of the terminator.

It might also be close to the end of humanity, but at least it finally terminated Windows.

I already found version number breakage. The UNAME26 compatibility hack was missed.

https://lkml.org/lkml/2015/2/23/6

what is uname26, and what is the hack?

See the original commit for it [1].

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.

[1] http://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.g...

Isn't that kind-of okay though? If a program now started to depend on 2.6.43 (or any other >= 40 version), isn't it seriously broken anyhow?

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.

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:

http://mirror.linux.org.au/linux/kernel/people/ak/uname26/un...

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.

Thank you for the explanation.

> like how Microsoft is skipping Windows 9 because of how many programs execute version.startswith('Windows 9') and assuming that means Win95/Win98.

Has this been confirmed, or is it just internet speculation?

This isn't confirmation, but it certainly goes beyond speculation.

https://searchcode.com/?q=if%28version%2Cstartswith%28%22win...

From what I understand, that Java API would not return "Windows 9". So while those tests are wrong, it would not cause a problem.

I have not seen a single case proposed that would actually break.

Didn't realise that -thank you :)

Two people on reddit claiming to be Windows devs "confirmed" it. https://www.reddit.com/r/technology/comments/2hwlrk/new_wind... https://www.reddit.com/r/technology/comments/2hwlrk/new_wind...

The following lines appear to still be creating a string starting "2.6.".

Is there a specific reason that the Linux kernel team has given for not adopting semantic versioning? Or has the discussion just never been started?

Probably because of this:

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.

"What version of Linux are you running?"

"Uh, 2.something."

"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).

The stable API/ABI is for _user_ space, not kernel space.

If the userspace API/ABI never changes, maybe a more useful use of the version number would be to reflect kernel API/ABI changes?

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.

Java had been 1.x since 1996. Sun took to using the minor version as the everyday name - so 1.8 is Java 8 - and that seems to have worked okay so far.

I have no idea what Oracle or whoever will do if 2.0 ever does come out. But I doubt it ever will.

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".)

I actually thought that, but you'd still end up with things like 2014.12-r7 because you end up creating different versions when you backport fixes.

Because the semantic versioning meme appeared tens of years (!!) after people started using x.y.z versions for software (including Linux).

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.

It has tricked the https://www.kernel.org/finger_banner page:

    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

Interesting how this is the opposite of Knuth's converge-on-pi versioning system.

Guess Linux ain't perfect?

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."

I believe TeX is not adding new functionality now; only fixing bugs.

Linux keeps getting more features all the time, so an asymptotic numbering scheme doesn't make as much sense.

I remember last time the concern with going from 2.x to 3.x was that version parsers would break. Is that still a concern today?

Reply on news.ycombinator.com