Linux 0.11 renace en Rust y arranca en QEMU

Reescribir Linux 0.11 en Rust suena, a primera vista, como un ejercicio de nostalgia técnica. Un kernel de 1991, arrancando en QEMU, con una base de código moderna y una sintaxis que no existía cuando Linux nació. Pero si te quedas solo con la anécdota, te pierdes lo interesante: este tipo de proyecto sirve para medir cuánto aporta Rust cuando te acercas al metal, qué tan cómoda se vuelve la programación de sistemas y qué costo real tiene adaptar ideas viejas a herramientas nuevas.

El repositorio de referencia es linux-0.11-rs, una reimplementación idiomática de Linux 0.11 en Rust que logra bootear en QEMU. No estamos hablando de un kernel completo ni de una distro usable. Estamos hablando de una pieza histórica reescrita para explorar arquitectura, arranque, memoria y límites del lenguaje. Y eso ya da bastante material para discutir.

Qué significa reescribir Linux 0.11 hoy

Linux 0.11 es una referencia interesante porque pertenece a una etapa muy temprana del proyecto. No tiene nada que ver con el Linux moderno en tamaño, complejidad o ecosistema. Precisamente por eso funciona como banco de pruebas: si puedes hacer arrancar una versión tan pequeña en Rust, puedes observar con más claridad qué partes del lenguaje ayudan y qué partes todavía requieren trabajo manual.

La idea no es “mejorar Linux” en términos absolutos. La idea es responder preguntas concretas. ¿Qué tan legible queda el código cuando migras estructuras y rutinas de bajo nivel a Rust? ¿Cuánto te protege el compilador de errores que en C suelen aparecer tarde? ¿Qué tanto te obliga a pensar distinto sobre ownership, mutability y layout en memoria?

También hay una razón histórica. Muchos desarrolladores aprendieron sistemas con C porque era la herramienta natural para escribir kernels, drivers y componentes cercanos al hardware. Rust cambia el punto de partida: conserva control fino sobre recursos, pero mete reglas más estrictas para evitar clases enteras de bugs. Reescribir un kernel histórico permite ver esa diferencia sin la escala de un proyecto moderno de millones de líneas.

Por qué QEMU importa en este experimento

Que el kernel arranque en QEMU no es un detalle menor. Emular hardware te permite iterar sin depender de una máquina física, sin riesgo de romper tu equipo y con un ciclo de pruebas más corto. Para proyectos de sistemas, eso significa menos fricción al validar cambios de boot, interrupciones o manejo de memoria.

QEMU también te deja aislar el problema. Si el kernel falla, sabes que estás depurando tu código, no una placa específica o un controlador raro. Para una reescritura experimental, esa ventaja vale mucho más que un arranque “real” en hardware, porque el objetivo es entender el comportamiento del código, no certificar compatibilidad con cien máquinas.

Rust en bajo nivel: qué aporta de verdad

Cuando se habla de Rust en sistemas, casi siempre aparecen las mismas tres promesas: seguridad de memoria, menos data races y mejores abstracciones sin costo extra evidente. En un kernel, esas promesas no son marketing, son restricciones de diseño. Si tu código toca memoria, interrupciones o estructuras compartidas, el compilador se convierte en una segunda línea de defensa.

Eso no significa que Rust te quite todo el trabajo difícil. En un kernel sigues lidiando con punteros crudos, mapeo de memoria, ensamblador y hardware específico. La diferencia es que puedes encapsular esas zonas peligrosas y mantener el resto del código en una forma mucho más verificable. En otras palabras, no eliminas el riesgo, lo acotas mejor.

En un proyecto como linux-0.11-rs, el valor está en esa frontera. El código idiomático en Rust puede hacer más explícitas las invariantes: qué se inicializa primero, qué recursos dependen de otros, qué estructuras no deben moverse, qué datos son compartidos. Esa explicitud ayuda cuando lees el código meses después, y también cuando otra persona quiere revisar una parte crítica.

Seguridad de memoria sin vender humo

Rust no evita bugs por arte de magia. Si usas unsafe, puedes equivocarte igual que en C. La diferencia es que Rust te obliga a justificar esas zonas y a dejar claro dónde termina la garantía del compilador. En un kernel, eso es útil porque reduce el tamaño de la superficie peligrosa.

Un ejemplo simple: en C, una estructura compartida entre subsistemas puede terminar con accesos inválidos si una inicialización falla a mitad de camino. En Rust, el diseño suele forzarte a modelar mejor ese estado intermedio. No siempre es más corto, pero sí más explícito. Para sistemas de bajo nivel, esa explicitud ahorra tiempo de depuración.

Qué se ve en una reescritura idiomática

La palabra “idiomática” importa. No basta con traducir C a Rust línea por línea. Si haces eso, pierdes buena parte del beneficio. Una reescritura idiomática intenta usar patrones naturales del lenguaje: Result para errores, Option para ausencia de valor, enums para estados, módulos para separar responsabilidades y referencias para expresar relaciones de propiedad.

Eso cambia la forma de leer el kernel. En C, muchas veces entiendes el flujo por convención y por contexto. En Rust, una parte de ese contexto queda codificada en el tipo. Eso no vuelve el código trivial, pero sí más navegable. Y cuando trabajas en componentes tan delicados como el arranque, cualquier claridad adicional cuenta.

También hay una ganancia pedagógica. Reescribir Linux 0.11 en Rust te obliga a volver a conceptos que a veces damos por sentados: layout de estructuras, alineación, punteros a registros, manejo de errores en etapas tempranas del boot. Si tú trabajas en firmware, embebidos o infraestructura, ese repaso vale más que una demo bonita.

