On Tue, Dec 08, 2020 at 12:44:36PM -0600, Robert G. (Doc) Savage via CentOS wrote:

...

CentOS 8's future is not looking bright. Recently deployed CentOS8 on my production workload and now hearing this. What do other folks think about this?

Speaking only for myself, I am ready to give up on CentOS (and Red Hat) entirely. Fedora meets all my clients' needs with none of the chaos.

I definitely appreciate the vote of confidence in Fedora! You're not alone in using Fedora in a lot of serious ways.

However, I really encourage everyone to give this a chance. This is (post-Fedora) RHEL development opening up in a new way, and CentOS is central to it. That's a good place to be!

On 9/12/2020 3:19 μ.μ., Nikolaos Milas wrote:

I still hope that you will not disappoint CentOS admins and users so badly and that you will continue to support CentOS 8 (and CentOS 7) in its current/expected form.

A petition has started, to request IBM/Redhat to continue CentOS 8 as initially announced/promised.

Those who agree, are urged to sign:

https://www.change.org/p/centos-governing-board-do-not-destroy-centos-by-usi...

Cheers, Nick

On Fri, Dec 11, 2020 at 09:51:05PM -0500, Yves Bellefeuille wrote:

I'm most disappointed with the silence from Karanbir and friends. Obviously their Red Hat salary is more important to them than keeping CentOS the way it was. :-(

Yes, far be it from people to worry about putting food on their children's table during a pandemic.

Your mistake, along with that of many, is thinking the Board had a choice in any of this. So what, exactly, do you expect Singh or others to say? What, if anything, could they say that would make you feel better about this?

John

On Fri, Dec 11, 2020 at 10:11:36PM -0500, Yves Bellefeuille wrote:

Oh, please. Nobody suggested this has anything to do with the pandemic; nobody even mentioned the pandemic, except you.

"Red Hat salary more important"

This implies you expect them to put their jobs on the line to protect some set of ideals. Even if it were not for the pandemic it's folly to expect people to commit career suicide over what's a done deal.

John

On 12/12/20 4:43 PM, Leon Fauster via CentOS wrote:

Am 12.12.20 um 04:11 schrieb Yves Bellefeuille:

...

"John R. Dennison" jrd@gerdesas.com wrote:

...

Yes, far be it from people to worry about putting food on their   children's table during a pandemic.

Oh, please. Nobody suggested this has anything to do with the pandemic; nobody even mentioned the pandemic, except you.

While we are on pandemic, a complete different point here now. ( its already being said, but it occupies us still mentally )

What about the small businesses that in this times suffer very much, being forced to pay licenses will kill them ... I have a client that moved from IBMCloud/RedHat to AWS/CentOS to survive this times. (BTW: I suggest initially to use RHEL!) What do imagine who will be killed when they receive the message that they should plan some budgets for new licenses ...

Hi. Springdale Linux, RHEL clone already exists. Rocky Linux clone is in preparation, and CloudLinux plans to publish RHEL clone also. And notice that CentOS Linux 7 will be supported until EOL in 2024 and there will still be support for CentOS Linux 8 for next 12 months, enough to chose your exit strategy smartly and without emotions.

-- Leon

---

CentOS mailing list CentOS@centos.org https://lists.centos.org/mailman/listinfo/centos

Am 12.12.20 um 21:55 schrieb John R. Dennison:

On Sat, Dec 12, 2020 at 09:50:07PM +0100, Ljubomir Ljubojevic wrote:

...

Hi. Springdale Linux, RHEL clone already exists. Rocky Linux clone is in preparation, and CloudLinux plans to publish RHEL clone also. And notice that CentOS Linux 7 will be supported until EOL in 2024 and there will still be support for CentOS Linux 8 for next 12 months, enough to chose your exit strategy smartly and without emotions.

Springdale does not at present have an EL8 release to the best of my knowledge.

I was also confused at the beginning taking a look at it but they have a current EL8.3 branch - a tested migration path look like this:

curl -O "https://springdale.math.ias.edu/data/puias/7/x86_64/os/RPM-GPG-KEY-puias"

rpm --import RPM-GPG-KEY-puias

curl -O "https://springdale.math.ias.edu/data/puias/8/x86_64/os/BaseOS/Packages/sprin..."

curl -O "https://springdale.math.ias.edu/data/puias/8/x86_64/os/BaseOS/Packages/sprin..."

curl -O "https://springdale.math.ias.edu/data/puias/8/x86_64/os/BaseOS/Packages/sprin..."

rpm -K springdale-* |grep "digests signatures OK"

rpm --nodeps -ev centos-linux-release-8.3-1.2011.el8.noarch centos-linux-repos-8-2.el8.noarch

yum --releasever 8 localinstall spring*

yum clean all

yum distrosync

reboot

-- Leon

On Sun, Dec 13, 2020 at 01:40:58AM +0100, Ljubomir Ljubojevic wrote:

They only do not have DVD ISO, but they have "network" CD ISO for 8.1, and they have boot.iso for 8.3 for install over internet.

Ahh. Good to know. Thanks to both you and Leon Fauster for correcting me on this.

John

On 12/12/20 10:34 PM, Konstantin Boyandin via CentOS wrote:

My only concern ATM is whether RH can change its CentOS 7 maintenance plans as well, all of a sudden.

This is what bothers me, too, but in a slightly different way.  Even for the GPL software, Red Hat actually doesn't have to provide public access to the source code; the only thing required by GPL is that those who receive binaries must be able to get sources.  So, even though it has been said that the source will be available, well, it was also said that C8 would be supported to 2029.  There are enough packages in RHEL with non-GPL licenses where it would be very difficult to rebuild the whole distribution without them, and RH is not required by those licenses (MIT, BSD, and others) to redistribute those modified sources even to people who have been distributed binaries.  So, while I want to believe that the sources will remain available, that belief relies on trust, which unfortunately is less abundant these days.

So while using another rebuild seems to be a good stopgap solution, I do wonder if it will prove to be sustainable post-2021.  I'm personally looking at which of the four (that we know about) to possibly go to; I just really doubt I am going to use Oracle; Rocky isn't really there yet and is very young; Springdale is available, mature, and academically supported (nothing wrong with that, just a statement); CloudLinux OS Project Lenix isn't yet released.  Out of the bunch, Springdale would be my first choice right now because it's been around a very long time and is available now.  C8 is supposed to be around until end of 2021, so there is some time for the dust to settle and the way to become more clear, though.  But CentOS 8 Stream is only an option for me if the hardware driver KABI synchronization issue is solved and stays solved.  RHEL?  Under the current subscription models we just can't afford it. (Cost also keeps SLES out of the running.)

But I'm now seriously considering just simply going to something that is both older than Red Hat, fully and totally open, extremely well-supported by a diverse developer community, and used by a whole lot of people.  Yes, that's Debian; until I realized where the name came from (Deb and Ian) it read to me like a play on 'deviant.'  The 'stable' period is shorter, for sure.  The tradeoffs are pretty simple: guaranteed openness versus less change for ten years.

So, let's look at that last piece.  CentOS 6's support just ended; what have the last nine years and three months of actual C6 support looked like?  I supported several C6 machines, and there were distinct challenges early on, at least for the first four years or so.  Since then, on the server, it's been very stable, but really old; key pieces of infrastructure software we use slowly became unusable on C6 due to the old versions of specific packages, and either a third-party repo with newer packages or a newer CentOS was needed.

Third-party repos have improved over the years, but some of the earlier C6 machines I installed had packages from Linuxtech, Dag, ATrpms, City-Fan (one particular DVD burner that just had to have the non-wodim cdrtools for some reason; yes, I know all the warnings about that repo), and others.  Having EPEL and Dag both package a few things that I needed, but package them differently, introduced me to package pinning and repo priorities.... I don't miss those days.  Seriously stable in the core repos means very little when you need much less stable third-party repos to get actual work done. That's also why Fedora isn't really an option, just too much package churn; been there, done that, a few years ago.

So I've started re-evaluating just why I use CentOS anyway; the answer really boils down to the fact that I started out with Red Hat Linux in 1997 (I live in North Carolina, and I've always liked supporting local companies) and I just really don't want to change; it feels like I've wasted so much effort if I change now (that was the reason I stuck with it through the Fedora-RHEL split years ago, too, and went with a RHEL rebuild, first WBEL then CentOS).  But the reality is not nearly so stark; a vast majority of the information and skills I've picked up in these years are portable to other distributions; so it's not wasted effort.  Well, other than RPM packaging skills; those are a bit less portable.  Whenever I've built from source I've tried to either build my own RPM for it or rebuild the Fedora RPM for it, and so I have a local repo of those packages, making reinstall much easier.  So it becomes a tossup: small change to another rebuild now, possibility of major change later, or bite the bullet and go ahead and get the major change over with and only have small changes later.

The whole issue of "support longevity" raises an issue I've been pondering, is 10-year support a good thing from a security perspective? At work we use Ubuntu LTS which has only a five year support cycle (you can pay for an extra five years) but, even with that, issues have arisen. Although they do security and bug fix updates, the package versions remain basically the same. So, if a package is on version 1.2.3, it remains 1.2.3 with bug fixes and security patches for the life of the distribution. Does Red Hat/CentOS do the same thing?

The reason I ask is I ran into an issue where OpenVPN was updated in a later release to support a more robust security architecture which wasn't available until I upgraded. A configuration change could have addressed a security weakness in the older version so that the issue wasn't one of a security patch. However, the change required a lot of effort to implement.

Now I'm wondering about packages in general.

________________________________ From: CentOS centos-bounces@centos.org on behalf of Lamar Owen lowen@pari.edu Sent: Monday, December 14, 2020 10:57 AM To: CentOS mailing list centos@centos.org Subject: [EXTERNAL] Re: [CentOS] CentOS 8 future

CAUTION: This email originated from outside of the organization. Do not click links or open attachments unless you recognize the sender and know the content is safe.

Harriscomputer

Leroy Tennison Network Information/Cyber Security Specialist E: leroy@datavoiceint.com P:

[cid:Data-Voice-International-LOGO_aa3d1c6e-5cfb-451f-ba2c-af8059e69609.PNG]

2220 Bush Dr McKinney, Texas 75070 www.datavoiceint.comhttp://www..com

