.comment: The Price of the Bleeding

By: Dennis E. Powell
Wednesday, October 11, 2000 07:00:00 AM EST
URL: http://www.linuxplanet.com/linuxplanet/opinions/2446/1/

Deja Vu All Over Again

Anybody remember a little atrocity called glibc-2.0.7?

There never actually was such a thing, officially, but that didn't keep it from appearing in multiple incompatible forms on machines running Linux 18 months or so ago--especially on those running Red Hat Linux 5.x.

It mostly worked, to some extent, a little. Users had a high old time of it if they tried to set up StarOffice and get it to run reliably, because it had its own hack of glibc-2.0.7. The Star Division glibc-2.0.7 was not compatible with the Red Hat hack of glibc-2.0.7. The two could be made to coexist, but it was not easy and the result was not pretty.

A lot of distributions held off, waiting for glibc-2.1 before leaving behind the old, reliable but limited, libc5.

I mention this because it illustrates exactly the sort of thing that has caused Red Hat to catch so much hell lately. Hell that it either richly deserves or doesn't deserve at all, depending on what the company thinks it's doing. It's easy to wonder if it even knows what it thinks it's doing.

Release Early and Often

One of the hallmarks of Linux is the philosophy of shoveling code out the door the minute it does something or has the potential for oneday doing something. Indeed, the Linux kernel got its start in precisely this fashion. And open source development could scarcely take place if no one could get the code. There is more than one project that has begun with the release of merely an idea--no code at all.

And that's just fine. It's the way it should be. While the idea of releasing early and often, assigning actual version numbers to each release has been pre-empted in big projects by CVS and CVSUP, which offer code so fresh that in times of rapid development it's possible that no two people have the same "version" of the code, the underlying philosophy remains. This is a Good Thing.

Distributions got their start when it became useful to round up all the available code, burn it onto a CD, crank out some sort of documentation, and ship it. In the early days, when Linux was strictly a hacker's OS, this was just fine, too.

Linux isn't strictly a hacker's OS anymore. Distributions have offered themselves as suitable for business use. They have floated initial public stock offerings and hauled in enormous amounts of money. They encourage enterprises to rely on them.

Distributional Schizophrenia

Red Hat Linux has always had a particular, unique "flavor," as has each of the other leading distributions. Even as Debian has been extremely circumspect and careful, as Caldera has put stability above all, Red Hat has sought and held the leading edge. Red Hat was the first to jump to glibc, for instance, in the 5.0 distribution that few remember very happily. (Even 5.1 had upwards of 60 megs of errata within weeks of its release.) But for users who expected a rough go of it, it was fine. Red Hat was doing what Red Hat did, and aside from the usual distributional chauvanism no one had much of a problem with it--though no one deleted a working Red Hat 4.2 partition then, either.

It would be easy to argue that if a business wanted to get into Linux and happened to settle upon Red Hat 5.0, well, that was its tough luck. A little research would have shown that a different distribution would probably have been better suited for many business purposes.

That argument can no longer be made. It is Red Hat that has made the claim that Linux is Red Hat Linux. It is Red Hat that has established associations with businesses such that there are proprietary software products and hardware drivers not for Linux but for Red Hat Linux.

Well, Red Hat, you can't have it both ways. You can be the bleeding-edge hacker distribution, or you can be the bulletproof business distribution. You can't be both, and any attempt to do so will hurt not just you but Linux in general.

There are businesses out there who will look at things like market capitalization, the flavors of Linux that companies such as Hewlett-Packard support, and your own PR, and these things will lead them to go with Red Hat. They're likely to go with the current distribution on the belief, common in the software world, that the current version is probably better than earlier versions.

Soon, they'll be hiring exterminators to come and tent their computers. And in their minds they will have learned the terrible price of straying from the Microsoft fold.

glibc-2.0.7 Redux

