Wandering Thoughts archives

First Irritations with Fedora Core 4

I can't call this a review or even first impressions of Fedora Core 4, because I haven't used it enough yet (and may not for a while). So this is my first irritations with Fedora Core 4, gained from banging my head against it repeatedly in the process of preparing our new OS load for a planned late-August upgrade/reinstall of a bunch of workstations.

• The Anaconda installer is buggy. (Still with no sign of an update.)

• Once X starts, it kills the normal text consoles. Depending on your machine you get either blank consoles or scrambled consoles. The root cause is the decision to use GCC 4 in FC4, which either miscompiles or exposes as incorrect some code in X's libvgahw.a (which it is depends on who you ask). Bugzilla #161242.

• Matrox cards don't work very well (if at all). This is probably related to the libvgahw.a bug, but it's not clear; it's not fixed by some things that fix the former bug. Bugzilla #163331, to the extent that there is an organized single bug for this. (We like Matrox cards here. Whoops.)

• The default desktop background is about 75% black on a decent sized display (1280x1024). I don't know about you, but a black background makes me nervous that something is wrong. Past Red Hat releases used a much nicer background.

The following are not entirely Red Hat's fault, since I believe they come from Gnome. But still:

• The core menus take a long time to appear the first time you click on them, presumably as the gnome-panel code runs all over the system doing XML magic. Dear Gnome: please build those menus in the background when you start, because otherwise it annoys everyone sooner or later.

