Slackware 11.0 - first experiences and upgrade process

Well, Slackware 11.0 is officially out after an exhaustive batch of release candidates and (due to some hideously attentive monitoring of the ChangeLog in recent weeks) I've already upgraded to this system. In fact, I've been downloading each new package for the last few weeks as and when they changed the Changelog, and about once every few days, I'd create a DVD and install it onto a copy of my primary partition to find problems before I took the plunge and actually started using it as my primary desktop (replacing an up-to-date, clean Slackware 10.2).

The upgrade, as ever, goes like a dream so long as you follow instructions *very* carefully - don't omit any steps. We won't mention my moment of idiotic forgetfulness where I forgot to upgrade the rc.udev file once I'd installed it or even failing to copy the initial /dev from my existing partition to the "mirror" partition that I was upgrading, both of which caused Slackware to fail to boot... One of those is mentioned in the upgrade.txt (transfer ALL the .new files across! In a moment of blindness, I omitted rc.udev.new), however the other was just common sense if you intend to work from an accurate copy of your existing system! Those installing onto a clean partition should have no problem at all.

After many, many tests (I was, after all, performing a major operating system upgrade on a system that was still being used for "real" work), I copied my Slackware 10.2 main partition to a blank space, freed up 1.5 Gb on it (as leeway for new packages, upgrades, temporary files etc.) and installed the upgrades over the top of this copy. Once I'd followed the upgrade.txt (which, at the time, was the 10.1->10.2 upgrade.txt but still the principle is the same), all I had to do was recompile my kernel (Slackware 11.0 now ships with GCC 3.4 which means you also have to recompile any custom kernel or kernel modules that you may have had from Slackware 10.2, which only used GCC 3.3), reinstall lilo and it all just worked.

However, be very careful if you have extra modules in your kernel (e.g. nVidia/ATI drivers, out-of-tree wireless drivers etc.) as they *will* need recompiling. When you are using the same compiler and kernel on two different machines, the modules are usually transferable between the two machines, but Slackware has changed the default compiler so this time-saving trick no longer works. Failing to recompile them *will* crash your machine, maybe not immediately - for instance, in my initial testing on a blank partition, failing to recompile the nVidia modules and instead "copying" them from a previous installation crashed the machine hard as soon as OpenGL was used, but had functioned perfectly until then (even accelerating X and video flawlessly).

The crash was so hard that the (journalled) filesystem stopped halfway through a write and corrupted the partition - proof, if ever it were needed, that the use of proprietry modules removes any guarantees of stability and also that journalled filesystems and RAID are no substitute for adequate backups. That's also why you should always backup and/or test on a copy of your primary partition before you do stuff like this - I did it out of academic interest and was surprised that X or the kernel didn't throw up more warnings.

