Unix and OS X

Apple's trying to bring the power of Unix to the masses. But that power comes from a variety of things, and making them all conform to a Mac-like user experience will not be easy. After all, there are good reasons the masses don't already use UnixŠ

In many of the discussions of Mac OS X, the phrase the "power of Unix" has been brought up. In general, however, it's never made clear what that power really is. Nobody doubts that Unix is powerful; variants of it run the machines that require high reliability and handle heavy loads, like those devoted to scientific work and serving web pages. But that power comes at a price: Unix has never been noted for being user-friendly, and it suffers from organizational issues resulting from attempts to keep it compatible with 25 years worth of software developed for it.

Apple's got to balance several competing interests in creating OS X. Can it change some of the awkward directory structure and obscure file names typical of Unix systems while retaining the ability to run software designed for its other versions? Can they bring the software that provides a lot of the functionality of Unix to OS X without causing hassles when users try to manage them? It's not going to be easy to keep the OS powerful and flexible without exposing users to the bewilderment and frustrations that managing a Unix system can bring.

The Power of Unix

So, what is the power of Unix, anyway? The simple answer is that it's in the preemptive multitasking, protected memory, and fast virtual memory that lets a Unix system handle many tasks in a fast and stable manner. There's no question that, by using the Mach microkernel as the basis for OS X, Apple's going to bring all of these features to every Mac application. And that is also an unquestionably good thing. It may take some time for applications that are used to hogging memory and processor time to be adjusted, but most things will run a lot more smoothly under OS X.

As usual, however, the simple answer doesn't even come close to explaining the entire situation. A lot of the power of any Unix system doesn't come directly from these basic features of the OS, but rather from what these features allow. The features described in the paragraph above let a large number of programs (or, in Unix parlance, processes) to run smoothly at the same time. Over the years that Unix has been around, people have found that it's better to add a feature to the OS as a process rather than to build it into the operating system itself. Many of the features that are added to the current Mac OS via extensions to the operating system will be added to OS X via individual processes. Unlike the Mac, where a poorly written extension can lock the OS with a freeze or crash, a poorly implemented feature in Unix usually results in the death of the process that provides the feature. The system as a whole remains stable.

A related part of the power of Unix is that one basic Unix OS will provide a similar set of features and programming interfaces to any other basic Unix OS. Thus, it's easy to modify the code for a process or utility program that was designed for one type of Unix so that it will work on another type. The result of this is that those programs and utilities that have been found to be useful are available for almost any flavor of Unix that's out there. For example, Apache web server software runs on Linux, OS X Server, Solaris, all the BSDs, etc. Since OS X will have full compatibility with BSD Unix, it will be quite easy to get a lot of the utilities that work there running on OS X.

