Mac OS X 10.1 (original) (raw)

Prelude The introduction of Mac OS X on March 24th, 2001 was the fulfillment of a promise made over a decade earlier—a promise to Mac users that they would get a brand new operating system, and that it would be insanely great. The mere existence of an actual shipping product let millions of Mac users … Continued

Prelude

The introduction of Mac OS X on March 24th, 2001 was the fulfillment of a promise made over a decade earlier—a promise to Mac users that they would get a brand new operating system, and that it would be insanely great.

The mere existence of an actual shipping product let millions of Mac users breathe a sigh of relief. But when the dust settled, the software itself appeared less than great in many areas, and seemingly insane in others. The honeymoon was over before it even began.

My personal experience with Mac OS X has been rocky. I installed Mac OS X on my Mac at work, a dual G4 450MHz with 256MB RAM, as soon as version 10.0 shipped. But on my home machine, a blue and white G3 400MHz, I stuck with Mac OS 9. I did this for several reasons.

First, not all of my hardware was supported in Mac OS X, including (most importantly) my printer. Second, many of the applications I use every day did not have native OS X versions. Third, and perhaps most troublingly, I still felt a lot more productive and happy in the Mac OS 9 user interface. This was partially due to the sluggish performance of the OS X interface on my G3/400 (a problem in its own right), but it was also because I could not set up the OS X user interface to suit my needs the way Mac OS 9 did.

So that's how I've lived for the past six months: spending 40 hours a week using Mac OS X, following it through four updates to version 10.0.4, and then coming home to my Mac OS 9 system. Coming home to Mac OS 9 often felt like coming back to an old friend. My G3/400 felt like a speed deamon, as I scrolled through my email messages, pulled down menus, and launched applications at speeds that made my "faster" dual G4/450 at work seem positively moribund.

On the other hand, the uptime on my Mac at work, which I left on 24 hours a day, was roughly equivalent to the the time between OS updates from Apple (excluding hardware upgrades). I had a total of five system crashes (all of them user interface deaths; no kernel panics), most of them in version 10.0 through 10.0.2.

And so the platforms dueled: stability vs. ease of use; a pretty interface vs. a responsive one; a full suite of Unix tools and services vs. good hardware support and a wide selection of applications. For the most part, things came down on the side of Mac OS 9 for me. Despite the particular features that made it a good fit for my work environment, Mac OS X was still too slow, too awkward, too resource intensive, and too "unfinished" for me to accept as my "new Mac OS."

Many Mac users felt the same way. Some didn't even want to think about Mac OS X until some point in the future--after they'd purchased new hardware, or when the OS matured some more. While the early adopters frolicked, and the part-time geeks experimented with occasional trips into the world of Aqua, the rest of the Mac community waited.

Despite spending five days a week using OS X, I felt like I was waiting with them. Many of OS X's problems were acknowledged by Apple, but some were not. On Apple-run mailing lists, signals crossed and tempers flared on issues ranging from the Dock to the color, shape, and position of the window widgets. Confusion and uncertainty reigned.

But Mac users are nothing if not patient. For the faithful, hope springs eternal in the skies above Cupertino. Mac OS X 10.0.x was not the OS I had hoped it would be, and yet I can see the end of the road for classic Mac OS fast approaching. I want to like Mac OS X. I want to love it. I want it to sweep away any memory of classic Mac OS.

Like Mac users everywhere, I want to believe.

Illustration: John McCoy

Introduction

Mac OS X 10.1 was released on September 29th, 2001, but that date depends on your definition of "released." Update CDs were handed out for free after Apple's keynote speech at the Seybold publishing conference in San Francisco. People who did not attend Seybold have several ways to get the update. Starting on the 25th, free update CDs are being handed out at Apple stores and some other retail outlets. This free update does not include the developer tools, but those can be downloaded by all ADC online members (free registration required) from Apple's web site. Finally, owners of Mac OS X 10.0 can order a full update containing a Mac OS 9.2.1 CD, a Mac OS X 10.1 update CD, and a developer tools CD through Apple's Mac OS X Up-to-Date program at a cost of $19.95 (plus state tax). The 10.1 update is not available for free download.

So, like I said, "released on September 29th," right? Nothing's ever simple with Apple these days, it seems. Nevertheless, you can be sure that the 10.1 update, repeatedly called "a free update" by Apple, is finding its way into the hands of Mac OS X users everywhere, despite the distribution and pricing confusion.

Mac OS X 10.1 is the first major revision of Mac OS X, Apple's new operating system. Ars Technica has been following Mac OS X since the second developer release in 1999, and this is my tenth (ha!) article in the series. The previous articles are listed below in reverse-chronological order, with the major public releases in bold.

• Metadata, The Mac, and You 8/20/2001
• Mac OS X 10.0 4/02/2001
• 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

The earlier articles contain basic information that will not be repeated in this article (such as the correct pronunciation of "Mac OS X" ;-) This article will concentrate on the changes between version 10.0 and 10.1.

Steve Jobs has described the migration from classic Mac OS to Mac OS X in terms of a clock face. He's called it a 12 month transition, starting with the release of Mac OS X 10.0 six months ago, with each hour on the clock face representing one month. Mac OS X 10.1 marks the half-way point, "six o'clock", in the transition. While version 10.0 was acknowledged by Apple to be an "early adopter's release," version 10.1 is aimed at a larger market. "This is the mainstream release," says Jobs.

There were four minor updates between 10.0 and 10.1. Versions 10.0.1 through 10.0.4 were distributed through Apple's Internet software update mechanism, and through free downloads from Apple's web site. Between 10.0 and 10.0.4, many bugs were squashed, hardware support was increased, and a few minor features were added. But many of the most critical problems in the 10.0 release were not addressed—performance being the most glaring, with user interface a close second for many people.

The word of mouth in the community regarding 10.1 has focused heavily on performance, so much so that casual observers may think that's all there is to 10.1. But there is at least one change in 10.1 that may be even more significant than the performance increase, as we'll see a bit later.

The test systems for this review were the same as those used in many of the earlier articles (more detailed descriptions were requested by readers):

• G3/400: A revision 1 blue and white Power Mac G3 400MHz with 384MB RAM; an IBM 12GB 5,400 RPM HD on the motherboard's ATA/33 bus; an Ultra SCSI PCI card with a 100MB Zip, an old 1GB HD, and a Plextor CD-RW attached; an ATA/66 PCI card with an IBM 45GB 7,200 RPM HD attached; and a 17-inch Apple Studio Display CRT.
• Dual G4/450: A Power Mac G4 with dual 450MHz CPUs, 768MB RAM, a Quantum FireBall LM 30GB 7,200 RPM HD on the motherboard's ATA/66 bus, a DVD-ROM drive, and an NEC AccuSync 120 21-inch CRT.

As in the past, the G3/400 was used for the more rigorous benchmarking tasks, and the dual G4/450 was mostly used for subjective performance observations and comparisons. (Faithful readers may notice that both systems got a significant RAM upgrade since the 10.0 review; more on that later.)

Here we go again...

Installation

The 10.1 installer looks and behaves almost exactly like the 10.0 installer. The differences are mainly in the choices and sizes of the installed components. The component selection for both a clean install and an upgrade to 10.1 are shown below (required components are in bold):

