Big Plan for 2027: explore the viability of migrating my infra from #NixOS to #Guix.

Previously, I had three major concerns: GNU, my reliance and investment in systemd, and package availability.

The latter isn't terribly hard to address. The second is no longer a concern. That leaves GNU, but even there, nixos has worse entities near it than GNU.

I will have to figure out how to replace impermanence and home manager, but the former is also a concern with nixos, because upstream recently dropped a feature I use, and do not wish to stop using.

@algernon
Theres guix home so that should handle declarative home settings.

impermanence is an interesting issue. not sure if theres something similar. i wonder if you can use a btrfs snapshot. write some scheme code to take a snapshot and mount that to / during boot at each boot so it always goes back to the snapshot contents initially

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

@algernon can you elaborate on the second point? I've vaguely had the thought to check out Guix in the future, but I haven't made any efforts yet, so it'd be good to know :)

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

@algernon @anemofilia uses #guix with a tmpfs root:

https://codeberg.org/anemofilia/zero

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

So many things to borrow.

@gaborudvari @algernon @anemofilia wow. That looks like a fantastic setup! I'll will try that out when I get a chance :)

@algernon what is the concern with gnu?

Also, impermanence sounds intriguing. Am I understanding correctly: you have /nix (/gnu/store in guix) on some partition and that works as usual. When you boot, the system builds the various links to /nix, creates config files and whatever else you have in your nix declarations (declarations are stored where? On /nix as well, or /boot?). The result is a tmpfs mounted on /.

How's the boot times? I guess since it's mostly links, the RAM use for the tmpfs is pretty modest. Do you use it for say a laptop? I'm curious how it runs.

That all seems doable in principle with guix. But I'm very much a beginner here and have no idea how much work would be needed to actually make it happen...

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

@algernon i have good news my friend.

i have an impermanence setup and instructions from when i did it. and going from nix home to guix home is no problem.

join us.....

@algernon one neat, if useless, thing you can do is keep /nix and /gnu on the same btrfs filesystem, since everything else is constructed at boot on impermanent /.

@bjc There will be no time when both /gnu and /nix will exist. There is /nix now, and there will be /gnu after. Migration will be:

1. Spin up new VPS, with Guix.
2. Restore /persist from backup.
3. Reboot to let everything start up correctly.
4. Delete the old NixOS VPS.

I'll take this opportunity to rearrange the filesystems, my original setup had some bad decisions.

One other thing I will have to figure out wrt Guix is encrypted disk + Clevis + Tang, and ssh + wireguard on initramfs as fallback.

And something like sops-nix (but as far as I see, a similar thing exists for Guix aswell) so I can have reasonable secret management.

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

@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

@4censord Not sure how useful this part of my distro-hopping¹ journey would be to you, because I'm going NixOS->Guix, declarative to declarative. That's a much smaller change than going Debian->declarative, and I expect the outcome between NixOS and Guix to look very similar in spirit.

But as usual, when it comes to doing it, I will be live tooting it. :)

---

1. 4 distros in 30 years! SHOCKING! ↩︎

@algernon i found this to be the most helpful statement ever, for setting my expectations about guix

https://solarpunk.moe/@stellarskylark/116537038791992542

i'm not put off by it yet, still want to try it out, but now i can brace for impact with the differences i'll experience coming from 100% debian and get less frustrated

(tyvm @stellarskylark)

@pho4cexa @stellarskylark I am a proud freak pervert, because I enjoy writing and updating package definitions.

My desktop needs are also tiny: Emacs, Alacritty, Niri, LibreWolf. Everything else is optional, and I can do without if need be. I don't need the latest from either - except maybe LibreWolf, but patchelfing someone else's binary is fine for my usecases. I can easily keep all four of these updated to the versions I need - but chances are, most of them will be sufficiently recent in Guix too.

@pho4cexa @algernon @stellarskylark you might have to write more package definitions, but at least doing is easier with guix than it is with debian

@algernon @pho4cexa @stellarskylark all four of those are already packaged

@noisytoot @stellarskylark @pho4cexa Packaging is not an issue. I can - and did, at various point in my life - build policy compliant deb packages with nothing but sh, tar and ar (and make, if the source has to be policy compliant too). And I enjoyed it. Scheme is much more enjoyable than that.

I'm unironically a masochist freak pervert in this regard. :)

@pho4cexa @algernon I had Guix running my website for a while and it was nice *except* that each system generation was like 2GB so the store kept growing to consume all available disk space on my tiny (16G) cloud VM. I *think* I could've avoided that by doing system rebuilds externally on some nice beefy CI machine, instead.

Also there were a couple nasty Shepherd memory leaks but I believe those have been fixed now.

I kinda want to try my hand at rewriting syslogd/journald in Guile.

@zwol @pho4cexa I'm doing system rebuilds on an external machine with Nix too, so that shouldn't be an issue with Guix.

Now syslogd/journald... that'll be a tough cookie. I like the idea of journald. Never liked the implementation, but the idea is great. Will have to figure something out about my logs.

Chances are, I'll simply route them to /dev/null, except for the few I already route to VictoriaLogs through Vector.

OTOH... there are cases where my services log to stdout. Will have to pipe that to Vector somehow. Will have to check if Shepherd can help me there.

@pho4cexa @algernon Guix's lead dev is @civodul on here, FYI