What is Mac OS X 10.0?

Mac OS X is Apple's new operating system. I've said it before and I'll say it again: the "X" is pronounced "ten", like the roman number, not "ex" like the letter. Don't make me come over there.

Mac OS X was released on March 24th, 2001, with a suggested retail price of $129 and a version number of 10.0. Don't let the version number confuse you; this is the first official release of Apple's new OS. It was preceded by many developer releases and one public beta release.

To say that Mac OS X has been eagerly awaited by Mac users is an understatement. Apple has been trying to produce a successor to the classic Mac OS operating system for almost 15 years. It's a tragicomic litany of code names: Pink, Taligent, Copland, Rhapsody. In the early days (the Pink project was launched in 1987), Mac users paid little attention to these efforts, confident that their current OS was the most advanced in the personal computer market. But as the years passed and competing operating systems evolved, both by adopting Mac-like GUIs and by advancing their core OS features, Mac users--as well as Apple itself--became skittish.

By 1995, Windows had confined Apple's OS to a small corner of the market. Perhaps Windows 95 wasn't "insanely great", but the market had declared that it was "good enough." Meanwhile, Microsoft quietly continued its own long-running project to radically revise its core operating system technologies: Windows NT (which eventually gave birth to Windows 2000, and soon, Windows XP).

By the time Apple's penultimate next generation OS project, Copland, was mercifully killed in 1996, the situation was dire. Mac users had suffered too many broken promises, and Apple had stumbled down too many blind alleys. By all rights, Copland should have been Apple's last chance. But the acquisition of NeXT and the second coming of Steve Jobs gave Apple one final window of opportunity.

Despite the (comparatively) minor market requirements hiccup of the Rhapsody strategy, the Mac OS X project proceeded with what can only be described as single-minded determination, from its official announcement in May of 1998 to its first release in March of 2001. Dates were missed, features were added and removed, but unlike all earlier efforts, this one produced a shipping product.

And yet the success of Mac OS X is still an open question. Unlike the relatively controlled public image of the Copland project, Mac OS X has endured the increased scrutiny of the Internet age. While Mac users from 1994 to 1996 were treated to optimistic articles and future-world mock-ups in enthusiast publications like Macworld and MacUser magazine, Mac OS X has been analyzed by a much wider audience.

Here at Ars Technica, we've been following Mac OS X since its second developer release. It may seem strange to have seven articles dedicated to a product before the first official release, but the journey of Mac OS X has certainly been an interesting one.

This article will cover Mac OS X 10.0, but it will build on everything that was discussed in the earlier articles. If you haven't already read them (or similar articles elsewhere), you may have some difficulty following along. The list of earlier OS X articles appears below in reverse-chronological order. The most relevant are the two most recent: the Public Beta article and the relevant section of my recent Macworld San Francisco coverage.

• MWSF: Mac OS X Post-Beta 1/17/2001
• Mac OS X Public Beta 10/03/2000
• Mac OS X Q & A 6/20/2000
• Mac OS X DP4 5/24/2000
• Mac OS X DP3: Trial by Water 2/28/2000
• Mac OS X Update: Quartz & Aqua 1/17/2000
• Mac OS X DP2: A Preview 12/14/1999

Let's begin...

Installation

I've never quite understood the fascination some people have with the install process. As far as I'm concerned, the only issues are:

1. Does it install on configuration XYZ?
2. How well does it preserve and/or handle existing configuration settings?

And yet almost every review of a new operating system can't help but begin by listing how long the installation took, often down to the second. The bottom line as far as such "benchmarking" is concerned is that the gating factor in the install process is almost always an invariant: disk speed, network speed, etc. Mac OS X is no exception, as we'll see.

The primary test system for this review was my revision 1 blue and white Power Mac G3 400MHz with 256MB RAM and a 12GB hard drive, all as delivered by Apple. Additional personal configuration includes an ATA/66 PCI card with a 45GB IBM 75GXP drive attached, and several SCSI devices hanging off the (Apple-installed) Adaptec SCSI card.

A dual 450MHz G4 with 256MB RAM and a 30GB HD served as a secondary test system, mostly for subjective performance comparisons.

The Mac OS X box includes a thin 30 page tutorial booklet, the usual license agreement and legalease, and three CDs:

• Mac OS 9.1
• Mac OS X 10.0
• Mac OS X Developer Tools

I began by reformatting the 12GB disk, creating a fresh HFS+ volume, and installing Mac OS 9.1 on it. As you know (because you did your homework and read the other articles, right?), Mac OS X requires a full installation of Mac OS 9.1 in order to run classic Mac OS applications. The 9.1 installation can be anywhere: on another disk, on the same disk, on a different partition, etc. I chose to install 9.1 on a fresh disk and then install Mac OS X directly on top of it. I suspect this will be the most common configuration.

After 9.1 was installed, I inserted the Mac OS X CD and ran the installer. Immediately, a dialog popped up with a "restart" button. The only purpose of this portion of the install process is to set the startup disk to the OS X install CD and then restart. Unfortunately, clicking the restart button produced an error message that told me the startup disk could not be changed. Not an auspicious start, but booting from a CD is not rocket science. I simply restarted and held down the "c" key to force my Mac to boot from the install CD.

The install CD boots into Mac OS X, not Mac OS 9. The installer asks to install the following components:

• Base System - 288,662K
• Essential System Software - 592,980K
• BSD Subsystem - 82,867K
• Additional Print Drivers - 78,885K

The last two items are optional, but selected by default. I chose to follow the defaults and install everything. That's over a gigabyte of data, stored compressed on a CD. More than anything else, this determines the time required to install. The benchmark-obsessed should be able to do the math in their heads, but if you insist on a published number, it took about 16 minutes from start to finish.

The first boot from the new Mac OS X installation begins with a bit of a surprise: a QuickTime movie showing the word "welcome" in several languages floating upwards in a sea of wavy blue liquid. There's even background music.

After that, a number of setup questions are presented, both demographic and technical. You're asked to enter your name and address, some information about how the computer will be used, your network connection type, the current date and time, your time zone, your email address, and your iTools registration information. (iTools is Apple's suite of Internet services available to all Mac users. It includes a free email address, web space, and network disk storage.) You're also asked to set up a user account for yourself, choosing a short username ("john") to go with your longer full name ("John Siracusa"). Both the short and the long username may be used to authenticate in Mac OS X.

The first real surprise comes from the email setup screen. It defaults to the iTools email address entered earlier. The surprising part is that it is listed as an IMAP account and uses Apple's server for outgoing SMTP. Previously, iTools email supported only POP, and required the use of your ISP's SMTP server for outgoing mail. Industrious Mac users actually discovered iTools's new abilities about a week before Mac OS X's release, but I was still surprised to see IMAP as not only the default choice for iTools email, but also the only choice in the setup screen. If you select "use my iTools account", it selects IMAP for you and disables the rest of the form.

I'm a big fan of IMAP, so this change made me very happy. As far as I know, this is the first (relatively) spam-free free email service that provides its own authenticated SMTP server for outgoing mail, and an IMAP server for incoming mail. It doesn't even append one of those annoying signatures to all your email. And since there is no real web component to the iTools email service, it's open to anyone. You do need a Mac to sign up, however, but it's well worth borrowing a friend's Mac for a few minutes to snag an account for yourself--assuming, of course, you don't have any issues with an address that ends in "@mac.com."

Again, for the "benchmark" fans, it took me about 8 minutes to fill out all the information and complete the setup process. After that, the Finder appears and you're up and running with Mac OS X.

First boot into Mac OS X 10.0

Getting Started

Attentive readers may notice that, by default, Mac OS X avoids the login screen entirely. The system is configured to automatically log in under the account created during the setup process. As discussed in earlier articles, this is an "administrator" account, but it is not the "root" or "superuser" account (user id zero). In fact, the root account is disabled by default. Apple clearly does not expect or want users to log in as root. Anything worth doing can be done through a normal user account that is blessed with administrator privileges.

But to really screw up--er, I mean "play with" the system, clever (or possibly not-so-clever) users will want to enable the root account. There are many ways to do this, ranging from command line incantations to GUI manipulation. I chose the GUI route, selecting the relevant menu item in the NetInfo Manager application. You are prompted to give the root user a password, after which the account is enabled.

Enabling the root account

Rather than getting down and dirty with the Unix guts, let's throw the benchmark set another bone and do some startup time comparisons. As with install time, I've never understood the importance some people attach to boot times. My own experience with computers has shown little relation between boot time and any other meaningful statistic. I've seen powerful workstations that take forever to boot, and primitive home computer that boot nearly instantly.

Nevertheless, short boot times are a desirable feature, all other things being equal. The first full boot after setup took about 1 minute and 50 seconds. For comparison, the first full boot of my fresh Mac OS 9.1 install took about 47 seconds. (Note that both of these times exclude the POST sequence, which varies greatly depending on the hardware installed.) Subsequent boots of OS X with some nonessential services disabled (primarily the remote NetInfo server lookup) improved on the 1:50 time by a few seconds.

Despite these numbers, Mac OS X should not double most people's boot times. Remember that the 9.1 install was bone-stock. My primary 9.1 install (on the faster 7200RPM ATA/66 drive) takes over two minutes to boot due to all the extensions I've got installed. The OS X boot process is further hampered by its current "safe" implementation: a linear sequence of events. Parallelization of the startup process has been discussed for some time on the relevant Darwin mailing lists, and should improve boot times considerably.

Here are some more, possibly more relevant startup times. The classic environment takes about 47 seconds to start. Note that that's exactly as long as Mac OS 9.1 took to boot normally. With extensions disabled, classic starts in about 15 seconds. Once classic is running, application launch times are also comparable to their "native" Mac OS 9.1 performance. The table below shows a sampling of classic application launch times in OS X (excluding the time needed to launch the classic environment, which is listed separately). All applications were launched twice to test the benefits of caching. And remember that this is just me sitting in front of the screen with a stopwatch, so the margin of error is probably several seconds.

Classic Environment and Application Launch Times
	First Try	Second Try
Classic Environment	47 secs	40 secs
Classic (extensions off)	15 secs	13 secs
Photoshop 5.5	12 secs	10 secs
MS Word 2001	3 secs	2 secs
Internet Explorer 5.0	3 secs	3 secs
Quicken 2001	10 secs	9 secs

These times are in line with the same applications running on a plain Mac OS 9.1 system, again highlighting the fact that the classic environment is not "emulation" in the same sense that something like Virtual PC is emulation. There is no instruction set translation going on. This is native PowerPC code running on PowerPC hardware.

