A Modest Construct

Lately, I just can’t seem to get enough of OpenSuse 10.1. And believe me, I’ve been making the rounds. In the last month, I’ve played with the new Ubuntu 6.06 LTS, Debian sid, Fedora Core 5, an Arch Linux snapshot¹, and lots of OpenSuse.

Without getting into full-fledged, screenshot-speckled reviews of each distribution, here’s the fatal flaws that they all seem to suffer from.

Ubuntu 6.06 LTS – “Dapper Drake”

Few distributions have been so hyped as Ubuntu, the relative newcomer on the scene. I’ve had good experiences with it in the past, but unfortunately it’s never been a contender for my main machine because Debian was one of the later distributions with a default kernel supporting ITE8212 chipsets, and so even as of 5.10 (Breezy Badger), I was left without access to my audio and document drives—obviously, an acceptable scenario.

One of the nice things about Ubuntu is the fact that because it’s timed to coincide with the latest GNOME release, you’re guaranteed to have the latest version of your desktop environment. The bad thing about it is because it’s very specific about version freezes for upcoming releases, you could be bereft of the latest version of some other integral piece of software. Firefox 1.5, for instance, wasn’t available in any stable version of Ubuntu until a week ago, when Dapper was released. Users either had to use a third-party tool like Automatix or EasyUbuntu or resort to a dirty hack to get a recent Firefox release working.

But version freezes notwithstanding, Ubuntu generally has an excellent software catalogue (18000+, once certain extra repositories are enabled), fairly active forums, and—in my estimation—a great new GTK2 engine (Ubuntulooks) with a fugly color scheme. Yeah, I get it, it’s African and organic and brown, but this orange and brown nonsense makes me want to puke. One of the first things I did when I tested it out was grab a blue coloring of Ubuntulooks from Gnome-Look².

Installation

For the new release, Ubuntu has gone from Debian archaic text-based installer to a LiveCD with a Python-based GUI install. Debian’s got a similar one in testing, and Gentoo included one in their 2006.0 release that seemed hopelessly broken. I had mixed success with the GUI install; initially, it installed correctly, but booted to the grub> prompt, apparently unable to find menu.lst. After a complete HDD wipe (I had originally just reformatted a SuSe partition, which might be what caused it), I tried the GUI install again, and this time grub didn’t seem to install at all. A quick sudo grub-install /dev/sda2, and then I had to edit menu.lst and point it to the right drives, because whatever version of Gnome that Ubuntu is using now, it blows hard at working with SATA drives.

Thankfully, that seemed to fix the booting issue, although while I’m at it, I should mention that Ubuntu can’t install grub on an XFS partition. I either have to make a separate /boot partition in ext2, or just make the entire root ext3. This will come into play later.

Performance and Usage

As much as everyone seems to think Ubuntu is responsive, and as many good things as I’ve heard about the performance of Gnome 2.14, I found Ubuntu to be a little on the slow side. Also, despite the fact that the repos now have the fglrx driver (ATI’s proprietary binary driver), I had some difficulty getting it activated, and even when it finally appeared in an fglrxinfo, it seemed to be awfully slow—Metacity left visible trails when I moved windows, and it generally felt laggy.

Actually, I’ve always felt that Ubuntu felt a little on the slow side. It’s only optimized for i386 (except the kernel, which has optional variants, including k7 and i686), and while I know that shouldn’t make that much of a difference in overall responsiveness, I can’t help but think that Ubuntu just isn’t very fast. Even enabling prelinking doesn’t seem to help much.

Xgl and Compiz

There are a million guides to install Xgl and Compiz in Dapper—I looked at three.. One involves directly changing gdm.conf, another involves starting up a shellscript at boot, and yet another involved an .Xsession file. The only one that seemed to work for me, after getting the latest packages from Quinn’s repo, was the latter, but that only worked if I killed the X session, logged in as root, and then manually started X. Logging in as a normal user didn’t do anything.

