Recently in Etch Category

Image above of the Debian Etch GNOME desktop from Wikimedia Commons. I always liked this version of the Debian swirl on the wallpaper.

I just saw the news that Debian Etch will no longer receive updates from the Debian Security Team as of Feb. 15, 2010.

As you may or may not know, the current Stable version of Debian is Lenny, which received that "Stable" designation on Feb. 15, 2009.

See the pattern? In the world of Debian, once a release is declared Stable, the previous release moves from Stable to what the project calls Old Stable, at which time it receives security patches for an additional year. That gives users a full year during which to upgrade to the current Stable distribution, which in case you haven't been reading closely is Lenny.

Truth time: I still have an Etch installation — an Apple PowerPC box, in fact. I'm not running the Etch drive, but it's still in the box waiting to be hooked up (I have the OS X drive connected and running). So if and when I hook the Debian drive up, I'd have to update the Etch installation, which hasn't seen an update in about a year, then dist-upgrade to Lenny (which I'm running on my main laptop as well as two other machines).

I remember Debian Etch fondly. It was released in April 2007, mere months after I started mucking around with Linux, and its 2.6.18 kernel played very well with the machines I ran for the next two years. I did run other things between then and now (Ubuntu, Xubuntu, Slackware, CentOS, OpenBSD, Wolvix, Puppy), but for reasons that one can deduce from the past 100 entries in this blog, I'm back in the Debian camp with Lenny (and not feeling all that good about my Intel video-running laptop and the future of Linux and Xorg, meaning I'll be sticking with Lenny for quite some time).

Just as one can have a very good experience running the Debian Testing branch, Squeeze, right now, with no date certain for going Stable, one could have run Etch that same way before April 2007. But if you're the conservative type (and I usually am when it comes to my old machines and the software they run) and you began running Debian Etch in April 2007, the release's life from Stable through Old Stable to the end of its patched life will be roughly 2 years, 10 months (unless I miscounted my fingers). Not bad for a "long-term release," which in the world of Debian is EVERY release.

I've been approaching the point over the past year where I'm becoming much less a free, open-source software-using hobbyist, trying out the various Linux distributions and BSD projects to see how they run, and am now pretty much a regular user of one open-source operating environment, with productivity and stability being the only thing that matters.

And if you've read the past 20 or so entries, you know that means I'm running one of the driest distributions around, Debian Lenny. (You can pretty much follow my whole OS progression from 2007 to the present in the blog archives.)

In the last week I've gone from the Los Angeles Daily News' Web developer to online editor, which means the ramp up in my work that I've experienced over the past many months is getting that much more intense.

I don't have time to fix broken networking, video, hot-plugging, screen-saving, kernel mode setting, or any of the other things that have gone wrong since my use of OpenBSD 4.4 led into the Xorg disaster that was 4.5 in May 2009, leading me to Ubuntu 8.04 soon thereafter.

My mistake was upgrading to Ubuntu 9.10, where things really started to go badly. After the hardware on which I was running Ubuntu Karmic took an unrelated turn for the worse (LCD cracking onto death), I took that as a sign to return to the OS I've used on more machines and probably for more time than any other: Debian GNU/Linux (Debian uses the GNU, so I will too, for the moment anyway).

I started running Debian Etch soon after it went stable in April 2007, and in December 2009, I again returned to the Stable branch of Debian, now Lenny (yes, every Debian release is named after a "Toy Story" character)

Sure the temptation is there to upgrade to the current Debian Testing branch (code-name Squeeze), but mindful of all the trouble I've had with my 2001/02-era Toshiba Satellite 1100-S101 laptop, especially with its Intel video chip, the need to stay productive with a minimum of tinkering is keeping me in the Debian Lenny camp.

You see, I expected to have some configuration work to do when I ran OpenBSD 4.4 as my primary desktop from May through November 2009. But when I made the move to Ubuntu, with its "Linux for Human Beings" mantra, I figured a whole lot would be done for me by the system itself (and, by extension, the developers who put it together).

