I manage a "tiny company", but we have 10-ish production CentOS 7/8 servers and this sounds interesting. Although my web-app use case is probably fine with Stream, I don't know why everyone is assuming Stream will be completely broken and useless.
It probably wont be completely broken and useless, but they replaced a stable OS with a beta, which is particularly galling to many users who picked that OS specifically because it was so stable.
Just trying to see how you define "beta"
Slightly detached because of their processing/release process (Fedora X never quite matched to RHEL Y even if there was some derivation), but yes, Fedora is absolutely the alpha for RHEL. It gets changes, including breaking changes, on a fast track (IIRC, Fedora frequently goes toe-to-toe with Arch for having the most recent packages), has a 13-month lifecycle with a strong expectation that you'll `dnf system-upgrade` regularly, and doesn't shy away from pushing on tech that they believe to be desirable even if it's not (yet) widely used (Wayland, BTRFS, CGroupsV2).
> Did you consider RHEL to be a beta for CentOS previously?
Now that's an interesting point that actually makes me stop and consider:) It is true that previously CentOS could legitimately claim to be even more stable/slow-moving than RHEL. I think the distinction that I would make is that RHEL had its own betas that were called betas, and that each point release was frozen/stable until the next one came along, while Stream is explicitly unfrozen all the time. So yes, I suppose a person could have described RHEL as CentOS's beta, although probably only jokingly because it still had Red Hat supporting it and feature freezes to control changes.
The benefit of Fedora was that they handled a lot of things that were a pain to configure. The biggest culprit being fonts. But now that TrueType patents have expired, and it's included in Arch automatically it's one less reason to use Fedora.
The point is that with CentOS you expect a super stable release. Red Hat replaced that with what is clearly a less stable project. And as was said before, if you used CentOS, it's probably precisely because you want something super stable with long term support. Those are not the sorts of users who'll want to use Stream.
CentOS Stream seems like "Fedora, again" and does not do what CentOS did. And now, the willingness to blow up CentOS with so little warning means there is a massive trust deficit here.
More generally, orgs that are running "Enterprise" software are already set up to pay for software. Going from spending $X to spending $X+Y is often not a big deal ("Ok, I'll run that through the same process I used to get approval for buying FooSoftWorks"), while going from $0 to $Y can be very hard ("I don't even know who I'd need to ask to get purchase approval for that").
Except when $Y == $1000X. Then it really is a big deal.
When you only have a tiny minority of RHEL hosts that you have full support contracts on, and an overwhelming majority of CentOS hosts that you administer in-house, it really isn't trivial.
It's almost certainly cheaper to migrate to Oracle or Rocky. Migrations aren't cheap either.
Crucially, though, most entities who are running their own "enterprise" software deployments will need way more than 16 servers.
Small shops do use "enterprise" software, of course, but they usually just pay somebody else to run it for them.
Red Hat offers a "no support" server license for $350/year, which is the lowest licensing tier. Tiers with more capability and support are available for $800, and $1300.
https://www.redhat.com/en/store/red-hat-enterprise-linux-ser...
Oracle has a larger range of tiers. The "no support" license is $120/year. Tiers with more capability and support are available for $500, $1200, $1400, and $2300.
Oracle Linux can be used in production without a paid license of any kind; Red Hat Linux cannot be used in this way for large deployments (excepting the new 16-seat license for a developer account).
Red Hat is aggressive with software audits; I have seen one.
Both Oracle and Red Hat now have complete toolsets to convert support between an installed CentOS/RedHat/Oracle OS.
Red Hat can now convert an installed CentOS or Oracle Linux to RHEL; previously a wipe and reinstall was required ("have fun reinstalling your system" is still on Oracle's CentOS site). The description looks much more thorough in replacing all possible packages with Red Hat versions:
https://access.redhat.com/articles/2360841
Oracle does not replace CentOS or RedHat RPMs in their conversion (AFAIK), so it is much less violent on the platform changes.
https://github.com/oracle/centos2ol
https://linux.oracle.com/switch/centos/
https://blogs.oracle.com/linux/reasons-for-switching-centos-...
Apologies if a dumb question, but I assumed CentOS 8 was a clone of RHEL 8. What would change?
If memory serves, the process consists of, basically, installing the <distro>-release package for the "new" distro (which includes the files in the /etc/yum.repos.d/ (or whatever) directory that defines the package repositories), enabling the repositories it just added, disabling the "old" distribution's repositories, then running a "yum update" to replace the "old" distributions packages (including the kernel) with the (nearly identical) ones from the "new" distribution. After all that is done, you reboot the host so that the new kernel is loaded and that's pretty much it.
Mostly out of curiosity, I tried out Oracle's "centos2ol.sh" (or something like that) script ~8 years ago on a new CentOS 6 VM I had set up for just that purpose and it was as easy as they claim that it is. I don't recall encountering any issues and I suspect that, by now, they've ran into most of the potential issues and have devised ways to resolve them automatically.
Note that while CentOS 8 is a clone of RHEL 8, the CentOS packages are rebuilt versions of the RHEL ones. Most of them are built from the exact same source code but some packages do have minor changes made to them before they are rebuilt (for trademarks, etc.).
When switching the provider of package updates, the old repository must be disabled, and a new one substituted, among other changes that the new provider requires to switch support.
Oracle makes (by default) modest changes for such a switch. Red Hat essentially rewrites your whole operating system, and has added a warning that consultants should be retained for such conversions in case of trouble.