El cambio de Debian en CERN es una advertencia para toda la infraestructura crítica
CERN está migrando sus sistemas de control de aceleradores desde CentOS 7 hasta Debian 13. Esta decisión revela un patrón: mientras las distribuciones comerciales de Linux persiguen el nuevo hardware, la realidad de la infraestructura funciona con tecnología heredada. Aquí te explico por qué esto importa mucho más allá de la física de partículas.
El problema de hardware que nadie comenta
Cuando CERN anunció la semana pasada que está migrando sus sistemas de control de aceleradores de CentOS 7 a Debian 13, la historia que emergió no fue sobre preferencias ni política. Fue sobre un muro de silicio antiguo que se niega a morir.
La organización opera aproximadamente 2.200 computadoras industriales de placa única y placas madre personalizadas distribuidas en un sitio de 43 kilómetros cuadrados, cada una conectada directamente a unos 17.000 dispositivos de hardware que controlan los aceleradores de partículas. No se trata de servidores de centros de datos que se actualizan cada cinco años. Son controladores diseñados a medida integrados en sistemas que llevan años, a menudo décadas, en funcionamiento, y fueron concebidos alrededor de una pila de software sobre la cual CERN construyó toda su infraestructura: Linux compatible con Red Hat.
Red Hat cambió las reglas. La empresa ha ido endureciendo progresivamente sus requisitos de soporte para arquitecturas de CPU más nuevas, específicamente conjuntos de instrucciones x86-64-v2 y posteriores. Para la mayoría de las organizaciones esto significó actualizar servidores. Para CERN significó ya sea rediseñar el hardware personalizado detrás de 2.200 computadoras de control o encontrar un sistema operativo que funcionara con lo que ya tenían.
Su propia evaluación situó la tasa de éxito de forzar RHEL 9 hacia adelante en ese hardware heredado en aproximadamente un 20 %, incluso bajo supuestos optimistas. Eso los dejó con una opción binaria: reconstruir el hardware o cambiar el software. Optaron por Debian.
El anuncio se realizó durante una presentación en la MiniDebConf Winterthur del 29 de agosto, impartida por los ingenieros de CERN Federico Vaga y Nikos Tsipinakis, y fue posteriormente confirmada por el propio proyecto Debian. La migración está programada para el cuarto trimestre de 2026, cuando se espera que entre en funcionamiento el próximo ciclo de aceleradores.
Qué significa esto para una infraestructura que no puede detenerse
La historia más profunda aquí no es simplemente qué distribución de Linux eligió CERN. Es lo que la decisión revela sobre el estado del Linux empresarial y quién queda rezagado cuando las distribuciones comerciales avanzan más rápido de lo que el mundo físico puede seguirles el ritmo.
CentOS murió por cambio de política, no por falta de demanda. Cuando Red Hat se desplazó hacia CentOS Stream —un lanzamiento continuo que se sitúa por delante de RHEL en lugar de como una reconstrucción gratuita downstream—, creó un vacío de gobernanza para las organizaciones que necesitaban un sistema operativo estable, predecible y de costo cero para cargas de trabajo en producción. Scientific Linux llenó ese vacío para CERN durante muchos años. Cuando también alcanzó su fin de vida, CERN recurrió a CentOS Stream 9, luego 10 y 11. El hardware dijo que no.
Este es un patrón que se repite en toda infraestructura que no puede simplemente borrarse y reinstalarse. Hospitales con equipos médicos heredados. Fábricas que operan con PLCs personalizados. Redes energéticas controladas por equipo que data de antes de las herramientas nativas de la nube. Cada uno de estos dominios enfrenta la misma restricción: no se puede parchear en caliente un acelerador en funcionamiento, así como no se puede reiniciar un robot quirúrgico en medio de una operación o ciclar una subestación eléctrica por una actualización del kernel.
El modelo de lanzamiento de Debian —ciclos fijos, soporte a largo plazo y un ecosistema de socios externos que ofrecen soporte extendido de vida útil— se alineó con la necesidad de CERN de programar actualizaciones alrededor de paradas técnicas y ventanas de mantenimiento en lugar de al revés. Un modelo de lanzamiento continuo podría ofrecer paquetes más nuevos, pero no ofrece el tipo de previsibilidad que requieren las operaciones críticas.
La implicación no obvia
La mayoría de los comentarios sobre el panorama posterior a CentOS se han centrado en AlmaLinux y Rocky Linux como sucesores, y en cierto sentido lo son. Ambos continúan la tradición de ofrecer reconstrucciones compatibles con RHEL para organizaciones que desean el stack de Red Hat sin la licencia. Pero ninguno resuelve el problema de CERN. Si el problema subyacente son requisitos de arquitectura de CPU en lugar de licencias o disponibilidad de reconstrucciones, entonces las distribuciones sucesoras heredan la misma exclusión de hardware.
La ventaja de Debian en este escenario no es ideológica. Es arquitectónica. El proyecto mantiene soporte nativo para una gama más amplia de niveles de conjunto de instrucciones de CPU y familias de procesadores que cualquier distribución compatible con RHEL ofrece actualmente. Esto significa que los chips Xeon más antiguos, las variantes integradas de ARM y los diseños de placas personalizadas no quedan descartados del soporte en el momento en que llega una nueva generación. Es una característica que importa precisamente porque quienes lo despliegan no gestionan flotas de servidores completamente nuevos.
Esto crea un quieto realineamiento en cómo la infraestructura crítica debería pensar sobre Linux. La suposición de que la compatibilidad con RHEL es el camino predeterminado para despliegues críticos ya no es universalmente válida. Cuando tu hardware tiene requisitos que la distribución no cumple, la distribución gana. No hay solución alternativa que no implique reconstruir la capa física.
Qué viene después
CERN no trata esto como un simple intercambio de SO. La organización está usando la transición para rediseñar cómo sus computadoras frontend arrancan, cómo se distribuyen los componentes del SO y cómo los controladores de dispositivo se abstraen de cualquier distribución de Linux específica. El objetivo es evitar que la próxima migración sea desviada por el mismo tipo de dependencia del hardware.
Esa es una señal que vale la pena observar. Las organizaciones que han ligado su infraestructura al plan de hardware de una sola distribución deberían considerar si su propio equipo heredado enfrentará la misma restricción dentro de los próximos años. La pregunta ya no es qué distribución compatible con RHEL elegir. Es si la distribución elegirá tu hardware.
El reinicio de los aceleradores en 2026 será la primera prueba real de si el enfoque de CERN se sostiene bajo condiciones de producción. El resto del mundo de la infraestructura espera ver qué sucede cuando corre la prueba.