RHEL is EOLing CPU architectures that CERN still relies on heavily.
RHEL 9 mandated x86-64-v2, requiring instruction sets like SSE4.2 and POPCNT, while RHEL 10 targets x86-64-v3. CERN's accelerator infrastructure manages more than 2,200 specialised front-end computers and 17,000 embedded devices, including legacy Core 2-era and custom industrial boards, engineered for 10- to 15-year lifecycles aligned with long-term accelerator shutdown windows. Upstream microarchitecture mandates threatened to abruptly obsolete thousands of functional, purpose-built control nodes.
And they are, in fact, planning to continue to use RHEL and/or AlmaLinux on their desktop and datacenter machines, even going so far as to adapt Fedora's build system to support building Debian packages[1] to leverage their existing RPM infrastructure.
As I understand it (from reading another article[2] posted on HN a few days ago), this change applies purely to the layer of machines that more or less directly interface with their experimental hardware, which has requirements more akin to industrial controllers than workstations or servers when it comes to the expectation of long service life with limited windows for scheduled maintenance.
Comments
RHEL is EOLing CPU architectures that CERN still relies on heavily.
Okay, but Alma rebuilds with x86-64-v2 as a separate ISO, and they even build EPEL packages with support for it: https://almalinux.org/blog/2025-06-26-epel-v2-now-covers-alm...
So the original commenter's questions stands IMO: why is Alma not considered a solution?
Nobody was ever fired for choosing Debian.
CERN wants x86-64-v1 binaries, not v2.
And they are, in fact, planning to continue to use RHEL and/or AlmaLinux on their desktop and datacenter machines, even going so far as to adapt Fedora's build system to support building Debian packages[1] to leverage their existing RPM infrastructure.
As I understand it (from reading another article[2] posted on HN a few days ago), this change applies purely to the layer of machines that more or less directly interface with their experimental hardware, which has requirements more akin to industrial controllers than workstations or servers when it comes to the expectation of long service life with limited windows for scheduled maintenance.
[1] https://gitlab.cern.ch/linuxsupport/rpms/koji-debian-plugin
[2] https://lwn.net/SubscriberLink/1092512/0772b817c369632b/
Ah, you're right! Somehow I "autocorrected" that when reading TFA, now it makes more sense.