Slashdot Mirror

Raj Dutt has done a nice writeup on why you should, or shouldn't try a devel kernel. If you've never tried one, and wonder why or even if you should try, you should read on. Especially timely considering yesterdays feature freeze, we're on the home stretch for 2.2.0. The following was written by Slashdot Reader Raj Dutt

In the world of Linux kernel development, both Development-releases and stable-releases are developed concurrently. This is an extremely effective method of development as it provides the basis for improvement at both unbelievable speed and quantity. However, since the model does not follow the traditonal singular develop-release-develop-release cycle, it can create great confusion among users.

Before detailing the implications of development kernels, it might be beneficial to some to understand the kernel versioning convention:
(Generation.Major.Minor)

It is the Major number that is the key here. An even Major version represents a stable, release kernel and an odd Major version is indicative of an unstable, development kernel. For example, version 2.0.33 means "33rd minor release of the Second generation, 0 (even therefore stable) Major version Linux kernel." Using the same classification, version 2.1.91 means "91st minor release of the Second generation, 1 (odd therefore unstable) Major version Linux kernel"

Hence, the 2.2.x series, which will be released starting with 2.2.0 in the near future, will be the next Major version of stable kernel releases.
With that out of the way, let us examine the PROs and CONs of using development kernels.

The PROS

Nobody (well almost nobody) will deny that the current crop of release kernels work great. Why then should one jump ship and run something that is not nearly as stable as 2.0.33? The development kernels offer three main advantages that often convince people to go with them :

Firstly, after 91 development kernels, ALOT of new hardware is now semi-officially natively supported. If you have a device that you can't use because of the simple lack of a driver, check out the 2.1.x series, there is a good chance that your hardware will be among the hundreds (Color Quickcams, Radio Cards and NCR53C9x SCSI just to name a few) of new components supported.

Secondly, there are numerous technical arguments for the superiority of the latest crop of creations. These include :

• Faster access to user memory (covering the 4GB user space in its entirity)
• Unbelievable improvements in SMP (Symmetric Multi-Processor)
• Major tcp/ip updates - (read: faster better networking)
• Better PCI access and support
• Major disk swap / buffer updates (including dcache)
• Lot's of improvements for non x86 (intel-like) architectures
• Improved x86 IRQ handling
• Lot's of filesystem code updates - FAT32 is natively supported, improved VFAT etc.

There are lots more. Literally hundreds. For a complete listing of changes, visit Cutting Edge Linux - a great site which keeps track of the additions on a per kernel basis.

Thirdly, in addition to the technical benefits and new device support that you may grow to love, you can bask in the knowledge that you are helping the Linux Kernel development. By sending in bug reports, you are aiding in the quality control department - something extremely important when talking about code which needs to be bulletproof.

The CONS

The very word Development carries some connotations that cannot be simply ignored. To put it bluntly, when you install a development kernel you are venturing into unchartered territory. Don't expect to receive sympathetic support when something goes wrong. Development is proceeding at an unbelievable rate and nobody is going to stop to hold your hand. "It's broken? Well it's a development kernel, what did you expect?"

Alot of people run Linux for the stability. Be prepared to give some of that up if you choose to run with 2.1.x. Since they have not been tested (at least not as thoroughly as mainstream release kernels =), your mileage with development kernels will vary. Even experiences using the same kernel on different machines can be very different. After running version 2.1.91 for just under a week, I have noticed a few problems. None of them have been serious enough to bother reinstalling 2.0.33 though. Namely, I had to upgrade my pppd to 2.2.3 and twice I had to bear some serious disk thrashing for no apparent reason.

IN CONCLUSION

Obviously, a non release kernel is not for everyone. If you run a mission critical server or have a strong need for stability, stick with the even-numbered kernel releases. But if, like me, you have a personal workstation to fool around on and are always looking to try something new, then you might wish to consider "upgrading" to a development kernel

When it comes down to the crunch, It's really a question of balance. If you can sacrifice a little stability and the possibility of a few problems for the excitement and improvements of being right on the bleeding edge, go for it.

Ed:With yesterday's feature freeze, hammering out those bugs is very important, if you're looking for something new to try, the next few releases in the 2.1.* series should keep getting more stable for the soon-to-be-ready 2.2.0.

Raj Dutt has done a nice writeup on why you should, or shouldn't try a devel kernel. If you've never tried one, and wonder why or even if you should try, you should read on. Especially timely considering yesterdays feature freeze, we're on the home stretch for 2.2.0. The following was written by Slashdot Reader Raj Dutt

In the world of Linux kernel development, both Development-releases and stable-releases are developed concurrently. This is an extremely effective method of development as it provides the basis for improvement at both unbelievable speed and quantity. However, since the model does not follow the traditonal singular develop-release-develop-release cycle, it can create great confusion among users.

