Slashdot Mirror
The Must-Fix List For 2.6.0
Jeremy Andrews writes "Andrew Morton posted a lengthy list of items that need to be done before the 2.5 development kernel tree should be turned into the 2.6 stable kernel tree. He prefaced his list by noting that 2.6.0 does not mean, "it's finished, ship it", alternatively offering, "I'd propose that 2.6.0 means that users can migrate from 2.4.x with a good expectation that everything which they were using in 2.4 will continue to work, and that the kernel doesn't crash, doesn't munch their data and doesn't run like a dog. Other definitions are welcome.""
Actually, accomplishing that would exceed the expectations I've evolved for 2.4.x. (That's the great thing about Linux performance -- if you don't like the VM, wait a day and it will change.)
What I'm listening to now on Pandora...
I'm all in favor of these things getting fixed so I can run the new 2.6 kernel.
Any, uh, realistics care to venture when all this might be done?
"Provided by the management for your protection."
so this isn't going to be Linux Kernel 3.0
(as previously reported on slashdot back in september)
Use my userscript to add story images to Slashdot. There's no going back.
Testify, brother!
We keep trying to go to 2.4, and end up back at good ol' 2.2 every time.
Most of our NFS infrastructure cannot be made to run under 2.4, and the scsi drivers (especially adaptec) suck (because they are poorly rewritten 2.2 drivers) and many of the network device drivers (such as, TG3) are so poorly written they will lock up your machine completely in a packet storm. Or, alternatively, they will create a packet storm.
I'm posting this anonymously because Alan's already mad enough at my whining and complaining.
It's free software. Use 2.2 until something better (maybe 2.6, maybe the mythical 3.0, maybe the Hurd) evolves.
Come on guys. I only had to stare at this story for a couple of seconds before I figured out that you're talking about the Linux kernel. But I shouldn't have to! Stop being so lazy!
Until I realize I am the only one around with the biggest pile of tokenring cards and hubs for testing. Maybe in the summer vacation, I could work on some of the code, and try fixing the receive buffer problems. This is assuming I'm a better programmer by then.
I hope the rest of the kernel is stable as hell by the release time. Most geeks in their homes with x86 clones dont need more functionality, we need stability that kicks Solaris and BSD.
"Give orange me give eat orange me eat orange give me eat orange give me you." -Nim Chimpsky
-B
Ash and Hickory, straight-grained and true, make excellent bludgeons, dandy for the cudgeling of vegetarians.
I've been running various versions of 2.5 for a while now. You need to make sure you have the new module utils installed, but otherwise just use it! I haven't had any problems with it (other than it can be a bit of a pain to get the nVidia binary drivers working, but it's not that bad). I think the performance is better. But if you can (IE you don't need hardware that doesn't currently work) then I'd suggest you use it.
Comment forecast: Bits of genius surrounded by a sea of mediocrity.
Yesterday I cooked up a 2.5.68 development kernel (the latest beta version as of this writing, according to kernel.org), since it has a fix for my newer chipset (damn VIA and their nonstandard AGP GART...), though I suspect that, depending on whether mine uses agp2 or agp3 I might be able to trick a stable kernel into playing nicely with it (assuming it's just a matter of model number, in which case agp_try_unsupported=1 comes to the rescue.)
My impression of the development kernel (aside from nice new features and not needing to 'make dep' anymore) is that it seems to be just a little bugfixin' away from being "ready"... and desktop users will appreciate the fact that ALSA seems to be in the kernel proper now, instead of being something to tack on the side afterwards.
So, these are all the things that should be fixed in 2.6, except the things that are broke, the things you want, and the things that don't work.
Not only that, if you do ask, they definately won't fix it. Love that open source.
I'd propose that 2.6.0 means that users can migrate from 2.4.x with a good expectation that everything which they were using in 2.4 will continue to work, and that the kernel doesn't crash, doesn't munch their data and doesn't run like a dog..."
Shouldn't we wait till the 2.4.x branch does that?
/* oops I accidentally made a comment, sorry */
I'm not sure if this has been addressed in 2.5 yet, so apologies if it has.
;
2 9947&list=7493
4 515769523283&w=2
:-)
Many thanks to Andrew for all his work, especially with ext2/ext3 (but much more I know). I'd like him to consider making sure that direct IO is properly working in 2.5 (and 2.4 for that matter). In particular
a) Support in ext3.
He posted a patch to the kernel list that added this, which I tested and it seems to work. It would be good if this is in the 2.4 and 2.6 kernel.
http://www.geocrawler.com/mail/msg.php3?msg_id=93
b) Correct functionality for non-4K multiple reads in ext2/ext3
i.e. less than 4K read as a remainder at the end of file. Again, Andrew posted a patch for this on the kernel list, and it seems to work. This is relevant for a) as well it seems.
http://marc.theaimsgroup.com/?l=linux-kernel&m=10
Apart from that, all the stuff we need to make sure we can read and write as fast as possible to disk or RAID would be great. I need at least 300 MB/sec (PCI-X, U320 SCSI bus x2) but the more the better
Keep up the great work!
There are probably about as many that I'd place in the "extremely useful & wanted by industry" category. The "lustre" filesystem would be in that category, for scalability, which IBM, et al, are positively screaming for.
There are probably about twice the above two combined in the category of "improves compatibility with other OS'". The port of Sun's Doors IPC system to Linux is one example. STP (Scheduled Transfer Protocol), from SGI, is another.
The practical reality is that you can't add them all. I know, cos I've tried, and the result is horribly unstable. I'm going to resume work on FOLK, asap, but I'm going to use the Linux Kernel testing code to develop a validation suite. It'll mean that patches won't match the author's version, but it should make FOLK a good deal more robust. (Besides, the main reason for using FOLK is to see how crazy the configuration menu has become.
So, what am I saying? I'm saying that either some need to be in 2.6.x, and others added in 2.7.x, OR you need to add the bulk of these in 2.7.x.
The bottom line is that there's a lot of really important code that Linux needs, if it's to retain the crown as Standards King. The more lax we become in adding this code, the more the mainstream industry will stick to existing, closed-source solutions. Why switch to something that adds nothing? (From their perspective, that is.)
Linux is an amazing OS - the 5th fastest supercomputer in the world runs on it! Try that with any other mainstream OS! Its growth has been exponential and looks set to stay over that critical linear level for some time...
So far, much of what I've seen in 2.6.0 is great - for EXISTING users, but really doesn't offer any new strong incentive to those yet to take the Linux plunge. Hey, there's nothing wrong with the old incentives, but if you want to continue with the exponential growth curve, you've got to keep adding new compelling reasons why Linux would be worth the time, money and effort of switching to.
It's a small world and it smells funny; I'd buy another if it wasn't for the money; Take back what I paid (SoM)
Oh come on now guys. This is the 90s. We don't use Token Ring anymore. We use ATM and LANE. Oh wait, that was last year. Now we use FDDI. Oh wait, this is 2003. What the hell is wrong with you people?!
decent ntfs write support. every now and then i need to write some files to my brothers pc, but ntfs write support for linux is evil. it will screw your entire harddisk, so i converted his disk back to fat32. but this kinda kills a lot of security features so i would like to be able to write to his disk from linux.