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.