WSL-style Linux machines for Linux hosts.

161 points•bketelsen•1 day ago•101 comments•
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 sharing come along for the ride, just like WSL. Take a look and tell me what you think... It's yet another step in my long journey to keep my host installation free from all the changing and breaking dev dependencies that force a reinstall every few months.

101 comments

rao-v1 day ago
I have to say this is nice packaging. It is weirdly not obvious how nice it is to cleanly use a different “machine” inside your desktop.

I never thought I’d prefer WSL to even my MacBook for working with remote servers and dev but somehow I do.

I of course know the many ways to roll something like this for myself, yes dev containers are better for many things etc. but it’s wierd how good the ergonomics of a WSL like container are.

bketelsen1 day ago
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.
Have you tried mise? It handled most of that for me because dev environment is exactly what is needed per project
rao-v1 day ago
I use mise inside WSL. It's sort of a terminal into "workspace" for me. Should probably spin an orbstsck or whatever to do thisnon my macbook
dathinab1 day ago
How does it differ from existing tools kinda do exactly same, like e.g. toolbx. (And to a slightly lesser degree flatpack, snap, etc.)?

And what prevented adopting/supporting existing projects, instead of further tool ecosystem fragmentation? (kinda the same question, just differently phrased)

philips1 day ago
Ha! I wrote the first commit to CoreOS's toolbox in 2014: https://github.com/coreos/toolbox/commit/dc4aa0b14bceafd6afa...

And then I read your comment and my first reaction was, oh, they typoed toolbox. But, nope, Red Hat created toolbx which confusingly has the CLI binary of `toolbox`: https://containertoolbx.org

bketelsenabout 21 hours ago
Hi Brandon!
bketelsenabout 21 hours ago
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.
just60secabout 9 hours ago
Yeah, I can see why you'd want this. Being able to cobble it together with other tools is one thing. Having it ready to go without a bunch of setup is still a win.

Got a quick demo? Just opening an editor, running a dev server, and showing how you access the files would help me get a feel for it.

lprovenabout 13 hours ago
I have never heard of "Snow Linux" before. The homepage is minimal:

https://snowlinux.org/

I submitted the Github page as a new story:

https://github.com/frostyard/snowdesktop

https://news.ycombinator.com/item?id=49907568

martijnvdsabout 11 hours ago
Snow Linux was a thing way back in the 90s: https://archive.org/details/snowlinux2.2

The company behind rebranded to SUE.

bketelsenabout 11 hours ago
that repo is retired, now all the Frostyard atomic images build out of a single mkosi repo at https://github.com/frostyard/snosi. the website is https://frostyard.org - I'll take down the older snowlinux.org or redirect it. Thanks!
lprovenabout 11 hours ago
Holy cr4p that is a wall of text on the repo! :-o

Is that massive amount of bumf machine-generated?

0x4571 day ago
I'm confused why VM + systemd-nspawn? From my understaing WSL 2 runs a single VM + something like systemd-nspawn per "linux installation", but it runs a VM because it needs linux kernel. Why not just do systemd-nspawn if you alread on linux?
pkulak1 day ago
Way better isolation, is my guess. Plus, you can use a different kernel this way.

I used to poo-poo when people said that containers aren't a _real_ security boundary, at least for personal stuff, and not a multi-tenant server. But I bet even mid-tier LLMs can break out of LXC/Docker/nspawn at this point.

avadodinabout 16 hours ago
> Plus, you can use a different kernel this way.

Any kernel could be the last to support old nVidia drivers for your $10k card.

fhn1 day ago
can they not break out of a VM?
bketelsen1 day ago
you could, and if that's your preference https://nspawn.org is just right.
bityard1 day ago
I was surprised I hadn't heard of this as a separate tool from systemd-nspawn. Then I realized why... the GitHub repo shows version 0.6 released in 2022, then version 1.0.0 last week, followed by a flurry of releases up to 1.8.0 yesterday.

So basically, it's been all Claude'd up extremely recently.

That said, the landing page, docs, and git README are much higher quality than I normally see out of LLM-generated projects, so at least the author knows how to reign in the needless verbosity and write for a technical audience. So I will give him credit for that at least.

0x4571 day ago
Neat, I wasn't aware of this tool. I just either run nixosContainer in systemd-nspawn or OCI image in systemd-nspawn.
delusional1 day ago
Claude told him to do it this way.
nateb20221 day ago
I'd trust OP to make good architectural decisions/provide guidance even if AI mostly wrote the docs and UI. Looking into their GitHub, seems they are an engineering manager at Microsoft and contribute semi regularly to uBlue and Project Bluefin. Should be better quality than some random vibeslopper.

Read the full thread on Hacker News →

Related stories