El impulso para salvar la arquitectura Itanium en Linux
Los desarrolladores del kernel de Linux están eliminando el soporte para la arquitectura Itanium (IA-64) de Intel, lo que ha provocado un debate sobre cuánto tiempo deben los proyectos de código abierto cargar con hardware legado. Quienes comentan señalan que la mayoría de los sistemas Itanium restantes ejecutan sistemas operativos propietarios como HP-UX o VMS, el interés de aficionados es mínimo y ninguna empresa está financiando el mantenimiento, por lo que depender de kernels antiguos u otros sistemas tipo Unix es más realista que mantener IA-64 en Linux principal. El hilo se convierte en una reflexión más amplia sobre los costes de la compatibilidad hacia atrás, el valor de la diversidad arquitectónica y la necesidad práctica de mantenedores y hardware de prueba.
¿Quién sigue usando Itanium y por qué?
- Muchos asumen que la demanda restante de Itanium está ligada a HP-UX y VMS, no a Linux.
- Ejemplos: bases de datos Oracle en hardware HP, clústeres VMS, COBOL personalizado en HP-UX, antiguos clústeres HPC y supercomputadoras que ejecutaban Linux.
- Varios comentarios sugieren que la producción activa de Linux sobre Itanium es ahora diminuta (<~1000 sistemas, y probablemente se está reduciendo rápido).
- Los ciclos de vida industriales y aeroespaciales son largos (por ejemplo, m68k en la aviónica del Eurofighter), pero Itanium no parece ocupar ese nicho en la práctica.
Interés retro / de aficionados
- El interés de aficionados por Itanium se describe como muy pequeño: el hardware es raro, caro, ruidoso, consume mucha energía y a menudo está vinculado a SAN e infraestructura de centros de datos.
- A algunas personas les gustaría tener máquinas Itanium “por diversión”, pero se lo compara con m68k, Amiga, SPARC, etc., que tienen comunidades más fuertes y buenos emuladores.
- La falta de un emulador de Itanium (como el soporte de QEMU para m68k) se ve como un factor que limita el mantenimiento comunitario.
¿Por qué eliminar IA-64 de Linux?
- El argumento central: no hay mantenedores ni probadores activos, muy pocos usuarios y un coste de complejidad significativo para el resto del kernel.
- Mantener arquitecturas exóticas puede impedir la refactorización y las mejoras de rendimiento, y requiere casos especiales para funciones poco usadas.
- Algunos ven los intentos de mantener IA-64 como una falacia del costo hundido. Otros argumentan que las arquitecturas exóticas ayudan a mantener el kernel portable y a detectar errores.
- La tendencia del consenso: si nadie da un paso al frente para mantener y probar, el código se elimina; formar parte del árbol principal no es un derecho adquirido.
“Solo usa un kernel antiguo” frente a soporte a largo plazo
- Muchos señalan que los usuarios pueden quedarse en kernels antiguos (por ejemplo, LTS 6.1) indefinidamente; esto ya es algo común en la industria.
- Preocupaciones: no hay retroportación sistemática de correcciones para arquitecturas muertas; no hay soporte para nuevos controladores ni cambios de infraestructura.
- Algunos temen que la eliminación agresiva de controladores o arquitecturas antiguas (por ejemplo, NICs QLogic) acelere la obsolescencia del hardware y socave la estabilidad a largo plazo.
Alternativas y contexto más amplio
- El puerto ia64 de NetBSD existe, pero parece inactivo.
- SPARC se cita como una arquitectura “exótica” todavía viable (hardware usado barato, sistemas Fujitsu en curso) que aporta diversidad.
- Se menciona RISC-V como una ISA que podría dominar en el futuro, aunque otros descartan la idea de “terminar” las guerras de ISA.
- Varios comentarios sitúan el fracaso de Itanium en su excesiva dependencia de los compiladores, el fin del escalado de Dennard y la competencia de x86-64.