Debian woes…..

Debian is lovely in all but one respect….. It’s a problem as far as I’m concerned, but I’m probably in the minority. An internet connected server needs constant updating, both for security updates and functionality improvements. The standard release cycle of software vendors doesn’t fit that. OS vendors have a major release (Version X.0), and the only changes they make between releases is for security (version X.1, X.2 etc.). This means that I’ve got major headaches, including significant testing and down time, when version X+1 comes out because several fundamental changes are going on at the same time. This release methodology is primarily driven by the need to sell your software as a box on the shelf of a retailer. Retailers will hate you if you’re constantly changing out software, and the returns would bankrupt you.

Linux shouldn’t be that bad, because the kernel structure is rigidly defined and every application is written and packaged in a way to just work. In fact most major distros release schedules are marketing or QA driven, rather than by a feature addition. Red Hat release a new major version of their Enterprise OS every 18 months, regardless of what new features are added in the mean time by the community. They do this because it means their customers can plan ahead for the major upgrade upheaval.

Because every package comes from a different source, you need to use the built in package management tools to do updates in an efficient manner. If I want to support PHP 5 on my server and I’m running Debian Sarge, I’m out of luck unless I want to remove the packaged PHP 4.4.3 and install version 5.2.0 from source. This now means that I need to keep an eye on Debian’s bug list and PHP’s one, and follow an extra update process.

Debian are the best and the worst of the major distros. Because they’re one of the few non-commercial operators, they can wait to release a version until it’s ready, so when they finally do release Etch, it’ll be rock solid. The down side is that you can be waiting years between versions. You can get around that by using their second release structure. They have a “stable“, “testing” and “unstable” release structure also. “Stable” is identical to their current full release version. If they release a new full version, in theory your server will switch over to this new version overnight, “testing” is their next release. It’s under constant modification until they freeze development to get everything lined up for release. “unstable” is bleeding edge stuff.

Because so many of us need current versions of packages available to us, we have to either install and maintain them from multiple sources or run the “testing” version of Debian. Unfortunately, Debian don’t recommend using anything but “stable” in the real world, and don’t put the “testing” updates through the same QA as the “stable” version. This morning, I ran an update, and saslauthd got broke. Sasl is the bit that provides the glue between postfix, my mail server, and authentication. It allows me to force a password check before allowing my server to relay email from another computer. This way I can have a globally accessible outbound email server so I don’t have to go reconfiguring my email client when I’m out and about. I’m not happy

Debian don’t “sell” their software at retailers. I download the ISOs from debian.org when I need them, so why should I download a disk image that was fixed 12, 18 or even 24 months ago. Why can’t Debian switch to the stable/testing/unstable structure as their primary release framework? Stable can still be a point in time fork of the testing development track, and deliver the the static OS experience that some need. Additional testing resources for the testing version could deliver a slowly evolving, always up to date, modern distro, with the ease of maintenance that Debian is famous for.