|
 |
|
By Brian Proffitt, LinuxToday 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 Linux 7.0. 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 distribution. Cox denied these charges in the discussion, reiterating his point that Red Hat's efforts were innovative, and not divergent. 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 us." Troan went on to outline Red Hat's position towards the accusations that Red Hat is attempting to depart from the Linux standard. "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 2.96'." 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 files. "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 written statement: "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 happy. "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." | ||||||||||||||||||||||||||||||||||||||||
