After frothing lightly about the kernel-centricity, here's an email about the kernel. Please point out any errors.
I started to upgrade my first machine to kernel 2.6.0-test9 at the Sunday's ALUG meeting, as some of may have seen. I didn't actually complete the upgrade there. As with all good projects, I ignored it resolutely for two days and took another look at it on Wednesday. It seems there are some things which can catch out the unwary when you upgrade from 2.4 to 2.6, but it feels a lot faster, so it's probably worth doing if you have a machine with fairly simple hardware. I hear there are still IDE bugs, so maybe you should wait for 2.6.0 proper. Nevertheless, off I went.
First off, there's some changes in the device handling. Some time ago, devfs was introduced into the kernel. It offers a /dev which only contains the devices you actually have, rather than having you waste disk on a directory full of mostly unused special files. It seems that time has not been kind to devfs, as it upset kernel developers with a relative lack of maintenance, alleged design flaws and continuing its own incompatible naming scheme.
devfs is still there in 2.6 at the moment, but is marked as "obsolete". Before you rush to disable it, note that part of its intended replacement, udev, is on version 0.06. I'm using a distribution which makes devfs fairly essential, so I've left it enabled for now.
udev looks like a nice idea. It uses a really important new filesystem in 2.6, the sysfs. This is a virtual filesystem, like devfs and procfs, which exposes "kernel objects" as files. A "kernel object" seems to be a device or driver that is loaded into the kernel. When something is added to sysfs, the kernel calls hotplug (possibly familiar to USB device users) and udev acts on the hotplug event to create an entry in /dev. So far, not much difference. What is different about udev is that it accesses the sysfs object and calls a helper to tell it what to call the entry in /dev. That helper, called "namedev", can identify devices by their serial numbers, so even if you plug your USB printer into a different socket, it can still appear as /dev/lp0 without reconfiguring. Alternatively, it can assign a particular port to a particular device, so *that* USB socket is always your /dev/input/mouse0, even if you change the mouse plugged into it. Of course, this is controlled by text files for now. Will GUI user tools appear soon? More details in the slides and paper linked from http://kerneltrap.org/node/view/1029
Secondly, ModUtils has been replaced by ModuleInitTools. Outwardly, there aren't too many changes, as you can still use commands like "modprobe", but it says that a lot of tidying up of the interface between kernel and tools has happened. modules.conf is dead, long live modprobe.conf -- it's a simpler configuration file which can usually be generated from modules.conf by the supplier tool (called "generate-modprobe.conf"). It couldn't handle the trick my scanner does to ask the kernel to rescan the SCSI bus for it on first use of /dev/scanner, but apparently that should be done by udev now. (Yes, that means I'm prodding the scanner by hand until I have switched over to udev...)
An improvement which may interest some is the better ACPI support. Sleep, suspend to disk and suspend to swap are claimed to be supported, although I've not yet really tested this. The kernel can do an ACPI power off, which 2.4 never did on this machine.
Also, ALSA replaces OSS/Free as the preferred sound system. Yippee! If you haven't been using the Advanced Linux Sound Architecture, then you're probably going to get access to all the features of your soundcard for the first time. I had been using the OSS/Free which was installed by the distribution. I didn't even know that the sound card can do half the tricks it can. It sounds much nicer now and debian users won't have to fiddle around as much to make it compile.
One final note. On the second machine I upgraded, the compile failed with the error that it couldn't find stdarg.h, which is a header that comes with GCC. It seems that the kernel Makefile uses options to GCC that the GCC manuals say not to use. A quick (and slightly dubious) edit of the Makefile to replace "-iwithprefix include" with "-I/full/path/to/GCC/header/include" made it work. I'm not sure what is different between the two machines, as they supposedly have the same distribution with the same GCC version.