APM Partition Boots Intel Macs

I'd thought that if you wanted to boot Intel Macs you needed to use the recently available GUID partition table, mainly because that's what it says in Disk Utility when you format the drive. In fact, as it turns out (at least as of Mac OS X 10.5.5), using the Apple Partition Map (APM) boots Intel Macs perfectly well. It's exceedingly useful to have a partition format that will boot both architectures, particularly at the museum, where Intel and PPC Macs still very much coexist.

Disk Utility Partition Styles: Lies!

In fact, my Mac is a G5, but all the new hardware is, of course, Intel-based. And I'm trying to create a master build image for setting up new machines. Generally the way I do this is by making a test build on a firewire partition. I can boot into this build and tweak it until it's perfect. And when it is, I image it to an ASR disk image for NetBooting. I was worried that architecture limitations would make this painful — that booting into my test build partition would be impossible on my PPC Mac because of these restrictions. Glad to know I can just use the old reliable APM for everything and it'll do what I need.

Not sure when or how they worked this out, or why the language in Disk Utility has gone unchanged. That fact does give me pause. But so far booting Intel Macs from APM partitions has worked perfectly for me on multiple machines.

UPDATE:

More info at Apple's Secrets of the GPT Tech Note, via Jeff in the comments.

Spotlight Sort Options

While Spotlight in Mac OS X 10.5 is greatly improved, there is one area in which it has regressed to an unusable state. Sort options in Leopard's Spotlight are limited to only three fields: Name, Kind and Last Opened. Uh... This is bad, guys...

Leopard's Spotlight Sort Options: Last Opened? Lame!

For most quickie finds I'll usually turn to the Spotlight menubar item. And this usually gets the job done. But every now and then I need to create a more complex search, and for that I'll typically turn to the "command-f" Finder method. Again, there are many useful advantages in Leopard over Tiger when it comes to this sort of search, most notably the nested search properties. These allow Spotlight in Leopard to create searches of Byzantine complexity. Astoundingly, the results will only be sortable by the aforementioned criteria. Need to look at your "Date Created" search by "Date Created?" Too bad. Guess you're shit out of luck.

Smart folders never looked so dumb.

This has been posted about The Internets for some time now, mentioned recently in this fine MacOSXHints post, and now listed as one of that site's author's most glaring problems in Leopard. I must admit, I haven't needed this functionality until recently — very late in Leopard's release — which is why I'm only noticing it now. But boy, when you do need it, it's shocking to discover this constraint in an otherwise greatly improved tool.

It kills me when a company takes one step forward and another back like this. I really hope Apple fixes this shortcoming sooner rather than later.

Leopard umask

This is one of those I-keep-forgetting-how-to-do-this posts, so I'm writing it down. It's certainly been posted elsewhere, but I'm tired of going looking every time I need it. So here it is. In Tiger a simple defaults command could be used to modify a user's umask (a setting that controls the default permissions for newly created files and folders). Leopard, however, changes the way this is done. Leopard instead uses a launchd configuration file. To create a custom umask for all users of a system (i.e. all user-level processes):

  1. Create a file called launchd-user.conf.
  2. Place the file in /etc/
  3. Enter the property, then the umask setting in the file, like so: umask 002
  4. Restart the machine.

The restart may not be necessary, but if I recall it was the only way I could get it to work. If you don't want to reboot, you'll at least need to restart launchd and any application or process you want to use the new setting. Rebooting, though, is a nice catch-all.

Some additional info: if you want virtually all applications (i.e. system-level processes) to use a custom umask, you can leave the "user" off the file name. Using /etc/launchd.conf will have said affect, but it is not recommended by Apple (or me for that matter).

Setting a custom umask in general isn't something I recommend either, but it's damn handy in certain file sharing environments in which multiple users need access to the same stuff, but where ACLs — the preferred method for setting up complex file sharing permission sets — aren't an option. Creating a common group for the users and setting up their umask to create files and folders that are group-writable is an acceptable workaround in many scenarios. Which, by the way, is what the above setting will do. A umask of 002 will create files with permissions of 775 (the opposite of 002 — it's a mask, silly).

Okay then. Happy umasking!

Faulty Arguments

I've been following the running commentary on Apple's decision to remove firewire from the MacBook. The latest article comes from Ars Technica, who responds to the "Steve Jobs" quote:

"Actually, all of the new HD camcorders of the past few years use USB 2."

