Welcome to the Queens Zoo



Bobble on the Bookshelf
Originally uploaded
by Rich Renomeron.

Today is a lousy day to be a Mets fan.

After weeks of playing the “will-they-or-won’t they” game with Willie Randolph, they fired him today, or rather, early this morning, after a win no less. The reasons for doing the deed when it was done include “they didn’t want to fire him on Father’s Day,” and “they didn’t want him to hear about it from the media.” But it seems to me that the Mets’ brain trust could not make up their collective mind on What To Do about their underachieving team.

After last season’s epic collapse, it was pretty clear that Randolph was “on notice” – and despite public pronouncements like “Willie is the manager, and he has a contract,” there’s been a feeling that they might drop him the moment things went south. There were rumors floating around in the media such as, “if they don’t take this series, he’s gone,” or “another week like that, and it’s over.” Constantly. Since April.

Today I read that Omar Minaya may have been pressured by the Wilpons to act, and it very much reminded me of the Steinbrenner Way, particuarly the mid-’80’s edition. They called the Yankees’ organization “The Bronx Zoo” for a reason – and I certainly hope that something similar is not happening over in Queens.

Exposure

Dugout Confab

Epiphany and Modernity

Farragut Outlit

One of the fun things about publishing your photos publicly on Flickr is that you never know who might find your shots interesting. A couple of weeks ago, I got an email requesting that three of my photos were on a “shortlist” for inclusion in an online travel guide called “Schmap”. So I went to their web site and granted them rights to use the photos (as I use the Creative Commons Attribution-Noncommercial-No Derivatives license, you need explicit permission to use them in a commercial endeavor). The other day, I was informed that all three were selected. The three winners can be seen in the travel guide here, here, and here.

Upgrading to Ubuntu 8.04

There have been many blog posts on the Ubuntu Planet about the ease of upgrading to the brand new 8.04 version. Unfortunately, my experience with my Dell Inspiron 1420N was not flawless. Of course, the three big problems were caused by software that was not fully supported; one problematic package was an esoteric bit of software from the community-supported “universe,” the second was caused by a Dell-provided driver for a softmodem I never use, and the third was caused by a proprietary program that hasn’t kept up with the changes to the Linux kernel. There was also a minor problem with the Wifi light that is easily fixed by installing an additional package. Most people, who stick to Ubuntu-supported software (the “main” component), or well-known stuff from universe, will probably have an easier time. I did, however, get everything working with a little bit of elbow grease, the details of which follow for anyone who finds themselves in the same boat.

The first and most serious problem: pam-encfs, as shipped in Hardy, does not work, and will mess up your PAM configuration. This will prevent you from logging in, and in fact, will lock you out of your system in the middle of the upgrade if your screen locks after a period of inactivity (as happened to me). To gain control of things, I had to boot into recovery mode, run “dpkg –-configure -a”, and then “apt-get dist-upgrade” to make sure everything was installed correctly. Even then, I still could not log in. From recovery mode, looking in /var/log/auth.log revealed the following messages:

Apr 22 21:10:18 pigwidgeon gdm[5577]: PAM unable to dlopen(/lib/security/pam_encfs.so)
Apr 22 21:10:18 pigwidgeon gdm[5577]: PAM [error: /lib/security/pam_encfs.so:
    undefined symbol: __stack_chk_fail_local]
Apr 22 21:10:18 pigwidgeon gdm[5577]: PAM adding faulty module:
    /lib/security/pam_encfs.so

After disabling pam-encfs in my PAM configuration, I could log in normally, but my encrypted directories weren’t mounted automatically. Googling around turned up bug 20573 in Launchpad, so I’m not the only one who ran into this. Luckily, there’s a patch, and I’ve built a usable package that will work until the official fix gets into Ubuntu, which can be obtained from my Personal Package Archive on Launchpad.

If you encrypt your entire home directory, something like the following might work (I haven’t tried it myself, so YMMV):

  1. Do the upgrade, make sure your screen doesn’t lock, and don’t do anything that would require authentication.
  2. Reboot when it’s done, but make sure you reboot into “recovery mode,” and drop into a root shell.
  3. Add the my Personal Package Archive on Launchpad to your Apt sources.
  4. Do the usual “apt-get update && apt-get upgrade” thing, make sure libpam-encfs gets upgraded.
  5. Exit the root shell, continue bootup as normal.

It appears that libpam-encfs is not a very widely used package, so hopefully the number of people who will be bitten by this is small.

The second problem: No Sound. This always seems to be a problem with the 1420N (I initially had no sound on the Feisty to Gusty upgrade), and it has the same cause: the softmodem driver. But I didn’t figure that out until an entry on the Dell Linux Wiki about it appeared soon after the official release. After following those instructions to remove the driver, the problem was solved. I’m sure that in a few weeks the Dell folks will have a new, working driver for the softmodem, but since I never use it, I’m not too worried about it.

Third problem: VMware doesn’t work. There are two issues here; the first is that VMware Server 1.0.x is incompatible with the 2.6.24 kernel series, and the second is a conflict with a system library that VMware overrides. The kernel issue was solved by uninstalling the vmware-server and vmware-kernel-modules packages, installing the tar.gz version of VMware Server 1.0.5, and then running the latest vmware-any-any package (download here). The library conflict, which prevented even the server console from running, manifested itself with the following error messages on startup:

