"Clear-eyed!" we raved. "Engaged and focused!"
Last week, we were happy to laud Sun for the moves it's been making with its Java Enterprise System, the long-awaited software licensing/packaging combo that promises to make provisioning enterprise IT simpler than ever. Because there was so much time to spend on that, we didn't get around to covering the moves Sun is making with its Solaris for x86 offerings, which has long been considered the red-headed stepchild of the Sun lineup, or at least red meat when tossed in the x86 Unix gladiator pit with the BSDs and Linux.
It's probably best we waited, because during the past week Sun focused on tooting its licensing horn. In this short amount of time, figuring Sun out has gotten tricky again, and the trickiness centers around Sun's ongoing confusion (or perhaps confused protests of clarity) where Linux is concerned.
In February 2002, Sun CEO Scott McNealy was seen capering around LinuxWorld Expo in a penguin costume, declaring his love of Linux. It probably played well to the audience there, and we'll be the first to admit there's no warmer feeling than the one that comes from the approbation of a room full of Linux nerds hearing what they want to hear. It played well enough with us, too: Everyone we knew who had dealings with it considered Solaris on x86 machines to be a bad joke ... a pale imitation of the OS's greatness on high-end gear. It made sense for Sun, still reeling around after The Bust, to be figuring out a way to crack into the low-end opportunities a commodity Unix on commodity hardware might provide.
We might have ruined the love affair for everyone earlier this year, though, when we sat down with some members of the Solaris marketing team and suggested Sun's heart wasn't really in the x86 port of its OS: The idea got a distinctly chilly reception, then Sun withdrew to plot the unveiling of the Java Enterprise System (née Orion), and we decided we probably had a point, but it might be rude to bring it up. When we learned in July that Scott McNealy refers to the penguin head from his 2002 LinuxWorld costume, which he keeps in his office, as a "decapitated penguin," we realized we might have gotten personal without meaning to.
Then, a week ago we noticed that in an interview with The Register, Sun executive VP Jonathan Schwartz admitted his company had fiddled while Solaris x86 burned, and the company frittered away the boom years pushing higher-end hardware. "There will be a transition back to Solaris," he promised.
We thought we might have a week or two before hearing anything more, but Schwartz was out the gate with the new meme just a few days later, telling reporters "let me really clear about our Linux strategy. We don't have one. We don't at all. We do not believe that Linux plays a role on the server. Period."
So much for the penguin costume.
Or rather, so much for life on this side of the looking glass, where Linux on the desktop is still a struggling concept in the minds of most enterprise managers, yet seems to be handling servers rather well. The new Sun line seems to be the opposite: Linux is a dangerous liability on servers and a perfect fit as an inexpensive, drop-in Windows replacement. Last week, when we cautiously noted the Sun Java Desktop System (née Mad Hatter) as a potentially good idea fraught with not unprecedented peril, we had no idea that the server side of the equation for Linux at Sun had been so decisively dismissed. Now, we're willing to say the Java Desktop System is a misapplication of Linux, if that's where Sun thinks its sole role should lie.
What does the rest of the world think? An Aberdeen analyst says Sun's Linux strategy (the one Mr. Schwartz says it doesn't have) is weak, and that if it's all about Solaris after all, Sun is risking a growing body of customers that want the Linux choice in a meaningful, well-supported way. We're inclined to agree.
In Other News
Sun and the JDS provide a nice segue into this week's other bit of important news, which is the burning question of indemnification of Linux users from IP-related law suits. The question is burning because SCO, which has its own, non-copyright reasons for hating Linux on commodity hardware, is attempting to extract $1,800 a server from corporate Linux users, and threatening legal action if those users don't come across. As we've previously noted, Linux's loudest enterprise proponent, IBM, says it won't indemnify users and doesn't need to. Sun has struck a middle ground, offering to indemnify its Linux desktop users, but withdrawing that legal protection if its Java Desktop System ends up running a server somewhere. We suppose that's one way to frighten would-be Linux customers back to Solaris.
Also in indemnification news comes word that SCO's mystery licensee, which we mentioned late last month, is not Hewlett Packard. How do we know? HP said so Wednesday: "We have not signed any deal with SCO and have not paid them any money to protect ourselves," said HP vice president Martin Fink.
The company also announced it's indemnifying all of its Linux customers if they buy a standard support contract with their Linux hardware. "We're going to provide indemnification whether SCO's claims are valid or not," said Fink. The only catch is that users may not modify the Linux source code. If they do, they lose HP's legal aegis.
Oddly enough, rather than waiting five minutes before announcing it would be suing HP for every one of its unlicensed Linux customers, SCO praised the deal, saying "HP's actions this morning reaffirm the fact that enterprise end users running Linux are exposed to legal risks," and "HP's actions are driving the Linux industry towards a licensing program. In other words, Linux is not free."
In other words, perhaps SCO's outrage over its "stolen" intellectual property is less an issue of copyright and more an issue of stopping the continued demolition of its own x86 Unix offerings at the hands of Linux, even if someone else rakes in a few licensing bucks on it.
Finally, we'd be remiss if we didn't mention Jupitermedia's own upcoming Enterprise Linux Forum in Washington, DC. Forum chair Jon "maddog" Hall says it's a "Linux conference for the rest of us," meaning the focus will be aimed at companies new to Linux, or not even using Linux yet. We were happy to moderate a panel or two at the last ELF in Santa Clara, and can attest that it's a tight show with an enterprise focus. The D.C. conference runs October 22 and 23, and features keynotes from Hewlett-Packard and Oracle.
After last week's rush of ssh and sendmail patches, things quieted down in the Unix world. We did, however, find one patch of note after press time late last week: IBM's DB2 on all supported Unix platforms has a denial of service vulnerability. The vulnerability has been addressed in Fixpack 10a for IBM DB2 version 7, and the IBM support site provides information on fixes.
Tips of the Trade
Now and then we like to use this space to plug a piece of software that makes our lives easier. This week's plugee is the marvelous screen.
If you're like most busy admins, you probably maintain several servers from a single console. It can be a real pain moving between assorted servers, especially if you're prone to interruption or find yourself needing to look in on a process from somewhere else on your network. screen takes away some of the pain by, as the project page describes it, "[multiplexing] a physical terminal between several processes." In other words, you can open up more than one login shell on the same terminal at the same time. Moving between the different shells is as easy as pressing ctrl-a and the space bar.
What makes screen even better is that it can detach a process to run in the background, then pick that process back up again from another physical terminal with a simple reattach argument. screen is especially good for programs that don't handle simple control-z backgrounding very well (or at all).
Other advantages to screen: If a detached process needs user interaction, it will wait until the screen is reattached at another terminal rather than spilling the prompts out onto the console. screen lets you start a long process, perhaps a software build, at home, and pick the same build back up once you get to work without missing a beat, and without missing any error messages or prompts that may need to be dealt with.
There's a lot to do with screen, more than one week's worth of tips, in fact. Next week we'll look at configuring screen to make your life on the console more productive. See you then!