3 ms·

What are the technical merits of Guix compared to Nix? Also, what's the situation with unfree packages? And package availability in general?

Zambyte 3y ago
Guix started as a fork of Nix, but I believe all original Nix code has been replaced with Guix specific code at this point. Core functionality is pretty comparable between the two of them. Two differences I can tell you immediately is that GNU Guix has a built in user home configuration management system[0], and Nix depends on an external module to do the same[1]. NixOS, like most distros uses systemd for it's init system. GNU Guix uses Shepherd[2]. Honestly it hasn't really been much of a point of note in my experience, but it's probably worth mentioning as a difference. Regarding Free vs non-Free packages: this can be a pain point if your system requires non-Free packages to function on GNU Guix. I (like most other Guix users I would guess) use the nonguix[3] channel for additional packages. One of my systems requires the baseline Linux kernel for propriety Ethernet drivers (included in Linux because of GPLv2 :P), so I had to create a custom installation ISO with the baseline kernel. This probably sounds horrifying, but creating a custom installation ISO is actually very easy in Guix (and probably Nix as well). It's the only distro I've ever done it for. But between the main Guix channel, nonguix, and Flatpak, it's very uncommon that I cannot find what I want. According to repology[4], Guix is the #5 repo for most packages. And the few packages that I have wanted that were missing, I have actually been able to contribute package definitions for upstream to Guix, since the process is very easy and well documented (also the only distro I have ever done that for). [0] https://guix.gnu.org/manual/en/html_node/Home-Configuration.html https://guix.gnu.org/manual/en/html_node/Home-Configuration.... [1] https://github.com/nix-community/home-manager https://github.com/nix-community/home-manager [2] https://www.gnu.org/software/shepherd https://www.gnu.org/software/shepherd [3] https://gitlab.com/nonguix/nonguix https://gitlab.com/nonguix/nonguix [4] https://repology.org/ https://repology.org/
- nextos 3y ago
  An interesting advantage of Guix over Nix is having better options for runtime isolation. Nix is not well developed in this area yet, although one can always use bwrap or AppArmor to implement something ad hoc. Besides, Guix uses Scheme everywhere, whereas Nix is a mix of the Nix language and lots of shell code. The Nix language is a pretty elegant lazy functional language, and yields very compact and clean code. But if you want to do complex things, Scheme might be easier.
  - ryukafalz 3y ago
    Although it doesn't seem have much in the way of runtime isolation of Guix source files themselves. From what I can tell it runs the Guile scripts that evaluate to manifests and such as your own user, with all of the authority associated with that. So although Guix provides good mechanisms for isolating applications at runtime, you do have to put a lot of trust in the channels you're using. (This is something I would like to see improved as a Guix user.)
  - fulafel 3y ago
    Are there writeups about this isolation feature? I was left wondering if it's a security boundary, like sandboxing, or a packaging system feature.
    - nextos 3y ago
      See https://guix.gnu.org/manual/en/html_node/Invoking-guix-shell.html https://guix.gnu.org/manual/en/html_node/Invoking-guix-shell... It's a sandboxing feature similar to e.g. Firejail. One can launch applications in a separate container, and choose whether to give access to the network, filesystem, and other environment variables. I find this very convenient, and I wish Nix provided a similar feature.
      - fulafel 3y ago
        Thanks. So there are two concepts where isolation is mentioned, the --pure and the --container options. But still the documentation is very light on details and doesn't really answer what kind of (if any) security boundary or sandbox is provided by the container feature. How might it compare to eg using nsjail[1] or firecracker [2] or flatpak's sandbox[3]? These could be also good benchmarks for the documentation. [1] https://github.com/google/nsjail https://github.com/google/nsjail [2] https://github.com/firecracker-microvm/firecracker-containerd https://github.com/firecracker-microvm/firecracker-container... [3] https://docs.flatpak.org/en/latest/sandbox-permissions-reference.html https://docs.flatpak.org/en/latest/sandbox-permissions-refer...
        3y ago
- rekado 3y ago
  > Guix started as a fork of Nix This is not actually correct. Guix only ever used a copy of the nix-daemon, because there's no point in reinventing the derivation format or the low-level implementation of functional package management; no other part of nix/nixpkgs has been used to make Guix.