Before detailing the implications of development kernels, it might be beneficial to some to understand the kernel versioning convention:
(Generation.Major.Minor)

It is the Major number that is the key here. An even Major version represents a stable, release kernel and an odd Major version is indicative of an unstable, development kernel. For example, version 2.0.33 means "33rd minor release of the Second generation, 0 (even therefore stable) Major version Linux kernel." Using the same classification, version 2.1.91 means "91st minor release of the Second generation, 1 (odd therefore unstable) Major version Linux kernel"

Hence, the 2.2.x series, which will be released starting with 2.2.0 in the near future, will be the next Major version of stable kernel releases.
With that out of the way, let us examine the PROs and CONs of using development kernels.

The PROS

Nobody (well almost nobody) will deny that the current crop of release kernels work great. Why then should one jump ship and run something that is not nearly as stable as 2.0.33? The development kernels offer three main advantages that often convince people to go with them :

Firstly, after 91 development kernels, ALOT of new hardware is now semi-officially natively supported. If you have a device that you can't use because of the simple lack of a driver, check out the 2.1.x series, there is a good chance that your hardware will be among the hundreds (Color Quickcams, Radio Cards and NCR53C9x SCSI just to name a few) of new components supported.

Secondly, there are numerous technical arguments for the superiority of the latest crop of creations. These include :

• Faster access to user memory (covering the 4GB user space in its entirity)
• Unbelievable improvements in SMP (Symmetric Multi-Processor)
• Major tcp/ip updates - (read: faster better networking)
• Better PCI access and support
• Major disk swap / buffer updates (including dcache)
• Lot's of improvements for non x86 (intel-like) architectures
• Improved x86 IRQ handling
• Lot's of filesystem code updates - FAT32 is natively supported, improved VFAT etc.

There are lots more. Literally hundreds. For a complete listing of changes, visit Cutting Edge Linux - a great site which keeps track of the additions on a per kernel basis.

Thirdly, in addition to the technical benefits and new device support that you may grow to love, you can bask in the knowledge that you are helping the Linux Kernel development. By sending in bug reports, you are aiding in the quality control department - something extremely important when talking about code which needs to be bulletproof.

The CONS

The very word Development carries some connotations that cannot be simply ignored. To put it bluntly, when you install a development kernel you are venturing into unchartered territory. Don't expect to receive sympathetic support when something goes wrong. Development is proceeding at an unbelievable rate and nobody is going to stop to hold your hand. "It's broken? Well it's a development kernel, what did you expect?"

Alot of people run Linux for the stability. Be prepared to give some of that up if you choose to run with 2.1.x. Since they have not been tested (at least not as thoroughly as mainstream release kernels =), your mileage with development kernels will vary. Even experiences using the same kernel on different machines can be very different. After running version 2.1.91 for just under a week, I have noticed a few problems. None of them have been serious enough to bother reinstalling 2.0.33 though. Namely, I had to upgrade my pppd to 2.2.3 and twice I had to bear some serious disk thrashing for no apparent reason.

IN CONCLUSION

Obviously, a non release kernel is not for everyone. If you run a mission critical server or have a strong need for stability, stick with the even-numbered kernel releases. But if, like me, you have a personal workstation to fool around on and are always looking to try something new, then you might wish to consider "upgrading" to a development kernel

When it comes down to the crunch, It's really a question of balance. If you can sacrifice a little stability and the possibility of a few problems for the excitement and improvements of being right on the bleeding edge, go for it.

Ed:With yesterday's feature freeze, hammering out those bugs is very important, if you're looking for something new to try, the next few releases in the 2.1.* series should keep getting more stable for the soon-to-be-ready 2.2.0.

Get ready to rumble as the tidal wave continues. First off, Andrew Mobbs sent us an important list of must-read RFCs. RFC2321, RFC2322, RFC2323, RFC2324, RFC2325. He also reminds everyone that ds.internic.net is no longer the canonical RFC archive. Luis Villa sent us Important news on the Java API. Gernot asked us to check This directory on ftp.gimp.org. Lastly, james sent us this one and Raj Dutt sent us this one.

Get ready to rumble as the tidal wave continues. First off, Andrew Mobbs sent us an important list of must-read RFCs. RFC2321, RFC2322, RFC2323, RFC2324, RFC2325. He also reminds everyone that ds.internic.net is no longer the canonical RFC archive. Luis Villa sent us Important news on the Java API. Gernot asked us to check This directory on ftp.gimp.org. Lastly, james sent us this one and Raj Dutt sent us this one.

Well with the UO lawsuits we were talking about lately, it's interesting that we suddenly have an X11 Linux client available for UO. Thanks to raj dutt who was the first to write in.