Las dependencias obligatorias de Rust llegarán a Debian APT a partir de mayo de 2026

• El gestor de paquetes APT de Debian incorporará código basado en Rust y sus dependencias a partir de después de mayo de 2026
• En la etapa inicial, los objetivos de integración serán el compilador de Rust, la biblioteca estándar y el ecosistema Sequoia
• Los analizadores de archivos .deb, .ar y .tar, así como el código de verificación de firmas HTTP, son las principales áreas de mejora en términos de seguridad de memoria y fortalecimiento de las pruebas unitarias
• Los ports que no tengan toolchain de Rust deberán construir un entorno Rust en un plazo de 6 meses o dejarán de recibir soporte (sunset)
• Es una medida para que todo el proyecto avance hacia herramientas y tecnologías modernas, sin quedar frenado por la compatibilidad con hardware antiguo

---

Plan para incorporar código Rust en APT

• Está previsto introducir código Rust y una dependencia dura (hard dependency) en APT después de mayo de 2026
  • La adopción será después de mayo de 2026; no se aplicará antes de esa fecha
• El alcance inicial de la integración se limitará al compilador de Rust, la biblioteca estándar y el ecosistema Sequoia

Objetivo: mejorar la calidad y seguridad del código

• El código de análisis de archivos .deb, .ar y .tar, junto con el código de verificación de firmas HTTP, es el principal objetivo de la adopción de Rust
  • Se indica que estas áreas se beneficiarán especialmente de un lenguaje con seguridad de memoria y de un sistema de pruebas unitarias reforzado

Requisitos para los mantenedores de ports

• Los ports que no cuenten con un toolchain de Rust deberán establecer un entorno Rust en un plazo de 6 meses
  • De lo contrario, ese port podría ser descontinuado (sunset)

Dirección del proyecto

• Se enfatiza que el proyecto Debian debe evolucionar aprovechando herramientas y tecnologías modernas
  • Se especifica que el avance no debe retrasarse por intentar ajustarse a hardware antiguo o a dispositivos de computación retro

Información adicional

• El remitente es Julian Andres Klode, desarrollador central de Debian y Ubuntu
• El correo fue publicado en la lista de correo para desarrolladores de Debian, debian-devel
• Incluye como archivo adjunto la firma PGP (signature.asc)
• No se mencionan más detalles técnicos ni cambios de calendario

[GN⁺]

Opiniones en Hacker News

• Parece que por fin llegó el momento. Seguir manteniendo en C código para parsear datos no confiables es una deuda técnica que crece con el tiempo
  Rust no es mucho más difícil de escribir que C, y parece el tipo de lenguaje que habría salido si hoy rehiciéramos C reflejando lo que sabemos ahora sobre diseño de lenguajes y seguridad del código
  Si se puede abandonar el soporte de x86 de 32 bits por razones prácticas, entonces también aplica para estas arquitecturas. Si de verdad se quieren mantener, habría que crear directamente el backend del toolchain de Rust

  • Actualmente, los lenguajes permitidos para aplicaciones clave en el sistema base son más o menos C, C++, Shell (bash), Perl y Python. Python se agregó hace unos 20 años, y Rust es el primer lenguaje que se acerca lo suficiente como para reemplazar el papel de C
    Go era lo más parecido, pero nunca se discutió al punto de usarlo en un sistema central como systemd. Me pregunto si también hubo este tipo de discusiones cuando se añadieron C++, Python y Perl en su momento
  • Se dice que “los parsers de .deb, .ar, .tar y el código de verificación de firmas HTTP se beneficiarían de un lenguaje memory-safe”, pero me pregunto qué beneficio real aporta reescribir en un lenguaje nuevo código que ya se ha estabilizado durante 30 años
    ¿De verdad vale la pena desechar código probado en batalla para crear nuevos problemas de compatibilidad y bugs?
  • Como enfoque más práctico para resolver problemas de seguridad en código C antiguo, está el proyecto Fil-C. La idea es convertir C prácticamente en un lenguaje gestionado, reduciendo la necesidad de reescribir
  • Esto no es solo un tema de memory safety. También está el envejecimiento de la comunidad de C, que hace difícil encontrar gente para mantenimiento. En nuestro equipo también estamos migrando todo el código C/C++ a otros lenguajes. La mayoría de los desarrolladores de C/C++ andan por los 40 y tienen poca intención de cambiarse de trabajo
  • Me cuesta aceptar la idea de que Rust sea una recreación moderna de C. Por ejemplo, el código del widget de reloj de COSMIC Desktop es mucho más difícil de leer que código C de complejidad similar, como GNU coreutils

