[rhelv6-beta-list] This is what I'm talking about -- WAS: RHEL6 finish (~ date)

[Bryan J Smith]

From: Nico Kadel-Garcia <nkadel at 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.