Show HN: NSL – WSL for Linux

Original Article ↗ Hacker News Discussion ↗

A new tool called NSL aims to bring a WSL2-style experience to Linux by running a lightweight VM that hosts multiple systemd-nspawn containers, providing isolated “pet” environments for development without polluting the host system. Commenters compare it to existing options like Distrobox, toolbx, LXC/Incus, and plain VMs, debating trade-offs in isolation, performance, host integration, and ease of use. Some praise the UX and packaging for making this workflow more accessible, while others question the need for yet another layer and express unease about the project’s apparent reliance on AI-generated documentation.

Architecture & Approach

  • NSL aims to bring a WSL2-like experience to Linux: a single “host” VM running multiple systemd-nspawn containers.
  • The VM is launched via systemd-vmspawn; inside it, instances are systemd-nspawn containers, not Docker/Podman or LXC.
  • This is positioned as “pet” VMs/instances with limited but convenient host integration, rather than disposable containers.

Comparison to Existing Tools (Distrobox, toolbx, LXC/Incus, VMs, etc.)

  • Distrobox/toolbx: Typically mount the host $HOME and are designed as overlays on the host environment; NSL intentionally does not, favoring isolation of dotfiles, PATH, and system libs.
  • LXC/Incus: Provide container-based “full systems” without a VM; NSL adds a VM layer for stronger isolation and the option of a different kernel.
  • Traditional VMs (qemu/multipass/Vagrant): NSL is pitched as lighter-weight, headless by default, sharing the host’s Wayland session when needed rather than running a full desktop.
  • Some see it as redundant given existing tools; others argue the main differentiator is UX and packaging, not raw capability.

Use Cases & Motivation

  • Primary goal: keep the host OS “clean” from dev dependencies and experiments that can subtly break the system.
  • Common use case: running IDEs or dev toolchains in a different distro than the host, with easy terminal and file access but without polluting the host.
  • Some users mention using it to safely let AI agents install system-level dependencies.

Security & Isolation

  • Several comments stress that containers are weaker security boundaries than VMs; the VM layer is seen as stronger isolation, though not perfect.
  • Concern is raised that NSL’s host integration (files, ports, windows) may still allow breakouts unless extra isolation flags are used, which may hurt UX.

Performance & Practicalities

  • Performance impact vs native or pure containers is asked about; no concrete benchmarks are provided in the thread.
  • Graphics support via shared Wayland is noted as a plus.
  • Some request demos and clearer homepage explanations of how NSL differs from Docker/Distrobox and what problems it uniquely solves.

Docs, Naming, and Ecosystem

  • Multiple comments note heavy use of LLMs in the website/README; reactions range from “unbearable Claudisms” to “surprisingly good for LLM-assisted.”
  • Naming (NSL/WSL) and the history of “Windows Subsystem for X” are discussed, mostly as trivia.
  • A few worry about further tooling fragmentation versus adopting existing container/dev-env solutions (Nix, mise, etc.).