I’ve been watching a lot of NASA TV lately (always do when the Shuttle visits the ISS, although probably more this time than previously).
One thing I’ve noticed a lot more this trip than any other: lots of stupid issues with Microsoft Windoze software. Problems getting email, problems getting printers to print, etc.
Now, I’ve seen lots of Macs in use at NASA. You can see them in Mission Control on NASA TV. You can see them in photos of the various labs all over the country.
Why aren’t they using Macs in orbit? I know Macs have their share of problems, too, but seriously. Email, word documents, printing…this kind of stuff works much, much better on a Mac than it does on Windows (if you don’t think so, you’re a fucking moron and should be sterilized to keep you from reproducing). Plus, you get the benefits of a virus-free OS. I know if I were in space, that’s what I’d want.

Feh. Time Machine sucks. After a painful setup process, I left Time Machine to do its thing. I just saw it mount a disk image that it created on the remote volume, so I know that all the speculation about enhancements to AFP (and possibly HFS+) are bunk. If it’s going to create disk images, it could do the same thing on any kind of file server. There’s no excuse for the AEBS not working.
That, I’m sick, and it’s pretty clear Cal’s going to lose to ASU. Fuck, what a shitty weekend.
Update: Feh. Time Machine does not estimate time remaining nor current data rate. I seem to be getting about 28.92 GB/h (over wired gigabit Ethernet).
Update: Time Machine really consumes CPU cycles. When the MBP is idle, the fans are not audible. Since Time Machine has been backing up, they've been continuously audible. The average data transfer rate has dropped to 16.9 GB/h. I have spent a few minutes of the last two hours watching streaming video, and doing a little bit of other work, but mostly it has been running undisturbed. mdimport is also running, not sure why.
Update: The combination of Time Machine and Leopard on the client and server make for some seriously fast network volume mounting! Whereas SuperDuper! takes ages to mount a network volume served by a Buffalo GigaStation NAS (first the volume, then the disk image on that volume, a process that takes several minutes), Time Machine and Leopard get the disk image mounted in seconds. After clicking on the Time Machine icon in the Dock, most of the time spent waiting for time machine to actually engage (with a tip of the hat to Picard) is waiting on the server’s drives to wake up.
I have yet to see how well the whole system does when I sleep the MBP, go to another network, and wake it up again. Maybe I’ll try that this afternoon. For sure I’ll try it when I go to work tomorrow.
One other note: When engaging Time Machine, the network volume does not mount; only the disk image mounts. Not sure how they pull that off, but maybe that’s one of the enhancements to AFP in Leopard. Hardware Growler reports both the server volume and the disk image mounting; just the network volume is hidden from the desktop (even though I have configured things to show mounted volumes).
When Time Machine begins an automatic backup, it does not display the floating progress window. Opening the System Preferencs panel shows a progress bar, though.
Update: Time Machine doesn’t deal well with lost servers. I engaged Time Machine, let it mount the backup volume (disk image), closed the lid on the MBP (it took a minute or more to sleep, but this is not new behavior in Leopard for me), and went to a breakfast place with free WiFi. There, I opened the MBP, saw the Time Machine screen still up, waited for Hardware Growler to indicate that the system had self-assigned an IP address, and then started moving through time. After a bit of back-and-forth, Time Machine appeared to hang (although the starry background animation continued). After several minutes (5 - 10), I decided to force-quit Time Machine. Pressing Command-Option-Escape had no effect, and after pressing it several times, Time Machine suddenly disengaged and there was a server-disconnect dialog on the screen.
Also, during the time that Time Machine was up, a dialog was presented asking if I wanted to join one of a couple of networks, including the free one at at the breakfast place. However, I was unable to click on any of the networks to select them, and hence, was unable to join a network (the window could move, and the “Other…” and “Cancel” buttons worked fine). Feh. Feh.

