Durante años, una de las medallas de Linux ha sido poder arrancar en casi cualquier cosa: servidores modernos, portátiles viejos, placas raras y hardware que otros sistemas dejaron atrás hace décadas. Esa compatibilidad casi absurda ha sido parte de su encanto. Pero esa filosofía empieza a chocar con un problema nuevo: la avalancha de reportes generados por IA.
El caso más llamativo llega desde el kernel. El desarrollador Andrew Lunn ha propuesto eliminar varios drivers Ethernet antiguos, de la época ISA y PCMCIA, porque mantener ese código ya no compensa. No se trata solo de que sea hardware viejo, sino de que ahora herramientas automáticas, fuzzers y usuarios con IA están encontrando y enviando supuestos fallos que obligan a los mantenedores a perder tiempo revisando código que quizá no tenga usuarios reales.
Ahí está el punto delicado. Un driver viejo no molesta demasiado mientras nadie lo toca, pero en cuanto empieza a recibir avisos de fallos, reportes automáticos o parches dudosos, deja de ser una reliquia tranquila y se convierte en una carga. Alguien tiene que leer el aviso, comprobar si el fallo es real, decidir si merece la pena arreglarlo y, en algunos casos, tocar código para hardware que probablemente ya no está ni enchufado en ninguna máquina de uso diario.
La polémica está servida. Para unos, es una limpieza necesaria: si nadie mantiene esos drivers y casi nadie tiene ese hardware, mejor sacarlo del kernel y reducir superficie de mantenimiento. Menos código viejo también significa menos posibles errores, menos trabajo para los desarrolladores y un kernel algo más fácil de revisar.
Para otros, en cambio, es una pequeña traición a una de las grandes virtudes de Linux: conservar soporte durante años para máquinas que el mercado ya dio por muertas. No todo el mundo usa Linux en el último portátil con NVMe y 32 GB de RAM. También hay laboratorios, talleres, sistemas industriales, aficionados al retrohardware y equipos que siguen funcionando precisamente porque Linux aún los acepta.
Y el asunto va más allá de unos drivers antiguos. Linus Torvalds también se ha quejado recientemente de que los reportes de seguridad generados con IA están saturando la lista privada del kernel con duplicados y ruido. Es decir, la IA no solo amenaza con llenar internet de textos mediocres: también puede llenar los proyectos de software libre de trabajo inútil.
El problema de fondo no es que una IA encuentre fallos. Ojalá encontrara fallos reales, bien explicados y fáciles de reproducir. El problema es cuando produce reportes con apariencia técnica, pero sin contexto suficiente, repetidos o directamente irrelevantes. Para quien los envía puede parecer una contribución barata. Para quien mantiene el proyecto, es más ruido en una bandeja de entrada que ya estaba al límite.
La pregunta incómoda es esta: si mantener compatibilidad histórica empieza a ser demasiado caro por culpa del spam técnico automatizado, ¿seguirá Linux siendo “el sistema que revive hardware viejo” o acabará pareciéndose cada vez más al resto?
Quizá la respuesta no sea conservarlo todo para siempre, ni borrar a la primera todo lo que parezca antiguo. Pero el debate deja claro algo bastante incómodo: incluso en el software libre, el soporte no es gratis. Alguien paga ese coste en forma de tiempo, revisión, paciencia y mantenimiento. Y si la IA empieza a multiplicar el ruido, puede que los primeros en caer sean precisamente esos rincones viejos del kernel que durante años hicieron que Linux pareciera casi indestructible.
Fuentes
https://www.phoronix.com/news/Linux-Old-Network-AI
https://www.tomshardware.com/software/linux/linus-torvalds-says-ai-bug-reports-have-made-linux-security-mailing-list-almost-entirely-unmanageable
https://www.techradar.com/pro/security/almost-entirely-unmanageable-linus-torvalds-says-ai-bug-hunters-have-ruined-linux-security-mailing-list
https://www.tomshardware.com/software/linux/linux-may-be-ending-support-for-older-network-drivers-due-to-influx-of-false-ai-generated-bug-reports-maintenance-has-become-too-burdensome-for-old-largely-unused-systems
https://arxiv.org/abs/2605.07678

Deja una respuesta