Wandering Thoughts archives

Progress towards an all 64-bit application world

When I started with x86_64 Fedora Core, I still built a few things as 32-bit applications on an otherwise 64-bit system; a 32-bit Firefox to use Adobe's 32-bit only Flash plugins, and a 32-bit mplayer so it could use Windows codecs to play various content. This has caused a certain amount of heartburn.

Recently, I decided to experiment with 64-bit versions of both (partly because doing the 32-bit compiles has been a pain; I build my copies of both from source). The results have been very pleasing.

• mplayer has added native support for various codecs while I wasn't paying attention, with results good enough for my relatively undemanding usage. I've successfully used it for FLV videos (YouTube's Flash stuff), Apple's Quicktime movie trailers, and some random AVI files. I suspect that it won't natively handle .wmv files, but I haven't needed to deal with any yet.

• Nspluginwrapper runs 32-bit plugins in 64-bit Firefox builds. Unfortunately it is a bear to get compiled and has some peculiarities when you're trying to use it. To save people the effort of wrestling with it, I've put precompiled x86_64 FC5 and FC6 RPMs up here, along with my hacked up SRPMs.

  (Don't even bother trying to rebuild the SRPMs under mock; nspluginwrapper has build requirements that as far as I know can't be expressed in what BuildRequires: allows.)

  One important and underdocumented thing is that the nspluginwrapper program must be run with the full path to a plugin's .so to install it. If you don't, it doesn't complain but it doesn't actually do anything, which is frustrating and annoying. (You can put the plugins anywhere; I like $HOME/.mozilla/plugins/i386.)

This does leave Java applets unaddressed for now; fortunately I don't need any at the moment, and apparently the gcj web plugin works pretty well (usage instructions for FC6 are here).

(And now back to wrestling with fonts, which is much like wrestling with pigs.)

The quest for a nice Linux CD player application

Why is it so hard to find a decent CD player on a modern Linux system? It's not that I have particularly demanding requirements; all I really need is something reliable that does CDDB lookups, ejects the CDs when they're done playing, and that will show me the total time remaining in as well as elapsed time in the track. (Other features would be nice but are not as important.)

(Technically, I also need a CD player program that will do direct digital playback, since DVD-ROMs don't seem to come with headphone jacks any more. Fortunately this seems common these days, although it is giving me flashbacks.)

So far, on a Fedora Core 6 machine, I have tried:

gnome-cd	Works, but doesn't have end of disk eject or total remaining time.
kscd	Promising, except for the bit where it randomly claims to have no permissions on /dev/cdrom and doesn't work. (And the information display is unfortunately designed.)
sound-juicer	No time displays.
xmms	Doesn't have end of disk eject or total remaining time, and it doesn't actually display the CDDB information it looks up.
xmcd	Hard to get working and uses obsolete SCSI ioctls, so if I run a standard kernel my kernel will scream at me all the time. But at least it has all the features I want.

If I had the spare time and energy, my best choice would be xmcd, which says something. (It is particularly depressing because xmcd is more than ten years old. Heck, I was using it ten years ago. (And recently; up until this upgrade, it has been my CD playing application of choice. But it is an ever-increasing amount of work to make behave, and I'd need to rebuild the current version.))

(Yeah, yeah, I know, these days everyone rips their CDs to disk and plays the audio files directly off disk. I'm old fashioned, plus I have better things to do with my disk space.)

Some more power consumption numbers

We had a power meter lying around my new office and a different variety of stuff from last time, so here's some more power consumption numbers.

First, for a random assortment of stuff:

Allied Telesyn FS705-LE 5-port Ethernet switch	3 watts
Allied Telesyn FS750 16-port Ethernet switch	7 watts
Sun SunFire X2100 1U server, powered off	6 watts
SunFire X2100 powering on	130 watts and a lot of noise
Dell 1907FP LCD displaying stuff	26 watts
Dell 1907FP in powersave with no signal	2 watts

Next, for a 2.4 Ghz Intel Celeron on a VIA CN400/PM800 based motherboard in a more or less generic case with a more or less generic 40Gb IDE drive, running Ubuntu Linux:

powered off	3 watts
idle at the Ubuntu Gnome login screen	75 watts
CPU usage at 100%	120 watts

Finally, for one of my main M2N4-SLI machines:

powered off	3 watts
in the BIOS's hardware monitor screen	122 watts
idle, either text or graphics	98 watts
in the Gnome screensaver	120 watts
streaming disk reads from one drive	125 watts
streaming disk reads from two drives	137 watts
one core busy with a CPU soaker	128 watts
both cores busy with CPU soakers	155 watts
both cores busy and streaming writes to a software RAID-1	158 watts
both cores busy and one drive doing streaming reads	158 watts
both cores busy and both drives doing streaming reads	162 watts

The streaming disk reads took about 10% of the (dual core) CPU for one drive and 21% for two drives, all in system time according to vmstat and procinfo. Streaming writes use a significant amount of CPU all on their own, so I only ran them with the CPU soakers active.

Interestingly enough, the power figures suggest that writing to the software RAID-1 filesystem (which was actually LVM on top of a RAID-1) was not actually driving both disks simultaneously. Possibly the Linux kernel bursts writes back and forth between the drives.

Sidebar: the boring hardware details

The M2N4-SLI machine that I measured has an Athlon 64 X2 4600+ CPU in an ASUS M2N4-SLI motherboard, 2GB of memory, two 320GB Seagate SATA drives, an Enermax Liberty 500 watt power supply, and an ATI X800 GT PCIe graphics card. I'm not going to try the ATI binary drivers this time around, so I have no figures for that.

I don't know what exact hardware the Celeron box is built from; it is a more or less generic box that we happened to have lying around.

The quest for the mythical C.UTF-8 locale

Recently, Pete Zaitcev wrote in passing:

Now if only someone designed a UTF-8 locale which did not screw the ordering files in ls output...

What he said. I've come to realize that what I want what I'll call the 'C.UTF-8' locale: all of the old-fashioned Unix non-locale behavior, but with non-ASCII characters encoded in UTF-8. I don't mind UTF-8 too much and it's clearly the future, but I don't want anything else that gets bundled up as a 'locale', and I especially don't want crazy sorting.

Having spelunked glibc info docs and done some experimentation, there are several useful environment variables for achieving something like this:

• LC_CTYPE sets the output and input character encoding, although some programs have their own overrides that may also need fiddling (eg, less has LESSCHARSET)
• LC_COLLATE sets the collation order, which controls how ls (and the shell's echo and so on) order files, among other annoyances.
• LC_MESSAGES sets what language messages appear in. It does not appear to set an implicit default output character encoding, so you must set LC_CTYPE as well for anything that needs non-ASCII characters.

LANG sets global values for these, overridden by the more specific versions; LC_ALL sets all of them, overriding everything else.

Linux glibc is smart enough to convert from message character encodings to output character encodings, even for relatively complicated things like Chinese error messages. On the other hand, it's kind of daunting to think about how much code gets invoked when ls prints an error message.

(I observe in passing that it's very handy to have a graphical program that deals only in UTF-8 and some UTF-8 files when testing this sort of thing. That way you can be sure that things really are generating UTF-8 or are in a UTF-8 display mode.)

I currently run with no LANG et al set, because of past concerns (and because I only work in English, so I can get away with it). Having looked at all this, it's tempting to set LC_CTYPE and step into the modern UTF-8 world. In theory it would be transparent (xterm and vi and GNU Emacs and so on seem to correctly switch into UTF-8 mode without further poking), and it'd mean I'd stop seeing vaguely mangled manpages every time I ssh into a normal modern Linux system.

Installing Wine on Fedora Core 5 x86_64

Here's a fun Fedora Core RPM dependency problem that I just fixed. (Since I've jumped on Ubuntu for similar things, I feel that equal time is only fair.)

I have been trying to install Wine on my Fedora Core 5 machine for a while, without success. The visible manifestation of the problem was that 'yum install wine' would download everything and then bomb out during the install complaining about two things:

• 'package sane-backends-1.0.18-2.fc5 (which is newer than sane-backends-1.0.17-4) is already installed'
• 'file <various> from install of sane-backends-1.0.17-4 conflicts with file from package sane-backends-1.0.18-2.fc5'; the files were all architecture-independent things like manpages.

My machine is an x86_64 one, but Wine is an i386 program and thus requires requires i386 libraries, which was clearly where the requirement for 'sane-backends' was coming in; it was trying to install an i386 version, which was conflicting with the x86_64 version I already had installed.

Installing the same package for multiple architectures is a hard problem. In order to make it work in RPM, you have to insure that each package supplies absolutely identical versions of common files like manpages and so on. Knowing this, I wrote the Wine installation problems off to the Fedora Extras Wine people having goofed up on this, and just retried periodically hoping that they'd fixed it.

(I flirted briefly with removing the x86_64 version of sane-backends, but it turns out to be required by a number of things that I wanted to keep.)

After I did a successful install of Wine on my FC6 test machine, I took a deeper look into the problem to try to figure out what was different between the two environments.

• first, I yum installed all of the other Wine dependencies, just to simplify things. This let me see that FC5 Wine was pulling in the i386 sane-backends because it wanted 'libsane.so.1' (an i386 library; an x86_64 one would have had a '(64bit)' tacked on the end).
• rpm -q --requires wine-core on the FC6 machine showed that the FC6 Wine still needed this library.
• rpm -q --whatprovides libsane.so.1 on FC6 said that it was coming from the i386 sane-backends-libs.
• yum list sane-backends-libs* on FC5 said that there was indeed an i386 version of this RPM.

So I yum installed the RPM by hand, then retried the Wine install and it went through.

What happened is that Red Hat ran into the multiarch issues and split the libraries off into the sane-backends-libs RPM to fix it, but only after Fedora Core 5 was released. The old, pre-split version of the sane-backends RPM stayed around in the 'core' RPM repository (which is what was shipped with the initial release); when yum went looking to satisfy the dependency it found that first and used it. Fedora Core 6 avoided the problem by having the post-split RPM from the start.

(You can see this live with 'yum whatprovides libsane.so.1' on a FC5 machine, which will report both sources.)

While I could call this a yum bug, I think a fairer assessment is that yum is missing a feature: it should have some way of ordering the repositories when it tries to satisfy dependencies (I suspect that at the moment it effectively uses alphabetical order in /etc/yum.repos.d). Alternately, it should just default to preferring the newest RPM that will satisfy the dependency.