The Ars writer chimes in, chastising people who want firewire by, essentially, telling them there's no demand. But see, what we're trying to tell you is that there is demand. We still want firewire at the consumer level. Making the argument that no one wants it won't really work on folks who do want it.

Ars and others are also equating this to Apple's ahead-of-the-pack decision to lose the floppy drive on the original iMac, when clearly this is different: Apple is now following the pack, not leading it, by Ars' own assessment:

"The truth is, FireWire—and in particular the FW400 variety—has been slowing [sic] disappearing for the last few years. Apple eliminated FireWire from iPods several years ago, since it allowed slimming down of iPods and made the nano and shuffle possible. Even external hard drives rarely have a FW400 port; FW800 and/or eSATA are the ports that are usually offered if there is anything other than USB 2. And, as Jobs says, most if not all of the consumer HD cams on the market now use USB 2."

Oddly, firewire's lack of ubiquity didn't stop Apple from supporting in the first place.

And finally, Ars backs up "Steve Jobs'" idiotic and patently false claim, stating:

"And, as Jobs says, most if not all of the consumer HD cams on the market now use USB 2."

Well, first off, that's not what Jobs said. He said "all," not "most, if not all." He said "HD camcorders" not "consumer HD camcorders." And he said "HD camcorders of the past few years," which is just wrong. In fact, the dominant consumer-level HD format for the past several years has been HDV, which is transferred over firewire. HDV cameras are still plentiful in the market, and will probably remain popular for at least another year or two. It's only been in the last year or two that AVCHD — an MPEG-4 variant with much lower bitrate requirements capable of transferring over USB — has gotten good enough to be taken seriously by anyone who knows anything about video.

Ars even makes the argument that editing video on a MacBook is no fun:

"I can also say from personal experience that trying to edit HD video on a MacBook is pretty much the worst experience ever, and I would never wish it on my worst enemy."

Fine, and I tend to agree. But the fact is, I know plenty of people who do want to continue editing video on a MacBook. They've been doing it for years, and are quite happy with it. This article seems to be addressed to people with no MacBook video experience. But those are the people who are complaining, the people who are currently doing video on their MacBooks. Telling them that they don't really want to be doing that, and if they do, to go buy a MacBook is condescending and insulting.

I'm generally a fan of the reporting that goes on at Ars. But this article has me incensed. It bothers me when big sites like Ars Technica try to tell people that their desires are unresonable, but it's a hundred times worse when their logic is faulty and their facts are just plain wrong.

Syncing Makes Me Cranky

