Guix System First Impressions as a Nix User

There are plenty of options: nix-sops, or nix-age, or whatever you would like - past the overall idea the implementation details are purely a matter of taste how you fancy things to be. Key idea is to have encrypted secrets in the store, decrypted at runtime using machine-specific credentials (host SSH keys are a typical option to repurpose, or you can set up something else). For local management you also encrypt to the “developer” keys (under the hood data is symmetrically encrypted with a random key and that key is encrypted to every key you have - machines and humans).

Alternatively, you can set up a secrets service (like a password manager/vault) and source from that. Difference is where the secrets live (encrypted store or networked service, with all the consequences of every approach), commonality is that they’re fetched at runtime, before your programs start.

I’m currently using deploy-rs, but if I’d redo my stuff (and the only reason I don’t is that I’m pretty much overwhelmed by life) I’d probably go with plain vanilla nixos-rebuild --target-host and skip any additional layers (that introduce extra complexity and fragility).

Just a crude and somewhat haphazard summary but hope it helps.

nixos-anywhere to create, deploy-rs to deploy. sops-nix for secrets. Works great.

I seemingly went what I consider simple, others might consider barebones: I have a Makefile, define all the hosts there, and then use scp to copy over all files into the right hosts, and then run `nixos-rebuild switch` on them once copied over. Some have extra "restart-service-X" as some services have their configuration managed outside NixOS (but still in my source repository) so those as well are scp'd into the right place, then the service restarted after the nixos-rebuild switch. Otherwise it's all .nix files and service-specific configuration files.

I struggled with remote deployment + secret management, too. Like a lot of folks, my nix-config grew over the years as I added secrets management, user management etc ad hoc.

I recently found clan.nix [1] and am quite pleased. It's kind of a framework for writing nixos configurations with a focus on multiple devices. It bundles secrets management and remote deployment into a convenient CLI.

It has the concept of "services", which are e.g. used for user management and VPNs. Services define roles, which can be assigned to machines, e.g. the wireguard service has a controller and a peer role. That feels like the right abstraction and it was very easy to set up a VPN with zerotier like that, something I struggled doing myself in the past.

It's a rather young project, but I converted my nix-config repo after a short evaluation phase to use clan. It's worth taking a look for sure.

[1]: https://clan.lol/

> programmatically create a file or dir for every user of a certain group

To be fair here, NixOS module system also makes this a breeze. Whether via `systemd.tmpfiles` or via generated scripts.

It might be nicer to have some more DSL capabilities in nix though.

Unfortunately, some packages which are free software can only be found in nonguix, due to Guix wanting to be able to build everything from source. So things like Gradle that require a huge bootstrap chain that no one yet has bothered to do are instead packaged in nonguix as a binary download.

Wouldn't that just make it harder to bootstrap an OS, needing to start with JVM and all...

Is there a need to "modernise" it?

I have a non-shallow clone and the .git directory is less than 3GB.

Interesting, I have taken a stab at maintaining a repo on the nixpkgs and using a --sparse approach, i.e. `git clone --filter=blob:none --sparse --branch nixos-25.11 https://github.com/NixOS/nixpkgs.git nixpkgs-dorion cd nixpkgs-dorion`

I remember thinking about doing that, but found value in having my fork tell me when was the last time I synced with upstream which was something useful to assess if I wanted to rebase my patch once again. Eventually my change got upstream and I stopped tracking my own fork though.

Modern NVIDIA drivers for their more recent cards are actually okay, again.

AMD cards need propietary firmware.

Honestly back when I was still in college one and a half decade ago, it was quite clear the whole Nvidia-only ML and AI libraries weren't a good idea

I went with AMD for compatibility playing games, but AFAICT AMD ROCm is not in a great state for computation. Why can't I have both?

That's something like what they're describing as "a nightmare," isn't it? "As agreements and law allows," is part of the nightmare. Under a modern OS, it should not be difficult to have the full capability of the hundreds or thousands of dollars worth of hardware you paid for.

NVIDIA drivers work perfectly fine, when you decide from the beginning to use them, instead of attempting to first use alternatives like nouveau.

The only problems appear when your Linux distribution decides for some reason to make difficult for its users to choose the NVIDIA drivers, like GUIX. On distributions where the users can choose NVIDIA freely, like Gentoo, which I am using, there are no problems whatsoever with NVIDIA. I have used the NVIDIA drivers for Linux and for FreeBSD during more than 20 years, on many kinds of desktops and laptops, with no problems. All this time I have also used Intel GPUs and AMD GPUs, and especially with the latter there have been problems more frequently.

Unfortunately, some of the Linux kernel developers actively try to sabotage the NVIDIA kernel driver from time to time, e.g. by imposing restrictions on the kernel symbols that it may import, which is certain to complicate the work of the maintainers of the NVIDIA drivers, and which can cause problems for the Linux users who are not aware that for this reason they must have a version of the NVIDIA driver that is matched to their kernel version.

I much prefer to have only open-source privileged code, but it cannot be said that NVIDIA has not done a good job with their Linux (and FreeBSD) support, which has been much better than that of almost any other hardware vendor. Only Intel had even better support for their hardware, including not only CPUs and GPUs, but also networking, WiFi etc. However, even with Intel, their Linux GPU drivers have been frequently worse than their Windows GPU drivers (like also with AMD), unlike NVIDIA, where their Linux drivers always had the same performance as the Windows drivers.

While non-professional users may not encounter many problems with the Intel or AMD GPUs, any user that has needed more complex OpenGL applications has frequently encountered problems in the past when the Intel or AMD OpenGL implementation in their Linux drivers was incomplete or buggy in comparison with NVIDIA. Such problems were easily exposed by just running popular benchmarks like SPECviewperf or the Unigine benchmarks on Linux and comparing what you see with an NVIDA GPU with what you see with an AMD or Intel GPU. The Intel and AMD drivers have improved in recent years (or more accurately, Mesa is what has improved), but previously it was hard to use under Linux non-NVIDIA GPUs for any really demanding graphic application.

