Llevo años administrando servidores Ubuntu —de hecho, esta misma bitácora corre sobre uno— y cuando Canonical anunció en 2025 que iba a «oxidizar» la distro, es decir, reemplazar las herramientas de siempre por versiones escritas en Rust, me tomó con escepticismo. No porque no crea en Rust, sino porque el coreutils de GNU tiene décadas de estabilidad y cualquier desviación se paga caro en producción. Esta semana se confirmó que Ubuntu 26.10 «Stonking Stingray» completa la migración a coreutils en Rust, y creo que vale la pena mirar de cerca cómo lo hicieron, porque es un caso de estudio de cómo se deberÃa hacer este tipo de transiciones.
La historia del camino con tropiezos
Ubuntu 25.10 fue la primera versión en venir con utilidades basadas en Rust (uutils) y con un sudo también reescrito en Rust. Pero en 26.04 LTS tuvieron que dar marcha atrás parcial: cp, mv y rm —o sea, tres de los comandos más peligrosos que existen— se quedaron en sus versiones GNU porque una auditorÃa de seguridad les encontró problemas TOCTOU (time-of-check to time-of-use) a las versiones nuevas. Traducción: la verificación y el uso del recurso no eran atómicos, y en ese hueco se pueden colar condiciones de carrera. En comandos que borran y mueven archivos, eso no es una wea menor.
Lo notable es lo que vino después. Canonical no escondió el problema ni presionó para igual migrar: esperó que se corrigiera upstream y recién ahora, en 26.10, completa el set. La distro viene con el paquete completo de utilidades Rust: ls, cat, chmod, du, y la lista completa.
Por qué me parece importante (y no solo moda)
El argumento de Rust es conocido: la seguridad de memoria se verifica en tiempo de compilación, mientras que en C los buffer overflow y use-after-free pasan desapercibidos hasta que alguien los explota. Una buena parte de los CVEs graves de las últimas décadas vienen de bugs de memoria en software escrito en C. Si las herramientas que usas todos los dÃas —como root, encima— tienen esa clase de bugs estructuralmente eliminada, la superficie de ataque baja de verdad.
Pero lo que más me gusta es la decisión de diseño del proyecto uutils: apuntan a compatibilidad drop-in con GNU y tratan cualquier desviación como un bug. Eso es exactamente la actitud correcta. No están pidiendo que cambies tu forma de trabajar ni que aprendas flags nuevos; el punto no es funcional sino de seguridad. Tu script de bash de hace diez años deberÃa seguir funcionando igual.
Como admin, lo otro que valoro es el respaldo económico: Canonical dona unos €40.000 al año a la Trifecta Tech Foundation, la fundación sin fines de lucro detrás de uutils, que además está reescribiendo el protocolo NTP en Rust. Canonical planea que ese cliente sea el default para 27.10. Es decir, no es un experimento de viernes en la tarde; es una apuesta con financiamiento de largo plazo.
Mi opinión: cautela razonable
¿Voy a migrar mis servidores el dÃa uno? No po. Como siempre en infraestructura, mi regla es dejar que 26.10 cocine un par de meses y mirar los reportes de regresiones, sobre todo en casos de esquina: permisos raros, filesystems exóticos, paths con caracteres insólitos. La compatibilidad drop-in es el objetivo, no una garantÃa matemática.
Aun asÃ, esto es de las noticias más subestimadas de la semana. Mientras todos miran los lanzamientos de modelos de IA, un cambio silencioso está reemplazando la base de uno de los sistemas operativos más usados del planeta por código memory-safe. La migración completa de coreutils de GNU a Rust en una distro mainstream es un hito histórico del software libre, y lo hicieron de la única forma que funciona: despacio, con auditorÃas de por medio, y sin romper nada en el camino. Ese es el estándar que me gustarÃa ver en cada reescritura que se anuncie de ahora en adelante.
Fuente de inspiración: Ubuntu 26.10 completes transition to Rust-based coreutils
