Your team has deployed on CentOS Linux for years and now has to choose a platform for the next five. Explain what CentOS Stream is in relation to Red Hat Enterprise Linux, and where AlmaLinux and Rocky Linux fit in that picture.

## The pipeline, and which way it flows Red Hat's distribution chain has three positions. Fedora is the fast-moving community distribution where new technology lands first. CentOS Stream is the midpoint. RHEL is the stabilised, supported product with a decade-long life. The single fact that trips people up is the direction of flow at the middle position. Until 2020, CentOS Linux sat *after* RHEL: Red Hat published sources, the CentOS project rebuilt them, and a CentOS 7.9 release appeared some time after RHEL 7.9 and was as close to identical as a rebuild can be. That made it the default "RHEL without the invoice" for an enormous number of shops. CentOS Stream sits *before* RHEL. It is continuously delivered and tracks the content that is heading into the next RHEL minor release. Packages appear there first, get exercised by the community, and then form the basis of the next minor. It is a legitimate and useful thing — it is where you test whether your software will survive RHEL 9.7 before RHEL 9.7 exists — but it is not a conservative platform, and treating it as a drop-in successor to CentOS Linux is the mistake the announcement caused. ## What actually happened, in sequence - **December 2020:** Red Hat announces CentOS Linux 8 will end at the close of 2021, years earlier than its published lifecycle, and that focus shifts to CentOS Stream. CentOS Linux 7 ran to its ordinary end of life in 2024. - **2021:** AlmaLinux and Rocky Linux launch to occupy the vacated downstream position, both targeting compatibility with the current RHEL majors. - **June 2023:** Red Hat stops publishing RHEL source packages to the public git.centos.org repository, pointing to CentOS Stream as the public source. Rebuilders adapt their sourcing. That last change is what caused the two rebuilds to diverge philosophically, and it is the part an interviewer is usually probing for. ## AlmaLinux versus Rocky Linux Both produce a distribution on which RHEL binaries and RHEL-targeted third-party packages run. They differ in what they promise: - **Rocky Linux** continues to aim at bug-for-bug identity with the corresponding RHEL release — the closest thing to the old CentOS Linux contract. - **AlmaLinux** has explicitly moved from "identical" to "ABI compatible": it guarantees that software built for RHEL runs, but reserves the freedom to differ. In practice it has shipped security fixes ahead of RHEL and has kept hardware support that RHEL dropped in a major release. Neither difference matters to a typical web application. It matters a great deal if you run a certified ISV product whose support statement names an exact platform, or if you must be able to say the running kernel is byte-identical to a vendor-supported one. Other options exist at the same layer — Oracle Linux is a long-standing RHEL-compatible rebuild, and an industry body was formed in 2023 to keep enterprise Linux sources publicly available — but Alma and Rocky are the two an interview expects you to name. ## Choosing for a five-year horizon Structure the decision rather than picking a favourite: 1. **Does anything on this fleet require vendor support or ISV certification?** Databases, SAP workloads, some storage and security agents will only be supported on genuine RHEL. Those hosts need subscriptions; there is no argument to have. 2. **Does anything require a validated cryptographic module or a certification artefact?** Certificates attach to Red Hat's own builds, not to a rebuild of them. 3. **Everything else** — build agents, internal services, ephemeral compute — can run a rebuild at no cost with the same operational habits, because the ABI and the packaging are the same. 4. **CentOS Stream** belongs in the pipeline as a forward-looking test platform: run your integration suite there and you find out about a breaking change one minor release early instead of on upgrade day. ## The migration angle Moving between these platforms in place is a solved problem in both directions: Red Hat ships `convert2rhel` to bring a compatible rebuild onto RHEL, and the rebuild projects ship their own conversion scripts to go the other way. That lowers the cost of being wrong, which is a reasonable argument for starting on a rebuild and converting the hosts that later turn out to need support — but it does not make the choice free, because the two halves of a split fleet need one automation codebase, not two.