For those that lived this history from the inside enough to tell it as you both do below.... Whatever part you played in the original RHL, whether for profit or for pride, you are my heroes. Thank you for starting this project. You changed the world. On Wed., Dec. 23, 2020, 11:30 a.m. Stephen John Smoogen, <smooge at gmail.com> wrote: > 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. > > _______________________________________________ > CentOS-devel mailing list > CentOS-devel at centos.org > https://lists.centos.org/mailman/listinfo/centos-devel > -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.centos.org/pipermail/centos-devel/attachments/20201223/1b71a731/attachment-0005.html>