As usual, the definitive review of the latest OS X update is on Ars Technica, written by John Siracusa, and he details each and every point so thoroughly that the review is 23 pages long with no table of contents and it’s almost impossible to quote anything, because each point is detailed over half a dozen paragraphs. (You wouldn’t think the guy has a Twitter account.) I’d even say this year’s review is a little more belabored and fluffed than usual, but that may just be because I was tired when I read it (and, like I said, 23 pages).
Still, it’s a must-read, as usual, and it explains in relatively clear language why Snow Leopard is important, and how good and magical some of the new APIs are.
The visual sameness of Snow Leopard presents a bit of a marketing challenge for Apple. Even beyond the obvious problem of how to promote an operating system upgrade with “no new features” to consumers, there’s the issue of how to get people to notice that this new product exists at all. […]
Yep, it’s a snow leopard. With actual snow on it. It’s a bit on the nose for my taste, but it’s not without its charms.
That’s a great justification of why OS X’s packaging suddenly got so… pedestrian (not that it was ever subtle, actually). I still don’t like it — and I was surprised not to see more reaction to the images, or was it that I didn’t read the reactions to the first leaks because I couldn’t believe they were true? — but it does make sense.
In fact, all compressed Snow Leopard files appear to contain zero bytes when viewed from a pre-Snow Leopard version of Mac OS X. […] Ah, there’s all the data. But wait, it’s in the resource fork? Weren’t those deprecated about eight years ago? Indeed they were.
The reason I’m interested in that idea (which is kind of a clever compatibility hack, although it makes a bit more of a mess of the filesystem) is my personal pet peeve: Dropbox, the best cloud synchronization system, doesn’t sync resource forks. Every time I see someone recommend it (and it happens often, because it’s so well done), I jump on the occasion to remind them that it fucking corrupts anything that relies on resource forks — used to be just icons, web bookmarks and text clippings, but now it’s gonna be all system-compressed files.
I don’t know how transparent the compression process will be to Dropbox, and at how low a level they access the filesystem, but there’s a chance it would motivate them to finally get to work on this. Or not.
And then, the final frontier: an entire file’s contents stored uncompressed in an extended attribute. […] When storing information in a data or resource fork, HFS+ allocates space in multiples of the file system’s allocation block size (4 KB, by default). […] When allocating disk space for extended attributes, however, the allocation block size is not a factor; the data is packed in much more tightly.
Now, talk about filesystem hacks. That’s very clever: if a file is much smaller than the drive’s block size, just store its contents in the file allocation table (ok, apparently it’s called “the Catalog” on the Mac, sorry for purists, I’ll admit I never looked at the inner workings of HFS). But Jesus is it hackey.
Also, Siracusa points out later in his review that HFS is inherently unstable, and you always gets corruption over time in your Catalog. So I guess those are files that just won’t ever recover from errors, will they?
And, speaking of the filesystem, the thing I’m most eager to try out, as a developer, with Snow Leopard, is the entirely rewritten filesystem APIs: you wouldn’t imagine how convoluted it got for me when I simply wanted Sokusei to follow aliases to files and folders — two dozen lines of unfathomable code for something that, conceptually, should be just one instruction.
Well, now that appears to be solved (according to the article; I haven’t looked at the documentation yet), and… I’m not gonna be able to play with it for a while.
Incidentally, that new API, if it’s really well designed, could very well be the main reason, rather than 64-bit computing or Grand Central Dispatch, why small productivity utilities and all kinds of little applications could quite quickly update to Snow-only versions. I can tell you that Sokusei would probably go that route within a couple of months if my main machine was an Intel Mac.
The article makes a nice summary of where Snow Leopard is on the 64-bit front, and where the previous versions of the OS were — an important reminder that Leopard was already very much 64-bit–compatible, and that the only difference in Snow Leopard is that the kernel can run in 32-bit (but doesn’t for compatibility’s sake), and the system (I guess that means the Finder, Dock, Time Machine, and so on?) does run in 64-bit… but all apps could already run in 64-bit with Leopard; it’s just that they didn’t care to.
And that’s followed by another nice reminder of the nicest reasons why 64-bit is more efficient than 32-bit: x86 processors don’t work quite the same way when they’re in 64-bit mode, and let go of some legacy contrivances, making computation faster beyond the fact that it happens on eight bytes at once.
Remember when Apple switched to Intel and Siracusa complained that he could imagine his data going through that tortuous, inelegant architecture instead of the PowerPC’s streamlined RISC instruction set? Well, as I understand it, that’s a little bit of what this is about.
Those with some multithreaded programming experience may be unimpressed with [Grand Central Dispatch]. So Apple made a thread pool. Big deal. They’ve been around forever. But the angels are in the details. Yes, the implementation of queues and threads has an elegant simplicity, and baking it into the lowest levels of the OS really helps to lower the perceived barrier to entry, but it’s the API built around blocks that makes Grand Central Dispatch so attractive to developers.
The code examples he gives are just baffling in their simplicity. I had already been amazed when I discovered Leopard’s NSInvocationOperation (which already made it insanely easy to spawn tasks as new threads), but the elegance of Dispatch for creating threads and processing their results back in the main thread is just unbelievable.
When a 64-bit application using QTKit requires the services of the 32-bit-only QuickTime 7 back-end, QTKit spawns a separate 32-bit QTKitServer process to do the work and communicate the results back to the originating 64-bit process. If you leave Activity Monitor open while using the new QuickTime Player application, you can watch the QTKitServer processes come and go as needed.
Just like Safari’s plug-ins running in their own processes (for the same reason), the idea that this works, and is even remotely efficient, amazes and puzzles me a bit.
Also, [QuickTime Player’s] title bar obscures an entire swath of the top of the frame, and this can’t be moved. I appreciate the compactness of this approach, but it’d be nice if the title bar overlap could be disabled and the controls could be dragged off the movie entirely and docked to the bottom or something.
When everyone described how the the title bar disappeared while a movie was playing, there was never any hesitation in my mind that the title bar had to be outside the movie — like the Finder’s sidebar which just grows out of the window when you activate it.
Having it overlap the whole top of the movie, with not even a bit of transparency, is absolutely bonkers. Like I said in a previous post, there is one or several sociopathic designers in the iTunes and QuickTime Player teams who just won’t let anything go out without imposing their demented mark on the interface.
Finally (and I did mention that the original review is 23-page long and the most thorough, documented article you’ll ever read on the internet, so I’ve only been writing here about stuff I had to comment on; it doesn’t in any way replace reading the whole thing), I always assumed that Siracusa would be the one to finally do some testing, and listing, on which applications do and don’t support text substitutions. But I guess he doesn’t care much for that functionality, because it only gets a screenshot and a couple of sentences. Damnit, you can’t count on anyone anymore.