nix vs guix.org

nix vs guix.org

Nix vs Guix

These are notes to the stream: https://youtu.be/S9V-pcTrdL8

Some notes

• We are not aware of a lot of GNU software available to us.
• Seems that Guix more hacker-friendly/explorable.

General comparsion

Description	Nix	Guix	Comment
Established	2003	2013
Poprietary Software	Yes	No
Other OSe	MacOS, GNU/Linux	GNU/Linux, Hurd
Packages	nixpkgs (53000)	guix (15000+)	https://repology.org/
Nix vs Guile	Nix	GNU Guile
Documentation	Docbook	GNU Texinfo
Branching model	Combined	Rolling-release
Service manager	systemd	GNU Shepherd
Build scripts	Bash	G-exps
Version lock	Flakes	Channels
Consistency	Medium	High
cli implementation	c++	guile
Bootstrapping	?	Yes	GNU Mes
Module System	Yes	No
Implicity	Frequent	OKeish

Version lock

Flakes seems to provide more hermetic builds than guix channels. Guix still can access different values on host, maybe I’m not yet aware of some features like pure evaluation mode or something similiar.

Nix vs Guile

Nix isn’t bad, but feels like DSL and it’s necessary to learn/invent new patterns, the tooling is kinda lacking. There are some goodies: you can have few versions of nixpkgs in one profile at the same time, nix doesn’t have namespaces and it won’t fail with name collision.

Guile is full-fledged scheme with good tooling.

Packages

Nix has much more packaged.

Guix has only free software in main repo, definitions looks more consistent and less hacky.

Documentation

Guix has centralaized and well-organized documentation in html/pdf/info format. Moreover info format has links to related topics like guile, different gnu utilities and so on.

For example info:guix#Build Systems refers to info:guile#Optional Arguments.

Branching model

NixOS has a release twice an year. Guix doesn’t have stable branch, all fixes goes straight to master. Is it bad or good is debatable, because it’s possible to freeze versions of specific packages or even whole development environments. That’s mean that we can keep as less system packages as possible to reduce attack surface and possible breakage on pulling updates from master, everything else will be managed per-user or per-project inside profiles.

Guix problems

• You can’t use few channels with different version of guix in one profile

Nix problems

• Inconsistent nix cli
• Tooling kinda lacking for nix language
• Glued together different parts not so well integrated

Resources

• https://www.reddit.com/r/NixOS/comments/9zwiee/nixos_vs_guixsd/eaddvf6/
• https://news.ycombinator.com/item?id=16490027

@rekado Thanks for the detailed explanation :)

@rekado Very nice explanation indeed!

The gist and information here is a little outdated and incomplete/incorrect, so, maybe it's a good idea to revisit and make an updated summary of the current state of nix vs guix question. Just thinking out loud.

the comparisons seems highly biased unfortunately. It might be useful to ask someone more familiar with nix ecosystem to fill out that side. For example nix is not propietery and under LGPL v2.1
Also in nix problems one of the major pain points in convoluted naming of nix package manager and nixos (even the site name is nixos) leading to further confusion that you actually need the OS, when in fact you can just use the package manager

@arijoon

For example nix is not propietery and under LGPL v2.1

Pretty sure that row is referring to whether one can install proprietary software with the default nix channels vs the default guix channels. In my opinion, that row favors nix.

the comparisons seems highly biased unfortunately.

Can you please give another example of this bias?

