It is no small source of consternation to those of us who have grown attached to OS X that systems that would run it best - primarily, those with processors created by AMD - will never do so unless Intel fails to deliver on some promise made to Steve Jobs.
It's doubly difficult for me because I'm a devotee of both OS X client and server operating systems. It's triply difficult because Leopard is system software to get hot and bothered about, and I have a solid three weeks until October ends and Leopard ships. There's an Xserve here with Leopard's name on it and a Mac Pro pining for it, and they're about as patient as I am. Yes, they speak to me. If you own a Mac, you understand.
Even with the wild wonders that Leopard will bring, and has brought in secret to those with the foresight to buy Apple Developer Connection Premiere memberships, there are things that OS X won't and may never do. I've already mentioned the biggie. There is a dual-socket Quad-Core Opteron at my feet, literally at my feet, running SPECcpu 2006, and it would be a happy box indeed if OS X Tiger Server was making a scorching day for Barcelona. I have an Intel Clovertown Xeon server that thinks, given Intel's cozy relationship with Apple, it is entitled to run OS X. It's not to be. Alas, and bummer.
As an aside, when I broach this subject, I always draw comments from readers who tell me that dude, if I want to run OS X on an AMD machine, it can be done. To all who would offer this helpful advice, I tell you with the greatest disdain I can muster to stuff it. You're all making Apple wonder whether its open source program, which is exploited to pirate OS X's way onto non-Mac systems, is worth the trouble. I have the same advice for my colleagues in the media who treat every advance scored by OS X scofflaws as legitimate news.
Back to the subject at hand: to wit, what a law-abiding individual is to do when deprived of OS X. As a developer and system administrator, I need to be able to run multiple instances of OS X, different versions if need be, or simply for purposes of isolation and consolidation. I can do this with Windows, Linux, Unix, OS/2, and DOS. But despite how technically simple OS X's design would make and has made virtualisation (PowerPC OS X's MacOS Classic environment relied on virtualisation), Apple won't let OS X run as a virtual guest, not even on a Mac.
So what's an OS X nut to do when he can't tap the Mac's active and welcoming community, sumptuous documentation, gratis dev tools, out-of-the-box richness, and massive library of free and affordable software wherever he needs it? I recently found the answer: Run Solaris.
A chorus of groans is now rising from my readership. For some reason, Solaris, particularly Solaris on x86 and 64-bit x86 systems, suffers from a reputation problem. That used to make sense when Solaris x86 was the performance- and compatibility-challenged stepchild of SPARC Solaris, but Sun has long had its x86 Unix in lockstep with its SPARC operating system. While Solaris has none of the no-brainer usability and manageability of OS X client and server OSes, I'm finding Solaris to be an increasingly comfortable workmate with enough similarities to OS X to deserve some attention.
For starters, Solaris is legitimate Unix and legitimate open source. OpenSolaris is Solaris to a far greater degree than Darwin can be equated with OS X. Even though it is open source, OpenSolaris plugs into the same free, automatic software update system that commercial Solaris customers enjoy. Solaris' GNOME-based GUI is a good thing since Solaris is a System V Unix, something that takes OS X users a while to get used to. And StarOffice 8, which is now standard with all versions of Solaris, has strong Office document compatibility and a user interface that Office users find familiar.
Like OS X, Solaris has free developer tools, and impressive ones at that. Its compiler, debugger, and IDE suite, Sun Studio 12, incorporates leading-edge standards and processor feature compatibility. Solaris also includes innovations that Apple found worthy of borrowing for Leopard, specifically DTrace, the real-time performance profiling facility, and ZFS, which exceeds the loftiest dreams of administrators who want a fast, simple, and bulletproof dynamic file system. The extent to which Leopard will implement ZFS is unknown, but if you meet ZFS on Solaris, you quickly understand why Apple is so impressed.
The Solaris user, admin, and developer communities are boundless and positively stuffed with everything you ever wanted to know. When you go to Google looking for OS X system-level enlightenment that's not in Apple's documentation, you'll often get shunted off to blogs and half-helpful, albeit well-meaning, user-written texts. Google is a reliable index to Solaris documentation. Even the fuzziest search yields definitive results, and most of those point either to Sun or a major university, both of which reliably hit the nail on the head.
As for virtualisation, it's baked into Solaris, and its specialty is self-virtualisation using a facility called Containers. Like other unique Solaris system facilities, Containers requires some reading, but Sun has done a remarkable job at producing two-to-four-page PDFs that walk you through setup of complex and unfamiliar facilities.
I'm just feeling my way around Solaris after an absence of several years, and so far, I really like what Sun's done with the place since my last visit.
Solaris is rough hewn compared to OS X, and the catalog of things that Solaris won't do for OS X users is at least as long as its strengths, with simplicity and usability topping the list. But Solaris is free in all relevant definitions of the word (I recommend Solaris 10 Express Developer if you want to see all that Solaris can be), and its interoperability with OS X is seamless. After all, Solaris and OS X are both Unix, and if that's not enough, know that PowerBook, MacBook, and MacBook Pro are practically de facto choices among Sun's engineers. There's clearly some clue in the halls in Menlo Park. As I get more acquainted with that, I'll clue you in.