These are notes to the stream: https://youtu.be/S9V-pcTrdL8
- We are not aware of a lot of GNU software available to us.
- Seems that Guix more hacker-friendly/explorable.
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 |
Guile is full-fledged scheme with good tooling.
Nix has much more packaged.Guix has only free software in main repo, definitions looks more consistent and less hacky.
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.
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.- You can’t use few channels with different version of guix in one profile
- Inconsistent nix cli
- Tooling kinda lacking for nix language
- Glued together different parts not so well integrated
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:
/nix/store
.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:
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.