[Leaplist] Enterprise Linux lifecycle and ABI compatibility -- WAS: Another Vixta ??

[Bryan J. Smith]

On Fri, 2008-02-22 at 22:08 -0500, Hank Lambert wrote:
> All of my experiance with Linux so far is based on Debian.

Debian is an outstanding project with extremely long-standing guidelines
that have resulted in many benefits.  It's sad that some other people
constantly think these advantages are issues.

> From what I have seen, most IT job opportunities that are looking for Linux 
> experience want Red Hat, usually Enterprise Server or SuSe experience.

That's because there are still only two (2) Linux vendors with 7+ years
of guaranteed Application Binary Interface (ABI) compatibility -- Novell
and Red Hat.  Canonical's Ubuntu 3-year Long Term Support (LTS) releases
have not had that, although Canonical is starting to target a 5-year
Server release that may.

It will be interesting to watch Canonical grow beyond the "Endowment"
afforded it by Mark Shuttleworth and into a commercial entity that will,
at some point, run into the same cash flow issues that Mandrake did.
Ironically, I'll be one of the people that will defend Canonical at that
point when they get so wrongly demonized by the masses, just like
Mandrake did, just like Red Hat did.

> Being my experience is with Debian, I know and use (and love) apt. I 
> want to install Linux on my laptop to start my migration to be Windows 
> free at home. I figure if I install Fedora, I will get some experience 
> using RPMs

Please don't use "APT" and "RPM" in the same sentence.  It's an apples
to oranges comparison.  You want to say either "APT" and "YUM"** or
"DPKG" and "RPM."  I.e., APT ~= RPM, it's APT ~ YUM** and DPKG ~ RPM.
If you want to talk about the "guts" of Debian, it's DPKG.  Likewise, if
you want to talk about typical management of any Fedora or RHEL system,
it's YUM.

One of the ways you can tell someone doesn't know anything about Red Hat
is by saying RPM.  I'd say even over 50% of RHEL administrators don't
know what they are doing, and still applying knowledge that is a good 10
years old.  I.e., that's really a show stopper for anyone I'd hire.

It's been well over 5 years since Red Hat systems were even
"officially"** managed with RPM, it's closing in on a decade since
APT-RPM and YUM-RPM became available.  **NOTE:  Officially UP2DATE was
used for RHEL until the last few years, with YUM now being official and
the default.  But even UP2DATE has had YUM support for well over 5 years
as well.

> and learn the Red Hat way of doing things.

It's not really a "Red Hat way" of doing things, but more about
understanding Red Hat's support focus.  A distro is a distro these days.
E.g., most packages-based distros (a ports-based distro, like Gentoo is
another story), has a 3 tag release model ...

1.  Package tested
2.  Integration tested
3.  Regression tested (optional/varies)

Each will vary from distro to distro.  But the flow is basically the
same.  Packages are first built and tested, then released into a pool of
packages.  At some point the packages are selected and then integration
tested.  Once integration tests are done, regression testing is a common
issue.  I.e., what changes will affect (and possibly break) API and/or
ABI (programmer and/or binary/run-time, respectively) compatibility.

Distros like Fedora are more focused on features, so regression is more
limited to API, not so much ABI.  Fedora typically has a 2-3 month, 2-3
month plus 2-3 month for package testing (Development) and integration
testing (Test), and there is only more limited regression testing (not
so much avoidance) as Fedora's forward-looking design tends to cause
regressions anyway (at least ABI, API may be better maintained for 2-4
releases).  Fedora distros come out every 6-9 months as a result, a
history that goes back over 20 releases now (to Red Hat Linux 4.0).

Distros like Red Hat Enterprise Linux (RHEL) focus on extreme,
anal-level ABI compatibility (let alone API).  After 2-4 Fedora
releases, a Red Hat Enterprise Linux release will take place, typically
every 12-24 months.  Although RHEL doesn't do as much package testing
(relying more on Fedora), it still has its own "Rawhide" for that.  But
the main integration and regression testing is done with Alpha and Beta,
respectively.

