Years ago I was told that I made a poor choice for using the "niche" Ubuntu Linux as our standard. I am feeling a bit better about that.
I think we are going to do a bit on this over the weekend. I am doing a lot to see how far I can push the video process to see if I can get more than 8 videos up this month which is sucking a lot of time.
I do appreciate hearing the thoughts on this. It is good to know I am not the only one who did not see this as a benefit to the community.
Yeah, but running RHEL/CentOS enterprise is kinda niche as well - at least in the shop I run.
I have meetings next week regarding this IBM "dick move"s, but let me give you an example of why having CentOS die might end up costing RHEL much more business than IBM thought....
a) With CentOS, you can't do release uplift the same way you can with Ubuntu (or Debian). So if CentOS 8 is only getting a 1 year lifespan that's pretty much a death sentence here. But then, should we even be running it?
At work, I try to steer the demo/professional services guys from asking for CentOS/RHEL VMs, unless whatever it needs to run is only supported/tested for a specific Linux distribution (a good example is Blackboard LMS or Oracle RDBMS (*ugh* the app that I really hate to support)).
Why? Lifecycle issues. Once you have a CentOS 5, machine, it stays a 5 machine for the entire lifecycle of the VM. It might get patches, it might get package updates, but if someone asks for, say, a newer version of httpd, or a specific PHP package with a feature add, well, you check the EPEL repo. If EPEL has it, good. If not, it's either a custom source build using rpmbuild, signed with my keys, or I tell them to go away. You can't change a repo and expect a CentOS 5 machine to be upgraded to CentOS 6 as easily as, say, do-release-update on Ubuntu Server OR switch repos to Debian, and apt-get dist-upgrade (as long as you pay attention to major release changes during the uplift process and plan for contingencies, you should be okay). To me, CentOS is a bit rigid. You stick with the same kernel/user-land family for the next 5 years, and you hope that the backports work and are stable.
b) With Debian delta repos and package holds, it's not that hard to get the same results as CentOS/RHEL and have a stable machine
The way I set up Debian/Ubuntu machines is that I run an apt-proxy and then setup delta repos to lock at a specific date, do package holds/pins, test specific machines up 3 months from the rest, if the repo changes doesn't do that much to break the machine functionality, I rsync the new repo files out, run a dist-upgrade and then bounce the VMs on a Friday afternoon. For my use case, incremental changes to a system applied steadily over time is better than constantly depending on an upstream vendor constantly hacking a 2-3 year old distro to stay somewhat relevant. Plus chances are, if the applications above the OS needs to be updated, then it will demand updates to its OS dependencies. This used to be not-a-thing when it came to installing Enterprise Java apps on JBoss or Websphere (where things don't really change that often)....but then, JVMs do change significantly nowadays, and patches happen.
c) Avoiding change management is a bit unrealistic sometimes.
Believe it or not, there are organizations who still have Windows Server 2003/2008 machines in production, and RHEL4/5/6 machines sitting in the backwaters somewhere performing one or 2 tasks. The issue is that the developers (and their managers) hate change (especially if it is drastic changes that forces machines down, and machines viewed as unimportant (like demo/repo/QA machines) are suddenly critical (oh no, I cannot do customer facing demos on this machine you built for us 4 years ago and left in a vacuum? I am taking this to your boss and demand that you don't touch it). My philosophy has always been to snapshot the filesystem, do the changes incrementally, reboot, ensure things come back to life, and rollback if I have to. All of a sudden a fleet of neglected Ubuntu 10/Debian 6 machines got tossed up to Ubuntu 16/Debian 9 and my life suddenly becomes easier. If I have CentOS machines that's a re-roll right off the bat, and there are hidden technical debts to pay off (why the hell did this piece of code use PHP5 AND x86 instead of PHP7 and x86_64? Oh, because this idiot dev chose the wrong docker container to write the code against...and etc). Sometimes thats doable, but often than not, I am already up to my eyeballs with powershell - Linux nonsense is the worst nonsense since it's usually easy nonsense to fix..provided that you have bandwidth to deal with it.
d) Paid support is often a nice-to-have, not essential, and if you "get" open source you can probably google your way around issues faster.
(Sometimes having friends that you can throw beer money at within vendors also help)
Okay, so I might have to call Oracle or Red Hat for issues regarding certain things, but sometimes those "things" might be self-perpetuating.
"Oh, some developer in your CentOS 7 environment needs Khmer support on PHP7 and we don't have a suitable package in your repo? Hold on, lemme assign you an engineer who can go to our repo environment and build you one.."
versus
"oh wait, there's a package on epel that fixes it? wget, rpm -i, bounce the app and fixed..."
or
"oh, I can just pull a slightly later version with easy dependency graphs via git, rpmbuild a custom, push it out of the company repo and push a yum update on the dev machines that needs it..."
or even better:
"Ha, we run Debian here - freaking thing can already do Khmer. Tell the dev to spin up a buster container, repull from git and repo against it instead"
I don't really have an absolute need or RHEL - CentOS was more like an easy gateway drug to get into the RHEL ecosystem, and if I need paid support for legal reasons (the repo machine that was built will now be used for customer facing purposes, we'll need to buy an RHEL license, change the repo to RHEL, do an in-place distro swap and then tighten things up as a production machine), I need it. I don't love or prefer it, but CentOS is the distro I go with if whatever I run on top is only supported in RHEL, and the installer scripts/packages assumes an RPM based environment with specific RHEL/CentOS underpinnings. Otherwise if it's something generic like PHP, I quietly put them on delta repo/pinned Debian (or Ubuntu, but I seriously prefer Debian) setup. If the argument is that IBM will simply force people to go to RHEL (so they can cash in), then I have less even less desire to use it. It's not even that hard to make RHEL oriented aps run on Debian based machines.