Applications, however, should not require any re-compilation at all, unless they are very tightly integrated into the kernel or statically build from the supplied libraries (something that they shouldn't do for most purposes). I haven't found anything that I've needed to recompile except for kernel modules but I'm sure I will find something that will have stopped working - a lot of stuff uses the kernel as the definitive source of information on things like kernel structures etc.

KDE was neatly upgraded to 3.5.4 in the process, all my old settings just ported over without any hassle (although a few KDE-specific tweaks, such as what the taskbar looks like and how multiple-desktop thumbnails work had reverted to a new default - easily changed and they were the exception rather than the rule). And it still runs like a dream.

Given a 1Ghz, 512Mb RAM machine, there is no significant detrimental performance difference between Slackware 10.2 and 11.0. In fact, because of both the KDE and X.org upgrades, programs under X run noticeably smoother - this is an old machine and small optimisations make a big difference when you don't use eye-candy like transluceny and anti-aliasing. Even code like a static-QT installation of Opera 9.0 is seeing responsiveness improvements compared to before. Given that Slackware is not designed as a desktop OS, it functions admirably under such circumstances and the system requirements are minimal.

Because it's Slackware, most desktop software will require, at some point, extra libraries or installations (for instance, mplayer codecs and OpenOffice.org are not included) but everything will usually compile cleanly from source without any patches or there is always Linux Packages.net for packages of any extra software you may need. Slackware's main install is only around the 3-4Gb mark when installed (depending on filesystem and block size) so on a modern hard disk, there's plenty of room for extra software. My main partition (not including personal files in /home directories) rides comfortably around the 10Gb mark and there's always plenty of space for a full install of Slackware plus Wine, Crossover Office, Microsoft Office, OpenOffice and many, many other large pieces of software.

One word of advice - take upgrade.txt's suggestion to just "install the rest of the packages" lightly - in fact the best method, especially if you are short of disk space, is to go through each package directory one-by-one... e.g. upgradepkg --install-new /root/slackware/a/*.tgz etc. Not only does this make it easier to omit the KDE/Koffice internationalisation packages for languages you don't speak (e.g. upgradepkg --install-new /root/slackware/kdei/*en_GB*.tgz), or to omit those packages that you don't need installed anyway (TeX or emacs for example), it saves a lot of time and diskspace and prevents you upgrading to a 2.4 kernel (hiding in slackware/k) and then having to reinstall the 2.6 kernel packages from /extra.

In terms of the final product, hotplug/udev is greatly improved and detects most peripherals and uses them automatically - nothing new or exciting unless you've not run any other recent Linux distro, but being able to plug in a USB drive, joystick or mouse and have it instantly recognised and have X/KDE start using it is a welcome return to the ease of a typical Windows installation. This does require a relatively modern 2.6 kernel though, but the scripts are still designed to take account of older kernels (2.4 or 2.6) that are not able to do this. And yes, 2.4 kernels are still the default for the time being.

One other change to the install process is that the sata.i bootdisk is now set as the default for any bootable CD or DVD (even the text on "how to boot in an emergency" on the boot screen reflects this), allowing direct installion on a old-style-PATA or shiny-new-SATA harddrive without having to select a different bootdisk - apparently a code conflict between the modules for the different hardware has now been resolved, making this possible. It's a welcome simplification to the install process.

All in all, the installation was fairly flawless but be careful about your kernel - unless you stick with the default 2.4 or 2.6 kernels (which will be out-of-date within a week or so, if not already) you are going to have to recompile the kernel and any modules and then reinstall LILO or GRUB. The only other thing to remember (and it's in upgrade.txt) is to ensure that all the .new files that appear on your computer have your settings transferred into them and then rename *them* to replace your original configuration - this way you won't miss any new config options that might have appeared.

I suppose the biggest disappointment would be for Gnome users - there isn't a sign of Gnome left in Slackware (the distribution cited ease of compilation/packaging as the reason for its removal in the last release) although you can still get Slackware packages for it from various third-party sites. To me, this went unnoticed as when I first started off installing Linux with X desktops, I tried both of the major window managers at the time and KDE came off best every time. Gnome felt clunky, old, out-of-place, like the Borland Windows dialogs used to back in the early days of Windows... nothing WRONG with them, they just didn't fit.

They are both now skinnable and in fact either can look like the other, so it's not a win-win situation - however, because of that there's also little reason to claim Gnome's loss is devastating... KDE can be made to work just the same and in fact the two projects are collaborating on just about everything these days. The GTK libraries etc. are still installed by default and, in fact, some ancient Gnome-based software that was left on my setup from its previous Slackware upgrades still functions perfectly.

People say that KDE is full of bloat but, I'm sorry, 3Gb for an entire OS including X and an office suite? That's well within the realms of convenience on a modern computer and most packages can be omitted if you really want (you can get a X installation down to less than a Gb if you really try and omit all the rubbish - I'd hate to imagine what the absolute minimum would be - I should think it would be amazingly small). And a 512Mb system showing only 100-200Mb in use when I have several applications open (and a few dozen background processes including Apache) under X/KDE is perfectly acceptable. And with KDE4 currently in development, the introduction of QT4 is supposed to make everything so much faster and leaner. But let's not get ahead of ourselves.

Altogether, Slackware 11.0 is another flawless upgrade of a "clean source" distribution - there are very few patches to the software included on the disks and the kernel is always "pure"... making upgrades, recompiles and troubleshooting simplicity itself. I should also imagine that it makes the lives of the software developers much easier as the bug reports are directly relevant to the software, rather than patches that the distro has tried to add itself.