“The enterprise Linux community requires standardization, stability, and consistency,” said Gregory Kurtzer, CEO of CIQ and Founder of Rocky Linux. “CIQ is bringing stability to our partners, customers, and community, by building a broad coalition of like-minded companies, organizations, and individuals. SUSE has embodied the core principles and spirit of open source; CIQ is thrilled to collaborate with SUSE on advancing an open enterprise Linux standard.”
From that quote, Rocky Linux appears to be onboard with SUSE concerning their fork of Red Hat.
Imagine that… A distro from the ashes of Red Hat, backed by SUSE Enterprise and Rocky Linux, combined.
OpenSUSE is ABI compatible with SUSE Enterprise. CentOS stream is ABI compatible with RHEL as well.
OpenSUSE source is freely available, … as well as CentOS stream source code.
OpenSUSE has a 5 years support cycle, as well as CentOS stream.
SUSE Enterprise is 10+ years support cycle, RHEL is 10. So, see if you can find the SUSE Enterprise specific source code, especially after the first 5 years, when OpenSUSE support already expired.
OpenSUSE doesn’t have 10 years lifecycle like SLES, so basically it’s lifecycle is circa 5 years give or take. OpenSUSE Leap 15 was 6 years, but the previous version(s) was 4 years.
We also need to clear up that Rocky is not CIQ and CIQ is not Rocky. Rocky and RESF are their own entities. CIQ sponsors Rocky, which isn’t the same as saying it is in control of Rocky. Which some people seem to think that is how it is.
The SUSE announcement is truly nonsensical. We already have CentOS stream, which is 1:1 binary compatible with RHEL. In fact, point releases in Stream are a bug, not a feature.
I suppose it’s a PR move. Talk about the pot calling the kettle black:
And SUSE doesn’t provide anything even close to CentOS Stream, or Fedora. And I’m not defending Red Hat here, however, the corporate posturing of Oracle and SUSE are obvious here.
Like, for example, how the heck will a SUSE funded RHEL fork be more RHEL compatible than CentOS Stream already is? Would SUSE be so kind and provide some technical details on how they’re planning to clone their competitor’s product, without actually cloning it? Oh, the pure nonsense of it…
I actually wanted to give an example to your comment. The example is the screenshot I posted. I can only imagine that SUSE would reply with righteous indignation if the community would call them out on their own SUSE Enterprise Linux source code BS. But throwing shade at a competitor? Not an issue for them, apparently. Oracle wants to be seen as a FOSS saint as well. My-oh-my, the world we live in.
The ones that are really hurting financially from this are corporations like Oracle, and companies that relied on community distributions in a production environment while getting vendor support for whatever software they’re running on top of EL. Rocky Linux and AlmaLinux will be fine, and so will the open source community. As for everyone else, there’s always Debian GNU/Linux. It’s rock solid, believe me.
i am not sure if the following could be consider good or bad idea
it’s about rocky create another project beside rocky that has an os that offer EL level of service i know if it even a good idea it will take while to be built and the business around it to be created and also get community and commercial adaption
The “update” concept of SuSE Leap is quite different. While the version number “only” changes in his minor place, its actually an “upgrade”. This is quite different to RHEL derivates update concept. Even when someone argues that Leap upgrades are fluent. There is a reason for the 6 month overlap between minor releases of SuSE Leap. So, the life cycle is actually shorter. Even Centos Stream would be more attractive in terms of lifecycle (5years, C8S ends ->2024, C9S, ends 2027)
I guess if we are looking at the point releases, then yes that would be correct. As you mention, it requires upgrading to move from 15.2 to 15.3 etc, unlike RHEL which automatically upgrades to the next point release when dnf update is ran. That said, RHEL does offer pinning, so technicaly I could pin to RHEL 8.7 and stay on this and it won’t update - just like OpenSUSE/SLES does by default.
If we look at when OpenSUSE 15 was released and when the last point release is, then the entire 15 version stretches over 5 years. The fact that each point release can be updated to the next does actually mean the entire lifecycle stretches to over 5 years just like SUSE write in the link I provided.
As an aside, looking at the graphs halfway down this page: Red Hat Enterprise Linux Life Cycle - Red Hat Customer Portal show RHEL having more or less six months for each of their point releases too (not counting extended support as that is an extra cost). The only thing not being done by default by RHEL is stopping upgrading to the next point release like SUSE does by default.
Regarding OpenSUSE Leap : their support cycle of 72 months is a myth. Leap is a moving target, with the odd breakage happening when upgrading from one “minor” release to the next. I’ve used it in production until 15.4, and since they let it die anyway - only to replace it by a containerized abomination in pre-alpha state - I’ve jumped ship.
