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

@algernon i know you've had plenty of assistance already, but if you need it, i have some notes for the install process itself:

https://git.spork.org/guix-impermanence-init.git/about/

@bjc thanks! Bookmarked, will ping you when I get around to play more with guix, if I get stuck :)

@algernon

What exactly is so bad about #nix?

@gaborudvari @anemofilia @algernon Neat. Would be nice to offer impermanence as an option.

Another thing that will play a major role here: GCD008. I feel it would be pointless to migrate from NixOS to Guix if Guix doesn't have a reasonable GenAI/LLM/whatever policy.

It's bad enough that core components I have to use are tainted. I do not wish my operating system to be full of its own layer of slop, too.

But as this is a 2027 project, there's a non-zero chance that the bubble will burst by then, and all this will be largely irrelevant.

@civodul @gaborudvari @anemofilia @algernon i went looking to do that a couple months ago, but found it really difficult to work with the installer code and was having trouble finding docs for it, or even people familiar with it on irc, for that matter. if you have hints, i'll take 'em, because i'd still like to do it.

@bjc @anemofilia @gaborudvari @algernon I wouldn’t necessarily look at the installer, but rather at OS configuration.

Now that I think about it, Nicolas Graves actually submitted patches going in that direction (I even reviewed them!):
https://issues.guix.gnu.org/65335

Looks like a good starting point.

@civodul vanilla guix has no problem with tmpfs root these days, but having to drop to the terminal to install it might seem a bit harrowing, at least vs. a nice "install on impermanent root" option.

more people should use impermanence! (i am a zealot, i know) it works really well without any setup, since guix already does everything you need at boot anyway. i want to make it easy =)

@anemofilia @gaborudvari @algernon

Predictably, I can't stop thinking about Guix, and am starting to Plan™, regardless of the outcome of GCD008. My thinking is, even if there's no reasonable LLM policy, heck, even if there's a policy but a bad one, Guix would be easier to fork.

Or rather, Guix would be an easier foundation to strip apart and build something new from, than NixOS & nixpkgs, should it come to that.

I'm also seeing far fewer slop wranglers lurk around Guix than around NixOS, so the amount of damage they can cause before the bubble bursts is likely to be a lot smaller.

I'm kind of warming up to channels, and will have my own too. Kind of like Avalanche (a NixOS flake of mine that has derivations and whatnot for a couple of things I needed), but less shit.

Maybe channels are nicer than flakes, I'm starting to think.

@algernon I'm slightly curious about the initial operating system installation experience, but not enough to check. The NixOS one was one of the things that scared me away.

I am, of course, highly opinionated about this. I want a scripted, fast installation, since I have that for Debian.

@liw I'm not sure how I will install Guix. The only thing I know is that I will not go through an installer, neither GUI nor TUI.

For NixOS, I had a declarative configuration, and I used nixos-anywhere to install it. No human input, fully automatic, fully scripted. Wasn't exactly fast, because it downloaded a ton of binary packages - but the bottleneck was my bandwidth. That's an acceptable bottleneck.

My plan is to do something similar with Guix. Like you, I want (nay, will have) a scripted, reasonably fast installation.

The experience will be documented in a blog post.

Not quite sure at this time whether I will need multiple files, or if I'll be able to shove my entire configuration into a single scheme file.

Will I need N files for every system? Or can I have all my systems in a single file?

One of the best things about my current NixOS setup is that it's barely more than a single flake.nix (it's also an SSH key and a bunch of secrets, and some wallpapers). I like this because the various hosts can refer to others!

Like, on Quickbeam, where my Prometheus lives, if I want to scrape the metrics of iocaine (on Eru), I can use nodes.eru.config.systemd.sockets."iocaine-metrics".socketConfig.ListenStream, and won't have to repeat the same info twice, nor will I need to use noweb refs to embed the single truth two times to different places.

I guess in Guix, I could arrange my systems into some kind of module, and import the relevant parts as appropriate.

But... that requires arranging them into modules. A huge advantage of my NixOS flake was that I didn't need to do that. It's just one big beautiful mess.

@algernon I have this feeling that adding support for any operating system that has a tool with the shape of debootstrap (i.e., installs a bare bones root file system to a directory) would be possible to support with my installer. One would need to add a step to do the bootstrapping, and probably a couple more to add extra packages and setting up a bootloader, but the rest should be there already.

If I had time to work on this...

@liw Yeah. The gist of nixos-anywhere is basically that: kexec into an image that has all bootstrapping tools, build the configuration, do the partitioning, mount the target partitions, copy the config to the target, activate it.

Activating a configuration is provided by the OS, and takes care of setting up the bootloader, packages, and so on. In my case, partitioning was also provided by the OS (via a third-party module). Building & copying the configuration is also part of the OS.

So all nixos-anywhere really had to do is kexec, and call a few scripts in order.

Eh, I guess there's not much difference between (use-modules (algernon systems)) and then referring to bits and pieces of system configs, and having multiple nixosConfigurations in a single flake.

Though, the question I have now is: if I have an (operating-system ...) defined in one module, can I refer to a part of it, like I do in the NixOS case (nodes.<system>.config.<blah>)?

I can lift the parts I need shared out into a dictionary/alist/whatever you call it in scheme, but it would be nicer if I didn't need to, if I could directly refer to another property of another system, deep within its configuration.

In other news, if I want to have a channel, looks like that will need multiple files - at least if I want news (which I might, that sounds like a good thing).

Hmmm hmm. I'll have to think long and hard about how I do channels and development environments.

One big question is, whether I want something like Avalanche in the first place? Or do I just make the channel part of my infrastructure.org repo?

Also... what if the source is literate?

Quite a few things to explore here.

@algernon @pho4cexa be warned that packaging Rust software in particular is something of a sisyphean task on Guix. It often means packaging the package and its dependencies and its dependencies' dependencies and its dependencies' dependencies' dependencies and so forth

@stellarskylark @algernon @pho4cexa

I think the packages available on creates.io are the most convenient to package on Guix. just `guix import -i path/to/rust-apps.scm crate abc` `guix import -i path/to/rust-crates.scm crate abc -f path/to/Cargo.lock and adjust something

@Z572 @algernon @pho4cexa one of the times I crashed out and switched distros from Guix was when I wanted to update nushell to the latest version because it was extremely behind. it was somewhere around updating/adding package definition 200 that I gave up and also decided I don't care for Rust's dependency resolution model

@algernon according to impermanence. Nicolas Graves did it, he even contributed necessary utils to RDE, but not finished a write up yet. You can ping him on codeberg or email.

@liw @algernon 'nixos-install' might already be close to this (standard part of NixOS, https://www.mankier.com/8/nixos-install), though ironically IIRC it might be tricky to install on non-NixOS systems 😊.