Mac OS X 10.2 Jaguar (original) (raw)

Introduction I want to believe. Those words set up my review of Mac OS X 10.1 almost a year ago. Mac OS X began life as the last, best hope for Apple's decade-spanning quest for a modern operating system. At first, it was enough for it to simply exist as a stable, feasible product strategy. … Continued

Introduction

I want to believe.

Those words set up my review of Mac OS X 10.1 almost a year ago. Mac OS X began life as the last, best hope for Apple's decade-spanning quest for a modern operating system. At first, it was enough for it to simply exist as a stable, feasible product strategy. But while developer releases revealed some very interesting technology, they also raised some red flags. The public beta was a warning shot across the bow of an anxious community of early adopters. The initial release reinforced the old Apple saying: "real artists ship." Mac OS X 10.0 had arrived, but there were problems.

By the time version 10.1 was released, I was ready for some salvation. Version 10.1 held the promise of being the "mainstream release"--something good enough for everyone to use, not just the brave early adopters that sweated out the public beta and the 10.0 release. Version 10.1 certainly was a vast improvement over 10.0. The previous statement can be read as praise for 10.1 or as a condemnation of 10.0, but it is undeniable.

In the end, I wanted more than something that was simply "better than 10.0." As I wrote in my 10.1 review:

I want to believe that [Mac OS X] will replace Mac OS 9 in a way that improves upon every aspect of the classic Mac OS user experience. Unfortunately, although this may still come to pass, Mac OS X 10.1 is not that version of Mac OS.

It seemed that even Apple itself didn't fully believe in its new OS, as it continued to ship hardware that booted into Mac OS 9 by default.

Fast forward to the summer of 2002. Apple has converted its entire product line to both ship with and boot into Mac OS X out of the box, and it's ready to release the next major revision of its flagship operating system: Mac OS X 10.2. Note: not its "future" operating system, or its "new" operating system, but its "flagship." On August 24th, strange animal-fur-themed boxes and discs arrived at retail stores everywhere. This time, perhaps things will be different...

Background

Ars Technica has been following Mac OS X since the second developer release in 1999. Earlier articles are listed below in reverse-chronological order, with the major public releases in bold.

The earlier articles contain information that will not be repeated here, as well as concepts that will be referenced but not re-explained. In general, it is safe to assume that any praise or criticism found in the 10.1 article that is not either reinforced or contradicted in this article continues to be true of 10.2.

The test systems used for this review are shown below:

What's in a Name?

The official product name for this release is "Mac OS X Version 10.2 Jaguar." The previous releases also had "big cat" code names. Version 10.0's somewhat inappropriate code name was "Cheetah." Version 10.1 was "Puma." But these code names never spread very far outside of Apple. Developers and technically-minded Mac enthusiasts were aware of them, but that's about it.

Apple has a history of using internal code names as product names. "Macintosh" and "Newton" were project code names that were never replaced with "real" product names. In the case of Mac OS X 10.2, the code name has simply been appended to the version number. Nevertheless, Apple is pushing the name "Jaguar" into the public consciousness.

The box has Jaguar fur on the side. A furry "X" logo has replaced the translucent blue aqua-themed "X" logo from earlier versions. The comparison is striking:

Mac OS X boxes: old vs. new

The campaign has been such a success that "Jaguar" is the most commonly used name for Mac OS X 10.2 among enthusiasts and casual users alike. What brought about this branding decision? I have no inside information, but I do have a few theories...

First, the optimistic take. Historically, code names have been chosen without much regard for how well they work as product names. This allows code names to be strange and exotic. Examples from inside Apple include "Brazil", "Spock", "Nimitz", "Reno", "Serrano", and even the infamous "Carl Sagan"--later litigated into "BHA" (Butt Head Astronomer) and then finally LAW ("Lawyers are Wimps").

Interesting and even offensive code names are a kind of high-tech team-building tool; geeks like this kind of thing. And it is an even more powerful reward to allow the developers to keep their code name, something they usually acquire a significant affection for, even as the project goes into production. This is a classically "Apple" move: rewarding the strange, creative geeks who are down in the trenches doing the real work.

Now for a more cynical angle. The Apple of today has clamped down on previously widespread and similarly morale-building diversions such as software easter eggs, and has even disallowed the use of individual developers' names in applications' credits dialog boxes. Apple software is now created by the whole of "Apple", not by individual developers. (This practice also supposedly keeps outside companies from poaching Apple talent--a dubious means to that end, in my opinion.)

Would this kind of corporation allow a code name to become a product name simply because it makes developers happy? In this environment, it seems more likely that not only the plan to keep the code name as part of the product name, but also the initial selection of the code name itself took place much higher in Apple's chain of command.

Finally, perhaps most realistically, it is likely that Apple learned something from the introduction of Mac OS X 10.1. Despite very significant improvements to the product, a Mac OS X 10.1 retail box looked nearly identical to a 10.0 retail box. The difference between "10.0" and "10.1" printed in very small type is not something that's easy to spot at a distance. Similarly, Apple's Mac OS X 10.1 web site and other marketing materials did not look very different than they did when 10.0 was introduced. You've seen one giant aqua-themed "X" logo, you've seen them all.

And while the product name "Mac OS X" had good brand recognition, not all of the connotations were good. The 10.1 release addressed the biggest problem area of 10.0: performance. But improved performance is not as easy to sell as a collection of whizzy new features. "Mac OS X 10.1 - now with fewer instances of horrendous performance" is not a particularly compelling slogan. In short, Apple did not do a good job of articulating the benefits of 10.1 to the public.

Combine the 10.1 experience with the recent pressure from Microsoft to speed up the adoption rate of Mac OS X and you get a catchy, fur-themed 10.2 release that's hard to miss. Jaguar is branding at its most basic--a completely manufactured association between two totally unrelated things. This is a well-known device for improving recall in all situations (e.g. a waiter taking orders without writing them down), not just in marketing. Regardless of which of the possible motivations listed above contributed to Jaguar's branding (if any), I think it was a very wise decision. Furthermore, offbeat maneuvers like this are part of what keeps people interested in Apple and what makes it fun to be an Apple fan.

Allow me a few final notes on branding. Jaguar furthers the spread of the typeface that is slowly replacing the custom Garamond variant that Apple has been using since the introduction of the Macintosh in 1984. Samples of the new and old fonts are shown below.

Apple fonts: old vs. new

If any of the font gurus out there know exactly what the new typeface it is, or if it's another custom font variant made just for Apple, please let me know. [Update: survey says...it's a variation of Adobe's Myriad typeface.]

Of course, a company like Apple that is so strongly associated with a vegan CEO would never think of using real animal fur in its advertising. Steve Jobs had his other company render computer-generated fur for all of Jaguar's marketing materials. Even the fur-themed desktop background that ships with Jaguar is named "Faux Fur" to ensure that there's no politically incorrect misunderstanding. So while some things may change at Apple, it's nice to see that other things remain the same.

Finally, as a surprisingly large number of Mac users probably already know, Jaguar--a code name that became a product name--already has a nickname: "Jag-wire." You'll also see it spelled "Jagwyre", both with and without the hyphen. The spelling varies because the source of the nickname is speech, not text. Steve Jobs pronounces the word "Jaguar" so that it sounds like "Jag-wire." Apparently this is a regional California accent, not a personal quirk. Then again, he also pronounces "automatic" as if the first syllable sounds like the word "owe", so who knows what's really going on. Speaking as an easterner, "Jag-wire" sounds pretty strange to me. Apparently other Mac users agree, and "Jagwire" has caught on as an oddball, fashionable, and possibly even "133+" nickname for Mac OS X 10.2. What a world.

Installation

