Enterprise Unix Roundup: Linux Heavyweights Turn a Corner

by Michael Hall

SUSE and Red Hat neatly encapsulated the post-boom Linux company story this week as Novell announced plans to scoop up SUSE with a little help from Big Blue and Red Hat formalized a major business model shift. And for those who've been lured by tales of how much faster software can run if it's compiled using optimization flags, we suggest making time for 'time,' a program that reports how long a command takes to execute.

There's a school of thought among long-time Linux watchers that the real Holy Grail for most Linux companies isn't the death of Microsoft or even mere profitability, but salvation by buy out.

Pushing Linux in and of itself is a dead end, goes the theory. The only hope these people really have is to 1) make a product so good that enterprises cough up the dough on a yearly basis for updates, or 2) be swallowed by IBM and become a Linux R&D division for big iron.

This particular outlook won some water cooler bragging rights this week, as the two most viable commercial Linux outfits, SUSE (neé SuSE) and Red Hat, announced acquisition by bigger fish and formalized major business model shifts, respectively.

SUSE has an interesting background in the Linux space. Among enthusiasts and desktop users, it enjoyed a following not unlike our favorite college band: Popular among the cognoscenti and "big in Europe," but always an also-ran in the United States, trailing in name recognition to the more popular and less tuned (by desktop standards) Red Hat. Some of that may have been because the company was as defiant as the GNU "copyleft" allowed it to be when it came to giving away product: It followed the letter of the license on releasing source code, but consistently dragged its feet on making downloads of its latest releases available. Red Hat, in contrast, has generally released its downloadable and retail versions simultaneously.

Desktop popularity aside, SUSE's real earning seemed to stem from deals with IBM that involved tweaking Linux for big iron. IBM S/390's, for example. That relationship fueled much of the talk about SUSE being an IBM acquisition candidate.

Come January 2004 (as has already been covered in exhaustive detail), if all goes as planned, SUSE will be bought out, if not by IBM, then perhaps by the next best thing: Novell will do the acquiring, with part of its purchase underwritten by a $50 million stock investment from IBM to ease the $210 million price tag. Along with its recent focus on NetWare as a suite of Linux services and the purchase of Linux desktop company Ximian, Novell is now pretty much a "Linux company."

Time will tell whether SUSE will be known as a company that successfully navigated the perilous shoals of shedding its old, tired identity as the company that Windows NT killed or, alé Corel, did itself in chasing a Linux exit strategy that it didn't have the staying power to execute.


It won't be so bad to stay "popular in Europe," where Linux and open source software in general are riding a wave of deployments in government, which has Microsoft and its proxies in the "Initiative for Software Choice," an organization founded to counter pro-open-source legislation, feeling distinctly uncomfortable. Novell took pains to point out that SUSE's German headquarters will remain intact. In the United States, where Novell still has presence, albeit a diminished one over the past few years, SUSE has as much of a chance as it did before, when Red Hat was holding it to a sub-25 percent market share. Here, Novell's marketing power might even help.

In many ways, the acquisition represents a second second chance for SUSE after it threw a lot of weight behind United Linux in an effort to form a consortium with little purpose other than subjecting Red Hat to death by dogpile.

And perhaps it was the resounding flopping noise United Linux made that emboldened Red Hat to get around to telling everyone what we've seen coming since early this year: Red Hat Linux as we know it is dead. The company sent out a formal end-of-life announcement to its customers on Monday. As of December 31, errata support for versions 7.1, 7.2, 7.3, and 8.0 of its distribution will be discontinued. Red Hat Linux 9 users get a reprieve until April 30 of next year.

While Red Hat will continue to contribute to the open source Fedora Project, which represents a more openly developed version of Red Hat Linux than the company could get behind when its revenue hinged on shipping shrinkwrap, the end-of-life announcement solidifies the evolutionary process we discussed two weeks ago. Good or bad, the company is now committed to its enterprise offerings.

The announcement received its share of dismayed squawks from predictable parties, including customers that may have recently invested in Red Hat Linux 9, which has been out for less than a year. They're receiving some salve for their burned noses in the form of 50 percent discounts on Red Hat's Enterprise Linux ES and WS (Enterprise Server and Workstation offerings) for the next two years. The products normally cost $349 and $179, respectively for the "Basic Editions," which puts the workstation offering at about the same price point that Red Hat Linux 9 sold for on retail shelves.

