bketelsen

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.

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!

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.

Hi Brandon!

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.

you could, and if that's your preference https://nspawn.org is just right.

challenge accepted!

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.

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!

super quick turn around. Left a GH issue, need to bump internal package version to match deb version: https://github.com/generalaction/emdash/issues/1091

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.

That's clean. Nice.

I didn’t make it a real URL intentionally because i’m not trying to steal attention/clicks from OP’s interesting project.

nice! I made github.com/frostyard/plow last week with a serverless take on this (just for debian repos though). Being served by gh-pages means no git-lfs support though. repogen might be a better option if any packages get too big.

I did exactly this, put it in a 2U case. Fantastic performance, but even with the best Noctua I could put on it the CPU fan sounds like a Hawker Harrier doing VTOL when it's under load. Don't regret the board, but wish my rack was in another room now.

Normally I'd nod and smile at the nix documentation joke, but mkosi's documentation is the man pages, or the man pages.

Sweet! Tried it out and found two small snags, so I sent two pull requests.