If you’re lucky, this is the last time you’ll hear me mention Windows 7 for a while. But I’ve received a number of queries about my continued use of it for a while now. I have some very excellent reasons that I figured I should put in writing for easy reference.

1. Proactive non-reason: I don't hate Apple. I think their hardware is beautiful and I think Mac OS X is one of the most usable Operating Systems around (although it's got a learning curve like any OS does). Their prices are on the high end of reasonable, considering the hardware is generally top-of-the-line and well-built.
2. Proactive non-reason: I am pro-open-source. I think Linus' Law is spot on, and I think that "Release Early, Release Often" is a faster way to quality software. But I'm not an ideologue. I run Linux exclusively at work, but also I use plenty of closed-source applications without complaining. I'll even purchase DRM-ed media without much grumbling.
3. I like to build my own computers. There's something about the hundreds of interlocking details that appeals to my nature. The challenge of learning (or re-learning) interfaces and chipsets and how memory works is exciting. (Aside: I find the enjoyment that I get from following sports to be somewhat similar. They're complex worlds with details that are almost entirely self-consistent. And its the exceptions and quirks that make them enticing.)
4. Unfortunately, Mac OS X doesn't work on non-Apple hardware, at least not officially. And I don't feel comfortable applying a delicate hack that will make that work on my every-day machine.
5. My wife needs Windows for phone syncing and work applications. As a doctor, there are a number of applications she runs on her phone and at home to access charts and medical databases. Some of them have iPhone options, and a couple have cripped web versions, but none of them that I know of yet have a full-featured client that will work under either Mac OS X or Linux client.
6. I like to play games. I do it less than I did back in college, but I still spend five or six hours a week playing Team Fortress 2 or Trackmania or a number of other games. There are few Mac OS X or Linux versions of most games: Windows is by far the most popular gaming platform. (Gaming works well in Parallels within Mac OS X, but you still need a Windows install/license.)
7. Dual booting is more trouble than it's worth. I have no problem with Windows. In fact, so far, Windows 7 is really nice and stable and it plays nice with all of my hardware. I have several good reasons to use Windows, but no compelling reason to use something else. So I have no reason to go through the effort to set up a second OS.

Red Hat Enterprise Linux has ridiculously old versions of packages — especially those that are intended for a desktop audience. The GIMP 1.2.3 is so old that it's hardly worth using, so yesterday I spent an hour getting the latest version (2.2.8) working. There were a lot of steps involved because almost all of the prerequisites were a bunch of versions behind, too. So here's what I had to do to get Gimp installed and working on RHEL3.

1. You'll need some Red Hat packages installed. XFree86-devel, libart, and libart-devel are necessary, and you'll probably want some image libraries, too. I installed libjpeg, libpng, and libtiff, along with their respective -devel packages.
2. Set environment variables PATH should include /install/dir/bin, LD_LIBRARY_PATH should include /install/dir/lib, and PKG_CONFIG_PATH should include both /install/dir/lib/pkgconfig and /usr/lib/pkgconfig. Don't use /usr or /usr/local as your install dir. Who knows how these updated libraries could affect things if they clobber the older versions. I installed in /opt/gimp.
3. Get the sources for pkg-config, glib, fontconfig, freetype2, ATK, cairo, pango, GTK, Gimp. Links are located on the GIMP from Source page, except for cairo which is available from cairographics.org. I got the most recent version of all of these libraries except for freetype2. Version 2.1.10 will cause some problems that I haven't resolved, so I used 2.1.7.
4. Unpack all of the sources, and compile them in this order: pkg-config, glib, fontconfig, freetype2, ATK, cairo, pango, GTK, Gimp. (This was the hard part, figuring out the right order.) For each package, just add the argument "--prefix=/install/dir" to configure. Then make and make install. No other flags are necessary.
5. Gimp will be in /opt/gimp/bin/gimp. Delete the source files.

Recently, Sun released version 3.1 of the Sun Ray Server Software. It now has Linux support for USB devices connected to the thin clients. Instead of being kernel-level, this support is user-level — in the form of a modified libusb. Unfortunately, roughly 97% of applications expect kernel devices, and thus lack support for libusb. Luckily, pilot-link belongs to the minority. The following are my (roughly chronological) notes on getting a Palm (in the form of an old Handspring Visor) to sync with my Sun Ray.