• If you unwarily try to use your Gnome configuration from Fedora Core 2, the result looks like overgrown ass; you pretty much have to delete it and let the system give you the defaults. (I hope none of our few thousand students had any customizations they really cared about, because they're about to lose them.)

• The Gnome default layout now uses two stripes of the screen, one at the top and one at the bottom. Dear Gnome: my screen space is a limited and therefor precious resource. Please stop stealing bits of it.

• Whose bright idea is it to make the terminal window's cursor blink? Dear Gnome people: humans are reflexively attracted to blinking things, because it's a form of apparent motion and change. However, the cursor is simply not that important; making it blink is like having a four year old jumping up and down going 'I'm here! I'm here! I'm here!'.

Overall, I am sufficiently unhappy with the X bugs that I am not currently planning on upgrading my own machines. Although now that I write it up, this list of irritations is smaller and less impressive than I thought when I was banging my head against them.

(Note that I don't consider Fedora Core 4 shipping without support for MP3s, or without Flash and Sun's Java and Adobe Acrobat and a pile of other commercial software, to be an 'irritation' as such. Fedora Core can't ship with those; see the 'commercial software' bit. (Yes, even MP3 decoders; MP3 decoding in patented in all places that actually allow software patents.))

The legend of Debian Linux

Officially, Debian is a widely used Linux distribution that meets people's needs with stability, lots of software and years of security releases. The Debian community has lots of developers and will tell you that it's just the right thing if you're tired of living on Red Hat's bleeding edge.

Unfortunately, that's a legend. The truth is somewhat different, as I have found out by actually running a server using Debian's 'Woody' release.

By the time it was replaced with a long-delayed new release this June, Woody was antiquated, long overdue for a replacement and full of obsolete and orphaned software (including the kernel). The failure to get a new release out had become a long-running sore spot (and somewhat of a joke) inside the Debian developer community.

If you griped about obsolete software versions to almost any serious Debian user, their likely advice was to in effect not actually run Woody: they would suggest updating to Debian 'testing'. Testing isn't a release; it's a usually working rolling snapshot of what Debian developers are working on. Naturally, testing comes without many of the promises Debian makes about its regular releases, like security updates.

My impression is that almost no serious Debian users or developers actually used Woody; everyone was using testing instead, and Woody was for people who didn't know better. Woody was so unsuitable for real use that Ubuntu has created a popular and fast growing business more or less out of taking periodic snapshots of Debian testing and turning them into a stable releases.

Thus, all of those things told about Woody were in fact a big Debian legend. Woody was not suitable for anyone with even relatively modest needs for relatively current software, which included me on my server.

Debian has just come out with 'Sarge', their new release; maybe the fable of Woody won't repeat itself all over again. (The omens are so-so, seeing as Sarge ships with some significant bits pre-obsoleted, including the default kernel.)

These days, I'm seriously wondering whether I can take that gamble with some new servers we're planning, or whether the odds are against me. (Or maybe I am just grumpy due to the problems my existing Debian Woody server is giving me because of its obsolete software versions.)

Chasing a problem in our Gnome customizations

Yesterday I talked about how I made a day-long excursion into the depths of Gnome, trying to chase down a problem we were having customizing Gnome's main menu, when I could have skipped most of the work by doing some Googling first. I thought it would be interested to give some more detail about the problem and the process I followed in finding it.

The problem was that we want a submenu for our local applications to appear on the default main applications menu. I had everything else necessary (such as the files that created the entries for the individual applications), but the submenu wasn't showing up; instead everything was showing up in an 'Other' menu.

My problem turned out to be because the XML file format for submenus had changed between Fedora Core 2 and Fedora Core 4; I needed a DTD declaration and a few other bits. But to find that I wound up going on a magical journey through the depths of /etc/gconf/schemas and the Gnome panel source.

The default Fedora Core 4 panel has three menu entries: Applications, Places, and Desktop. At first I assumed that the Panel schemas would have an explicit mention of and pointer to each of the menus, like it has explicit pointers for everything else on the default panel. Instead it didn't even have any mention of three menus.

By techniques including trying to add every gnome-panel item that looked promising to a test account's configuration, I discovered that all three menus were produced by a single panel object, the 'Menu Bar'. Examination of the XML schemas eventually persuaded me that this was an opaque gnome-panel object, menu-bar. (I didn't expect this partly because Red Hat had arranged for the Applications menu to have a little red fedora besides it, and I figured Red Hat would have done this by simply changing some XML definition file somewhere.)

At that point I yanked out the gnome-panel source code and started looking for where and how it created 'menu-bar' objects, which led me to discovering that it involved a file called 'applications.menu', which led me off to more or less verifying that this was how it worked in Fedora Core 2, which led me to looking at our submenu XML file versus some other, system-provided submenu files, and fixing the differences.

Looking back, my big problem in solving this efficiently was that I started with the implicit premise that what was wrong is that Fedora Core 4 had changed how Gnome generated the applications menu and submenus. So I started looking to find that, which led me down the path above. Had I started even with the assumption that FC4 worked the same as FC2 but that perhaps the exact format had changed, I would have jumped immediately to looking at our submenu XML file and comparing it to others.

(In a bonus irony, I am pretty sure that I went through this entire process of finding applications.menu when setting up our localized Fedora Core 2 configuration a year ago. Clearly the details of how the Gnome panel generates those menus didn't stick in my memory.)

Adding submenus to Gnome

It's interesting how easily I can use Google to embarrass myself.

Last week, I spent most of an entire day trying to work out how to add a submenu to the default main application menu in the Gnome Fedora Core 4 configuration. (Not building the submenu itself; we had already done that for a previous Red Hat release. Just figuring out how to get it to appear, so that all the students who use the default configuration would see our local application menu.)

I was all set to write a grumpy entry about how information about how to do this should be more widely distributed, but decided to try Googling something like 'Gnome adding submenu'. Tragically for my plans, this actually turns up information on how to do it; the best guide is here.

For future Googling, here's the answer:

Fedora Core 4 uses the FreeDesktop.org standard for menus (adopted by both Gnome and KDE). This puts the master application menu creation in /etc/xdg/menus/applications.menu (an easily read XML file).

Submenus can be created either by directly editing that file, or by creating new files in the applications-merged subdirectory, using the same XML syntax. (Important safety tip: remember to copy the doctype.)

Moral: I should Google, even before starting something that I think will be a quick and easy task. Especially if the quick and easy task starts getting a bit long and annoying.

Why apt-get is not my favorite application

In a nutshell:

# apt-get upgrade
Reading Package Lists... Done
Building Dependency Tree... Done
3 packages upgraded, 0 newly installed, 0 to remove and 0  not upgraded.
Need to get 1351kB of archives. After unpacking 77.8kB will be freed.
Do you want to continue? [Y/n]

Truly, the count of packages to be fiddled with is more important that telling me what they are, by default. Here, apt-get manages to be simultaneously over-chatty and uninformative.

All too often apt-get doesn't seem like a program that is really at home with Unix and the Unix way of things. For all that it's a command line program, it doesn't feel much like part of a system; instead it seems to be its own little universe. As a result I wind up grinding my teeth most of the times that I have to deal with it.

Other irritations:

• why doesn't 'apt-get upgrade' default to doing an 'apt-get update' at the start? Local caches and databases are an implementation detail, not a user interface.
• why is it so hard to get just a list of the packages that 'apt-get upgrade' will upgrade? (A list of the package URIs is not the same thing.)
• the verbosity.

I have no idea why people love it so much. Personally I like yum a whole lot more (although it's gotten more verbose in Fedora Core 4).

Fedora Core 4's buggy Anaconda

I am quite irritated right now, because Fedora Core 4 has the most significantly buggy Anaconda installer that it has ever been my displeasure to have to try to make work. These are bugs that are both serious and obvious, one of them even introduced because of last-minute change. (Have people learned nothing from history? Hasty last-minute changes always have bugs; that's why you don't make them.)

• You cannot repartition drives, because Ananconda holds open a reference to an old partition, the kernel refuses to accept the new partitioning while there is such a reference, and Anaconda dies. (Bugzilla #160693.)

The 'workaround' is to exit out of the error alert, reboot again and this time don't repartition (this time around the partition table is right). Of course this works oh so well for automated installs, where you don't exactly want to visit each machine to reboot it out of the error. Our ugly hack is:

%pre
mf=/proc/ide/hda/media
if [ -f $mf -a `cat $mf` == "disk" ]; then
  dd if=/dev/zero of=/dev/hda bs=512 count=1
fi

(Of course, if another error happens later we're screwed; we've blown away the MBR, so we're not rebooting this machine without an external boot media.)

• Anaconda writes totally bogus entries for swap in /etc/fstab, with LABEL= values that have random non-ASCII characters in them. This is so broken that the fstab-parsing library code throws up its hands on the spot, rendering any filesystem listed later in the file totally unmountable and invisible. (Bugzilla #159087.)

We have all our data on NFS-mounted filesystems. Enough said. (One can at least fix this in %post-production.)

• One cannot just say '-<package>' in the %packages section (which is normally used if you want a class of packages, minus some specific packages). If you do, Anaconda dies with an internal error. (Bugzilla #160209.)

There are workaround, such as performing a rain dance to make Anaconda use a lightly patched version of one Python sourcefile.

Ironically the '-<package>' bug was apparently introduced by a last-minute code change with the goal of supporting '-<package>.<architecture>'. In the process they cleverly broke (and never tested) the more common variant.

So far, Red Hat doesn't seem to be showing any real signs of issuing a formal update. I have no idea why, especially given that the first problem affects even manual, non-Kickstart installs.