El kernel de 100 KB que quiere reemplazar a Linux en la nube (y está escrito en Rust)

Un kernel de 100 KB, escrito completamente en Rust, que cabe en 2 MB de RAM y añade Linux a los contenedores sin reiniciar la máquina. Esa es la propuesta de FTL, el nuevo sistema operativo para nubes que acaba de presentar un ingeniero de Microsoft y que ya acumula 161 puntos y 65 comentarios en Hacker News. No es un proyecto académico abandonado: tiene repositorio público, kernel compilado y una hoja de ruta con Docker como siguiente paso.

¿Por qué otra vez Linux?

Linux es maduro, battle-tested y está en todas partes. Nadie va a reemplazar el kernel de tu laptop. El problema es otro: Linux está diseñado para que el kernel sea grande y monolítico, y eso significa que cualquier innovación a nivel de kernel exige programación de kernel, sudo y un reinicio del servidor.

En la nube moderna tu aplicación corre dentro de un contenedor. Si quieres un stack TCP propio, mejores hooks de observabilidad o simplemente un io_uring optimizado, tienes que pasar por el kernel de Linux — y ese kernel lo compartes con los miles de contenedores vecinos en el mismo host.

FTL propone la alternativa: un kernel híbrido donde el kernel hace muy poco y casi toda la lógica vive en una biblioteca de espacio de usuario, una distinta por contenedor.

Qué es FTL y cómo funciona

La idea central es que el kernel de FTL se comporta como un hipervisor. Expone primitivas mínimas — vCPU, espacio de handles, espacio de direcciones virtual, objetos de memoria virtual, interfaz de red virtual — y nada más. La diferencia clave frente a un hipervisor clásico es que FTL opera en modo usuario, no con virtualización asistida por hardware.

Eso significa que no necesitas instancias bare metal para mantener rendimiento, y que la frontera de aislamiento es lógica, no de hardware.

El corazón de la innovación se llama Userspace OS: una biblioteca que implementa los conceptos del sistema operativo en espacio de usuario. Es parecida al application kernel de Sentry o gVisor, pero con una diferencia enorme: puedes tener un Userspace OS diferente para cada contenedor.

• Un contenedor puede implementar su propio stack TCP.
• Actualizar el OS de un contenedor es reiniciar solo ese contenedor con la biblioteca nueva — sin tocar la máquina, sin sudo, sin downtime global.
• FTL ejecuta binarios Linux tal cual: no reescribes tu aplicación. En el futuro también imágenes de Docker.
• Cada contenedor mapea su Userspace OS en todos sus procesos, implementando procesos, PIDs, ficheros y sockets de forma compatible.

Los números que importan

• 100 KB — tamaño del binario del kernel, escrito 100% en Rust.
• 2 MB de RAM — funciona en QEMU sobre x86-64.
• 65 comentarios en HN — la conversación es técnica, no ciclo de hype.
• Stack único de kernel y manejo de OOM escrito también en Rust.

Los drivers de dispositivo (hoy solo virtio-net) están embebidos en el kernel. El propio autor lo admite como la mayor desventaja frente al microkernel original, y planea moverlos a un servicio de espacio de usuario.

El problema gordo: Chromium

FTL no lo esconde y por eso merece que lo leas: como el Userspace OS es una biblioteca compartida, los procesos dentro del mismo contenedor pueden interferir con el propio sistema operativo. Chromium, por ejemplo, necesita trabajo extra para aislar sus componentes de forma segura sobre FTL.

El plan es usar mecanismos de aislamiento in-process como Intel MPK para proteger el Userspace OS de las aplicaciones. Pero eso es futuro: hoy es una limitación real.

¿Por qué deberías importarte?

Si trabajas con contenedores, FTL es una señal de dónde va todo. Tres casos donde te toca directamente:

1. Arranque en VPS barato. Si corres en una VPS de 1 GB, un kernel de 2 MB te deja el resto para tu aplicación. Linux se queda con memoria que no necesitas.

2. Multi-tenancy sin sustos. Si tu SaaS corre código de clientes en el mismo host, el aislamiento en espacio de usuario sin virtualización por hardware es exactamente lo que quieres revisar.

3. Linux sigue siendo Linux. No tienes que reescribir nada. El binario corre tal cual. Eso baja la barrera de entrada a cero.

Mi postura es clara: esto no va a matar a Linux ni en 2027 ni en 2030. Un kernel monolítico con 30 años de madurez no se sustituye así. Pero FTL demuestra algo que importa: la innovación en sistemas ya no está en el kernel, está en donde pones la lógica. Y moverla a espacio de usuario, con Rust como base, es el mismo movimiento que hicieron gVisor, Firecracker y containerd.

Estado actual: qué funciona y qué no

Hoy hay un kernel compilable, primitivas básicas, binarios Linux ejecutables y drivers virtio-net. Falta: imágenes de Docker nativas, drivers fuera del kernel, aislamiento in-process y un ecosistema real de hardware. El proyecto es joven — trátalo como el oráculo de lo que vendrá, no como algo para producción.

Aun así, para el 99% de nosotros seguiremos usando Linux. Pero si quieres entender dónde está la próxima pelea de infraestructura, aquí está el comienzo.

Preguntas para ti

¿Pondrías un contenedor tuyo en un kernel híbrido de 2 MB cuando Linux ya funciona? Déjame tu respuesta en los comentarios — y si quieres ver el código, está en GitHub.

Comparte esto con alguien que todavía cree que Linux es imposible de tocar. El kernel más pequeño que vas a ver hoy te va a cambiar la perspectiva.