Actually, I’m surprised that Ubuntu even has Xgl and Compiz in their repositories, since Debian doesn’t have them in any branch, sid included³ but they obviously have a long way to go before it’s integrated into the desktop.

Final Thoughts

The release of Dapper was delayed by six weeks so that it could be polished. To be quite honest, this seems to me like one of the buggier distributions to date. At least all the previous ones installed correctly, without CLI intervention by me. The Ubuntu team has done a lot of UI work, some of which I dislike, but this release hardly seems leaps and bounds above its predecessors, perhaps because it’s a Long Term Support release, and the next release with be the “toys and eyecandy” experiment. A lot of people think that Ubuntu’s the new end-all/be-all of Linux, but I’m just not very impressed.

Debian sid

It may be somewhat redundant to review Debian test/sid after talking about Ubuntu, but there are a number of differences, and they are important one.

Installation

Technically speaking, I downloaded a netinstall image for Debian etch, or testing release. The testing release is midway between the stable (generally outdated) release and the relative sandbox of unstable. I opted for the traditional text-based installer instead of the experimental GUI installer (notably not a LiveCD with a launchable installer, but another Python-based installer that runs in a sort of pre-boot environment, like Anaconda).

I first tried this several weeks ago, and of course got grub errors (the grub in Debian testing probably being very similar to the one in Ubuntu Dapper), which consisted of the word “GRUB” in capital letters and a required hard reboot instead of the customary “Loading Grub Stage [#]” that one sees in successful installs. My little trick with grub-install and an edited menu.lst worked the same for Debian as it did for Ubuntu.

Once booted into Gnome, I edited my sources.list file to point to unstable instead of testing, as well as adding a few extra repos (Christian Marillat’s and RareWare), and a quick apt-get update && apt-get upgrade.

Problems

I had problems right off the bat. To begin with, I had similar difficulties getting the proprietary ATI driver installed, though once I did, the performance seemed a bit better than in Ubuntu. However, my system was insistant that I didn’t have a CPU Frequency Scaling interface installed. What distribution can’t enable that by default at this point? All my efforts with both powernowd and cpufreqd, getting the software, adding the modules at boot time, etc, seemed to no avail. Debian didn’t want to frequency scale.

Debian just wasn’t a cohesive desktop. To be fair, I understand that Debian is not intended to be a beginner’s distro, and that I used a testing and not a stable release (but sarge still uses Kernel 2.4.x), but it’s one of those distributions that isn’t point-and-click easy—few things will be set up for you the way they are in newer, more tightly-packaged distributions. Unfortunately, there will never be a stable Debian that’s particularly useful as a desktop distro: users want the latest and the greatest, and by the time software hits Debian stable, it’s already long out of date.

Plaudits and Final Thoughts

Debian did have some good things going for it—as I said earlier, it seemed relatively responsive compared to its African cousin. Also, by using the unstable branch, I wasn’t limited by long waits for new versions: sid is constantly in flux, as its a version-agnostic tree.

It’s also got an even greater number of packages than Ubuntu (especially because of the version agnosticism)—after adding the extra repos for multimedia, there was really nothing than I couldn’t find. This is a major plus, as far as I’m concerned, but not enough to make Debian Proper a good choice for the desktop.

Fedora Core 5

Some of my earliest experience with Linux goes back to the beginning of the Fedora Core Project (excluding my brief, torrid affair with Mandrake Linux, 9.x), which may be what fostered by lingering love of Bluecurve artwork. The early FC releases suffered from a number of bugs, not the least of which was apparently poor driver support, noticeably in the x86_64 release.

As of Fedora Core 5, I’m happy to say that the distribution has gotten a lot more professional, a lot more streamlined, and a lot less buggy. I would even call it usable out of the box.

Installation

I’ve always loved the Anaconda installer—it’s attractive, Bluecurvy, and traditionally it’s been pretty fine-grained. One of the first things I noticed about this release was that the Anaconda loader was branded with the FC5 artwork, which is impressive in and off itself, sporting the new f-cum-∞ logo and the bubbly background. I also noticed that the Gtk2-based Anaconda had animated progress bars, meaning that FC5 shipped with the latest beta (2.7) of gtk2-engines, with the latest Cairo code, something that no other distribution seems to do.

They’ve simplified the installation process a bit, trying to appease the end user with bigger graphics instead of longer lists (this will be a theme), and overall everything went quite smoothly. One nasty little tidbit I found was that support for extra journaled file systems like JFS or XFS have to be specified at the boot prompt: boot: linux [x/j]fs. Even then, Fedora Core won’t let you install grub to an XFS partition, just like Debian and Ubuntu.

Performance and User Experience

Fedora Core is an i386-optimized distribution, Ubuntu. Also like Ubuntu, it felt laggy to me, and generally slow—but, then, I’d already read that a standard FC5 was a behemoth compared to others.

As with any Linux installation, one of the first things the normal end user (and especially me) has to do is enable support for various formats and codecs that aren’t included for various reasons. This usually means enabling extra repositories. For Fedora Core, this means a headache. You see, the main Fedora installation source and Fedora Extras, are relatively large repositories, although they don’t even come close to matching that of Debian. As with any truly “Free as in Freedom” distribution of Linux, there are third-party packagers who provide patent-encumbered or otherwise legally-nebulous packages. With Fedora, there have always been several, and they don’t get along.

There’s Livna, FreshRPMs, Dag Wieers, atrpms, and probably another that I don’t remember offhand—in fact, some of those might be overlapping, as there have been a number of attempts to unify these third-party providers into a single compatible repo (RPMForge), but the work on that seems to be slow at best. Attempts to find a “Which repos should I use” FAQ yielded as many answers as there are possible combinations. Livna seems to be the most popular, even offering easy one-click installation of binary drivers from ATI and nVidia. So, I selected just Livna and the Official FC repos to be safe, and tried to run an update.

Updating in FC has traditionally been a pain. In FC5, the “up2date” tool is finally gone, having plagued Red Hat distros for years (and freezing every time it ran). Now, it uses a couple of homegrown apps to handle such things: pup as a update notifer applet and pirut as its package manager. Upon invoking pirut, even before I had enabled extra repos, it froze and crashed while trying to cache the repo metadata for the official source. A second and third try produced the same results. After installing yum and the gorgeous yumex and enabling some third-party repos, I was finally able to get my system into some sort of working order.

Final Thoughts

There’s a lot that I like about the Fedora Core distribution. Anaconda is wonderful, and the new direction of their branding is wonderful as well. I would like to see the Bluecurve theme updated a bit, as it’s getting long in the tooth compared with the Ubuntulooks or Gilouche (SuSe), but I’m ecstatic that the developers included the recent work done on the Clearlooks-Cairo engine.

In the end, the third-party repos weren’t enough. I couldn’t find, for instance, linuxdcpp. Many of the repos have overlap, and so the number of new packages they bring to the table doesn’t extend very far beyond the traditional assortment of libxine1s and w32codecs. For the casual user, this might be just the ticket—that is, if they can squash some of their stability bugs.

OpenSuSe 10.1

There are so many things that I like about the SuSe platform: it’s got great hardware recognition, it’s i586-optimized. The thing I hate about it is the flagship portion of its infrastructure: YaST2. YaST2 is a QT app that serves as both the installer, the control center, and the package manager for SuSe. It’s also slow and buggy, not so much as an installer, but as a package manager.

Installation

The first thing that hits you about OpenSuse 10.1 is the installer’s splash screen, a gorgeous textured blue with a minimalist logo. It finally replaces the gaudy green that was favored for 10.0, and in general this release has improved in a UI sense.

As an installer and setup tool, YaST2 really isn’t bad: it’s got excellent hardware recognition, it’s own partition—with support for LVM and all sorts of filesystems and support for installing grub to an XFS partition!—a customizable software installation screen, and a workable UI. It even supports setting the mountpoints and mount options of other drives, which saves me the trouble of manually configuring fstab later. The only complaint I have is that it’s slow like molasses.

A default Gnome installation spans three CDs. I’ve given up customizing my installation not only because it takes significantly longer, but also because I know that I’m going to be updating those packages anyway.

Packages, Updating, and User Experience

There are two default ways to manage packages in Suse. Previously, it used YOU to tie into Suse’s security and other updates. Additional software had to be invoked through the YaST2 software management screen, which could technically also handle updates. The problem was that one added repositories to Suse through an entirely different application, and it had a tendency to freeze when these were added. If you were lucky enough to get past that stage, then the Software Management application would likely freeze when trying to read in the package data⁴.

The new system of updates is Libzypp, a marriage of YaST2 and Ximian’s RedCarpet, and it’s pretty much been panned across the board, prompting frantic fixes from developers. Personally, I wouldn’t use Libzypp any more than I would use YaST2/YOU. I long ago discovered that the SMART package manager, though not the greatest-looking, beats all other package managers, synaptic included, hands-down.

The OpenSuse wiki has a pretty good list of extra repositories you can add. Besides the official installation source, installation source extras (which includs semi-free programs like Java and Flash), and the Official Updates, there’s also Guru’s repo, Packman’s repo, and a number of other, smaller repos with specialty packages like Azureus. I haven’t yet experienced a problem with conflicting packages (at least, none that SMART didn’t resolve transparently).

Installing the proprietary ATI driver is a cinch: download the .run file from ATI’s site, make sure you have gcc and kernel-sources, and do the following:

sh /path/to/ati_install_x.y.z —buildpkg SuSe/SUSE101-IA32

This will create an rpm in the home directory.

smart install /path/to/package.rpm

SMART should install any other needed packages, but keep an eye out for output errors: if you don’t have the required packages I mentioned above, it won’t be able to build the needed modules and you’ll have to install them and run the module building script that was created.

Now, just tell Xserver about your new drivers, and then configure SaX2 to use them to the fullest extent.

aticonfig —initial

sax2 -r -m 0=fglrx

Reboot, and a quick check of fglrxinfo should tell you that you’re using ATI’s drivers instead of Mesa’s. Try running glxgears to see your frame rate. I get about 4000-5000fps on my 9800Pro.

Xgl and Compiz

OpenSuse is the very first distribution to include Xgl and Compiz officially. They aren’t installed by default, but you can download them as an extras disc for installation, or just make sure that the installation source is set as one of your repositories and install them from SMART. Once installed, an “Xgl” icon should appear in the Gnome Control Center (KDE users have to manually invoke gnome-control-center, I guess), where you can enable the 3D desktop and manage settings.

For me, it was that easy. It got even better when I was able to download and install Quinn’s latest binaries for SuSE, which enabled a lot more plugins, as well as gset-compiz, a GUI tool to manage compiz settings with a much finer grain than the Xgl settings menu allows.

Final Thoughts

As you can probably tell by my tone, I’m enamored of OpenSuse. Sure, YaST2 is horrible, but once you learn to bypass it and use better tools. OpenSuse is the fastest and most responsive distro that I’ve used to-date. It’s also bleeding-edge in a lot of ways (it’s got Mono heavily integrated), despite not yet providing the 2.14 release of Gnome, and all-in-all provides a set of packages that gives other distributions a run for their money (though of course it can’t quite rival the sheer immensity of Debian’s trees). I don’t know if its Novell’s influence, or perhaps the recent spin-off of a Free as in Freedom distribution to serve as a sandbox for their SLED distro, but Suse is really going places, and it’s making me excited about Linux like no other distro has before.

1. My failures with Arch were so dismal that I cannot offer any sort of review here[↩]
2. Funnily enough, both homegrown versions I tried didn’t place nice with GTK 1.x[↩]
3. Each Debian release is based on a snapshot of Debian’s unstable sid tree[↩]
4. The repodata for the installation source is generally about 17MB or so, which could easily explain the application hangs, especially if you don’t use a fast mirror[↩]