Slashdot Mirror
No 2.7 Linux Kernel Branch Due Soon
An anonymous reader writes "At the fourth annual Linux Kernel Developers Summit, it was decided that there won't be a 2.7 Linux kernel development branch any time soon. Instead, Linux creator Linus Torvalds and the official 2.6 maintainer Andrew Morton have decided to continue working as a team, further enhancing the 2.6 kernel. Up to this point, kernels ending in an odd number (2.1, 2.3, 2.5, etc) were considered development kernels, and kernels ending in an even number (2.2, 2.4, 2.6, etc) were considered stable kernels. However, according to this KernelTrap article, active development will now continue in the mainline 2.6 tree, and the final stabilization will be left up to the companies that provide Linux distributions."
An interesting thread on the lkml began when Greg KH submitted a patch for the 2.6 kernel saying, "Ok, to test out the new development model, here's a nice patch that simply removes the devfs code." This was quickly followed with a comment by Oliver Neukum who said, "may I point out that 2.6 is supposed to be a _stable_ series?" In one branch of the thread, the usefulness of devfs was examined.
In another thread, dicussion was focused on this "new development model". Jonathan Corbet explained that Linus Torvalds and Andrew Morton [interview] were very happy with the results of their recent teamwork, and saw no immediate pressure to fork a 2.7 development branch. On the contrary, they intend to keep at it as they've been, with things first going into Andrew's -mm patchset [story] for testing, then eventually being merged into the mainline 2.6 kernel. Jonathan went on to explain, "Andrew stated his willingness to consider, for example, four-level page tables, MODULE_PARM removal, API changes, and more. 2.7 will only be created when it becomes clear that there are sufficient patches which are truly disruptive enough to require it. When 2.7 *is* created, it could be highly experimental, and may turn out to be a throwaway tree." And he summarized:
"Andrew's vision, as expressed at the summit, is that the mainline kernel will be the fastest and most feature-rich kernel around, but not, necessarily, the most stable. Final stabilization is to be done by distributors (as happens now, really), but the distributors are expected to merge their patches quickly."
Subscribers to LWN.net can find out all about this recent development and more on LWN's 2004 Kernel Summit coverage section.
Dude, there was no Fedora Core 2 debacle. The 4K stacks patch went into the vanilla kernel also. Thanks to the Fedora team, NVidia had a 4K stacs driver much sooner for you vanilla guys.
Unless you pulled 2.4.11-dontuse or 2.4.15-greased-turkey off kernel.org.
Slow down, cowboy! It has been 4 hours since you last posted. You must wait another few hours.
Not quite. It was Linus that ripped the VM out. Red Hat sticked with the VM that originally shipped with 2.4
Lesbian Nazi Hookers Abducted by UFOs and Forced Into Weight Loss Programs - -all next week on Town Talk.
it makes it harder to distinguish between stable and development
(Overly) simple answer: 2.6-mm is development. 2.6 vanilla is stable.
Please explain?
So far for me, 2.6 is turning out to be pretty stable, and I switched to it quite early, starting with 2.6.3 I think. In comparison, 2.4.3 was really bad. It was almost a miracle that I managed to avoid critical data loss after switching to 2.4.0 and using ReiserFS on my root partition.
2.6 so far just works and that's it. Maybe there's some lack of polish somewhere, but so far it works fine here on SMP.
Unfortunately according to the article, that's not true.... 2.6-mm is bleeding edge, 2.6 is development/testing and 2.6.redhat or whatever is stable.....
Buses stop at a bus station
Trains stop at a train station
On my desk there's a workstation....
This goes against the whole idea of Free Software.
No it doesn't. Free Software is about free software. It comes with no warantee, and a brand new kernel from kernel.org has not been thoroughly tested outside of the developers boxes themselves.
I don't like sitting around waiting for Patrick to make a new kernel. I like to update my kernel myself from the official Linus tarball as and when required. This will no longer be possible.
You are free to download it or not, however its pretty ignorant to blindly run untested software in a production environment (I'm not talking about your personal box).
Plus, what feature or bugfix have you needed that required a brand new kernel? I've only needed a bleeding edge kernel once in my life and that was because I needed more file descriptors per process than 256 and the 2.0 kernel did not provide this. I ran 2.1.115 (IIRC) because in my testing of the 2.1 branch, that one was stable. It was not the latest at the time and I did not upgrade to 2.2 until I've heard reports that it was stable.
Firstly,
This goes against the whole idea of Free Software.
No it does NOT.
The whole idea of free software is that anyone is free to develop the software in whatever way they want to develop it. If you don't like how the developers are doing it, fork the kernel and do it your way. Who are you to dictate whether the idea is to make a "working, useful product"? The idea is whatever the developer wants the idea to be.
Secondly, your suggestion that this new model will produce "half-baked cripple-ware" is unwarranted. When the distributers make stability fixes, what makes you think they won't be applied to mainline just like they are now?
Finally, about compiling your own kernel. You know how to use patch don't you? Take a look at gentoo kernels, some of them contain the exact same patches that redhat ship. Debian, Slakware and others can do exactly the same.
-- MartinG To mail me: echo kewyjlcxyzvjfxbqwh | tr bcefhjklqvwxyz
Sorry, but Debian does patch their kernels.
There: Something at a specific location.
Their: Owned by someone.
Please make sure your english compiles.
"Didn't that happen with 2.4?"
Only when it was in its "VM of the Week" phase.
I suppose this is where I explain that the branch names in FreeBSD (and possibly the others also) are misleading.
There is only a single active CURRENT or STABLE branch at any time, but there are numerous RELEASE branches (one for each x.y version of FreeBSD)
CURRENT is the new technology branch which is considered bleeding edge similar to 2.5 or 2.7.
STABLE is also a development branch focused on making improvements but not on wholesale architectural changes to the system. Changes are intended to be more incremental, and less bleeding edge (eg backporting but not, say, ripping out the VM as happened in 2.4)
RELEASE branches are periodically created from a CURRENT/STABLE branch. Those created from STABLE are generally considered rock solid production releases, and only updated for bug and security fixes. Those created from CURRENT are reasonably stable snapshots of the development of the next major version. These could be likened to the early 2.4 releases where things were still changing (like replacing the VM)
It's not intuitive, but it's the way things are.
Of course, this isn't to say that the naming scheme you suggest doesn't make more sense. The FreeBSD scheme can be confusing and apparently can result in new users who refuse to believe that STABLE is not in fact a maintenance branch, even in the face of clear documentation.