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.
we get stories for every kernel realease as it is, and now we get stories when there's *not* gonna be a kernel release?
what's next? a story on microsoft *not* putting out a new version of windows?...oh, wait...
"Facts are meaningless. You could use facts to prove anything that's even remotely true." - Homer Simpson
Nothing like doing development on a production machine! I love the smell of flaky kernels in the morning.
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.
The 2.6 linux kernel has been a roller coaster ride of development, and it was obvious from the switch from 2.5->2.6 that the kernel was far from ready for prime time.
So, now we're stuck with a rapidly developing 2.6 kernel that poses a lot of risks for anyone wishing to adopt the new so-percieved "stable" kernel into an OS/Embedded/Other product.
In a way, this is just an acknowledgement that things went a bit too fast with 2.6, and that waiting to release it -after- some pretty solid core feature freezes would have been good.
There is still a lot of development and teething going on, and it's going to be a real pain on the part of "third party distributors" to find and use whatever build-of-the-week is more stable than another in a given sub-branch of the 2.6 kernel.
Oh well, so much for having a nice stable 2.6 base to build new functionality into.
"Don't worry about the problems you have in mathematics, I assure you mine are much greater." - Einstein c.1919
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.
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
So what exactly does this mean for distributions such as Slackware wich ship a vanilla kernel? Personally I always preferred having it "as it was meant to be" without any tweaking of the distributor.
The latest Fedora Core 2 debacle proves that this can lead to trouble (NVidia Binaries broken, etc.).
Distributions such as SLKX (wich ships a vanilla 2.4.22) didnt include the 2.6 series as the defaultkernel. My guess is Patrick didnt trust the beast yet. So what is a man like Pat to do if there isnt the manpower or will to patch the kernel but the "stable" branch cant be trusted anymore, too?
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
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.
Seems to me (strictly from what I just read) that these changes will lead to users who just want their kernel to work will either either use their distro's or stay on 2.4
Seems to me that planning on NOT offering a usuable stable product and relying on significant and independant effort by third parties is not the way to go about keeping your users happy.
Seems to me that this will cause way more forking pressure. This may even open the possibility for a new vanilla stable kernel fork, not distro specific. Perhaps called 2.6-Stable?
When you have a bad feeling after reading the news, that usualy means the news was not good.
Maybe they don't want to go to 2.7 because they're worried that they may run out of digits before they have to go to Linux 3.0
:E
Hmmmm.. The step to Linux 3.0. Could be a PR disaster. 2 is a sexy sequel, 3 is usually a not so sexy sequel. 4 is the beginning of something mature and steady, but 3 is just... well it's just a number!
May the Maths Be with you!
I remember waiting patiently for the 2.5 track to be turned into a 2.6 release ... then when it finally happened I admit to waiting until 2.6.3 before I even tried it (can we say coward?) ... and after running it for a few days I quickly reverted back to 2.4 ... my story probably mirrors alot of users out there who found that it didn't stand up to the reputation that the 2.2 and 2.4 release built ...
... ok, done babbling ...
But can they (the kernel team) hope to rebuild the trust by making this policy change? Has Redhat (sorry, have to single out some distro here) and others gotten too lassiez-faire about the kernel? Will they (the distros) waken tomorrow to realize that their jobs just got 80% harder?
It's too early to quantify my own feelings about this move, do I feel abandoned? do I feel like jumping into kernel development? or, god forbid, do I just feel like installing FreeBSD?
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....
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....
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)
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 don't believe 2.7 will ever happen. In a move guaranteed to improve the acceptance of Linux by CEOs and PHBs, it will surely be...
Linux 3000 Xtreme Professional Plus (codename: BiggerHorn) - based on NT (New Tux) technology.
What I really liked was the multiple admissions that devfs was a piece of crap that should never have made it into the kernel in the first place.
So, I'd feel a lot more comfortable now applying a patch to remove the whole homungous turd to "stabilize" it, as this is now going to be an accepted (not just "winked at" thing :-)
and and and and Finally, I get to say "I told you so!"Too complex, certainly. Time for microkernels? If there were a good one with servers for all the relevant hardware ready? Sure! The HURD? HELL, NO!
Compared to its peers (QNX, VSTa), the HURD is tremendously bloated and slow. Its development involved massive (and performance-reducing) changes to its libc (which have had negative impacts on *other* OSes that use that same libc). Compare to QNX, which runs on tiny embedded devices and which has a demo disk available with massive hardware support and a full web browser all fitting on a single floppy, or to VSTa, which last I heard fit the kernel into 28K (and shrinking) and outperforms some popular macrokernels.
Microkernels are a great idea -- I absolutely look forward to writing and debugging filesystem code and hardware drivers with my usual userland tools. But the HURD? I'll keep my macrokernel, thank you.
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."
Either something is wrong here or you've got a serious lack of sysadmin skills.
If your company is in danger of going out of business, and you don't know how to fix it, one thing you don't do is sit there and mess with things you don't know enough about. You go and email the reiserfs and LVM people. Both are well maintained. Given Linux's open source nature, you could even try to look for a programmer that worked on the kernel. That option probably wouldn't have been very cheap, but it'd sure beat going out of business.
The ReiserFS developers will offer support for free if it was their fault. If it was your, pay them, and they'll help. And btw, you should have backups on removable media. Tapes, DVDs, etc.
This decision scares me. I believe that this will create pressure that will lead to one of two things:
- Kernel fork so that companies can have a stable branch that they can trust, and just cherry pick new things from the main tree as and when they want
- OR - vendors like Oracle, Sybase, IBM, etc. only supporting one or at most two distributions
Before you shout me down, hear my reasoning out...Vendors developing applications need stable APIs and ABIs. We're already too close to a potential fragmentation situation with multiple distributions on different kernel versions, glibc versions, etc. It's giving vendors headaches because they claim to support Linux, but then the masses spew insults when their particular distribution doesn't work.
Ignoring performance stability, instability of the code base will hurt Linux acceptance. If it costs vendors more to keep up with the ever-changing world than they can make from selling Linux solutions, they'll either find a way to freeze that world (i.e. fork), or they'll discontinue or reduce their support, and tie it to just one or two distributions. These are both bad options for the end-user.
You also have to wonder how much trust should be placed in the distribution companies. Going for a Red Hat solution is in many cases more expensive than a similar Sun solution, and Red Hat don't provide a lot of choice. Want to use XFS or JFS on your Red Hat Enterprise Linux AS 3 server that you paid them $1000 for ? That's just tough, because if you do that, they won't support the box.
Pay a grand and get no support - that's the price of 'choice' with Red Hat. I'm sure other distribution vendors will be the same, because at the end of the day, they need a known-good installation to troubleshoot against. That's fair enough, they're in this for business reasons. But to say that we should rely on their altruism for our stable kernels ? Doesn't seem like good forward thinking to me!
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.
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.
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
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.
Maybe they should call the current 2.6.x series -RELEASE, and then when 2.7.x starts, call it -STABLE as it goes into maintenence mode.
Having the 3 forms like FreeBSD does: -CURRENT, -RELEASE, and -STABLE, is a good model, IMO. -CURRENT means you shouldn't touch it unless you are a developer, -RELEASE means end users can touch it, but it is not necessarily stable.. it's kind of a beta that's good enough for public consumption for the most part. And -STABLE is the ultra solid, will-not-crash, version.
So, 2.4.x = -STABLE
2.6.x = -RELEASE
2.6.x-mm = -CURRENT
"Active development going on" often results in "no worky" whether by accident or design. Look at the 2.4 kernel and all the VM trouble, for example.
Stick Men
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'
I don't speak Welsh. How will I know?
Stick Men
A question for someone that knows more about the guts of the kernel than I, What(if any ) problems would this araingement cause? It this approach practical? I believe this is how the fire{fox,bird} developement started.
Laws are horrible moral guides, moral guides make even worse laws.