Are Updates the Dirty Linux Secret?

A recent post by tech writer David Gewirtz goes on a rant about a remote-hosted server which failed to function or reboot after a CentOS Linux software update.  Others have responded, both in the comments and in articles of their own, supporting both sides of this argument.

So, are updates the dirty little secret of running Linux?

Just like installing any software, updates are new software code running on your computer.  Because this is new code, it does have the possibility to run or act differently.  I had my own example of this just recently, with a CPAN module not working correctly on one Red Hat server — after updating over two dozen servers, this was the one error which I encountered.


I've had my share of more spectacular stable-update failures as well.  Our home livingroom-laptop runs Debian 6 (Squeeze) and recently had an issue with its bootloader not knowing where to find the kernel.  I had to boot from the Debian LiveCD and reinstall the GRUB bootloader and everything worked after that.  Was it easy?  Sure.  Was it obvious?  Not at all, to a non-techy.  Is this type of problem limited to Linux?  Not at all.  I've had my share of MBR issues on Windows machines.


Windows has certainly had its share of failed updates.  I've seen plenty of mup.sys hangs at bootup, plenty of BSODs, plenty of disk not found errors.  I'm far more concerned with a failed update to a remote Windows server not coming back online after updates and a (far-too-common) reboot, than I am with a reboot of a GNU/Linux server.  Short of a harddrive issue or the boot issue mentioned earlier, a failing Linux server is almost always recoverable by command-line tools and can often be done remotely.  A Windows server, on the other hand, has extremely limited command line tools (until the relatively recent release of Microsoft PowerShell, which took administration and functionality hints from GNU/Linux systems) and remote core-system administration of a Windows server requires that the core is up and running.

What about version upgrades, from say Debian 5 to Debian 6, or Windows 2000 to Windows XP?  I've faired rather well with those over the years.  At a client's office we upgraded over 200 desktops from Windows 2000 (sp2?) to Windows XPsp1, and we only had one problem machine there.  Recent Windows 7 doesn't allow upgrades from XP; I have very little experience with Vista.

On my various servers and desktops running Debian, the Debian Stable upgrades have always worked well for me; trying to maintain a "rolling release" Debian Testing hasn't always been smooth but I'm willing to gamble on those setups.  Red Hat doesn't support version upgrades as far as I know.  The only failed version upgrades I've ever experienced have been from Kubuntu in the 6.x-8.x days, and that experience (and the KDE setup at the time) has kept me away from that distro.

The biggest point here is that computers are complex.  They do a lot of things, they make the hard things easy and make the impossible become possible, but to do this they have a million little parts that may or may not decide to behave.  A GNU/Linux system does require that its software is packaged just so to run on a specific distribution release, and this is a headache to many.  Mozilla Firefox seems to have gotten around this and their software, save a few dependencies, runs out of the box on most modern distributions.  But we often forget that these aren't mix-and-match platforms; GNU/Linux distributions are each their own Operating System.

Just as you can't run the Microsoft webserver (IIS) on a Red Hat computer, likewise you cannot run the Debian webserver (apache2) on a Red Hat computer.  Red Hat is its own OS, and so are the others.  If you don't know how to manage your software at all, you're certainly going to have problems.

Readers, how have your upgrades gone?  Either version upgrades or stable release upgrades, have you had more issues with Windows or Linux or equal problems over the years?