No 2.7 Linux Kernel Branch Due Soon 447
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."
Wow (Score:3, Insightful)
Re:Wow (Score:4, Funny)
This is bad. (Score:4, Insightful)
Re:This is bad. (Score:5, Interesting)
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.
Re:This is bad. (Score:2)
Fair enough, but most distros were back-porting patches anyway. I usually would actually get rid of my default red-hat kernels and download them from kernel.org
Re:This is bad. (Score:2, Insightful)
To FreeBSD. Now I get software that is as up to date as I want it, and the base system and kernel are left alone ot
Re:This is bad. (Score:5, Informative)
Not quite. It was Linus that ripped the VM out. Red Hat sticked with the VM that originally shipped with 2.4
Re:This is bad. (Score:3, Insightful)
Dude, then use Debian stable or testing or another community distro.
Very true (Score:2)
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. Bil
Re:Very true (Score:3, Interesting)
I too was worried when I saw the "final stabilization" phrase. If you read the article, it's no big deal.
What I really liked was the multiple admissions that devfs was a pie
Re:Very true (Score:5, Insightful)
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.
Re:Very true (Score:3, Informative)
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 blin
Re:Very true (Score:3, Insightful)
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
Re:Very true (Score:3, Insightful)
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 vend
Re:Very true (Score:3, Informative)
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
Re:Very true (Score:2)
Why not keep the even number for "no active development" and put the development into the odd number with only bug and security fixes in "stable"?
Maybe I'm getting old or something, but what they have ain't broken. They just need to be more rigorous in their application of their own rules.
Re:Very true (Score:2, Insightful)
Unstable as in "active development is going on", not as in "no worky."
Re:Very true (Score:3, Interesting)
Re:Very true (Score:2)
Re:This is bad. (Score:2)
Your tense is incorrect.
Which kernel was an unstable piece of crap? (Score:2)
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?
Re:This is bad. (Score:2)
Its not really any different than it is now. There have been production kernel releases that have sucked, and most people who are using linux beyond a hobby are already relying on a distribution to provide a stable kernel. I will say that the linux kernel has never been an "unstable piece of crap" since I
Re:This is bad. (Score:2)
Let's say for the sake of argument that 2.6.8 is a stable kernel, but thing breaks at
In my opinion it doesn't really matter whether the unstable kernel is named 2.7.x or 2.6.9.
Re:This is bad. (Score:2, Insightful)
Distro maintainers who don't want to do their own patching of the kernel mainline can simply grab the source RPM for RedHat's or SuSE's kernel, and use that kernel and patchset for their own distro. It is GPL, after all.
Re:This is bad. (Score:3, Informative)
Unless you pulled 2.4.11-dontuse or 2.4.15-greased-turkey off kernel.org.
what next? (Score:5, Funny)
what's next? a story on microsoft *not* putting out a new version of windows?...oh, wait...
Nothing like... (Score:4, Funny)
Oh dear... (Score:3, Insightful)
Re:Oh dear... (Score:4, Insightful)
So with development continuing longer on the 2.6 branch it might help decreasing the diversety of the different vendor kernels. At least it is worth trying.
Re:Oh dear... (Score:2)
It's already a pain in the ass to deal with different kernels, threading models and c library revisions. As the kernels start to diverge, the concept of what "linux" is becomes less and less clear.
Meanwhile, I can run code compiled for Windows NT 3.5 in 1992 on my Windows XP box with little fuss.
Re:Oh dear... (Score:2)
A large number of programs will not run properly, even in "compatibility mode". I can specifically recall having problems with 4 or 5 programs, mostly older games, that have problems on newer NT machines.
Re:Oh dear... (Score:2)
Unfortunately from a support standpoint, a lot of legacy code runs just fine on 2000/xp. So we couldn't use incompatability as a reason to move people off of things like WordPerfect 5.1 for Dos and WP 6.0 for dos.
Even the little things I did in Visual Basic for Dos ran just fine.
Not entirely unexpected.... (Score:4, Interesting)
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.
Your 2.6 kernel is, and always will be, stable (Score:4, Insightful)
Say, 2.6.6.
Then they'll backport security fixes just like they did for 2.4.
The difference is nothing.
Re:Your 2.6 kernel is, and always will be, stable (Score:3, Insightful)
I just finished installing a webserver and it doesn't seem to suffer from having a 2.4-series kernel. Maybe it would be COOLER with a 2.6 but I somehow doubt it. Then again, some people like to rice their cars, too...
Re:Your 2.6 kernel is, and always will be, stable (Score:2)
Then why have 2.6 vanilla releases at all? What are they there for? If they serve as a new-feature testing ground, then why not create a 2.7 branch?
If the vanilla 2.6 series is used as a "base reference", then it must be a stable base point. This idea, however, has just been tossed out the window by Torvalds & Co.
What about people, like myself, who like to use the vanilla releases from ke
Features over stability means it's a dev kernel (Score:3, Insightful)
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...
Re:Not entirely unexpected.... (Score:4, Informative)
So far for me, 2.6 is turning out to be pretty stable, and I switched to it quite early, starting with 2.6.3 I think. In comparison, 2.4.3 was really bad. It was almost a miracle that I managed to avoid critical data loss after switching to 2.4.0 and using ReiserFS on my root partition.
2.6 so far just works and that's it. Maybe there's some lack of polish somewhere, but so far it works fine here on SMP.
Not again (Score:3, Insightful)
Re:Not again (Score:2)
That's exactly what it means. Reguardless of what people say, the even numberes kernels aren't stable until a couple of even numbered releases *after* the next odd kernel is created. Anyone who tells you different is a fool. Don't trust 2.6 for production machines. For your personal des
Slackware and Vanilla? (Score:5, Interesting)
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?
Re:Slackware and Vanilla? (Score:2, Informative)
Re:Slackware and Vanilla? (Score:2)
Just to be clear, it was a standard (and reasonable) kernel option that broke the nVidia drivers - it's not like the FC2 team put a crazy patch in the kernel that broke them.
-Erwos
Re:Slackware and Vanilla? (Score:2, Insightful)
Re:Slackware and Vanilla? (Score:2)
Question (Score:3, Insightful)
Re:Question (Score:2)
Not truely a bad thing... (Score:3, Insightful)
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.
Good! (Score:3, Insightful)
vendor support (Score:2, Insightful)
No end user product (Score:2, Interesting)
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.
Re:No end user product (Score:2)
Why not just run 2.6? I'm running 2.6.7 and if future kernels get too unstable (I see no indication of that), I'll just stick to 2.6.7 (which has proven to be rock solid for me).
More Practical Reasons? (Score:3, Funny)
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!
Re:More Practical Reasons? (Score:2)
They could take the Sun route and just renumber the next major version to Linux 7. Solaris 2.6 -> Solaris 7, Linux 2.6 -> Linux 7.
Re:More Practical Reasons? (Score:2)
2.7 ==> 2.8 ==> 2.9 ==> 2.10 ==> 2.11....
I fail to see a problem here
Re:More Practical Reasons? (Score:2)
on the other side of the coin, we'd have to worry about people associating Linux 3.1 with Windows 3.1. And let's not forget 'Linux for Workgroups' 3.11, where they simply rehash 3.1, only they make it actually work.
Too complex: time for microkernels? (Score:2, Insightful)
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.
Re:Too complex: time for microkernels? (Score:2)
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.
The Hurd's biggest problem right now is a lack of developers. Right now a few core hackers are doing a formidable job at porting the Hurd from Mach to L4, a modern research microkernel with extremely low IPC latency. This redesign is also attempting to learn from earlier mistakes.
Re:Too complex: time for microkernels? (Score:3, Interesting)
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 we
Re:Too complex: time for microkernels? (Score:2)
Problem is, these are not peers. They do not aim for full POSIX compatibility, they do not aim for multiple personalities nor for the level of development flexibility of the Hurd. They may fit on floppies, but so does GNU/Linux if you trim it enough.
You know just enough to be dangerous
microkernels are more complex (Score:2)
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.
Re:microkernels are more complex (Score:2)
We have enough system resources to pay for the cost of glue. Yes, the initial implementation is more complex, but further modular development gets simpler.
Glue isn't free (Score:2)
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
what you should have done :-/ (Score:2, Offtopic)
2. Try what you did, on one copy, for a day.
3. Buy support from the Reiserfs folks.
Re:Too complex: time for microkernels? (Score:2, Interesting)
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
oh that sounds great... (Score:2)
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.
Re:oh that sounds great... (Score:2)
but above comment doens't really make sense... I'm to tired... I'll shut up now.
As the kernel turns ... (Score:2, Interesting)
But can they (the kernel team) hope to rebuild the trust by making this policy change? Has Redhat (sorry, ha
Already happening.... (Score:3, Insightful)
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....
Re:Already happening.... (Score:5, Interesting)
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.
Re:Already happening.... (Score:2)
So basically (Score:4, Insightful)
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.
BAD move, very bad move (Score:3, Insightful)
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)
Lessons Learned from 2.4 (Score:5, Insightful)
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.
On one hand...and on the other (Score:2)
Re:On one hand...and on the other (Score:2)
Chill. (Score:5, Insightful)
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?
Re:Chill. (Score:2)
That is entirely contradictory; active development should not exist on a STABLE branch to prevent any unforeseen stability issues when introducing new code, ideas, and features.
On a STABLE branch you only want bug and security patches. People are very realistic that stable (even) Linux kernels have had serious issues, but introduc
Re:Chill. (Score:2)
2.4 had so many changes go in during it's [sic] "stable" life, maybe their [sic] just trying to be realistic and make 2.6 actually be more stab
Re:Chill. (Score:3, Interesting)
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. M
The name game (Score:4, Funny)
Linux 3000 Xtreme Professional Plus (codename: BiggerHorn) - based on NT (New Tux) technology.
kernel forking (Score:2)
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 kern
A Very Stolid Idea (Score:2)
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
Don't Panic! This is not a big deal (really). (Score:5, Insightful)
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.
Sign of instability (Score:3, Insightful)
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?
Help Me! (Score:2)
Joke Alert: Relax Mac hippies, I'm typing this on my Powerbook. (Cred to El Reg for the Joke Alert tag).
Version numbers: Gobleddygook or Fooforrah? (Score:3, Insightful)
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
Scary potential futures here... (Score:3, Interesting)
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 find this turn of events... disturbing. (Score:3, Insightful)
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.
Article text (Score:2, Informative)
In another thread, dicussion was focused on this "new development model". Jonathan Corbet explained that Linus Tor
Re:A good idea? (Score:2, Informative)
(Overly) simple answer: 2.6-mm is development. 2.6 vanilla is stable.
Re:A good idea? (Score:5, Informative)
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.....
BSD Style Versioning? (Score:4, Interesting)
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
Re:BSD Style Versioning? (Score:3, Informative)
There is only a single active CURRENT or STABLE branch at any time, but there are numerous RELEASE branches (one for each x.y version of FreeBSD)
CURRENT is the new technology branch which is considered bleeding edge similar to 2.5 or 2.7.
STABLE is also a development branch focused on making improvements but not on wholesale architectural changes to the system. Changes are intended to be more
Re:KDE releases??? (Score:2)
Re:Stable drivers would be nice (Score:2)
Why don't you use 2.4 instead?
Re:stick with 2.4.x? jump to a different kernel? (Score:2)
Re:stick with 2.4.x? jump to a different kernel? (Score:2)
Re:stick with 2.4.x? jump to a different kernel? (Score:2)
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 marketi
Re:Sounds good to me! (Score:2)