But there's no avoiding the fact that classic is a whole other world of native PowerPC code running alongside the rest of Mac OS X. The classic environment matches a plain Mac OS 9.1 system in another measure as well: RAM usage. Actually, it's a bit better than a 9.1 system due to the lack of a classic Finder process and other code sharing trickery, but it still takes a hefty bite. Just booting the environment takes about 30MB of RAM (give or take, depending on which extensions you've got loaded in 9.1). After that, the per-application RAM usage matches the RAM allocations set for each classic app.

Native OS X application launch times are not particularly impressive, and sometimes downright bad. Even without a stopwatch, it's easy to measure the time needed to launch an application by counting how many times its icon bounces in the Dock before it settles down to run. "Bouncemarks" may be rough, but when you see classic Internet Explorer 5.0 barely make it through a single bounce before coming up, and then watch the carbonized Internet Explorer 5.1 "preview" bounce 18 times, the verdict is clear. Even something as simple as launching the System Preferences takes 6 bounces.

Granted, like boot times, application launch times are not as important as they're sometimes made out to be, especially on an OS with a modern virtual memory system. But as good as OS X's VM is, it's still wise to quit applications that are not in use before heavy paging activity starts. Speaking of which...

RAM Usage

Mac OS X likes RAM. The official requirement is a minimum of 128MB of RAM. Some people will tell you that you can get by with 64MB if you don't run classic. And, in fact, you can. I'll bet you could even boot OS X with as little as 32MB if you were persistent enough. But merely "booting" is a far cry from "using."

Rule number 541 of computer use: never run any software on the "minimum required system" marked on the box. Yes, OS X's virtual memory infrastructure is very solid, but you can't get blood from a stone. As I write this, I'm running the Finder, iTunes, Terminal, System Preferences, and DragThing, plus IE and BBEdit in the classic environment. Here's a peek at the output of the (Unix) top command:

	Processes:  38 total, 4 running, 34 sleeping... 105 threads         15:02:46
	Load Avg:  0.53, 0.83, 0.73     CPU usage:  29.7% user, 8.5% sys, 61.9% idle
	SharedLibs: num =   81, resident = 16.9M code, 1.20M data, 4.38M LinkEdit
	MemRegions: num = 1821, resident = 82.6M + 5.48M private, 31.4M shared
	PhysMem:  25.5M wired, 34.8M active,  192M inactive,  253M used, 3.25M free
	VM: 1.70G + 41.0M   8068(0) pageins, 0(0) pageouts 
	PID COMMAND      %CPU   TIME   #TH #PRTS #MREGS RPRVT  RSHRD  RSIZE  VSIZE
	271 top         10.1%  0:00.53   1    19    14   176K   224K   400K  1.31M
	265 TruBlueEnv   4.2%  2:32.46  15   228   195  50.0M  1.43M  51.0M  1.05G
	262 System Pre   0.0%  0:03.08   2    76    66  1.99M  4.83M  5.05M  49.0M
	259 iTunes      21.1%  4:15.90   8   165   188  6.30M  6.30M  8.67M  62.1M
	246 tcsh         0.0%  0:00.22   1    17    14   252K   452K   692K  5.57M
	245 telnet       0.0%  0:00.04   1    17    15   100K   264K   320K  1.43M
	236 Terminal     0.0%  0:11.58   6   103    95  2.67M  6.54M  7.32M  53.1M
	233 DragThing    0.0%  0:14.74   1    63   116  2.88M  5.33M  4.51M  48.4M
	231 Dock         0.0%  0:05.22   3   107   171  3.48M  5.33M  4.73M  48.6M
	230 Finder       0.0%  0:24.97   3    92   153  8.91M  14.9M  15.1M  67.8M
	229 pbs          0.0%  0:02.43   3   106    64   636K  1.35M  1.95M  15.6M
	226 loginwindo   0.0%  0:03.04   2   104    66  1.26M  3.34M  2.93M  45.1M
	223 cron         0.0%  0:00.01   1    10    14    84K   220K   132K  1.50M
	219 SecuritySe   0.0%  0:00.18   2    24    27   524K  1.01M  1.50M  4.68M
	207 automount    0.0%  0:00.03   2    12    18   220K   284K   324K  2.21M

Check out the highlighted section: 253M used, 3.25M free. Physical memory is nearly exhausted on a 256MB system under what would be a pretty light load in Mac OS 9. But note that nothing at all has been paged out at this point, and only 25.5M is "wired" (meaning it cannot be paged out: mostly kernel-related memory). Now I'll launch the following applications: Sherlock, Mail, OmniWeb, Preview, TextEdit, iCab, Network Utility, and Disk Utility, plus Word and Photoshop in classic. Let's see how the picture changes:

    Processes:  46 total, 2 running, 44 sleeping... 134 threads         15:20:23
    Load Avg:  0.76, 0.74, 0.81     CPU usage:  24.7% user, 20.8% sys, 54.5% idl
    SharedLibs: num =   95, resident = 9.61M code, 324K data, 2.00M LinkEdit
    MemRegions: num = 2905, resident =  145M + 4.84M private, 33.0M shared
    PhysMem:  28.6M wired,  149M active, 74.7M inactive,  253M used, 3.30M free
    VM: 2.13G + 45.3M   12003(12003) pageins, 2648(2648) pageouts

      PID COMMAND      %CPU   TIME   #TH #PRTS #MREGS RPRVT  RSHRD  RSIZE  VSIZE
      300 top          0.0%  0:00.36   1    19    14   184K   196K   404K  1.31M
      297 Disk Utili   0.0%  0:01.90   1   109    77  1.79M  3.36M  4.17M  49.3M
      296 Network Ut   0.0%  0:02.64   1    65    50  1.32M  2.88M  3.33M  48.4M
      295 iCab         0.0%  0:04.29   3    84    88  2.11M  4.93M  6.06M  52.0M
      294 Preview      0.0%  0:01.03   1    61    43   872K  1.69M  1.55M  46.6M
      292 Mail         0.0%  0:15.58   8   127   132  5.46M  4.56M  8.20M  62.6M
      291 TextEdit     0.0%  0:01.18   1    67    46  1.04M  1.74M  1.80M  47.1M
      290 Sherlock     0.0%  0:04.46   3    94    69  2.46M  3.05M  4.23M  48.6M
      289 .OmniWeb     0.0%  0:09.89  11   120   223  5.32M  4.61M  8.41M  59.3M
      265 TruBlueEnv   0.0%  5:05.42  15   254   244  96.1M  1.01M  96.7M  1.06G
      262 System Pre   0.0%  0:03.42   2    76    66  1.76M  2.85M  3.37M  49.0M
      259 iTunes       0.0%  7:03.99   8   167   194  6.18M  2.73M  6.71M  62.1M
      246 tcsh         0.0%  0:00.32   1    17    15   268K   348K   540K  5.59M
      245 telnet       0.0%  0:00.04   1    17    15    32K   152K   124K  1.43M
      236 Terminal     0.0%  0:16.65   6   129   109  1.86M  4.40M  4.29M  53.9M

The first thing you'll notice is that the amount of free RAM has stayed about the same (a slight increase, actually). Mac OS X is apparently determined to keep a small stash of free RAM. But check out the other highlighted spec: 2648 pageouts. Wired RAM increased slightly, presumably due to increased kernel resource usage by all the newly launched applications.

But the numbers only tell part of the story. While all this is going on, here I am typing away in BBEdit without an apparent slowdown. iTunes hasn't skipped. I can switch to any one of the applications and use it without undue thrashing. But the wall's out there somewhere. Let's find it by launching the rest of the applications...

...and by "the rest" I mean every application that comes with Mac OS X (not including the Developer Tools CD), plus a few popular third party applications. During the (simultaneous) launch sequence, iTunes stuttered a few times and I was effective locked out of BBEdit because every time I clicked on an editing window to switch it, another application would launch in front of it. But I'm up now, and my application switcher palette (16x16 tiles on the right edge of my screen, courtesy of DragThing) goes off the bottom of my monitor. The dock is equally tiny:

Mac OS X running many, many applications
(Tiny dock appears at the bottom, DragThing applicaton switcher palette appear on the right, running off the bottom of the screen.)

Top shows the following:

    Processes:  78 total, 2 running, 76 sleeping... 208 threads         15:42:20
    Load Avg:  1.73, 1.91, 2.53     CPU usage:  46.8% user, 42.8% sys, 10.4% idl
    SharedLibs: num =  112, resident = 18.5M code, 716K data, 4.45M LinkEdit
    MemRegions: num = 5532, resident = 88.0M + 13.0M private, 69.7M shared
    PhysMem:  31.7M wired,  147M active, 73.5M inactive, 252M used, 3.54M free
    VM: 3.74G + 49.4M   29467(1) pageins, 8466(9)pageouts

      PID COMMAND      %CPU   TIME   #TH #PRTS #MREGS RPRVT  RSHRD  RSIZE  VSIZE
      441 top         14.7%  0:00.88   1    19    15   284K   220K   504K  1.39M
      360 DirectoryS   0.0%  0:01.16   3    36    49   452K   752K  1.18M  4.45M
      351 PrintServe   0.0%  0:00.40   1    36    20   288K   760K   704K  6.64M
      350 DisplaySer   0.0%  0:00.43   1    41    36   304K   384K  1008K  18.3M
      347 tail         0.0%  0:00.11   1    16    13    56K   192K   228K  1.23M
      340 StuffIt Ex   0.0%  0:04.16   7    86    83   916K+ 2.93M  2.44M  48.3M
      339 Print Cent   0.0%  0:01.77   3    92    59  1.73M  4.21M  3.93M  47.2M
      338 ProcessVie   2.9%  0:06.98   2    66    52  1.32M  4.41M  4.42M+ 50.0M
      337 NetInfo Ma   0.0%  0:01.48   1    64    51  1.27M  3.83M  4.15M  48.5M
      336 Keychain A   0.4%  0:04.17   1    59    63  1.42M  3.57M  3.45M  46.0M
      335 Key Caps     0.0%  0:01.22   1    60    62   740K  3.20M  2.32M  48.6M
      334 Applet Lau   1.6%  0:10.16  15   194   140  8.69M  8.14M  15.1M   223M
      333 ColorSync    0.0%  0:01.21   1    61    57  1.25M  3.69M  3.60M  48.3M
      332 DigitalCol   0.0%  0:10.98   1    72    61  1.48M  3.13M  3.12M  48.1M
      331 Disk Copy    0.0%  0:02.95   1    65    42  1016K  2.58M  2.37M  46.8M

Summary: more pageouts, similar free and wired RAM. What it doesn't show is the sluggishness of the whole system. BBEdit is fine, and iTunes hasn't skipped again since the launch sequence, but if I switch to another application and try to use it, it takes a little while before it can get its working set paged in, and is sluggish and unresponsive until it does.

So, what has this masochistic little exercise shown? Well, it's shown that Mac OS X's VM system stomps all over Mac OS 9's (although that's not much of a shock). Mac OS 9 with the default VM settings for a 256MB system wouldn't be able to run a similar complement of applications. It would "run out" of memory after the applications had (statically) allocated all the available RAM. But the Mac OS 9 system would also be a lot more responsive for the same reason that it can't handle the load: it keeps more in physical memory and less on disk. Yes, there are many more important advantages to a "real" VM system as found in OS X versus the cobbled together OS 9 implementation, but the bottom line is this: OS X will give users enough rope to hang themselves.

Mac OS X won't complain about "running out" of RAM. It'll cheerfully and dutifully page-out to disk...and page and page and page. Obviously, most normal users aren't going to launch so many applications simultaneously, but just imagine a system with half the RAM, like the "minimum required" 128MB machine. It wouldn't be too hard to push such a machine to similar limits, even with a "normal" load of applications.

So we come back to our rule: never run any software on the "minimum required system" marked on the box. I certainly wouldn't want to do anything more than trivial email, web, and word processing tasks on a 128MB OS X system, but for such tasks it should squeak by without unreasonable performance degradation.

This is definitely a psychological shift for most Mac users who are used to their OS complaining about RAM usage long before performance drops to the levels experienced in the experiment above. Mac OS X would benefit from some sort of (optional) "advisory" resource limit warnings to ease the transition.

Performance

Pushed to the limits, OS X's VM system holds up as well as can be expected. But there are even more crippling conditions around the corner. The most glaring example I found was the interaction between the classic environment and heavy disk i/o. When I installed the Developer Tools CD on a lightly loaded system, the handful of classic applications I had open became totally unresponsive. Other applications were sluggish as well, but nothing like the complete lock-out in classic. After the install finished, everything returned to normal, but I'd still file such an inexplicable performance drop-off as a pretty big bug.

Enough abuse. Let's look at how OS X performs under "normal use." It turns out to be a mixed bag. We've already seen the application launch picture: classic, good, OS X native, not-so-good. Readers who have followed our past coverage of OS X are undoubtedly curious about the performance pitfalls that have dogged OS X throughout its development process. I'm sad to say that, for the most part, they remain.

Window Resizing

The headliner is opaque window resizing. On my G3/400, it was unacceptably slow across the board. All opaque resize interactions required an attentiveness and time investment that was way beyond sane limits. The interaction was much like the aviation phenomenon of "chasing the needle": over-correcting in response to time-delayed instrument feedback. In OS X, it works like this: you grab the corner of a window and drag to make it smaller or larger. Visually, nothing happens, so you drag some more. Eventually, the display updates and you see that you've over-shot your goal size. You reverse your action to correct, and the cycle repeats, oscillating until you converge on your desired window size.

Compared to the "gray outline" abstraction used in classic Mac OS during window resizing (shown below), OS X's opaque window resizing is meant to give better visual feedback and increase the feeling of "direct manipulation." But the reality of the situation is that poor performance makes opaque resizing in Mac OS X less responsive with less of a feeling of direct manipulation than classic Mac OS's gray outlines.

Resizing a window in Mac OS 9: abstracted, but always responsive

Does this problem make the entire OS unusable? Of course not. And does it improve with faster hardware? Marginally. But anyone who finds the performance "acceptable" has very low standards, in my opinion. Even on the dual G4/450, it was unbearably slow. And there's no denying the fact that it is much slower and less responsive than classic Mac OS's gray outlines. Again, keep in mind the goal of opaque resizing: better visual feedback and an increased feeling of direct manipulation. Mac OS X's opaque resizing fails on both counts, and would have been disabled if usability was the primary concern.

On the other hand, if you add "marketing" and the ability to perform gee-whiz demos to the picture, perhaps the feature can be better explained. While I recognize the value of such things, you have to draw a line in the sand somewhere. At the very least, Apple should have added a system-wide option to disable opaque resizing in favor of gray outlines.

The cause of this performance gaffe is probably only important to the Apple folks who have to fix it, but that hasn't stopped rampant speculation among Mac users. The current front-runner is the idea that many Quartz operations cannot be accelerated by current video card hardware, which is accustomed to simply streaming solid pixels to the screen. This feature, at least, is accelerated in OS X. But almost every other operation requires calculations by the CPU (and memory bus overhead to feed it) before the pixels to be drawn can be passed to the graphics card.

This model, at least, correctly predicts the observed behavior that windows with many child elements resize more slowly than windows with few. The poster-boy for slow resizing is the Finder list-view window, which is rife with child elements: column headers, rows, and cells. According to the theory, each of those child elements must be calculated by your poor, tired CPU before the pixels to be drawn can be sent to the graphics card. The more calculations, the slower the redraw.

Second generation display layers like Mac OS 9's that are only concerned with drawing solid pixels to the screen (with the occasional small-scale compositing calculation) are fully accelerated by today's 2D graphics hardware. Fully accelerating a third generation display layer like Quartz will require new, more powerful hardware. Already, there is talk of using the considerably more sophisticated 3D hardware on today's graphics cards to give Quartz a boost. No, this does not mean that window will suddenly become three-dimensional. It just means that all those compositing calculations that your CPU has to do today when running Mac OS X may be off-loaded to a super-powerful GPU on your 3D graphics card. My fingers are crossed.

Quartz

Aside from window resizing, the Quartz display layer performs admirably. That's not to say it performs as well as Mac OS 9's considerably simpler display layer, because it doesn't. Mac OS 9's display performance is undeniably faster on the same hardware. This it not surprising at all, given the amount of work done in comparison to Quartz, but it would be nice if Apple could make the performance gap a bit smaller.

In some areas, Quartz almost matches Mac OS 9's responsiveness while doing considerably more work. The best example is window dragging. On a lightly loaded system, incredibly complex windows can be dragged across equally complex UI elements with nearly the same responsiveness that Mac OS 9 drags mere outlines. For example:

Click the image for a larger version with more explanatory text
Here's a better shot of the letters' drop-shadows

Dragging this window behind the also-transparent Dock is impressively responsive, especially given the graphics acceleration issues and necessary CPU involvement described above. Again, this is under light load. Under stress, this eye candy also infringes on the interface's usability as it "drops frames" while trying to keep up with user input.

But given the average performance of this feature, it's my opinion that the use of transparency in OS X is safely on the opposite side of that usability/features line in the sand mentioned earlier. Although it currently impairs usability, it does so to a much lesser degree than the window resizing performance. (And note that dragging a totally opaque window is almost entirely hardware accelerated. Only the rendering of the transparent drop-shadow behind the window requires CPU involvement.)

Application Performance

"Numerical" application performance, meaning time taken to complete a computationally intensive task like a Photoshop filter or MP3 encoding, is not particularly interesting. Classic runs such tasks close enough to a plain Mac OS 9 system as to be indistinguishable without a stopwatch. In my testing, the performance hit was less than 10%, and often too small to be measured with any accuracy.

The most obvious "application performance issue" isn't related to applications at all. The subjective performance experience provided by a combination of the redraw speed and general UI responsiveness is what will make most casual observers label a particular application "slow." The truth is, any classic application will take a small redraw speed hit from running in the classic environment. Likewise, any native OS X app that has a lot of overlap with the display performance problems describe in the previous section will feel "slow."

Multitasking is where application performance really comes into play: how well does each application behave in this new environment? Classic applications continue to exist in their cooperative little world, of course. The only new wrinkle is that if the classic environment itself (a regular userland process, remember) is not getting enough CPU cycles, the applications running in classic will also be starved, and therefore unresponsive. As mentioned earlier, I saw an extreme case of this when installing the Developer Tools CD. Classic, more than any other OS X application, has hooks deep into the core OS, all the way down to the Mach kernel. As an apparent consequence, it seems to be the most susceptible to bad behavior in response to system load.

The next offender has no such defense. The OS X Finder is the undisputed king of unresponsiveness among the OS X native applications. We've already touched on the horrendous list-view resize problems, but wait, there's more. An unreasonable number operations "block" in the OS X Finder. By "block", I mean that the Finder is unresponsive during these operations. Almost anything that requires network access exhibits this behavior. If the mounting of an AppleShare volume or your iDisk takes 30 seconds, the Finder will be useless for 30 seconds. This is clearly an application shortcoming, not a fault of the OS, since many other applications do not exhibit these problems. It's a shame that such an important application is so afflicted.

The bundled 5.1 "preview" version of Internet Explorer is another performance dud. It takes forever to launch, has the usual assortment of window resizing and scrolling problems, often blocks when downloading files, and generally behaves worse than IE 5.0 running in the classic environment. After fighting with IE 5.1 for several hours, I gave up and pasted the pretty IE 5.1 icon onto my copy of IE 5.0 and used that for my web browsing instead. Its performance is superior in all respects.

QuickTime performance remains problematic on the G3. I was unable to play even a single copy of the large (588x440) version of the Ruby iMac television advertisement at the full framerate on the G3/400, even on a totally idle system. This movie plays just fine in Mac OS 9 on the same machine. The dual G4/450 does much better, happily playing two copies of this movie simultaneously at full speed on a lightly loaded system. Obviously, the G4's AltiVec unit helps QuickTime playback a great deal, but I'm still puzzled by the poor G3 performance, especially the disparity between playback in OS X versus Mac OS 9. This has been a problem throughout Mac OS X's development, and it's a shame to see that it's made it into the 10.0 release. Is Apple simply giving up on the G3 in favor of G4 optimizations?

One final popular performance metric: "will my MP3s skip?" Well, it depends. A Mac OS X native version of Apple's iTunes MP3 player/encoder application was released on March 24th, but is not included in the OS X box. It's a rough port that suffers from some major redraw slowdowns, and it doesn't yet support many features like CD burning and full-screen visualizations. Nevertheless, left minimized in a corner, it dutifully plays nearly skip-free MP3s.

I say "nearly" because I can indeed make it skip on my G3/400 by, say, grabbing a translucent terminal window and shaking it back and forth as fast as I can. (The tremendous CPU overhead of this action actually makes sense, given the graphics acceleration issues discussed earlier.) This trick doesn't work on the dual G4/450, but I was still able to make iTunes skip on that machine by exercising the classic environment (starting, stopping, using classic applications, etc.)

According to Apple's documentation, Mac OS X's Mach kernel boasts "real-time support" that "guarantees low-latency access to processor resources for time-sensitive media applications." I don't doubt the potential of such Mach features, but I have not seen an application that takes full advantage of these abilities. MP3 playback in the Mac OS X version of iTunes does not seem substantially more "skip-free" than its Mac OS 9 counterpart. CPU cycles are a finite resource, of course, but it seems to me that the full realization of totally skip-free playback could be achieved via Mach's real-time capabilities. iTunes 2.0 on Mac OS X 10.5 perhaps?

Performance Summary

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

A lot of the above is to be expected with any new OS. The most comparable experience in the Mac world that I can recall is the introduction of color. My venerable SE/30 had its display performance cut nearly in half by the addition of a 14" color monitor and a ($600!) 24-bit color display card. Likewise, the introduction of System 7 brought with it a huge performance hit. I booted System 7.5.5 on my 8MB SE/30 recently and was amazed at how slow basic operations like selecting the Apple menu were. I could literally watch as the OS drew the menu, the menu items, and all the icons next to them. System 6 on the same hardware using the black and white display is considerably snappier.

Apple's transition to the PowerPC CPU brought with it another similar experience. "Classic" (68K) applications are emulated on PowerPC Macs--and this is real instruction set translation, which is much more computationally expensive than the series of shims that make up the classic environment in OS X. Yet it was not an insurmountable obstacle to the success of the transition. A short time after the start of the transition, PowerPC Macs were emulating 68K applications faster than any native 68K machine had ever run them.

On the other hand, the upside of native PowerPC applications was considerable. Mac OS X does not have this advantage. Native OS X applications are not automatically faster than their classic counterparts, and may even be considerably slower, as demonstrated by the OS X Finder and the (admittedly, preview) version of Internet Explorer that ships with the OS.

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

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

I've yet to cover other issues like stability and user interface, of course, and there will be advantages and disadvantages to consider there as well, so don't make your decision yet.

Stability

Mac OS X is the most stable version of Mac OS ever released. Did I ruin the surprise for you? It's doubtful, considering the technical inclination of the average Ars Technica reader. Yes, Mac OS X is a modern operating system with preemptive multitasking and (finally!) memory protection. The only things that can take down Mac OS X are:

• Bugs in kernel-mode code (this includes device drivers).
• Resource starvation and denial-of-service attacks.
• The incapacitation of the user-visible interface.

Kernel Panics

Kernel crashes or "panics" are the real deal. If you land on one of these whammies, your only recourse is to restart (or debug the crash remmotely, if you're so inclined). These are the equivalent of the venerable "bomb" dialog boxes from classic Mac OS, only much, much uglier:

A Mac OS X kernel panic: very ugly.

I've used many releases of OS X, starting with DP2 in 1999, and I've only been able to cause a kernel panic once (in build 4K70, for the curious; more on build numbers later). I don't doubt that OS X 10.0 has kernel and/or device driver bugs just waiting to be tripped up, but the situation is orders of magnitude better than the world of classic Mac OS where any process anywhere can completely hose your machine.

Resource Starvation

The classic resource starvation "crasher" is the fork bomb, named after the Unix system call that spawns a new process. A fork bomb is a process that repeatedly clones itself in an attempt to consume system resources. A popular variation is to add some memory allocation before each fork(). The end result is a process that multiplies and gobbles memory and kernel resources until the system is so unresponsive that it can essentially be declared dead.

The typical defense against such attacks is a system of resource limitations imposed on users. BSD resource limits prevent naive fork bombs from doing much damage. In my testing, fork bombs eventually ran into the default per-user process limit of 100, after which no new processes could be spawned. Fork bombs combined with massive memory allocation also ran into resource limits, eventually crying uncle with "error: Can't allocate region" messages. In both situations, the OS remained responsive enough that I could kill the offending processes and return the system to normal.

The superuser, of course, can circumvent and/or change these limits. I didn't test whether or not the superuser could bring down the system through resource starvation because the superuser can simply recursively delete the boot volume if he really wants to cause trouble. I also suspect that successful resource starvation attacks from normal users are possible, but I wasn't able to cause any real harm in my brief testing.

The bottom line is that Mac OS X holds up reasonably well when subjected to basic resource starvation attacks. And it looks even better when compared with classic Mac OS, where an effective resource starvation attack is to simply hold down the mouse button.

User Interface Death

The final danger to stability is the possibility that the user-level processes that make up the GUI will crash. This in itself does not hurt the system, since user-level processes cannot crash the OS. But without the GUI, the system is as good as dead to someone without the skills and means to log in and fix the problem via telnet (assuming its enabled!). Death of the GUI and/or the failure to respond to user input (which may actually be a real kernel- or driver-related crash) is equivalent to a real crash as far as most users are concerned. I've experienced several of these situations in the developer releases of OS X as well as the Public Beta, and unfortunately, the 10.0 release is not immune.

A recent, and very frustrating example involved the classic environment. I left the dual G4/450 to sleep over night with all my applications (classic and native) open. When I returned in the morning, classic was frozen. I hit command-option-escape to bring up the "force quit" dialog, but nothing happened. (I've found that force-quit rarely works when I really need it in OS X.) Luckily, I had several terminal windows open, and I killed the classic process manually. The real trouble started when I tried to re-launch classic. It would freeze half way through, requiring another manual kill. The Finder had also gone south by this point, and I was forced to kill that as well. Things eventually degenerated to the point where the only useful processes left were Terminal and the Dock. I gave up, killed off the rest of the processes, and was bounced back to the login screen.

But wait, there's more: when I logged back in, I found that classic still wouldn't launch successfully. Applications started freezing up again, and I was forced to kill everything off and reboot. Even that task wasn't easy, since the "restart" menu item wasn't working. After rebooting, everything appeared to be back to normal.

I've encountered similar situations on the G3. Even worse, I often fail to get back to the login screen successfully, leaving the machine stranded with a blank screen and no means to bring it back to life (e.g. a remote machine to telnet in from). A hard-wired interrupt like Linux's alt-Fn virtual consoles would really help in these situations.

The moral of these stories is that an OS is only as stable as its user interface. To most users, the interface is the computer. While it's nice to no longer be mere milliseconds away from a classic Mac OS "bomb" dialog box and a mandatory reboot, a crumbling UI that takes minutes to diagnose and repair, and then eventually requires a reboot anyway, isn't pleasant either.

Stability Summary

Mac OS X is unquestionably more stable than Mac OS 9, but its theoretical stability advantage is not fully realized due to numerous bugs in the areas described above. Its "effective stability" is only marginally better than Mac OS 9. With the 10.0 release, it's not a question of "if" you'll encounter (essentially) fatal bugs, it's only a question of "when" and "which ones." If you have a complex hardware setup with many peripherals, you may get a lot of kernel panics. If you depend heavily on the classic environment, your biggest enemy could be classic-related UI freezes. If you're unlucky enough to stumble across a poorly (or deviously) written application that gobbles resources, your Mac may grind to a halt in a flurry of disk thrashing.

If you dream of year-long uptimes in Mac OS X, the 10.0 release will disappoint unless you are extremely disciplined with your usage. The potential is there, but the reality is still very rough around the edges.

User Interface

There were no startling UI revelations in Mac OS X 10.0. In fact, surprisingly little has changed in the OS X user interface since I last visited the topic in my Macworld San Francisco article. Of course, actually using the post-beta features is somewhat different than seeing Steve Jobs demonstrate them on a stage. Let's see how things turned out.

The Dock

What can I say about the Dock that hasn't already been said in my previous articles? Well, there are new features and improvements in 10.0, but the fundamental nature of the Dock remains unchanged. Whether that's good or a bad thing depends on your user interface priorities. First, let's look at the changes.

Dock Changes

• Dock icons now have "infinite" height. The clickable area of docked icons now extends all the way to the edge of the screen, and the edges of the neighboring icons. It's no longer necessary to carefully aim for the (possibly intricately drawn) icon itself.
• Docked folders, applications, and "docklets" now support hierarchical pop-up menus. The example that greets users the first time they boot into Mac OS X is the "Displays" docklet that provides a pop-up menu for color depth and resolution switching. Any folder placed on the Dock provides a pop-up menu of its contents, and any running application presents a list of its open windows.
• The Dock may be moved to any edge of the screen, and may be pinned at either end. This feature has no GUI interface and was actually disabled earlier in the development cycle, but has been re-enabled in 10.0. It can be activated by a simple and widely documented hack. The result is a pop-up menu for pinning and relocating the Dock (shown above).
• QuickTime movies continue to play in miniaturized form in the Dock. While not a particularly useful feature, it does demonstrate that applications are free to do almost anything they want with their patch of real estate on the Dock.

What do these changes buy in terms of usability?

The larger Dock icon click areas improve targeting accuracy tremendously. This is a no-brainer feature for any UI element rooted on the edge of the screen, and only Apple knows why it took so long for it to appear. (It debuted in a post-beta developer release.)

Docklets provide the functionality of the classic Mac OS control strip, but they are currently rare (only three are included in 10.0: Displays, Airport Signal Strength, and Battery Monitor) and the APIs for third party Docklets are still in flux.

Docked folders match most of the functional merits of the classic Apple Menu, providing Mac OS X with a much-needed universally accessible, user-configurable, hierarchical quick-access mechanism.

The window menus attached to running applications offer a shortcut to any open window, provided you know which application it's in.

The ability to move and pin the Dock is useful, but the average user shouldn't have to dig around in XML property lists to enable basic UI features. Apple should provide a GUI for these options.

QuickTime movies playing in the Dock: what else can I say? It's neat.

The Big Picture

Taking a step back, aside from the improvements listed above, the big picture remains the same. The interface simplification provided by the Dock--a single UI element that handles a tremendous number of tasks--comes at a substantial usability price. The essential nature of the Dock as a clearing house for almost all aspects of the Mac OS X UI not handled by the menu bar or applications themselves negates many of the post-beta improvements.

The ability to pin the Dock at one end is hampered by the population pattern of the Dock. Minimized windows insert themselves next to the Trash, so pinning the Dock at that end only provides a single stationary target: the Trash itself. Applications insert themselves next to the Dock divider, making it possible to create a series of application launcher icons with stationary targets on the left side. But complex launching requirements are arguably better handled by hierarchical pop-up menus instead of a linear list of icons, and folders cannot be stationary on the Dock unless you never minimize a window.

The Control Strip-like functionality provided by Docklets is handicapped by the Dock's catch-all nature. The advantages of the Control Strip are mostly absent in Docklets: the small size, the ability to be minimized when not needed, and the isolation from unrelated UI elements. Dockets take up just as much room on the Dock as folders, the Trash, running applications, inactive application, documents, and URLs, no matter how you rank the relative importance of those items in your daily work.

Similarly, anyone who wants to use a docked folder to duplicate the Apple menu must consign himself to a much larger loss of screen real estate, since the entire Dock must be visible if the one docked folder he's interested in is to behave like the always-accessible Apple menu. Even at its smallest size, the Dock very quickly consumes considerably more room than the small Apple Menu icon.

Don't misunderstand, these changes are undeniably improvements. In fact, many of them were suggested in earlier articles. The Mac OS X 10.0 Dock is a much more useful and usable interface element than the Public Beta Dock. Furthermore, the simplification provided by the Dock is a tremendous help to novice users.

But does even the new, improved Dock enable Mac OS X to meet the needs of more demanding users as well as the separate interface elements found in classic Mac OS? Unfortunately, as in all previous Mac OS X releases, the answer in 10.0 remains no.

Even for novice users, some problems remain. Windows can still get stuck behind the Dock. Some native OS X applications are aware of the Dock and try to avoid this situation by automatically resizing themselves (another expert-unfriendly feature, in my opinion), but classic applications are not so lucky, and often find themselves buried.

The Dock still gets very crowded, very quickly, even in the hands of a novice doing nothing more than a little email and web browsing. I've observed that window minimization is the screen clutter solution most likely to be found by novices in OS X. And once they find it, they rarely continue looking and discover the application and window hiding features. The end result is a Dock that's jam-packed with windows that were minimized and then promptly forgotten (Finder windows are especially susceptible to this fate since you can always spawn a new one--an issue in its own right.) As the Dock gets crowded, everything suffers: icons get smaller, harder to find, and harder to recognize. It eventually degenerates into a game of "hunt-and-click", something even novices recognize as inefficient and frustrating.

Dock items still lack text labels without a mouse-over, hastening the onset of "hunt-and-click" (or should I say "scrub-and-click"). This is most damaging to folder and minimized window icons which can appear inscrutable (or even identical, in the case of folders) even at very large sizes. And again, this affects both novices and experienced users, although experienced users can mitigate the problem somewhat by applying custom icons to their docked folders.

The Dock's Future

Like the Windows Taskbar before it (and the NeXT Dock before it), the Mac OS X Dock will undoubtedly evolve. And like the Taskbar, I suspect that the Dock's UI flaws will be largely ignored by the average personal computer user. But experienced Mac users know it can--and should--be done better.

For novice users, the Dock's simplicity probably outweighs its problems. Throughout its development, it seems the philosophy of the OS X UI has been to strip everything back to its barest essentials, and then build it back up in response to user feedback. An optimist might see this as a refreshing break with the past, while a pessimist might see it as an inability to learn from the mistakes (and successes) of past. (You can guess which camp I lean towards.) Either way, as the most visible (and hyped) new interface feature of Mac OS X, the Dock is one polarizing widget. But there are even more pressing interface concerns for the Mac faithful in OS X.

The Finder

I wrote earlier that, to most computer users, the interface is the computer. Well, to most Mac users, the Finder is the interface. It's been what Mac users think of as "the computer" for 17 years. Even the slightly nonsensical name--a name that was on the chopping block during development, but has happily survived to 10.0--quickly becomes second nature to Mac users. "Switch to the Finder." "Check the Finder." "It's in the Finder."

The importance of the Finder in classic Mac OS went beyond the philosophical. Many important OS functions were handled by the Finder: file management, application launching, volume mounting, even the Apple menu. In Mac OS X, this much, at least, has changed--and for the better. The Mac OS X Finder is "just another application" in the best sense. Applications need not rely on its functionality to perform what are rightfully system-level functions.

The Spatial Finder

It's the more philosophical role of the Finder where Mac OS X runs into trouble. As discussed at length in the Public Beta article, the distinguishing characteristic of the classic Mac OS Finder--and by extension, the entire Macintosh user experience--is the spatially oriented file management system it provides. In the Public Beta, this experience was all but destroyed by a difficult to avoid, decidedly non-spatial browser-style interface.

And yes, some people like the browser-style interface. I use it myself for certain tasks. It is a useful addition. But the spatial interface is the benchmark for "Mac-like" behavior. Until Mac OS X, the spatial Finder was the only Finder. Non-spatial file management utilities like Greg's Browser existed, but were not used by the vast majority of Mac users. And if you asked your average Mac user why they choose to use a Mac, the number one response would probably have something to do with the interface. By the mid- to late-1990s, anyone who didn't like the classic Mac OS interface or who prioritized user interface below concerns like technical superiority, software or hardware availability, or price would have long since defected to the Windows PC platform (or elsewhere).

It's into this world that Mac OS X is being released. To think that Mac OS X will be so wonderful that its target audience should be the much larger world of PC users (or the much smaller world of NeXT devotees) rather than existing Mac users is an extremely foolish conceit. No, Mac OS X's most important market is, and has always been current Mac users. This is why I think spatially oriented file management is extremely relevant to any discussion of the Mac OS X Finder--despite the fact that 90% of the PC-using world seems to get by just fine with the decidedly non-spatial Windows interface, all their windows maximized to full-screen, alt-tabbing furiously.

The spatial Finder current runs deep in the Mac community. Since the Public Beta, many concessions have been made to the classic, spatial way of doing things in response to the thousands of pieces of feedback submitted to Apple regarding the Public Beta. Disks now appear on the desktop by default. The name of the current folder or disk now appears in the Finder window title bar, along with a proxy icon. The Finder toolbar can be hidden via a widget in every Finder window's title bar, and a status area may be added to Finder windows, making them look almost exactly like (Aquified) traditional Finder windows. In this mode, opening a new folder creates a new window instead of replacing the contents of the existing window. All of this goes a long way towards making Mac users feel more at home, and makes it feel "more like a Mac."

Unfortunately, a frustrating litany of bugs and mis-features leaves the Mac OS X Finder short of its goal of a truly "Mac like" experience:

• Windows are supposed to remember their size and position, but sometimes they forget and appear in odd places at odd sizes.
• In list view, the state of disclosure triangles is not preserved.
• The grid spacing is unreasonably wide, and is not adjustable.
• The default font is very large, and is also not adjustable.
• The "shrink-to-fit" functionality of the window's zoom widget behaves erratically, often failing to scroll the window and ending up the wrong size.
• In certain situations, icons spontaneously jump from their positions in response to window resize events.
• Moving folders often results in their views being changed or their windows being closed.
• Moving upwards in the folder hierarchy via the title bar pop-up menu tends not to honor the position and state of the spawned window.
• Despite diligent and constant dismissal, the Finder window toolbar reappears constantly, changing the size of the window, affecting icon positions, and generally making itself a nuisance.
• Clicking on the Finder icon in the Dock when the Finder is the front-most application spawns a new browser-style window, regardless of the state of all other Finder windows in use.

I could go on, but the bottom line is that the spatial functionality and browser-style functionality of the Finder are still heavily entangled, mostly to the detriment of the spatial style. So no, it is not yet possible to make the Mac OS X Finder behave "just like" the classic Mac OS Finder, as has been claimed by Steve Jobs during several of his Macworld keynote presentations.

The solution to this problem is to cleanly separate the browser-style Finder from the spatial Finder. A window of one type should not be able to spawn a window of the opposite type, and the user should be able to choose which is the default behavior. Everyone's happy.

The Finder Browser

As was demonstrated at Macworld San Francisco, the browser-style Finder has slimmed down and learned some new tricks since Public Beta. The star of the show is the new, customizable Finder toolbar. We'll get to that in a minute. But first, there are some more subtle changes and improvements. Take a look at the new browser window:

The Finder browser

The toolbar in its default state includes a web-browser-style "back" button, a widget to toggle the view to icon, list, or column (shown), and four icons representing some common destinations in the file system. The status bar (the area that reads "10 items ...") can be toggled independently. The toolbar itself can be toggled via the oblong widget on the far right side of the window title bar. The name and proxy icon corresponding to the current folder ("Developer" in the screenshot) also appear in the title bar.

In column view, the size and number of columns is determined by the width of the window. As shown above, the window is mere pixels away from showing only two columns. As you can see in the picture below, the columns may get very wide before a new one is spawned. Unfortunately, this threshold is not adjustable, and the relative widths of the visible columns cannot be changed independently.

The Finder browser, shrunken slightly to show two columns

In browser mode, opening a folder results in the contents of that folder replacing the existing contents of the window in much the same way that clicking on a link on the web (usually) causes the new page to replace the old one within the same browser window. The back button, likewise, works as you'd expect on the web, reverting the window to its previous state. But don't get too crazy with the back button because there is no corresponding "forward" button to save you if you over-shoot your destination--a puzzling omission.

Browser mode is not limited to column view. Icon and list view both work with the toolbar visible, and exhibit the same single-window content replacement behavior. (And note that column view is also available when the toolbar is not visible, further entangling and compromising the spatial integrity of the alternate mode of operation.) In fact, the presence of the toolbar itself (not including the status bar) is the only thing that distinguishes a spatial Finder window from a browser-style Finder window. Its visibility determines the behavior of the objects within the window--a non-obvious cue that may take a while to dawn on novice users (who, like all users, never read the manual ;-)

The real fun starts when you select "Customize Toolbar..." from the "View" menu (or shift-click the toolbar widget in the window title bar). The contents of the window are replaced by a palette of toolbar widgets shamelessly reminiscent of Internet Explorer's toolbar customization feature. You can add, delete, and rearrange toolbar icons in any way that suits you. Most of the toolbar icons are proxies for file system locations. Files and folders can be dragged and dropped onto these toolbar icons, resulting in the appropriate move or copy operation. And, of course, clicking on these toolbar icons displays their contents in the browser window.

One of the most interesting toolbar items is the iDisk icon. Click on it and your iDisk is mounted on the desktop, provided you've filled out the relevant information in the Internet preference panel. After your iDisk has been mounted, the iDisk toolbar icon becomes an eligible drag target for files, just like the other proxies icons.

If you're not content with the selection of toolbar icons presented in the "customize" screen, you can actually drag any file or folder up to the toolbar. (The Finder is even intelligent enough to remove the toolbar icon if the item it represents is deleted.) This feature is a close approximation of the "shelf" used in the NeXT file browser, and it makes the browser window a much more powerful and flexible tool for file management than the fixed-toolbar version found in the Public Beta.

Unfortunately, you cannot have a different toolbar for each Finder window. The one layout you create appears everywhere. The ability to create different toolbars tailored to specific areas of the file system would make this feature even more powerful.

If you fill your toolbar with many items and then make the window too narrow to show them all, an awkward pop-up menu is provided at the right edge:

The Finder browser with a truncated toolbar

Items in this pop-up menu can't be dragged to, disabling an important function of the toolbar. I'm sure Apple would have liked to have implemented a more elegant solution, like enabling the entire toolbar to smoothly slide from side to side in response to item drags or explicit clicks. Perhaps we'll see such a change in the next major revision.

In column view, the far right pane shows a thumbnail preview of the selected file. This feature works for most common file types, including movies (as shown below), MP3s, images, and even plain text files.

The Finder preview pane

Unfortunately, the Finder is very wary of displaying previews for "unknown" files, even if they contain data that it understands. Unless the file has a known filename extension or classic Mac OS type and/or creator code, the Finder won't even try to display a preview for it. A more aggressive strategy would make the preview feature a lot more useful.

With the removal of pop-up tabbed folders and the sluggish performance of list-view Finder windows, the Finder browser window is one of the fastest way to jump around the file system, particularly in column view. Although it lacks the complexity of similar file browsers in other operating systems (the Windows Explorer, for example), its simplicity makes it more accessible to novice users.

Long-time Mac users with sophisticated work habits honed through years of classic Mac OS usage may not quite know what to do with the new browser interface, and their inability to duplicate their spatial environment in Mac OS X may cause them to curse the Finder's browser mode as the cause of their suffering. But as discussed earlier, it's not the existence of browser functionality that's the problem, it's the entanglement of the two modes and the lack of features in the spatial realm. The new browser is a welcome and useful addition to Mac OS. Apple just needs to cleanly separate it from the traditional Finder, and make sure the traditional Finder mode equals (or improves upon) the functionality of the classic Mac OS Finder.

Finder Miscellany

The contents of the Finder's menus are interesting. Most of the expected commands are there: duplicate, make alias, show original, clean up, etc. But there are some notable changes and additions. First, the additions.

The Finder's Go menu

The new "Go" menu provides shortcuts to many common locations, including your iDisk. The more general "Connect to Server..." item takes the place of the "Network Browser" and "Chooser" applications from classic Mac OS. Like most Mac OS X applications, the Finder has a "Window" menu that lists its open windows. The Finder's application menu houses the orphaned "Empty Trash" command now that the obscurely named (but alas, sentimentally traditional) 17 year old "Special" menu is gone. The other evicted tenants of the Special menu appear elsewhere: "Restart", "Shutdown", and "Sleep" are in the new Apple menu (more on it later), and "Clean Up" is in the "View" menu. The "Erase Disk" command has been removed entirely in favor of a separate Disk Utility application. Overall, the menu layout makes a lot more sense than it has for years.

As mentioned earlier, mounted volumes appear on the desktop by default, but are also accessible via the "Computer" file system abstraction visible in Finder windows. The much maligned (but again, traditional) act of dragging a disk icon to the trash to unmount and eject it remains in OS X, but with a new twist. As soon as you begin to drag a disk icon, the trash icon in the Dock changes to an "eject" symbol (shown right).

If you're going to keep this shortcut in the UI, this is a clever way to avoid ever having to tell a novice to "drag the disk to the trash." Instead, you can now say, "drag the disk to the eject symbol." Then they'll ask you what an "eject symbol" is and why its on the Dock, at which point you can break down and show them the more logical "Eject" menu item or context menu. Oh well, I still think it's a clever improvement.

The 10.0 release retains its ability to put a picture in the background of any Finder window. With some careful hacking of the Finder's resource files, it's even possible to enable a feature that allows icons of different sizes within the same window:

Icon size hacking in the Finder

The combination of these features could make for some very interesting and artistic window layouts. (Of course, your hard work arranging a window "just so" may be erased later by the fickle nature of the 10.0 Finder. Grrrr...)

The Finder now supports an "Undo" command that can reverse almost any single action, including moving, copying, or renaming a file or folder. (Emptying the trash is not undo-able, although dragging to the trash is.)

The "Get Info" menu command, now renamed "Show Info", brings up what looks like a traditional Finder information window, but there's one big difference: only one of these windows can be open at a time, and it reflects the currently selected item, not necessarily the one you requested information about. Experienced Mac users will likely find this behavior infuriating, since one of the main uses of the "Get Info" command in classic Mac OS is to compare two or more files or folders.

Aside from that one huge, glaring mis-feature, the information window functions well, provides some new features, and one welcome omission. The omission is the memory allocation settings present in classic Mac OS which are not needed in a modern virtual memory system. The additions are three new panes named "Application", "Application Files", and "Preview." Predictably, the Preview pane shows the same preview as the Finder's column view.

The Finder's "Show Info" window: "Application" pane

The Application pane (shown above) controls the application that will be used to open a particular document. Interestingly, changes to these settings do not change the file's classic Mac OS type or creator codes or the file name extension of the file (if any).

When an application is selected, the "Application Files" pane (shown below) allows easy graphical manipulation of bundle resources such as plug-ins and localization data.

Bundle manipulation in the Finder
(Note the Gopher plug-in. Omni rules :-)

Bundle resource manipulation can be done manually in the Finder via the "Show package contents" context menu (or via the command line, of course), but both of those methods are error-prone and somewhat complex. The "Show Info" window provides a much cleaner solution, and really shows off yet another one of the benefit of bundles.

The "Privileges" pane (not shown) remains essentially unchanged from classic Mac OS, with the interesting caveat that it's now twiddling Unix-style permission bits behind the scenes.

Finder preferences

The Finder preferences window might be better named "desktop preferences." Most notably, the desktop picture can be set here...and not via a context menu popped-up on the desktop itself. In fact, context menus are sorely lacking almost everywhere in the Finder, providing only the barest of functionality, and sometimes not even that. Rumor has it that the context menu APIs were not finalized in time for 10.0, and will be fleshed out, published, and leveraged much to the betterment of Mac users everywhere in a future Mac OS X releases.

The Mac OS X Finder supports "long" file names (255 characters max), but displays them in a frustrating manner. Names that are too long to fit in the allowed area are truncated in the middle rather than at the end. Take a look at the folder named "This Folder Has a Long Name" in the following screenshot:

Finder name truncation

In list and column view, at least there's the option of making the columns wider. (But note that the list view window is shown with the name column at its default, and in my opinion, much too narrow, width.) But in icon view, the user has no recourse. The Finder truncates names in icon view that are wider than about an inch and a half, regardless of how much room is around them (even in the extreme case). Even if Apple wants to avoid the (seemingly) obvious solution of wrapping long names into multiple lines, the Finder should at least increase the truncation threshold. Ideally, names in icon view would be aware of how much room they have on either side, and truncate themselves intelligently.

Although this partially falls under the category of performance, the Finder's usability is hampered by its poor responsiveness (scrolling, window resizing, etc.) and by its tendency to put up a "busy" cursor and become totally unresponsive during almost any network-related activity (mounting network disks, using the "Connect to Server" network browser, and so on) or any other long-running task besides moving and copying files. In many respects, the Mac OS X Finder displays multitasking abilities that are inferior to the Mac OS 9 Finder.

Finally, missing features abound. I've already mentioned the incomplete context menu support. Finder labels, a feature used and loved by many classic Mac OS users who have a lot of files and folders to organize, have also missed the 10.0 release. The insanely wide (and non-adjustable) icon snap-to grid can no longer be toggled via a command-drag operation, making the often misbehaving "Clean Up" menu item the only option, even if you only need to align a single icon. Typing a file's name in list view no longer scrolls the window to show the selection. The default "Empty Trash" warning can no longer be toggled on a global basis. And, of course, pop-up tabbed folders are completely gone, and are not adequately replaced by any of the Dock's functionality.

Finder Summary

The Mac OS X Finder needs a lot of work before it can fill the shoes of its predecessor. The addition of many useful and powerful features to the Mac OS experience (column view, browser mode, the toolbar, bundle manipulation, file mapping, and built-in network integration) does not outweigh the significant problems. Missing features, mis-features, and bugs render the new Finder unable to reproduce the spatial file manipulation environment that has been the defining characteristic of the Macintosh experience since 1984.

To add insult to injury, troubling performance and multitasking lapses handicap even the better parts of the application. Clearly, there is tremendous room for improvement in this most important application. And thankfully, the independence of the OS X Finder makes it eminently more changeable than its heavily integrated classic Mac OS forbearer. Let's just hope that one day the Mac OS X Finder will live up to its namesake.

Open/Save Dialog Boxes

Open/save dialogs in Mac OS X are implemented as sheets, those clever translucent panes that spring from document window title bars and remain attached, reminding the user which dialog goes with which document no matter how long it's been awaiting user input. The dialog has two forms: compact and expanded. The compact form looks like this:

Open/save dialog box: compact mode

It's as simple as can be: enter a file name and then pick a destination from a pop-up menu. The menu contains common locations like the user's home directory, documents folder, iDisk, the user's "favorite" destinations, and a list of recently used folders and disks. For novice users, this simple dialog will suffice in almost every situation.

For users with more sophisticated organizational requirements, the small downward-facing triangle widget next to the pop-up menu expands the dialog to look like this:

Open/save dialog box: expanded mode

Note that the expanded version is really a superset of the compact version. The dialog merely grows taller (in real-time, of course), inserting a miniature Finder-like column view between the pop-up menu and the Save/Cancel buttons. Buttons for creating new folders and for adding an existing item to the user's list of favorite places are also added. The dialog is also resizable.

Much of the benefit or annoyance of these dialogs is at the discretion of the application. Good applications remember the previous state of these dialogs. So if you always use the expanded version, you don't have to keep expanding it every time you save a file. Likewise, the location that was last used to save in a particular application should be remembered and reused. Applications that do all of this are much more pleasant to use.

Applications that don't behave in this way are extremely frustrating to use, especially if you want to use the expanded form all the time. Each open/save operation expands to become an unnecessarily long sequence of clicks and keystrokes as you repeatedly navigate to your desired destination--even if that destination is the same as the one you just saved to or opened from a few seconds ago.

In truth, classic Mac OS has the same limitations. But the maturity of most classic Mac OS applications means that you're more likely to have a pleasant experience there. Many OS X applications do not yet exhibit all the nice state-preserving behavior that most Mac users expect. This is not the fault of the OS, of course, but it still affects the user experience at this stage in OS X's development.

File Name Extensions

As discussed at length in the Mac OS X Q&A article, Mac OS X uses a sophisticated discovery procedure to determine file types. Unfortunately (or perhaps fortunately, depending on your point of view), one of the not only supported, but recommended techniques for file type identification is the use of file name extensions.

Almost all of the bundled applications in OS X save files with file name extensions, and often without classic Mac OS type/creator codes. This is a significant user experience change for Mac users. All file name extensions (except the ".app" added to application bundles) are visible in the GUI, but they're often hidden in open/save dialog boxes. Saving a file as "My Resume" in TextEdit, for example, actually creates a file called "My Resume.rtf" (or "My Resume.txt", depending on the selected format). This disconnection between user input and application action is a new (and in my opinion, unwelcome) addition to the Mac user experience.

Nevertheless, the dawn of the Internet and the lowest common denominator of simple, one-dimensional file streams that it has spread across all of computing, even to areas that the dominance of Windows had not yet reached, makes support for "meta-data through file name mutilation" a necessary evil. I just wish more OS X applications also supported traditional Mac OS standards alongside the required interoperability features by always adding type/creator codes when saving to volume formats that support these features.

Window Layering and Manipulation

Window layering in Mac OS X is done on a per-window basis, unlike classic Mac OS where windows are layered in groups based on the parent application. For example, clicking on an IE browser window in classic Mac OS brings all of IE's open windows to the front (preserving their layering relative to each other, however). In OS X, clicking on one of IE 5.1's windows merely brings the selected window forward. (As expected, Classic applications continue to use a per-application layering policy.)

The new window layering system has definite advantages in situations where two applications have many overlapping windows open, but you are only interested in one from each application. In OS X, you can simply bring forward the two windows you're interested without worrying about all the other windows in each application getting in the way.

In practice, it's not that simple. The applications' "Window" menus (or pop-up lists of windows from their Dock icons) are usually necessary to get at the windows you're looking for in the situation described above. Selecting windows from menus and lists is another departure from spatial manipulation, but is necessary when space is limited and windows are numerous.

Per-application window layer does have significant advantages in a number of situations. It essentially offers a two-dimensional hierarchy within which to manage windows, rather than the linear list presented by the per-window layering model. What this means is that any visible portion of any window belonging to an application can be used to reduce the possible window choices dramatically by bringing all the windows associated with that application to the front.

This is most often used in the classic Mac OS Finder, where clicking anywhere on the desktop (a piece of which is almost always visible) brings all Finder windows forward. In OS X, this maneuver degenerates to:

1. Click on the desktop.
2. Realize that no Finder windows have become visible.
3. Consult the Finder's Window menu (in the menu bar or Dock) and try to find your window by title.
4. Repeat for any other Finder windows you're interested in.

Thankfully, this effect is mitigated somewhat by the Dock's functionality. Clicking on an application's icon in the Dock brings all of its windows forward. (Unfortunately, in the case of the Finder, it will also spawn a new browser-style Finder window if the Finder happens to be the front-most application at the time.) Many third-party Dock replacement/augmentation applications also mirror this behavior.

Still, it would be nice if the window layering policy were adjustable via a preference panel, with a behavior toggle activated by a modifier key. I'm personally much more productive with per-application window layering, and would be completely willing to command-click to get per-window layering in the rare cases that I need it.

Window minimization via the famous (or possibly infamous) genie effect is a useful mechanism, despite the performance issues caused by the eye candy. (And note that the slow-motion effect used in many of the OS X demonstrations at Macworld Expo remains in the 10.0 release: just shift-click on the minimization widget.) There are even two additional minimization transformation effects available via some XML hacking: "scale", which proportionally shrinks the window into its Dock icon, and "suck", which looks like an asymmetrical distortion caused by a vacuum force in the Dock.

In-place window minimization via classic Mac OS's window shade feature is sorely missed by those who used it. Displaced minimization like the genie effect solves a different problem. The ability to "peek behind" windows or quickly hide many windows while maintaining some marker for their on-screen size and position is incredibly useful and should be added to (or more cynically, "put back into") Mac OS X. This is a golden shareware opportunity.

The New Apple Menu

The new Apple menu has a completely different role than its classic Mac OS counterpart. As discussed in the MWSF article, the contents of the Apple menu are fixed. They are, to quote Apple's own documentation, "defined by the system and cannot be modified by users or developers." The new Apple menu is a "system menu" rather than a user-customizable all-purpose launcher. It provides a universally accessible home for system-wide functions like sleep, restart, shutdown, as well as a handy menu of recently used applications and documents:

The new Apple menu

More puzzlingly, it contains shortcuts to a few selected applications like System Preferences, Location Manager, and the Dock. The Dock menu item even has a sub-menu for direct manipulation of a few options. The question is, why these items? What if I never change my location, but frequently toggle file sharing? If any application and settings shortcuts are going to appear in the Apple menu, why should users be confined to Apple's best guess at their needs? Like the OS X toolbar widget, the Apple Menu should be user-customizable.

User Interface Summary

Despite the official release status of 10.0, The Mac OS X user interface is still clearly a work in progress. The biggest lapses are the system-wide interface responsiveness issues and the hobbled Finder. The Dock is a close third, presenting a sort of UI logic puzzle in which optimizing its usage for one of its functions (application switching, launching, Apple menu replacement, Control Strip functionality, etc.) causes it to become sub-optimal for one or more of its other functions. Thankfully, third party utilities are quickly arriving on the scene to help experienced users create the environment they need to be productive.

Overall, the user experience of OS X is not as pleasant or as simple as that of classic Mac OS. The number and severity of bugs alone would likely turn a novice off, especially those surrounding the still-necessary classic environment. Novice users shouldn't have to know or care what classic is, why it's frozen, and how to recover. And much of the time, the provided GUI methods (force quit, etc.) don't work as expected anyway, leaving a trip to the command line and the kill command as the only alternative.

The unresponsive interface will be noticed by everyone. Many features are slow enough that even plodding grandmothers will be confused by the apparent lack of response to their input (when resizing a list-view window, for example). And there's still the "why can't I do anything now?" experience, especially in the Finder during network-related operations. Grandma doesn't care that she can still switch to another application and continue working if the next thing she needs to do is in the Finder, which is currently locking her out because she chose to mount her iDisk.

As in every one of the previous OS X releases, the score-card remains the same. Even taking into account the increased stability and superior multitasking potential, Mac OS X does not yet live up to the level of user interface excellence set by the technically inferior Mac OS 9.

Classic

The classic environment is controlled via a system preference panel that offers almost every useful option imaginable. Most notable is the explicit "Force Quit" option, another acknowledgement by Apple of the rough edges in 10.0. It sits there telling you that, yes, classic will hang on you from time to time.

Classic is Mac OS 9.1 running inside Mac OS X. The only caveats are that it takes up slightly less RAM than actually booting the machine into Mac OS 9.1, and applications running under it incur a small (approximately 1% to 10%) but noticeable performance hit due to the shims and trickery needed to make Mac OS 9.1 forget that its actually running inside another application. Other than that, it's exactly what you'd expect from Mac OS 9.1.

Classic preference panel (Click to see the "Advanced" tab)

Well, ideally it's exactly what you'd expect. What you'll find is that its prone to freezing and crashing (sending you running to that handy "Force Quit" button) unless you are very careful about what extensions you load (thus the "modifier key on startup" option). Then there's the aforementioned possibility that classic will not only hang, but that it'll hang in such a way that you cannot start it again successfully without rebooting the machine. Not fun, especially considering the current dearth of native OS X applications.

In practice, a happy medium can be found if you run a well-known (and stable) set of extensions and applications in classic. I've also found that it helps to shut down classic at the end of each day rather than allowing it to sit idle over night, but your mileage may vary.

Integration with the rest of Mac OS X is impressive, given the technical hurdles. Drag and drop between OS X and classic applications usually works as expected, as does copy and paste (with a slight delay for clipboard synchronization--a known bug). Many classic applications even go to the correct (user-specific) desktop via command-d in open/save dialogs. Given the incredibly buggy and decidedly non-integrated state of classic in many of the development releases, the integration of the 10.0 incarnation is a pleasant surprise.

Cosmetic issues abound. Classic is not double-buffered like native OS X applications, and it shows. Dragging an OS X window around in front of a classic application's window results in the dreaded "giant eraser" effect as the OS X window invalidates (and subsequently erases) huge swaths of the classic application's windows. They're quickly redrawn, but not quickly enough to remove the incredibly ugly effect. It's a far cry from the behavior of native OS X applications, where the windows behind the one you're moving are magically "just there" with absolutely no visible redraw.

Transparency also doesn't work when displayed on top of classic applications. This includes menus, the Dock, and anything else non-opaque that can potentially be displayed on top of a classic application's window. Given the "direct draw" nature of classic QuickDraw and the layered compositing model of Quartz, this type of problem strikes me as a tough nut to crack...especially if classic is to maintain its responsive (relative to Quartz) performance.

Classic's subjective interface performance seems at first to be faster than "native" Mac OS 9.1. In reality, it is slightly slower on the redraw in almost every respect. Operating side-by-side with the OS X Aqua interface makes it seem much faster than it really is. Compared to OS X native applications, classic windows scroll and resize more responsively, menus pop down instantly, and QuickTime performance is often actually better in the classic environment than in OS X native applications on my G3/400: the audio stays in sync better and the framerate is comparable.

In many respects, it will be nice to see the need for classic disappear as new OS X native applications arrive. RAM usage for a typical daily work load will decrease dramatically, and the removal of the deep hooks into OS X that classic requires to do its job will free up those resources for more productive processes like video and audio playback, both of which I've found to be most susceptible to interruption when classic is running. On the other hand, unless OS X itself (or the hardware it's running on) has improved tremendously from its 10.0 state, the disappearance of classic may mean the disappearance of a truly responsive UI.

File System Layout

The GUI view of the file system in Mac OS X is refreshingly simple. The "computer" toolbar button takes you to the conceptual root where all mounted volumes are displayed, plus a network access point for remote files, folders, and volumes.

The boot volume shows seven standard folders:

• Applications - The default system-wide location for applications.
• Applications (Mac OS 9) - The default system-wide location for Mac OS 9 applications (possibly moved to this location during the install process).
• Developer - Developer tools, libraries, and documentation installed by the Developer Tools CD.
• Library - Local resources that are not part of the core OS: browser plug-ins, desktop pictures, shared libraries used by third party applications, etc.
• System - The core Mac OS X operating system.
• System Folder - The Mac OS 9 operating system.
• Users - Local user home directories.

Many of these directories also appear under "Network", meaning that these resources do not necessarily have to be on the local machine. Network applications, users, and libraries are all possible via any of Mac OS X's supported networking protocols.

The most structured branches of the file system are the "Library" and "System" folders. (And actually, the only thing in the Mac OS X "System" folder is another "Library" folder.) The structure of these folders is heavily subdivided, but still understandable. Some examples of sub-folder names include "Fonts", "Printers", "Sounds", "StartupItems", "Perl", "Filesystems", and "Speech." Even the most obscure still give some hint of their purpose: "CFMSupport", "CoreServices", "DTDs". At the leaf nodes of these structured directories are the clever versioned bundles that have been discussed at length in earlier Mac OS X articles (see the relevant sections of the DP3 and DP4 reviews).

The Applications folder is at the user's disposal. It may be subdivided as desired. The Mac OS 9 System Folder and Applications folder, of course, follow all the typical rules (or lack thereof) of a traditional Mac OS 9 system.

The "Users" folder is subdivided by "short" username (e.g. "john" rather than "John Siracusa"). A user's home directory starts off looking like this (icons set to their maximum size because, well, they're pretty :-)

