Extract From Byte Magazine - April 23

[Steve Bildermann]

As BYTE is now a subscription service I thought some people might enjoy reading some extracts.

OS X: Should I Stay or Should I Go?
by Moshe Bar

Some people have a weakness for fast cars, others for great wines or antiquities. I have a fondness for good computers. Since my early teens I have always wanted better, faster, sleeker, smaller or more powerful computers, either on the desktop, in my server room, or on my lap.

Unfortunately, there is little that stimulates a gadget addict's appetite in the traditional PC industry these days. Sure, the recent tablet PCs do have sex appeal, but they only run on Microsoft Windows, and as a Linux aficionado there is little I can do with such a tablet PC. Next to the relative novelty of tablet PCs, there is really nothing new out there.

In view of this, the slew of activity around Apple's products is even more refreshing. Not only is Apple's Mac OS X on the way to becoming the most widely used UNIX dialect, but it also sets new standards for computing hardware with its eyecatching and exceptionally functional PowerBook laptops. Apple knows how sexy its products are and is spending millions in advertisement to lure Windows and Linux users to switch to OS X.

Should You Switch?

As someone who for years has used Linux on laptops, I have come to expect little from a graphical user interface or from software support of laptop hardware features. As I have written previously, amazing as the progress is in the look and feel of Linux desktops, there is no way they can even get close to the elegant, sleek, instinctively easytouse GUI of OS X. Add to that the stability of the UNIX core powering OS X, and its natural suitability as a development workstation, and the only advantage Linux is left with is that Linux remains completely open source while OS X is only partially released into the free software world. Well, actually Linux has another advantage: It's much faster than OS X, as I showed in my December 2002 column.

I love the Apple laptop/OS X combination so much that I have fully switched my working environment to a couple of PowerBooks and iMacs. I use the just released 12inch screen PowerBook (867 Mhz, 640 MB, CDW/DVD) for traveling and the amazing iMac (17inch screen, 1 Ghz, 1 GB RAM, CDW/DVDW, 60 GB disk) for work at home and in the office. My wife uses the 17inch iMac for all her email, browsing, and Photoshop needs.

For those times when I need to do Linux kernel development, I have a second partition with Gentoo Linux on both laptops. Gentoo Linux is easily installable on these PowerBooks and recognizes all of the peripherals except for 32bit support of the ATI 64MB graphics adapter. Even 802.11B and 802.11G works out of the box with Linux. But apart from pure kernel work, there is really no reason to boot into Linux on these machines; everything works just as well under OS X. I even develop my own open source software—openMosix (see http://www.openMosix.org/)—under OS X with vi and/or Emacs.

Now, I am not proselytizing here. In my abovementioned December 2002 article I did speak of OS X's shortcoming as a server OS when compared to Linux. And in fact, I keep all of my servers firmly under Linux, since it is hard to beat its power, versatility and low total cost of ownership (TCO) for serveroriented tasks.

So the question arises which of the two most widely used UNIX dialects—OS X and Linux—will eventually prevail. In a recent speech in Israel, famous kernel hacker Ted T'so told the audience how the standard for UNIX had gone from BSDstyle to SCO UNIXstyle to Solaris and now finally to Linux. There is hardly a software developer today not writing Linux, or at the very least Linuxcompatible, software. There is hardly a major piece of software out there that doesn't support the Linux platform. Oracle is selling thousands and thousands of licenses for its products on the Linux platform, eating eagerly from Microsoft's plate. The same for many other big ISVs. But you can already see widespread support for OS X as well. A contact at Apple told me the company is internally testing SAP R/3 on the OS X platform. Oracle 9i is running under OS X on my Powerbook as I am typing this.

Surely as Linux prepares to release version 2.6, it will progress further into the big server domain, replacing more and more of those big Sun, HP, and IBM SMP servers. Already, Sun, IBM, and HP can feel the pinch in their traditionally very lucrative lowend and midsized markets. Of course both HP and IBM have a valid Linux strategy to smoothly transition to the new Linux reality, whereas Sun really has a strategic problem. The company only halfheartedly embraces Linux and open source, embarking instead on big projects like N1—Sun's vision, architecture, and products for the nextgeneration data center—hoping to be able to corner tomorrow's enterprise networks with proprietary software.

It seems right now that Linux beats all other options in the server market and that OS X easily wins the usability and beauty contest. Why can't both be united? The best scenario for us users would be an OS X with a Linux kernel and the Aqua interface. The choice of the FreeBSD/Mach kernel seems obviously wrong, and not only from a performance point of view. Just imagine the thousands and thousands of open source contributors and developers who would flock to OS X if they could rely on a kernel they already know well.

Another weak spot of OS X is its internal file system layout and its byzantine library system. For users switching from Linux, the filesystem layout is very confusing. The /tmp directory, for one, is linked to each user's home directory. And the important /etc is just a link to /var/etc/.

The most common linking and executable format in the UNIX world is Executable and Linking Format (ELF). It's the one used in Linux, Solaris and a score of others. In ELF, the old distinction between shared libraries and loadable modules does not exist, and thus most developers today just treat them the same. In OS X, for some strange reason, Apple chose to reintroduce the distinction between the two with its MachO executable format. Shared libraries have the internal file type MH_DYLIB and the .dylib suffix attached to them, whereas loadable modules—called "bundles" in OS X speech—have the internal file type set to MH_BUNDLE and the .bundle suffix. This is bad because developers have to use special flags with gcc when compiling a shared library or a bundle. Furthermore, annoyingly, the OS X linker does not allow common symbols and therefore the fnocommon compiler flags is required to make things run. Another big departure from classic UNIX behavior is OS X's system library, called "libSystem." This library is a container for libc (the standard C library), libinfo (Apple's old NetInfo library), libm (the math library), libpthread (the Posix threads library), and libkvm (the kernel's virtual memory library). There are some symbolic links to placeholders for libSystem, such as libm.dylib from /usr/lib, but it is still a much too complicated system to deal with if you come from the simple and elegant Linux standards.

With Linux what you get is what you see. Less sophisticated, but simpler and ideal for developers. OS X is beautiful outside, but still too ugly inside. If you are not a developer, then OS X is way more appealing. If you happen to be a developer then either adapt to the little (but annoying) idiosyncrasies of OS X, or stay with Linux until Apple fixes these issues.

[cstaylor]

I respect Moshe's contributions to clustering (that's what MOSIX is), but he needs to spend some more time in the Darwin kernel source before he starts dropping things like this.

Unlike Linux (and I don't think this has changed under the upcoming 2.6 release), Mac OS X has a very nice message-passing system between kernel and user space applications. Where OS X fails is with its BSD compatibility layer: the original BSD was not designed for multiple CPUs, so the inherent capabilities of OS X to scale to large-scale SMP systems doesn't work well because of two large "funnels" (locks) that block any other thread from accessing certain OS resources.

As a Linux and OS X software engineer, I find the documentation for Linux kernel programming far superior to Apple's docs.

Just my semi-informed opinion.