But whether it was my relatively aged hardware, the lack of luck in having Intel video (which is very, very common, by the way), or just the way it is, I ended up doing just as much configuration in Ubuntu as I did in the past for Debian Lenny when I used it during its Testing phase.

Except with Ubuntu I had to fix broken things not just with every six-month-release upgrade but often in between as package updates started to break things large and small.

With Debian Lenny, I figured everything out, got the laptop running as well as I could, and over the last month all I've been doing is using my computer. Sure I'd like the newer packages in Ubuntu (or Debian Squeeze, for that matter), but right now I just need to get work done, and between the large number of packages in the repository and the stable, staid and secure base system, Debian Lenny is doing the job.

Most of the time I'm not all that broken up about the older packages in Lenny. When it comes to my day-to-day, there's very little I can't do, and I appreciate not having to drop into uber-geek mode every time there's a kernel or Xorg update.

I'm not saying I won't use Ubuntu again. I still maintain one machine running Ubuntu 8.04 LTS (and doing very well with it). I have three running Lenny exclusively, with my Mac G4/466 booting into Debian Etch on one drive, OS X 10.4 on the other.

And that doesn't mean I won't be back in OpenBSD on the desktop at some future time. Or FreeBSD.

But for now, it's Debian Lenny on my desktop.

Somewhere between the debut of Ubuntu 9.10 (Karmic Koala for those into animal names) and today, the developers/maintainers/overlords of what many consider the leading Linux distribution have fixed the dreaded "kernel mode setting bug" that rendered the X Window system on many computers using Intel video hardware unusable until kernel mode setting was turned off.

I found a fix for this fairly quickly, as I have for the other Ubuntu-related problems befalling one of the two Toshiba Satellite 1100-S101, 2002-era laptops I rescued from the to-be-recycled heap when the Daily News moved offices what now seemed like a millennium ago.

Back to the kernel-mode-setting issue. I barely understand the reason for kernel mode setting, although my faint grasp of the details involves something about the kernel configuring the X server (or perhaps I should just say "the video") and not the Xorg program itself. Seeing a blank screen after booting my first time into Ubuntu 9.10 was not a welcome sight.

As I said, I quickly found the way to turn kernel mode setting off for Intel video, but I thought this potentially show-stopping bug was a bit of a turnoff, shall we say, for potential, new and/or less-experienced users of Linux.

Well, somewhere along the way, this bug was fixed.

How do I know?

Due to another seemingly ill-advised change in the way Ubuntu does its thing — namely lamely notifying users about software updates at intervals that even an ancient astrologer couldn't ascertain and in a most obtrusive way, botching a process that used to be quick and clear — I've been doing my updates in the terminal using Aptitude (which I find usually does a more complete job than apt alone when installing, removing and updating software in apt-based system such as Debian and Ubuntu).

Today I opened a terminal and did the usual:

$ sudo aptitude update

followed by

$ sudo aptitude upgrade

Some 50+ packages, including the kernel, were in need of an upgrade. (After completing this process, which installed kernel 2.6.31-15 to replace 2.6.31-14, I checked the "older" kernel, and it does X just fine with kernel mode setting, so the fix must either be in the older kernel or another package in the system.)

I don't know if the usual Update Manager or apt would have done this in the exact same way, but as part of the aptitude upgrade process, a message in the terminal asked me how Aptitude should handle my /boot/grub/menu.lst file, since it was "locally modified" (can't remember the exact wording, but that's the gist) and needed to be changed to accommodate the kernel update.

And if you've followed this tale of woe, you already know I had modified menu.lst, the configuration file that controls how the GRUB bootloader works, to turn off kernel mode setting for the i915 driver and get the display working once again in the GUI right after my upgrade from 9.04 to 9.10

