Greg kurtzer is not the founder of CentOS. This is FUD he's been regurgitating ever since tricking one of the past CentOS community managers into doing a blog post.
If you read the mailing list archives you'll see the truth.
Why do you always take every opportunity you can to try and discredit me on this? Anytime someone mentions me, boom, there you are, in every social media, everywhere, being the first to try to discredit to me. As a spokesperson for a competing project, I'd expect a higher level of decency than spreading FUD like this.
I'd be happy to discuss and debate this with you, but you weren't actually there. I tell you what, go find someone else who was actually there at that time, and I'd be happy to discuss it with them publicly.
This change: https://almalinux.org/blog/future-of-almalinux/ means that Alma is no longer covered by STIGs and other RHEL-specific certifications. Rocky is usually permitted to piggyback on such things. This has directly affected deployments (my team spent time migrating from one o the other as a direct consequence). Compatible, sure, but that is a narrow view of the value CentOS provided.
I cannot speak for AlmaLinux, but it's incorrect to say they're not compatible. They are most definitely still compatible with the upstream distributions. Yes, they have made some changes that make them quite different from the upstreams, but this was their choice and it works for their community and their overall goals. I personally don't see any issues with what they've chosen to do, but that's my extremely narrow view as all clients I work for only use RHEL or Ubuntu.
In regards to STIG, this makes me think of the "scap-security-guide" package that helps the openscap package run tests for compliance like PCI-DSS and HIPPA (among other things). While it is true that we mark ourselves as a "derivative" of RHEL in that package, it doesn't mean we have any certifications or the like and we certainly do not claim to have such certifications. The only thing we actually have officially is a CIS benchmark set at cisecurity.org.
AlmaLinux on the other hand appears to be upstreaming themselves into the content itself, which I think is pretty cool (https://github.com/ComplianceAsCode/content/tree/master/prod...). I've always wanted to see Rocky Linux do the same thing for the past few years, but I don't know what it would take. I've asked our security team some weeks back to look into what has to be done, so maybe something will happen. I just know it will take a long, long time to get things figured out either way. (As much as I'd like to look into it myself and work with the security team, I just don't have the time in between my personal life, day job, and the project.)
STIGs are not inherited. It absolutely does not work that way.
I think you're reading into the changes completely wrong. AlmaLinux has power to actually do things, fix issues, contribute real and meaningful changes, all while maintaining 100% compatibility. A lot has been done already, with plenty more to come, with 0 compatibility issues.
Bug for bug is a sham and always was. It's a disservice to users to only clone something.
Underneath it all, compatibility is what matters. At AlmaLinux we still target RHEL minor versions and will continue to do so. We're a clone in the sense of full compatibility but a derivative in the sense that we can do some extra things now. This is far, far better for users and also let's us actually contribute upstream and have more of a mutually beneficial relationship with RH versus just taking.
Sometimes the hardware or the software you run requires exact versions of the packages with some specific behavior to work correctly. These include drivers' parts on both kernel and userland, some specific application which requires a very specific version of a library, so on and so forth.
I for one, can use Alma for 99% of the time instead of the old CentOS, but it's not always possible, if you're running cutting edge datacenter hardware. And when you run that hardware as a research center, this small distinction cuts a lot deeper.
Otherwise, taking the LEAPP and migrating to Alma or Rocky for that matter is a no-brainer for an experienced groups of admins. But, when computer says no, there's no arguing in that.
If you're running cutting edge datacenter hardware, CentOS is a better fit now than it ever has been before. It will be the first to get support for new hardware within a major version, ahead of RHEL and all it's derivatives. It is possible that some hardware doesn't get support within the current major version of any of these related distros, and you'll have to wait until the next major version, which CentOS also does first before the rest.
We don't change the expected versions. We might patch/backport more to them if there are issues, but the versions remain.
Basically the goal is still to fit the exact situation you just brought up. I'm not aware of this ever not being the case if it weren't to be the case for some reason, then we have a problem we need to fix.
All of the extra stuff we do, patch, etc. is with exactly what you just stated in mind.
I'll be installing a set of small servers in the near future. I'll be retrying Alma in a couple of them, to give it another chance.
As I said, in some cases Rocky is a better CentOS replacement than Alma is.
But to be crystal clear, I do not discount Alma as a distribution or belittle the effort behind it. Derivative, clone or from scratch, keeping a distro alive is a tremendous amount of work. I did it, and know it.
It's just me selecting the tools depending on a suitability score, and pragmatism. Not beef, not fanaticism, nothing in that vein.
Sustainability is one of the core reasons why we are not using RHEL SRPMs to build AlmaLinux. RH doesn't want us doing that, and doing so would be unsustainable and bring into question the future of AlmaLinux as it can, and likely will, turn into a game of cat/mouse getting those SRPMs :)
Red Hat Enterprise Linux excludes btrfs support in its distribution because Red Hat does not believe btrfs to be stable enough to be worth considering. That decision trickles down to recompilation projects that pretty much amount to "RHEL, but without having to pay for it".
And rightfully so, imo. btrfs is the only filesystem I've used where it's gotten so corrupted due to faulty memory on a computer that I had to recover the files and reinstall from scratch after replacing the memory (obviously not using btrfs the second time ..).
AlmaLinux is a perfect replacement for scientific agencies. It's got the fastest turnaround time for security patches, an open community, and sustainable funding sources.
https://github.com/AlmaLinux/ALESCo/pulls?q=is%3Apr+is%3Aclo...