User: Password:
|
|
Subscribe / Log in / New account

The 3.12 kernel is out

Linus has released the 3.12 kernel. "I was vacillating whether to do an rc8 or just cut the final 3.12, but since the biggest reason to *not* do a final release was not so much the state of the code, as simply the fact that I'll be traveling with very bad internet connection next week, I didn't really want to delay the release."

Some of the main features in this release include improvements to the dynamic tick code, support infrastructure for DRM render nodes, TSO sizing and the FQ scheduler in the network layer, support for user namespaces in the XFS filesystem, multithreaded RAID5 in the MD subsystem, offline data deduplication in the Btrfs filesystem, and more.

Linus noted a couple of other things in the announcement. One is that the 3.13 merge window will not be starting for another week. He is also starting to think about an eventual 4.0 release, and has tossed out the idea of having 4.0 be a bugfix-only release, though he has his doubts as to whether it would work. "But I do wonder.. Maybe it would be possible, and I'm just unfairly projecting my own inner squirrel onto other kernel developers. If we have enough heads-up that people *know* that for one release (and companies/managers know that too) the only patches that get accepted are the kind that fix bugs, maybe people really would have sufficient attention span that it could work."


(Log in to post comments)

The 3.12 kernel is out

Posted Nov 4, 2013 4:11 UTC (Mon) by Tara_Li (subscriber, #26706) [Link]

The international community managed to get together and hold an International Geophysical Year back in 1957-1958, where a huge amount of effort was concentrated on just a few projects...

Maybe someday we could have an International Bug-fix Year, where nothing but bug-fixes go in for all projects?

Eh, not likely, but a guy can dream, right?

The 3.12 kernel is out

Posted Nov 4, 2013 7:58 UTC (Mon) by micka (subscriber, #38720) [Link]

I sure would not want that.
One year with only bug fixes would mean maybe one year and hald old hardware not supported, for example.

The 3.12 kernel is out

Posted Nov 4, 2013 8:11 UTC (Mon) by oldtomas (guest, #72579) [Link]

That would be OK if the hardware world also went into bug fixing mode for one year (and hardware *is* mostly software these days, unless we're talking about the gate/FinFET boundary, ain't it?)

The 3.12 kernel is out

Posted Nov 4, 2013 9:25 UTC (Mon) by Otus (subscriber, #67685) [Link]

> One year with only bug fixes would mean maybe one year and hald old hardware not supported, for example.

Doesn't have to mean that. Even stable kernel rules allow simple hardware enablement (new device IDs and quirks).

The 3.12 kernel is out

Posted Nov 4, 2013 8:27 UTC (Mon) by yoshi314 (guest, #36190) [Link]

Well, there's RHEL and derivatives that seem to match those requirements.

Plus, if someone were to really do it, they would either get behind in hw support, new features or get jumped over by competition.

The 3.12 kernel is out

Posted Nov 4, 2013 11:28 UTC (Mon) by torquay (guest, #92428) [Link]

    there's RHEL and derivatives that seem to match those requirements.

RHEL has its own franken-kernel. For example, the "2.6.32" in RHEL 6 is actually 2.6.32 + stuff continually backported from later kernels (often hardware support, but not limited to it). When doing the backports, the API and ABI for modules from later kernels is adjusted to match that of 2.6.32.

Obviously RHEL has the infrastructure to run regression tests in order for this franken-kernel to fly. It'd be nice if Red Hat did that for regular upstream kernel releases.

The 3.12 kernel is out

Posted Nov 5, 2013 0:26 UTC (Tue) by dag- (subscriber, #30207) [Link]

On one hand you call it a "franken-kernel" as if it is some sort of monstrosity, but then you would like to run that same monstrosity.

Regardless of those conflicting signals, RHEL's kernel source code is freely available for anyone to use as-is. The SRPMS can be found at:

http://ftp.redhat.com/redhat/linux/enterprise/6Server/en/...

The 3.12 kernel is out

Posted Nov 5, 2013 2:12 UTC (Tue) by donbarry (guest, #10485) [Link]

Are the patches broken out individually, meeting the full spirit of the GPLv2 section 3 ("The source code for a work means the preferred form of the work for making modifications to it") or is RH still aggregating this material into a big frankendiff?

The 3.12 kernel is out

Posted Nov 5, 2013 7:39 UTC (Tue) by mchapman (subscriber, #66589) [Link]

Individual patches (each with a detailed commit message) are available from the Red Hat Customer Portal if you are a RHEL subscriber.

The 3.12 kernel is out

Posted Nov 5, 2013 11:01 UTC (Tue) by tao (subscriber, #17563) [Link]

If the kernel is available for download without being a RHEL subscriber, while the sources are only available in the preferred form if you're a subscriber, then I'd say it's a violation of the GPL.

The 3.12 kernel is out

Posted Nov 5, 2013 12:39 UTC (Tue) by drag (subscriber, #31333) [Link]

That's the first time I heard somebody accuse a company of violating the GPL by providing the source code.

Good job.

The 3.12 kernel is out

Posted Nov 5, 2013 13:55 UTC (Tue) by paulj (subscriber, #341) [Link]

I guess then you missed the article here on LWN in 2011: https://lwn.net/Articles/432012/

By all accounts, RedHat are *not* providing their preferred source for building their kernels out, other than to subscribers. Whether this matters at all is down to the Linux kernel copyright holders.

The 3.12 kernel is out

Posted Nov 5, 2013 18:24 UTC (Tue) by ThinkRob (subscriber, #64513) [Link]

> By all accounts, RedHat are *not* providing their preferred source for building their kernels out, other than to subscribers. Whether this matters at all is down to the Linux kernel copyright holders.

But the GPL doesn't require that you give the source to anyone and everyone, just to those to whom you distribute a binary.

Unless RedHat distributes binaries to non-subscribers (which, AFAIK, they don't) shouldn't they be in the clear?

GPL requirements

Posted Nov 5, 2013 18:49 UTC (Tue) by corbet (editor, #1) [Link]

It's really worthwhile to read the GPL to understand what the source requirements really are. For most cases, there's two alternatives:

  • The source has to accompany the binary (section 3a)

  • The binary must have a written offer to provide source to any third party (section 3b).

Since few binary distributors bundle all the source with the binary, they are indeed required to give the source to "anyone and everyone."

GPL requirements

Posted Nov 5, 2013 20:11 UTC (Tue) by Wol (guest, #4433) [Link]

Bear in mind, GPL 2 and 3 are *different* in this regard. I had my knuckles rapped over this on Groklaw :-)

GPL 2 did not envisage the web. So if you put the binary and source in two different packages such that a visitor can choose only to download the binary, it is classed as a binary distribution and triggers the "any 3rd party" requirement :-(

The FSF considered this a bug, as I'm sure most of you would agree, so GPL 3 says if you make the source available with the binary and a visitor chooses not to download the source, they have no right to come back later and demand it.

Cheers,
Wol

GPL requirements

Posted Nov 5, 2013 21:12 UTC (Tue) by paulj (subscriber, #341) [Link]

Nitpick: "it is classed as"? By who exactly? I think perhaps you mean this is a possible loophole in the GPLv2, that someone might use to argue they do not need to provide source to anyone. I don't think it's ever been tested anywhere though, has it?

The 3.12 kernel is out

Posted Nov 5, 2013 12:59 UTC (Tue) by mathstuf (subscriber, #69389) [Link]

So anyone who puts up source without their full git history (or equivalent) isn't GPL compliant? That's absurd.

The 3.12 kernel is out

Posted Nov 5, 2013 13:45 UTC (Tue) by mchapman (subscriber, #66589) [Link]

I think the phrase "preferred form" is vague enough (and Red Hat's lawyers are smart enough) that Red Hat probably aren't violating the letter of the GPL. It's a hassle, but no different from the bad old days when all open-source projects were simply published as tarballs.

The 3.12 kernel is out

Posted Nov 5, 2013 15:10 UTC (Tue) by fandingo (subscriber, #67019) [Link]

Red Hat only has an obligation to the users who receive a binary copy of the software (i.e. paying customers). Red Hat has no obligation to provide source code to the public. (However, Red Hat cannot restrict redistribution of GPL code by those customers.)

The 3.12 kernel is out

Posted Nov 5, 2013 15:27 UTC (Tue) by corbet (editor, #1) [Link]

That is only true if Red Hat delivers the source with the binary. Otherwise the GPL requires that they provide the source to anybody who asks for it.

That said, the question of Red Hat's GPL compliance status has been discussed into the ground in the past; most people seem to think that there is not a problem here.

The 3.12 kernel is out

Posted Nov 5, 2013 22:33 UTC (Tue) by dag- (subscriber, #30207) [Link]

It's not my place to defend Red Hat, for all I know I am using all the wrong reasons, but here's at least my opinion...

Source-code seems the be quite adequate to make modifications to. Red Hat upstreams their bug-fixes and features upstream. But the RHEL kernels often get these backported bug-fixes, features and drivers from upstream in their old kernels.

If one is not running RHEL yourself, why would one be interested in specific backported functionality for a specific RHEL kernel (be it 2.6.9, 2.6.18 or 2.6.32) ? You called it a "franken-kernel", so why do you feel as if you're being hurt ? If you would like to see what's changed, you can look at the diffs from each released SRPM already.

The people I've heard complaining about this aren't interested in the individual patch-sets at all but have some political/religious/competitive beef with Red Hat. Don't expect my sympathy in that case...

The 3.12 kernel is out

Posted Nov 5, 2013 8:10 UTC (Tue) by torquay (guest, #92428) [Link]

    On one hand you call it a "franken-kernel" as if it is some sort of monstrosity, but then you would like to run that same monstrosity.
    Regardless of those conflicting signals
No conflicting signals. It was an observation that the RHEL kernel is far from vanilla 2.6.32. It's full of patches from later kernels and further modifications. It's essentially a continually updated fork. I do not run such a kernel, not because I don't like it (such a kernel definitely has its uses), but simply because I prefer to stick to the official upstream kernel.
    RHEL's kernel source code is freely available for anyone to use as-is. The SRPMS can be found at
Yes, but that's not interesting. Red Hat is legally required to do that. What's interesting is the set of regression tests that RH must have for its franken-kernel. If RH was a good open-source citizen, it would make those regression tests available so that they can be used to test the official upstream kernel.

Bug-Fix Cycle for 4.0?

Posted Nov 4, 2013 12:17 UTC (Mon) by Felix.Braun (subscriber, #3032) [Link]

Ingo Molnar made a couple of very insightful comments here.

Bug-Fix Cycle for 4.0?

Posted Nov 4, 2013 14:30 UTC (Mon) by jospoortvliet (subscriber, #33164) [Link]

Yeah, insightful. My first thought was: "and what exactly do you hope to accomplish?" as I doubt it would lead to anything other than a slowdown in development. A durable quality improvement? Unlikely... Bugs get fixed as part of the development process, not in isolation. Ppl would just take a vacation or continue developing in branches.

I don't think the Kernel is different from other FOSS projects in this regard, btw. It'd be a lot of pain for little gain.

Bug-Fix Cycle for 4.0?

Posted Nov 4, 2013 17:16 UTC (Mon) by ballombe (subscriber, #9523) [Link]

Maybe you are missing the point by focusing on the developers.
They are not the target: the target is the testers.
Fixing bugs is not the problem: kernel developers are very good at fixing properly reported bugs.
Instead the problem is finding regressions in a timely fashion.
It is clear now that Linux merge code faster than people can test it.
Freezing the merge for two months could help testers to catch up and encourage to run longer tests.
If developers continue to produce code during that time, no development
time is lost.

The 3.12 kernel is out

Posted Nov 4, 2013 23:20 UTC (Mon) by xtifr (subscriber, #143) [Link]

While I have no strong opinions on the general concept of a bug-fix-only release--that should be up to the developers--I am somewhat appalled at the notion of combining that with a major-version-number bump. It seems to me that that's pretty much the opposite of what you should use to justify a bump in the major number.

Is Linus suddenly suffering from version-number-jealousy or something?

A bump in the major number should indicate a major (and possibly incompatible) set of changes. And if that never happens because of the current development model, well, I have no problem with the thought that my grandkids might be running 3.32767. :)

The 3.12 kernel is out

Posted Nov 4, 2013 23:39 UTC (Mon) by bronson (subscriber, #4806) [Link]

Just checking, did you read the fingers-and-toes rationale in the article? Gotta admit, I'm in his camp. I find 2.6.18 much easier to talk about than 2.1.131.

As far as 4.0 being a bugfix-only release, I suppose that's just Linus being his turdly self. :)

The 3.12 kernel is out

Posted Nov 5, 2013 6:26 UTC (Tue) by eru (subscriber, #2753) [Link]

I have no problem with the thought that my grandkids might be running 3.32767.

Besides, with 3 now being the major number, and the minor still less than 0.14, Linus could emulate Don Knuth and begin asymptotically approaching pi ....

The 3.12 kernel is out

Posted Nov 6, 2013 18:44 UTC (Wed) by jengelh (subscriber, #33263) [Link]

It is consensus that no one in the kernel camp wants to go that TeX numbering route. There are numbers other than pi which are also interesting.

SemVer?

Posted Nov 5, 2013 13:42 UTC (Tue) by lamawithonel (subscriber, #86149) [Link]

Out of curiosity, why doesn't Linus use Semantic Versioning or something similar? It would alleviate some of the ABI issues mentioned in the KDS coverage, would it not?

SemVer?

Posted Nov 5, 2013 14:30 UTC (Tue) by dgm (subscriber, #49227) [Link]

Easy peasy.

The first digit doesn't make sense, Linus doesn't want user space broken.

Second and third digits do not make sense in isolation. There has never been a Linux release that didn't fix bugs _and_ added new functionality (in a backwards compatible way).

So, what we have now is in fact similar to Chrome and Mozilla sequential version numbers, incremented by a first "era" digit that is merely cosmetic. If you think about it, it's the only think that can really work for projects that grow continuously (as opposed to in discrete steps).

SemVer?

Posted Nov 5, 2013 19:36 UTC (Tue) by scottwood (subscriber, #74349) [Link]

So then leave it at 3.x for as long as that policy is in place, and at least reserve the possibility that some day (in 20 years? 100? 1000?) there may finally be a desire to drop some old cruft.

Or, if you absolutely don't want to consider that possibility (or would prefer that the name be changed in such an event), then go the Firefox route and drop the leading digit altogether, since it doesn't mean anything. I don't get this fear of somewhat-large numbers, as if 4.2 is somehow more manageable than 42.

SemVer?

Posted Nov 5, 2013 19:41 UTC (Tue) by scottwood (subscriber, #74349) [Link]

Oh, and userspace API breakage isn't the only thing that could justify bumping the major version number... It could also be internal changes that are sufficiently intrusive as to break the "stabilize every three months or so" development model, requiring a temporary return of the stable/unstable split. Again, hopefully not something that happens for a long time, if ever, but it could happen.

SemVer?

Posted Nov 6, 2013 1:58 UTC (Wed) by JdGordy (subscriber, #70103) [Link]

The numbers are meaningless and arbitraty. That's been made pretty clear (by Linus) here and in the past. And as someone above said, Linus refuses to every break userspace so not incrementing the major number is pointless (pretend there is a 0. prefix and you have that.)

Just be glad we arent using the git tag hashes for the version *strings*


Copyright © 2013, Eklektix, Inc.
Comments and public postings are copyrighted by their creators.
Linux is a registered trademark of Linus Torvalds