A muchos nos ha pasado en casa: tenemos un dispositivo que sigue funcionando, cumple perfectamente con lo que le pedimos y, de pronto, el software empieza a dejarlo atrás. Puede ser ese iPod que ya no recibe nuevas actualizaciones o un ordenador todavía capaz que no cumple los requisitos para dar el salto a Windows 11. El hardware no se ha roto, pero su vida útil empieza a estar condicionada por lo que puede ejecutar. Es una situación bastante doméstica, hasta que llevamos el mismo problema a otra escala: la de los ordenadores que ayudan a mantener en marcha los aceleradores del CERN.
Lo que estaba en juego no eran los portátiles de los investigadores ni todos los servidores de la organización, sino una pieza mucho más específica del complejo de aceleradores. Hablamos de unos 2.200 Front-End Computers, entre ordenadores industriales y sistemas embebidos, utilizados para comunicarse con la electrónica que controla esas instalaciones. Los requisitos de procesador introducidos en las nuevas generaciones del ecosistema Red Hat amenazaban con dejar atrás una parte relevante de ese parque. El laboratorio debía decidir entonces si actuaba sobre máquinas y electrónica todavía funcionales o si resolvía el problema cambiando el camino del software.
Un problema de software con consecuencias físicas
Para entender dónde estaba el conflicto hay que mirar al procesador. La etiqueta x86-64 no describe una única colección inmutable de capacidades: existen niveles como x86-64-v2 y x86-64-v3 que añaden conjuntos de instrucciones que el software puede dar por disponibles. Red Hat Enterprise Linux 9, RHEL 9, pasó a exigir como mínimo el nivel v2 y RHEL 10 elevó el requisito al v3. Eso permite compilar el sistema pensando en CPUs más modernas, pero tiene una consecuencia directa: los procesadores anteriores que no incorporan esas instrucciones quedan fuera, aunque continúen funcionando sin problemas con el software que ya utilizan.
Cuando el CERN hizo números, la incompatibilidad dejó de parecer un problema marginal. En su análisis de riesgo de 2023 calculó que aproximadamente el 47% de aquel parque utilizaba procesadores situados en el nivel x86-64 original, por lo que quedaba por debajo del mínimo exigido por RHEL 9. Otro 17% estaba en x86-64-v2 y entraba en conflicto con el salto posterior de RHEL 10 a v3. No significa que el 64% tuviera que sustituirse inmediatamente, pero sí que, al seguir esas sucesivas generaciones del sistema, alrededor de dos tercios de la infraestructura acabarían chocando con el nuevo suelo de hardware.
Y aquí aparece otra diferencia importante con el ordenador que podemos tener en casa. Estos sistemas forman parte de una infraestructura distribuida por el complejo de aceleradores y están conectados a unos 17.000 dispositivos, entre electrónica de control y equipamiento especializado. El CERN habla además de alrededor de 70.000 cables y utiliza tanto hardware industrial como placas y controladores desarrollados para necesidades muy concretas. Sustituir una de esas máquinas puede implicar, por tanto, comprobar compatibilidades, modificar electrónica, reorganizar conexiones y volver a validar que todo el conjunto funciona como debe.
Cuando sus responsables calcularon cuánto costaría resolver el problema desde el hardware, la escala cambió por completo. El escenario que manejaban en 2023 rondaba los 5,4 millones de francos suizos, unos 5,7 millones de euros al cambio actual, y contemplaba el rediseño de unas 11 placas, seis incorporaciones especializadas entre ingenieros y técnicos, trabajos de reorganización y recableado de racks y una nueva puesta en servicio posterior. Aun así, la propia estimación interna calificaba como optimista una probabilidad de éxito del 20%, incluso suponiendo que el desarrollo de las nuevas soluciones saliera sin errores. Era mucho esfuerzo para corregir una incompatibilidad nacida en el software.
Debian no apareció de la nada. El CERN llevaba más de dos décadas trabajando dentro del ecosistema de Red Hat, primero con Scientific Linux y después con alternativas como AlmaLinux y CentOS Stream, una continuidad que facilitaba reutilizar herramientas, conocimiento e infraestructura. Aun así, sus responsables habían mantenido Debian como plan alternativo ante posibles cambios que comprometieran ciclos de vida tan largos. Cuando ese respaldo dejó de ser teórico, la decisión fue clara: trasladar estos sistemas de control a Debian 13. Los propios ingenieros lo resumieron con una frase: «Solución de software para un problema de software».
Cambiar de distribución, sin embargo, no equivalía a instalar Debian y dar el trabajo por terminado. El equipo se encontró con carencias en herramientas estándar para automatizar la construcción y publicación de paquetes, además de dificultades para mantener varias versiones de un mismo componente y gestionar determinados módulos binarios del kernel. Parte de la solución pasó por adaptar su propia infraestructura, incluida Koji, que ya utilizaba en otros entornos. La ventaja era clara: concentrar el esfuerzo en software y herramientas internas en lugar de intervenir físicamente sobre una red de sistemas industriales mucho más compleja.
La transición ya ha empezado. Cuando los responsables del proyecto presentaron sus planes a finales de agosto, explicaron que decenas de máquinas con Debian ya estaban funcionando en el complejo y fijaron como objetivo llevar los más de 2.200 ordenadores industriales y sistemas embebidos de este entorno a Debian 13 antes de terminar 2026. Esa versión contará con soporte LTS hasta 2030, con opciones para prolongarlo todavía más. Pero el cambio tiene unos límites muy claros: los centros de datos y la computación de los experimentos seguirán utilizando RHEL y AlmaLinux. El CERN no abandona Red Hat; ha decidido que, para esta parte concreta de sus aceleradores, prolongar la vida del hardware pasa por cambiar el software.
