Mac OS X 10.5 Leopard: the Ars Technica review

Introduction

At the end of my Mac OS X 10.4 Tiger review, I wrote this.

Overall, Tiger is impressive. If this is what Apple can do with 18 months of development time instead of 12, I tremble to think what they could do with a full two years.

That was exactly two and a half years ago, to the day. It seems that I've gotten my wish and then some. Mac OS X 10.5 Leopard has gestated longer than any release of Mac OS X (other than 10.0, that is). If I had high expectations for 10.5 back in 2005, they've only grown as the months and years have passed. Apple's tantalizingly explicit withholding of information about Leopard just fanned the flames. My state of mind leading up to the release of Leopard probably matches that of a lot of Mac enthusiasts: this better be good.

Maybe the average Mac user just expects another incrementally improved version of Mac OS X. Eighteen months, two and a half years, who's counting? Maybe we enthusiasts are just getting greedy. After all, as Apple's been so fond of touting, there have been five releases of Mac OS X in the time it's taken Microsoft to deliver Windows Vista.

But far be it from me to use Microsoft to calibrate my expectations. Leopard has to be something special. And as I see it, operating system beauty is more than skin deep. While the casual Mac user will gauge Leopard's worth by reading about the marquee features or watching a guided tour movie at Apple's web site, those of us with an unhealthy obsession with operating systems will be trolling through the internals to see what's really changed.

These two views of Leopard, the interface and the internals, lead to two very different assessments. Somewhere in between lie the features themselves, judged not by the technology they're based on or the interface provided for them, but by what they can actually do for the user.

This review will cover all of those angles, in varying degrees of depth. Like all other Mac OS X releases before it, Leopard is too big for one review to cover everything. (After all, Tiger's internals alone can fill over 1,600 printed pages.) As in past reviews, I've chosen to delve deeply into the aspects of Leopard that are the most interesting to me while also trying to provide a reasonable overview for the non-geeks who've decided to take the plunge into an Ars Technica review. (Hi, Mom.)

Okay Leopard, let's see what you've got.

Background

This is the part where I usually link to the entire history of Ars Technica's Mac OS X coverage, from the hoary DP2 in 1999 all the way up to the previous major release. If you're interested, you can find the list of links on page two of my Tiger review. But with 10.5, I think it's time to make a clean break from the past. While Mac OS X is still changing as fast as it ever has, I feel like the concept of Mac OS X as a product has settled down in the minds of users. What was once seen as a strange and exotic beast is now simply "the Mac operating system." It's almost a shame that the "X" qualifier is in there.

After over eight years of exposure, even the hardest of hardcore classic Mac OS fans have gone through all five stages of grief over what's been lost—some of us multiple times. Though what's been found in Mac OS X has long overshadowed those concerns, rest assured that they are not forgotten. The difference now is that enough time has passed to allow them (I hope) to shed all semblance of nostalgia and be seen as they always should have been, as critical statements about the current state of Mac OS X, full stop.

Moving on to hardware, can you believe I still don't have an Intel Mac in the house? Okay, maybe it's not so hard to believe if you happen to recall that my dual 2GHz G5 replaced a blue and white G3/400, and my G3/400 replaced an SE/30. Though a MacBook Pro is likely on its way to my house as you read this, alas it did not make it in time for this review. On the bright side, my relatively static hardware collection allows for good continuity of performance impressions. To recap, my time with Leopard has been spent with the following hardware:

• Dual G5 2GHz: A dual 2GHz Power Mac G5 with 2.5GB RAM, an ATI Radeon 9800 Pro video card with 128MB of VRAM in an 8x AGP slot, two 160GB 7,200 RPM Serial ATA hard drives, a DVD-RW/CD-RW drive, and a 23-inch Apple Cinema HD Display (the non-aluminum one).
• Dual G5 1.8GHz: A dual 1.8GHz Power Mac G5 with 1.25GB RAM, an ATI Radeon 9600 XT video card with 128MB of VRAM in an 8x AGP slot, a 80GB 7,200 RPM Serial ATA hard drive, a CD-RW/DVD-ROM drive, and a Dell 20-inch LCD.
• 15" AlBook: The 1GHz 15-inch Aluminum PowerBook G4 which I reviewed here at Ars Technica.

In this post-PowerPC era, it's reasonable to expect that Apple is spending most of its time on Intel-specific performance enhancements, but even if this were not the case, Intel's CPUs have long since left behind the last PowerPC chips used in Macs in terms of all reasonable performance measures. There is no need for deep analysis or gnashing of teeth; Leopard is faster on today's Intel Macs than it is on yesterday's PowerPC Macs because today's Intel Macs are, well, today's Macs. Time marches on.

The good news, I suppose, is that Leopard certainly isn't hamstrung on PowerPC Macs. More on performance later. For now, let's talk fluff.

Branding

Big cat names are still in effect. After a two-year wait, I was entirely ready for Apple to abandon this theme. It's almost as if they have. Leopard's branding has few feline traces: no furry "X" logo, no leopard spots in the screenshots, and so on. So what is the theme? First, recall the history.

So what's the story with Leopard? Quite simply, it's Tiger in space.

To my eyes, Mac OS X's branding is changing ever so slightly less between each new release. I guess this is yet another sign of a maturing product. I like the space theme. Like Tiger's spotlight theme, it highlights the most prominent feature of the OS. It also leads nicely into a secondary future-world theme, as seen in this screenshot of a prerelease web page at apple.com.

It took a while to settle down, but once the space theme was chosen, Apple has run with it and produced what I think is the most appealing mass-market message for Mac OS X yet.

Installation

The installation process has been further pared down. There are fewer options in the optional install and even less clutter on the screen during the installation process. We Mac users take this all in stride, but I can imagine the Leopard installer being a revelation to someone who uses Windows exclusively.

Apple has also updated the introduction movie, which now plays full-screen during the first boot into Leopard. It's hot.

Leopard's new look

There's been mention of a "new look" in most post-10.0 Mac OS X reviews, and with good reason. With each release of Mac OS X, Apple has chosen to revise the look of several aspects of the interface. Sometimes these changes were made for usability reasons, but increasingly, the motivation appeared to be, for lack of a better word, fashion.

The phrase "arbitrary graphical change" has become increasingly applicable, and the sheer number of possible looks for any given element of the OS has exploded. As of the end of Tiger's reign, most major interface elements had at least two possible looks, with windows themselves having many more than that. Worse, Apple itself has introduced many new looks that are exclusive to its own applications (e.g., the iTunes scroll bars or just about the entire Aperture interface.)

I've never been among those who rail against this proliferation of looks based solely on their number. It's okay to have multiple looks for, say, a button as long as it's still recognizable as a button. In fact, this exact sentiment was expressed in Apple's human interface guidelines long before the advent of Mac OS X.

That said, I have my own reasons for being down on the state of Mac OS X's appearance through the Tiger era. Put simply, after six years of tweaks, I'm ready for a big change.

I touched on this in the introduction, and it colors my entire view of Leopard: I'm looking for a discontinuity, a new beginning, in all aspects of the OS. This is unfair (and you'll see how unfair in a moment), but it's how I felt. I know plenty of other Mac fans also pinned their hopes on a radical appearance revision in Leopard; all the "top secret" hype certainly fanned those flames.

Just to be clear, I'm talking only about the appearance of the OS for now. I certainly wasn't expecting big changes to the interface behavior—a crazy iPhone-like multitouch reimagining, pervasive voice or handwriting recognition, and so on. But there's plenty of room for a revolution solely within the "look" half of "look and feel."

Look no further than the introduction of Aqua itself for the quintessential example. Remember what that was like?

Aqua hit like a ton of bricks, and it wasn't just because it was such a break from the past. Aqua was a comprehensive overhaul of the look of Mac OS. As it existed in Mac OS X 10.0, Aqua was a closed circle: a single, internally consistent design from top to bottom.

That's not to say that it was perfect—far from it. Some judged it too bright; the pinstripes were a bit too pronounced; translucency hindered legibility in some areas; the list went on. These flaws were slowly corrected with each subsequent revision of Mac OS X. But while these corrections improved the usability and (usually) the look of the OS, they also compromised the overall aesthetic design. What started as a (flawed) work of genius was patched and filled and tweaked by a committee of pragmatists, rendering it much improved, but considerably less inspired.

Is it fair to expect Leopard to wipe the slate clean and, further, to succeed where Aqua failed by being at once a work of art and a pragmatic match for the evolved Tiger user interface? Maybe not, but that's what was in my heart as Leopard was revealed. I wanted Steve to get up on stage and say, "Aqua's had a good run, but it's time for something new. Introducing (insert code name here)." That's why I loved the "Illuminous" rumor so much. To me, a new name meant a new beginning.

Leopard's new look: the reality

Leopard's appearance is not a new beginning, but it is still the most substantial visual change in the history of Mac OS X. This is mostly attributable to the appearance of windows. A Leopard window looks like this (mouse over for graphite).

Notice that I didn't say that this is what a "standard" Leopard window looks like, or a "metal" Leopard window, or a "unified" Leopard window. That's because there's only one kind of window in Leopard, and you're looking at it. This slate gray appearance replaces all other standard window styles. Existing applications that ask for metal or unified windows will get this appearance instead.

Custom appearances like those used by some of Apple's applications retain their unique looks. (Yes, Garage Band is still sporting wood.) But oddballs aside, this is effectively a Grand Unification of window appearance after six long years of experimentation.

I mentioned before that I've never been opposed to multiple window looks on general principles, but there was one reason (aside from my desire for radical change) that the multiplying window appearances bothered me. The big problem was that it was never clear which appearance to use in any given situation. Apple's few attempts at setting guidelines stank of retroactive justification, so developers were left to their own judgment. This led to some poor choices and some ugly applications.

And, truth be told, if there's no coherent reason for the use of a new window appearance, then why does it need to exist at all as a system-wide option for all developers? I'm not sure what to call the new One True Window Appearance in Leopard (Aqua? Slate?), but I'm glad someone at Apple finally made a choice and stuck with it.

As for the look itself, I find it kind of heavy, especially when paired with the still-bright standard window background, as seen in dialogs, especially.

It also clashes a bit with the mostly unchanged buttons, scroll bar thumbs, and other standard controls that retain their shiny blue appearance. The old "Aqua" window looks (any of them) were definitely a better fit.

Tool bars in the new windows are "unified" in that there is no dividing line between the title bar and the tool bar area. Tool bar items retain their many different looks across the bundled applications. There's a new appearance for the "selected" state of toolbar items, which has its own interesting story.

There's also been a welcome revision to the look of "capsule" toolbar buttons. Gone are the muppet-felt blue buttons introduced in Tiger's Mail application, replaced with more palatable gray equivalents.

The capsules are still a bit of an oddity, coming in little clumps as they do. The Safari-style square toolbar buttons are more common, and much nicer looking. The depressed (mouse-down) state of these buttons is particularly nice.

The inactive state of the new windows is now more clearly distinguished from the active state. Inactive windows fade to a much lighter shade of gray. The switch from dark to light gray can actually be a bit jarring when it happens to large windows.

It takes a while to get used to these changes. Long-time users used to looking for "dark windows" to pick out Safari, for example, will be flustered. Now, only the front-most window is dark, and even Safari windows are light when in the background. Still, it's a change worth acclimating to.

To even further emphasize the front-most window, its drop shadow has been greatly expanded (see screenshot above). It's large, but also quite diffuse, so it doesn't unduly obscure content below.

Aesthetic quibbles aside, the new window look is overwhelmingly a net win. It eliminates developer and user confusion, sweeps up and disposes of several ugly (in the opinion of many) looks from past versions of Mac OS X, and is, well, pretty okay looking in its own right.

Perhaps I should try to sound more positive about the new window style, because it turns out to be the highlight of the visual changes. Leopard also includes its own crop of the aforementioned "arbitrary graphical changes," and most of them are not changes for the better.

Leopard's new look (continued)

Arguably, the new window appearance was also an arbitrary change. (Why dark gray? Why not standardize on the old "unified" appearance instead?) But in the grand scheme of things, the particular design chosen is not as important as the fact that a choice was made. Of course, it could have been an ugly choice (I don't think it is) or it could have suffered from terrible usability issues (I don't think it does), but at least the intent was a good one: to simplify.

The same cannot be said for a several other significant changes to the look of Leopard's interface. Their intent is unclear at best, they cause usability issues where none existed before, and many of them are visually unpleasing, if not downright ugly.

Folders

Let's start with the most iconic icon in the OS, the humble folder. Next to windows and standard controls, the folder icon is the most ubiquitous piece of reused art. A lot of people didn't like the folder icon introduced in Mac OS X 10.0 and carried through essentially unchanged to Tiger.

As the look of the OS moved away from 10.0's heavily pinstriped, ultra-bright-and-shiny look, the folder icon stayed stuck in the past. Some also complained that the isometric perspective didn't match Apple's icon design guidelines. But these are all trivial issues, and subjective ones at that. Most Mac users were not clamoring en masse for new folder icons.

I'm not opposed to a new folder icon design, of course. But the first rule of such an effort should be "don't make it worse." Unfortunately, that's exactly what Apple's done with the Leopard folder icon design.

The look isn't bad, right? It's still easily recognizable as a folder. It's even environmentally friendly; note the darker blue flecks that imply it's a recycled paper product. (Er, recycled pixels... or something.) The trouble starts when you see what the "special" folder icons look like (Applications, Documents, etc.)

The embossed look is attractive, but it's also incredibly low-contrast and pretty much impossible to make out at small sizes. I keep several special folders in my Dock, and I rely on being able to pick them out quickly, even at small sizes. Here's how they look in Tiger.

Now here they are in Leopard.

When it comes to at-a-glance identification, the difference is striking. I find myself literally squinting at the Leopard special folder icons, as if I'm constantly not seeing them clearly. You can find a more rigorous examination of the new folder icons at Indie HIG (a site whose mere existence is a blot on Apple's recent user interface record).

Poorly designed folder icons aren't the end of the world, but it's the context that's so maddening. Here's an interface element that maybe could have used some freshening up, but it was far from broken. Apple's gone and made it worse in a way that's obvious in seconds to anyone who's ever given any thought to interface design. It boggles the mind. The rumor is that Jobs likes them. Great.

The Dock

It gets worse. Next to go under the knife is the Dock. Now here's an interface element with some serious, long-standing issues, but remember we're only talking about appearances in this section. On that front, there's not much to complain about in Tiger, where the Dock is a minimalist translucent rectangle upon which icons are arrayed.

Hmm, how can we make this more "Leopard"? We'll have to decrease the usability in some obvious ways. I've got a few ideas there. Let's start by removing the uniform background, leaving the icons partially hanging over the desktop. That'll be sure to cause some visibility issues. Next, the already-small triangles that appear under running application icons can probably be further obscured. Let's replace those with fuzzy blue orbs. Also, if we can somehow make the Dock less space-efficient, that'd be a plus. But we also have to jazz it up, don't we?

I know! Let's make it pseudo-3D! And finally, the obligatory demo feature: reflections everywhere! Reflections on the fuzzy blue orbs, a reflection highlight line running across the whole Dock, and—the coupe de grâce—real-time reflections of any windows that move near the Dock! Behold, the Leopard Dock.

It's a cornucopia of Obviously Bad Ideas, again addressed more thoroughly by others. This is like the folder icon situation all over again, but even worse. It's an example of sacrificing usability for the sake of purely aesthetic changes that are far from universally loved (to put it mildly) in isolation, and inexcusable given the price paid for them.

Seriously, pseudo-3D? Really? If a compulsion for gaudiness must be quenched, at least try to confine such exercises to more obscure features. Don't scribble all over the second-most visible interface element in the entire OS like a nine year-old girl putting make-up on her dollie.

When the Dock is placed on the side, it regains its sanity, appearing with a uniform, flat background that encloses the icons entirely. There are no real-time reflections, and running applications are indicated by a small but high-contrast white dot.

This visual style never appeared in a developer seed of Leopard, indicating that it was added very late in the game. Perhaps it's meant as an apology, or an acknowledgement that the people most annoyed by the look of the horizontal Dock are also the most likely to have their Docks on the side. Either way, the presence of an alternate look is a tacit admission that the default design has problems.

If you want the alternate look when the Dock is on the bottom too, type the following commands at a Terminal prompt:

% defaults write com.apple.dock no-glass -boolean YES
% killall Dock

There is actually one legitimate improvement in the appearance of the Leopard Dock. The text labels that appear when hovering over Dock icons are more readable, with light text on top of large, uniform, dark backgrounds.

Did I say "second-most visible interface element" earlier? Oh, you see it coming, don't you? What's the most visible interface element? What's on screen even more than the Dock? Your brain doesn't even want to go there, I know. "The menu bar? Surely they didn't... I mean, what's to change there?" Oh yes, buckle your straightjackets; we have now passed over to the other side.

The menu bar

Completing the troika of insane, unnecessary changes for the worse made to Mac OS X's most prominent interface elements is the Leopard menu bar which is, inexplicably, incomprehensibly translucent.

It's more of a "menu smear" than a menu bar, as if someone painted it onto the screen with Vaseline. (It's actually using Core Image to filter the background, if you care.)

It used to be worse, believe it or not. In prerelease versions of Leopard, the menu bar was even less opaque—comically so. But Apple gets zero points from me for lessening the degree of transparency. That'd be like congratulating someone for extinguishing the left half of his body after intentionally lighting himself on fire.

The rationale proffered by Apple for the use of translucency in the original Aqua design was that it denoted a transient element—pull-down menus and sheets, for example. Now it's being applied to the least transient element in the entire interface.

