I’ll admit it -- I’m one of IT's most unapologetic Linux fans. If an application will run on Linux, I’ll run it on Linux. It’s not religious dedication for
me as much as it just makes more sense in many cases. Its price-performance ratio on Intel hardware can’t be beat, the system
administration skills required to run it are analogous to any proprietary Unix flavor, my favorite proprietary (Oracle) and
open-source (mySQL) databases run on it, and vendor support for it is growing. The value proposition for Linux is so strong,
I pitched it in a recent board meeting, and the guys on the business side “got it” immediately.
But this week I encountered a conundrum that was quite troubling to this Linux proponent. At InfoWorld, we’re running a processor-hungry
application that is straining one of our old Sun Microsystems machines, an Ultra Enterprise 450 with dual 300MHz UltraSparc
processors. We did some testing and discovered that the application would run much better on an available Intel machine with
two 1.4GHz processors. The only catch was that this Intel machine would have to run Windows 2000, not Linux. After calming
down our IT manager and systems administrator (both even bigger Linux fans than I), we decided to give it a go on Windows
2000.
For a shop that is virtually 100 percent Linux, this was an unusual decision. But it's one that many of you might be facing,
both specifically and generally. As proprietary Unix hardware and operating systems purchased a few years ago reach the end of their lifecycles, IT managers everywhere face a
tough choice: Continue with the old approach (Sun) or leapfrog to running Linux on an Intel box?
Our situation is odd in that it illustrates another fact of life about real-world IT: Many IT managers are unable to make
this decision freely. Although many vendors still support Solaris and Windows, they haven’t yet made the leap to Linux. In
our case, the vendor had a Linux port that was just about to enter QA, but we chose Windows because it was officially supported
(however we anxiously await the Linux port, honestly). I wouldn't turn our company into the QA department for this vendor
just to prove that the application would run well on Linux -- that would be a waste of time.
At one of my earlier jobs, I worked in a staunchly Solaris shop, where we were evaluating high-throughput e-mail delivery
systems. The vendor for the leading product recommended that we benchmark its solution on Windows NT and Solaris. We did,
and NT consistently beat Solaris -- for this particular application. After much hand-wringing, we decided to run the application
on NT because it met these particular needs. I don’t think I’ve ever seen so much consternation within an IT department. Although
we very much wanted Solaris to be faster, it just never came out that way. It was odd to see a group look so defeated after
finding a better, faster solution.
When day-to-day IT decision-making is reduced to one's dogma instead of careful analysis driven by business needs, the tail
is wagging the dog. If you’re a JSP shop, sometimes it might make sense to use ASP. If you’re fully committed to C++, sometimes
quickly building an application in Perl might do the trick. In our case, we would rather run Linux in the long term because
it matches the rest of our environment -- and therefore costs less for us to run -- but when a key application’s availability
is in question and Windows fits the bill, it would be foolish not to give Windows a whirl.