UNIX under the Desktop

When Steve Jobs introduced Apple's new iMac in January 2002, the spotlight was focused entirely on the physical architecture of the first mainstream computer that fully defied the term “box”. The new iMac is a white dome with a flat screen that floats on the end of a chrome arm. It looks like a cross between a Luxo lamp and a makeup mirror. Jobs called it “the best thing we've ever done”.

Coverage—including a TIME magazine cover story—was all about hardware. Nobody paid attention to Steve Jobs' slickest move of all, which is leveraging UNIX where it counts. Starting in January 2002, every new Mac will ship with OS X as its default operating system. OS X is built on Darwin, an open-source implementation of BSD on a Mach kernel. So now every new Mac is a Trojan horse that arrives with an invisible army of UNIX experts.

Regardless of the technical and religious differences that separate the many breeds of UNIX, expertise at one ports well to another: from Solaris to HP-UX to AIX to Linux to BSD to Darwin and OS X. If you want to hack, the environment is there—so are the tools and the community.

Put another way, OS X gives us the first popular desktop OS that fits into a prevailing Linux environment and also into the prevailing marketplace. On the bottom, it's UNIX. On the top, it runs Microsoft Office and the whole Adobe suite. This has its appeals.

In iDevGames.com, Aaron Hillegass writes:

The social effects of OS X on the Open Source community were already apparent at the O'Reilly Open Source Convention in July 2001, when slab-like Macintosh G4 Titanium laptops seemed to be everywhere. At one Jabber meeting, four out of the seven attendees tapped away on TiBooks, including Jabber's creator, Jeremie Miller. Terminal windows were scattered across his screen. When we asked what he was doing, he replied, “compiling code while I catch up on some e-mail”.

The growing abundance of OS X fruit on the UNIX tree creates new and interesting market conditions for Linux, along with every other UNIX branch. There are sales projections for six million iMacs alone. Many of these machines will be penetrating markets where Linux has strong incumbent server positions, such as science and education. Lawrence Livermore National Laboratory was once Apple's biggest customer and might easily reclaim the title. In January 2002, the state of Maine announced its intent to give a new iBook to every teacher and student in the seventh and eighth grades. All those kids will have their own UNIX machines. Consider the implications.

Is there a server market for OS X? It's worth noting that OS X Server has existed as a product for more than two years and has never attracted much attention. Also, while every new OS X Mac is ready to perform a variety of server functions, that's not why it sells. IT Manager and Mac columnist John C. Welch calls OS X an “okay server, mostly due to hardware limitations and immaturity”. Meanwhile he says, “Linux is an excellent server. It runs on more and better hardware than Windows can ever dream of, thanks to IBM and Sun.” So OS X is no threat to Linux in the server space. And it's utterly absent from Linux's other home turf, embedded computing.

Where OS X will succeed is in the one category where Linux has struggled for popularity (if not functionality) from the start: on the desktop.

Is this a problem? That was the question at the top of our minds when we visited Macworld in January 2002. To our surprise, the answer was quite the opposite. Not only were plenty of familiar Linux figures walking around kicking tires (approvingly, it appeared), but there were UNIX geeks wearing Sun and SGI schwag as well. One Linux hacker told us OS X was “subversive” because it “seeds” the world with millions of open-source UNIX machines. Another said, “I can go to my Mom's, fire up her iMac, open a shell, ssh to my own server and get some real work done.” So the market logic of Linux and OS X appears to be AND, not OR.

Apple also has attracted some top talent from the open-source ranks. Brian Croll, who runs OS X engineering for Apple, was recruited from Eazel. Jordan Hubbard, the world's foremost BSD hacker (and a founder of FreeBSD), actually pitched his way into a job working on Darwin at Apple. After seeing OS X in preview form, he said “Hallelujah” and “This is what I've been waiting for the past 20 years....I never thought about working for Apple before, and now I was saying, How do I join?”

