Linux 2.6.0-test3 Released

xepsilon writes "Linux 2.6.0-test3 has been released. Grab your copy off your local kernel.org mirror and report those bugs! Remember, any bug you find that you don't report is likely to not be fixed in the next release if you don't report it. See the ChangeLog for more details."

Comments

Heh

[Eric(b0mb)Dennis]

Remember, any bug you find that you don't report is likely to not be fixed in the next release if you don't report it.

Time for some homebrew babelfish

Translation: Any bug you don't report (But hundreds of others will) might not be fixed, that is, if you don't report it!

geeze :P slashdot is replacing fark for the laugh factor

Payment?

[alien_blueprint]

Great!

But before I download this, where do I pay my SCO licensing fee?

Re:Payment?

[Pharmboy]

It appears that any kernel version 2.6 is royalty free, since SCO has only claimed IP in 2.4 and 2.5. so go wild.

Re:Payment?

[Pharmboy]

No, I found sco in the changelog... so it's only a matter of time before payments are required. It's gonna cost big.

Various schemes failed; immediately deregistering while in the diSCOnnect routine causes crashes because the videodev layer sets some ..
stack, and which had gone out of SCOpe. ..

Maybe this means they will reduce the price for licensing 2.4 kernels to $499, and charge the $699 for the 2.6 kernels, making 2.4 affordable to most people. I bet they are even nice enough to let you upgrade your 2.4 license to a 2.6 license for only $399. Thank god SCO has been so understanding during this time of potential IP infringement.

Think I will go buy some of their stock now. Surely if they go with this type of licensing of Linux, it will generate lots of good will in the community.

Translation

[wfberg]

If found a bug, by you it is, report it you must, or fixed not it will be. This I sense in the Force. Chances you must take not, that reported by others it is, such a bug. Vigilant always, a kernel tester must be.

(For those of you who report "Jedi" as your faith on the Census).

Re:What else do you need beside the kernel?

[geeveees]

You *need* to upgrade modutils, also if you want to use cryptoloop you'll have to get a new util-linux.

Re:RPM for Redhat 9?

[Pharmboy]

You won't see an official rpm from redhat on an experimental kernel. typically, redhat released kernels lag a couple months anyway. You might find 3rd party RPMs, but your mileage will REALLY vary.

You really don't want to install an rpm of an experimental kernel anyway, you should build it yourself. If you are not familiar with building your own kernel (not trivial, but not that difficult) then you should probably stick with stock kernels, since experimental and/or release candidates tend to have bugs that can break things. Also, anytime to upgrade from 2.4x to 2.6x you can expect potential to break things anyway.

The best thing is to install the source on a spare box, and compile it yourself, or learn how to if you don't know how. Its not THAT hard, but expect to screw it up a few times at first. Just be sure to update GRUB or LILO (and run lilo).

I use pretty much stock kernels now, although I will build them on my test boxes, to get a better understanding of changes. The stock kernels from RedHat are pretty good and functional from my experience, unless you need UberOptimized kernels.

It will likely be a few months AFTER 2.6 is released officially before RH issues and official version. Keep in mind that any 2.x.0 kernel is going to have the MOST bugs anyway. Most production boxes should wait for 2.x.2 releases anyway, unless they absolutely NEED the new features, or you love living on the edge (which if that is the case, you would be building your own kernel anyway).

One more thing...

[Markos]

Remember, any story posted to slashdot that isn't edited is likely to have errors if it isn't edited.

Thank you.

Re:RPM for Redhat 9?

[AndersM]

RedHat's Arjan van de Ven has RPM's here.

But: Half the fun of Linux is hand-tweaking your own kernel setup and compiling your own. Why not just do that? =)

Also, remember that you need to upgrade other pieces as well when going from 2.4 to 2.6 - the module utilities in particular. They are now known as "module-init-tools"

Re:RPM for Redhat 9?

[Xpilot]

However, if you do want an rpm, there are people at Redhat who do build them ;)

You can download from here.

Re:What else do you need beside the kernel?

[etymxris]

Here's your list of gotchas. Read it carefully before proceeding.

Here's How to Test Your New Kernel

[MichaelCrawford]

You should test your new kernel more thoroughly than by just casually trying it out on your machine. You can help the kernel developers significantly by doing so. You should also never deploy a new kernel on a production machine, even from a stable source version, unless you have rigorously tested it. While it may work great for everyone else, you may be personally blessed with the discovery of your very own bug, a bug which may cause data loss or significant downtime.

You should also be aware the Linus gets to release a new kernel whenever he wants. He does this when he thinks its the right time, for reasons that don't always involve reliability. He posts a new kernel release when he feels its ready, often without testing it particularly rigorously, and it has happened quite a few times that Linus has released a new "stable" kernel that turns out to be quite broken. It is actually quite common for the stable releases of the non-86 architectures to be quite buggy.

Finally, Linus announced on linux-kernel that the reason he released the first 2.4 stable kernel (2.4.0) was because he wanted more widespread testing, not because he felt it was ready to use. I wouldn't be surprised if he does this with 2.6. Both 2.2 and 2.4 went through several releases before they were really stabilized, and 2.4 has never been as reliable as the later 2.2 versions.

That's why I ask you to read:

• Why We Should Test the New Linux Kernel
• Using Test Suites to Validate the Linux Kernel

The Open Source Development Lab's Japan development center used to have japanese translations of them but they don't seem to be online anymore. I'll track them down and post them here when I can find them.

I am actively seeking further translations of these and the other articles that are at The Linux Quality Database. The articles are all under the GNU Free Documentation License so you can just grab them and translate away.

Thank you for your attention.