4 ms·

Does anyone know of a recent comparison of NixOS vs Guix? Both these projects are awesome and I’m a NixOS user but I want to learn more about Guix. I’ve found o

Does anyone know of a recent comparison of NixOS vs Guix? Both these projects are awesome and I’m a NixOS user but I want to learn more about Guix. I’ve found older ones but nothing in the past year and with all the recent developments in both communities I’d love to see a side by side comparison.

cbaines 6y ago
Maybe it would be nice to have a wiki style page for this... anyway, I can only offer a perspective from the Guix side of things, but these are the reasons I'd personally be cautious about using Nix/Nixpkgs. I believe a higher proportion of Nixpkgs don't build all or some of the software/artifacts from source. I picked a random example, JOSM. The nixpkgs package definition is quite short [1], but I don't think it's actually building the software? The Guix package definition is much longer [2] but I think that's because it's actually building the software from source. 1: https://github.com/NixOS/nixpkgs/blob/master/pkgs/applications/misc/josm/default.nix#L44 https://github.com/NixOS/nixpkgs/blob/master/pkgs/applicatio... 2: https://git.savannah.gnu.org/cgit/guix.git/tree/gnu/packages/geo.scm?id=8b00728144d0e4bbc740e1595c85f0ecee3f6fb0#n1163 https://git.savannah.gnu.org/cgit/guix.git/tree/gnu/packages... Personally, I like binary packages, which is why I use Guix, but I also value the security and flexibility of having these packages actually build the software from source. Nixpkgs also contains non-free software. This is sort of related to the previous point, as it's much harder to tell if software is free or not if you're not building it from source, but Guix everything should be free software which takes away a worry when using it. With nixpkgs, I believe there are some bits of non-free software that are marked as such, but not taking a strong stance on attempting to build everything from source makes me generally unsure about the quality assurance in this area.
- rudolph9 6y ago
  All good points but it’s worth noting that in order to install any non-free NixOS packages there is an explicit flag you need to set which affect their entire OS or set of packages on your machine. That said, downloading a jar instead of compiling the jar from source is definitely a notable difference and potentially is unfree software despite the license stating otherwise and the flag previously mentioned set. While there is nothing inherent about NixOS To prevent non-free software from entering the ecosystem, there is also nothing inherent to Guix either that would prevent any non-free software. Ultimately it comes down to community curation of the packages and while Guix almost definitely is more vigilant about free software both have focus on free-software NixOS has the option to install non-free (which you need to explicitly enable to install non-software) and Guix is more strict where their official packages don’t intentionally support any non-free software and they employ practices that are more likely to catch oversights.
rekado 6y ago
I generally don't like to talk about other projects negatively, because I don't think that Nix and Guix should compete. They are different takes on the same concept. But as I'm very familiar with Guix and have occasionally looked at how they deal with some of the packaging problems I worked on in Guix I can say that the Nix colleagues are often punting on problems instead of solving them. Let me give you a few examples. In Nixpkgs there are quite a few generated packages, some of which cannot be built. I'm maintaining R packages (from CRAN and Bioconductor) in Guix and I see that the equivalent packages in Nixpkgs do not accommodate some of their quirks, so they cannot actually be built. Another example where Nixpkgs does not build packages from source is TeX Live. The SVN repository of TeX Live contains countless generated files, and all of the TeX Live packages in Nixpkgs merely copy the generated files from SVN instead of building them from source. Java packages in Nixpkgs often seem to include pre-built jars whereas in Guix we're going to great lengths to build everything from source. This comes at a cost, of course: Guix has fever Java packages because of that, but those that it has are actually built from source. Of course, I'm biased towards Guix, but I must say that I'm very fond of the level of integration that Guix achieves. When I look at Nix I see a bunch of seemingly separately developed tools that are written in a mix of languages (with Shell code being rather common). In Guix all tools are written in Scheme, use the same API, behave similarly, etc. It just feels much more polished to me. That said, there is no animosity between these communities, and I think we would all be better off avoiding the mental pitfall of competition; we work on the same problems with different values and thus our approach differs. This leads to diversity rather than duplication of work. Here are some more things I wrote comparing Nix and Guix in the past: https://news.ycombinator.com/item?id=19807042 https://news.ycombinator.com/item?id=19807042
- AnIdiotOnTheNet 6y ago
  > This comes at a cost, of course: Guix has fever Java packages because of that, but those that it has are actually built from source. Truly this is much more valuable than actually being able to use the software.
  - uncletaco 6y ago
    Note that just because you cannot manage a lot of jars through guix you can still maintain a java project that includes steps to build its source outside of guix. Also for clojure heads the Nonguix[1] repository includes a leiningen package. I think as time goes on and guix matures we will start to see more third party repositories that provide convenient builds of things. For instance I run guix system on a 2015 Chromebook Pixel and to do that I used the installation image provided at Nonguix to make sure I had all of the nonfree drivers I needed. [1] https://gitlab.com/nonguix/nonguix https://gitlab.com/nonguix/nonguix
