bketelsen
bketelsen on Hacker News
These kinds of projects bring me joy. Well done
I used my paper route money saved up for 2 or 3 months to buy a C80 when I was in 5th grade. I loved that thing so much. It was a fun moment of nostalgia clicking on this link.
I hadn't seen this before, at first glance it looks interesting. I'll check it out, thanks!
the README is probably 50/50 hand written and LLM written. We haven't really done much to publicize the org yet, we were waiting for bootc to stabilize on Debian. Tomorrow is actually retirement day for the non-bootc installation paths so we may do some clean up in the future. Don't really have a burning need to become the next hot distro though. If atomic debian desktops and servers sound good we're here.
It really depends on how much of that other distro you really want/need. NSL's benefit for me is that it's headless unless I need a graphical app, then it shares the host's Wayland. My most common use case is an IDE inside a completely different distro from the host. If you want the whole desktop environment from your VM then NSL isn't your best route.
That was my go-to for the past 8+ years as well. In fact, a different angle on this same problem I wrote is Blincus:
https://blincus.dev I think I lost the plot on it though and tried to do too much, automate too much.
Hey one of the authors here. Surprised to see the submission. Happy to answer questions.
I'd love to hear your thoughts on it afterwards, either here or as an issue on GitHub.
... it's not. Just another way to keep my host clean and do the dirty work somewhere else. Where did reproducible builds come through? Another comment?
Most of these tools you mention are designed to work best as an overlay to your $HOME. toolbx, distrobox, and to some extent flatpak and snap. NSL is built to give you the "pet" virtual machines with limited integration to the host - you can get to the host filesystem if you want, and you can use the host's Wayland session. I think a better comparison would be using NSL instead of using a remote computer or VM.
Thanks for saying so! That's exactly why I wrote this. The UX of wsl2 is just right. There are a lot of other ways to accomplish this, but none touch that same experience.
none of the above. a single vm started by systemd-vmspawn which then starts one or more containers for your instances using systemd-nspawn. It ends up being fast and lightweight.
WSL2 uses a shared VM that does host integration (networking, shared files, permanent storage for each instance). NSL uses the same model but with Linux native technical implementations.
As for keeping my host clean - it's the developer's curse that always gets me. Install libWhatever3.2-dev because you need it to compile something, then don't realize until next time you open Chrome that it broke your system in some subtle way. There are dozens of ways to solve this like devcontainers, docker, incus, fully separate or remote vms. I like the WSL2 model so I wanted that same UX.
Distrobox mounts $HOME in the container at $HOME by default. WSL and NSL do not, and that's my preference. This means you can install tools that change your default path, change your dotfiles, etc, without affecting the host. The other obvious difference is that distrobox is powered by podman or docker, while NSL uses a VM that runs systemd-nspawn containers.
Posted by
bketelsen on Tuesday September 29, 2026 @10:51AM
from the show-hn dept.
https://frostyard.github.io/nsl/
One of the things that Windows really got right is WSL2. I drive an atomic Linux distro for daily use, but wanted a way to develop with multiple different distros with that same WSL UX. NSL is my answer. It is a faithful reproduction of the developer experience, powered by a single VM that hosts one or more systemd-nspawn containers with your development instances. Host file edits and port...
I kind of love this. Are you going to open source it?
Always good to see Joe doing interesting things. mecatl looks interesting, to say the least. I had a tour through the code and I can already think of a dozen ways to use this.
Admiral Akbar would approve
When GitHub released their status update feature I re-imagined finger for the modern world:
https://github.com/bketelsen/finger I didn't advertise it, nobody cared. But it was fun.
nice! I built one of these too and the thing that made it most useful was a GitHub action that other repos could use. You should put that on your backlog.
This looks really nice. Excited to find some time to test it out. I frequently have the same needs and godom looks like a great fit.
Looks slick. Linux version please!
this looks great, but can't test, the .deb package is broken with an issue about NODE_MODULE_VERSION mismatches. There seems to be a PR waiting for approval. Will keep an eye on it.