Wandering Thoughts archives

Some thoughts on the Fedora Core 5 Gnome desktop

I am still testing things on my new machine, so I haven't bothered trying to build my usual highly custom X Windows environment on it. Since I've still been poking around with it, I've been getting a reasonable amount of exposure to the default Gnome desktop in Fedora Core 5.

To my surprise, it's turned out to be a surprisingly usable and livable environment. To a fairly large extent a lot of things just work, without fuss or muss. When they don't work, it's been relatively easy for me to figure out what to do; for example, while CD-ROMs automount and appear on the desktop, floppies don't, but if you open up the 'Computer' icon on the desktop and click on a floppy, that does it.

(I've been conditioned from years of disappointment and irritation to expect default desktop environments to be pretty unusable for people like me.)

I'm not really the right target for the desktop metaphor, because my desktops are invariably more cluttered than I want the computer to show me all the time. It's still pretty usable, and it has been encouraging me to clean keep my computer desktop clean (which I do mostly by making subdirectories and shoving the mess there, though). It's reasonably easy to make things behave and open files with the program I want and so on.

(There are some stupid interface bits there, though. For the love of something, why on earth do I have to feed Gnome the full path to an alternate program when it's already on my $PATH?)

It's also interesting to see how deep the Gnome environment still is, despite the much argued about movement to simplify things for basic users. The default FC5 configuration has virtual desktops. You can make Capslock into another Control key (although this is hiding in the Control section of the keyboard customization, instead of the Capslock section). It's easy to shuffle the system taskbars around (sometimes too easy, since there doesn't seem to be an undo).

Overall I can actually imagine using this environment full-time if I had to, which is not at all what I expected when I started playing around with it. (In a sense I already am, but this is in no way permanent; I still vastly prefer my regular X environment.)

And to my surprise there are things I will miss when I move back to my regular X environment. (However lame it is, I do like having the current temperature and weather conditions displayed in a little taskbar applet.)

How to supply an IP address in Red Hat's Kickstart

Ignoring DHCP, there are three ways to supply an IP address when you're using Kickstart to set up machines automatically:

1. put a network line in your Kickstart file. You need to give all of the information (--hostname, --ip, --gateway, --netmask, --nameserver) and also use '--bootproto static'.
2. put the information on the kernel command line, with ip=, gateway=, netmask=, and dns=. Non-DHCP is assumed in this situation, and you can't provide the hostname; instead it's taken from what the IP address reverse-maps to in the nameserver.
3. force Anaconda to pause and ask you for the information, by putting 'ip=askme' on the kernel command line. (You don't actually need 'askme', just anything that isn't an IP address or 'dhcp'.)

The third option is undocumented but probably unlikely to break in the future, and sometimes quite handy.

The Kickstart process assigns the machine IP address very early on, before Anaconda has started and before the more sophisticated bits of the Kickstart file are evaluated. Thus, you can't have the IP address and suchlike generated by a %pre section.

From personal experience, syslinux is the only bootloader that lets you have a lot of boot entries and deal with them sensibly. LILO has a low hardcoded limit, and while Grub can theoretically deal with lots you'll have to scroll through a huge menu; with syslinux you can do things like have a generic USB key that will install any one of a hundred machines with the right IP address options just by typing its hostname.

(Disclaimer: this is all how it was in Fedora Core 4 (and earlier versions); I haven't tested FC5 to see if it changed anything.)

Sidebar: why not DHCP?

I don't like DHCP, because it is very rare that I want a machine's IP address to be assigned based on its Ethernet address. Far more common is things like lab situations, where I want machines to be given names based on their physical location. You can do this with DHCP, but you have to be careful to maintain what is effectively a table mapping physical location to Ethernet address, and I'm not convinced you get anything for the effort.

Seeing Quicktime movie trailers on Fedora Core 5

Today I got Linux one more step into being a proper, fully functioning system: I got Quicktime movie trailers displaying in Firefox. It turned out to be pretty easy once I realized what was going wrong.

I'll assume that you've got the Unofficial Fedora Core FAQ handy. Directions in a nutshell:

1. install rpm.livna.org's livna-release package. (Ignore the other bits of the unofficial FAQ's instructions; they're not necessary as far as I can tell.)
2. yum install mplayerplug-in
3. install the w32codec RPM from atrpms.net. You'll need to get the RPM by hand from here. (I'm not sure how the FAQ's instructions are supposed to work since the livna-release RPM doesn't set up any repository stuff for the atrpms RPM repository, so yum has no idea where to get 'atrpms' stuff from.)
4. rpm -e totem-mozplugin

The last step is the crucial one. Without it, you have both Totem and MPlayer trying to claim various video formats, and Firefox decides that Totem wins. Unfortunately, Totem is kind of lacking in codec support, so the result with trailers is that the video display area starts up but pukes, sometimes with mysterious errors. Removing the totem-mozplugin RPM gets Firefox to use the MPlayer plugin, which works.

(As far as I can tell, Firefox has no way to control which plugin gets called on to display content, so you have to outright remove the Totem plugin instead of just setting the MPlayer plugin to a higher priority.)

My glee may sound petty, but playing movie trailers and other amusing videos you find on the web is one of the few things that I haven't been able to do under Linux that I really wanted to. In the past, I've even resorted to firing up VMWare when I got curious about a trailer. (Of course, now I have new shiny tempting diversion at work. Oops.)

Some computer power consumption numbers

One of the things we have lying around here is a power meter with a handy convenient watts output, so I've spent parts of yesterday and today measuring how much power my new machine uses in various circumstances.

Modern graphical hardware apparently doesn't fire up all of its power-consuming stuff until you start using the 3D bits. The open source drivers for the ATI X800 graphics card in this machine don't have any 3D support, but the 'fglrx' binary ATI drivers do. (Now you know what got me started playing around with additional FC5 packages yesterday.)

I'm a bit surprised at the 30 watt difference from just enabling the 3D hardware, with no actual 3D operations going on. I believe that it sticks around even if you drop the machine into runlevel 3.

Rebooting seems to peak around 150 watts, averaging around 140 or lower. Powering up the machine averages about the same as rebooting, but has a peak of around 170 watts.

Banging on the disks makes little to no difference in the power usage, which wasn't really surprising once I thought about it. Since the disks are already spinning, the only extra load is from the read/write electronics and head seeks, and they're apparently pretty low.

(Unfortunately OpenGL stuff is not currently working without the ATI binary drivers, so I don't have power consumption figures for glxgears on the open source drivers. This may not be the fault of the binary driver packages, since I'm not sure glxgears ever worked; I didn't test it before installing the ATI binary drivers.)

I note in passing that part of the irritation with benchmarking and measurement is all of the stuff you only think of in hindsight.

Sidebar: the hardware (in summary)

The test machine has an Athlon 64 X2 4400+ with 2GB RAM in a Tyan K8E motherboard, the already mentioned ATI X800 GTO (PCIe), two 300 GB Seagate SATA drives, and a 500 watt Enermax Liberty power supply.

Some Fedora Core 5 experimentation

The Unofficial Fedora Core FAQ has a section on how to install prebuilt packages for various things that can't be shipped as part of Fedora Core, like MP3 players and binary graphics card drivers. I've always ignored it, installing what I needed by hand; user-friendly installs aren't necessarily very sysadmin friendly, and I never felt like taking the risk. (I deal with enough badly packaged RPMS as it is.)

But one of the advantages of scratch installs on new machines is that I don't have to care how messed up they get; they're perfect for wild experiments. So that's why I spent part of today trying out installing things the easy way, starting with the ATI binary drivers for the machine's X800 graphics card and going onwards to various media players.

Amusingly, the ATI binary driver runs glxgears so fast that the gears seem to turn slowly. At first I thought that I wasn't actually getting hardware accelerated 3D; only seeing the frames per second numbers that glxgears prints convinced me. (I suppose I should actually see what the software 3D performance numbers are for comparison.)

The results with the various media player bits are more inconclusive, partly because Totem still has a death grip on every media type in sight in Gnome (and doesn't have enough codec plugins).

(If Totem wants to insist on handling pure audio types, the least it could do is not still have a huge black video area in its window while playing them.)