The result of using a combination of an "early adopter" (but not
unstable, just not always ABI or API compatible) distro released often
with a trailing edge, long-supported Enterprise Linux distro, is that
Red Hat is unmatched in long-term ABI/API compatibility.  After GCC 2.7,
Red Hat skipped GCC 2.8, adopting Cygnus' EGCS (EGCS 1.1.2 became GCC
2.91.66) and, after its take over of Cygnus, skipped GCC 2.95 (which had
several, incompatible versions no less -- much like GCC 2.7 and 2.8 were
incompatible) to the first, official, fully ANSI C++ compliant GCC
release.

The result is that many Red Hat Linux 6 C binaries/libraries and Red Hat
Linux 7 C/C++ binaries/libraries still run on even the forthcoming
Fedora 9 and Red Hat Enterprise Linux 6.  Red Hat tends to "set the
standard" when it comes to the next-generation of ABI compatibility of
Linux Standard Base (LSB) C/C++ as well.

> That is now, who knows what distro I will have on it in 6 months.

If you're going to learn RHEL, you want to learn CentOS.  It's a source
rebuild of RHEL, since Red Hat releases its full source and build
system.  Novell only more recently started offering that for SuSE Linux
Enterprise Linux Server (SLES), but I haven't seen a distro doing that
yet like CentOS, Scientific Linux, Oracle Unbreakable Linux (CentOS),
etc... using RHEL.

BTW, contrary to popular believe, SLES predates RHEL, name SLES 7, based
on SuSE Linux 7.x.  It was SuSE that first discovered organizations
wanted 3-5 years of ABI compatibility.  Red Hat, at the time, was only
offering a 3-year Service Level Agreement (SLA) on Red Hat Linux 6.2.
Yes, doesn't that sound like what Ubuntu is doing with LTS (history
repeats itself ;)?

With Red Hat Linux 7.x, Red Hat released Red Hat Advanced Server (RHAS)
2.1 (Red Hat considers RHL6.2"E" to be its "version 1), which was later
expanded to include the entire line called RHEL 2[.1] of a
Workstation/Client, Entry Server and Advanced Server.  Red Hat's naming
conventions and subscription prices are largely for Service Level
Agreement (SLA) purposes -- i.e., what they will support.  CentOS just
builds the top-level server and releases it.

Also, despite common rhetoric, CentOS is very much involved with Red Hat
developments, and many aspects of Red Hat keep CentOS involved.  This
includes the Red Hat sponsored Fedora project, which offers Extra
Packages for Enterprise Linux (EPEL) and many other, "unsupported"
Enterprise Linux offerings that are done by Red Hat employees and the
community, which involve CentOS.

Virtually everything Red Hat does is due to trademark, hence the reason
why Fedora(TM) is used.  Furthermore, unlike many other community
distros, Fedora(TM) purposely does not use the Linux(R) trademark for
various, legal reasons (long story, a very good discussion on its own).
The trademark reasons, in general, were because Red Hat's past goodwill
that opened up the abuse of the name to other companies, namely
Microsoft and -- more specifically -- Sun.

E.g., There are still people who claim to have supported Red Hat(R)
Linux on Cobalt Cube systems.  There was never a version of Red Hat(R)
Linux that ever ran on those systems, it used MIPS which Red Hat never
shipped.  That discussion is also a good one, especially on what misuse
of trademark can do to hurt a firm.  Despite countless "trademark
guidelines" to still allow the community to use the Red Hat(R)
trademark, it was summarily ignored (e.g., Cobalt/Sun), and further,
wrongful demonizations by select entities (e.g., Cheapbytes) made it
impossible.

Hence why no one can call it Red Hat(R) Linux without paying Red Hat(R)
for the trademark.  If you think this is bad in the US, it's even worse
in many European countries.  E.g., Sun nearly made the fatal mistake of
using SuSE(R), and SuSE(R) -- a German firm -- defended its trademark
far, far worse than Red Hat ever has (although Novell has loosened that
on at least OpenSUSE(TM) now).  In the end, ironically, Sun probably
ended up paying far more for a SuSE distro license for its Java Desktop
than had they just worked with Red Hat.  ;)


-- 
Bryan J  Smith              Professional, Technical Annoyance
mailto:b.j.smith at ieee.org  http://www.linkedin.com/in/bjsmith
-------------------------------------------------------------
           Fission Power:  An Inconvenient Solution