The eve of the coming-out party

At the time I'm writing this three-part mini-series, the Mac web is in a state of Mac OS X apathy. We have been waiting too long for Puma, regarded as the second coming of OS X, and all our thoughts are centered around one simple question: "When can I just get that damn CD already?" We have forgotten about the serious OS X issues, problems and questions. The debates, the controversies, the feuds between the "whiners" and the "advocates" have petered out; there are only a few souls lingering in the previously so busy OS X debate message boards. We seem to be willing to believe that 10.1 will be the ultimate answer to all OS X questions.

Well, it won't. Mac OS X is still a work in progress, and it should still be controversial. We still need to watch out for its questionable solutions, which still abound, and tell Apple and the developer community if we're unhappy about something they have the power to change. And there's still plenty to be unhappy about.

This series will look at three serious OS X issues that Puma doesn't seem to be addressing the right way. This first part is about the Unix vs. Mac division. The second part will be about human interface design, and the third will focus on the OS X way of handling file types: possibly a huge step backwards, all the way to pre-Macintosh times.

Unix: resistance is futile

Let me begin with a parable.

And the Master said, "I shall tell you how to install an Unix application on Mac OS X." And the Master showed the disciples how to download, compile and install the application. And the Master told the disciples to edit their preference files. And when the Master told them to use a command line text editor like vi or emacs, one of the disciples was troubled in his heart, and said:

"But Master, why do you tell us to use vi or emacs, when we have excellent graphic text editors like Pepper, BBEdit, or even the very basic TextEdit, that let us take advantage of a wonderful invention that vi and emacs leaves us bereft of: the mouse?"

And the Master said, 'Get behind me, Satan! You cannot serve two lords: you either serve the Mac and its unclean mouse and its frivolous icons, or you serve Unix and its fixed-width ASCII cleanness. You shall use vi or emacs, for the Unix way is the only true way. It is the way we and our forefathers have edited text since the late seventies, and will continue to edit it for ever and ever.'

And the disciple understood.

Mac and Unix is nirvana, said Steve Jobs. We have the stability of Unix, and the ease of use characteristic to the Mac. What more could one possibly want from an OS? Well, there's one more thing I'd want from an OS: I'd like it to exist. The Mac-Unix nirvana sounds too good to be true, and, well, currently it is.

Mac and Unix are an odd couple. We have Mac fanatics and Unix geeks, the two opposite ends of the computer-using spectrum. The Unixically challenged Mac user feels being looked down on just because he cannot let go of his stupid mouse, and has a serious mental deficiency that prohibits him from memorizing hundreds of apparently nonsensical three-letter Unix commands that are necessary for real computer use. At the same time, the Unix geek doesn't understand how the software industry is built around completely computer-illiterate people who call themselves "power users" just because they can click on pretty buttons that, by the way, waste huge amounts of memory and disk space.

Of course, there are some people who actually use both operating systems, and they welcome OS X as a great marriage: now their Unix and Mac needs will be fulfilled on one single machine. They no longer need to turn on a Mac when they do graphic design, web surfing or other GUI-intensive work; and they no longer need to go over to a Unix machine when they want to do Unixy stuff, such as developing and testing their command-line server applications, or accessing some of the traditionally robust Unix tools. Both will be there for them at the same time, on a Mac running Mac OS X.

But does that make Mac OS X a robust example of unity and integration, or is the new operating system little more than the sum of its parts?

Strange bedfellows

Well, integration of Mac and Unix must take place on two levels. One is that of preferred user interaction, where we have the CLI vs. GUI (command line interpreter vs. graphical user interface) debate, and the other is the integration of the two foundations, which is about the plumbing and wiring of the system.

As for the user interaction and perception level, the dichotomy is more than apparent, and it's likely to remain so for a while. Hardcore Unix users will continue to claim that navigating between directories is easier by typing directory paths in a terminal window than using the Finder, and that manually editing a thousand-line configuration file gives you more power than a preferences application with well-organized panes, text fields and check boxes. At the same time, most Mac users will continue to bow down before the perceived superiority of the Unix geek, who will insist on doing everything in an unsightly, complicated, though undoubtably more impressive way than the poor Mac idiot does.