Leopard's new look has been compared to the Aero Glass look in Windows Vista. While I think there are few legitimate similarities, this comparison comes up as often as it does because the two designs share one prominent attribute: the gratuitous, inappropriate use of translucency to the detriment of usability.

Why, Apple? Why!? Was there something horribly wrong with the existing menu bar—something that could only be fixed by injuring its legibility? Like the folder icons and the Dock, it's not so much a fatal flaw in and of itself. It's what it implies about the situation at Apple that is so troubling. What in the holy hell has to happen in a meeting for this idea to get the green light? Is this the dark side of Steve Jobs's iron-fisted rule—that there's always a risk that an obviously ridiculous and horrible idea will be expressed in his presence and he'll (inexplicably) latch onto it and make it happen? Ugh, I don't even want to think about it.

In the meantime, there's sure to be a burgeoning market for hacks to restore blessed sanity to the menu bar. This is nothing new, really. Since the dawn of Mac OS X, third-party developers have been saving Apple's bacon by doing what Apple should have done itself. I already need several "hacks" to be happy in Tiger, but a hack for the menu bar? It's just getting ridiculous.

I guess I should try to say something nice about the Leopard menu bar too. Well, the new Spotlight icon fits in much better with the line-art theme used for other menu icons.

Leopard's menus also have a subtle change: rounded corners. Only the lower corners are rounded in drop-down menus, while all four corners are rounded in pop-up menus.

Although I'm a big fan of rounded corners (round rects forever!) I don't like them in this particular location; I think it makes drop-down menus in particular look less crisp. But at least the change has no detrimental effect on usability and isn't aggressively ugly.

The new menu highlight color is a deep, rich blue on an appropriately slatey gray, both with the obligatory gradients. They're certainly striking, but perhaps distractingly so. I know, I know, I'm never satisfied.

Leopard's visual scorecard

I'm going to stop here, not because there's nothing more to say about the new look in Leopard, but because the things I have covered span the range of quality. The new, standardized window style makes the biggest visual impact and is the best aspect of the new design. At the other end of the spectrum are the baffling alterations and adornments that make Leopard less usable and (in many cases) less pleasant to look at. There are small visual improvements in individual applications, but the overall look of the OS proper is foundering.

I was ready for an all-new look in Leopard; I was ready for Aqua's successor. That Leopard doesn't provide that is a disappointment, but hardly a sin. But a lower degree of difficulty should entail less risk. Viewed in that light, Leopard's graphical missteps are damning. If Apple is going to make mistakes, let them be made in service of a truly daring design. I'm willing to forgive, and even to look back fondly on the original Aqua UI for this reason. But to attempt a relatively tame evolution and then to willfully screw things up—things that were not broken before—that I do not forgive.

The Kernel

Let's go in the opposite direction entirely and dive into the core of the OS. We'll work our way back up to the higher levels eventually. For now, it's kernel time.

There was a bit of a kerfuffle about the future of the Mac OS X kernel back in the summer of 2006, fed mostly (as these things often are) by an information vacuum. The summary is that Apple wasn't releasing the source code to its then-new x86 kernel (as it had with all previous kernels) and wouldn't say why. Many theories sprang up to fill the void. I, of course, had my own pet theory.

The most logical reason that I can think of for Apple's refusal (thus far) to publish the source code to the x86 version of the Mac OS X kernel is that the kernel shipping today in the x86 versions of Mac OS X Tiger is an evolutionary dead end, and therefore not worth the effort to pretty up and publish.

Presumably, all of the major work on Mac OS X, the kernel or otherwise, has long been focused on Leopard. Now imagine that the Leopard kernel has significantly diverged from the Tiger kernel. Maybe it's a new kernel entirely, or maybe it has significant changes to support virtualization more efficiently, or something in between. Apple seems to be holding its cards close to its chest until WWDC. In the meantime, pushing out the source to a soon-to-be defunct incarnation of the Tiger kernel might not be along the critical path.

I even had some crackpot ideas about what, exactly, could replace the existing Mach/BSD kernel—ideas that didn't stand up to much scrutiny, sadly. But as usual, I was smart (or wimpy) enough to hedge my bets.

I'll be very surprised if there's no big kernel-related technology or announcement at WWDC. That said, I don't see any pressing need for major kernel shenanigans in Leopard, just more of the same kinds of improvements that came in Tiger. Maybe no big announcement really would be the best possible outcome.

