Switching to GNU Guix: A Beginner's Perspective
34 points by tusharhero
34 points by tusharhero
A fundamental difference between Guix and Arch Linux is that Guix is a source-based distribution at its core, backed by substitute servers that distribute prebuilt binaries.
If a newly pulled channel commit has not yet been built by the substitute build farm (such as ci.guix.gnu.org or Bordeaux), your machine will fall back to compiling the packages locally.
I wish that Guix would do things differently. Instead of waiting for the packages to land on master to build them, they should be built first and promoted to the main branch after the artifact has been built.
In particular the way they aren't following the Not Rocket Science Rule is
[changes are] the tested in isolation and then integrated on the basis of that test (with no guarantee that the integrated combination works).
Re: substitutes, I had this same thought when I considered dipping my toes into Guix as a Nix user. The whole point of the build cache is to not have to build things yourself.
That said, I'm definitely not an expert and there may be a way to configure channels such that you always hit the cache. In Nix-land for example there a multiple branches/channels of varying stability you can pull from (though they have already populated the cache by the time the commit hits them, as far as I can tell).
Nix channels move forward after Hydra finishes building them, so if you follow a channel, you should always hit the cache. If you follow the underlying git branch, though, you might be ahead of Hydra when you update.
sure. But defaults matter. Nongnu has to exist because of the G in Guix. This doesn't, especially considering that their prior-art does it right.
I'm not an expert either. afaiu providing the binary cache (substitute servers) is tied to cuirass. One can configure Curiass to subscribe to branch (channel) to start building jobs. What I'm less clear is what notion of identity the binary cache uses. If I have two branches with the same commit ID, will the binary cache be populated for any commit with the same ID?
In theory, having a branch guix committer manually commit to, e.j. how the master branch is used today, and having cuirass push to another branch (f/e main) the contents of the master branch after it has been build successfully should be enough to ensure that there are always binary assets available. At the cost of lagging behind the master branch, which could be a drawback when trying to distribute security fixes as quickly as possible.
In general, one of the things I really liked from nixpkgs and the nix ecosystem was there devops culture. There are other things I wish Guix did differently, several are at related to, lets do things more like the nix ecosystem.
To answer your specific question:
If I have two branches with the same commit ID, will the binary cache be populated for any commit with the same ID?
Yes. If Cuirass has already built that commit on one branch, why would moving the same commit to another branch require rebuilding it?
why would moving the same commit to another branch require rebuilding it?
It doesn't require it. But it depends on how are things being looked up on the cache. Since I don't know the specific implementation details I didn't want to assume. In theory the cache doesn't even have to depend on the VCS, only on the package inputs and code for the package itself (the actual scheme code that says which build system to use and modifies what to do on each phase)
Guix doesn't wait for packages to land on master to build them. Cuirass and Hydra work similarly in that changes can be built on other branches, and the resulting binaries can be made available from substitute servers/binary caches. If the resulting derivation is the same after the change lands on master, then it doesn't need to be rebuilt just because it was merged.
A major practical difference is that Nix has considerably more build capacity, so its build farm tends to catch up faster and binaries become available sooner. On the other hand, it’s super easy and fun to run a Cuirass instance on your own hardware (even a cheap Pine board) and then provide your own substitutes for things you need in your specific setup.
A major practical difference is that Nix has considerably more build capacity, so its build farm tends to catch up faster and binaries become available sooner
That is not the reason. Unlike Guix, When a PR lands of nixpkgs' master branch, it does not become immediately available for users of the unstable channel. Only after hydra (the cuirass equivalent) has built all the tests for that commit does it get promoted to the unstable branch. Between landing a change and the change being available to the users a couple of days can pass. source.
Both nixos-unstable and nixpkgs-unstable follow the master branch of the Nixpkgs repository, although both do lag the master branch by generally a couple of days.
There is a pr-tracker tool to see on which channels a PR is already available. You can see that the latest merged PR is not available on any channel yet: https://nixpk.gs/pr-tracker.html?pr=538275. While a PR from yesterday is only available on the unstable-small channel: https://nixpk.gs/pr-tracker.html?pr=562749
So yes, nixpkgs has a more powerful buildfarm, but that is not the reason why the binary cache is up to date. Its become they don't release the channel to users until the binary cache is up to date with that commit.
If the resulting derivation is the same after the change lands on master,
That is exactly the thing that the Not Rocket Science Rule is warning against. If you are only testing things in the PR, which is likely not up to date with the latest main branch, you are not testing the code that actually lands on the main branch.
You're conflating a pull request CI potentially not testing the exact eventual master state with whether a previously built identical Guix derivation can be reused. Those are separate issues. If the derivation on master is genuinely the same derivation, then by definition the inputs relevant to that derivation haven't changed in a way that alters it. Build capacity still affects how quickly that promotion can happen, but that’s separate from the derivation-reuse point.
They are different things, but the drift is what results in the binary cache misses. If there was a different branch where commits are pushed (ff-only, no merged) only after all the packages have been rebuild then there wouldn't be any misses.
However, as I explored deeper, documentation in NixOS became a major source of friction.
This is why some years ago I chose Guix for my home servers and personal setups over Nix. I really like being able to read and search documentation locally, as well as having one place for the answers to most of my questions. And the Guix documentation is written in a way that I feel promotes users using what they read to build things, not just giving precise instructions on how to do one thing (or worse, just dropping something for a user to copy and paste).
It’s interesting reading the perspective of a Guix user who has not even a passing interest in Nix. Some of the things the author described in this post, like being able to host their entire Guix configuration and all its services and branches in Git, are also features of Nix, but because they're new to this type of distro generally this fact doesn't occur to them. It’s refreshing to see Guix being talked about in a context that doesn't compare it to Nix. It would be great if we could get the Lobsters tag changed so that Guix and Nix discussions can be more independent of each other.
Also, Hugo and Caddy aren't available due to Guix's strict rules surrounding packages being able to be built from source to be allowed into its channel. Go dependencies are often hard to track down and circular, which makes many complex packages really hard to package from source. I'm glad the author chose to use readily available alternatives. I'd recommend Haunt as a replacement for Hugo so that they can build their static site in Scheme.
My understanding of Guix has evolved over the years. I've stopped thinking of it primarily as a distro; it's a tool for building reproducible packages, containers, environments, images, and systems. Building an operating system with Guix is a major use case, but only one of many. Looking at it through that lens, I've become a lot more forgiving of what it lacks as a distro, and more appreciative of what community efforts like Nonguix provide.
Go dependencies are often hard to track down and circular, which makes many complex packages really hard to package from source.
Having tried to package opentofu recently, the friction wasn't due to the requirement of building from source. But to the decision of the go-build-system to map each dependency into a single package/input. So packaging one application can result in having to package hundreds of other packages. It is possible to structure the build system to take a single input with all the source code for the go dependencies which would make the process of packaging applications easier. Hako's Rosenthal channel actually implements that approach in its go-vendored-build-system. Which is why they can also package caddy for Guix by writing only one package.
The Rust team in guix 'recently' revamped their packaging process to differentiate between applications and libraries that are only a dependency for an application and packaging rust apps in Guix is now much simpler. Kudos to Guix's Rust team!
I've stopped thinking of it primarily as a distro; it's a tool for building reproducible packages, containers, environments, images, and systems.
Indeed things like guix home container or guix shell's integration with containers are great examples on how better worlds that Containerfile or podman play are possible and available now!
I haven't paid attention to the mailing list in a while and didn't know the Rust team made this change! Hopefully the Go team follows suit, because I'd really like to package k3s.
Yeah, nix documentation is so scattered and is very often web only. There is a REPL, but any kind of REPL-driven development with nix is very non-intuitive.
I vastly preferred the documentation and tooling around Guix, with the caveat that it very much assumes that you use emacs.
I agree that the Guix documentation is much better, but this
and is very often web only
is not really true. In fact, when I (briefly) worked on the Nix documentation one of the blockers for a handful of improvements was the requirement that we still be able to render the (entire!) Nix and NixOS manuals as manpages!
Ah, it could be that this has changed more recently? I tried it a few years ago, and then the REPL wouldn't have documentation for all functions and I couldn't find the input parameters for the experimental features of the nix CLI in the manpages.
The official Guix channel has strict libre standards and a smaller catalog than the Arch User Repository (AUR). Common utilities like hugo and caddy are not present in the official channel.
Adding other channels is not something to do without evaluating the tradeoffs but it can help you out with having more packages available. With toys you can search channel's of other community members. You can see that the Roshental channel, which has its own subsitute server package Caddy. There is also binary-guix which packages a lot of 'devops' related programs by distributing their binary releases instead of building form source. It can serve as a stop gap measure to get things running.