A Brief Foray Into Windows

I just had a rare occasion to use a Windows XP machine here in the lab. Oy, was it painful! All I wanted to do was take three simple screen shots — just three — for an instructional article I was writing for our community. It took a half an hour.

I started, of course, by logging in to a Windows box. That went fairly smoothly. Type my name and password, and, sure enough, I get in. So I open a new window by going to the Start menu and clicking "My Computer," although it's not my computer. It's anything but. Still, "My Computer" gets the new window open. I take my first screen shot by hitting the "Print Screen" key. Yes, Windows has a dedicated screen capture key called "Print Screen." Hit it and it sends the entire screen to the clipboard. Not to a file, mind you. To the clipboard. Next you'll need to open up some kind of image editor. I chose the venerable Photoshop CS3. Opened the app, created a new document, and hit control-v to paste my screen grab in. Good (if a bit of a pain in the ass) so far. Next I made some settings in my open window, and made another screen grab. And once more for good measure.

In Photoshop I decided that it would be best to save my files to my centrally-located network home account, so I hit the save button and navigated there, named the file, and... The Save dialog crashed. After waiting about five minutes I decided that the only thing to do was to force quit Photoshop, which I did, losing all my screen grabs and necessitating beginning the entire process anew.

Windows XP: Definitely Not My Computer (click image for larger view)

The next time around I saved each of my screen captures locally as I went, and that seemed to go okay. Next I just wanted to copy these documents to my network account so I could access them from my office Mac, but the copy failed, producing a meaningless error message. Looking through my files, however, it was clear what the problem was. Apparently, during the crash Photoshop had spewed about three thousand temp files all over my home account, and these needed to be deleted before Windows would copy anything over.

So, I began the process of deleting these three thousand or so files by selecting about six hundred of them and hitting the delete key. I kind of like that Windows' delete key actually deletes stuff. That's a nice touch. What I didn't like was that deleting 600 zero byte files was going to take four minutes. But what was I to do? I went ahead with the file deletion. Four minutes of sitting and watching that miserable, 8-bit trash deletion progress bar — you know, the one where the trash files fly through the air and dissipate in a big pink sparkle — is enough to turn just about anyone's brain to mush. Which is probably why, after it was all over I went ahead and switched to list view (though there seems to be no way to make this setting stick across windows) and selected the remaining 2400-or-so files, right-clicked and hit delete.

Eleven minutes?! Argh!

With some time to kill I decided to log in to an adjacent Mac. Once logged in the Windows brain-fog cleared and it dawned on me: I could just delete the files from the Mac! And it won't take eleven frickin' minutes!

And by golly, that's just what I did.

Eleven seconds later I was able to copy up my files from Windows to my network account and get on with my life.

When I think of how easy all that would have been on a Mac I'm appalled. Absolutely appalled. Windows is ugly, flimsy and crash-prone by comparison. And the user experience is dead-awful. It's no wonder I avoid it like the plague.

God help the Windows Admins! You have my pity.

Time Machine After Logout

I've been using Time Machine for a while now. And I've noticed some interesting things about its behavior. Of particular note, I've noticed that Time Machine does not back up your data when you are logged out. I found this strange until I figured out why this is the case.

I first noticed Time Machine not backing up logged-out users after setting up the staff computers here at work. Oddly, my work computer did back up when I was logged out, which I realized when I noticed a backup failure due lack of drive space. According to the Console logs this backup attempt had occurred in the middle of the night. Clearly Time Machine was able to backup when users were logged out, but it would only do so on my machine. So what was the difference?

By default, Mac OS X wisely un-mounts external volumes when a user logs out. This makes sense for a number of reasons, not the least of which is the fact that it's what users expect, and it's the least likely to break something if a user logs out and pulls their firewire plug without ejecting their disk. It's a very sane default that errs on the side of data protection. But it's not always what you want. For instance, say you have network shares, like external RAID drives, that are connected via firewire (which, in fact, we do). Or say your network backups that run in the middle of night get stored on a firewire volume (which ours do). If you want these drives constantly available you need to be able to keep them mounted even when no user is logged in. Fortunately, Apple provides a method for doing this, though it's by no means obvious.

The trick to keeping external drives mounted after a logout lies in a little .plist file. The name of this file is autodiskmount.plist, and it does not exist by default; you have to make it. In the file should be the following text:

<?xml version="1.0" encoding="UTF-8"?>

<!DOCTYPE plist PUBLIC "-//Apple Computer//DTD PLIST 1.0//EN" "http://www.apple.com/DTDs/PropertyList-1.0.dtd">

<plist version="1.0">

<dict>

<key>AutomountDisksWithoutUserLogin</key>

<true/>

</dict>

</plist>

Put this file in:

/Library/Preferences/SystemConfiguration/

And reboot. (Yes, reboot.)

Now all external drives (firewire, USB, eSATA, etc.) will stay mounted after a logout. If they're shared, they'll always be available. And they'll always be available to Time Machine.

So the difference between the staff machines and mine? My computer is set to never unmount drives at logout. Apparently, Time Machine is perfectly capable of running even when no one is logged in. But it obviously needs the Time Machine drive available to do so. Keeping firewire drives mounted post-logout will allow Time Machine to work all night long. Sweet!

And since I'm so crazy with the Installer Packages these days, I'm including one here that will install the necessary preference file to make all this happen. You know, just to make your lives a little easier.

Download KeepExternalDisksMounted

You're welcome!