This message has been sent on behalf of a company that is part of the Harris Operating Group of Constellation Software Inc.

If you prefer not to be contacted by Harris Operating Group please notify ushttp://subscribe.harriscomputer.com/.

This message is intended exclusively for the individual or entity to which it is addressed. This communication may contain information that is proprietary, privileged or confidential or otherwise legally exempt from disclosure. If you are not the named addressee, you are not authorized to read, print, retain, copy or disseminate this message or any part of it. If you have received this message in error, please notify the sender immediately by e-mail and delete all copies of the message.

On 12/12/20 10:34 PM, Konstantin Boyandin via CentOS wrote:

My only concern ATM is whether RH can change its CentOS 7 maintenance plans as well, all of a sudden.

This is what bothers me, too, but in a slightly different way. Even for the GPL software, Red Hat actually doesn't have to provide public access to the source code; the only thing required by GPL is that those who receive binaries must be able to get sources. So, even though it has been said that the source will be available, well, it was also said that C8 would be supported to 2029. There are enough packages in RHEL with non-GPL licenses where it would be very difficult to rebuild the whole distribution without them, and RH is not required by those licenses (MIT, BSD, and others) to redistribute those modified sources even to people who have been distributed binaries. So, while I want to believe that the sources will remain available, that belief relies on trust, which unfortunately is less abundant these days.

So while using another rebuild seems to be a good stopgap solution, I do wonder if it will prove to be sustainable post-2021. I'm personally looking at which of the four (that we know about) to possibly go to; I just really doubt I am going to use Oracle; Rocky isn't really there yet and is very young; Springdale is available, mature, and academically supported (nothing wrong with that, just a statement); CloudLinux OS Project Lenix isn't yet released. Out of the bunch, Springdale would be my first choice right now because it's been around a very long time and is available now. C8 is supposed to be around until end of 2021, so there is some time for the dust to settle and the way to become more clear, though. But CentOS 8 Stream is only an option for me if the hardware driver KABI synchronization issue is solved and stays solved. RHEL? Under the current subscription models we just can't afford it. (Cost also keeps SLES out of the running.)

But I'm now seriously considering just simply going to something that is both older than Red Hat, fully and totally open, extremely well-supported by a diverse developer community, and used by a whole lot of people. Yes, that's Debian; until I realized where the name came from (Deb and Ian) it read to me like a play on 'deviant.' The 'stable' period is shorter, for sure. The tradeoffs are pretty simple: guaranteed openness versus less change for ten years.

So, let's look at that last piece. CentOS 6's support just ended; what have the last nine years and three months of actual C6 support looked like? I supported several C6 machines, and there were distinct challenges early on, at least for the first four years or so. Since then, on the server, it's been very stable, but really old; key pieces of infrastructure software we use slowly became unusable on C6 due to the old versions of specific packages, and either a third-party repo with newer packages or a newer CentOS was needed.

Third-party repos have improved over the years, but some of the earlier C6 machines I installed had packages from Linuxtech, Dag, ATrpms, City-Fan (one particular DVD burner that just had to have the non-wodim cdrtools for some reason; yes, I know all the warnings about that repo), and others. Having EPEL and Dag both package a few things that I needed, but package them differently, introduced me to package pinning and repo priorities.... I don't miss those days. Seriously stable in the core repos means very little when you need much less stable third-party repos to get actual work done. That's also why Fedora isn't really an option, just too much package churn; been there, done that, a few years ago.

So I've started re-evaluating just why I use CentOS anyway; the answer really boils down to the fact that I started out with Red Hat Linux in 1997 (I live in North Carolina, and I've always liked supporting local companies) and I just really don't want to change; it feels like I've wasted so much effort if I change now (that was the reason I stuck with it through the Fedora-RHEL split years ago, too, and went with a RHEL rebuild, first WBEL then CentOS). But the reality is not nearly so stark; a vast majority of the information and skills I've picked up in these years are portable to other distributions; so it's not wasted effort. Well, other than RPM packaging skills; those are a bit less portable. Whenever I've built from source I've tried to either build my own RPM for it or rebuild the Fedora RPM for it, and so I have a local repo of those packages, making reinstall much easier. So it becomes a tossup: small change to another rebuild now, possibility of major change later, or bite the bullet and go ahead and get the major change over with and only have small changes later.

_______________________________________________ CentOS mailing list CentOS@centos.org https://lists.centos.org/mailman/listinfo/centos

I'm also using CentOS for a while and I'm deploying a CentOS8 cluster for some months.... because it was supported until 2029! Bad idea. For me, using debian has 2 important drawbacks - some of proprietary software we are using is certified RHEL and SLES. Deploying on CentOS is out-of-thebox. Deploying on debian (we have also debian servers) is often a nightmare and some functionalities still doesn't work (and support reply "debian is not supported"). We have no alternative for these softwares. - hardware support for servers rely also on some certifications and they are mainly for RHEL or SLES (or Unbutu but for laptops, not servers) and in case of trouble the support has yet answered "please use a certified os". Centos is considered as RHEL by the support. Not sure that with stream it will be the same.

Patrick

Le 14/12/2020 à 17:57, Lamar Owen a écrit :

On 12/12/20 10:34 PM, Konstantin Boyandin via CentOS wrote:

...

My only concern ATM is whether RH can change its CentOS 7 maintenance plans as well, all of a sudden.

This is what bothers me, too, but in a slightly different way.  Even for the GPL software, Red Hat actually doesn't have to provide public access to the source code; the only thing required by GPL is that those who receive binaries must be able to get sources.  So, even though it has been said that the source will be available, well, it was also said that C8 would be supported to 2029.  There are enough packages in RHEL with non-GPL licenses where it would be very difficult to rebuild the whole distribution without them, and RH is not required by those licenses (MIT, BSD, and others) to redistribute those modified sources even to people who have been distributed binaries.  So, while I want to believe that the sources will remain available, that belief relies on trust, which unfortunately is less abundant these days.

So while using another rebuild seems to be a good stopgap solution, I do wonder if it will prove to be sustainable post-2021.  I'm personally looking at which of the four (that we know about) to possibly go to; I just really doubt I am going to use Oracle; Rocky isn't really there yet and is very young; Springdale is available, mature, and academically supported (nothing wrong with that, just a statement); CloudLinux OS Project Lenix isn't yet released.  Out of the bunch, Springdale would be my first choice right now because it's been around a very long time and is available now.  C8 is supposed to be around until end of 2021, so there is some time for the dust to settle and the way to become more clear, though.  But CentOS 8 Stream is only an option for me if the hardware driver KABI synchronization issue is solved and stays solved.  RHEL?  Under the current subscription models we just can't afford it. (Cost also keeps SLES out of the running.)

But I'm now seriously considering just simply going to something that is both older than Red Hat, fully and totally open, extremely well-supported by a diverse developer community, and used by a whole lot of people.  Yes, that's Debian; until I realized where the name came from (Deb and Ian) it read to me like a play on 'deviant.'  The 'stable' period is shorter, for sure.  The tradeoffs are pretty simple: guaranteed openness versus less change for ten years.

So, let's look at that last piece.  CentOS 6's support just ended; what have the last nine years and three months of actual C6 support looked like?  I supported several C6 machines, and there were distinct challenges early on, at least for the first four years or so.  Since then, on the server, it's been very stable, but really old; key pieces of infrastructure software we use slowly became unusable on C6 due to the old versions of specific packages, and either a third-party repo with newer packages or a newer CentOS was needed.

Third-party repos have improved over the years, but some of the earlier C6 machines I installed had packages from Linuxtech, Dag, ATrpms, City-Fan (one particular DVD burner that just had to have the non-wodim cdrtools for some reason; yes, I know all the warnings about that repo), and others.  Having EPEL and Dag both package a few things that I needed, but package them differently, introduced me to package pinning and repo priorities.... I don't miss those days.  Seriously stable in the core repos means very little when you need much less stable third-party repos to get actual work done. That's also why Fedora isn't really an option, just too much package churn; been there, done that, a few years ago.

So I've started re-evaluating just why I use CentOS anyway; the answer really boils down to the fact that I started out with Red Hat Linux in 1997 (I live in North Carolina, and I've always liked supporting local companies) and I just really don't want to change; it feels like I've wasted so much effort if I change now (that was the reason I stuck with it through the Fedora-RHEL split years ago, too, and went with a RHEL rebuild, first WBEL then CentOS).  But the reality is not nearly so stark; a vast majority of the information and skills I've picked up in these years are portable to other distributions; so it's not wasted effort.  Well, other than RPM packaging skills; those are a bit less portable.  Whenever I've built from source I've tried to either build my own RPM for it or rebuild the Fedora RPM for it, and so I have a local repo of those packages, making reinstall much easier.  So it becomes a tossup: small change to another rebuild now, possibility of major change later, or bite the bullet and go ahead and get the major change over with and only have small changes later.

---

CentOS mailing list CentOS@centos.org https://lists.centos.org/mailman/listinfo/centos

On 12/15/20 9:48 AM, R C wrote:

The only thing RHEL can 'bank on' in the near future is that there is nothing else around yet. (but problems like these never lasted long in the past)

Springdale made by Princeton exists longer then CentOS: https://puias.math.ias.edu/

They have "network" CD ISO for 8.1 and boot.iso for 8.3.

On 12/15/20 10:06 AM, Matthew Miller wrote:

On Tue, Dec 15, 2020 at 01:48:21AM -0700, R C wrote:

...

I think that Centos, being that close to RHEL, should have had a licensing scheme for personal use, small business use, just to make things 'fair'.

So, again, please stay tuned. Not for licensing schemes for CentOS, but for programs for these use cases for RHEL. See https://www.redhat.com/en/blog/faq-centos-stream-updates#Q10 and please really do mail centos-questions@redhat.com with your use cases. This is answered by humans designing these programs, not by sales.

Oh I know, there are already programs like that. For example, want to learn how to play with Kubernetes, sure, here get a free full trial licence for RHEL to do that (but you can only get one.). Use cases; I think a lot of people using Centos do it, because they can easily/free build a server/workstation pretty much the same as at work, the only difference being the background being blue instead of red.

