An important factor is that we have developers in different areas (compiler, kernel, glibc) and thus can offer porting to new platforms etc. Noone else can offer the same.
Another is of course the level of support Red Hat and partners can provide.
No, we made a consciuous effort (that is, QA, testing, fixing) to include the best tool currently available. It's way better than egcs or gcc 2.95.2 which was why we did it in the first place.
We're not discontinuing support for multiple platforms - just wait and see. We haven't announced anything (as in will do/won't do) yet, so saying we won't is way premature.
Red Hat Linux 7 has the USB backport (done at linux-usb, which seemed to stabilize this summer and is now even going into mainstream 2.2)
We only support mice and keyboard, the rest of the modules are included "as is" - most seem to work, while others have problems (especially usb-storage, which to be really good would need a backport of the 2.4 SCSI layer)
We're bringing the techonology out for developers and users to use....
... and in the process of so doing, mature and bring the technology forward. Note that most changes to gcc, gdb, rpm and good parts of other systems (gtk, GNOME, kernel, glibc) come from Red Hat employees - we are actually creating the technology. Another company which does
much of the same, is SuSE. Other distributions, like Slackware and Mandrake don't come close to this level of innovation and influencing on the future of opensource technologies (this doesn't apply to Debian, which by nature couldn't do such things - Debian users contribute as individials to the different projects)
We had updated CDs in the past, but it was unpopular with sysadmins etc. who wanted to know exactly what was on a CD: Changes and updates could be applied after install. So we stopped years ago.
It is clearly marked as a snapshot(the version string says "Red Hat Linux 7.0"), and it is currently the best compiler for our needs.
We're obviouly not going to issue a "blessed" errata unless it is fully compatible - we care about our product and and compatibility, having multiple releases of compilers etc. is completely unmaintainable and might confuse people developing on it.
Anyway, this discussion is at a dead end. We released a fixed snapshot, we're not doing anything wrong with this (we should have told the gcc steering committee, but technically it was the right decision) and we're not going to break compatibility with it. EOD.
MOSIX and "beowulf"-type clusters are totally different beats.
MOSIX just migrates the application to one computer, beowulf is about letting it run on many computers at the same time. To do the latter, the applications need to programmed differently - no matter how people would want it to be, someone needs to split the computation into parts which can be computed at the same time. Some operations can be done by compilers (like for loops without inter-dependecies in the data) and others (like some common linear algebra routines) can be placed in libraries, but there's not going to be an automatic system for parallellizing everything: Knowing what parts of the problem can be computed at the same time and what data is needed to do so will continue to be important for scientific apps.
Of course I can defend it - technically, it was the right decision and I still think we should have done it. We needed the features (like actually working, and support for multiple platforms), and as probably the only company have the inhouse expertise to stabilize it. The C++ compatibility issues are far less important - as C++ has never been compatible anyway.
What we did wrong was not communicate our intentions better to the steering comittee.
Releasing a "blessed" gcc (if not looking at our compat-compilers which are egcs 1.1.2) is of course not going to happen - they wouldn't be compatible, and the reasons we had for choosing to do what we did are still valid. We did the right thing, and in so doing improved the current state of gcc a lot. Be happy.
Kernel development aren't the people doing the distribution - OS Engineering is. The kernel is only one (but major) part of the system,
Backing out major items liks glibc and the compiler late would be very hard after making the entire distribution on it (and if late enough, not enough testing either). Also, integrating these for all platforms (including IA64) would be next to impossible - the current IA64 toolchain look a lot like the one in Red Hat Linux 7, and this isn't a coincidence. Add to that that we commit to binary compatibility for many releases, and needed better i18n support for the Japanese product. We would definitely prefer not to ship pre-releases (although heavily QAed and fixed), but we felt we didn't have much choice.
As for speaking to the rest of the authors, this was a miscommunication internally (I would estimate that most come from Red Hat anyway, from Jakub Jelinek in OS Engineering and former Cygnus)
"shipping a snapshot": This was cut of the tree a long time before shipping and then QAed and fixed. Us wantin to ship it got it huge amounts of testing and bugfixing, which would accelerate release of GCC 3.0.
As for KDE2, I just stated that preannouncing features of a release is bad in case it turns out not to be released when planned (2.4 kernel, KDE2 and others)
Non-biased does not mean "prefer Red Hat", but it would mean not making comments like "recovering from Red Hat Linux 7" on many stories, and if someone submits story which seems negative, actually do some checking (of course, this should be done nonetheless, but it doesn't seem to)
The sites I feel most interesting these days are LWN and Linux Today
We don't want to preannounce releases, features publically - if it turns out we can't deliver (like if we had promised KDE2 at some point it had looked like it would be ready), many will be disappointed and we will be attacked for FUDing and preannouncing the way Microsoft usually does.
So we have internal policies of being careful. This does not mean not to speak to authors, of course - it's not like they would run of to some cheap tabloid, like say "Slashdot" (which seems to have some Red Hat-bashing in and "oh, I love Debian" in every other article, which never seems to check a story for accuracy (not even if it has been published) or have any credibility left)
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.
And since we then have to keep the compiler though the 7.x series:
egcs 1.1.x was hardly an option,
2.95.2 is buggy (especially on non-x86)
having it not differ too much from the current IA64 tools is also important (this is also part of our buildtrees, and the same package needs to build on many platforms
binary compatibility with C++ has always been a horrible mess
As far as compatibility goes, glibc is the great challenge and C++ not that important: When binary compatibity is a high priority goal, C++ has never been an option when developing for Linux.
So does this mean that the next major version of GCC will break everything with C++?
Sourcecode compiled with the compiler shipped with Red Hat Linux 7.0 should still compile - binary compatibility will also be preserved through the 7.x series. As for other binary compatibility with C++ (i.e. outside of Red Hat Linux), probably not - which is no change from the current situation.
Given that we want a good multiplatform compiler, we didn't have much choice.
As for incompatible, the C ABI works and C++ has never been binary compatible and AFAIR, the drafts I've seen of different compatibility standards mentions this explicitly: Avoid the horrible mess that is C++ if you want binary level compatibility.
That was a internal misunderstanding since resolved - they could have told the steering committee, but preferred to be cautious.
Anyway, with what was shipped in the public beta two months ago I can't understand why the release surprised anybody. Going back from KDE2 because it was just too buggy is one thing (it's included as a preview, though), but changing one of the major subsystems like glibc or the compiler after that was obviously not going to happen.
Apache may well ble slower than IIS (and probably is, as their main focus is portability and correctness, while many performance-tuning tricks must be applied manually), but IIS is by far slower than Tux as tested by Dell.
Links:
Wow... what's this? Another clueless story on Red Hat Linux where Debian fans can say something not very insightful and get scored up? Yahoo.
Take a look at those bugs - if you remove duplicates, notabug et., you cut the number in half. Remove requests for enhancements, and you've lowered the number even more. Look at the rest(many of which are "I would like it to be this way, not that way"), think of the fact that Red Hat Linux gets by far the most beating of any distribution and it doesn't look at all bad.
Our testing programs for this release was more extensive than ever, and I think this release is very good.
Slashdot Mirror
An important factor is that we have developers in different areas (compiler, kernel, glibc) and thus can offer porting to new platforms etc. Noone else can offer the same.
Another is of course the level of support Red Hat and partners can provide.
FWIW, the compiler was used in compiling the entire Red Hat Linux 7 - this is quite a testbed.
No, we made a consciuous effort (that is, QA, testing, fixing) to include the best tool currently available. It's way better than egcs or gcc 2.95.2 which was why we did it in the first place.
We're not discontinuing support for multiple platforms - just wait and see. We haven't announced anything (as in will do/won't do) yet, so saying we won't is way premature.
Red Hat Linux 7 has the USB backport (done at linux-usb, which seemed to stabilize this summer and is now even going into mainstream 2.2)
We only support mice and keyboard, the rest of the modules are included "as is" - most seem to work, while others have problems (especially usb-storage, which to be really good would need a backport of the 2.4 SCSI layer)
We're bringing the techonology out for developers and users to use....
If you find a bug in the compiler, remember to put it in bugzilla
That way, we can fix it and even put the fix back in the gcc tree.
We had updated CDs in the past, but it was unpopular with sysadmins etc. who wanted to know exactly what was on a CD: Changes and updates could be applied after install. So we stopped years ago.
It is clearly marked as a snapshot(the version string says "Red Hat Linux 7.0"), and it is currently the best compiler for our needs.
We're obviouly not going to issue a "blessed" errata unless it is fully compatible - we care about our product and and compatibility, having multiple releases of compilers etc. is completely unmaintainable and might confuse people developing on it.
Anyway, this discussion is at a dead end. We released a fixed snapshot, we're not doing anything wrong with this (we should have told the gcc steering committee, but technically it was the right decision) and we're not going to break compatibility with it. EOD.
MOSIX and "beowulf"-type clusters are totally different beats.
MOSIX just migrates the application to one computer, beowulf is about letting it run on many computers at the same time. To do the latter, the applications need to programmed differently - no matter how people would want it to be, someone needs to split the computation into parts which can be computed at the same time. Some operations can be done by compilers (like for loops without inter-dependecies in the data) and others (like some common linear algebra routines) can be placed in libraries, but there's not going to be an automatic system for parallellizing everything: Knowing what parts of the problem can be computed at the same time and what data is needed to do so will continue to be important for scientific apps.
There is no overlap.
Of course I can defend it - technically, it was the right decision and I still think we should have done it. We needed the features (like actually working, and support for multiple platforms), and as probably the only company have the inhouse expertise to stabilize it. The C++ compatibility issues are far less important - as C++ has never been compatible anyway.
What we did wrong was not communicate our intentions better to the steering comittee.
Releasing a "blessed" gcc (if not looking at our compat-compilers which are egcs 1.1.2) is of course not going to happen - they wouldn't be compatible, and the reasons we had for choosing to do what we did are still valid. We did the right thing, and in so doing improved the current state of gcc a lot. Be happy.
I certainly hope so... with any luck, gcc 3.0 will go some way towards that goal.
Kernel development aren't the people doing the distribution - OS Engineering is. The kernel is only one (but major) part of the system,
Backing out major items liks glibc and the compiler late would be very hard after making the entire distribution on it (and if late enough, not enough testing either). Also, integrating these for all platforms (including IA64) would be next to impossible - the current IA64 toolchain look a lot like the one in Red Hat Linux 7, and this isn't a coincidence. Add to that that we commit to binary compatibility for many releases, and needed better i18n support for the Japanese product. We would definitely prefer not to ship pre-releases (although heavily QAed and fixed), but we felt we didn't have much choice.
As for speaking to the rest of the authors, this was a miscommunication internally (I would estimate that most come from Red Hat anyway, from Jakub Jelinek in OS Engineering and former Cygnus)
"shipping a snapshot": This was cut of the tree a long time before shipping and then QAed and fixed. Us wantin to ship it got it huge amounts of testing and bugfixing, which would accelerate release of GCC 3.0.
As for KDE2, I just stated that preannouncing features of a release is bad in case it turns out not to be released when planned (2.4 kernel, KDE2 and others)
Non-biased does not mean "prefer Red Hat", but it would mean not making comments like "recovering from Red Hat Linux 7" on many stories, and if someone submits story which seems negative, actually do some checking (of course, this should be done nonetheless, but it doesn't seem to)
The sites I feel most interesting these days are LWN and Linux Today
We don't want to preannounce releases, features publically - if it turns out we can't deliver (like if we had promised KDE2 at some point it had looked like it would be ready), many will be disappointed and we will be attacked for FUDing and preannouncing the way Microsoft usually does. So we have internal policies of being careful. This does not mean not to speak to authors, of course - it's not like they would run of to some cheap tabloid, like say "Slashdot" (which seems to have some Red Hat-bashing in and "oh, I love Debian" in every other article, which never seems to check a story for accuracy (not even if it has been published) or have any credibility left)
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.
As far as compatibility goes, glibc is the great challenge and C++ not that important: When binary compatibity is a high priority goal, C++ has never been an option when developing for Linux.
So does this mean that the next major version of GCC will break everything with C++?
Sourcecode compiled with the compiler shipped with Red Hat Linux 7.0 should still compile - binary compatibility will also be preserved through the 7.x series. As for other binary compatibility with C++ (i.e. outside of Red Hat Linux), probably not - which is no change from the current situation.
Given that we want a good multiplatform compiler, we didn't have much choice.
As for incompatible, the C ABI works and C++ has never been binary compatible and AFAIR, the drafts I've seen of different compatibility standards mentions this explicitly: Avoid the horrible mess that is C++ if you want binary level compatibility.
That was a internal misunderstanding since resolved - they could have told the steering committee, but preferred to be cautious.
Anyway, with what was shipped in the public beta two months ago I can't understand why the release surprised anybody. Going back from KDE2 because it was just too buggy is one thing (it's included as a preview, though), but changing one of the major subsystems like glibc or the compiler after that was obviously not going to happen.
Apache may well ble slower than IIS (and probably is, as their main focus is portability and correctness, while many performance-tuning tricks must be applied manually), but IIS is by far slower than Tux as tested by Dell. Links:
Try disabling the loading of the agp-gart module, it's interacting badly with some machine.
Without actually tweaking the Makefiles to deal with it. Just do an "export CC=kgcc" and you should be fine.
Wow... what's this? Another clueless story on Red Hat Linux where Debian fans can say something not very insightful and get scored up? Yahoo.
Take a look at those bugs - if you remove duplicates, notabug et., you cut the number in half. Remove requests for enhancements, and you've lowered the number even more. Look at the rest(many of which are "I would like it to be this way, not that way"), think of the fact that Red Hat Linux gets by far the most beating of any distribution and it doesn't look at all bad.
Our testing programs for this release was more extensive than ever, and I think this release is very good.