UPDATE 1: A reader asked in the comments how I came to have the preference file installed on my system. I'd put it there long ago because I needed firewire drives mounted for rsync backups of staff machines. But I certainly didn't figure out how to create that file myself. Credit for that goes to this Mac OS X Hints hint. It's got all the details if you're interested.

UPDATE 2: One other thing I forgot to mention: Why is this useful? I mean, if you're logged out you're not really capable of creating any new data, so there's nothing really new to backup anyway, right? This is mostly true, indeed. But imagine your boss uses Time Machine for his hourly backups. Now imagine he creates a whole buttload of data — I don't know, emails to the CEO, photos of his kids, whatever — and he creates this data right before he leaves for the day. Then, safe in the knowledge that Time Machine's got his back, he logs out and goes home for the weekend. That weekend there's a power surge or something, and his machine is fried. "No problem," he thinks, "I have my backup." But his most recent data is gone. His photos, his draft to the CEO, gone. And guess who's to blame? Yup. The Systems Admin. Your ass is grass, and Time Machine is the lawn mower. (Uh, this is why I don't write in the mornings.)

Personally, I think it would be smart if Time Machine asked you at logout if you'd like to make a backup, or at least warned you that backups would not be performed after logout. This seems like a bit of an oversight on Apple's part.

The other time this can be useful is when you're creating your first backup. This is typically a lot of data. Here in the office we told folks to let it run overnight. But they couldn't log out. So we dropped them to the Login Window with Fast User Switching. Still, it would have been that much more intuitive if we'd just told them to log out like they always do, and that their backups would be ready in the morning.

So yeah, not earth-shattering, but still potentially useful. And interesting on an academic level to know that Time Machine will run sans login.

I have to go install that preference file on my staff machines now. Bye!

NetBoot Part 5

So far this NetBoot/NetInstall thing is working out a thousand times better than I ever thought it would. I wish I'd done this years ago. Not only does it save time, it also reduces errors. This is often one of the most overlooked features of automating a process: the less human interaction in the process, the fewer mistakes can be made. I have only to compare the set of instructions I gave to last year's crew for building a new system to the instructions for using the new NetInstall system to see evidence of this truism. The list of human actions to take — and, thus, potentially screw up — is significantly shorter using the new process. And that's a beautiful thing.

At this point I've converted about half the staff to Leopard with the NetInstall system, and for the most part it's been quick and painless for both me and them. Contrast with years past, where upgrading staff computers — which are both the most customized, and the most important to preserve the data of — has been fraught with tension and minor hiccups. This year I almost feel like I've forgotten something, it's been so easy. But staff would surely let me know if there were problems. (I'm so knocking wood right now.)

I've also had an opportunity to test building multiple machines simultaneously. Yesterday I built five Macs at the same time, and, amazingly, all five built in about the same time it takes to build one — about a half an hour. I'm astounded. We should be able to build our new lab workstations this summer in a day. And still have time for a long lunch. And for the most part I'll be able to offload that job to my assistants.

As I finish up the system, I've realized some things. First of all, it sort of reminds me of software development — or at least what I imagine software development to be like — because I'm building little tiny components that all add up to a big giant working whole. Also, as I write components, I find myself able to reuse them, or repurpose them for certain, specific scenarios. So, in a sense, the more I build, the easier the building becomes, as I imagine is true in software development. Organization is also key. I find myself with two repositories: one contains the "build versions" — all the resources needed to build the packages — and one contains the finished products — the packages themselves — organized into something resembling the physical organization (packages for staff computers in one area, packages for workstations in another, for instance). It's shockingly fascinating to work on something like this, something that's built from tiny building blocks and that relies very heavily on good organization. I'm really enjoying it so far, and I'm a little sad that the groundwork is built and it's nearly done. There's just something fundamentally satisfying about building a solid infrastructure. I guess that's just something I innately like about my job.

The next step in this process, as I've alluded, will be to do a major build, i.e. our new batch of workstations when they come in the summer, and an update of all our existing computers — all-in-all about 40 machines. Between now and then there are sure to be some updates, so I'll probably update my base config before we do the rest of the lab. And then will come the fun. I will report back with all the juicy details when that happens, in what will probably be the final installment of this series.

See you in summertime!

Firefox URL Bar for Mac Users

The fact that John Gruber is trying and writing about the latest Firefox betas — which, by the way, I am frickin' loving — is a testament to how good this release will be. Though he's not switching for a variety of reasons, his review is still quite complimentary.

Most of Gruber's Firefox complaints either don't bother me or don't affect me, but there is one that has always bugged the crap out of me: a single-click in the URL field of the browser highlights the entire URL. This is almost never what I want to do. If I want to highlight the entire URL, I'll just hit Command-L and be done with it. If I'm clicking in the URL field it's because I mean to edit that thing, and I want my click to place the cursor right where I clicked, damnit. Despite Firefox 3's attempt — and, I should mention, general success — to integrate better with your platform of choice, it gets it wrong here.

Fortunately, Gruber's posted a link to a dude who has the skinny on the fix. Here it is in my own words, if you don't feel like following the links:

• Type "about:config" in the URL field
• Filter by "clickSelectsAll"
• Change the "browser.urlbar.clickSelectsAll" to "true" (just double-click it)

Firefox 3 Beta 5: Fix the URL Bar
(click image for larger view)

From now on clicking in the URL bar in Firefox will behave as it does in Safari: single-click places the cursor; double-click highlights the word; triple-click highlights the whole URL.

Oh, sweet merciful heaven, that's good stuff.