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.
Have they adobted the KDE release cycle?
uggh...
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.
In true slashdot tradition I didn't RTFA (for some reason I can't access it - can't be /. already, probably my ISP fucking up).
But it seems somewhat worrying for those who want to compile their own kernels it makes it harder to distinguish between stable and development and also it means the differences between distro kernels may be even more pronounced than before.
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
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.
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.
Will there be an easy to see marker in the version number indicating new features? I would like to know if a specific kernel was released for fixes or for new features. This is sure going to keep Gentoo's Portage people busy.
I suppose every changelog must be checked by the distro folks, so kernels can be marked accordingly.
I can feel the headache already...
On the other hand, 2.6 kernel is great, and well thought out and implemented features and hardware support should be welcomed with open arms.
-
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?
Then we can't tell users to "go and get the lastest stable kernel from kernel.org" anymore huh ?
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.
on the article it has a picture of tux with a venus flytrap thing what is it?
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
... for the first poster who cries "FORK!!!"
What? Oh, jeez, it was me.
I'm not normally an irrational zealous dickhead, but I figure "When in Rome..."
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.
Kernal, huh? How about we call it a kernel. I call it the Linux Kernel, because it is a kernel called Linux.
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!
It is amazing how some people can rant on about the specifics the Linux kernel naming war, yet repeatedly spell "kernel" wrong. Before you start arguing about a subject, make sure you can spell it.
For example
Those damn Lunix hackers stole all the code from SCO. I think Lunix is an unstable piece of crap. Lunix steals jobs. Lunix made me an antisocial geek!
Despite the fact that my arguments have no merit, I spell the point wrong repeatedly and noone will take me seriously.
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
Looks like I picked the wrong day to throw out my Solaris disks
Sanity is the trademark of a weak mind. -- Mark Harrold
you have to become a kernel hacker if you want your own distro.
sure you can go for one of those 'stable' commercial kernels... but for desktops, remember to take one of the older ones they supply, as the latest kernels from commercial distro's are usually to bleeding edge to be considered rock solid. Not true for the server editions I guess.
But does that mean that if I want a rock solid 2.6 kernel I can't use the ones on kernel.org ????
That sounds silly.
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....
This would explain why they've decided to bugger up the support for advansys SCSI cards in 2.6.6+.
I'm having to run with 2.6.5, despite an incredibly annoying usbnet bug that I'm almost certain is fixed in later versions, because the kernel people decided now would be a good time to randomly make massive changes to what has been a pretty stable driver.
It's incredibly frustrating - I don't run a Redhat kernel, I'm happy using Debian, and this just means that somebody will create a stable kernel. Why doesn't Linus just hand off 2.6 to somebody else if he enjoys working with Andrew and then we could have (if necessary) an unstable tree that's occasionally stabilised, rather than the big bang release style that's been more common
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.
Microsoft, Apple and Sun will be falling over themselves with laughter when they see this. Linux's legendary stability will go down the pan, and people will leave in droves. Bill Gates and Steve Ballmer especially will make great capital out of this.
Stick Men
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)
Is anyone else glad that we got an explanation as to what an odd or an even number is? ;)
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."
since 2.2.x came out. the 2.0 branch was pretty good, but for now if you want stability, switch to FreeBSD.
The only thing that really upset me here was the offloading of stabilization to distros. What about distros that don't have a huge developer army (Slackware for example). Before this the vanilla kernel was actually useable. I wonder if this will make it less so. OTOH 2.6 isn't really feature complete quite yet. Some things like LVM2 still are missing from 2.6. So I guess I don't mind feature additions as long as they don't destablilize the main tree, thus requiring distros to use a non-vanilla kernel. Once we do that, you force distros to use an even more highly patched kernel than they currently do.
----- Question authority, but not ours. Hate the man, but we're not him.
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.
Gentoo always tests out kernels before marking them as stable, and always releases their own patches to improve performance and stability. What's different now?
How about switching the kernel to BSD so the SCO FUD disappears? I am thinking of OSX. Having the "secure" BSD's as well as Linux in the open space is confusing.
I was going to upgrade to a 2.6 kernel this weekend, but maybe I should stick with 2.4 the way the comments here are sounding. I generally don't concern myself with kernel-level details, but I don't care for Linus' decision here. The even-odd scheme gave me a level of confidence in any even-numbered Linux kernel that feels like it's just been yanked away.
Or maybe I should ditch Linux altogether in favor of NetBSD. I'm already running NetBSD on a couple of my boxen.
Constitutionally Correct
I don't like this, and not for the reason that we're breaking tradition, but we're entering the domain of applying new features to a branch that should be stable. If it's all bugfixes and tweaking you won't hear me object, but as soon as we're adding widely untested features into a stable branch I'm going to be extra cautious about rolling out 2.6 kernels on production machines.
As far as leaving the final stabilization to the distributors, do you really think that is such a good idea? The company I work for has a strict policy of vanilla-kernels-only. The reason behind that is that some companies enjoy stuffing the kernel with things from the unstable branch, making sure their distribution is more bleeding edge, but leave the bleeding up the end-user/administrator.
What's wrong with the cautious approach of keeping a stable branch? Anything new in the unstable branch can always be backported to it, and if it proves too much work or too much of an ugly hack, leave it in the unstable branch with the all too familiar warning: if it breaks, we warned you.
My guess is that I'm going to have to start believing the rumors that people are spreading, that 2.6 was released before it's time, and that I should stick to 2.4 for a little while longer on production machines. Not to be ungrateful for the enormous amounts of work developers around the world have done, but can you be a little more specific to the end-user/administrator what the effects on the vanilla 2.6 kernels will be? Are you going to change things so drastically that it might become unstable?
So, we're going to get all of the friggin schisms that plagued old unix are we? Bring back the highlander philosophy someone *PLEEZE* So, as a developer of a neato linux appliance my vanilla linux kernel from funet.fi won't cut it, or be understood by the vast army out there ('cos they are hacking on the red hat, debian, SuSE (oops Novell) variant or something else... We really need this shit. I need even more un R&R time... Sigh. Maybe NT embedded isn't so bad after all... Hey at least I won't get sued by SCO (grins)
The "stable" kernel broke at 2.6.3 when it was arbitrarily (read the usenet posts...) decided to remove the scanner module because libusb "should" work. Guess what. It doesn't. Not all the time. Not for my scanner and quite a few others (google it...). Oh, and I love the fact that any pre 2.6.4 kernel can't be compiled on GCC 3.3.3... really hoses things. So if I want to revert suse 9.1 to be able to use the removed scanner module, I have to change my compiler. Not good.
there we multiple flavours of Linux, kinda like BSD. A fork would be good. Not to mention we might start seeing more rapid development, and divergent philosophies might start producing more interesting sub-systems which could be interchanged. I suppose this happens to an extent, something more mainstream would be nice.
Won't this cause Linux Kernel forking? Each distribution will be adding "stabilization" patches to the kernel, which may or may not be compatible with other distributions' "stabilization" patches. These "stabilization" patches may or may not be accepted back into the Torvalds/Morten kernel.
They probably thought of all of this at the Kernel summit. The KernelTrap article only mentions:
"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."
Why did I lurk so long before registering for a Slashdot account? I could have had a Slashdot ID of less than 100000.
> Espcially if 2.6 becomes an unstable piece of crap.
I can't remember any development kernel in 2.5 that was an unstable piece of crap. Despite installing most of the latest releases when they come out I have not seen a kernel crash since 1996. Are there really people who have crashes on a regular basis?
i am concerned that this means that, in order for us to get stable kernels in the future, we have to pay our favorite distro. someone please explain how woefully incorrect i am.
1. Use dd to make spare copies of the raw disk.
2. Try what you did, on one copy, for a day.
3. Buy support from the Reiserfs folks.
This is a wonderful idea if you want to make it nearly impossible for small groups or individuals to develop and maintain Linux distributions. Has Linus now joined Microsoft in it's contempt for the small developer?
The great advantage Linux has had over Windows and several other operating systems is it's stability. Now that stability is going to be placed in the hands of those maintaining the distributions rather than those who have made Linux into what it is today. Instead of being assured that every even-numbered kernel is solid, anyone using Linux will have to pay careful attention to reviews from each distribution to figure out which ones are really stable and which ones aren't.
I'm a great fan of Linux and of Linus Torvalds, but I feel this is a huge mistake and I hope that either I'm convinced that my fears are unfounded or that this decision is reversed quickly.
-All that is gold does not glitter - Tolkien
www.ra
What the fuck. Linus, get a fucking hold of yourself and regain focus on what you are doing. There's no need to climb versions at the fucking pace you're doing now. Every new version of Linux is more shit than the last, to the point where I'm not really comfortable installing the latest "stable" Linux kernel onto my machines lest they break all sorts of things and/or crash and burn at unexpected times. Take a hint from FreeBSD and OpenBSD and take it a little easy, focus on stability, do code auditing. Stop churning out new kernels (even new major versions!) all the fucking time "just because." I long for the days of Linux 2.0 stability...
This is the beginning of the end for Linux. It will mean endless forks and shit patches. I want to be able to download the latest vanilla fucking stable kernel and have it be ROCK FUCKING SOLID. Keep development in the fucking development trees. CHRIST.
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.
Linux is dead? :)
Reality isn't like that. Artificial barriers between components lead to various hacks. Glue isn't free: there is complexity in the interaction of the many components. Microkernel systems pretty-much rule out many common ways of writing code, such as the use of global hash tables.
Depends on your usage. For a production server, I doubt you would want 2.6. The current versions of 2.6 (I've used my own vanilla versions, SuSe's and Mandrake's) seem to have stabilised sufficiently now for most purposes, however. I've used 2.6.x (x>=3) on my main desktop about 12 hours a day for months now with no trouble.
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?
It's a headache. The last kernel that flawlessly worked for me was 2.6.4, the rest had very annoying cd/rw problems and kept filling up my syslog, or SELinux giving me segfaults every other hour. The only thing that would force me to upgrade would be a security vulnerability.
Joke Alert: Relax Mac hippies, I'm typing this on my Powerbook. (Cred to El Reg for the Joke Alert tag).
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..."
don't look for a 2.6 kernel in debian stable for a long time.
I'm not sure yet what my take on this is. On the one hand it may mean some flux in the 2.6 mainline for some time to come. On the other hand I think it is a better way to continue development of features that will enhance the kernel.
The main problem with branching an odd series kernel is that no one wants to test it. People say that 2.6 came prematurely, but Linus had to shove it down our throats to get some users on it and iron out the bugs. It is amazing how bugs can hang around for months in some obscure tree, but once they go mainline, the bug fix is out in the very next release candidate.
Many of us don't want to be beta testers, but like it or not, this is Free Software and Linus can't afford an army of interns sitting around doing QA (think MS). I think that leaning toward the side of bleeding edge, and letting the distro's be a buffer for the people that want stable kernel releases is the best way to reach his goal, the best Kernel he can make.
As a Linux developer, I never have to deal with the complexity of doing RPC. I just make a function call. I never have to contort my design to avoid shared data tructures. I can do trees, hashes, hashes of trees, and so on. I don't have to worry that something might not be mapped. I don't have even half as many thread priority interactions that I would in a microkernel design.
Modular development of Linux is simple. The system is cleanly designed, unlike the 1980's monolithic kernels that microkernels are typically compared against. Developing for GNU HURD may well be easier than developing for SCO UnixWare, but who cares anyway? Linux is easier than both.
2.4.27 should be out shortly. If you feel the need to upgrade to something, upgrade to that! :)
2^5
Since you are still on 2.4 now, it sounds like you already distrust the even numbered kernels. I don't blame you, I'm still floating back and forth between 2.4 and 2.6 depending on the systems use.
I don't think this changes anything. If you look at the slow adoption of 2.6, the hit-and-miss stability and the general bugginess of 2.6, I think that the kernel devs have been developing in the stable branch since 2.6. The 2.5 unstable series development only changed in name to 2.6. It was more of a marketing/PR thing than a sign of stability.
To those of us who have been watching kernel stability, this is more of an admission than a revelation.
If tyranny and oppression come to this land, it will be in the guise of fighting a foreign enemy. - James Madison
I talk about stuff.
Isn't the proper response to this, that if Linux turns into a unstable POS, then you should fix it yourself? It is open source after all...
Development is impeded by difficulty in moving code around. There are artificial barriers imposed by the microkernel design. Heck, it's even difficult to debug because of all the threads running.
Microkernels: Just Say No
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!
I'm a little confused as to what people are talking about. Maybe it's just ignorance of the situation on my part. I haven't had trouble with the 2.6 kernel. I've had problems with linux in general like NVIDIA drivers, applications closing for no reason, arts crashing, but I don't know if those are related to kernel 2.6.7 that I'm running or other buggy applications. If 2.4 works then why bother changing it. Hell, you can always go back if it doesn't work out. I guess it depends on what distro you're running that would make it easy or hard to switch kernels back and forth.
Good luck nonetheless
Damn this Linus bloke for stopping our 2.7 dev stream...
:p
:D
You would think by the sound of it he knows something about Linux... gawd he's even acting like he created it!
No dramas with 2.4.x series for me, and now I'm on a 2.6.6 kernel with no dramas.
Using LVM2 + RAID-1 on EXT3 Most are 2Gb+ of RAM machines... with ~1TB of disk...
It's all down to what ya compile in ppl.
I have been running the Slackware 9.1 linux release since it came out. Excepting some early problems with XFS on IDE RAID, the only times I have rebooted has been to boot from a newer 2.6.x kernel. I would like to point out that if you start out with a well designed distro to begin with (, and not some distro that breaks when you add a new piece of software), the 2.6.x kernel is pretty darn stable (knock on wood here). Of course, YMMV.
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.
If this change produces better code, I doubt we'll here much more complaining. If it ends up making things worse, we'll have another data point to use for future work. Progress cannot be made without occasional mistakes, so they can try something else.
This was a very effective way to ruin my day, possibly my weekend. I'll have to consume copious amounts of [insert_drug_of_choice_here] to try to forget about this for the next 3 days. Just wanted to express my gratitude to Linus, AM and the gang for making yet another well-thought-out decision! NOT!
..." to honor of Mr. Torvalds & Mr. Morton's choice, on pretty much a daily basis.
Just when it looks like OSS really has a chance to succeed/have an impact, a prominent project such as the Linux kernel goes and does something really stupid like this that pisses off even their most hard-core fans that are not using said project for purely-scientific purposes, but also for business-oriented ones.
Oh well, I'm sure it will feel good to know a lot of sysadmins world-wide will soon say "In the words of Dick Cheney, go
Must-not-watch TV!
From the article, API changes are possible in the 2.6 branch possibly resulting in source or binary incompatibility with existing programs.
LedgerSMB: Open source Accounting/ERP
Don't neglect the advantages to this approach, which is probably a fallback to the "old style" of development
Removing the need to fully stabilize the kernel allows more features to be implemented and a more dynamic approach to be taken. Linux will be more nimble and evolve more quickly if the developers don't spend all their time doing testing. Let some of the users test.
How else can you kick-start development that might have slowed down or lost its focus?
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
So what is the Conclusion ? Yes DROPPING the buggy devfs code may lead to a MORE STABLE KERNEL! Slashdot posters seem to have a bad day... Oh well.
cheers,
Robert
udev has full devfs compatibility, but it does it in userspace.
Userspace is usually preferable to kernel space because it avoids bloat, it is simpler to write and maintain, and it greatly simplifies handling of a lot of exceptional cases.
Not only that, but devfs requires support from every driver in the kernel, which many driver writers consider cruft that they would rather get rid of if they do not need it.
Add to this the fact that devfs is not maintained and has known fixable and unfixable race conditions, and we end up with the desire to remove it in favor of udev.
GNU Linux. No, seriously. If the main branch of the kernel starts being used for development work, what's to stop the FSF creating and maintaining a stable kernel? (Apart from HURD politics, that is.)
Just a thought.
Escher did his work mostly with lithographs. I've never heard of or seen an escher painting.
-Reid
This is not in the spirit of Free software. It is vital that *ALL* kernel development is in the public domain due to the conditions of the GPL. Therefore making the kernel more stable. Any changes made by the distribution makers need to be reported back to the kernel team. This very kernel team also needs to be governed by a more democratic process to ensure that Linux is representative of the entire global community. The failure of the internet can be seen in ICANN being controlled by the US. Linux needs a 3rd party driver system and that coding should be done under GPL coordinated by the chip vendors where possible. The core kernel and interface structure should be the role of the kernel team. The current situation is too dependent on Morton or Torvalds. Let Linux be free!!! We need UN involvement in this or at least some migration toward a more scalable robust organisation. The freedom of the kernel from the Distro makers prevents RedHat or Suse from dominating it and turning it into a ms-windows closed shop. Another question is why so few comments in the kernel code??
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
If the major distros are left to stabalise things, couldn't this lead to different solutions from different companies? They arn't all as altruistic as you would like to think (they ARE businesses after all), and won't they be tempted to look after their own interests rather than those of the community?
I know they can do this to an extent with patches and the like, but I'd prefer a central place where submissions are made.
Silly rabbit
I can see why they would want this. It seemed like the kernel folks were spending all their enerygy packaging an unstable version so they could turn it into a stable one. They didn't get to do the fun devlopment that makes it worth it.
What I wonder about is it seems like the community will have to coordinate themselves a little more on which version of the kernel they patch at. Before it mostly centered on an even number. Now, there may be people and distributions working all over the place on which version they pick to enhance. Before at elast the features were the same even if they picked different point in like say, the 2.4 series. Now, the feature set will be different depending on which point they pick.
AB HOC POSSUM VIDERE DOMUM TUUM
I should mention that I wasn't working on Mach.
Several people on the team had worked with Mach
though, and thus knew well the errors of Mach.
So this isn't just a Mach problem. Switching the
Hurd from Mach to L4 won't save the Hurd.
Supposing that you're right about our culture,
and you may well be, shouldn't you account for
that in your design? If "getting it right" will take
forever no matter what your resources, you'd
best find some other plan. (monolithic for example)
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 think it will do the exact opposite. Much of the kernel fragmentation from the 2.4 series came from backported patches. Now, up-to-date features will be there in the current 2.6 kernel, creating less need for patches.
As for the final stabilization from the vendors, I assume these patches will make their way into the main kernel tree. As I see it, this will help everyone.
The biggest problem in making software is debugging. Writing code is simple, every monkey can do it. With enough monkies with typewriters and a few smart people filtering the monkey output you can even get something that improves over time. But to get real products that are usable, you need lots of competent people doing slow and hard work behind the scenes. Linux development is more and more moving towards a model where the real work is pushed to become Somebody Elses Problem. And people wonder why BSDs are getting more and more popular. Seesh.
Bug fixes and security vulnerabilities.
Say, for example, 2.6.8 turns out to have a bug or two and the odd vulnerability.
If 2.6.9 has other unrelated active development it has a greater chance of containing other unknowable issues than a 2.6.9 with fixes and minor mods to well understood code with track history.
__
Arse
This happened with 2.4 as well. I guess you guys don't remember the memory manager changes, and the instability in between 2.4.9 and 2.4.14 We had a saying when I was at IBM among us testers: Friends don't let friends run 2.4.10.
I stopped running vanilla kernels back then, and now I always use my distro's source.
And so far, 2.6 has done very well with this development model. It has acquired quite a lot of features that were still necessary, but has been a lot more stable than 2.4 in the early days.
Even for stability it might be a win. The kernel will be a lot closer to the kernels distributors are shipping (because they don't have to apply big patches for necessary features), which means that all their stabilization work can immediately be ported to the vanilla kernel.
Short summary: Andrew doesn't like big forks. I don't see how this gives up the idea of Free Software, as has been stated in many comments. Just to the contrary, IMHO.
This is a surprise to me. I always liked the idea of having a dev branch, and a stable branch. With 2.6 being active development, it kind of makes me worried about switching to the new kernel.
I run Slackware, and we use a vanilla kernel to start. I run 9.1 at the moment completely patched, and since I need no new functionality, I've no reason to move to Slack 10. For my own desktop I'm not really that concerned about the next kernel because I'm not changing my current (everything works) I am concerned about people that need to upgrade to get extra things on a newer system working. This could cause problems down the road.
Another problem which does scare me is that getting vendors (mainly gaming companies) to release ports for linux may have just become that much harder now that they can not write for a vanilla kernel. Perhaps it will not be a problem, or perhaps they will just release for RH (which I do not care for).
Suppose we will have to wait and see and hope for the best.
Brendan
Have you ever tried to switch kernel and then get your current modules to run smoothly? Ever used a nVidia card?
Thought so. The microkernel idea allows for user modules to work in a better way and not be dependant of the whole kernel.
You could much more easilly switch and upgrade drivers without the need to reboot the whole kernel. Yes, you can do some stuff as modules today, but it ain't very cross-version stable.
Nah, I just don't feel the need to keep up with the "latest and greatest" all the time. I ran YDL 2.1 well past when 2.3 was available, and finally upgraded just before 3.0 came out - 2.1 was good enough for what I was doing and I didn't see a reason to upgrade. Likewise, I stayed with MacOS 8.1 until X was available, because I saw no compelling reason to upgrade before that.
Constitutionally Correct
I think this is a mistake on the part of Linus, but anyway...
As Linus no longer sees the need to provide us with a stable kernel, a group of developers need to come forward and establish a credible project to maintain a stable branch.
While branches are ok for some things, I think the objective of small groups (from distributions) making the kernel stable is quite scary, and will be bad for Linux's reputation in general.
But often enough, newer features are labelled with such tags as [UNTESTED] or similar. This means that if you're compiling a kernel, you can tell which parts aren't necessarily going to work happily. Generally, the rest would be an update/upgrade to existing functionality, so it shouldn't be too unpredictable.
For those that make the distros, they'll probably compile the kernel without the UNTESTED sections until they are known to be more stable (or just use them as modules)
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.
OMG. If this is so, Linux is in for hard times, because regardless of what developers know to be the actual truth, the world considers 2.6 to be a stable kernel line. The even-stable / odd-development concept has a very long pedigree, and 2.6 was officially released as "stable" within that simple and clear scheme.
The lkml statement that 2.6 will no longer be regarded as a stable kernel, and that for stability people should seek assistance from distros, has horrible connotations. It comes close to suggesting that one should rely on commercial outlets instead of being able to rely on the power of the open community to create a stable product.
I forsee a lot of bad press coming from this.
"The question of whether machines can think is no more interesting than [] whether submarines can swim" - Dijkstra
"...continue in the mainline 2.6 tree, and the final stabilization will be left up to the companies that provide Linux distributions."
That leaves out the custom/hardcore linux users (E.g. LFS/BLFS).
Oh well, can't server everybody
On the other hand, I don't blame the key developers of glibc or the linux kernel - this is a much easier way for them to go about things. Since neither linux nor glibc has any warranty there is no accountability NOW - it's just a whole hell of a lot easier to find a working release.
"You're right," Fisheye says. "I should have set it on 'whip' or 'chop.'"
2.4 was released under pressure and it wasn't ready for primetime. 2.6 was all marketing. Expect it to stabelize around 3.1 er... 98 er... nevermind, just backport reiserfs to 2.2.21
This is why the BSDs exist. Stable, safe release versions, and fun, exciting dev versions.
Make the switch. It won't hurt too much, and you'll feel much better afterwards.
Ok, now what happens when a commercial distro ships a basic and a professional version? - Basic - The latest 2.6 deved kernel, no vendor changes - Professional - A vendor stabilized kernel that they charge you $ for - Enterprise - A vendor exetended kernel with all the features for $$$$$$. In all the open source community takes a hit. Branching, and be extension importantly vendor specific extensions, locks a customer into a particular vendor (the amount of testing and resources that an institution will spend in "certifying" a release is extensive). So much for an open platform. Furthermore, individual kernel extensions and stability components become proprietary, thereby reducing the amount of developer exposure and interaction in improving that particular feature.
Half of Slashdot's readers are below the median, not the average. Get your terminology straight.
here. (-:
Got time? Spend some of it coding or testing
Got two nforce2 boards with no problems running 2.6.7. Perhaps you had something unusual in your configuration, there.
When they say "stable" it is my clear impression that they mean:
1) No behavior changes, not even of undocumented interfaces. Basically, no user program should stop working because of a stable kernel upgrade.
2) No kernel module interface changes; no module should need updating because of changes to the kernel. Usually in an unstable kernel they will make changes to the interface without updating even the modules in the kernel, and the depend on the module maintainers to keep up.
3) And the catch-all: No huge changes which is likely to contain hidden bugs.
I am afraid this is a conspiracy by big commercial distributors. They want to be the only ones who provide stable kernels, so that we will have to buy their product. This decision to make 2.6 a development branch obviously hinders the interests of users and small non-commercial distributors.
oh brother, I'll move to BSD! www.freebsd.org www.openbsd.org www.netbsd.org www.dragonflybsd.org
> Unstable means that going from one release to the
> next you may have complete systems ripped out form
> under you and replaced with a diffrent interface.
Why would this matter to you if you are not writing drivers? I have not seen any single user-visible feature removed yet from the kernel during development. In fact such features are added instead, like the event device was added during 2.5. To an application developer the interface remains as stable as it can be. The only exception I can think of is the removal of ide-scsi that broke cd recording apps that relied on that.
This is one of the reasons I use Slackware. I want the genuine kernel , not some bastardised version hacked about by some kernel team wannabe in some backroom at Deadrat or whereever who thinks he can do better than the real kernel hackers. Screw that.
this is all horsehit. ... you know the open sourse thingy. but what
before getting scared about chemical photos showing
pictures of ghosts, pleeease reagard the fact, that
CPU and mainboard and all other crap is getting
faster by the day.
finally USB and firewire is officially supported
by
seems to be a buttload of stick it up my-ass (e.g.
gay)lamness (no other words seems to fit the day)
is god damn 3D video mega many transitor grafic
card support. HELP HELP!
hey you-a marketing for product guys ($ not N
OPTION)
I've been running it on several system since 2.6.2 and has not had any problems with it at all. Some things broke when I upgraded, but that was just because it does some things a bit differently from 2.4 (like input and framebuffers).
A lot of drivers in 2.6 were in a not so finished state at first, but this was mostly for new hardware anyway, so that was to be expected.
The most significant improvement for me is smb file transfers, where I have seen 4 times the transfer rates compared to the 2.4 kernel.
Kernel 2.6 works and is stable. One should keep in mind here that they are not using the 2.6 tree to test experimental stuff. The things that go into 2.6 has been tested first in the -mm tree, and only safe patches go on to the stable kernel.
I say things has been looking good with 2.6 developement so far, so let's try this out for a while, and see how it goes.
except instead of releasing it, it escapes. ;)
Remember, Slashdot does not have a -1 disagree moderation, and no, troll, flamebait, and overrated are not substitutes.
What do you do when you have a wife & two kids, and you're tired of de facto leadership of Linux marketing, and you don't want to appoint a sucessor?
Answer: You cease to do the necessary things you don't feel like doing, such as determining stable releases. "Stability" ceases to be the responsibility of developers, and the core (Linus) kernel development group become irrelevant to Linux users. Eventually, kernel development will fork to whomever is best able to take the reins of community chairmanship. Because the general public will go with the kernel that is most stable, able to be used in a production environment, and least hinders developer contributions.
Take a look, I suspect Torvalds is taking lessons from Bill Gates...
There is no America. There is no democracy. There is only IBM and AT&T and DuPont, Dow, General Electric, and Exxon
Nah, the development linux kernels are more stable than the "stable" ms win9x kernels. Well at from what I http://www.deanliou.com/WinRG/remembered.