jhoechtl 6y ago
Guile seems to have made some substantial improvements too. Has there been made any performance comparisons between the Racket VM and Guile?
- civodul 6y ago
  There are benchmarks at https://ecraven.github.io/r7rs-benchmarks/ https://ecraven.github.io/r7rs-benchmarks/ but unfortunately they lack data for Guile 3.0. There's a Guile 2.2/3.0 comparison at https://www.gnu.org/software/guile/news/gnu-guile-300-released.html https://www.gnu.org/software/guile/news/gnu-guile-300-releas... .
jnxx 6y ago
I think what will make the most difference in the long term is using GNU Guile Scheme as language for package definitions. I think it is a brilliant choice to use a mature and popular language which supports functional programming very well. The fact that Scheme is minimalist and easy to learn will without doubt help attracting contributors in the future, and this in turn will be decisive for driving adoption in the long term. Another feature that is very nice is that there is no difference between a package definition in a local development environment, and a definition in the official channel. What you put together as a build recipe of a tool that is useful for your quirky local project will also work as part of the distribution.

cbaines 6y ago

Maybe it would be nice to have a wiki style page for this... anyway, I can only offer a perspective from the Guix side of things, but these are the reasons I'd personally be cautious about using Nix/Nixpkgs. I believe a higher proportion of Nixpkgs don't build all or some of the software/artifacts from source. I picked a random example, JOSM. The nixpkgs package definition is quite short [1], but I don't think it's actually building the software? The Guix package definition is much longer [2] but I think that's because it's actually building the software from source. 1: https://github.com/NixOS/nixpkgs/blob/master/pkgs/applications/misc/josm/default.nix#L44 https://github.com/NixOS/nixpkgs/blob/master/pkgs/applicatio... 2: https://git.savannah.gnu.org/cgit/guix.git/tree/gnu/packages/geo.scm?id=8b00728144d0e4bbc740e1595c85f0ecee3f6fb0#n1163 https://git.savannah.gnu.org/cgit/guix.git/tree/gnu/packages... Personally, I like binary packages, which is why I use Guix, but I also value the security and flexibility of having these packages actually build the software from source. Nixpkgs also contains non-free software. This is sort of related to the previous point, as it's much harder to tell if software is free or not if you're not building it from source, but Guix everything should be free software which takes away a worry when using it. With nixpkgs, I believe there are some bits of non-free software that are marked as such, but not taking a strong stance on attempting to build everything from source makes me generally unsure about the quality assurance in this area.

