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."
Well, i guess that's what is was like with 2.4, unofficially.
This is bad. Not all distribution maintainers have armies of patch people. This will push people to one of a few distributions such as RedHat or Suse. Espcially if 2.6 becomes an unstable piece of crap.
IMHO this will just increase the fragmentation between the vendor kernels. There should really be one, and only one stable kernel used by all the vendors. We have enough problems with binary compatibility in Linux already.
Maybe I don't know what I'm talking about here, but it seemed like there was a rush to get 2.6 out there. I'm glad the team is taking some time to settle down and solidify 2.6 before once again plunging forward. To me, at least, a stable kernel is much more important than partially-functional bleeding-edge features.
There's a Mercedes gap too. I want one and can't afford one, but it's not government's job to do anything about it.
Does this mean a return to the 2.4.x type of problem where no-one could agree on which virtual memory management to use and the stable series ended up being, well unstable, until it reached about 2.4.19 (or thereabouts)?
flossie
Write now. Defend liberty
As "final stabilization will be left up to the companies that provide Linux distributions." does this not introduce the risk that the final versions will begin to diverge and over time a RedHat OS, a SuSe OS etc will emerge? Will we have a VHS vs Betamax style battle in Linux?
You don't need a lab to make mud.
...and nither is it totally out of the ordinary either...
Linus hung out on the 2.0,2.2 kernels before truely turning them over to a new person for a long time. 2.4 was really the first that he jumped out of quickly because he had ideas that truely shouldn't have been going into the "stable" kernel.
Power Corrupts,Absolute Power Corrupts Absolutely, leaving one person(group)in charge is absolutely corrupt.
I like this idea as it makes development go even faster. Not that i am a big fan of development just because but rather becaues i feel there is much left to be done before things are really mature. I really hope though that this wont make security suffer. My hope lies in better security being built into the kernel and new ways of protecting it being developed.
HTTP/1.1 400
Moderators: Don't agree? pray tell why.
This will hopefully provide product vendors (eg NVIDIA, user-mode linux etc) with the opportunity to catch up with the release cycle. A good thing for the next 12-24 months.
Distros will pick a 2.6 release.
Say, 2.6.6.
Then they'll backport security fixes just like they did for 2.4.
The difference is nothing.
It has been a time since I've started to consider Linux too complex. 2.4 also took quite some time to stabilise, and 2.6 still isn't production ready in some quite relevant situations.
For example, trying 2.6 + LVM2 + soft RAID5 + ext3 is asking for data loss. I and several other people reported this, but seemingly either we were statistical noise or we weren't well connected enough, and the kernel hackers never paid attention up to at least 2.6.5 - I just gave up following up nothing at all since 2.6.6.
I know it has taken some bad decisions and now lacks critical mass, but perhaps the Hurd is the way to go... it should enable better isolation of disruptive development, and enable kernel development to continue adding features.
In fact the Hurd was conceived between a bridge between ad-hoc POSIX and cleaner Lisp systems.
Leandro Guimarães Faria Corcete DUTRA
DA, DBA, SysAdmin, Data Modeller
GNU Project, Debian GNU/Lin
Am I the only one that thinks this new dev model is a really bad idea?? Stability is the hallmark of Linux, but that is now effectively broken. If we have a problem, we can't say anymore "oh! There's a new kernel! We should try that!" There's NOTHING wrong with the current odd-test/even-stable scheme. If Linus and Morton want to play around with new features, MAKE A 2.7 BRANCH! 2.6 is finalized, let it be! If you don't think that there's enough features in it, YOU SHOULDN'T HAVE RELEASED IT!
A lot of people use the vanilla sources, myself included obviously, I should have to go RedHat to get a working kernel. The 2.6 branch is NOT a playground, that's what the -mm branch is for.....
2.6.6 works for me, and I'm not changing. For the first time in my life, I *DON'T* trust what's coming from Linus & Co.... and that's scary.... It's like God is forsaking you to go play with some toys....
Buses stop at a bus station
Trains stop at a train station
On my desk there's a workstation....
We can no longer count on the bare kernels to have any stability and depend on companies to stabilize the kernel.
I disagree with this method for a few reasons.
Everyone still probably remembers when you had to use a bare kernel to recompile and get Nvidia HW Accel drivers to work with the 4k stack problem.
Also this will pose a problem with many distro's that do not have armies of people to sit around and stabilize the kernel for their distro.
Another problem is with drivers being fixed. A bare kernel will be fixed but the customer may have to wait 2-3 months before their specific distro comes up and included a fixed kernel.
Lastly this will increase costs for developers of distros such as Redhat and Novell due to them having to now employ kernel hackers to deal with problems that may exist in the Kernel.
I can see no good coming from this approach to Linux and may hurt us in the long run. I hope they reconsider.
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.
No sane person will now touch 2.6 tree for a production server knowing that developement is the 2.6 tree, unless they buy from RedHat etc who may guarrantee stability
Lets hope they reconsider and create 2.7 ASAP otherwise I know some companies will probably want to either stay at current release, or abandon Linux ({cough} some may even go back to Micro$oft)
First off, forcedeth is a brand new driver and pretty new hardware (compared with, say the Intel EEPRO hardware which I can assure dwarfs your petty nVidia hardware in not only quality but also numbers by a long shot).
Second of all, if it works in a previous version, why can't you just stick with what works? Is there some fetish for being on the cutting edge?
Jesus, many commercial users of Linux (especially embedded) still use the 2.0.x series or 2.2.x series of kernels because they are stable and they work very well (not to mention they don't have the resources to change their code to fit an ever-changing kernel API). Would it bother you to know that our company actually produces hardware with 2.2 kernels that our customers are satisfied with?
If you don't like the way things are, contribute some code OR STOP BITCHING ABOUT IT.
Even "production" kernels can have problems. Remember the VM changes around 2.4.10?
New productions kernels deserve every developer's full attention until they're really really ready.
"Provided by the management for your protection."
To everyone saying this will kill the independent distro, chill.
If you were going to make a new distro right now, in my opinion you'd be better off starting with Fedora or Progeny's Componetized Linux or vanilla Debian or something as it is, stand on some shoulders people. Linus and his crew produce a kernel, not an operating system, I'm sure they're doing this to produce the best kernel they can, not because they hate you.
Like other people said, 2.4 had so many changes go in during it's "stable" life, maybe their just trying to be realistic and make 2.6 actually be more stable than 2.4 this way?
I'm a Slakware man myself, but 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.
Stick Men
It seems to me that everyone is assuming that there will never be a 2.7 tree. From the article, the simply quote Jonathan Corbet as saying that "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."
They are just concentrating on the stable branch for now, and collecting a patch set (Andrew Morton's -mm patch set, that is) as a testing ground for proposed (stable) kernel changes.
This really doesn't seem like a big deal, and it implies that the kernel people will focusing on stability for the time being.
IMHO this is bad. If the development process can no longer isolate between what's stable and what's under development, then they probably are incapable of measuring the stability of the current release product.
But I wonder how Debian and Gentoo will handle this since they aren't the stereotypical Corporation who stabilizes the kernel prior to release. Debian at least, does a very slim job of customizing the Linux Kernal when compared to RedHat, Mandrake, and SuSE.
Does this imply that the LKML has decided to abandon their origins of Free and just hack code and let someone else actually worry about a finished workable product? Sounds like they are kind of blowing off their community.
Or is the community filling up with whinnie-assed whimps who don't know what the meaning of "make clean" means?
I've been constantly amazed by people imagining that version numbers on the Kernel, (Or other software for that matter) actually reflect anything other than a simple fact: A build at a point in time.
Read the kernel mailing list. Sure, as a version approaches, Linus makes an attempt to not include patches which have not undergone much testing, but the simple fact of the matter is that the Kernel is no less or more stable at 2.6.n version as it is in version 2.6.n-mm4, or 2.6.n-rc7 etc...
Versions in the kernel are really just "points in time" The apparent stability of a version is really perception as to what is working or what isn't, and is completely outside of the versioning.
What's worse, in order to facilitate the versioning mechanism, Kernel maintainers have moved closer to the 2.n.m-rc1234 bla bla bla in order to signify that the whole number m is "stable", which, just as often it isn't quite, and requires patches anyway.
Honestly, for my money Linus could either use 2.6.n.20040722 to signify his builds, and I'd be just as happy.
Aside notes:
For those who used the 2.5.xx series and found it unstable, Did you report what unstability you had?
For those who tried the 2.6.xx serise and found unstability, did you report what unstability you had?
I think that when you claim that a version is unstable, you should back it up with what is wrong, and how it affected you, and pass that information forward to the developers. If you don't, you are robbing the developers of the very feedback they need. Complaining about it doesn't do much good if they don't know about it.
I thinks I rant too much
"...In your answer, ignore facts. Just go with what feels true..."
Whoah, I need coffee.
Unstable as in "active development is going on", not as in "no worky."
Actually, I think this shows a maturity in the Open Source model, as the community has spread deeply into the commercial realm.
Red Hat, IBM, Novell, SGI, Mandrake, and all the other companies that support, market, and contribute to Linux are a very significant part of the community. Many of the top kernel hackers are employed by these companies. They are heavily invested in both pushing the envelope with Linux, and supporting a solid and stable platform for their customers.
Given that the commercial vendors are the ones who are closest to the majority of end users and have a significant interest in the hardware Linux is deployed on, they are in the best position to deal with the majority of bugs which have to do with specific drivers and interfaces. In fact, it would hardly surprise me if most of the current bug finding and fixing comes from these companies. This seems to be their natural position in the community.
On the other hand, given the tremendous popularity of Linux in research and higher education, the core maintainers have to contend with a massive volume of architecture and implimentation issues. File systems, schedulers, memory managers, performance, scalability and QoS issues -- these are the bread and butter of the core team. The fact that someone neglected endian issues with a specific network controller should not be their problem.
Personally, I think this is less of a policy mandate than it is a recognition of how the community has changed over the last few years. Since the release of 2.4, people have embraced the MM and other trees as a testing ground for unproven additions to the stable kernel, while the odd series kernels have become more esoteric. I like this model, as it allows for major changes to vet themselves in the unstable branch, while continuing stepwise improvement in the unofficial stable branches (MM et al), and ensuring bug squishing and stability in the official vanilla release.
If Linux is to continue to mature and improve, this sort of delegation is necessary. These are growing pains, and I'm confident that the Linux kernel community (commercial or otherwise) has the intelligence to govern itself effectively.
Version numbers may not matter to developers, but I think this is an example of a usability problem. The old version naming was good and well understood. It's almost like an unwritten contract with users that you don't switch these things mid-stream. Naming is part of the interface.
From the article...Isn't that the Microsoft model we know and hate? I think they have their priorities out of order. Unlike closed source the code to all the new features is out there in the dev tree. If some distributor thinks they need to take an wants to take untested/unstable code from Dev to Stable, let them do it. Instead distributors will now have to remove or disable unwanted code?
Call it what you will, but this sounds like a development kernel to me.
It comes with no warantee
In the hope that it might be useful.
Plus, what feature or bugfix have you needed that required a brand new kernel?
Bug and security fixes mainly.
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.
Well I've not long upgraded to 2.4 (about a year). I held out till they put a stable VM in. I needed the extra hardware support, otherwise I'd have stayed on 2.2.
My 486sx runs 2.2. I also have two K6-2s, 2 P-IIs, and various other odds and ends. They don't run "development" kernels, only mature, stable ones.
I'm not a kernel developer, so I don't want to spend all night debugging. I get my distro from Slackware (yes, I've parted with money).
Stick Men
Most things have been said. So I will just add my opinion to the others. I, too, agree that it is a bad thing. Earlier, we knew how to distinguish between stable and unstable. Now we leave it to someone else and have to search for the right one. Yes, it doesn't mean anything. But only for now. The outcome of this decision can not be forseen. Distros will try to persuade their users of having the most stable kernel. It will be used as an argument in the competition of the distros. If that is a good or a bad thing, is left to the reader. Just remind yourself that marketing does not understand why featurism and stability do not go hand in hand.
Problems will not pop up suddenly. But what has before prevented them in doing so, is gone. Who can be trusted? I only see Debian. Before they were the ones lacking behind. But now they might win since they always concentrated on stability. I say, go for Debian. They have the right people and should be the last ones caring about this decision.
Sven
While I have no problem with them making patches in 2.6 for security reasons or to do bug fixes or corrections, the dev branches have been traditionally an opportunity for the kernel devs to tinker and to begin adding newer and cooler features to the kernel. One could rely on the fact that in a linux kernel numbered x.y.z, that if the only thing that changed was the z, one could usually reasonably expect that nothing significant would be changing within their system. That if they upgrade from x.y.a to x.y.b, the only things of note will be bug fixes, security fixes, and _MAYBE_ a minor feature or two that 99.99% of the people wouldn't notice anyways, but nothing too significant will have actually changed unless it was previously broken. However. now they want to make 2.6.x a development tree and I can see that this could have one of two negative consequences:
In other words, not having a 2.7 is a Bad Thing. Why they don't see this is beyond me.
File under 'M' for 'Manic ranting'
Pat has always (iirc) refused to ship a new kernel until there's a separate development branch. Because he knows it won't be stable. And ime with 2.6, this is entirely justified. So pat will probably ship 2.4 for a while. And all those who want a stable system will thank him.
I am trolling