Post

@algernon oh I'll be very interested in following that
I've been trying both multiple times, and then ended up going back to Debian and or kubernetes respectively

...and Quickbeam & my desktop will be hard to migrate. My Mom's likely staying on NixOS, because it works for her, and she does not like change. She wouldn't benefit from switching to Guix.

My desktop & Quickbeam will be harder, because they're physical PCs in my homelab. I can't spin up a new one, and delete the old.

I have to do actual in-place migration. That'll suck. But - at least in case of my desktop - it lets me correct some early mistakes.

@pabryan My main concern with GNU is mostly RMS himself, and to a lesser extent, with the project sometimes making impractical choices (wrt non-free, for example: the reality is that as much as I'd love to, I can't have a fully free system. making it harder for me to run non-free software is not helping me choose Guix).

Regarding impermanence: yep, that is pretty much it. My / is tmpfs, during boot, the system builds symlinks to various places in the Store, and uses symlinks, bind mounts, and other tricks to link permanent storage to places they need to be linked to. Eg, /persist/system/apps/foo/var/lib/foo gets bind-mounted to /var/lib/foo if foo doesn't like symlinks. Or it gets symlinked if that's okay.

RAM use is tiny, becuse it's 90% symlinks, and 10% tiny generated files. On this laptop I'm tooting this from (my wife's, actually), / is a 128MiB tmpfs, with 248k used. I usually set a much smaller / (~8MiB). Boot time is within margin of error vs non-tmpfs. The declaration itself isn't stored on the machine as-is. The derivation built from it is in the Store. I believe this is common between both Guix and NixOS.

I mean, when I boot, the configuration is not rebuilt on the fly. That would be slow and unnecessary. I boot into a derivation built from a configuration, same as without impermanence. The only difference is that / is tmpfs, and a bunch of stuff gets symlinked or bind mounted.

I'm using impermanence everywhere: on all three of the NixOS-based servers I operate, on my desktop, on my wife's laptop, and on my Mom's miniPC. I do not see any scenario where I wouldn't use it.

I know all of this is doable with Guix - I had a long experiment with both Guix and NixOS a few years ago when I wanted to choose between the two. It's just a pain in the backside to rewrite something like my infra config, and then another big pain to actually migrate the servers.

Though, migrating the servers should be - in theory - easier: deploy Guix on a new server, copy the persisted data over, done. But I'm sure it will not be that easy in reality.

@gaborudvari @anemofilia Oooh, that configuration looks fantastic! On codeberg, tmpfs as /, btrfs subvolumes, opendoas instead of sudo!

So many things to borrow.

@trivial second point being systemd?

Well, Guix uses Shepherd. Up until recently, I had no desire to change from systemd. It's not perfect by any means, but it beats shell scripts and most alternatives, and some of its features like socket activation, hardening stuff are things I use every day.

But like so many things, systemd went down the slop path, and I can no longer justify using it. So I'm willing to lose some convenience and niceties, and use shepherd.

@dlakelan I don't want to tie it to btrfs. I currently use tmpfs as /, and wish to keep it that way. Every boot is a clean boot from declarative config + explicitly saved permanent state.