Last 2.5.x Linux Kernel Released

Kourino writes "Today on LKML, Linus released 2.5.75, which he said will be "the last 2.5.x kernel from me", and that he and Andrew Morton are going to start a 2.6-pre series soon. While this certainly does mean things could get interesting soon, don't hold your breath about seeing the actual 2.6 for a while; there are still many areas that need work. This essentially means that the development branch is going into maintenance mode, and new features probably won't get in after this point. Changes of note in 2.5.75 include a merge of the anticipatory scheduler from Andrew Morton's -mm tree and updates from several architectures."

Comments

So

[Anonymous Coward]

Will the 2.6 "stable" kernel series actually be stable?

The 2.4 series had this public cloud of wierd problems hanging over it its entire existence. It seems like 2.4 never really seemed "trustworthy", they kept making huge and highly experimental changes and 2.4 seemed just kind of like a work in progress for its entire run. Will 2.6.0 be totally safe to download and run and install in a production environment, or is that going to be kind of a "well thats still sort of experimental be careful"? And if the latter, why the heck aren't they staying in 2.5 until it's ready for production.

Am I just too paranoid, or do you know what i mean?

-- anonymous and terrified

Re:So

[Anonymous Coward]

The main problems with 2.4 were the VM problems, especially on big boxes. Now with massive amounts of testing and resources especially from IBM, they are very much improved. There hasn't been a mention of a VM problem for quite a while.

2.6.0 I think will be a lot more stable than 2.4.0, but I don't think its for a critical environment. Its more to start getting testers on board. The number of people using 2.6 probably increases exponentially with each point release for the first few, so leave the more critical stuff for a while. Do you really need it?

What about C2 -style auditing?

[StupidKatz]

The SNARE folks say they are working to get C2-style auditing capability in the kernel, since the old hooks were broken/fixed in 2.4.21. This is a big feature that is keeping Linux from being a "serious" player in "secure" environments, such as certain government-controlled areas.

Re:Easiest way to fix the bugs

[Muggins the Mad]

>Just name it 2.6 - everyone will flock to it because 2.even means that it must be a stable release, never mind it's the first release.

And those who made that mistake with 2.4.0 will continue to ignore 2.6 until it's proven itself stable and not find the bugs anyway.

(I'm not one of them, but I have time to spend
on following dev releases. Not everybody does).

I'm not a fan of the "it compiles, ship it! and we'll fix it in a service pack" mentality.

- Muggins the Mad

Re:Easiest way to fix the bugs

[Bill, Shooter of Bul]

I'm not a fan of the "it compiles, ship it! and we'll fix it in a service pack" mentality.
And I'm not a fan of waiting for beta testing that will never happen before releasing it. It is a thousand times easier to find bugs that have been found. Therefore the method that allows you to find the most bugs in the shortest amount of time is the best method. This is assuming that you are not actually selling the product for a profit. In other words, release the 2.6 kernel because no one important is going to use it until it gets put into a distribution. So there's sort of always a testing period after the release but before most people start using it.
ok, I've managed to completly disagree with myself several times. I guess that means I must be right. Its pretty clear to me that there *isn't* a best solution. So for heaven's sake just do something, it will be better than nothing.

Hardware optimisation will be the telling factor.

[ratfynk]

It will be the processor optimisations that will determine the success of 2.6 Linux. The solutions that Microsoft has embrased with hyperthreading might be a non-starter for Linux. The Intel/MS world view is to optimise compilation for Windows and software emu the 32 bit environment, a difficult if not stupid way to do things.

If the Amd world view of how to achieve 32 bit without emu on a 64 bit platform are to fly then the adoption of AMD by the server world is essential for Linux in the future. Blindly following the Intel/MS lead may lead to kaos. The same as blindly imitating Microsofts functions by reverse engineering, is for programmers.

The office desktop lock of MS is not the route that Linux should take, the applied advanced scientific computing and clustering is the best route. When a great scientific workstation can be had for the price of a Linux install on a 64 bit AMD system the business computing world will finally start to wake up and take notice.