rudolph9 6y ago
All good points but it’s worth noting that in order to install any non-free NixOS packages there is an explicit flag you need to set which affect their entire OS or set of packages on your machine. That said, downloading a jar instead of compiling the jar from source is definitely a notable difference and potentially is unfree software despite the license stating otherwise and the flag previously mentioned set. While there is nothing inherent about NixOS To prevent non-free software from entering the ecosystem, there is also nothing inherent to Guix either that would prevent any non-free software. Ultimately it comes down to community curation of the packages and while Guix almost definitely is more vigilant about free software both have focus on free-software NixOS has the option to install non-free (which you need to explicitly enable to install non-software) and Guix is more strict where their official packages don’t intentionally support any non-free software and they employ practices that are more likely to catch oversights.

rekado 6y ago

I generally don't like to talk about other projects negatively, because I don't think that Nix and Guix should compete. They are different takes on the same concept. But as I'm very familiar with Guix and have occasionally looked at how they deal with some of the packaging problems I worked on in Guix I can say that the Nix colleagues are often punting on problems instead of solving them. Let me give you a few examples. In Nixpkgs there are quite a few generated packages, some of which cannot be built. I'm maintaining R packages (from CRAN and Bioconductor) in Guix and I see that the equivalent packages in Nixpkgs do not accommodate some of their quirks, so they cannot actually be built. Another example where Nixpkgs does not build packages from source is TeX Live. The SVN repository of TeX Live contains countless generated files, and all of the TeX Live packages in Nixpkgs merely copy the generated files from SVN instead of building them from source. Java packages in Nixpkgs often seem to include pre-built jars whereas in Guix we're going to great lengths to build everything from source. This comes at a cost, of course: Guix has fever Java packages because of that, but those that it has are actually built from source. Of course, I'm biased towards Guix, but I must say that I'm very fond of the level of integration that Guix achieves. When I look at Nix I see a bunch of seemingly separately developed tools that are written in a mix of languages (with Shell code being rather common). In Guix all tools are written in Scheme, use the same API, behave similarly, etc. It just feels much more polished to me. That said, there is no animosity between these communities, and I think we would all be better off avoiding the mental pitfall of competition; we work on the same problems with different values and thus our approach differs. This leads to diversity rather than duplication of work. Here are some more things I wrote comparing Nix and Guix in the past: https://news.ycombinator.com/item?id=19807042 https://news.ycombinator.com/item?id=19807042

AnIdiotOnTheNet 6y ago
> This comes at a cost, of course: Guix has fever Java packages because of that, but those that it has are actually built from source. Truly this is much more valuable than actually being able to use the software.
- uncletaco 6y ago
  Note that just because you cannot manage a lot of jars through guix you can still maintain a java project that includes steps to build its source outside of guix. Also for clojure heads the Nonguix[1] repository includes a leiningen package. I think as time goes on and guix matures we will start to see more third party repositories that provide convenient builds of things. For instance I run guix system on a 2015 Chromebook Pixel and to do that I used the installation image provided at Nonguix to make sure I had all of the nonfree drivers I needed. [1] https://gitlab.com/nonguix/nonguix https://gitlab.com/nonguix/nonguix

jhoechtl 6y ago

Guile seems to have made some substantial improvements too. Has there been made any performance comparisons between the Racket VM and Guile?

civodul 6y ago
There are benchmarks at https://ecraven.github.io/r7rs-benchmarks/ https://ecraven.github.io/r7rs-benchmarks/ but unfortunately they lack data for Guile 3.0. There's a Guile 2.2/3.0 comparison at https://www.gnu.org/software/guile/news/gnu-guile-300-released.html https://www.gnu.org/software/guile/news/gnu-guile-300-releas... .

jnxx 6y ago

I think what will make the most difference in the long term is using GNU Guile Scheme as language for package definitions. I think it is a brilliant choice to use a mature and popular language which supports functional programming very well. The fact that Scheme is minimalist and easy to learn will without doubt help attracting contributors in the future, and this in turn will be decisive for driving adoption in the long term. Another feature that is very nice is that there is no difference between a package definition in a local development environment, and a definition in the official channel. What you put together as a build recipe of a tool that is useful for your quirky local project will also work as part of the distribution.