Because of this emphasis on individual pieces of software (a typical Unix system), there is a small horde of processes running at the same time. Web and FTP servers run all the time in the background (they're called daemons because of their constant activity). Most users typical require a half-dozen more processes running just to get anything done. A typical Unix GUI acts via a whole collection of processes--one to draw the windows, one to manage files in response to the actions in the windows, etc. Even something simple, such as auto-mounting Zip disks when they're inserted, is handled by a small process (if it's handled at all). If any of these go sour, the rest of the system usually carries on, unperturbed.

Power at what Price?

Unix compatibility will open up a whole new world of capabilities for Mac users, but it's going to require a careful balancing act for Apple and those who administer OS X systems. To begin with, a typical Unix utility does not have an interface that a Mac user would be comfortable with--if it has an interface at all. Many of them can only adjust how they function based on modifiers that are typed in during launch. An example of this is the "ls" command, which lists the contents of a folder. Simply typing "ls" gives the name of all the visible items in a given folder, while "ls -al" lists every item in the folder, along with several of the properties of the files. Those utilities that do interact with the user often do so via text-based interfaces, something no Mac user should have to deal with. Deciding which utilities are worth bringing to the average Mac user and then modifying them to work via a visual, Mac-like interface will require a substantial effort.

Splitting what Mac users view as a unified system into a small host of processes also introduces another layer of complexity: managing these processes. Someone is going to have to decide whether to fire up a web server after the machine boots, and there's going to have to be a convenient and intuitive mechanism for acting on that decision. In addition, OS X is going to be a multi-user system; the system's administrator is going to have to decide who gets access to what utilities. Different users may also require different features when they use the OS, so that different processes might be launched or terminated when a user logs in or out.

There are other aspects of process management to consider. As I mentioned above, splitting essential tasks into small processes helps enhance the overall stability of the system, but it doesn't keep a bit of bad code or an unexpected situation from freezing or crashing any one of those processes. This can have serious consequences. Using a GUI on a Linux system, I once managed to crash the process that managed files. The rest of the interface carried on as if nothing had happened, but suddenly all attempts to move files via the GUI failed to accomplish anything. I didn't even find out what had gone wrong until I rebooted the machine. OS X may face some similar issues. What happens when somebody manages to crash his portable's Dock? Until it's restarted, users have lost what's going to be their primary method for interacting with the computer. What if somebody sends the process that mounts removable drives into an infinite loop? There's got to be a simple and intuitive method for killing it off and restarting it, or the computer will have to be rebooted before anybody can get at a Zip disk.

The result of all of these issues is that a lot of effort and thought will have to go into the tools that are provided for managing the processes and utilities which form such a large part of the power and stability of Unix. In the end, the problem boils down to an issue that Apple's always faced: how to shield users from the worst of the complexity while still allowing them to adjust their computers to best handle their needs. The tools will have to allow a beginners accomplish what they need to, allow the administrator of a multi-user system to customize the system for the needs of its users, while still allowing those users to handle minor problems without calling the administrator down. But the problems of using Unix as the basis for the Mac OS don't end there.

The problems of Unix

Managing the processes is hardly where the bad side of running Unix daemons and utilities ends, though. Unix systems and the programs that run on them do not expect to find a coherently organized directory structure with reasonably intuitive names, such as the Mac OS currently has. As a legacy of the years where Unix systems were strictly text-based, most of the names of files and directories are shortened to the point of being unintelligible. The file that determines which partitions are mounted at bootup is found in a directory called /etc and is named fstab. There is an invisible file in the home directory of each individual user called .xinitrc that determines which of the many Unix window managers that user can access.

Apple will almost certainly take some action to rename a lot of these files and directories, and their redesign of the system may make the use of others obsolete. This may make a Mac user happy, but it may also make some of the Unix utilities freak out when they go looking for critical files. There are two solutions to this problem, and both have disadvantages. The first is to rewrite the Unix program to work with OS X's file naming conventions. This may not be too difficult, but it has the consequence of making the new programs' code diverge from the code used for other versions of Unix. This can result in the Mac version falling behind other versions in terms of features and performance. An alternate method, and one thats been used often in the past, is to put the Unix equivalent of aliases, called links, in all the places programs typically find the files they need. Thus, the /bin directory is linked to /sbin and X11/bin, since similar files show up in all three locations. The unfortunate consequence of this, though, is that the links make an average Unix systems directory structure an unstructured mess. Although a program may be able to find the files it needs, the uninitiated user probably won't.

The Mac OS has solved problems like this via the Preferences Folder and the Desktop Database. Programs know to find configuration in the Preferences Folder, and the Type and Creator codes of a file can help applications link up with the files they need. A benefit of this is that a Mac system allows users to arrange most files and programs in whatever way they feel is best. Unix, which lacks similar mechanisms, generates situations where moving or deleting the wrong file can bring a program, or the whole system, to its knees. As noted above, the wrong file might be named something as innocuous as fstab. Mixing Mac and Unix programs on the same system brings up further issues. Most Unix programs don't know how to interpret things like type and creator information or a resource fork; some of them can't even read the files' contents properly because all that extra information confuses them. All of these things make it unlikely that moving a Unix application to OS X will be a smooth process itself, or that OS X will have all the power of other Unix systems.

In the end, there are a lot of things that require balancing. How much of the power of Unix can Apple bring to OS X without making the system as difficult to manage as something like Linux? Will people be able to re-work existing Unix programs to give them a decent interface while still keeping them up to date with other Unix systems? How Apple handles these issues, and how well they respond to the suggestions and complaints of the people who will be using them, may go a long way towards determining the success of OS X.