Slashdot Mirror
GCC's Response To Red Hat
The GCC Steering Committee has issued a statement on the use of snapshots in distributions. This statement is clearly in response to Red Hat's use of gcc-2.96 in its Red Hat 7 release. They didn't like it very much, and there are compatibility problems. Worth a read. Credits for this news goes to Linux Weekly News.
Richard Henderson ignores the issue of binary compatibility with other distributions, and, I believe, overstates the problems with 2.95.2. The Alpha back end isn't great, but ia32 which most folks use was decent and it was the best C++ front end we ever had. And the kernel developers did a lot of work so that at least the Linux development kernels build ok with 2.95.2 -- but "2.96" can't build Linux (gcc problems building the kernel are often kernel, not gcc, bugs, though sometimes gcc is at fault).
Also, Richard is wrong when he says that their "2.96" is compatible with the forthcoming 3.0 at the source level. It isn't; it still uses libstdc++-v2 (the v3 library is not complete). Streams aren't templates, the standard library is not in the std namespace. It is compatible with 2.95.2 at the source level, not 3.0.
Even so, I could have accepted his arguments much more readily had they been made before the release and not after, and if they had polled customers and software developers about the issue rather than just deciding internally.
Now, I'm grateful for all the hard work the Red Hat/Cygnus folks have put in. But when different (GNU/)Linux distributions can't run each others' binaries, you have exactly the same situation the Linux company chiefs say they won't allow to happen: effective forking of Linux.
Where did you get the idea that 2.95.2 is "the buggiest release of GCC since early days"? Have you ever used it? Did you know that it is the production compiler on Debian 2.2 and they are reasonably happy with it? That it had some of the most thorough testing of any GCC release ever?
I've been an active user of g++ since 1990. For C++, 2.95.2 is the highest quality release ever put out. The problems with 2.95.2 are platform-specific, the Alpha port wasn't great. Don't spread false information.
I agree that the C++ ABI issue is a horrible mess, but you really can't blaim AT&T for that. If the C++ ABI had been set back in early days, it would have had to be revised several times over the years as templates, namespaces, and so forth were added to the language. For this to have been any better than the present situation, a much more extensible object file format would have to have been created than we use today.
The real issue is that C and C++ still use a flat namespace for symbols in object files, just like in the 1950's when assembler languages were all that existed. The minor additions made to ELF for static constructors and the like were the absolute minimum to get C++ to work--leaving no option but kludge-of-the-day name mangling to flatten C++'s multitude of hierarchies. This is so inelegant that no one wanted to define it into a standard -- surely a better way will arise? But it hasn't.
CFront's name mangling could have been taken as the de facto standard and extended as C++ was extended. That didn't happen, and given that AT&T didn't "own" C++ the way that Sun owns Java, it probably wouldn't have happened even if they pushed it. But why perpetuate what is an ugly kludge, anyway?
It's probably too late to fix the real problem. Rejiggering the entire toolchain for a new object file format just isn't going to happen. (Some people are still smarting after the change to ELF.) So we'll have to live for the forseeable future with fragile and incompatible attempts to fit N-dimensional structures into flat lists...
Has anyone ever stopped to wonder whether redhat did this to CREATE incompatibilities? Redhat is the market share leader. If someone distributes a binary, it is most likely going to be for redhat. What's an easy way to "compete" with other distributions? Make sure that binaries for your linux won't run on other distributions. This forces companies that want to distribute binary-only packages, or packages that are not easy to compile, as multiple binaries thereby confusing the scene. If other distributions follow redhat and use this compiler, well then you've got a situation where redhat is the leader and everyone else is trying to be compatible with it. You've got that already to some extent, but this would make it even worse as distribution developers would have to work to stay RH compatible.
I don't know if this is what redhat is doing, but it certainly is interesting.
Personally I think they've pulled a DOS 4.0.
Lee Reynolds
Muslim community leaders warn of backlash from tomorrow morning's terrorist attack.
Yes, RedHat is evil (in this circumstance). Releasing snapshots of absolutely-critical components of an OS is evil. Whatever their technical/marketing reasons for the inclusion, it was irresponsible. Free software should enjoy the same respect of version control as do commercial products. To do otherwise weakens the notion of free software products as being stable, manageable entities, and will lead people to choose products that noone ever got fired for choosing (VC++ 6.0, for example).
It's a matter of whether you believe "the ends justifies the means". Sure, Linux is all about practicality, but I would also like a little discipline in my commercial distro. (that's why I run FreeBSD)
What gets me is this: why the mad upgrade cycle? I mean, I understand why redhat has to release a new 'version' of RH now and then... to keep sales up, but...
That is SOO microsoft. We don't NEED an upgrade every year.
My problem, though, isn't with redhat releasing them.. it's with people who decide to 'upgrade' their systems. Feh!
Why do you upgrade something if it's not broke?
Rule #1 of systems management: if it's not broke, don't fix it!
From what I heard, RedHat thought that the gcc 2.96 snapshot they got would be library compatable with gcc 3.0. They didn't want to ship 2.95.2 because it is a dead-end branch that isn't compatable with either 3.0 or egcs. They didn't want to ship egcs because stuff like kde2 won't compile with it. They truly stated that they *really* wanted to avoid breaking the C++ ABI twice (once going to 2.95.2 and once going to 3.0)
So, they were caught between a rock and a hard place... The didn't have any "good" compiler to ship, so they did the best they could and shipped an older egcs release as "kgcc". They could have postponed their release (like Linus just did for 2.4), but who knows how long before 3.0 is released? Also, they have a lot of customers without requirements for a specific version of the compiler... Why make those guys wait for the GCC guys to get 3.0 finished?. As it stands 2.96 compiles most C and C++ code correctly (or as well as any other version of GCC), and kgcc compiles the kernel. It Seem To Work(tm) for most people, if they have correct C++ code, and use kgcc for the kernel.
That said, there have been a *lot* of problems reported with RH7, though many come from not RTFM ("I can't compile my own kernels!"). They probably should have delayed shipment for more QA, but not necessarily waited for a new compiler.
Stop and think. Why would a distribution ship a compiler that is off the development branch? Why in God's name would they ever do anything so incredibly horrible as that?
Simple: features. Many of you may be C programmers, so you may be scratching your head right now, saying "Huh? What features?" But if you work with C++ (and you will notice it mentioned specifically in the post from the GCC team), you know what features RedHat was trying to get by going with the supposed "2.96".
Now, before someone goes off all half-cocked and starts bitching about C++ and C being better, go read up on Inti, specifically on the why's. RedHat will make its money either directly or indirectly from its distribution--the more people who buy Linux, the more ways for them to make money. More people will use Linux if there is software. More software will "appear" if companies use Linux as a development platform.
From what I have read about Inti and its reasons for being started, companies are passing on Linux because they cannot get good enough C++ support and tools in Linux. That's right--C++ support is hurting Linux.
Yes, yes--C++ sucks, yadda, yadda, yadda. Stop and think. The reason so many of you turn your noses up at companies and work is because they pretty much require you to use C++ anymore. I'm not saying it is fair. I'm not saying it is necessarily a "good thing". I'm just raising the issue--most development shops, if given a choice between C and C++ use C++. Perhaps this is all Microsoft's fault. I have no idea.
But I happen to use C++. And let me tell you, writing C++ with the gcc/g++ is a royal pain in the ass. The ANSI standard has been out, and many vendors are still getting their stuff together. But the gcc is one of the lagging ones (IMO--I may be wrong, please list any worse offenders). You buy the C++ Reference by Stroustrap and try to follow the examples (try using sstream with anyone besides RH 7.0, and you will see what I mean)--endless amounts of frustration.
RedHat is just sooooo evil. They included a compiler that had better C++ support. Before you demonize them, stop and try and see it from their perspective. I for one, appreciate a better STL implementation--the one in 6.2 was just aweful. 6.2 had a C++ library with a build date of February 2000. Now that may *sound* new, but it isn't. It isn't even close to the current standard in some areas.
All that being said, I'm not sure that the "negatives" that come with 2.96 were worth it. I would have rather seen RedHat include a good STL port (I hear there are a few good projects out there). Still, the C++ support found in current Linux distribution sucks. Just join any linux C++ project mailing list and see how many times gcc bugs will come up :-(
And if you think this is flamebait, you best check your moderator rules.
"Doubt your doubts and believe your beliefs." -- Switchfoot, Ode to Chin
In my opinion, Open source is going to show more and more of these problems because of the conflict of interest between open development and maintaining commercial advantage to remain competitive.
The fundamental issue is that if you are going market an operating system, you need to have a well defined and controlled environment for building the OS, especially the compilers and linkers. In fact, the very first part of the PetrOS project was to create a compiler capable of building the kernel from, which has proved fruitful because the kernel is extremely stable - I know exactly what machine codes are executing at any point in the kernel. When you are left to a 3rd party compiler, you are at the mercy of the compiler developers interpretation of how the language should be implemented, and even suffer the bugs they may have left in the distribution. I am only too familiar with that aspect.
The other issue that open source developers face is the frequent version releases, some perhaps not fit for public consumption. Clearly in this case, the gcc people should have made their version numbering scheme represent the beta nature of the product. Heck, even we do that with Trumpet Winsock. Before we go to major version release, we tag the version number with a beta sub version number to clearly indicate that the product won't be supported and that it should not be used for any production implementations or distributions.
It is for precisely these reasons that I have opted not to endorse an open source model for the PetrOS project, but rather some form of synthesis whereby key parts of the distribution are kept closed source, but allowing some of the outer edges of the project to be open source. I believe this is the only way for complicated projects like an operating system.
The other comments I hear (hearsay???) about Red Hat being closed shop about their plans hints of corporatism.
A word of advice to all those penguins out there. Beware the corporate world - it's ruthless and they'll take every advantage of the open source movement, even to it's detriment!!! I'm certainly not saying that Red Hat are doing this, but sooner or later, some company who wants to cash in on the Open Source movement will come in and plunder all the good work that's been done. Perhaps this incident is a small warning of what *could* happen. It's happened before in other parts of society - eventually "feel good" movements get exploited in one way or another either politically or economically.
I could say more, but it really deserves a much better appraisal than an off the cuff comment on a forum.
Don't get me wrong, I am in no way denigrating Open Source - I'm just saying that trying to operate it on a commercial basis is full of problems.
Dunno, i don't agree with using snapshot's in distrobution... i find that just wrong, imho
This is just "a snapshot of the day" - this was a snapshot from a good time before we went gold, and after that we spent lots of time QAing it and fixing it.
Well folks, this clearly does make matters more difficult, both for the GCC Steering Committee, which now has to deal with the repurcussions of Red Hat's decision, and for people who use "2.96", which will not be binary-compatible with 2.95.2 or upcoming 3.0.
However, I don't think choosing which GCC version to use was this simple a matter for Red Hat. After all, they needed to maintain compatibility with the Linux kernel on the one hand, and have better I18N support on the other. The reason Red Hat included "2.96" was because they desperately wanted better I18N support... I'll bet it was probably because they are trying to compete on the international front, most particularly with GUESS WHO (hint: SuSE and TurboLinux). Heck, I'll admit I'd have a hard time deciding on this too, especially when it could mean $$$ for a company which has yet to make a profit. Then there was "KGCC", because after all, who wants a distro that has a non-working kernel?!?
I do think Red Hat has been a bit too eager to include bleeding-edge packages in its distros, but in some cases, including this one, it is NOT just done without careful consideration. I think they should be cut just a little slack on this one.
It would be really nice if there were more people who understood management issues as well as technical issues, who could swim in both ponds. Put such a person in charge and you could be sure that important issues from both the management/business/marketing side of things and the technical side of things would each be properly dealt with.
As it is now you've either got a technical genius who knows nothing about how to run a business, or a manager who knows nothing about technical issues. People who are a little of both are rare. Bill Gates is the obvious exception to this rule. Sometimes it isn't that bad of a problem if the mangager is willing to listen to the people who understand technical issues. Someone who is smart and wise enough to understand what it is that they don't know and listen to those who do know those things is always an asset. But when you've got a manager who due to some psychological or emotional malfunction is unable or unwilling to listen to others, then you've got big problems.
A company which can't attract and keep good customers because their product's quality has declined or is no longer competitive will itself decline. In that situation even the best manager can do nothing more than delay the inevitable. When management isn't willing to listen to the people upon whom their profits truly depend, those managers are maiming and sometimes murdering the company they work for. Ion Storm, John Romero's new company and producer of the not so thrilling Dikatana, is the perfect example. From what I hear they had a psychotic in there running the show and of course causing such huge upsets that half the developers walked on the same day.
I think this is the reason why CIS degrees are popular. The idea being that a graduate of such a program would be skilled in management and aware enough of technical issues to be able to make decisions. The problem is that CIS majors don't learn much on the technical side of things. I work at a university in the college of business so I have some concept of what they are studying. Imagine a handful of elementary programming classes in C++ and Visual Basic in addition to some database stuff? The rest of the degree is all business related. A person like this may be more dangerous than a clueless manager because they might remember just enough from their classes to be truly dangerous, especially if they think those classes qualify them as an expert.
I don't know what exactly is going on at Redhat. You would think that simple testing would prove to even the most pointy-haired of managers that 2.96 simply didn't work right. Things like this don't happen by accident. Either there was woefully insufficient testing, or the results of the tests were ignored. Sometimes people with good track records mess up. If that is the case here then very little needs to be done other than make sure the person or persons responsible understand where they made a mistake. If however this is due to someone who is a screw up or causes problems, get rid of them.
Creating a company is not easy. Finding the best people you can find and constructing a work environment and system that maximizes the ability of each person to do their job can be tricky. But it can be done by people who know how. Such people cannot be deluded about their own self importance. They must understand that they are the grease that coats the gears to allow the real work to be done. The moment they forget this and begin to think that, due to their usually higher salary, that they are a gear is when the friction will begin to mount.
Lee Reynolds
Muslim community leaders warn of backlash from tomorrow morning's terrorist attack.
suggest that builds are actual successors to earlier releases. The
Mozilla milestone approach, and the linux-kernel `test' and `pre'
releases can help to avoid this.
Still, it is exceptionally incompetent of Redhat to release a
distribution based on code generated using an unfinshed compiler whose
binaries are incompatible with existing official releases.
It's not really fair to leave out Richard Henderson's explaination on linux-kernel...
Basically he says 2.95 isn't that great on non-x86 platforms and their version is much better, and that 2.95 already has incompatibilities between egcs 1.1 and the future gcc 3.0 so it doesn't make a big difference.
But doesn't Red Hat own Cygnus, ie, the single largest part of GCC development? Couldn't they just ask them?
I heard a while back the reason MS has problems was (partially) because they had no intercommunication between, say, the browser, the kernel, and the office suite teams. I always thought that free software development was better, you could just ask the next guy "Hey, does your Foo work with my Bar?" But if Red Hat can't manage to phone their other building and say "Hey, is your GCC ready for any kind of release with RH7?" it's kind of disconcerting.
Oh well. Time for me to start evangelizing Debian to all my friends again.
Windows 2000: Designed for the Internet. The Internet: Designed for UNIX.
...considering four out of the fourteen members of the steering committee are from Red Hat.
I don't agree with RedHat's decision to ship what was essentially a snapshot, in RedHat's defense I have to say that they were faced with a dilemma. They could either:
They chose the last option, knowing that there was no possibility of having 3.0 compatibility aside from option #2, and that they'd at least get a stable and largely standards-compliant C++ compiler.
After RedHat chose a snapshot, they continued to follow subsequent snapshots but because of the necessities of release engineering created patches against the original snapshot, which has lead to the accusation (largely unwarranted) that they have forked GCC.
Personally, I think they should have stuck with 2.95.2, warts and all, but it was a judgement call for them, and the path they took is not without some justification.
(BTW, the FreeBSD folks are so disgusted with 2.95.2 that they're considering making a similar move.)