The Fugue

I now have Leopard, so expect a flurry of posts as I discover neat things and annoyances.

The biggest reason why I got Leopard, apart from that my fellowship paid for it and you never turn down free gadgets or software, is for Terminal.app redux, aka Terminal 2 (think Schwarzenegger). When working on a laptop, I must have a tabbed terminal. This forced me to use iTerm, which worked well most of the time. However, iTerm hates me. It has an impossible-to-track-down bug that will occasionally render every curses program (including vim) useless for an indeterminate amount of time, and not even restarting iTerm will fix it. In general I've found iTerm to be somewhat shoddy, and Terminal is beautiful and, well, Mac-ish. So I'm excited for the switch to Terminal 2.

I had a right to be, too. It is a beautiful piece of software. I have a few qualms, though. First, and most annoyingly, the keybindings for next/previous tab aren't configurable, and they're set to the ridiculous default of ⌘-{ and ⌘-}. Yes, that means you have to press shift too. However, there is hope! Go to the Keyboard & Mouse preference pane, in the Keyboard Shortcuts tab. Scroll down to Application Keyboard Shortcuts, and add shortcuts for Terminal.app. Now I can switch tabs with ⌘-→ and ⌘-←, as it should be. Naturally, you can use this trick to change any unfavorable keyboard shortcut in any native OS X application.

I'm having some emulation issues, but this is not new to Terminal 2. When I ssh to my linux box and run irssi the screen doesn't update properly. It works ok if I run irssi in screen though.

I like the unlimited scrollback, though I hope it's not all going into RAM. Sometimes I'll do the odd copious command that spews on forever. I don't mind if it's going to a temporary disk buffer, but I don't want it all in RAM. I'm sure they figured that out though.

The built-in themes are nice. The configuration is well layed out, with one exception. I wish there was a place to set default preferences, common to all of the themes that don't override them. But since I and most other people who would care will stick to one theme, I guess it's not a big deal.

I haven't noticed any of the rumored problems of Terminal resizing without permission. I think Gary must have been expecting terminal to read his mind about where and how big new terminal windows would be. I'm glad it doesn't, because if I closed a terminal that I had resized temporarily, and then all my terminals started opening at that odd size, I'd be quite grumpy indeed. Size is one of the preferences you can set, and it works almost perfectly. I like mine as tall as I can get them, and I set it to 53 lines (with Anonymous 10pt). For some reason terminal would end up not quite at the top of the screen and sized only at 50. I opened a few tabs, sized it the way I wanted it (oops, with tabs I only get 51), and then went to the menu and chose Shell, Use Settings as Default. Now it behaves itself. My only unresolved annoyance is that I can't tell it to always have tabs, even when there's only one tab open. I don't like the shifting and resizing during the transition from 1 to 2 tabs (or vice versa). Oh well.

I was a beta tester for VMware Fusion. Fusion is a quality product, as I've come to expect from VMware. Unfortunately, the beta is over and a dialog box popped up when I tried to run it the other day. "The long wait is over!" Yeah, I've been waiting with bated breath for my beta to stop working until I fork over $40. You read my mind!

$60 ($40 after the current promotion) is the most affordable virtualization option for OS X right now, and in my opinion the most technically superior to boot. But I'm still a cheapskate, so I decided to use VMware Server on Linux over NX instead. NX is indistinguishable from magic. It works great, with one problem: the keyboard mapping in the virtual machine is completely skewampus.

In googling for the answer, I found a few people who had trouble with a key here or a key there. No, I had a completely unusable keyboard. e was the backspace key, backspace was a comma, escape was a letter, and everything else in between was equally unreasonable.

So I tried it over ssh (btw, it works a lot faster if you use ssh -Y instead of ssh -X), and it worked fine. So the gauntlet was down.

After some stabbing in the dark, reading, more stabbing in the dark, more reading, finally understanding, and one last stab in the dark, I got it to work. The theory is in this article. In short, VMware tries to map key codes to emulated PC scan codes (v-codes). If it can't do that, it maps keysym codes to v-codes. The former is apparently foolproof but isn't always an option. The problem here is that VMware thinks it will work, but it won't (probably because Apple's X11 isn't XFree86). So we simply need to put this in ~/.vmware/config:

xkeymap.nokeycodeMap = true

In OS X, when you "delete" something in the Finder it ends up in the trash. Each device has its own trash, which makes a lot of sense, but can be problematic.

First, let's consider the real-world analogy that is the trash. When you have something you want to get rid of, you throw it in a trash can. Later, you empty the trash at your convenience at which point the stuff is really gone. In the meantime, you can dig through the trash and retrieve stuff you didn't really mean to throw away.