• La tendencia de reescribir sistemas centrales en Rust es fuerte, pero no está claro si la seguridad realmente mejora al reescribir herramientas antiguas
  Entiendo que sea difícil introducir sistemas nuevos, pero igual da la sensación de seguir apilando capas sobre decisiones de diseño de la era del telégrafo

  • Se suelen escuchar dos razones para estas reescrituras.
    Primero, casi no hay nuevos contribuidores que quieran lidiar con bases de código viejas de C/C++. Pasar a Rust facilita la entrada de nuevos desarrolladores
    Segundo, la confiabilidad se valida con el uso, pero la seguridad solo se valida mediante ataques. No se puede asumir que el código viejo ya pasó por todos los vectores de ataque. Por eso hay una justificación fuerte para reforzar la seguridad de forma preventiva
  • uutils/coreutils usa licencia MIT, mientras que GNU coreutils usa GPL, así que hay una diferencia de licencias. Desde la perspectiva empresarial, eso puede ser un punto importante
  • Alguien tiene que aprender, así que me parece bien reescribir proyectos simples y fáciles de probar como práctica. Pero que el resultado termine reemplazando al original es otro debate

• Según el hilo de correos de Debian, Rust ya es obligatorio en la mayoría de las arquitecturas de lanzamiento de Debian
  En este correo relacionado se menciona como excepciones solo a alpha, hppa, m68k y sh4. Me da curiosidad el destino futuro de esas arquitecturas

  • De verdad me pregunto si todavía hay gente usando esas máquinas viejas. La mayoría es hardware de más de 20 años.
    Rust ofrece un target Tier 3 para m68k, pero no para las otras arquitecturas. Me interesan los casos de uso reales
  • Según Debian Supported Architectures, esas plataformas están en estado no oficial.
    Me sorprende que sigan ahí mientras x86 de 32 bits y MIPS ya quedaron fuera. En lo personal me da algo de nostalgia, pero no tengo claro para qué se usan realmente
  • m68k ya tiene un port a LLVM, así que una implementación de Rust es posible. Los backends de LLVM para alpha, hppa y sh4 también tienen valor como material de referencia educativo
    Antes LLVM tenía un backend para DEC Alpha, pero eso fue hace mucho
  • Desde la perspectiva de Ubuntu, estas arquitecturas no tienen valor comercial
  • Están completamente obsoletas, así que simplemente podrían quedarse congeladas en la última versión compatible o mantener su propia distribución. Agregar soporte de Rust no es realista

• Me gustaría que la comunidad de Rust, en vez de meterse en proyectos ya existentes, demostrara su valor creando directamente tecnología moderna nueva
  Redox es un ejemplo de eso, y da pena que no se impulse más ese tipo de intento

  • Esta es una decisión oficial de Debian de añadir dependencias de Rust. No es algo impuesto por fans externos de Rust
    Claro, existen fans intensos que dicen “reescríbanlo en Rust”, pero este caso es distinto
  • ripgrep es justamente un ejemplo así. Se hizo desde cero y a la gente realmente le gusta

• No me molesta usar la biblioteca estándar de Rust, pero no quiero arrastrar 500 paquetes de cargo para compilar un parser simple de deb