This time it isn't glibc-2.0.7 but gcc-2.96. Just as there was no actual glibc version 2.07, there is no actual gcc-2.96. This fact has not, however, stopped Red Hat from shipping gcc-2.96 in its 7.0 Linux product.

For those who aren't yet familiar with these things, gcc is the C and C++ compiler. It is the engine that, in association with other programs, converts source code to executable binaries. This makes it very important if you plan ever to compile any software. Which, whether you know it yet or not, you do.

Among the things a compiler ought to be able to do is compile a Linux kernel. Linux 2.4, with a multitude of new and useful features, will be released by year's end, and many, many people will want to upgrade to it. This is nontrivial, but it is also not difficult. Unless you are using gcc-2.96. (To be fair, there was a stretch when the current versions of gcc and its parallel compiler project, egcs, wouldn't reliably burn a kernel, either, so distributions typically shipped gcc-2.7.2.x pretty much entirely for kernel compilation. But this stretch is now over, though with gcc-2.96 a new one may have begun.)

How bad is it? Bad enough that last week the gcc organization was moved to comment.

"We would like to point out that GCC 2.96 is not a formal GCC release nor will there ever be such a release. Rather, GCC 2.96 has been the code-name for our development branch that will eventually become GCC 3.0," wrote gcc's Gerald Pfeifer. "Current snapshots of GCC, and any version labeled 2.96, produce object files that are not compatible with those produced by either GCC 2.95.2 or the forthcoming GCC 3.0. Therefore, programs built with these snapshots will not be compatible with any official GCC release."

So here we have the leading Linux distributor, by its own account, shipping a compiler that's incompatible with anything else--and selling it to businesses. Does Red Hat believe that it has achieved the power and stature to decree that the standard is the basically nonexistent gcc-2.96? One hopes not.

Big things are about to happen in the Linux world, and soon. This is the week that StarOffice gets GPLed. KDE2 will be golden in the next week or two. While Linus tells us that Linux-2.4 is still a couple of months away, it will be released by year's end. At least two of these--KDE2 and Linux--won't build with gcc-2.96. Red Hat is therefore shipping, again, a compiler dedicated to the kernel. Red Hat does not much care for KDE.

In an interview, a Red Hat spokesman said that it doesn't matter if the resulting binaries are incompatible, and that anybody seeking to do serious work with any software ought to test it thoroughly first, anyway (which is certainly true if the any software in question is a dot zero distribution from Red Hat). This view is a valid one, but not the only valid one. Another is that a company that advertises Linux for business might want to be a little less cavalier about whether or not the damned thing works.

There Are Other Ways

In the interview, too, Red Hat said (I paraphrase) that releasing flaky, nonstandard, and possibly unreliable stuff is the only way to advance the product. Nonsense. I can point to two other outfits that maintain very reliable distributions while offering the outer limits to users who want to go there: Debian has its unstable tree. Caldera has a second distribution, a kind of technology preview (that you can buy in many places for $19.99 with a $20 rebate), that has nothing to do with its flagship product.

Red Hat itself has had its Rawhide ftp directory, where the cutting edge stuff is available, all compiled in neat little RPMs, allowing Red Hat to maintain control.

The advantage here is that it becomes a matter of user choice, and by definition a more informed user choice. It's one thing to decide to try out the latest development version of the compiler, or C libraries, or XFree86. It's an entirely different thing to package it all up and tell businesses it's just what their IT department, likely made up of Microsoft-certified types, needs.

There's a choice that's even more obvious: anyone who cares to run a developmental version of gcc is perfectly free to download the source and build it. That's the tradition, and it has built into it wonderful safeguards: no one does it accidentally, and no one who is technically inept will succeed at it. This means that there's a pretty good chance that anyone undertaking the project will have an idea why he or she is doing it and will be aware of the risks and problems involved.

What makes no sense at all is slapping together a distribution of stuff that is not exemplary of the stability and reliability of Linux and then luring businesses in, saying that it represents the best that Linux has to offer.