Working with the Open Source community is still new for Apple, and the relationship has been a challenge to the company's highly proprietary approach to intellectual property. But Apple has compromised on some issues. After hackers barfed on Apple's original public source license, the company issued a new one that the Open Source Initiative soon approved. Shortly after the new license was issued in January 2001, OS X product manager Chris Bourdon summarized it this way: “You can take Darwin and do anything you like. It's there for everybody.”

We first tried OS X when it entered public beta in November 2000. At that time nothing in the last paragraph was anywhere in sight, and the new public source license was more than a month away. It was vastly different from the “Classic” Mac OS (which it ran under emulation) and from other desktops on both Linux and Windows. It was pretty, but also slow and notably devoid of drivers for CD-ROM burners, DVD players and other peripherals essential to the modern desktop computing experience. If we had reviewed it then, as we had planned, our thumbs would have pointed toward the floor. And we wouldn't have been alone. “Frankly, I think it's a piece of crap”, Linus Torvalds wrote in his book, Just for Fun, which was also in the works around that time.

Things got better the following spring, when Apple released the 1.0 version of the OS. But it was still slow and some key drivers were still lacking. In September 2001, version 10.1 was released with kernel version 1.4.1, which by all accounts was vastly improved. Soon plenty of drivers showed up, reports of kernel panics fell below noise level, and the OS was ready for prime time.

Since then a good thing has become steadily better, thanks in large part to what the open-source geeks have brought to the table. XFree86 and XonX brought the X Window System to Darwin. Fink used Debian tools like dpkg and apt-get to build a package manager. Their site lists hundreds of available packages. In fact, you don't even need to run Darwin on Apple hardware, since an x86 version is available as well (from Apple, even). GNU-Darwin is already the leading non-Apple Darwin distribution. Watching all this happen, our thumbs began rotating toward the ceiling.

Then last week we put OS X on a Titanium laptop. It blew our minds.

When we plug in a second monitor (or a projector), the OS autodetects it, then lets us decide whether to make it mirror the laptop screen or operate as a contiguous extension anywhere on all four sides. When we plug in a FireWire drive or a USB storage device (such as a camcorder, an MP3 player or a digital camera), the device shows up on the desktop, in the appropriate applications and in the directory. When we soft-eject the FireWire drive, it goes away, unless something requiring it is in use—in which case the OS gives me a warning or a rebuke, never a crash.

Installing OS X (now at 10.1.2) was a snap. It immediately ran every one of several dozen Classic Mac applications that were already on the machine, including Adobe GoLive and Photoshop, both of which are big, resource-intensive programs. Running Classic and OS X native apps concurrently isn't a concern. Everything looks and acts just fine.

But OS X really performs when it comes time to move the machine. In the past this was an exercise in prophylaxis that required running down a checklist of things that might go wrong. Not anymore.

On its desk the Titanium is connected to the network through Ethernet and DHCP. The rest of the building is covered by an 802.11b wireless network. We can close the TiBook's lid while it's hooked up through Ethernet, watch it go to sleep instantly, unplug everything (seven cables, including USB, FireWire, Ethernet, speakers, power and monitor) and watch it wake up instantly when I open it up on the kitchen table, where it's now connected to the network, wirelessly. Later we can close the lid, return it to the desk, plug everything back in, open it up and watch it wake instantly and carry on as before. We've been doing this several times a day with no ill effects.

Not that life is perfect. Every so often the laptop starts to slow down. Then we usually look for responsible processes. (Memory, incredibly, feels like a non-issue, even though we have “only” 384MB.) Apple provides a helpful GUI uitility called Process Viewer, but we'd rather do it the right way: through a terminal session. We just run top or top -u, isolate CPU hogs and kill them off. In UNIX fashion, life goes on.

The usual culprit is TruBluEnv, which is part of the Classic emulation environment. Apple obviously still has some work to do there. But again, failures are never catastrophic and are far less common than they were with the Classic Mac OS, which would typically crash several times a day.

