LWN: Comments on "A look at Nix and Guix"

Grafts / runtime dependencies replacement

Rutherther — Wed, 14 May 2025 09:12:11 +0000

I would like to comment on a minor inaccuracy. It is not true that NixOS doesn't have a feature like grafts. It does have it. They have a function replaceDependency / replaceDependencies. It is just that while in Guix, grafts are used in the main channel, Nixpkgs doesn't use them at all.

In nixpkgs, if there is a change that triggers rebuild of a lot of packages, they put it to staging branch. This branch is built by CI and merged roughly every two weeks. Guix doesn't have as big build farm to make that sustainable, grafts are much faster for security updates.

A look at Nix and Guix

jrw — Fri, 22 Mar 2024 02:12:00 +0000

Page 11/15 of https://archive.org/download/198706ByteMagazineVol1207Bon...

A look at Nix and Guix

jrw — Fri, 22 Mar 2024 01:50:46 +0000

I found the paper I remembered: Bill Gates, "Beyond Macro Processing," BYTE Bonus Edition, Summer 1987. Subtitled "A strategy for customizing applications software".

A look at Nix and Guix

jrw — Thu, 21 Mar 2024 19:34:16 +0000

That Emacs Thesis is a oldie but goodie. Somewhere I have a ripped-out magazine article (from Byte magazine?) from the 1980s written by Bill Gates which discussed the same thing and I'm sure the concept is much older than that. I can't seem to work up enough DDG-fu to find that article mentioned on the internet however. I worked on a project based on that architecture (low-level kernel/toolkit with clean API; application written in interpreted extension language) in the late 80s at IBM Research. It truly was a delight.

A look at Nix and Guix

Foxboron — Thu, 14 Mar 2024 10:46:19 +0000

I should read better. It's not really using "Reproducible Builds" at all an is only talking about build environments, which is very much what the static build-paths represents.

Equating this paper with reproducible builds is the mistake here, not them misusing any words.

A look at Nix and Guix

Foxboron — Thu, 14 Mar 2024 10:36:55 +0000

I re-read the paper and this is wrong as well. This paper is just misusing the "Reproducible Builds" definition from the Reproducible Builds project. It's checking if you can reproduce the build paths which has nothing to do with the build outputs.

From RQ1:

> Therefore, we adjust RQ1.2 slightly into: assessing whether we can reproduce identical output paths for all the jobs (as we can always retrieve historical Hydra output paths).

From RQ2:

>Besides, for now, we do not check for *bit-by-bit* reproducible builds [ 16 ]. Extending our evaluation to build more revisions and checking for reproducible builds are both part of our future plans

So they have redefined "reproducible builds" to mean "can we reproduce the build-paths" and schewed the Reproducible Builds definition to "bit-by-bit reproducible builds" which is just misleading and extremely dissapointing.

A look at Nix and Guix

Ivar — Mon, 11 Mar 2024 18:48:06 +0000

I think Nix has the same level of extensibility, everything it provides can be overwritten or added to, as I assume is the case with Guix.

The concepts of channels maps directly to Nix as well, there you could also define (and easily share!) and additions you've made using channels or flakes. The central package/configuration module repository, nixpkgs, exposes all of it's infrastructure to help you out with this.

The tooling itself doesn't treat nixpkgs differently from any other channel/flake, you could in theory use the primitives provided by the Nix language to recreate everything from scratch without it. There isn't much of a point to rewriting the entire universe, but its possible!

A look at Nix and Guix

gioele — Mon, 11 Mar 2024 12:44:33 +0000

> A 4 page article claiming "some buildsystem is reproducible in this experiment" isn't particularly interesting when actual Linux distros are reproducing ~90% of their published packages in the real world.

This is a misreading of the paper.

The paper results are:

> Our results show that we can achieve 99.99% reproducibility of build environments over 7 010 516 packages coming from 200 historical revisions of Nixpkgs, the Nix package set. Additionally, we were able to rebuild 99.94% of the packages from a 6-year-old Nixpkgs revision, demonstrating that reproducibility of build environments is actually useful for software rebuildability.

"This experiment" is rebuilding 99.94% of all the packages of a 6-year-old revision of a distro. "Actual Linux distros", cannot reproducibly build that many packages today, nor are able to do that for older revisions.

A look at Nix and Guix

Foxboron — Mon, 11 Mar 2024 12:34:43 +0000

A 4 page article claiming "some buildsystem is reproducible in this experiment" isn't particularly interesting when actual Linux distros are reproducing ~90% of their published packages in the real world.

A look at Nix and Guix

Nebucatnetzer — Fri, 08 Mar 2024 19:26:36 +0000

There has been a nice study about the reproducibility of Nixpkgs[1].

