Slashdot Mirror
Linux Kernel 2.3.41
sdriver writes "For those of us who enjoy *panic*, *oops*, and suddenly seeing their video BIOS... the newest version is out! Be the first on your block to submit a new patch! ;) " If you don't know where to get it, you probably should stick to your warm and cuddly 2.2.x kernel *grin*. Now outta my way, I wanna crash my laptop!
What exactly does ``unstable'' mean? Or, more accurately, what does ``stable'' mean? The 2.2.13 and 2.2.14 kernels (supposedly ``stable'') have rather nasty inode leaks. And 2.2.11 and 2.2.12 had a memory leak (which is why SGI based their SGI Linux 1.1 kernel patch on 2.2.10). Hmm... Looks like stability ``leaves somewhat do be desired''.
Featurefulness perhaps? Well, one patch I find extremely useful is the ext3 filesystem. (Now that seems stable enough, despite the frightening version number: 0.0.2c) But Stephen Tweedie hasn't finished porting that to 2.3.x. Another useful patch is the international crypto patch, and that doesn't come for 2.3.x... Or the Openwall security patch: ditto. Hmm... Looks like I'll stick to 2.2.x for some time. (And, no, it isn't exactly ``warm and cozy''.)
I'd like to try the 2.3.x kernels by using User mode Linux, but so far the only thing I've got from that is a core dump.
Sigh...
I've been running dev kernels for 2 years now and have never had to hack 'real C'. Yes things get broken, but I watch the linux-kernel mailing list and submit a bug report if I can't find the answer there. Some times its not the code thats broken, but new undocumented proceedures for setup. I test and report, and get a jump new setups. With lilo setup to boot multi versions of the kernel, I can fall back if things are badley broken.
If you can test, do! We all benifit in the end.
Krakken
I read here that IBM is offering Linux kernel developers code from AIX to integrate into Linux.
What does AIX have to offer Linux? Is there anything worth mining? Anything that could help the move towards 2.4?
(38 and on), I've not experienced ANY disk-corruption
whatsoever. There are, however, lost of other bugs,
both known and unknown. Why? Because us (relatively)
few developers can't possibly try every hardware
combination. We have a couple of new subsystems
in v2.3 which needs a lot of testing (USB (even if
it exists in v2.2, this one has been rewritten
quite extensively), FireWire, PCMCIA, I2C, I2O), as well as a lot of new drivers for soundcards, videocards, TV/Radio-cards, disk-controllers etc. The list can be made much longer.
Oh, and if you have an SMP-machine, you should definitely try v2.3.xx; a lot of SMP-related changes has been made, to improve the performance.
So please, unless you have production-machines, give the v2.3.41 or upcoming developmental kernels a try. You will certainly help both yourself and the Linux-community out in the long run.
If (when) you find bugs, submit them to linux-kernel@vger.rutgers.edu.
Uptime.o creates a
To use, simply run insmod uptime, and then echo the number of seconds of your uptime to
Never become the target of low uptime jokes again! Download uptime.o today - amaze your friends, terrify your enemies, and become king of all that is Linux!
- Hat (with too much time on his hands)
No, actually Linus himself has said that he *wants* as many people to use development kernels, *even if they're not developers*. So long as you don't mind putting up with some possible instability (or worse), there's no reason not to play with development kernels.
USB. Keyboard/Mouse/Joystick/Serial ports should work fine,
together with some less common stuff (some cameras,
for instance.) All in all, the USB-support itself
seems quite stable, but the problem is the lack
of drivers for everything but the most common things
(that is, those things that share a common standard or
one of the USB-developers own...)
If you have some device that isn't supported, why not either write a driver for it (IF you know how to do so, of course),
or contact the makers of the device and ask them for a Linux-driver (despite what many companies seem to believe, the consumer is always right. Well, apart from those that buy Micro$oft products, of course; they can't be right in their heads...)
If you have some device that isn't supported, why not either write a driver for it (IF you know how to do so, of course),
Hell, write one even if you *DON'T* know how. You'll learn a shitload.
Start here:
Linux Device Drivers