Calling the recent days for Red Hat a bit unpleasant is akin to
calling the Great Flood a mild summer rainstorm.
Unfortunately for Red Hat, this is not new ground for them,
since there are a fair amount of critics they deal with on a daily
basis. But the level of ire towards the North Carolina-based
company has reached new heights this week with a flaming thread on
the linux-kernel mailing list and an actual bug submission to
Bugzilla asking for the recall of Red Hat 7.0. Throw in a report on
Slashdot about 2,500 bugs found on the currently shipping Red Hat
7.0, and you get the kind of week that makes a Red Hat executive
reach for the aspirin.
While these events were unrelated, an announcement late last
week from the GCC Steering Committee stirred up the echoing flames
from the linux-kernel brouhaha a week prior and set off a wave of
speculation about the quality of the recently released Red Hat
The linux-kernel mailing list discussion began with a question
regarding problems a developer was having with compilation. From
there, the discussion rapidly grew into a full-fledge argument
about the stability of applications being released with Red Hat,
with the main target being the user-space GCC compilation package
labeled as GCC 2.96.
From there, the argument ensued at full strength, with Linux
kernel developer and Red Hat employee Alan Cox taking up the cause
of Red Hat's decision to release Red Hat 7 with these packages.
Cox's primary argument was that the inclusion of application like
GCC 2.96 is innovative progress for users of Red Hat 7.
"I want people to be prepared to ship new and
innovative things," Cox wrote in the discussion, "If everyone
complains about not shipping precise reference kernels, then all of
a sudden for [kernel] 2.2 I become some anointed high power for
approval for vendors--that is something I don't wish to be and
which would be very, very bad for Linux. Do you really want a world
where you cannot buy a distribution with 2.2 that has Reiserfs
because Alan Cox refused to merge it with the mainstream?"
Despite this statement, several members of the discussion list
would not back away from charging that because of its inclusion of
a compiler that was not binary compatible with anything else, Red
Hat was beginning an attempt to create a proprietary
Cox denied these charges in the discussion, reiterating his
point that Red Hat's efforts were innovative, and not
Cox's comments were echoed by Eric Troan, Red Hat's VP of
Product Engineering in an online interview with Linux Today.
"The questions which have arrived over the compiler is actually
about the user-space compiler we ship, not the kernel compiler. The
kernel compiler is essentially the same version we shipped in the
last couple of Red Hat releases," Troan explained. "The user space
is based on a snapshot version of gcc, which we have tested
extensively inside of Red Hat. While no compiler is perfect, we've
built tens of millions of lines of code and it works very well for
Troan went on to outline Red Hat's position towards the
accusations that Red Hat is attempting to depart from the Linux
"As for the compatibility issues, we do think binary
compatibility between Linux distributions is very important. We do
not ship kernels with extra APIs unless Linus Torvalds has accepted
those new APIs into the development kernel trees. Likewise, we work
hard to maintain full backwards compatibility," Troan said.
"As the Linux Standard Base (LSB) group gets finalized, Red Hat
will be fully compliant with it's recommendations, ensuring that
LSB compatible applications will run on the widest varieties of
Linux-compatible systems possible," Troan continued, "Fragmenting
the Linux binary APIs will not help anyone.
"Moving Linux forward is important, however. Doing that requires
changes that can make it difficult to move applications from newer
systems to older ones. This is inevitable, and every platform
vendor has this type of problem (applications built for Windows
2000 apps do not work on Windows 98, for example, and Solaris
applications do not run on SunOS). The LSB will provide a common
denominator to allow application compatibility between releases
while still providing a path for new features to be added to Linux
distribution," Troan explained.
The GCC Sterring Committee's position on the matter was released
last Friday, when the committee announced its disapproval of the
"GNU/Linux distributions... currently shipping with 'GCC
In the message posted on the gcc-announce mailing list, steering
committee member Gerald Pfeifer explained that "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."
Pfiefer could not be reached for clarification on which specific
distributions the announcement addressed.
The problem of compatibility, first argued in the earlier
linux-kernel thread, is that programs created with the 2.96 version
of GCC are not compatible with GCC 2.95.2, the last official
release, and the future GCC 3.0 release, due to incompatible object
"Actually, C and Fortran code will probably be compatible, but
code in other languages, most notably C++ due to incompatibilities
in symbol encoding ('mangling'), the standard library and the
application binary interface (ABI), is likely to fail in some way,"
Pfeifer clarified in the GCC announcement, "Static linking against
C++ libraries may make a binary more portable, at the cost of
increasing file size and memory use."
Red Hat has taken the GCC announcement fairly in stride. Red
Hat's Chief Technical Officer Michael Tiemann had this to say in a
"While many customers are satisfied with our... 6.2 product,
many others want to build their products or infrastructure using
some of the many enhancements that are now available as development
sources. Red Hat did its best to judge which sources were ready and
which sources were not ready for our Red Hat Linux 7 distribution,
and in truth, there was no choice that would make everybody
"Many online forums will continue to debate the merits of the
choices we made, and we respect these debates as part of the
strength of the open source model," Tiemann continued. "We also
acknowledge that these discussions represent only a part of the
broader market we serve. As long as these discussions are
productive, Red Hat will participate in them, making each release
better than the last and delivering the support necessary to make
our customers successful with Red Hat Linux."
The overall quality of the Red Hat product also came into
question in a Linuxnewbie.org posting which directed readers to the
2,500 bug report and the specific bug on Bugzilla that asked for
the recall of Red Hat 7. This article was in turn linked to by
Slashdot, where the discussion inflamed the rumor of the 2,500 bugs
alledgedly in the Red Hat 7 release.
Troan's response to this posting was direct: "First of all, the
2,500 number was all of the open bugs in our ticket system for all
releases of all products. It includes engineering requests as well
as our engineers internal todo lists for future releases.," Troan
said. "The very fact that someone queried our ticket tracking
system, counted the results, and assumed those were all unique bugs
in Red Hat 7 makes the Slashdot post unfair at best."
When asked about criticisms that Red Hat's development cycle is
too fast to allow for the release of quality products, Troan
replied, "Is our release cycle too fast? We don't think so. Users
who are running 24x7 production boxes should definitely use a
proper test methodology before deploying new releases of any
software, including Red Hat Linux. Open Source moves remarkably
fast, and Red Hat is proud to deliver that level of innovation to
our user base. Our testing and quality processes have matured
greatly over the past few years, and Red Hat 7 is undoubtedly of
higher quality then Red Hat 6.0 or 5.0."