Linux 4.15 Becomes Slowest Release Since 2011

An anonymous reader shares a report: Linus Torvalds has decided that Linux 4.15 needs a ninth release candidate, making it the first kernel release to need that much work since 2011. Torvalds flagged up the possibility of an extra release candidate last week, with the caveat that "it obviously requires this upcoming week to not come with any huge surprises" after "all the Meltdown and Spectre hoopla" made his job rather more complicated in recent weeks. Fast-forward another week and Torvalds has announced "I really really wanted to just release 4.15 today, but things haven't calmed down enough for me to feel comfy about it."

In more ways than one?

[subk]

Let's hope it doesn't also run slower than it did in 2011

Re:

[subk]

Yes, that's exactly what I think. To that end, I expect a kernel from today should perform better than or equal to a similarly configured kernel from yesterday, and indeed that has been the trend. While the Linux kernel has grown in some areas, it has gotten leaner in others.

Re:In more ways than one?

[TheRealMindChild]

Do you remember the move from 2.4 to 2.6? 2.6 all of a sudden made those "light" linux distros for old computers unusable in a large amount of cases.

Re:

[mrvan]

Ludwig, is that you? :P

Re:

[thegarbz]

Yes. Unusably FAST! We covered this in quite a bit of detail on the Slashdot of old [slashdot.org]. The summary is quite good with it's description: 2.6 kernel "creams" the 2.4

Re:

[kyrsjo]

Wasn't that mainly about size? AFAIK 2.4 was the last that could fit comfortably on a floppy disk.

Re:

[Jeremi]

Wasn't that mainly about size? AFAIK 2.4 was the last that could fit comfortably on a floppy disk.

Are you referring to the 1.44MB 3.5" floppies, the 360KB 5.25" floppies, or the original 80KB 8 inch floppies?

As far as I can tell, they are all equally relevant at this point, since nobody uses any of them.

Re:

[hcs_$reboot]

It easily runs slower. Do you think software performance improves faster than hardware performance?

Algorithms improvement? Like improving concurrent accesses tools? Memory management (malloc/free are expensive)? Optimizing hardware utilization and compatibility? This is the Linux kernel - a newer release\ might work faster (better) than an older one.

Re:

[hcs_$reboot]

Let's hope it doesn't also run slower than it did in 2011

That's what they try to do. Don't forget that besides the microcode, the kernel also has to integrate some Meltdown/Spectre "mitigation" code, which is likely to alter performances.

Re:

[Chrisq]

Let's hope it doesn't also run slower than it did in 2011

Since it includes the Meltdown fix it will do on Intel processors

Re:

[Anonymous Coward]

This slow it is not about the OS speed, it is about the new version publication.

Easy fix

[110010001000]

Obviously if Linus adopted an Agile strategy this wouldn't be an issue. He just needs to setup some sprints and things will work out.

Re:Easy fix

[freeze128]

Imagine how Linux Kernel development will progress once Linus steps down. He isn't going to live forever, you know. I doubt that his replacement would be as tenacious.

Re:Easy fix

[110010001000]

He could be replaced by a seasoned Certified Scrum Master (SCM). You just have to make the SCM is Certified by http://www.scrumalliance.org./ [www.scrumalliance.org] Otherwise it will just be some crazy process nut who is more concerned about the process than the final product. You might think that anyone can write and release software, but you really need to be certified. You just can't have uncertified regular people releasing software! That would be insane!

Greg Kroah-Hartman already runs most development

[raymorris]

If Linus is the king of the kernel, Greg Kroah-Hartman is the Prime Minister. He makes as many development decisions as Torvalds does, and he's ready to take over as BDFL.

Re:

[DeVilla]

You don't have to look far to find someone to say something bad about him. I don't know GKH well enough to criticize his skills. He does seem to get things done. I do think he's far too polite to take Linus' place. That's not saying a person needs to be a jerk to do the job. But you need to bluntly tell people no, regardless to how they may respond. I don't see GKH that way.

Re:

[hcs_$reboot]

Unfortunately, the replacement could be the kind it was for Apple in 2011. Tim Cook is not that bad as a regular CEO, it's just that Jobs was exceptional.

Comment removed

[account_deleted]

Comment removed based on user account deletion

Get it right the first time

[Anonymous Coward]

I prefer Linus's "try to get it right the first time" approach to releases versus the, unfortunately, too common "get it out the door as quickly as possible, we'll fix it later" approach employed by seemingly almost everyone else. (I'm looking directly at you, Microsoft. And Apple's getting a bit of stink-eye, too, given the flurry of patches for the dodgy current macOS and iOS versions.)

Re:

[umghhh]

In our house we release when it compiles, does this qualify for 'first time right' or 'it wobbles trough the door' strategy?

Re:

[slashdot_commentator]

Eh. It seems to me that the Linux kernel is a mature product, thus dead one. Most of the significant changes are really addressing hardware changes, rather than implementing new concepts to enhance computing.

The Linux kernel is monolithic, meant for the hardware age of standalone computer. When it comes to optimizing cloud architectures or quantum computers, they will probably be best advanced with totally new implementations of OS.

When Linux dies, the people who only really care about the advancement of

Title is misleading; slowest PROCESS since 2011

[Khopesh]

This is the slowest Linux kernel release process, not the slowest kernel itself.

Re:

[arth1]

This is the slowest Linux kernel release process, not the slowest kernel itself.

It could very well be. It's the first new release with pmi (which closes Meltdown like risks, but both makes system calls slower and uses more memory).
And the kernel has become more and more bloated. The absolute minimal kernel to run on any given hardware is much bigger today than it was a few years ago. 2.6.17 is the last one I could fit on a floppy. 2.6.35 is the last one that's practically feasible to run on a system with 128 MB RAM or less.

Re:

[hcs_$reboot]

Not sure "slowest process" is the appropriate term talking of a kernel. "Slowest release completion" might be better.

Most of us don't need that much speed on nix.

[mohsel]

Let's face it, how is this speed difference going to affect the largest majority of linux userbase ?

Re:

[Barefoot Monkey]

The title is somewhat misleading. Linux isn't running any slower than before; it's just that the developers have taken longer to release version 4.15 than they have for any other version since 2011, partly due to all of Intel's recent mishaps. This doesn't actually affect anyone much at all (unless you've been anxiously awaiting some or other new feature) - it's just an observation that some might find interesting.

Re:

[mohsel]

My bad then ! thanks for noticing :) I could use a slower release process for my comments too ! Still on point though, as much as speed of code execution, the speed of the releases aren't that critical for most users. for the rest, they could use the RCs or join the party by committing resources to the development process if that bit of features is that important to them.

Good!

[GerryGilmore]

I, for one, am glad to see that someone is taking a more measured, thoroughly tested approach rather than the usual "OMG! Quick - flash new BIOSes, gimme new CPUs, install the latest kernel patches regardless of testing...." approach that has characterized the approach from "the technical community" so far.

Re:

[110010001000]

Blasphemy. Do you know what would happen if you had to wait for a more measured, tested approach??? You would miss your sprint!

Re:

[hcs_$reboot]

This. Indeed.

most unprotracted

[epine]

All that extra time, and the slow story authors still didn't manage to rummage around in their duffel bag of virtuous clarity long enough to fish out the phrase "most protracted".