• Tal vez sea razonable esperar a que se estabilice el port de Rust-for-GCC
  El kernel tampoco planea hacer obligatorio Rust hasta que haya soporte en GCC.
  Si aparecen varias implementaciones, el lenguaje se volverá menos inestable
  Pero si se corta ahora el soporte para arquitecturas, más adelante, cuando exista el toolchain de Rust, el proceso de regreso podría complicarse

  • En realidad, estas arquitecturas ya están fuera de Debian desde hace más de 10 años. Este cambio no las está expulsando recién ahora
  • No tienen soporte oficial y apenas las mantienen personas en su tiempo libre. A menos que una empresa se haga cargo del mantenimiento a largo plazo, será difícil que vuelvan
  • GCCRS todavía ni siquiera puede compilar libcore y está más o menos al nivel de Rust 1.50. Parece que faltan años para que sea un compilador de uso general
    De hecho, es más probable que rustc_codegen_gcc se estabilice antes
  • Los ports no se incluyen en los lanzamientos oficiales de Debian, solo se distribuyen por el canal unstable

• Vale la pena recordar que el autor del correo en la discusión de Rust en Debian es el mantenedor del paquete keepassxc
  Hay hilos que dicen que antes también tuvo formas bruscas al tratar con desarrolladores upstream y usuarios

  • Yo también vi ese correo y lo comprobé de inmediato; me dio risa porque me acordé de hilos anteriores
  • Sinceramente, la forma en que escribe es brusca, pero directa, no insultante. Me parece drama innecesario
  • La publicación en HN en sí no es agresiva, pero algunos parecen tomársela demasiado a pecho
  • Esta cultura está bastante extendida en el mundo del software libre. Creo que desde la época de GNOME 3 y Mozilla existe esa tendencia de perseguir un usuario idealizado más que al usuario real

• Es interesante ver cómo cambia la opinión de una persona. Enlace a una declaración anterior

  • Da gusto ver a alguien cambiar de parecer con el tiempo
  • La adopción de Rust en APT también podría ser, igual que la transición de coreutils, una decisión administrativa

• Creo que Rust es solo hype. En el mundo embebido, C sigue siendo el rey.
  En mi entorno nunca he visto a nadie usar Rust ni siquiera considerarlo

  • Sacar conclusiones con “yo no lo veo a mi alrededor” es forzado. Sí hay muchos desarrolladores embebidos que usan Rust
  • Dentro de AWS, servicios clave como EC2, IAM, DynamoDB y S3 están escritos en Rust.
    Mantiene rendimiento y eficiencia de memoria mientras acelera el desarrollo.
    La única desventaja es el tamaño de los binarios. Yo diría que el futuro de Rust ya está bastante asegurado
  • Rust también es fuerte en embebidos, pero como falta soporte del fabricante, la carga de trabajo inicial por hardware es grande.
    Aun así, lo atractivo no es solo la memory safety, sino la calidad integral del lenguaje y del toolchain
  • Con avr-rust, esp-rs, cortex-m y otros, el ecosistema embebido también está cambiando poco a poco
  • En Microsoft, Google y otras empresas también se está discutiendo Rust y ya se está aplicando en productos reales

• Creo que un entorno polyglot solo crea más problemas.
  Tener Python, Node, Go y Rust implica distintos toolchains y gestores de paquetes, y eso complica todo
  Se eliminaron los buffer overflows usando Node, pero aumentaron los ataques a la cadena de suministro.
  Mejor empezar de cero, y si de verdad se quiere usar Rust en todo, lo correcto sería contribuir a Redox OS

  • En la práctica, cada lenguaje tiene ventajas y desventajas propias, y Debian, como SO práctico, debe soportar varios lenguajes
    Reescribir todo en un solo lenguaje es irreal, y empujar Redox quizá hasta sería ineficiente
    Rust ya es un lenguaje suficientemente probado y tiene valor como lenguaje compilado con menor probabilidad de autodestruirse al modificarlo que C
    Tampoco sería tan descabellado abandonar arquitecturas antiguas
  • En un proyecto grande como Debian, ampliar las opciones es una decisión razonable. Agregar Rust es una decisión bastante entendible
    Qué lenguajes sacar o meter es algo que deben decidir los mantenedores de Debian
  • Linux ya renunció a luchar contra la complejidad hace décadas