For sure, we needed a build infrastructure for RISC-V. I started out with five VisionFive 2's in my lab, and they're still doing work as needed. Granted, those are quite slow and painful because some builds will take a long, long time on those (for example, GCC took 7 days at the beginning, but we have it at about 5 days plus change now). Ever since we've added SiFive P550's to the mix, it has made it much faster for us to identify build issues and get them rectified. I still happen to use my VF2's for the "tiny" builds.
It's true that since we've had a usable build root since last 2024, it gives our AltArch group the opportunity to build different kernels to support other SBC's or boards like they already do for ARM SBC's (rasperry pi for example, since that support isn't native to the EL kernel). So while we support the VF2's and QEMU out of the box, that group will handle the additional kernels for more hardware support.
I'm actually looking forward to seeing what other boards the AltArch group will happen to add support for.
>One of the main value propositions of RHEL (and RHL before it) is that each distro version has a fixed ABI throughout (kernel included), making it a valid compilation target for binary-only software. Neither Stream nor even Alma are that.
Maybe for current point releases of RHEL and derivatives, building against CentOS Stream may not be that great of an idea. For example, EPEL has different build targets that build against RHEL or CentOS Stream to account for the differences between point releases such as libraries (especially qt libraries!) and also to make the transition easier for their users between point releases when running a dnf update on the next RHEL point release.
As a side tangent: In my opinion, I think vendors should be compiling software against CentOS Stream to ensure compatibility and validation for the next RHEL point release, which should work for the next point release of RHEL, Rocky Linux, AlmaLinux, and even Oracle Linux. I've not seen many vendors do this, though.
With that said, the differences that AlmaLinux have should not cause incompatibilities (and if there are, I can't see them being anything more than minor issues). This means that builds on an AlmaLinux build root should allow the software to still work on the others. Any of the distributions in the family should be fine as build targets.
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.)
CentOS was a binary/functionally compatible build of RHEL without the RHEL branding.
>IBM effectively cut off CentOS.
Red Hat (not IBM) made the decision to end CentOS Linux and move their focus toward CentOS Stream.
>Rocky Linux is the replacement free RHEL-compatible distro...
Rocky Linux is one of many choices for a RHEL-compatible distribution. I would also say CentOS Stream is also a viable choice. It works well from my own personal experience.
>but is higher effort to maintain than CentOS was.
Speaking as the lead of Release Engineering, it does require quite a bit of effort to maintain Rocky Linux. It can be especially time consuming during May and November when releases are scheduled, given that it's volunteer time.
As for CIQ, who knows what they offer or what it is they are actually doing with our distribution. Is it to check a box? Probably, given the way I've seen some companies act around these sorts of things. Does it offer security improvements? Who really even knows.
There's actually a (very silly) reason for not removing /etc/redhat-release. There's many applications out there that rely on that file's existence, even if it's just a symlink to the proper file. Some apps use this as a way to figure out "what kind of system" it is (e.g. is it a red hat like system?) or as a way to figure out what the system is and version it is running. It's a bit annoying, as sometimes these apps either read it or they don't, so it's inconsistent.
It gets even more weird when you consider /etc/os-release has better information (in my opinion) then the {redhat,system}-release file would ever provide. There's also the random situations where if redhat-release doesn't exist, an app may look for system-release and do some sort of parsing to figure it out (again, ignoring os-release) and may get it wrong.
That's part of why you'll find Oracle Linux, CentOS Stream, Fedora Linux, and even us with /etc/redhat-release existing as a symlink to our own. I find it to be the odd bandaid to something that shouldn't be a problem, but sometimes life just isn't straightforward.
It's true that since we've had a usable build root since last 2024, it gives our AltArch group the opportunity to build different kernels to support other SBC's or boards like they already do for ARM SBC's (rasperry pi for example, since that support isn't native to the EL kernel). So while we support the VF2's and QEMU out of the box, that group will handle the additional kernels for more hardware support.
I'm actually looking forward to seeing what other boards the AltArch group will happen to add support for.