Want to know the killer app for OS X? It's the uptime command. Right now it says this about the Titanium: “11:21AM up 6 days, 16:54, 3 users, load averages: 1.81, 1.55, 1.36”. On another desk is a G4/500 dual-processor desktop, also running OS X. There uptime says, “11:22AM up 22 days, 1:50, 2 users, load averages: 0.16, 0.04, 0.00”. On that machine I'm also running a little program called CPU Monitor, which shows activities on both CPUs. Pretty cool.

In his book In the Beginning Was the Command Line, Neal P. Stephenson compared Linux, Microsoft and Apple to car dealerships. Linux consisted of volunteers making tanks that were free for the taking. Microsoft made ironically popular but failure-prone station wagons and SUVs. Apple made “expensive but attractively styled cars with their innards hermetically sealed, so that how they worked was something of a mystery”.

There is still plenty of hermetically sealed stuff inside OS X, but you can open the hood and work on the thing. At last, it has a command line.

The terminal lives in /Applications/Utilities. Open it up, do an ls / and you'll find familiar directories (bin, etc, sbin, tmp, Users, usr, var) alongside others such as Applications, Library, Trash and so on.

Look in /usr/bin and many of the tools you expect to find are there: autoconf, bison, cvs, fetchmail, nslookup, perl, ssh, whoami and so on. The unexpected tools come from the Mac side of OS X's heritage. One example is osascript, which lets you run an AppleScript script from the command line—a feat one imagines the original AppleScript designers never envisioned.

Some usual suspects are missing: no Python or Pine, for instance. But these are itches open-source developers are free to scratch, which is exactly what many are doing. The OSXGNU archive already includes Python, bash (the OS X default is tcsh), Pine and Lynx. So their absence is corrected easily.

The Fink Project distributes ports of ant, MySQL, Nmap, Ruby and so on, with the stated intent to make OS X “a coherent, comfortable distribution that matches what Linux users are used to”.

It's interesting to discover that much of the software included with OS X is BSD- or MIT-licensed, while much of the software one downloads is GPLed. Though that's just a rule of thumb, it's a definite contrast between OS X and Linux. For example, OS X comes with Curl, available under the MIT license, rather than the more familiar GPL-licensed GNU Wget. This may be attributed to an allergy to GPL-licensed software in Apple's legal department.

Though there is a separate OS X Server, OS X itself includes server software such as Apache, sendmail, named and sshd. AppleTalk and Samba support are built-in.

Because OS X is so new, kinks are still being discovered. For example, a security issue was uncovered in Apache, since HFS+, the Mac's native filesystem, is not case-sensitive. This meant a URL that would otherwise be denied would be made readable just by changing the case of the request. Apple responded with a new Apache module that enforces pseudo-case-sensitivity, and which any build instructions for Apache on OS X must take into account.

There are, of course, GUI ways of doing command-line work. Some of them aren't bad. Turning on Apache is easy in the GUI. You press the Start button in Web Sharing utility in System Preferences. You can turn on FTP and SSH access the same way. The command line is still there, of course. Just edit /etc/httpd/httpd.conf with your favorite editor.

This System Preferences panel allows one to turn on and off Apache and FTP access

The GUI is called Aqua, named for its watery, gum-droppy look, which includes variably translucent windows and other stuff Microsoft can copy later. It includes a file browser (still called Finder) that resembles both the Classic Mac OS and the NeXT multicolumn file browser, depending on how you use it. Most GUI applications are stored in /Applications. It's worth noting that one founding UNIX sensibility OS X brings to the desktop is a relatively rigid hierarchical directory schema. Users in the past could scatter apps and documents wherever they pleased. With OS X, applications go in the Applications directory and documents go in the user's own Documents subdirectory. Though you're still free to place them elsewhere (this is UNIX), it's clearly in bad form (also UNIX).