Sure, redhat might help these  "use cases" out, but that means you are accepting a gift from a company that has an interest in selling to your employer, and most employers will definitely not allow that and terminate those who do.

From what I understand, RHEL and Centos go different ways so a lot of "the community" will start looking for alternatives, and will find them. We'll see how it goes.

(the order of magnitude in increase of email on these lists, might be an indication about the quality of that idea.)

...

I don't think their (IBM/RHEL) course is going to change though, redhat going "commercial" has been going on for a decade and a half or so, and it looks like initial investors have a desire cashing/selling out at this point.

I don't think there will be a course change either, but for different reasons. The motivation isn't "cashing/selling out". It's... actually the stated motivation https://www.redhat.com/en/blog/faq-centos-stream-updates#Q2

On Tue, Dec 15, 2020 at 12:24 PM Tom Bishop bishoptf@gmail.com wrote:

On Tue, Dec 15, 2020, 11:06 AM Matthew Miller mattdm@mattdm.org wrote:

...

I don't think there will be a course change either, but for different reasons. The motivation isn't "cashing/selling out". It's... actually the stated motivation https://www.redhat.com/en/blog/faq-centos-stream-updates#Q2

-- Matthew Miller mattdm@fedoraproject.org Fedora Project Leader _______________________________________________ CentOS mailing list CentOS@centos.org https://lists.centos.org/mailman/listinfo/centos

I know you and other RHEL folks keep saying this about cashing out etc, but they could have kept stream and Centos stable at the same time but chose not to. Ya know, if it walks like a duck and quacks as a duck...who knows maybe this goes down as one of the best decisions ever for RH but I think its going to hurt them in more ways then they ever thought about. _______________________________________________

Not to mention the constant barrage of "You just want free Red Hat" and "CentOS users are moochers" and "We deserve value from all those CentOS users, so we're going to turn them into beta testers for RHEL." I have gotten these responses here and on twitter from CentOS and Red Hat employees.

So, sorry, but this line about this not being a money grab is an obvious crock of excrement.

On Tue, Dec 15, 2020 at 11:31 AM Phelps, Matthew mphelps@cfa.harvard.edu wrote:

Not to mention the constant barrage of "You just want free Red Hat" and "CentOS users are moochers" and "We deserve value from all those CentOS users, so we're going to turn them into beta testers for RHEL." I have gotten these responses here and on twitter from CentOS and Red Hat employees.

So, sorry, but this line about this not being a money grab is an obvious crock of excrement.

Or the line that they "never promised 2029" and that it "was a mistake". THey keep trying to make it out as if the lifetime of CentOS was separate from RHEL. Yet, this interview comes out where Rich Bowen says exactly that it is, like we all expected it to be.

First, it's important to understand that the dates that the CentOS

project lists as EOL (End Of Life) dates are, and always have been, dependent on Red Hat. That is, we can say that CentOS Linux 7 will be EOL on a particular date, but if the dates around RHEL 7 shift, hypothetically speaking, then so will those around CentOS Linux 7. That's what happened with CentOS Linux 8. This decision was made by Red Hat and the CentOS Board. https://en.wikinews.org/wiki/Red_Hat_to_move_focus_away_from_CentOS_in_favou...

On Tue, Dec 15, 2020 at 11:24:03AM -0600, Tom Bishop wrote:

I know you and other RHEL folks keep saying this about cashing out etc, but they could have kept stream and Centos stable at the same time but chose not to. Ya know, if it walks like a duck and quacks as a duck...who knows maybe this goes down as one of the best decisions ever for RH but I think its going to hurt them in more ways then they ever thought about.

As I've also said before, I have no special insight into how RH and the CentOS board came to this timeline, but I _am_ inclined to believe that the motivation is the one that they give: they want to focus attention and resources. Look at CloudLinux saying that they plan to invest a million dollars a year into doing their rebuild. It's easy to _say_ "Red Hat could easily have done both".

On Tue, Dec 15, 2020, 12:07 PM Matthew Miller mattdm@mattdm.org wrote:

On Tue, Dec 15, 2020 at 11:24:03AM -0600, Tom Bishop wrote:

...

I know you and other RHEL folks keep saying this about cashing out etc,

but

...

they could have kept stream and Centos stable at the same time but chose not to. Ya know, if it walks like a duck and quacks as a duck...who knows maybe this goes down as one of the best decisions ever for RH but I think its going to hurt them in more ways then they ever thought about.

As I've also said before, I have no special insight into how RH and the CentOS board came to this timeline, but I _am_ inclined to believe that the motivation is the one that they give: they want to focus attention and resources. Look at CloudLinux saying that they plan to invest a million dollars a year into doing their rebuild. It's easy to _say_ "Red Hat could easily have done both".

-- Matthew Miller mattdm@fedoraproject.org Fedora Project Leader _______________________________________________ CentOS mailing list CentOS@centos.org https://lists.centos.org/mailman/listinfo/centos

Please, yeah poor, poor Redhat, they are struggling these days, *cough* they needed to do this in order to survive. I thought it didn't have anything to do with cashing in. Really it's there choice if the decide to run it into the ground or not, to many bean counters get involved and it all becomes about making money, nowhere close to the original ideals for the company when it was started.

I don't think there will be a course change either, but for different reasons. The motivation isn't "cashing/selling out". It's... actually the stated motivation https://www.redhat.com/en/blog/faq-centos-stream-updates#Q2

First, I will note that I think the idea of creating *a version of* CentOS that is called "Stream", with the intent that it leads RHEL by a bit, is a GREAT idea, for exactly the stated reasons!

There's one problem I have with this asserted motivation. Stream is not being done as *a version of* CentOS. It is being done as *THE* CentOS, which means you're discontinuing point releases. As far as "maintaining CentOS point releases to follow RHEL"- this is what is being discontinued. How much money, in developer time and other incidentals, does this cost RedHat per year? Of course this is a proprietary number. But let's imagine that this number is $250k per year. Out of what was it, about $433M of profit (2019)? So it would cost RedHat 0.06% of profit to hire more developers to keep issuing CentOS point releases.

What does RedHat "buy" in return for spending 0.06% of its profit on maintaining point releases? -Community trust and goodwill. Those members of the community that cannot afford RedHat licenses for whatever reason still know that the #1 player in the Linux marketplace still has their back. Then when those folks move on to enterprises that can afford RH licensing (and in some cases demand it), will select RedHat because of this trust and goodwill. They will be highly likely to recommend other RedHat products- since it all "works together" and they'll know RHEL (i.e. CentOS) well. Also note that this trust and goodwill means "convenience", even within enterprises that have a large budget with RedHat. If I have a project and I want to spin up 100 OS instances just for the heck of it, I can. I don't need to ask anyone, I don't need to reserve or download any entitlement key files. I don't need to debug weird problems when entitlement key files don't work. -Control of part of the ecosystem. Those companies that build their products to run on RHEL (or in RHEL containers) are able to (and encouraged to) certify those products on RHEL because they are able to use CentOS.

But more to the point, what does RedHat LOSE by saving 0.06% of its profit? The damage to community trust and goodwill far exceeds the gains that would be realized if the status quo were kept in place. Yes, it's true that many of the folks who used CentOS would never turn into paying customers. But due to this situation, you have thousands of system administrators who are actively looking to completely abandon the RedHat ecosystem altogether. When it comes time to recommend products... they aren't going to recommend RHEL. They aren't going to recommend JBoss, or Fuse, or 3Scale API management. It's clear that RedHat can't be trusted with some parts of its portfolio, so why should we trust ANY of its products?

If it is 100% factually correct that the ONLY motivation for killing point releases is the stated motivation, then it's just a simple matter of finding a spare $250k (or whatever that cost is) from the almost-half-a-billion dollar corporate coin purse. The return on investment has been, and will continue to be, immeasurable... IF y'all do damage control ASAP.

--JK

On Tue, Dec 15, 2020 at 12:06 PM Matthew Miller mattdm@mattdm.org wrote:

On Tue, Dec 15, 2020 at 01:48:21AM -0700, R C wrote:

...

I think that Centos, being that close to RHEL, should have had a licensing scheme for personal use, small business use, just to make things 'fair'.

So, again, please stay tuned. Not for licensing schemes for CentOS, but for programs for these use cases for RHEL. See https://www.redhat.com/en/blog/faq-centos-stream-updates#Q10 and please really do mail centos-questions@redhat.com with your use cases. This is answered by humans designing these programs, not by sales.

...

I don't think their (IBM/RHEL) course is going to change though, redhat going "commercial" has been going on for a decade and a half or so, and it looks like initial investors have a desire cashing/selling out at this point.

I don't think there will be a course change either, but for different reasons. The motivation isn't "cashing/selling out". It's... actually the stated motivation https://www.redhat.com/en/blog/faq-centos-stream-updates#Q2

-- Matthew Miller mattdm@fedoraproject.org Fedora Project Leader _______________________________________________ CentOS mailing list CentOS@centos.org https://lists.centos.org/mailman/listinfo/centos

On Tue, Dec 15, 2020 at 7:41 PM Johnny Hughes johnny@centos.org wrote:

On 12/15/20 6:12 PM, Joshua Kramer wrote:

...

...

I don't think there will be a course change either, but for different reasons. The motivation isn't "cashing/selling out". It's... actually

the

...

...

stated motivation https://www.redhat.com/en/blog/faq-centos-stream-updates#Q2

First, I will note that I think the idea of creating *a version of* CentOS that is called "Stream", with the intent that it leads RHEL by a bit, is a GREAT idea, for exactly the stated reasons!

There's one problem I have with this asserted motivation. Stream is not being done as *a version of* CentOS. It is being done as *THE* CentOS, which means you're discontinuing point releases. As far as "maintaining CentOS point releases to follow RHEL"- this is what is being discontinued. How much money, in developer time and other incidentals, does this cost RedHat per year? Of course this is a proprietary number. But let's imagine that this number is $250k per year. Out of what was it, about $433M of profit (2019)? So it would cost RedHat 0.06% of profit to hire more developers to keep issuing CentOS point releases.

