Archive for the ‘Software’ Category

A set of scripts to unmount drives before sleeping

Sunday, February 11th, 2007

When I’m at home, my MacBook Pro is hooked up to an external display, a couple of hard drives, and other peripherals. When I need to go on the road, I put it to sleep, unplug all the peripherals, and away I go.

There’s only one problem: Unplugging a hard drive can corrupt its filesystem if it’s still mounted. To prevent that from happening, I wrote a script that automatically unmounts all drives. As an added bonus, the script fails if any of those drives are busy and can’t be unmounted, warning me to take additional action before hitting the road. Here it is:

tell application “Finder”
    eject (every disk whose ejectable is true)
end tell

In most cases, this simple script works great, but it suffers from a few drawbacks:

  1. It ejects not only hard drives, but optical discs as well, which is usually not what I want.
  2. It won’t eject remotely mounted drives, such as NFS or AFP mounts.
  3. It won’t work if Finder is not running, which may be the case for PathFinder users like myself.

To fix these issues, I split the script into two parts, one for local drives and one for remote drives, and I rewrote it so that optical discs would be left alone. Here’s the part that unmounts local drives:

-- Set this list to the names of the local drives
-- you want to unmount
set local_drives to [“Backup drive”, “Clone”]

repeat with drive in local_drives

   set drive to “/Volumes/” & drive
   set driveExists to false

   try — Ignore AppleScript warnings
      do shell script “test -d ” & ¬
            quoted form of drive

      — Test completed successfully; drive exists
      set driveExists to true
   end try

   if driveExists then
      — Eject the drive
      do shell script “umount ” & ¬
            quoted form of drive
   end if

end repeat

And here’s the part that unmounts the remote drives:

-- Set this list to the names of the remote drives
-- you want to unmount
set remote_drives to [“DreamHost”, “DOC”]

repeat with drive in remote_drives

   set drive to “/Volumes/” & drive
   do shell script “umount ” & ¬
         quoted form of drive

end repeat

I don’t eject optical drives, but if for some reason you need to do so, here’s how:

-- This will eject the optical disc in the
-- primary (built-in) drive
do shell script “drutil -drive 1 eject”

-- This will eject all discs in all optical drives
do shell script “drutil eject”

For a downloadable version of these scripts, see my AppleScript page.

How to use Saxon with Ant

Monday, January 8th, 2007

As the only open-source processor that supports the XSLT 2.0 specification, Saxon is becoming indispensable. I use it in my HR-XSL project, and the new functions and features of XSLT 2.0 have helped make the code a lot simpler.

A typical way of running Saxon is via Ant, which offers built-in support for XSLT processors. Its Xslt task defaults to the Xalan processor, but because this task understands the TrAX API, switching to Saxon is trivial. All you need to do is put Saxon’s JAR on the classpath. (This works because Saxon declares support for the TransformerFactory service in its manifest. When TrAX finds a match for this service, it knows which processor to use.)

But there’s a problem here. Xalan also supports TrAX, so it specifies the TransformerFactory service, as well. Thus it becomes a contest. The first processor listed on the classpath wins!

Now, one would think this wouldn’t be an issue. Xslt’s classpath attribute trumps the system’s classpath, right? Unfortunately, that’s not how it works—as discussed in the Ant FAQ—and as a result, you get unpredictable behavior: Your Ant script may or may not use Saxon depending on whether Xalan happens to be in your system’s classpath. This can be a real problem if, for example, you’ve used Fink to install Ant, which places Xalan on the system classpath by default.

All right, so that’s bad. Is there an easy way to solve this dilemma? How about the <factory> element of the Xslt task? It specifies a particular transformer factory to use, rather than letting TrAX instantiate the first one it happens to find. With this element, you should easily be able to force Ant to use Saxon, like this:

<xslt ...>
    <classpath location=“/path/to/saxon.jar”/>
    <factory name=“net.sf.saxon.TransformerFactoryImpl”/>
</xslt>

