Here’s to the crazy ones: a decade of Mac OS X reviews

As the Ars team convenes for two days of meetings in Chicago, we're reaching back into the past to bring you some of our favorite articles from years gone by. This story originally ran in January 2010.

The latter half of the 1990s was a dark time for the company then known as Apple Computer, Inc. Windows 95 had dashed any remaining hopes of mass-market desktop dominance for Apple. The big profits of the earlier part of the decade had given way to some huge annual losses. The future of the entire company was in doubt.

Like injured animals, corporations are adept at hiding the true magnitude of their injuries. As grim as things appeared from the outside, few Apple enthusiasts knew at the time just how close the company came to fiscal ruin. But the software picture was always crystal-clear—clear, and terrifying.

The Mac operating system lacked two important features essential to remaining competitive past the end of the decade: memory protection and preemptive multitasking. Over the course of many years, Apple made several abortive attempts to create a modern successor to the classic Mac operating system, all of which crashed and burned before the horrified eyes of Mac fans everywhere. Regardless of its financial issues, it was clear to the geeks that Apple was on the road to technological ruin.

Apple made its final play for salvation in 1997 when it purchased NeXT and, after one more false start, announced at WWDC 1998 what would be, blessedly, its last next-generation operating system strategy: Mac OS X.

By all rights, the Mac faithful should have been, if not ecstatic, then at the very least relieved at this turn of events. Finally, a modern operating system for the Mac. But there was another, equally common reaction: fear. As a body of code, Mac OS X was not an evolution or enhancement of the Mac operating system that we knew and loved. It was an entirely different—albeit not exactly new—operating system to which the Mac name and, presumably, user experience were to be retroactively applied.

Fear of just how badly this undertaking could turn out is a big part of what motivated me to not only learn as much as I could about the future of Mac OS, but also to write about it. As a freshly-minted Unix nerd, I couldn't help but be somewhat excited at the marriage of my two favorite operating systems. But laid over that optimism was a blanket of mild hysteria regarding every part of the project above the core OS.

Now here we are, a decade later, and Mac OS X has matured into a fine product. This ten-year marker presents an opportunity to do something technology writers usually avoid. I'm going to look back at some of my hopes and fears from the early days of Mac OS X's development and compare them to the reality of today. Was I right on the money, shrewdly warning of future disasters that did, in fact, come to pass? Or do my predictions now read more like the ravings of a gray-bearded lunatic? It's judgment day.

1999: Mac OS X DP2

The path to the Mac OS X project was littered with broken technological promises and missed ship dates. As it turns out, Apple was about to turn the corner and start actually hitting its dates and keeping its promises. But in 1999, I still had my doubts.

The current party line has Mac OS X on store shelves some time in 2000. I fearlessly predict that it will not appear until 2001 at the earliest.