What does RedHat "buy" in return for spending 0.06% of its profit on maintaining point releases? -Community trust and goodwill. Those members of the community that cannot afford RedHat licenses for whatever reason still know that the #1 player in the Linux marketplace still has their back. Then when those folks move on to enterprises that can afford RH licensing (and in some cases demand it), will select RedHat because of this trust and goodwill. They will be highly likely to recommend other RedHat products- since it all "works together" and they'll know RHEL (i.e. CentOS) well. Also note that this trust and goodwill means "convenience", even within enterprises that have a large budget with RedHat. If I have a project and I want to spin up 100 OS instances just for the heck of it, I can. I don't need to ask anyone, I don't need to reserve or download any entitlement key files. I don't need to debug weird problems when entitlement key files don't work. -Control of part of the ecosystem. Those companies that build their products to run on RHEL (or in RHEL containers) are able to (and encouraged to) certify those products on RHEL because they are able to use CentOS.

But more to the point, what does RedHat LOSE by saving 0.06% of its profit? The damage to community trust and goodwill far exceeds the gains that would be realized if the status quo were kept in place. Yes, it's true that many of the folks who used CentOS would never turn into paying customers. But due to this situation, you have thousands of system administrators who are actively looking to completely abandon the RedHat ecosystem altogether. When it comes time to recommend products... they aren't going to recommend RHEL. They aren't going to recommend JBoss, or Fuse, or 3Scale API management. It's clear that RedHat can't be trusted with some parts of its portfolio, so why should we trust ANY of its products?

So don't trust them. Move to something else if you think something is better.

...

If it is 100% factually correct that the ONLY motivation for killing point releases is the stated motivation, then it's just a simple matter of finding a spare $250k (or whatever that cost is) from the almost-half-a-billion dollar corporate coin purse. The return on investment has been, and will continue to be, immeasurable...

$250K is not even close. That is one employee, when you also take into account unemployment insurance, HR, medical insurance etc. now multiply that by 8. Now, outfit those 8 employees to work from home .. all over the world, different countries, different laws.

.. THEN buy 30 machines minimum (servers, not workstations) for building and testing, buy a service contract for those 30 machines, host the bandwidth required to sync out to 600 worldwide servers.

We need all the CI machines .. that is a bunch of blade servers for that. They need service contacts too.

In any event it doesn't matter. The decision is made. If people don't want to use CentOS Stream, then don't. The decision is not changing. _______________________________________________

We won't.

Thanks for all your work in the past. Good luck to you.

And to Red Hat I have one more thing to say:

Buh bye!

###

I would like to echo the thanks in this post, and to add a bit of information that I have learned doing some quick research on where to go.  Scientific Linux is basically no more, they deferred to Centos and pretty much ended their distribution. Oracle seems to be the easiest and quickest migration, they have a script which will make all of the changes to your server, switching you over to the Oracle flavor of Linux. On the horizon is Rocky Linux, a start up from the people who brought you Centos. As well as Cloud OS who says they are going to pick up where Centos left off, and continue a down stream version of the product. Worst case, we / you will have Oracle to fall back on if Rocky Linux or Cloud OS doesn't come through.. But once again, a BIG THANK YOU to Centos for all the years of work.

John Plemons

On 12/16/2020 11:45 AM, Valeri Galtsev wrote:

My apologies about top posting.

I join Matthew on all counts.

The following might sound as a rant, but it is not, given the circumstances we have been put into.

First, and most important: thank you CentOS team for all great work youhave done during all these years. As user who used results of your work without giving much back (not counting maintaining public mirror, or helping others on the list whenever I felt my expertise adequate), I can not express how high I value what you gave to all of us.

Now, that CentOS as we knew it (as a “binary replica” of RedHat Enterprise) ceases to exist many of us are trying to figure out new long term solution for their “enterprise” sort of systems. Luckily I only partly have to do that, as for servers I already didmigration quite long ago. My mentioning it on this list was causing moreannoyance than I would like to, so I stopped mentioning it. But now it is time to mention it again, just to help everyone arrive at best decision. But first some thoughts on migration to different Linux Distro:

One of obvious possibilities is to migrate to some other “binary clone” of RHEL. One can find several, Oracle Linux (even thoughmany are cautious of Oracle, they - Oracle - didn’t drown out ofexistence mysql so far, maybe thanks to mariadb fork existence, …), Scientific Linux (which is effort of really small team, and I evaluated it well below CentOS when I had to make decision, and it confirmed trueover time), and others... However, once RedHat (or rather its owner IBM)made fundamental decision, it is not as much about the one who clones (binary rebuilds) of RHEL, as it is about RHEL itself. At least fo me it is. As, by undermining trust, even if they roll everything back to what it was, the trust is already lost by the knowledge of everyone that any moment they can do that in a future. This alternative is just out of question for me. Will I maintain RHEL for my current or potential future employer? Yes, definitely. Will I recommend fair (and way cheaper, better, longer lasting) alternative? By all means, yes, and with my experience of migration, and documented migration steps, etc...

Another possibility for pure Linux folks is switch to different distro.Not with 10 years life cycle (here RedHat was unique), but shorter one, yet with much easier upgrade from one release to another. [Even knowing about Ubuntu LTS] Debian would be my choice, which I am going to pursue for CentOS number crunchers and workstations I maintain. Laptops are Debianclone Ubuntu since long ago. This will be “rolling release", i.e. mostly you will have to upgrade packages to latest release, and constantly will take chance something will break with change of internals of given software from one release to another. It will be more work (for 24/7/365 servers most gravely notable). But it may outweigh the single event when your “enterprise” life is cancelled one day, and youhave to redo the whole infrastructure all at once. Think about it and about peace of mind avoiding that eventuality.

This leads me at last to telling that my sever infrastructure was migrated long ago to FreeBSD. One can chose different BSD successor based on one’s own assessment of suitability. First of all, pure Linux folk, it is not that challenging as one may think. I would say here the same thing I was telling to my users who we just starting to use UNIX (or Linux). How many command do you need to know to start using UNIX? Just 5-6 isenough. Start doing things, and in a couple of Months you will feel you know everything. In 6 Months you will be top expert: the one who knows what he knows and knows what he doesn’t know. My choice was based on the following facts: FreeBSD is most widely used (even Microsoft was once noticed to run some of their servers on FreeBSD). FreeBSD has excellent documentation. FreeBSD community is as eager to help the one who got stuck with something as our CentOS community is. They have as excellent experts as Johnny, Matthew, ... sorry I can not mention everyone, that will take separate huge post...

And now, with my servers gone to FreeBSD long ago, I can share this nice experience. On FreeBSD (base system is separate, and Linux, BTW, decided to go same excellent way), and extra stuff can be added from huge port collection, most part of which is available as binary packages. Ports/packages are up to their maintainers, and pretty much all of the ones I use are available as different versions, still maintained and patched, so younot necessarily have to upgrade to latest version when it is released. In this respect, individual ports or packages can live as “enterprise” portions of your ecosystem themselves (each with its own life cycle, still…) This actually is not as challenging as it may sound, as long before end of life of some package version (like PHP-5), at every update you will get warning that it will be end of life soon (starts multiple Months before the day it is going to happen…).

Anyway, what I am leading to is: life with FreeBSD is not as challenging as it may seem before you try. Just try it. And it is more “enterprisish” than with Linux “rolling release” in my opinion. Though I must confess, I have much less “rolling” Linux release server experience, than I have FreeBSD experience.

I did not even mention FreeBSD jails which essentially are containers with the same base system mounted read-only (or you can several base system versions, e.g. 12.x and 11.x for some or another jails). Anyway, jails can be long separate post…

The length of my post suggests that it is a “log goodbye”which it probably will be.

Thanks again to CentOS, the hard working excellent team. Whatever fallson you from us has nothing to do with you, but rather with RHEL/IBM, andthe trust they decided to throw out of window.

Valeri

...

On Dec 15, 2020, at 7:04 PM, Phelps, Matthew mphelps@cfa.harvard.eduwrote:

On Tue, Dec 15, 2020 at 7:41 PM Johnny Hughes johnny@centos.org wrote:

...

On 12/15/20 6:12 PM, Joshua Kramer wrote:

...

...

I don't think there will be a course change either, but for different reasons. The motivation isn't "cashing/selling out". It's... actually

the

...

...

stated motivation https://www.redhat.com/en/blog/faq-centos-stream-updates#Q2

First, I will note that I think the idea of creating *a version of* CentOS that is called "Stream", with the intent that it leads RHEL by a bit, is a GREAT idea, for exactly the stated reasons!

There's one problem I have with this asserted motivation. Stream is not being done as *a version of* CentOS. It is being done as *THE* CentOS, which means you're discontinuing point releases. As far as "maintaining CentOS point releases to follow RHEL"- this is what is being discontinued. How much money, in developer time and other incidentals, does this cost RedHat per year? Of course this is a proprietary number. But let's imagine that this number is $250k per year. Out of what was it, about $433M of profit (2019)? So it would cost RedHat 0.06% of profit to hire more developers to keep issuing CentOS point releases.

What does RedHat "buy" in return for spending 0.06% of its profit on maintaining point releases? -Community trust and goodwill. Those members of the community that cannot afford RedHat licenses for whatever reason still know that the #1 player in the Linux marketplace still has their back. Then when those folks move on to enterprises that can afford RH licensing (and in some cases demand it), will select RedHat because of this trust and goodwill. They will be highly likely to recommend other RedHat products- since it all "works together" and they'll know RHEL (i.e. CentOS) well. Also note that this trust and goodwill means "convenience", even within enterprises that have a large budget with RedHat. If I have a project and I want to spin up 100 OS instances just for the heck of it, I can. I don't need to ask anyone, I don't need to reserve or download any entitlement key files. I don't need to debug weird problems when entitlement key files don't work. -Control of part of the ecosystem. Those companies that build their products to run on RHEL (or in RHEL containers) are able to (and encouraged to) certify those products on RHEL because they are able to use CentOS.

But more to the point, what does RedHat LOSE by saving 0.06% of its profit? The damage to community trust and goodwill far exceeds the gains that would be realized if the status quo were kept in place. Yes, it's true that many of the folks who used CentOS would never turn into paying customers. But due to this situation, you have thousands of system administrators who are actively looking to completely abandon the RedHat ecosystem altogether. When it comes time to recommend products... they aren't going to recommend RHEL. They aren't going to recommend JBoss, or Fuse, or 3Scale API management. It's clear that RedHat can't be trusted with some parts of its portfolio, so why should we trust ANY of its products?