Less credible are the complaints of hobbyists who say this represents some sort of betrayal on Red Hat's part. We've said it before and we'll say it again: Red Hat's "give away the razors and the blades, and make money explaining how to work them" business model was doomed. Red Hat "gives back to the community" in ways other than free downloads, including its employment of some big sticks in the Linux kernel developer world. When we indulge our idealistic streak and consider Red Hat through the eyes of an open source activist, we don't see much to complain about.

With their announcements this week, SUSE and Red Hat have neatly encapsulated "the post-boom Linux company story." One has found an out in the form of acquisition, the other in going for broke on the salable strength of its product.

In Other News

  • IBM has demanded, through a Motion to Compel Discovery, that SCO produce the source code it claims was purloined by Linux kernel developers. The alternative, says Big Blue, is for the courts to toss SCO's lawsuit out. SCO claims to have already honored its obligations in that regard. Our sister site, LinuxToday, continues to cover the angles of this one as thoroughly as anyone.
  • If you can't get enough SCO coverage, you'll have a chance to hear CEO Darl McBride keynote at Jupitermedia's own cdXpo in Las Vegas, from Nov. 17 to 20.
  • Apple OS X 10.3 (Panther) users are probably feeling mauled. The latest version of the Unix-based operating system arbitrarily formatted Firewire-based hard drives during upgrades, which might not seem like such a terrible thing -- until one considers that handy external hard drives are the perfect place to keep valuable files safe during an upgrade of the operating system on the main disc. Ouch. Apple has identified the problem and fixes are out.
  • OpenBSD 3.4 was released late last week, and the OpenBSD organization announced the immediate end of life of OpenBSD 3.2 on Monday.
  • Elsewhere in the BSD world, FreeBSD is approaching its tenth anniversary. Plans to celebrate with a party in San Francisco are under way.

Security Roundup

It wasn't a big week for widespread vulnerabilities. We did notice a recently updated kernel bug that affects BSD family kernels (it's been documented specifically in OS X and FreeBSD) that could enable an attacker to cause a panic condition with the transmission of a large volume of spoofed ARP requests.

We also caught a Red-Hat-specific Apache bug that could allow a remote attacker to view directory listings by sending a specific HTTP GET request. Although the bug doesn't result in a direct compromise, it could aid an attacker attempting to gather sensitive information about a targeted system.

Finally, and in case you missed its importance to your system's security, end-of-life announcements were issued for Red Hat versions 7 though 9 and OpenBSD 3.2. They lift the burden of responsibility from those organizations and place it firmly on the shoulders of admins running those systems past their end-of-life dates. Considering conversations we've had with consultants and vendors in the past six months about versions of Red Hat Linux as old as 7.2 still in use in assorted operations and solutions, the December 31 cutoff looms rather large.

Tips of the Trade

If you maintain a Unix server, you've probably been faced with the issue of building the occasional package from source code. In a few previous columns, we've even offered some tips for how to smooth out the process of maintaining compiled packages.

You may also have been lured by tales of how much faster software runs if it's compiled using certain optimization flags. We understand the allure of optimizations, but we suspect there's much wishful thinking in some of the more breathless accounts of "blazing speed" gained from using some of gcc's more exotic flags, and we know that some "optimizations" introduce instability in some cases.

A datapoint for this debate appeared this week in the latest edition of the Debian Project's weekly newsletter, where an enterprising developer reported some surprising results on just how much faster "optimized" code can run. Or how much slower, since his figures indicate that his application performed worse when compiled with even simple optimizations.

So our tip this week isn't a pointer to a useful program or interesting trick. Instead, it's a reminder that the usefulness of lore passed around by self-styled gurus can fade with a few judiciously applied benchmarks, but not before causing plenty of headaches.

And if you absolutely must try out an optimizing trick, we'll go ahead and offer a program that helps you do your own benchmarks: time.

When used before a command, "time" reports how long that command took to execute. Just today, we were asked to look back into our archives for a piece of mail sent months ago. If we wanted to time how long the search took, and assuming it was a simple grep for the word "styleguide," we'd execute this command:

time grep styleguide *

which netted us the following results (and a sudden awareness that we keep too much old mail around):

real 0m9.576s
(how long the command took to execute in real time)
user 0m0.090s
(how many CPU seconds the program used to execute)
sys 0m0.230s
(how many CPU seconds the system used to execute the program)

We've heard exotic tales of time being used to count the total seconds per year users spend in certain applications, and we've seen it used to resolve flame wars over just how fast "hello world" runs when compiled on in iMac running Jaguar vs. on a Celeron running Linux.

Most people, however, will probably just want to use it to make sure the spiffy optimization flag someone told them to try isn't snake oil and wishful thinking.

This article was originally published on Thursday Nov 6th 2003
Mobile Site | Full Site