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.
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.
I'm very curious about this - as a mise user this seems like a redundant extra level of abstraction that I can't figure out the benefits of (& WSL definitely comes with at least some downsides).
From the OP I see:
> my long journey to keep my host installation free from all the changing and breaking dev dependencies that force a reinstall every few months
mise does this 100% for me (assuming we don't count mise itself as one of those dev dependencies). I'm struggling to think of what falls outside of it?
i agree. you can quickly import distro images into named WSL VMs (distros) to keep things separated. and you get close-to-native performance (especially by disabling kernel mitigations)
No need for mise just run separate wsl “distros” (VMs ) eg Debian-node , debian-Claude by importing root images . I use alpine because each one is tiny
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?
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.
That has to be the host kernel not the guest kernel. Old Nvidia systems without supported kernel drivers often lack IOMMU to forward PCIe memory, too. I wouldn't recommend using an outdated host kernel with 2026 AI-powered vulnerability scanners.
Windows (10 LTSC or 11 with dTPM) actually works better for old Nvidia systems with WSL. You even get CUDA libraries within WSL and security updates for the next 5 years.
CVEs for runc are much more frequent than CVEs for KVM. The attack surface area is bigger, and containers were never intended as a security boundary, but rather as a resource management tool.
it is quite likely that you can break out even with no linux containers related CVEs. --isolate does seem to fix that somehow but is explicit opt. in and "more painful to use" ... (which creates a UX challenge unlikely to end well from a security POV).
I was just testing this and it's not clear that it works out of the box. `krun` shows a different kernel than with `crun` but it doesn't reflect the dropped capabilities in the same way. I'm probably holding it wrong but I'm not sure what to look for at the moment.
"During a test conducted by Trail of Bits researcher Artem Dinaburg, a preview version of GPT 5.6-Cyber was tasked with breaking out of a Debian 12 virtual machine. Initially, the agent exploited a known Linux kernel vulnerability, CVE-2026-53359, by developing its own exploit. After the host was updated, the agent found another pathway through libslirp, chaining a known vulnerability (CVE-2026-9539) with a previously unassigned bug to gain arbitrary host memory access. Even after QEMU and libslirp were updated, the agent analyzed system components and constructed a new escape chain using three zero-day vulnerabilities and one KVM flaw that had not yet reached the distribution kernel.
These findings suggest that general-purpose VMs may not be adequate security boundaries for highly capable AI agents, especially in older systems with delayed security updates. Trail of Bits recommends using specialized isolation systems like Firecracker, restricting VM access, and implementing rapid patching to mitigate these risks."
Can confirm. My abliterated models kept breaking out of qemu VMs due to BIOS implementation quirks in qemu.
I'm using firecracker now with a very defensive systemd-as-separate-non-admin-user seccomp sandbox on top, which seems to hold them off long enough for me to see an agent going rogue and intervening.
Currently I still have hopes that eBPF sandboxing will help, but just a couple days ago my agent discovered a use after free bug in the ebpf kernel-side verifier... so there's that.
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.
nspawn maintainer here. Yes, it has been done with the help of AI (the README has a clear AI usage disclosure), but I have been writing Rust code since a very long time ago, before agentic coding was a thing (you can check my GH profile). Every change is reviewed by me, and the architecture/implementation is dictated by me as well.
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.
Hi, nspawn maintainer here, that's not the case. I have been working with code/software architecture/design since a very long time before agentic coding was a thing. nspawn uses AI to help write code (the README has a clear AI usage disclosure) but every change is reviewed by me.
The architecture decisions, etc are dictated by me as well :)
If you have any suggestions, etc, they are welcome.
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)
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
... 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.
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!
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.
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.
I was wondering the same thing. Distrobox mounts $HOME by default, but it’s trivial to give a distrobox its own $HOME.
Can you explain the advantages of systemd-nspawn containers versus podman/docker? I’m not familiar with systemd-nspawn, but I’m a regular user of distrobox and podman.
Nspawn is a full system container engine with its own systemd environment, which makes it closer to LXC/Incus than Podman/Docker. You can do the single process thing in system containers or use a full init system in Docker/Podman, but the experience won't be as smooth.
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.
This is most useful to people who run Linux as their daily driver so rather than saying its like WSL can you explain what it offers that existing Linux containers do not?
Its also sounds different from WSL which I thought is a VM rather than a container.
> 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.
Something that also require a bit of explanation. What do you do that makes this such a common problem.
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.
Hah! One would wish so but they do. `/usr/local` usually has preference over `/usr` and libraries that use a plugin architecture often break when you update but forget to recompile plugins.
And once you go into FFI for interpreted or JIT compiled languages it turns into hell. Both Python and Java creates huge headaches when you have multiple versions of the same libraries in various /usr subdirs.
I often helped lab students who read a simple `make; make install` tutorial for OpenCV and permanently messed up their Python installs.
So a single VM with multiple containers within it? Interesting, but I think you should make it immediately clear on your site. Persistence is not the USP because there are lots of ways that you can get persistent VMs or sandboxes.
It makes an image and runs it in separate namespace. It can start at bash or init. It's very fast but there seem to be a problem creating an Ubuntu image on Debian and vice versa.
I'm a bit of an outsider here (I don't understand computer) but a few weeks ago I was wrestling with the question of deploying an application on many boxen. After looking into Docker (and unikernels, lol) I arrived at the conclusion that "the operating system is part of my application."
A very bloated "part", which I did not write, don't understand very well, and which spontaneously self-modifies. An OS is a big bag of global mutable state! Ew!
This made me very sad. (At which point I was informed that I had basically reinvented NixOS from first principles?)
Also something about "we don't break userspace -- that's libc's job!"
this whole thing is a misunderstanding from legacy docker semantics. you can easily use namespaces in systemd as user in lighter ways, for example, keeping the rootfs but protecting home and binding a private tmpfs, or to bind a completely different rootfs, providing a vm-like experience. Please read the documentation before vibe coding; the name wsl for Linux just shows how lost you are.
The name WSL has always struck me as a bit back area (LSW would seem to make more sense, since it is a Linux subsystem for Windows). I guess they mean it as a Windows Subsystem for Linuxing.
Anyway, should this be called LSL or WSLL? Or maybe LSWSL.
It's an issue because Linux is a trademark. Microsoft cannot call something a "Linux something" without infringing a trademark, but they can say something is "for Linux" the same way third-party companies could market e.g., WordPerfect for Windows. Hence Windows Subsystem for Linux, mirroring the old Windows Services for Unix:
It's a subsystem instead of "services" because WSL1 really was an NT subsystem: a "kernel personality" that knows how to interpret Linux system calls just like the DOS and OS/2 subsystems of early NT.
The naming is a bit awkward now, but an original design goal of the Windows NT kernel was the ability to host different types of OS "personalities" (userspace, essentially) on top of the Windows kernel, and these are called "subsystems." Win32 is one such subsystem, although there was no need to formally call it "Windows Subsystem for Win32" because everyone understood that it was just Win32 ported to NT.
The NT kernel designers came from VMS, and during development MS made various half-hearted promises that NT would be able to run VMS software as well but never actually followed through. If they had, there would likely have been a Windows Subsystem for VMS.
Nope. This is a VM, with containers inside. And the containers weren't "re-implemented", it uses existing systemd containers. That's what I was able to learn by skimming the site for 30 seconds. Did you not even do that? And why even be so condescending to someone else's project?
Because it does seem like we already have tools that skin this particular cat, it's valid to wonder what value this project provides over existing solutions.. even if they chose the wrong example to compare it to. Why do you think that's condescending?
LXC is a jail and qemu is an extra layer of emulation. Why pay that extra cost? Just because it serves a wsl image isn't really an answer. How is that worth the extra layer?
I've wanted a little more isolation than what distrobox can give me for a while now, and I did enjoy WSL when I used Windows. I've also never heard of Frostyard before, and the other repos look pretty interesting as well. Thanks for sharing!
Is the VM layer mostly for host hygiene, or are you also treating the instances as a real security boundary when something untrusted (deps or agent-written code) runs inside?
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.
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.
Exactly opposite, gonna test it out today for a pet project since I can let Claude go haywire inside if it needs to install any deps from systemside. Similar stuff exists, but this seems lightweight enough for experimentation.
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.
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.
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
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
I'm very curious about this - as a mise user this seems like a redundant extra level of abstraction that I can't figure out the benefits of (& WSL definitely comes with at least some downsides).
From the OP I see:
> my long journey to keep my host installation free from all the changing and breaking dev dependencies that force a reinstall every few months
mise does this 100% for me (assuming we don't count mise itself as one of those dev dependencies). I'm struggling to think of what falls outside of it?
i agree. you can quickly import distro images into named WSL VMs (distros) to keep things separated. and you get close-to-native performance (especially by disabling kernel mitigations)
not sure I follow the context of this comment - did you mean to reply to me?
No need for mise just run separate wsl “distros” (VMs ) eg Debian-node , debian-Claude by importing root images . I use alpine because each one is tiny
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?
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.
> Plus, you can use a different kernel this way.
Any kernel could be the last to support old nVidia drivers for your $10k card.
That has to be the host kernel not the guest kernel. Old Nvidia systems without supported kernel drivers often lack IOMMU to forward PCIe memory, too. I wouldn't recommend using an outdated host kernel with 2026 AI-powered vulnerability scanners.
Windows (10 LTSC or 11 with dTPM) actually works better for old Nvidia systems with WSL. You even get CUDA libraries within WSL and security updates for the next 5 years.
can they not break out of a VM?
It's at least harder! Better chance it'll hit your 5-hour limit before it does. haha
See my response to the above comment
CVEs for runc are much more frequent than CVEs for KVM. The attack surface area is bigger, and containers were never intended as a security boundary, but rather as a resource management tool.
through just from scanning the feature side
> Your files and your account [..]
> Ports and windows on the host
it is quite likely that you can break out even with no linux containers related CVEs. --isolate does seem to fix that somehow but is explicit opt. in and "more painful to use" ... (which creates a UX challenge unlikely to end well from a security POV).
libkrun exists so we can just run containers inside a virtualized environment without special tooling
I was just testing this and it's not clear that it works out of the box. `krun` shows a different kernel than with `crun` but it doesn't reflect the dropped capabilities in the same way. I'm probably holding it wrong but I'm not sure what to look for at the moment.
Yes, and have.
---
"During a test conducted by Trail of Bits researcher Artem Dinaburg, a preview version of GPT 5.6-Cyber was tasked with breaking out of a Debian 12 virtual machine. Initially, the agent exploited a known Linux kernel vulnerability, CVE-2026-53359, by developing its own exploit. After the host was updated, the agent found another pathway through libslirp, chaining a known vulnerability (CVE-2026-9539) with a previously unassigned bug to gain arbitrary host memory access. Even after QEMU and libslirp were updated, the agent analyzed system components and constructed a new escape chain using three zero-day vulnerabilities and one KVM flaw that had not yet reached the distribution kernel.
These findings suggest that general-purpose VMs may not be adequate security boundaries for highly capable AI agents, especially in older systems with delayed security updates. Trail of Bits recommends using specialized isolation systems like Firecracker, restricting VM access, and implementing rapid patching to mitigate these risks."
---
https://www.scworld.com/brief/ai-agent-repeatedly-escapes-vi...
Can confirm. My abliterated models kept breaking out of qemu VMs due to BIOS implementation quirks in qemu.
I'm using firecracker now with a very defensive systemd-as-separate-non-admin-user seccomp sandbox on top, which seems to hold them off long enough for me to see an agent going rogue and intervening.
Currently I still have hopes that eBPF sandboxing will help, but just a couple days ago my agent discovered a use after free bug in the ebpf kernel-side verifier... so there's that.
So this is the death of "Stable" finally?
you could, and if that's your preference https://nspawn.org is just right.
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.
nspawn maintainer here. Yes, it has been done with the help of AI (the README has a clear AI usage disclosure), but I have been writing Rust code since a very long time ago, before agentic coding was a thing (you can check my GH profile). Every change is reviewed by me, and the architecture/implementation is dictated by me as well.
Ideas/issues/PRs are welcome.
Any issues/features requests are welcome. Thanks for bringing it up here.
Neat, I wasn't aware of this tool. I just either run nixosContainer in systemd-nspawn or OCI image in systemd-nspawn.
Claude told him to do it this way.
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.
Hi, nspawn maintainer here, that's not the case. I have been working with code/software architecture/design since a very long time before agentic coding was a thing. nspawn uses AI to help write code (the README has a clear AI usage disclosure) but every change is reviewed by me.
The architecture decisions, etc are dictated by me as well :)
If you have any suggestions, etc, they are welcome.
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)
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
Hi Brandon!
Oh, hey Brian! I like the project. How is it related to reproducible builds though?
... 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?
I just had never heard of "frostyard" and the github.com/frostyard page says: Foundation for Reproducible OS Technologies
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.
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
Snow Linux was a thing way back in the 90s: https://archive.org/details/snowlinux2.2
The company behind rebranded to SUE.
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!
Holy cr4p that is a wall of text on the repo! :-o
Is that massive amount of bumf machine-generated?
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.
:-o
Gosh. OK then.
How does this compare to distrobox?
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.
> WSL and NSL do not, and that's my preference.
To be fair, WSL mounts all your drives under /mnt/ by default, which I would argue isn't any better, arguably even worse.
I was wondering the same thing. Distrobox mounts $HOME by default, but it’s trivial to give a distrobox its own $HOME.
Can you explain the advantages of systemd-nspawn containers versus podman/docker? I’m not familiar with systemd-nspawn, but I’m a regular user of distrobox and podman.
Nspawn is a full system container engine with its own systemd environment, which makes it closer to LXC/Incus than Podman/Docker. You can do the single process thing in system containers or use a full init system in Docker/Podman, but the experience won't be as smooth.
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.
This is most useful to people who run Linux as their daily driver so rather than saying its like WSL can you explain what it offers that existing Linux containers do not?
Its also sounds different from WSL which I thought is a VM rather than a container.
> 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.
Something that also require a bit of explanation. What do you do that makes this such a common problem.
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.
Stick non-distro libs into /usr/local and they can't break anything.
Hah! One would wish so but they do. `/usr/local` usually has preference over `/usr` and libraries that use a plugin architecture often break when you update but forget to recompile plugins.
And once you go into FFI for interpreted or JIT compiled languages it turns into hell. Both Python and Java creates huge headaches when you have multiple versions of the same libraries in various /usr subdirs.
I often helped lab students who read a simple `make; make install` tutorial for OpenCV and permanently messed up their Python installs.
So a single VM with multiple containers within it? Interesting, but I think you should make it immediately clear on your site. Persistence is not the USP because there are lots of ways that you can get persistent VMs or sandboxes.
Have you ever heard of Nix, direnv, Lorri, flakes, devShell etc.? Aren't containers overkill for most dev activities?
I'll give this one a try, thanks for sharing!
FWIW, I'm currently using systemd-nspawn via mkosi: https://github.com/systemd/mkosi
It makes an image and runs it in separate namespace. It can start at bash or init. It's very fast but there seem to be a problem creating an Ubuntu image on Debian and vice versa.
Nice. Cool that it supports graphics too!
I'm a bit of an outsider here (I don't understand computer) but a few weeks ago I was wrestling with the question of deploying an application on many boxen. After looking into Docker (and unikernels, lol) I arrived at the conclusion that "the operating system is part of my application."
A very bloated "part", which I did not write, don't understand very well, and which spontaneously self-modifies. An OS is a big bag of global mutable state! Ew!
This made me very sad. (At which point I was informed that I had basically reinvented NixOS from first principles?)
Also something about "we don't break userspace -- that's libc's job!"
https://blog.hiler.eu/win32-the-only-stable-abi/
Haha, I was getting ready to bring up NixOS until you mentioned it.
this whole thing is a misunderstanding from legacy docker semantics. you can easily use namespaces in systemd as user in lighter ways, for example, keeping the rootfs but protecting home and binding a private tmpfs, or to bind a completely different rootfs, providing a vm-like experience. Please read the documentation before vibe coding; the name wsl for Linux just shows how lost you are.
The name WSL has always struck me as a bit back area (LSW would seem to make more sense, since it is a Linux subsystem for Windows). I guess they mean it as a Windows Subsystem for Linuxing.
Anyway, should this be called LSL or WSLL? Or maybe LSWSL.
It's an issue because Linux is a trademark. Microsoft cannot call something a "Linux something" without infringing a trademark, but they can say something is "for Linux" the same way third-party companies could market e.g., WordPerfect for Windows. Hence Windows Subsystem for Linux, mirroring the old Windows Services for Unix:
https://en.wikipedia.org/wiki/Windows_Services_for_UNIX
It's a subsystem instead of "services" because WSL1 really was an NT subsystem: a "kernel personality" that knows how to interpret Linux system calls just like the DOS and OS/2 subsystems of early NT.
The naming is a bit awkward now, but an original design goal of the Windows NT kernel was the ability to host different types of OS "personalities" (userspace, essentially) on top of the Windows kernel, and these are called "subsystems." Win32 is one such subsystem, although there was no need to formally call it "Windows Subsystem for Win32" because everyone understood that it was just Win32 ported to NT.
The NT kernel designers came from VMS, and during development MS made various half-hearted promises that NT would be able to run VMS software as well but never actually followed through. If they had, there would likely have been a Windows Subsystem for VMS.
Notably there was Windows subsystem for OS/2 though
OS/2 subsystem, for Windows NT :). And a few others: https://helparchive.huntertur.net/document/52712
It’s to do with trademark usage as I understand it.
It is continuing a historic naming "accident", the precedent having been set by Windows Services for UNIX and similar in the 90s/00s.
I now prefer WSL over Darwin, especially with agents because I can easily scope disposable "VMs" that have a clean terminal integration.
It's neat seeing this experience come to linux.
Sure you "could" do this with a bunch of tools, but it's the UX that matters.
Creative idea to fix something that nobody thought was broken, but actually was.
So you've just basically reimplemented LXC?
Nope. This is a VM, with containers inside. And the containers weren't "re-implemented", it uses existing systemd containers. That's what I was able to learn by skimming the site for 30 seconds. Did you not even do that? And why even be so condescending to someone else's project?
Because it does seem like we already have tools that skin this particular cat, it's valid to wonder what value this project provides over existing solutions.. even if they chose the wrong example to compare it to. Why do you think that's condescending?
The condescending way the comment was written...
Well I think that's being a little sensitive, frankly..
LXC is a jail and qemu is an extra layer of emulation. Why pay that extra cost? Just because it serves a wsl image isn't really an answer. How is that worth the extra layer?
EDIT to not be a dick about it: I think the key detail here is the difference in isolation between containers and VMs, and where emulation comes in.
Just a reminder that the Hacker News community generally frowns on caustic dialog. Let's make sure this place doesn't turn into slashdot. :-)
Agreed. Edited. I do feel like I was just following the existing tone set by OP, but no excuse.
What differentiates this from distrobox?
How does this compare to "sdme"?
- https://sdme.io
- https://www.youtube.com/watch?v=1eVfgzd_xyQ
I hadn't seen this before, at first glance it looks interesting. I'll check it out, thanks!
At first glance the main difference seems to be that NSL uses virtual machines with systemd-vmspawn and sdme uses containers with systemd-nspawn
Nice flip of the WSL idea the other way — simple interop like this keeps a one-person stack from turning into a VM zoo.
Looks very cool.
Now all you have to do is run NSL under WSL.
challenge accepted!
I've wanted a little more isolation than what distrobox can give me for a while now, and I did enjoy WSL when I used Windows. I've also never heard of Frostyard before, and the other repos look pretty interesting as well. Thanks for sharing!
Just a recommendation that difference between docker container and nsl on homepage is worth it
Always looking for a successor to https://developer.hashicorp.com/vagrant. Is this it?
Is the VM layer mostly for host hygiene, or are you also treating the instances as a real security boundary when something untrusted (deps or agent-written code) runs inside?
I use incus/LXD for this, though it does require a bit of faffing around with the networking.
The benefit is that its super low overhead (no VM).
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.
Have you measured the performance penalty when compiling code in one of the containers against compiling on the host system itself?
The project is cool, but please use human written text.
The website's Claudisms are unbearable.
'National security letter' for Linux?
I think I'll stick to Nix & Podman.
would really like a NixOS for this. would be interesting to play with and figure out.
This is very cool. GG.
someone has to ask the question: can you run lsl in wsl?
There's already Distrobox, which does exactly the same thing but isn't slop.
This handles use cases Distrobox can't, they both have a place.
> This handles use cases Distrobox can't
Which?
Already explained with examples upthread:
https://news.ycombinator.com/item?id=49896422
Why is this better than just spinning up another distro in a VM?
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.
Nobody wants this
Exactly opposite, gonna test it out today for a pet project since I can let Claude go haywire inside if it needs to install any deps from systemside. Similar stuff exists, but this seems lightweight enough for experimentation.
I'd love to hear your thoughts on it afterwards, either here or as an issue on GitHub.
So I was working with some graphics related stuff and since I think I don't have GPU passthrough, then I could not use it directly this time.
Gladly (Y)
Will try to give it a spin later.
IS it LXC containers or docker? Or are you running a custom chroot namespace setup?
He runs a systemd-nspawnd container in a "small vm", so neither really?
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.
Oh cool thanks for the info!
It's an interesting project.
Are these systemd containers comparable to lxc containers or better maybe?
This could be a really interesting alternative to fully featured LXC containers.
Ubuntu has a similar cli tool you probably know about called multi-pass but it just spins up Ubuntu distros.
The issue I had with multipass was how difficult it was to access and backup files, I guess it was meant for more of a disposable container.
Haven't checked the actual project but he does state he uses systemd-nspawn. Which is it's own kind of container runtime.