i know.
That is still something that Red Hat can close down, even if it depends on a bunch of lawyers.
We already have to migrate from RHEL 7 due to it going EOL, and yes, the step to go to Debian 12 instead of RHEL 9 is a bit more work, but it is the better and future proof approach, compared to now going to RHEL 9 and in half a year or year, have to switch to Debian because RockyLinux was taken down. Staying in the RHEL ecosystem is too much of a risk for a company at the moment when the migration work needs to be done now, anyway.
this looks like a loophole that maybe probably can be closed if purple hat feels like it.
For me 1 week to rewrite the scripts and configs to work on the new system, at least that’s what I calculated in my head, not sure how long will it take to move to an unfamiliar system. Thought 1 week, because I’m doing it alone, but testing surely will take like 2 months, there are a lot of people who need to try it out.
After testing, it will be installed on one or two production servers for like 1.5 month to test it out with daily usage. That’s 4 months until it’s ready.
After that 3-4 months until I install it everywhere.
Working with snaps is a pain and some services only run on snaps for Linux. apt is not super intuitive to use either. In general the ubuntu-server image is mostly fine though.
In my personal experience, it takes me a few tries setting up things as simple as a LAMP stack even when my process is the same every time. The nice thing though is that once you get stuff working you can just sit back and forget about it for the most part. Even through updates and the like, it’s rock solid.
(again this is just my personal experience, you might get different takes from other people)
My opinion is similar but in my case it is mostly because I just don’t like apt/dpkg. Honestly, I find Debian just as annoying from a usage perspective.
The benefits for me are:
Almost everything has official support for Ubuntu LTS
It is easy to find instructions on how to do just about anything for Ubuntu
@mihalycsaba honestly I would go with Centos Stream or stick with your plans to move to Rocky Linux. Most of this is a storm in a teapot brought to you by the same people who said systemd was the end of the world. This article sums up why you would be better served by Centos Stream than you were likely served by Centos7 https://medium.com/@gordon.messmer/in-favor-of-centos-stream-e5a8a43bdcf8 . He makes a lot of sense.
That being said if you were running Centos7 with SELinux enforced none of the listed options are realistic. You will be facing a serious security shortfall for any of them. OpenSuse probably has the best SELinux support out of the options, but expect a lot of tinkering to get where you need to be.
Ubuntu fails in every respect for me with a bewildering array of competing technologies that get dropped from LTS to LTS and the mess Snaps create for diagnosing problems SMH…
Also yes I work in a Redhat shop but we have developers who use a wide array of distros…that they inevitably run into trouble with. You have many easy ways to mitigate the risk of running on CentosStream if for some reason you think it will not be rock solid. The easiest thing to do is to setup a server running either Nexus or Artifactory (licensing is very reasonable and Artifactory even has an opensource version). Point all your customers hosts at this host for updates. Have one rig pull in every package imaginable. This will place them all in the cache and then turn Nexus or Artifactory to offline mode. You now have control over when updates are available. Have another test host pulling updates directly from Centos Stream repos. If everything works fine you set weekly updates and reboots, where you bring Nexus or Artifactory back to online mode where it will reach out to the Centos Stream repos. Rinse and repeat. Is it perfect …no but it will get the job done.
Personally I would not bother and in the case of Centos Stream I would just drink directly from the firehose. Your production environment will still be plenty stable in pretty much every sense of the word. Any problems you do run into you will have more experience resolving quickly simply due to muscle memory from running Centos7 for almost ten years. Moving to any of the other ones will carry a lot of hidden costs.
I am not so sure if Red Hat can ever prevent this. The GPL grants their customers access to the source code AND the right to redistribute the source code.
“Our General Public Licenses are designed to make sure that you have the freedom to distribute copies of free software”
“You may copy and distribute verbatim copies of the Program’s source code as you receive it, in any medium, provided that you conspicuously and appropriately publish on each copy an appropriate copyright notice and disclaimer of warranty”
i don’t know if you realize this, but Red Hat is an US-American company and both RockyLinux and Almalinux are also based in the US. Meaning they can go to court for just about anything they want. And then it depends on whose wallets are empty first. IBM/RedHat or Rocky/AlmaLinux’s wallet. I wouldn’t bet on both wallets to hold up against IBM …
If your own company depends on the Server-OS being future proof, that’s a gamble you will try to omit completely, especially when you already have to put in a lot of work for migration now because your old OS is going EOL, not next year or the year after.
Only roughly 30% of RHEL is covered by the GPL the rest is a mix of MIT, apache, BSD, and possibly others. So yeah Redhat can do what they have done and frankly were probably right to do so. Hate siding with corpos being corpos, but in this instance their actions are well reasoned, and reasonable.
You can still build a Redhat clone from the final commits for a version in CentOS stream, however now as a rebuilder you will no longer be able to say it is an exact copy, and by inference gain the benefit of the ten year lifecycle. As a rebuilder you will be stuck at five year lts and if you want to go longer you will have to do the heavy lifting
it is. We looked into it and decided not to go that way. it basically is RHEL’s testing channel with stuff that will be included in the next RHEL release if it proves stable in Stream.
There, you can see that RHEL customers can use EUS to continue receiving security updates to system running (for example) RHEL 9.2 even after 9.3 has been released. That means that they can apply security patches to systems without updating to 9.3. None of the other systems that we’re discussing in this thread (Stream, Alma, or Rocky) have that option. And because none of them have that option, all three of those are effectively equally stable.
RHEL offers a greater level of stability than the other systems. And because Alma and Rocky offer a lesser level of stability, they don’t have any advantage over CentOS Stream for most purposes. They imitate RHEL’s minor release process without delivering is benefits. It’s a superficial imitation.
Conversely, CentOS Stream gets many bug fixes earlier than Alma and Rocky. By eliminating the superficial minor release process, CentOS Stream delivers a more reliable distribution."
From that reddit thread.
There is a RHEL Beta and that Beta is RHEL version# Beta. The only reason it is really available is for configuration management testing and final testing for the end user to test migration processes.
@nadb I understand you, if I would work for Red Hat, I also would want to sell my product or at least keep the customers close so that they maybe switch from Stream to the paid Red Hat. But that won’t happen because Red Hat simply is too expensive to have a chance against free options and the remaining free RHEL option’s future is way too uncertain to bet on them.
@mihalycsaba yet another reason to go to Debian: They offer a well tested upgrade path, so if we go that way, we don’t have to install our production servers from scratch with the major updates like we had to do in the past with CentOS 5 to 6 to 7 and would have to do now when going to anything RHEL-9.
