An Infinite Number of Browsers

It's hard to believe, but even in this day and age some websites insist that you must use some version of Internet Explorer before you are allowed to enter, even if the site uses no special features of Windows or IE (e.g. ActiveX).

This is the rational behind the User Agent Switcher extension for Firefox.

The Switcher comes with a default set of browser ID strings: IE6, Opera, and Netscape, I believe. But what if you want more? What if you need to see if a site will recognize IE on a Mac running OS 9?

Thanks to Matt Parnell's post, I've found a site which will solve all your problems. Just go to Tech Patterns, download this file, and install it using the directions in Parnell's blog. Now you have a gazillion (more or less) browser possibilities. The Tech Patterns forum has some suggestions as to how to use them.

Two Weeks in Oz

I've been gone for a couple of weeks, back in Kansas because of a family medical emergency, successfully resolved, thanks. During that time, I spent most days driving back and forth between Holyrood and Hutchinson. It's about sixty-five miles, house to hospital, and takes about 70 minutes. In contrast, my daily commute in the DC area is 28 miles and takes about 45 minutes. Oddly, I hit more stoplights & stop signs on my Kansas commute than I do on my regular DC commute. Anyway, here's my observations of the trip:

• If you have to get someplace, fast, consider Southwest Airlines. I got full-fare round-trip tickets from BWI to KC for under $500, leaving about six hours after I ordered the tickets. Other airlines wanted about $1,000, and one offered to fly me on the ever popular BWI-Salt Lake City-Atlanta-Wichita route.
• Of course, this meant I still had to get from KC to Holyrood. On the way in I was picked up by another family member. On the return, I flew from Salina to KC on Air Midwest, operating as US Airways Express. This cost about $65, as opposed to $45 for a trip on the bus. Since the bus would have dropped me off in downtown KC and the plane took me to the airport, this works out to be a cheaper way to travel.
• Because I had full-fare tickets, Southwest and Air Midwest let me change my reservations numerous times, as the situation changed. I was fearful this would put me on the no-fly list ;-) but fortunately it didn't.
• The flight from Salina to KCI was interesting: there was one Air Midwest employee at the ticket counter, three TSA people for security, two pilots, and an unknown number of people in the control tower. There were two passengers. I don't know how long they can keep that route open.
• As you may have heard, Kansas has been extraordinarily wet this summer. In addition to the Greensburg tornado, there has been lots and lots of rain. In an average year, for example, Hutchinson gets 32.7 inches of rain. In May, Salina got 15.94 inches, and in many places it was much higher. (Very unofficially, Holyrood got 25 inches of rain in May.)
• This leads to never-before seen phenomena. Cheyenne Bottoms, a marshy area which usually covers about 50 square miles, is rather full. As in not-for-at-least-the-last-eighty-years full. Note the sentence in the above article that reads “The only safe entrance to the Wildlife Area was from the west of U.S. 281, but now that approach has about 19 inches of water on it and is not passable.” Highway K-156, which skirts the southeast edge of the bottoms, is surrounded by water on both sides. The roadbed is only about 4 feet above water level, and the mile roads which run through the bottoms are all under water.
• The usually placid Plum Creek, which runs to the east of Holyrood, flooded one night, covering the K-156 bridge, fortunately closed because of construction. The bridge is about 20 feet above the normal level of the creek. Given the topography of the area, the flooded creek was at least a quarter-mile wide. A distant cousin, somewhat more daring than I, took pictures, if he sends them to me and gives permission I'll put them online. Four bulls were surprised by the rushing water and were killed, fortunately no humans were injured during the storm.
• Well after the storm, Plum Creek has enough water to support a family of ducklings, something I'd never seen before.
• In addition to ducklings, the entire area is suffering a small-scale plague of frogs — only small scale because they're about 1 inch long. Thousands of them die each day trying to cross the roads, done in because they are thick enough that drivers can't avoid them.
• The aforementioned Salina Airport's terminal building was flooded twice, and has a resident frog population.
• What with planting season drought and early spring freezing, this rain has pretty much done in the wheat harvest. Yields are low: a friend who hauls wheat says it's taking about three times as long as last year for a combine to fill up a truck to take to the grain elevator. And the wheat is poor quality: nominally a bushel of wheat weighs 60 pounds, but this years crop weighs in at anywhere between 42 and 55 pounds. Even though wheat now sells for over $6.00 per bushel, a lot of farmers are going to be hurting this year.
• I need to get a second digital camera, so I can have one on these expeditions and the family can have one as well.

AHAHAHAHAHAHAHAHA!!!!

Just a little fun, for a change. This is from the Sex Kills episode in Season Two of House, and is Hugh Laurie at his finest:

• Evil Laugh (ogg format, 35070 bytes)
• Evil Laugh (mp3 format, 29117 bytes) [Currently unavailable due to Awardspace.com restrictions on uploading mp3 files — I'll eventually put it up elsewhere. Email if you really want it in this format.]
• Evil Laugh (wav format, 305964)

Recorded using Audacity 1.2.6, from a video tape of the episode. I had to remember to use gnome-volume-control to unmute the line-in input so that audacity could actually hear the tape. I also had to use Audacity's envelop function to increase the volume.

Photograph from IMDB.

Re-Installing Intel(ligence?)

If all Linux distribution were the same, there wouldn't be a point in having so many of them. But that, of course means that different distributions are different. OK, there are certain categories you can use to pigeonhole them, e.g., tarball/rpm/deb packages, GNOME/KDE/whatever Window Manager, graphical/text installation, etc., but there are also more subtle differences.

Case in point, for the standard /bin/sh shell required of every Unix-like computer, Ubuntu (and, I suppose, Debian) uses the Debian Almquist shell (dash), using a symbolic link from /bin/dash to /bin/sh. Most other distributions link to the heftier Bourne-again shell (bash). You can see which shell you are linked to with the command:

$ ls -l /bin/sh
lrwxrwxrwx 1 root root 9 2007-05-28 12:26 /bin/sh -> /bin/dash

which shows that when I call /bin/sh, I'm really running /bin/dash.

And that's fine, in most cases. If some program in the Ubuntu distribution requires the capabilities of bash, rather than dash, to run its scripts, the package maintainer can alter every invocation of /bin/sh to read /bin/bash, and all is right with the world.

Unless, of course, you have a third-party program that doesn't allow a distribution maintainer to alter the code in any way, assuming that the distribution is allowed to put the code in its repositories in the first place.

And therein lies today's sermon:

A long, long, time ago, four weeks, I guess, we upgraded Hal to the Feisty Fawn edition of Ubuntu Linux. Back then I said something about eventually re-installing the free-for-noncommercial-use Intel® Fortran Compiler for Linux and corresponding Intel® Math Kernel Library (MKL).

Today was the day. (Amazing what you'll do to keep from balancing the checkbook.) I got the newest versions of the compiler and the library, filled out the yes – I'm – only – going – to – use – this – myself – and – yes – we – bought – a – copy – for – work form, and went to town.

I've installed various versions of the Fortran Compiler before, and the procedure listed in that link always worked, with suitable modifications of the version numbers. Not this time, though. I got the compiler installed, but when I tried to run it, an error message told me I'd performed an illegal operation. The problem turned out to be in Intel's ifort script, which actually calls the compiler. It's written using the generic shell /bin/sh, which Intel expected to be linked to /bin/bash, but which Ubuntu links to /bin/dash. Since dash is a lot simpler than bash, the script fails. The solution is to simply edit the ifort file, which on my system is at /opt/intel/fc/9.1.043/bin/ifort, so that the first line reads

#!/bin/bash

For more on this, see Intel's help pages and the Ubuntu Forums.

That's half the battle. As I've noted before, for scientific calculations it is useful to have certain operations optimized (in assembly) for your CPU. When using the Intel compilers, the preferred vehicle for this is the Intel Math Kernel Library (MKL), which is distributed under the same license as the compilers.

Naturally that library expects /bin/sh to also mean /bin/bash. Worse, the installation script for the libraries fails because of the bash/dash problem, and just changing /bin/sh to /bin/bash everywhere doesn't seem to work..

There's a solution at the bottom of this Ubuntu Forums thread, but it ain't pretty:

In a standard Ubuntu installation, /bin/sh is soft-linked to /bin/dash:

$ ls -l /bin/sh
lrwxrwxrwx 1 root root 9 2007-05-28 12:26 /bin/sh -> /bin/dash

We're going to change that:

$ sudo ln -sf /bin/bash /bin/sh

Warning: if you leave out the -s option, you will mess up your system beyond belief. At the very least, you're liable to have bash and dash point to the same file, with uncertain consequences.

If the ln command is successful, bash is now your default shell. Run the MKL install. You shouldn't have to edit any scripts after this.

Finally, if you want to restore dash as the default shell, go back and run

$ sudo ln -sf /bin/dash /bin/sh

Again, do not forget the -s!!!!!

So far, all my codes compile correctly with ifort, and the MKL libraries all link properly, so I believe everything works.

But it sure would have been easier if Ubuntu developers had access to the package.

And Then They Fix the Kernel

Bug, feature, whatever, the latest kernel upgrade, delivered tonight, uses the ata_piix driver, and all my disks once again pretend they are SCSI.

Of course, now that I switched all the entries in /etc/fstab to use UUIDs, so it doesn't matter.

I hope.

Fixing My Bug

I finally have enough time to write up the resolution to my difficulties with the 2.6.20-16 kernel upgrade:

First of all, there is a bug, or at least an inconsistency, in the way the kernel is handling SATA disks. (Warning: Blogger is about to dive into areas he knows almost nothing about. Please keep your various appendages inside the vehicle while he attempts this dangerous maneuver.)

Apparently, disks (or, at least, SATA disks) can be mounted using one of two drivers: piix (Pci Ide/Isa Accelerator), which treats the disks as IDE drives, and ata_piix, which treats them as SCSI drives. In the former case, drives are mapped to /dev/hda, /dev/hdb, /dev/hdc, etc. In the latter, the drives are mapped to /dev/sda, /dev/sdb, /dev/sdc, and so on.

In the Dapper release, my drives were mapped to /dev/hda and /dev/hdd, meaning that we were using piix. In the initial install of Feisty, however, the drives were mapped to /dev/sda and /dev/sdb. (Drives “d” and “b” are the same drive, IDE worries about which controller the drive is connected to, SCSI doesn't.)

It doesn't matter, so long as we're consistent. So long as we can construct a proper /etc/fstab file, all will be well.

My problem began with the aforementioned update. From what I learned reading bug report, sometimes the piix driver gets control of the disks, and sometimes the ata_piix driver does. The kernel should choose one or the other consistently, but different kernels choose different drivers — that's the bug. (I think.)

Now, as to what was happening to me. Let's look at my pre-20-16 /etc/fstab file:

# /etc/fstab: static file system information.
#
# <file system> <mount point>   <type>  <options>       <dump>  <pass>
proc            /proc           proc    defaults        0       0
# /dev/sda1
UUID=38afc33a-e732-45eb-8271-cd23555ce5bc /               ext3    defaults,errors=remount-ro 0       1
/dev/sdb1                                 /home           ext3    defaults        0       2
# /dev/sda6
UUID=efc49726-51d6-411e-9745-a05edad31c21 /opt            ext3    defaults        0       2
# /dev/sda2
UUID=a955cf3a-b1bc-4998-92e1-0073aba94c4c /scratch        ext3    defaults        0       2
# /dev/sda5
UUID=79a7a282-c5b8-416b-a738-89ed35013381 /usr/local      ext3    defaults        0       2
# /dev/sda3
UUID=080af2c2-1bd6-4b4a-bceb-2e7c6c2a8fa2 none            swap    sw   0       0
/dev/scd0       /media/cdrom0   udf,iso9660 user,noauto     0       0
/dev/fd0        /media/floppy0  auto    rw,user,noauto      0       0

One of these lines is not like the others, one of these lines just doesn't belong. Spot it? It's the line that starts /dev/sdb1. There is no UUID for this drive, which just happens to be the partition holding all my data. Apparently (Danger! He's thinking again), the piix and ata_piix drivers can locate disk partitions by their Universal Unique IDs, and the initial Feisty install determined the UUIDs for all of the drives in my system, and entered them into /etc/fstab, helpfully putting up a # /dev/sda? comment for each drive, so we know how to refer to it in the traditional way.

Except that I didn't have my data disk hooked up when I installed Feisty — if something went wrong, I didn't want to accidentally erase all my files. I installed the drive later, and manually added the /dev/sdb1 line to /etc/fstab.

Which works fine, so long as the kernel keeps using the ata_piix driver! With the update to 20-16, the kernel started referring to my data drive as /dev/hdd1, which wasn't in the /etc/fstab file.

OK, I could just change /dev/sdb1 to /dev/hdd1 and all would work, but suppose the next kernel starts using ata_piix again? A more elegant solution is needed, and that is to refer to my data disk by its UUID.

And how to I do that you ask? Well, I sure didn't know, so I looked around the Ubuntu Forums and general Googling®. There, I discovered the command

$ ls -l /dev/disk/by-uuid/
total 0
lrwxrwxrwx 1 root root 10 2007-06-06 13:06 080af2c2-1bd6-4b4a-bceb-2e7c6c2a8fa2 -> ../../hda3
lrwxrwxrwx 1 root root 10 2007-06-06 13:06 38afc33a-e732-45eb-8271-cd23555ce5bc -> ../../hda1
lrwxrwxrwx 1 root root 10 2007-06-06 13:06 79a7a282-c5b8-416b-a738-89ed35013381 -> ../../hda5
lrwxrwxrwx 1 root root 10 2007-06-06 13:06 a955cf3a-b1bc-4998-92e1-0073aba94c4c -> ../../hda2
lrwxrwxrwx 1 root root 10 2007-06-06 13:06 bdad36ce-b67a-4c39-988e-94f40df90f67 -> ../../hdd1

Which tells me that /dev/hdd1 has the UUID bdad36ce-b67a-4c39-988e-94f40df90f67.

So now the resolution of the problem (for me, anyway) is simple. I just replace the offending line in my /etc/fstab file by

# /dev/sdb1
UUID=bdad36ce-b67a-4c39-988e-94f40df90f67 /home           ext3    defaults        0       2

Problem solved. I can now use the new kernel, and, hopefully, will be immune from this type of problem.

Hopefully.

Things I Don't Know About SATA

Sometimes, I astound myself with my technological dweebishness. I mean, here I am, knowing more about computers than 95% of the people on the planet,^† and I still get confused about things.

I think I know what happened to me yesterday. The “bug” probably doesn't affect every user of Ubuntu, only those who added extra disks and labeled them as /dev/sdb in /etc/fstab.

It might even be a feature, not a bug.

Unfortunately, I don't have time to track it down now. When I do, I'll write it up for posterity. I just wanted to post add a post here so that those who actually have a clue won't think I've completely lost my geek status.

^†That's not particularly arrogant. I also know more physics than 99.9% of the people on the planet. That would be arrogant, but I've got all sorts of pieces of paper to prove it.