Now some people use the computer trash (or "Recycle Bin") as a sort of junk drawer. They don't really want anything in there thrown away yet, they just want it out of their face. This is bad, for the same reason that putting something in the real trash that you might still want later is: someone might empty the trash while your back is turned. This happens at our house all the time—it's like magic.

On the other end of the stick are the people that berate the poor junk drawer souls, but don't flinch at having to empty the trash every time you turn around to accomplish something (see next paragraph). They're wrong too. The trash should be emptied when you feel like it and/or when you run out of trash can space.

Now, OS X doesn't afford the sane behavior because of the way it handles trash for removable drives. That is, it handles it the same as for permanent drives. When I delete something on my flash drive, it is still on my flash drive (in the trash) until I empty the one grand unified trash. In other words, you can't empty the bathroom trash without emptying every trashroom in the house. Also, you can't throw out those leftovers that have been rotting in tupperware for 3 weeks now unless you take out all the trash.

This is unfortunate for two reasons. First, since computer trash doesn't start to reek, we'd like to keep the trash around as long as we have spare disk space to do so, on the off chance we need something we deleted a few weeks ago. This is, after all, the whole point of having a trash can instead of instantaneous deletion, and the longer the better. Yes, it might fuel the junk drawer fire, but oh well. Second, taking out the trash to free up space is a bother, and the main trash usage pattern really is different from the delete-stuff-off-my-jump-drive usage pattern.

As an example, my MP3 player is a USB mass storage device. I put songs and podcasts on, and take them off, all the time. The Finder is more convenient than the commandline for this because of the file browsing nature of the task (not to mention spaces and special characters in the names of files). But when I press cmd-delete to delete the latest album I tired of, there's no more space than there was before. I have to empty my whole trash (or rm -rf /Volumes/YEPP/.Trashes) to reclaim it. This is unacceptable.

I found an elegant way to disable the trash on a device. That is, treat it more like a fridge than a house. It's quite simple:

cd /Volumes/YEPP
rm -rf .Trashes
touch .Trashes

Now when you delete stuff, Finder will see that it can't make the .Trashes directory, because a file of that name already exists, so it wil confirm that you really want to permanently delete stuff, and not put it in the trash. Everyone's happy.

If you don't like the idea of no trash at all, I think you can set something up with Automator and some shell scripting to empty the trash. Here's a sample workflow: "Get Selected Finder Items", then "Run Shell Script" with the input as arguments:

for i in "$@"; do
    if [ -d "$i"/.Trashes/501 ]; then
        rm -rf "$i"/.Trashes/501
        mkdir -p "$i"/.Trashes/501
    fi
done

As you may be aware, the default filesystem for OS X is HFS+ Journaled without case sensitivity. It retains case, but foo.txt and foo.TXT are the same file. You can install on an HFS+ case-sensitive disk, but if you do some apps may give you trouble down the road if they sloppily assume case insensitivity. So I chose to go with the default, even though I knew someday I would really want case sensitivity. That day came yesterday.

I'm using Tailor to create a Mercurial mirror of the FlightGear CVS archives. More on that later, but suffice it to say that from time to time people want to "rename" files in CVS (so far as you can call what CVS does renaming) to change poor case decisions. e.g. a file something like 747-SouthWest.xml got changed to 747-Southwest.xml (don't take my word on the exact filename). This was causing problems because CVS would get a conflict when it would try to check out that revision, and complain that the first filename is in the way, and if you manually intervene and remove it then it would claim that the first filename was missing.

So I thought, what would be ideal is a dynamically sized filesystem-in-a-file. It should automatically grow, but not take up more space than it needs to. It turned out to be easy to do in OS X. With Disk Utility, create a new image. Make it a sparse image and give it a reasonable maximum size (I chose 8 gigs). Then go into the partitioning and give it a nice name and an HFS+ case-sensitive filename. Uncheck the box for OS 9 support. Mount it and symlink it to wherever you want, et voilá, you have a case-sensitive subtree in your filesystem. It's a thing of beauty. When space gets tight and you need to shrink it to its minimum size, delete what's not needed (i.e. make clean), empty the trash, and then use hdiutil(1) to do the job (hint: compact).

When you compile OSG version 2.0 from source on OS X, your OSG apps won't be able to find the OSG plugins unless you intervene. The problem is that on OS X OSG looks in {~,}/Library/Application Support/OpenSceneGraph/Plugins/{,osgPlugins-2.0.0} for the plugins, but make install installs them to /usr/local/lib/osgPlugins-2.0.0. You can intervene either by creating the appropriate symlink or by setting the environment variable OSG_LIBRARY_PATH appropriately. Note that if you install the binary package on the website (which puts them in /Library/...) it would find the wrong plugins even if you had a symlink in ~/Library/..., so OSG_LIBRARY_PATH might be a cleaner solution. Or just don't have both the binary and hand-compiled versions installed at the same time.

