You cannot reason people out of a position they did not reason themselves into. These people are not thinking logically and reacting to facts, they are reacting to what influencers in their sphere say and accepting that appeal to authority as fact.
> edit: after a little thought it seems that moving to RHEL might cost us the least amount of money and downtime. Still sucks and not what we need to be working on right now.
And that is exactly what IBM is counting on. Vendor lock in.
We are switching to Debian-based distros because, frankly, we don't trust IBM not to knife us in the back even on RHEL for more money. Of course we have the advantage of being able to take the time to convert.
This is not about IBM. It may not be a pleasant change for everyone, but it's a change that has strictly technical motives.
CentOS was acqui-hired because Red Hat's upstream for layered products (at the time mostly RDO/OpenStack and oVirt/RHEV) could not use Fedora because it was too far from RHEL a year of two after RHEL was released, could not use RHEL because upstream contributors would have to pay, and could not use CentOS because its releases had too large delays. The solution was to make CentOS releases happen timely by paying people to make them.
These days a RHEL downstream is not enough for the layered products. Some of them require the kind of bleeding edge feature that is backported every six months to the RHEL kernel, and corresponding userspace changes (BPF, virtualization, etc.) and cannot afford waiting for the CentOS release because development must be done in parallel with RHEL. So the solution was to move CentOS from happening after RHEL to before RHEL which is what CentOS Stream is.
I can confidently say that the reasons are technical because other CentOS downstream have the same needs (e.g. Facebook's) and they also want to send patches to CentOS for bugfixes or features themselves, instead of waiting for Red Hat to find out about that bug, or decide they need the same feature. Plus there's no reason for rebuilds to disappear. The SRPMs will still be released by Red Hat.
That in no way explains why they don't continue to have both. They indeed will have both for another year. There was no requirement the Stream product even use the CentOS name.
CentOS was a community project whose leadership and control was taken over (acqui-hired as you say) by Red Hat and then it's core use case for the majority of people actually using it was discontinued. That is a statement of facts that happened as I understand them, not some spin on my part.
If Red Hat had not stepped in, perhaps some of CentOS problems (trouble getting releases out on time) would have been worse, or perhaps some other companies would have stepped in. We don't know, but we do know that CentOS has not been changed to be something different than it was before. It used to be a free re-spin of RHEL. Going forward it's something entirely different.
Red Hat always had the option to stop funding/providing resources to CentOS and name their new thing something else, but they didn't, and now they've effectively co-opted CentOS to be something different than it was originally intended to be.
> That in no way explains why they don't continue to have both
Because they don't need it anymore. CentOS Linux or other rebuilds can still exist (just not using the name; I disagree with that but I can understand Red Hat doesn't want its name attached to something that might have large delays in security fixes in the future) if somebody funds it or volunteers to do it, just like CentOS still supports Xen but RHEL does not.
Also for what is worth there have been lots of engineering changes to RHEL in the past couple of years that make nightlies (and CentOS Stream) much more stable than they used to be, especially with respect to regressions. Running CentOS Stream is not going to be like Fedora Rawhide or Debian sid.
>>> it's a change that has strictly technical motives.
I understand the business reasons for doing so. I don't agree with anyone branding this as done for purely technical reasons. Having CentOS Stream may be needed for technical reasons. Stopping CentOS 8 is in no way a technical decision. They are unrelated in any technical sense.
If Red Hat just doesn't want to put resources towards CentOS as it traditionally existed anymore, that's their option, but they deserve any flak they get for taking over an open source project just to extinguish it, since CentOS is in no way really needs to be linked to their Stream product. They could just as easily called it RHEL Stream and said it's free, and it would be a less confusing and more direct funnel of people that want RHEL stability into RHEL subscriptions. Using the CentOS name is just a mind-share grab and screwing over an open source community. They control it so can do it, but that doesn't mean I'm not going to call them out for doing so.
The thing is, Red Hat never considered the distro more than a side effect of providing a base for developing "things" that will run on RHEL. It's even written on the centos.org home page, the distro is not why CentOS existed in 2020. So the fact that users (including myself!!) enjoyed a free distro as a result was not a part of Red Hat's RHEL strategy in any way.
That only makes sense if Red Hat started CentOS. They didn't. The fact that they took control of it then changed it, even the web page, and then are not effectively killed the reason people are using it, is the thing I'm upset about.
If I effectively took control of the EFF and then a couple years later changed the website copy to say that the EFF is a vehicle for litigating cases that kbenson thinks are important, and then actually changed its actions to do so, would you argue the same points? How is this any different? Something that was a net good for many people has been taken over and eventually killed. I think we're all worse off for that.
IBM is all about expensive support contracts. We cannot afford RHEL. So we went with CentOS 7 and recently CentOS 8. I migrated some machines from 7 to 8. Turns out I did that for one year. My boss wasted precious money there, and it isn't getting us closer to RHEL. My take is its getting us closer to Debian Stable instead. Which is RedHat's loss because a migration to RHEL is then more out of the picture. They know this. They thought of the above. And they are fine with it. That is not a technical decision, as you said. It is a business decision.
Fire up the wayback machine and find when the centos.org home page changed the mission statement. At this point it started to be about a different "us" than you think, an "us" that doesn't include you and me and presumably doesn't mind CentOS Stream at all.
In particular I started doing that and I got to the Sep 2019-Dec 2019 range, around the time CentOS Stream was launched. At that time this:
> For users, we offer a consistent manageable platform that suits a wide variety of deployments. For open source communities, we offer a solid, predictable base to build upon
was changed to this:
> CentOS Linux is a consistent, manageable platform that suits a wide variety of deployments. For some open source communities, it is a solid, predictable base to build upon.
Oh come now, this is Red Hat, a company based on Open Source software. We're not wrong for wanting to hold it to a higher standard. They have benefited from the OSS community just as they have contributed to it.
Red Hat didn't make CentOS they acquired it. This is very similar to a large corporation acquiring a smaller competitor, promising to continue supporting it, creating a new, different product using the brand, then dropping the original product.
Centos was always a free alternative to Redhat. I and many other people used it because it was a way to get the benefits of Redhat without paying for it.
This is a really smart more on their part to get people to stop doing precisely this, and getting them to pay money for RH. Pepople who are not willing to pay (me included) are now rightly annoyed, but we were never their customers in the first place, so we don't really matter.
I’m in the same situation, and I recently had started to plan on upgrading a small HPC cluster from CentOS 7. Before today, I had planned on CentOS 8.
Now? “¯\_(ツ)_/¯“ Probably Debian.
I’ve always used CentOS for clusters, but part of the reason for that is that there are some research packages that support RPM installation, but not deb. At least this gas historically been the case.
If a large amount (maybe even a majority) of users have to switch away from CentOS and RPM packaging, I think we’ll see an acceleration away from RPM as a default option.
So, in that way, I think we do matter, but just not on the balance sheet.
I disagree. Having a pool of sysadmins / developers who know how to manage CentOS makes RHEL a more appealing alternative than Debian for many companies. The three companies I've worked at have primary used CentOS for development boxes. Shifting to an alternative will change who is familiar with CentOS / RHEL significantly for the worse.
I'm not confused at all about that. I was responding to the point that said "it's a change that has strictly technical motives." It's a business decision that's based on profit and positioning and name mind-share, so let's not hide that.
> Puerto Rico is a US territory and not a state, so its residents don’t pay federal income tax unless they work for the US government. Even so, workers there pay the majority of federal taxes that Americans on the mainland pay — payroll taxes, social security taxes, business taxes, gift taxes, estate taxes and so on.
> Is this true? At my last company we wasted a bunch of time every week dealing with the accumulation of ad-hoc changes in different environments creating different behavior.
That is an issue a disciplined one-man operation won't have since (generally) they have a Dev and a Prod environment, the changes would be made in Dev first then duplicated in Prod.
If you have 2+ developers, you have environment drift like you experienced because (generally) Dev is the local environment on the laptop or otherwise a distinct environment for each developer. So now you have 3+ environments you need to sync and then discipline starts to fall apart as you have to communicate every change.
What happens to the disciplined single dev when their EC2 instance falls over in either environment? How do you get things back in sync without code to automatically stand things up in the right state? And if you're going through the work of writing/maintaining that code, are you saving anything over using Kubernetes (consider out of the box, Kubernetes gives you logging, ssh, process management, service discovery, etc)?
Not everyone uses EC2 which is prone to fall over.
And the disciplined single dev documents their changes. That is why it works in a 1 man shop but not at scale, there is always someone who is unreliable once the group gets large enough.
Its mostly in the form of advanced purchases of product and grants. No one is building new factories. This is more about distribution and R&D grants than it is about factories.
> In July, Pfizer got a $1.95 billion deal with the government’s Operation Warp Speed, the multiagency effort to rush a vaccine to market, to deliver 100 million doses of the vaccine. The arrangement is an advance-purchase agreement, meaning that the company won’t get paid until they deliver the vaccines. Pfizer did not accept federal funding to help develop or manufacture the vaccine, unlike front-runners Moderna and AstraZeneca.
> April 16: HHS made up to $483 million in support available for Moderna's candidate vaccine, which began Phase 1 trials on March 16 and received a fast-track designation from FDA. This agreement was expanded on July 26 to include an additional $472 million to support late-stage clinical development, including the expanded Phase 3 study of the company's mRNA vaccine, which began on July 27th.
> May 21: HHS announced up to $1.2 billion in support for AstraZeneca's candidate vaccine, developed in conjunction with the University of Oxford. The agreement is to make available at least 300 million doses of the vaccine for the United States, with the first doses delivered as early as October 2020, if the product successfully receives FDA EUA or licensure. AstraZeneca's large-scale Phase 3 clinical trial began on August 31, 2020.
> October 16: HHS and DoD announced agreements with CVS and Walgreens to provide and administer COVID-19 vaccines to residents of long-term care facilities (LTCF) nationwide with no out-of-pocket costs. Protecting especially vulnerable Americans has been a critical part of the Trump Administration's work to combat COVID-19, and LTCF residents may be part of the prioritized groups for initial COVID-19 vaccination efforts until there are enough doses available for every American who wishes to be vaccinated. The Pharmacy Partnership for Long-Term Care Program provides complete management of the COVID-19 vaccination process. This means LTCF residents and staff across the country will be able to safely and efficiently get vaccinated once vaccines are available and recommended for them, if they have not been previously vaccinated. It will also minimize the burden on LTCF sites and jurisdictional health departments of vaccine handling, administration, and fulfilling reporting requirements.
> November 12: HHS and DoD announced partnerships with large chain pharmacies and networks that represent independent pharmacies and regional chains. Through the partnership with pharmacy chains, this program covers approximately 60 percent of pharmacies throughout the 50 states, the District of Columbia, Puerto Rico, and the U.S. Virgin Islands. Through the partnerships with network administrators, independent pharmacies and regional chains will also be part of the federal pharmacy program, further increasing access to vaccine across the country—particularly in traditionally underserved areas.
I think many of us have the same feeling. I have a basic x86_64 home server that I keep dreaming of converting to a redundant cluster (x86_64 machines or rasberry pis, it probably doesn't matter).