In the OS X Applications directory there's a small pile of free-as-in-beer closed-source applications, mostly from Apple. Some, such as iTunes, iPhoto and iMovie, do what Apple always has done best, which is raise the bar in both GUI art and ease of use. Others, such as Apple's Mail app, calculator and clock, are handy placeholders. There are free-beer third-party apps too, including one that many Linux geeks would rather avoid: Microsoft's Internet Explorer. Fortunately, native OS X versions of Mozilla, Netscape and Opera are a download away, and all appear to work quite well. OmniWeb 4 is another nice browser that works only on OS X.

The portfolio of available applications for OS X is still small, relative to Windows and even to Mac OS Classic (which OS X runs in emulation). But it's growing fast. As of January 2002 the number was about 5,000, including more than a thousand ported-over UNIX apps. BBEdit (which Mac geeks regard as the greatest text editor ever) is out. More members of the Adobe suite are showing up every month. And now there's an all-new Microsoft Office that some believe leapfrogs the latest Windows version of the suite. Steve Jobs has vowed to make OS X the best environment for Java apps, and we see nothing to defy the claim (while Java was always a pain on the old Mac OS). All these developments are sure to make OS X far more popular (and, we sarcastically suspect, its command-line interface even more necessary).

Little of OS X above its UNIX foundation is open source, although Apple has gone out of its way to invite and incorporate changes and improvements recommended by anybody who's interested—something that Apple never would have done before Steve Jobs returned (with his UNIX-seasoned NeXT team). One report said upward of 70,000 recommendations were sent to Apple during the public beta period alone, and many were incorporated throughout OS X.

Darwin has mostly attracted system-level outfitters. GNU/Darwin appears to have strong interest and developer involvement. XFree86 and XDarwin were developed in the XonX Project. You can run XDarwin rootless, meaning side by side with Aqua, or in its own window. The Fink folks even have GNOME running on OS X.

OroborOSX , a port of the Oroboros window manager, “attempts to make X11 act in a more 'Mac-like' way (whether you like it or not!)”. With Photoshop still not shipping for OS X, the GIMP is another popular download.

On the other hand, the going has been slow in bringing OpenOffice to OS X; Bill Roth of Sun told CNET, “I'm going to make a blatant plug here. We need people on this project.”

Table 1 shows how OS X stacks up against Debian GNU/Linux at the time of this writing.

OS X vs. Debian GNU/Linux

With every retail copy of OS X Apple ships a Developer Tools CD. Included are the familiar cc and gdb along with Project Builder and Interface Builder: an IDE and user interface layout tool. This is a huge change from earlier development environments. To develop for Macs prior to OS X, one had to purchase MPW (Macintosh Programmers Workshop) tools from Apple or CodeWarrior from Metrowerks.

As of this writing Metrowerks is on the OS X case. So is Borland, with JBuilder. More significantly from a Linux perspective, Trolltech is out with Qt/Mac.

Project Builder and Interface Builder have generated a lot of enthusiasm. Says Graeme Hiebert, “Project Builder is a very nice IDE, and Interface Builder is an amazing piece of work. Prior to Mac OS X, I've been pretty much a makefile guy, but I rarely use them anymore.”

Gabriel Ricard says,

For writing GUI apps, one has a choice of writing to the Carbon APIs, which are a revision of the Classic Mac APIs, or using Cocoa, which is an updated version of the NeXT frameworks. Carbon is the best bet for Mac developers porting Classic apps to OS X because it requires the fewest code changes. Cocoa is recommended for new applications. Cocoa applications can be written in Objective-C or in Java. Objective-C is, like C++, a superset of C.

Aside from Carbon and Cocoa apps, one also can create command-line tools, kernel extensions, plugins, pure Java apps and frameworks with Project Builder.

And there is outside participation on the kernel. The list of Darwin Committers is short, but it appears that these people are up to serious work. The Darwin Developers list (to which we subscribe) is quite active and helpful. It makes clear how much work is going on—and how much remains to be done.

It's still early. Almost everything we're talking about here is very new, from Darwin and OS X to the platform-spreading tools and applications developed by the Free Software and Open Source communities.

We'll continue to watch OS X developments closely and invite our readers to do the same and share what they learn. Interoperability isn't something you do alone.

Resources