So don't trust them. Move to something else if you think something is better.

...

If it is 100% factually correct that the ONLY motivation for killing point releases is the stated motivation, then it's just a simple matter of finding a spare $250k (or whatever that cost is) from the almost-half-a-billion dollar corporate coin purse. The return on investment has been, and will continue to be, immeasurable...

$250K is not even close. That is one employee, when you also take into account unemployment insurance, HR, medical insurance etc. now multiply that by 8. Now, outfit those 8 employees to work from home .. all over the world, different countries, different laws.

.. THEN buy 30 machines minimum (servers, not workstations) for building and testing, buy a service contract for those 30 machines, host the bandwidth required to sync out to 600 worldwide servers.

We need all the CI machines .. that is a bunch of blade servers for that. They need service contacts too.

In any event it doesn't matter. The decision is made. If people don't want to use CentOS Stream, then don't. The decision is not changing. _______________________________________________

We won't.

Thanks for all your work in the past. Good luck to you.

And to Red Hat I have one more thing to say:

Buh bye!

###

-- *Matt Phelps*

*Information Technology Specialist, Systems Administrator*

(Computation Facility, Smithsonian Astrophysical Observatory)

Center for Astrophysics | Harvard & Smithsonian

60 Garden Street | MS 39 | Cambridge, MA 02138 email: mphelps@cfa.harvard.edu

cfa.harvard.edu | Facebook http://cfa.harvard.edu/facebook | Twitter http://cfa.harvard.edu/twitter | YouTube http://cfa.harvard.edu/youtube | Newsletter http://cfa.harvard.edu/newsletter _______________________________________________ CentOS mailing list CentOS@centos.org https://lists.centos.org/mailman/listinfo/centos

---

CentOS mailing list CentOS@centos.org https://lists.centos.org/mailman/listinfo/centos

On Dec 16, 2020, at 11:38 AM, R C cjvijf@gmail.com wrote:

On 12/16/20 9:45 AM, Valeri Galtsev wrote:

...

My apologies about top posting.

I join Matthew on all counts.

The following might sound as a rant, but it is not, given the circumstances we have been put into.

First, and most important: thank you CentOS team for all great work you have done during all these years. As user who used results of your work without giving much back (not counting maintaining public mirror, or helping others on the list whenever I felt my expertise adequate), I can not express how high I value what you gave to all of us.

Now, that CentOS as we knew it (as a “binary replica” of RedHat Enterprise) ceases to exist many of us are trying to figure out new long term solution for their “enterprise” sort of systems. Luckily I only partly have to do that, as for servers I already did migration quite long ago. My mentioning it on this list was causing more annoyance than I would like to, so I stopped mentioning it. But now it is time to mention it again, just to help everyone arrive at best decision. But first some thoughts on migration to different Linux Distro:

One of obvious possibilities is to migrate to some other “binary clone” of RHEL. One can find several, Oracle Linux (even though many are cautious of Oracle, they - Oracle - didn’t drown out of existence mysql so far, maybe thanks to mariadb fork existence, …), Scientific Linux (which is effort of really small team, and I evaluated it well below CentOS when I had to make decision, and it confirmed true over time), and others... However, once RedHat (or rather its owner IBM) made fundamental decision, it is not as much about the one who clones (binary rebuilds) of RHEL, as it is about RHEL itself. At least fo me it is. As, by undermining trust, even if they roll everything back to what it was, the trust is already lost by the knowledge of everyone that any moment they can do that in a future. This alternative is just out of question for me. Will I maintain RHEL for my current or potential future employer? Yes, definitely. Will I recommend fair (and way cheaper, better, longer lasting) alternative? By all means, yes, and with my experience of migration, and documented migration steps, etc...

Another possibility for pure Linux folks is switch to different distro. Not with 10 years life cycle (here RedHat was unique), but shorter one, yet with much easier upgrade from one release to another. [Even knowing about Ubuntu LTS] Debian would be my choice, which I am going to pursue for CentOS number crunchers and workstations I maintain. Laptops are Debian clone Ubuntu since long ago. This will be “rolling release", i.e. mostly you will have to upgrade packages to latest release, and constantly will take chance something will break with change of internals of given software from one release to another. It will be more work (for 24/7/365 servers most gravely notable). But it may outweigh the single event when your “enterprise” life is cancelled one day, and you have to redo the whole infrastructure all at once. Think about it and about peace of mind avoiding that eventuality.

This leads me at last to telling that my sever infrastructure was migrated long ago to FreeBSD. One can chose different BSD successor based on one’s own assessment of suitability. First of all, pure Linux folk, it is not that challenging as one may think. I would say here the same thing I was telling to my users who we just starting to use UNIX (or Linux). How many command do you need to know to start using UNIX? Just 5-6 is enough. Start doing things, and in a couple of Months you will feel you know everything. In 6 Months you will be top expert:

I work in HPC, pretty much exclusively with redhat and it's clones/derivatives, in very large scale environments. I mostly do R&D 'stuff', and very much rely on our admins doing that, I constantly talk with them for advice, or just to discuss system stuff, most of them have been doing this longer then I have. I still consider myself a rookie.

so yeah.... 6 months.... *chuckle* you should consider applying in places like that if you're that good.

No I am not considering myself “that good”. Even after running FreeBSD servers for what? about last decade probably. And running or using UNIXes long ago before I became "Linux guy”. Not at all.

But this is not about myself, this is for those who decide to switch to [Free]BSD. Remember how soon after starting with Linux you felt comfortable with it? Now mind it that being Linux expert, you will become facile with [Free or any other]BSD much sooner. You will likely get rid of “Linuxisms” 6 Month down the road, and develop strong BSD-isms when dealing with Linux then.

And as a “top expert” I meant the highest stage of acquiring knowledge, like in:

1. I don’t know anything 2. I know something 3. I know everything 4. I know a lot, and I do know what I know and what I don’t know

And there is nothing higher, no 5 ...., this is the highest. At least not if I were apply it to myself.

My apologies if I put it in confusing way in my previous post.

Valeri

...

the one who knows what he knows and knows what he doesn’t know. My choice was based on the following facts: FreeBSD is most widely used (even Microsoft was once noticed to run some of their servers on FreeBSD). FreeBSD has excellent documentation. FreeBSD community is as eager to help the one who got stuck with something as our CentOS community is. They have as excellent experts as Johnny, Matthew, ... sorry I can not mention everyone, that will take separate huge post...

And now, with my servers gone to FreeBSD long ago, I can share this nice experience. On FreeBSD (base system is separate, and Linux, BTW, decided to go same excellent way), and extra stuff can be added from huge port collection, most part of which is available as binary packages. Ports/packages are up to their maintainers, and pretty much all of the ones I use are available as different versions, still maintained and patched, so you not necessarily have to upgrade to latest version when it is released. In this respect, individual ports or packages can live as “enterprise” portions of your ecosystem themselves (each with its own life cycle, still…) This actually is not as challenging as it may sound, as long before end of life of some package version (like PHP-5), at every update you will get warning that it will be end of life soon (starts multiple Months before the day it is going to happen…).

Anyway, what I am leading to is: life with FreeBSD is not as challenging as it may seem before you try. Just try it. And it is more “enterprisish” than with Linux “rolling release” in my opinion. Though I must confess, I have much less “rolling” Linux release server experience, than I have FreeBSD experience.

I did not even mention FreeBSD jails which essentially are containers with the same base system mounted read-only (or you can several base system versions, e.g. 12.x and 11.x for some or another jails). Anyway, jails can be long separate post…

The length of my post suggests that it is a “log goodbye” which it probably will be.

Thanks again to CentOS, the hard working excellent team. Whatever falls on you from us has nothing to do with you, but rather with RHEL/IBM, and the trust they decided to throw out of window.

Valeri

...

On Dec 15, 2020, at 7:04 PM, Phelps, Matthew mphelps@cfa.harvard.edu wrote:

On Tue, Dec 15, 2020 at 7:41 PM Johnny Hughes johnny@centos.org wrote:

...

On 12/15/20 6:12 PM, Joshua Kramer wrote:

...

...

I don't think there will be a course change either, but for different reasons. The motivation isn't "cashing/selling out". It's... actually

the

...

...

stated motivation https://www.redhat.com/en/blog/faq-centos-stream-updates#Q2

First, I will note that I think the idea of creating *a version of* CentOS that is called "Stream", with the intent that it leads RHEL by a bit, is a GREAT idea, for exactly the stated reasons!

There's one problem I have with this asserted motivation. Stream is not being done as *a version of* CentOS. It is being done as *THE* CentOS, which means you're discontinuing point releases. As far as "maintaining CentOS point releases to follow RHEL"- this is what is being discontinued. How much money, in developer time and other incidentals, does this cost RedHat per year? Of course this is a proprietary number. But let's imagine that this number is $250k per year. Out of what was it, about $433M of profit (2019)? So it would cost RedHat 0.06% of profit to hire more developers to keep issuing CentOS point releases.

What does RedHat "buy" in return for spending 0.06% of its profit on maintaining point releases? -Community trust and goodwill. Those members of the community that cannot afford RedHat licenses for whatever reason still know that the #1 player in the Linux marketplace still has their back. Then when those folks move on to enterprises that can afford RH licensing (and in some cases demand it), will select RedHat because of this trust and goodwill. They will be highly likely to recommend other RedHat products- since it all "works together" and they'll know RHEL (i.e. CentOS) well. Also note that this trust and goodwill means "convenience", even within enterprises that have a large budget with RedHat. If I have a project and I want to spin up 100 OS instances just for the heck of it, I can. I don't need to ask anyone, I don't need to reserve or download any entitlement key files. I don't need to debug weird problems when entitlement key files don't work. -Control of part of the ecosystem. Those companies that build their products to run on RHEL (or in RHEL containers) are able to (and encouraged to) certify those products on RHEL because they are able to use CentOS.