Alas, this also fails to work. For some reason, Ant always throws a ClassNotFoundException when you try to use the <factory> element this way. (See bug #41314 for more details.)

This was starting to hurt. I didn’t want my HR-XSL users submitting bug reports just because Ant couldn’t find Saxon. I needed a way to ensure that Saxon would run every time.

After following a number of dead ends, I finally found a solution. The trick is to set the Java property javax.xml.transform.TransformerFactory to Saxon’s transformer factory class. The TrAX implementation in Ant happens to look for this property and, if set, it will use the specified class rather than whatever it discovers on the classpath.

The hard part, surprisingly, is how to set the property. Ant provides no mechanism for changing Java’s system properties, so I rely instead on a custom Java class that extends and replaces Ant’s default TrAX handler. Just before a transformation occurs, it sets the transform factory property to net.sf.saxon.TransformerFactoryImpl, forcing Saxon to be used, then it restores the previous setting when the transformation is complete. (Restoring the property prevents conflicts with other XSLT-related Ant tasks, such as FOP.)

Once this class has been compiled, you tell Ant to use it via the processor attribute. For example, if the custom class is called SaxonLiaison (to reflect the class that it overrides, TraXLiaison), you’d call the Xslt task like this:

<xslt ... processor=“SaxonLiaison”>
    <classpath location=“/path/to/saxon.jar:/path/to/SaxonLiaison”/>
</xslt>

That’s it! Saxon will be used every time, regardless of what’s on the system classpath.

You can find a complete listing of my SaxonLiaison custom class in the util directory of the HR-XSL distribution.

Bunnies!

Thursday, November 30th, 2006

Apparently the developers at 1 Infinite Loop like to keep their code cheerful. An example posted to the Apple Developer Connection uses bunnies—yes, cute little bunnies—to demonstrate the power of frame buffer objects in OpenGL.

If you have a Mac, go ahead and download the example. Run it, then hit the Spacebar. You’ll see some very trippy effects that remind me of Dumbo’s pink elephant hallucination.

Bunnies

The frame buffer object, in case you were wondering, is a relatively new feature in OpenGL. It provides hardware-accelerated offscreen rendering of a texture. FBOs improve upon the older pixel buffer (PBuffer) technique, which was basically the same but required an evil context switch that hindered performance.

From Russia with Love

Saturday, November 18th, 2006

Back in July, Link TV aired one of the most fascinating documentaries I’ve seen in recent years. It was the story of fiendish addiction, intimidation, and high-stakes legal feuds set against the backdrop of Cold War tensions. And the cause of this real-life drama? A video game.

The BBC documentary, Tetris: From Russia with Love, chronicled how a simple, black-and-white, silent computer game started out as a prisoner behind the Iron Curtain, then suddenly escaped and went on to become one of the most popular titles of all time. Well-written and artfully photographed, the first half of the show focused on the birth of Tetris, explaining how Alexey Pazhitnov came up with the original idea and programmed it on his Electronika 60 (a Russian clone of the PDP-11) while working for the Soviet Academy of Sciences in Moscow.

The second half of the show was arguably more exciting, but it focused on the business aspects—contract disputes with the Kremlin, million-dollar royalties, that sort of thing—and ironically, that’s when I got a little bored. I was much more interested in the video clips of “ancient” computer systems. For instance, check out how big the floppy disks were back in the early 1980s:

Floppy disk of the 80s

Still, the documentary is well worth watching, especially if you played Tetris as a kid or have any interest in video game history. If it ever comes back on the air, I highly recommend tuning in.

The myth of the Gutmann method

Monday, September 18th, 2006

Most people know that when you sell or give away a computer, you should format its hard drive to make sure your sensitive information doesn’t fall into the wrong hands. And most of those people know that formatting a drive doesn’t actually erase all the data. Instead, you should use a special utility that overwrites every block of data on the drive. And a smaller portion of those people know that overwriting a block just once isn’t enough. If you really want to be safe, you should apply the Gutmann method, which overwrites every data block 35 times. And an even smaller portion of those people know that the Gutmann method is a myth.

I had always thought that the idea of overwriting the same data block 35 times was a bit dubious. (Why would 35 times be secure but 34 times not be?) And yet, most disk utilities provide an option to erase a hard drive 35 times over.

Disk Utility erase options

In a recent Slashdot article, I discovered a comment that shed some light on this issue. User Psionicist wrote (with typos faithfully reproduced):

I would like to take the oppertunity here to debunk a very common myth regarding hard drive erasure.

You DO NOT have to overwrite a file 35 times to be “safe”. This number originates from a misunderstanding of a paper about secure file erasure, written by Gutmann.

The 35 patterns/passes in the table in the paper are for all different hard disk encodings used in the 90:s. A single drive only use one type of encoding, so the extra passes for another encoding has no effect at all. The 35 passes are maybe useful for drives where the encoding is unknown though.

For new 2000-era drives, simply overwriting with random bytes is sufficient.

Here’s an epilogue by Gutmann for the original paper:

Epilogue In the time since this paper was published, some people have treated the 35-pass overwrite technique described in it more as a kind of voodoo incantation to banish evil spirits than the result of a technical analysis of drive encoding techniques. As a result, they advocate applying the voodoo to PRML and EPRML drives even though it will have no more effect than a simple scrubbing with random data. In fact performing the full 35-pass overwrite is pointless for any drive since it targets a blend of scenarios involving all types of (normally-used) encoding technology, which covers everything back to 30+-year-old MFM methods (if you don’t understand that statement, re-read the paper). If you’re using a drive which uses encoding technology X, you only need to perform the passes specific to X, and you never need to perform all 35 passes. For any modern PRML/EPRML drive, a few passes of random scrubbing is the best you can do. As the paper says, “A good scrubbing with random data will do about as well as can be expected”. This was true in 1996, and is still true now.

Looking at this from the other point of view, with the ever-increasing data density on disk platters and a corresponding reduction in feature size and use of exotic techniques to record data on the medium, it’s unlikely that anything can be recovered from any recent drive except perhaps one or two levels via basic error-cancelling techniques. In particular the the drives in use at the time that this paper was originally written have mostly fallen out of use, so the methods that applied specifically to the older, lower-density technology don’t apply any more. Conversely, with modern high-density drives, even if you’ve got 10KB of sensitive data on a drive and can’t erase it with 100% certainty, the chances of an adversary being able to find the erased traces of that 10KB in 80GB of other erased traces are close to zero.

So it seems my suspicions have been confirmed: You do not need to erase a hard drive 35 times before selling it on eBay. A quick zeroing out of the data is sufficient.

A comeback game in Warcraft III

Wednesday, August 23rd, 2006

This summer I’ve gotten into the habit of playing Warcraft III online. Unlike certain other online games that are all the rage these days, WC3 isn’t a timesink. Games only last about twenty minutes on average, and they’re self-contained, so you don’t feel like you have to keep playing to build up your character’s experience points or inventory or whatever.

My favorite format is the three-on-three pick-up game, in which the server selects six random people and forms them into two ad hoc teams. One such game was a bit more interesting than most, so I saved it as a replay. (You can play it back if you happen to own a copy of Warcraft III.) Here’s a play-by-play:

11:30 The opposing team masses an army of Level 2 units and rushes Orange.
14:15 Orange’s base is toast, and Teal delcares his team the winner. Orange gives up and leaves the game. It’s over! …or is it?

Orange faces destruction
Orange faces destruction.

17:00 The opposing team now sets their sights on me. Purple advises that I retreat to his base, so I teleport there.
18:00 As my base is being destroyed, Purple and I counter-attack Red.
20:00 Caught off-guard, the opposing team tries to defend Red, but it’s too late. Red is annhilated, leaving Green and Teal. Armed only with Purple’s base and my five Chimeras, is victory possible?
20:30 I send my Chimeras for an end run around the back of Green’s base. He has no AA, so the Chims destroy his base easily. Only Teal remains!
22:30 My Chimeras make another end run, this time to the back of Teal’s base, destroying his gold mine.
27:00 Teal and Green attack us in a last-ditch effort, sending everything they’ve got. It’s a battle for the center!

Battle for the center
It’s a battle for the center!

27:30 The opposing team’s Level 2 units are no match for our Level 3 Chimeras and Tauren! Green and Red give up.
28:00 Teal, deprived of gold by my Chimeras, has no units and admits defeat.
28:18 Victory! What a comeback!

Another reason why I don’t use Windows

Thursday, August 17th, 2006

My colleagues and I were finally able to publish our Autonet research at a conference in Chicago. Being the lead author, I hopped on a flight to the Windy City last Tuesday to present the results of our work. When I arrived at the hotel, I met the other two speakers scheduled for the afternoon session. The first one was busy setting up his Dell at the podium while the audience slowly began to fill the room. The second speaker had no laptop, only a USB drive with his slides; he was hoping to borrow the first speaker’s Dell.

We were about two minutes away from showtime when the projection screen suddenly froze. Here’s what everyone in the audience saw:

Blue screen of death

It turned out that the guy’s Dell was crashing whenever he tried to start his PowerPoint presentation. Rebooting didn’t help. Windows insisted on giving him the Blue Screen of Death.

By this time, we were now late. Frustrated, the two speakers saw me typing on my Mac and asked if I could help. I walked up to the podium, plugged my Mac into the projector, loaded both of their presentations into Keynote, and returned to my seat. The first speaker then began his presentation using my PowerBook. Then the second speaker. Then me.

No BSoD. No crashing. It just worked. My Mac saved the day!

Hmm, that reminds me of an ad…

Restart ad

Nisley’s Notebook

Saturday, August 12th, 2006

I’m a regular reader of Dr. Dobb’s Journal, a monthly magazine covering the world of software development. One of my favorite columns in Dr. Dobb’s is “Nisley’s Notebook” because it mainly deals with my favorite topic: embedded systems. You can imagine my surprise, then, when I reached the end of the July 2006 column and saw my name:

Speaking of Windows ME, alert reader Trevor Harmon reminds me that it still allowed direct, user-mode I/O port control. Read more on FAT and the Microsoft patents at en.wikipedia.org/wiki/File_Allocation_Table.

I read that paragraph several times, thinking there must be some other Trevor Harmon who reads Dr. Dobb’s and had written to Ed Nisley. Then I suddenly remembered: I had, in fact, emailed Ed some time ago about his April 2006 column. Here’s how it went down:

In your April article in Dr. Dobb’s Journal called “Tight Code,” you state:

“The notion of a user program directly controlling an I/O port pretty much died with Windows 98.”

Why Windows 98? I thought it was architecturally almost identical to Windows 95. Was there some significant difference in the Windows API that I’m not aware of? In any case, I thought direct control of an I/O port died much earlier, way back in the 1970s with the advent of UNIX and its abstraction of I/O hardware as a /dev file.

Thank you,

Trevor

To which Ed replied:

Direct I/O control died -with- Win98: that was the last Windows flavor allowing that sort of thing. WinME sorta-kinda did, too, but MS was revamping the driver model and (IIRC) discouraged using the Olde Versions.

Or maybe I just have a picket-fence error…

Indeed, the various Unix-oid systems did bring protected hardware to the university level, but the vast bulk of Windows boxes pretty much overshadowed all that. As far as the mass market goes, programmers were doing direct I/O from DOS right up through Win98 (or ME?), at which point everything they thought they knew went wrong.

Ed

I responded:

Ah, I read that as “was killed by Win98”, as if Microsoft had developed some revolutionary product that nullified anyone’s desire for direct hardware access.

Yes, I believe ME, not 98, was actually the last Windows version to support direct hardware access. That’s one of the main reasons I was confused: It was the NT kernel, not Win98, that changed things in the Microsoft world.

Also, you used the word “notion,” and I would say that the notion died long before Windows ME even existed. Nobody (except maybe for game developers) supported the notion of direct hardware access, even though it continued to exist in legacy operating systems like Windows 9x. So I was doubly confused.

Trevor

And Ed concluded with:

Part of the job here is to write so that sort of thing doesn’t happen… I’ll drop a correction in the bitstream for the next column.

Thanks for keeping me straight!

Ed

So, this other “Trevor Harmon” mentioned in the column was me after all! I had completely forgotten about my conversation with Ed. Although I’ve published in Dr. Dobb’s before, it was still fun to see my name in print, especially in such an unexpected way.

Possible fix for Mac apps that immediately quit

Saturday, July 29th, 2006

Out of the blue, iMovie decided to stop working for me. I’d launch it, and it would immediately quit. Not crashing, just quitting. (No crash log was generated.) The dock icon wouldn’t even appear.

I knew it wasn’t a problem with the iMovie application itself because when I switched to another user account on the same machine, iMovie ran fine. It had to be something in my home directory that was causing the problem.

Normally, simply getting rid of any preferences or caches fixes this sort of problem. I checked my account and found these:

  • ~/Library/iMovie/
  • ~/Library/Caches/iMovie HD/
  • ~/Library/Preferences/com.apple.iMovie.plist
  • ~/Library/Preferences/com.apple.iMovie3.plist

Unfortunately, moving them out of my Library directory didn’t change a thing. iMovie was still quitting on launch. Frustrated, I took my PowerBook to the local Apple Store for some advice, but even the “genius” at the bar wasn’t able to help. I returned home thinking that I’d have to reinstall Mac OS X before iMovie would ever work again.

I decided to give iMovie one last try. On a whim, I dragged its icon out of the Applications folder and into my Desktop, then launched it from there. Imagine my shock when iMovie started up! I quit, moved the icon back to Applications, and launched iMovie again. It still worked! Everything was back to normal.

iMovie

I have no idea why dragging iMovie out of the Applications folder solved the problem. In fact, it shouldn’t have worked. But it did. Assuming this is not some obscure and one-in-a-zillion issue, it may affect other Mac apps, not just iMovie, so I’m posting this tip in the hope that it might help others who encounter the same problem I did.

How to extract GPS coordinates from TomTom Navigator 5

Wednesday, July 19th, 2006

TomTom Navigator 5 is a marvelous piece of software that can turn a PDA into a GPS navigation system. At $180, it’s somewhat expensive, but if you already have a PDA and get a cheap GPS receiver, you can end up saving hundreds of dollars over traditional stand-alone navigators.

For a few months now, I’ve been using it with my Treo 650, which means in addition to making calls, tracking finances, playing games, and surfing the web, my little smartphone keeps me from getting lost, too! I no longer have to ask for directions or look them up on the Internet; I just hop in the car, give Navigator an address, and it tells me exactly where to turn.

One of the more useful features in Navigator is that when you arrive at an interesting location, you can save your current GPS coordinates as a “Favorite.” You can then return to your Favorite at a later date without having to give Navigator an address. This feature is especially useful for remote locations that might not have an actual street address to begin with.

For instance, on a trip to South Dakota last week, my wife and I stayed at my parents’ cabin, which happens to be pretty deep in the woods, so I marked its location in Navigator as a Favorite. It wasn’t that I was worried about finding my way back; instead, I wanted to remember the coordinates of the cabin so that I could easily look them up in Google Earth when I returned home.

When I got back, I discovered that extracting those GPS coordinates was anything but easy. The Navigator 5 software won’t display the coordinates of a Favorite, and it doesn’t offer any documented way of uploading a Favorite to a computer. That meant I had to find an undocumented way.

After scouring numerous discussion boards and various websites, I finally cobbled together enough information on how to extract the GPS coordinates of a Favorite from TomTom Navigator 5. To save others from the trouble I went through, I’m posting a step-by-step guide below.

  1. Convert the Favorite into a Point of Interest (POI).
    1. Go to Change Preferences, then Manage POI, and choose Add POI Category.
    2. Type a name for the new Favorites category. (“Favorites” sounds like a good choice.)
    3. Choose a marker.
    4. Choose Add POI, then select the Favorites category.
    5. Choose Favorite and select the Favorite you want to convert to a POI.

    Manage POI

  2. Transfer the POI file to your computer. The easiest way to do this is with the FileZ utility.
    1. Launch FileZ, then view the contents of the external card.
    2. There should be a directory there called region-Map, where region is the map you are currently using (e.g., “Plains”).
    3. Open that directory by tapping on the little triangle.
    4. Look for a file ending with “OV2” and having the same name as the POI category you created in the previous step (e.g., “Favorites.ov2”).
    5. Transfer this file to your computer. The easiest way to do this is to tap the file to select it, then tap the Send button and choose the Bluetooth option. This will shoot the file through the air onto your computer (assuming, of course, that your computer supports Bluetooth, as all good computers do). If not, you can choose the VersaMail option to email yourself the file, or use any other means at your disposal.

    FileZ

  3. Extract the contents of the POI file. The next step is to convert the OV2 file from its original binary form into something that mere mortals can read. The easiest way to do this is at the GPS Visualizer website, which provides a convenient front-end for the GPSBabel software.
    1. Go to the GPSBabel section of the GPS Visualizer website.
    2. For the input file format, choose “TomTom POI file”.
    3. For the output file format, choose “Textual Output”.
    4. Select the file (e.g., Favorites.ov2) that you transferred to your computer in the previous step.
    5. Click the “Convert the file” button.

    GPS Visualizer

That’s it! You should now see a list of your Favorites. The first column is the name of the Favorite; the second and third columns are its longitude and latitude. (The fourth column in parentheses is the location in UTM coordinates.) For example:

Cabin   N44 58.663   W103 35.017   (12T 617600 4890373)

Now that you know the coordinates of your Favorite, you can use them any way you wish. For instance, you can copy and paste them directly into Google Earth’s search box, and it will immediately fly you there.

Google Earth