Title photo
frugal technology, simple living and guerrilla large-appliance repair
Sat, 12 Feb 2011

All quiet on the Debian Squeeze front

When you run Debian Stable, you get used to updates to the system being few and far between.

While there is certainly some truth to the open-source OS adage that bugs related to functionality (and not security) at release tend to stay unpatched, the emphasis in Debian on releasing when ready means there are theoretically (and practically) fewer broken pieces in the system and not as much need to push updates for non-security-related issues.

So a Stable installation of Debian doesn’t have the Update Manager (or apt or Aptitude) working all that hard.

While it might be boring (and make many geeks itchy for the kind of constant updates that many systems push to users), it’s also efficient. If you’ve set up the system the way you want it, then tested everything and are satisfied that things work the way you expect, a stable, boring Stable release can really boost your productivity.

Chances are, what’s not broken won’t break — and certainly won’t be broken with an update from Debian.

It’s not the cutting edge, the bleeding edge, the leading edge, but a comfortable, conservative build with nothing broken — for the most part.

Key to choosing any distro/project release of an operating system is whether or not it runs well on your hardware and performs your tasks the way you like and expect. If you have a favorite OS/environment in a general sense, I’d say be flexible — a different hunk of hardware might not respond so well, and the version of a particular software package in a given release might not work as well as a newer (or even an older) version.

Many, if not most application developers tend to fix bugs and then release a new version. They don’t backport those fixes to the versions in a given Debian or Ubuntu release. That’s where things like Backports (in Debian) PPAs (in Ubuntu) and what I remember being called “development” builds in Fedora can come in handy. If you really rely on a particular application, finding a newer (or older) version in a different repository, or with a .deb or .rpm package, or even building it yourself from source (or a port in BSD) can make a given OS installation work better for you.

In my case, that “holy grail” app is gThumb, the image organizer/editor. Fedora was a great place to run gThumb because the newest versions were always being pushed via the package manager if the “development” version was installed.

In my case, the gThumb version in vanilla Debian Squeeze does everything I need it to do. Same for OpenOffice and the dozen or so other applications that I rely on day to day.

But I’m not above using Debian Backports, pulling from Sid, or grabbing a .deb or the source to keep my workflow, uh, flowing.

As I’ve written way too many times, while I do have the stock 2.6.32 Linux kernel installed on my Squeeze laptop, I’ve been running the Liquorix 2.6.37 kernel for about a month, and I expect I’ll soon be seeing the 2.6.38 kernel (with the much-heralded 200-line patch that’s supposed to make everything faster and better).

I also plan to follow the newer kernels in Debian Backports; while Liquorix has been great, I feel better running as much out of the Debian repositories as possible (and I consider Debian Multimedia, which I use heavily, to be “official” enough).