First, the good news. It’s not new news, but it’s still good. Leopard shipped with a read-only implementation of ZFS. To get a beta version of a full read/write ZFS, you need to have an Apple Developer Connection account (the free Online membership is enough). Look in the “Mac OS X” section of the downloads area. I’m using v1.1.
Now, the bad news: you can’t use ZFS storage pools as your Time Machine Backup drive. Sigh. I’m not surprised, but I had hoped. Eventually, it makes sense for Apple to move to ZFS as the default file system, but who knows how long that will take? For the time being, HFS+ (Mac OS Extended) file systems store meta data about files that other file systems can’t handle natively. I suspect this is true of ZFS, too. You can hack your way around these limitations, by simply creating additional files on the system and storing the meta data in there, but that’s ugly. My hope is that Apple will enhance ZFS to support HFS+’s metadata natively, and that will be that.
Time Machine has other limitations, too. I’m not too upset that I can’t yet use ZFS for my backups (so long as Apple fixes this in the next six months or so), but I am upset that I can’t use the AirPort Extreme Base Station as a backup file server. It was said, in the months leading up to the release of Leopard, that Time Machine could back up to the AEBS. In fact, it’s the reason I bought the AEBS: I couldn’t be sure that a non-Apple file server would properly support AFP, and I had it on good authority (Apple) that the AEBS would do the trick.
I can speculate as to why: other Mac backup solutions, like SuperDuper!, create a disk image on the target volume to work around limitations in AFP. Although I’m not certain of the precise limitations, they have to do with file ownership and permissions (for example, a user ID on one system is not necessarily the same as a user ID on another system). From what I understand, Apple has enhanced AFP in Leopard (and by one account, HFS+, or at least the filesystem API) to accommodate the needs of backup software.
So, at the last minute, Apple tells us that you can’t use an AEBS as a backup server, but you can use Personal File Sharing on another machine running 10.5. I have an older PowerBook sitting around, so I decided to buy a FireWire external drive and use that as my backup solution (for now).
I bought a Buffalo DriveStation Duo. I chose it because Fry’s had it (I could get it right now) and I was able to verify that it can operate in JBOD mode. I wanted to try using ZFS first, and if that didn’t work, the DriveStation supports mirroring.
I followed the directions in the Apple ZFS Readme’s Getting Started section. As described in the readme, it was necessary to repartition the drives to use the GUID Partition Table. I had a bit of difficulty with this. The volumes mounted when I first connected it, and I used the Finder to unmount them. I tried to make a ZFS pool before repartitioning, which ZFS did without complaint, and which subsequently caused a new volume to mount. I unmounted that, but attempts to repartition resulted in “resource busy” errors (the other drive repartitioned fine). Disconnecting the entire DriveStation and reconnecting it seemed to fix it.
I built a nice ZFS mirrored pool out of the two drives, shared it via Personal File Sharing, and mounted it on the other Mac. Time Machine refused to recognize it as an acceptable backup volume. I briefly considered making a disk image on the drive and trying that, but decided I disliked that solution enough that I didn't want to use it even if it worked.
Attempting to use the ZFS pool on the local machine also doesn’t work.
The next step was to reconfigure the DriveStation as a mirrored array, with an HFS+ volume format. I tried to do this with the RAIDSetting application from Buffalo, but it failed with complaints about the "The old volume lable [sic] is not valid. Delete volume label by using disk utility.” After half a dozen attempts to repartition the drives as PeeCee drives, I still can’t get RAIDSetting to function without complaint. The front of the DriveStation shows a green #2 and a yellow flashing #1.
Also note: the RAIDSetting app from Buffalo only works on PowerPC Macs. Basically, the Buffalo DriveStation Mac support is crap, and I would recommend strongly against using it (if you want to use their RAID support).
I finally decided to just play through the pain, and ignore the error. It seems to set the drive into the right mode, so we’ll see what happens.
As I write this, I’ve mounted the new, shared HFS+ Backup volume on my MacBook Pro, and Time Machine is “Preparing.” I’ll try to post an update if it works.

Well, I've had 10.5 installed for about 24 hours now, and so far, it’s not really worth the money. In day-to-day use (as a developer), none of the new features has yet to significantly impact my life. Sure, windows look a little different, and settings have been rearranged, but so far I don’t feel like I’ve gotten my money’s worth. For reference, I chose to “Upgrade” my system, rather than “Archive & Install.”
A few things are better. The variety of user interface styles has been reduced, and brushed metal is gone, replaced by a nicer-looking gradient (the Menu Bar looks a bit too much like a title bar, and I thought something was wrong with it until I realized it was transparent, and I was seeing the stars in the default desktop image through it).
Xcode has at least one improvement: it shows error messages in the editor window, directly underneath the offending line. It also complains a lot more about implicit conversions from double to float, but I can fix that.
One thing I’m not sure I like is that many standard icons have changed. Some have changed dramatically, like the System Preferences icon (it now looks like the iPhone’s Settings icon), and others have just been modified. These kinds of changes leave insecure users (like my parents) feeling disoriented, and I think they’re generally a bad idea.
One big fix: Apple Mail no longer seems to break long URIs! It has taken three or four major releases (an unacceptable delay to fix a minor, but very annoying, bug), but non-Mail clients can finally use long URIs sent by Mail without having to hand-edit them (Mail used to break them in a way that destroyed the URI for non-Mail clients).
Hardware Growler still works. My ARM development tool chain still seems to work. The Keyspan USA-19HS USB-to-serial adapter still seems to work. The FTDI USB-to-serial IC on the Sparkfun EM406 SiRF III Evaluation Board still works. ZTerm still works!
In the next post, I’ll talk about my experiences with Time Machine, the AirPort Extreme Base Station and ZFS.

A recent story about the U.K. possibly allowing cell phone use on airplanes quotes someone saying, "It would drive me absolutely mad if the person next to me was using his phone."
Now, some people speak more loudly when they're on the phone than when they're talking to someone next to them. Those people need to learn to quiet down.
Putting that aside, the only reason to be annoyed by a cell phone conversation is because you can't eavesdrop on the whole thing. You only get half of it. You know what? Tough shit. You're not a part of the conversation. Why don't you concentrate on your own business?
As far as the safety concerns with cell phones, I'm unconvinced. I'm both a pilot and an electrical engineer. I'd be surprised if a cell phone caused any real interference with flight-critical systems. Certainly everyone's heard the DSSS noise leak into amplified audio channels, and that could conceivably make its way into the pilots’ comm radios, but I doubt it would actually prevent communication. In any case, it should be generally allowed, and each pilot should decide on a case-by-case basis when to prohibit their use.
If ON Air's system really can allow cell phones to work without interference with aircraft systems, then by all means, allow it!
Don't forget, without special help, most cell phones won't work at typical flight altitudes.