• You'll need to have libusb 0.1.8 or newer installed. For reference, RHEL3 doesn't have a new enough version; I needed to find a non-standard RPM.
• Get the latest version of pilot-link from http://www.pilot-link.org/. I used 0.12.0-pre4. You'll almost certainly need to compile it, since even if your distro has a package for it, it probably won't be compiled with libusb support.
• Be sure to add the --enable-libusb flag when you run configure for pilot-link. (I assume the reader knows how to compile and install stuff under Linux)
• When you run commands that you want to use the Sun Ray libusb support, you need to run them with the LD_PRELOAD environment variable to include "/opt/SUNWut/lib/libusbut.so.1".
• I'm not sure what most of the executables that pilot-link installs do, but I know the important one is pilot-xfer. This command line works for me: bin/pilot-xfer --port usb: -s $HOME/.pilot-link This command will fail unless you have the Palm already trying to sync. You'll also need to run it as root, although the pilot-link guys say they're working on a fix for that.

I'm still on the hunt for something that will allow me to access data on a USB thumb drive.

Yesterday, I passed my Red Hat Certified Engineer exam with flying colors. I’m willing to call it a legitimate certification. The entire test was hands-on troubleshooting (“Here’s a machine that won’t boot. Fix it”) and installation and configuration (“Here’s bare metal, and a four page description of how we want the machine setup. Go”). It’s very indicative of the kind of work I do on a daily basis, so it’s far more useful than a multiple-choice test would have been.

I’m at Red Hat training this week in Westford, MA. The water bottles here have the logo on them, along with the following in tiny print: “Free (as in water)”. Geek humor at its best. (Read about Gratis versus Libre for an explanation of the joke.)

Once a process in Linux is running for more than 24 hours, it's impossible to get an exact measurement of its start time from ps. The best you can do it something like this:

lingalls@foobar:~$ ps -o “user pid stime tty comm” -u lingalls USER PID STIME TT COMMAND lingalls 32237 Apr06 ? gconfd-2 lingalls 11813 Apr06 ? gnome-session lingalls 11940 Apr06 ? utaudio lingalls 11950 Apr06 ? utslaunch lingalls 11951 Apr06 ? utmhscreen lingalls 11960 Apr06 ? utaction lingalls 11975 Apr06 ? ssh-agent lingalls 11979 Apr06 ? bonobo-activati

Which is completely unhelpful. So I wrote a script to calculate the accurate starttime from information in the proc filesystem. Shared here for your conveniece:

stime () { if ( test ! -d /proc/$1 ); then echo “No process $1”; return; fi; U="awk '{print $1}' /proc/uptime | sed -e 's/\.//'"; N="awk '{print $22}' /proc/$1/stat"; D="$(( (U-N)/100 ))"; perl -e ‘print scalar localtime(time - shift)."\n"’ $D }

Copy and paste that script into your bash or ksh session (or append it to your .bash_profile or .profile), and then run "stime PID".

The aforementioned major deploy went out this morning. It went well. More than 5000 man-days culminated in a very smooth site rollout this morning. I feel like a weight has been lifted from my shoulders.

Remember a few months ago, when I said that we had gone with SuSE instead of Redhat? Apparently, before we could sign a contract with Novell, Redhat turned around and told us “We want your business. We will match any offer Novell gives you.” So although nothing (still) has been totally resolved, it looks like we will be going with Redhat for our Linux needs. It’s been a long, wild ride, but it looks like we’ll soon finally have enterprise support for the roughly sixty servers under my domain.

Yesterday, after three months of indecision, we finally decided on a Linux distribution. We’re going, not with the (essentially) industry standard Redhat, but with SuSE. The codebase is obviously virtually identical, and the featuresets are pretty comparable, and Novell (who bought SuSE January 2004) gave us an amazingly good deal. It’ll be an interesting exercise trying to get all of our Dev and QA stuff moved over in the next few weeks, and there are apparently a couple of vendors we’ll have to pressure to hurry up their SuSE support, but it’s nice to have this decision finally made.

Update 3-23: It didn't go as easily as expected.

There are a lot of questions about this, but very few adequate answers available on Google. Solaris has a feature called “lofs” that allows you to mount some directory (say /bigvolume/foo) somewhere else (say /bar). The quick response is “duh, symlinks”, but if you want /bar to be read-only, or noexec, or nosuid, or some other uber-secure setting, this allows you to do it. Also, since chroot() breaks symlinks that point outside the new root, this can be used to simplify setting up chroot jails.

Since kernel 2.4, Linux has had support for mount binds (synonymous to Solaris' lofs), and here’s how to do it.

Command to mount /bigvolume/foo under bar:

# mount –bind /bigvolume/foo /bar

If there are other filesystems mounted under /bigvolume/foo, they’ll be ignored. To get them bound also, you’ll need to use –rbind instead of –bind. You can add -o and any options (like noexec, etc.) to the command.

To make this bind occur automagically on reboot, add the following to /etc/fstab:

/bigvolume/foo /bar none bind 0 0

Add any options after “bind” and a comma as you would normally.