[CentOS-devel] Balancing the needs around the RHEL platform

Wed Dec 23 16:30:12 UTC 2020
Stephen John Smoogen <smooge at gmail.com>

Hi Red Baron Browser.. [you had me at the name since I helped come up with
it 24 years ago]

On Wed, 23 Dec 2020 at 02:57, redbaronbrowser via CentOS-devel <
centos-devel at centos.org> wrote:

> Karsten Wade has indicated the centos-devel mailing list is the place to
> talk about why he thinks things are going to turn out okay.  He implied on
> the CentOS blog there is balancing of the needs of CentOS.  Mostly the
> article is about the “openness gap” (which is brought up seven times).
> He goes through a very selective stroll through history to present his
> point leaving out anything that doesn’t fit his agenda.
> So, let’s go back to 2002.  The most polished version of pre-RHEL Red Hat
> Linux, code named Valhalla, was released in March 2002.  It was the result
> of years of refining the Red Hat packages in a repository called Rawhide
> and then a branch was released only when it passed quality assurance.
If you are going back in time, you need to look at the box covers for Red
Hat Linux 6.0 Originally it was just going to be RHL6 with no .0 on the
end.. this was a push from management to move to a continuous delivery
mechanism where we would snapshot Rawhide to a release and then keep
updating 6 in small incremental parts to make it easier to sell to
Enterprises. We had outstanding contracts with IBM and then SGI and then HP
to make a Linux which would be kept stable for 10 years with a 20 year
absolute lifetime.

The problem was that engineering and support found that too much of a
change and pushed back on it hard. There were still too many changes in
core software to be able to keep to that and it was felt being clear on the
dot release would be clearer to customers. As can be seen with the changes
needed between 6 and 6.1 and 6.2 the amount of change churning was greater
than expected by our contracts so we only finally got to an enterprise
account with 6.2EE (or RHEL-1.0 I like to cheekily call it). That still was
not able to be maintained for 10 years as the kernel, glibc, and other
tools were 'behind' the Unix API needs that the vendors wanted for their
software and the changes to make that caused major disruptions requiring
RHL 7 (again trying very hard to keep to just a single number). Eventually
this solidified and branched off before RHL7.2 to become RHEL2.1. [It was
called 2.1 because the sales logic is "never ship a 1.0 because everyone
expects that to be an Alpha and never ship a 2.0 because people expect that
is the Beta. 2.1 is the first number accounting people will trust to buy. I
thought that was bogus until after I left Red Hat and saw that was exactly
how various software procurement rules worked.]

The work on 8 was not going well so a 7.3 was released to keep a release
out every 6 months. That didn't help greatly and eventually a 'shoot the
programmers/qa and ship the product decision' was made which went out as
RHL 8. At this point the threading code in glibc got into a working state
for another enterprise release and RHL9 and RHEL-3 were released.

A side story at this time was that for years there had been a thought by
technical people that boxed sets was the way that Linux could make it to
the masses however the sales numbers were not happening. Up until 5.0, Red
Hat had always made more on t-shirt and book sales than it did from Linux
software. And while there had been a boost, it fell apart with the software
retail collapse that accompanied the dot-com bust. Initial sales would be
good, but returns would begin to eat into this so that after a release you
had 1-2 months positive and 3-5 months negative. After the dot-com bust the
numbers got bigger but there was always the thought that the next release
would fix things back to where they had been. That didn't happen, and
RHL-10 became Fedora-1 with no plans for boxed sets, etc. This caused all
kinds of problems in the community and internal to Red Hat with some people
leaving for other companies (some created rPath).

> Around the same time, a branch of Valhalla was also released as Red Hat
> Enterprise Linux 2.
Actually I believe this was started off of before Enigma. This is why some
packages are before 7.2 and some are after 7.2

> Then in September 2002, code name Psyche replaced Valhalla.  Security
> updates for Valhalla ended unless you became a RHEL 2 customer.
> Psyche was a problem for a couple reasons.  While Red Hat pointed out that
> it had more features than RHEL, it wasn’t just the “good” features.  Psyche
> contained several regressions and bugs that should have never passed
> quality assurance.  Rather, it appeared whatever was the latest packages in
> Rawhide just got dumped as Psyche since it was just the free community
> version and RH QA was focused on just RHEL.
> If I recall correctly, at the time Red Hat apologized for Psyche and tried
> to reassure the community the problems were not intentional.  Red Hat 9
> (Shrike) was released in March 2003 and the first Fedora Core released in
> November 2003.
> The continued development under FC addressed several of the bugs.  But two
> new issues came up.
> First new issue was Red Hat’s creation of the openness gap.  There were
> now two Rawhide repositories.  The public Rawhide moved to Fedora.  But
> also a Rawhide branch that RHEL work from was kept private.
> Second new issue was a COMPATIBILITY gap.  Fedora wasn’t designed to be
> 100% API or ABI compatible with RHEL.  Several times a binary built on
> Fedora could not be run on RHEL 2.  A statically linked binary might
> temporarily address the issue but then security updates to the RHEL 2
> libraries would not fix issues with the statically linked binary.  To build
> a dynamically linked binary for RHEL 2 without paying for RHEL 2 required
> using Valhalla which was no longer getting security updates.
> In May 2004, a solution to the COMPATIBILITY gap was released.  The
> Community ENTerprise OS.  As stated in it’s FAQ:
You accidently dropped some history here. First there was WhiteBox and then
a couple other rebuilds. Then the CAOS project started building their own
to meet some needs for their project. That rebuild became CENTOS. [The
Community Enterprise was a backronym as it was CAOS Enterprise Operating
System.. It was also jokingly referred to as Cabal Enterprise Operating
System since it was a small circle of people who could do the builds and
the only changes being made to the package was what you list.. remove
trademarks and work out how to rebuild it to be good enough.]

> > “Does CentOS change the upstream Source RPMs?”
> > “No. CentOS' key mandate for our base and updates repositories is NOT
> extending or enhancing packages or features beyond those supplied by the
> upstream Source RPM's. CentOS strives intentionally to provide binary
> functionality for our users.”
> Now the community had two options.  Fedora for features or CentOS for
> compatibility.  It is important to remember, CentOS strived for
> COMPATIBILITY by *avoiding* additional features as this fundamental concept
> will come up later.
> In October 2004, Ubuntu would be released.  This would be a challenge for
> CentOS.  While CentOS *strive* for being 100% compatible with the
> commercially supported RHEL, Ubuntu LTS community edition is able to prove
> it is 100% identical to Ubuntu LTS with commercial support.
I am not sure that CentOS cabal ever saw Ubuntu as any sort of challenge.
That was more of a Red Hat challenge.. There was enough of a challenge just
getting packages to build.

I have reached maximum email parsing and am not sure I can follow where you
were going from here. I am clipping here as I am EBRAINFULL.

Stephen J Smoogen.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.centos.org/pipermail/centos-devel/attachments/20201223/4377cdda/attachment-0005.html>