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."
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
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?
That said, it could be a good thing to preempt the distros from forking in order to add new features that they do not want to wait for, and it also adds the benefit of Linux providing the OS features that you want ASAP, not in 2005, err, maybe 2006, 2007 or 2008 when the next major release is planned-- that would be the Longhorn development model.
Who do you get to be an expert to tell you something's not obvious? The least insightful person you can find? -J Roberts
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.
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?
I'm sorry your forcedeth driver example is harsh. The driver is clearly labelled as "EXPERIMENTAL", and what's more it is *reverse engineered* because nvidia didn't want to give out the documentation to it. You are lucky someone was actually working on it at all.
As a sidenote, nvidia is now actually contributing to this very driver, however that has been since 2.6.7.
So this line of argument holds no water.
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.
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!
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
I think, without reading (for $$) the details on lwn.net, the point was that Linus was feeling productive working with Andrew Morton (who will become the 2.6 tree maintainer once they split to a 2.7 tree). Once there are sufficient changes between the released 2.6 and the patched 2.6.x-mm, Linus will move on to 2.7. There apparently will be some new features introduced directly into 2.6, but nothing really big.
Only when Linus was the maintainer. As soon as the kernel was handed over to Marcelo Tosatti, 2.4 got SIGNIFICANTLY more stable and development slowed to a crawl. Many peoples point is that 2.6 will never be anything but early 2.4 because Linus refuses to leave it behind and start something new. I blame a lot on Andrew Morton. Morton stated that he does not want to slow down development of 2.6 after Linus leaves 2.6 which means: 1. Andrew Morton should NOT be a maintainer of a stable branch because he does not have stability as a philisophical goal. 2. There is less reason for Linus to leave due to Mortons lack of intentions in the stability area.
I hope Linus can find a way to choose another 2.6 maintainer with a different predisposition.
I don't think anything bad about Morton- he is just meant to be a developer and not a maintainer. It is also a weekness of Linus. Torvalds has too much fun as a developer to be a good maintainer. Fortunately in the past, Linus has left maintenance in the hands of people who were GOOD mainteners and Linus kept doing what he is best at ,which is development. I and many others are saddened that the 2.6 kernel will not trully be given into the hands of a good maintainer like Linux has historically progressed.
I miss the Karma Whores.
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.