Skip to content

Instantly share code, notes, and snippets.

@abcdw
Last active February 17, 2024 14:21
  • Star 36 You must be signed in to star a gist
  • Fork 0 You must be signed in to fork a gist
Star You must be signed in to star a gist
Save abcdw/e54807b0a25e61fe2cf1bf8991410f83 to your computer and use it in GitHub Desktop.
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

DescriptionNixGuixComment
Established20032013
Poprietary SoftwareYesNo
Other OSeMacOS, GNU/LinuxGNU/Linux, Hurd
Packagesnixpkgs (53000)guix (15000+)https://repology.org/
Nix vs GuileNixGNU Guile
DocumentationDocbookGNU Texinfo
Branching modelCombinedRolling-release
Service managersystemdGNU Shepherd
Build scriptsBashG-exps
Version lockFlakesChannels
ConsistencyMediumHigh
cli implementationc++guile
Bootstrapping?YesGNU Mes
Module SystemYesNo
ImplicityFrequentOKeish

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

@shegeley
Copy link

shegeley commented Nov 6, 2021

Thnx! 👏

@michael-nhat
Copy link

Thank you! Someone gonna need this!

@iwinux
Copy link

iwinux commented May 3, 2022

So....no luck to use Guix on macOS as of today (2022-05)?

@abcdw
Copy link
Author

abcdw commented May 7, 2022 via email

@rekado
Copy link

rekado commented Sep 21, 2022

re macos: perhaps it runs in lima.

@rekado
Copy link

rekado commented Sep 21, 2022

re package count: nixpkgs has a lot of automatically generated R packages that are unlikely to work correctly. The package count is quite inflated.

@rekado
Copy link

rekado commented Sep 23, 2022

@iwinux the problem with macos is that glibc doesn't exist for macos. To build it (or a drop-in replacement) would require the use of the proprietary Xcode toolchain, which we as the Guix project cannot use to transparently build glibc for macos.

Nix people just accept that they put their system on top of proprietary foundations with an arbitrary cut-off for the binary base. Guix goes the opposite way on GNU+Linux aiming to dramatically reduce the "binary seed" with Mes. To use Guix on top of macos would require a huge binary blob that can only be built with proprietary tools.

Given these circumstances it would not be much uglier to run Guix in a virtual GNU+Linux system on top of macos.

@iwinux
Copy link

iwinux commented Sep 26, 2022

@rekado Thanks for the detailed explanation :)

@abcdw
Copy link
Author

abcdw commented Oct 6, 2022

@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.

@arijoon
Copy link

arijoon commented Feb 4, 2023

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

@hab25
Copy link

hab25 commented Feb 4, 2023

@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?

@abcdw
Copy link
Author

abcdw commented Feb 4, 2023 via email

@arijoon
Copy link

arijoon commented Feb 4, 2023

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)

@abcdw
Copy link
Author

abcdw commented Feb 5, 2023 via email

@megatux
Copy link

megatux commented Jun 17, 2023

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 ?

@rekado
Copy link

rekado commented Jun 23, 2023

There is no port of the glibc for OSX.

@AndersonTorres
Copy link

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

@alex-fu27
Copy link

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 😦

@abcdw
Copy link
Author

abcdw commented Dec 25, 2023

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.

@lehmanator
Copy link

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.

@rekado
Copy link

rekado commented Dec 29, 2023

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment