A finales de agosto, dos ingenieros del CERN presentaron cómo habían llegado a una decisión incómoda: seguir en el ecosistema de Red Hat, con el que llevaban años funcionando, les obligaba a cambiar hardware por millones. No porque el hardware se hubiera roto. Porque las versiones nuevas se compilaban pidiendo instrucciones de procesador que buena parte de sus máquinas no tenía.
Una de sus diapositivas se titula «Forcing Obsolescence With A Compiler Flag»: forzando la obsolescencia con una bandera de compilador.
Es un caso de laboratorio de física de partículas y, a primera vista, no tiene nada que ver con una empresa de veinte personas en Galicia. Tiene una cosa: el mecanismo. Y el mecanismo aparece igual cuando a alguien le dicen que su servidor «ya no da», que el ordenador de la caja «no admite la versión nueva» o que su web «hay que rehacerla».
Qué pasó exactamente
El complejo de aceleradores del CERN se controla con unos 2.200 ordenadores y unos 17.000 dispositivos instalados —y creciendo—, según los datos de la propia presentación. No son ordenadores de oficina: son máquinas industriales metidas en armarios, cableadas a equipos que están bajo tierra.
Ese parque venía funcionando con el ecosistema de Red Hat. En 2023 el equipo hizo un análisis de riesgo con una pregunta concreta: qué pasaría si se quedaban en él. La respuesta salió de dos números.
Red Hat Enterprise Linux 9 se compila exigiendo un nivel de instrucciones de procesador llamado x86-64-v2. La versión 10 sube el listón a x86-64-v3. Y en el parque del CERN, cerca del 47 % estaba por debajo del primer nivel —o sea, fuera ya de RHEL 9— y otro 17 % cumplía el primero pero no el segundo, con lo que se quedaba fuera de RHEL 10. La presentación da los dos porcentajes sin declarar sobre qué conjunto exacto están calculados; los publicamos como los publican ellos.
Son dos umbrales distintos y en dos momentos distintos, no una única frontera. Sumados, dejaban fuera a buena parte del equipamiento: sin haberse estropeado, sin haber perdido capacidad y haciendo exactamente lo mismo que el día anterior.
Lo que costaba arreglar eso por la vía del hardware está en la presentación, y conviene leerlo entero porque no es solo la factura:
- Presupuesto estimado: 5,4 millones de francos suizos.
- Alrededor de once placas que habría que rediseñar.
- Seis contrataciones: dos ingenieros de electrónica, dos de software y dos técnicos.
- Reorganizar y recablear armarios.
- Puesta en marcha: la mayoría de los sistemas se verían afectados.
- Fecha límite dura: el último trimestre de 2026.
- Y la línea que remata: probabilidad de éxito estimada, «un optimista 20 %», con su condición al lado —asumiendo soluciones libres de errores—.
Es decir, el camino caro era además el que probablemente no salía bien. Lo que escribieron al decidir empieza así: «solución de software para un problema de software». Cambiaron de distribución de Linux —a Debian— en lugar de cambiar de máquinas.
Tres precisiones, porque el titular fácil aquí engaña. La primera: no se ahorraron 5,4 millones. Esa cifra es el presupuesto estimado en 2023 para la alternativa que descartaron, no un gasto evitado que nadie haya contabilizado después. La segunda: el CERN no dejó de actualizar; actualizó, y lo hizo cambiando de proveedor de sistema operativo, que es una decisión mucho más grande que aplicar un parche. Y la tercera: tampoco venían de abandono. Su propia presentación enseña antes la cadena de versiones que habían ido siguiendo durante años, y el susto que ya se habían llevado cuando CentOS terminó su soporte antes de lo previsto.
El mecanismo, sin aceleradores de partículas
Quítale los 17.000 dispositivos y queda esto: cuando algo deja de servirte porque el software que quieres seguir usando le ha subido el mínimo, la fecha de caducidad no la ha decidido tu equipo. La ha decidido ese requisito.
Es una diferencia que importa porque cambia a quién hay que preguntar. Cuando algo deja de funcionar por desgaste, la conversación es con quien vende máquinas. Cuando deja de funcionar porque le han subido el mínimo, la conversación es sobre software: qué versión pide, quién decidió pedirla, y si hay otra forma de seguir al día que no pase por comprar.
En una pyme el mismo mecanismo aparece por tres sitios, y ninguno tiene aspecto de noticia:
En el servidor donde vive tu web. La versión de PHP, la de la base de datos, la del sistema operativo. Cada capa tiene su propio calendario de soporte, y el software que corre encima va subiendo lo que pide.
En el gestor y en lo que tu web lleva montado. Un framework o una librería saltan de versión mayor, y a veces esa versión trae requisitos nuevos: una versión mínima de lenguaje, de base de datos o de sistema.
En el equipamiento de la tienda o del taller. El TPV, el ordenador que mueve el programa de gestión, la máquina conectada a un lector. El programa nuevo pide un sistema operativo que ese aparato ya no admite, y la factura llega como «hay que renovar el equipo».
En los tres casos, la primera pregunta es la misma: qué ha cambiado, mi máquina o el requisito.
Lo que el CERN sí tenía, y no era suerte
Conviene no sacar del caso la moraleja fácil. Actualizar con más frecuencia no habría hecho que sus procesadores cumplieran el requisito nuevo: ese lo fija Red Hat al compilar, y no está en manos de quien lo usa.
Lo que sí hicieron, y su presentación lo enumera, fue cuatro cosas, todas antes de que hicieran falta:
- El análisis de riesgo, en el segundo trimestre de 2023.
- Escribieron que no podían permitirse más sorpresas, y de ahí salieron dos decisiones: que su propia capa de integración no dependiera de ninguna distribución concreta, y seleccionar y preparar un sistema operativo de plan B —Debian— antes de necesitarlo.
- Eligieron qué versión adoptar mirando el calendario de paradas de sus aceleradores, para no tener que tocar un sistema en marcha.
- Y patrocinan a Freexian, para reforzar la comunidad de Debian y asegurar su continuidad.
Nada de eso se improvisa.
Ya hemos contado por otro lado qué pasa cuando el reloj lo pone otro, con la seguridad en vez de con la obsolescencia: en el caso que analizamos, los primeros sondeos llegaron unos diez minutos después de publicarse el arreglo de un fallo, y le llegaron al servidor de quien había publicado esa corrección. Lo que depende de ti no es cuándo se publica el arreglo: es cuánto tardas en tenerlo puesto.
Las preguntas que te sirven mañana
Si alguien te dice que hay que renovar algo, estas cuatro cambian la conversación. Valen tanto si tu web la llevamos nosotros como si la lleva otro:
- ¿Qué ha cambiado: mi máquina o el requisito? Si la respuesta es que el software nuevo pide más, no es una avería: es una decisión de un tercero, y conviene preguntar qué alternativas hay antes de aceptar la primera.
- ¿Qué versiones estoy corriendo hoy y cuándo termina su soporte? Con fechas. Es una lista corta —sistema operativo, lenguaje, base de datos, framework— y quien lleva tu web debería poder dártela.
- ¿Cuánto falta para la primera de esas fechas? Ese es tu margen, y es el número que decide si vas a poder comparar caminos o solo aceptar el que quede.
- ¿Qué se actualiza de forma periódica, con qué frecuencia, y qué queda fuera? «Se mantiene» no es una respuesta. «Frameworks y librerías, cada mes» sí lo es.
La segunda conviene pedirla por escrito: es una lista que hay que poder releer dentro de un año.
Cómo lo tenemos montado nosotros
En los planes de mantenimiento de Galianet Webs hay dos líneas publicadas en la página de planes: actualizaciones de sistema operativo y actualización mensual de frameworks y librerías, incluidas en los tres planes —Básico, Profesional y Empresarial—, no solo en los de arriba.
Eso es lo que dice la página y es todo lo que decimos aquí: son actualizaciones incluidas. Vigilar fechas de fin de soporte, avisarte de ellas o mantener una lista al día de versiones y vencimientos son cosas distintas, y ninguna la tenemos publicada como parte de ningún plan.
Con una condición que decimos siempre y que aquí toca repetir: nuestros planes de mantenimiento cubren las soluciones que hemos desarrollado nosotros, no cualquier web. Si la tuya la hizo otro proveedor, lo que te sirve de este artículo son las cuatro preguntas de arriba, y es a quien te la lleva a quien hay que hacérselas.
Por dónde empezar esta semana
Pide la lista de la pregunta 2 —versiones y fechas de fin de soporte— a quien lleve tu web o tu programa de gestión. Sin pedir presupuestos y sin decidir nada: solo para saber cuánto margen tienes.
Y si estás pensando en un desarrollo nuevo, hay algo que preguntar antes de firmar: qué se actualiza, cada cuánto, y qué pasa el día que una versión mayor cambie los requisitos. Es una pregunta sobre los años que ese software va a durarte, y no es de las que contesta una lista de funcionalidades.
¿Estás pensando en un desarrollo a medida, o quieres que le echemos un ojo a uno que ya hicimos para ti? Cuéntanos qué necesitas.
Fuentes
- «El CERN tenía dos opciones: cambiar de sistema operativo o reemplazar más de mil ordenadores. Eligió la vía más lógica», Xataka, 7 de septiembre de 2026. xataka.com
Los datos citados —el parque de máquinas, los porcentajes por nivel de instrucciones, el presupuesto estimado, la probabilidad de éxito y las decisiones de preparación— están tomados de la presentación original: «Controlling CERN's Accelerators with Debian», de Federico Vaga y Nikos Tsipinakis, 30 de agosto de 2026.
