Welcome to the Slashdot Beta site -- learn more here. Use the link in the footer or click here to return to the Classic version of Slashdot.

Thank you!

Before you choose to head back to the Classic look of the site, we'd appreciate it if you share your thoughts on the Beta; your feedback is what drives our ongoing development.

Beta is different and we value you taking the time to try it out. Please take a look at the changes we've made in Beta and  learn more about it. Thanks for reading, and for making the site better!

Is the Stable Linux Kernel Moving Too Fast?

Soulskill posted 1 year,11 days | from the committed-to-committing dept.

Operating Systems 156

darthcamaro writes "Yesterday the stable Linux 3.10 kernel was updated twice — an error was made, forcing a quick re-issue. 'What happened was that a patch that was reported to be broken during the RC [release candidate] review process, went into the release, because I mistakenly didn't pull it out in time,' Greg Kroah-Hartman said. The whole incident however is now sparking debate on the Linux Kernel Mailing List about the speed of stable Linux kernel releases. Are they moving too fast?"

cancel ×


Sorry! There are no comments related to the filter you selected.

TDD (0)

Anonymous Coward | 1 year,11 days | (#44636275)

TDD, BDD anyone ?

Re:TDD (1)

Nemesisghost (1720424) | 1 year,11 days | (#44636311)

Neither will guarantee defectless & errorless code. They help, but you still need to do more. If you are relying only on either, then your process is broken.

Too Fast? (2, Insightful)

Jeremiah Cornelius (137) | 1 year,11 days | (#44636355)

Let me try and catch up to it, and ask...

Seriously. Why is this even a question? Did a new stable release show up in your watch or your laptop - or your in flight entertainment system, over night?

Packagers and distribution maintainers aren't exactly up in arms about this...

Re:TDD (4, Insightful)

greg1104 (461138) | 1 year,11 days | (#44636335)

"the fun thing about a kernel is that there is no good way to test it except to run it" [] --Greg Kroah Hartman

I work on PostgreSQL, and nothing goes out until it's been validated on the entire buildfarm [] . It's hard to have such a thing for the Linux kernel though, because it's so easy for a bug to break test machines. You need to catch when machines are responding, do a hardware reset, and then rollback to a known good kernel instead. It's much harder than most software testing to automate.

Re:TDD (2)

malacandrian (2145016) | 1 year,11 days | (#44636879)

Doesn't check it works perfectly on all hardware, but a good chunk of the testing could be done on VMs running monkey-scripts which are simply disposed of & a new image spun up if they break. That said, automating hardware resets [] is hardly an unsolved problem.

Re:TDD (3, Interesting)

greg1104 (461138) | 1 year,11 days | (#44637001)

The logs of the machines that break are the most important part of the test results here. You can't just throw them away when a VM dies without losing most of the testing value. If you're lucky, a busted kernel will stay alive long enough to create a crash dump when running on dedicated hardware. That's less likely to happen on VMs.

It's also possible to automate hardware resets with IPMI [] or similar lights-out management code. All of that takes special hardware though, and test code like this is painful to build.

Re:TDD (4, Insightful)

The_Wilschon (782534) | 1 year,11 days | (#44638369)

For the purpose of release testing, though, the only thing you care about is whether or not there was a crash. If there was a crash, don't release. Back out the busted patch and release the working version. Then you can spend your time debugging the busted patch, which requires the logs and all.

Re:TDD (1)

cheater512 (783349) | 1 year,11 days | (#44637065)

VMs create a single 'hardware' platform. You aren't testing more than a fraction of the kernel.

And your automated resets will let you boot a new kernel easily (so does 'reboot' anyway), but if it does break you can sit there resetting over and over again in to the same broken kernel. Yay!

Re:TDD (2)

hobarrera (2008506) | 1 year,11 days | (#44637487)

You'd need VMs to emulate all sorts of hardware and architectures. We don't have all that yet. We can't emulate every mouse, network driver, etc, so there's no way to test those drivers (which are part of the kernel).

Re:TDD (3, Insightful)

ultranova (717540) | 1 year,11 days | (#44638203)

We can't emulate every mouse, network driver, etc, so there's no way to test those drivers (which are part of the kernel).

Which rises question of just why are they part of the kernel? Why does a mouse driver need to run at Ring 0?

Re:TDD (4, Informative)

MikeBabcock (65886) | 1 year,11 days | (#44639347)

You need to do some more reading on how Linux works.

Re:TDD (-1)

Anonymous Coward | 1 year,11 days | (#44638577)

Fuck Linux. It's the Windows of the UNIX-like world anyway.

Tons of compiler warnings? Who cares. Doesn't build? Fuck it, ship anyway. Crashes? You're holding it wrong.

Linux isn't designed, Linux is grown. If you're using Linux, you're used to mediocrity anyway so STFU and just pull the next -rc-beta-alpha-fuckmesideways.

Re:TDD (0)

Anonymous Coward | 1 year,11 days | (#44638617)

Wow really? There are hundreds of thousands of permutations of devices? Is he implying that each and every driver is not operating through some API but instead, everyone is freely messing around in kernel space? Laughable.

What a stupid question. (1)

Slartibartfast (3395) | 1 year,11 days | (#44636379)

Clearly, the author of the post has forgotten 3+ year intervals for kernel releases. Of the odd, quickly fixed pothole is the price of 6x release speed, "Hell, yes!" Is the answer.

Re:What a stupid question. (1)

Sponge Bath (413667) | 1 year,11 days | (#44636465)

The result is mainline kernels (including "stable") are perpetual beta. Any important machine should only run a kernel vetted and tweaked by a trusted distribution.

Re:What a stupid question. (1)

Stumbles (602007) | 1 year,11 days | (#44636659)

Ah yeah, like isn't trusted. Yes I know you said "distribution" but really now.

Re:What a stupid question. (4, Insightful)

Rich0 (548339) | 1 year,11 days | (#44637339)

Ah yeah, like isn't trusted. Yes I know you said "distribution" but really now.

He wasn't talking about trusting that it didn't contain a trojan or something. By trust he meant vetted for quality.

It is a legitimate concern. The whole reason for having a release cycle is to have sufficient QA to prevent issues like this from happening. Distros provide that service - when Linus/Greg call a kernel done, they call it ready to start being tested. RHEL is still running 2.6 (albeit with backports).

Re:What a stupid question. (1)

TheGavster (774657) | 1 year,11 days | (#44637741)

The problem with RHEL is that the true version of any package (for compatibility purposes) is the part after the dash. They'll call it "2.6.18" (I think that was the RHEL5 kernel), but really it's got most of the patches (but not all!) up to a much more recent version. If you have a piece of software from outside the RH repositories, and you want to know if your libraries are sufficiently up to date, you need to go dig up the SRPM for the version of each that you have installed and peruse the changelog feature checking for what has and has not been backported from the "real" latest version. I've never been able to find a magic decoder ring from RH proper to make this process of getting the true package version anything less than absolutely hellish.

WHAT THE FUCK! WHAT THE FUCK!!! (2, Interesting)

Anonymous Coward | 1 year,11 days | (#44636469)


I can't believe this. I've been reading Slashdot since 1998, and I have never seen such a stupid suggestion in all that time.

Test-driven development is not the solution to this problem. And my good gawd, behavior-driven development is even farther away from the solution than fucking test-driven development is.

Behavior-driven development is one of the biggest loads of shit to splash upon our profession in years. Customers and analysts will write tests? Riiiiiiiiiiiiight...

All that we get from BDD is half-arsed tests that don't work and clients or analysts who cry to high heaven about how they hate writing them. And we programmers can't just rewrite them in Java or C# or Python or C++ or whatever our project is using. Noooooooo! They all require stupid English-like syntaxes that need to be translated down into real code by some turdy tool named after a vegetable.

Fuck TDD. Fuck BDD twice over. And please, for the love of all that is good, NEVER suggest that either of them be used seriously, especially for a critical piece of software like the Linux kernel.


Anonymous Coward | 1 year,11 days | (#44636595)


I can't believe this. I've been reading Slashdot since 1998, and I have never seen such a stupid suggestion in all that time.


OK, one of those two must be blatantly false.


Motard (1553251) | 1 year,11 days | (#44636609)

Thanks Linus, but I think it's an established rule that you can't go releasing new versions of software until the ridicule surrounding your last release has died down. How else are we going to get stories for /.? Microsoft plays along. Why can't you?


Zeromous (668365) | 1 year,11 days | (#44638163)

Only said fuck four times not including subject. Not Linus.


hermitdev (2792385) | 1 year,11 days | (#44638311)

If I had mod points, you'd be given one. I have Linus giving the finger to nVidia as my desktop wallpaper at work. That being said, I'm more of a Windows guy. I work on Linux, predominantly, and I use Windows as home exclusively (except for around 4 VMs) because I'm a gamer.


Anonymous Coward | 1 year,11 days | (#44638949)

"I work on Linux, predominantly, and I promote Windows in tech forums exclusively (except for around 4 VMs) because I'm a tosser."



Billly Gates (198444) | 1 year,11 days | (#44639467)

... Microsoft plays along. Why can't you?

Fucking Linus and Alen Cox are greedy mofus! No more supported updates for kernel 2.2 after April 2014 WTF!!

It still works fine and I am not willing to change just to make them happy

Software does not have rusticles form. It does not age and we had a good thing running back in 2001 in kernel 2.2 and it makes no sense at all to throw out a perfectly working and I do not want to run some bloated kernel with useless utilities and eye candy for teenagers.

We have software that is very expensive to change and you all hipsters on slashdot and the LKML fail to understand! All hardware better support it or we wont make your product and not one slashdotter or Linux user has given me a reason to change?

I can browse the web with Netscape just fine as Root as /dev/modem wont work with a wheel user account, so why should I change?

No (5, Insightful)

Stumbles (602007) | 1 year,11 days | (#44636307)

its moving along just fine. People make mistakes, get over it, its not the end of the world. Considering its current release speed, the amount of changes made over the long term the Linux kernel folks have as good or better track record than most other software houses.

Re:No (0)

Anonymous Coward | 1 year,11 days | (#44636557)

Seems any slip in the Linux world is heavily scrutinized by their own community. Feels a bit like self-sabotage.

Re:No (2)

Stumbles (602007) | 1 year,11 days | (#44636689)

Well everyone has bellybuttons but that doesn't mean we all should gaze upon the great naval; at least for to long else your eyes will burn out.

Re:No (2)

vilanye (1906708) | 1 year,11 days | (#44636955)

That is the way it should be.

That's how Linux can thrive dispite the chaos of getting patches from 1000's of independant programmers.

Re:No (0)

Anonymous Coward | 1 year,11 days | (#44636965)

>> Feels a bit like self-sabotage.

Feels a bit like it is working as intended.

Re: No (4, Interesting)

Brien Coffield (3026589) | 1 year,11 days | (#44637933)

I prefer to think that an immediate response from the community is a sign of an active and concerned user base. It might be worse if the community insisted on staying on LTS-type releases.

Re: No (2)

TCM (130219) | 1 year,11 days | (#44638665)

As if you can't have both. That's what branches are for! Duh.

But of course you'd have to understand branches and their use first. Why call it stable if it's just another testbed where everything is shipped regardless? If "stable" is moving so fast that bugs that are already recognized cannot be pulled back in time, something is just wrong.

Re:No (1)

Runaway1956 (1322357) | 1 year,11 days | (#44638513)

Self flagellation is preferred over allowing the greater world to whip you mercilessly.

Re:No (3, Interesting)

CAIMLAS (41445) | 1 year,11 days | (#44636745)


The current process resulted in us having CFQ + EXT3 as the default for a long time (some distros still have this). This basically means any sort of interactive performance is worse than horrible. The only reason we're beyond it now is because EXT3 is on its way out with EXT4 being preferred.

IIRC, wasn't CFQ one of the first major infrastructural things put into 'stable' after this 'rapid release' approach was adopted?

Also, udev.

I'm sure there are other examples... and maybe I'm projecting a bit.

Re:No (1)

cheater512 (783349) | 1 year,11 days | (#44637113)

CFQ only comes in to play when accessing new uncached data from disk when disk is at medium-high usage (at low usage any read/write queues are empty).
I'm struggling to figure out any interactive programs that fit that description. Web/email/documents/games etc... don't touch the disk in any significant way and the cache handles most disk accesses for them anyway.

Re:No (1)

Anonymous Coward | 1 year,11 days | (#44638533)

CFQ under ubuntu 12.04 lts produces studders and freezing of applications with only one or two VM running.

BFQ is a million times better. Thank goodness for the liquorix kernel.

Re:No (3, Interesting)

jhol13 (1087781) | 1 year,11 days | (#44638453)

Linux (the kernel) is accumulating new security holes at least at the same speed as they are fixed.
Proof: Ubuntu kernel security hole fix rate has been constant for years.

(actually I have not counted the actual number of holes, only the actual number of kernel security patches - these two should correlate though).

Re:No (1)

tibman (623933) | 1 year,11 days | (#44638623)

How does the Kernel drive what your disks are formatted to? Your disks are formatted to ext3 or 4 long before you config/compile the Kernel.

Re:No (1)

dAzED1 (33635) | 1 year,11 days | (#44638717)

yeah, I'm a bit confused by his comment too. Is he suggesting the ext4 support is not available? Because does the kernel (otherwise) have to do with what formatting is "default?"

Re:No (1)

MikeBabcock (65886) | 1 year,11 days | (#44639363)

The current process didn't result in that at all. Your distro chose that default and could've changed it any time they liked.

Get involved with your distro if you care so much and help them choose sane defaults.

Re:No (1)

Shark (78448) | 1 year,11 days | (#44636825)

All in all, I think it's a nice problem to have. Compare that to the kernel being stagnant, it's great that being able to include submitted code safely and fast enough becomes an issue to look into. I doubt MS or any of the other big software companies have issues where features and improvements are being *produced* so fast that QA is unable to keep up. I suspect that they have more of an issue with them being *requested* faster than the company can provide.

Re:No (1)

msobkow (48369) | 1 year,11 days | (#44637011)

Timely releases of the Linux kernel don't hurt anything anyhow, because most of the packagers and distributors don't release the updates until they've had further testing. In fact, most distros lock in at a particular kernel release, and backport patches to *that* release rather than updating the whole kernel.

So there are really three levels: dev, stable, and production.

Re:No (0)

Anonymous Coward | 1 year,11 days | (#44637033)

People make mistakes, get over it, its not the end of the world.

Linus ripped one of the kernel devs for making almost the exact same statement.

Re:No (0)

Anonymous Coward | 1 year,11 days | (#44637311)

People make mistakes... and airplanes fall from the sky, cars crash, and infotainment systems BSOD.

Linux is used in those environments of the above examples, and though folks will hate it, the kernel development for the sake of development is moving along fine. For power users that have no need for kernel hacking, this is very bad, cause all marketing, university professors, and customers only see what's in the latest release (i.e. new features), and dev teams are directed by them in the end... hence creating heartache as you update to the latest kernel and breaks all you apps, video drivers, and even booting (typically). You can't have them in mission critical systems (or just important systems) as they are released.

In the end this is good as it will force mission critical developers that use linux to either:
a. support older, more stable versions that are feature rich (a compromise).
b. drop Linux

Number of changes or fixes doesn't determine track record alone, usability, compatibility, design, and robustness does as well.

Re:No (1)

gweihir (88907) | 1 year,11 days | (#44638793)

Indeed. Also anybody with some experience in rolling their own kernels with sources from knows not to use any x.y.0 releases when they want stability. Give a specific release some time to mature before using it, say 2-3 weeks. You may also have to read changelogs to find out what things were patched. There are also nice, pretty current "longterm" kernels.

That said, I have been on some current releases for some 24/7 machines and did not encounter any issues. I would say that the Linux kernel folks are doing a fine job. I can only guess that the story mistakenly assumes a freshly released kernel version is somehow "perfect". Rolling your own kernels from is not a beginners game. Get over it.

Compared to what? (5, Insightful)

bmo (77928) | 1 year,11 days | (#44636329)

"Are they moving too fast?""

Compared to what, Windows, IOS, OSX, What?

>known bug that got by review
>fixed rapidly instead of waiting for the next release

I don't see the problem.

If this was a regular occurrence, yeah, it'd be a problem. But it's infrequent enough to be "news."

Unlike Patch Tuesdays, which aren't.


Re:Compared to what? (2)

ericloewe (2129490) | 1 year,11 days | (#44636391)

Patch Tuesdays aren't news. Patch Tuesdays that break something are.

Re:Compared to what? (2, Funny)

geekoid (135745) | 1 year,11 days | (#44636695)

Now you're being redundant.

Re:Compared to what? (-1)

Anonymous Coward | 1 year,11 days | (#44637211)

You're being a cunt.

Re:Compared to what? (0)

Anonymous Coward | 1 year,11 days | (#44636961)

Patch Tuesdays that break something aren't news either.

Re: Compared to what? (2)

O('_')O_Bush (1162487) | 1 year,11 days | (#44636989)

You mean, break everything. It is rare that a MS update doesn't break *something*.

Re: Compared to what? (2)

Barlo_Mung_42 (411228) | 1 year,11 days | (#44637801)

Their massive install base works against them here. On Windows a one in a million bug will happen by next Tuesday.

Re:Compared to what? (1)

cheater512 (783349) | 1 year,11 days | (#44637117)

Although they are starting to become the norm.

Re:Compared to what? (0)

Anonymous Coward | 1 year,11 days | (#44637419)

I rote a kool program that steals credit card numberz. and micro$ofts patch borken it.

Re:Compared to what? (3)

jamesh (87723) | 1 year,11 days | (#44636455)

"Are they moving too fast?""

Compared to what, Windows, IOS, OSX, What?

Compared to a speed where accidents like this are less likely to happen, if such a thing exists. It could be that OS release cycles are unsafe at any speed!

Re:Compared to what? (0)

Anonymous Coward | 1 year,11 days | (#44639025)

Moving too fast compared to the speed of available broadband in USA. I'm sure if Greg had faster connection he would have been able to pull it out in time.

Re:Compared to what? (3, Informative)

MikeBabcock (65886) | 1 year,11 days | (#44639371)

Which would be why you should use an actual distribution kernel and not the compile-it-yourself variety if you need stability and testing.

What's good. (3, Insightful)

dutchwhizzman (817898) | 1 year,11 days | (#44636479)

Why do you have to compare it to other operating systems? Just look at what should be the right way to do it, maybe learn from other operating systems, but don't just look at the speed of what others are doing and try and match that. If things go wrong because you're moving too fast, you should either slow down, or fix your methodology so you can deal with the speed. If things don't get adapted by distributions because it's a pain to keep supporting, slow down, or make it easier for them to support it. If things go too slow and you miss essential features that everybody needs, speed it up. It's not that hard to rely on your own merits and not be dependent on other operating systems to determine how fast you should be going.

Re:Compared to what? (1)

rudy_wayne (414635) | 1 year,11 days | (#44636483)

"Are they moving too fast?""

Compared to what, Windows, IOS, OSX, What?

A long time ago, I don't remember where it was, maybe LKM, Linux Torvalds said there would never, ever be a version 3 of the Linux Colonel. I thought that was a strange thing to say, even for him. I thought to myself "things are really gomna get weird when they get to".

So now, he's changed his mind and the version numbers are zipping along. Not as fast as the absurd version number inflation of Firefox and Chrome, but still a lot faster than it used to be.

In General, I don't have any Major problems with the Linux Colonel. But I don't think it's unreasonable to say "Whoa, what's your hurry? Maybe you should slow down a little bit."

Re:Compared to what? (-1)

Anonymous Coward | 1 year,11 days | (#44636717)

The word you meant to use is "kernel" as in "'kernel of truth." It's at the center, the core, the essential part. "Colonel" is a rank or designation, especially of the military. The more you know!

Re:Compared to what? (0)

Anonymous Coward | 1 year,11 days | (#44639383)

And the person who live in the toilet is a loo tenant

Re:Compared to what? (0)

Anonymous Coward | 1 year,11 days | (#44637619)

Would anything be different if they had stayed on 2.x.x?

Of course not!

A version number, when used correctly, is just an identifier. That the proprietary world has hijacked them for marketing purposes doesn't really change anything.

Re:Compared to what? (1)

bmo (77928) | 1 year,11 days | (#44637907)

>Last sentence. []


Re:Compared to what? (0)

Anonymous Coward | 1 year,11 days | (#44637003)

Compared to itself? Why is it the Linux crowd is always trying to battle other OSs instead of just concentrating on what theirs does? So fucking hung up on Apple and Microsoft that they're missing the real big picture.

Re:Compared to what? (1)

bmo (77928) | 1 year,11 days | (#44638025)

>moderation "overrated"

Not like karma counts for anything, but I've always thought the "overrated" mod was chickenshit.

"I disagree with you, but I don't have the balls to reply"


Re:Compared to what? (-1)

Anonymous Coward | 1 year,11 days | (#44638199)

Shut up, fucktard. No one gives a fuck what you think. Go suck another faggot dick.

Released kernels are the real testbed (4, Informative)

icebike (68054) | 1 year,11 days | (#44636369)

As indicated in the debate on LKM, rc kernels get hardly any testing, although all of the tests it does get are mostly by highly motivated and astute testers

Most distros are releasing kernels at least one behind the developers tree, with not a great deal of incentive to update the kernel right away, (even if they make it available in a repository for those wanting it). So much of the real world testing on new kernels comes only after its been released, and even then it doesn't hit Joe Sixpack's machine for several months.

So at most, this was an embarrassing incident, and not a bit deal. The amazing thing is that it was caught at all. Some of us remember kernels that got into production distros with serious things broken that should have been caught much earlier.

Re:Released kernels are the real testbed (2)

NotFamous (827147) | 1 year,11 days | (#44636447)

So much of the real world testing on new kernels comes only after its been released, and even then it doesn't hit Joe Sixpack's machine for several months.

One of these days I am going to meet Joe, and I am going to complement him on his Abs.

Re:Released kernels are the real testbed (0)

Anonymous Coward | 1 year,11 days | (#44637975)

One of these days I am going to meet Joe, and I am going to complement him on his Abs.

They mean beer, not queer.

Re:Released kernels are the real testbed (1)

DocHoncho (1198543) | 1 year,11 days | (#44638663)

One of these days I am going to meet Joe, and I am going to complement him on his Abs.

They mean beer, not queer.

Thanks for the clarification, genius.

Oh, and woosh.

Re:Released kernels are the real testbed (0)

Anonymous Coward | 1 year,11 days | (#44636525)

it doesn't hit Joe Sixpack's machine for several months.

I dunno. I feel someone who uses Linux on the desktop at all is probably not a Joe Sixpack. They're either a techie, or an elderly relative of a techie.

Re:Released kernels are the real testbed (4, Informative)

CAIMLAS (41445) | 1 year,11 days | (#44636873)

From where I'm sitting, as someone who used to routinely build rc releases and use them, this is how things look.

Five, ten years ago you had people such as myself who would build RC (or AC, etc.) kernel trees to test things and see how they'd work. I know several people who regularly made LKML submissions, many of which turned out to contribute to fixes.

Today, using the rc releases isn't as practical because they're fairly divergent from distribution patchsets. A lot goes into a distribution kernel which isn't present in the vanilla kernels, it seems.

More often than not, pulling everything together to build our own kernels isn't worth the extra effort: possibly due to the shortened cycle and possibly due to general code maturity, there's little benefit. Maybe our definitions of 'benefit' has changed, too - but arguably, the changes in the kernel today are nowhere near as drastic or significant as when (say) XFS was getting merged with additional kernel and disk schedulers.

This Post is Retarded (-1, Troll)

Anonymous Coward | 1 year,11 days | (#44636411)

Nuff said

Now? (0)

Anonymous Coward | 1 year,11 days | (#44636427)

OK, so the entire stable transition from 3.4 to 3.10 went like this:

1) kernel 3.n.1 compiles. Ship it!

2) Knowing that 3.n.1 has been out for three days, GKH leaves a message like, "System builders, go fsck yourself. Kernel 3.n.1 is out, stop using kernel 3.(n-1), it won't be updated, nothing to see here. Don't care if you're Fedora and you just released a new system based on a decent kernel. It's obsolete now. Just move on."

3) kernel 3.(n+1).0-rc2 is released, with six more weeks until it becomes the new kernel 3.n

4) release kernel 3.n. Wait three days

5) repeat step 1.

And now, because of one simple human mistake, there's a debate on the pace at which stable kernels are released?!? Sheesh!

P.S. -- GKH is a good guy to me, now that he's released a new LTS kernel. He's a hard worker, and I can't blame him for the way he goes about his work.

That's what he said! (5, Funny)

fizzup (788545) | 1 year,11 days | (#44636443)

I mistakenly didn't pull it out in time.

Re:That's what he said! (0)

Anonymous Coward | 1 year,11 days | (#44637341)

I mistakenly didn't pull it out in time.

And he was also "going to fast".

The problem with oversight from two persons (1)

Mister Liberty (769145) | 1 year,11 days | (#44636473)

... is that it would move even faster.
Really, this is a non-problem. The 'system' worked.
Thank God they're no slick sleezeballs like Ballmer,
but acked and corrected.
Enjoy your new kernel. Relax. Be happy!

Nothing a few f-bombs for linus can't fix (0)

Anonymous Coward | 1 year,11 days | (#44636475)

Because everyone's obviously learned their lessons

Re:Nothing a few f-bombs for linus can't fix (2)

Virtucon (127420) | 1 year,11 days | (#44636615)

No that's only when you break User Space.

Time for an LTS Option (1)

Anonymous Coward | 1 year,11 days | (#44636519)

Time for an LTS option. RedHat, Canonical, Debian, should backport security fixes and maybe mature drivers to a LTS kernel for 5 years or so.

For that matter, go ahead and make a LTS gcc fork, backporting security fixes during that same time schedule.

Re:Time for an LTS Option (0)

Anonymous Coward | 1 year,11 days | (#44637075)

Uhhh... isn't this how this is already done?

Re:Time for an LTS Option (5, Informative)

greg1104 (461138) | 1 year,11 days | (#44637499)

3.10 is the next LTS kernel [] by Linux standards. The existing long term kernels [] are 2.6.32 (as used in RHEL6, Debian Squeeze, Ubuntu LTS 10.04), 2.6.34, 3.0, 3.2.50 (used in Ubuntu 12.04 LTS), and 3.4.59.

Re:Time for an LTS Option (0)

Anonymous Coward | 1 year,11 days | (#44638263)

Amen !
  I thought 3.10 was supposed to be a LTS kernel.

I would have hoped for a little extra care and testing for a LTS where many distros will build LTS versions.
This will be around for at least 2 years.

No, you want a frozen kernel (4, Informative)

robmv (855035) | 1 year,11 days | (#44636581)

No, you want a frozen kernel. A stable kernel isn't one without bugs, is one where there aren't massive changes and you get dot releases with fixes

Absolutely not (2)

stox (131684) | 1 year,11 days | (#44636599)

There are plenty of older kernels being actively maintained. Stable does not equal recommended for all production needs.

Maintainer is too nice of a guy (0)

Anonymous Coward | 1 year,11 days | (#44636667)

"People want national championship banners. People want to talk about Indiana being competitive. How do we get there? We don't get there with milk and cookies."
- Bob Knight

No (1)

swillden (191260) | 1 year,11 days | (#44636861)

Keep in mind that the stable kernel releases are not expected to be production-ready. Linus just produces the input to the actual testing and validation processes, which are performed by the distributions. That assumption is built into the kernel dev team's processes. Not that they intentionally release crap, but they don't perform the sort of in-depth testing that is required before you push a foundational piece of software onto millions of machines.

This is why we have Linux Distributions (2)

Khopesh (112447) | 1 year,11 days | (#44636911)

I haven't needed to bypass my Linux distro and install a vanilla kernel in over ten years. I can wait. If it hasn't been packaged by the major distributions yet, it also hasn't been widely deployed. There are some highly competent kernel package maintainers out there, and they're likely to catch a lot of things themselves.

Then there's the package release and its early adopters (Debian, for example, releases the latest kernels in Experimental and/or Unstable, letting them cook for a while). I typically pick up new kernels when they're in Debian Testing or Unstable (if I really want a new feature). This minimizes the chance of running into problems.

(note, this works best for people using standard hardware. ymmv regarding embedded or obscure devices)

Cool Farts (0)

sexconker (1179573) | 1 year,11 days | (#44636921)

[Read as if you're Robert Preston in The Music Man addressing the town]

Now we're all familiar with hot farts here on Slashdot. That sharp exit of heated gas that warms your anus for a few seconds during its escape.
It's a unique sensation, and it's often uncomfortable! But my friends there is another way to fart. Yes, I said another way!

Why just last week I was sittin'. Sittin' in this very chair, browsin' this very site.
Yes I was sittin'. And while I was sittin' I felt that familiar pressure. The pressure we all know all too well. The pressure of a tight little bubble of gas winding it's way through my bowels.

But this time it was different. As I felt that fart knocking on my door I took a look around. I say, I looked around for anyone who would see or smell or hear.
Friends, family, coworkers, even gosh darn strangers. But my friends the coast was clear. Yes I was free and clear to let'r rip!

But I decided to try something a little bit different. I passed on my usual lean and "foof". I opted against the raucous blast. I say I did something just a little bit different that made all the difference in the world.

Oh I leaned to the left. I leaned to the left and raised my right cheek off the chair. I raised it up and I put it back down. Right on the right edge of that chair.
Then I leaned to the right. This time to the right, raising my left cheek up and settin' it down.

Now over there on the left edge of the seat was one ass cheek. And way over there on the right edge was the other.
But right in the middle, free and clear and stretched nice and taught was my anus. And my friends what a glorious, clean pink anus it is. I took that anus and I opened the valve nice and slow. Like openin' a shaken up bottle of pop.

And just like that bottle of pop my anus let out a slow "hisssssssss". Yes a hiss! And as I savored the extended release of that one little fart, I felt a sensation. A sensation like none I'd ever felt before on this green Earth.

There was a coolness. A coolness from that escaping gas that refreshed my anus and rectum better than one of ol' Doc Miller's suppositories. It was a coolness that lasted. Stayed with me all day long! It put a skip in my step and a twinkle in my eye and that's why, my friends, I'm here today. Tellin' you about this new great way to fart.

9X / 4.XX line will be better just don't use USB (0)

Joe_Dragon (2206452) | 1 year,11 days | (#44637023)

USB will suck in the first 4.XX one.

is_gate_vma bug (0)

Anonymous Coward | 1 year,11 days | (#44637185)

Introduced in an RC, copied to stable, fixed in RC, still in stable a few releases later.

#define is_gate_vma(vma) ((vma) = &gate_vma)

If "Stable" isn't stable... (2)

Tarlus (1000874) | 1 year,11 days | (#44637247)

...then it's moving too fast.

The decline of quality of time (1)

rasper99 (247555) | 1 year,11 days | (#44637293)

As someone who tested drivers with it:
OK through about 3.2 then it started to decline.
Faster decline around 3.4
3.7 - Who needs NFS anyway? Took until 3.9 to fix that

Re:The decline of quality of time (1)

Billly Gates (198444) | 1 year,11 days | (#44639495)

Which is why I do not like Linux. I favor FreeBSD. At least our terrible 5.x and 6.x releases were well understand.

It is kind of like the XP die hard loyalists who feel Windows 7 is too cutting edge and wont change. Better to stick with the devil when it comes to deficiencies.

I use Linux a lot more but only CentOS in a VM. I prefer something works and if I wanted cutting edge I never would have named my account this name and became a MS hater back in the old days when it BSOD all the time. Sadly Windows has surprised Linux when it comes to stability and now use my older nemisis OS as my main as I have given up on FreeBSD and Linux for that purpose.

Is Torvalds abusing people again (0)

musth (901919) | 1 year,11 days | (#44638553) the current debate?

S[hiT (-1)

Anonymous Coward | 1 year,11 days | (#44638807)

of a solid dose We''l be able to Going to continue, and distraction would take about 2 continues to lose PREFEERABLY WITH AN

Rate of patch submission? (2)

gwstuff (2067112) | 1 year,11 days | (#44638873)

I follow kernel development only cursorily, looking at the kernel mailing list once in a while. But I get the distinct feeling that patch volumes have been higher over the past few months than they would be a few years ago. A version is simply something that group a set of tested patches. Generally, you don't want the sets to get too big, so it seems natural that the speed of version releases is keeping up.

It would be nice to see a plot of the number of commits and number of versions over time.


Provocateur (133110) | 1 year,11 days | (#44639251)

Are we *gasp* agile?Or what!

still pissed there hasn't been a LTS since 3.4 (1)

davydagger (2566757) | 1 year,11 days | (#44639469)

I am still pissed there hasn't been an LTS since 3.4, and they are NOT being released on a regular cadence

3.0, 3.2 and 3.4, released in short succession all are LTS, and since then none. I understand the devs can't maintain a zillion kernels, but could they at least space them out and/or release on a more stable cadence.

i.e. drop 3.0 or 3.2 for 3.10/11???
Load More Comments
Slashdot Login

Need an Account?

Forgot your password?

Submission Text Formatting Tips

We support a small subset of HTML, namely these tags:

  • b
  • i
  • p
  • br
  • a
  • ol
  • ul
  • li
  • dl
  • dt
  • dd
  • em
  • strong
  • tt
  • blockquote
  • div
  • quote
  • ecode

"ecode" can be used for code snippets, for example:

<ecode>    while(1) { do_something(); } </ecode>