Slashdot Mirror
How To Upgrade Linux To The 2.6 Kernel
An anonymous reader writes "Here's a good computer project for the long labor-day weekend. KernelTrap has posted a howto detailing eight steps to upgrade your GNU/Linux OS from the 2.4 stable kernel to the 2.6.0-test development kernel. Complete with screen shots, the end result sounds to be well worth the effort." Since chances are most people will be upgrading anyway once 2.6 is deemed release-worthy, it's always worth learning the upgrade procedure well.
Anyone know why they still require gcc 2.95? Or is this a minimum? Will it compile and run with gcc 3.3.x without problems? I was under the impression they tried to target the current stable version of gcc on each new major release.
Well actually 'make xconfig' uses the Qt libraries. So 'make xconfig' is just as much KDE as 'make gconfig' is Gnome.
This seems to be yet another in the growing collection of mostly useless 2.6 "migration guides". It doesn't mention any of the common gotchas with configuration, its recommendation for invoking the build process is wrong, etc, etc.
A much better guide is Dave Jones's Post Halloween 2.5 document, which, although very slightly dated, does a much better job explaining how and why things have changed in 2.6 and their impact when upgrading from 2.4.
However, that doesn't mean we can't all contribute a little for these architectures. The PC has SPARC and ARM emulators, for example, which are about as close to the real thing as you're likely to get.
Even if only a handful of Slashdot readers who don't normally do kernel work just grab an emulator, cross-compile 2.6 for it, and see what breaks -- hey, it might make all the difference between a working 2.6 and another Brown Paper Bag release, for those architectures.
"Why go to all the effort? It sounds hard work!"
It really isn't. Arcem is pretty much complete, and even comes with a Linux image. As I'm suggesting a cross-compile, you don't have to worry about 90% of the "requirements". The filesystem tool is about all you absolutely need to update on the Arcem image.
"What do I get out of it? I don't even use this processor!"
Finding a single bug - even a single mis-placed #ifdef, as in the SPARC architecture, mentioned elsewhere - and getting a fix submitted, would earn you a place in the CREDITS file. You get to add the emulated architecture to your resume (if it's fashionable, such as the PPC64, SPARC64 or IX64). You also get "bragging rights" as an OS kernel developer.
That's not bad personal compensation for the effort needed. Linux itself gains, by getting more extensive testing on lesser-used architectures, where it has a good chance of cornering the market.
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)
Granted, you're mostly just trolling, but someone might seriously ask those questions. So:
Why is it necessary for anyone other than a kernel developer to compile the kernel sources?
Because this is still a development kernel. No Linux distribution ships with binaries of this kernel. So if you want to run it, you have to download the source and compile it yourself.
Why would anyone want to do that then? Because this is an open source project, and by running the test kernels, you help expose any lurking bugs so that they can be fixed. Once they're all fixed, the kernel can then be formally released. Distributions will ship with it, and people will then be able to run this kernel without the need to compile it themselves.
Should just anyone do this? No. This kernel isn't yet fit for a production environment. But people with spare machines, or who want to experiment, can do this if they want to contribute.
Why haven't all the optional pieces been broken out into modules yet?
Oh, they have been. Take a look at any of the major distributions. They ship with standard kernels, in which support for pretty much everything that can be modularized, is. That way it's as close as possible to a one-size-fits-all kernel and most users have no need to recompile it. About the only thing that can't be taken into account by this approach is CPU optimization, which is why a lot of distros ship with a set of otherwise identically configured kernels, each optimized for a particular CPU type.