[conspire] x86-64 and 2.6 kernels (was: Fedora Core 3 for a Celeron Dell desktop box)

[Rick Moen]

I wrote:

[Stuff about the three recent lines of RH-compatible enterprise distros,
each of the three comprising a distinct binary "target platform":

o  RH 7.3, RHAS 2.1, CentOS2 (all defunct)
o  RH 9, RHEL3, CentOS 3.x
o  FC1, RHEL4

Note that FC2 and later are not even _in_ this map, being _way_ too
fast-moving and unsettled for "enterprise" use.]


> Again, referring to my "RH Releases" page, you'll see that the
> severely-aging-but-not-yet-dead RHEL3 architecture is a retread of RH9.
> This is corporate America's current gold standard for Linux (though the
> smarter ones are migrating to SUSE Linux Enterprise Server 9).  FC1, but 
> not later Fedora Core releases, recycles that architeture.  It uses RH's 
> heavily patched 2.4.21 kernel and the reasonably stable v. 2.3.2 glibc.  
> For now, that would be fine for a Celeron system.  (For x86-64, by
> contrast, RHEL3 and kin are dysfunctional, which is one reason why that
> architecture's a dead-end.)

OK, I'm going to bore y'all with a further state-of-the-market analysis, 
so brace yourselves for a geek rant.  Here's the elephant in the room
that the Linux-using enterprise world is dragging its feet on
acknowledging:  IA32 is dead.

Yes, my cheap-ass PIII and PII boxes still are IA32.  Eddie's Celeron
is.  Maybe your boxes.  You can even go a little out of your way and
buy, today, a P4.  _But that would be dumb._  It's gone with the dodos,
guys.  The market has moved on.

AMD started it with those wildly successful Opterons, defining a CPU
spec that had a company-specific marketing name of "AMD64" but now is
generically dubbed "x86-64".  Intel, with considerable ill-grace,
eventually followed bobbing in AMD's wake -- which was pretty painful
for them to do, but they did it -- with "Xeon64" chips that implement
that same x86-64, in a minor variant that they choose to call "EM64T"
for reasons, basically, of corporate pride.  (That is not to say they
aren't good:  I think they're poised to trounce the AMD guys.)

Intel's and AMD's designs are so close in their programming interfaces
that they're functionally the same, from the point of view of an admin
running Linux -- or even, in most situations, of programmers.  Thus, we
call those systems (generically) "x86-64", regardless of which firm made
the CPU or what marketing terms it slapped onto the box.

And x86-64 makes a huge difference.

The Linux-using enterprise world has a problem:  It's buying x86-64
hardware like candy, and RHEL3 doesn't work properly on that.  It simply
doesn't.  Red Hat's infamously overcomplicated kernel-maintenance
process keeps cranking out "2.4" kernels in its "Update" service packs,
that are really 2.4 kernels in name only:  They're crammed to the gills
with backported 2.6-kernel patches -- a slapdash effort that works well 
enough on IA32 systems (PII, PIII, Celeron, P4, plain Xeon) but _not_ 
on x86-64.  Those systems are unstable unless you _statically compile_
the kernels.  They fall over when run under heavy load.  They have bugs
all over the place.  Bugs that are minor on IA32 become major when the 
same code is run under x86-64.

So, you might ask, why doesn't Red Hat simply retrofit a 2.6 kernel to
RHEL3?  They _physically_ could, and it _would_ fix the x86-64 problems.  
The reason they don't do it -- and will never do it -- is that doing so
would contradict their product strategy:  They promised the business
world that each RHAS/RHEL release would remain a stable binary platform
for five years.  So, they're trapped, by their own corporate strategy, 
into keeping RHEL3 on a "2.4" kernel, even if it's that in name only.

The upshot is that you really cannot run stable x86-64 systems (unless 
really lightly loaded) on RHEL3.  You never will be able to -- except by 
supplying your own, non-vendor 2.6 kernel, and thereby foregoing the
very corporate support you bought RHEL for in the first place.

So, basically, modern hardware is going to _require_ enterprise Linux
distros based on 2.6 kernels -- like FC4, RHEL4, and SLES9.  And that
specifically _excludes_ 2.4-based distros like RHEL3 / RHAS 2.1, not to
mention Red Hat 7.x.   They're gone.  Forget them.  The moment you
switch to the newer CPU architectures, they're obsolete -- and _that_ 
horse is already out of the barn.

Which leaves people like Eddie, charged with making badly written legacy
proprietary code (written with unnecessary dependencies on RH 7.3-era
system software) in a real long-term quandary.  Eddie's not alone, and
there is going to be a lot of stranded code out there.  This problem is
going to keep getting worse.  (You read it here first!)