One of the primary sources of confusion we have seen in the community revolves around phrases such as binary compatibility, bug-for-bug, full compatibility, and a wide array of other equally ambiguous jargon and how they apply to AlmaLinux now that it is no longer a 1:1 clone of RHEL. This post will concisely and clearly answer what that means for the average user.

A split image representing two concepts. On the left, a computer screen displaying a before and after view of a system update. The ‘before’ part shows a standard desktop, and the ‘after’ part shows the same desktop with minor visual changes, indicating a subtle update. On the right, two parallel paths in a landscape diverging slightly over time, symbolizing AlmaLinux and RHEL. The paths start together and gradually separate, but they remain close and parallel, illustrating their continued similarity despite slight divergence. The paths are surrounded by a calm and serene environment, emphasizing stability.

A Small Drift⌗

Think of your RHEL 8.9 system that hasn’t been updated for a month. When you execute dnf update, the system undergoes several changes. Software packages are updated, security patches are applied, and perhaps some new features are introduced. However, after this update, you still recognize your system. It works as expected, and the changes, though potentially significant, don’t alter your experience or the system’s fundamental nature.

Now, consider the relationship between AlmaLinux and RHEL. The differences between AlmaLinux 8.9 and RHEL 8.9 in five years will be significantly smaller and more subtle than the changes from running a dnf update in the previous example[1].

Divergence is a strong and scary word. Consider it a small drift away from upstream. AlmaLinux will always be a stable, secure, fully compatible drop-in replacement for RHEL.

[1] Excluding changes related to branding, such as the AlmaLinux logo and related artwork, verbiage, and other branding elements.