[1]: https://telecom-paris.hal.science/LTCI/hal-04430009v1

A look at Nix and Guix

Foxboron — Thu, 29 Feb 2024 19:43:52 +0000

All distros build in a sandbox, there is not *really* a lot of magic to it and the benefits are shared.

The fact that NixOS does other things, like setting timestamps to 0 and the like, is not a property of the sandbox itself.

A look at Nix and Guix

shreyansdoshi — Thu, 29 Feb 2024 14:31:16 +0000

Thank you so much for this write-up, I am trying to dip my toes into this world and have been trying to find a resource that would concisely explain some of the salient differences between the two so I could decide which one I should try first since they are quite deep rabbit holes. This gives me a good starting point. :)

A look at Nix and Guix

zimbatm — Thu, 29 Feb 2024 14:21:14 +0000

A better comparison is the Gnome ISO, including the build dependencies: https://reproducible.nixos.org/nixos-iso-gnome-r13y/, but that also includes all the fetch URLs, as far as I know.

There is some truth in the sense that some variance in reproducibility is removed when using Guix/Nix because of the build sandbox. It removes some classes of reproducibility.

But without all the effort that Debian, Arch and other distros have put into reproducibility, the above graph wouldn't be at ~95%. The real hero is the https://reproducible-builds.org/ project.

A look at Nix and Guix

nrdxp — Wed, 28 Feb 2024 19:16:05 +0000

Long time Nix user here, since about 2015. Used Arch for quite some time before that. I have to say that, in all that time, I have never seriously regretting switching to NixOS on my dev machines, and even some of my build servers. In my early days there were some major frustrations with the language and module system, in particular ridiculously complex infinite recursion errors with baffling traces. I've learned enough by now to almost never have to deal with them anymore, but it took a significant amount of time and effort, and I was already acquainted with functional programming paradigms before I even began, so I don't blame newcomers for finding the whole thing a little too complex.

With that said, the reliability and recoverability are just leagues ahead of anything else out there I've used, and for me at least, it was all well worth the trouble. Not to mention the fact that my configuration has been tracked in a git repo for all that time, so I have a consistent history of changes I can reference back to if I ever need to, and I always have my tools setup and configured the way I need them with basically no effort. I use a nix flake and the colmena deployment tool to track and deploy changes to several of my machines in different physical locales, and I use NixOS to configure a private nebula mesh to connect them all, so pushing changes when I fix a bug or add a feature to all my machines is as simple as a single command in most cases. I also use a small bit of terraform, via terragrunt, to manage some of my cloud VPSs, but Nix still does all the building and service configuration on those machines.

For years now, I have also been very interested/involved in bringing the power of Nix to the professional landscape, but here I feel it still has a bit of an uphill battle before it is fully viable. I am one of the coauthors of divnix/std, which started out as a way to bring the power of Nix to devops tooling (CI, container publishing, etc, etc). Honestly I think we were actually fairly successful and were using it in a professional setting for several years, however the friction added to onboarding new, and even some existing developers was enough that we had to scale back our usage of Nix to basically just providing a convenient devshell.

It's unfortunate because I think the power of the tool is sometimes overshadowed by the difficulties in the language or the inefficiencies in some of the code, particularly the network code when dealing with binary caches or remote build machines. This is enough that it causes a significantly different UX for users who are intimately familiar with its quirks vs those who are not.

Even so, it might be pertinent to point out that there is a small team of developers working to address some of these pains from the foundation via the Tvix project, which is essentially a full rewrite of Nix in Rust seeking to maintain compatibility with the Nix language while addressing some of the more painful aspects of the current C++ implementation.

It is still fairly early days for Tvix, so we'll just have to see if they end up being successful in some of their ambitious goals, but they already have a working and fairly performant evaluator, and an interesting, innovative nix store implementation that is capable of deduplicating data both at rest and in transit, which would be a significant win for the enterprise space.

I hope that we can see Nix, or at least the core ideas in some future form, become more and more mainstream in the coming decades. Once you get used to it, it is such a positive paradigm shift that it seems almost silly to do things by hand, similar to what IaC has done for the infrastructure provisioning and management space. But it is still not without it's warts, and I will continue to do my part to help address them where I can.

A look at Nix and Guix

Baughn — Wed, 28 Feb 2024 11:30:54 +0000

> nonguix is not mentioned in any of the official Guix documentation, because the GNU project doesn't endorse using non-free software.

People are also encouraged not to mention it, apparently.

My own dalliance with GuixSD started and ended with a visit to their IRC channel, where I attempted to figure out how I would make it work with my Nvidia GPU. I was told that wasn't possible, and have been a happy user of NixOS for many years.

A look at Nix and Guix