The first thing you'll notice is that every one of the "standard" folders has a custom icon--a tacit acknowledgement of the difficulty of distinguishing folders in the Dock without text labels. Again we see a "Library" directory, subdivided heavily like all other Library directories. The "Public" and "Sites" folders are read-only accessible to all other users on the system. The other folders are self-explanatory categorized storage locations (Music, Movies, etc.) and are the private domain of the particular user (unless he choses to modify the folder permissions, of course).

The "Desktop" folder is by far the most interesting item. It's a regular folder that contains the items that appear on the desktop--with the exception of the mounted volumes, which appear in the conceptual root in the GUI. Each user has his own desktop.

In the classic Mac OS world, the desktop is the root of the file system: there is nothing above the desktop, and you can get to any part of the system from there. In Mac OS X, the desktop is reduced to a container for the files that appear on the Finder desktop. In Mac OS X, there essentially is nothing below the desktop (except files and folders you place there explicitly). The drives, the network, and everything else is rooted farther up in the file system.

This change was necessary to emphasize the multi-user nature of Mac OS X. The user's home directory is his private playground, while the rest of the system should be respected as a common area. As a per-user resource, it makes sense for the desktop to be a visible entity in the user's home directory (as opposed to being buried in the user's Library folder as it was in earlier releases of OS X). Likewise, disks are a shared resource and are therefore more logically placed at the top of the file system.

File System Layout Summary

The new layout is definitely a break with the past, but it's necessary in the new world of multiple users. In its default configuration, Mac OS X does its best to appear as a single user OS, automatically logging the user in and presenting what appears to be full control (with the occasional authentication using the user's own password, not a separate easy-to-forget "administrator" password). There are more directories with well-defined structures than in classic Mac OS, where the System Folder was basically the only area that cared about such things. But the areas most likely to be modified by users (documents, applications, the desktop, etc.) are surprisingly flexible, especially given the Unix roots of the OS.

