To be fair, WSL mounts all your drives under /mnt/ by default, which I would argue isn't any better, arguably even worse.

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.

The website's Claudisms are unbearable.

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.

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.

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.

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.

Which?

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

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.

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?

Now all you have to do is run NSL under WSL.

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.

> 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).

---

"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...

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.

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

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.

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.

Ideas/issues/PRs are welcome.

The architecture decisions, etc are dictated by me as well :)

If you have any suggestions, etc, they are welcome.

Anyway, should this be called LSL or WSLL? Or maybe LSWSL.

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.

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.

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.

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

I think I'll stick to Nix & Podman.

Will try to give it a spin later.

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.

The benefit is that its super low overhead (no VM).

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/

https://snowlinux.org/

I submitted the Github page as a new story:

https://github.com/frostyard/snowdesktop

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

Is that massive amount of bumf machine-generated?

Gosh. OK then.

The company behind rebranded to SUE.

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.

- https://sdme.io

- https://www.youtube.com/watch?v=1eVfgzd_xyQ