zimoun — Wed, 28 Feb 2024 10:27:20 +0000

Thanks for the nice write up!

For what my opinion is worth, it seems better to speak about extensibility. Guix provides various mechanisms to extend it. Somehow, it embraces The Emacs Thesis -- see Guile manual [1]:

" [...] it is delightful to create composite programs based on an orthogonal kernel written in a low-level language together with a powerful, high-level extension language.

Extension languages foster extensible programs, programs which adapt readily to different users and to changing times."

Channels [2] are an example. They go from "non-free" programs as drivers to deal with some hardware requirements to specific tools [3] developed in scientific context.

There is a continuum from the package definition or system declaration to the core of Guix itself: all is Scheme or Domain-Specific Language (DSL) as Scheme easily allows. I think that is the main difference with Nix: a completely free core named GNU Guix that you can extend for your needs; you or a group of people sharing the same interests. :-)

Nix can be extended too, obviously. However, from what I have seen, it seems more scattered and less continuous. But I might have overlooked.

( There is still one non Scheme part: guix-daemon inherited from Nix. People are working to some non-C++ reimplementation )

1: https://www.gnu.org/software/guile/manual/html_node/The-E...
2: https://guix.gnu.org/manual/devel/en/html_node/Channels.html
3: https://hpc.guix.info/channels

A look at Nix and Guix

jpoiret — Wed, 28 Feb 2024 09:05:11 +0000

Guix has [1], but note that it doesn't track full reproducibility of a package and its dependents, but only of the package itself. Also, it doesn't take bootstrappability (which is a very hard problem) into account, the most prevalent issue being GHC, infecting the rest of the ecosystem via pandoc.

[1] https://qa.guix.gnu.org/reproducible-builds

A look at Nix and Guix

Foxboron — Wed, 28 Feb 2024 08:28:32 +0000

> Derivations are nearly all reproducible, with the same inputs generating the same outputs. Some packages still include randomness or information about the timing of the build, which foil reproducibility.

This is perpetrating a myth I've been trying to point out for years at this point. NixOS contains almost 110,000 packages and they are probably testing less than 2000 of them.

The "path" metric used in the reproducible builds dashboard is also misleading as one derivation does not equal one path. They also contain `fetchUrl` static files pinned with hashes, which means the metric is comparing the reproducability of static files. This inflates the percentage.

Guix is doing better as they contain a much smaller package sets, but if you want a realistic metric there is always the Arch rebuilder. The debian rebuilder effort has sadly been stalling for a few years.

https://reproducible.archlinux.org/

https://github.com/fepitre/package-rebuilder?tab=readme-o...

A look at Nix and Guix

daroc — Wed, 28 Feb 2024 01:59:55 +0000

I certainly didn't mean to malign Guix, and I apologize if it came across that way. In fact, I suspect that many people will find the fact that only free software is available by default a bonus. Yes, you certainly can use nonguix to get package definitions for non-free software. Even if that weren't the case, Guile is a full-fledged programming language — you could write your own package definitions that did whatever you wanted, including downloading and compiling non-free software.

However, I do think there's a meaningful difference. Trying to install a non-free package using Nix gets you a warning message prompting you to set nixpkgs.config.allowUnfree, because the packages are present in nixpkgs, just disabled. Trying to install a non-free package using Guix will get you the same error as trying to install any non-existent package, unless you track down and configure nonguix. And nonguix is not mentioned in any of the official Guix documentation, because the GNU project doesn't endorse using non-free software.

I don't think that this difference in behavior says anything about the capabilities or worth of the two projects, but it does say something different about their priorities and approaches.

A look at Nix and Guix

old — Wed, 28 Feb 2024 01:08:11 +0000

It is unfair to compare Guix to Nix, saying the latter supports non-free software

> (in contrast to Nix, which packages non-free software behind a configuration option)

but not asserting that the former can essentially do the same, because GNU.

A look at Nix and Guix

atai — Wed, 28 Feb 2024 00:41:37 +0000

Guix only packages free software. "Nonguix" is, as its name implies, outside the Guix project.

A look at Nix and Guix

old — Tue, 27 Feb 2024 23:19:50 +0000

> Guix is a GNU project, and so it only packages free software

This is not true. The main "guix" channel (a channel is where packages definitions can be found), only has free softwares. However, users can add any channel they want. For example, the "nonguix" channel has all the usual non-free softwares someone might want, e.g. chrome, proprietary firmware, steam, etc.

A look at Nix and Guix

pj — Tue, 27 Feb 2024 21:52:05 +0000

I first started using nix (the package manager) to replace pyenv, rbenv, nvm, jenv, sdkman, and the like. Why have one tool per language when just one will do? I'm far from an expert, but the reproducibility is nice.