libgcc_s.so.1: version `GCC_3.4' not found (required by /usr/lib/libcairo.so.2)
/usr/local/lib/vmware/bin/vmware:
   /usr/local/lib/vmware/lib/libgcc_s.so.1/libgcc_s.so.1: version `GCC_4.2.0'
   not found (required by /usr/lib/libstdc++.so.6)
/usr/local/lib/vmware/bin/vmware:
   /usr/local/lib/vmware/lib/libgcc_s.so.1/libgcc_s.so.1: version `GCC_3.4'
   not found (required by /usr/lib/libcairo.so.2)

This was caused by an incompatible version of the library libgcc_s.so.1 that’s shipped with VMware. Removing the file /usr/local/lib/vmware/lib/libgcc_s.so.1/libgcc_s.so.1 forced VMware to use the Ubuntu-supplied version of the library, and allowed VMware to start normally.

The fourth problem, which is very minor, was that the WiFi light on the front panel no longer works. This is a consequence of moving to the next-generation driver for the Intel wifi chip. To solve it, simply install the “linux-backports-modules-2.6.24-16-generic” package.

Once those problems were out of the way, I was able to enjoy the new release, which is full of the incremental improvements I’ve come to expect from Ubuntu every six months – including an integrated version of the new Firefox 3, which is worth it for the JavaScript performance improvement alone.

The School as a Neighborhood Anchor

While flipping through the Mozilla blogosphere this evening, I came across an interesting post from David Ascher, the new leader of Mozilla’s messaging effort, which was only tangentially about messaging. He had attended an event where people were discussing how to sesmically retrofit aging Vancouver city schools, and pondered the differences between building a consensus on school construction policy and building a consensus on the “future of email.” One point he made that struck me was this:

… it was hard to find people who didn’t appreciate the elegance of an old idea: that our schools shouldn’t be thought of (and budgeted for) as single purpose “teaching boxes”, but instead as multi-purpose community hubs, leveraging precious real estate to provide a variety of civic services (libraries, gyms, meeting spaces, cafeterias, playing fields), with an appropriate funding model.

He goes on to list a few positive effects of viewing schools in this manner, all of which had me nodding my head in agreement. Building schools with the intent of using them as “neighborhood anchors” won’t solve all the ills of urban schools (I remember a particularly heartbreaking example of a glittering new high school in Washington, DC that was left to rot), but it’s a good idea, especially in communities where there is little investment, public or otherwise.

Fixing MoinMoin for Firefox 3

I’ve been trying out the Firefox 3 betas lately, and have been impressed. But I’ve noticed a big problem with the WYSIWYG editor in the MoinMoin wiki (which runs a small wiki I have on my home network). When I try to click the “link” button on the toolbar, the ensuing popup window is completely blank, instead of showing a nice dialog box as it should. This also happens with any other popup dialog box in the editor. Since Firefox 3 will likely be the standard browser around the house when the next Ubuntu upgrade comes in April, this poses a problem.

So I decided to find out what was going on, and if there was anything I could do about it. The first round of Googling was not encouraging. MoinMoin uses FCKeditor to provide its WYSIWYG editing capability, but it uses very out-of-date version. The FCKeditor folks did a bunch of fixes for Firefox 3, but MoinMoin hasn’t updated their copy to pick up the changes.  There’s a bug report for the issue on the MoinMoin site, but there appeared to be no activity on fixing it. Attempting to simply replace MoinMoin’s copy of FCKeditor with the new version failed miserably; there was a JavaScript alert dialog on practically every keystroke, and with little knowledge of the underlying code, there was no way I could figure out the problem.

After doing some more digging into what the exact Firefox 3 incompatibility was, I found that Firefox has an issue with a window opened with the JavaScript flag “modal=yes”. Further, the discussion in the FCKeditor bug tracker pointed me to a patch that fixed the problem. Unfortunately, there has been quite a bit of refactoring in the codebase, and I couldn’t simply apply the patch to the copy MoinMoin has (the file mentioned doesn’t even exist in the MoinMoin version); I had to backport it. After looking around the directory tree in /usr/share/moin/htdocs/applets/FCKeditor, I was able to find a similar spot in the code, and make the change. Here are the steps:

  1. Fire up your favorite editor and open $MOIN_HOME/wiki/applets/FCKeditor/editor/js/fckeditorcode_gecko_2.js. If you’ve installed MoinMoin from an Ubuntu package, $MOIN_HOME/wiki is /usr/share/moin/htdocs.
  2. Search on the string modal=yes. It should be on a line that looks something like this:
    var J="location=no, menubar=no, toolbar=no, dependent=yes,
    dialog=yes, minimizable=no, modal=yes, alwaysRaised=yes"+",
    resizable="+(G?'yes':'no')+", width="+D+", height="+E+", top="+H+", left="+I;
  3. Remove the “modal=yes,” (include the comma).
  4. Clear your browser cache.

After that, I was able to edit my MoinMoin wiki with all the Firefox 3 goodness.

Update 3/21: The MoinMoin developers have checked in the fix, so this won’t be a problem in the next version (1.6.2) of MoinMoin!

Update 4/7: With the fix, the link editor now inserts invalid links.  We’re not done yet.