(Yes, I know the columns don't add up to the totals listed, but I'm just going by what the installer application displayed. Maybe it knows something I don't.)

I chose the "upgrade" installation, installing on top of 10.0.4 on both the G3/400 (on the 12GB drive) and dual G4/450. I chose not to install the foreign language kits, leaving the total tonnage of changed bits at 254,792K, according to my calculations—which may or may not agree with the installer's.

That's a lot of new or changed files for a fairly minimal install of a ".1" revision upgrade. I suspect there are three reasons for this. First, some components are completely new (e.g. the DVD player application). Second, many components have had code changes since 10.0.4: bug fixes, new features, optimizations, etc. Third, components that have not had any code changes may have been recompiled with the (presumably) improved version of Apple's compiler. My guess is that components with code changes make up the bulk of the upgrade installation.

The developer tools components (all of which are optional) look like this:

(The total size listed above is the simple addition of the component sizes. I forgot to note the size indicated by the installer, and I'm not willing to wipe the disk again and reinstall to obtain the information :-)

I installed the developer tools on both systems, omitting only the ProjectBuilderWO IDE.

Bundled Applications

If you add up the clean-install sizes for the whole OS and developer tools, it comes out to over 1.7GB. That disk real estate buys you a modern OS with a complete development environment and documentation, suitable for basic email, web browsing, and video editing (iMovie 2 is included), plus a complete BSD-derived Unix environment. The only thing missing is a basic office-type application suite for word processing, spreadsheets, and such.

DVD playback has been promised for OS X since 10.0, and it finally arrives in 10.1—but not for everyone. The DVD player application was not even installed on the G3/400 because its DVD playback hardware is not (yet?) supported. In fact, DVD playback is only supported on AGP-equipped Macs, leaving the "Yikes" Power Mac G4 in the lurch as well (unsupported hacks notwithstanding).

This is disappointing, given the smooth playback provided by the G3's dedicated hardware when used in Mac OS 9, and the amount of time Apple has had to implement the OS X player. It seems to me that the software-based playback used on the G4 series would be harder to code than the hardware-based playback on the G3. I hope DVD support for the remaining unsupported machines will arrive before they all pass into obsolescence.

On the bright side, DVD playback on supported machines seems much improved over the Mac OS 9 experience. I tested the feature on the dual G4/450 by playing movies in a player window in the corner of my screen during a normal work day. There was no skipping or stuttering, and the audio and video always stayed in sync. The picture looked very good as well, with no obvious decompression artifacts.

The DVD player "remote" (the floating control window) looks a lot like a larger version of the minimized iTunes window. It has both vertical and horizontal orientations, and sports the usual variety of movie control functions (some hidden in a slide-out panel). You can see the player in action at Apple's web site. The horizontal version of the remote appears below.

The DVD remote (see also: vertical version)

As in Mac OS 9, it is possible to play DVD movies "on the desktop" by setting the desktop pattern to be a particular color. The DVD player uses this color as a mask for its video display, allowing the movie to appear on the desktop pattern even when the player window itself is hidden. (Unfortunately, this trick doesn't play well with the transparent drop-shadows on OS X windows, making it a somewhat ugly experience in X.)

It's nice to see iMovie 2 included, but I couldn't test it since I don't have a DV camera, and the iMovie "dog wash" tutorial movie does not seem to be installed.

Another notable addition is a Mac OS X native version of Acrobat Reader 5.0—a tacit acknowledgement that the Preview application (which uses on Quartz's built-in PDF support) does not support enough of the most recent PDF spec to read all PDF documents that users might encounter.

Applications that already existed in 10.0.x have also been revised for 10.1. Internet Explorer version 5.1.2 is a considerable improvement over the 5.1 "preview" version in 10.0.x. Some of the rough edges have been polished, and pages seem to render more quickly. But it still feels like a Mac OS 9 application dressed up for OS X, especially when compared to the true blue Aqua interface of OmniWeb.

The bundled Mail application includes many important bug fixes, and has been much less crash-prone when handling my monstrous collection of email across more than 10 different accounts. Other users have had the opposite experience, however. Your mileage may vary.

iTunes looks identical, but the playback experience is a whole new ball game (more on that later). The iTunes Dock icon pop-up menu now includes simple song control functions, as well as the artist and title of the current song (see image top right).

The revised Terminal application adds support for many more text encodings (see image right). This feature was much-requested by non-English speakers. Unfortunately, something seems to have broken during the revision because the 10.1 Terminal does not play nicely with saved terminal sessions. Some saved session files don't work at all, producing only a local shell prompt regardless of the command that was supposed to execute. Others now appear to launch a local shell prompt and merely "type" the command at that prompt for you, rather than running the requested command directly (i.e. without running a shell first). Compare the result of running the command "

telnet www.apple.com 80

" in the version of Terminal from 10.0.4 and the version that comes with 10.1:

"telnet www.apple.com 80" in the 10.0.4 Terminal

"telnet www.apple.com 80" in the 10.1 Terminal

These may seem like a handful of minor annoyances, but they combine to make the user experience less efficient (and less pleasant) for someone who opens and closes a lot of different terminals during the day. After fighting with the new Terminal application for a few days, I reinstalled the version of Terminal that came with 10.0.4, and have been using that instead. In my opinion, that's bad sign for whomever's responsible for the Terminal application at Apple.

(It's also worth noting that other users have had different experiences—both worse and better. I'm not sure exactly what's going on, but it doesn't seem good.)

System settings

The System Preferences application in 10.1 reorganizes the previously alphabetical list of preference panels into groups:

While the grouping has made finding a particular icon easier than in the ungrouped, alphabetical list in the 10.0.x version, the groups seem a bit loose to me. Why is QuickTime under "Internet & Network"? Why is Login under "Personal"? (It contains personal settings for login items, but also allows the system-wide login behavior to be changed.) Overall, it's an improvement, but a more extensible (and user-configurable) organization scheme would be even better.

System Preferences may be on the same evolutionary road as the classic Mac OS Control Panel: starting as a monolithic application, gaining organization and extensibility slowly, and eventually turning into a "special folder" containing individual control panel applications, deferring organization to the user via the Finder's usual file management interface. Time will tell.

The Desktop preference panel, used to set the desktop background, is a new immigrant to System Preferences, coming from its former home in the Finder's application preferences. It makes more sense in System Preferences. Users shouldn't need to know which application controls the desktop area.

Desktop preferences

The General preference panel includes a new option to set the number of recent applications and documents (5-50) that will be displayed in the corresponding items in the Apple menu. Font smoothing (antialiasing) can now be turned off below a certain font size threshold:

General preferences

Also note the option to use traditional scroll arrows (one on the top and one on the bottom) or to combine the arrows (both arrows grouped together on the bottom or right side of the scroll bar). As in Mac OS 9, the ability to have both scroll arrows at both ends is not accessible via the GUI, but is possible through other means.

The "changes" to the Dock preferences are in a similar vein: they're all features that existed in 10.0.x, but were only accessible indirectly. 10.1 now gives the position (left, right, or bottom) and animation (genie or scale) options their own GUI in both System Preferences and the Docks's pop-up menu (both shown below). When the "scale" effect is selected, minimizing a window scales it uniformly while moving it towards its eventual position in the Dock. This effect is much less processor intensive than the flashy "genie" effect, and therefore completes in less time, making window minimization feel snappier. Both effects are demonstrated (with a repositioned Dock) in Apple's Mac OS X theater.

Missing from the new 10.1 GUI (but present, sans GUI, in 10.0.x) are the options to "pin" the Dock at one end, to move the Dock to the top of the screen, and to select the "suck" minimization effect. These features are present in 10.1 as well, but still have no proper GUI.

The actual, functional changes to the "new" Dock in 10.1 are few and small. In 10.0.x, hiding an application caused any of its minimized windows to "fly over to" the application icon in the Dock, in a sort of "rainbow" path. Revealing the application again caused the minimized windows to "rainbow" back to their former positions in the Dock. In 10.1, they merely shrink and "re-grow" in-place. The (still hidden) pinning option is now preserved across logins. Typing "q" while command-tab-ing through running application in the Dock causes the selected application to quit. Typing "h" hides the selected application. Finally, application icons in the Dock now "jump" when they want your attention. (This can be cute or annoying, depending on your mood.)

The new Universal Access preference panel includes an option to control mouse movement with the keyboard (shown below), and a "sticky keys" feature to aid in executing keyboard modifier command sequences.

Universal Access preferences

ColorSync now auto-detects display devices and configures an appropriate device profile. Manual calibration is still possible via the Displays panel. Speaking of which, the Displays panel still refuses to give me the option to set the G4's AccuSync 120 monitor to the supported 85.02Hz refresh rate in my preferred resolution. Both 10.0.x and 10.1 provide 75Hz and 85Hz options, but no 85.02Hz. At 85Hz, the image is slightly distorted and off-center, so I'm forced to use the 75Hz setting. Needless to say, Mac OS 9 correctly detects and provides the 85.02Hz option. (If anyone knows how I can manually force the display into 85.02Hz in Mac OS X, please mail me.)

One of the most intriguing new features in 10.1 is hidden in the inconspicuous-looking Keyboard preference panel:

Full Keyboard Access: control your Mac entirely from the keyboard

The Full Keyboard Access tab gives Mac user the ability to access window controls, menus, and even the Dock via the keyboard. Combined with the Universal Access features described above, any part of Mac OS X 10.1 can be operated with the keyboard alone. Windows (necessarily) had this ability since its introduction due to the initial scarcity of mice on PCs. The ability has been retained in later versions of Windows, and is expected by PC users. Adding this ability to Mac OS X makes 10.1 slightly less disconcerting to any Windows users looking to migrate, and finally satisfies Mac users who have wanted this feature, but have had to resort to third party software in the past.

The feature works much like its Windows counterpart. The currently selected control has a dim "glow" around it, as seen in the image below. Controls may be navigated with the tab key, or shift-tab to cycle in the other direction. User-configurable keyboard shortcuts are also provided to jump directly to the menu bar, Dock, toolbar (like those found in Finder windows), and floating "Utility" windows or palettes. The feature itself can be turned on and off with a keyboard shortcut as well, saving a trip to the preference panel. It is turned off by default.

The keyboard focus "glow"

Unfortunately, this new feature is very buggy. As attentive readers may have noticed already, it is impossible to entirely disable this feature. For example, the checkbox in the screenshot above has the focus "glow", but as that checkbox clearly indicates, the feature is (supposedly) turned off. In fact, it is turned on in this preference panel, despite the appearance of the checkbox. And this bug doesn't just occur in preference panels. Many of the dialogs and windows I've encountered using 10.1 have had the "glow" on their checkboxes, radio buttons, tabs, etc., despite the fact that the feature is (ostensibly) turned off. This bug is mostly just a cosmetic annoyance, but it mars a useful and otherwise well-executed feature.

The Sharing preference panel includes new options to allow Apple Events to be received from other computers on the Network. I imagine this feature will be most useful to AppleScript authors. It is disabled by default, presumably for security reasons.

Networked AppleEvents

The Users preference panel includes a new option to associate an icon with each user. Combined with a new option in the Login preference panel, these icons may be displayed next to each user name in the new login window:

Login window with user list and accompanying icons

(Also note that the "computer name" is displayed beneath the large "Mac OS X" title text, rather than the Unix host name as in 10.0.x. My computer is unimagintively named "Mac OS X", so it looks a bit odd.)

Clicking on an icon condenses the window to display just the selected icon, plus a password field. The presence of the "Other..." icon is optional (set in the Login preference panel), and is turned off by default. Selecting it presents text fields for both the username and password.

As in 10.0.x, 10.1 defaults to automatic login, which means that Macs with only a single user will never need to see the login window. When a user is added, a dialog box pops up asking if the automatic login setting should be changed. This is helpful the first time it pops up, but it appears every time a new user is added, which is slightly annoying.

Some of the preference panels have an option to display icons on the right side of the menu bar, allowing fast access to their settings at any time. The sound and displays "system menus" are shown below, with the displays menu selected:

System Menus

The aesthetic theme for system menus is monochromatic: simple black line art. There are many other system menus, depending on your configuration, indicating battery charge, AirPort status, modem status, etc., and all of them share the same appearance theme.

One final note on the System Preferences application itself: it doesn't remember its window position. Annoying.

Performance

Mac OS X 10.1 is all about performance. That's the hype, anyway. To examine the reality, I delved farther into the seedy underworld of benchmarking than I have in past articles. Let me establish up front that I am just one person with access to two Macs, Mac OS X 10.0.4, 10.1, and a stopwatch. The results described below should only be interpreted as broad indications of the relative performance of Mac OS X 10.1 vs. 10.0.4. They may be not suitable for comparisons between Mac OS X any other operating system, or even between other Macs and the ones I used in the test, due to the huge number of variables between those environments.

I think these tests work as a way to make broad comparisons between 10.0.4 and 10.1 because, within the context of the testing environment, I tried to make sure the OS version was the only significant variable. I'll be offering my own subjective account of performance as well. These are mostly useful in combination with my performance observations from earlier articles.

Is 10.1 faster than 10.0.4? The answer is a resounding "yes." Is it as fast as the hype surrounding its release may lead you to believe? I don't think it is. Let's take a look.

Application Launching

I focused most of my heavy benchmarking on application launching. I did this because it's relatively easy to measure (just try "measuring" window resize performance), it's likely to be significantly different across OS and application versions (as opposed to something lower-level like integer arithmetic, which presumably will not change that much on the same hardware), and because it was dreadfully slow in 10.0.x.

I measured launch times in two ways. The first, simplest measurement is the now-famous "bouncemark" score. When an application is launched in Mac OS X, its icon appears in the Dock and then bounces up and down while it's launching. (This animation can be turned off in the Dock preferences, but it's on by default.) This is the most user-visible indication of launch speed.

Of course, it is also one of the most susceptible to trickery. The length of each bounce is variable, making a mere count of the bounces somewhat less useful than you might expect. Also, an application does not stop bouncing when it is actually "finished" launching, but when it is ready to receive events. By combining the two, one can imagine a slower bounce speed and an ability to receive events earlier in the launch sequence resulting in an application that seems to launch much faster. "Hey look, it only took two bounces in 10.1, instead of five in 10.0.4!"

This is not all bad, of course. If 10.0 taught us anything, it's that perceived performance is almost as important as actual performance. But to keep the bouncemarks honest, I also tested actual launch time. The stopwatch can't be tricked. Unfortunately, the person operating the stopwatch can! The difficult part about timing an application launch is deciding when the launch is complete.

Obviously, waiting for the application to stop bouncing is not an accurate technique. Even though an application may be receiving my keystrokes, for example, it's not very useful to me until its entire user interface is up and running. The metric I used to pinpoint launch completion was the existence of a complete application UI. If an application creates a new blank document when it starts (like TextEdit, for example), I stopped the stopwatch when that window was fully visible and complete. If an application has a "main window" (like Mail), I stopped when that window was fully visible and complete. The exact stopping point for each application was different, but the same stopping point was used for each application in each OS version. So the application-to-application times are comparable, but only broad comparisons can be made between different applications, or between the same application on another computer timed by another person. (See, isn't benchmarking evil? :-)

The testing technique was as follows:

1. Arrange all the applications in the Dock, and on the desktop.
2. Reboot and (auto)login as an admin user.
3. For each application in the Dock (ordered as shown in the graphs, from top to bottom), repeat three times:
   • Click the application icon in the Dock and wait for it to finish launching.
   • Quit the application.
4. Repeat three times:
   • Select all the application icons on the desktop and select "open" from the Finder's file menu to launch all of them simultaneously.

Although I repeated all the launches three times, the graphs only show two times since the third time never varied significantly from the second. All these tests were done on the G3/400, where Mac OS X was installed on the 5,400RPM 12GB hard drive. The tests were done immediately after each OS version was installed, and without any third party software added to the system (other than BBEdit, that is). Let's start with the bouncemarks:

Mac OS X 10.0.4 appears in the blue bars, and 10.1 is in red. Each set of bars includes the first launch on top, and the second launch on the bottom. As you can see, the icons are bouncing a lot less in 10.1. The only application that did not bounce significantly fewer times (especially on the second launch) in 10.1 was the previously maligned Terminal application. iTunes was the most improved, going from a second-launch of eight bounces in 10.0.4 to a mere one bounce in 10.1

But were any of these applications cheating by simply stopping bouncing earlier? Or was 10.1 itself lengthening the duration of each bounce? Have a look at the actual launch times:

The actual times are not quite as impressive as the bouncemarks, but there's still a clear improvement over 10.0.4. There are some puzzles, however. Check out the identical first and second launch times for iTunes in 10.1, which contrasts greatly with the 4-to-1 bouncemark scores in the same OS. I ran the entire 10.1 test cycle again to verify that time, and it turned out about the same. The only difference I could observe was in the amount of hard disk activity I heard.

In general, second launches had a lot less disk activity than first launches. Some applications, like TextEdit, had no discernable disk activity at all on the second launch. Ah, the wonders of caching.

I think almost every application tested stops bouncing earlier in 10.1 than in 10.0.4. Of course, almost every application has changed since 10.0.4 as well. Apple's WWDC session on application launch performance specifically mentioned this "perceptual optimization", and it appears that Apple's developers (and the MS IE team) are showing the way with the bundled applications.

The applications bundled in 10.1 also seem to incorporate other optimizations mentioned in the WWDC session: deferred loading of application components, decreased extraneous file access, etc. I'm basing this speculation on the apparent decrease in disk activity in 10.1 during application launch.

BBEdit, an application that did not change between OS versions, showed both decreased bouncemarks and launch times, so the OS itself must also be doing something right.

Finally, let's look at the launch times for the simultaneous launch test. (No, I didn't attempt to count the cumulative number of bounces!)

The bottom set of bars, labelled "Launch All", show how 10.1 fared vs. 10.0.4. The improvement is clear and significant. While observing the bounce-fest of the simultaneous launch, I couldn't help but notice that two applications in particular were still bouncing when the others had long since settled down: Terminal and BBEdit. I decided to try the test without Terminal, and then without both Terminal and BBEdit to see how much the time would improve.

Dropping Terminal saved about 5 seconds, but dropping both cut the times by more than half! The second attempt launched eight application in about nine seconds—not too shabby for a 5,400RPM ATA/33 drive and a 400MHz G3 processor. Clearly, the world would be a better place if more OS X applications launched like Mail and Internet Explorer, and fewer launched like the new Terminal and BBEdit.

As developers update their applications, I suspect the OS X application launch experience will improve steadily. It's already at "acceptable" levels, in my book. Mac OS 9 is still faster in many situations, particularly on the G3/400. But 10.1 has nothing to be ashamed of (with the possible exception of the new Terminal application, which is slower to launch than it's 10.0.4 counterpart, on top of the bugs described earlier.)