On 2023-02-03 23:26, arijoon wrote: @arijoon commented on this gist: the comparisons seems highly biased unfortunately. It might be useful to ask someone more familiar with nix ecosystem to fill out that side. For example `nix` is not propietery and under [LGPL v2.1](https://github.com/NixOS/nix/blob/master/COPYING) Also in `nix` problems one the major pain points in convoluted naming of nix package manager and nixos (even the site name is nixos) leading to further confusion that you actually need the OS, when in fact you can just use the package manager

This is not a standalone comparison, these are notes for the stream: https://www.youtube.com/watch?v=S9V-pcTrdL8. At the time of writing I was a Nix user cosidering migration to Guix and had pretty limited experince with Guix and good enough understanding of Nix and its internals, this could lead to the situations, where I didn't mention some details (maybe even quite important) like guix services mechanism, grafts for security updates, usage of different versions of the same channels and package transformation implemented differently and has its downsides (and upsides as well), but it doesn't make the comparison itself highly baised, especially in terms "I'm in favor of one over another and ignore obvious things", I was weighting pros and cons of both at the moment and just shared my thoughts and findings.

…

-- Best regards, Andrew Tropin

Pretty sure that row is referring to whether one can install proprietary software with the default nix channels vs the default guix channels. In my opinion, that row favors nix.
Can you please give another example of this bias?

My bad in that case for the misunderstanding. Aside from that point its no longer highly biased, may be worth adding the nix manual to the documentaion section as well since its relatively rich but of course doesn't capture everything (could also be another disadvantage that docs are spread around in man pages of commands, source code and sometimes requiring the use of repl to find the source code to find the docs for something)

On 2023-02-04 11:11, arijoon wrote: @arijoon commented on this gist: > Pretty sure that row is referring to whether one can install proprietary software with the default nix channels vs the default guix channels. In my opinion, that row favors nix. > Can you please give another example of this bias? My bad in that case for the misunderstanding. Aside from that point its no longer highly biased, may be worth adding the [nix manual](https://nixos.org/manual/nixpkgs/unstable/) to the documentaion section as well since its relatively rich but of course doesn't capture everything (could also be another disadvantage that docs are spread around in `man` pages of commands, source code and sometimes requiring the use of repl to find the source code to find the docs for something)

Added a link to the stream recording to the beginning of the file with notes to make it clearer that it's just notes/outline for the stream, but not sure if it is a good idea to add other changes as it will make it "out of sync" with stream recording. I think it's a good idea to just post comments, which elaborates or covers additional subtopics and maybe later someone will make a more complete, standalone and maintainable comparison.

…

-- Best regards, Andrew Tropin

Just asking as curious, on the Mac port, isn't GNU Mes an advantage to port to other systems, as it start very small & builds up? or the glibc that it builds is totally incompatible w/OSX ?

There is no port of the glibc for OSX.

Nixpkgs updated their docs to use Markdown Commonmark instead of Docbook.

I don't know much about the theory of functional programming languages, could someone please give me a link to a writeup about what "frequent implicity" and "O'Keish implicity" is? I currently fail at looking it up 😦

I don't know much about the theory of functional programming languages, could someone please give me a link to a writeup about what "frequent implicity" and "O'Keish implicity" is? I currently fail at looking it up 😦

It's subjective feeling from language + API. (and it's already quite old) Don't pay too much attention.

What does "consistency" mean here and what is it relative to?

NixOS seems extremely inconsistent to me. The only major things in NixOS that I'd actually consider consistent:

• All outputs required for your system can be found in /nix/store.
• Your entire system configuration can exist in one file/directory.
• Most of the common config edits for various programs composing a Linux system can be done using the Nix language & inside NixOS configs. You could say all config edits if you expand "done in Nix" to include slapping entire configs into some extraConfig multi-line string, but it would be equally as true for most programming languages, albeit more difficult.

I would only call NixOS "consistent" if comparing it to conventional Linux distros where you manually write each config file under /etc or ~/.config in whatever language/syntax it uses. I have zero experience with Guix, but I imagine it is far more consistent.

(I tried listing a bunch of examples of inconsistencies within Nix/NixOS & major NixOS ecosystem projects here, but it eventually became unorganized & out-grew the length of this gist lmao. Perhaps I will organize my thoughts and write a full blog post on this later.)

A few other questions:

• Is it possible to declaratively install the nix package manager in Guix? I saw NixOS recently got options to add configure the guix package manager & store. I was wondering if Guix has similar.
• Is there anything that Guix can manage declaratively that NixOS can't? Or does better than in NixOS? Vice versa?

If so, it would be cool to fill in any gaps in Guix/NixOS using the other...or at least wrap packages exclusive to the other OS. I'd imagine it wouldn't be too difficult for stuff that doesn't depend on either systemd or GNU Shepherd. Ideally, I'd like to run Guix as completely libre, reproducible base OS then add Nix on top, but given the package gap & state of libre firmware & driver support, it would probably make more sense to run Guix inside NixOS rather than the other way around.

Would also be cool to have something to build a complete Guix system like lib.nixosSystem inside my config flake so I could build a Guix system for hardware that runs well without any proprietary firmware.

Is it possible to declaratively install the nix package manager in Guix?

Yes.

Is there anything that Guix can manage declaratively that NixOS can't?

Guix has an abstraction for system services, i.e. anything that contributes to the operating system. Unlike NixOS where a system is a free for all global namespace, in Guix all system services form a DAG.

but given the package gap & state of libre firmware & driver support, it would probably make more sense to run Guix inside NixOS rather than the other way around.

You can use vanilla Linux and non-free firmware with Guix System. You just need the linux and linux-firmware packages from the nonguix channel.