2 ms·

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

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.

KAMSPioneer 22d ago
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-almalinux-10-stable/ 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?
- m000 22d ago
  Nobody was ever fired for choosing Debian.
- winstonwinston 22d ago
  CERN wants x86-64-v1 binaries, not v2.
  - KAMSPioneer 22d ago
    Ah, you're right! Somehow I "autocorrected" that when reading TFA, now it makes more sense.
  - jasomill 21d ago
    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 https://gitlab.cern.ch/linuxsupport/rpms/koji-debian-plugin [2] https://lwn.net/SubscriberLink/1092512/0772b817c369632b/ https://lwn.net/SubscriberLink/1092512/0772b817c369632b/

KAMSPioneer 22d ago

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-almalinux-10-stable/ 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?

m000 22d ago
Nobody was ever fired for choosing Debian.
winstonwinston 22d ago
CERN wants x86-64-v1 binaries, not v2.
- KAMSPioneer 22d ago
  Ah, you're right! Somehow I "autocorrected" that when reading TFA, now it makes more sense.
- jasomill 21d ago
  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 https://gitlab.cern.ch/linuxsupport/rpms/koji-debian-plugin [2] https://lwn.net/SubscriberLink/1092512/0772b817c369632b/ https://lwn.net/SubscriberLink/1092512/0772b817c369632b/