I installed RH 7 this weekend, against the advice of co-workers and others. In the hour that it inhabited my drive (before I reloaded RH6.2), it caused me more frustration than any other Linux distro ever has.
Firstly, RH7 ships with gcc 2.96, which is a development snapshot of the program. While RH claims to have been able to use it with no problems, I was unable to compile a single program without a failure occuring. Notably, gcc 2.96 breaks both pvm-3.4.3 and pvm-3.3.11, which are used on Beowulf clusters. I didn't try compiling MPI, but I'll go out on a limb and say that it probably doesn't work either. I'm extremely disappointed with this release...
Update: 10/11/2000: And, it apparently has a flaw that limits the uptime to three weeks. The Redhat Update Daemon leaks file descriptors, which cause a failure after this time. RH says that a patch has been released, however.
Update: 10/12/2000: Bob Young released a letter regarding RH7. It may be found below the Linux Today press release.
More info:
http://linuxtoday.com/news_story.php3?ltsn=2000-10-09-005-21-NW-CY-RH:
By Brian Proffit
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."
An open letter from Bob Young, regarding RH7
Subject: Freedom & personal responsibility good, serfdom & tyrannical control bad.
From: bob@redhat.com
Dear Slashdotter,
The wild and heated debate about Red Hat 7 in recent days has been interesting to follow. It demonstrates the strength of the open source model. By comparison (I'm not sure if anyone noticed this) Computerworld had a front page story a couple of weeks ago about how there were problems with Solaris on Sun's Enterprise systems, but that these bugs were not well known because Sun was making their customers sign NDA's (non-disclosure agreements) before helping them fix the problem.
Consider the contrast between a proprietary vendor's unwillingness to debate the merits of their technology with the open debate that Red Hat Linux enjoys.
This discussion is of such value to the users of Red Hat products that we feel little need to even attempt to comment. Informed readers can read all sides of the debate, download our products, test them, and decide for themselves whether our critics or supporters are correct. Of course the readers who post things like "well I haven't tried RH7 but I've heard..." aren't very helpful, but I trust most Slashdot readers to see through that kind of stuff.
There is one recurring comment that I could not resist addressing. Namely the regular habit of our critics of comparing Red Hat to Microsoft. I just don't get it.
There are many things for which we should be justifiably criticised (I have no idea what these might be, but I'm certain they exist ;-) but trying to act like Microsoft is not one of them. Red Hat's business is built on solving the problem thatMicrosoft's business model has imposed on the software user since Bill Gates disagreed with the members of the Homebrew computing club back in 1980.
The software industry that Microsoft has been the role model for is built on the premise that customers are not to be trusted with the technology that they are building their organizations on. The legacy software industry is built on the proprietary binary-only model where not only does the user not get the source code he needs to make changes, but worse he receives the product under a license that essentially says that if you make any improvements to the technology you are using, if you solve a bug that is causing your systems to crash, or add a feature that your users or customers desperately need the vendor can have you thrown in jail. (If you don't believe me, just read any shrinkwrapped software license). This kind of business model, where the customer is completely beholden to his supplier exists in no other industry in any free market that I know of. It harks back to the old feudal systems of 12th century Europe.
Red Hat's business success is owed to one simple benefit our products and services offer that our larger binary-only OS competitors do not. Namely that our commitment to publish the code that we write and distribute under open source licenses enable us to give our customers control over the technology they are using to build their systems. We cannot promise to deliver perfection. All we can promise is to acknowledge the problems immediately and work with you to fix them publicly and in real time. With control over their systems our users can simply build more stable and reliable systems than the binary-only model allows.
This is why the fear that Red Hat is somehow going to wake up one morning and abandon our commitment to open source is so mis-placed. Open source provides us with -the- competitive advantage that enables us to compete effectively against much larger competitors. To abandon open source is simply not in our customers interest and hence not in Red Hat's financial interest.
So if you want to criticise us for shipping gcc 2.96, you have every right to do so - you'd be wrong, but it is at least a legitimate debate and I'd respect your opinion. But to compare Red Hat to Microsoft indicates an ignorance of what is driving our success.
Remember that this debate was begun by someone going to Red Hat's public site and trying to add up all the registered bugs in Red Hat 7. When was the last time Microsoft (or any other legacy software vendor for that matter) gave you access to their complete bug registration system? Which software model do you really want to see succeed? One where you have to trust your vendor (who can and frequently restrict access to information you does need) or one where you are in control of the technology you are using?
We may be making mistakes - that up to you to decide. Some of them may be important to you and while I have no doubt you will point them out to us, you have control over the technology you are using. We work hard to build products that please most of our users most of the time. But if you don't like something about Red Hat Linux you don't have to use that feature or function. We simply are not pursing a business model that bears any resemblance to Microsoft's, so just quit it.
The next slashdotter who compares anything Red Hat does to Microsoft will be punished. The punishment will be to find the nearest blackboard and write "freedom & personal responsibility good, serfdom & tyrannical control bad" seven hundred times.
Cheers, Bob.
The flamefest: http://slashdot.org/article.pl?sid=00/10/09/1819249&mode=thread