Linux sucks (sometimes)

(May 20, 2006)

As you may or may not already know, I use both Windows and Unix-like operating systems, both at work and at home. (I’d like to add OS X to that list, but Apple decided to sell the underpowered x86 Mac minis at ridiculously high prices, but that’s another story …) In the last few days, I had a fair amount of »fun« (note the quotation marks) with Linux, though.

The Debian box (a.k.a. notebook)

One component of my usual home computing environment is a nice little Acer TravelMate 3000 series notebook that runs IRC/ICQ and Mail clients as well as Opera for reading some RSS feeds while sitting on the sofa. The Debian installation there is my main Linux installation, so it’s paramount to have full hardware support (including 3D) and frequent updates. The latter one is why I chose Debian, because honestly, APT is cool :) Gentoo would have been an alternative, but I wasn’t willing to spend extreme amounts of time and disk space for compilation of such monsters as KDE or OpenOffice. IMO, a 2.6 series kernel compile takes long enough :)

Two or three weeks ago, Debian made the switch from X.org 6.9 to 7.0. Consequently, aptitude upgrade wanted to update about everythign that has to do with X. Because I didn’t want to sacrifice stability then, I postponed the update until about one week ago. The update was a little bit tricky, because the package depencies were sufficiently broken to require a lot of bitching around with APT. Eventually, I had X.org 7.0 installed and was surprised how well everything went. Everything except 3D acceleration, that is.

It turned out that the i915 DRI driver wasn’t compatible with the kernel driver I had. I tried to retrofit 2.6.16.14’s driver into my serverly hacked-up 2.6.14 kernel. I wasn’t willing to do a full switch to 2.6.16.x because I had applied some patches and modified some code to make it work (i.e. not crash) on my notebook. But the retrofitted kernel module did nothing but throw kernel-level exceptions, so I resigned and let the 3D problem unfixed.

Yesterday, I finally decided to do a kernel update – and this was exactly the right date, because the Debian maintainers decided to drop pre-2.6.15 compatibility by installing a new version of udevd. I built a brand-new 2.6.16.16 kernel, along with a custom ACPI DSDT table, because I remembered that with the original one, the battery indicator didn’t work. The first boot into the new kernel was apalling – it didn’t crash straight away like the unpatched 2.6.14 did back then, but twice a second, I got a three-line critical ACPI error message, and since X didn’t work either, I couldn’t do anything but boot into my old 2.6.14 again and recompile the kernel. As the ACPI error message was a DSDT related one, I removed my custom DSDT and voilĂ , the kernel booted. To my utmost surprise, even the battery status worked – the new ACPI code must be more fault tolerant than the old one.

However, there were two other annoyances: 3D acceleration still didn’t work and I didn’t get any sound. Fortunately, solving these problems only involved some Google use. The 3D acceleration problem turned out to be a incompatibility between the kernel module and the DRI driver again, but this time, it was the other way round: The kernel module was too new for the DRI driver. A fresh snapshot driver from the DRI page (man I’m glad they have binaries there!) solved the problem.

The sound problem was a rather strange one. The drivers were loaded without problems, and all programs played without any errors, I just didn’t get any sound, like everything was muted. Fiddling around with the mixer settings didn’t help, either. Looking at the ALSA bug tracking system revealed that this was quite a common problem with High Definition Audio devices, but as it seemes, these were minor model-specific problems. One more generic bug of this kind was marked as »fixed in 2.6.17-rc4«. Now I didn’t want to compile yet another kernel, let alone a development one. I tried to install ALSA 1.0.11-final instead (the kernel had 1.0.11-rc3), and to my relief, it worked.

Bottom line: Linux on the desktop and especially on notebooks can still be an adventure. But the ACPI story shows me that at least, the situation improves over time.

SUSE Linux 10.1

My other PC is a normal desktop model with an Athlon64 3000+ on an Asus K8V-SE Deluxe board. This box mostly runs on Windows, so the Linux installation there is only rarely used. So my requirements for this system are a quite different than those for the notebook: I don’t want to fiddle around too much to get everything working, I expect the distribution to do all the funky stuff.

The Linux partition still contained a half-broken remnant of some distribution I tested back in March for the CLT beginner’s distributions comparison. As I just downloaded the SUSE 10.1 DVD for a colleague and SUSE 10.0 was one of the best distributions in my test back then, I decided to install it.

To sum it up: SUSE 10.1 is a mess. In my review, I recommended 10.0 to novice users because installation went flawlessly and the amount of manual configuration was minimal. The SUSE community managed to kill all these advantages and get back to the dark 8.x ages.

The first thing is the almost unbearable slowness of the installer. Every setup screen takes about one or two minutes to show up. The delays reminded me of a SUSE 8.0 installation I did six or seven years ago – but my computer now has about 10 times the performance of the box back then …

Not only the installer is slow. Booting and starting KDE also takes almost unbearable amounts of time. The online update function updated only one of four packages I selected. Also, I don’t remember the YaST dialogs be so unlogical, misleading and badly designed.

The point where I finally lost my patience was the nVidia driver installation. In 10.0, YaST offered the installation of the binary nVidia drivers as part of the initial online update (that is, even before the desktop is started the first time). In 10.1, no nVidia drivers can be found whatsoever. The only thing is the tiny-nvidia-installer, which turns out to be nVidia’s original installer that can’t handle a running X instance (executing /etc/init.d/{x,g,k}dm stop is really a hard job, you can’t expect this to happen automatically!!!11) and needs the complete kernel sources to build its module. No, I’m not going to install 250 MB just because of this <censored> driver. I will rather use some Kanotix version again later on …

7 Responses to »Linux sucks (sometimes)«

Post a Reply

XHTML: You can use these tags: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <s> <strike> <strong>

Captcha:
 

By submitting the comment, you agree to the terms of the Privacy Policy.