Slashdot Mirror
Future of 2.4 and 2.6 Kernels
Blair16 writes "According to this article on C|Net, not everybody is chomping at the bit for the new Linux 2.6.0 kernel. Marcelo Tosatti, the appointed deputy for the 2.4 kernel is not expecting to make any non-crucial additions to the popular kernel, saying that all new projects should be pumped into the new 2.6. This has upset some people who are not quite willing to move to so-called untested software. Some of their claims seem legitimate, but I wonder if all these people will really be left in the cold?"
How do these guys have any credibility? Aren't they just fanboys for whonever buys ads, or for whomever [SPIFFY CONSULTANCY COMPANY] says is the Next Big Thing. Want information? Ask RedHat. Ask Linus. Ask the folks at SuSE. What's next, Slashdotters panicking when Dvorak weighs in on kernel patches?
I want to delete my account but Slashdot doesn't allow it.
Microsoft no longer develops for Windows 98... Apple no longer develops for OS9...
So they don't want to move on to "untested" 2.6? If people added features to 2.4, it would become just as untested. Nobody's saying to halt all development on 2.4, just not to add new features. Stability fixes will still go in... heck, stability and security fixes are still being added to 2.2! Those who don't want "untested" software favor stability and security anyways... so stick with 2.4.
-3Suns
~~~~
The Revolution will be Slashdotted
The logical volumes manager (device-mapper) is still incomplete in current 2.6 kernels.
:
Snapshots don't work without an experimental patches.
Other patches are needed to make EVMS properly work.
This is a showstopper.
However, if you don't need virtual volumes, yes, 2.6 definitely
1) rocks
2) is stable.
{{.sig}}
We're running 2.4.18 on our linux router at Netmar, and we have 3 Cyclades PC300 cards installed, running 5 T-1 lines.
I was under the impression that driver was already in the kernel. I don't remember putting it in there otherwise.
Hrm.
~Wx
sig?
"pretender" is a false cognate in portuguese which means "intend".
And it's working great. That's 2 weeks without rebooting.
Now, I don't do anything critical or really strain the kernel at all, but it works great...never had one lick of trouble. It's also very peppy!
But for people running critical servers and the like, I can understand their reluctance.
"Music is everybody's possession. It's only publishers who think that people own it." - John Lennon.
Um, don't GNOME and KDE do that when you log out anyway? It's called session management...
My other car is first.
For future reference, the term is "champing at the bit", not "chomping at the bit":
http://www.brainydictionary.com/words/ch/champ1
Its a equine/race track metaphor. When a horse wants to run and you hold it back it impatiently grinds its teeth.
Chapel Hill, NC
I have been in the "nforce2 stability discussion", and the lockup issue surrounding it has been believed to be solved. There are two kernel patches available for test11. I don't believe there are any other issues.
You're in luck: Transgaming sells API implementations that support games like D2 and CS on Linux. (Actually they sell "subscriptions" but whatever.)
main(c,r){for(r=32;r;) printf(++c>31?c=!r--,"\n":c<r?" ":~c&r?" `":" #");}
yes, if the browser supports it. (a lot of them do opera, galeon etc.)
/usr/src/sys/pci/if_rl.c
* The RealTek 8139 PCI NIC redefines the meaning of 'low end.' This is
* probably the worst PCI ethernet controller ever made, with the possible
* exception of the FEAST chip made by SMC. The 8139 supports bus-master
* DMA, but it has a terrible interface that nullifies any performance
* gains that bus-master DMA usually offers.
better spend those 4 bucks somewhere else...
I encourage anyone running a desktop system to try 2.6.0-test10. I've occasionally tried the various 2.5.x kernels, but I've always found myself going back to 2.4.2x with Con Kolivas' patchset. Well, no longer. 2.6.0-test10 is better than I expected the 2.6.0 release version to be. If you're the type of person who would upgrade to a new 2.4.x version readily, you should get the new bandwagon now.
In Soviet America the banks rob you!
Worth noting is that the people complaining are the developers of "new" features, not the users. If a user needs a feature, he'll get the patch and apply it. The particular complainers are SGI's XFS file system team, users already have several choices in the kernel, so if they are not included the kernel their share will drop
Users, on the other hand, want their stable kernels to be stable.
You are in a maze of twisted little posts, all alike.
I mean which is the One True Mouse?
/dev/input/mice - All events from all plugged in mice (hotplug supported ones, anyway) get sent through this device.
Well noone ever stoped working on Apache 1.x and look at all the people that have switched to 2.x... Oh wait, almost noone has switched to 2.x yet because people just kept working on 1.x. noone has even bothered to port most of the modules to 2.x _correctly_ yet.
And so it will be with Linux 2.6.x
- Adam L. Beberg - The Cosm Project - http://www.mithral.com/
Here's how You should understand this issue:
linux-2.4.0.tar.gz is 24378762 bytes
linux-2.4.23.tar.gz is 37010062 bytes.
So you can expect 2.4.25 etc. won't go over 40 megs compressed. That's what a "stable" kernel development stands for.
(BTW it is kind of weird thing that a stable kernel has grown so much)
Is to try out 2.6.0-test11 which is the latest at this point in time.
/dev/input/mice works in the 2.6 kernels.
/dev/input/mouseX working in 2.4, though.
/dev/input
It's a very nice node. I never even got
$ ls
mice mouse0 mouse1
The Linux kernel is monolithic in the sense that it runs everything in a single kernel address space, all at the same protection level, but it is not monolithic in terms of the code structure or the development model.
I'm not sure you understand just how tightly bound the filesystem layer is with the rest of the system now. Sure, you can write to the VFS layer and whip out something fairly swiftly -- but the buffer caching mechanism that is above and below the VFS layer is a hairy bunch of interactions if you want to do anything other than the buffered fixed-size block writes that the VFS layer currently supports. A filesystem that supports variable-sized packet writing would *NOT* be easy, and would require major modifications to the kernel from the VFS layer to buffer cache all the way down to the individual SCSI and IDE drivers (although SCSI drivers, at least, *do* have support for variable-sized packets, so if there's a problem there it's a problem at the IDE driver level). There's just too much hard-wired all down the bottom of the API stack to do things easily if they were not invented at the time that the original authors designed the API stack.
Look, this isn't a problem specific to Linux. When Solaris came out in 1989 or so, it had a state of the art tape driver. Today, its tape driver sucks the big one -- it locks up regularly, does not support any modern tape drive features such as the LOCATE function or block positioning, and otherwise shows the fact that it was designed in 1989-1990 to the primitive hardware available at that time. It appears to be an architectural limitation in the Solaris kernel where it'd take ripping up a bunch of code to fix it, because otherwise the functionality would have been added over the years just as it was in IRIX, FreeBSD, and Linux.
As for why the Linux API stack has gotten so intertangled: It's all about performance. The Linux API stack used to be a lot cleaner and simpler, but as Mindcraft showed (in their second, fair, test, not in the first one that was rigged), it was also significantly slower than a kernel that had been hacked up with all sorts of nifty performance tricks. If you want to, e.g., ship a packet directly from a disk buffer to a network interface (a common performance trick), that means you have an interaction between the network API and the disk buffer API (and the filesystem API that is filling the disk buffer). Those interactions build up over the years. It's called "cruft", and Linux is starting to get somewhat crufty, though it's not as bad as in some applications of Linux's age that I've dealt with.
Anyhow, enough for now. It's late at night even here in San Francisco...
-E
Send mail here if you want to reach me.
I did some searching for a cheap NIC that doesn't suck. Intel and 3Com NICs are of course very good, but expensive. The low end cards seem to be mostly realtek crap or almost-as-crap AMD Pcnet based. Eventually I found a real gem in the Linksys LNX100TX cards. They are cheap, about 14 EUR here (the cheapest realtek cards are about 9 EUR), and the chipset they use is a clone of the famous DEC Tulip chip, which BTW has a real good Linux driver.
You have to enable the mouse driver under "input core". I enable everything under input core as modules. If you want to use a USB mouse you'll need to enable the HID driver under the USB menu. In the last few kernels you'll need to check the "HID input layer" checkbox, which isn't on by default. Hope this helps.