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.
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.
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.
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.
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.
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.
PuercoPop | 10 hours ago
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
zmitchell | 9 hours ago
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).
jaculabilis | 3 hours ago
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.
kwas | 8 hours ago
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.
PuercoPop | 2 hours ago
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.
elais | an hour ago
To answer your specific question:
Yes. If Cuirass has already built that commit on one branch, why would moving the same commit to another branch require rebuilding it?
elais | an hour ago
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.
elais | an hour ago
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.
mccd | 32 minutes ago
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.