Speaking of which...

Unix: The Man Behind the Curtain...and More

The OS X GUI provides a reasonably Mac-like view of what is essentially a Unix-based operating system. But the view from Mac OS X's open source core, Darwin, is very different. Drop into a shell via the bundled Terminal application (or telnet over from elsewhere) and the truth is revealed. Take a look at the real root of the file system:

-rw-rw-rw-   1 john  admin     12316 Mar 29 22:52 .DS_Store
d-wx-wx-wx   2 root  admin       264 Mar 24 13:03 .Trashes/
-r--r--r--   1 root  wheel       146 Mar 28 20:15 .hidden
dr--r--r--   2 root  wheel       128 Mar 29 18:46 .vol/
drwxrwxr-x  29 root  admin       942 Mar 26 21:34 Applications/
drwxrwxrwx  16 root  wheel       500 Mar 24 14:00 Applications (Mac OS 9)/
drwxr-xr-x   2 john  admin       264 Mar 24 22:52 Cleanup At Startup/
-rwxrwxrwx   1 root  wheel    204800 Mar 27 18:17 Desktop DB*
-rwxrwxrwx   1 root  wheel   1833490 Mar 27 01:11 Desktop DF*
drwxrwxrwx   2 root  staff       264 Mar 25 14:07 Desktop Folder/
drwxrwxr-x  13 root  admin       398 Mar 24 20:50 Developer/
drwxr-xr-x   3 john  admin       264 Mar 29 20:02 Documents/
-rwxrwxrwx   1 root  wheel         0 Mar 24 12:30 Icon?*
drwxrwxr-x  22 root  admin       704 Mar 24 23:36 Library/
drwxr-xr-x   6 root  wheel       264 Mar 24 13:13 Network/
-rw-r--r--   1 john  admin         0 Mar 26 21:38 Shutdown Check
drwxr-xr-x   3 root  wheel       264 Mar  1 20:14 System/
drwxrwxrwx  41 root  wheel      1350 Mar 25 20:21 System Folder/
drwxrwxrwx   2 root  wheel       264 Mar 25 14:00 TheFindByContentFolder/
drwxrwxrwx   4 root  wheel       264 Mar 24 13:17 TheVolumeSettingsFolder/
drwxrwxrwx   2 root  wheel       264 Mar 29 18:34 Trash/
drwxr-xr-x   4 root  wheel        92 Mar 24 13:07 Users/
drwxrwxrwt   3 root  wheel       264 Mar 29 18:47 Volumes/
drwxr-xr-x  33 root  wheel      1078 Mar  1 21:03 bin/
lrwxrwxr-t   1 root  admin        13 Mar 29 20:02 cores@ -> private/cores
dr-xr-xr-x   2 root  wheel       512 Mar 29 18:46 dev/
lrwxrwxr-t   1 root  admin        11 Mar 29 20:02 etc@ -> private/etc
lrwxrwxr-t   1 root  admin         9 Mar 29 20:02 mach@ -> /mach.sym
-r--r--r--   1 root  admin    652056 Mar 29 18:46 mach.sym
-rw-r--r--   1 root  wheel   4039448 Mar  1 09:58 mach_kernel
drwxr-xr-x   7 root  wheel       264 Mar 29 18:47 private/
drwxr-xr-x  56 root  wheel      1860 Mar  1 21:01 sbin/
lrwxrwxr-t   1 root  admin        11 Mar 29 20:02 tmp@ -> private/tmp
drwxr-xr-x  10 root  wheel       296 Mar  1 20:15 usr/
lrwxrwxr-t   1 root  admin        11 Mar 29 20:02 var@ -> private/var