("Nailed it"…though predicting that a software product will be late isn't exactly a tough call.)

It wasn't really fair to make any sort of judgement about Mac OS X based on the second "developer preview" release, which Apple acknowledged upfront existed only to help developers begin their work and did not represent the final user interface. That's a good thing, because my evaluation of DP2 was not kind.

Actually using DP2 is akin to logging into a demented Xterm running a poorly designed window manager theme meant to look something like Mac OS. Launch a Cocoa application and you feel like you've been warped into NEXTSTEP, again running that funny window manager. Run a classic applications and it's like being in a slightly odd version of Mac OS 9, with that alternate NeXT universe still visible in the background. Pull up the command line and you start to think that all of this is one big facade running on top of good old Unix.

Given how far the final Mac OS X user interface diverged from the one in DP2, this harsh criticism hardly seems relevant. But none of us knew what 10.0 would look like back then. Something called Mac OS X Server 1.0 did exist as a shipping product in 1999, and it and looked a hell of a lot like Mac OS X DP2. It was not beyond the bounds of reason to imagine that the final Mac OS X user interface might be a cleaned up, refined version of this very same interface—and that would have been a bad thing.

Ever looking for the silver lining, I went on to opine that "I'd much rather be stuck using Mac OS X DP2 on a daily basis than Mac OS X Server. They both completely fail the 'Mac-like' litmus test, but DP2 is closer to that goal." Reading that now, it's clear to me just how desperate I was to find something good to say about the UI of this new OS.

The image below is a good distillation of my already slightly desperate attitude towards the Mac OS X user experience. Practically speaking, it compares the mouse movement allowed by Mac OS (green) when selecting an item from a sub-menu to the movement required by Mac OS X DP2 (orange). (Following the green path in DP2 caused the sub-menu to immediately disappear.)

The subtext was this: "Hey, NeXT guys. This is just one example of the kinds of things we Mac users appreciate—nay, expect—in an operating system that bears the Mac name. Slapping a Platinum coat of pixels on your existing NeXT code base is obviously not going to cut it. User interface design is not just what it looks like; design is how it works."

Internals intrigue

The technical underpinnings of Mac OS X were considerably more interesting. Even ten years ago, I couldn't help but dwell on the possibility of an x86 future.

The OpenStep APIs are cross platform. Mach is cross-platform. WebObjects is cross-platform. x86 builds of Rhapsody, Mac OS X Server, and Mac OS X inside Apple have been all but confirmed. Rumor has it that Apple routinely synchronizes all changes to Mac OS X across both PowerPC and x86 builds of the OS. Clearly, Apple's choice of where to deploy its new operating system is not limited by the technology. If they decided to try releasing a version Mac OS X for x86 processors, it would be technologically within their means.

Before you congratulate me for my amazing prescience, consider the next two sentences I wrote: "But will they do it? I seriously doubt it." If you'd asked me to place money on the question, I'd have bet heavily against Apple moving to x86. But I now realize I would have been betting with my heart, not my mind. My brain did get in the final word, however:

The cross-platform card is something to watch for. For the first time, the only thing keeping Apple off of the "PC" platform will be its business plan. And hey, with Steve Jobs calling the shots, anything is possible.

It's interesting to note that only two short years after his return to Apple, Jobs had already (re)cemented his reputation as a fearless and often unpredictable leader. Age had not slowed him down one bit.

File system metadata (which I was then calling "meta-information," for some reason) was also tickling my brain, though mostly in a positive way, believe it or not. I was intrigued by the concept of bundles, especially their use of this shiny new "XML" data format. But while storing metadata in separate flat files within bundles could work for applications, the future of plain file metadata was still in doubt.

How will Mac OS X identify the file type and creator of "regular" files? By file name extension, that concept so alien to traditional Mac OS? Or will HFS/HFS+-dependent type/creator meta-information soldier on into the future? Time will tell.

Note the blithe dismissal, the seemingly complete lack of concern. "Oh well, time will tell." Indeed it would.

2000: Quartz and Aqua

Apple unveiled Aqua, its next-generation user interface, at the Macworld Expo San Francisco in 2000. It was a lot to take in all at once. There was a radical new look for all the familiar interface elements (scroll bars, windows, menus), plus some entirely new elements (the Dock, sheets), all built on top of a new graphics engine, Quartz.

Despite the visual punch of Aqua, I spent the first half of my article on the topic discussing its Quartz underpinnings, labeling it a "third-generation display layer," in contrast to the character-based and non-composited bitmapped display layers that preceded it. More bold declarations followed:

What do Quartz and Aqua mean to the industry as a whole? To paraphrase Steve Jobs once again, it's very clear to me that every computer will work this way someday. No, I don't mean that the world's computer screens will be covered with candied window widgets and genie animations a few years from now. I mean that third-generation display layers are clearly the future. […] Apple is the first of the major players to bring this to market…albeit in a a fashion that is not likely to appeal to anyone but Apple's core market. I expect the rest of the industry to follow in a more conventional fashion in a few years.

Like my Mac OS X ship-date forecast, the prediction above might also seem like a bit of a gimme. But keep in mind that in its initial incarnation, Aqua was unbearably slow and a huge resource hog. Intellectually, most people understand how technology progresses. But the emotional inclination to condemn any feature that is not able to run well on current or near-future hardware is a strong one. I went on to write:

The GUI itself is the prototypical example. At one time, the thought of using memory and CPU cycles to draw windows, menus, and buttons on a bitmapped screen was considered monumentally wasteful. (I'm sure we all know one or two CLI curmudgeons who still think that way.) But the widespread adoption of the GUI was inevitable. In the end, the advantages (ease of use, improved aesthetics, market differentiation) outweighed the obvious disadvantages (speed, size, code complexity).

And so it came to pass. Every contemporary desktop operating system now has a compositing window manager that supports at least one vector drawing API. This is also true of the latest mobile operating systems—one of which is actually based on Mac OS X, of course. And yet if you'd suggested back in 2000 that Quartz, the display layer that made Mac OS X's UI so dog-slow, would, in seven short years, be running on a cell phone lauded for its responsive touchscreen interface, you'd have been declared a lunatic.

Betting against technological progress is always a bad idea. But what many of Quartz's detractors actually meant was not that a compositing/vector display layer was a bad idea, but rather that Apple simply deployed it too soon. Better to wait for better hardware support, they said.

But by the late 1990s, developers were already going to great lengths to achieve Quartz-like effects in classic Mac OS. Had Apple developed and launched Mac OS X without Quartz, those developers would have done the same on Mac OS X. Then, when more capable graphics hardware became available, Apple would have had to convince these developers—who had just ported their applications to a new OS—to update their drawing code to use the new display layer, often to create the very same effects they'd already custom-coded using the old drawing APIs.

There are only so many transitions users, developers, and the platform as a whole can endure. Consider the one "secondary transition" Apple actually did saddle Mac OS X with: the move from Carbon to Cocoa. Though it didn't start in earnest until six years after the launch of Mac OS X, the move still managed to throw some prominent developers for a loop—to the (continuing) detriment of the platform.

Back in 2000, while it was easy to dump on Apple for what it was doing with Quartz, burdening its new OS with a GUI that was slower than the one in its old OS, what Apple wasn't doing was just as important. It wasn't condemning Mac OS X developers to endure yet another significant transition so early in the life of the new OS, and it wasn't diluting its internal development efforts by creating a stopgap API in addition to a true next-generation API.

Aqua

For such a big departure from the past look of Mac OS, Aqua was met with a surprisingly positive reaction. In fact, I considered the very familiar-looking but inconsistent UI in DP2 to be a much greater affront to my sensibilities. Here are a few samples from the first public showing of Aqua. (Please forgive the JPEG compression; those were grim days for PNG support in web browsers.)

Like high school yearbook photos, there's a definite cringe factor to these screenshots. Look at that soft focus on the buttons, the extreme transparency in the menus, and the stripes—oh God, the stripes! But damned if that QuickTime movie of an iMac commercial didn't keep right on playing when that "Go" menu was pulled down in front of it, the action showing through the pinstriped haze in real time. Heady days for a long-time Mac user. I allowed myself to be dazzled, at least for a little while.

The Dock, Finder, etc.

In addition to the new look and feel, Aqua introduced a raft of new features which would come to define the Mac OS X user experience—much more so than the cosmetics, which would change frequently in the coming years. Initially, I spent most of my time just explaining how these things worked rather than analyzing them in any great detail.

Still, I couldn't help taking a few shots at what I'd derisively labelled "The 'New' Finder." Mac OS X 10.0 hadn't even shipped yet and I was already on Apple's case about how little the Finder differed from its wholly unacceptable incarnation in DP2. This, despite the fact that whole swaths of the OS were so obviously unfinished at this point. It's a testament to how important I considered the Finder to be to the overall Mac experience that I was already pressing for change.

At the conclusion of the review, I was left with a long list of unanswered questions. What happened to pop-up folders? (Lower-right in the linked screenshot, whippersnappers.) Where the heck is the Apple menu? How is the Dock supposed to scale? And what is up with that Finder, anyway?

If I'd actually been given accurate answers to all of these questions at the time, my head probably would have exploded.

Mac OS X DP3: the honeymoon is over

As the RDF of the Macworld keynote faded and I got some time to actually use the first release of Mac OS X to include the Aqua user interface, Mac OS X DP3, reality quickly asserted itself. As a contrast to the carefully composed screenshots from Apple's website, I offered a few pictures of a real system in use. The results were not always pretty.

Having lived through the Transparency Wars, long-time Mac OS X users can look back on such screenshots with a knowing smile. Sadly, it seems it's only possible to learn this lesson the hard way.

But for all the complaints, adjusting a few alpha values is trivial. There were much larger issues looming. Take the Dock, for instance—so novel and intriguing in a Steve Jobs demo, but a bit tougher to swallow in actual use. No two ways about it: I gave the Dock a good thrashing.

The Dock, as it currently exists in Mac OS X DP3, is a is a total failure in that it not only fails to improve upon any aspect of Mac OS 8 and 9's equivalent GUI feature, it actually makes every single one of them substantially worse.

Then, later, in the conclusion:

[The Dock] doesn't need to be "fixed" so much as it needs to be split out into individual components that do a particular task (and do it well), rather than a catch-all Dock that does everything atrociously.

While I stand by my assessment of the Dock as it compares to the implementations of the equivalent features in classic Mac OS, I now believe that the radical simplification it brought to the Mac UI has been a net benefit to the platform. For every user who continues to be frustrated by the Dock's limitations, there are thousands of others who are buoyed in their computing efforts by its reassuring simplicity and undemanding design.

I still curse Apple for not providing public APIs that would allow third-party developers to fully replace the Dock. But should Apple have done as I suggested nine years ago and broken up the Dock's functionality into separate interface elements? No, probably not.

As for the rest of the UI, the answers to my earlier questions about Aqua slowly revealed themselves, and I didn't like what I saw. Single-window mode was nuts.

The center-mounted Apple "badge" in the middle of the menu bar nearly broke my mind.

The Classic environment wasn't quite as well visually integrated as it could be.

And, oh yeah, the whole thing was slow as molasses and a RAM hog, to boot. My conclusion was a big, fat downer.

The road to hell is paved with good intentions, and I believe that Mac OS X DP3 has its heart in the right place. It certainly looks very nice, and it is generally impressive in action. But the devil is in the details, and Aqua manages to get most of them wrong.

This is also about the time that the hate mail from Mac users really started to ramp up. When writing about DP2, few people were paying much attention to Apple's new OS project. (Number five in the series; collect them all!) My initial coverage of Quartz and Aqua doted over the technical details and was generally positive about the aesthetics. The Aqua introduction at Macworld got a lot more people interested in Mac OS X, which translated to a larger number of readers. Then came my review of DP3, an OS that many Mac users were interested in, but few had actually used. I had used it, had not liked a lot of what I'd seen, and said so. Though I took pains to qualify my statements, emphasizing that Mac OS X was not even close to being finished, the hate-mail flood gates opened nonetheless.

As someone who got his first Mac in 1984 and had evangelized them to anyone who would listen ever since, it was definitely a new experience for me to be pilloried, both publicly and privately, as an "obviously PC-using Mac-hater." (I'm sure Ars Technica's reputation at the time as a PC-centric website contributed to this perception.) Yes, the honeymoon was over for Mac OS X itself, and for coverage of Apple at Ars Technica. In the coming years, I would continue to write about what Apple was doing wrong with Mac OS X, drawing ever more intense interest from readers on both sides of the Mac/PC battlefront.

Not that it placated either faction in the then-thriving platform wars, but I did try to end each Mac OS X article on a positive note:

I continue to enjoy the technical aspects of Mac OS X, and I hold out hope that Apple will listen to its users and reconsider some of the UI decisions made for Mac OS X.

Mac OS X DP4: resignation

The fourth developer preview release of Mac OS X marked the start of the final push towards release. My UI complaints from the DP3 review were reiterated and elaborated upon. Again, I harped on Aqua's focus on novices.

Although Aqua fills the needs of novice users admirably by clarifying the most problematic features of classic Mac OS, it fails almost everyone else, particularly experienced and/or advanced users with sophisticated needs.

Experienced Mac users pick and choose their favorite UI elements. […] Aqua removes this flexibility, and, most damaging, much of the core functionality that makes it possible. While providing a simplified interface for novices is admirable, it should (and, more importantly, can) be done in a manner that does not take functionality away from experienced users. (Perhaps Apple should revisit the concept of "scalable" interface complexity bandied about during the Copland project.)

If this sounds overblown, recall that when DP4 was released, Mac OS X lacked most of the built-in features and third-party enhancements we take for granted today. There was no Apple menu, no menus for Docked folders (let alone stacks and grids), no ability to pin the Dock at one end or put it on a different screen edge, no Quicksilver, no DragThing, no FruitMenu, no replacement whatsoever for many of the most-used features from classic Mac OS.

Though Apple's focus on the novice would indeed prove to be laudable in the long run, advanced users still need some minimum level of support, and Mac OS X as of DP4 was not providing it. From the DP4 review conclusion:

I suspect that Mac OS X will undergo significant UI changes only after its official release (possibly due to public outcry from experienced Mac users regarding the 1.0 version). In other words, I do not doubt Apple's resolve to ship Mac OS X with an interface feature set that is not a radical departure from that seen in DP4.

There are ample precedents for this phenomenon in the Mac community, the most glaring of which may be the long battle to make the Apple menu hierarchical in classic Mac OS. It took years of shareware Apple menu enhancement utilities to convince Apple to integrate that functionality into Mac OS. Let's hope similar changes to Mac OS X don't take as long.

Apple would prove itself to be even more reluctant to add functionality found in popular third-party applications to Mac OS X itself than it was to do the same in the classic Mac OS era. But what Apple probably considered an appropriately judicious pace seemed agonizingly slow to me at the time. The delta between DP3 and DP4 was not encouraging.

Despite hype to the contrary, I do not believe that the UI changes in DP4, welcome though they may be, have made any significant dent in the problems detailed in my DP3 review, elsewhere on the web, and reiterated in this article.

Mac OS X Public Beta

As 2000 drew to a close, the public beta release of Mac OS X shut the door on all but the most minor UI changes before the official release. It was time to take stock of the other important factors: stability and performance.

Stability, blessedly, had never really been an issue; all of the developer previews of Mac OS X exhibited better OS stability that any release build of classic Mac OS. Very early Mac OS X builds had plenty of application stability issues, but those disappeared at a steady pace leading up to the beta.

Performance, on the other hand, had been a thorn in Mac OS X's side ever since Aqua first appeared on the scene. Knowing the actual slope of Mac OS X's eventual performance ramp, this passage from the beta review's conclusion seems a lot like hero worship mixed with wishful thinking:

Steve Jobs has proven himself to be a notorious stickler for performance. The relevant anecdote from the halcyon days of the original Mac project involves Jobs demanding that the Mac be made to boot faster. His rationale, as related by Andy Hertzfeld, one of the lead designers on the Macintosh project, was that saving five seconds of boot time multiplied by the millions of people who would buy this computer added up to fifty lifetimes. "You're saving fifty lives!", Jobs is said to have proclaimed.

But more important than Jobs' demands for performance is the result of this exchange. In Andy Hertzfeld's words, "it was a nice way of thinking about it, and we did get it to go faster." Is Apple's current crop of engineers as talented and as motivated as the original Mac team? One can only hope.

In the end, it was the design of Quartz that doomed Mac OS X to have a slow GUI in its early years. As previously discussed, despite my frequent complaints about GUI performance, I believe the design of Quartz was justified. I believed that at the time as well, but focused most of my energy on communicating exactly how unacceptable the performance levels were in the first few years of Mac OS X's life (rather than, say, calling for Quartz to be replaced with entirely different, less ambitious display layer).

Classic, the "Mac" part of Mac OS X, and, inevitably, the Finder

In all my pre-release Mac OS X reviews, I spent what now seems like an inordinate amount of time on the Classic environment: its performance, compatibility, stability, resource usage, etc. Once I actually switched to Mac OS X full time, I made shockingly little use of the Classic environment. But as of the public beta, I was far from that transition.

Each time I've sat down to write a Mac OS X review, from the DP2 article right up to this one, I've attempted to create the entire article while working inside Mac OS X. So far, I still haven't made it all the way through.

Initially, this was due to problems in the Classic environment that prevented me from running "legacy" versions of apps like Photoshop and IE. But with Beta, Classic is more than solid enough to run an editor, a browser, and Photoshop. There's even a relatively stable Carbon version of IE. But the problems that I experienced trying to work on this article in OS X Beta were not related to the applications I used, but rather to the way the OS facilitated the interaction between the various parts of my task.

Some of this was not the fault of Mac OS X itself. Many of the applications I needed to do my work had not yet been ported to Mac OS X. And no matter how good the Classic environment was, using half my applications in one (virtual) OS and half in another was never going to be an efficient or satisfying experience.

But there was still the elephant in the room. Was this ever going to be an OS I could adopt wholeheartedly? Would it ever be a true Mac OS?

I want to like Mac OS X. I want to use it as my primary operating system when it's released. I'm tired of applications bringing down the entire system in Mac OS 9. But technical merit is just one part of what makes an operating system, and it has historically been a very small part of what defines the Macintosh experience. The Macintosh is defined by its interface, and any redefinition of that must be at least as good as what it's replacing. Mac OS X Public Beta does not reach that goal.

The Finder in particular continued to peg my this-ain't-no-Mac meter. Having mostly avoided delving into the nitty-gritty details of what made the classic Mac OS Finder such a successful application, I now attempted to articulate its design and the many ways that the Mac OS X Finder failed to fill its shoes.

The Finder has been the single most important and influential application in the Mac OS user experience. Since 1984, the foundation of the classic Mac OS Finder has been the concept of spatial orientation. To quote Bruce Tognazzini again, "spatial orientation" includes "not only the nesting of folders within folders, but being able to recognize a window based on its size, shape, and the layout and coloring of the objects within."

I would revisit this topic—ad nauseam, some would say—in the years that followed. But for all the endless discussion of the "rules" that define a spatial file manager, the heart of the matter is right here in the very first paragraph I ever wrote on the topic. The spatial Finder is not an end in itself; it's simply a means to better leverage an incredibly powerful part of the human brain: visual/spatial recognition.

It's been my experience that this is the aspect of spatial file management that most people don't grasp—both opponents and proponents. It's not about dogma or ideological purity. In fact, it's the exact opposite. Pragmatically, to effectively reap the benefits of visual/spatial recognition, the requisite illusion that certain user interface elements behave according to the same rules that have shaped our brains over millions of years has to be maintained to some minimum degree. And it doesn't take much of a deviation from the expected for a window's spatial characteristics to be written off as an ineffective means of identifying its location in the file system hierarchy.

As for the other aspect—the importance of the spatial Finder to the classic Mac OS experience, and, by extension, how much popular demand there would be for a continuation of this experience in Mac OS X—I must conclude that this is another case where I vastly overestimated the satisfaction threshold of most users. Only the most demanding users can fully appreciate the particular efficiencies inherent in any interface. This is true for the spatial Finder just as it is for the Unix command line. But in both cases, aficionados make up a vanishingly small portion of the computer-using public. I used the term "novice" earlier, but the fact is that nearly all of the people Apple would like to sell to fit this description.

In the case of the Dock, I concluded that the platform is probably better served by presenting a vastly simplified interface than by an approach tailored to the needs of sophisticated users. But in the case of the Mac OS X Finder, a failure to adhere to the spatial metaphor from classic Mac OS has not resulted in an equivalent simplification. Instead, the Mac OS X Finder is now considerably more complex and inscrutable than the classic Mac OS Finder ever was, especially when it comes to the retention of spatial state.

Many have long contended that the limited appreciation of the spatial Finder among users necessarily renders the issue irrelevant. I say the opposite is true. The less able the common person is to consciously recognize the origin and mechanism of an experienced benefit of a product, the more important it is for the creator of that product to provide it. Put more simply, the customer isn't responsible for knowing how to make a better product. The Mac OS X Finder obviously meets the minimum threshold of acceptability among the majority of Mac customers, but there are few that would call it great.

As for users' ability to experience the benefits of spatial consistency, regardless of whether they understand the origin, my views are continually reinforced by the masses' unflagging devotion to the lone remaining relentlessly spatially consistent interface element: the desktop. People love to fill their desktops with files, and the less comfortable a person is with computers, the more likely he or she is to do so.

The reason is simple: the desktop is the one "place" on the computer that every user knows how to get to. People don't even think of it as existing in the file hierarchy (though, of course, it does); to them it's a location in the physical sense, and items placed within it behave almost as if they were real objects. A file can be "lost" in the file hierarchy—irretrievably, as far as novice users are concerned—but finding something on the desktop will never be any worse than rummaging through the messiest real-life junk drawer. And that bargain, that task of keeping things neat by placing, removing, and arranging, is something that people are comfortable with, and that their innate human abilities are tailored for.

This is where I stand with the Mac OS X Finder. Though popular outrage in response to the abandonment of spatial consistency in the Finder never materialized, I remain firm in my conviction that a Mac OS X Finder that retained all the advantages of its predecessor would have a much better shot at greatness. The new browser-style features are invaluable additions, but the sacrifice of spatial consistency was foolish and needless. A Finder that does not leverage such important aspects of human perception can never reach its full potential.

2001: Mac OS X 10.0

The official release of Mac OS X 10.0 brought with it the more prosaic aspects of a proper OS review: discussion of the installation process, some basic benchmarking, reports on resource usage, performance, etc. After many thousands of words about the developer preview releases, there were few surprises in these areas, but the duty to assess the official release remained. Regarding performance in particular, I was blunt.

Mac OS X is slower than Mac OS 9 on the same hardware. The interface is less responsive overall. All classic applications take a minor speed hit. RAM usage is considerable due to the "double-OS" nature of the Classic environment. Despite a superior VM system, OS X can and does get into trouble when the paging activity starts to build on systems with close to the minimum-required 128MB RAM.

(Mac OS X in 128MB of RAM! Imagine!)

The performance summary goes on to discuss two earlier performance hiccups in the history of the Mac platform: the upgrade from System 6 to System 7 and the transition from 68K to PowerPC.

Mac OS X 10.0 suffers from a combination of these ailments. It's got the interface responsiveness and RAM hunger of the color/System 7 transition and the legacy application speed hit of the PowerPC transition, but without the easy native application performance increase.

Is this a fatal combination, or will Mac OS X have a snappy UI and be running classic applications faster than any Mac OS 9 system ever ran them, come 2003? Time will tell, but I think the performance issues alone may be reason enough not to use Mac OS X 10.0 on any system that does not ship with it pre-installed, unless you're an acknowledged early adopter. And yes, since OS X is not scheduled to be pre-installed on any Apple systems for some time, this means that I think even new Mac owners may not want to install OS X on their existing hardware based solely on performance considerations

In essence, my answer to the question, "Should I install Mac OS X?" was, as of version 10.0, a big, fat "no." And remember, this was based on performance considerations alone; the passage above is not from the conclusion of the review, but from the performance summary in the middle. Halfway through and Apple's new OS had already gotten a thumbs down.

More user interface griping followed, mostly just summarizing and, in some cases, elaborating on topics covered in earlier articles. There were few new developments, though the Apple menu had reappeared at Macworld Expo San Francisco 2001, albeit in name only. The contents of the menu were fixed, rendering it unable to fill its former role.

Third-party applications would rush to fill this void, in all shapes and sizes: Dock-based pop-up menu applications, configurable menus on the right hand side of the menu bar, faceless hot-key-triggered launchers, and several faithful reproductions of the classic Apple menu. This is a case where Apple would not budge. As it turned out, some of these new applications far surpassed the old Apple menu's capabilities and efficiency.

Was this part of Apple's grand plan? More importantly, would these new applications ever have been created had Mac OS X shipped with a user-configurable Apple menu? Even if you believe the answer to this question is no, these new applications didn't appear instantaneously. Apple still bears some responsibility for leaving a small selection of its user base in the lurch. I'm sure they're fine with that, and in the end, so am I. Though I believe innovative applications like Quicksilver and LaunchBar would've been created regardless of what kind of Apple menu shipped with Mac OS X, if forced to choose between a classic-style Apple menu and one of these new applications, I'd take the new kids anytime.

File system metadata

With the official launch of Mac OS X, two things became abundantly clear to me. The first was that Apple and I weren't on the same page when it came to the Finder (see earlier discussion). The second was that Apple had chosen its path regarding file system metadata—the wrong path. Apple had decided that the benefits of "non-standard" file system metadata were not worth the costs in terms of performance and complexity, and that file type information was best stored within the file name.

The sheer folly of these decisions was so obvious to me that I had, until then, assumed that the pre-release builds of Mac OS X were just taking a while to overcome NeXTSTEP's primitive notions of file typing and metadata. After all, Apple had very nearly selected BeOS as its next-generation operating system—BeOS, the poster child for the power and utility of extensible file system metadata. Surely Apple understood in which direction the arrow of progress was pointing.

And as for file name extensions, come on! Apple had run an entire ad campaign ridiculing Windows 95 for its primitive, user-hostile file name requirements (C:ONGRTLNS.W95). After 17 years of letting Mac users rename their files with impunity, there was no way Apple was going to slap on the shackles and willingly step back into the 1970s. I mean, right? Right guys? Hello?

And yet that's exactly what Apple did. File names, once completely within the purview of the user, had been partially reclaimed by the operating system, sacrificed on the altar of interoperability. For reasons that probably made a lot more sense to the twenty-something-year-old version of myself, I decided to try to explain what, exactly, is so darn terrible about file name extensions.

Like the Finder article that would come later, my treatise on all things metadata-related was largely ineffective as a means of conversion. Readers' existing views were reinforced, for the most part. What the decision-makers at Apple thought, assuming any of them read what I wrote, is anyone's guess.

And again, like my repeated pleas regarding the Finder, the tragedy of it all was that the benefit that Apple sought—interoperability with other operating systems, in this case—could readily be achieved without lowering Mac OS X to the level of lesser operating systems. No one proved that more decisively than Apple itself with the introduction of Uniform Type Identifiers in Mac OS X 10.4 Tiger. Here was a flexible, extensible, expressive system for representing file type information, far surpassing even the MIME types used by BeOS. And yet here we are, in 2010, and the canonical storage location for file type metadata in Mac OS X remains after the "." character at the end of the file name.

(Adding insult to injury, file creator metadata is apparently being phased out as of Mac OS X 10.6, relegated to its legacy classic Mac OS representation and storage location—now ignored by Mac OS X's application binding policy—rather than being given the obvious modern format and a proper home in an extended attribute.)

By all means, Apple should recommend and support the use of filename extensions for interoperability. But there's no reason for Mac OS X itself to rely entirely on something so fragile as a carefully mangled file name to store and retrieve such an important piece of metadata.

This hurts even more because the other half of my big metadata pitch actually did come to pass…eventually. In 2005, the same year that UTIs were introduced, Mac OS X gained support for arbitrarily extensible file system metadata. Apple wasted no time putting this new ability to good use. In the years that followed, extended attributes would be used in virtually every new operating system feature that had anything to do with the file system. Today, anyone using Time Machine has an entire volume where every single file has several extended attributes.

In the conclusion of my metadata article, I wrote that "the future of metadata in the computer industry is clear: more accurate, and more of it." On the Mac platform, at least, this has now come to pass. The continuing designation of the file name as the one true location for file type information is the only thing holding Mac OS X back. It drags behind "the world's most advanced operating system" like a twisted, gangrenous limb. Trumping even the schizophrenic Finder, the inability to rename files without worrying about breaking something (and the too-clever subterfuge that makes this appear to be possible) is the most glaringly un-Mac-like aspects of Mac OS X.

Taking stock

When something turns out well, as I believe, ten years later, Mac OS X certainly has, it's easy to discount the dire warnings beforehand as symptoms of fear, undue caution, or even prejudice. Suggested remedies also suffer in hindsight. Either they came to pass, in which case the calls for change needn't have been so shrill, or they were obviously unnecessary, given the exemplary present state of affairs.

Reality is much more complex. The many changes made to Mac OS X during its development happened because someone within Apple looked at an existing feature, found fault, devised a remedy, and had it implemented. In my writing, I was forced to stop before the final step. Where I diverged with Apple, it was most often the remedies that differed, though sometimes none at all were offered.

There were definitely times when my anxiety level was "a bit higher than necessary," let's say. My biggest mistake was underestimating the influence of third-party developers, particularly independent developers, on the quality of user experience. Perhaps the biggest compliment that can be paid to an operating system is that it disappears when in use, letting the applications shine through. Fixing the most egregious faults in Mac OS X—the sluggish UI, the awkward classic environment, the worst of the bugs—did that, for the most part. And the applications, whether they were ported from classic Mac OS or newly developed for Mac OS X, turned out to be fan-freaking-tastic.

Obviously, I still think Mac OS X has plenty of room for improvement. Though I may still find myself in a state of panic from time to time regarding some real or imagined disaster looming in Apple's future, I'll be happy if my hit ratio is at least as good as it was in the zeros (or whatever we're calling this decade). I was the most wrong about the Dock and the Apple menu, the most right about file system metadata, and the most unwavering on the Finder. Overall, I give myself a B-, and Mac OS X itself an A-. Here's to another ten years.