Jaguar comes on three CDs: two discs for installing the OS, and one disc containing the developer tools. The slim pamphlet that comes in the Jaguar box (it can't rightfully be called a "manual") cryptically notes, "Your copy of Mac OS X may include the Developer Tools CD." Perhaps the inclusion of the developer tools with the OS has been debated within Apple, and the printed materials went to press before the final decision was made?

Although both Mac OS X 10.0 and 10.1 came with a Mac OS 9 installation CD, Jaguar does not. The classic environment used for running older applications remains in Jaguar, but the user is expected to furnish his own copy of Mac OS 9. This appears to be the penultimate signal from Apple that Mac OS X is the One True Apple Operating System. The only card left to be played is the replacement of all remaining hardware products that can boot into Mac OS 9, and I suspect that is due very soon.

The first thing long-time Mac users will notice when booting from the Jaguar installer CD is that the "Happy Mac" startup icon is gone. In place of a tiny, smiling picture of a classic Mac, a dark gray Apple logo appears in the center of the screen. The new startup screen looks something like this:


The new Jaguar startup screen

This screen is not specific to the installer. All Macs running Jaguar will show this image when starting up. Also, note the total lack of color...you know, just in case Mac OS X ever needs to boot on a device without a color screen... (cue X-Files music ;-)

Although I personally find the new startup screen very classy, and a good match for the new Apple hardware, I can't help but mourn the passing of our beloved Happy Mac. If you're too broken up over the loss, you can always restore the Happy Mac to its rightful place on your screen.

The Jaguar installer offers a few new choices, but is otherwise the same as it was in 10.0 and 10.1. The first difference is probably the most useful. In addition to the normal upgrade installation and the "clean install", there is now an installation option that combines the benefits of the other two.

An "upgrade" installation is essentially an "overlay", over-writing any older files with the same names, creating new files, but generally not deleting old OS files that do not exist in the new version of the OS. This is seen as a less desirable installation method by those seeking to reap the largest benefits from the new OS version. There is some anecdotal evidence to suggest that an "upgrade" installation results in a more troublesome system than the "clean install" option described below. (Whether or not the "left-over" files from older OS versions are the cause of the observed problems is debatable, since there are may other variables.)

A "clean install" is on the other end of the spectrum. It erases the target disk before installing the new OS, ensuring a fresh start for the user. The obvious disadvantage is the loss of all data and customization. The user must re-install all his applications, re-create the user account(s), and so on.

The hybrid "archive install" approach starts by setting aside any existing Mac OS X installation by moving or copying files to an out of the way directory on the target disk. It then installs Jaguar and migrates the existing user accounts, network settings, and so on to the new installation. In this way, the OS gets the benefit of a clean installation in which its files don't have to mingle with those from the previous version, and the user is not forced to wipe the entire disk and start from scratch.

Despite the possible advantages of an "archive install", I chose to do a normal "upgrade" installation on both the G3/400 and the G4/800. My OS X installations are extensively customized with third party Unix software, and I simply couldn't determine with certainty whether or not the hybrid installation would retain all of those customizations. I'm also of the opinion that the only problems cured by a "clean install" are ones that existed already but had yet to manifest themselves. In other words, it was my hope that my systems were well-managed enough that an "overlay"-style upgrade would not reveal any buried bodies.

The second important change in the Jaguar installer is the increased granularity of the custom installation options. Localized resources and third party printer drivers are broken up into many small optional modules. Excluding the far-eastern localized files alone saves almost a gigabyte of disk space.

While optional OS components can be installed later (by double-clicking the package file on the install CD, not by using the installer application), individual items must still be manually extracted using a third party tool.

I finally decided to install the printer drivers, but I omitted all non-English localized files.

In an interesting change, the bundled applications (iTunes, iMovie, iPhoto, etc.) are also an optional installation choice in Jaguar. The applications are all on disc number 2, leaving only the OS itself on disc 1. They are installed by default, of course, but users who don't want them now have the option of decreasing OS X's disk space usage even further.

The installation process was painless for me. The simple registration screen can still be easily skipped by hitting command-q, and there are still no long serial numbers to enter or any other copy protection annoyances to deal with. But even after a successful installation, I still had a lot of work ahead of me in order to restore my systems to their previous state...

Unix Changes

Jaguar includes (and was presumably compiled with) gcc version 3.1. While there are binary incompatibilities between gcc3 and gcc2 (used in 10.0 and 10.1), Apple has been careful to either hide or avoid these differences. In particular, Apple has worked hard to ensure that drivers compiled with gcc2 for Mac OS X 10.1 continue to function in 10.2. I planned to rebuild all my custom-installed Unix software using gcc3, just to be safe.

As it turns out, some of that software did break when I upgraded. For example, executables that linked to Mac OS X's curses library (used for manipulating text in terminal windows) now died with symbol resolution errors. Apple moved the curses library form libSystem to a library of its own (where it is generally accepted that it should have been from the start). Programs that use curses now need to be recompiled so they explicitly link with the curses library in its new location.

This type of thing is not uncommon in the world of Unix, but it should not affect anyone who hasn't intentionally modified that environment. Those who have (like me) are expected to know enough about what they're doing to fix the problems themselves. All of the Apple-supplied Unix software was upgraded along with the rest of 10.2, of course, so casual Unix users should not experience any problems.

The Unix side of OS X has been expanded and improved considerably in Jaguar. In addition to the new gcc3 toolchain, previously available technologies have been fleshed out and new features have been added. There is now a more extensive set of command line tools for dealing with SMB (Windows) file servers. IPv6 and IPSec support have been added to the kernel. The Common Unix Printing System (CUPS) is now included, opening up a new world of printer drivers to Mac users--provided they're willing to brave the configuration process. Not all of these Unix infrastructure improvements have friendly GUI front-ends in Jaguar, but even those that don't are still hard at work behind the scenes.

There have been so many far-reaching improvements to the Unix foundation in Jaguar that it is difficult to complain about any small omissions. On the other hand, the fact that the rest of the Unix layer was so comprehensively updated makes the few stagnant areas all the more glaring. My personal peeve is that Jaguar ships with the same version of Perl (5.6.0) that came with 10.0. Perl 5.6.0 was released in March of 2000--over two years ago. Perl 5.6.1 was released in April of 2001. Perl 5.8.0 was released in July of 2002.

I can understand Jaguar not having Perl 5.8.0, but sticking with 5.6.0 is a real detriment to Perl development on the platform since most users don't have the desire or the ability to upgrade Perl on their own. Anyone distributing Perl code for Mac OS X must assume that users are running 5.6.0, with all the bugs and problems that entails. In particular, installing third party Perl modules from CPAN, something that should be a simple process, is made much more difficult for the Unix novice by bugs and other unfriendly behaviors in the default installation of Perl 5.6.0.

The handy ncftp command was also removed in Jaguar, but the default ftp command now has greatly expanded abilities which (almost) make up for the loss. And there are other minor issues like the movement of the default shell initialization files to a different location, disabling some convenient aliases for users who don't know how to re-enable the files. But in general, the good far outweighs the bad. (They even added ruby and python, but Perl fans will not be appeased so easily! ;-)

Upgrading Perl to 5.8.0 and recompiling all my old Unix software and libraries (apache, mod_ssl, Berkeley db, mysql, expat, etc.) gave Jaguar a chance to shine. Or perhaps it gave the Unix community a chance to shine. As with Linux in its early days, Mac OS X started life as the ugly duckling of the Unix world. Unix software that compiled just fine on the various BSDs, Solaris, Linux, and even AIX had to be manually tweaked to build on OS X. As time has passed, the Unix developer community has added Mac OS X support to their build scripts and configuration systems. The result is a much less painful build process for popular Unix software, almost all of which correctly detects and accounts for the fact that it is being built on Mac OS X.

This is especially impressive, given OS X's somewhat exotic dynamic linking mechanism and symbol namespace handling. Of the software I (re)compiled, only the mod_perl-enabled apache executable required special attention. Perhaps thanks to the popularity of OS X among (to use Tim O'Reilly's phrase) the Alpha Geeks, OS X seems to be maturing into a well-supported Unix flavor even faster than Linux did.

Satisfied that I'd recreated my Unix environment with fresh gcc3-compiled software, I moved on to the GUI side of the OS...where a few more compatibility issues awaited me.

Developers, Developers, Developers!

It's no secret that I find fault with many aspects of the OS X GUI, so it should come as no surprise that I run several third party applications that enhance the GUI. The list includes TinkerTool, WindowShade X, FruitMenu, DragThing, Menuversum, and Yapsu. Some of these applications use unpublished APIs and other techniques that are not "officially supported" by Apple, so it is not unexpected for them to break after a major OS upgrade. Developers that choose to use APIs that Apple has clearly stated are not public and are subject to (incompatible) change without notice have only themselves to blame when their applications break in Jaguar. Right?

In my view, the situation is not that simple. Developers of some types of the applications above are faced with a choice in Mac OS X: use private APIs and other "devious" techniques to implement their functionality, or give up completely. In other words, there are many marketable features that simply cannot be added to Mac OS X without using "illegal" techniques. So it's not as if these developers are using private APIs and clever runtime patches out of spite. There is simply a demand for these kinds of applications, and these developers are addressing it.

There has been a somewhat uncomfortable truce between Apple and these developers. Apple either does not plan to, or has not yet had time to add certain functionality to OS X, and these developers have found a way to provide it. This is a market opportunity for the developers, but there is always the risk that Apple will eventually add these features to the OS, eliminating the third party market for them. And in the meantime, these developers have to be diligent about tracking the changes in OS X to ensure that their applications continue to work.

But if Apple cannot find time to (or does not ever plan to) add the functionality represented by these applications into OS X itself, it would seem to be in Apple's best interest to eventually supply a set of officially supported APIs to enable developers to more cleanly extend the OS. This would be in the best interest of everyone involved. Developers would have a more stable and maintainable code base. Apple would have more assurance that third party applications would not endanger the stability of the shared system services that they modify or extend. Users would get the functionality that they want. Developers would get money. Apple's platform would be made more capable and flexible. It would be a win-win-win situation.

This strategy may be in the works at Apple, but it is not here yet. For example, although Dock-like third party applications are popular, it is not yet possible for a third party developer to create an application that completely replaces the Dock. So far, no one has been able to support things like Dock menus, application icon updates and alerts, and displaced window minimization, using either private or public APIs. So anyone using one or more of the popular Dock-like applications must also keep the Dock running (and possibly also visible) or be resigned to losing the Dock functionality that cannot be reproduced elsewhere.

While there are no public APIs for Dock-replacement applications, there are public APIs for some other OS extensions. Developers can create new menus in the right side of the menu bar using the NSStatusBar API, for example. But Apple's iconic menu bar items, called "menu extras", use a different and more capable API. The Apple-supplied menu extras (e.g. sound volume, monitor resolution, etc.) can be rearranged by dragging and can be activated or disabled by dragging them onto or off of the menu bar.

True to form, industrious third party developers saw that they could gain a competitive advantage by supporting this more capable user interface in their applications. Apple's private menu extras APIs were reverse engineered and leveraged to great effect. The architecture was so popular that an application for managing predefined sets of menu extras (third party or otherwise) was in development.

All of that changed with the release of Jaguar--but not because the private APIs had changed. If they had, third party developers would have updated their applications to work with the new APIs, as they have resigned themselves to doing by choosing to use private APIs in the first place.

But what actually happened in Jaguar was that Apple added code to forcibly exclude all non-Apple menu extras. Other parts of the API did not change. But when a menu extra is loaded, it is compared to a hard-coded list of "known" menu extras from Apple. If the menu extra is not on that list, it is not allowed to load.

It's easy to laugh at Steve Ballmer's sweat-soaked gyrations as he chants "developers, developers, developers!", but Microsoft clearly understands something that Apple is still struggling with. It is in a platform vendor's best interest to encourage development for its platform. In Apple's case, this doesn't mean that they have to bend over backwards to make every single system service and UI element "pluggable" via public APIs. That's clearly a lot of work, and not something that needs to be the number one priority for an OS in its infancy. And in the meantime, if third party developers want to sell into a market that requires the desired functionality to be added in "unsupported" ways, then they must be prepared for the maintenance consequences of their decisions.

But for Apple to _go out of its way_--to actually _expend developer effort_--to stop these third party developers, while still failing to provide a supported alternative, is incredibly foolish. "Developers, developers, developers!" To Apple, perhaps that seems like a proclamation of derision!

I have not yet heard convincing justification for Apple's behavior in this situation. The official party line is that those APIs were never public to begin with and that third party developers should use the less capable NSStatusBar API. This reasoning would justify any actual menu extras API changes that, as a matter of course, broke third party menu extras. But it does not justify expending development time solely to hurt third party developers, with no other legitimate API changes.

I have also heard that Apple does not want bugs in third party software to reflect poorly on its software. Since all menu extras are loaded as plug-ins by the SystemUIServer in OS X, a buggy third party menu extra could theoretically bring down the entire SystemUIServer, causing all menu bar icons (and other things controlled by the SystemUIServer) to disappear (and presumably reload a second or two later).

But most users are not nearly as careful when assigning blame as this argument suggests. When any application of any kind crashes for any reason, it has the potential to reflect poorly on Apple. And it's not as if there has been a rash of buggy, crash-prone menu extras to justifies this offensive from Apple. I used the word "theoretically" earlier to describe the threat from buggy third party menu extras because I have never seen a menu extra of any kind crash, let alone crash in such a way that the entire SystemUIServer crashes.

On the other hand, I have seen plenty of total UI freezes and a handful of kernel panics that have nothing to do with menu extras. Clearly, menu extras are not among the stability culprits in OS X.

Not only does the new third party menu extra restriction reflect poorly on Apple, it is also a futile gesture. The block was broken in several different ways before Jaguar was even released. So not only was the block unable to actually block third party developers, it has also led to one more "unsupported" bit of third party code running on Mac OS X.

No one wants this type of thing to turn into an arms race between Apple and its developers. Speaking as a user, I just want my software to work. With only one or two exceptions, all of my own personal third party OS enhancements now run on Jaguar--despite Apple's efforts to the contrary. This is not a healthy relationship, and something needs to be done.

I hope it's clear to Apple by now that they can't simply wish away the desires of any portion of their user base. No matter how small the market, some software vendor somewhere will try to address it. This is a good thing. This is a sign of a healthy platform. This is something that should be encouraged by Apple. And if it cannot immediately be encouraged due to resources being allocated in more important areas, I don't think it is too much to ask for Apple to keep from expending any extra effort to intentionally harm third party developers who want to address this market. Sheesh.

What's New, Pussycat?

It's a testament to comprehensive interface simplification of Mac OS X that I'm able to cover almost all significant new features of Jaguar by looking in a single application: System Preferences. As an added bonus, it also provides an example of the new capabilities of the toolbar widget. In addition to the four previous combinations of icons and labels, there are now variants with both small icons and small labels. Behold the possibilities:

Not all applications currently take advantage of these new modes, but I suspect that will change with time. Now, onto the new features.

The System Preferences have been rearranged once again in Jaguar.

The groups make a bit more sense this time around, particularly the "Personal" category which is wisely placed at the very top of the window. On the other hand, poor QuickTime is still stuck in the "Internet & Network" group for some reason. If this bothers anyone, System Preferences now provides an option to organize the items alphabetically...although this mode is likely to make you realize how convenient some kind of grouping really is.

Jaguar now supports desktop picture rotation. The option to change every 5 seconds may seem extreme (ahem), but we'll see the connection to another Jaguar feature a bit later.

Four font smoothing modes are available in Jaguar: Standard (labeled as "best for CRT"), Light, Medium (labeled as "best for LCD"), and Strong. Samples of the different modes are shown below. PNG versions are provided in separate links.

All of the modes except "Standard" use what is often called sub-pixel rendering. This is a bit of a misnomer (or, at the very least, it is too vague) since all of Mac OS X's rendering algorithms can and do (conceptually) place items at fractional pixel positions. But what is commonly meant by "sub-pixel rendering" is that the horizontal resolution is effectively tripled by treating the side-by-side red, green, and blue picture elements that make up each pixel as separate entities. A more detailed explanation of this technique is available at grc.com.

This font smoothing technique only works to its fullest effect when the red, green, and blue picture elements are placed side-by-side in each pixel (some CRTs have a triangle arrangement) and are in a known order. LCDs fit this description perfectly. The "Standard" mode used the font rendering technique from Mac OS X 10.1 and does not exploit the individual picture elements of each pixel.

When a tablet is connected to a Mac running Jaguar, the "Ink" preference panel appears, revealing Jaguar's new handwriting recognition feature. Yes, it's true, Apple has finally done something with all that left-over Newton technology.

Ink can be used to enter text anywhere in Mac OS X. Once an interface element that accepts text has the input focus, the user can simply start writing anywhere on the screen and a translucent, dynamically expanding sheet of lined yellow paper will begin to appear beneath the pen. It's a very clever interface. Ink also supports some simple editing gestures (mouse-over the "gestures" tab above)

Recognition accuracy is excellent if you print legibly and separate your letters. If, on the other hand, your handwriting looks like mine, it will take some dedication to slow down and "draw" each letter well enough to be correctly recognized. If not, you'll get results like those shown below.

The Ink QuizMatch up the handwriting on the left with the result on the right.
1. A.
2. B.
3. C.
4. D.
5. E.
6. F.

Check the answer key at the bottom of the page to see how you did.

As fun as Ink is to play with, its presence in Jaguar is a bit puzzling. Its recognition ability isn't really all that bad--my handwriting is mostly to blame for the comical results above. But a keyboard is a much more efficient (and accurate) input method.

The only logical conclusion is that Ink is the first step towards hardware that can run Mac OS X but lacks a keyboard. Although waiting for an Apple tablet or PDA is like waiting for Godot, what other possible conclusion can be drawn? Does Apple really think that pen-based text input will ever be used when a keyboard is available. Like I said, puzzling...

The new "My Account" preference panel provides simple and convenient access to the current user's account settings. This functionality was previously available only in the slightly more intimidating "Users" preference panel which provided access to all user accounts. The new, simpler preference pane, placed in the "Personal" group, is a welcome change. Observant readers will also note a link to "My Address Book Card" in the screenshot above. More on that later.

The "CDs & DVDs" preference panel specifies the actions to be taken (if any) when various types of media are inserted. The event can be ignored, or an application of the user's choice can be launched. These actions used to be a hodgepodge of (possibly conflicting) application preferences, and it's nice to see them properly centralized in Jaguar.

The "Energy Saver" panel has removed the slider for the hard disks sleep setting, replacing it with a simple checkbox that offers to "put the hard disk to sleep when possible." Much more importantly to me, the bug that used to cause the secondary hard drive on the G3/400 to spin down constantly regardless of the Energy Saver settings in both Mac OS X 10.0 and 10.1 is blessedly fixed in Jaguar.

There is now a setting for scroll wheel speed in the Mouse preferences. This is a bit odd since Apple still does not ship anything but single-button mice with no scroll wheels, but it is a welcome addition. The only complaint is that the lowest setting seems a bit too slow and the next highest setting seems a bit too fast.

The iDisk tab of the Internet preferences provides information about your current usage and a few simple permissions settings. (Yes, iDisk storage is no longer free, but I'm not going to rehash the entire ".Mac" debate in this article. Take it to the forums.)

The Sharing panel has been expanded and reveals some new functionality. The Services tab shown above now includes Windows file sharing--a visible benefit of the expanded SMB capabilities of the Unix layer.

The new Firewall tab provides a simple GUI for the packet filtering capabilities that have been in the kernel since Mac OS X 10.0. The interface is as user-friendly as a firewall can be, and there are presets for many common protocols. (Believe it or not, not everyone knows that Gnutella uses port 6346 ;-)

Unfortunately, configuring the firewall through GUI wipes out any settings that may have been added through traditional Unix-isms like shell scripts. Since the GUI can't create firewall rules that are more complex than a global allow/deny based on port numbers, advanced users must use a more sophisticated third party GUI firewall tool, or simply stick to traditional shell scripts.

The Internet tab presents a nice GUI for a feature that required a four or five line shell script in previous versions of OS X. But for most users, until a feature has a friendly GUI, it might as well not exist. Like the firewall GUI, the connection sharing panel is very simple, and more advanced users are free to ignore it and continue to customize from the Unix side of the fence.

The new Classic preference panel now provides a old-style memory allocation view of running classic applications. The window that appears when the classic environment is starting up is much smaller now, perhaps emphasizing its diminishing role.

The Date & Time panel sports a fancy new map graphic. Talking alerts return in the form of the "Spoken User Interface" tab in the speech preference panel. The greatly expanded Universal Access panel sports many new usability options. And I haven't even mentioned all the preference panels that only appear when supported hardware is attached (e.g. handwriting recognition in the "Ink" panel and MIDI support).

Unfortunately, I simply don't have the hardware to test all of Jaguar's new features. I hope this whirlwind tour of System Preferences gets across the point that Jaguar is most definitely a "features" release. While there are certainly performance improvements and subtle refinements, the overwhelming message of Jaguar is that it Does More. And we haven't even covered it all yet. Before we get to all the new and improved bundled applications, let's take a diversion into two of the important new core technologies in Jaguar.

Answers to the Ink Quiz - 1:D, 2:E, 3:A, 4:F, 5:C, 6:B ?

Rendezvous

Rendezvous is Apple's brand name for a technology that is hard to explain to the average computer user, and potentially even harder to market. I'm going to come at it from a few different angles. First, here is the (mildly) technical side of the story.

Technology

Rendezvous supports four important services.

  1. IP interface auto-configuration.
  2. Translation between host names and IP addresses.
  3. Service discovery.
  4. IP multicast address allocation.

The first two items sound like services you probably already have. Your network interfaces might automatically configure themselves by contacting a DHCP server. Translation between host names and IP addresses is done with the help of one or more DNS servers (possible also configured by your DHCP server). Service discovery sounds like something that's already handled by one of the many directory services that exist today (e.g. Active Directory on Windows.) The last item in the list sounds kind of esoteric. So who really needs these services?

The picture starts to become a bit clearer when the list of services is rewritten in terms of existing technologies in the same areas. How does this slightly revised list strike you?

  1. Allocate addresses without a DHCP server.
  2. Translate between names and IP addresses without a DNS server.
  3. Find services, like printers, without a directory server.
  4. Allocate IP Multicast addresses without a MADCAP server.

Suddenly we've gone from a list of seemingly uninteresting services to a set of capabilities that sound like magic! The last one still sounds a bit uninteresting, but it's actually a strong hint about how the whole system works.

Put simply, Rendezvous enables a local network of devices to configure themselves without the aid of any centralized servers. The key word here is "local", because Rendezvous only applies to a limited network domain. Rendezvous is not designed to scale to support the entire Internet. It is meant for small to medium sized networks.

All the magic happens through cooperation. Participating devices talk amongst themselves to sort out who has what address and what hostname, etc. This communication is done through the use of multicast IP addresses.

In order to bootstrap, all participating devices initially communicate using a "well-known" (i.e. pre-defined) multicast address. The first step is for each device to assign a unique IP address to all of its network interfaces. These so-called "self-assigned" addresses are taken from a special address block reserved for this purpose: 169.254/16.

(This address range may look familiar to those of you who have seen a machine fail to get an address from a DHCP server and then fall back by assigning itself (thus "self-assigned") an address in this range.)

Before continuing, it's important to note that these self-assigned addresses may be (and probably will be) assigned in addition to a device's "normal" Internet IP address. Remember that a single network interface can support multiple IP addresses.

Of course, the trick to self-assigned IP addresses is ensuring that no two hosts assign themselves the same one. To resolve these conflicts, Rendezvous-enabled hosts are able to "ask" simple questions (again, using well-known multicast IP addresses) such as "does anyone else have this address?" Address conflict resolution is actually done dynamically on an ongoing basis, rather than only once when a device is initially configured. This is possible because all Rendezvous services share the same dynamic configuration policy.

Take service number two, for example: translation between host names and IP addresses. Since IP addresses may change at any time due to the ongoing dynamic address conflict resolution, so too must hostname assignment and lookups be done dynamically on an ongoing basis. Again, well-known multicast IP addresses are used to ask questions such as "is anyone else using this hostname?" and "what IP address currently corresponds to the hostname 'foo'?"

Remember that there is no central server, so the answers to these types of questions come from the only authoritative source: the other hosts themselves. Each host is responsible for responding to questions about itself--questions that only it can answer with certainty.

Note that these Rendezvous hostnames only have meaning within the current network and exist in addition to any "normal" Internet hostnames that may be associated with the device.

Given this ad-hoc network of devices, the third item, "service discovery", is straightforward. Devices ask the network at large, "is anyone providing the service 'foo'?" Any device on the network that is providing the requested service will respond, saying "I am providing that service."

Finally we get to the last item in the list: IP multicast address allocation. This service is used to dynamically allocate application-specific multicast IP addresses. Rather than using "well known" multicast addresses (which every device is listening on) for all communications, devices can request the use of a private multicast address for a given network scope. As you'd expect by now, all participating devices cooperate to share the finite pool of multicast addresses pulled from the address block reserved for this purpose.

In truth, these services have all been provided by earlier technologies like AppleTalk, NetBIOS, and IPX. The first thing that makes Rendezvous different is that it is an open standard. Rendezvous is merely Apple's name for its implementation of the technologies proposed by the Zero Configuration Networking (Zeroconf) workgroup of the Internet Engineering Task Force (IETF). Apple does not "own" the technology any more than it owns IP networking or any other Internet standard.

The second thing that makes Rendezvous different is that it is built using existing IP networking technology. It communicates using standard IP networking. It uses standard DNS request packets for name resolution. Device and multicast addresses are allocated from address blocks explicitly reserved for this purpose. There is nothing proprietary or vendor-specific about it, and it is designed to work on existing IP networks without requiring any changes to them and without causing interference of any kind.

Network administrators reading all of this may have reservations as they envision network broadcast storms and other unfriendly behaviors that were exhibited by earlier proprietary protocols. The Zeroconf specification was written with this in mind, however, and there are restrictions on such behavior. It remains to be seen exactly how much less "chatty" the first implementations of Zeroconf really are, but the use of existing packet formats and addressing techniques will certainly give it a big head start on proprietary protocols that need to have each of their proprietary packets "wrapped" in standard IP packets before transmission.

History

A look at the history of Rendezvous is also instructive. As mentioned earlier, Rendezvous is Apple's brand name for its implementation of the Zeroconf standard. Zeroconf, in turn, traces its roots back to a discussion on a Macintosh network programmers' mailing list in 1997. The idea was to give IP networks the same ease of use enjoyed by AppleTalk networks.

Since 1997, Apple itself has made a transition from AppleTalk to IP networking, and in the process it has lost some of its historic ease of use. So it is not surprising that a standard designed to make IP networking more friendly was originated and eventually ended up in use at Apple.

With each foray into the world of standards, Apple is improving both its behavior and its success rate. The Bad Old Apple suffered from a severe case of Not Invented Here syndrome, insisting on inventing its own proprietary standards for just about everything. This often allowed Apple to leapfrong existing technologies, especially in the area most important to Apple: ease of use. AppleTalk is a great example of this. It provided a very friendly networking experience to the masses long before ease of use was even a consideration for most other networking standards.

The disadvantage of proprietary standards is that it's very difficult to get them adopted by the rest of the industry. No one wants to tie part of their business to a technology owned and controlled by a competitor. A standard that does not get adopted by the rest of the industry suffers in several ways. First, the entire cost of development must continue to be shouldered by a single company, rather than shared across the entire industry. Second, a smaller market means lower volumes, higher prices, and fewer choices. Finally, inevitably, industry-wide open standards eventually catch up with the proprietary technology, rendering it an island of interoperability.

AppleTalk suffered all of these fates. Apple's choice to move away from AppleTalk and towards IP networking was unavoidable, largely due to the explosion of the Internet. But this change met with some resistance because IP networking had not yet caught up to AppleTalk in terms of ease of use. Rendezvous finally closes the gap, providing the few remaining AppleTalk-like services that IP networking lacked.

More importantly, Apple has accomplished this not by defining a new, proprietary Apple-only extension to IP networking, but by working "within the system" to help define an open standard that is compatible with existing networks.

It's certainly a lot easier (and quicker) to unilaterally create a new proprietary standard. This interview with Stuart Cheshire, the chairman of the Zeroconf working group and an Apple employee, gives some insight into the difficulties of convincing the IETF that "ease of use" was even an important quality for IP networking to have. Here's what he had to say on the topic:

The IETF is generally populated by people who care very little for ease-of-use [...] Even today, it remains a something of a minority view in the IETF. Most IETF people work for router vendors, ISPs, backbone providers, telephone companies, etc., and their focus is wide-area networking. If you work for a company that makes routers, you've not going to be very excited about technology that lets computers communicate directly, without needing a router. If you work for a company that sells a DHCP server, you've not going to be very excited about technology that lets computers communicate without needing a DHCP server. If you work for a company that sells DNS servers, you've not going to be very excited about technology that lets computers communicate without needing a DNS server. I'm sure you get the point.

But ease of use is incredibly important to the end user, and will only become more important as more potentially networkable products are introduced. So, finally, let's look at Rendezvous from the perspective of the consumer.

Consumer Applications

Many computer enthusiasts take pride in their meticulously constructed home networks that support many PCs, printers, and other devices. But even the best home networks have growing pains, and it's very common for even self-described geeks to struggle to get every device to reliably communicate with every other device. When a friend visits with his laptop, the home network is put to the test as the new device attempts to join the party.

And this is a best case scenario. Most personal computer users have no idea how to even begin constructing a home network like the one described above--which is why geeks take pride in their networks, of course.

Now imagine a world where creating a home network is a simple as connecting all the devices with ethernet cables (okay, granted, you can screw that up too, but stay with me here) and turning them all on. Without any additional effort, every device can see every other device and can ask interesting questions like "are there any printers out there?" and "is anyone serving MP3s?"

As mentioned earlier, Rendezvous functions on a limited scale. It would be nice if the entire Internet was self-configuring, but that is a significantly more daunting problem to tackle. So any home network will still have to deal with the vagaries of NAT and DHCP and the rest of the alphabet soup that lets every computer in the house pull up the arstechnica.com web site.

But for a certain class of devices, communicating locally is much more important than being a node on the wider Internet. What Rendezvous does is provide a separate, totally self-configuring communication domain dedicated to local data exchange.

Stop thinking about PCs and web sites for a second and start thinking about personal video recorders, stereo systems, and DVD players. The ability to listen to your MP3 collection from any stereo in the house, or (to use Stuart Cheshire's example) to view programs stored on one or more PVRs from any TV in the house is very attractive. But you probably don't want to share your TV viewing habits with the whole world, so the local-only domain of Rendezvous networking actually becomes a benefit, and even a security feature.

It doesn't take much imagination to think of ways that Apple can leverage this technology. As we'll see a bit later, Jaguar includes a few interesting applications of Rendezvous, with more sure to follow in the coming months.

Quartz Extreme

Quartz Extreme is Apple's name for the new GPU accelerated version of the Quartz Compositor. This is not one of Apple's more inspired product branding efforts, and many Mac enthusiasts have taken to calling it by the more descriptive (or at least less embarrassing) name QuartzGL. I'll simply refer to it as QE.

The Quartz display layer was examined in several earlier articles. Here's a crash course in Quartz to refresh your memory.

Quartz in a Nutshell

Quartz is an umbrella term that describes the core technologies used by Mac OS X to render images. It has two parts: Quartz 2D and the Quartz Compositor.

Quartz 2D (formerly "Core Graphics Rendering") is a vector-based 2D drawing library. The Mac OS X System Overview describes its capabilities succinctly:

[Quartz 2D's] APIs allow you to create text and images by specifying a sequence of commands and mathematical statements that place lines, shapes, color, shading, translucency, and other graphical attributes in two-dimensional space. You do not need to specify the attributes of individual pixels. As a result, a shape can be efficiently defined as a series of paths and attributes rather than as a bitmap.

Quartz 2D accepts input from a variety of sources and can produce output in several different formats, including PDF, PostScript, and of course bitmaps suitable for screen display.

Quartz 2D has several "sibling" APIs that also produce bitmapped data for screen display: QuickDraw, QuickTime, and OpenGL. QuickDraw actually uses some Quartz 2D APIs in its back end, but QuickTime and OpenGL do most of their own drawing.

All of the bitmapped data produced by Quartz 2D, QuickDraw, QuickTime, and OpenGL is passed to the Quartz Compositor for eventual display on the screen.

The Quartz Compositor (formerly "Core Graphics Services") is implemented as a single "window server" process that is responsible for managing all on-screen windows. Each window has an associated bitmap (created by the application that owns the window using one of the drawing APIs). The window server produces the final screen image by compositing all of the visible window bitmaps with each other according to their position and layering. From the System Overview:

[The window server] composites and recomposites each pixel of an application's window as the window is drawn, redrawn, covered, and uncovered. Each window is represented as a bitmap that includes both translucency (alpha channel) and anti-aliasing information. The bitmap serves as a buffer, allowing the window server to "remember" an application's window contents and to recomposite it without the application's involvement.

The window server also routes events (e.g. cursor movement, mouse clicks, typing) to the appropriate applications, and manages the cursor.

So, in a nutshell: applications issue drawing commands using one of the various drawing APIs; the drawing APIs produce a bitmaps based on these (possibly vector-based) drawing commands; the window server retains the resulting bitmaps and composites them into a pleasing, cohesive final image on the screen.

Performance Problems

There are at least two performance problems with this architecture. As we've seen in earlier articles, the amount of memory used by the window server for retaining window bitmaps quickly becomes substantial. Worse, it scales linearly with the number and size of windows on the screen.

In more traditional architectures, bitmaps are not retained for every window on the screen. Instead, applications are asked to redraw any newly revealed portion of their windows. Each application draws into a single shared "frame buffer" that is the same size as the screen itself (e.g. 1024x768 pixels). This frame buffer is usually stored in dedicated video memory on the video card, rather than in main memory. To enable smoother drawing, it is possible to use two frame buffers: one on-screen and one off-screen. Applications draw into the off-screen frame buffer, and the video card swaps the two when the drawing is done. In this way, no one ever sees drawing "as it happens."

It's easy to calculate the video memory needed for display of a given size using this more traditional architecture: two frame buffers the same size and depth as the screen itself (e.g. 2 frame buffers x 1024 pixels x 768 pixels x 32 bits per pixel = 50,331,648 bits = 6,291,456 bytes = 6MB).

In the Mac OS X architecture, however, the screen resolution is almost irrelevant as far as memory usage is concerned. The memory usage for a pair of frame buffers is dwarfed by the potentially boundless number of windows that may be on the screen at any given time, each of which has its own buffered bitmap equal to the size of the window.

Mac OS X stores its window buffers in main memory rather than trying to fit them all in video memory. Although neither memory pool is limitless, main memory is still usually larger than video memory, and main memory is managed by the OS's virtual memory system which falls back to using hard disk space when things get tight. Things fall off a performance cliff pretty quickly when that happens.

The second performance problem has to do with all the compositing that the window server does. Rather than simply take the pixels from each window's bitmap and display them as-is on the screen, the window server must blend each pixel with the pixels from all of the other windows that have a pixel at that position, taking into account each pixel's transparency value.

When windows are entirely opaque, the calculations required are significantly abbreviated. But every window in Mac OS X has a partially transparent drop shadow and title bar (if it is not the front-most window). Menus are also partially transparent, as are the Dock, the overlays that appear when you hit the sound volume or media eject keys on the keyboard, and so on. The point is that transparency is unavoidable in Mac OS X, and the compositing calculations become more significant as more transparent objects appear on the screen.

Enter Quartz Extreme

So, where does Quartz Extreme fit in? As stated earlier, QE is a reimplementation of the Quartz Compositor using OpenGL--a description that should make a bit more sense to you now. Let me restate my "in a nutshell" summary of the Mac OS X on-screen graphics system, this time accounting for Quartz Extreme. Stay with me here, because this gets a little strange.

Applications issue drawing commands using one of the various drawing APIs; the drawing APIs produce a bitmaps based on these (possibly vector-based) drawing commands; the window server, now an OpenGL application itself, retains the resulting bitmaps as textures on polygons in an OpenGL scene and composites them into a pleasing, cohesive final image on the screen by issuing OpenGL drawing commands.

It's slightly confusing to think about the window server as an OpenGL application, but that's what it is. It just happens to be the only OpenGL application that does not send its output to the window server for compositing...because it, er, is the window server.

Let's see what this buys us in terms of performance. Here's a comparison of the Mac OS X display architecture with and without Quartz Extreme:

Notice the sudden proliferation of the red "hardware" lines in QE-enabled diagram. What it's trying to show is that the calculations required to composite each application's windows onto the screen are now handled by the GPU on the graphics card rather than by main CPU. Each window is treated as an OpenGL surface, and the bitmap that makes up the window's contents is the "texture" mapped on that surface.

The end result is that the CPU cycles previously spent compositing windows are now free for other purposes, and the previously (mostly) idle GPU is put to work doing what it does best.

Now let's look at what QE does not do. First, it does not affect Quartz 2D or any of the other drawing APIs at all. They all continue to function just as they always have, with the same amount of participation from the CPU.

Second, QE doesn't lessen the memory requirements of Mac OS X's display architecture. The window server must still retain bitmapped buffers for each window on the screen, and those buffers are still stored in main memory for the reasons stated earlier.

For maximum performance, the textures (window buffers) being composited should be in video memory. But they must also remain in main memory, because they can be evicted from the limited pool of video memory at any time.

Without QE, data flows from the window buffers in main memory to the CPU for compositing. With QE, data flows from main memory to the video card instead. This removes the burden on the bus between main memory and the CPU. But if all of the window buffers in main memory cannot fit into video memory, there will be heavy demands placed on the bus between main memory and the video card.

So it's no surprise that two of the requirements for Quartz Extreme support are at least 16MB of VRAM (32MB recommended) and an AGP2x bus (4x or better recommended). Furthermore, since windows come in many different shapes and sizes, video cards that do not support arbitrary texture sizes (e.g. ATI Rage 128) cannot use Quartz Extreme. The video card must also have support for all the pixel formats used by Quartz, and support multitexturing.

The G3/400 with its Rage 128 card on a PCI bus fails to meet these requirements and therefore cannot use Quartz Extreme. The 64MB GeForce 4 MX card in an AGP 4x slot on the G4/800 is ready to go, however. We'll see what kind of difference it makes in the next section.

Performance

Jaguar is marketed as a "features" release mostly because there are so many new features. New features are also easier to sell than incremental performance increases. Mac OS X performance was examined extensively in the 10.1 review, and for the most part those observations continue to hold for 10.2. But while 10.2 does not provide as big a leap as 10.1 did, performance has improved in many areas.

Boot time is substantially faster in Jaguar, thanks largely to its ability to start services in parallel, provided there are no dependencies between them (e.g. network time synchronization can't start until the network is up.) This is especially helpful when one of the startup items takes a long time to complete (e.g. requesting an IP address from a busy DHCP server.) Rather than blocking the entire boot sequence while waiting for this long-running task to complete, Jaguar will continue to launch other independent services.

On the G3/400, the boot sequence was dominated by POST and the new "gray apple" startup screen. Once the startup progress bar appeared, it zipped to the end very quickly, shaving a full 20 seconds off the 10.1 boot time. The G4/800 got a bit faster as well, but it has a static IP address and was already very fast (no waiting for an address from a DHCP server.)

On the memory usage front, Jaguar now enables the previously dormant window buffer compression feature of the window server. In Jaguar, "inactive" window buffers are compressed in order to save memory. Since many windows contain large areas of "empty space" (i.e. long lines of the same color) they tend to compress very nicely even using a simple algorithm like RLE (run length encoding, e.g. "white pixel x 200" rather than "white pixel, white pixel, white pixel, ...") Window compression is independent of Quartz Extreme, so everyone who can run OS X will benefit from it.

Application launch speed has improved in Jaguar, but the improvement is not comparable to the huge leap that 10.1 made over 10.0. I actually repeated the entire test suite from the 10.1 review, but the results were somewhat inconclusive because almost all the applications tested have been revamped since 10.1. In general, the launch times were a 1-3 seconds faster on Jaguar. Several bundled applications also stopped bouncing sooner than they did in 10.1.

The speed-up is likely due to changes in Jaguar's Mach kernel. Here's the explanation from Apple's technote 2053:

In order to reduce application launch times, the kernel now maintains
information about the working set of an application between launches
(in "/var/vm/app_profile").

These so-called "pre-heat files" are a variation on a well-known optimization for decreasing application launch time, but it's somewhat disappointing the the benefit is not more substantial. Nevertheless, it's good to see that Apple is working hard to improve this part of the user experience. (Yes, I'd definitely call modifying the kernel to improve application launch times "working hard" :-)

The dreading "spinning rainbow disc" has an all new look in Jaguar, but it appears just about as often as it did in 10.1. Since the rainbow disc is merely an indication of when an application has not responded to events for a few seconds, it's really an application problem. But if the application is blocking on a system call that's taking much too long, it may also be an OS problem. Either way, it's annoying.

Jaguar minimizes the annoyance by changing the cursor back to normal when it is not over a window owned by the unresponsive application. This makes it clear to the user that other applications are still okay and will respond correctly if clicked on. While this was also true in earlier versions of OS X, the cursor did not change, causing many users to assume they had to wait.

Although scrolling is still often much slower than it should be, the performance has improved significantly in Jaguar. Previous versions of Mac OS X would redraw the entire contents of the window during scrolling. Jaguar simply shifts the existing content upward or downward as necessary (something that can be done in hardware on the video card, even without Quartz Extreme), and then redraws only the newly revealed portion of the window. (This effect is easy to see using the Quartz Debug application included on the developer tools disk. Just turn on the "flash screen updates" option and scroll a few windows.)

Window resizing remains very slow, especially in "brushed metal" applications like iTunes and iPhoto. Window resizing sometimes actually seems worse overall in Jaguar--an impression created by the proliferation of the brushed metal interface. Whatever is making window resizing so slow needs to be found and fixed. Quartz Extreme doesn't help in any measurably way, so obviously window composition overhead is not the culprit.

To explore the actual performance benefits of Quartz Extreme on the G4/800, I returned to the old standby: the transparent terminal window. First, I downloaded the largest version of the Star Wars Clone War trailer.

To set a baseline, I played the movie as-is. As expected, the G4/800 had no problem playing it at its full framerate of 24 fps. The torture began with the placement of a single transparent terminal window (80x24, 0.25 transparent, where 1 is totally opaque) on top of the movie. I noted the maximum and minimum sustained (for more then 1 second) framerate during playback. Then I repeated the test after positiong two transparent terminal windows on top of the movie, then three, then four, and so on. The results are shown in the table below:

Framerate (Min/Max)
# Win Mac OS X 10.1 10.2 w/ QE
0 24fps 24fps
1 8.6fps - 11fps 24fps
2 5fps - 10fps 24fps
3 1fps - 6fps 24fps
4 .5fps - 5fps* 24fps
5 0fps - 3fps* 24fps
* Sound drop-outs during playback

I actually ran tests with many more than 5 windows on top of the movie. In Mac OS X 10.1, the movie playback was pretty much shot after 5 windows were added. The movie actually stopped entirely (0fps) for a second or more several times, and the sound (which began dropping out with 4 windows) was completely broken up.

In Jaguar with Quartz Extreme enabled, the GPU really flexes its muscles. I actually kept adding transparent windows until I hit 25 and got bored. The framerate never dropped at all. Impressive!

It was time to pull out all the stops and unleash the dreaded shaking transparent terminal window. The test is the same as described above, except that the top-most terminal window is shaken as fast as humanly possible over the top of the rest of the pile. This is the test that caused iTunes to skip in Mac OS X 10.0 and could bring movie playback to its knees in 10.1. Here are the results for 10.2 with Quartz Extreme, listing the minimum sustained (for more than 1 second) framerate. (Results from 10.1 are shown just for completeness :-)

Minimum Framerate
# Win Mac OS X 10.1 10.2 w/ QE
1 0fps 24fps
1 0fps 24fps
2 0fps 24fps
3 0fps 24fps
4 0fps 21fps
5 0fps 17fps

Things are grim in Mac OS X 10.1. I was able to stop the movie dead by shaking just one transparent terminal window vigorously. Not surprisingly, things didn't get any better as the number of (stationary) transparent terminal windows below it increased.

Jaguar with QE was a champ right up until the 4 window mark. After that, it began to degrade fairly linearly. Although this performance is worlds better than 10.1 without QE, I wanted to know exactly what it was about shaking the top window that cause the performance loss. After all, the amount of compositing calculations seemed equal, and could potentially be even less, since the top window occasionally moved away from the playing movie completely during shaking.

My next thought was that it might be a bandwidth problem. Perhaps shaking the window somehow caused the AGP bus to be swamped? But that didn't make much sense, especially with 64MB of VRAM and a set of windows that weren't changing at all (except for the movie). The unchanging window buffers for all the terminal windows could fit comfortably in the card's video memory.

So I tried to look at it more logically. QuickTime needs CPU cycles to decode the audio and video in the movie. A reduction in framerate means that QuickTime is not getting enough CPU cycles. Therefore shaking the transparent terminal window must be taking up CPU cycles. Running top verified it: the window server was taking roughly 70% of the G4/800's CPU cycles when I was shaking the window on top of four other windows. It took progressively less CPU time as the number of stationary transparent terminal windows decreased.

That explains why the movie's framerate started to drop, but what explains the window server's increased need for CPU cycles? The test with the stationary windows showed how well compositing calculations are handled by the GPU. With 25 stationary windows, there was no drop in framerate. Why does a shaking window require so much more CPU involvement? And, even more puzzling, why does the amount of CPU involvement increase in proportion to the number of stationary windows sitting below the shaking window?

Unfortunately, I didn't have time to explore the boundaries of Quartz Extreme much further, as there are many other interesting parts of Jaguar that required my attention. Furthermore, the example above is not likely to come up in daily use. Stationary windows are much more common than shaking ones, and QE handles them without breaking a sweat. Still, it would be nice if window movement was just as smooth.

While QE doesn't help window resizing and isn't responsible for the scrolling speed increase, you can most certainly make a Mac OS X system "feel" faster by playing to QE's big strength: compositing.

Fun with compositing

Here are a few fun things you can do leverage the power of Quartz Extreme.

Most of these little diversions are fun because they're so smooth in action. While most of them work without QE, the CPU overhead can be prohibitive. There's nothing cool about low framerates and a CPU bound system. With Quartz Extreme, while there is some CPU overhead for the more complex items (e.g. the fish screensaver), the heavy lifting is done by the GPU. It was actually possible to work comfortably all day on the G4/800 with nicely rendered fish swimming around on the desktop.


Mmmmm...useless...

Okay, enough fun and games. Back to the grindstone...

User Interface

There have been no shocking changes to Mac OS X's user interface in Jaguar, but there have been many minor tweaks. The Dock is nearly the same as it was in 10.1, minus the pinstriped background. It's now a simple, uniformly transparent rectangle.

The aqua widgets for buttons, pop-up menus, sliders, and a handful of other controls have been subtly revised. The image below shows the new look. By dragging you mouse over the image, it should change to show the old look. If this doesn't work for you, try manually viewing individual images: old and new.)

Jaguar widgets (mouse-over to toggle)

The new aqua widgets make the old ones look slightly blurry to my eyes, although I do miss the more three dimensional look of the old buttons. The new buttons look a lot flatter. Widget drop shadows have also been minimized in the new look, and most of the controls seem to look shinier and have better contrast. Overall, I think it's a change for the better.

Speaking of changes for the better, a handful of transparent interface elements are now ever-so-slightly more opaque in Jaguar. The image below shows a drop-down menu in Jaguar. As in the previous example, dragging your mouse over the image should make it switch to the Mac OS X 10.1 version of the menu. (Separate images also available: old and new)

Jaguar menu (mouse-over to toggle)

Both menus are shown on a black desktop. The difference is small, but noticeable. Thanks to its higher opacity, the Jaguar menu is whiter and offers better contrast. Sheet-style dialogs also appear to be slightly more opaque in Jaguar, but inactive window titlebars remain unchanged.

In other look-and-feel news, the "brushed metal" look has become an officially supported appearance style in Jaguar. It is now built into the OS and can be used by third party dervelopers with the click of a checkbox.

The new "textured" window appearance is just a click away

The official name for the look is the "textured" window appearance, perhaps implying that the exact texture applied could change in the future. (How about a "woven straw" look?) In fact, Apple has subtly changed the brushed metal look serveral times already, from its start in the ill-conceived QuickTime 4 player all the way through to the metal-themed iApplications of today.

But what kinds of applications should use the new "textured" appearance? The Aqua Human Interface Guidelines have this to say on the subject:

[The textured] window style has been designed specifically for use by--and is therefore best suited to--applications that provide an interface for a digital peripheral, such as a camera, or an interface for managing data shared with digital peripherals, such as the Address Book application.

This appearance may also be appropriate for applications that strive to re-create a familiar physical device--the Calculator application, for example. Avoid using the textured window appearance in applications or utilities that are unrelated to digital peripherals or to the data associated with these devices.

I don't know about you, but I find the description of the applicability of the "textured" appearance to be so vague that almost any application could qualify. And as we'll soon see, Apple itself apparently has no problem stretching the rules as well.

The official adoption of this new alternate window appearance is a bit puzzling. At first I thought the brushed metal look was a bid by Apple to invert the traditional relationship between the OS and the application. Maybe that is still part of the plan, but I think the vague restrictions on when and where to use the metal appearance will come back to bite Apple down the road. The proliferation of the metal look dilutes its value as a differentiation tool. In fact, there's already a utility that will turn any application into a metal monster. It will be interesting to see how this shakes out.

Moving on, the open and save dialog boxes in Jaguar no longer suffer from the most glaring cosmetic bugs found in earlier versions of OS X, but I still find the column view layout infuriatingly difficult to navigate quickly (or sometimes at all) from the keyboard. It is not always obvious "where I am" in the column view control, making it difficult to determine what will happen when I press a key. I also find the horizontal scrolling of the column view to be less efficient than the pop-up menu used to display and navigate the file system hierarchy in classic Mac OS open and save dialog boxes. There remains a lot of room for improvement in this interface element.

I'm happy to say that the very small (but very annoying bug) that caused the insertion point to disappear when it was moved with the arrow keys has been fixed in Jaguar. This bug fix affects all standard text fields everywhere in the OS. Yay.

File system metadata, file typing, and application binding remain in more or less the same dismal state. There are some minor changes such as the addition of the "Open with..." menu item, but the fundamentals remain the same. Renaming files remains a "dangerous" operation. File name extensions are still required on all files created on Mac OS X. "Smart" file name extension hiding is still as inscrutable as ever, and is still enabled by default. And so on and so forth. You know where to find out more, and you know what you can do about it.

The Finder

The Finder has learned a few new tricks in Jaguar, but it has not fundamentally changed.

The heavily requested spring-loaded folders feature from classic Mac OS has returned, albeit in slightly handicapped form. For the most part, it works just like it did in classic Mac OS: drag an item over a folder and it "springs" open, at which point you can drag the same item on top of another folder, and so on, until you reach your destination and drop the item. When you do, the windows "spring shut" behind you. But spring loaded folders do not work on the Dock, and do not work with the double-click-and-hold method.

Most window opening and closing operations in the Finder now use the "scale" effect (as seen in the Dock) in place of traditional "zoomrects" (rectangular outlines that grow from the window's source to its eventual location on the screen.) This effect is surprisingly fast, even on the G3/400. Like the genie effect before it, it gives a clear indication of where each new window came from. Unfortunately, the effect is not as consistent as zoomrects were in classic Mac OS. In Jaguar, sometimes opening or closing a window triggers the effect, and sometimes it doesn't.

The Finder's "Find" command no longer launches the (slow, bloated) Sherlock search tool. Instead, it now brings up a blessedly simplified (and therefore quick to appear) dialog that is actually focused on finding files.

Find returns to the Finder

The Jaguar Finder now supports multiple "Get Info" windows. The old singleton "inspector" palette is available by holding down the option key when selecting the menu item or entering the keyboard shortcut (cmd-opt-i). Both windows now include an expandable set of attribute inspectors at the bottom. There are so many of them that a fully expanded window doesn't fit on many screens.

The most useful new feature (aside from the ability to open more than one window, of course) is the addition of administrative authentication (the lock icon in the image below) that enables an authorized user to change file ownership without resorting to the command line.

chown without sudo

Unfortunately, neither the inspector palette nor the individual info windows remember the state of the expandable portion of the window. All of the expandable sections start out collapsed each time, forcing you to manually re-open the ones you're interested in.

SMB servers are finally given peer status with AppleShare servers. The "Connect to Server" dialog now shows Windows file servers and domains right alongside the AppleShare servers, and SMB usernames and passwords are now properly stored in the keychain.

Now that SMB has graduated, the FTP protocol is the new second-class network citizen in the Jaguar Finder. FTP servers can be mounted in the Finder, but like SMB before it, FTP usernames and passwords are not stored in the keychain. FTP upload is also badly broken.

The Jaguar Finder still has a tendency to block during long-running network operations, often hanging completely. Network resources mounted via the command line do not initially show up as volumes on the desktop, but do show up if the Finder is restarted (perhaps after a network-related hang)...at which point attempting to unmount them from the Finder will often cause another hang.

The Finder's contextual menus have been expanded a bit. There's now a handy "Open with..." item that allows the selected document(s) to be opened with an application other than the default. The desktop background can now be changed from the desktop's context menu. There are now also context menu items for the dubious file/folder copy and paste features.

Icons dragged "in formation" from one icon-view window to another (or to the desktop) now properly retain their relative positioning. The snap-to-grid feature now includes a nice animation to show the icon(s) sliding into place. It is still difficult to grid-snap-toggle-drag (that is, toggling the grid snap by holding down the command key when dragging) many icons repeatedly because the command key is also the key for multiple selections in the Finder. Perhaps the grid-snap toggle should use a different modifier key.

Finder windows now behave in a much more aesthetically pleasing manner when the zoom widget is used in "shrink-to-fit" mode, leaving a comfortable and uniform amount of space around all window contents.

The Finder finally gets adjustable font sizes in Jaguar, and on a per-window basis no less. But the choices only span from 10pt to 16pt, and changing the font size actually changes the grid spacing of the window--and then actually moves your icons to align with the new grid, regardless of the grid-snap settings for that window.

Sigh...

Jaguar is much better about retaining window sizes and positions, however, and icons are less likely to randomly scramble themselves. But the browser-style user interface continues to dominate the Jaguar Finder, much to the disappointment of those of us who valued the spatially-oriented Finder from the first 16 years of the Macintosh. (You've no doubt heard all of this before...)

The Finder toolbar continues to make unscheduled appearances in windows where it has been repeatedly dismissed in the past. Although permanently hiding the toolbar would not restore the spatial Finder to its former glory (sorry, I can't help myself), it would still be nice if that particular widget, once hidden, wouldn't continually reappear, haunting me like the Ghost of Browser-Style Navigation Future.

Fans of the Finder toolbar will be happy to see the addition of a "forward" button to complement the preexisting "back" button, and a small text input filed that allows the current window to be transformed into a Sherlock-2-style search results window: found items listed in the top pane, selected item path shown in the bottom pane.

The new Finder toolbar search feature

Unfortunately, the results do not update in real-time as you type (see iTunes for an example) and the search field is not expandable, remaining about one inch wide regardless of how much room there is in the toolbar.

Jaguar's toolbar search feature strikes me as a half-hearted attempt to implement the "live search" feature planned for Apple's aborted Copland OS effort. The planned Copland feature entailed the creation of a special class of Finder window that would show a dynamically updated view of the file system, filtered according to user-selected criteria. Users could permanently save these windows as special folders. For example, a user could have a folder that always appeared to contain the twenty most recently created MP3 files, or all of the Word documents with the word "proposal" in them.

The Jaguar toolbar search feature fails to match the (admittedly, vaporware) Copland feature on several important fronts. Like many parts of the Mac OS X Finder, the toolbar search feature "hijacks" the window it is activated in, transforming it into yet another variety of browser. The result of a search is not a an entity that can be saved and reused, but rather a one-time-only modification of the current window's contents.

I'm trying not to re-grind too many old axes here, but I feel like the changes being made to the Mac OS X Finder betray a fundamental lack of vision--any vision. Tearing down the old Finder and starting over is all well and good, but the new Finder has yet to even get off the ground. It's taken two major revisions and more than a year to get simple icon dragging right, for crying out loud. Extrapolating based on this rate of progress, we should see some sort of poorly-implemented replacement for things like labels and pop-up folders some time in 2006. And forget about any truly forward-looking features akin to Copland's saved searches or BeOS's metadata-powered custom views. Put simply, the Finder, once the crown jewel of the Mac user interface, no longer seems to be a priority at Apple.

Bundled Applications

What does appear to be a priority at Apple is the further development of the increasingly comprehensive suite of applications that ship with Mac OS X. This includes the so-called "iApplications": iTunes, iMovie, iPhoto, and iDVD. The existing iApps have largely divorced their development process from the OS X release schedule. For example, the version of iTunes bundled with Jaguar was actually released several months earlier. Jaguar includes a few new applications that will presumably follow the same development trend, but Jaguar marks their big debut.

Address Book

The Address Book application was technically included with all previous releases of OS X, but it was a mere shadow of its Jaguar incarnation. The new version appears to be a complete re-write. The Address Book application itself is but one of many possible front-ends to a system-wide address database service. Any application can integrate with the system-wide address database through a set of public APIs provided by Apple.

Jaguar's new Address Book application

The Address Book application has a very simple interface and does not appear to be all that significant on its own. But integration is a big theme in Jaguar, and that's what makes the Address Book so promising, as we'll soon see.

Address Book is clearly a 1.0 application, however. It provides the bare minimum of features. For example, the Undo command does not function when editing an entry. There's not even a place to enter a person's middle name. And although it can import address data in a variety of formats, it doesn't do a very good job of merging imported entries with existing entries for the same person. I'm ready for 2.0 already.

iChat

iChat is Apple's new instant messaging client. It operates on the AOL instant messenger network thanks to a deal signed way back in 1999. This just goes to show that it's never to late for Apple rumor mongering to come true.

Like the Address Book, iChat is another brushed metal application. Unlike Address Book, it is not clear why it's brushed metal. As far as I can tell, it isn't an "interface for a digital peripheral", or an "interface for managing data shared with digital peripherals", nor does it "strive to re-create a familiar physical device." It's just...metal.

iChat's feature set does not cover all of the official AIM client's capabilities (there is no audio chat support, for example), but then again, there are also no annoying banner ads.

iChat is a good place to start the integration domino effect. Follow the bouncing ball...

The iChat buddy list is integrated with the address book database. Buddy icons can be pulled from the address book, written to the address book, or kept separate. Address cards (the file representation of address book entries) can be traded via iChat. Sending email to a buddy can be done with a simple click in iChat. The new Mail application (see below) also integrates with the address book and provides access to the selected buddy's address card. A small status icon next to email messages received from people in your buddy list indicates their AIM availability in real time. Clicking on the status icon (or the "Chat" toolbar widget) in Mail opens an iChat instant message window directed to that user. In addition to the standard AIM buddy list, iChat uses Rendezvous to show a list of all iChat users on the local network (with no configuration required and no central iChat directory server, of course). To transfer a file to any of these users, simply drag it from the Finder onto their buddy list icon.

The "network effect" is very much real in Jaguar, and the more applications take advantages of these new technologies, the richer the possible interactions become. The ability to use iChat as an ad-hoc auto-configured drag and drop file sharing network alone is worth the price of admission, and the integration and data sharing among iChat, the address book and Mail is so obvious and natural that it's difficult to go back to a world where each application manages its own set of contact information.

There are a few dark clouds looming, however. First, in order for to fully reap the benefits of integration, these shared services should be both open and replaceable. By "open" I mean that third party applications can take advantage of them. The address book database is a good example of an open service, but I'm not sure that the iChat instant messaging services will be equally open (probably due to AOL contract restrictions). By "replaceable" I mean that third party developers should be able to create drop-in replacements for services like the address database. This is a difficult thing to accomplish, and Apple probably does not see it as something that's in their best interest right now. But it certainly would benefit users, and the platform in general.

Anyway, back to iChat. The interface is simple and, well, cute. New IM windows pop onto the screen with a tiny zoom animation. Words appear in colored speech bubbles next to each user's buddy icon, and on opposite sides of the window. Even images are scaled and displayed inside the speech bubbles when they are passed from one user to another. Rows in the buddy list reshuffle themselves in a dance of translucent animation. Minimized IM windows show up in the Dock as buddy icons. A buddy who is in the process of typing a response has a cartoon thought bubble placed next to his icon in the chat window.

Samples from the iChat user interface

Although this all sounds like a borderline Hello Kitty experience, it's surprisingly usable and even enjoyable. Although many of the too-cute interface elements can be toned down or disabled, to my own surprise, I found myself reverting almost all of the interface options back to "cute" mode. I even left my buddy list in "large text" mode, since I rarely have enough online buddies to fill the window.

I found that the text bubbles actually do help quickly highlight the flow of conversation. You can even set your outgoing and incoming "bubble color", or you can make your outgoing color random and accept incoming colors as-is. Once I color-coded my text bubbles to match my buddy icon, there was no going back ;-)

Sadly, even more so than Address Book, iChat is a glaringly "1.0" application. Many basic IM features are missing. The buddy list does not support categories. The text input area in IM windows is tiny and is not resizable. Chat windows do not remember their positions or sizes. The iChat Dock menu is nearly useless. Despite having an icon that cries out for a "flashing bubble" animation, the only notification action available is the dreaded Dock bounce.

Stability has not been stellar either. Bugs, both minor and major, abound. I've experienced truncated text, long messages that were dropped entirely, a whole zoo of cryptic file transfer errors, an inability to see other AIM users (and even other iChat users), and enough buddy icon trouble to fill another entire article. If Address Book is ready for a 2.0 version, iChat sometimes feels like it could stand to start over with proper 1.0 version.

Despite all of this, iChat shows promise. I'm tempted to say "wake me up again when it hits version 3", but the sad fact is that AOL's strangle hold on its IM network makes iChat the least offensive "officially supported" AIM client. Despite all the bugs, I've had better luck transferring files with iChat than I have with my first IM love, the multi-protocol wonder Fire. Plus, iChat users that sign on using their mac.com email addresses are reportedly not visible when using "unofficial" IM clients like Fire. Bleh.

Mail

The version number of Jaguar's Mail application is only 1.2, but it certainly deserves to graduate to 2.0. The updates are so significant that the user is actually prompted to "learn what's new" the first time Mail is run, and there's a "What's new in Mail?" item in the Help menu. The highlights include support for SSL and Kerberos authentication, better mail importing capabilities, integration with the new Address Book and iChat, a redesigned mailbox organization system, more flexible mail sorting rules, the ability to search across multiple mailboxes, rudimentary thread highlighting, and a new "learning" junk mail filter.

I'll start with the junk mail filter because it's Mail's most interesting feature. Out of the box, the junk mail filter correctly identifies most spam, but it plays things safe, allowing some spam through rather than falsely identifying legitimate mail as spam. To improve the junk mail filter's accuracy, the user is encouraged to correct its mistakes by manually marking messages as junk or not junk. In response, the junk mail filter learns how to better identify spam, slowly increasing its accuracy over time based on the kind of spam that each user gets.

Spam spam spam spam spam spam spam

Ignoring the actual success rate of this system, the Tamagotchi-style interaction is strangely appealing. The feeling that you're "teaching the computer", and in the process making your email life a little easier, is a powerful reinforcement for each corrective behavior. "Bad junk mail filter!" "Good junk mail filter!" It's kind of fun.

Once you are satisfied with the filter's accuracy, you can set it to "automatic" mode and it will wisk your junk mail away into a dedicated junk mail folder. The three preset modes are "Training" (the default), "Automatic", and "Off." These choices correspond to a set of predefined rules that will be applied to junk mail. Mail continues to "learn" even in "Automatic" mode, and the user can customize the rules without any problems (in which case the junk mail mode is shown as "Custom")

Thanks to the appearance of my email address all over the web (and therefore its existence in web caches on Windows computers everywhere) I get a ridiculous amount of spam. Although Mail's junk mail filter correctly identified most of it, it continued to have trouble with a few varieties even after a week of "training." In particular, the various virus emails that consist of only a nonsensical subject line (e.g. "So cool a flash,enjoy it") and an equally nonsensical attachment tend to give the junk mail filter fits. My theory is that those messages do not give the filter much content to go on, so they're hard to use as examples. Equally worrying, perhaps as a result of my training, Mail has started identifying a handful of legitimate email messages as spam--sometimes even messages sent to mailing lists that I subscribe to.

I'm not willing to condemn the junk mail filter after only a week of training, especially since I think I receive a heck of a lot more spam than the average user, whose email address isn't plastered all over the net. But I'm still not entirely convinced that it's as good as it could be. On the other hand, other users report great success with the filter. Your mileage may vary.

The new mailbox organization scheme is certainly interesting, but also slightly confusing. The first thing most users will notice is that "special" mailboxes such as the inbox, sent mail, junk mail, drafts, and trash have been pulled out of the account(s) that they apply too and are grouped together by type at the top of the mailbox drawer.

These special mailbox groups may be treated as separate items, or lumped together as if the whole group is a single mailbox. For example, selecting the "parent" inbox icon will show messages from the inboxes from all accounts. Selecting an individual inbox shows just the messages from that account. Selecting more than one inbox shows the union of the two inboxes (see image). The other "special" mailboxes work in the same way.

As the number of accounts grows, the mailboxes rearrange themselves in an attempt to reduce clutter. If there is only one item in a group, that group tends to flatten itself out into a single item. Under certain circumstances, a somewhat confusingly named "On My Mac" group will appear. You might think that everything that is not in that group is not "on your Mac", but you'd be forgetting about the "special" mailboxes that are split out form their respective accounts. You'd also be forgiven for being slightly thrown by Mail's occasional use tiny folder icons for items that it refers to as "mailboxes."

If you're confused right now, you're not alone. It took me several days of use (and consultation with other Mail users and some of the Mail developers themselves) to feel like I completely understood what was going on in the mailbox drawer. Once you understand it, it is an interesting and useful system. But it's not very flexible and the initial confusion is a problem. The extremely responsive and enthusiastic Mail developers at Apple are sure to be working on revisions as you read this.

Although Mail is not yet in the same league as "high-end" email applications like Microsoft's Entourage, it is now good enough to safely recommend to the vast majority of users. Mail even surpasses the big boys in many areas. Mail's junk mail filter is certainly more ambitious than most, and Mail's performance in a few key areas in unmatched among Mac OS X email clients. Marking large groups of messages as read is nearly instantaneous in Mail, for example, but brings up a progress bar in Entourage. Mail also is currently the only OS X email client that integrates with the new Address Book and iChat.

Although I personally rely on too many of Entourage's advanced features (particularly the "custom views" that let me see arbitrarily defined "slices" of all my email) to switch to Mail full time, I have to admit to being somewhat jealous of the address book and iChat integration. On the other hand, Microsoft's developers are not just waiting around for the Mail team to eat their lunch. This is shaping up to be an interesting competition.

Sherlock

Since the Finder has taken over the job of finding files (imagine that), Sherlock is free to pursue its dream of being a "web services" front end. Sherlock 3 now provides a friendly GUI for web-based services, such as movie listing, stock prices, language translation, and so on. Here's a screenshot.

Wait, no, I'm sorry. That's actually a screenshot of Karelia software's web services application, Watson, recent winner of Apple's "Most Innovative Mac OS X Product" design award. Here's a screenshot of Sherlock:

As the Watson FAQ explains, although Apple's new version of Sherlock is a dead-ringer for Watson, there is no formal relationship between the two applications. If you'll allow me to digress...

There are a couple of ways to look at this situation. On one hand, it's a shame to see Apple bundle a free product that so closely resembles a popular and innovative (by Apple's own admission) third party product. Apple's development of Sherlock is subsidized by its hardware sales and other parts of its business; it can afford to give Sherlock away for free with Mac OS X. But Karelia is a software vendor that needs to make money from its products. From Karelia's perspective, Apple just ate its lunch. It's eerily reminiscent of Microsoft's tactics from years past.

On the other hand, Apple hasn't made any attempts to prevent users from installing Watson, deleting Sherlock, or both. But the playing field is still far from level. It's not easy to compete with a free, pre-installed product that is even remotely comparable to your own (non-free) product. Karelia might be better off seeking its fortunes elsewhere. Not surprisingly, a Windows port of Watson is "a strong possibility" according to the Watson FAQ.

I think this whole situation could have been handled better by Apple. I don't fault Apple for making a web services application. It can be argued that Watson itself built on the ideas in Sherlock 2. And it's not as if either of these products were the first to put a friendly GUI on web services. The striking similarity between parts of the Watson and Sherlock 3 interfaces is probably the most damning indictment of Apple, but that type of thing is notoriously difficult to pin down (as Apple knows all too well).

Nevertheless, Apple could have been more understanding. Karelia probably would have been receptive to any reasonable offer of compensation--or even just credit where credit is due--from Apple. Instead, Apple offered Watson's creator, Dan Wood, a job at Apple. While that may seem generous to readers who assume that every Mac programmer dreams of working for Apple, making it on your own is an equally valid dream. Dan Wood had this to say on the subject:

"Yes, I personally was offered a position at Apple, though that offer was made almost immediately after Watson was released. The offer was made again, ostensibly as some compensation for crushing Watson, but I declined for a number of reasons--though it would have kept me employed, it did nothing for the people working on my team. It also did not compensate for the intellectual property. Giving somebody a job is paying them for work yet to be performed. So it really wasn't any compensation at all."

I don't think Apple's actions can be considered "developer friendly" by any reasonable measure. If Karelia software is driven away from the Mac platform by Apple's actions, it will be a loss for Mac users as well as Apple itself. Here's more from Wood:

"Apple is promoting an 'unhealthy ecosystem' by attempting to bundle the most useful applications with the OS. Rather than concentrating on taking market share away from Microsoft, they are taking market share away from their own developers. Though it may seem to have short-term benefits, I believe it will hurt them in the long run, because developers will be discouraged from writing for the Mac. [...] Apple should be truly supporting its developers, helping bring the small developers out of the woodworks, and fostering their growth."

In contrast to Wood, I actually applaud Apple's efforts to create a comprehensive suite of bundled applications for Mac OS X. Some amount of resulting conflict is simply inevitable, and may even be healthy. But Apple needs to find a better balance. Apple is not Microsoft, and it simply cannot afford to create an environment where developers are afraid to go near any application domain that Apple has expressed an interest in. Where there is overlap between Apple's products and those of third parties, Apple must do everything it can to ensure that the rising tide of the Mac OS X platform raises all boats.

Imagine, for a moment, if Apple had simply licensed Watson from Karelia rather than expending their own development resources duplicating its functionality. Had this route been taken, Karelia would have remained independent (and successful), Apple would have saved time and development resources, and Mac users would have gotten a superior product.

Yes, Watson is indeed a better product than Sherlock 3 in its current incarnation. Watson offers a wider range of services, better performance, and an extensible plug-in architecture that encourages the independent development of new web service modules, all of which can be made seamlessly available to all Watson users. Clearly, Karelia understands how to stimulate development for its tiny platform. Apple could learn something from them.

I'm not going to expand further on Sherlock 3's features. Thanks to the straightforward UI so reminiscent of Watson's, it's pretty much self explanatory. If you're curious about web services, give it a try. If you're serious about web services, take a look at Watson. And if you don't like how Apple has handled this situation, let them know how you feel.

Terminal

If you'll allow me one more slightly self-indulgent digression, I'd like to talk about an application that I have something of a personal vendetta against...or perhaps it has one again me. While I will try to extract some larger truths about Mac OS X from this topic, make no mistake about it: this is a grudge match, me versus the Mac OS X Terminal application.

(Note for the humor-impaired: no hate mail, please.)

First, some background. I use the Terminal application every single day. I can safely say that it is one of my most commonly used Apple-supplied applications. I don't ask for much from Terminal. I just happen to have a few personal preferences that I'm very attached to. For the most part, I was happy with the version of Terminal that shipped with Mac OS X 10.0.

My troubles with Terminal began in Mac OS X 10.1. It shipped with a new Terminal application that took much longer to launch, and could not understand my existing terminal session files. Worse, when I converted the session files, the 10.1 Terminal insisted on starting a local shell before running the command saved in the session (e.g. an ssh connection to another host). The 10.1 Terminal bothered me enough that I pulled a copy of the old Terminal application off the Mac OS X 10.0 installation CD and proceeded to use that instead.

I had high hopes for the 10.2 Terminal. I had filed many bugs against the 10.1 Terminal, and almost all of them were fixed in Jaguar. The Jaguar Terminal also launched much faster, and had many new capabilities: Unicode support, a GUI preference for transparency, an expanded set of window title options, and even a handy splitter control for each window.

But there was trouble in paradise. My font of choice for Terminal windows is 9pt Monaco. This has been my preferred monospaced font for more than a decade, and old habits die hard. So deep is my devotion to Monaco 9 (as I like to call it) that I was actually upset when Apple tweaked the font several years ago, making the lowercase "L" look less like the capital "i", and adding other beneficial changes. Snicker if you will, but do not come between a man and his font!

The Jaguar Terminal, cruel temptress that it is, with its whizzy new splitter pane and numerous bug fix appeasements, has laid a devious trap for my beloved Monaco 9. Behold a comparison of the One True Font in the 10.0 and the 10.2 Terminal:

Monaco 9 the 10.0 Terminal Monaco 9 the 10.2 Terminal
If you don't see any differences, you should probably just skip to the next section :-)

Frantically, I attempted to adjust the Jaguar Terminal's new line height and line spacing controls. Eventually, I thought I'd done it; I thought I'd restored my font to its former non-scrunched glory. But then I accidentally leaned on the "=" key, producing a line of characters that looked like this:

Your eyes do not deceive you! There are indeed extra spaces inserted into what is supposed to be a monospaced font! A choice between characters that touch each other and characters with extra space between them is no choice at all.

I eventually found refuge in the very Monaco-like VT100 font. But the VT100 single quote character is slanted instead of straight up and down, and the pipe character is split in the middle. It's just not the same.

Although the Jaguar Terminal's splitter feature is useful enough to keep me from reverting once again to the 10.0 Terminal, this is still an upsetting situation. All I want is a window containing monospaced, non-antialiased 9pt Monaco text. Is that too much to ask? Is it beyond the technical capabilitiess of the Mac OS X text system?

(Now I will make my run at some sort of larger relevance for this, shall we say, "personal" issue...)

Something lurking in Mac OS X's text system simply does a terrible job of displaying small, non-antialiased text. The spacing is awful. Characters touch each other and sometimes even overlap! This has been a problem since 10.0, and I've mentioned it in earlier articles. But since it only happens at small sizes and with antialiasing turned off, I've been able to avoid it in most situations.

Now that it has invaded the Terminal, however, the gloves have to come off. I'll be damned if I'm going to use antialiased text or anything larger than a 9pt font on a Unix command line. Call me crazy if you want, but until presbyopia starts to set in, that's the way it is. I don't think this is too much to ask.

I'm still not even sure why Mac OS X can't display small, non-antialiased text properly. Some OS X applications (e.g. Entourage, the 10.0 and 10.1 Terminal, and even Jaguar Mail) are able to do it correctly. I can't imagine two applications that are farther apart than a huge Carbonized Mac OS classic application like Entourage and a Cocoa reincarnation of an old NeXT application like the 10.0 Terminal. How can both of these applications get it right while so many others get it wrong? Is there a special MAKE_SPACING_NOT_LOOK_LIKE_ASS flag that they're using?

But I'm not ready to lay the blame on the Jaguar Terminal developers. The widespread occurrence of this problem tells me that it is an OS issue at its core. And besides, the Terminal developers not only fixed the bugs I filed, they often did so in the exact way that I wanted (e.g. providing a checkbox to specify whether or not a saved Terminal session will open a new local shell). So I'll dutifully file bugs against the 10.2 Terminal, but this particular issue may be out of their hands.

In the meantime, I guess I'll have to continue slumming with VT100. Bleh.

[Update: this bug has been confirmed by Apple, and it is indeed a bug in Apple Type Services, not in the Terminal application itself.]

The Big Picture

Jaguar is a sprawling OS release, at least by Mac OS X standards. In this article I've covered the features and topics that I find most interesting, but there's just as much that I've missed. Mac OS X has reached the point where truly comprehensive coverage would require a sizable book.

But I will stop short of saying that Mac OS X has "matured." There remain too many "unfinished" corners of the OS. All the little details that used to separate Mac OS from more user-hostile OSes have not yet been added to Mac OS X. Even tiny things like the aesthetically unpleasing default placement of progress dialog boxes in the Finder (wedged into the upper-left corner of the screen, with no surrounding space) contribute to the feeling that there is still much work to be done to match the fit and finish of classic Mac OS.

User interface responsiveness continues to be an issue in Jaguar, despite significant strides in this area (e.g. QE). Booting back into Mac OS 9 gives an immediate impression of almost unbelievable speed, particularly when scolling or resizing windows. Unfortunately for Apple, despite the vast technical superiority of Mac OS X over Mac OS 9, perception is often nine-tenths of reality.

Although I tried not to rehash too many of my old issues with Mac OS X usability, not much has changed on that front either. The file system metadata issue in particular needs some serious attention if Apple wants to regain a leadership position in this area. I can only hope that a team of very smart people working in the bowels of Apple's secret software development labs are busy constructing a suitably modern metadata infrastructure for Mac OS X.

The Mac OS X Finder is improving, but progress is slow, and without any clear direction. As with the metadata issue, I can't help but wonder if a radically new Finder isn't in development at Apple. Surely the Jaguar Finder does not represent nearly a year's worth of developer effort on such an important part of the OS.

I'm not particularly optimistic about the Finder's future right now. It seems clear to me that no one with any authority at Apple understands what made the classic Mac OS Finder so good. Microsoft didn't understand it when it created the Windows file management interface, and it shows. So too does the Mac OS X Finder fail to live up to its namesake. The Jaguar Finder has improved enough since 10.1 to keep its head above water, but that's about it.

Many of the other usability problems can be papered over with the judicious use of third party software. Apple could stand to be more appreciative of the service its enthusiastic third party developers provide, rather than attempting to thwart their efforts when they conflict with Apple's vision of what customers "should" want.

On the bright side, although you can argue over the degree, there's no denying the fact that Jaguar is better than Mac OS X 10.1 in every important way. It's faster overall, it has more features, and it's generally more pleasant to use. If Apple wasn't so wary (rightfully so, in my opinion) of the branding consequences of reaching version 11.0, Jaguar would likely be Mac OS X version 10.5.

It's tempting to say that 10.2 is what 10.0 should have been. I certainly wouldn't want to show a potential "switcher" a version of Mac OS X other than Jaguar. But in the grand scheme of things, it was much more important for Apple to get the ball rolling with 10.0 than it was to wait until they'd gotten their feet under them to the degree demonstrated in Jaguar.

Mac OS X 10.2 has a suggested retail price of $129, and there is no upgrade discount for users who purchased version 10.1 in anything but the very recent past. Nevertheless, I think Jaguar is a must-have upgrade for anyone who uses Mac OS X on a daily basis. If you can stick it out with 10.1 until the next major revision, then you're a more tolerant person than I am.

Whether or not I'm ready to believe in Mac OS X, it's clear that Apple does. As classic Mac OS recedes into history, the reputation of the new Apple rests largely on the shiny, translucent shoulders of Mac OS X. Although Steve Jobs declared version 10.1 to be the "mainstream release" of Mac OS X, Jaguar, with its unique branding and pumped-up feature set, represents OS X's first real step into the mass market. I just hope it's got what it takes to make it. After all, it's a jungle out there.

Photo of John Siracusa

John Siracusa has a B.S. in Computer Engineering from Boston University. He has been a Mac user since 1984, a Unix geek since 1993, and is a professional web developer and freelance technology writer.

12 Comments