Show HN: NSL – WSL para Linux

Artículo original ↗ Discusión en Hacker News ↗

Una nueva herramienta llamada NSL pretende llevar a Linux una experiencia al estilo WSL2 mediante una VM ligera que aloja múltiples contenedores systemd-nspawn, ofreciendo entornos “pet” aislados para desarrollo sin contaminar el sistema anfitrión. Los comentaristas la comparan con opciones existentes como Distrobox, toolbx, LXC/Incus y VMs convencionales, debatiendo compensaciones entre aislamiento, rendimiento, integración con el host y facilidad de uso. Algunos elogian la UX y el empaquetado por hacer este flujo de trabajo más accesible, mientras que otros cuestionan la necesidad de otra capa más y expresan inquietud por la aparente dependencia del proyecto de documentación generada por IA.

Arquitectura y enfoque

  • NSL pretende llevar a Linux una experiencia similar a WSL2: una única VM “host” que ejecuta múltiples contenedores systemd-nspawn.
  • La VM se inicia mediante systemd-vmspawn; dentro de ella, las instancias son contenedores systemd-nspawn, no Docker/Podman ni LXC.
  • Se presenta como VMs/instancias “pet” con integración limitada pero cómoda con el host, en lugar de contenedores desechables.

Comparación con herramientas existentes (Distrobox, toolbx, LXC/Incus, VMs, etc.)

  • Distrobox/toolbx: normalmente montan el $HOME del host y están diseñados como capas sobre el entorno del host; NSL intencionalmente no lo hace, favoreciendo el aislamiento de dotfiles, PATH y bibliotecas del sistema.
  • LXC/Incus: ofrecen sistemas “completos” basados en contenedores sin una VM; NSL añade una capa de VM para un aislamiento más fuerte y la opción de usar un kernel distinto.
  • VMs tradicionales (qemu/multipass/Vagrant): NSL se presenta como más ligero, sin interfaz gráfica por defecto, y compartiendo la sesión Wayland del host cuando hace falta, en lugar de ejecutar un escritorio completo.
  • Algunos lo ven redundante dado que ya existen herramientas; otros sostienen que el principal diferenciador es la UX y el empaquetado, no la capacidad bruta.

Casos de uso y motivación

  • El objetivo principal: mantener el SO anfitrión “limpio” de dependencias de desarrollo y experimentos que puedan romper sutilmente el sistema.
  • Caso de uso común: ejecutar IDEs o toolchains de desarrollo en una distribución distinta a la del host, con acceso fácil a terminal y archivos, pero sin contaminar el host.
  • Algunos usuarios mencionan usarlo para permitir de forma segura que agentes de IA instalen dependencias a nivel de sistema.

Seguridad y aislamiento

  • Varios comentarios subrayan que los contenedores son límites de seguridad más débiles que las VMs; la capa de VM se ve como un aislamiento más fuerte, aunque no perfecto.
  • Se plantea la preocupación de que la integración con el host de NSL (archivos, puertos, ventanas) aún podría permitir escapes salvo que se usen banderas de aislamiento adicionales, lo que podría perjudicar la UX.

Rendimiento y aspectos prácticos

  • Se pregunta por el impacto en rendimiento frente a lo nativo o a contenedores puros; no se aportan benchmarks concretos en el hilo.
  • Se señala como punto positivo el soporte gráfico mediante Wayland compartido.
  • Algunos piden demos y una explicación más clara en la página principal sobre en qué se diferencia NSL de Docker/Distrobox y qué problemas resuelve de forma única.

Documentación, nombre y ecosistema

  • Varios comentarios señalan un uso intenso de LLMs en el sitio web/README; las reacciones van desde “Claudisms” insoportables hasta “sorprendentemente bueno para estar asistido por LLM”.
  • Se discuten el nombre (NSL/WSL) y la historia de “Windows Subsystem for X”, en su mayoría como curiosidad.
  • Algunos se preocupan por una mayor fragmentación de herramientas frente a adoptar soluciones existentes de contenedores/entornos de desarrollo (Nix, mise, etc.).