mac.column.ted: Mac OS X, UNIX, and the "average" Mac user

by Ted Landau
September 2004

Apple makes no secret of the fact that "beneath the surface of Mac OS X lies an industrial-strength UNIX foundation." It's touted on an Apple Web page titled, appropriately enough, "Based on UNIX." What is somewhat less clear is exactly what this implies for the typical or average Mac user. By "typical" or "average," I mean the Mac user who is about as interested in delving into UNIX as the average mobile phone user is interested in understanding the "beneath the surface" technologies that allow them to make a call. These are the Mac users who want to use Microsoft Word to write a report or iTunes to download music, without needing to understand much, if anything, about how all of this magic actually happens.

I contend that if these typical Mac users are ever expected or required to work with the UNIX layer of Mac OS X, it represents a failure of the OS. In particular, these Mac users should virtually never be required to launch Terminal (Mac OS X's main window to its UNIX underlayer). Terminal employs a UNIX command-line interface that is the antithesis of what the Mac is all about. Instead of a mouse-driven interface with commands that can be accessed from menus and dialogs, you have to type out all commands. And some commands have so many options that it could take days just to figure out all that a given command can do -- and even longer to remember these options without needing to recheck a manual each time.

Now, none of this would matter if it was never necessary for users to access Terminal unless they wanted to do so. In such a case, to complain about Terminal would be like complaining that the average Mac user could not use most of the software included on the Xcode Tools (Developer) CD. Who cares? It's not intended for the average Mac user.

Given this standard, how does Mac OS X stack up? Overall, very well. I estimate that most Mac users could use a Mac for months (maybe years!) without ever confronting a problem that required Terminal. And this is much more true now than it was when Mac OS X was first released.

There are two major reasons for this welcome evolution:

• With each Mac OS X revision, Apple has worked to eliminate bugs and quirks that would otherwise require a trip to Terminal to resolve. Apple also continues to add to and improve the Aqua-based utilities that provide alternatives to Terminal, such as Activity Monitor, Network Utility and Printer Setup Utility. The Finder's Get Info windows and Panther's new Authenticate dialog also provide simple interfaces to accomplish tasks that would otherwise require using Terminal.
• Third-party (primarily shareware and freeware) developers continue to deliver a cornucopia of Aqua-based utilities that provide simple user-friendly interfaces for UNIX-based tasks. Utilities such as FileXaminer, XRay, Cocktail, Xupport, Carbon Copy Cloner, and SharePoints are just some of the more well-known examples.

"But wait a minute," you may be saying at this point, "That typical Mac user you were talking about probably would want to avoid utilities such as Network Utility or SharePoints almost as much as they would want to avoid Terminal." True enough. But if they ever do need to solve a problem that requires changing permissions, for example, it's nice to know that they can do so using the Finder or Mac-like utilities such as FileXaminer, rather than having to master UNIX's chmod command.

Still, it is at this point that I find myself drifting toward another important category of Mac user, the one who would like to do their own troubleshooting, as much as possible, but without having to become a computer "expert." These users have been the main target of the books I have written. It has always been my contention that one of the virtues of the Mac is that even relatively non-technical Mac users could learn to fix almost any software problem with their Mac. All it took was a relatively small collection of basic skills and easy-to-use software. Mac OS X's foundation of UNIX challenges this contention.

For better or worse, and despite the above-mentioned utilities, I believe that effective Mac OS X troubleshooting still requires a familiarity with the basics of UNIX and Terminal. Troubleshooters should at least know the commands for listing and navigating through UNIX directories, as well as deleting and copying files. They should also ideally be familiar with many of the commands that serve as the back end to Mac OS X software. For example, it would be useful to know how to use the ipfw command to expand on the Firewall options available from the Sharing System Preferences pane. Or how to use diskutil to expand on the features available in Disk Utility. The good news is that much of this knowledge can be acquired on a "when you need to know it" basis, and is not nearly as onerous a task as, for example, picking up Mac OS X Unleashed or UNIX Power Tools and trying to master everything contained between their covers. If you want to delve into the depths of UNIX on a Mac, there are certainly benefits to doing so, but you can be an effective Mac OS X troubleshooter without such knowledge.

Despite this overall rosy picture, there are still a few flaws in the canvas. One gripe is that Apple, in its Knowledge Base documents, too often relies on Terminal-based solutions for common problems that even a beginning Mac user might face. Perhaps the most notable example is the procedure Apple describes to change the short name of an account. This is a frequent request (especially from users who did not realize, when they first set up their Mac, that they were choosing a nearly "permanent" name). The procedure to change the name takes 40 steps, some of which involve UNIX's chown command. Come on. Apple can do better than that. Fortunately, my colleague Dan Frakes has provided a better solution: A utility that changes the name in essentially one step. It's what Apple should have done!

Another example is a Knowledge Base article that explains what to do if you "cannot print, use Classic, start file sharing, burn discs, or update software." This is a fairly serious set of symptoms. It turns out the source of all of this trouble is an inadvertently deleted alias (actually a symbolic link, in UNIX-ese) to UNIX's tmp directory. The solution is to create a new link file. Admittedly, most users will never find themselves in this jam, as the symbolic link is normally invisible (and thus difficult to accidentally delete). But if Apple is going to provide a solution, they could do better than telling users to deal with Terminal commands such as ls -la / | grep tmp.

Actually, there are ways to bypass the need for Terminal here: you could use the Finder's Find command to check if the invisible tmp file exists (set the criteria as: Name is tmp, Visibility: invisible items, Kind is alias), and then use a utility such as Cocktail to create the new symbolic link and a utility such as FileXaminer to make it invisible, if needed. But this, too, is a bit awkward. An easier solution would be for Apple to have provided a simple utility to create the missing link. Written in AppleScript, this would have taken hardly any work at all to develop. It's the sort of thing Apple would have been obligated to do for the Classic OS. Now Apple is more willing to use Terminal as a crutch to avoid even the minimal effort needed for such solutions. Apple could still include the Terminal-based solution in its support document, for those who prefer that route, but at least it would not be required.

The most extreme example I have seen of Apple's over-reliance on Terminal was their solution for a situation where you could not get any USB or FireWire devices to work. This symptom first cropped up with some users after updating to Mac OS X 10.3.3. In other words, it could happen to anyone, not just an advanced user mucking around with things they should have better left alone. I won't detail the full extent of Apple's suggested solution, but here is a critical excerpt:

• Open the Terminal (/Applications/Utilities/).

• Type: kextstat | grep -v apple

  Some text, or "output," appears.

• Type this in Terminal, on one line:

  grep -rl {Name from the last section} /System/Library/Extensions

  Instead of "{Name from the last section}," you'd type the text that's before the numbers in parenthesis (in the output).

  For example, substituting com.SuperDuper.driver.HIDDevices for Name from the kextstat output means you'd type:

  grep -rl com.SuperDuper.driver.HIDDevices /System/Library/Extensions

• What you'll get is an output relevant of .kext files that reside in /System/Library/Extensions, like this:

  /System/Library/Extensions/SuperDuperUSBHIDevices.kext/Contents/Info.plist
  /System/Library/Extensions/SuperDuperUSBHIDevices.kext/Contents/MacOS/SuperDuperUSBHIDevices

  [In case you don't know, here is what these commands are doing: The first typed line results in a search through all of your currently active extensions, displaying the status of those that do not come from Apple (or more accurately those extensions whose "name" does not contain the word "apple"). These are thus files that were installed by third-party software and are the likely candidates for causing the problem. Unfortunately, the output of the command does not include the actual names of these kernel extension (kext) files as found in the Finder. That's what the second command provides.]

  At least one of the identified kext files is the likely culprit. The solution is to remove the culprit from its current location. To do so, you have to do something that Apple generally advises users not to do: remove files from the /System directory. While Apple explains how to do this removal, it only indirectly notes that problems may still remain unless you replace the removed file with an updated one available from the third-party vendor.

Whew! If this problem happened to my mother, and she called me for advice, Apple's solution is not what I would want to have to explain -- at least not if I wanted to be off the phone in less than 24 hours. Grep? Kext files? Directly messing with the System folder? Give me a break. Again, Apple should have come up with a small utility that automated all of this. The utility should locate and list all the potentially culprit files after clicking a Check button. You should then be able to select or deselect a checkbox for each kext file, to either remove or return the file from/to its default folder.

A more global solution would be for Apple to create an extensible utility, perhaps named something like Simple Terminal, that provides commands, selectable via typical Mac OS X menus and dialogs, for all the troubleshooting tasks that would otherwise require using Terminal. Via plug-ins, Apple (or other developers) could expand the utility's repetoire as needed.

To be fair, Apple eventually provided a better solution to the kext problem: update to Mac OS X 10.3.4. This and later versions of Panther (once they became available) eliminated the symptoms (which is why the above excerpted text is no longer found in the relevant Knowledge Base article). But a similar problem, requiring a Terminal-based solution, could crop up again in a future version of the OS.

Finally, I have a gripe for which Apple cannot be blamed. This involves those UNIX folk who, failing to recognize the availability of simple Aqua-based solutions, persist in offering Terminal-based solutions instead, even to obviously beginning-level users. Such "helpers" appear to view UNIX as the true Mac OS X, with the Aqua interface as an optional graphical overlay to be accessed only when absolutely necessary. As one example, there was a posting on Apple's own Discussions boards recently that asked how to quit a frozen application when the Finder's Force Quit command does not work. In some cases, it was noted, the only solution is to reboot (because the freeze appears to affect the Finder itself and perhaps all other applications). However, to avoid rebooting and assuming the freeze is limited to just the one application, one respondent suggested launching Terminal and using the ps -aux command to identify the PID (process ID) of the frozen application. Then use the kill command with the PID to quit the process. But wait! Why not instead first give Activity Monitor a try? Select the frozen application from Activity Monitor's list and then select Quit from the Process menu -- a simpler, more Mac-like, and easier to remember solution that effectively does exactly the same thing. Even simpler, in some cases, just force quitting from the Dock works, even when the Finder command does not.

But I don't want to get too carried away here. Mac OS X's UNIX underpinnings provide numerous well-documented advantages, offering features distinctly lacking in OS 9. And the ability to use Terminal to access those UNIX features provides a more accessible and open window to the OS than ever existed in the Classic Mac OS. If you make the effort to learn how to use Terminal, you will be amply rewarded. Overall, I applaud the way Apple has integrated UNIX into Mac OS X. All I am suggesting is that, for the vast majority of Mac users, Terminal should remain an option, not a requirement.

A word about the iMac G5

The design of Apple's new iMac G5 is quite appealing. Harking back a bit to the design of the 20th Anniversary Mac, the entire computer fits into the monitor case. As a troubleshooter, I find one of the iMac's best new design features is its removable back cover. As seen in the photograph below from Apple's iMac site, and confirmed by this Apple Knowledge Base document, you can access (and even replace!) virtually every component of the iMac.



What a pleasant change from previous iMacs. In those older models, accessing components other than memory and AirPort cards, was not merely difficult -- it was almost impossible for mere mortals to do.

Removing the iMac G5 back cover also gives you access to a new Mac feature: four diagnostic lights on the main logic board that can "help you to troubleshoot." For example, "LED 1 indicates that trickle voltage from the power supply has been detected. This LED will be ON when the computer is turned off and your power supply is working correctly." Unfortunately, Apple is a bit vague about how you should use these lights. Clearly, they only work when the iMac is plugged in and turned on. However, in instructing you how to remove the cover so you can see these lights, Apple states: "Turn your computer off and disconnect all cables and the power cord from your computer." It never states when it is safe to turn the iMac back on (although I am assuming you do this when all the prior steps have been completed).

This is the latest in a series of monthly mac.column.ted articles by Ted Landau. To see a list of previous columns, click here. To send comments regarding this column directly to Ted, click here. To get Ted's latest book, Mac OS X Help Line, click here.

Resources


• More from Mac Musings