Sure enough, downloading Stuffit files of automatic installers makes you look far less brainy than wgetting, compiling and configuring source distributions while watching the Terminal window spew out hundreds of lines of incomprehensible messages. The Unix way demands that you know more about the guts of the system, forcing you to become quite a bit of an IT expert, as you're "doing it yourself" much more than on the Mac.

However, this is precisely what scares the bejeesus out of the Mac purist, who wants to be shielded from the guts of the system. He or she just wants to use an application and not tamper with it; he doesn't want to build his own tools, he prefers to buy them. The Mac purist is right: he wants to be a user, not a builder, just like the casual audiophile who prefers to buy a stereo to building one, choosing simplicity and ease of ownership over the extreme amounts of control he would have by choosing all the components, materials and manufacturing processes.

This is why the Mac purist can choose to bypass the entire install of the BSD subsystem, including the Terminal application, sparing him the window into the depths of the Unix nastiness dwelling inside Mac OS. Which is pure defiance: the "nastiness" remains there anyway.

The situation will be hopefully changing in the future. What might be scary for a Mac user today (like administering an Apache server) would suddenly become far more attractive if a GUI were built around it. GUIs don't necessarily dumb things down. On the contrary, they might be used as learning tools. A GUI can provide well-organized and intuitive shortcuts to a lot of functions or preferences that would be a daunting task to learn to access from a command line. Learning Unix commands may force you to become savvy fast, but a graphic metaphor can teach you the same concepts more gently: dragging a file from one folder to another doesn't make you less aware of the file system than typing out the Unix command for moving a file.

Using applications that bridge the gap between the GUI and the command line would be especially helpful. Think about your web browser. It types out URLs when you do nothing but click at links, thus allowing you to learn all about URL construction, letting you decipher the way Web applications pass parameters to PHP or (God forbid!) ASP scripts in the URL. Your browser even lets you look at the HTML source of every page you visit, and if you are interested in learning HTML, your browser will become a valuable learning and production tool.

All it takes is a few pioneering developers writing applications that unite the Unix shell with the GUI, and soon we will have Mac GUIs even for what are now the most purely command-line applications, opening up the arcane world of Unix to uninitiated and scared Mac users.

Want proof? Look at a former command-line stalwart like FTP, and PostScript, a genuine programming language. FTP used to be about typing out commands to communicate with a remote server. Now it's all about drag and drop. PostScript is a powerful programming language used for describing pages. However, unlike most programming languages whose goal is to allow coders to write code manually, PostScript code is not usually written by humans. PostScript programs are the output of page layout applications like QuarkXPress or Adobe Illustrator. PostScript files are rarely touched outside a GUI. See? There is program code written without manual coding!

There are more landmark victories for the GUI to come, on a Mac near you. Trust me on that.

But how about the foundations?

This is the part where there's less and more to worry about.

There's less to worry about, because Apple has apparently done an excellent job in placing the OS on top of a lightweight microkernel that controls everything that happens on the computer. This is the "good Unix" bit of OS X that is there behind everything you do, without your noticing it. It's there when you run Photoshop in Classic mode, making sure that your Classic environment gets its processor time and is shielded from the memory space of other processes.

On the other hand, Mac OS X must comply to some Unix standards that integrate very badly with the Mac look and feel. It has been a great challenge for Apple to keep supporting type and creator codes (file attributes that let the Finder determine the type of a file without relying on filename extensions) in Mac OS X. There seemed to be hope that Apple would manage, and we wouldn't have to endure a Windows-like filename extension nightmare, but Apple's latest plan to hide filename extensions, as well as indications that Apple would "move away from" the type/creator model shows rather that Apple has tried and failed; and now moves on. It looks like some of the Mac look and feel will be sacrificed on the altar of Unix compliance. We'll dig deeper into that issue in the third part of this mini-series.

Andras Puiz

Forum thread on this article started here...