Three reasons why GNU/Linux is better for Web servers than OS X

Apple’s OS X, which has been an official certified Unix system for some time now, is often installed onto Internet-exposed or intranet-only Web servers for serving up dynamic content. I’ve worked with such configurations for a couple of years, and with GNU/Linux alternatives for even longer. There are at least three reasons why GNU/Linux systems do the job better.

Web servers are key corporate assets, and systems administrators are supposed to keep them humming along, but that’s not always easy. Security is always an issue for sites, as shown by daily vulnerability reports and security advisories. Performance, in terms of load time and response time, is another key issue. Customers get frustrated if it takes longer to add something to their browser’s shopping cart than it would take them to visit a nonvirtual shop to buy it there. Sysadmins also must focus on availability. If your site is down, you’ll lose all the benefits an otherwise well-administrated Web site provides.

GNU/Linux and the BSDs generally have a fine track record as Web servers. In terms of software licenses, they make reliable hosting on the cheap possible, and they let you host dynamic sites that serves tens of thousands of visitors per day over hundreds of days without major hiccups.

Lately, Mac OS X is popping up on dedicated Web server machines more often than it used to, perhaps due to the ongoing success of OS X and Apple in the desktop market and the synergistic effects this has on buying decisions made by Apple users in relevant positions. I coadminister a number of Apple machines that serve a PHP- and MySQL-based Web app, and I’m not as happy with them as I am with sturdy GNU/Linux offerings like Debian. Here are three reasons why.

Managing software on OS X is inconvenient

OS X lacks proper package management. Sure, it’s easy to install disk image files. The .dmg file format defines application packages and is understood by Apple’s installer program. However, not all software that’s important for your average Web server setup comes packaged as a .dmg file. Often, corporate policy forbids the installation of third-party software like Fink or Portage. You end up installing some programs the “proper” way, unrolling some tarballs to your filesystem by hand, and compiling and installing some other programs yourself.

Apple’s Software Update doesn’t necessarily know about all the little nuts and bolts that keep your system up and running. You’ll often find yourself waiting for potentially crucial security fixes a lot longer than you would on well-maintained GNU/Linux distros, because Apple tends to provide fixes for individual software in batch volumes on a specific day.

It’s much more convenient to have all your software managed by a central facility like APT or an RPM package, as you can under GNU/Linux. In most GNU/Linux distros, packaged software is maintained by a toolkit that can even pull in fixes for your applications automatically. It’s also trivial to package third-party software that’s not in your distribution’s repositories yourself to have it consistently integrate with the other software on the system.

Default configurations of popular software seems awkward

Apple’s strategy for selecting (or rather, configuring) server software is strange. The average Web app (that doesn’t run under Internet Information Server) probably needs PHP at some point, but the version that ships with Apple’s latest offering, OS X 10.5 (code-named Leopard), doesn’t come with popular and much-needed PHP extensions out of the box. PHP Extension and Application Repository (PEAR), a vast software repository with reusable chunks of code, is not installed by default, so you’ve got to do that yourself (and without a suitable disk image). The distributed PHP build also lacks support for convenient extensions like calendar, mcrypt, and gd (a library vital for generating images dynamically), which renders the whole package next to useless for some add-on software. The only solution to these problems is to throw out Apple’s default PHP installation and roll your own, with all the pain of setting up your build environment and finding out how to configure each feature.

Virtually any GNU/Linux distributions that comes with binary packages allow for an easy opt-in installation of these and any modules, and some actually enable you to rebuild any package in their repositories from source, with customized options set at configuration time. That said, all distributions geared toward operating a LAMP server usually come with all the well-known PHP extensions you might want to use enabled out of the box, so you most probably won’t have to deal with these issues at all.

OS X is going astray from the “one true way” of Unix

Although OS X is a real Unix system, as Apple’s marketing department let the world know in 2007, it isn’t as close to Unix as it could (or should) be. For example, most GNU/Linux-literate people know what /etc/fstab and /etc/resolv.conf are for, and are surprised by what they do on OS X: nothing. /etc/resolv.conf applies only to some programs; there are multiple, independent ways of resolving domain names on OS X, which is a potential source of confusion. Many standard Unix tools also work in unexpected ways. For example, mounting a remote filesystem on the command line becomes a real quest as soon as you’d like to grant access to users other than the one who actually executed the mount command. Also, the well-known /etc/passwd file does not really reflect a user’s login shell, and chsh, the program you use to change that setting whenever you don’t edit config-files manually with a text-editor, operates on some different yet unrevealed data store. In addition, octal Unix permissions do not necessarily represent what’s really going on and what you may or may not do with files; there’s a chance that you’ll get a “permission denied” error when you try to change to a certain directory even though the POSIX view of the system would seemingly allow you to do so without hassle, because some other system programming API (presumably Apple’s Cocoa) overrules them. The standard userland tools don’t allow for ordering command-line arguments any way you want, which can be highly inconvenient. The list of strange discrepancies and annoyances is a long one.

You won’t come across a System V init system on OS X either. The system uses a service called launchd to control most of its other services (and supports a legacy system to control similar functions in parallel), and it performs tasks like automatically starting, stopping, or restarting services whenever various conditions apply. The configuration for those services is kept in XML files, making them difficult to read and even harder to write from scratch. In general, OS X does not really support you much when administering it via SSH on the command line. Most of the guides and howtos on the Web assume you’re sitting in front of the desktop shell of OS X and next to the physical machine it’s running on, and are dependent on the mouse and GUI. That’s not always possible.

On GNU/Linux systems, a graphical interface (such as the X Window System) isn’t a necessity, and many servers don’t have one installed. Most of the configuration relevant to servers takes place via a command-line interface (CLI) anyway, because it is efficient to work with and you can easily script and automate processes.

A few bright spots for OS X

What I do like about OS X is its default mail transfer agent (MTA), Postfix, due to a personal preference for that particular program over its numerous competitors. You can have that on all mature GNU/Linux distributions too, but it’s not the default for popular choices like Red Hat Enterprise Linux or Debian. OS X’s manual pages are top-notch, too.

However, despite these couple of positives, I don’t see any benefit in having a Mac act as your Web server. Updates and software installation can be a pain, and you’re likely to find a cheaper, more flexible, better-working, and better-performing solution with GNU/Linux at a lower price.