I'm writing this on machine with a 1660 TI on Guix with the open source(ish) drivers from nonguix and it works just fine.

Eh, I think it's that with Nixlang one can write

  foo.bar = true;

as a shorthand for

  foo = { bar = true; };

which makes deeply-nested options much easier to write out. In general Nix looks a lot more like a config file to me.

> Guix channels in use:

> - guix (additional patches are used locally for root on ZFS support)

i'm hopeful too, but think it may not be so simple (yet) >u< here's a more precise link

https://codeberg.org/guix/guix/pulls/1917#issuecomment-69760...

Thanks! A very nice set of configs. I've done something similar for NixOS and my LAN but never advanced at such point in Guix.

You have a statistical point of view that doesn't go into detail enough: yes, Debian, Ubuntu, Mint are mainstream distros and use ext by default. The vast majority of their users are also mainstream users and would never approach declarative distros, which are alien to them.

Those who choose going declarative instead are people with operations knowledge, who understand the value of a system ready to be built, modified, and rebuilt with minimal effort thanks to the IaC built into the OS, who understand the value of their data and therefore babysit them properly. The average user of Debian, Ubuntu, Mint today doesn't even have a backup, uses someone else's cloud. If they run experiments, they waste storage with Docker, or use manually managed VPSs; they don't own a complete infrastructure, let alone a modern one.

So thinking about them for Guix means never letting it take off, because those users will never be Guix users. ZFS is the opposite of complicated; it's what you need to live comfortably when you know how to use it, which unfortunately isn't mainstream, and declarative distros do the same.

NixOS succeeds despite the indigestible Nix language because it offers what's needed to be comfortable to those who know. Guix remains niche not because of GNU philosophy but because it doesn't do the same, not offering what those coming from operations are looking for and they are the most potential realist target users.

I don't consider myself a "believer" in anything, but as a sysadmin, if I see a deploy with ext4, I classify it as a newbie's choice or someone stuck in the 80s. It's not a matter of conviction; it's simply about managing your data:

- Transferable snapshots (zfs send) mean very low-cost backups and restores, and serious desktop users don't want to be down for half a day because a disk failed.

- A pool means effective low-cost RAID, and anyone in 2026 who isn't looking for at least a mirror for their desktop either doesn't care about their data or lacks the expertise to understand its purpose.

ZFS is the first real progress in storage since the 80s. It's the most natural choice for anyone who wants to manage their digital information. Unfortunately, many in the GNU/Linux world are stuck in another era and don't understand it. They are mostly developers whose data is on someone else's cloud, not on their own hardware. If they do personal backups, they do them halfway, without a proven restore strategy. They are average users, even if more skilled than average, who don't believe in disk failures or bit rot because they haven't experienced it personally, or if they have, they haven't stopped to think about the incident.

If you want to try out services and keep your desktop clean, you need a small, backup-able volume that can be sent to other machines eg. a home server, to be discarded once testing is done. If you want to efficiently manage storage because when something breaks, you don't want to spend a day manually reinstalling the OS and copying files by hand, you'll want ZFS with appropriate snapshots, whether managed with ZnapZend or something else doesn't really matter.

Unfortunately, those without operations experience don't care, don't understand. The possibility of their computer breaking isn't something they consider because in their experience it hasn't happened yet, or it's an exceptional event as exceptional that doesn't need automation. The idea of having an OS installed for 10 years, always clean, because every rebuild is a fresh-install and storage is managed complementarily, is alien to them. But the reality is that it's possible, and those who still understand operations really value it.

Those who don't understand it will hardly choose Guix or NixOS; they are people who play with Docker, sticking to "mainstream" distros like Fedora, Ubuntu, Mint, Arch. Those who choose declarative distros truly want to configure their infrastructure in text, IaC built-in into the OS, and truly have resilience, so their infrastructure must be able to resurrect from its configuration plus backups quickly and with minimal effort, because when something goes wrong, I have other things to think about than playing with the FLOSS toy of the moment.

>Easier to format automatically than Lisp

You wish. Emacs did that for free since the 80's.

Same here, I'm 22 and Uncle Bob sold me on the Lisp language. Reading SICP and Land of Lisp gave me a newfound appreciation for programming and design.

Bikeshedding over the language is a huge waste of time, too.

I haven’t written a line of Nix since I started using it, yet it defines three of my systems. I just read diffs that an LLM created when editing my config.

Making a big deal about the language substrate feels like someone still trying to argue over vim vs emacs. It’s trivial and uninteresting.

How the errors/debugging compare? From what I've read this is the main pain point with Nix where a more mature language like Guile should have a much better experience here. The article touches on this but I'd be curious of a more extensive comparison about this aspect.

And which an LLM/AI model can apply the huge training set of Lisp/Scheme to help solve your problem.

Nixlang is so infuriatingly obtuse that I generally have to fire up Discord and bug the local Nix acolyte when something goes wrong. I've bounced Nixlang off of the LLM/AIs, but I have learned that if the AI doesn't give you the correct answer immediately for Nixlang then you need to stop; everything forward will be increasingly incorrect hallucinations.

I suspect LLM/AIs will hallucinate far, far less with the Scheme from Guix.

What? From what I've seen Nix configs and Guix configs look nothing alike in terms of structure. Guix uses Scheme modules whereas Nix modules are just fancy dicts merged together lazily. Which is sad because I like Lisps but I prefer the Nix way of structuring the config.