Ejemplo de la diferencia entre C y Rust

Mira este ejemplo simplificado. No es código del proyecto, sino una forma de ilustrar el cambio mental:

struct BootState {
    memory_ready: bool,
    interrupts_ready: bool,
}

impl BootState {
    fn init_memory(&mut self) {
        self.memory_ready = true;
    }

    fn init_interrupts(&mut self) -> Result<(), &'static str> {
        if !self.memory_ready {
            return Err("memory not initialized");
        }
        self.interrupts_ready = true;
        Ok(())
    }
}

En C, este tipo de dependencia suele vivir en comentarios, nombres de funciones o disciplina del equipo. En Rust, la estructura del código empuja a que esas dependencias sean visibles. No es una solución universal, pero sí una mejora concreta para proyectos donde el orden de inicialización importa.

Qué problemas reales ayuda a discutir

Lo más útil de este proyecto no es el arranque en sí, sino las preguntas que dispara. La primera es si Rust reduce errores de memoria en código de sistemas. La respuesta corta es sí, pero con matices: reduce una clase importante de bugs, no elimina la complejidad del dominio.

La segunda pregunta es ergonomía. ¿Es más fácil mantener un kernel pequeño en Rust que en C? Depende del equipo y del tipo de código. Si vas a tocar mucho puntero crudo y ensamblador, el costo de unsafe sube. Si tu código puede vivir en capas bien separadas, Rust te puede ordenar el proyecto de una forma difícil de replicar en C.

La tercera pregunta es rendimiento. En proyectos de bajo nivel, el miedo suele ser que el lenguaje “meta peso”. Pero el costo no se mide por intuición. Se mide por compilación, tamaño binario, latencia de arranque y comportamiento en runtime. En un kernel histórico como Linux 0.11, el objetivo no es ganar benchmarks, sino verificar que la abstracción no estorbe el control fino.

Tres señales de que Rust sí suma aquí

1. Menos estados inválidos en estructuras críticas.
2. Mejor separación entre lógica segura y zonas unsafe.
3. Revisiones de código más claras cuando hay dependencias de inicialización.

Eso no significa que todo deba reescribirse en Rust. Significa que, para piezas concretas, el lenguaje puede darte una base más segura sin renunciar al control que exige un kernel.

Comparación práctica: C histórico vs Rust moderno

Para aterrizar la discusión, conviene mirar el problema con una tabla simple. No se trata de declarar un ganador, sino de ver dónde cambia la experiencia de desarrollo.

La tabla no dice que Rust sea mejor en todo. Dice algo más útil: cambia el tipo de deuda técnica que acumulas. En C, la deuda suele esconderse en invariantes no documentadas. En Rust, la deuda aparece antes, porque el compilador te obliga a resolverla o a declararla explícitamente.

Si trabajas en LatAm, donde muchos equipos todavía mantienen sistemas heredados, esa diferencia importa. No siempre puedes reescribir todo. Pero sí puedes decidir qué módulos merecen una capa más segura y dónde conviene mantener interfaces estrechas y bien definidas.

Cuándo tiene sentido intentar algo así

No todos los proyectos necesitan una reimplementación histórica en Rust. De hecho, la mayoría no la necesita. Pero hay escenarios donde sí vale la pena, y conviene tenerlos claros para no convertir el experimento en una moda.

Primero, cuando quieres formar equipo. Un kernel pequeño en Rust sirve como laboratorio para aprender conceptos de sistemas sin meterte de golpe en un monstruo de millones de líneas. Segundo, cuando quieres validar una arquitectura de arranque o una capa de abstracción antes de llevarla a un proyecto mayor. Tercero, cuando buscas reducir errores de memoria en una base crítica que hoy vive demasiado cerca del límite.

También puede ser útil en educación. Si enseñas programación de sistemas, una reescritura de Linux 0.11 en Rust te permite mostrar conceptos históricos y modernos en el mismo ejercicio. Eso ayuda a que el estudiante vea continuidad entre C, ensamblador, emulación y un lenguaje con garantías más fuertes.

Checklist para evaluar un proyecto similar

• Define el objetivo real: aprendizaje, mantenimiento, investigación o portabilidad.
• Separa claramente el código seguro del código unsafe.
• Usa emulación, por ejemplo QEMU, para iterar rápido.
• Mide arranque, tamaño y estabilidad, no solo compilación exitosa.
• Documenta invariantes clave desde el día uno.
• Evita traducir C literal: busca diseño idiomático.

Lo que deja este repositorio

El valor de linux-0.11-rs está en que no intenta impresionar con una capa de humo. Hace algo concreto: toma un kernel histórico, lo reescribe en Rust y consigue que arranque en QEMU. Eso ya basta para abrir varias conversaciones serias sobre ergonomía, seguridad y diseño de sistemas.

Si tú vienes de C, el proyecto te obliga a mirar Rust sin prejuicios y sin promesas exageradas. Si ya trabajas con Rust, te muestra dónde el lenguaje brilla y dónde todavía dependes de conocimiento clásico de sistemas. Y si estás en un equipo que mantiene software crítico, te da una excusa para discutir migraciones parciales, no solo reescrituras completas.

Para profundizar en la parte técnica del lenguaje, te conviene revisar la documentación oficial de Rust sobre ownership y referencias en The Rust Book. Si quieres entender el entorno de emulación que hace posible el arranque, la documentación de QEMU en qemu.org/docs es una buena base. Y si te interesa el contexto histórico del kernel, el propio repositorio de referencia deja ver el enfoque y alcance del proyecto.

Tabla resumen