Update January 3rd, 2022: Please see: The State of Enterprise Linux in 2022
Change is hard. Explaining that change in a way that makes sense is hard. Not getting frustrated when someone is explaining change to you, or while explaining it is hard. We are all human, so please be patient. But, before you get angry, please read this. I’ve been surfing Twitter, Reddit, and HackerNews threads just like many others. I’ve gathered some major buckets of complaints which seem to come up, and I’d like to address each of them.
Before I start, full disclosure, I work at Red Hat and I’ve been here 9.5 years. I’ve never missed a paycheck. Never. Not one time. It’s always been there on payday. That makes me happy, but just because you work somewhere doesn’t mean you check your brain at the door. I am constantly questioning what we are doing, and coming to my own conclusions. A work relationship is like any other relationship, and it must be evaluated from time to time. Like any rational human being, I do this every now and then. I’m also known for saying my mind, even when the truth is difficult to hear. I think this makes me a decent diplomat for tough conversations. That said, these are my opinions and thoughts, not Red Hat’s.
Let’s have a tough conversation here. There are a lot of complaints and some optimism about the CentOS to CentOS Stream change. Let’s dissect each of what I consider legitimate complaints:
#1 This Was Communicated Poorly
As I said in the introduction, messaging is hard. We are all human, even the people at Red Hat. Do I think it’s possible that this could have been communicated better? Sure. That said, I’ve seen a lot of people tossing hate toward Rich Bowen (CentOS Project shifts focus to CentOS Stream) as well as Chris Wright (CentOS Stream: Building an innovative future for enterprise Linux) who wrote the two main pieces which communicated this change.
That’s not fair. These are both stand up guys. I mean seriously. I met Rich many moons ago because I had read and used his Apache docs. I went up to him and said thank you with nervousness. This guy believes in open source, more than most. He not only uses, he contributes. Big time. Same with Chris. I’ve never seen anyone who gets open source more than Chris. Seriously, when you listen to him speak you can discern how deeply he thinks about it. He is committed to it. If Red Hat ever changed their stance on open source, I am 100% sure that both of these guys would leave. There’s no conspiracy here, not with these guys. I know them both personally, and I believe in both of them. When these guys get up and say something, it’s true to the best of their knowledge at the given time. But, the world changes, and so do strategies.
Furthermore, this is a big change, and many people were involved, from both the community and from Red Hat. In fact, I’m writing this blog because I have a bias towards contribution and I believe it’s all of our responsibility to try to communicate this change effectively. Will Red Hat live and learn from this messaging? Yes, I believe so.
My only ask is, please extend some goodwill to Red Hat and see how this change goes. Give it a chance. I believe it will actually be better in the long run, and more sustainable.
#2 Things Changed, I Don’t Like Change
This brings me to the next most common gripe I hear. I get it it. Please try to separate your anger that is a direct result of unwanted change, from the other things discussed in this blog. Every time I’ve ever went through a re-org at work, changed roles, changed companies, bought a house, had a child or remodeled a room in my house, I’ve sort of had this “who moved my cheese” feeling. Everything was one way, now it’s another. Being annoyed by change is legitimate, but ask yourself what the benefits might be?
Already, some people have proposed some benefits to this change, and I agree. I’m going to summarize the benefits I’ve seen from three different sources  and add some of my own thoughts:
- It makes RHEL development more transparent and reliable  – historically, once a RHEL release snapped from Fedora it became a black box. Red Hat tries to solve this by creating Alpha and Beta releases which we share with customers and partners. We spend a tremendous amount of time/energy/money (as a PM I have to answer bunches of questions about Alpha/Beta), but literally almost nobody uses them. It’s expensive and painful. CentOS Stream will change this. Now any CentOS Stream user will have access to and be able to participate in this process. This is amazing.
- It provides a way for ISVs and developers to contribute fixes and features  – Even when partners and customers would use Betas/Alphas it was difficult for them to contribute changes back. None of the branches/repositories were public. Remember, the source code at git.centos.org is basically read only, downstream code from RHEL. That’s how Red Hat complies with the GPL. Technically we go above and beyond because we are only legally required to provide code to customers, and not required to provide code for BSD/Apache/etc licensed code, only attribution. Nonetheless, this was not a community, this was a code repository. The RHEL code was more akin to Android’s read-only, versus Kubernetes’ or the Linux kernel’s read-write community. With CentOS Stream, this all changes.
- It provides a way for the community to provide feedback  – Partners have special people dedicated to them called partner managers, and historically these partner managers help partners provide feedback and drive changes to the RHEL repositories. Community CentOS users (and even Fedora users) never had a way to drive changes into RHEL minor releases. Fedora drives changes into major releases, but there was a black box with minor releases. This gave RHEL the perception of being insulated from the upstream community, and it was. With CentOS Stream, this all becomes transparent. It’s a noble goal, and I genuinely believe this is better.
- Moving to a rolling stream is a consequence of moving to a cloud native world  – this was an interesting one and I hadn’t thought about this. This is a consequence of the world of containers. I always understood the value of containers to control when you absorb updates into your application dependencies, but it also means that a rolling stream of OS updates just doesn’t matter anymore. Now that containers control when the updates occur, why even care about whether it’s a rolling stream or released with version numbers. Do a “podman build” after the minor release drops in RHEL and don’t update again until the next dot release – boom, you have something quite similar to downstream CentOS Stream. A rolling stream lets us move faster and freer.
- Don’t underestimate the value of working directly with Red Hat engineering  – As Neal points out, CentOS was always a community driven project. Red Hat had extended it’s brand to the CentOS brand, and perhaps mistakenly given the perception that this was a well funded project when in fact it never was. Like every community driven project I have ever seen, there are more wants and desired than time and energy. Maintenance of community driven projects is not wholly unlike non-profits where a sort of depression permeates because it feels like you are never making enough progress, and worse you feel like you’re not being appreciated by the people who benefit from the charity. CentOS stream will be directly integrated with Red Hat engineering providing a direct line to RHEL. These are people paid to do this work, in service of making RHEL better. This aligns incentives and makes it much more sustainable, but more importantly, it creates a natural communication channel between Red Hat engineering and the community which frankly never existed. This will keep RHEL engineering more in touch with the realities of user needs, and provide the community a sense of connectedness. This is a very positive move.
- Don’t underestimate the power picking up a thousand new smart, highly motivated power users with a bias towards contribution, not consumption  – I haven’t seen anyone highlight this value yet. There are thousands of Solutions Architects, Consultants, Engineers, Product Managers, Product and Technical Marketing Managers, and Evangelists at Red Hat. None of them had an incentive to talk about CentOS much less contribute to it. I haven’t used CentOS in 9 years because I like getting a pay check. I was annoyed when customers wanted to talk to me about CentOS. I never contributed. I didn’t hate it, but I always viewed it as a wash – it garnered users of Red Hat technology, but these users very rarely contributed. I’ve never even seen a CentOS user file a RHEL issue (aka Bugzilla) or ping me on Twitter for CRI-O, Podman, Buildah, Skopeo, or anything else I work on at Red Hat. These users weren’t even on my radar. About a month ago, I installed CentOS Stream so that our team could collaborate with a customer on some Podman development. I didn’t have to feel dirty about pointing them to a downstream rebuild. With an upstream rebuild, the feedback is all directly useful to RHEL – feature requests, bugs, etc. This is powerful.
: Unpopular opinion: CentOS switching to Stream is not a bad thing at all by Kristian Köhntopp (@isotopp)
: My own thoughts.
#3 The Life Cycle Commitment Was Changed
The complaint is that the CentOS wiki originally said that CentOS 8 would be supported until 2029, and that this seems particularly egregious since CentOS 6 was recently deprecated. I totally understand being upset by this if you already had your heart set on using this, but think about why you’re upset? Let’s delve into this from an open source product management perspective. To the best of my knowledge, I am the first person to attempt to talk about open source in the context of creating and capturing value (Blogs/Presentations: The Delicate Art Of Product Management With Open Source) – two concepts that are quite common in the start-up world.
Let’s talk about this in the first principles of product management. Something free was meeting your needs (market problem). That solution was not lowering the development cost of RHEL (bottom dark red block), and it was also putting price pressure on Red Hat’s ability to capture some of the value that we create. This is a problem long term. Here’s a dirty secret with technology companies, it’s not about making money, it’s about out growing your competitors. Making steady money is fine for a gravel company, but it’s death for a technology company. You have to grow or die. Red Hat reported 69 quarters of consecutive growth before being folded into IBM’s earnings, and continues to grow within the Cloud Business Unit at IBM. This isn’t coincidence. This isn’t luck. We have to keep focusing on growth. We grow or die, just like any technology company.
Everyone knows that CentOS puts price pressure on RHEL. Let’s all look each other in the eye and discuss it. Many CentOS users speculate that that’s why Red Hat made this change, but let me explain how this isn’t a conspiracy. If successful, CentOS will lower the development cost of RHEL by spreading it across the community. With more eyeballs, all bugs are small. But, it will not remove the price pressure. That’s right, if CentOS Stream is successful, we will still have to compete with ourselves to make money. Why? Because CentOS Stream will likely be ridiculously stable just like CentOS was. That’s fine. That means that as a Product Manager on the RHEL team, I need to be laser focused on providing my customers with what they need. Every. Single. Day. I have to be focused on velocity of the value our team (Podman and container images) provides to RHEL and OpenShift customers.
Challenge accepted. I’ll still make sure RHEL provides value that CentOS Stream doesn’t. For me, it has nothing to do with hamstringing CentOS Stream and everything to do with focusing on creating value in the Buyer’s Problems boxes (light red, and pink boxes in above drawing)!
Could Red Hat have waited until CentOS 9 to make this life cycle change? Sure, I agree that would have ruffled less feathers, but we need these people in the CentOS Stream community. Proprietary engineering is a zero sum game, and the only way to change that is to do community driven development where the cost is socialized among the people who benefit (see also: Why Red Hat is investing in CRI-O and Podman). Any complaints about the stability of CentOS Stream absolutely positively must be looked at in the light of spending money stabilizing downstream CentOS. Without downstream to worry about, upstream will get better. The zero sum portion of the cost of engineering CentOS moves upstream, and becomes socialized. That effectively doubles the chance that CentOS Stream will be great.
#4 The Marks Are Owned By Red Hat
This is a touchy subject. One could make the argument that Red Hat should have never touched CentOS. Over beer, I could be convinced of this argument. I was in sales at the time that Red Hat acquired the CentOS trademarks. Some people hated it, some loved it. I always felt neutral about it. I felt like it was the best existing development platform for OpenStack, which was a problem at the time. The Red Hat contingent working on OpenStack needed something more stable than Fedora because they weren’t interested in doing Operating System development, they were interested in building a platform on top of the operating system. That was a tough problem to solve. Fedora wasn’t the answer because Fedora isn’t the upstream for RHEL minor releases (aka dot releases). I’m sure some people thought about releasing an upstream to RHEL, but it would have taken years and OpenStack was moving at the speed of light. So, Red Hat acquired CentOS.
Again, let’s all look each other in the eye and have a talk like grown ups about this. Once Red Hat touched the CentOS brand, it could never set it free again. There would always and forever be a perception that “Red Hat owns it” – this would forever benefit the CentOS brand and forever incur a cost for Red Hat. Before you slam your laptop shut in anger, let me explain.
First let’s talk about the value that Red Hat gave to the CentOS brand. Before Red Hat acquired the marks, and started paying the contributors, there were always worries that the project might fail one day. Remember in 2009 when Greg Davis disappeared for a while and people freaked out? Yeah, that’s what I’m talking about. There were many similar incidences where updates were slow, rebuilds of new versions took longer than expect, etc, etc. But, when Red Hat took over, all of those worries went away. That made a lot of Red Hat customers feel a lot less worried about running development, test, and even production workloads on CentOS for things they didn’t feel they needed support on.
There’s a big problem that almost nobody understand. The RHEL update stream has a huge value proposition, and most people assume the CentOS update stream is built by the same people, or at least people that can communicate with the people that build it. Let’s be honest. But, the updates in CentOS were never produced by the RHEL engineering team. In fact the packager on my team never, ever talked to the CentOS people, and the CentOS people never talked to him. There was no transfer of knowledge going on. The CentOS updates were produced by a few community members who rebuilt them. Doesn’t matter, the world perceived it as “updates from Red Hat” – I know it with all of my heart. That could never be undone. Never. If we let the marks go, some other people would fire up a rebuild and capture that value in the community. It’s fair that Red Hat didn’t want to give up that value capture.
Second, when Red Hat acquired the CentOS brand, we automatically incurred a cost – forever. Even if it’s just answering questions about how we gave CentOS back to the community and don’t patch it. I remember when I was a Solutions Architect and the CentOS acquisition occurred, there was an expectation from my customers that I would tell them about the value of CentOS. If you think about that, it’s completely insane. Why would a sales person come in and tell you about the value you can capture with a free project? It’s fine to capture the value, but asking Red Hat about it is a cost we incur. Forever and ever. We will always have to answer questions. This is a weird one, and to be honest, I don’t think anybody could foresee how expensive that is. If there’s a cost incurred, there needs to be value captured. With CentOS upstream it’s probably net-neutral from a value perspective. It will lower RHEL development costs, but incur sales costs. That’s better than a net loss.
I genuinely understand why this one makes people mad, but I also understand why Red Hat would have heartburn giving these back to the community. Open source is a tough business.
#5 CentOS Stream Support is Only 5 Years
This is an interesting one. It’s a fair critique, and to be honest, one I hadn’t internalized this when we made this announcement. Let’s be fair, this is basically identical to what Canonical does with Ubuntu LTS. You pay for the later year updates. This has a very good logic to it. If you are running something for that long, it’s probably a cost/benefit analysis and not some upstream development. That means you’re making money off of it. In the parlance of product management, we discuss these concepts as creating value and capturing value. What you might not realize is that whatever workload you are running on Downstream CentOS is creating value for your business, especially in years 6-10. Moreover, you’re likely charging for the service you run on downstream CentOS and capturing value. This is a leaky value chain that isn’t sustainable.
I mean, I’ll admit it, I’m a lazy sysadmin at heart and have had blogs, wikis, and ticket systems run for ten years before, so this isn’t 100% true. Not everyone running old-ass shit is making money, but you get the point. This is a key area of value capture for RHEL and it doesn’t feel wrong to me to charge money here. It feels fair. Neither Ubuntu nor SUSE Enterprise Linux have freely available, highly promoted downstream rebuilds which are supported for 10 years, built and paid for by the companies that sell the upstream products. This actually feels like madness right?
Tangential to the life cycle complaint, that Red Hat should have waited until RHEL 9 to make this change, I get why people are mad about having an expectation changed. That said, providing maintenance for CentOS Stream 8 until 2024 is still pretty damn good for $0. Also, remember, when you run something for $0, you take full and complete responsibility for it. With open source, you have the power to do whatever you want with it. You’re not trapped. That’s the power of open source, and also the responsibility.
This five year support debate is really about value creation and value capture – what should be given away for free, and what should be charged for. That’s strictly a business decision, even though I know it’s annoying. I’m not some hardcore Libertarian that likes to get on the “responsibility soap box” but I see the problem in the CentOS space and it’s even more egregious in the Linux container space. Companies are consuming container images for $0 without realizing they need to have the expertise to build/rebuild them if the upstream project ever disappears or decides go a different direction. One time, I talked to a partner that wanted to move to UBI, but they didn’t know how to move a bunch of their software because they just consumed container images from upstream without knowing how to rebuild them. They were selling this solution to their customers. Let that sink in. This is a serious problem in the cloud native world. You must ruthlessly track and gauge the risk you incur with by consuming upstream dependencies.
When you consume community open source software like CentOS, you become a product manager like me whether you realize it or not. I don’t mean to be insensitive, but consuming CentOS for $0 instead of buying RHEL means you are responsible for the life cycle even if somebody else was making your life easier by doing it for you. You are only in a bind if you are paying $0 and have no contributors.
#6 CentOS Stream Will Be Less Stable Than RHEL
There’s a perception that CentOS Stream will be less “stable” than downstream CentOS. This could be rephrased as, “this pisses me off because I always relied on paying RHEL users to absorb these changes, test them, and file bugs for me!” In reality, this move basically swaps who gets changes first, but the changes themselves were never “unstable.” Assuming these changes are unstable is essentially a conspiracy theory. Here’s why.
If Red Hat was upsetting RHEL users with a bunch of unstable live testing, how would Red Hat even have paying customers? The fact is, every dot release, RHEL users have been absorbing these same changes without a problem for years and years and years. How is this possible? Do you want the blue pill or the red pill?
The truth is Neo, with RHEL, there never really were dot releases. Not in the sense of traditional Unix numbering. RHEL has always been quite similar to a rolling release within a major version. With the launch of RHEL 8, we made this even more explicit with Always Ready RHEL It’s just that few people understand it. For years, we’ve encourage customers and partners not to park on dot releases. We always tell them that there is forward compatibility built into the architecture, but they never listen. I genuinely think this comes from how other software vendors have trained them. The stability of RHEL has always come from it’s architecture, and now that’s verified with tests and gating.
First, let’s start with the architecture. Many vendors don’t adhere to Semantic Versioning. RHEL does. If you don’t feel like reading that Semantic Versioning (SemVer) page, it’s the three digit version number that is so commonly used in software. It works like this. Given a version number MAJOR.MINOR.PATCH (ex Podman 2.0.5):
- MAJOR version when you make incompatible API changes
- MINOR version when you add functionality in a backwards compatible manner
- PATCH version when you make backwards compatible bug fixes
Software in RHEL falls into four levels of compatibility. If you’ve never heard about this, or don’t understand, check out: Red Hat Enterprise Linux 8: Application Compatibility Guide. All of the key pieces of software in RHEL like the kernel, glibc, openssl, are in compatibility level 1 or 2 which means they are binary compatible within a major release. Stated another way, changes to compatibility level 1 or 2 software are in the category of patches, not major or minor changes (there are some minor exceptions when a rebate doesn’t break compatibility). The main reason the RHEL dot release increments is because some of the higher level pieces of software in compatibility levels 3 and 4 can change. RHEL dot releases are nothing more than a bunch of patches bundled up on a certain day, ran through quality engineering (QE) testing, and tagged together.
This doesn’t change with CentOS Stream. It’s architecture must adhere to these API/ABI promises to front run RHEL.
How could it not? CentOS Stream wouldn’t be an upstream for RHEL dot releases if it deviated from these rules. The stability of RHEL starts with the architecture, application compatibility promises, and back porting.
Second, let’s talk about testing. You can’t test your way out of bad code (design, bad programmers, etc). RHEL starts with very high quality code and limits the variance of any change which can be accepted into the pipeline. Each change builds off of the last stable version. This is the foundation which makes RHEL stable. Even with this filter in place, each change then goes through rigorous testing and Quality Engineering (QE).
Humans do QE which improves stability and gives developers feedback, while automated testing verifies that regressions haven’t popped up in the code. Automated testing doesn’t necessarily make software more stable per se, it allows teams to move faster while retaining the same stability. Stated another way, gating tests are designed to catch things that have broken before. They prevent major flaws from re-entering a piece of software before it’s committed, but let’s also be fair about the limits of CI/CD.
CI/CD has never caught more than a small percentage of bugs with any software (even with 100% code coverage). The magic of automated test plans is that teams can move quicker, break things, and fix things while retaining quality. They can add new tests quickly so that teams don’t break the same things over and over again. Automated testing works because there’s an implicit assumption that things break at the weakest link. Testing verifies that those weakest links haven’t cracked again. None of this changes with CentOS Stream. Brendon Conoboy does a great job of explaining the multiple tests and QE that CentOS Stream goes through in this post: How RHEL is Made. CentOS Stream is essentially always ready RHEL. Stef Walter walks through the vision and the journey it took to get to this place with this blog: CentOS Stream is Continuous Delivery.
There’s argument being made is that CentOS Stream won’t be stable because it isn’t tested, or it’s “beta RHEL” which is just patently false. Don’t listen to Brendan, Stef or myself, who all work in the RHEL team, listen to a CentOS contributor named Carl George: “Yes, it is. In fact, large portions are tested twice. Everything released into CS8 has already been through RHEL8’s internal tests as well as the public t_functional test suite.” CentOS Stream is tested quite rigorously before it’s released to users.
Historically, if a bug made it past RHEL gating tests, it was automatically, and naively picked up by downstream CentOS. Today, if a bug makes it past CentOS Stream gating, it’s likely going to get automatically and naively picked up in RHEL. This effectively swaps RHEL and CentOS in the update stream. If RHEL users weren’t getting unstable changea before, there’s no reason to believe CentOS Stream users will get unstable changes now.
The RHEL team doesn’t want public Beta testers with CentOS Stream, we want community members that will help drive the next cool RHEL feature. The RHEL Alphas/Betas are/were rarely used, and were never the key ingredient to stability. The stability has always come from a combination of the architecture, high quality engineering (open source), back ports, ABI/API compatibility for level 1 and 2 software, and verification tests. Our competitors have never been able to achieve the same thing because they refuse to do the same level of work. Back porting is. Not. Fun. Let’s all be honest. But, it’s super convenient to consume. CentOS Stream users will still be able to run a yum update with little worry of pulling in breaking changes. The stability of CentOS Stream should be effectively the same as downstream CentOS for most users. This should be mostly a non-event. Your anger likely stems from not understanding this.
#7 You’re Not Looking For Opportunities to Improve This Ecosystem
RHEL and CentOS have become tied at the hip from an ecosystem perspective. This especially became true when Red Hat acquired CentOS, but you’re not looking for opportunities to improve this. Let me provide an example from my perspective.
The Container Tools team in the Red Hat engineering (Podman, Buildah, Skopeo, CRI-O, Red Hat Universal Base Image) releases our main application stream (container-tools:rhel8) about once every 12 weeks. We move faster than most subsystem teams in RHEL. Our upstream projects are still young tools and adding features very quickly. Our customers are dying to get the latest versions of Podman. Often, our customers are happy to get access to new versions of Podman even just a weeks earlier, especially when there is some killer feature they want. Historically, I had to point our RHEL customers to Fedora (which I love), but the configuration is often different than RHEL (ex. cgroups V2 on by default). Worse, our team doesn’t commit to Betas. Since we release every 12 weeks, the version on the Beta would already be old. This means, my customers had to wait until the RHEL dot release, which is painful.
Before the release of RHEL 8.3, I was able to share Podman 2.2.5 configured on a box that looked pretty much identical to RHEL (no cgroups V2, same registry config, etc) weeks before it dropped in RHEL 8.3. This gave us user feedback that will be used for our next 12 week release, as well as RHEL 8.4. Historically, we had to wait for feedback until RHEL 8.4 dropped. This was very painful because the upstream Podman team is moving so fast and the version on was never up to date. With CentOS, our problem is solved for both our team and our customers.
Furthermore, let me propose an idea. A place every project struggles, is with docs. I am constantly giving user stories to our documentation people, and they are constantly having to stack rank them, prioritize them and complete the pieces that they can. Imagine if we can move our containers guide (BUILDING, RUNNING, AND MANAGING CONTAINERS) upstream and have the CentOS Stream community contribute docs? That would be amazing and socialize the development cost for my team. This is a concrete example of the types of ideas that will come down the pipe if we all work together.
Look for the opportunity, not the challenges.
This change will be difficult for some, and I have empathy for that. Know that we are listening. I’m listening and available on Twitter @fatherlinux. I’m sure there’s still going to be a lot more anger, but hopefully this perspective helps people see the benefits, and perhaps better understand why these changes were made. Give it a year, and lets see how this things turn out. It’s really up to all of us to make this work. I want to leave you with a something funny, and something sad.
Let’s start with funny. Apparently, somebody spent the time to make this website: centos.rip. I’m not going to lie, I literally laughed out loud when I saw it. I mean, like really hard. I’m fine with people trolling Red Hat about this change. All is fair in love and open source. This is funny.
Now, let’s talk about something sad. There’s a change.org petition (Do not destroy CentOS by using it as a RHEL upstream), which I think is on the line because this is for things like wildlife being killed or rain forest being destroyed, but fine. I don’t have any heartburn with people being angry and expressing it, but I do have a problem with people comparing this change to the Charlie Hebdo Shooting. The Je Suis CentOS meme I’ve seen floating around is just disrespectful to the people that were murdered. It feels like people are just trying to find things to go viral.
Right now, children are getting blown up in Syria. If you’re in an emotional state where you feel the urge to make comparisons between a free software change and mass murder, please spend your energy and money on something that really helps the world. I urge you to donate to The Free Burma Rangers. They deliver food and water to people in need, even in war zones where normal NGOs won’t and can’t operate. This is a problem on the scale of Charlie Hebdo, or global warming, or the deforestation of The Amazon. Don’t make these comparisons lightly.
Finally, I’m not trying to dismiss your anger, but moving to CentOS Stream is literally three commands (How do I migrate my CentOS Linux 8 installation to CentOS Stream?). I understand that it’s annoying to have to migrate servers, even if moving is super easy, but put this in context. This CentOS change will cause you to do something that you might not want to do, but there are a lot of potential positives and I hope you will focus on that and try to help make it better.