Slashdot Mirror
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."
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.
:)
Bitching will ensue, and the bugs will get fixed even quicker. Why mess around with all the pre-2.6 stuff, when this is obviously the fastest way to get it all working
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
the anticipatory scheduler, because I haven't been expecting them to do that yet.
"Linux 2.5.x? Pssh. That's old! I run linux 9.0!"
----
Go canucks, habs, and sens!
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.
Maintenance mode? No, 2.2 is in maintenance mode.
2.4 isn't even in "maintenance" mode yet - it is _the_ stable tree, and its getting new things added to it with each release (slowly, and after being tested in other trees, and RCs). Just recently new ACPI for example.
2.5 is going into "stabalisation" mode, to get it ready enough for 2.6.0 that it won't piss too many people off who try it. 2.5 has been a good cycle and 2.6.0 will be quite stable, but it needs to go through a few 2.6 point releases during which more and more people will start testing it.
Then _2.4_ will go into "maintenance" mode.
Linux definition: On most hardware platforms, a jiffy is 10 milliseconds in duration.
In other Engineering and science diciplines there are other definitions of "jiffy".
In English, it means "a short amount of time" as in "I'll do it in a jiffy".
Linus Torvalds and Alan Cox made a joint press release today. In an effort to save time, Linux 2.5.75 will be renamed 2.6.75, to reflect how mature they assume the code is. "We don't feel like bothering with all that 'pre-' crap, so we thought we'd save some time and just jump right into 2.6" reasonned Torvalds. Alan Cox elaborated that "when MS Windows went frm 3.11 staight to 95, they really left us behind. Now that they're at 2003, we've really got to get our shit together to catch up".
No more large changes are going to take place... just bug fixes, driver updates, etc. Today Linus said he would reject the HUGE (40k+ lines) ARM merge excepting stuff that only touched the ARM specific source (ie, arch/arm) even though ARM doesn't currently compile. The only thing he says must be working out of the box for 2.6.0 final is x86 and he doesn't care if other architectures are broken on release if fixing them destabilizes what's already there.
Don't leave your mind so open that your brain falls out. Don't close it so much that you cut off the blood.
-
Why We Should All Test the New Linux Kernel -
Japanese
-
Using Test Suites to Validate the Linux Kernel
-
Japanese
The Open Source Development Lab's Japanese facility was kind enough to provide the Japanese translations.I am looking for translations into other languages for all my Linux Quality Database articles - there are other articles on web application quality and C++ programming, and more will be posted from time to time.
They are all under the GNU Free Documentation License, but for reasons explained in Which License for Free Documentation? I am planning to change the license soon to another one.
Request your free CD of my piano music.
You kids and your new fangled "2.5". Back in my day, the kernel was 0.1, and the only supported boot device was a piece of toast. And we liked it better that way! Stable, unstable? Kids these days are so ungrateful. Back in my day, when linux crashed, not only did it erase your hardrive, but it put you into seizures! But it built character, and that's the way we liked it!
====
Crudely Drawn Games
Today LKML confirmed that linux is dying.
Linus was quoted as saying this will be "the last kernel".
This announcement, of course, has the same high validity as the claim that *BSD is dying.
I protested the release of 2.4, saying its inclusion in distros would cause users to unknowingly run a poor quality kernel, but Linus said the reason he wanted it released was so that it would get more widespread testing.
The "stable" branch of the kernel is perhaps misnamed. Linus gets to release a new kernel whenever he wants, and I imagine he does some testing, but I don't think he puts a stable release through any kind of rigourous qualification, I think it's more like when the complaints about his pre- versions die down a little.
I know it's common for Linus to release stable kernels that are actually quite broken on some non-x86 architectures. People who run Linux on PowerPC use a branch that's extensively patched from Linus' releases.
Both the 2.4 and 2.2 kernels went through a number of releases before they were really usable. I think the reason 2.2 became reliable was that it was smaller and simpler, and fewer people were working on it.
I'm pretty sure a good part of the reason behind the establishment of the Open Source Development Lab and their hiring of prominent kernel developers like Linus and Andrew Morton is to make sure that 2.6 actually does turn out to be enterprise quality. IBM is a big backer of OSDL, and I don't think they want the billion dollar investment in Linux in general to go to waste.
Request your free CD of my piano music.
Well, some of the nice things are:
o New i/o scheduler, which seems to improve a lot of people's desktop performance;
o Better scheduler performance under loads with lots of processes;
o Rewritten scheduling and threading code, which, coupled with Ulich Drepper's NTPL library, greatly improves threading performance;
o ALSA for sound, and AGP 3 support;
o Faster and cleaner framebuffer support;
o Faster CD recording that doesn't need ide-scsi;
o Upgrades for NFS (v4), NTFS, and HFS+, as well as merges of JFS and XFS;
o System-level in-kernel profiling support;
o CPU Frequence scaling
o IPSec
More information can be found in Dave Jones' list of things to expect in 2.6. Personally, I think it's great to see features that benefit both big and small systems.
perhaps "schedulatory anticipator"
- First they ignore you, then they laugh at you, then ???, then profit.
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.
OH THE SHAME I fell off the wagon and use sigs again!
Though we're bordering on offtopic here, because this discussion isn't as closely related to the kernel as it could be, I'm fairly convinced needs no focus as you imply.
First of all, the Linux kernel is and will be the most important readily available high performance computing platform. I cannot imagine a design decision with more than temporary character that will slow down the kernel. Through constant improvement it will lead on all 64bit platforms, Dec Alpha, PowerPC, IA-64 and x86-64. We all know, in the long run, open source isn't beatable in improvement. The kernel is already far on the right side of that curve.
Now, should Linux developers at large focus on scientific computing, or the desktop, on both? Actually this is a "no-question". The development force of open source will always distribute itself along its own best interests, not because of what anybody told them. Till now the technical gurus of programming turned the core of the GNU/Linux OS in what it is, but the evergrowing developer community is attracting more and more apps developers (they are simply more readily available). So while the kernel project is readily scaling to bigger and bigger feats, the app world will still aim for the desktop, the poweruser's desktop first. Simply because there are many people that want to provide apps and simply will do. This will not impair kernel development in any way, and anyhow those people have no different needs from the kernel as the scientists have: stable, efficient, robust.
Since the POSIX and other standards strongly decoupled OS internals from the apps developers (what's going on behind the scenes is no business of the apps developer) we have the power to do it both, in parallel, with no friction.