From: Nico Kadel-Garcia <nka...@gmail.com> > egcs, which you cited, is a very unfortunate example of RedHat's > visionary and leading edge development. For me, it was a painful > nightmare and a reason to stay at RedHat 6.x rather than investing > money in RedHat 7.x.
Ummm ... Red Hat dumped GCC 2.7, did not go GCC 2.8 like other distros, and adopted EGCS 1.1.2, which was the compiler in Red Hat Linux 6, _not_ 7. EGCS offered all sorts of release compatibility. GNU liked it so much, Cygnus was given the go-ahead to design the new object model for GCC 3 using the EGCS lineage. The EGCS 1.1.2 lineage became GCC 2.91, and Red Hat still offered it in Red Hat Linux 7 / Red Hat Enterprise Linux 2.1 as GCC 2.91.66. For the longest time, this was the only GCC release compatible for the kernel. Several distros wrongly started building the kernel on GCC 2.95, which was always experimental, and there were object incompatibilities between sub-relesaes. The new EGCS design compiler forced ANSI C++ compliance and broke a lot of existing C++ code. Of course, a lot of C++ code broke from GCC 2.7 to 2.8 as well as to EGCS 1.1.2 as well. Eventually Red Hat forced the issue. This forced a lot of codebases that were not ANSI C++ compliant to choose to either build using 2.91.66 or re-write their objects to ANSI C++ compliance. The benefit today is that Red Hat's C++ object compatibility goes all the way back to that release. People forget to "look back" at that reality. Because, in the end, what did everyone adopt?! Case closed. ;) Heck, people still moan about Red Hat Linux 5 switch to GLibC 2, and yet there is that reality of what GLibC 2 has done. It's hard to complain about Red Hat forcing the community to where it needs to be, the community follows, and the complains are really because Red Hat forced people to change for the benefit everyone has today. It's easier to ride coat-tails and complain that acknowlege why something very necessary was done. > Unfortunately for me, I couldn't wait it out, but had to backport and forward >tools to it. It was..... awkward. ??? GCC 2.91.66 worked fine in Red Hat Linux 7 for existing EGCS C++ code. > FireFox forklift updates, ??? Please explain. > and investing in ext based filesystem upgrades rather than persuing ReiserFS? Ummm, ReiserFS was missing a lot of features my customers needed, let alone I won't even talk about the sync issues between kernel journal implementation and off-line fsck. I even had that discussion back in '99-01 with SuSE and even they agreed Ext3 (Red Hat) and XFS (only SGI officially supported, until recently Red Hat too) were clearly the better course for several of my clients. Most of the arguments for ReiserFS over Ext3 were based on early Ext3 full journaling, and Ext3 meta-data journaling in ordered and write back modes made them moot. Both JFS and ReiserFS always had compatibility issues with many interfaces. Heck, many of the issues JFS and ReiserFS had weren't addressed until kernel 2.6 by most of the subsystem donations by SGI (from XFS), and both still had lingering design differences from a traditional POSIX inode approach (JFS because it was from OS/2, not AIX, and ReiserFS because ... well, it was ReiserFS). Many of the alleged advantages of ReiserFS were always at the cost of compatibility, which Ext3 preserved. This is _exactly_ what I'm talking about. I need say nothing further, it only proves why Red Hat was continually the best move for my professional consulting career at various clients for the past decade, and years as the Linux guru as a employee at companies before that. _______________________________________________ rhelv6-beta-list mailing list rhelv6-beta-list@redhat.com https://www.redhat.com/mailman/listinfo/rhelv6-beta-list