Your reaction to this listing will quickly categorize you as a user. If you are appalled, confused, or frightened, you're in the majority. Most Mac users should never need to know or care about the seedy underbelly of Unix in Mac OS X. But if your reaction is a comforted sigh, You Might Be a Unix Geek. "Ahhhh...I'm home."

Lets take a look at some of the tricks used to keep all this complexity away from the average user. Hiding files and directories from is the most common technique. Almost everything in the / listing above does not appear in the Finder or other GUI navigation interfaces such as open/save dialog boxes. Items may be hidden in at least four basic ways.

First, on HFS+ volumes, the "invisible" bit can be flipped. Classic Mac OS uses this same bit to hide its administrative files (e.g. the "Desktop DB" and "Desktop DF" database files shown above, which are actually part of the Mac OS 9.1 installation, not Mac OS X). The second technique is to put a period "." at the start of the file or folder name. This is the Unix convention for hidden files, and (by default) the Finder honors it as well. The third method leverages the second. If a file named ".hidden" exists in a directory, the items listed in the (plain text) file are hidden in the Finder. Fourth, the Finder itself may choose to hide or "move" resources in order to maintain the preferred abstraction. Disks are mounted under /Volumes, for example, while the boot volume is mounted at /. But the Finder shows them all along side each other in its conceptual root.