BlueTemplar 3y ago
There's also a social element here : communities around software matter, and I for one (being a EU developer, for reasons of professional ethics) cannot justify any more associating myself with the kind of developer that still thinks it's acceptable to use Github (especially for something as fundamental as Nix(OS) - and I'm pretty sad about Rust too) (at this point developers had enough time to migrate even the most complicated projects off of it).
- bbkane 3y ago
  Because GitHub is non-FOSS or owned by Microsoft or something? I use GitHub, and I don't really have any complaints...
  - deleted 3y ago
    [deleted]
zamalek 3y ago
> What are the technical merits of Guix compared to Nix? It doesn't boot on non-libre hardware. In all seriousness, it uses Lisp. That is a _substantial_ advantage over Nix - which uses a home-grown language. As you can see from the front page today, there is roughly a million Nix-wrappers addressing the issue that people don't want to learn nixlang.
- orbital-decay 3y ago
  All these wrappers are there because nixpkgs doesn't have non-awkward ways to deal with the stuff people deal with often. Nix the language is probably the least of the issues, it's maybe a few % of the chaotic Nix ecosystem. Most of the logic (that desperately needs proper documentation) is in nixpkgs and tooling.
- mdaniel 3y ago
  s/Lisp/scheme/ unless you meant "a Lisp" https://guix.gnu.org/manual/en/html_node/Package-Modules.html https://guix.gnu.org/manual/en/html_node/Package-Modules.htm... -> https://www.gnu.org/software/guile/manual/html_node/Guile-and-Scheme.html https://www.gnu.org/software/guile/manual/html_node/Guile-an... but I'm with you on "why in the holy hell reinvent the wheel". I need to dig back into Guix and see if it supports moving the store out of /gnu since on Cupertino's OS one cannot write to / without a bunch of stupidity <https://nixos.org/manual/nix/stable/installation/installing-binary#macos-installation https://nixos.org/manual/nix/stable/installation/installing-...>
  - samatman 3y ago
    Lisp usually means "a language in the Lisp family", more than it means "Common Lisp specifically", these days. I don't have a strong opinion on whether that's good or bad, leaning slightly in the direction of good. Just sharing the observation.
    - lispm 3y ago
      Lisp usually means a Lisp which identifies as such: Common Lisp, Emacs Lisp, ISLisp (which is an ISO Standard), Emacs Lisp, AutoLisp, Interlisp, ... Languages like Scheme have their own standards (RNRS, IEEE Scheme, SRFI, ...). It's perfectly fine to make a difference between Lisp and Scheme, for example. In the Scheme literature "Lisp" often means the earlier&older language before Scheme. A language which emphasizes symbols, property lists on symbols, lists, imperative programming, several namespaces, dynamic binding, ... Common Lisp, even though it is younger than Scheme, preserves the Lisp features from before Scheme. Other Lisp languages, like Emacs Lisp and ISLisp, are also backwards compatible. There is also an idea of a wider family of Lisp-inspired languages, but that has very little practical meaning because they are often very different languages: Logo, Dylan, Racket, Clojure, newLisp, Hy, LispE, ... JavaScript, R, ...

Zambyte 3y ago

Guix started as a fork of Nix, but I believe all original Nix code has been replaced with Guix specific code at this point. Core functionality is pretty comparable between the two of them. Two differences I can tell you immediately is that GNU Guix has a built in user home configuration management system[0], and Nix depends on an external module to do the same[1]. NixOS, like most distros uses systemd for it's init system. GNU Guix uses Shepherd[2]. Honestly it hasn't really been much of a point of note in my experience, but it's probably worth mentioning as a difference. Regarding Free vs non-Free packages: this can be a pain point if your system requires non-Free packages to function on GNU Guix. I (like most other Guix users I would guess) use the nonguix[3] channel for additional packages. One of my systems requires the baseline Linux kernel for propriety Ethernet drivers (included in Linux because of GPLv2 :P), so I had to create a custom installation ISO with the baseline kernel. This probably sounds horrifying, but creating a custom installation ISO is actually very easy in Guix (and probably Nix as well). It's the only distro I've ever done it for. But between the main Guix channel, nonguix, and Flatpak, it's very uncommon that I cannot find what I want. According to repology[4], Guix is the #5 repo for most packages. And the few packages that I have wanted that were missing, I have actually been able to contribute package definitions for upstream to Guix, since the process is very easy and well documented (also the only distro I have ever done that for). [0] https://guix.gnu.org/manual/en/html_node/Home-Configuration.html https://guix.gnu.org/manual/en/html_node/Home-Configuration.... [1] https://github.com/nix-community/home-manager https://github.com/nix-community/home-manager [2] https://www.gnu.org/software/shepherd https://www.gnu.org/software/shepherd [3] https://gitlab.com/nonguix/nonguix https://gitlab.com/nonguix/nonguix [4] https://repology.org/ https://repology.org/

nextos 3y ago
An interesting advantage of Guix over Nix is having better options for runtime isolation. Nix is not well developed in this area yet, although one can always use bwrap or AppArmor to implement something ad hoc. Besides, Guix uses Scheme everywhere, whereas Nix is a mix of the Nix language and lots of shell code. The Nix language is a pretty elegant lazy functional language, and yields very compact and clean code. But if you want to do complex things, Scheme might be easier.
- ryukafalz 3y ago
  Although it doesn't seem have much in the way of runtime isolation of Guix source files themselves. From what I can tell it runs the Guile scripts that evaluate to manifests and such as your own user, with all of the authority associated with that. So although Guix provides good mechanisms for isolating applications at runtime, you do have to put a lot of trust in the channels you're using. (This is something I would like to see improved as a Guix user.)
- fulafel 3y ago
  Are there writeups about this isolation feature? I was left wondering if it's a security boundary, like sandboxing, or a packaging system feature.
  - nextos 3y ago
    See https://guix.gnu.org/manual/en/html_node/Invoking-guix-shell.html https://guix.gnu.org/manual/en/html_node/Invoking-guix-shell... It's a sandboxing feature similar to e.g. Firejail. One can launch applications in a separate container, and choose whether to give access to the network, filesystem, and other environment variables. I find this very convenient, and I wish Nix provided a similar feature.
    - fulafel 3y ago
      Thanks. So there are two concepts where isolation is mentioned, the --pure and the --container options. But still the documentation is very light on details and doesn't really answer what kind of (if any) security boundary or sandbox is provided by the container feature. How might it compare to eg using nsjail[1] or firecracker [2] or flatpak's sandbox[3]? These could be also good benchmarks for the documentation. [1] https://github.com/google/nsjail https://github.com/google/nsjail [2] https://github.com/firecracker-microvm/firecracker-containerd https://github.com/firecracker-microvm/firecracker-container... [3] https://docs.flatpak.org/en/latest/sandbox-permissions-reference.html https://docs.flatpak.org/en/latest/sandbox-permissions-refer...
      - 3y ago
rekado 3y ago
> Guix started as a fork of Nix This is not actually correct. Guix only ever used a copy of the nix-daemon, because there's no point in reinventing the derivation format or the low-level implementation of functional package management; no other part of nix/nixpkgs has been used to make Guix.

BlueTemplar 3y ago

There's also a social element here : communities around software matter, and I for one (being a EU developer, for reasons of professional ethics) cannot justify any more associating myself with the kind of developer that still thinks it's acceptable to use Github (especially for something as fundamental as Nix(OS) - and I'm pretty sad about Rust too) (at this point developers had enough time to migrate even the most complicated projects off of it).

bbkane 3y ago
Because GitHub is non-FOSS or owned by Microsoft or something? I use GitHub, and I don't really have any complaints...
- deleted 3y ago
  [deleted]

zamalek 3y ago

> What are the technical merits of Guix compared to Nix? It doesn't boot on non-libre hardware. In all seriousness, it uses Lisp. That is a _substantial_ advantage over Nix - which uses a home-grown language. As you can see from the front page today, there is roughly a million Nix-wrappers addressing the issue that people don't want to learn nixlang.

orbital-decay 3y ago
All these wrappers are there because nixpkgs doesn't have non-awkward ways to deal with the stuff people deal with often. Nix the language is probably the least of the issues, it's maybe a few % of the chaotic Nix ecosystem. Most of the logic (that desperately needs proper documentation) is in nixpkgs and tooling.
mdaniel 3y ago
s/Lisp/scheme/ unless you meant "a Lisp" https://guix.gnu.org/manual/en/html_node/Package-Modules.html https://guix.gnu.org/manual/en/html_node/Package-Modules.htm... -> https://www.gnu.org/software/guile/manual/html_node/Guile-and-Scheme.html https://www.gnu.org/software/guile/manual/html_node/Guile-an... but I'm with you on "why in the holy hell reinvent the wheel". I need to dig back into Guix and see if it supports moving the store out of /gnu since on Cupertino's OS one cannot write to / without a bunch of stupidity <https://nixos.org/manual/nix/stable/installation/installing-binary#macos-installation https://nixos.org/manual/nix/stable/installation/installing-...>
- samatman 3y ago
  Lisp usually means "a language in the Lisp family", more than it means "Common Lisp specifically", these days. I don't have a strong opinion on whether that's good or bad, leaning slightly in the direction of good. Just sharing the observation.
  - lispm 3y ago
    Lisp usually means a Lisp which identifies as such: Common Lisp, Emacs Lisp, ISLisp (which is an ISO Standard), Emacs Lisp, AutoLisp, Interlisp, ... Languages like Scheme have their own standards (RNRS, IEEE Scheme, SRFI, ...). It's perfectly fine to make a difference between Lisp and Scheme, for example. In the Scheme literature "Lisp" often means the earlier&older language before Scheme. A language which emphasizes symbols, property lists on symbols, lists, imperative programming, several namespaces, dynamic binding, ... Common Lisp, even though it is younger than Scheme, preserves the Lisp features from before Scheme. Other Lisp languages, like Emacs Lisp and ISLisp, are also backwards compatible. There is also an idea of a wider family of Lisp-inspired languages, but that has very little practical meaning because they are often very different languages: Logo, Dylan, Racket, Clojure, newLisp, Hy, LispE, ... JavaScript, R, ...