⏱️ Lectura: 17 min
FTL corrió su primera aplicación real, un servidor HTTP en Rust compilado para Linux, en septiembre de 2026, usando un kernel de usuario que mide una fracción del código de un sistema operativo convencional. Lo demostró en su propio sitio, ftl-os.org.
📑 En este artículo
- TL;DR
- ¿Qué es un kernel de usuario?
- Por qué importa el sistema operativo de biblioteca de FTL
- Cómo funciona el kernel en espacio de usuario de FTL
- Ejemplos prácticos con el userspace OS de FTL
- Casos de uso reales para un sistema operativo de biblioteca
- Errores comunes y buenas prácticas
- Comparativa: FTL frente a contenedores, VMs y microkernels
- Profundizando: el diseño interno del kernel en espacio de usuario
- Preguntas frecuentes
- Referencias
Es la prueba de un diseño poco común. FTL mueve casi todo el sistema operativo a una biblioteca que corre en espacio de usuario y deja que el kernel haga lo mínimo: así aísla contenedores con la seguridad de una máquina virtual, pero sin pagar el costo de arrancar una VM completa.
TL;DR
- Un kernel de usuario mueve el sistema operativo a una biblioteca que corre junto a la app.
- FTL aísla contenedores con el modo de usuario de la CPU, sin pedir hardware de virtualización ni bare-metal.
- Los binarios Linux corren sin cambios: FTL traduce sus syscalls a una interfaz mínima de vCPU, memoria y drivers.
- El roadmap oficial fija filesystem para noviembre de 2026 y Node.js y Go para diciembre.
- Actualizar el sistema de un contenedor FTL es recompilar una librería, no parchar el kernel compartido.
¿Qué es un kernel de usuario?
Un kernel de usuario es una capa de sistema operativo que implementa procesos, sistema de archivos y red dentro de una biblioteca que corre junto a la aplicación, no en el núcleo privilegiado. FTL lo usa para aislar contenedores con el aislamiento de modo de usuario de una CPU, sin máquinas bare-metal.
La idea no es nueva en el papel: los unikernels y los microkernels llevan décadas moviendo lógica fuera del núcleo compartido. Lo que cambia con FTL es la ejecución: cada contenedor corre su propio sistema operativo de biblioteca, compilado junto a la aplicación, y el kernel FTL se limita a repartir CPU virtual, memoria y acceso a dispositivos, como lo haría un hipervisor.
Por qué importa el sistema operativo de biblioteca de FTL
Un contenedor normal comparte el kernel Linux del host con todos los demás contenedores de la máquina. Si un atacante encuentra un bug en cualquiera de los cientos de syscalls, subsistemas de red o controladores que expone ese kernel, puede escapar del contenedor y tocar lo que corre al lado. Es la razón por la que servicios multiinquilino de alto riesgo prefieren máquinas virtuales completas en lugar de contenedores simples: una VM aísla con su propio kernel invitado, a costa de arrancar un sistema operativo entero por cada carga de trabajo.
FTL apuesta a cerrar esa brecha sin pagar el precio de la VM. En vez de confiar en namespaces y cgroups, los mecanismos que usan Docker y Kubernetes, para separar procesos dentro de un mismo kernel, cada contenedor FTL trae su propio sistema operativo de biblioteca. Si ese código tiene un bug, el daño queda contenido dentro del mismo contenedor: el kernel FTL nunca delega en él operaciones privilegiadas de memoria o dispositivos, solo le da una interfaz mínima para pedirlas.
Esto también cambia cómo se actualiza el sistema operativo de un contenedor. Parchear el kernel Linux de un host significa coordinar un reinicio o usar mecanismos de live patching. Parchear el sistema operativo de biblioteca de un contenedor FTL es, en cambio, recompilar una librería y volver a desplegar el binario, el mismo flujo que ya se usa para la aplicación.
Cómo funciona el kernel en espacio de usuario de FTL
El diagrama oficial del proyecto resume la idea en dos columnas. A la izquierda, Linux: cada proceso llama al kernel por syscalls, y ese kernel concentra el manejo de procesos, memoria, red y dispositivos en un único espacio privilegiado. A la derecha, FTL: cada proceso llama a su propio sistema operativo de biblioteca, que a su vez usa una interfaz mínima del kernel FTL para pedir vCPU, memoria y controladores.
flowchart TD
subgraph FTL["Arquitectura FTL"]
A1["Proceso Linux"] --> U1["Userspace OS: VFS, TCP/IP, procesos"]
A2["Proceso Linux"] --> U2["Userspace OS: VFS, TCP/IP, procesos"]
U1 --> K1["Kernel FTL: vCPU, memoria, drivers"]
U2 --> K1
end
subgraph LINUX["Arquitectura Linux tradicional"]
B1["Proceso Linux"] --> L1["Kernel Linux: process, fork/exec, TCP/IP, drivers"]
B2["Proceso Linux"] --> L1
endEl truco: aislamiento por modo de usuario, no por hipervisor
Acá está el matiz que distingue a FTL de proyectos como Firecracker o Kata Containers. Esos sistemas usan extensiones de virtualización por hardware (VT-x en Intel, AMD-V en AMD) para correr un kernel invitado completo dentro de una microVM. FTL hace algo más liviano: usa el mismo mecanismo de anillos de protección que ya separa procesos de usuario del kernel en cualquier CPU moderna. El sistema operativo de biblioteca de cada contenedor corre en modo usuario, igual que correría una aplicación común, y solo el kernel FTL necesita privilegios reales.
Por eso el proyecto afirma que no hace falta una máquina bare-metal: si una nube ya ofrece una VM normal con un kernel Linux, FTL puede correr dentro de ella sin pedir virtualización anidada. La separación entre contenedores no depende de confiar en que cada sistema operativo de biblioteca se comporte bien; depende de que la CPU impida que código en modo usuario toque memoria o dispositivos que no le pertenecen.
El camino de una syscall dentro de FTL
Cuando una aplicación Linux sin modificar llama a write(), esa syscall no llega al kernel Linux real. La intercepta el sistema operativo de biblioteca del contenedor, que implementa su propia versión de VFS y de la pila TCP/IP. Si la operación necesita memoria nueva o acceso a un controlador, el sistema operativo de biblioteca se lo pide al kernel FTL a través de la interfaz mínima (vCPU, memoria, drivers) que describe el proyecto.
sequenceDiagram
participant App as Aplicación Linux
participant OS as Userspace OS
participant Kernel as Kernel FTL
participant HW as CPU en modo usuario
App->>OS: syscall write
OS->>Kernel: petición de vCPU y memoria
Kernel->>HW: ejecuta en modo usuario aislado
HW-->>Kernel: resultado de la operación
Kernel-->>OS: entrega el resultado
OS-->>App: retorno de la syscallEl resultado es que un binario Linux compilado de forma normal, como el servidor HTTP en Rust que FTL usa para servir su propio sitio, corre sin recompilar y sin saber que su kernel de usuario no es el Linux real. El proyecto también permite aplicaciones al estilo unikernel que ni siquiera usan abstracciones POSIX, para cargas de trabajo que no necesitan la compatibilidad completa.
📌 Nota: FTL no reemplaza la virtualización por hardware, la evita. Al usar solo los anillos de protección que cualquier CPU x86-64 ya ofrece, no depende de VT-x ni de acceso privilegiado al hipervisor del host.
Ejemplos prácticos con el userspace OS de FTL
El siguiente boceto ilustra, de forma didáctica, cómo luce la interfaz mínima que un sistema operativo de biblioteca necesitaría para atender una syscall de escritura. No es la API oficial de FTL, el proyecto todavía no publica una referencia completa; es un modelo simplificado para entender la idea de interceptar la syscall antes de que llegue a un kernel real.
// Boceto conceptual: así podría verse el despacho de syscalls
// dentro de un sistema operativo de biblioteca sobre FTL
struct PeticionSyscall {
numero: u64,
args: [u64; 6],
}
fn despachar(req: PeticionSyscall) -> i64 {
match req.numero {
1 => vfs_escribir(req.args[0], req.args[1], req.args[2]),
2 => proceso_fork(),
_ => -38, // ENOSYS: syscall no implementada todavía
}
}
fn main() {
let req = PeticionSyscall { numero: 1, args: [1, 0, 13, 0, 0, 0] };
let resultado = despachar(req);
println!("syscall devolvio: {}", resultado);
}
La función despachar recibe el número de syscall y sus argumentos, y decide si la resuelve ella misma (como pasaría con vfs_escribir, implementada dentro del propio sistema operativo de biblioteca) o si necesita pedirle algo al kernel FTL. Para una escritura de 13 bytes al descriptor 1, la salida esperada es: syscall devolvio: 13.
Para comparar con el mecanismo que usan hoy la mayoría de los contenedores, este comando real de Linux muestra el otro extremo del espectro: aislamiento con namespaces, dentro del mismo kernel compartido.
# aislamiento con namespaces de Linux: el mecanismo de los contenedores tradicionales
unshare --fork --pid --mount-proc bash
Al ejecutarlo, la nueva shell ve un árbol de procesos propio: un ps aux adentro muestra a bash con PID 1, aunque el kernel que atiende esa syscall sigue siendo el mismo que el del host. Es la diferencia central con FTL, donde cada contenedor no solo ve su propio árbol de procesos, sino que lo implementa él mismo, en su sistema operativo de biblioteca.
Cómo empezar
FTL está en una fase muy temprana (la primera versión, v0.0.1, salió en septiembre de 2026, y la siguiente, v0.1.0, con soporte async, en octubre de 2026, según el roadmap oficial), así que todavía no hay un procedimiento de instalación estable para producción. Lo que sí se puede hacer hoy, antes de clonar nada:
- Confirmar la arquitectura: correr
uname -m. FTL corre hoy sobre x86-64; el soporte de 64-bit Arm está planeado para enero de 2027, todavía no disponible. - Revisar el estado del roadmap: la página oficial lista qué corre en cada versión. A la fecha de este artículo hay soporte confirmado para aplicaciones Rust async sobre Linux (hilos,
epoll), sin sistema de archivos persistente. - Clonar desde la fuente oficial: el repositorio está enlazado desde ftl-os.org. Como el proceso de build cambia con cada versión mientras el proyecto está en desarrollo activo, conviene seguir el README de la versión clonada en vez de un comando fijo.
⚠️ Ojo: todavía no hay soporte de filesystem (llega en noviembre de 2026) ni de múltiples núcleos por contenedor (SMP llega en enero de 2027). Un contenedor FTL hoy corre en un solo núcleo virtual y sin disco persistente.
Casos de uso reales para un sistema operativo de biblioteca
Hoy, con solo un servidor HTTP en Rust como demo pública, FTL no reemplaza nada en producción. Pero el diseño apunta directo a tres escenarios donde los contenedores tradicionales incomodan: plataformas multiinquilino que ejecutan código de clientes que no se conocen entre sí, funciones serverless que necesitan arrancar en milisegundos sin la sobrecarga de un kernel invitado completo, y entornos edge con poca memoria donde duplicar un sistema operativo por cada carga de trabajo no entra en el presupuesto de RAM.
La comparación más cercana hoy es con gVisor y Kata Containers, dos proyectos que atacan el mismo problema desde ángulos distintos. gVisor intercepta syscalls desde un proceso en espacio de usuario escrito en Go, sin tocar hardware de virtualización, pero reimplementa el kernel Linux completo como un solo componente compartido entre contenedores. Kata, en cambio, sí usa una microVM con KVM por contenedor, con el costo de arranque que eso implica. FTL se ubica entre los dos: aísla por contenedor como Kata, pero sin pedir virtualización por hardware, como gVisor.
El roadmap público conecta esos escenarios con fechas concretas. Node.js y Go llegan en diciembre de 2026, lo que abriría FTL a dos de los runtimes más usados en funciones serverless. El soporte de imágenes de contenedor y SMP, previsto para enero de 2027, es el paso que falta para competir de verdad con el empaquetado que ya usan Docker y Kubernetes.
Errores comunes y buenas prácticas
El error más fácil de cometer es pensar que FTL ya ofrece la compatibilidad POSIX completa de un Linux real. No es así todavía: el proyecto corre aplicaciones Linux compiladas de forma estándar siempre que no dependan de funciones que su sistema operativo de biblioteca aún no implementa, como un sistema de archivos persistente.
Otro malentendido común es confundir el aislamiento de FTL con el de un hipervisor tradicional. No usa VT-x ni AMD-V, usa los anillos de protección estándar de la CPU. Esto lo hace más liviano, pero también significa que su modelo de amenaza depende de que el kernel FTL mismo no tenga bugs en esa interfaz mínima: es una superficie más chica que un kernel Linux completo, no una superficie cero.
Sobre verificación: a la fecha de este artículo, FTL no publicó un comando ni una métrica propia para confirmar desde afuera que un contenedor está corriendo aislado por el kernel FTL y no por otro mecanismo. No hay forma directa de verificar esto desde afuera todavía, más allá de revisar el binario del kernel que se levantó y confirmar, por la documentación oficial, qué versión y qué garantías ofrece.
Comparativa: FTL frente a contenedores, VMs y microkernels
La tabla resume cuándo conviene cada enfoque de aislamiento, con el sistema operativo de biblioteca de FTL como una cuarta opción entre los extremos ya conocidos. El diagrama siguiente ubica esas cuatro opciones en una escala de aislamiento creciente, de un proceso simple a una máquina virtual completa.
flowchart LR
P["Proceso simple"] --> C["Contenedor con namespaces"]
C --> F["Contenedor FTL: kernel de usuario"]
F --> V["Máquina virtual con hipervisor"]| Opción | Cuándo usarla | Ventaja | Limitación |
|---|---|---|---|
| Kernel monolítico (Linux + namespaces) | Cargas de trabajo generales sin inquilinos hostiles entre sí | Rendimiento máximo, ecosistema maduro (Docker, Kubernetes) | Superficie de ataque enorme: un bug en cualquier subsistema compromete el kernel completo |
| Microkernel (seL4, Minix) | Sistemas donde la verificación formal importa más que la velocidad | Aislamiento fuerte entre servidores de OS, probado matemáticamente en seL4 | El paso de mensajes entre servidores añade latencia en cada operación |
| VM con hipervisor (KVM, Firecracker) | Multiinquilino de alto riesgo, código que no se conoce entre sí | Aislamiento probado durante décadas, kernel invitado completo | Arranque más lento y memoria duplicada por cada sistema operativo invitado |
| FTL (kernel de usuario) | Contenedores que buscan aislamiento tipo VM sin el costo de una VM completa | Actualizar el OS es recompilar una librería, no tocar el kernel compartido | Proyecto en fase temprana: sin filesystem completo ni SMP todavía |
Profundizando: el diseño interno del kernel en espacio de usuario
La interfaz que expone el kernel FTL se parece, a propósito, a la de un hipervisor: vCPU, memoria y controladores. Pero en vez de usarla para arrancar un kernel invitado completo como haría KVM, FTL la usa para arrancar algo mucho más chico: un sistema operativo de biblioteca que solo implementa lo que esa aplicación en particular necesita.
Esta decisión tiene una consecuencia directa en cómo se extiende el sistema. Agregar una función nueva al kernel Linux real implica escribir código en C dentro del árbol del kernel, o depender de eBPF para inyectar lógica sin recompilarlo. Agregar una función nueva al sistema operativo de biblioteca de un contenedor FTL es escribir código de aplicación normal: se puede poner un printf para depurar, aplicar un parche de seguridad y volver a desplegar, sin coordinar con nadie que comparta ese kernel, porque nadie más lo comparte.
El manejo de memoria sigue una lógica similar. Un kernel Linux decide qué páginas físicas le da a cada proceso y defiende esa asignación con la unidad de paginación de la CPU. El kernel FTL hace algo parecido, pero un nivel más abajo: le da páginas al sistema operativo de biblioteca de cada contenedor, y ese sistema operativo de biblioteca decide cómo repartirlas entre sus propios procesos internos.
El costo de esa libertad es que cada sistema operativo de biblioteca repite trabajo que un kernel compartido normalmente centraliza: su propia pila TCP/IP, su propio VFS, su propio manejo de procesos. FTL apuesta a que ese trabajo repetido, compilado junto a cada aplicación, pesa menos en rendimiento de lo que parece, porque el kernel FTL que queda por debajo es deliberadamente mínimo: vCPU, memoria y drivers, nada más.
📖 Resumen en Telegram: Ver resumen
Tu próximo paso: cloná el repositorio enlazado en ftl-os.org, corré uname -m para confirmar que tu máquina es x86-64 y seguí el README de la versión más reciente para levantar el servidor HTTP de ejemplo que sirve el propio sitio del proyecto.
Preguntas frecuentes
¿FTL reemplaza a Docker o a Kubernetes?
No todavía. FTL resuelve el aislamiento a nivel de kernel, pero no ofrece hoy el empaquetado de imágenes, el registro ni la orquestación que dan Docker y Kubernetes. El propio roadmap ubica el soporte de imágenes de contenedor en enero de 2027.
¿Necesito hardware especial para correr un kernel de usuario como el de FTL?
No. A diferencia de Firecracker o Kata Containers, FTL no depende de VT-x ni de AMD-V. Usa los anillos de protección estándar de cualquier CPU x86-64, por eso corre dentro de una VM de nube normal sin pedir virtualización anidada.
¿Qué aplicaciones puedo correr hoy en FTL?
Según la versión v0.1.0, publicada en octubre de 2026 según el roadmap del proyecto, aplicaciones Rust async compiladas para Linux que usen hilos y epoll, como el servidor HTTP que sirve ftl-os.org. Todavía no hay sistema de archivos persistente ni soporte para Node.js o Go.
¿FTL es un microkernel?
Comparte la filosofía de mover lógica fuera del núcleo privilegiado, pero no pasa mensajes entre servidores como un microkernel clásico. Cada sistema operativo de biblioteca vive dentro del mismo espacio de direcciones que la aplicación, no en un servidor separado.
¿Cuándo soporta FTL otros lenguajes además de Rust?
El roadmap oficial fija diciembre de 2026 para Node.js y Go. Noviembre de 2026 llega antes, con soporte de sistema de archivos, un requisito previo para muchas de esas cargas de trabajo.
Referencias
- FTL: A new operating system for clouds: página oficial del proyecto, con la descripción de la arquitectura y el roadmap citado en este artículo.
- Unikernel (Wikipedia): contexto sobre el diseño de sistemas operativos especializados que inspira parte del enfoque de FTL.
- Microkernel (Wikipedia): explicación del diseño con el que se suele comparar a FTL.
- Protection ring (Wikipedia): el mecanismo de hardware que FTL usa para aislar sin depender de VT-x o AMD-V.
📱 ¿Te gusta este contenido? Únete a nuestro canal de Telegram @programacion donde publicamos a diario lo más relevante de tecnología, IA y desarrollo. Resúmenes rápidos, contenido fresco todos los días.
Imagen destacada: Foto de Patrick Martin en Unsplash
¿Te sirvió? ¿Te dio otro error? Contalo abajo: las preguntas se responden y le sirven al siguiente que llegue.
Dejar un comentario
0 Comentarios