Intel at Apple's core

The recent news about Apple adopting Intel chips for its hardware elicited roughly the same amount of excitement in me as washing a pile of dirty laundry -- that is to say, not much. My main reaction was this: Since when did Apple people care so much about CPUs?

Free IT resource Open Source Business Conference (OSBC) May 22-23, 2007 Sponsored by OSBC Free IT resource TechNet: More ways to know it, share it, and keep it running. Sponsored by Microsoft

Granted, the announcement was at Apple's Worldwide Developer Conference, but fretting about a chip just seems antithetical to the "it just works" mantra I hear so often from Mac fans. The volume of press devoted to the announcement has been staggering. But Apple's decision made me remember what I've always loved about open source: The CPU doesn't matter. Never have so many column inches and so much airtime been wasted on what will amount to a simple recompile for most developers -- but open source fans working in Unix environments have known this all along. Relying on solid open source tools gives IT an amazing amount of flexibility in choosing the best architecture of the moment and in moving software across them with minimal effort.

Almost 10 years ago, well before Linux was mainstream in corporate environments, my boss found out that someone had set up a rogue Linux box to run a critical in-house application. The application had been working fine, but Linux scared him, so I was charged with moving critical production code from the Linux environment running on Intel onto a "safe" Sun Solaris machine with a Sparc processor . (Interestingly, several years later everyone was moving production code from their Sparcs back to Linux on Intel, but that's a topic for another column.)

Because we were moving important code across two entirely different architectures, this effort was a major "project" and was put on our priority list for tracking. The code was written in the Perl scripting language, so I compiled a copy of Perl for Solaris on the Sparc machine using GCC (GNU Compiler Collection), moved the code from the Linux machine to the Sparc, changed a few lines of code where specific directories on the Linux machine had been referenced, and voila -- this big "project" was done. If I'd had to move code from a DEC Alpha to the Sparc machine, the process would have been no more difficult. It really was that easy. And that was almost 10 years ago.

These days I'm equally comfortable moving, say, Apache across architectures, more or less at will. If Sun released a line of Sparc servers at half the cost of my current Intel-based Web servers, I could accept shipment of the new Sun boxes in the morning and have them in production by the afternoon. Again, a simple recompile would do the trick. (Of course, if you don't want to mess around with compilers, there are almost always pre-compiled binaries of major open source software packages, and you could even use something such as the SpikeSource Core Stack if you're sticking with Linux for now.)

The great thing about open source is that, with your hands on the source code, you can switch platforms, recompile the code, and get on with your job without the hand-wringing incurred by commercial software packages. For me, open source long ago lifted the veil of mystery surrounding the porting of software to various chip architectures. With sincere thanks to the compiler engineers around the world, I'll just keep doing what I'm doing in my open source environment while Apple developers recompile their software for the new Intel architecture. I doubt they're sweating it. I'm not.