FTL: propone aislar contenedores como una VM
@programacion
Lo esencial
- FTL aísla cada contenedor con su propio kernel en espacio de usuario, con el mismo nivel que una VM.
- El kernel FTL solo expone vCPU, memoria y drivers; el resto del sistema operativo vive en una biblioteca de la app.
- Su servidor HTTP en Rust ya corre como binario de Linux sin modificaciones sobre FTL (v0.0.1, septiembre 2026).
- Faltan piezas clave: sistema de archivos en noviembre de 2026 y Node.js, Go, SMP recién entre diciembre y enero de 2027.
Un contenedor de Docker comparte el kernel de Linux con todos los demás contenedores de la máquina: si uno escapa de su sandbox, llega directo al núcleo real del sistema. FTL, un proyecto experimental publicado en septiembre de 2026, propone que cada contenedor cargue su propio sistema operativo como si fuera una biblioteca más de la aplicación, con el mismo nivel de aislamiento que ofrece una máquina virtual completa.
Qué es un library OS
Un library OS es un sistema operativo empaquetado como una biblioteca que se enlaza directamente con la aplicación, en lugar de vivir separado en modo kernel. Las funciones que normalmente resuelve el kernel (gestión de procesos, sistema de archivos virtual, pila TCP/IP) se compilan junto al programa y corren en el mismo espacio de direcciones que la app.
Eso cambia la forma de depurar y actualizar el sistema: agregar un printf, aplicar un parche de seguridad o sumar una función nueva se vuelve tan simple como modificar cualquier otra librería, sin recompilar un kernel monolítico ni reiniciar la máquina entera. El propio proyecto lo resume en su sitio: en FTL, el sistema operativo es solo una biblioteca.
El problema que FTL ataca: contenedores que comparten kernel
Los contenedores tradicionales logran aislamiento con namespaces y cgroups, mecanismos que viven dentro del mismo kernel de Linux que comparten todos los procesos del host. Esa frontera es más débil que la de una máquina virtual, donde un hipervisor separa el hardware entre huéspedes con una capa adicional.
Las VMs son más seguras, pero cuestan más: cada una carga su propio kernel completo y consume más memoria y tiempo de arranque. FTL apunta a ese punto intermedio: aislamiento del nivel de una VM, con el peso de un contenedor.
- Contenedor tradicional: namespaces y cgroups sobre un kernel compartido por todos los procesos del host.
- Máquina virtual: hipervisor más un kernel completo por VM, aislamiento fuerte pero pesado.
- FTL: kernel mínimo tipo hipervisor más un sistema operativo de biblioteca por contenedor.
La arquitectura: un hipervisor minimalista en espacio de usuario
El kernel FTL no implementa procesos, archivos ni redes. Expone una interfaz mínima (vCPU, memoria, controladores de dispositivo) parecida a la que ofrece un hipervisor a una máquina virtual, pero usando aislamiento de hardware liviano en modo usuario en lugar de requerir una máquina física dedicada.
Sobre esa interfaz corre el userspace OS: una biblioteca compartida que implementa los conceptos que un programa de Linux espera encontrar (procesos, VFS, TCP/IP) y traduce cada llamada al sistema hacia la interfaz mínima del kernel FTL. El resultado combina, según describe el propio proyecto, lo mejor de los microkernels (flexibles y seguros) con lo mejor de los kernels monolíticos (rápidos y simples).
FTL Linux
+-------------------------------+ +-------------------------------+
| Proceso Linux | Proceso Linux | | Proceso Linux | Proceso Linux |
+-------------------------------+ +-------------------------------+
| llamadas al sistema de Linux | interfaz de Linux
+-------------------------------+ +-------------------------------+
| Userspace OS (proceso, VFS, | | Kernel de Linux |
| TCP/IP, ...) | | procesos, fork/exec, memoria, |
+-------------------------------+ | senales, TCP/IP, /proc, ... |
| interfaz minima +-------------------------------+
+-------------------------------+
| Kernel FTL (vCPU, memoria, |
| drivers, ...) |
+-------------------------------+Qué pasa por dentro cuando una app hace una llamada al sistema
El proyecto todavía no publica su API completa, pero la idea central se puede ilustrar con un fragmento conceptual: el kernel FTL solo resuelve primitivas de bajísimo nivel, y la biblioteca que actúa como sistema operativo traduce ahí cada syscall de Linux.
// Ilustracion conceptual, no es codigo oficial de FTL
fn sys_connect(fd: i32, addr: SocketAddr) -> Result<(), Errno> {
let socket = userspace_os::tcpip::lookup_socket(fd)?;
ftl_kernel::vcpu::syscall_passthrough(Syscall::Connect, socket, addr)
}La función de ejemplo muestra el patrón: la biblioteca resuelve la lógica de red (buscar el socket, armar el paquete) y solo delega al kernel FTL lo que de verdad requiere privilegios de hardware, a través de su interfaz mínima de vCPU.
Compatible con binarios de Linux sin recompilar
FTL no exige reescribir las aplicaciones desde cero. El servidor HTTP en Rust que sirve ftl-os.org es, según documenta el proyecto, una aplicación de Linux corriendo tal cual sobre FTL. También admite programas al estilo unikernel, sin las abstracciones POSIX completas, para casos donde se busca el menor costo adicional posible.
Las limitaciones de FTL hoy
FTL está en una etapa muy temprana. La versión v0.0.1, lanzada en septiembre de 2026, solo corre un servidor HTTP simple de Linux: todavía no hay sistema de archivos persistente ni soporte multinúcleo (SMP), y tampoco existen imágenes de contenedor como las de Docker.
La hoja de ruta pública lo confirma: el soporte para Rust asíncrono (hilos, epoll) llega en octubre de 2026, el sistema de archivos en noviembre, Node.js y Go en diciembre, y SMP junto con soporte para Arm de 64 bits no antes de enero de 2027. Para cualquier carga de producción real, FTL todavía no es una opción: es una prueba de concepto que vale la pena seguir, no algo para desplegar esta semana.
Qué significa esto para el futuro de los contenedores
Si el enfoque de FTL madura, un orquestador como Kubernetes podría programar contenedores con aislamiento de VM sin pagar el costo de un kernel completo por instancia. Eso importa sobre todo para quien corre cargas multiusuario (funciones serverless, sandboxes para agentes de IA, entornos compartidos) donde escapar del contenedor hoy significa comprometer el host entero.
El proyecto es de código abierto y mantiene su hoja de ruta pública, así que cualquiera puede seguir de cerca si cumple esos plazos o si, como pasa a menudo con sistemas operativos experimentales, las fechas se corren.
Conclusión
FTL no inventa un concepto nuevo: los library OS y los unikernels existen desde los años noventa. Pero sí propone aplicarlo a contenedores de nube con una pieza clara: un kernel mínimo tipo hipervisor que aísla en modo usuario, y una biblioteca que hace de sistema operativo completo por encima. Falta sistema de archivos, multinúcleo y soporte de lenguajes; lo que ya existe alcanza para entender hacia dónde podría moverse el aislamiento de contenedores en los próximos años.
📖 Versión extendida con más detalle: https://elsolitario.org/2026/10/03/ftl-apuesta-a-aislar-contenedores-como-una-vm/?utm_source=telegraph&utm_medium=instant_view&utm_campaign=programacion