What happened

The author runs an atomic Linux distro day to day: the system updates as a unit, and installing compilers, SDKs, and project dependencies straight on the host is the opposite of the point. On Windows, WSL2 solved that pain: a separate development environment, the same project files, ports on 127.0.0.1. NSL ports that pattern to Linux. One VM hosts one or more machine containers; they start when needed and keep packages, services, and files between sessions.

The commands mirror the familiar gesture. nsl create debian --distro debian:13 creates a machine and verifies the signed image. nsl from a project directory opens a shell in the default machine on the same files. nsl run make test runs one command and returns its exit status to the host. $HOME, /run/media/USER, and /mnt appear under /mnt/host; inside the machine you keep your username, UID/GID, and passwordless sudo. A development server’s ports land on host localhost; Wayland apps can open windows on the desktop through Waypipe.

Seven distros are available: Debian, Ubuntu, Fedora, CentOS Stream, Arch, openSUSE Tumbleweed, and Leap. Images rebuild weekly, and NSL checks they came from Frostyard’s signed publishing workflow before use. For software you do not trust, --isolated gives a separate VM without host files, desktop, or host actions. nsl itself runs as your user and does not install packages or rewrite groups, device permissions, or sudoers — host prerequisites come first. It is still pre-release: v0.4.0 is the first release of this design; the tested host is Snow Linux 13 on x86-64 with specific systemd, QEMU, and virtiofsd versions.

Why it matters

Atomic and immutable Linux hosts are pleasant daily drivers and a poor fit for “install everything into the system.” Developers either break immutability or juggle ad-hoc containers and VMs without one shared habit. NSL aims at the WSL model: the development environment is a furnished apartment, and the host is your permanent address that should not absorb every package you try.

Signed images and weekly rebuilds reduce the “download a random rootfs and hope” risk. Isolation mode admits that not every experiment should see your home directory. For people who already learned WSL gestures on Windows and moved to Linux, that lowers the cost of keeping the same muscle memory.

In practice

There is no stable release yet, so treat NSL as an idea and an early tool, not a company standard. It fits an atomic desktop, several distros for different stacks, and a desire not to dirty the host. It fits less well if you need mature support for every machine outside the tested host matrix.

1. Check host prerequisites before install — nsl will not configure packages and permissions for you.
2. Create the first machine with nsl create … --distro … and confirm signature verification succeeds.
3. Keep build tools and SDKs inside the machine; keep sources on the host via /mnt/host.
4. Use --isolated for untrusted utilities so they do not see your home directory and desktop.
5. Read the architecture notes and nsl.conf before building a permanent workflow around NSL.

Takeaway

NSL answers a simple request: leave the Linux host clean and still keep several full development environments with a WSL-like UX. The tool is early, but the model is clear — one VM, systemd-nspawn machines, host files and ports, signed images, and harder isolation when you need it.