WWDC came and went (and came and went) and there was no major kernel announcement. The Leopard kernel does indeed contain "more of the same kinds of improvements" that we've seen over the life of Mac OS X, and that's not a bad thing at all. (I'll save my kernel pipe dreams for Mac OS X 11.0, I suppose.)

A lot of the kernel rumor craziness had its origins in the idea that Mac OS X is a poor performer at the kernel level due to some fundamental design choices. This is a long-standing meme with some sound (though often misapplied) computer science theory surrounding it, as well as the expected bevy of dubious benchmarks.

As usual, the truth is much less dramatic. The core OS team at Apple is, perhaps predictably, the polar opposite of the graphical design team. Apple's kernel engineers in particular are pragmatic, cautious, and wise. They're also human, however—if you prick them, do they not bleed?—which may explain why they spent some time at WWDC spelling out the philosophy behind Mac OS X's kernel development process.

Apple's focus is on system-level performance, not micro-benchmarks. The kernel team's job is to make the software at the higher levels look good. If improving the performance of some tiny aspect of the kernel tenfold does not provide a measurable performance increase for some user-visible feature or task, it's not an effective use of development time, benchmark bragging rights be damned.

That's not to say that Apple's kernel team isn't competitive. But when it comes to dedicated kernel benchmarks, there's a natural home-field advantage: Linux tends to do well on LMBench, Solaris does well on libmicro, and so on. This is not surprising; the choice of benchmark determines where optimization is done. Apple's decision to measure kernel performance "from the top" by looking at the behavior of the real applications running on the full OS dictates which aspects of the kernel get the most attention.

In Mac OS X in general, and in Leopard in particular, improvements to scheduling and latency are important. There's a big difference between being "fast" and being "responsive," and Apple's focus is on the latter. Here are a few of the highlights from the Leopard kernel. (For the nitty gritty details, there's always the source code... or will be, once Apple updates its repository.)

Kernel highlights

The Leopard kernel is better about scheduling processes on CPUs, moving from a single, flat queue of processes to a hierarchical one that better reflects the actual hardware (e.g., two separate chips, each with two CPU cores). Bouncing a process from one CPU to another is bad for performance; the on-chip caches don't get a chance to properly warm up. But multiple cores on the same chip often share some caches. A hierarchy of process queues in the kernel created with this knowledge allows for better scheduling choices.

The Leopard virtual memory system is better about determining which pieces of memory are actually being used by your application right now and which are safe to swap out to disk. When it comes time to swap to disk, Leopard will (finally!) dynamically allocate swap files, which means that you should get some disk space back when the memory pressure abates.

Resource limits, the bane of my existence in Tiger and earlier, are dynamic where possible in Leopard. These are things like the number of open files or processes per user and so on. If you've never bumped up against these limits, consider yourself lucky; a lot of things stop working in very bad ways when you can't open any more files, for example.

I routinely run into these limits in Tiger and have often been forced to take heroic measures to increase them. A few of the defaults have also increased in Leopard (e.g., the default maximum number of processes per user has increased from 100 to 266. I'll still keep mine over 2000, thanks). And for good measure, there are even a few new limits on previously unlimited resources like resident and wired memory sizes.

The Leopard kernel also has a new "sandboxing" system which forces certain processes to run in their own isolated, restricted environments for security reasons. Apple's implementation is based on mandatory access control (yet another "MAC" acronym that's not short for "Macintosh"). These sandboxes are defined, in typically unpretentious Unix style, by plain text files (examples can be found in /usr/share/sandbox) and are applied to many system services in Leopard, including Bonjour, Quick Look, Spotlight, NTP, and many others.

DTrace

Perhaps the most significant change in the Leopard kernel is the addition of DTrace. DTrace was developed by Sun and is open source. Apple's core OS team has continued its streak of shrewdly identifying and adopting best-of-breed open-source projects and has completed the substantial task of porting DTrace from Solaris to the Mac OS X kernel. DTrace solves a long-standing kernel development problem, and does so in such a fantastic way that it creates new opportunities for Apple to help all programmers, not just kernel hackers.

To understand how DTrace helps kernel developers, consider the following scenario. Let's say you're a developer working on some aspect of process creation in the kernel. To help during your development, you'd like some sort of notification every time a new process is created. So you find the function in the kernel that creates a new process, and you add a bit of your own code to the beginning of that function that prints some information to a log file. Now you recompile your kernel, reboot, and continue your work.

Unfortunately, you've hard-coded at least three things using this technique: 1) the fact that you want some debugging information, 2) the location of the inquiry, and 3) the mechanism of the report. Furthermore, it's likely that you'll want similar bits of debugging code in other places in the kernel in the future, and it's unlikely that you'll want every one of these bits active at the same time.

So, being the good little programmer that you are, you come up with a more general solution. At each point where some debugging code may be useful, you wrap the code in a conditional expression that asks, "Should this piece of debugging be turned on right now?"

This seems like a good solution until you've filled the kernel with these snippets. Remember that the kernel, by its nature, tends to contain code that executes very quickly and very frequently. A tiny check to see if a particular piece of debugging should be turned on may only take a millisecond, but if the entire routine executed in ten milliseconds before you added this check, you've just increased the execution time significantly. And if this routine is called many thousands of times per second, you're starting to talk some real wall-clock time down the drain. Now multiply this by many hundreds or thousands of debugging probes in the kernel, and it becomes clear why all these checks cannot be left in the finished product.

The obvious solution is to convert these debugging checks from conditions that are evaluated at runtime to conditionally compiled code. When debugging is enabled during the kernel build process, some or all of the debugging code is included in the build. But when debugging is disabled for a production build, the debugging code is omitted entirely from the kernel.

Though I've simplified things greatly, this is the gist of traditional kernel-level debugging probes. You work with a special "debug build" that may be slow but which contains all the diagnostics you need for development. When you need to add, enable, or disable some debugging code, you recompile and reboot. When you're happy, you compile an optimized production build of the kernel that contains none of this debugging code.

Into this environment comes DTrace, which proposes the following seemingly impossible combination of features.

• No recompilation required. Enable or disable debugging probes in real time on a running kernel.
• Near-zero overhead when not in use. The impact of disabled debugging code is so small that all such code can be left in production kernel builds.

Programmers reading this will be forgiven for cringing a bit at the smell of self-modifying code, but my advice is to just close your eyes and think of England. The bottom line is that it actually works, and works well.

DTrace supports its own simplified programming language called "D" (no, not that one) which is used to define probes. Here's an example that prints a notification every time a new process is created.

#!/usr/sbin/dtrace -s 

#pragma D option quiet

syscall::exec*:return
{
  printf("%Y New process %s (pid %d) createdn",
         walltimestamp, curpsinfo->pr_psargs, curpsinfo->pr_pid);
}

The output looks like this.

2007 Sep 22 22:10:16 New process ls (pid 1743) created
2007 Sep 22 22:11:34 New process nmblookup (pid 1746) created
2007 Sep 22 22:18:11 New process coreservicesd (pid 85) created
2007 Sep 22 22:21:11 New process login (pid 1752) created
2007 Sep 22 22:21:12 New process bash (pid 1753) created
2007 Sep 22 22:21:12 New process sh (pid 1755) created
...

Here's another one, slightly more complicated. It waits for the ls program to make the stat() system call, then traces the execution of this call through the kernel.

#!/usr/sbin/dtrace -s 

#pragma D option flowindent

syscall::stat:entry
/execname == "ls" && guard++ == 0/
{
  self->traceme = 1;
}

fbt:::
/self->traceme/
{
  /* default action */
}

syscall::stat:return
/self->traceme/
{
  self->traceme = 0;
}

Here's the (abbreviated) output.

CPU FUNCTION
  1  -> stat
  1    -> vfs_context_current
  1    <- vfs_context_current
  1    -> vfs_context_proc
  1    <- vfs_context_proc
  1    -> namei
  1      -> vfs_context_proc
  1      <- vfs_context_proc
  1      -> lookup
  1        -> name_cache_unlock
  1          -> mac_vnode_check_lookup
  1            -> vfs_context_proc
  1            <- vfs_context_proc
  1            -> mac_policy_list_conditional_busy
...
  1      <- vfs_context_issuser
  1    <- vnode_getattr
  1    -> vfs_context_current
  1    <- vfs_context_current
  1    -> nameidone
  1    <- nameidone
  1    -> vfs_context_proc
  1    <- vfs_context_proc
  1  <- stat

In action, it's indistinguishable from magic. You write these little text files with script-like bang-pound lines using this weird C-like language and you have essentially free reign to grope all over the kernel. (You have to be root to run DTrace at all, for obvious reasons.)

The D language does not support branching, subroutines, or loops—a good thing, because accidentally creating an infinite loop or recursion inside the kernel definitely should not be one tiny plain-text script away. You also can't use DTrace to modify kernel memory or CPU registers or to call arbitrary functions.

But within its limited scope, D is still quite powerful. It supports most common C/C++ data types, aggregates, local variables, and a whole slew of shell/awk-style conventions: script arguments in $1 .. $N, BEGIN and END blocks, etc. It even has native support for cute ASCII histograms. It's quite pleasant to use—especially compared to recompiling the kernel and rebooting.

And remember this is all running on a plain old consumer copy of Leopard, not a special build. DTrace is included on all Leopard systems; it's not an optional install. This means that developers can rely on their users having it. Since DTrace scripts are plain text files, remotely debugging a thorny problem by e-mail suddenly got about a thousand times easier.

(Debug kernel builds that contain a full complement of symbols and other metadata are still useful. DTrace does not replace them. What it does do is provide an unprecedented level of flexibility on top of them—flexibility that remains even in the shipping version of the kernel.)

Install the developer tools, and you'll get a Garage Band-like GUI application for applying debugging instruments (get it?) to individual applications or the entire system. This application was called Xray for most of its development life, which explains the icon. It's now called Instruments for reasons that surely involve lawyers. If you'll forgive me, I'm going to keep calling it Xray for the rest of this review.

Unsurprisingly, many of the most powerful instruments are based on DTrace. There's even a GUI for creating custom DTrace-based instruments, plus the ability to record and play back a series of actions. Mmm... automated GUI-based performance regression testing.

DTrace and Xray invite good questions. "How many files does my application open on launch?" "How many times is a particular function called?" "What does the memory usage of my application look like over time?" DTrace and Xray make the previously daunting task of answering these questions almost trivial and (dare I say it) fun. I can't imagine any Mac developer seeing Xray and not instantly longing to sic it on his application.

All of this newfound power can't help but lead to better, faster, more stable applications—from third-party developers as well as from Apple itself. And it's all thanks to an obscure, open-source, low-level kernel debugging framework from Sun.

State of the kernel

With Tiger, Apple finally completed the kernel's transition from its NeXT roots to its Mac OS X future by nailing down the kernel APIs and providing a clear path forward. Leopard has taken the first big step down that path. The addition of DTrace is the most significant change. It's an entirely new feature and was not created with Mac OS X's kernel in mind. DTrace will also have the biggest impact on the development process and by extension on the nature and quality of applications available to users.

The rest of the changes are "more of the same," and that's a good thing: performance optimizations, scalability improvements, better standards compliance, all in appropriately conservative doses. The addition of DTrace must have helped a bit with the rest of Leopard's development, but it has taken a while for DTrace to come up to speed on Mac OS X. The real payoff will come in the next major version of the OS, which will have spent its entire development life in a post-DTrace world.

64-bit

Tiger included support for 64-bit processes, but only if they did not use any of the major GUI APIs on the system. Here's how the 64-bit future of Mac OS X looked to me at the time.

There are few benefits to being a 64-bit process for the vast majority of GUI applications. Nevertheless, it's safe to assume that, eventually, all Macs will include 64-bit CPUs. The introduction of 64-bit versions of all Mac OS X subsystems (Carbon, Cocoa, Core Foundation, QuickTime, Quartz, etc.) seems inevitable.

I just wonder how much benefit there will be from introducing any of that support piecemeal. [... ] All the higher-level GUI libraries rely on lower-level services like Quartz and Core Foundation anyway. So it seems to me that the best move in the future will be to roll out a complete 64-bit system all in one shot. That's a tall order, which is why I think it'll be a while.

Well, it certainly has been a while since Tiger, and guess what? Leopard is the release that goes 64-bit all in one shot... with a few caveats. But before getting to that, I want to revisit the idea that "there are few benefits to being a 64-bit process for the vast majority of GUI applications."

I wrote that before Apple's transition to Intel processors. Thanks to the tortured history of the x86 instruction set, there actually are performance benefits for most applications when moving from 32-bit Intel (x86) to 64-bit Intel (x86_64). The table below explains why.

The PowerPC instruction set was designed with a 64-bit implementation in mind; its "transition" to 64-bit was really nonexistent. The x86 instruction set, on the other hand, was created in the 16-bit era and has accumulated quite a bit of cruft going from 16-bit to 32-bit. Some of that cruft was wisely abandoned during the transition from 32-bit to 64-bit. Applications compiled for x86_64 don't just get larger registers, they get more registers, plus a more modern calling convention and more addressing modes.

Every 32-bit x86 application can benefit from these changes, it's just a question of how significant that benefit will be. This is not true of PowerPC applications, which get the added memory and cache pressure of 64-bit register sizes without any of Intel's cruft-abandoning benefits.

I say "x86 application" and "PowerPC application," but of course Leopard, like Tiger, supports what Apple calls Universal Binaries. These are single executable files that contain code for all supported architectures: 32-bit Power PC, 64-bit PowerPC, 32-bit x86, and 64-bit x86_64. Here's an example from Leopard.

% cd /Developer/Applications/Xcode.app/Contents/MacOS
% file Xcode
Xcode (for architecture ppc7400): Mach-O executable ppc
Xcode (for architecture ppc64):   Mach-O 64-bit executable ppc64
Xcode (for architecture i386):    Mach-O executable i386
Xcode (for architecture x86_64):  Mach-O 64-bit executable x86_64

And there you have it: the big 64-bit news in Leopard is that GUI applications can now be 64-bit. Leopard applications can also specify an architecture preference order as well as a minimum OS version for each architecture. All of this 64-bit goodness comes in a single OS; there is no special 64-bit version. Leopard is one operating system that runs both 32-bit and 64-bit applications.

There is no "mixed mode" in Leopard. Every process is either 32-bit or 64-bit. Since a 64-bit process cannot load 32-bit plug-ins (and vice versa) there will be a significant transition period for applications that rely heavily on plug-ins. (I don't envy Adobe's developers... and it gets even worse for them, as you'll soon see.)

Apple has gone 64-bit across the board, with two major exceptions. The first is the kernel itself, which remains 32-bit in order to maintain compatibility with existing drivers. The second is a bit of a sad story... or perhaps a hopeful one. You decide.

Brave new 64-bit world

At the HIToolbox State of the Union session at WWDC 2006, a slide entitled "The Future of HIToolbox" appeared. Hint number one: it is rarely a good sign when the phrase "The Future of (insert technology)" appears on a slide at WWDC.

For those of you that don't know, HIToolbox is the most modern and most important part of the API more commonly known as Carbon. The man on stage at this session began by saying the following, which I'm providing in audio form so you can get the full, nuanced experience of this moment.

• The future of HIToolbox (MP3)

For several milliseconds, Carbon programmers attending this session at WWDC 2006 saw their coding lives flash before their eyes. I say only "several milliseconds" because, after that oh-so-agonizing pregnant pause, the last sentence actually finished like this.

• The future of HIToolbox, after the pause (MP3)

"Integration! Oh thank God!" Yes, Carbon programmers were given a reprieve in 2006. But the fact that the big push at WWDC that year was for Carbon programmers to learn how to integrate Cocoa APIs into their Carbon applications should have been a big red flag.

Fast-forward to WWDC 2007, this time in the 64-bit session, and the other shoe dropped. Though several non-GUI parts of the Carbon API that are shared with Cocoa will be supported in 64-bit mode in Leopard, the GUI portions of the Carbon API will not.

Yep, it's (finally) the end of the line for Carbon GUI applications in Mac OS X. Oh, sure, they'll be around for years and years to come, but the lack of 64-bit support is a long-term death sentence.

The last vestiges of the original Macintosh API are finally being put to rest. They've done their job and are being given a decent burial, I think. A slow, almost natural transition. Bugs will be fixed in the 32-bit Carbon APIs, of course, but no new features will be added. All new GUI APIs in Leopard and future Mac OS X releases will be added as Cocoa-only APIs.

Perhaps the most painful part of this for developers with large Carbon code bases (poor Adobe... ) is that Apple did, in fact, port Carbon to 64-bit. There were sessions on it at WWDC 2006, and the code appeared in Leopard seeds. The decision to drop 64-bit support for Carbon was obviously a hard one to make, but eventually it was made, despite the work already put into the effort.

I think it was a good decision. Apple has been hamstrung by the need to support two entirely different APIs, maintaining feature parity between them, and having to explain which one developers should choose.

When it came down to it, Cocoa "won" because it's the more modern API. In the beginning, with Mac OS X 10.0, it wasn't at all clear that Mac developers would want to learn Objective-C and a whole new set of APIs. Here in 2007, the developers have spoken. The only people still doing Carbon development are those with code bases that predate Mac OS X. Apple has been encouraging these developers to port to Cocoa for years now. Now it's finally time for some tough love.

Making a clean break

Carbon is just one example. Apple has wisely decided to use the transition to 64-bit as an opportunity to make all sorts of backwards-incompatible changes. After all, 64-bit is backwards-incompatible with 32-bit already, so there's nothing to lose.

In Cocoa, deprecated APIs were simply not ported to 64-bit. The Objective-C runtime is all-new for 64-bit, with a new ABI, faster dispatching, zero-cost exceptions, and public APIs for introspection built on top of newly opaque internal structures. All over Cocoa, ints have been replaced with NSIntegers. In all of the graphics APIs, floats have been replaced with CGFloats.

QuickTime also got the "Carbon treatment." The venerable plain-C API for QuickTime is not available in 64-bit. The Cocoa QTKit library is the only game in town for 64-bit QuickTime.

And on and on. With Leopard, Mac OS X's API future is clearer than it's ever been. The future is Objective-C, Cocoa, 64-bit. Full stop, no waffling, everyone get on board the train.

There's an inherent tension between developers with existing applications and skillsets and the OS vendor's desire to attract new blood and make good long-term decisions for the platform. The late call on the 64-bit Carbon decision is clear evidence that Apple struggled mightily with these issues internally.

In the end, Apple made the hard choice instead of the easy one. I think it will pay off, though the short-term consequences could be pretty grim. After all, just look at how long it's taking to get an Intel-native version of Microsoft Office for the Mac. Should we expect a 64-bit Cocoa version in, say, 2012? And I have no idea what Adobe's going to do about 64-bit versions of its products. That's many millions of lines of Carbon code between those two companies alone. We may be in for a rough patch, so buckle up.

FSEvents

Once upon a time there was an operating system called BeOS with a daring and innovative design. Not all of its audacious new ideas worked out as well as expected, however, and those that did were not enough to save the product from other, nontechnical forces that led to its demise. Nevertheless, BeOS made quite an impression on the OS community. In particular, the file system and related interfaces in BeOS included four noteworthy features.

• Journaling
• Arbitrarily extensible file system metadata
• Asynchronous file system notifications
• Automatic metadata indexing and integrated query engine

These features combined to provide a user experience unlike any other contemporary PC operating system. Mac users, in particular, saw these features, understood their value, and wanted them in their favorite OS—assuming they hadn't already jumped ship for BeOS.

(The book Practical File System Design with the Be File System describes the history and implementation of these features. A free PDF is also available.)

In 1997, Apple purchased NeXT instead of Be and based Mac OS X on the NEXTSTEP OS. Initially, Mac OS X had none of the BeOS file system features listed above. The push to add them to Mac OS X, both external and from within Apple, met with significant resistance from engineers aligned with the NeXT/Unix philosophy. And so began a multiyear struggle for the future of Mac OS X file system technologies: the Mac guys versus the NeXTies.

At some point (so the legend goes) the Mac guys inside Apple "won," and Apple started down a new path. But it takes a long time to turn a ship as big as Mac OS X. From the perspective of an outside observer, the history of file system technology in Mac OS X resembles a six-year-long struggle to implement each and every BeOS file system feature listed above, all of which were decried by the NeXTies at one point or another as inefficient and unnecessary.

Journaling was added to HFS+; Spotlight brought automatic metadata indexing and an integrated query engine; the new extended attributes APIs brought arbitrarily extensible metadata. Now, in Leopard, the final piece has arrived: an asynchronous file system notification API in the form of the FSEvents framework.

File system events déjà vu

Tech-savvy Mac users will note that such an API existed in Tiger; it was what made Spotlight possible. The /dev/fsevents facility tracked all file i/o as it went through the Mac OS X kernel, providing notifications to interested clients. This allowed the Spotlight engine to index (or reindex) each new or changed file without resorting to polling. (Polling is the act of repeatedly asking if something has changed. It's massively inefficient and totally unfeasible as a way to detect changes across an entire file system.)

The /dev/fsevents API was private—though that didn't stop industrious hackers from playing with it. But it was private for a very good reason. It has to do with the mechanics of file system notifications.

To be aware of all relevant file system changes, the notification mechanism must exist at the choke point for all local i/o: the kernel. But the kernel is a harsh mistress, filled with draconian latency and memory restrictions. Ideally, the /dev/fsevents kernel code should make each event available to interested clients and then move on as quickly as possible.

Back in userspace, things are much more leisurely. Processes that signed up to received file system notifications via /dev/fsevents may be off doing something else when an event arrives. This is all par for the course in userspace, but it's extremely incompatible with the kernel's need to get things done right now, with minimal memory and CPU overhead.

What's the kernel to do when 10,000 file system changes occur in two seconds (say, as part of some software installation) and the stupid, lazy userspace process that registered for file system notifications is now too preoccupied with other things and hasn't pulled any notification events off its queue in the past three seconds?

Well, the kernel has to buffer those events, of course. That is, it has to save the events and wait for all interested clients to finally get around to receiving them. But buffers are not unlimited. This is especially true in the kernel. What happens when the buffers fill up?

Well, the kernel could block waiting for some buffer space to become available. However, consider what happens when a client gets blocked on a file system operation because there's no room in the queue for the corresponding event, but space never becomes available because the other client that needs to read events to free up buffer space is blocked on the client that blocked waiting for space in the first place! Hello, deadlock.

The only other option is to dynamically allocate memory, but that just postpones the problem. Put simply, either you limit the number of events you can buffer, accepting that sometimes the buffer will fill up and you'll have to drop events, or you can commit to potentially using an unlimited amount of memory.

Apple has chosen the former. The kernel buffers are a fixed size, and if they fill up because of a slow client, events get dropped. This means that one badly behaved client can ruin it for everyone.

So, no, /dev/fsevents is not a good candidate for a public API. But the demand for efficient, asynchronous file system notifications remains. What to do? Enter Leopard's FSEvents framework. It takes a pragmatic approach to providing these features.

This is a theme that recurs throughout Leopard's new technologies. Given a thorny technical problem, FSEvents does not attempt to be all things to all people. Instead, it shrewdly narrows its focus, concentrating on the possible and the probable. FSEvents provides an "80 percent solution" with (near) 100 percent reliability, rather than attempting to be an all-encompassing, "perfect" solution.

FSEvents design and implementation

It seems to me that the key breakthrough in the design of FSEvents was arrived at by considering yet another weakness of /dev/fsevents. The private /dev/fsevents API doles out notifications in real time to all interested clients. This appears to be the best feature of the API, but it's actually quite a burden for clients. Any events that occur when a client program is not running will never be seen by that client. This is why the Spotlight indexing process is launched when the system boots and remains running as long as the computer is on. It must do this in order to catch and process all file system events.

If any other program wanted to observe all file system events, it would have to do the same thing: launch at boot time and stay running forever. Oh, and never crash, because even a process that immediately relaunches itself after a crash may miss some events during the time that it's down; /dev/fsevents waits for no process.

So how does this realization lead to a design for FSEvents? The answer is that solving the problem of the constantly running client also makes many other problems disappear. Here's how FSEvents does it.

The /dev/fsevents API can only support a few extremely well-behaved clients. Spotlight is one. In Leopard, FSEvents is another. The FSEvents framework relies on a single, constantly running daemon process called fseventsd that reads from /dev/fsevents and writes the events to log files on disk (stored in a .fseventsd directory at the root of the volume the events are for). That's it. That's the super-high-tech solution: just write the events to a log file. Boring, pragmatic, but quite effective.

Programs wishing to use the FSEvents API do not need to be running constantly. They can be launched at any time and can ask, "Okay, what's changed since the last time I was running?" As long as they know where they left off in the log file, the FSEvents framework can (effectively) "play back" every event that's occurred since then and answer the question accurately.

Pragmatic? Isn't it also fair to call this solution "fraught with its own intractable problems"? How big are these log files? Are they going to fill my disk if I constantly create, modify, and delete files? Will the log files be trimmed? What if a process doesn't run for a year and then wants to know what's changed since then?

Pragmatism means compromise. Yes, if fseventsd drank from the /dev/fsevents fire hose and wrote every single event to disk, you'd run out of disk space pretty quickly. To avoid this, fseventsd only writes out changes at the much less granular directory level. The FSEvents framework, in turn, can only tell its clients, "Something has changed in directory /foo/bar/baz."

Clients of FSEvents are expected to then scan the directory that has changed in order to determine what, exactly, happened (assuming they're interested in that level of detail). The common pattern is to register for notifications for some subset of the file system tree, do an initial scan of that tree, wait for an event about a particular directory, then compare the new state of the directory to the state seen during the initial scan.

That sure seems like a lot of tedious work: register, scan, get event, scan again, compare. This same code has to be written by each FSEvents client program, and there are race conditions lurking if programmers are not careful. Pragmatism has its price.

But the payoffs are also quite substantial. No more daemon processes; launch any time to find out what's changed since you last checked. No risk of badly behaved clients causing dropped events. Read the events as slowly as you'd like. Hang, crash, relaunch: it's okay, you won't miss any events. You can even go backwards in time to revisit old events.

As with all kernel-based file system notification mechanisms, including /dev/fsevents, there's still the possibility of file system changes occurring without going through the kernel. For example, a removable disk may be mounted on another non-Leopard computer and modified there. When it returns, the local kernel has no idea what's changed.

The FSEvents API includes callbacks for these situations, effectively telling the client, "Unknown changes have occurred. You'll have to do a full rescan yourself, then pick up on the new event stream going forward." That's certainly not what a program wants to hear, but it's the unavoidable truth. and FSEvents is upfront about it. In effect, it's a form of reliability. FSEvents will not lie to you.

The fseventsd log files are written in a compressed binary format. Since only per-directory changes are kept, multiple changes to the same directory occurring within 30 seconds of each other are coalesced into a single event in the log file. The upshot is that, even when running a disk-thrashing server-type workload for 24 hours straight, the fseventsd log files will only grow by a megabyte or two per day. Normal usage will produce a small fraction of that.

That's good, because these log files are kept forever. Well, as close as possible, anyway. FSEvents uses a monotonically increasing 64-bit counter for events. Barring any malicious number-skipping hackery, this counter won't wrap around in your lifetime. But if it does, or if you run out of disk space, or if the logs are explicitly purged (there's a public API for this), FSEvents will dutifully spread the bad news to its clients: "Sorry, it's full rescan time."

Events are identified by their 64-bit event id, which does not necessarily have any particular relationship with date and time. Nevertheless, FSEvents does include the ability to ask for the approximate event id that corresponds to a particular date and time.

To prevent events from being logged at all for changes to a particular volume, simply create a file named no_log in the .fseventsd directory on that volume. And in case it doesn't go without saying, FSEvents honors the Mac OS X access control rules; you cannot receive events about directories that you don't have permission to read.

Spotlight sidebar

Spotlight has been substantially rewritten in Leopard, and is noticeably more responsive. It does not, however, use FSEvents. Instead, it continues to drink from the /dev/fsevents fire hose, grabbing each individual event as it happens. This may seem like a failing of the FSEvents framework, but it's really more of an acknowledgment of the nature of Spotlight as a system-level facility.

After all, in BeOS, metadata indexing was actually done at the file system level, within the BFS file system code. This, of course, only worked for BFS-formatted volumes, and was even further removed from anything possible in userspace, third-party code. For better or worse, system-wide file system indexing is something that the OS is best suited to handle itself, with private APIs if needed.

The future of the file system

With the addition of a public API for asynchronous file system notifications, Mac OS X has finally achieved feature parity with BeOS in all major areas of file system technology. There were compromises along the way, but also many advances. BeOS never had a persistent log of file system events, nor did it provide metadata indexing on non-BFS volumes. Leopard provides that and more (Spotlight can actually search across servers now too), all with a collection of extremely conventional userspace libraries and daemons running on top of only the barest few kernel hooks.

It's often seemed as if Apple has had to be dragged kicking and screaming into the future of file system technology, but at least it has finally come around. Yes, there have been bumps in the road, and things surely have not turned out exactly the way I expected them to. But in the end, it's the results that count.

Mac OS X developers now have all the tools they need to do some very interesting things with the file system—and this includes Apple itself. As we'll see, they've really gone to town in Leopard, finally using all the features they so grudgingly added to the OS over the last six years. In fact, Leopard's signature feature would not be possible without FSEvents.

As for the file system itself, can you believe we're still using HFS+? That's right, rumors of ZFS's ascendance as the default file system in Leopard have not come to fruition.

The effort to port ZFS to Mac OS X is ongoing, and Leopard ships with a read-only ZFS file system driver, but that's about it for now. A read/write ZFS driver appeared in a few earlier Leopard builds and will no doubt make its official appearance in some future version of Mac OS X. (A beta is available to ADC members.)

Will ZFS ever replace HFS+ as the default file system in Mac OS X? Time will tell, but it's clear that, eventually, something has to replace HFS+. Will it be ZFS, a new Apple-developed file system, or something else entirely? As I wrote last summer:

Although I would be satisfied with ZFS, I think Apple has a unique perspective on computing that might lead to a home-grown file system with some interesting attributes. When might such a thing appear? Not in Leopard, it seems—or at least not in 10.5.0.

It's plausible that the completed ZFS port will be available in the 10.5.x time frame, but I fully expect to have to wait for Mac OS X 10.6 or later for anything to replace HFS+ as the default file system in Mac OS X. The good news is that, when it does finally arrive, all these great file system APIs will be there waiting for it.

Core Animation

In the post-Mac OS X era, Apple has been a big fan of adding animation to its applications and the OS itself. Examples are everywhere: items in the iChat buddy list fade in and out and visually reshuffle themselves as new items appear; switching preference panes triggers a cross-fade and an animated window resize; items in the Dock shuffle and squirm around when a new item is dragged towards it.

Too much animation can be harmful and grating. But in the best cases, these animations actually help usability by providing an explicit visual explanation of state changes while also adding an undeniable sense of pizzazz.

Understandably, third-party developers have long tried to ape these effects. Historically, that's been a tall order. Take something as simple as the cross-fade between preference panes in the System Preferences application. A developer creating, say, a text editor may want to use that cross-fade in his preferences dialog.

But doing so takes him far from his comfort zone, into the world of graphics APIs, perhaps even OpenGL. What does all that have to do with editing text? Sure, Apple can afford to have one of its graphics gurus add whizzy effects, but it's another thing for small developers to take the time to learn a bunch of new APIs unrelated to the actual functionality of their applications. And for what? Pizzazz?

But try they did, rapidly increasing the number of Mac applications containing Core Graphics and/or OpenGL code of questionable quality, for dubious purposes. What's Apple to do?

The motivation seems admirable: third-party developers want their applications to look as cool as Apple's. Broadly speaking, this is not something that should be discouraged. But it really is inefficient to have all these developers trying to write custom code far outside their areas of expertise.

And for that matter, it's not such a great idea for Apple to be doing the same thing. Though it may have the talent on staff, Apple would be much better served by having its graphics experts work on APIs that everyone can use, rather than adding custom cross-fade code to yet another first-party application.

And so, in Leopard, Apple has introduced Core Animation. It gets a snazzy purple sphere icon to go with its friends.

Core Image

Core Audio

Core Video

Core Animation

Animation frameworks can easily blossom into full-blown redesigns of the entire GUI API. After all, isn't a static interface element simply the degenerate form of an animation? Let's reimplement everything in terms of our new animation framework! It'll be awesome!

It'll probably also be late, incompatible, buggy, and slow—not to mention being met with resistance by developers who are not keen to rewrite their GUI code from scratch using the new animation-based APIs.

Thankfully, Apple's taken a different route with Core Animation. Like FSEvents, Core Animation is a pragmatic API. It does a few well-chosen things and does them very well. It also goes to great pains to make this functionality available to existing applications with extremely minimal changes to the code.

Core Animation's original name, Layer Kit, reveals a lot about its design. At its heart, Core Animation manages a collection of 2D layers. Though layers are sorted by depth and can have perspective transforms applied to them, Core Animation is not a 3D engine. That is, layers can overlap, but they cannot intersect (in the 3D sense).

The 2D/3D distinction is further confused by the fact that Core Animation, like all graphics in Mac OS X, runs (albeit indirectly) on top of OpenGL. Apple's "3D" Core Animation demos (e.g., about 52 minutes into the WWDC 2006 keynote) also haven't helped. But rest assured that you will not be constructing any teapots in Core Animation. There are no vertexes, triangles, or lights in the Core Animation API. It's a layer kit, remember? Think "non-intersecting 2D planes in space."

But what planes they are. To start, each layer has the following properties: geometry, background, contents, border, filters, shadow, opacity, and mask. Each layer can have zero or more sub-layers, and the filters are Core Image filters, of course. But the layer contents are the really interesting part.

At some point during pretty much every WWDC since the introduction of Mac OS X, an Apple engineer has explained how to mix content produced by different APIs: drawing styled text on top of an OpenGL scene, putting a standard button or checkbox over a QuickTime movie, applying a Core Image filter to part of a dialog box, and so on. These demonstrations were complicated, often involving special overlay windows, manual color space conversions, and wasteful data duplication. Inevitably, the Apple engineer would apologize as he demonstrated, acknowledging that this kind of thing really shouldn't be as hard as it is. Well, in Leopard, thanks to Core Animation (of all things), it's now nearly trivial.

Core Animation layers provide, for the first time in Mac OS X, an easy way to mix all supported content types without restrictions: QuickTime video, OpenGL, Core Graphics drawing, Quartz Composer scenes, standard GUI controls like buttons, checkboxes, and pop-up menus, styled text, you name it. Composite them, layer them, animate them; it all just works. In effect, Core Animation is the unification of all things graphical in Mac OS X.

Layers are animated declaratively, rather than procedurally. For example, to make a layer fade out, simply set its opacity to zero. Rather than instantly becoming invisible, the layer will fade out over a period of time (0.25 seconds, by default). In other words, tell each layer its goal state and (optionally) a few more pieces of information about the transition, and the Core Animation engine handles the actual process of changing the layer from its current state to the goal state. Though all of the animation settings are optional and have sane defaults, animations have configurable durations, timing curves, keyframes, and transition types. Also, multiple property changes can be batched into a single atomic change.

Under the covers, each Core Animation layer is handled by OpenGL and ends up in VRAM on the video card. (For layers that are beyond the maximum texture size of the video card, Core Animation provides a "tiled layer" API, with callbacks to retrieve each portion of the larger image as needed.) Core Animation layers are extremely lightweight; modern Macs can animate many thousands of layers simultaneously. The unification of content types in Core Animation layers provides an opportunity to consolidate many previously separate GPU acceleration mechanisms for video, 2D drawing, and animation into a single context.

The underlying technology really is impressive, but the big win comes on the more prosaic end: the way this functionality is exposed to the developer.

Core Animation in Cocoa

Unsurprisingly, Core Animation is a Cocoa API. Politics aside, it's a good fit. Cocoa has existing conventions for observing changes to object properties, and Core Animation ties right into that. But the real genius is in the how little work is required to start using Core Animation in an existing application.

The process for developers is simple. To enable animation of a view, check off the appropriate checkbox in Interface Builder, or make the corresponding [view setWantsLayer:YES] call at runtime. Doing so creates a Core Animation layer for the view and all subviews it contains. The result is two view trees: the collection of "normal" views and subviews that have always existed in your Cocoa application (windows, buttons, etc.) and another, parallel hierarchy of Core Animation layers representing the subset of normal views that have their "wants layer" property turned on.

Each layer-backed view has an animator attribute. Method calls that affect animatable properties are animated when made through this object and are not animated when made through the view itself. For example, let's say you have some existing code to set the size of a window in your application:

[view setFrame:rect];

To animate that using Core Animation in Leopard, causing the window to smoothly scale from its current size to the new size using a GPU-accelerated, OpenGL-based compositing animation engine running on a separate thread, you must type eleven more characters, changing the line above to this:

[[view animator] setFrame:rect];

This is usually the point in the WWDC presentation where Cocoa programmers unfamiliar with Core Animation begin to drool and moan.

Yes, obviously it gets more complicated if you want to customize the animation, but only slightly. In the common case, adding animation to your existing Cocoa application really is as simple as the example above implies. As a first pass, just send all the method calls you want to animate through the animator property. As an optional second pass, customize the few animations you want to go faster or slower or do something else fancy. There is no step three, as they say. No OpenGL code, no custom drawing, no GPU programming. Ahh.

Apple has gone hog wild with Core Animation, both in its own applications and in Cocoa itself. All the basic visual properties of views can be animated—plus some esoteric ones like rotation. Yes, if you have the urge to create spinning buttons or slanted windows, Core Animation is there for you. You can even add new animatable properties to your custom views.

Apple's also created several new Cocoa views and controls that provide functionality that would have required many thousands of lines of complex code before the advent of Core Animation. The best example is the extremely flexible NSGridView. This one view can be used to create something that looks and behaves like the iChat buddy list or the Dock, all with extremely minimal code. Items fading in and out as they're removed, squirming out of the way to accept a drag, flying all over to re-sort themselves, even text-base searching and visual filtering—it's all basically "free" with NSGridView and Core Animation.

Separation of concerns

As alluded to earlier, the animation part of Core Animation runs on its own thread and has its own run loop independent of the application itself. These two parallel worlds—the application view hierarchy and the Core Animation view hierarchy that backs some portion of it—are largely divorced. Communication happens implicitly when the application changes some part of its visual state.

For example, let's say an application moves an element in a window from position A to position B. From the perspective of the application code, the change happens instantly. The item that was in position A moves immediately to position B as soon as its coordinates are changed.

In the parallel world of the Core Animation engine, however, the move from A to B happens over several frames of animation and takes some time. This means that there's a transitory mismatch between where the application thinks the element is, and where it actually appears on the screen. This usually isn't a problem, but developers are encouraged to take precautions to prevent any strange effects (e.g., by disabling controls while they're in motion, reenabling them when the animation completes).

But that's about the only ill effect of this arrangement. The benefits are much more substantial. For starters, with today's multicore CPUs, putting Core Animation on its own thread is a clear win in terms of CPU utilization. It also means that the application can blindly make changes any old time it wants, without concern for the state of any outstanding animations. For example, an application can move an item from A to B, then move it again to C before the A-to-B animation completes. The Core Animation engine will take it all in stride, smoothly animating the item towards C from whatever position between A and B it was in when the application initiated the move to C.

The application's total lack of (mandatory) involvement in the animation itself is incredibly freeing. It prevents applications from becoming filled with animation-centric code. Gone are the days of preference dialogs with 50 lines of code for getting and setting preferences and 200 lines of code for creating cross-fades and autoresizing panes. Less application code means fewer bugs and more freedom for Apple to optimize the actual drawing and animation process.

The animation age begins

Yes, the advent of Core Animation probably means that we'll have to endure some amount of gratuitously animated software created by "overly enthusiastic" developers. But the same was true during the introduction of styled text and color graphics. Mac developers learn quickly, and Mac users are good at rewarding restraint and punishing excess.

The minimal, almost humble way Core Animation integrates with Cocoa belies its incredible sophistication. More so than any other new framework in Leopard, Core Animation provides functionality and performance that was previously difficult or impossible for the average Cocoa programmer to create on his own. Now, finally, third-party applications can look as impressive as Apple's, and they can do so by using exactly the same code that Apple's using—code written by expert graphics programmers and continually revised and improved by Apple to take advantage of the latest hardware. Excellent.

Quartz GL

I spent several pages of my Tiger review exploring how Mac OS X's Quartz display layer has evolved over the years, specifically how functionality has been migrating from the CPU and main memory to the GPU and VRAM. Tiger was to bring the latest step in that evolution, Quartz 2D Extreme, which would finally move execution of the drawing commands themselves to the GPU, writing the results directly to VRAM.

I dedicated so much time (and so many sweet OmniGraffle charts) to Quartz 2D Extreme because it was one of the Tiger technologies that I was most excited about. I'd waited a long time for it, slogging through Mac OS X 10.0 where every part of the drawing and compositing process happened on my poor 400MHz G3 CPU, with the expectation that, someday, it'd all happen in dedicated hardware.

Sadly, though the Quartz 2D Extreme code was indeed included in Tiger, it was disabled by default. At the time, I speculated that it might be enabled in a subsequent update, "perhaps as early as version 10.4.1." Ha! Over two years later, Tiger has reached version 10.4.11 and Quartz 2D Extreme is still disabled by default.

But surely—surely—Quartz 2D Extreme will be enabled in the mighty Leopard, right? When it comes to moving drawing code to the GPU, maybe we should all get used to disappointment.

First things first. Quartz 2D Extreme, always quite a mouthful, has been renamed Quartz GL in Leopard. I'm heavily in favor of the evisceration of "Extreme" from all Apple product names, so yay. Second, it's important to understand why Quartz GL was disabled in Tiger for all those years. Apple's never made any public statements about this, but developers who've asked have gotten a pretty consistent message. What it boils down to is differences between Quartz GL and the "old" more CPU-centric implementations of Quartz—differences that actually affect existing applications.

Bugs are the most obvious issue. Quartz GL was brand new in 10.4.0, a release that had enough of its own problems without globally applying a new drawing engine to all applications. The other important issue was explored in the Tiger review: Quartz GL can actually make some applications slower because the "best practices" when writing for a CPU/RAM-centric Quartz implementation are often exactly the opposite of those for Quartz GL.

So what's changed in Leopard? Presumably, most Quartz GL bugs have been squashed, but the performance issues are really up to application developers to address by changing their code. But why would they be motivated to change their code? After all, Quartz GL is disabled in Tiger. This chicken/egg situation explains why Quartz GL is not globally enabled in Leopard either.

Unlike in Tiger, however, applications in Leopard can explicitly enable Quartz GL, either for the entire application or just for specific windows. This allows each developer to choose when and where to use Quartz GL. It's a good compromise; there's actually nothing to be disappointed about. Quartz GL, like many Leopard technologies, will surely begin to seep into the applications we use every day. It may not be as obvious as something like Core Animation, but in the long run it's just as important.

Resolution Independence

Speaking of technologies present in Tiger but never enabled, resolution independence takes a few more steps forward in Leopard. A brief refresher: simply stated, resolution independence, also sometimes called "scalable user interface" or "high DPI support," is the ability to draw user interface elements using more pixels.

For example, the little red "close" widget in the window title bar uses about 16x16 pixels at the default ("1.0") scale factor. This is okay for screens that use around 100 pixels per inch (PPI), but on a 200ppi monitor it would be quite a small click target. Using a scale factor of 2.0, this same widget would be drawn using 32x32 pixels—four times as many. That would make the click target exactly the same size as the 16x16, 1.0 scale factor version on a 100ppi screen. The 2.0 scale factor version would also be more detailed, since it uses more pixels.

The benefits of resolution independence are twofold. On the high end, displays with much greater pixel density become feasible now that there's a way to prevent the widgets that make up the UI from shrinking to unclickably small proportions. In particular, text will look a lot sharper as the display's PPI rating begins to approach the DPI rating of modern printers.

On the low end, resolution independence allows users with poor vision to make everything on their existing low PPI displays larger, while actually increasing the amount of detail (as opposed to current "screen zooming" feature that magnifies the existing pixels into an increasingly blurry mess).

In Tiger, the user interface scale factor control existed only in the Quartz Debug application (part of Apple's free developer tools). In Leopard, the user interface scale factor control... exists only in the Quartz Debug application. Sorry.

Actually increasing the scale factor provides a pretty convincing demonstration of why this is so. Take a look at the nonuniform gaps in the segmented control in this screenshot of TextEdit at a 2.0 scale factor.

As you can see, there are still plenty of rough edges even for the simplest of applications. Since interface scaling has a global effect, it can't be enabled piecemeal like Quartz GL.

Unlike Quartz GL, Apple has actually provided a pretty clear message to developers about resolution independence. There have been sessions at the past few WWDCs about how to prepare applications to run properly at scale factors above 1.0. The real hold-up has been Apple itself, however, which doesn't quite have resolution independence working correctly across all of Mac OS X's GUI frameworks. Also, the exact details of how resolution independence will interact with the various APIs have changed as recently as WWDC 2007.

Nevertheless, the rumored date for resolution independence to appear as a user-visible feature in Leopard is 2008. Early 2008? Late 2008? If Apple knows, it's not saying. And so the question posed two years ago still stands. Which will come first, affordable high-PPI display hardware or a resolution-independent version of Mac OS X? The wait continues.

But that's not all there is to say about resolution independence in Leopard. In fact, you might say there's one more thing...

Core UI

Resolution independence is a fine idea, but there's the pesky issue of exactly how to draw all those user interface widgets using more pixels. When resolution independence finally arrives in 2008 (or whenever), will the Mac OS X UI be drawn entirely using infinitely scalable vector art? That'd sure solve the problem of where to get all those extra pixels, but I'm not a fan of this approach. How about simply including huge bitmaps for each interface element, relying on the traditional bitmap scaling mechanisms to draw them at the smaller sizes? That'd work fine, but it does seem kind of wasteful to use giant bitmaps for thing like line art and basic shapes which are oh-so-compactly represented by vectors.

Hey, what do we have here lurking under /System/Library/PrivateFrameworks in Leopard? Why, it appears to be a new framework: CoreUI.framework. Whatever could that be for? Surprise! Every piece of the user interface in Leopard is being drawn in an entirely new way that incorporates the best of the bitmapped and vector styles.

Let's take a look at the moving parts. Core UI draws each piece of the user interface based on a series of XML "recipes" that describe the structure and features of each element, referencing pieces of art stored as separate resources files within the framework bundle. Here are just a few example recipes:

/System/Library/PrivateFrameworks/
  CoreUI.framework/Resources/AquaUI.bundle/Contents/Recipes/
    checkbox.xml
    disclosurebutton.xml
    disclosuretriangle.xml
    menu.xml
    menubar.xml
    progressindicator.xml
    pushbutton.xml
    radiobutton.xml
    roundbutton.xml
    scrollbars.xml
    splitter.xml
    syncarrow.xml
    ...

Note the storage location: the Core UI framework contains other bundles which in turn contain the recipes and resources. It's hard not to look at this arrangement as a kind of theming engine in the tradition of Kaleidoscope, ShapeShifter, and of course Apple's own Appearance Manager... albeit an engine that's closed to outsiders and likely to change in the future. But still, it's quite a departure from the comparatively inflexible approach to drawing the UI used in Tiger and earlier. At the very least, the new recipe/resource structure lays bare the components that make up what's shown on the screen.

Take the humble checkbox, for example. The checkbox.xml file is a dizzying 2,800+ lines long, most likely created by Apple's long-rumored (to those paying attention) in-house Core UI theming tools. It references a figure named checkmark, represented in the Resources directory by the checkmark.pdf file.

In that same directory you'll also find various "material" bitmaps. Here are two examples (scaled down from their actual 398x398 pixel sizes):

Keep in mind that these are not giant radio buttons; bitmaps like these are used as texture sources for widgets of all shapes and sizes.

Finally, here's what a checkbox looks like in Leopard at various scale factors.

You can see how this all starts to come together. Browsing through the full set of resources reveals an unsurprising division of labor between big bitmaps (PNGs) and vector graphics (PDFs). Anything that looks like line art or is a basic shape is done with vectors. The "lickable" bits, on the other hand, are still represented by (presumably hand-tweaked) bitmaps, usually in very large sizes. In particular, the way Core UI constructs the various shiny Aqua widgets using a suite of "materials" bitmaps—some for highlights, some for backgrounds, and so on—is a nice way to conserve memory while still using hand-drawn art.

So what does this all mean for Mac OS X? Well first, it means that Apple is ramping up for resolution independence. We knew that already, but it's still nice to see how far along things are. Remember, even at the default (1.0) scale factor that Leopard will ship with, all the UI widgets you see are being drawn by Core UI. This wasn't always the case. Earlier Leopard seeds only used Core UI at scale factors greater than 1.0, falling back to the old way for 1.0. The move to using Core UI everywhere shows some confidence in the technology.

Core UI also means that Apple is well-positioned to deliver the radical change to Mac OS X's appearance that I longed for in Leopard. Core UI is certainly not a general-purpose engine capable of creating any appearance an artist can dream of. It's clearly focused on creating Aqua-like appearances, with baked-in support for things like drop shadows and highlights. But the general approach of using XML recipes to compose vector and bitmap resources is a sound one that will last Apple a very long time, well into the coming age of resolution independence.

Internals grab bag

These "grab bag" sections give me a chance to briefly touch on interesting features that don't warrant their own sections—or, quite often, that time constraints have prevented me from expanding into entire sections. For the first time, I'm giving the internals their own grab bag, to separate the more technical bits from the later grab bag that covers more user-visible features. Put another way, this is the grab bag without screenshots. Here we go.

Metadata in action

Leopard is the first Mac OS X release to really take advantage of the extended attributes APIs added in Tiger. When faced with a problem that requires the storage of some information about a particular file or directory, Apple is finally using (gasp!) file system metadata to implement this. It's everywhere in Leopard. Just look at these extended attribute names:

• com.apple.metadata:kMDItemFinderComment—Finder comments in real metadata. (They're also still stored in the .DS_Store files, presumably for compatibility with pre-Leopard systems).
• com.apple.quarantine—Tagging files downloaded from the Internet as possibly untrustworthy, storing the application used to download them, among other things.
• com.apple.backupd.SnapshotVolumeLastFSEventID—One of a whole suite of extended attributes used by a certain backup feature to be described later.

It's enough to make me shout "Hallelujah!" Apple finally gets it! See how useful this stuff is? Just imagine the insane contortions the pre-metadata-enlightenment Apple would have gone through to store and track all this stuff, each application going off in its own direction with a custom implementation. So much wasted effort, so many unique bugs. No more! Extended attributes provide a general-purpose facility for doing the same things, written and debugged in one place.

Leopard even includes a command-line utility for viewing and modifying extended attributes. Readers may recall a similar utility called xattr, created by Marquis Logan for my Tiger review. Apple's own utility actually has the same name, but slightly different command-line options.

Other commands in Leopard have also become extended attributes-savvy. For example, the ls command now displays a "@" character after the permissions string for each file that has extended attributes. Wandering around a Leopard system using the ls and xattr commands will reveal just how much Apple has taken file system metadata to heart. It's about time.

Core Text

Mac OS X finally has a single, official, standard text drawing and layout API: Core Text. (As far as I know, this "Core" technology does not get its own lickable sphere icon.) Core Text replaces the confusing alphabet soup of text APIs in Mac OS X Tiger and earlier, mostly inherited from classic Mac OS: ATSUI, MLTE, and QuickDraw text.

Core Text has a cleaner API, it's faster, it's available in 64-bit, yada yada. I mention it here for two reasons. First, it's interesting because Core Text actually existed in Tiger as a private API. It was used by Apple's own applications as a sort of test bed for the framework. Leopard is its coming-out party, now that it's been properly refined.

It's similar to the FSEvents situation, but in that case Apple decided that the private API that was "auditioned" in Tiger (/dev/fsevents) was not suitable for public consumption, and another solution was needed. Perhaps /dev/fsevents, unlike Core Text, was never intended to be public, but maybe it just appears that way in hindsight. Either way, keep your eye out for private frameworks in Leopard that could be up for publication in 10.6.

Second, Core Text is an indicator of how young, in relative terms, Mac OS X really is as a platform. Here's Leopard, ostensibly a mature product in its sixth major release, just now getting a standard text layout API? As mature as Mac OS X may seem, it was quite a mishmash of technologies at its birth: a little BSD Unix here, some NeXT there, and a bucket of classic Mac OS splashed on top. This is all going to take a long time to sort out. Leopard takes some important steps towards the future by deprecating several old technologies and anointing their successors.

Code signing

Leopard supports cryptographically signed applications. This topic rings alarm bells for some people. The controversial Microsoft Palladium initiative increased public awareness of the issue several years ago when Microsoft misjudged the market and ended up evoking a bleak future of iron-fisted corporate control rather than the security utopia they were trying to pitch. To this day, it's hard for some people not to see all such efforts as opportunistic power grabs dressed up as "security" features.

The first thing to understand about code signing in Leopard is that it's not presented as, nor is it capable of anything so grand. It's not going to give Apple (or anyone else) complete control over your system, nor is it going to provide impenetrable security.

Here's what it actually does. Code signing ties a cryptographically verifiable identity to a collection of code and ensures that any modification to that code is detected. No guarantees are made about the parties involved. For example, if you download an application signed by Acme Inc., you can prove nothing about it except that it came from the same entity claiming to be Acme Inc. the last time you downloaded something from their web site.

This example actually highlights the most useful application of the technology from a consumer's perspective. When upgrading a Mac OS X application today, the user is often prompted to re-verify that this application is allowed to access the Keychain to retrieve usernames and passwords. This seems like a good security feature, but all it really does is train Mac users to blindly click "Always Allow" each time it appears. And really, what is the average user going to do, run the executable through a disassembler and manually verify that the code is safe?

A signed application, on the other hand, can mathematically prove that it is indeed a new version of the same application from the same vendor that you expressed trust for in the past. The result is an end to dialog boxes asking you to confirm a choice whose safety you have no reasonable way to verify.

In the end, it still all comes down to trust. Either you trust software from Acme Inc., or you don't. That's up to you to decide. Signed applications are just as capable of erasing your hard drive and stealing your passwords as unsigned applications.

But unlike unsigned code, a signed application cannot be tampered with after installation. If an application from Acme Inc. does something malicious, you can be sure that it's not because it's been hijacked by some other bit of malware. Put another way, well-behaved code will continue to be well-behaved. Any attempt to modify it will stop it from running entirely.

Apple has signed all applications that ship with Leopard. I expect most reputable third-party developers to do the same eventually.

Code signing also means an end to the practice of applications modifying themselves (e.g., saving custom theme files inside the application bundle itself rather than in ~/Library/Application Support/MyApp or another user-specific location). This practice has always been discouraged by Apple, and now there's another reason avoid it.

So, to review, code signing does:

• Provably seal code
• Verify the identity of the sealer

Code signing does not:

• Impart special privileges
• Protect against bugs
• Protect against misplaced trust
• Provide copy protection
• Enslave you in The Matrix

It may be just a small step towards increased security, but it's one that's done right.

ASLR

Speaking of security, Leopard also supports address space layout randomization, or ASLR. The name pretty much explains it: ASLR moves stuff around in memory to make it harder for malicious software to predict the address of a particular piece of code. Apple still has a long way to go to reach Microsoft's current level of paranoia about security, but then Mac OS X has not been subjected to the same kinds of malware pressures that Windows has. Still, it's nice to see Apple taking some initiative in this area rather than waiting for disaster to strike and then reacting.

LLVM

LLVM stands for low level virtual machine. It's an open-source project that Apple has taken under its wing, hiring the lead developer and actively improving the code. You can read all about what LLVM can do at the project's web site. The explanations you'll find there are kind of impenetrable if you're not already familiar with compiler technology, however. The best way to think of LLVM is right there in the name: it's a virtual machine, but one that models something quite low-level, more like a CPU than a traditional virtual machine that models an entire PC.

Why model something so primitive? Who wants to write code that targets a virtual CPU? Well, compilers, for one. The idea is that you produce code in LLVM's platform-neutral intermediary representation (IR) and then LLVM will optimize it and then convert it to native code for the real CPU of your choice. This conversion can be done ahead of time, producing a traditional executable, or you can ship the platform-neutral byte code as-is and let LLVM compile it just in time (JIT).

Why bother with the LLVM middleman? Why not let the compiler produce native code on its own? That's what most compilers do. Unfortunately, they do so with varying degrees of quality. The aim of LLVM is to provide a set of modular compiler components that anyone can use, in order to concentrate the optimization efforts currently spread among many different compilers into a single project, thus the use of a platform-neutral intermediary representation.

Think of it as a big funnel: every sort of code you can imagine goes in the top, all ending up as LLVM IR. Then LLVM optimizes the hell out of it, using every trick in the book. Finally, LLVM produces native code from its IR. The concentration of development effort is obvious: a single optimizer that deals with a single format (LLVM IR) and a single native code generator for each target CPU. As LLVM gets faster and smarter, every single compiler that uses LLVM also gets better.

So, that's the pitch. The reality is that it will take a long time to convince the compiler world of the merit of this approach. Apple, however, is already on board. In Leopard, LLVM is used in what might strike you as an odd place: OpenGL.

When a video card does not support a particular feature in hardware (e.g., a particular pixel or vertex shader operation), a software fallback must be provided. Modern programmable GPUs provide a particular challenge. OpenGL applications no longer just call fixed functions, they can also pass entire miniature programs to the GPU for execution.

Prior to LLVM, Apple implemented software fallbacks for all of this using its own custom JIT compiler for programmable GPUs. Apple wrote native code for each primitive operation (e.g., a dot product). These chunks are then glued together at runtime to produce the CPU equivalent of the mini-program intended to go to the GPU.

This approach severely limits the scope of possible optimizations. Any transformation that spans more than one primitive operation is extremely difficult, leaving only the relatively weak and simple optimizations within each primitive.

Still, Apple was content with its custom JIT when it only had to target 32-bit PowerPC CPUs. But as 64-bit PowerPC and later 32-bit and 64-bit Intel CPUs joined the platform, updating that JIT for all the new architectures (and features like SSE, SSE2, SSE3... ) started to get a bit hairy.

A custom compiler with weak optimization abilities and an ever-increasing number of target CPUs? LLVM to the rescue! In Leopard, each primitive is contained in an LLVM byte code library file (search for files with a .bc extension). Mixing calls into those byte code libraries and just-in-time compiling them into a single, comprehensively optimized chunk of native code? No problem; that's what LLVM is designed to do.

Predictably, LLVM rocks the house in this application, performing up to several hundreds of times faster than Apple's old custom JIT for certain operations that the old system couldn't even JIT, but had to interpret instead. Perhaps the biggest win is that Apple's OpenGL group no longer has to maintain its own JIT compiler. The best kind of code is no code at all.

Don't be misled by its humble use in Leopard; Apple has grand plans for LLVM. How grand? How about swapping out the guts of the gcc compiler Mac OS X uses now and replacing them with the LLVM equivalents? That project is well underway. Not ambitious enough? How about ditching gcc entirely, replacing it with a completely new LLVM-based (but gcc-compatible) compiler system? That project is called Clang, and it's already yielded some impressive performance results. In particular, its ability to do fast incremental compilation and provide a much richer collection of metadata is a huge boon to GUI IDEs like Xcode.

I know this LLVM subsection is quite a digression, but even if it's only used in a limited capacity in Leopard, LLVM is quite important to the future of Mac OS X. Indeed, it could also be important to the present of the iPhone and other OS X platforms.

I'm not sure how the iPhone supports all the visual effects used in its interface, but it's not unreasonable to imagine that Core Animation, OpenGL, and an LLVM-based software fallback are crucial to getting this all to hum on a platform with a relatively weak GPU and CPU. And did I mention that Apple recently did some extensive work on the LLVM ARM backend? You know, ARM, the CPU used by the iPhone. Yeah, the pieces sure seem to fit.

Anyway, thanks for the indulgence. If you want to learn more about the latest LLVM developments, check out the video of an LLVM presentation at Google given by Chris Lattner, LLVM lead developer and Apple employee.

Objective-C 2.0

I briefly mentioned the new Objective-C runtime in the 64-bit section. This is part of the larger revision to the Objective-C language known as Objective-C 2.0. The version-based branding is apt because Objective-C's abilities hinge so heavily on the runtime library at its core. This library handles class introspection and extension, method dispatch, and in the 2.0 version, memory management as well.

That's right, the biggest news in Objective-C 2.0 is that it supports garbage collection. This is an opt-in feature, and a single code base can be compiled both with and without support for it. When garbage collection is enabled, all manual memory management calls are simply ignored. This is how all of Apple's Objective-C libraries in Leopard are written; they work with garbage collection enabled or disabled.

For developers, Objective-C 2.0 includes several features that formalize common idioms. For example, there's now built-in support for simple accessor and mutator methods for object properties. Writing many such methods is tedious and prone to mistakes. Since the best practices are, by now, well defined, Apple simply added properties as a "native" feature of the language. I put native in quotes because it really boils down to a form of syntactic sugar, but a little sugar is a good thing.

Objective-C 2.0 is a big step forward for a language that has not changed much in the past decade or so. Though Objective-C is open-source and is supported by the GNU C compiler, Apple effectively "owns" Objective-C in the same way that Microsoft owns C#. Apple is, by far, the heaviest user of the language and has the most stake in improving it. Objective-C 2.0 is a declaration of this ownership, and it appears uncontested. Mac developers, meanwhile, are lapping it up. But my eyes are on the future.

During the introduction of Objective-C 2.0, Apple was careful to put the change in context, declaring that Objective-C 2.0 is "not focused on revolutionary changes to your development world to achieve the next generation development environment" (emphasis added). That's all well and good, but then what is going to bring that "next generation development environment"?

I've been flipping out about this for years now, and the pressure just keeps mounting. What's Apple's plan to transition to a dynamic, fully memory-managed development environment? I did a three-part blog series on the topic (1, 2, 3) back in 2005 with the intentionally provocative title, "Avoiding Copland 2010." (The year 2010 is actually probably a few years before the crisis point.) In it, I pooh-poohed Objective-C with garbage collection as an unsuitable long-term solution. It appears that Apple agrees with me, but that still leaves the problem unsolved.

I'm sure there are Mac developers reading this that don't see any problem at all, in 2010 or otherwise. I could go off on another tangent about how programmers always seem to think the language they're currently using provides exactly the right amount of abstraction for the task at hand, with anything less dynamic being considered barbaric, and anything more dynamic seen as crazy and unsafe, but I'll spare you and save it for a blog post.

In the meantime, the take-home point related to Leopard is that Objective-C 2.0 is a good thing. The additions to the language make Objective-C much more pleasant to use and easier to learn. The new runtime is cleaner, faster, and more capable. Garbage collection, if it becomes as pervasive as it ought to, will help train a new generation of Mac developers to surrender one more bookkeeping function to the computer. If there's a cliff up ahead, at least Apple's picking up speed and starting to build a ramp. I just hope there's something on the other side to land on by the time we hit the edge.

The Finder

Here's what I had to say about the Mac OS X Finder two years ago.

Over the years, the Mac OS X Finder has gained a well-deserved reputation as the least pleasing bundled Mac OS X application. [...] While some people like it, few love it, and many hate it.

To a casual observer, this might appear a bit extreme. The Mac OS X Finder seems, if not glamorous, then at least benign. What's the big deal? The bad feelings about the Finder don't spring from a single source. There are at least three distinct threads of Finder dissatisfaction, usually appearing in combinations of two or more in any given Finder malcontent.

I went on to describe those three threads of dissatisfaction: spatial/browser-mode interaction, performance, and "the little things." That summary is still worth reading; all three pillars of Finder angst remain relevant in Leopard.

They're relevant partly because the Leopard Finder makes an effort to address each one directly. "Address" does not mean "resolve," however. But first, some good news.

Performance

The Leopard Finder seems to have finally sorted out how to deal with most network resources without locking up its entire user interface. I know there have been false alarms about this in the past, but I think Apple really did it this time.

Case in point: iDisk. Even when .Mac is extremely slow to respond, the iDisk window appears instantly. Granted, the window may be empty for some time as the Finder waits for .Mac to send data, but the important point is that control is immediately returned to the user. Put that iDisk window aside and come back to it later when it's finished loading; you can continue your work elsewhere. Ah, blessed sanity.

This applies to local folders too. I can open a folder with over 10,000 items in it and then immediately switch to another Finder window and do something else while it loads. But I shouldn't really bother because it'll load in only a second or two. Scrolling through 10,000 items still has a few hiccups, but it seems mostly i/o bound now, as it should be. The dreaded beach ball never appears during this exercise.

Problems still lurk, however. For example, connecting via FTP (sorry, still read-only), putting the server to sleep, then attempting to open a folder on the server will sometimes result in some quality beach ball time. The timeout seems reduced from Tiger, however. The "Server connection interrupted" dialog appears in about fifteen seconds.

Other times, it works just like the iDisk case: a new window appears with a spinning progress indicator in its status bar, and control returns to the user immediately. I don't know why the beach ball appears so sporadically, but it's still a refreshing change from the days when it was omnipresent.

Disk i/o in general feels snappier in the Leopard Finder. The most prominent example is how quickly icon previews are generated. Perhaps it's not so much that they're generated quickly, but that the task is accomplished with so little fuss. The disk ticks, the generic icons are replaced with previews, and all the while the Finder remains responsive to other actions.

Overall, I have to say this is the most significant performance improvement in the history of the Mac OS X Finder. There's still more work to be done on the dark corners of network connectivity, but the underlying issues seem to have been addressed.

The little things

The Leopard Finder goes a long way towards fixing all those niggling little issues that have been driving people nuts for years. In fact, several of my own personal peeves have been addressed. Keep this positive outlook in mind as I embark on one last rant about how long this has all taken.

I'll start with two screenshots (highlights added).

It's hard for me not to use profanity at this point, so thoroughly do these two additions infuriate me. On the one hand, I've been wishing, hoping, and sometimes begging for these features for years, and I'm glad to finally see them in Leopard. But on the other hand, actually using these features and experiencing how much more pleasant they make my daily life on the Mac—as I knew they would—only reminds me of how stubbornly Apple refused to add them for the past six years!

Oh, the agony inflicted for want of such simple features! In the case of the icon grid spacing adjustment, this is something that existed in a lesser form (only two settings: tight and wide) in classic Mac OS and was dropped during the transition to Mac OS X, like so many other features, without explanation or justification. Worse, the spacing between icons was expanded to a comical size in Mac OS X 10.0 and never recovered. It always seemed to me to be some sort of punishment for daring to use icon view. Just look at this screenshot from Tiger showing the Applications folder with 48x48 pixel icons, scaled to 50 percent of its original size.

Icon view in Tiger

Apparently the super-secret technology that enables adjustable grid spacing has finally been rediscovered at Apple, presumably in a huge warehouse filled with identical-looking crates of classic Mac OS technology. Here's a screenshot of the same folder with the same 48x48 icons, scaled to the same 50 percent of its original size, when viewed with sane icon spacing in Leopard.

No names are truncated, every single icon is visible, and the window uses about half the number of pixels. Amazing, this modern world we live in.

As for the warning when changing file name extensions, it's a reasonable thing to do in a system where (unfortunately) file name mangling is the official way to encode file type metadata. It's the inability to disable the warning that's so obnoxious. Again, the changes required to do this are not complicated. Why did it take so long?

I'm sure the words "limited resources" and "priorities" would appear in any explanation Apple would give (as if they'd ever give one, ha), but ironically, I think that misses the bigger picture. What we have here is a textbook case of priority inversion: two seemingly insignificant features held back for years, unnecessarily fomenting ill will by needling users on a daily basis, effectively blocking the higher priority task of making a Mac OS X Finder that everyone can enjoy using—or, put less charitably, that fewer people loathe.

Obviously, everyone's pet features can't be added, but at a certain point the ratio of "ease of implementation" to "annoyance caused by their absence" tips over in favor of features like this. There were already enough legitimate reasons for people to hate the Finder. Leaving little annoyances like this around for so long was just rubbing salt into the wounds.

Okay, rant over. Adjustable grid spacing and the ability to silence file renaming warnings are finally here in Leopard. These tiny features will make a disproportionately huge improvement in the lives of many thousands, perhaps millions of users. Apple gets full credit for recognizing the worst offenders and fixing them. The fact that it took so long is a shame, but much better late than never.

New views

The new Finder also has some interesting new features. We'll start with the visual.

The Leopard window look suits the Finder well, blessedly excising the fat borders of its metal ancestors. On the down side, the browser sidebar has adopted the iTunes look, with the obnoxious ALL CAPS headings and custom highlight style.

As you can see above, list view items now have alternating background colors—a welcome change. Cover Flow continues its march through Apple's product line, now appearing in the Finder as well as iTunes, iPhone, and iPod.

Smart folders get a place in the sidebar, with the default set shown above. As usual, a good selection of defaults goes a long way towards making a feature more useful. Even for people who have no idea what a smart folder is, the Today, Yesterday, and Past Week items are immediately understandable and useful.

By default, any smart folder created will initially appear in the sidebar. Drag it off and watch it go poof. Drag it back on and it can go in either the PLACES or SEARCH FOR sections (so obnoxious... ). Smart folders remain plain XML files that are simply treated specially by the Finder.

Finally, icon previews get even more aggressive in Leopard. The Finder goes to great lengths to provide previews for even the most mundane and inscrutable of file types.

The squinty text seems kind of silly, but believe it or not, you can actually make out the basic structure of the document (well, the first page, anyway) even at icon sizes smaller than those shown above. And as you'll soon see, a quick preview of the file's contents is only a keystroke away.

Quick Look

The new Quick Look feature, denoted by the stylized eye icon in the toolbar, provides a surprisingly fast and rich preview of file contents. Its keyboard shortcut is particularly convenient. Just select any file and hit the space bar to see a preview. Here's an example.

Most of the time, the black-tinted Quick Look pane pops up instantly. This responsiveness makes the feature much more likely to be used. The speed extends even to more complex document types, such as PDFs, in which the "preview" isn't far removed from actually opening the file.

That's a resizable, page-able view of the entire PDF. The dual arrows at the bottom expand it to full-screen, providing a nice way to do a quick presentation.

Quick Look has a plug-in architecture similar to Spotlight. Developers must create plug-ins that can read their own proprietary document types and generate previews. Leopard ships with plug-ins for most standard file formats.

Spotlight

Spotlight's crazy orphan search windows are gone in Leopard, leaving only its incarnation in the Finder—and a greatly improved incarnation, at that. Check it out.

Spotlight search: nested boolean logic!

Yes, that's right, nested boolean logic is finally supported! Just option-click on one of the circular "+" widgets to create a new nested clause. Combined with the aforementioned rewrite of the Spotlight indexing system, the new file search interface is now what it should have been all along: powerful, understandable, and fast.

Access control lists

Access control lists, introduced in Tiger but disabled by default, are now enabled by default in Leopard. The Finder's "Get Info" window includes a new pane for adjusting them.

Changes made to this pane that fall within the realm of standard Unix permissions are handled as such. Any rules that go beyond that will trigger the creation of an ACL. It's a nice unified GUI for concepts that are only separate internally for historical reasons.

(Note that the GUI provides only the basic options: read only, write only, and read/write. You still have to resort to the chmod command for more fine-grained control.)

Screen sharing

Leopard has extensive support for screen sharing—that is, the ability to see another computer's screen in a window on your Mac and (optionally) control that computer with your mouse and keyboard—using the VNC standard as well as Apple's own Remote Desktop protocol. Both the client and server are included in Leopard, and the Finder is the gateway to the client. Browsing a networked computer that has a server for one of the supported protocols enabled will reveal a "Share Screen" button.

Clicking it will launch the Screen Sharing application which is surprisingly capable, including many features absent from the pre-Leopard versions of the commercial Apple Remote Desktop product. In particular, scaling and adaptive quality control make this client noticeably faster.

In the screenshot above, I've scaled the remote computer (a Mac running Tiger and Apple Remote Desktop) to an extreme degree, but it's still fully functional and surprisingly usable even at this tiny size. The preferences dialog in the front belongs to the Screen Sharing application, as does the toolbar with handy "Send to/from Clipboard" buttons on it.

The Screen Sharing application is hidden in /System/Library/CoreServices, but can be launched manually and used to connect to another computer if you know the IP address. You'll be prompted for a username and password, with the option to explicitly request permission to share the screen.

(Screen sharing is also built into iChat, though it appears to require both participants to be running Leopard. URLs in the form vnc://... will also work in the Finder.)

If you are your family's "Mac guy," the newfound ubiquitousness of screen sharing alone is reason enough to get everyone to upgrade to Leopard.

An application divided against itself

The Finder still can't quite decide what it wants to be when it grows up, a file browser or a spatial file manager. A clean separation of concerns would allow it to be both, but this is a solution that Apple has thus far avoided.

In Leopard, the two window types remain: the sidebar/toolbar-sporting "browser" window style, and the style that lacks both the sidebar and toolbar. Opening a folder from within a browser-style Finder window replaces the contents of that window, whereas the same action in a non-browser window causes a new window to be opened.

The latter style is often called "spatial" because the creation of a new window for each folder is a prominent behavior of the classic Mac OS Finder and other file browsers that link spatial window state (size, position, etc.) to individual folders. But there's more to being a spatial file manager than opening a new window for each folder. The basic requirements for a spatial file manager are:

1. Each folder is represented by a single window.
2. Each window is unambiguously and irrevocably tied to a particular folder.
3. All changes to the spatial state of a window are preserved (e.g. size, position, color, view style, etc.)

Sorry for the review, but it's been a few years since I've covered this ground. I'm not, however, going to present an argument in favor of spatial file management in this review. (I wrote one four years ago, if you're interested.) I'm just trying to define the terms of the debate.

Historically, the Mac OS X Finder has not fulfilled the requirements described above and therefore could not be considered to have a proper "spatial mode." In particular, requirement number two is violated ten ways to Sunday by the oblong toolbar button that transforms any Finder window into a browser (i.e., a portal through which the contents of any folder can be viewed).

Of course, the mere presence of this ability isn't the same thing as it actually happening. For a simulated spatial Finder, why can't a user simply choose not to transform Finder windows in this way? The converse goes for those that want a purely browser-style Finder.

Sadly, working around the Finder's identity crisis has not been so easy. In all past releases of the Mac OS X Finder, it was impossible to work with one kind of window without the other kind popping up in your face periodically, unrequested and unwanted. This annoyed browser and spatial aficionados alike.

Upon first using the Leopard Finder, you will be forgiven for thinking that things are looking up on the spatial/browser front. Windows are much less likely to sprout (or un-sprout) sidebars and toolbars without being explicitly asked to do so. Sure, new folders created on the desktop still seem to unconditionally open in browser mode, but overall there's been an improvement over past releases.

Unfortunately, things are much more grim than they first appear for fans of spatial file management—or anyone else that cares about view style retention in the Finder.

The Leopard Finder makes its usual, halfhearted, buggy attempt to retain window size and position for each folder. It still does so using .DS_Store files in each directory, and those files are still written in an undocumented binary format. What the Leopard Finder no longer even attempts to do, however, is remember the view style for each folder (e.g., list view, icon view) unless explicitly asked to do so by the user. Here are the steps required to do that.

1. Open the folder.
2. Set its view style to the desired state.
3. Open the View Options panel (type command-j or select the item in the View menu).
4. Check the "Always open in ... " checkbox, where "... " will be the view style set in step 2.

This process must be repeated for every single folder that you want to retain its view style. If you do not do this, the view style of any given folder will be the same as the last view style that you explicitly selected for any folder.

In other words, while window size and position remain attributes of individual folders, view style is now a global attribute of the Finder application itself (optionally overridden by a per-folder setting that must be manually applied as described above). Here's a demonstration.

Note how Folder B's view style appears to mimic the view style set for Folder A. What's really happening is that the global Finder view style setting is being changed. Changing the view style anywhere—whether it's in Folder A, Folder B, or somewhere else—determines the view style that every newly opened Finder window will use. The only exceptions are those folders that have had their view styles manually pinned to a particular value using the "Always open in ... " checkbox.

And by the way, checking that checkbox does not mean that future changes to the view style of that folder will be retained. If you want to retain a view style change to such a folder, you must do the following.

1. Open the folder.
2. Set its view style to the desired state.
3. Open the View Options panel.
4. Uncheck the "Always open in ... " checkbox, where "... " will be the view style as it appeared in step 1.
5. Check the "Always open in ... " checkbox, where "... " will now be the style set in step 2.

Again, repeat this process for every every single folder that you want to retain the new view style that you've set for it.

This avalanche of mandatory explicit action effectively represents a denial of service attack on the spatial style of file management. It overloads the user with a never-ending stream of mundane tasks, making the formerly transparent process of view style retention so inefficient that it will likely be abandoned entirely.

If the Mac OS X Finder wants to be a pure browser, then fine, go for it. But in a proper browser, all view state—not just view style—is rightfully an attribute of the browser itself rather than the thing being viewed. For example, when opening a URL in Safari, the Safari application determines the size, position, and adornment (toolbars, etc.) of the resulting window, not the web site being viewed.

So why has the Leopard Finder chosen to make view style alone an attribute of the application, leaving window size and position as implicitly belonging to each folder? Why the continued charade of the two different window styles? Hell, what explains the continued existence of the global "Always open folders in a new window" preference that effectively stops any window from being a proper browser?

The Finder remains a truly conflicted application. On the one hand, the balance has shifted heavily in favor of browser-style file management in Leopard. On the other hand, many features related to spatial file management remain. It's a mess, and shifting the mess to one side or the other is not going to help much. It's particularly painful to watch Apple continue to flounder in this area when there's a blindingly obvious solution.

Of course, Apple could go all-browser or all-spatial, but presumably neither of those extremes is attractive or we'd have seen one already. No, the Finder has to do both. I've often gone into great detail about the particulars of such a Finder, but apparently there's too much nuance in that approach. Let me say it more plainly: for the love of God, Apple, just freaking separate the two modes! Let each be true to itself, free to flourish and expand in the appropriate ways. I can boil it down to three bullet points.

• Two window styles: browser and spatial.
• No ability to transform a window from one style to another.
• The "New Finder Window" command becomes "New Browser Window."

Then just make the browser and spatial windows behave according to the rules of their respective well-established conventions. That's it! Oh, sure, there are details to be sorted out, like, say, coming up with a reliable, efficient, user-specific mechanism for storing view state information, eliminating the scourge of .DS_Store files. But these are details; get the two modes sorted and everything else will fall into place eventually.

The Finder on the couch

I first noticed the new view style behavior in Leopard when I logged in one day and saw that all my open Finder windows had reverted to icon view. That's obviously a bug, I thought, and I filed one with Apple. As I investigated further and came to understand the underlying cause, I replaced the previous bug with a new one that reported the strange "global view state" phenomenon. Needless to say, the bug was closed with the status "Behaves Correctly."

Uncharacteristically for Apple, a brief explanation of the rationale for the change accompanied the closure. The boilerplate-esque text said, in part, "To appeal to most users, the view style mechanism has changed in Leopard. [... ] To view all folders in your favorite view style you need only click on the view style button once, and you will remain in that view style."

Rarely are we given any insight into Apple's reasoning when it comes to user interface changes, so I'm inclined to mine this tiny nugget for all its worth. It seems clear to me that the new behavior is intended to satisfy a demand for more browser-like behavior, something that "most users" have told Apple they want. I don't find that surprising; ever since the sidebar appeared, the Finder has certainly looked the part of a browser. Its behavior, however, has remained schizophrenic. The common user response: "It looks like a browser, but doesn't behave like one. Please correct this."

On the other hand, apparently some people at Apple believe that going to a full-on browser would be too much. Perhaps they fear it will result in a flood of complaints about "windows not remembering their settings."

This is the type of feedback you can expect from regular users: expressions of particular pain points. It's not their job to solve the Finder's problems or even to understand the underlying causes. But being reactive to this kind of feedback at this level of granularity will only lead to feature churn.

And so you get changes like those made to the Leopard Finder. A change here to address a situation where the Finder isn't browser-like enough, implemented in such a way that it (further) breaks spatial mode. Oops, now let's throw in an "Always open in ... " view option to make those other people happy. And round and round it goes. Push something in over here, something else pops out over there. No one is thinking about the big picture.

As a sop for spatial file management fans, the "Always open in ... " view option fails spectacularly. It's more like a giant middle finger from Apple. At the very least, an option to restore the pre-Leopard behavior of automatically retaining view style on a per-folder basis (radar 5543643) is necessary to restore some semblance of balance. But in the long run, it's all futile unless the larger issues are addressed.

Finder summary

The Finder was one of the biggest surprises for me in Leopard. It was not apparent at all from the brief Leopard Finder demos shown at the various Macworld Expo and WWDC keynotes that such significant changes had been made. Certainly, there's wasn't even a whiff of the new policy on view style retention.

After many years of bugs, poor performance, a feeble browser, and a pseudo-spatial mode, it'll be interesting to see what kind of reaction this change gets in the wider Mac community. You don't need to know or care about any of the high-concept user interface theories to get annoyed when the results of your actions are not respected enough to be preserved. On the other hand, the Finder has been flaky about state preservation for years. How many Mac users have simply given up trying to make the Finder a familiar, hospitable place? Maybe no one will even notice that view style changes are no longer preserved automatically.

Well I sure as hell noticed, and it pisses me off. I'll be gritting my teeth as I wander my hard drives, manually pinning down the view style of each folder I care about. I'll grimace every time I naively change a view style only to be surprised later when I realize that my change was ignored because I forgot to (re)pin it manually. I'll curse as I spend time and energy finding a way to automate the entire tedious process. (I've gotten as far as figuring out how to set the "Always open in ... " checkbox using a hex editor on the appropriate .DS_Store file. Sad, but true.)

The Leopard Finder's saving grace may be that the increased responsiveness and new features are likely to overshadow all other issues, and will go a long way towards damping the flames of hatred burning in certain corners of the Mac world (even as the view style changes ignite more).

Way back in 2002, I wrote that "the changes being made to the Mac OS X Finder betray a fundamental lack of vision." This continues to be the case. Not only does the Leopard Finder take no bold steps towards a brave new world of file management, it even further distances itself from a coherent incarnation of established file management paradigms. The changes in Leopard do indicate that Apple has taken a renewed interest in improving the Finder, but motion is not the same thing as progress. For where I'm sitting, it looks like one step forward, two steps back.

The Dock

If the Finder looks like a starlet headed for rehab, then the Dock is out on a bender in Leopard. We've already seen the aesthetic damage. Now it's time to take stock of the functional vandalism.

The left side of the Dock remains mostly unchanged. It still holds only applications, running or otherwise. All of the new features are on the right half of the Dock, where "everything else" lives. Files, minimized windows, and the trash all pass into Leopard unscathed. It's docked folders that received the most attention from Apple, for better or for worse. (Mostly worse.)

First off, I cheated a bit earlier with the screenshot of special folders. Docked folders in Leopard show their actual folder icons only when they are empty. Docked folders containing one or more items show the icons of those items stacked on top of each other, sorted by name (the default), kind, or date. In a fresh Leopard install, here's what the Applications folder will look like in the dock.

Seriously. It gets worse. Let's add the new Downloads folder next to the Application folder. Here's what it looks like in the Dock after downloading your first disk image.

Yep, that's it right next to the trash. I kid you not. Let's add an actual disk image file to the Dock.

That's the Downloads folder on the left, and the disk image file on the right. It's slightly bigger.

If you are not shaking your head, uttering something profane, or taking some deity's name in vain right about now, congratulations, Apple may have a position for you in their user interface design group.

Do I need to further explain my objection to this insanity? I hope not, but if so, let's continue by looking at a more typical Dock with several folders containing multiple items. First, the Tiger version.

Now Leopard.

Just try and freaking guess what those icons are in the Leopard Dock, I dare you. Sure, two of them are probably easy: the Applications folder that you've already seen, and maybe the Downloads folder which just has two additional items in it. But the others? Forget it. Here's the actual list, from left to right: Home, Applications, Downloads, Documents, Pictures, Movies. And yes, I had to scrub my mouse over the icons to get that list right.

When it comes to ease of identification, the Tiger version wins, hands down. And remember that the icons in the Leopard Dock will change their appearance as the contents of those folders change over time.

In the Leopard Dock, my home folder appears as a bunch of stacked folder icons because that's mostly what it contains: other folders. There's actually one document peeking out in the middle of the stack as a sliver of white. The icon on the top is the Desktop folder icon. So, out of the box, your home folder, when docked, appears to be the Desktop folder.

We already talked about Applications. It's basically Address Book, the head of the Automator robot icon, then a bit of folder peeking out the sides. My Documents, Pictures, and Movies folders all contain mostly other folders as the first few items, alphabetically.

Changing the sorting doesn't help much. The problem is that this is fundamentally a bad idea. There's just not enough room in a single Dock tile for a stack of icons to convey any meaningful information. Only the top one, two, maybe three items have any visual impact. And those few items may be misleading (e.g., the home folder appearing to be the Desktop folder) or completely generic (e.g., the Pictures and Movies folders showing up as plain folder icons.) Seriously, Apple, this is a bad idea. And do I need to tell you that there's no way to disable this behavior? Sigh. And we're not done yet.

Clicking a non-empty docked folder that contains other items no longer opens the folder in the Finder. Before I get into what does happen when you click on a docked folder, let me further point out that (surprise!) there is apparently no way to get the old behavior back. I modifier-clicked my fingers off with no luck. Yes, there's still the "Show in Finder" context menu item, and as we'll see, at least one other alternative that requires two clicks (possibly quite distantly separated), but nothing as succinct as the behavior that existed in Mac OS X 10.0 through 10.4. Leopard just takes this feature away.

Here's what does happen when you click a docked folder. If the folder is empty, it opens in the Finder. If it is not empty but contains less than a dozen or so items, it sprouts a curving stack of icons, topped by a "Show in Finder" button. Clicking on an icon is the same as opening it in the Finder: folders open in a new Finder window, documents open in the appropriate application, and applications launch. A command-click reveals an item in the Finder.

Apple calls this view "Fan." The curve is jaunty, but it also makes it a bit more difficult to click items high in the stack, requiring a varying amount of lateral motion rather than a straight shot upwards. Putting the "Show in Finder" icon is at the top seems particularly cruel. If it were at the bottom, the two clicks required to open a docked folder in the Finder would be tolerably close together.

If there are many items in a folder, clicking on its dock icon reveals an icon grid on a tinted background.

Items in the grid respond to clicks in the same ways as items in the fan view. Each docked folder can be viewed as a fan or a grid or can be set to "automatic" (the default), which uses a fan when there are few items and switches to grid to handle many items.

Both of these new features are actually pretty nice. It's too bad Apple decided to completely replace the old behavior. It would have been so easy to have it all: just add a "Window" menu item alongside Fan and Grid in the "View as" submenu.

Finally, the Leopard Dock is spring-loaded, at long last. That is, when dragging an item onto a docked folder and holding it over the folder for a few moments, the docked folder springs open to reveal its contents, allowing further nesting of the dragged item.

Taking stock of the Dock

Put simply, there are few positive changes to the Dock in Leopard. Fans and grids are nice, but even those new features are hampered by the needless abandonment of old behaviors. The "stacked contents" docked folder display method is a total loss. Burn it with fire, or at least provide some way to turn it off.

And lest we forget, despite these new Leopard feature, the Dock is still quite anemic. This isn't talked about much these days, but all the old power-user complaints about the Dock still have merit: the need for icon scrubbing, the moving targets, the arbitrary division of items, the way each function affects the others (e.g., minimizing many windows makes the Dock a less effective launcher by shrinking and moving all items), etc.

The benefits of the Dock are obvious and well established. Many of its weaknesses are actually strengths for beginners and users with less complex needs. But as the boneheaded changes to the Leopard Dock amply illustrate, there's one persistent fact that makes the Dock's failings stand out: you have to use it.

Mac OS X forces you to use the Dock by making it the exclusive home for some essential functionality. The three biggies are window minimization, application notifications (i.e., bouncing icons and icon badges), and application Dock menus. Maybe you could give up one of those, but it's pretty much impossible to live without having any of them.

Replacing or even just replicating any of these features elsewhere can only be done using scary, unsupported hacks (and thank God that's even possible) or inefficient, application-specific work-arounds (e.g., polling via Apple Events to simulate Dock icon badges for unread message counts and so on).

If Apple's going to not only refuse to make the Dock better suited to more complex or demanding usage scenarios, but also periodically hose existing functionality and add really terrible new behaviors, it needs to take away the Dock's exclusive ownership of essential features. Let me hide the Dock entirely and use a third-party replacement without sacrificing basic functionality and without compromising the stability of my system. I know it's always a pain to add new public APIs, but these changes are long overdue, and they'd benefit Apple in the long run as well. Mr. Serlet, tear down this wall! Don't force me to use the Dock, and I promise I'll stop actively hating it.

Time Machine

Time Machine is the best new feature in Leopard, perhaps the best feature ever added to Mac OS X. Put simply, Time Machine is a backup and recovery system that people will actually use. It effectively cuts the Gordian Knot of the age-old backup dilemma for normal users: "I know I should back up, but I never do. I wouldn't even know how to do something like that anyway." Well, enough of that. If you have more than one hard disk attached to your Mac, it's more difficult not to use Time Machine than to use it.

The first time two or more hard disks are connected to a Mac running Leopard, a dialog box will appear asking the user to select a backup disk. Choose one and you're done; no further action is needed. Were you to wander over to the Time Machine preference pane, you'd see this tidy little display.

Time Machine preference pane

The comically huge on/off button dominates the screen. (Shades of the iPhone "slide to unlock" control, eh?) The only two other controls are the "Change Disk" button and the "Options" button which leads to this dialog.

It's all pretty self-explanatory, and the defaults are sensible enough that no one ever even needs to know these screens exist.

The benefits of Time Machine are revealed in two important ways. First, if your main hard drive dies or is replaced, booting from the Leopard install DVD will provide a one-click way to restore from your last Time Machine backup. Second, when viewing any window in the Finder, triggering a special mode will show the contents of that window at all points in the past for which backup data exists. Files can be recovered from the past, replacing the current incarnations or existing alongside them.

This all sounds so simple that it's boring, but that's the genius of it. Apple took a survey of its customers' backup habits before creating Time Machine. Eighty percent of Mac users said they knew they should backup their data. (This is scary already. Only 80 percent?) Twenty-six percent said they do backup their data. That actually doesn't sound too bad until you get to the next question. Only four percent backup regularly.

In a nutshell, this means that if you could snap your fingers and make one Mac user's main hard drive disappear, there's a 96 percent chance that you just destroyed files that are completely unrecoverable. With more and more irreplaceable personal data being stored on Macs (e.g., family photos and movies) it'd be irresponsible of Apple not to address this issue in some way.

I harped on this topic a bit a few years ago, coming at it from the hardware side by suggesting that Apple put at least two hard drives in every Mac. In Leopard, Apple has approached the problem from the other direction, eliminating the software hurdles and relying on Mac users to supply the additional hard drive.

In hindsight, this is a more practical solution. Mac users are much more likely to purchase and attach a spare hard drive than they are to navigate the complexities of backup software on their own—software that may cost as much as a hard drive, these days.

And as the icing on the cake, Apple even made file recovery fun. It starts with the icon for the Time Machine, which is in the Dock by default.

Click it and everything but the front-most Finder window falls off the screen, revealing a crazy-ass swirling nebula and moving star field, into which fades a succession of historic incarnations of the lone remaining Finder window.

Completely non-standard arrows and buttons are used to navigate and restore files. A timeline along the right shows each backup as a tick mark, magnifying the marks on mouse-over much like the Dock magnification feature. It's all completely ridiculous, and you know what? I love it!

I'm willing to indulge Apple when it comes to these flourishes in Time Machine for two reasons. First, none of the silliness renders the features significantly less usable. Yes, those arrow buttons are crazy, but they're also huge click targets, and they clearly convey their purposes. Ditto for the buttons at the bottom. Second, and most importantly, Time Machine is designed in such a way that it's easy—almost trivial, in fact—for third-party developers to create their own interface to manage backed-up data. Which leads us to...

Time Machine internals

Backups are stored in a folder named Backups.backupdb at the top level of the drive selected as the Time Machine backup repository. Within that is a folder with the computer name (as set in the Sharing preference pane in System Preferences) which contains a series of date-stamped folders (YYYY-MM-DD HHMMSS), each of which contains a folder named for each volume being backed up. Here's an example.

In this case, the computer name is "Leopard" and the hard drive name is "Leopard Demo." Each "Leopard Demo" folder contains the complete contents of the volume as it existed at the time indicated by the parent folder's name.

Wait a second, the complete contents? Let's see, there are ten date-stamped folders, each containing a "Leopard Demo" folder... does that mean that the Time Machine backup drive shown above is at least ten times larger than the Leopard Demo volume? Fortunately, no. Time Machine is a bit more clever than that.

When creating a new date-stamped backup, Time Machine does not copy any files that have not been modified since the last backup. The same goes for entire folders; if all the files in a particular folder have not been modified, then the entire folder is not copied.

And yet there they all are. If you navigate into one of the "Leopard Demo" folders, you'll see every single file. Not aliases, not symlinks, the actual files:

Well, sort of. In my Tiger review, I included an explanation of Unix file permissions. To understand what Time Machine is doing, you must first know something about another standard Unix feature: symbolic links and hard links. This is very basic stuff for anyone with Unix experience, but I got a lot of positive feedback about the Unix permissions tutorial so I hope you'll allow me a brief digression. Feel free to skip this section if you know this stuff already.

Symbolic links and hard links

Mac OS has included the ability to create an "alias" of a file since System 7. Aliases are small, plain files whose contents are interpreted by the Finder and other Mac OS APIs, allowing the original file to be found. To the core OS in Mac OS X, however, aliases are meaningless. They're literally just small, plain files. (In fact, their size is shown as zero because all the data is in the resource fork.) The first part of this lesson is that aliases have absolutely nothing to do with symbolic links and hard links.

For decades, Unix has had two ways to do something similar to what aliases do: symbolic links and hard links. A symbolic link, also called a symlink, is a pointer to another file. The location of this file is specified using an absolute or relative path string. Symbolic links are created with the ln command using the -s flag. Here's an example.

% ls -l
-rw-r--r--  1 john  staff  894 Oct 18 10:04 myfile

% ln -s myfile mysymlink

% ls -l
-rw-r--r--  1 john  staff  894 Oct 18 10:04 myfile
lrwxr-xr-x  1 john  staff    6 Oct 18 10:06 mysymlink -> myfile

As indicated by the leading "l" in the Unix permissions string, mysymlink is a symbolic link. It points to myfile, which the ls command shows to the right of the little ASCII arrow. Note that the symbolic link is tiny: only six bytes. That's not a coincidence. Symbolic links are "dumb" in that they literally contain nothing more than the target file path as a string. In this case, the string is the relative path "myfile" which (surprise) is exactly six characters long.

If I move mysymlink to an entirely different directory that also happens to contain a file named myfile, then the symlink will point to that file instead. If I delete myfile, the symlink will remain, still containing that same path string which no longer leads to an actual file. Observe:

% rm myfile
% cat mysymlink
cat: mysymlink: No such file or directory

The error reported is a bit confusing. The mysymlink file still exists. But when the operating system attempts to open that file, it dutifully follows the symbolic link and finds that there is no file at the path specified by the link. The cat command then reports the error it encountered when trying to open the file it was originally told to open.

This property of symlinks can also be considered a feature in some circumstances: "simple" rather than "dumb." But sometimes a more robust mechanism is needed. Enter hard links.

A hard link is simply a reference to some data on disk. Think of a file as a combination of a name and a pointer to some data. Deleting a file really means deleting the name portion of that duo. When there are no more names pointing to a particular piece of data disk, then that disk space can be reused.

Most files have just one name. In effect, every plain file is a hard link. Take another look at the myfile listing from before.

-rw-r--r--  1 john  staff  894 Oct 18 10:04 myfile

See that number "1" right before the word "john"? That indicates that the data linked to the name myfile has only one name. In other words, deleting myfile will drop the count to zero, allowing the disk space previously used by myfile to be used for other purposes. Note that creating a symlink does not increment this number.

% ls -l
-rw-r--r--  1 john  staff  894 Oct 18 10:04 myfile
lrwxr-xr-x  1 john  staff    6 Oct 18 10:06 mysymlink -> myfile

In fact, the symlink itself has a "1" in that column, indicating that there is only one name linked to those the six bytes of data. Now let's make a hard link, again using the ln command, but this time with no flags.

% ln myfile myhardlink

% ls -l
-rw-r--r--  2 john  staff  894 Oct 18 10:04 myfile
-rw-r--r--  2 john  staff  894 Oct 18 10:04 myhardlink
lrwxr-xr-x  1 john  staff    6 Oct 18 10:06 mysymlink -> myfile

Now the link count for both myfile and myhardlink is two. This indicates that the data linked to by myfile has two names, and the data linked to by myhardlink has two names. In this case, both link to the same data. We have no way of knowing that merely by looking at the link counts; we know because we just ran the ln command ourselves.

Though the size for both myfile and myhardlink is listed as 894 bytes, those 894 bytes exist only once on the disk. Again, it's one chunk of data with two names. As far as the OS is concerned, neither myfile nor myhardlink is the "real" file. They are both equally real, as real as either one would be if the link count was one instead of two.

Since these two files link to the same data, the results of modifying that data will be reflected in each file. For example, let's add five bytes to the chunk of data linked to myfile (the word "test" plus a newline character):

% cat >> myfile
test
^D

Now let's look at the result.

% ls -l
total 24
-rw-r--r--  2 john  staff  899 Oct 18 10:38 myfile
-rw-r--r--  2 john  staff  899 Oct 18 10:38 myhardlink
lrwxr-xr-x  1 john  staff    6 Oct 18 10:06 mysymlink -> myfile

The sizes of myfile and myhardlink are now both reported as 899 (894 + 5). Meanwhile, mysymlink is still the lone name linked to its six bytes of data containing the string "myfile".

Back to Time Machine

Okay, digression over. Let's revisit the mystery of the ten apparently complete copies of my "Leopard Demo" volume in the Time Machine Backups.backupdb folder. As you might have guessed by now, Time Machine uses hard links to repeatedly link to the single instance of a particular chunk of data on disk. Here's an example:

% cd Backups.backupdb/Leopard/2007-10-18-103601/Leopard Demo
% ls -l mach_kernel
-rw-r--r--@ 10 root  wheel  10235416 Sep 18 23:50 mach_kernel

And there you have it: the "10" next to the word "root" indicates that there are ten names linked to the data that mach_kernel links to. That data exists only once on the Time Machine backup volume. This arrangement is repeated for each file that has not been modified since the last backup.

Time Machine goes one step further. Historically, Unix has only allowed hard links to files. In Leopard, Apple has included the ability to make hard links to directories. This has not been allowed in Unix because it can lead to all sorts of very nasty infinite loops during file look-ups. Of course, symbolic links can create loops too, but they're a lot easier to detect and prevent since symbolic links are easily distinguished from normal files. But as discussed earlier, every file is essentially a hard link, and all hard links have equal standing in the eyes of the OS, making loop detection a bit trickier.

Nevertheless, the benefits for Time Machine were substantial enough for Apple to (carefully) add this ability to Leopard. For example, if the entire /System directory has not changed since the last backup, Time Machine just has to make a single hard link to that directory in the new backup folder. Without support for hard links to directories, Time Machine would have to create 18,744 directories containing a total of 68,839 hard links to files (using numbers from my /System directory).

Yes, directories are small and hard links only take up the room necessary for their directory entries (at minimum, enough to store the name and a pointer to the data on disk), but those bytes add up fast when you're talking tens of thousands of hard links being created every time you want to do a backup. Hard links to directories make this all much simpler and more efficient.

There is one final bit of cleverness in Time Machine. When it comes time to do a backup, how does Time Machine know which files have changed since the last backup? If you've been reading along (and not skipping sections like a wuss), the answer is obvious: FSEvents.

Though Apple was kind enough to make it a public framework, Time Machine is arguably the entire reason FSEvents was created. Time Machine can wake up whenever it wants—it doesn't need to be running constantly—and efficiently find out what's changed since it last checked (that is, since the last file system event id that it saw). Since FSEvents reports changes at a directory level, Time Machine still has to determine which files in that directory have changed. No problem! It's got the previous backup of that directory to use as reference. FSEvents and Time Machine are a perfect match for each other.

Implementation consequences

It's unfortunate that Time Machine's cleverness does not extend just a bit further. The smallest unit of data that Time Machine will backup is an individual file. That means that if you change one byte in a 10GB file, that entire 10GB file needs to be copied to the backup volume. Hard link can't help you here. There's no way to make a hard link to "9.99999GB of the old data, plus this one byte of new data."

But how often does that happen? Sure, it's a worst case scenario for a file-level backup system like Time Machine, but isn't it rare to repeatedly modify a small portion of a giant file? Well, it depends. I can think of two instances that will bite many thousands of Mac users.

First, if you use Microsoft Entourage, your e-mail is kept in a single, large database file. Mine is about 2GB. Most people get new e-mail every day. Ugh.

Second, if you use any sort of virtualization software like VMware or Parallels, each virtual machine hard disk image is a multi-gigabyte file that changes pretty much every time you use the VM. Double ugh.

So, how many Mac users own some virtualization software or use Entourage? That number has to be in the thousands, and is probably growing.

Apple has been encouraging developers to use many small files rather than one big one for years now, mostly to make it easier for Spotlight to index application data. In Tiger, Apple Mail switched to saving individual messages rather than larger, monolithic mailbox files for this reason. Presumably Entourage could do the same, although I have no idea if it does so in the upcoming Microsoft Office 2008 release. But for virtual machine files, the problem is intractable. And those tend to be the biggest single files on most disks.

This problem needs to be addressed. The best solution is for Apple to move to a new file system that supports block-level snapshots. ZFS, for example, would fit the bill. Sadly, no such transition has happened in Leopard. Time Machine backs up to a plain old HFS+ volume (though read-only support for ZFS is included in Leopard, with experimental read/write support available to developers).

Reimplementing Time Machine on top of ZFS or some other similarly capable file system would be a big win in terms of space efficiency. Unfortunately, that's a tall order. Don't hold your breath for anything like that until 10.6 at least.

In the meantime, it is possible to exclude individual files from Time Machine backups by dragging them into the "Do not back up" list available in the Time Machine preference pane. That will exclude the file by path. The same underlying API (CSBackupSetItemExcluded()) can actually be used to exclude a file directly, preventing the file from being backed up no matter where it's moved or how it's renamed. (Extended attributes in action yet again.)

Time Machine's backup format also means that it's not possible to boot from a Time Machine backup volume. Instead, you must boot from a Leopard install DVD and restore the Time Machine backup onto a new volume. If, like me, you feel better also having a bootable backup around, an application like SuperDuper is still necessary. (I refuse to add the exclamation point. Sorry, David.)

On the bright side, the backup format isn't really a "format" at all. It's a bunch of plain files on disk in date-stamped folders. Don't like the loony space-motif file restoration interface in the Finder? Don't use it. You can wander around the Backups.backupdb folder using the Finder, the command line, or any other file manager. But the biggest win with all these public APIs and simple structures is that the field is wide open for third-party developers to create applications that complement and build upon Time Machine.

It's a clean machine

Despite a few consequences of Apple's continued inability to field a successor to the venerable HFS+ file system, Time Machine is a conceptual and technical home run. Okay, so it's an infield home run, but it still scores. Time Machine makes a task that was once so complex and intimidating that almost no one even attempted it, and makes it invisible. Like all great ideas, it seems obvious after you've seen it, but that in no way diminishes the achievement.

Time will tell (ha) if this machine is enough to get to Apple's stated goal of having 100 percent of Mac users backup regularly, but I think it'll certainly make a dent. I often get scolded by other mothers via e-mail when I use my mother as an example, but it's just too apropos to pass up here. Time Machine is literally the only way I can think of that I could ever get my mom to back up her Mac. Once she has upgraded to Leopard, I can tell her over the phone to buy an external drive, plug it in, and click a button in a dialog box. No cross-country visit, no Apple Remote Desktop session (although Leopard makes that part easier, too), no software installation, no new application to learn.

Yep, it's a glimpse into the self-sufficient-mom future we all imagine. The open backup format and APIs are exactly the right way to add a major feature without the burden of being all things to all people. Let third-party developers to add value; they'll love you for it. Time Machine earns its place as the marquee feature of Leopard. Good show, Apple.

Performance

Each new version of Mac OS X has been faster on the same hardware than its predecessor. I've said as much in my reviews, but the definition of "faster" is admittedly nebulous when applied to an entire operating system.

There are at least two important ways that an OS gets "faster." The first is traditional code optimization, where some subsystem is improved to use less CPU time or less memory or do less disk i/o, thus performing the same task in less time. The second factor is perceived speed. Though a task may actually take longer, it may feel faster due to changes in the way the OS reacts during the process.

Application launching is the canonical example that combines both. You can time how long it takes for an application to finish launching, giving you a measurement of actual performance. The perceived performance, on the other hand, has more to do with the number of bounces the Dock icon makes, when the first application window begins to draw itself, and whether there's a beach ball cursor at any time during the process.

Leopard, like its predecessors, gets faster on the same hardware in both areas. Frameworks have been extensively revised and optimized, yielding real performance benefits in the areas of screen drawing (2D or 3D), text display, and most of the features that were new in Tiger.

In particular, Spotlight's improvement has been revelatory. Maybe it will degrade with time, but after a few months of usage it's still lightning fast. I've actually been too lazy to install Quicksilver on each new Leopard seed, relying instead on Spotlight as a quick launcher—something that would be inconceivable to me in Tiger. And Leopard is not getting off easy by just indexing a clean install. No, it's indexing all 2+ million of my files.

This brings up an interesting point. Does a faster Spotlight contribute to the "OS" being faster? I say it does. From a user's perspective, an OS is a collection of features and bundled applications. Only nerds care about the "real" definition of an operating system, encompassing only the lowest-level services. Spotlight is perceptible and measurably faster in Leopard, and that makes a big difference to users.

Speaking of Spotlight, the continued addition of similar "system services" to Mac OS X has caused some concern. Upon booting into Tiger for the first time, for example, users had to endure a long disk-thrashing experience as Spotlight indexed all their files. Granted, it happened in the background, but it did slow things down. Perhaps more importantly, the sound of a hard drive grinding away in the background can be quite disconcerting.

Now Leopard adds Time Machine, which is set to do even worse: initially read and then write the entire contents of every file on your disk. It doesn't get much heavier than that when it comes to disk i/o. In practice, the upside is that this doesn't have to happen immediately upon your first login. If you don't assign a drive to Time Machine, it will do nothing. And you can always turn Time Machine off temporarily with the big honkin' switch, then turn it back on when you'll be away from the computer for a while. This increased control goes a long way towards making Leopard a more pleasant upgrade.

Most bundled applications get a boost of speed in Leopard, if only in the seemingly universally less disk-intensive launch process. One Dock bounce, a few hard drive clicks, and most applications are ready to go. I feel like I'm probably being cheated by yet more "bounce shaving," but the stopwatch bears it out, if only by fractional seconds in most cases.

Window resizing takes its usual baby step towards absolute responsiveness, no doubt aided by the faster text drawing and Cocoa framework optimizations. iCal remains the best (or is it the worst) test candidate for this task. It's still laggy, but improved.

I have a feeling the real performance wins will come as third party developers (and Apple too, I suppose) have time to optimize for Leopard, using Quartz GL, compiling for 64-bit Intel, using the new Objective-C 2.0 runtime, and so on.

In short, it's more of the same for Mac OS X performance in Leopard: steady improvement, with a few bright spots, and no real downsides.

Stability

For the longest time, very early in Leopard's development process, it wouldn't even boot my (PowerPC) Mac successfully. Each newly downloaded developer version would kernel panic before getting to the Finder. This was discouraging, to say the least. No previous Mac OS X version behaved this badly for this long during its development. Eventually, the kernel panic was fixed, and I could finally boot. But as the release month of October approached, there were still an alarming number of basic things that did not work reliably. I was getting bad flashbacks of the bug-ridden 10.4.0 release.

Then, around September, Apple released a build that miraculously seemed to make everything work, and work well. Now obviously I have no idea how closely Apple's developer seeds track with the actual state of the OS code in-house. Maybe Apple was holding back, seeding older versions, while the head revision inside Apple was in a temporarily unstable state awaiting the final big push. But whatever the case, this dramatic come-from-behind developer seed victory is unprecedented in the history of Mac OS X development. That September seed was so good, so stable, that I thought it could be the GM.

Well, the actual GM is just as good, probably even better—though I've yet to produce a single crash of anything even in the September seed. Of course, I only have a limited set of hardware and software to test on, so I can't say definitively that 10.5.0 is going to be great for everyone. And yes, the Miracle of September does give me some pause. But I'm cautiously optimistic that 10.5.0 won't be a repeat of the 10.4.0 experience. That said, a 10.5.1 release is almost certainly not too far away. I just think you won't be in desperate need of it when it arrives.

Grab bag

It's time for the grab bag section with all the shiny screenshots. This will be short, I think, because it certainly can't be exhaustive. Also, Apple itself has provided quite an extensive rundown of over 300 new features in Leopard. Thanks, Apple. Still, I'll have my say.

Spaces

Leopard includes an extremely competent virtual desktop implementation in Leopard, appropriately called Spaces. To some, this is a major new feature on the level of Time Machine. To me, it's a grab bag item, albeit the headliner. Your mileage may vary.

In the continued flavor-of-the-version shuffle, the "Dashboard & Exposé" preference pane from Tiger has been renamed to "Exposé & Spaces" in Leopard. Here's the new Spaces tab.

You can add rows and columns of spaces, up to a maximum of 16 in total. Applications can be assigned to specific spaces or can appear in all of them, which is a nice touch. For the next revision, a way to assign different desktop background to different spaces would be nice.

"Activating" spaces means displaying all the spaces on the screen at once. Once in this view, you can drag windows from one space to another. Dragging a window to a screen edge and holding it there will accomplish the same thing. I only wish that activating spaces did not interrupt the current drag operation. Ideally, I'd like to click and hold on a window title bar, then activate spaces and continue my drag of that window into a new space. (I do something similar on a daily basis when dragging files, using the command-tab application switcher as an indirect way to get the drag destination to come to the front without releasing the item that I'm dragging.)

Spaces's keyboard and mouse bindings are extremely flexible, allowing most sane combinations of keys, screen corners, and mouse buttons to be used as triggers. And above all, Spaces is fast. Space-switching happens instantly, accompanied by minimalist but pleasing sliding animations and a nice HUD (which I've been unable to get a screenshot of, but you can see it at Apple's web site).

After many years of heroic hacks by third parties, it's nice to finally have a supported implementation of this feature, and a good one at that.

New icons

From Spaces to icons? Yes indeed. A bunch of existing applications get new icons in Leopard.

I'm not sure how I feel about System Preferences adopting the iPhone settings icon, but overall, the new icons look nice. Most icons have been updated, in fact, if only to include larger sizes. Many have been entirely redrawn but look almost exactly like their predecessors. It all combines to gives a nice additional sheen to the OS.

Leopard also includes a nice set of icons representing most Macs made in the past few years, presumably meant to more accurately represent networked machines, though for some reason, the Finder thinks my PowerBook is a Cinema Display. Anyway, the icons are extremely nice looking. But at what point do these things stop being "icons?" At 512x512 pixels, they're more like "idealized photos." Decide for yourself.

Apple was even nice enough to include an icon for (to quote the file name) a "generic PC."

Cruel.

(I actually think the worst part is the monitor itself, not what's on it.)

Network

The new Network preference pane is awesome. Strike that, maybe it's just that the old one sucked so badly. Anyway, here it is.

It includes a whole bunch of features that were either well hidden (often in other preference panes) or only available from the command line: duplicating services, importing and exporting configurations, managing virtual interfaces, the whole nine yards. All of the esoteric stuff is behind that "Advanced" button, but at least it's finally all in one place.

Sharing

The Sharing preference pane is is similarly refined and expanded. The screen I've chosen to show below reveals the long-overdue addition of a GUI for sharing specific folders.

Nearly every service has some small new feature, usually in the form of more flexibility about who gets to use the service.

Guest account

The new guest account feature allows anyone to login without a password.

The usual set of constraints can be applied to the guest account, including the so-called "parental controls" that severely restrict access. A temporary home directory is created when a guest user logs in. The user id is always the same (201), and only one guest can be logged in at a time. There's no fear of one guest seeing another guest's left-over files because the entire home directory is deleted upon logout. Thankfully, Apple provides a warning.

Though I didn't go looking for it, I suspect it wouldn't be too hard to find the template for the guest account, perhaps in the form of a disk image or property list, and customize it to create a more comfortable environment for guests. (Say, by putting a giant Unreal Tournament 2007 alias in the center of the desktop. Hello, multiplayer gaming terminal.)

Disk Utility

The Disk Utility application can now delete and resize partitions without erasing all data on the disk. This is probably a result of the work Apple's done for Boot Camp, whose installer has long had similar capabilities (but really it was long overdue). The warning dialog Disk utility puts up during destructive operations is reassuringly clear.

Slightly less embarrassing text-to-speech

The new "Alex" text-to-speech voice is considerably better than the previous voices, which date back to the classic Mac OS days. More modern text-to-speech technology still sounds a lot better to my ears. Apple really needs to significantly update the core engine, not just add new voices. No screenshot.

Back to my Mac

Leopard includes support for what is essentially dynamic DNS via the new Back to My Mac feature of the .Mac service.

Enabling this feature lets any Mac know the IP address of all your other Macs by having each one report its IP address to the .Mac service. The result is that all your Macs are available as servers in the Finder sidebar, without requiring you to enter a server address. It's handy, but not much help if you travel across several draconian firewalls daily.

Grammar checker

The system-wide spelling checker now does grammar too. Bad grammar gets a green underline instead of red.

It's not the most robust grammar checker in the world—for example, it thinks "This are good" is perfectly fine—but like the spelling checker, its omnipresence makes up for its limited abilities.

iCal's Dock icon

Apple has finally submitted to adding what must be quite a hack to get the iCal application icon to show the correct date on its Dock icon, even when the application is not running.

Terminal

The Terminal application has grown up, proudly sprouting tabs, window groups, and saved window styles, including an appropriate wacky default set.

And hey, anyone remember that Apple Type Services bug that prevented my preferred Terminal font (Monaco 9pt forever!) from displaying correctly? You know, the one that lingered for five years after I first reported it?

Fixed.

Fixed! Can you believe it? A new look, tabs, and the ability to render bit-mapped fonts as well as a Mac 128k. My cup runneth over.

Welcome to tomorrow

I started this review talking about expectations. As I've learned more about Leopard, it's become increasingly clear where, exactly, those two-and-a-half years of development time went. Leopard is absolutely packed with improvements. It seems that not a corner of the OS has gone untouched.

Perhaps that's not as clear to the casual user who just sees the surface changes and the major new features in Leopard. But even in that case, there's more than enough to recommend it. If you're wondering whether you should upgrade to Leopard, the answer, as it's been for every major revision of Mac OS X, is yes.

I say this despite my deep hatred for many of the user interface changes. But perhaps I'm not representative of the average Mac user. In all likelihood, my hatred will translate into an occasional-to-persistent mild annoyance for most users. And truthfully, people can get used to just about anything (as the history of Mac OS X has shown).

I'm most excited about Leopard's internals. They're the star of this release, even if they don't get top billing. There's a good reason we've already seen so many prominent Leopard-only software announcements. This is where developers want to be.

Leopard's pull on developers will translate into better applications for users... eventually. In the meantime, I'm hard pressed to think of a single Mac user I know who wouldn't benefit from Time Machine's hassle-free backup magic. If you're looking for one reason to upgrade, this is it. Yeah, backups are boring, which is why you're probably not doing them regularly right now. No more excuses.

In many ways, Leopard feels like a new beginning. While Tiger consolidated the gains made in 10.0 through 10.3, pinning down APIs and dipping its toe into a few possible future directions for the GUI, Leopard charges bravely forward, choosing one particular new look and mandating it everywhere, redesigning all of the most prominent visual elements of the interface, and shedding old technologies like cat fur.

What's emerged is quite a strange beast: beautiful on the inside and, well, a bit unlovely on the outside. I hope a few years of user feedback will file down some of the sharper edges, even as my dream of a radical new look is postponed until 10.6 or later. It'd also be nice if Apple would finally make a decision about the successor to the HFS+ file system some time this decade.

What a long, strange trip it's been. Leopard turned out very differently than I imagined it would only a year ago. Despite some big disappointments near the end of its development process—the new Dock, the menu bar, more Finder floundering—the foundation is stronger than it's ever been.

Though this is not likely to happen, most of Leopard's biggest problems could be fixed in a 10.5.x point release. That's something that certainly could not have been said about any prior version Mac OS X. With Leopard, Apple has managed to snatch, certainly not defeat, but at least partial ignominy from the jaws of absolute victory.