I knew how to replicate the fix (stopping the boot process while GRUB was running, turning off kernel mode setting by editing that line in menu.lst for that boot and then going into menu.lst to add the fix permanently), so I let the system replace my /boot/grub/menu.lst with the one "provided by the maintainers." (Again, I'm paraphrasing; guess I should have done a screen shot. And while we're at it, who exactly are The Maintainers? Wasn't that an '80s band? ... I digress.)

I let the system rewrite GRUB without turning off kernel mode setting. Aptitude finished upgrading the system, and the system prompted me to reboot.

I did. I expected X to be inoperable after the system booted up, but much to my very pleasant surprise, everything works perfectly, X included. And still no xorg.conf is needed.

So for my system anyway, which uses the Intel Corporation 82830 CGC [Chipset Graphics Controller]. as lspci tells me in a terminal, X is seemingly as good as if not better than it's ever been.

And that means Linux in general, Xorg and Ubuntu in particular, appear to be cleaning up what has been a long graphics nightmare for Intel-powered video (and that's a whole lot more people than should've been put through what we've had to endure over the last very long while).

Like I said, Aptitude hasn't asked me until today to modify /boot/grub/menu.lst. I had been meaning to do a test of kernel mode setting to see if anything had changed, but right now I know it has.

I always say you should wait at least a month if not two before installing a new release of just about anything, especially Ubuntu. And if I had waited a month, I'd be upgrading to Karmic right about now, presumably with all the bugs fixed that have troubled me since my initial upgrade (chronicled painfully in a three-part series that somehow, some way, sprouted a fourth part with a flurry of follow-ups).

My review of Ubuntu 9.10 during the first week I used it was much more critical.

But now, at Ubuntu Karmic +1 month, I'm happy to the point of mild delirium (in a good way).

And my Ubuntu motto is now: Good (and patched) things come to those who wait.

What about the other Toshiba?: The other Toshiba, unlike the Ubuntu-running model, has a working CMOS battery, and also unlike the Ubuntu Toshiba, has a dead sound chip and a spotty display that, due to a bad inverter or something like that, needs the lid-operated screen-blanking switch to be pressed by hand every once in a while to bring the display back to life.

That "other" Toshiba formerly ran OpenBSD 4.4 until the whole thing blew up in my botched 4.5 in-place upgrade. It now runs Debian Lenny (and very well, too) with fully encrypted LVM. I'd have only encrypted /home and /swap, and perhaps also /tmp, but between you and me, that kind of thing is just too hard.

Hell, encrypting /home in OpenBSD is too hard. You'd think that in an operating system famed for its security and paranoia, creating an encrypted /home would be easy as peasy (and by that I mean a choice offered during the installation). But no. OpenBSD does encrypt /swap by default, I believe, and I wish it would at least give the installing user the option of encrypting other partitions without more extensive geekery than is already needed to get an OpenBSD system up and running.

I know. I! KNOW! that Ubuntu now offers users the ability to encrypt /home during the install (and there are forcefully geeky ways of turning an unencrypted /home into an encrypted one), but since all of my current Ubuntu installations began their lives with the live CD installer for 8.04 LTS, I haven't had the opportunity to choose an easily created encrypted anything.

And since the Debian text-based installer (as well as the nearly identical Ubuntu "alternative" installer) has offered fully encrypted LVM at least since Etch, I chose that for this experimental/backup Debian Lenny installation. I still think that carrying around a laptop with unencrypted personal data is a very bad idea, and I really shouldn't be doing it. But I'm too damn lazy to reinstall Ubuntu from scratch on my main Toshiba (or go through the aforementioned geekery to do it after the fact).

Now my plan is to wait — WAIT! I SAY! — for the next Ubuntu release, 10.04 LTS, to age a few months (like a homemade wine, which I also hope to craft in my garden shed, backwoods/prison/old-country-style) before doing a complete reinstall on whatever my main machine is at that time, during which I will encrypt /home, /swap and probably /tmp as well, keeping an unencrypted backup on a physically secured (i.e. off-site) USB-connected drive.