Someone recently noted that every time I attempt to synchronize some portion of my increasingly expanding digital life — be it Address Book contacts, calendars, mail, or any of the other bits of data that seem to be essential everywhere I go and at all times — I get cranky. It's true. Syncing has become the new Holy Grail for just about anyone who has data on more than one device, which is getting to be lots and lots of people. It's no surprise that my most popular post ever has been, essentially, about syncing calendars. (Publishing, actually, but it's basically a sync issue.) There are also any number of sync-related products on the market these days. But I have yet to hear of any that would meet my syncing needs for any length of time — Mobile Me, for instance, looks great on paper, but sounds disastrous in practice.

Mobile Me: Right Idea; Wrong Implementation

A new service, Fruxx (currently in beta), looks promising. But so far I've opted for free alternatives, and, most recently, those have revolved around Google (now that it supports IMAP — more on that later), which is increasingly sync-able with the Macintosh platform, and increasingly present in my digital life.

Fruxx: Looks Promising

So why the cranky? Two reasons, really. The first is that I always feel that syncing should be easy. The second is that syncing is never easy. Syncing is, at best, a big fat pain in the ass, and at worst a vector for data loss.

Why is syncing so tricky? An illustrative scenario that springs to mind is the moving of data. Let's say I have 5 GBs of data in a folder called Movies. This folder is located in my home directory. That home directory gets synced to a spare hard drive via Time Machine. Now let's say I move those movies to another folder in my home account called Old-Movies. At last sync I had a 5 GB folder called Movies and no folder called Old-Movies. Now I have an empty folder called Movies and a 5 GB folder called Old-Movies. There are a few ways to sync this data move, and none is completely foolproof. What Time Machine will do is what I call an incremental backup. That is, Time Machine will keep a copy of the 5 GB Movies folder and make a backup of the 5 GB Old-Movies folder, even though their contents are the same. This is safe, but not storage-efficient.

Another model is to mirror the data, in which case the source is adhered to strictly, and anything not on the source is deleted from the target. In this case, the files in Movies would be deleted and the ones in Old-Movies would be copied. This is more storage-efficient, but also more destructive; it does not take into account the need to access previous iterations of the data. And all this gets even more complicated when there are two data stores and each is modified separately. For instance, what if I'm storing, accessing and editing copies of my contacts on my phone, my computer and my Google account all at the same time. How do we keep these data stores properly in sync with one another?

Again, there are numerous models. But one of the best so far — and particularly for small bits of data, like contacts and calendars, but not so much for large data like, say, movie files — is what's being referred to these days as "The Cloud" model. "The Cloud" is really just a marketing term for keeping your data in a centrally located, globally accessible place. In my biz we call these servers. Using servers to store data works well for syncing because the "master" data set is accessible from all of its clients. Make a change on your phone, and that change goes directly to the server. Next time you log on to your computer, it too talks to the server and gets the latest changes.

This is the approach I've been trying to use. These days I am syncing my iCal calendar data to Google Calendar, and my Address Book contact info to Gmail. Google is a good service to use for my stuff because it's free, extremely reliable — it's Google for Christ's sake — and it works with the Mac. But setting all this up is inordinately painful. For calendars I am forced to use a Byzanntine setup process involving login info and insane calendar URLs for each calendar on each computer.

Google Calendar Setup: Painful

With 10 calendars on 3 computers, this has been annoying, time-consuming and error-prone. Not to mention cranky-inducing. For my Address Book contacts the process was much easier: I just entered my Gmail info into a sync panel in Address Book and I was off to the races. There are problems with this too, though. For some reason I only get the Google Sync option if I've attached an iPhone to the machine in question, which is ironic considering the iPhone is mainly a target, rarely a source, and generally relies on a computer to be the data "master." Also, Address Book and Google only seemed to sync when I synced my iPhone to my computer, greatly limiting the usefulness of this feature. My main Mac, my iPhone and Google are now in sync, but what about my other computers?

Google Address Book Sync: iPhone-Only Why?

But what's most annoying is that all this setup is completely redundant. It's all been done before. All the info I need is already there. In Mail.app.

For email I've long used a protocol called IMAP, which is an example of the concept of centrally located data that's been around for some time. Yup, that's right. We've been doing mail in "The Cloud" for over twenty years now. In fact, I'd venture to say that if we'd had the sort of standards for calendars and contacts that we do for mail, we might not even be having the whole "Cloud" conversation. Calendars and contacts would all be on our mail server and served over well-worn, well-understood, free protocols. Fortunately, we're getting there, and again, by running their services using free and open protocols, Google is leading the charge. And Apple is right behind them with support for standard, open formats like CalDAV and VCF in their applications. But the process needs to be simplified: If Mail.app has my Google user info, that should be all the system needs to set up the other services.

Ideally, I think it would be really neat if someone offered up a service that simplified all of this. Imagine a site or an application that consolidated all — and I mean all — your email, calendars and contacts. I know this is what Mobile Me is going for. Google is also, basically headed in this direction. But Mobile Me can't pull your Google data and vice-versa (or at least not easily). No one is taking into account users' current data sets. Thus far, these systems are still too proprietary. This all needs to work like mail does, only better. Ideally, I could enter a username and password, and the URLs of a few servers and The Service would aggregate everything for me. Just like Mail.app does with all my mail accounts now, The Service would do for contacts and calendars as well.

Of course, then what would I get cranky about?

Don't worry. I'll find something.

Addendum: Before I even had a chance to post this, Khoi Vinh, of Subtraction fame, posted some tangential thoughts on cloud computing in a financially unstable world. I found the following passage particularly relevant to at least part of my argument:

"...I pay a company to store my mail on the cloud, ostensibly, but I have no more or less trust in their longevity than I do in any other online business. Through the underestimated miracle and beauty of IMAP though, all of my messages are also mirrored on my hard drive, an invaluable insurance policy against the sudden disappearance of my mail server or host provider. To me, the IMAP approach is really the ideal approach, and I really wish it was a model for more Web services."

See? I told you so.

Khoi's article is less about syncing and more about data storage and archiving, but it's an interesting read if you're interested in where, for instance, all your Google docs will go when the company crashes under the weight of the current financial crisis, and other drawbacks to so-called "Cloud Computing."