The first thing I noticed upon initially booting up OS X is that it didn't go out of its way to advertise the fact that there was a Unix-compatible operating system under the hood. Unlike its FreeBSD, Linux or Solaris cousins, the boot-time messages that tell you exactly what is going on as the operating system takes full control of the computer were confined to a small pop-up dialog that announced the various major stages of the boot process and marked its overall progress with a colorful status bar. For the intended audience this was undoubtedly the right thing to do, but Unix purists like me will still miss seeing the device probes and other information that could conceivably be of use when debugging the system (which all Unix die-hards tend to do at one point or another).

After the system was fully up, a login-requester was displayed and I was able to log in using the administrator user name and password, which were requested during the installation of OS X. Once logged in, I was confronted by a standard icon dock at the bottom of the screen with a set of icons happily bouncing up and down as the applications they represented launched themselves. That's one of the first things I needed to get used to with OS X -- everything is very colorful and more than a little animated at times. I could live with that, but horrors, where was the terminal application -- that plain and simple window with command-line access to the raw power of the system?! Not to worry, Apple had simply hidden it a few clicks away. Inside the Utilities folder I found a terminal application and just a couple of clicks more presented me with a terminal window running tcsh, a version of the C shell that supports filename completion and other useful extensions that should be familiar to just about anyone who's used Unix before. So far, so good!

Once I had access to a command line, OS X started looking a lot more like a Unix system. A df command showed which file systems were mounted and I could traverse the file systems with all the standard Unix commands like find, ls, cd, etc. There are even copies of emacs 20.7 and Perl 5.6.0 installed by default, applications more typical of a "power user" configuration than what I'd expect to find on a standard out-of-box Unix installation and something of a pleasant surprise.

Unfortunately, the converse was also true and the next thing I noticed was that the C/C++ compiler suite was missing. For me and most developers, this could be rectified by simply installing the Developer package from the OS X Developer CD-ROM, an option in the beta for people who are part of Apple's Developer program. But this really should be a standard part of the final OS X release product and not something only "developers" can get or, worse, have to pay for. The compiler tool-chain is simply too much a de facto part of any system these days to make it something that can only be gotten by jumping through extra hoops, and I was a little disappointed to see that it was even unbundled by Apple in the first place.

Of course, the proof that I was working with a real operating system would be to compile something -- to get some of my favorite Unix-ish software running on this system. So I promptly fetched the source code to the GNU Project's bash 2.04, my favorite shell and one that didn't happen to be included with OS X. I unpacked it without any trouble. (Let's hear it for GNU tar, gzip, cpio and pax being standard components!)

I did run into some problems here. Once bash's configuration script was told it was on a "powerpc-bsd" machine, the build proceeded normally until the Makefile attempted to link in the GNU malloc library. If you are not Unix-familiar you probably don't want to know the details, but suffice to say, the attempted link was a bad idea and I had to do some minor tinkering to get a functional bash shell.

But as a portability benchmark -- a criterion with which to judge how easy it is to get foreign software running in Mac OS X -- this was certainly not bad at all and I had much the same good results with TCL, another popular open-source application. Porting Unix software to OS X is clearly far less work than trying to port it to Windows 2000 and with OS X providing such a high degree of Unix-compatibility, something like the FreeBSD ports collection (which highly automates the process) would make the third-party software situation pretty close to ideal.

The next thing I did was telnet into the machine to administer it from a desktop environment I was more familiar with. This is something else OS X does right out of the box (under control of the "Sharing" preferences). It even announces itself as "Darwin/BSD" in the login banner, letting one know you'll be in for a fairly typical BSD experience if you come in that way.

Of course, telnet is somewhat insecure, so I immediately looked for a copy of sshd (the secure shell daemon) to start up so I could do my telneting in complete security. Unlike the developer pre-releases that preceded it, this release of OS X included sshd. But this was also where OS X started to look just a little different from FreeBSD, which starts sshd by default. OS X doesn't have any obvious way of starting sshd at system startup time and after tinkering with various files for a while I gave up; clearly this is an area where OS X is significantly divergent and the documentation is still unclear.

Another area of confusion for me was the editing of user account data. On a BSD machine, for example, one can run the "chsh" command to set a user's default shell to be something else (like bash). Using chsh is also possible on OS X, the only problem is that it doesn't work. Only editing that information with the NetInfoManager made it stick and this is one of those areas where the OS X way and the traditional Unix way are both present, but also directly in conflict. Getting services like NIS or Kerberos to work correctly with OS X is something I didn't even want to try after looking into it for a while and I suspect that this will come up as a problem for anyone trying to assimilate OS X into existing heterogeneous Unix networks.

Apple's support for "resource forks" (roughly described as extended file attributes in the Unix world) is also a feature anyone wishing to use OS X largely as a Unix server machine will want to avoid given that resource fork information cannot be backed up and restored easily using any of the standard Unix backup tools.

Still, this is a beta release and it was impressive just how much "Unix stuff" did work exactly as I'd expected. One can easily log into the machine remotely or use a full suite of network tools such as ftp, ssh and NFS to access files on other machines, and the built-in Apache Web server can also be easily launched at the click of a button in the System Preferences tool. Considering just how much more network-capable OS X is out of the box when compared to a comparable Windows installation, it's almost embarrassing to complain about it.

Recent Stories