But more to the point, what does RedHat LOSE by saving 0.06% of its profit? The damage to community trust and goodwill far exceeds the gains that would be realized if the status quo were kept in place. Yes, it's true that many of the folks who used CentOS would never turn into paying customers. But due to this situation, you have thousands of system administrators who are actively looking to completely abandon the RedHat ecosystem altogether. When it comes time to recommend products... they aren't going to recommend RHEL. They aren't going to recommend JBoss, or Fuse, or 3Scale API management. It's clear that RedHat can't be trusted with some parts of its portfolio, so why should we trust ANY of its products?

So don't trust them. Move to something else if you think something is better.

...

If it is 100% factually correct that the ONLY motivation for killing point releases is the stated motivation, then it's just a simple matter of finding a spare $250k (or whatever that cost is) from the almost-half-a-billion dollar corporate coin purse. The return on investment has been, and will continue to be, immeasurable...

$250K is not even close. That is one employee, when you also take into account unemployment insurance, HR, medical insurance etc. now multiply that by 8. Now, outfit those 8 employees to work from home .. all over the world, different countries, different laws.

.. THEN buy 30 machines minimum (servers, not workstations) for building and testing, buy a service contract for those 30 machines, host the bandwidth required to sync out to 600 worldwide servers.

We need all the CI machines .. that is a bunch of blade servers for that. They need service contacts too.

In any event it doesn't matter. The decision is made. If people don't want to use CentOS Stream, then don't. The decision is not changing. _______________________________________________

We won't.

Thanks for all your work in the past. Good luck to you.

And to Red Hat I have one more thing to say:

Buh bye!

###

--

*Matt Phelps*

*Information Technology Specialist, Systems Administrator*

(Computation Facility, Smithsonian Astrophysical Observatory)

Center for Astrophysics | Harvard & Smithsonian

60 Garden Street | MS 39 | Cambridge, MA 02138 email: mphelps@cfa.harvard.edu

cfa.harvard.edu | Facebook http://cfa.harvard.edu/facebook | Twitter http://cfa.harvard.edu/twitter | YouTube http://cfa.harvard.edu/youtube | Newsletter http://cfa.harvard.edu/newsletter _______________________________________________ CentOS mailing list CentOS@centos.org https://lists.centos.org/mailman/listinfo/centos

---

CentOS mailing list CentOS@centos.org https://lists.centos.org/mailman/listinfo/centos

---

CentOS mailing list CentOS@centos.org https://lists.centos.org/mailman/listinfo/centos

On Tue, Dec 15, 2020 at 9:14 PM Bernstein, Noam CIV USN NRL (6393) Washington DC (USA) via CentOS centos@centos.org wrote:

Every package that ends up in a RHEL point release is in Stream at some point, right? While I can certainly believe that the cost for the entire CentOS effort is much more than $250K, dropping CentOS point releases just means not gathering the particular versions that ended up in the corresponding RHEL point release.