Good news! FlightGear version 0.3.11-pre1 builds perfectly well on OS X (Tiger). The dependencies are plib and SimGear. You should install plib via macports (the 1.8.4 upstream tarball fails to build, CVS might fare better), then compile and install SImGear version 0.3.11-pre1, then compile and install FlightGear and grab the fgfs-base package and move it to /usr/local/share/FlightGear.

MacFlightGear works too, version 0.9.10. It will probably have an 0.9.11 release sometime not long after the release of 0.9.11 (if not sooner), because it would be hard to justify not releasing it when FlightGear builds out of the box. You might like the one-download no-build nifty-gui-launcher aspects of MacFlightGear. I don't because it messes with .fgfsrc and I like the consistency with Linux. But we never said I was sane.

Imagine my suprise when a PDF created by Quartz (from the application Pages), turned out to be corrupt. It worked ok with Quartz apps, but not with more strict PDF apps like acrobat and various special-purpose PDF tools. ps2pdf give a nice summary of what's wrong:

$ ps2pdf mv.pdf 
   **** Warning:  File has an invalid xref entry:  28.  Rebuilding xref table.

   **** This file had errors that were repaired or ignored.
   **** The file was produced by: 
   **** >>>> Mac OS X 10.4.9 Quartz PDFContext <<<<
   **** Please notify the author of the software that produced this
   **** file that it does not conform to Adobe's published PDF
   **** specification.

I found a neat program called pdftk - the PDF toolkit. It is able to repair such PDFs. From its manpage:

Repair a PDF's corrupted XREF table and stream lengths, if possible:
pdftk broken.pdf output fixed.pdf

Et voilá! Worked like a charm. pdftk has a bunch of other neat tricks up its sleeve, like concatenating PDFs, etc., and it's Free software and cross-platform. Worth a look.

JACK is a low-latency audio server, written for POSIX conformant operating systems such as GNU/Linux and Apple's OS X.

If you're doing serious audio work, JACK is a beautiful thing indeed. I had a problem getting it going on the MacBook. I didn't have any trouble with it on the iBook, so either JACK changed, or a recent OS X update changed things, or just the fact that the MacBook has both a line in and a microphone canged things.

This is the error I was getting:

$ jackd -d coreaudio
jackd 0.102.20
Copyright 2001-2005 Paul Davis and others.
jackd comes with ABSOLUTELY NO WARRANTY
This is free software, and you are welcome to redistribute it
under certain conditions; see the file COPYING for details

JACK compiled with POSIX SHM support.
loading driver ..
Default input and output devices are not the same !!
Cannot open default device
Cannot open the coreaudio driver
cannot load driver module coreaudio
no message buffer overruns

You can see the thread on LAU for more details, but the short answer is you need to create an aggregate device in the Audio MIDI Setup panel. Open it up and go to the Audio Devices tab. Then go to the Audio menu and choose Open Aggregate Device Editor. Add ye an aggregate device with all the inputs/outputs, and JACK will just work. Not only that, but it will have access to all the available inputs and outputs.

I'm more than pleased to point my fellow OS X users in the direction of PDFView. It fixes all the annoying issues with Preview, i.e. stupid initial sizing, lack of auto-update, and the annoying 'onscreen display' for Beamer presentations. Thanks to bsag for the tip.

I was less than fair in my previous assessment of the MacBook's ability to run FlightGear. It is capable of running it at passable speeds if you disable some things. I went through the output of fgfs -h -v and disabled everything that could be disabled (almost) and I get about 20fps when I'm not looking at the KSFO terminal or something equally busy. Even then it's 14 or 15. That's flyable. Using the 2D cockpit (or no cockpit and just the HUD) will buy you a couple of frames per second. But so will using a less-complex 3D cockpit, e.g. the Piper Cherokee Warrior II or the Northrop T-38. Flying during the day will buy you a lot (something about airport lights). One nice thing is that you get basically the same frame rate with the window maximized (or full-screen) as at 640x480. It's not pixel-bound, in other words. Most of the checkboxes in View|Rendering Options make no noticeable difference, except shadows, and I don't know about the lighting options since any nighttime flying with airport lights is too slow to bother.

So here's the ~/.fgfsrc that gets me 23fps average in the air away from the airport in the Piper Cherokee Warrior II.

--disable-random-objects
#--enable-ai-models
--fog-fastest
#--disable-enhanced-lighting
#--disable-distance-attenuation
#--disable-specular-highlight
#--disable-anti-alias-hud
#--disable-hud-3d
#--disable-clouds3d
#--enable-fullscreen
--shading-flat
#--disable-skyblend
#--disable-textures
--aircraft=pa28-161

One of these days I'll see which of the three remaining I can trim also, but it looks good enough for now.