About a month ago, we spoke with John Loiacono, Sun's VP of Operating Platforms, to get an idea of where Sun's head was at on the Linux question. It turned out to be in a better place than most give the company credit for. The interesting twist in the conversation was Sun's new institutional take on why Linux has proven so popular. According to the company, the power of cheap x86 hardware is the real allure to enterprise operations, not the operating system running on that hardware.
We don't entirely agree with that assessment. We know Unix admins in certain institutional settings who took a pass on Solaris x86 when it was a fairly low-cost option because they liked Linux better for whatever reason, including their sense that Sun's heart wasn't in a low-end Solaris. At this point, it's interesting to note that Sun's corporate ship is coming around for another pass at a market it didn't care to touch a few years ago, when the sky was the limit.
This became more obvious this week week as Sun signalled more of that dawning respect for x86 hardware when it announced the release of AMD Opteron-based Sun Fire servers, and its intent to bring Solaris to Opteron by the middle of next year. Until that 64-bit Solaris is out, Opteron-enhanced versions of Linux will be standing in the breach on the new hardware.
The value of AMD's Opteron is fairly simple to describe: It's a 64-bit processor that can run 32-bit code in native mode (as opposed to Itanium's emulation mode). We'll leave the gory details to our colleagues at CPU Planet, who are pretty enthusiastic about AMD's 64-bit line from end to end. The big advantage of Opteron in an enterprise setting is that it means the move to 64-bit computing doesn't have to be a whole-hog thing: 32-bit apps will run just as well (and better) on an Opteron-based server as they will on a 32-bit machine, and not every current 32-bit app needs to be ported to the 64-bit architecture to begin the process of migration to the new platform.
The deal stands to be a win for both companies. In the past several months, Sun has rolled out a refined licensing model and placed greater emphasis on the end-to-end integration of the systems it sells. By confronting x86 in its predominantly 32-bit form now and getting aggressive about its 64-bit future, we think the Sun's back in the game. It still has to deal with Linux, but it will be doing so by focusing on its own strength as a seller of integrated systems, instead of reeling around and throwing punches at penguins (or fantasizing about decapitating them in darker moments of post-boom ennui).
While AMD isn't technically on our beat, it seems pretty clear that Sun is a prestigious partner for the company, and it offers proof that even if AMD was hanging on by its fingernails in the 32-bit world, it has some vision as far as where the transition to 64-bit computing is concerned. We suspect Intel is less than happy about this week's developments, and we wonder if HP is now second-guessing its own recent emphasis on Itanium.
In Other News
We've read the case studies from obscure municipalities in Florida that pick up Linux as a thin-client platform, and we think such deployments will make a much more compelling case if it's still a story in a year or two.
Mono is an open source effort to bring Microsoft's .NET to Linux. It currently includes a C# compiler, a virtual engine, and class libraries for ASP and ADO functionality. The project isn't quite soup yet, but when Novell announced a road map for Mono 1.0 and beyond, it signalled its interest in competing with Microsoft at more levels than the file-and-print-server market, and it made clear that it's assuming stewardship of the project.
And while we're on Novell:
The serene smile you see on our faces comes from the sublime awareness that as long as SCO exists, there will be a new Unix argument every week. It's reassuring to know that SCO seems to be one of the few constants we can count on.
Several years ago, we knew a harried system administrator faced with his first large-scale POP3 deployment. He had a sizable pool of untrained users he'd promised would be able to access their work e-mail from home. However, he didn't have the savvy to roll out a Web mail interface. The first dilemma he faced was how to make sure the users also had appropriate SMTP access, since many might not have it already configured on their home ISP accounts for whatever reason.
His solution, we learned too late, was pretty simple: He set up an unauthenticated SMTP server and told all the users to point their mail clients at it.
For about a month, all was bliss: The users were sending mail like champs, and the server was ticking along. It was e-paradise. Then a spammer found the open relay and used it 10 ways to Sunday. A few days later, the admin got some mail from blacklists that he mistook for a weird scam of some sort. A few weeks after that he was on several blacklists, with the users lined up outside his office wondering why they had polite form e-mails telling them the outside world didn't want to talk to a dirty spammer.
Too bad he hadn't heard of pop-before-smtp, which provides a relatively secure SMTP access solution for mail admins with remote and mobile clients. Here's how it works:
Every time a user logs in via a POP (or IMAP) connection, it's logged. The pop-before-smtp daemon watches the logs for successful POP connections and notes the IP where the connection originated. It then instructs the SMTP listener to accept relay traffic from the same IP for a set period of time.
Best of all, pop-before-smtp is about as simple to configure and run as it is to describe.
The documentation says it supports sendmail, and we've used it with both exim and postfix on a publicly available wireless node to make sure our guests weren't passing traffic through a mail server we couldn't move to another segment. We've also used it in conjunction with laptops that peer up to two or three networks in the course of a single day: Users don't have to change SMTP settings in their mail clients each time they change nets.
Sure beats a blacklisting.