Most of the technologies we work with at TechWorld revolve around Microsoft operating systems and Intel hardware, albeit with a liberal smattering of Linux and other OSs (not to mention the occasional look at a non-Intel CPU). It's easy to forget that there's another platform out there that is not only suited to both the desktop and the server, but has a user interface and operating methodology that's been around far longer than Windows. In its current incarnation, based on a Unix-type architecture, it does stuff like multi-tasking and memory protection properly. It is, of course, MacOS X.
A bit of a mix
The OS itself is a strange beast, since it's a hybrid of the Mach Unix kernel and the MacOS user interface. You'd think that this would be no different from the way that, say, Linux works with an X-Windows interface over the top of its inherently command-line-based architecture, but in fact this isn't quite the case: for one thing the user databases on the Unix and MacOS sides are separate. Just because you have admin privileges on the Mac side doesn't mean you get "root" privileges on the Unix side. The two worlds do, however, hang together extremely well. The MacOS and Unix directory structures are common, and so you can do all the obvious things like running a Unix script, piping the output to a text file and then opening that text file in (say) Word for MacOS, via the GUI.
I was a Mac specialist in an academic institution when the move from the 680x0 processor range to the PowerPC took place at the inception of the Power Macintosh. The biggest howl of anguish was always: "How do we run our applications on this new architecture without spending thousands?" The answer was: emulation. Put simply, MacOS for PowerPC would have a 680x0 emulator on top of which you could run your non-Power Mac programs if you couldn't afford to upgrade. And it was bloody awful, because running on an emulated CPU was hideously slow, since you had a whole extra layer of software between the application and the CPU, which more than negated the speed bonus the PowerPC chip gave you.
Emulator = nasty?
Apple faced the same issue with MacOS X, not because of a processor change but because of a move from the old Mac library calls to the new Unix ones – which are radically different, and run on an architecture that (unlike the old MacOS releases) did multi-tasking correctly and pre-emptively. This time, though, speed isn't a problem: processor technology has come sufficiently far, and today's CPUs are so darned fast, that you don't really notice any sluggishness when you fire up a non-OS X application and it launches it under an OS 9 emulator.
The main bonus with the migration to the Unix core that happened during the transition from MacOS 9.0 to MacOS X, though, is that it finally makes it a sensible offering at the server end as well as on the desktop.
MacOS on the server: Just say "No"
Mac servers have generally been a pretty dismal bunch. They've been OK as AppleShare servers (and thus of use only to those who run predominantly Mac clients). But they've needed add-on software to interface with Windows networks and when considered as (say) database or Web servers, they've not been the automatic first choice.
Mac advocates will be crying "foul" at this point, of course, but let's be honest, guys: is your average system manager whose arms aren't tied by pre-existing architectures going to choose a Windows system with IIS, a Linux system with Apache, or a Mac for his Web server? 99 times out of 100, the Mac would have been the third choice. Interestingly, Apple nearly got it right in the mid-1990s when they brought out some excellent AIX-based server machines as a joint venture with IBM, but people regarded these merely as RS/6000s with an Apple badge. They didn't appeal to the Mac types, who didn't recognise anything except perhaps the colour of the casing, and who, therefore, didn't have a clue how to work them.
The difference now is, of course, that the Mac is a serious option in the server market. Okay, its support for Windows filesharing is via SAMBA, not (like the AppleShare add-on for Windows) a vendor-written bolt-on. In the server version of MacOS X the Web server is Apache, the mail server is Wietse Venema's excellent Postfix, and more and more of the open source server-side applications familiar to Unix types have MacOS X options in their setup routines.
Commercial application support
Which brings us to the main Achilles heel in the MacOS-as-a-server-OS argument: application support. You simply can't get the big commercial applications for MacOS X like you can for, say, Windows, Solaris or even Linux. This means that if you want to step outside the Apple-supported sandbox and use something other than the built-in applications, you're into the realms of Open Source (or at least non-commercial) software, which opens the Mac to the same cries of: "But there's no support if it goes pear-shaped" that are received by Linux advocates.
With the introduction of MacOS X, though, there is a reasonable chance that the commercial server application providers will wake up to the idea that they have a platform that is suited to being a server and which is supported properly by its makers. This is also, of course, the motivation for the Linux distributors to make commercial "enterprise" versions that stay the same and are supported – it gives the software makers something they can rely on as a long-running, stable base for their code. Not only this, but many of the software manufacturers are already used to writing Mac stuff thanks to their desktop applications – and it can't do any harm that Microsoft plays an active part in Apple's ongoing existence, both as a shareholder and as a maker of desktop applications.
Once this commercial software support at the server end becomes reality – and there's a very good chance of this happening – MacOS will become more and more popular as a server operating system. In the meantime, though, there's every chance that the availability of Open Source applications will help it in the server market. Additionally, the fact that it does all of the stuff that most of us want, such as e-mail, Web serving and integration with Windows and other directory services in the corporate network, can't do MacOS's chances any harm at all.
Linux and MacOS
One final thing to consider is the contrast between MacOS and Linux. In many ways they're similar: although popular in their niche they're regarded by the mainstream as "outsider" technologies. They're striving to gain acceptance as commercially suitable operating systems upon which software writers can develop commercially-supported applications. The difference is clear, though: Linux is starting to make headway in the server market. Although it's coming closer to being accepted on the desktop, there's a long way to go as the commercial distributors have their eye firmly on the server arena. On the other hand, the Mac is already accepted as a desktop machine, and there are shedloads of mainstream applications from the likes of Microsoft, Adobe and hundreds of big names in the software business. To move into the desktop market, Linux has to penetrate a market with a large number of low-value installs; the server market that MacOS needs to get into, on the other hand, is a much smaller number of much higher-value installs. I know which marketing team I'd rather be on.
In short, then, MacOS is an established operating system that no longer lacks the punch to be a server OS as well as being a highly respected, and widely supported desktop OS. In many ways it deserves to grow in stature and popularity on the server, and it will start to do so just as soon as the commercial software vendors begin to roll out their MacOS X versions. In the meantime, though, it does as much server-side stuff out of the box (and therefore in a form that Apple will support if it breaks) as the majority of customers require. While we wait for the commercial applications, there are sufficient Open Source offerings to fill the gap. There can be no doubt: MacOS is a serious corporate operating system.