The 10.1 demos given by Steve Jobs, during which every application he clicks on launches in a single bounce (and less than three seconds), are entirely plausible, given a powerful system with a fast disk, lots of RAM, and a rigorous "warm-up" session to prime the caches. (Like all magic tricks, software demos are all about preparation ;-)

The bottom line for application launch in 10.1: it's better, and you'll notice.

Window resizing

Since the release of 10.0, almost every Apple presentation that has mentioned Mac OS X has talked about the need for performance improvements, and has specifically mentioned window resizing as a bullet point, right alongside better hardware support and the need for native applications. It boggles my mind that something as mundane as window resizing was allowed to ship in 10.0 in such a horrendous state that it garnered special mention in every significant review of the OS X—including Apple's!

The worst window resize performance in 10.0.x was provided by none other than the Finder itself. List view windows, in particular, were so unresponsive as to be nearly useless. Resizing a list view Finder window was one of the first things I tried in 10.1.

I was overjoyed when I saw how responsive it was, even on the G3/400. It's still nowhere near as fast as outline resizing (in Mac OS 9 or X), but the performance in 10.0.x was so bad that anything close to acceptable performance feels super-fast in 10.1.

Of course, that feeling wears off eventually. But the 10.1 performance is good enough to make list view Finder windows useful again, and that's something, at least. The resize performance in all the other Finder window views is also improved. The only remaining problem with Finder window resizing is a slight pause before there's any response (especially on slower systems).

After the dramatic improvement of the Finder's window resize performance, I rushed to try other applications. I was in for a disappointment. Applications other than the Finder do not seem to have significantly improved window resize performance vs. 10.0.4 on the same hardware—even applications that have changed since 10.0.x. Resizing an IE window, for example, is still painfully, uselessly slow on the G3/400. (It also suffers form some cosmetic issues.) And while the bundled Mail application does show improvement over the 10.0.x version, it's still much too slow on the G3 to be considered "adequately responsive."

So what, exactly, is the new Finder doing that these applications aren't? I'm not sure, but (not surprisingly) I have a theory...

Using the Quartz Debug application from the developer tools (which flashes any changed portion of the screen in yellow), I observed that list-view Finder windows flash a region equal to the extension of the window to the right and bottom edges of the screen whenever a resize move is initiated. The (simulated) animation below shows an example:

Resize "initiation" is indicated by a drag of one or more pixels in any direction on the resize widget. (Merely clicking and holding on the resize widget doesn't cause the yellow flash.) What's going on here? For some clues, let's look back a bit at the history of window resizing in OS X.

If one was to judge window resize performance in OS X based on every 10.0.x demonstration given by Steve Jobs, it would not appear to be a problem at all. When faced with the dismal performance of 10.0.x on their own computers, many Mac users eventually realized that the reason all of Jobs's demonstrations showed good resize performance was that he almost always chose to resize a window with good resize performance characteristics—his favorite being an image in the Preview application. Resizing in Preview is fast because it is merely "clipping" the image. The picture in the window exists in memory that is allocated when the image is loaded; resizing the window simply reveals or hides portions of the previously allocated buffer.

I contend that the Finder in Mac OS X 10.1 is doing exactly the same thing, but on a per-resize basis. When a resize action is initiated, I believe the Finder allocates a single, large image area (filled with the hidden contents of the Finder window, if any) that extends as far as the user can possibly resize that particular window (i.e. as far to the right and bottom as possible), which is the exact area indicated by the yellow flash. (Note that this allocation would also account for the "pause" I've experienced.) Subsequent resize motion is reduced to clipping: hiding or revealing the image that was allocated when the resize action was initiated. And as Jobs demonstrated so well in his 10.0.x demos, clipping is fast. It's fast in 10.1 too, and therefore so is Finder window resizing.

This is all speculation, of course. (Apple programmers should feel free to set me straight. And don't worry, I won't tell the boss ;-) But the Finder must be doing something differently than other OS X applications. On the other hand, the optimization may not be in the Finder itself, but in the "data browser" widget that the Finder's list view is based on. If this is the case, any application that uses this widget may benefit from the optimization.

Whatever technique the Finder is using, other OS X applications should adopt it, if possible, and revert to non-opaque outline resizing if acceptable performance cannot be achieved. The developers of Microsoft's Word X Test Drive, a demo of their soon-to-be-released OS X native version of Word, appear to have similar opinions of the situation. Windows in the Word X Test Drive use outline resizing on both the G3/400 and dual G4/450, and the user experience is significantly improved because of it.

If the Finder is really doing what I think it's doing, this optimization will not help any application that wants to dynamically reflow window contents during a resize. Internet Explorer currently tries to do this, with very poor results on the G3/400, and barely acceptable performance on the dual G4/450.

Despite the dramatically increased performance in the 10.1 Finder, I believe that what I wrote in my 10.0 review still applies to window resizing in Mac OS X 10.1, overall:

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.

If Apple is unable (or unwilling) to add such a system-wide option, it is up to developers to decide where it is "safe" to implement opaque resizing. Microsoft's Mac developers have apparently decided that opaque resizing was not ready for the Word X Test Drive. (We'll find out in November if the final release acts the same way.) Other Mac OS X developers should evaluate their own applications and make some decisions (possibly even at run-time, based on the hardware) about where and when opaque resizing is appropriate. I use several applications every day that exhibit painfully slow window resize performance. I've had Windows users briefly use OS X and initially think that the entire OS has frozen based on an unresponsive (or unsuccessful!) window resize attempt. Experience using OS X teaches you to slow down during window resizing and wait for the display to catch up to your cursor. This is a bad thing.

While the Finder's resize performance improvements are very welcome, this problem has not gone away, and will not go away until application developers (including Apple) start to make decisions based on the actual usability of opaque resizing, rather than the "expected" performance or bullet-point marketability. Window resizing is not a "high-end" feature. It's as basic as closing a window or selecting an icon. Window resizing should perform nearly perfectly on every system that Mac OS X can run on. If it cannot be opaque, so be it.

Memory usage

If you're reading this article for tips on how to improve your Mac OS X experience, now's the time to pay attention. Aside from purchasing a new Mac, the most important thing you can do to make Mac OS X more bearable is to buy more RAM. Go ahead, don't be shy. 512MB sticks are going for as little as $50 if you look hard enough.

Frequent readers may recall that both the G3/400 and the dual G4/450 had only 256MB RAM at the time of the 10.0 review. After using 10.0.x for a few weeks on the G4, I got sick of hearing my disk grinding constantly and upgraded to 512MB. The silence that followed was truly golden. It was a bigger improvement than any of the 10.0.x upgrades, by far.

(Although the G3/400 primarily runs Mac OS 9, I upgraded it to 384MB because, well, RAM was too damn cheap not to, I guess.)

After a few weeks at 512MB, the G4 started to get a little grind-happy again. I shuffled some RAM between machines to boost the G4 again to its current total of 768MB, and noticed a nearly linear boost in "smoothness" in daily use.

What's going on here? Where is all this memory going? Is Mac OS X a black hole for RAM? In a word, yes. But that's actually a good thing...sort of. I talked about Mac OS X's virtual memory system as it relates to the user experience and the infamous "minimum required system" in the 10.0 article. I'd like to take a short break from the "review" portion of this article and go into more detail about Mac OS X's memory system (as requested by numerous readers). Feel free to skip ahead to the summary if you're only interested in the RAM usage performance of 10.1 relative to 10.0.x.

(Note: A lot of the information presented below is heavily simplified in an effort to reach as broad an audience as possible. If you're interested in the gory details, picking up a good book on the topic is your best bet.)

Virtual Memory Basics

Mac OS X manages memory very differently than classic Mac OS. The first key to understanding memory usage in Mac OS X is to be understand how a modern virtual memory system works.

In a virtual memory management system, there is a distinction between real, physical memory and "virtual" memory. An application's virtual memory size is the amount of memory the application thinks it has allocated, but only a (possibly very small) portion of that memory may actually be stored in the real, physical RAM chips sticking out of your computer's motherboard at any given time. The rest exists on disk in some form, usually in one or more "swap files."

The operating system decides what portion of which processes exist in physical memory at any given time. This decision process is complex, and varies from OS to OS, but it usually uses recent usage statistics in its decision making process. A process that has not accessed a particular piece of (real, physical) memory for a long time may find that memory written out to disk so that another more active process can use that piece of physical memory. When a process has a large portion of its memory removed from physical RAM and placed on the disk, it is said to be "swapped out."

If a process needs a previously swapped-out piece of memory again, it will be transferred from disk back into physical memory—possibly in a different location than its earlier home in physical memory. When a previously swapped-out application becomes active again and causes a large portion of its memory to move from disk back to physical memory, it is said to be "swapped in."

To simplify memory management, the operating system deals with memory in uniform units of a minimum size (usually 4K) called "pages." Swapping out a page is also called a "pageout", and swapping in a page is called a "pagein." The policy used by the operating system to control memory management is often called the "paging algorithm."

Memory pages may store almost anything: code, data, even pieces of files. In fact, one of the useful features of virtual memory is that entire files may be "memory mapped": a file on disk may be accessed as if it's a series of memory pages that have been swapped out to disk.

Further optimization is possible by allowing processes that need access to the same information (code, data, files) to share memory pages. Only when one of the processes sharing a particular memory page chooses to modify that page is a private copy created. This behavior is aptly named "copy-on-write", and it allows many processes to efficiently share memory, with only the "differences" allocated separately.

Not all memory may be swapped out. Some pages are "wired down", meaning they may never leave physical memory during their lifetime. The memory pages that contain the operating system code that control the paging algorithm can never be swapped out, for instance (think about it). In fact, much of the operating system kernel is usually wired down.

Each active process needs some minimum portion of its memory pages to exist in physical memory in order to function efficiently. This portion is called the "working set." When the working set of all the active processes cannot fit in physical memory, the operating system must constantly shuttle pages to and from physical memory and the disk in a sort of game of musical chairs gone terribly wrong. A computer in this state is said to be "thrashing." The only cure is to either decrease the number active processes or buy more RAM.

The Buffer Cache

The second most important factor in Mac OS X's memory usage behavior is the buffer cache. The buffer cache is meant to speed up access to files on disk. Every time a piece of data is read from the disk, it may (optionally) be stored in memory. If that same piece of data is needed again in the near future, it may still be available in (physical) memory, saving a trip to the disk. Mac OS X implements a "unified buffer cache", meaning that the buffer cache and the virtual memory system are combined. A page is a page is a page in Mac OS X.

The buffer cache affects RAM usage in ways that a Mac user may not expect. Heavy file i/o can use a lot of physical memory very quickly, potentially thinning out the physical memory presence of running applications. Poorly written applications may exacerbate this problem by using cached file i/o when it is not necessary, or even useful. An application that reads and parses a large file a single time during start-up should probably not use caching i/o, since it is not likely that the application will need those memory pages again some time in the near future before they're evicted from physical memory by another active process.

The Window Server

The final major player in the Mac OS X memory ballet is, perhaps surprisingly, the window server. The window server orchestrates access to the screen, including both low-level drawing and higher-level concepts like the movement and layering of windows.

As discussed in earlier articles, the Quartz display layer (of which the window server is an important part) models the screen as a layered compositing engine much like the layers in a graphics application like Photoshop. Each pixel has a red, green, and blue components, plus a so-called "alpha channel" which determines its transparency, from totally opaque to totally invisible. The appearance of each pixel on the screen is determined by the composite of all the applications that have a pixel in that position. The window server calculates the composite of those pixels based on the layering and visibility of the participating pixels.

This provides the infrastructure for many of the "pretty" effects in Mac OS X: the transparent drop-shadows on the windows, the translucent menus and title bars, etc. Each individual application only needs to worry about its own pixels, without regard for anything in front of or behind it. The window server then composites those pixels and draws the result to the screen. This makes application development simpler, leaving the "hard work" of creating those nice on-screen effects to the operating system rather than each application.

Things get tricky again something on the screen has to move or change color (or transparency). The window server must re-composite every pixel changed by an application before the change can become visible to the user. And the compositing calculation needs not only the value of the changed pixel, but also the values of all other pixels that contribute to that position.

Think about the calculations necessary to do something as simply as move a window in Mac OS X. Every pixel of that window must be re-composited with every pixel of every application in each location for each new position of the window. Imagine a 500x300 pixel window (about 24 rows of 80 column text) moved 100 pixels to the right, with 5 other application windows behind it. That's about 15 million compositing calculations, each with 30 operands (red, green, blue, and alpha values for each contributing pixel from each application), all for moving a small window a few inches.

But wait, there's more. When something changes on the screen (a window moves, appears, or disappears), pixels belonging to other applications are revealed. Those pixels must, of course, be composited before they can be displayed, and those compositing calculations need all the pixel values for each application that has a pixel in the newly revealed area. Adding the compositing calculations associated with the newly revealed screen area in the moving window example above (and accounting for the transparent drop-shadow on the window) brings the grand total to almost 17 million 20-30 operand calculations!

Of course, this is a worst-case scenario that would only happen in a very naive implementation. Many optimization are possible. Solid pixels can abbreviate the number and difficulty of the compositing calculations tremendously, especially if the front-most pixel is solid.

But there's no getting around the fact that the window server still needs access to all the pixels of all the windows on the screen at all times, since it never knows when one of them will be required in a compositing calculation. Furthermore, this access needs to be very fast, since no one wants to wait while the OS reads pixels from a slow medium like disk.

Mac OS X provides the window server with fast access to pixels by making all windows "buffered." All the pixels of a buffered window are stored in in memory. When one of those pixels is needed in a compositing calculation, the window server simply reads the memory location corresponding to that pixel. It does not have to "ask" the application for the pixel. In fact, an application may be entirely frozen and unresponsive, but its window can still be moved around, hidden, and revealed without any participation from the application. When an application wants to change its window, the changes are all sent through the window server, which updates the window's buffer to reflect the changes.

This is a big change from classic Mac OS, where each application drew directly to the screen, and any newly revealed portion of a window had to be re-drawn by the application that owned that window. Window buffering and compositing had to be implemented explicitly by each application that wanted it, and it was totally independent of any other running applications.

From a development perspective, buffered windows make applications easier to code. Drawing only has to be done once, after which portions of the window may be hidden and revealed without triggering any custom redraw code in the application. From a user's perspective, window buffering allows newly revealed windows to "just be there," with no visible redraw. Buffering also provides smooth, flicker-free window movement. Mac OS X even goes so far as to synchronize screen drawing with the sweep of the electron beam on CRTs to avoid flicker and "tearing."

Quartz's buffering is generally a good thing. It improves the visual quality of on-screen elements and it makes application development easier. But what does all of this have to do with memory usage?

We've already seen the potentially tremendous number of calculations required to composite items on the screen. These calculations are all done by the CPU in Mac OS X, and are not off-loaded to a video card's GPU. But surprisingly, this is not as large a CPU hit as you might expect, thanks to both the common case of totally opaque pixels and the speed of today's CPUs (yes, even on Macs). A few million calculations every once in a while may cause a some instantaneous load on the CPU, but it is not really a factor in the long term. That said, it would be great to have the video card do these calculations rather than the CPU—something I'm sure Apple is working on. In pathological cases (e.g. the famous shaking transparent terminal window) the CPU load can briefly become significant.

But it's the memory usage that's the real killer. Classic Mac OS applications only need to retain the essential information about each window: its size, features, and contents. Mac OS X applications have to retain the same information, of course, but remember that the window server also has to retain a complete memory image of every pixel in the window! Repeat this for every single window on the screen, and it adds up very quickly.

Classic Mac OS requires only a few kilobytes to store the basic structures that define a simple, empty window. In Mac OS X, the total memory required for even a completely empty window is proportional to its size, regardless of the nature of its contents (if any).

In my daily work as a web programmer, this difference is very apparent. The nature of the work requires many windows to be open at once: text editors, web browsers, terminals, etc. In classic Mac OS, each text editor window, for example, would require only a small amount of memory for the window itself, plus whatever backing store the editor keeps for the (ASCII) text in each window. In Mac OS X, each simple text editor window becomes a giant 32-bit image (in addition to the other information, of course). Multiply this phenomenon across all the other applications, each with many windows of their own, and you quickly run into trouble.

Take a look at this window list from a typical work day on my G4. The total memory used by window buffers alone is an astounding 120MB! And remember, this is before even accounting for things like, say, the memory required by the actual applications and the core OS itself!

(The possibility of decreasing the window server's memory usage—and, more importantly, decreasing memory bandwidth usage—by compressing inactive window buffers is intriguing, but this feature is not officially supported in 10.1.)

The window server uses the same virtual memory system as every other part of OS X, of course. That means that the memory that makes up each window buffer is eligible to be paged out just like any other piece of memory. This is where the real performance hit comes in. Attempting to manipulate a window that has had some or all of its window buffer pages swapped out is a painful, stuttering, disk grinding experience as the virtual memory system rapidly tries to bring those pages back into physical memory from disk (evicting other resident pages while doing so, of course).

I encounter this phenomenon on a grand scale every time I return to work on Monday, after a weekend spent connected to the G4 via the command line running non-GUI applications from the terminal. On those Monday mornings, almost every window buffer is likely to have been swapped out during the weekend. The disk grinding session that ensues when all the windows are paged back in as I start to use them again is quite spectacular.

And remember, this is a system with 768MB of RAM. But the OS doesn't care. My command line work over the weekend required significant memory (compiling, running web servers, etc.), and the OS provided it. None of the GUI applications were active over the weekend, so their pages were swapped out to disk to make way for the memory needs of the command line activity. This is to be construed as a feature.

So, buffered windows: friend or foe? In the end, they are a friend. The OS X window server provides a higher level of abstraction to applications. With more abstraction comes more resource usage. But "increased abstraction" is essentially the definition of progress in the computer industry (otherwise we'd all still be programming in machine language). But like much of the rest of OS X, pervasive window buffering is slightly ahead of current state of hardware. Long-term, this is also a good thing, in my opinion. It's easier to wait for hardware to catch up to your ambitious (but clean) software architecture than it is to try to revamp your operating system in response to advances in hardware (just ask Apple ;-)

Swap File Optimizations

Since it is possible to use up almost any amount of physical RAM in OS X (I fill 768MB very quickly), further performance gains are still possible by moving the swap file(s) to a separate disk. No matter how much RAM you have, you will almost certainly hit the swap file eventually. The disk heads on the drive containing the OS and applications will already be scurrying around as they read and write application and OS code and data files. Making the swap file another stop on their frantic journey just adds yet another voice to the cacophony of disk grinding. Swap file access is especially painful since is usually interleaved with other disk operations: read a piece of application code from disk into memory, write an old memory page out to the swap file, read a piece of a data file into the buffer cache, write an old memory page out to the swap file, read a piece of application code from disk into memory...etc. etc. (Can you hear the grinding? :-)

Putting the swap file on a disk mechanism of its own allows the heads on that disk drive to benefit from better locality of reference (i.e. they don't have to move around as much), and frees the application and OS drive to concentrate on its tasks. There is no Apple-sanctioned way to move the swap file to another drive, and certainly no GUI for it. But brave users can follow the directions available on the web. Just be sure to make a total backup first, because you can potentially hose your entire system if you're not careful.

I only have one disk at work, but at home I've moved my swap file from the 12GB 5,400 RPM drive that houses OS X and all its applications to my 45GB 7,200 RPM Mac OS 9 drive. The reduction in disk grinding has been substantial.

Simply moving the swap file to dedicated partition on the same disk is of much smaller benefit (if any). The disk heads still need to make many trips to and from the swap partition and the rest of the disk. And since Mac OS X uses individual swap files (rather than a dedicated swap file system), a separate swap partition is only likely to make a significant difference if the previous swap files were heavily fragmented on disk. (Note: I'm talking about "external" fragmentation, where pieces of each swap file are spread all over the disk. The swap files themselves are always heavily "internally" fragmented, meaning difference pieces of memory are spread sparsely within each swap file.)

Memory diagnostics

There are several tools for measuring RAM usage included with Mac OS X. Unfortunately, most of them are command line programs. (A comprehensive GUI memory monitor would be a nice addition to Mac OS X 10.2.) There's not even an equivalent of the basic per-application memory usage graph provided in classic Mac OS's "About this Mac" dialog. Of course, such a simple summary is not possible in Mac OS X due to the vast differences between its memory management and classic Mac OS's.

The most basic memory diagnostic tool is the vm_stat program. The output looks like this:

% vm_stat Mach Virtual Memory Statistics: (page size of 4096 bytes) Pages free: 24350. Pages active: 30419. Pages inactive: 121158. Pages wired down: 20681. "Translation faults": 334217454. Pages copy-on-write: 1129146. Pages zero filled: 98430493. Pages reactivated: 456481. Pageins: 199957. Pageouts: 121833. Object cache: 363343 hits of 760464 lookups (47% hit rate)

(That's from my very busy G4; can you tell?) Most of those items should make sense to you after the earlier explanation: pageins, pageouts, pages wired down, etc. The "pages active/inactive" lines reflect the OS's distinction between pages that it currently considers eligible to be swapped out, and pages that it considers "active." The other numbers are less interesting, and are explained in the vm_stat manual page, available by typing "man vm_stat" at the command line. (In particular, do not be concerned with the scary looking "Translation faults" line.)

The top command provides a slightly more sophisticated picture of memory usage. top is useful for more than just memory diagnostics. Its purpose is to show the most demanding processes currently running—the "top" (usually 15) processes, so to speak. CPU usage is a big a factor in determining the order of the top processes, but top's output also includes information about each process's memory usage, as well as an overall memory usage summary. Here's my otherwise idle G4, as seen from a terminal window at home:

Processes: 56 total, 2 running, 54 sleeping... 149 threads 12:55:32 Load Avg: 0.09, 0.00, 0.00 CPU usage: 5.1% user, 8.5% sys, 86.3% idle SharedLibs: num = 132, resident = 24.3M code, 1.87M data, 5.85M LinkEdit MemRegions: num = 5485, resident = 140M + 8.62M private, 170M shared PhysMem: 80.8M wired, 119M active, 474M inactive, 673M used, 94.8M free VM: 3.06G + 56.2M 199957(0) pageins, 121833(0) pageouts

PID COMMAND %CPU TIME #TH #PRTS #MREGS RPRVT RSHRD RSIZE VSIZE 29269 top 13.7% 0:00.56 1 15 15 312K 324K 552K 1.45M 29257 tcsh 0.0% 0:00.24 1 24 16 500K 652K 960K 5.97M 29256 telnetd 0.0% 0:00.07 1 23 13 76K 332K 288K 1.30M 29159 ScreenSave 0.0% 2:34.32 3 85 589 10.4M 23.6M 26.9M 93.9M 29156 telnet 0.0% 0:00.17 1 16 15 88K 368K 328K 1.46M 29132 ASM Contro 0.0% 0:00.14 1 49 27 568K 588K 1.39M 34.1M 29131 System Pre 0.0% 0:03.18 2 66 106 2.61M 8.67M 5.98M 69.6M 29130 SystemUISe 0.0% 4:38.49 2 95 137 3.40M 7.33M 4.82M 70.4M 25353 Interarchy 1.7% 54:52.03 8 129 159 5.88M 38.1M 20.2M 117M 25348 DragThing 0.8% 7:59.17 1 55 115 2.73M 9.49M 3.91M 65.7M 25347 Fire 0.0% 2:20.39 3 113 166 3.02M 8.17M 5.42M 70.4M 25339 SecurityAg 0.0% 0:00.47 1 63 74 892K 7.65M 2.74M 65.9M 25312 BBEdit 0.0% 13:31.95 5 117 183 7.15M 70.9M 66.2M- 204M 25310 telnet 0.0% 0:00.23 1 16 15 92K 368K 324K 1.46M 25309 telnet 0.0% 0:00.49 1 16 15 92K 368K 324K 1.46M

A detailed description of the fields is in the lower portion of the output is available in the top manual page (type "man top" at the command line). Unfortunately, the summary information at the top of the output is not explained in the manual page. Fortunately, most of it is either self-explanatory (total number of processes and threads) or esoteric (number of memory regions).

The most interesting memory information in the summary section is in the bottom two lines. Like vm_stat, they list the amount of used, free, "wired down," "active," and "inactive" memory, but in more friendly units of megabytes (instead of vm_stat's very large numbers displayed in pages).

Don't be too concerned with the "free" memory statistic. During moderate to heavy usage, this will probably converge on a constant of a few megabytes. The number(s) you do want to look at to gauge memory usage as it relates to performance are described next.

The pagein/pageouts lines list two numbers (e.g. "199957(0)" for "pageins" above). The first number is the cumulative number of pageins or pageouts since the system was rebooted. The second number (in parenthesis) is the number of pageins or pageouts that have occurred in the last second. If those numbers in parenthesis stay above zero for a sustained period of time, that's an indication that you could use a bit more RAM. If they stay at, say, 50, or more for a sustained period of time, that's a sign that your system is thrashing. (Of course, you probably won't need top to tell you that if you're at the computer and can hear the drives yourself.)

The lower portion of top's output lists information about the top 15 (in this case) processes on the system. The last four columns contain memory usage information. The most important is the RPRVT column, which stands for "Resident Private." It shows the amount of physical RAM that is currently allocated for the private use of each process. (For all you long-time Mac users, this is the closest analog to the "filled" portion of the memory usage bars in classic Mac OS's "About this Mac" dialog.) RPRVT is a reasonable indication of the "working set" of each process.

The RSHRD column shows the amount of resident physical memory a process is sharing with one or more other processes. RSIZE shows the total amount of physical memory used by an application, including memory shared with other processes. (It may seem like this number should be the sum of RPRVT and RSHRD, but that's not the case. I suspect this is because RSHRD includes the total number of resident pages for each shared library, rather than just the resident pages that a particular application is using. Can anyone shed some light on this?)

Finally, the VSIZE column shows the total amount of (virtual) memory each process has allocated. This number is often very large. But remember, the amount of resident physical memory (e.g. RSIZE) is much more important.

The memory used for each application's window buffers is somewhat misleadingly lumped into the RSHRD column because it is shared with the window server process. BBEdit, for example, shows an RSHRD size of 70.9M, most of which is due to window buffers. The window server process itself is not in the top 15 (not surprising, since I'm connected via the Terminal right now and no one is using the GUI), but the "-l" option to top will list all processes. The (trimmed) output below shows that the window server is using a total of 124M of physical RAM (120MB of which is listed under RSHRD because the window buffers are shared with the corresponding applications). The total virtual memory size is a whopping 203M.

% top -l1 ... PID COMMAND %CPU TIME #TH #PRTS #MREGS RPRVT RSHRD RSIZE VSIZE ... 25283 Finder 0.0% 1:50.01 2 89 551 29.2M 15.9M 31.8M 103M 25278 pbs 0.0% 0:04.28 1 31 32 2.50M 696K 3.19M 19.9M 25269 loginwindo 0.0% 0:04.87 8 152 172 3.82M 7.97M 6.46M 71.9M 25268 Window Man 0.0% 76:48.92 4 249 279 3.91M 120M 124M 203M 13929 httpd 0.0% 0:00.01 1 9 168 0K 300K 72K 3.34M 13928 httpd 0.0% 0:00.01 1 9 168 0K 300K 72K 3.34M ...

One final diagnostic tool is useful for getting information about a particular process. The first column of top shows the PID or "process identifier." The ps command can be used to get information about a particular process using this number. For example:

% ps -o'pid,command,rss,rsz,vsz' -p 25268 PID RSS RSZ VSZ COMMAND 25268 126520 126520 207468 /System/Library/CoreServices/WindowServer console

The ps command has a bewildering array of options, but the example above should be fairly self-explanatory at this point. I'll leave further investigation as an exercise for the reader. (Hint: "man ps")

Memory Usage Summary

As should be clear by now, OS X loves RAM. The OS and the applications themselves need some, of course, but it's the "extra" consumers like the window server and the buffer cache that really put OS X in a league of its own. OS X's virtual memory system does an admirable job of keeping the physical RAM where it will do the most good, but there's nothing it can do when the working set far exceeds the available physical RAM—as is often the case on a busy system with many open applications, windows, and files, and a "Mac OS 9 caliber" complement of RAM.

RAM is already relatively inexpensive, and it will only get cheaper. If you are serious about using OS X on your current system, and you currently have less than 512MB or RAM, you should consider upgrading. (No, I'm not getting kick-backs from RAM vendors for this recommendation. But maybe I should ;-)

Mac OS X 10.1's RAM usage behavior has not been substantially different than 10.0, in my experience. Some applications that were revised for 10.1 take more RAM than their 10.0.x counterparts, and some take less (as we'll see in a bit). But the biggest factors in RAM usage—the memory architecture, buffer cache, and window server—remain unchanged in 10.1. Mac OS X 10.0.x needed a lot fo RAM to operate smoothly, and so does 10.1. I know this was a heck of a long section for such an unexciting outcome, but I hope that it's been informative for at least some readers.

The Classic environment

Classic performance has been nearly identical, in my experience. Classic does launch a bit faster in 10.1, but application performance does not seem improved over 10.0.x. This is not a bad thing, however. Classic applications continue to run at nearly full speed, with some features (e.g. classic application launch) that even exceed their performance in a "pure" Mac OS 9 system.

The classic environment's memory usage has improved in 10.1, however. Compare a freshly-booted Mac OS 9.2.1 in the classic environment of both 10.1 and 10.0.4:

    COMMAND      %CPU   TIME   #TH #PRTS #MREGS RPRVT  RSHRD  RSIZE  VSIZE

10.1: TruBlueEnv 0.0% 0:24.72 17 166 173 14.8M 8.58M 21.3M 1.05G 10.0.4: TruBlueEnv 0.0% 0:28.70 15 157 166 36.1M 1.31M 37.1M 1.06G

(We all know how to read those memory usage statistics now, right? :-)

It gets even better. Here's 10.1 vs. 10.0.4 running Word 2001 in the classic environment:

    COMMAND      %CPU   TIME   #TH #PRTS #MREGS RPRVT  RSHRD  RSIZE  VSIZE

10.1: TruBlueEnv 0.0% 0:30.14 17 167 185 20.1M 13.0M 31.0M 1.05G 10.0.4: TruBlueEnv 0.0% 0:56.15 15 165 184 62.6M 1.34M 63.5M 1.06G

That's some impressive progress.

The cosmetic issues from 10.0.x carry over to 10.1, but I suspect the classic environment itself will go away before they do.

Audio and Video

The new DVD player was discussed earlier, but there's more good news for audio and video in 10.1. QuickTime performance, dismal in 10.0 on the G3/400, has finally reached acceptable levels. The same 588x440 iMac commercial that skipped and stuttered on a totally unloaded G3 in 10.0.x now plays smoothly at the full framerate. But moving or minimizing the player window upsets it greatly on the G3, and the stutter is back.

As in 10.0.x, the G4 handles QuickTime playback much better than the G3. But on both systems, exercising the window server rapidly saps QuickTime performance. On the G3, I can actually make a playing movie stop entirely—audio, video, everything—by shaking a transparent terminal window around on the screen.

The old transparent window shaking maneuver has lost its power over iTunes in 10.1, however. Even on the G3, iTunes is totally unperturbed by any window abuse I've been able to inflict. In fact, I have not been able to get iTunes to skip at all on either system without resorting to deliberate attacks on the iTunes process or the entire OS (more later).

Menus, Scrolling, Etc.

The performance of pull-down menus in 10.1 is a big improvement over 10.0.x. Yes, they are still translucent and look just as good (or "bad", depending on your point of view) as they did in 10.0.x., so there's no "cheating" going on in that respect. The increased responsiveness I've experienced has been tantamount to a hardware upgrade. That is to say, the menu performance in on the G3 in 10.1 is about as good as the menu performance on the G4 in 10.0.x.

While the menus in Mac OS 9 on the same hardware are still noticeably more responsive (especially for large menus), 10.1 has finally achieved something close to acceptable menu performance in most situations.

Scrolling, on the other hand, remains dismal. Like the window server's compositing operations, scrolling is another task that is not currently off-loaded to the video card's GPU (as it often is in classic Mac OS), and it shows. Even on the dual G4/450, the only acceptable scrolling performance to be found is in classic applications, which continue to be hardware accelerated in the classic environment. (Turn on the "yellow flashing" option in the "Quartz Debug" application and scroll around in, say, classic IE. Then compare with the OS X native version of IE to see the difference.)

Some applications even suffer from crippling scrolling difficulties—a phrase I never even imagined before OS X. Open the "Apple System Profiler" application, for example, and go to the "Frameworks" tab. Then just try and scroll that seemingly simple window full of text. On the G3, I actually get a busy cursor (the "spinning rainbow disc") while trying to scroll! Granted, you could probably call this an "application problem", but I think it does say something about the OS itself when a simple task like scrolling through a few rows of text in a table is this problematic.

The more common case is nearly as frustrating. Scrolling through a large mailbox in Mail, for instance, is very choppy on the G3. It makes navigation into a sort of game involving many pauses and missteps as the message list jerks and stutters around my intended destination. (And note that this problem exists whether or not the list is displayed with antialiased text.)

Presumably, Apple is working on getting scrolling off-loaded to the video card once again in OS X, but 10.1 does not include this much-needed optimization. Like window resizing, scrolling is not a "high-end" feature. It should work well everywhere. But unlike window resizing, scrolling becomes much less effective when a "non-opaque" method is used; it becomes "scroll, guess, and release." For that reason, the use of real-time scrolling is still advisable in many situations, despite the terrible performance. Although scrolling performance is marginally better in some situations in 10.1, the change is not nearly significant enough to get this feature off the short list of necessary future optimizations (or "bug fixes", depending on how you look at it).

Although opaque window dragging has been impressively smooth since 10.0, it would be nice if the initial "pause" that occurs when some drag operations are initiated could be minimized. This is actually more of a memory issue than a video optimization, of course. As we discussed earlier, many bad things can happen when window buffers get swapped out. Perhaps wiring down more window buffer memory would improve the local user experience on machines with a lot of RAM.

Other miscellaneous display performance issues live on in 10.1, in only mildly improved form. "Band-selecting" icons on the desktop is still too slow. Dragging selections around (icons, text, etc.) continues to be more cumbersome than in classic Mac OS (which also uses limited transparency in some situations, incidentally). The genie effect, while greatly improved in 10.1, still stutters under heavy load on both the G3 and G4. Luckily, the new scale effect provides a more light weight option. ("Options"...imagine! ;-)

Priority Control

Priority control, the mechanism through which certain processes are given more or less opportunity to use CPU cycles, was badly broken in Mac OS X 10.0.x. This problem was quite easily demonstrated in 10.0.x using a simple "spin test" (a program with an infinite loop) and the Unix nice command (used to set process priority from the command line), as the following (slightly abridged) 10.0.4 terminal session shows:

cat > spin.c

main(){for(;;);}

cc spin.c -o spin

nice -20 spin &; nice +20 spin &

[1] 442 [2] 443

alias psn "ps -o'pid,nice,time,%cpu,command'"

psn -p442; psn -p443

PID NI TIME %CPU COMMAND 442 -20 1:41.65 43.8 spin 443 20 1:41.45 49.0 spin

As you can see, both processes got comparable amounts of CPU time, despite being at the far ends of the priority spectrum (20 is the lowest priority level, and -20 is the highest).

In 10.1, priority control via nice now works correctly:

cat > spin.c

main(){for(;;);}

cc spin.c -o spin

nice -20 spin &; nice +20 spin &

[1] 334 [2] 335

alias psn "ps -o'pid,nice,time,%cpu,command'"

psn -334; psn -335

PID NI TIME %CPU COMMAND 334 -20 2:08.11 65.6 spin 335 20 1:36.67 22.8 spin

The high priority process now (correctly) gets more opportunities to use CPU cycles than the low priority process.

Given the impressive performance of iTunes in 10.1, I wondered if it was taking advantage of 10.1's newly-functional priority control. But the iTunes process in 10.1 appears to run at the same priority (0, half way between -20 and 20) as every other normal user process in 10.1. Additionally, only the superuser (a.k.a. root) may increase a process's priority. Normal users may only lower the priority of their processes.

Mac OS X reportedly has some support for real-time priorities—that is, priorities that guarantee a certain amount of CPU cycles per unit time. Is iTunes using one or more real-time threads to maintain skip-free music playback? I'm not sure, but I did try changing its priority via the renice command, with some strange results.

iTunes starts at the standard user priority level (0), and is basically unskippable in this state. The only way I could upset it was by running a "memory bomb" (a process that allocates memory in an infinite loop) as the superuser—and it allocated over 600MB of memory on the 384MB G3 before iTunes started to stutter.

Decreasing the priority to 10 (remember that higher numbers correspond to lower priorities) made iTunes eminently susceptible to the old transparent-Terminal-shaking test: skip city.

The strangeness occurred when I increased the priority (as root) back to its original level of zero. Rather than returning to its former skip-free glory, iTunes remained susceptible to skip-inducing actions.

I'm not quite sure what's going on here. If there were any real-time threads running in iTunes, renice seems to have brought them back down into the realm of normal priority levels. And they didn't restore themselves when iTunes was reset to its original priority. (If anyone knows what's going on here, please mail me)

Anyway, this is all somewhat academic. The bottom line is that iTunes, in its normal state, is virtually indestructible. And the newly-functional priority control will certainly being useful for Unix hackers and Apple's own core OS team alike.

Performance Summary

Overall, Mac OS X 10.1 is indeed faster than 10.0.x, but it is not nearly "fast enough" in many important areas. Almost every aspect of window manipulation remains problematic, particularly resizing and scrolling. While some applications (particularly the Finder) have made great strides in this area, it is still an overall weak spot. Memory usage remains voracious, although the classic environment has slimmed down considerably.

If I had to pick two areas that are "most improved" in 10.1, I'd choose application launching and pull-down menu performance. These two features should be immediately noticeable to anyone who has spent time in 10.0.x, and will affect users every day. Combined with the improved performance of many bundled applications—the skip-free iTunes, the improved QuickTime player, the DVD player that bests its Mac OS 9 counterpart (for those who can use it), and all the other revised applications—Mac OS X 10.1 does indeed deliver a better overall performance experience than 10.0.x. But don't believe the "faster than Mac OS 9" hype, because, despite the bright spots, the big picture does not reflect it. Mac OS X still has a long road of performance improvements ahead of it.

(For more information of performance in Mac OS X, check out the Apple's Inside Mac OS X: Performance document.)

User interface

Much of the quality of Mac OS X's user interface is tied to overall system performance, which we've already covered. This section will therefore concentrate on the handful of other areas that play the biggest role in the OS X user interface: System Preferences, the Dock, and the Finder.

Performance is billed as one of the biggest changes in 10.1, in part because the user interface has not really changed that much. There are very few substantial new features, especially in the "big two" applications: the Dock and the Finder. Given that, much of the criticism leveled at the Mac OS X user interface in earlier articles still applies to 10.1. (And I'm sure some of that criticism will be reiterated here.) Once more into the breach, dear friends...

System Preferences

By "System Preferences", I mean more than just the application of the same name, which was covered earlier. I'm talking about any new features or settings that affect the system-wide user interface. The most important are listed below.

System Menus

One of the most welcome additions to 10.1 is the new "system menu" or "menu extra" (to use Apple's terminology) feature (also mentioned earlier). Although the simple menu extras provided with the OS may not seem that exciting (e.g. an audio volume slider or a battery monitor), it is the framework for system-wide menu bar modification that stands to have a tremendous impact on the future of the Mac OS X user interface. First, a little background.

In 10.0.x, there was no officially sanctioned method for global menu bar modification. With the OS X Apple menu off limits to user and developer modification (a designation that remains in 10.1), the entire 10.0.x menu bar was effectively fixed (with the exception of Apple's tacit inclusion of an optional menu bar clock). This was an especially disappointing, given the removal of Mac OS 9's application switcher menu from the far-right side of the menu bar, leaving that end entirely barren (again, save for the clock) in 10.0.x.

Apple's rationale for this decision has been described to me as being motivated by the proliferation of menu bar clutter in classic Mac OS. Many classic Mac OS applications wanted to include their own system-wide menus, some of which had limited value to the user. Of course, these menus were almost universally optional (although often enabled by default), and I never considered this a big problem in classic Mac OS.

Apparently, neither did other Mac users and developers, because many system-wide "menus" for Mac OS X 10.0.x quickly appeared. I put "menus" in quotes because many of these were not menus at all, but rather applications with borderless windows that drew themselves directly over the existing menu bar. This was an even bigger affront to UI "cleanliness" than the supposed proliferation of (proper) system-wide menus in classic Mac OS—and a further lesson that, if users want something, they'll get it.

Mac OS X 10.1 seems to acknowledge this by providing a proper framework/API for system menus. The user experience it provides is quite nice. System menus may be activated through preference panes, or may be explicitly dragged to the menu bar by the user. Once there, they may be rearranged by holding down the command key and dragging the menu icons (or titles) around, causing a "shuffling" animation similar to the Dock. Dragging a system menu off the menu bar causes it to disappear in a Dock-like puff of smoke.

All of the system menus described earlier are implemented using this interface, including the menu bar clock. You can almost hear the proliferation of new system menus, and the conversion of existing "hacked" menus to the new API. Apple itself has joined in with a new, and very useful system menu for running scripts: AppleScripts, Perl scripts, or shell scripts. Script Menu is a free download at Apple's web site.

Unfortunately, third parties will have to continue to stumble in the dark as they try to leverage the new system menu framework (and rest assured, they will try), because the system menu API is not public. Instead, Apple wants third party developers to add such functionality through what Apple calls "dock menus", meaning menus spawned from docked application icons (e.g. the new playback commands in the iTunes pop-up menu).

Apple's User Experience Technology Manager, John Geleynse, explained the situation this way:

Many of you have been asking for a mechanism to provide global access to certain features provided by your application. Dock menus are the way to do this. Please note that the menu extras area of the main menu bar is not being made available to 3rd party developers at this time and is reserved by Apple for hardware and networking related items. The Dock is intended to be the point of entry for 3rd party developers providing this type of global access functionality.

Furthermore, the 10.1 installer removes all of the old Apple-supplied "docklings" introduced in 10.0.x. John Geleynse again:

Dock Extras, aka Docklings, are no longer being developed by Apple
and the private APIs providing this capability are not guaranteed to
continue working after 10.1.

Existing third party docklings continue to work in 10.1, but produce a warning dialog.

Despite Apple's attempt to maintain an iron grip on the new global menu bar modification API, industrious third party developers will find (and, in fact, already have found) a way to use it. Like I said earlier, it is simply impossible to stop the development of applications that users want—and Mac users apparently want global menu bar modifications.

Apple is foolish to try to stop this phenomenon. Dock menus, while useful, do not fulfill the same need. They are lost in the over-burdened Dock's sea of functionality. While I fully expect new OS X applications to take advantage of the new Dock menus, the wave of global menu bar modification utilities will also continue, whether Apple likes it or not. This includes the current crop of "hacked" Apple menu replacements that draw directly over the existing Apple menu (which will have to continue on in their current form since the new API only appears to affect the right side of the menu bar).

Apple is hurting itself and its users by withholding the documentation for such highly requested APIs. The proliferation of "blind" attempts by third parties to leverage these (possibly changing) APIs without any public documentation will adversely affect the user experience. A user won't know that "it's not Apple's policy to allow third party global menu bar modification." They'll only know that their application switcher menu replacement has suddenly started crashing in Mac OS 10.1.3.

Bad show, Apple. Give the people what they want. Make the global menu bar modification APIs public.

Fonts

As shown earlier, there is a new system-wide preference for font smoothing. Unfortunately, not all applications honor the setting. Worse, some applications that choose to present "un-smoothed" text at certain sizes produce less than ideal results. Compare the following text, both in the same size and font, in 10.1's Mail application and in SimpleText in the classic environment:

Notice how the OS X text appears slightly compressed? It looks like the character spacing needs to be adjusted, or perhaps a bitmapped version should be used at smaller sizes. Whatever the problem, my preferred email message list font (9pt Geneva) is much less readable in OS X's Mail application than in Entourage in OS 9. I can only hope that the coming version of Entourage for OS X handles this situation better.

Other than the partially functional option to turn off font smoothing below a certain size, there are no other significant font choices in 10.1. You cannot adjust the font used in menus, dialogs, the Dock, toolbars, open/save dialog boxes, or the Finder. The default fonts are generally nice to look at, but many of them are much larger than I would like. The large fonts used in open/save dialogs and in the Finder are particularly bothersome because they reduce the amount of information that can be conveyed in a given width. Mac OS X desperately needs more font size adjustability in the interface, and 10.1 does not deliver it.

Keyboard Access

Full keyboard access was cover earlier, but it bears mentioning again. If not for the buggy implementation, this feature would be a home run for 10.1. I hope the bugs will be worked out in future 10.1.x releases.

Other forms of keyboard access continue to languish. Some open/save dialog boxes now respond to keyboard input in a sane manner, allowing navigation of the miniature column view with the arrow keys: up and down to move through a list, and right or left to descend or ascend the hierarchy. Typing the first few letters of a file or folder name also scrolls the selected list to the proper location. Unfortunately, the return key does not open the selected item or folder, making a trip to the arrow keys an essential, and annoying, part of any keyboard navigation experience in an open/save dialog.

I said that "some" open/save dialogs now respond to keyboard input in a sane manner because some continue to just plain go nuts. The movie below shows the open dialog box from the Acrobat Reader application bundled with 10.1. From the starting position shown in the movie, I simply typed the letters "a-r-s" in an attempt to select the "Ars Technica" folder from the list. Watch what happens.

Also check out the larger version

As you can see, I'm booted all the way back to the root of the file system, and one of the "arrows" from the file list has drawn itself on top of the left border of the dialog (easier to see in the the larger version). This bug has existed since 10.0, and it's a shame to see it still around in 10.1.

Also note that the file list allows partially obscured items in the list (look at the "Sites" folder in the right pane at the start of the movie) rather than forcing itself into a size equal to an integer number of items—another annoying bug.

Window Management

There is still no method for in-place window minimization in 10.1. The sole window minimization function, displaced minimization to the Dock, continues to be less than ideal for many purposes (e.g. "peeking" behind a window, or minimizing and restoring several windows quickly without trips to and from the edge-mounted Dock). It also forces anyone who wants to minimize a window to use the Dock for this purpose, regardless of whether or not they want the additional clutter, or whether they want to use the Dock at all. At work, I'm forced to keep the Dock visible at all times because I don't like the delay and uncertain targeting that a hidden Dock provides, but I do need to minimize windows.

A high quality in-place minimization hack would surely find many users (and possibly customers) in the Mac community. I hope someone out there is working on one right now, because Apple (in now-typical fashion) appears to have washed its hands of this feature entirely, despite strong demand from the user community.

The per-window layering policy from 10.0.x is carried on in 10.1. Users who prefer a per-application window layering policy must once again turn to third party software to enable this feature.

The Dock

The small number of functional changes to the Dock in 10.1 were covered earlier. The ability to reposition the Dock has the most significant effect on the user experience—for users that want the Dock someplace other than the bottom, that is. But the essential nature of the Dock remains unchanged. While its intended purpose as a interface simplification device remains admirable, it is still over-burdened with functionality that would better serve users in separate, more specialized interface widgets.

There are many third party applications that extend the OS X user interface, but none of them can completely replace the Dock because none of them can control window minimization the way the Dock does. And applications that implement portions of the Dock's functionality in a more specialized manner (say, a dedicated application switcher palette) do not remove those functions from the Dock. The resulting interface is even more confusing (e.g. there are now two lists of running application on the screen all the times).

At the same time that more applications are taking better advantage of the Dock's functionality (e.g. iTunes with its new pop-up functions and the Print Center application with its improved status display), the intractability of the monolithic, do-everything Dock continues to keep the Mac OS X user environment from suiting the needs of many users. A more customizable Dock, or possibly even an arbitrary number of more specialized Docks, would go long way towards making the OS X user interface more flexible and powerful.

One final complaint: Dock icons are still reduced to undecipherable vaseline-smeared blobs when the Dock is made very small—despite the possible existence of pre-drawn icon resources at or near that size (e.g. 16x16 "icns" icon resources). This makes the Dock both less attractive and less useful at small sizes:

Tiny smudges on the Dock

The Finder

Despite the window resizing performance improvements discussed earlier, I found the Finder to be the most disappointing new application in Mac OS X 10.1. I'm disappointed because, performance improvements aside, the 10.1 Finder still does not allow me to work the way I want to. Many of the 10.0.x bugs remain as well.

There are some interface improvements, however. I'll list them first.

Finder Improvements

• The state of disclosure triangles in list-view windows is now retained. Combined with the improved resize performance, list view windows are finally useful again.
• Icons on the desktop no longer jump into seemingly random positions across logins and reboots.
• The truncation algorithm used to display long file names is improved.
• Typing the first few letters of a file or folder name now causes list-view windows to scroll to the new selection.
• There is a new preference to always open folders in a new window.
• The warning before emptying the trash is now optional.
• Command-drag now toggles the grid snap on a per-drag basis. (Although this feature is of questionable use since command-click is now the multiple selection keyboard combination in the Finder. Just try command-dragging several icons in succession and you'll see what I mean.)
• Disk icons are now customizable.
• Column widths in column view are now adjustable, both together and independently.

Finder Bugs

Now, a tour of some of the bugs.

• Mounting your iDisk causes the entire Finder application to become unresponsive while the volume is mounted. Further navigation within the iDisk suffers form the same problem.
• The insertion point disappears while it's being moved left or right when editing a file name. (Actually, this seems to affect almost all text entry fields in OS X.) Can you guess where the insertion point will land?
• Window sizes and positions are sporadically forgotten, or depend on the particular location from which a folder was opened.
• List view windows sometimes forget their customized column order and widths.
• Windows sometimes get stuck in positions that do not show any white space on one side of the icons near the edge, and do not offer scroll bars to correct the situation.
• The zoom widget can cause Finder windows to position themselves behind the Dock.
• The Finder window toolbar sporadically reappears, despite any number attempts to keep it turned off for a particular window.
• When the Finder window toolbar does appear spontaneously, it does so by "stealing pixels" from the window's former size. When the toolbar is dismissed (again), the window size is smaller than before the toolbar made its unscheduled appearance.
• The "shrink-to-fit" behavior of the zoom widget sometimes sizes the window to a seemingly arbitrary size that may include extraneous (or not enough) white space on one or more sides.
• Dragging a set of icons into an icon-view window causes them to move to seemingly random positions in the destination window, rather than retaining their former arrangement.

Missing Features

• Finder labels do not exist in 10.1, but are still rumored to be on the long list of things Apple plans to add in the future.
• There is still no adequate replacement for pop-up folders or spring-loaded folders. There are many alternatives, but none of them reproduce all of the functional merits of these missing features.
• The Finder's context menus remain very sparsely populated. There's not even an option to change a window's view type, or to change the desktop background.
• Font sizes and grid spacing are not adjustable. (Just had to mention that one more time.)

Dubious Features

The 10.1 Finder allows files to be copied and pasted. Or, more precisely, it allows a copy of a file to be placed in a new location, and uses the "Copy" and "Paste" commands in the Finder's "Edit" menu to do so. It does not, however, behave like Copy and Paste in any other context. For example, the data that is "Pasted" is not guaranteed to be the data as it existed at the time of the "Copy" operation. Instead, it is the data as it exists at the time of the "Paste" operation. "Pasted" files also do not replace the current selection.

Unfortunately, most users do not seem to know or care that the Copy/Paste semantics that have not changed for seventeen years on the Mac platform are being violated by this new feature. I find this extremely troubling on several fronts.

First, the fact that Apple itself is doing this is upsetting (but, at this point, not that surprising). I know Apple is trying to define a new user experience for the Mac with Mac OS X, but I don't think the Copy/Paste interface benefits at all from this new exception to its long-standing interface rules.

Second, on a much more pragmatic front, I see no reason that the same exact file copy functionality couldn't be added through a different menu (say, I don't know, how about the File menu) and implemented independent of the clipboard and the Copy/Paste interface.

The behavior presented by this feature in 10.1 makes sense, given its purpose as a method for command-driven deferred file copying. But the fact that it differs from the behavior of Copy/Paste in all other contexts is a clear sign that it deserves to be its own distinct set of commands in the Finder. Overloading Copy/Paste for this purpose makes about as much sense and using "Save" and "Print".

I'm not sure if these issues were discussed and dismissed at Apple, or if they never came up at all. But the feature in its current form in 10.1 is a disappointing sign that priorities have shifted at Apple. Yes, perhaps the interface inconsistency created by this implementation will go unnoticed by the average user. But the measure of good interface design should not be based on which gaffes can be sneaked past the casual user. It's Apple's job to create an interface that's better than what the average user might create. Apple is supposed to be the faithful keeper of the interface—the expert creator and the watchdog for consistency. Instead, they've violated the semantics of perhaps the oldest single interface on the Mac platform, either unknowingly, or in a misguided effort to duplicate Windows.

I know I'm probably in the minority with my concern over this implementation (and, more importantly, the change in thinking that it represents). But I also know that I was in the minority when I chose the Macintosh platform, with its "funny rules" about how the interface should behave, over a decade ago. I hope Apple at least considers divorcing this new feature from the clipboard and Copy/Paste.

I'm not sure if this next feature belongs here, or in the missing features section above. The 10.1 Finder claims to support SMB file sharing with Windows hosts. And it does...sort of. The user must select the "Connect To Server..." item in the "Go" menu and then type a URL in the form of "smb://servername/sharename". There is no GUI interface for browsing servers or shares (as this page might lead you to believe after a quick glance). If you get any part of the URL wrong, you are given the same generic error. It looks like this feature was rushed out the door in order to maintain a bullet point on the marketing literature. If you're looking for fully integrated Windows networking, you'll have to wait a bit longer.

(There's one more "dubious feature", but it affects more than just the Finder. It will have a section of its own a bit later.)

More Problems

While the 10.1 Finder's icon grid scales with the icon size, it is still much too wide, and remains unadjustable. This makes it less useful for arranging anything other than the icons with very long names.

Sorry, that's as close as they'll get

(Changing icon sizes also causes the icons to move, which I consider a bug rather than a feature.)

The grid problem is slightly worse than it was in 10.0.x due to the new technique used to display long file names in the limited space beneath each icon. In 10.1, long names are wrapped to two lines. This solves the earlier problem of file names with "..." in the middle of them in icon view (the problem remains in list and column view), but introduces yet more white space beneath each icon on the grid. In a window arranged according to the 10.0.x icon grid, the new double-line names overlap. But when arranged according to the 10.1 grid, the overlap is eliminated.

The 10.1 icon grid includes less horizontal space (but is still wastefully wide, in my opinion), but more vertical space (to allow for the two-line names) than the 10.0.4 icon grid.

The entire grid width issue might not be such a problem if the font used to display file names was customizable. The current font is extremely wide compared to the classic Mac OS default, and is partially to blame for both the excessively wide grid spacing and the common appearance of ellipses in file and folder names. Compare the width of the same folder name in list and icon view in Mac OS 9 and Mac OS X:

File names on the desktop are constrained to even narrower dimensions than in Finder windows. This, in combination with the new two-line name wrapping, leads to the strange sight shown on the right.

Column view does not escape unscathed either. For example, the adjustable column widths in column view are great until you try to resize a column after independently resizing another one. The independently resized column instantly returns to the same size as the other columns.

Double-clicking on an icon in the far-right pane is still a game of speedy reflexes, as the icon you want to double-click slides out from under your cursor the second you make the first click (in order to make room for the preview pane).

The sort order of each column remains unadjustable.

What Problems?

I'll stop now, because I think you get the picture. But you may think "the picture" is that of a pedant determined to find every little thing wrong with the Mac OS X finder, so let me explain.

Taken individually, the bugs and problems listed above may not seem that bad (although some are pretty troubling on their own). But they combine to thwart any attempt to recreate the interface that has defined the Mac user experience since 1984: the spatial Finder.

I've covered all of this at length before, so I won't rehash it all now. But I do find it troubling that the seemingly simple and obvious things that would finally give Mac OS X a true spatial Finder experience—things that have seemed as easy as breathing to Apple for the previous seventeen years and have never wavered in any prior version of Mac OS—seem so unattainable in the Mac OS X Finder, even after years of development and six months on the market.

Mac OS X needs a spatial Finder, and it needs it yesterday. It is second only to performance in the list of areas where OS X fails to live up to its classic Mac OS predecessors. Performance got a substantial boost in 10.1. When will a proper Finder return?

Finder Summary

The 10.1 Finder is an improvement over the 10.0.x version, but most of the gains are a result of performance improvements, not feature enhancements. The 10.1 Finder still suffers from annoying "lock-outs" during some network activities. Many long-requested features remain unimplemented: labels, better context-menus, pop-up folders, spring-loaded folders, truly integrated Windows networking, etc. Font sizes and grid spacing remain unadjustable. Only a handful of the countless bugs that plagued the 10.0.x Finder have been fixed, and some new ones have been added.

Although the 10.1 Finder provides a better overall user experience than the 10.0.x Finder, it will still frustrate users who want to use more than just the browser-style interface. The 10.1 Finder is still not able to function properly as the consistent, predictable, spatial interface to files and folders that has carried the name "Finder" for the life of the Mac platform.

File Name Extensions.section

In an earlier article, I spent a considerable amount of time discussing the history of metadata, and its role in Mac OS X. I did that partially because it's such a large topic that I didn't want it to overwhelm this Mac OS X 10.1 review. But in the time since the metadata article was written, there has been a very significant public policy clarification from Apple—one that confirms some of my worst fears about the future of metadata in Mac OS X.

In the metadata article, I wrote that Apple's Mac OS X metadata policies up to that point "seem[ed] to be based on the assumption that file type metadata will always be encoded in the file name." Sadly, I turned out to be right.

The bombshell was first dropped on an Apple mailing list, and was later formalized in the Mac OS X 10.1 release notes. You should read one of those links if you haven't already, because the exact behavior of the metadata management system in Mac OS X 10.1 is very complex, and I don't think it can be fully explained more concisely than it is already in those documents. But if it had to be condensed down to a single point, it would be this:

File name extensions are mandatory in Mac OS X 10.1

To comply with the new 10.1 metadata guidelines, all files created by Mac OS X applications must include a file name extension.

The aforementioned complexity is caused by an elaborate system of per-user, per-file, context-based file name extension hiding, conflict and confusion prevention, and a long list of guidelines for applications that create files or display file names. But the bottom line is that every new file created by a Mac OS X application must be created with an appropriate file name extension.

The reasoning behind this policy is simple. If every file created on Mac OS X has its file type information encoded in its file name, no additional action is required (on the part of the user or the OS) when a file is shared with an operating system that expects file type information to be encoded in this way (e.g. Windows).

The file name extension hiding and file name editing policies are geared towards preventing the Mac OS X 10.1 user from knowing which extensions actually exist in a file name at any given time, and preventing users from removing or changing this information. The guiding principle is described by Apple as "what you see is what you typed", meaning that the exact file name entered by the user in a save dialog box or while editing a file name in the Finder should be what is shown in the GUI. (Again, consult the official guidelines for a more thorough explanation.)

Furthermore, traditional, distinctly stored file type and creator metadata (in the form of HFS/HFS+ type and creator codes) is optional under the new policy. Application developers "may" set this information "if they wish." The only benefit Apple lists for this action is "increased interoperability with Mac OS 9 applications."

Mac OS X 10.1 Metadata in Action.subsection

The table below provides a brief taste of Mac OS X 10.1's metadata policies in action. It shows a sequence of user actions, the resulting file name (both actual and displayed in the Finder), type and creator codes, icon, application binding, and any other warnings or interactions.

For those keeping score, that's:

• four different displayed file names
• five different actual file names
• three situations where the actual file name differed from the displayed file name
• four different icons (one of which gave no indication of which application would open the file)
• three different applications that launched and attempted to open the file when it was double-clicked
• four warning dialog boxes in the Finder
• one error dialog in Preview
• two instances of garbage displayed in TextEdit

(At no time were any HFS/HFS+ type or creator codes set.)

The user actions that caused all this consisted of a "Save" from within an application and a series of rename operations in the Finder.

For comparison, a similar sequence of steps in classic Mac OS would result in:

• a single icon displayed in the Finder
• a single application launched when the file is double clicked
• a displayed file name that always matched the actual file name

Again, this was all a result of a simple save and a series of rename operations in 10.1. Yes, there were many warning dialogs, but the point is that renaming a file should not be so fraught with danger, warnings or no warnings.

Furthermore, the warning dialogs displayed in the Finder mentioned only that the rename operations may cause the document to "open in a different application." There was no mention of an inability to view the document or a loss of cross-platform portability, despite the fact that, during four of the six states in this sequence, the file would not have opened successfully on a Windows system.

Big Problems.subsection

Needless to say, there has been strong and vocal opposition to Mac OS X 10.1's metadata policy from a large portion of the Mac community. And, not surprisingly, I've been part of that opposition. I don't think anyone debates the improved interoperability that strict adherence to this policy provides. It's the prioritization of interoperability above all else that is so objectionable. The natural extension of this value system is to simply use Windows.

Apple appears to want to have it all: perfect cross-platform interoperability married to a rich, Mac-like "local" user experience. But given the current state of those "foreign" platforms that Apple wants Mac OS X to interoperate with, sacrifices on one (or both) ends of that equation are required. The 10.1 metadata policy sacrifices simplicity and control (for both application developers and users) in the local user experience in an effort to improve cross-platform interoperability. This is an unwise sacrifice for many reasons.

While interoperability may be improved, it is still not perfect. Million of files created in classic Mac OS still exist on Mac OS X customers' hard drives—files either without file name extensions or, worse, with file names that may appear to have extensions. And don't forget about files that have resource forks, which will require encoding for safe passage to and from other platforms, with or without file name extensions.

The ability to choose file names that are meaningful to the user rather than the OS, and to have complete control over those file names (not just the illusion of control), has been a hallmark of the Mac user experience since 1984. It's also been one of its biggest advantages. If Mac users truly valued interoperability above the local user experience, they would not be using Macs in the first place.

If this sacrifice of a significant historic advantage of the Mac platform is meant to attract more users from other platforms, it is doomed to failure. First, the change alienates a substantial portion of the current Mac user base, so many of them will have to be replaced with platform converts to merely break even.

Second, in the grand scheme of things, mandatory file name extensions are a drop in the platform-convert bucket. Converts to the Mac platform would still need to purchase all new hardware, all new software, learn a new operating system, convert, transfer, or lose thousands of existing files, and then deal with all the remaining disadvantages of their new platform: fewer hardware choices, a smaller software selection, more expensive hardware, etc.

Furthermore, the "payoff" for this conversion consists of all of the historic advantages of the Mac platform that had failed to attract this user in the past, minus one of the biggest advantages that was just sacrificed in an effort to cause the conversion!

If the new policy is meant to improve the user experience for the current Mac user base, feedback on this issue to date clearly demonstrates that it fails to do so for many Mac users.

Ironically, the new policy hurts interoperability with the platform most likely to be encountered by Mac OS X users: classic Mac OS. Files created without type/creator codes by Mac OS X applications may not be usable in classic Mac OS, or in Mac OS X's own classic environment.

Worse, the 10.1 metadata policy also effectively closes the door on many possibly future metadata policies by not requiring that all possible metadata be written to every file created on Mac OS X. Less metadata means fewer possible interpretations, and therefore fewer possible policies for application binding, icon display, and so on, in the future.

Solutions

The obvious solution is for Apple to come up with a new metadata system for Mac OS X that improves interoperability while also retaining all of the advantages of the Mac Way. This new system should be backwards-compatible with type/creator codes, but should be an entirely new implementation that goes beyond the limitations of its predecessors. Hypothetical feature of this new system might include the use of BeFS-style extensible file system metadata, MIME types, Java-style (e.g. "com.adobe.Photoshop") application identifiers, etc. The interoperability of this new system, while important, should never come at the cost of the local user experience.

That's a tall order, of course, and no one expects such a system to spring, fully formed, form the forehead of Apple (especially when they're apparently still struggling with retaining window and icon positions in the Finder. Sorry, low blow ;-) But there is a simpler interim solution that requires much less work.

Start with the Mac OS X 10.1 metadata policy, but make the following changes:

• All Mac OS X applications must write HFS/HFS+ type and creator codes when creating a file.
• Make the application binding policy user-configurable. Include preset configurations that correspond to the traditional Mac OS and Windows policies, and allow custom policies to be created by the user that reference (or ignore) metadata of the user's choosing when determining which application a file will open in, and which icon will be displayed for that file in the Finder.
• Add "metadata services" APIs to the OS for converting to and from various metadata representations: appending the appropriate file name extensions (based on other file type metadata, or even the file contents), or removing file name extensions (setting other file type metadata as appropriate). These APIs would reference a per-user, user-configurable metadata representation mapping table.
• Change the standard open/save dialog boxes to leverage the new metadata services APIs, and provide both system-wide and per-application preferences for each user to control which applications append file name extensions by default, and which don't. All open/save dialog boxes should have a checkbox to allow the defaults to be overridden on a per-file basis.
• Add menu commands and context menus to the Finder that use the new metadata services APIs to allow the user to convert selected files (or folders full of files, or entire volumes full of files) to and from different metadata representations.
• Change any applications or system services that currently depend on the presence of file name extensions to also understand file type metadata stored in locations other than the file name.
• Make the entire file name, including any extension, visible and editable at all times.

To improve interoperability, a future version Mac OS X that includes the changes listed above could ship with default settings that correspond closely to the current 10.1 behavior: the system-wide option to append file name extensions could be on by default, and the customizable binding policy could be set to match the 10.1 behavior.

Such a system would have nearly all of the interoperability benefits of the 10.1 policy, while also providing experienced Mac users who are both willing and able to manage interoperability on their own with the ability to do so—while retaining complete, simple, direct control over all file names. The new metadata services APIs and their use in the Finder and standard open/save dialog boxes would provide even more power to experienced users, freeing them from some of the more tedious manual conversion tasks.

Metadata Conclusion.subsection

The metadata policy in Mac OS X 10.1 is complex in its implementation (sometimes to the point of being mysterious), misguided in its apparent motivations, and does not live up to the quality of the traditional Mac user experience that it intends to replace. Furthermore, it will make future improvements more difficult as files created with "partial metadata" by Mac OS X applications that adhere to this policy proliferate.

I'd like to paraphrase something I wrote in the metadata article because the sentiment seems even more apt in light of the current situation:

There is a feeling in some parts of the Mac community that the advantages of using a Mac are being eroded slowly by Mac OS X. Given Apple's tiny market share, compromises are often necessary to maintain acceptable levels of interoperability. But in cases where alternate solutions provide similar interoperability improvements without sacrificing favorable aspects of the Mac user experience, Apple should do everything in its power to implement them as such. Any part of the Mac OS user experience that duplicates the experience on another platform ceases to be a compelling reason to buy a Mac.

Stability and hardware support

Stability in 10.1 has been comparable to 10.0.4—that is to say, excellent. The same caveats about actual stability vs. perceived stability still apply to 10.1. I haven't run it long enough to know if user interface death is more or less of a problem in 10.1. There is still no way to recover from a total UI crash without another computer from which to connect and kill processes. A hardware-based interrupt system (something like "virtual consoles" on other Unix variants) that was guaranteed to remain accessible during anything short of an actual kernel panic would go a long way towards getting Mac OS X over that final stability hump.

I don't have access to enough hardware to know how much hardware support has improved. My serial printer (attached to an adapter in the G3's internal modem port) is still not supported, nor do I really expect it to be in the future. Networked laser printers accessible from the G4 worked in 10.0.x, and continue to work in 10.1. But 10.1 still does not include the proper PPD files for several of the LaserJet printers on the network.

As mentioned earlier, the Displays preference pane still does not list all of the supported refresh rates for the G4's monitor, forcing me to use a slower refresh rate in OS X than in OS 9.

On the G3, a series of repeating console messages cause delays in both startup and shutdown. They look like this:

Sep 23 14:57:26 localhost mach_kernel: ADPT_OSI_IndicateQueueFrozen: id 5, freeze
Sep 23 14:57:26 localhost mach_kernel: ADPT_OSI_IndicateGenerationChange (nop)
Sep 23 14:57:26 localhost mach_kernel: ADPT_OSI_IndicateQueueFrozen: id 5, unfreeze
[repeat many times]

My only guess is that they're related to the G3's cable modem, SCSI card, or ATA/66 card. These messages do not appear at all on the G4.

Enhancing Your 10.1 Experience

Here are a few of the third party applications that I find beneficial to my Mac OS X experience. The first is ASM, an application-switcher menu replacement that also includes an option to change the OS X window layering policy to be per-application (like classic Mac OS) instead of per-window. ASM is implemented as a "Menu Extra" (despite Apple's refusal to make these APIs public—way to go, Frank!) and includes its own preference pane.

(Mercifully, Apple has seen fit to make the preference pane API public. But I'm not sure how the System Preference application plans to handle what is sure to be a flood of new preference panes. There's not a scroll-bar to be found in the System Preferences application, and that window can only get so big...)

DragThing provides an example of what the Dock could have been, allowing an arbitrary number of highly customizable, moveable, achorable Dock-like palettes. I simply use it to recreate the classic Mac OS application switcher palette, but it is capable of much more.

Classic Menu provides a user-configurable Apple menu for Mac OS X. Unfortunately, it must use the "hack" method of drawing directly on top of the existing Apple menu, and it therefore does not interact with other menus in the expected way. But it's the best option so far for users who miss the functionality it provides. (Bonus points for including an optional rainbow-striped Apple icon :-)

Finally, TinkerTool prvides a convenient interface for many of settings that were previosuly adjustable only from the command line: Dock pinning, Terminal transparency, finer control over font smoothing, etc. It is also implemented as a preference pane. The version that is compatible with Mac OS X 10.1 is still in beta, however.

Miscellaneous

Mac OS X 10.1 includes attractive new transparent overlays that appear in response to the dedicated volume control keys on the new Apple keyboards, then "fade out" when they're done:

Volume control overlay

The F12 key doubles as the dedicated "media eject" key on all Macs running 10.1, not just portables which require this functionality. This means that desktop Macs with one of the new Apple keyboards now have two eject keys on their keyboard. Worse, accidentally hitting the F12 key during, say, a CD burning session can produce coasters in some situations, so be careful. (This is a known bug.)

A "CrashReporter" daemon is running by default in 10.1. Its purpose is to write crash reports to per-user log files. It is controlled through the Console application, and does not create crash logs by default.

On the Unix side of 10.1, the new compiler toolchain has thrown a monkey wrench into the build processes. Traditional Unix applications that once built flawlessly on 10.0.x now require significant tweaking to build on 10.1. The main culprit seems to be the new two-level namespace linking option, which is enabled by default in 10.1. While this new featue stands to enable programs that produced run-time symbol conflicts in 10.0.x to build and run successfully on 10.1, at this early stage in 10.1's life cycle, it is causing more build problems than it solves.

10.1 supports CD-R, CD-RW, and DVD-R burning from the desktop—provided you're using a supported configuration (usually a Mac that shipped from Apple with one of those drives in an internal bay). I do not have a supported configuration (external SCSI CD-RW on the G3, internal DVD-ROM on the G4) so I could not test these features.

AppleScript support has been greatly enhanced in 10.1. Many of the new abilities of AppleScript in 10.1 were demonstrated during the keynote speech at the 2001 Seybold publishing conference. AppleScript has been elevated to first class status among the programming languages available on Mac OS X. Complete Mac OS X native GUI applications can be created using the new AppleScript Studio development environment.

On a slightly personal note (I use Perl in my day job), 10.1 still ships with perl 5.6.0 rather than 5.6.1, which has been the latest stable build of perl since February, 2001). It's understandable that 10.0, released in March 2001, shipped with 5.6.0, but 10.1 should have come with 5.6.1.

Apple is also reported to have a Cocoa-to-Perl bridge functioning in-house, but not released. There is already a petition online asking for the release of this code. If AppleScript can do it, why not Perl too?

Conclusion

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

But 10.1 improves on 10.0.x in many important ways. Overall system performance shows the biggest improvement, but it is not as drastic as some reports may lead you to believe. Other areas have stagnated. The user interface has not made significant strides since 10.0.x. Many annoying bugs remain, and many features have yet to be implemented.

Should you purchase Mac OS X 10.1? If you already use and enjoy Mac OS X 10.0, you should run out and pick up a free 10.1 upgrade CD at your local retailer as soon as possible. If you tried 10.0.x and found it somewhat lacking, I recommend at least giving 10.1 a try to see if the improvements are enough to push you over the edge. If you are waiting for the point of no return, where Mac OS X is a complete no-brainer upgrade from Mac OS 9, you'll have to wait a little longer. If you plan to run Mac OS X full-time, you should consider upgrading your RAM to what were previously through of as obscene levels (512MB or more). It will be the best thing you can do for Mac OS X, short of buying a faster Mac.

If you're not a Mac user at all, but are intrigued by the possibilities of Unix based operating system with friendly user interface (Linux fans, no flames, please), 10.1 is as good a version as any to dip your toe into. Windows users should not expect a feature set remotely comparable to Windows XP, but Mac OS X is different enough that it should still broaden some horizons. And Linux users might want to see how another operating system has chosen to build a GUI on top of a Unix core.

To amend my earlier sentiment, it might be more accurate to say that I want to believe not just in Mac OS X, but in Apple itself. I want to believe that they can produce the next insanely great platform: a powerful, stable OS with an interface every Mac user can love, running on stylish, high performance hardware. Both the software and the hardware end of that dream currently need work. And so the waiting game begins again, as Mac users settle in with 10.1 and prepare for the inevitable 10.1.x updates. Will there be more 10.1 users than there were 10.0.x users? Probably. But it says something about this supposed "mainstream release" of OS X when Apple itself is still selling all its hardware configured to boot into Mac OS 9 by default.

I want to believe. But it looks like I'll have to wait a bit longer.

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

0 Comments