This is exactly what I was talking about. I didn't ask, "how much does it cost to build CentOS". More specifically I was speculating on the amount of additional effort that was specifically required to do CentOS point release support, over and above the standard CentOS development (that RedHat would still be paying for). Having said that- it's possible that RedHat has heavily modified the build path for CentOS, since now it's upstream of RHEL instead of downstream; and if that's the case it could be that the new build path makes it impossible to build point releases. Having said THAT- it should be relatively simple to tag specific versions of packages in CentOS once those packages are released in a RHEL point release, then do an ISO build off of that. (I was guesstimating that it would take one FTE worth of time to do such tagging or other work needed to build the point releases based on the work that had already been done on the Stream updates, that's where I got the $250k from.)

It seems as if it ought to actually be less expensive to do things this way than it has traditionally been to do CentOS... since traditionally, the CentOS team has had to pull the SRPMS for RHEL, duplicate a bunch of effort that RedHat had done to build them in the first place, and reconcile differences. Now since CentOS is actually part of the real RHEL build process, the work to create CentOS is paid for by RHEL. Officially.

Maybe THAT is the problem. Since CentOS is now part of the official RHEL build pipeline, RedHat is unwilling to allow that work to be used to build the traditional CentOS point releases. They aren't going to directly contribute work that is paid for by RHEL to do the free CentOS releases. In order to do the 'clean room' implementation of point releases they would have to essentially re-duplicate ALL of the work that has traditionally been required to build CentOS... and THAT'S where the requirement of 8 FTE developers and dozens of servers comes from. They would build RHEL point releases and then they would put forth the 8 FTE worth of effort to do a clean-room rebuild of those releases in the form of CentOS, as they always have done.

From an internal view, if I were a RedHat business manager, I could

totally see a legitimate desire to not fund a free product with the resources used to build my paid flagship product.

Having realized all of the above- and I understand this is pure speculation on my part- from an external view, as a community member, it looks different. It seems like RedHat is saying, "WAAAH WAAAH YOU CAN'T HAVE MY TOYS GIVE THEM BACK OR ELSE!!!!" Even if the above is true regarding internal RHEL management not wanting RHEL funding a free product, *there is NO practical difference* on the effects towards the community. It is still the case that by taking this course of action RedHat has branded itself as being a bad faith actor. It is still the case that it would only cost RedHat a trivial amount- perhaps substantially less than the $250k I estimated- to continue to do CentOS point releases based off of RHEL. It is still the case that RedHat could earn back a huge chunk of the trust that it destroyed, by deciding to spend this trivial amount to continue the status quo of CentOS builds.

RedHat needs to keep the following in mind: there is still value in RHEL. Patent indemnification, contractually guaranteed SLA's for defects for mission critical systems, and so forth. This is the whole idea of RedHat's existence, isn't it? To take all of these hundreds of free software packages and repackage them and sell the value that the legal and contractual guarantees offer. As a community we don't want that for CentOS. We know it's "not legally supported". We know that, if it breaks, we get to fix it ourselves or keep all the broken pieces. What we do want is a system that is repeatable, stable, and known. CentOS point releases provide that. CentOS Stream doesn't.

On 12/15/20 7:59 PM, Joshua Kramer wrote:

Why would RedHat invest millions more in buying the CentOS process just to have CentOS act as the beta?

Indeed.

Often, when you can't find a reasonable answer to a question, it is because the premise of the question itself is wrong.

On 12/16/20 10:39 AM, Frank Saporito wrote:

I may be cynical, but I think this is a business decision.

By gaining control of CentOS, RedHat gained control of its biggest (apparent) competitor.  This action should increase the value of RedHat.  A few years later, IBM buys RedHat for a staggering 34 BILLION dollars.  I would expect that before the purchase, there is an internal "PowerPoint" slide discussing the elimination of CentOS Linux.  Despite the commentary otherwise, I believe CentOS Stream is a type of "beta" release.  RedHat can release changes into CentOS Stream to make sure it is all good before the point release of RHEL to the paying customers.

Or maybe not.

That is exactly my thought. IBM is a very big company, 'physically' as well as capital wise  and they do top notch, state of the art, research and

development, and they can pretty much solve any problem. The only problem that IBM always had a problem with dealing with is their competition.

(The numerous, researchers, scientists, mathematicians, engineers they employ,  tremendously increases their overhead, hence everything IBM is expensive.

(I expect that to happen to their licensing too, for redhat in the future)

FCS

On 12/15/20 10:59 PM, Gordon Messmer wrote:

...

On 12/15/20 7:59 PM, Joshua Kramer wrote:

...

Why would RedHat invest millions more in buying the CentOS process just to have CentOS act as the beta?

Indeed.

Often, when you can't find a reasonable answer to a question, it is because the premise of the question itself is wrong.

---

CentOS mailing list CentOS@centos.org https://lists.centos.org/mailman/listinfo/centos

---

CentOS mailing list CentOS@centos.org https://lists.centos.org/mailman/listinfo/centos

On 12/16/20 10:50 AM, Johnny Hughes wrote:

Why did they change the development process of RHEL .. Because they want to do the development in the community. The current process of RHEL development is closed .. they want it to be open. It is that simple.

Johnny, let me say first of all thanks for these years of hard work.  I for one am grateful for your continued and dogged pursuit of what must be a mostly thankless task.  Thanks for the explanations from your point of view of this transition, too.

Having said that, I believe that in terms of RHEL development and transparency that CentOS Stream will be a very big win.  With working resolutions to the 'unsupported by Red Hat but not third-party out-of-tree driver kABI breaks frequently' and 'third-party out-of-tree hardware driver kABI breaks frequently' issues I'm sure it can be a very usable system for what I need CentOS for.  And it will be very nice to be able to have actual feedback that might actually make a difference in the development of each next point release.  That will work nicely for my main daily driver laptop.  Maybe or maybe not for my servers; that has yet to be seen.

But as I posted in my reply to Mike McGrath, Red Hat's reneging on the September 24, 2019 statement that "nothing changes" for CentOS, especially CentOS 8, still smarts.  A lot.  (I know it must be worse for you and the other devs.)

On 12/16/20 5:09 PM, Johnny Hughes wrote:

Hi Lamar, glad to interact w/ you on the list. We both have been doing this for a long time.

Yes, indeed. (Xenix V7 on a TRS-80 Model 16 in 1988..., I STILL use my vi skills from that time i my life!)

I was not thrilled about this decision and it would not have been the one made if things were up to me alone. Obviously they are not. I did support the issue from the perspective of the CentOS Board. Sometimes we have to make hard decisions in life. Many times, one wishes for another option. I do think I chose the best option available. ...

Yes, how true.  Been there, done that, on a much smaller scale.

... People can contact (via email) centos-questions@redhat.com

... Other than it is one of the things the CentOS Board negotiated for before our vote.

Thanks for the pointer.  I see I have some writing to do.  And thanks for pushing for that feedback mechanism!

On 12/17/20 5:54 PM, Konstantin Boyandin via CentOS wrote:

It's purely a developer's distro.

Has Chris Wright ever recommended CentOS for any purpose other than development and testing?

Shall I explain difference between a developer's distro and the one suitable for production servers (a rhetoric question)?

How did you imagine you would look when you asked a CentOS maintainer if he understands the importance of the thing he's been doing for 17 years?

On Fri, Dec 18, 2020 at 08:12:26AM -0500, Konstantin Boyandin via CentOS wrote:

...

...

It's purely a developer's distro.

Has Chris Wright ever recommended CentOS for any purpose other than development and testing?

Will a Red Hat CTO, in his right mind, ever recommend a free clone of RHEL for any purpose other than development and testing?

Right... he's not "lying", he just has a different audience.

Red Hat has definitely never ever said in any official way that CentOS Linux is acceptable for production uses. And that's not going to change with CentOS Stream.

You should see people's heads spin around like a scene from a horror movie when I suggest that people actually do run Fedora operating systems in production!

https://www.zdnet.com/article/cloudlinux-to-invest-more-than-a-million-dolla...

On Dec 18, 2020, at 12:14 PM, Matthew Miller mattdm@mattdm.org wrote:

On Fri, Dec 18, 2020 at 08:12:26AM -0500, Konstantin Boyandin via CentOS wrote:

...

...

...

It's purely a developer's distro.

Has Chris Wright ever recommended CentOS for any purpose other than development and testing?

Will a Red Hat CTO, in his right mind, ever recommend a free clone of RHEL for any purpose other than development and testing?

Right... he's not "lying", he just has a different audience.

Red Hat has definitely never ever said in any official way that CentOS Linux is acceptable for production uses.

OT: when will I learn to just shut up after arriving at my own decision? (rhetoric question)

It doesn’t matter whether RedHat said anything or not. We did use CentOS as “binary replica” of RedHat Enterprise (I for one for over decade and a half), and did have same level of stability as RedHat Enterprise customers had [almost?].Which confirmed the second word in the abbreviated name of the system (Community Enterprise OS).

But now there is nothing [in my book] to justify that “Enterprise" word in the name.

And that's not going to change with CentOS Stream.

You should see people's heads spin around like a scene from a horror movie when I suggest that people actually do run Fedora operating systems in production!

Indeed, that is why many of us who originally switched to Fedora (Hm, when free RedHat ceased to exist somewhere near RedHat 8, do people still remember these CD/DVD sets?). And shortly after, from Fedora to CentOS.

And no, “development” precursor of RedHat Enterprise which Fedora was is no match to “binary replica” of RedHat Enterprise. And it looks - for not too insightful person: myself - that now it will be CentOS a “development” precursor of RedHat Enterprise (taking place of Fedora, and potentially same production usability as Fedora has). And again, I will be happy for everyone who bravely keeps using CentOS (Stream) in production if my feelings are gravely wrong. But I myself “chickened out”. Servers: over 6 years ago (to FreeBSD, and there no surprises with FreeBSD; but apologies for annoying mentioning of the great UNIX successor on this list).

And once again, Thanks a lot for great work, CentOS team! We were enjoying excellent fruits of your work, I - for about decade and a half. And good luck to you in future, I know your work will be same great, it is just humble us who are unhappy about future arrangement.

Valeri

-- Matthew Miller mattdm@fedoraproject.org Fedora Project Leader _______________________________________________ CentOS mailing list CentOS@centos.org https://lists.centos.org/mailman/listinfo/centos

On 12/17/20 7:54 PM, Konstantin Boyandin via CentOS wrote:

On 16.12.2020 22:50, Johnny Hughes wrote:

...

On 12/15/20 9:59 PM, Joshua Kramer wrote:

...

On Tue, Dec 15, 2020 at 7:41 PM Johnny Hughes johnny@centos.org wrote:

...

$250K is not even close. That is one employee, when you also take into account unemployment insurance, HR, medical insurance etc. now multiply that by 8. Now, outfit those 8 employees to work from home .. all over the world, different countries, different laws.

I'm genuinely curious about something, and this is mostly academic since it's probably the subject of proprietary discussions within RedHat. Presumably, RedHat had a build pipeline for RHEL that worked well for them, by supplying alpha/beta releases of point releases to their customers and giving them time to "cook" before releasing those point releases into production. Why would RedHat invest millions more in buying the CentOS process just to have CentOS act as the beta?

Why did they change the development process of RHEL ..

Because they want to do the development in the community. The current process of RHEL development is closed .. they want it to be open. It is that simple.

I think Stream is also very usable as a distro. I think it will be just as usable as CentOS Linux is now.

It's usable, as Fedora is certainly usable - in its separate use cases. It's not bug-for-bug copy of current RHEL, so it's *not* as usable as CentOS Linux was.

...

It is not a beta .. I keep saying that. Before a .0 release (the main, or first, main reelase) is a beta. Point releases do not really need betas .. certainly not open to anyone other than customers. Now CentOS Stream is available all the time to everyone, customer or not. Once the full infrastructure is in place, everyone (not just RHEL customers) can provide feed back and bugs, do pull requests, etc.

Now please tell me whether Chris Wright was lying when saying the below to ZDNet:

"To be exact, CentOS Stream is an upstream development platform for ecosystem developers. It will be updated several times a day. This is not a production operating system. It's purely a developer's distro."

It's purely a developer's distro. Shall I explain difference between a developer's distro and the one suitable for production servers (a rhetoric question)?

Of course he wasn't lying. The purpose of ANY CentOS release from a Red Hat perspective, is as a developer release. Red Hat has never produced CentOS to be used in production for any reason.

It is ALSO completely free to use however YOU want to use it. As is CentOS Stream. If it meets your requirements, you can use it. Stream is no different.

People who certify things, who certified CentOS Linux for things, are free to evaluate and do that with CentOS Stream as well.

Is it ever going to be like it was before .. no. If that is a deal breaker for you, OK. Then you can't use CentOS any longer. Great, if you can't use it, then use something else.

All I can do is what I can do .. All you can do is what you can do. What is absolutely not helpful is continued complaining. A decision was made. It is implemented. CentOS Stream is CentOS Stream.

If you never want to use CentOS again .. great, don't use it. I can't make people use CentOS if they don't want to.

What I will do is what I have been doing for the last 17 years .. I will do the best job I can to make the things I can build for any version of CentOS Linux (or Stream) the best they can be. If people can use them, OK. If they can't OK.

On Fri, Dec 18, 2020 at 10:36:12AM -0600, Christopher Wensink wrote:

You have been involved in CentOS for a long time.  Would you mind explaining the structure here.  Do you work for Red hat full time on the CentOS team?  How many people are on that Team that were working on CentOS?  Is CentOS structured as a non-profit company with staff just working on development of this distribution or is this just a group of independent developers working on the same project?  How many people are working on active development of on the Red hat team / CentOS Organization (if any)?

Johnny can answer this too (and I'll let him cover the specifics about his own employment) but since I'm here:

Like Fedora, there is no formal legal structure around CentOS as a project. "A group of developers and stakeholders" is a reasonable description. Red Hat is the primary sponsor of both projects, and holds the trademarks and other intellectual property — and takes most legal responsibility and risk. Red Hat also funds engineering, hardware, and a community budget.

There is no dedicated CentOS team at Red Hat, just as there is no dedicated Fedora team. There are two highly-relevant teams, though. The first is Community Platform Engineering, which serves infrastructure and build tooling for both projects. Second is the Open Source Program Office, which has a team of community managers and leaders. (Rich Bowen and Marie Nordin fit in there.) Others are employeed other places — Ben Cotton, who serves as Program Manager for both Fedora and CentOS Stream — comes to us from the program management office.

There is no one at Red Hat whose individual job is "develop Fedora". Instead, like non-RH community members, lots of different people across Red Hat engineering have "maintain my package in Fedora" as part of their job, or "work on the Fedora Workstation as a whole". Those people are usually also responsible for something similar in RHEL.

This is true for RDO for OpenStack or OKD for OpenShift, too. And I'd have to check for sure but I assume it is also the case for AWX for Ansible.

So, CentOS Linux is something kind of an aberration, because RH was paying people in the CPE team to spend their time on package builds, even though they weren't building those packages for RHEL. That's the thing Red Hat wants to stop doing. With Stream, packages will be actually built by the engineers who are building them for RHEL. People working on CentOS Stream _project_ engineering will be more like the way CPE works for Fedora: on infrastructure and services around that.

As I understand it, this was something like 2-3 full-time equivalent positions just doing repackaging and associated work. I don't know the precise number. That might not seem like a lot, but if you've ever scrambled for req's for a project, you know it's a big deal. Red Hat's RHEL organization does not actually have a lot of extra fat to spare. But there is a lot of work that needs to be done to make the CentOS Stream infrastructure.

So, like I've said before, the given explanation of "we want to actually focus resources" makes total sense to me as an important driver. Instead of doing what is essentially duplicative work, people paid to work on CentOS specifically can act as catalysts, and the hundreds of people in the RHEL organization who previously didn't look at CentOS at all are now CentOS developers directly.

On Fri, Dec 18, 2020 at 11:29 AM Johnny Hughes johnny@centos.org wrote:

People who certify things, who certified CentOS Linux for things, are free to evaluate and do that with CentOS Stream as well.

This is what makes me think this isn't as bad as people made it out to be. (And yeah, I take full responsibility for being one of those 'people' LOL). For the community, there are two challenges. One is very easy to overcome and the other is an unknown. (Or perhaps it is a known, once we can get everyone to see from the same perspective.)

Suppose it is June of 2022 and I have been collecting and archiving all of the various versions of packages that are coming out for CentOS Stream. Then, maybe RHEL 8.7 is finalized and hits the mirrors. I can analyze the versions of packages that landed in RHEL 8.7. Then I can grab those versions from my archive and tag them "8.7". I could configure my repositories appropriately and build some ISO images. Of course, I couldn't call that "CentOS 8.7" because RedHat has prohibited that. But still I could release ISO's of "Enterprise Respin 8.7". That is the easy problem to overcome.

But there's still the question of long term support. Suppose it is 2027 and some major bug is found in OpenSSL. For RedHat customers, RedHat will build a package of OpenSSL for RHEL 8.10 that fixes the bug. I would guess that such an OpenSSL package would NOT be the same one that lands in whatever version of RHEL 9 drops in 2027, since the OpenSSL in RHEL 9 will be based on a later version of OpenSSL and have more features. Presumably that RHEL 8 version of OpenSSL would go through the CentOS Streams process. Theoretically I could pick up that version of the package and provide it as an update to "Enterprise Respin 8.10".

Except... how could that RHEL8 version of OpenSSL go through the CentOS Streams process? Based on what we've been told, at that time, "CentOS Streams" would really be "Whatever version of RHEL 9 drops in 2027 + 1". Or maybe it's even RHEL 10 by that point. So maybe long term updates won't go through the CentOS Streams process.

So the question for the community is how to account for that second issue.

--JK

On 12/18/20 9:20 PM, Joshua Kramer wrote:

Suppose it is June of 2022 and I have been collecting and archiving all of the various versions of packages that are coming out for CentOS Stream. Then, maybe RHEL 8.7 is finalized and hits the mirrors. I can analyze the versions of packages that landed in RHEL 8.7. Then I can grab those versions from my archive and tag them "8.7". I could configure my repositories appropriately and build some ISO images. Of course, I couldn't call that "CentOS 8.7" because RedHat has prohibited that. But still I could release ISO's of "Enterprise Respin 8.7". That is the easy problem to overcome.

Every package in CentOS stream will be signed with CentOS keys, and CentOS is now trademark of Red Hat. Are you sure it would be legal to publish/distribute CentOS-signed packages under any other name?

CentOS and other clones were legaly "safe" because they distributed their own binaries, but could bot use any RHEL's binaries...

On 18.12.2020 23:28, Johnny Hughes wrote:

On 12/17/20 7:54 PM, Konstantin Boyandin via CentOS wrote:

...

On 16.12.2020 22:50, Johnny Hughes wrote:

...

On 12/15/20 9:59 PM, Joshua Kramer wrote:

...

On Tue, Dec 15, 2020 at 7:41 PM Johnny Hughes johnny@centos.org

wrote:

...

...

...

...

$250K is not even close. That is one employee, when you also take

into

...

...

...

...

account unemployment insurance, HR, medical insurance etc. now

multiply

...

...

...

...

that by 8. Now, outfit those 8 employees to work from home .. all

over

...

...

...

...

the world, different countries, different laws.

I'm genuinely curious about something, and this is mostly academic since it's probably the subject of proprietary discussions within RedHat. Presumably, RedHat had a build pipeline for RHEL that worked well for them, by supplying alpha/beta releases of point releases to their customers and giving them time to "cook" before releasing those point releases into production. Why would RedHat invest millions more in buying the CentOS process just to have CentOS act as the beta?

Why did they change the development process of RHEL ..

Because they want to do the development in the community. The current process of RHEL development is closed .. they want it to be open. It is that simple.

I think Stream is also very usable as a distro. I think it will be just as usable as CentOS Linux is now.

It's usable, as Fedora is certainly usable - in its separate use cases. It's not bug-for-bug copy of current RHEL, so it's *not* as usable as CentOS Linux was.

...

It is not a beta .. I keep saying that. Before a .0 release (the main, or first, main reelase) is a beta. Point releases do not really need betas .. certainly not open to anyone other than customers. Now CentOS Stream is available all the time to everyone, customer or not. Once the full infrastructure is in place, everyone (not just RHEL customers) can provide feed back and bugs, do pull requests, etc.

Now please tell me whether Chris Wright was lying when saying the below to ZDNet:

"To be exact, CentOS Stream is an upstream development platform for ecosystem developers. It will be updated several times a day. This is not a production operating system. It's purely a developer's distro."

It's purely a developer's distro. Shall I explain difference between a developer's distro and the one suitable for production servers (a rhetoric question)?

Of course he wasn't lying. The purpose of ANY CentOS release from a Red Hat perspective, is as a developer release. Red Hat has never produced CentOS to be used in production for any reason.

Believe me, I don't care a penny about what Red Hat has in its perspective.

Fact: CentOS is and was successfully used in a variety of production servers (where RH, of course, would prefer to see RHEL). CentOS was stable and reliable. This is why I, among other sysadmins, was using it. It was stable and conservative, that's what I need.

It is ALSO completely free to use however YOU want to use it. As is CentOS Stream. If it meets your requirements, you can use it. Stream is no different.

People who certify things, who certified CentOS Linux for things, are free to evaluate and do that with CentOS Stream as well.

Is it ever going to be like it was before .. no. If that is a deal breaker for you, OK. Then you can't use CentOS any longer. Great, if you can't use it, then use something else.

All I can do is what I can do .. All you can do is what you can do. What is absolutely not helpful is continued complaining. A decision was made. It is implemented. CentOS Stream is CentOS Stream.

Who's complaining?

I am just displeased to see a corporation, which has no more use in CentOS, having decided to just kill it off.

As it was said many a time in the list, if the problem was in money, all RH would need to do was to ask. There would have been much response from both people and companies. No, RH just doesn't need it. CentOS Stream better supports its business model. Just a business decision, nothing personal.

I am sorry to see the community being split and displeased, that's all.

I will definitely use CentOS Stream, as development media (as I use Fedora), in case someone cares.

If you never want to use CentOS again .. great, don't use it. I can't make people use CentOS if they don't want to.

What I will do is what I have been doing for the last 17 years .. I will do the best job I can to make the things I can build for any version of CentOS Linux (or Stream) the best they can be. If people can use them, OK. If they can't OK.

I appreciate both your efforts and and efforts of whoever else supported CentOS all these years. It was a great work.

Personally, I advised to whoever I could to buy something from RH to support the cause, and supported CentOS in other possible ways I could. These 17 years were interesting ones.

I think this pretty much concludes the subject. My apologies if I did hurt your senses. CentOS is dead, long live CentOS, we're moving onward.

On 12/16/20 6:07 PM, Peter Eckel wrote:

Hi Johnny,

...

$250K is not even close. That is one employee, when you also take into account unemployment insurance, HR, medical insurance etc. now multiply that by 8. Now, outfit those 8 employees to work from home .. all over the world, different countries, different laws.

.. THEN buy 30 machines minimum (servers, not workstations) for building and testing, buy a service contract for those 30 machines, host the bandwidth required to sync out to 600 worldwide servers.

We need all the CI machines .. that is a bunch of blade servers for that. They need service contacts too.

I don't doubt your numbers, they sound perfectly reasonable to me.

On the other hand: How many of the employees will be laid off or reallocated now that CentOS point releases are no longer published? How many of the servers will be shut down, how many service contracts will be cancelled? What's your estimate of the reduction in bandwidth that will be saved by replacing point releases by a stream of releases with more frequent updates?

<snip>

CentOS Linux 7 will be fully supported until the scheduled EOL in 2024 and the current employees working on CentOS Linux will continue to work with the CPE team on CentOS Stream and other projects.

On 12/15/20 10:31 AM, Jon Pruente wrote:

On Tue, Dec 15, 2020 at 2:48 AM R C cjvijf@gmail.com wrote:

...

'Rocky Linux' guy might actually be on to something (although I'd pick another distro name)

The name comes from his CentOS co-founder Rocky McGaugh, who is no longer with us, in his memory.

I didn't know that fact, but hey that could be a pretty cool tribute.

---

CentOS mailing list CentOS@centos.org https://lists.centos.org/mailman/listinfo/centos

On Tue, Dec 15, 2020 at 9:18 AM Patrick Bégou < Patrick.Begou@legi.grenoble-inp.fr> wrote:

I'm also using CentOS for a while and I'm deploying a CentOS8 cluster for some months.... because it was supported until 2029! Bad idea. For me, using debian has 2 important drawbacks

• some of proprietary software we are using is certified RHEL and SLES.

Deploying on CentOS is out-of-thebox. Deploying on debian (we have also debian servers) is often a nightmare and some functionalities still doesn't work (and support reply "debian is not supported"). We have no alternative for these softwares. [...]

If you have to deal with proprietary software, OEL is currently the only cost-free option you have (if an RHEL clone is wanted). The advantage with OEL is that most proprietary software supports OEL out-of-the-box, you don't have to do "naming" tricks to run software like SAP.

Switching to OEL is quite easy (https://github.com/oracle/centos2ol) and the same method could be used to switch to something else if better options are available.

Kind regards Thomas

Am 17.12.20 um 17:38 schrieb Nicolas Kovacs:

Le 15/12/2020 à 10:09, Thomas Bendler a écrit :

...

If you have to deal with proprietary software, OEL is currently the only cost-free option you have (if an RHEL clone is wanted). The advantage with OEL is that most proprietary software supports OEL out-of-the-box, you don't have to do "naming" tricks to run software like SAP.

Switching to OEL is quite easy (https://github.com/oracle/centos2ol) and the same method could be used to switch to something else if better options are available.

+1 on that.

Oracle may be bad, but Oracle Linux is great.

Its great because it has RHEL inside (just joking in a storming weather) :-)

-- Leon

On Sat, 12 Dec 2020 at 23:55, edward via CentOS centos@centos.org wrote:

appears facebook is running centos stream and also helping developing

centos.

A small but important point of order on that statement, based on the article you link;

"an operating system they derive from CentOS Stream. "

So Stream is the starting point which Facebook then does "facebook things" to and forms their own in-house distro. They're not running Stream.

I'm most disappointed with the silence from Karanbir and friends. Obviously their Red Hat salary is more important to them than keeping CentOS the way it was. :-(

I'm sure they will speak out once they are in position to do so. That's obviously not now and nobody should blame them for it. They deserve better!

Simon

On 12/11/20 9:51 PM, Yves Bellefeuille wrote:

I'm most disappointed with the silence from Karanbir and friends. Obviously their Red Hat salary is more important to them than keeping CentOS the way it was. :-(

This boggles the mind.  OF COURSE their salary should realistically be more important to them than keeping CentOS the way it was; how strong of a disagreement with your employer is your salary worth?

However, reading between the lines, with Red Hat's internal developers directly working with CentOS Stream beginning 1Q 2021, and CentOS 7 ending support in 2024, I have to wonder a little what the long-term employment of those building CentOS looks like, specifically post-CentOS 7 EOL.  Of course, it's not really any of my business, to be honest, but the CentOS developers are all very bright and highly skilled, so they are very employable, whether at Red Hat or elsewhere.

Given what's already been posted to the lists, it seems to me that the CentOS Board was able to obtain some concessions; I will likely never know what those were, nor is it really any of my business what they were, but I thank the CentOS Board for doing what they could.

And I thank all those who have built and continue to build CentOS; I've had a relatively small exposure to what building and distributing packages is like, a few years back (well, 1999 to 2004), and user-entitlement-syndrome is part of the reason I won't do that any more (my wife's health was the primary reason I stopped, though; priorities are priorities!).