Mac OS X's use of BSD policies and mechanisms to implement its security model means that there is a pleasant congruence between the command line and GUI environments. Finder permissions are merely a reflection of BSD permissions, and vice-versa. Even the BSD-style extended attributes (man chflags) are leveraged to implement some classic Mac OS concepts like file locking. And for even more traditional so-called "Finder flags", the Developer Tools CD includes many useful command-line utilities for adjusting them (man SetFile)

Even resource forks are dutifully represented and manipulable via the command line. Developer tools like Rez, Derez, SplitForks, and CpMac handle file manipulation that used to be the exclusive realm of GUI applications. There's even an extremely clever implementation of resource forks that can be used by the plain vanilla Unix command line utilities: any file's resource fork may be accessed by appending /rsrc to the file name. This feature comes in handy when editing the new-style OS X resource files: files with resource data stored in their data fork instead of in their resource fork.

Since venerable Mac resource editing utilities like ResEdit can only work with resources that are actually stored in the resource fork, the following maneuver allows the new-style resource file "Localized.rsrc" to be (indirectly) edited by ResEdit:

% touch temp
% cp Localized.rsrc temp/rsrc
(Open "temp" in ResEdit, make changes, and save)
% cp temp/rsrc Localized.rsrc

To go one step further, even the parenthetical step of editing the file in ResEdit can be initiate from the command line via the handy open command:

% open /Path/To/ResEdit somefile

With some judicious aliasing, the following interactions are possible:

...
% CpMac Anarchie .
% resedit Anarchie
...
% cp ../httpd.conf .
% bbedit httpd.conf
...

And so on: a clever and powerful mix of standard Unix commands and traditional Mac GUI applications. Moreover, modifications made via the command line are immediately reflected in the GUI, and vice versa.

The Unix world of Darwin is not just an unrelated Mr. Hyde to the Aqua GUI's Dr. Jeckle. Even such seemingly Mac-like operations as installing software using Apple's bundled installer application end up using Unix behind the scenes (e.g. pre- and post-install scripts written in Perl). It's a very happy marriage of Mac and Unix.

Mac OS X as "Just Another Unix"

Let's try to forget for a moment that this is a new release of the Macintosh operating system, and pretend instead that it's merely a new and interesting flavor of Unix. Is that even possible? For the most part, yes, it is. If you are so inclined, you can, treat Mac OS X like a plain-old Unix box. But there's a catch: as with all new flavors of Unix, it will take a while for Darwin's "fingerprint" to spread throughout the huge library of Unix software.

Think of the early days of Linux. Downloading a popular Unix program and trying to compile it in Linux was fraught with the possibility for errors and conflicts: files located in different places, different flags for commands, library compatibility issues, and so on. Fast-forward to today and you'll be hard-pressed to find a source code distribution without one (or more) pre-defined configuration/Makefile settings for Linux.

As of OS X 10.0, many of the most popular Unix applications already correctly detect and configure themselves for compilation in Darwin (e.g. Apache, MySQL). Others are included by default (Perl, TCL, PHP). Still others are basic enough to compile successfully with the mere hint that Darwin is a "BSD-ish" system (GNU textutils, ncftp, expat).

It will take a long time before the entire world of Unix software opens up to Mac users. But 10.0 has gotten off to a very auspicious start. With minimal hacking, I was able to update the default perl installation with a huge collection of CPAN modules (many with compiled C components), compile the latest version of apache in both plain and mod_perl variants, compile and install SSH2, many popular GNU utilities, and generally make myself at home in the world of Unix.

Unix Future

Ironically, Mac OS X's Unix foundation is perhaps the most important part of Apple's new OS in terms of expanding market share. Apple has always targeted the home and professional graphics markets, but has never had a (well supported) compelling offering in the many varied markets where Unix is dominant. This is not to say that OS X will suddenly supplant Solaris and Linux, because it won't. But it certainly opens doors that were once entirely closed to classic Mac OS, particularly in academia and the scientific community where Macs have fallen out of favor due to (standard Unix) software availability and interoperability issues.

The second big win for OS X's Darwin core is the possibility of clean expansion in the future. Unlike the essentially monolithic and heavily entangled core of classic Mac OS, OS X's Unix foundation can be extended relatively cleanly. Unix's journey from its 1970s roots to its current state is a testament to this ability.

Thanks to the eminently portable nature of the core OS (NEXTSTEP ran on 68K and x86 processors, and Unix has been ported, well, everywhere), the possibility of changing CPU architectures down the road (when classic has been mercifully retired) is not as daunting as the 68K/PowerPC transition.

Finally, the open source nature of Darwin means that core OS developments are no longer entirely reliant on Apple. Already, in the 10.0 release, a lot of the code that ships on those CDs was contributed by volunteers rather than Apple employees--particularly bug fixes required to support obscure configurations. This process continues as we speak, making for a better core OS than Apple could produce on its own: open source software development in action. All told, the future looks extremely bright for Apple's new Unix-based baby.

Bundled Applications

OS X ships with a fairrly complete collection of applications, provided that using Internet is your primary computing activity. It ships with a capable web browser (IE 5.1 preview release), an email application that supports multiple POP or IMAP accounts, a telnet client (accessed via the Terminal), and integrated support for Apple's iTools.

As a port of the classic Mac OS version of IE, the web browser is the most full-featured bundled application. Unfortunately, persistent performance and multitasking issues dog this preview release. Most OS X users have downloaded at least one alternative browser, most commonly the (also unfinished, but still impressive) OmniWeb. OmniWeb is a veritable poster child for Mac OS X technologies and interface elements such as drawers, configurable toolbars, system-wide services for typography, spell checking, and so on. The fact that this impressive application was created by such a small team of programmers at Omni is a testament to the powerful application development tools and libraries supported by OS X. It's still a work in progress, however, which is why, as mentioned earlier, I've personally fallen back to using classic IE5 which currently outperforms the OS X port of IE, and is more stable and feature-rich than OmniWeb.

Despite the expected crop of bugs, Apple's simply-named Mail applications is the most impressive bundled Internet tool. Like OmniWeb, it's a showcase of new OS X technologies. It's no threat to larger email applications like Microsoft's Entourage (soon to be ported to OS X with the rest of MS Office, but currently quite usable in classic) whose integrated calender, contact management, Palm synchronization, and other features put them in a different league. But it is more than adequate for a bundled email application. I threw more than 5,000 email messages at it via my various POP and IMAP accounts, and it hasn't flinched yet.

When discussing OS X native applications, the issue of APIs inevitably comes up, particularly the distinction between Carbon and Cocoa applications. As you'll recall from earlier articles, Carbon is a cleaned-up version of the classic Mac OS API that run natively (i.e. without the help of the classic environment) in OS X. Cocoa is the latest incarnation of the object-oriented OpenStep framework inherited from NeXT.

The general consensus is that Cocoa applications are superior to Carbon applications in terms of support for OS X features, multitasking ability, and interface responsiveness. Whether this is due to any inherent superiority of the technologies in Cocoa or is merely a byproduct of the immaturity of the Carbon impelmentation (as compared to Cocoa/OpenStep which has been around for years) is still open for debate. But subjectively, I have to agree. The Cocoa applications I've used in OS X are definitely nicer. Some examples of Cocoa applications are Mail, OmniWeb, and Terminal. The most prominent black marks on the good name of Carbon are the Finder and the IE 5.1 preview. Time will tell if the API playing field is leveled by further development of Carbon.

One final note on bundled applications: the OS X screensaver preference panel is pretty neat. It uses (bundle-based, of course) plug-in modules and has already been extended with a set of ubiquitous OpenGL screensavers. But the highlights are the simple, but strangely attractive "Slide Show" and "Aqua Icons" modules.

Slide Show simply cycles through a folder full of images, but with a twist. Each image is slowly magnified or reduced, and image changes are done via a super-smooth cross-fade. The high-quality photographs Apple bundles with OS X add to the attraction. Set the slide show to the "Beach" theme and just drift away...

The Aqua Icons module also makes use of attractive fade-ins to display a sea of icons harvested from your own hard disk flying out from the murky depths of the screen. (Keep your eye out for the very rare spinning icons :-)

Exercise: compare the Aqua Icons screen saver to the traditional "flying Windows Logo" screensaver that Microsoft ships. That's the difference between Apple and Microsoft in a nutshell.

A Brief Digression: Build Numbers

Following the Public beta release, a series of widely leaked Mac OS X builds were created, each labeled with an alphanumeric tag like "4K50" or "4K70". Since these builds were so easy to find on the net, the most enthusiastic Mac users were downloading and installing each new build as they eagerly awaited the final release.

Build 4K78 began to circulate in mid-March, and like all previous builds, it was considered a work in progress by Mac fans. But as Mac OS X's release date crept closer, and no new (legitimate) builds appeared on the net, worry set in. When Mac OS X shipped with the 4K78 build number displayed in the "About this Mac" dialog box, speculation was rampant: was Mac OS 10.0 really the same as the 4K78 build that had been all over the net for weeks? Or was it 4K78, but recompiled without debugging code? Or would 10.0 be an entirely different "surprise" build that no one outside of Apple had seen before?

As it turns out, the retail version of Mac OS X is indeed exactly the same as the 4K78 build that shipped to developers in early March, and was later widely distributed on the net. File for file, byte for byte, bit for individual bit, they're the same. For folks who were expecting a Jobs-style surprise or, at the very least, the removal of the now-infamous "debug code" that was theorized to be slowing down the 4Kxx builds, sorry. You'll just have to wait for 10.1, I guess.