Guix Further Reduces Bootstrap Seed to 25%(guix.gnu.org)
guix.gnu.org
Guix Further Reduces Bootstrap Seed to 25%
https://guix.gnu.org/blog/2020/guix-further-reduces-bootstrap-seed-to-25/
91 comments
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.
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
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
> 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.
Truly this is much more valuable than actually being able to use the software.
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
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
> Guix has fever Java packages because of that
That's right, but 13,800 packages is not exactly bad. I believe that is more packages than Ubuntu had a few years ago.
That's right, but 13,800 packages is not exactly bad. I believe that is more packages than Ubuntu had a few years ago.
If you just wanted to download and run a binary (or jar) - you can still do that?
While freedom zero (the most important!) is the ability "to use the software" - being able to improve, patch and adapt the software is also very important!
While freedom zero (the most important!) is the ability "to use the software" - being able to improve, patch and adapt the software is also very important!
> If you just wanted to download and run a binary (or jar) - you can still do that?
If it were that simple, why would we need package managers at all? Sadly, the Linux community as a whole have dedicated themselves to a structure that makes this seemingly simple task remarkably difficult.
If it were that simple, why would we need package managers at all? Sadly, the Linux community as a whole have dedicated themselves to a structure that makes this seemingly simple task remarkably difficult.
> If it were that simple,
It is that simple.
> why would we need package managers at all? Sadly, the Linux community as a whole have dedicated themselves to a structure that makes this seemingly simple task remarkably difficult.
Because there's a huge difference between a user downloading/running a binary, and software package management in an OS. The former is not maintainable, your binaries will be out of date soon, etc. But, if you insist on wanting to do this, there's absolutely nothing preventing you from doing it. Have fun.
It is that simple.
> why would we need package managers at all? Sadly, the Linux community as a whole have dedicated themselves to a structure that makes this seemingly simple task remarkably difficult.
Because there's a huge difference between a user downloading/running a binary, and software package management in an OS. The former is not maintainable, your binaries will be out of date soon, etc. But, if you insist on wanting to do this, there's absolutely nothing preventing you from doing it. Have fun.
> if you insist on wanting to do this, there's absolutely nothing preventing you from doing it. Have fun.
I really do want to do this, precisely because the software in the repo is often out of date, if it is even there at all! I really don't like the idea of a mandatory middleman between the developer and the user.
And since I really do want to do this, and do it often, I can say with quite a bit of certainty that
> It is that simple.
Is complete and utter bullshit! Sometimes you get lucky and the developer produces AppImages or a static binary, sometimes you're less lucky and have to grab the binary and its dependencies and write a startup script that sets LD_LIBRARY_PATH, sometimes you're even less lucky than that and get to use patchelf to force it to use a compatible ld.so, but most of the time you end up having to compile the damn thing from source like it is 1975.
I really do want to do this, precisely because the software in the repo is often out of date, if it is even there at all! I really don't like the idea of a mandatory middleman between the developer and the user.
And since I really do want to do this, and do it often, I can say with quite a bit of certainty that
> It is that simple.
Is complete and utter bullshit! Sometimes you get lucky and the developer produces AppImages or a static binary, sometimes you're less lucky and have to grab the binary and its dependencies and write a startup script that sets LD_LIBRARY_PATH, sometimes you're even less lucky than that and get to use patchelf to force it to use a compatible ld.so, but most of the time you end up having to compile the damn thing from source like it is 1975.
> I really do want to do this, precisely because the software in the repo is often out of date,
That depends much on the distribution you use (if recentness is most important, why do you don't use Arch), and being out of date is definitely not the case for Guix System:
http://distrowatch.org/dwres.php?firstlist=guixsd&firstversi...
Sp, why are you bringing an argument that does not apply to Guix?
That depends much on the distribution you use (if recentness is most important, why do you don't use Arch), and being out of date is definitely not the case for Guix System:
http://distrowatch.org/dwres.php?firstlist=guixsd&firstversi...
Sp, why are you bringing an argument that does not apply to Guix?
Oh wow that sounds exactly like the kind of problems package mamagers solve. Your complaint basically boils down to - nobody prepared a one click package of latest version for free for me.
My complaint comes down to the following: why must there be a middle man between the developer and user, why must there be a separate middleman for every repo, why must said repo prevent me from installing older versions, why must the package manager prevent me from installing to alternative paths... basically, why does the community insist that this simple task that was the de-facto way to install software for DOS, MacOS (classic), NeXT, RiscOS, and MacOS (recent) insist on being complicated and restrictive in Linux?
And if package managers really solved the problem, why do so many projects deploy with Docker? Why do FlatPak and Snap exist, let alone my preferred AppImage?
And if package managers really solved the problem, why do so many projects deploy with Docker? Why do FlatPak and Snap exist, let alone my preferred AppImage?
> why must there be a middle man between the developer and user, why must there be a separate middleman for every repo,
Guix allows you to easily write own package definitions which are treated as part of the whole system. If you submit them and they are accepted, they simply become part of Guix.
> why must said repo prevent me from installing older versions,
Precisely this is a case that Guix solves extremely well: One can start environments with specific versions of packages, like in Pyhon's virtualenv.
And by the way, the complexity is caused by the issue that many many components need to fit together. That does not happen by chance, it is a massive amount of work to make it fit in a manageable way, and check that it works. That's what distributions do.
Guix allows you to easily write own package definitions which are treated as part of the whole system. If you submit them and they are accepted, they simply become part of Guix.
> why must said repo prevent me from installing older versions,
Precisely this is a case that Guix solves extremely well: One can start environments with specific versions of packages, like in Pyhon's virtualenv.
And by the way, the complexity is caused by the issue that many many components need to fit together. That does not happen by chance, it is a massive amount of work to make it fit in a manageable way, and check that it works. That's what distributions do.
And yet many operating systems throughout history have not needed to do that. The complexity is not inherent to the problem space, it is a creation of the community.
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/applicatio... 2: 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.
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/applicatio... 2: 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.
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.
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.
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.
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.
Guile seems to have made some substantial improvements too. Has there been made any performance comparisons between the Racket VM and Guile?
There are benchmarks at 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-releas... .
Who funds Guix development? This this one of those experimental/hobby/academic projects? I never hear anything about Guix outside of HN or F/OSS boards (and even then, very little). How does it continue?
The answer is "all of the above". Guix is largely community-driven, but receives donations[0] as well as sponsored work like the NLnet grant mentioned in the article. In addition some research institutions employ Guix developers[1].
Personally I have used Guix to convert a CentOS "appliance" into a full-blown desktop system, on a professional contract[2].
0: https://guix.gnu.org/blog/2018/gnu-guix-receives-donation-fr...
1: https://hpc.guix.info/
2: https://guix.gnu.org/blog/2019/running-a-guix-xfce-desktop-o...
Personally I have used Guix to convert a CentOS "appliance" into a full-blown desktop system, on a professional contract[2].
0: https://guix.gnu.org/blog/2018/gnu-guix-receives-donation-fr...
1: https://hpc.guix.info/
2: https://guix.gnu.org/blog/2019/running-a-guix-xfce-desktop-o...
The EU.
The article mentions: "We are excited that the Nlnet Foundation has sponsored this work!"
https://nlnet.nl/project/GNUMes/ mentions "This project was funded through the NGI0 PET Fund, a fund established by NLnet with financial support from the European Commission's Next Generation Internet programme".
So this is funded by the EU.
The article mentions: "We are excited that the Nlnet Foundation has sponsored this work!"
https://nlnet.nl/project/GNUMes/ mentions "This project was funded through the NGI0 PET Fund, a fund established by NLnet with financial support from the European Commission's Next Generation Internet programme".
So this is funded by the EU.
It's part of GNU [0] (which in itself is a community), but GNU as a whole is additionally funded in part by the FSF [1] ; And then as always: volunteers. I suspect since Guix heavily utilizes Lisp quite a few Emacs lovers might watch Guix closely and even contribute ; students might pick GNU projects as part of a thesis et cetera.
And I am unsure how 'active' development is, I have no insight, but it has been in existence for so long and still no one I know has ever used it. On the other hand NixOS[2] (or Nix as a package manager in similar vein) seems to be used heavily by some Power Users.
[0] http://www.gnu.org/software/software.html
[1] https://www.fsf.org/campaigns/
[2] https://nixos.org/
And I am unsure how 'active' development is, I have no insight, but it has been in existence for so long and still no one I know has ever used it. On the other hand NixOS[2] (or Nix as a package manager in similar vein) seems to be used heavily by some Power Users.
[0] http://www.gnu.org/software/software.html
[1] https://www.fsf.org/campaigns/
[2] https://nixos.org/
Development is very, very active. See for yourself: https://git.savannah.gnu.org/cgit/guix.git/log/
The FSF is GNU's sponsor, and provides some infrastructure, but generally hasn't done too much in terms of funding the project. However other funding has happened in terms of NLNet, Outreachy, GSoC, and some stuff with the Guix HPC project. But far and away the majority of contributions are from unpaid contributors.
The FSF is GNU's sponsor, and provides some infrastructure, but generally hasn't done too much in terms of funding the project. However other funding has happened in terms of NLNet, Outreachy, GSoC, and some stuff with the Guix HPC project. But far and away the majority of contributions are from unpaid contributors.
The latest release notes at https://guix.gnu.org/blog/2020/gnu-guix-1.1.0-released/ give some insights about the project's activity. Currently there's ~90 monthly contributors and ~1,700 commits per month. It's active. :-)
>I suspect since Guix heavily utilizes Lisp quite a few Emacs lovers might watch Guix closely and even contribute
As an Emacs user who contributes packages occasionally - yup, that's about right! It's a really natural combination. Every so often I'll run across something I want that's not yet packaged for Guix, and if you're used to hacking on elisp the Guix package definitions aren't too hard to get the hang of.
I think it's the only distro I've used that readily accepts new packages from the community (with review of course) - haven't used it myself but I think NixOS/nixpkgs is similar in that regard.
As an Emacs user who contributes packages occasionally - yup, that's about right! It's a really natural combination. Every so often I'll run across something I want that's not yet packaged for Guix, and if you're used to hacking on elisp the Guix package definitions aren't too hard to get the hang of.
I think it's the only distro I've used that readily accepts new packages from the community (with review of course) - haven't used it myself but I think NixOS/nixpkgs is similar in that regard.
In GNU fashion they're using savannah mailing lists and email patches so to those who are comfortable with git{hub,lab} it's slightly less familiar.
Here is their git repository: https://savannah.gnu.org/projects/guix
Here is the web interface to their issues and patches mailing list: https://issues.guix.gnu.org/
As you can see although the project is less popular, it is no less actively developed and you can easily find system configurations by searching git{hub,lab}.
Here is their git repository: https://savannah.gnu.org/projects/guix
Here is the web interface to their issues and patches mailing list: https://issues.guix.gnu.org/
As you can see although the project is less popular, it is no less actively developed and you can easily find system configurations by searching git{hub,lab}.
I fear it being 'GNU' they will shoot themselves in the foot somehow. Bad marketing, unnecessarily geeky and childish nomenclature, GPLv3 and make it all free software, no proprietary drivers, hard to get proprietary third party software to install et cetera...
'GNU Guix is a transactional package manager and an advanced distribution of the GNU system that respects user freedom.'[0]
NixOS is developed using the MIT license and does seem to just want things to work.
I am bringing this up purely as a question, is that fear justified or am I missing something? Would be glad for a take on this from someone who knows more.
[0] https://savannah.gnu.org/projects/guix
'GNU Guix is a transactional package manager and an advanced distribution of the GNU system that respects user freedom.'[0]
NixOS is developed using the MIT license and does seem to just want things to work.
I am bringing this up purely as a question, is that fear justified or am I missing something? Would be glad for a take on this from someone who knows more.
[0] https://savannah.gnu.org/projects/guix
The choice of GPL doesn't seem to be hurting the Linux Kernel. I doubt it'll hurt a package manager either. Plenty of Debian infrastructure software is also GPLv3.
At any rate, the choice to go "have a pure base" is the right one IMO: it's nice to have a system where I know I have the right to use/modify/distribute changes to the entire thing. It's easier to start with that pure base and add impurities if you need them (eg if your hardware requires blobs to operate it) than the reverse.
That said I think it would be helpful if there was a place to direct users who need to figure out how to install such blobs, even though I agree that the official mailing lists and project repository should not be it. (I am running a blobbed kernel on my current machine because I have to, but I previously was able to run with the linux-libre kernel Guix ships with. It's definitely possible to do if you need to, just not well documented.)
At any rate, the choice to go "have a pure base" is the right one IMO: it's nice to have a system where I know I have the right to use/modify/distribute changes to the entire thing. It's easier to start with that pure base and add impurities if you need them (eg if your hardware requires blobs to operate it) than the reverse.
That said I think it would be helpful if there was a place to direct users who need to figure out how to install such blobs, even though I agree that the official mailing lists and project repository should not be it. (I am running a blobbed kernel on my current machine because I have to, but I previously was able to run with the linux-libre kernel Guix ships with. It's definitely possible to do if you need to, just not well documented.)
It's open source, so of course it's 'possible', but if it's difficult to do and another project actually fully supports my use case, documents it, allows questions on IRC and mailing lists with regards to it... the choice for many is obvious then. Last I checked the Linux Kernel was GPLv2 only, and we all (I guess) know the reasons why.
I guess it depends on what you mean by shoot themselves in the foot. There are major differences in philosophy and bar the "superficial" differences these are quite different projects.
For one nix simply doesn't have a project focused on bootstrapping. As another example compare rust bootstrapping[0] versus using a rust binary[1]. Nix also has no alternative to guix challenge[2] or guix pack[3]. Even a comparison of their documentation shows this difference.
The question is if you consider these measures useful, and if you think bootstrapping is even an issue in the first place. To me this is the bigger question when comparing the two projects, as depending on your philosophy guix is either taking necessary precautions or unnecessary mitigations.
Given posts like this their marketing is okay, I haven't seen much unnecessary childishness - but both projects are fundimentally complicated thus have to invent words for concepts and there's nonguix[4] and most people run nix on GuixSD for their non free software needs.
I doubt guix will be more popular than nix anytime soon, but I don't think NixOS will be more popular than Arch anytime soon either.
[0]: https://guix.gnu.org/blog/2018/bootstrapping-rust/
[1]: https://github.com/NixOS/nixpkgs/pull/85542
[2]: https://guix.gnu.org/manual/en/html_node/Invoking-guix-chall...
[3]: https://guix.gnu.org/manual/en/html_node/Invoking-guix-pack....
[4]: https://gitlab.com/nonguix/nonguix
For one nix simply doesn't have a project focused on bootstrapping. As another example compare rust bootstrapping[0] versus using a rust binary[1]. Nix also has no alternative to guix challenge[2] or guix pack[3]. Even a comparison of their documentation shows this difference.
The question is if you consider these measures useful, and if you think bootstrapping is even an issue in the first place. To me this is the bigger question when comparing the two projects, as depending on your philosophy guix is either taking necessary precautions or unnecessary mitigations.
Given posts like this their marketing is okay, I haven't seen much unnecessary childishness - but both projects are fundimentally complicated thus have to invent words for concepts and there's nonguix[4] and most people run nix on GuixSD for their non free software needs.
I doubt guix will be more popular than nix anytime soon, but I don't think NixOS will be more popular than Arch anytime soon either.
[0]: https://guix.gnu.org/blog/2018/bootstrapping-rust/
[1]: https://github.com/NixOS/nixpkgs/pull/85542
[2]: https://guix.gnu.org/manual/en/html_node/Invoking-guix-chall...
[3]: https://guix.gnu.org/manual/en/html_node/Invoking-guix-pack....
[4]: https://gitlab.com/nonguix/nonguix
> I don't think NixOS will be more popular than Arch anytime soon either.
It seems to already have more packages though (60,000 vs 11,000).
I guess NixOS, and also Guix, will be used first in domains where both recentness of tools and libraries, as well as the capability to exactly reproduce software and results are important, such as in science, AI and commercial data analysis.
It seems to already have more packages though (60,000 vs 11,000).
I guess NixOS, and also Guix, will be used first in domains where both recentness of tools and libraries, as well as the capability to exactly reproduce software and results are important, such as in science, AI and commercial data analysis.
Nix has `nix build --check` which should do the same thing as `guix challenge`. I think there may be more fine tuned options in challenge though.
It's not the same. Guix also has "guix build --check" which builds a package a second time to compare potentially different results.
"guix challenge" challenges different substitute servers and also compares what they offer with what you may have installed (whether you built it locally or downloaded it from elsewhere). It's really quite different from "guix build --check".
"guix challenge" challenges different substitute servers and also compares what they offer with what you may have installed (whether you built it locally or downloaded it from elsewhere). It's really quite different from "guix build --check".
For those who are not into free software, or do not believe in user freedom, I believe there's already an excellent choice of software options, many of which will also sell your privacy. You will not find GNU to compete, good luck!
Yes it's GPLv3, and yes it doesn't package proprietary software. (Would you expect anything else from GNU? :)
There are a few unofficial channels that do package proprietary software for Guix, though they're of course not advertised on the official Guix site, etc.
There are a few unofficial channels that do package proprietary software for Guix, though they're of course not advertised on the official Guix site, etc.
Yeah this is my take on it too. While I deeply admire the GNU philosophy and practice I debated adopting NixOS or Guix a few months ago and ultimately adopted NixOS as I got the same vibe as you.
That said I really want to learn more about Guix. It seems like a more pure impl of a functional package manager but haven’t worked with it enough to know the difference.
That said I really want to learn more about Guix. It seems like a more pure impl of a functional package manager but haven’t worked with it enough to know the difference.
> unnecessarily geeky and childish nomenclature, GPLv3
You seem to be a bit new to this issue.
Building software from source and using FLOSS licenses makes sure that the software is available in the long term and can be developed further (even if the original developers lose interest or run out of time for that).
There are many more advantages in using free (copyleft) software which can be build from source, and making this capability available to the end user as Guix does:
- better privacy protection (the software does not phone home or leaks your private data, as does, for example, Zoom)
- a working software which is used will not be simply withdrawn and be forbidden to use (as many Google software projects).
- useful standards and file formats, such as markup in text documents are available in the long term (I still have latex sources from 1993 around which I wrote in another language that uses different char sets, and which I can today compile without any problem).
- FLOSS software also has the advantage that it is more economical with attention (a very precious human resource), as it only display useful stuff and does not extra things that only have the purpose to capture the attention of the user. For example, I really hate it when I open a web browser with a blank page, to look up something I am working with, and it is full of advertisements for news for completely unrelated stuff up to sexual gossip and celibrity trash, when what I need to do is concentrated work. Once you have become aware of how much many nonfree software wastes your attention, and that this is actively against your interests, it is difficult to ignore that.
- it does not need to assume unrelated features to compete, which prevents feature bloat and improves usability (your picture viewing program does not need to be a file manager, and your image editing program not a publishing platform)
- preventing feature bloat and open interfaces also improves its interopoeration with other software (who does really believe that MS Word is usable?)
- preventing commercial-driven featuritis is also good for long-term usability. I learned to use Unix in 1994 I believe, and I can still navigate and inspect the file system using cd and ls.
- Using open standards also means, for software developers, that their knowledge does not goes out of date quickly or becomes unusable when they change employers. Non-free software tools have a much shorter half-life (anyone still using Silverlight or Visual Basic?), and this means a lot of your learning effort becomes useless after a few years. This might be a minor advantage for somebody who has worked one year or two but it makes a big big difference after many years of working.
- As a lot of innovation happens incrementally and evolutionary, and innovation is based on open exchange of ideas, free software is very open to innovation. At the same time, as working code can always be shared (as, for example, the code for the build daemon in NixOS and Guix), innovation is better conserved than in closed-source software with usual commercial licenses. At a previous employer, I mighhjt have done a really good job with some kind of signal processing which would be useful for things like making wind energy more reliable, but the project manager fucked that up, the software is closed source, and the effort is lost to humanity. I would very much prefer the generation of my niece to get the returns of the work I did.
I could go on for half an hour but I have something else to do :)
But, all of this boils down to that the software on somebody's computer is controlled by its user, not somebody else or a big company which has interests very different from him (or her), and this is what the GPL is about. And yes, the GPL is a means to some end, one could discuss how to reach its specific goal in a different way, but simply labeling its intention as "childish" is just FUD (https://en.wikipedia.org/wiki/Fear,_uncertainty,_and_doubt).
You seem to be a bit new to this issue.
Building software from source and using FLOSS licenses makes sure that the software is available in the long term and can be developed further (even if the original developers lose interest or run out of time for that).
There are many more advantages in using free (copyleft) software which can be build from source, and making this capability available to the end user as Guix does:
- better privacy protection (the software does not phone home or leaks your private data, as does, for example, Zoom)
- a working software which is used will not be simply withdrawn and be forbidden to use (as many Google software projects).
- useful standards and file formats, such as markup in text documents are available in the long term (I still have latex sources from 1993 around which I wrote in another language that uses different char sets, and which I can today compile without any problem).
- FLOSS software also has the advantage that it is more economical with attention (a very precious human resource), as it only display useful stuff and does not extra things that only have the purpose to capture the attention of the user. For example, I really hate it when I open a web browser with a blank page, to look up something I am working with, and it is full of advertisements for news for completely unrelated stuff up to sexual gossip and celibrity trash, when what I need to do is concentrated work. Once you have become aware of how much many nonfree software wastes your attention, and that this is actively against your interests, it is difficult to ignore that.
- it does not need to assume unrelated features to compete, which prevents feature bloat and improves usability (your picture viewing program does not need to be a file manager, and your image editing program not a publishing platform)
- preventing feature bloat and open interfaces also improves its interopoeration with other software (who does really believe that MS Word is usable?)
- preventing commercial-driven featuritis is also good for long-term usability. I learned to use Unix in 1994 I believe, and I can still navigate and inspect the file system using cd and ls.
- Using open standards also means, for software developers, that their knowledge does not goes out of date quickly or becomes unusable when they change employers. Non-free software tools have a much shorter half-life (anyone still using Silverlight or Visual Basic?), and this means a lot of your learning effort becomes useless after a few years. This might be a minor advantage for somebody who has worked one year or two but it makes a big big difference after many years of working.
- As a lot of innovation happens incrementally and evolutionary, and innovation is based on open exchange of ideas, free software is very open to innovation. At the same time, as working code can always be shared (as, for example, the code for the build daemon in NixOS and Guix), innovation is better conserved than in closed-source software with usual commercial licenses. At a previous employer, I mighhjt have done a really good job with some kind of signal processing which would be useful for things like making wind energy more reliable, but the project manager fucked that up, the software is closed source, and the effort is lost to humanity. I would very much prefer the generation of my niece to get the returns of the work I did.
I could go on for half an hour but I have something else to do :)
But, all of this boils down to that the software on somebody's computer is controlled by its user, not somebody else or a big company which has interests very different from him (or her), and this is what the GPL is about. And yes, the GPL is a means to some end, one could discuss how to reach its specific goal in a different way, but simply labeling its intention as "childish" is just FUD (https://en.wikipedia.org/wiki/Fear,_uncertainty,_and_doubt).
I think the comparison to nix is quite unfair, since it's more than twice as old (~7 years vs ~16 years).
Does anyone know of a recent comparison of NixOS vs 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.
Well at least for this:
> We are excited that the Nlnet Foundation has sponsored this work!
> We are excited that the Nlnet Foundation has sponsored this work!
I love the idea of Guix. I also love Scheme and Free software. It seems Guix and I would be a match made in heaven. But then I read things like this: https://guix.gnu.org/blog/2020/deprecating-support-for-the-l... (turns out this was an April fools joke)...
I'm not sure I love Hurd so much. Admittedly, I have not used it, but would be hesitant to rely on it for any important work. Maybe it will prove me wrong. It just seems like it has been an awful lot of work to get Linux to where it is, and it was a pretty bumpy ride at times.
Edit: I guess I'm pretty dense. I hate April fools jokes! But now I'm happy I can start using Guix without fear of being forced into Hurd. That said, I will try out Hurd just for the fun of it.
I'm not sure I love Hurd so much. Admittedly, I have not used it, but would be hesitant to rely on it for any important work. Maybe it will prove me wrong. It just seems like it has been an awful lot of work to get Linux to where it is, and it was a pretty bumpy ride at times.
Edit: I guess I'm pretty dense. I hate April fools jokes! But now I'm happy I can start using Guix without fear of being forced into Hurd. That said, I will try out Hurd just for the fun of it.
I see that guix is a declarative package manager like nix. Where does it have a leg up over nix?
And how's the GUI integration with KDE and gnome? Is there a backend for KDE Discover or the Gnome Software Center?
Finally, I see that installation goes over a "curl | bash", which imo is a pretty insecure method of installation. I can understand why such an insecure method exists (so many different ways of installing software on linux), but that's like saying HTTP is a good idea because it's easier than HTTPS.
And how's the GUI integration with KDE and gnome? Is there a backend for KDE Discover or the Gnome Software Center?
Finally, I see that installation goes over a "curl | bash", which imo is a pretty insecure method of installation. I can understand why such an insecure method exists (so many different ways of installing software on linux), but that's like saying HTTP is a good idea because it's easier than HTTPS.
> Finally, I see that installation goes over a "curl | bash", which imo is a pretty insecure method of installation
So comparing https://nixos.org/download.html and https://guix.gnu.org/manual/en/html_node/Binary-Installation... - nix is curl | sh from a https address; guix is wget && chmod +x && run shell script. Both also have a trivially-available way to do GPG verification before running anything. So I'd call them pretty close.
In absolute terms, honestly I'm not sure it is that big of a deal; default protection is HTTPS, and GPG is easily available. The only obvious issue that I see is that nix might be vulnerable to the truncated-stream issue; I forget whether that can happen over HTTPS or not.
So comparing https://nixos.org/download.html and https://guix.gnu.org/manual/en/html_node/Binary-Installation... - nix is curl | sh from a https address; guix is wget && chmod +x && run shell script. Both also have a trivially-available way to do GPG verification before running anything. So I'd call them pretty close.
In absolute terms, honestly I'm not sure it is that big of a deal; default protection is HTTPS, and GPG is easily available. The only obvious issue that I see is that nix might be vulnerable to the truncated-stream issue; I forget whether that can happen over HTTPS or not.
This post is a pretty good example, for I don't know of any nix projects that are attempting to work on the bootstrapping problem. Guix pack[0] solves a parallel issue of distributing your nicely dependancy managed ecosystem whereas nix's alternative with nix-bundle barely works.
At the moment neither have gui integration and unfortunately both could use a lot of work with onboarding and beginner (I'm taking non programmers) friendliness.
[0]: https://guix.gnu.org/manual/en/html_node/Invoking-guix-pack....
At the moment neither have gui integration and unfortunately both could use a lot of work with onboarding and beginner (I'm taking non programmers) friendliness.
[0]: https://guix.gnu.org/manual/en/html_node/Invoking-guix-pack....
> At the moment neither have gui integration and unfortunately both could use a lot of work with onboarding and beginner (I'm taking non programmers) friendliness.
I think non-programmer friendliness can wait till there are enough technical users that the superficial daily-experience bugs get ironed out, and also the newbies have a social support system for onboarding. Trying to jump that curve will prove painful in the long term.
I would love to see the guidance and tools for technical users to try this out and start switching over the next few years.
AFAIK, Gnome/KDE or some other DE can be built/installed like any other package, so one can certainly have pretty much any GUI, just like any other Linux distribution.
I think non-programmer friendliness can wait till there are enough technical users that the superficial daily-experience bugs get ironed out, and also the newbies have a social support system for onboarding. Trying to jump that curve will prove painful in the long term.
I would love to see the guidance and tools for technical users to try this out and start switching over the next few years.
AFAIK, Gnome/KDE or some other DE can be built/installed like any other package, so one can certainly have pretty much any GUI, just like any other Linux distribution.
I like the container support! Declarative containers is an area where Dockerfiles fall short in my experience.
I’ve been using the NixOS container support which has drastically streamlined and unified the largely similar but many small variations of containers that I use https://nixos.org/nixos/manual/#ch-containers
I’ve been using the NixOS container support which has drastically streamlined and unified the largely similar but many small variations of containers that I use https://nixos.org/nixos/manual/#ch-containers
I am a basic Nix user so I can't speak to much, but my understanding is that one of the major difference is Guix uses Scheme (or a Scheme-like language) for config so it's more familiar. Nix uses their own language, also called Nix.
On the other hand I believe the package repo for Nix is much more comprehensive and kept more up to date.
On the other hand I believe the package repo for Nix is much more comprehensive and kept more up to date.
NixOS is an awesome system and Guix owes much to it and its creator, @edolstra.
Although GNU Guix is my personal preference, I believe that NixOS is an excellent choice and for the most part we have a shared vision.
If you are still using a legacy system, you'll want to try NixOS or GNU Guix!
Although GNU Guix is my personal preference, I believe that NixOS is an excellent choice and for the most part we have a shared vision.
If you are still using a legacy system, you'll want to try NixOS or GNU Guix!
> On the other hand I believe the package repo for Nix is much more comprehensive and kept more up to date.
What makes you say so?
(disclaimer: I'm a contributor to Guix and just upgraded several hundred R packages.)
What makes you say so?
(disclaimer: I'm a contributor to Guix and just upgraded several hundred R packages.)
When I was deciding between Nix and Guix, perhaps 5 years ago, I definitely got the impression that Nix had more contributors and the more comprehensive package set, which is one reason why I ultimately decided on NixOS. I couldn't say which was more up-to-date, but, well, anything not up-to-date is an excuse for me to contribute :)
That being said, at the time I had wanted to choose Guix over Nix. The channels seemed a bit better thought-out and grafts sounded like a good idea.
Not having a lisp background though, it was just easier for me to get into Nix.
That being said, at the time I had wanted to choose Guix over Nix. The channels seemed a bit better thought-out and grafts sounded like a good idea.
Not having a lisp background though, it was just easier for me to get into Nix.
This is extremely neat but the name "gash" is... a poor choice. Gory in standard English, worse as a slang term
I don't think it's intended as that slang... I think it's probably in the scheme tradition of self-deprecating conspiratorial names... I suspect it's meant to invoke that theme.
Not to mention that "bash" sounds like a concussive injury; "gash" sounds like a slicing injury. So follows that theme also.
I would be very surprised if genitalia slang came up in the author's mind as a choice of names but I guess I don't know them.
Not to mention that "bash" sounds like a concussive injury; "gash" sounds like a slicing injury. So follows that theme also.
I would be very surprised if genitalia slang came up in the author's mind as a choice of names but I guess I don't know them.
I'm amazed how it can be possible not understand that what came up in the author's mind is not the issue at all, and irrelevant.
According to your reasoning, I can name an alarm program "cock", just as long as what was going through my mind at the time was a rooster crowing in the morning. ("Get woken up by cock!") What anyone else chooses to read into it is their problem?
According to your reasoning, I can name an alarm program "cock", just as long as what was going through my mind at the time was a rooster crowing in the morning. ("Get woken up by cock!") What anyone else chooses to read into it is their problem?
> I'm amazed how it can be possible not understand that what came up in the author's mind is not the issue at all, and irrelevant.
Oh my, then you better not ever venture into the humanities! At least in musicology they spent the past 3 decades wresting free from the idea that evidence of the author's intentions are the only relevant thing.
Oh my, then you better not ever venture into the humanities! At least in musicology they spent the past 3 decades wresting free from the idea that evidence of the author's intentions are the only relevant thing.
Is the author of the project a fluent speaker of English?
Not everyone will be familiar with slangs in various countries.
Not everyone will be familiar with slangs in various countries.
Well, there is Coq, the interactive theorem prover. I quite like the name (and the logo, which is a rooster.)
Legend has it that Gérard Huet, who named Coq, enjoys double entendre and chose the name deliberately, just like he did with the Zipper data structure. So this might not be a great example of something that accidentally has a double meaning.
Apparently some British researchers were working on a theorem prover named Bit, which in French sounds like "bitte" (slang for penis). So the French researchers who worked on Coq cheekily chose a French word with a double-entendre meaning in English.
But all these anecdotes counteract what Wikipedia says, which is that Coq was named for one of its authors, Thierry Coquand, and for his "calculus of constructions" (CoC).
But all these anecdotes counteract what Wikipedia says, which is that Coq was named for one of its authors, Thierry Coquand, and for his "calculus of constructions" (CoC).
>But all these anecdotes counteract what Wikipedia says, which is that Coq was named for one of its authors, Thierry Coquand, and for his "calculus of constructions" (CoC).
It being named after Coquand is unsourced and even states something that is outright wrong (Coquand is not Coq's "principal author", the best fit would be Huet and Christine Paulin, but even then it was developed by a team, they just lead it. Source: Coq's history page).
It being named after Coquand is unsourced and even states something that is outright wrong (Coquand is not Coq's "principal author", the best fit would be Huet and Christine Paulin, but even then it was developed by a team, they just lead it. Source: Coq's history page).
"cock" is not a very good example. Gash, as slang, is nowhere near as often used as "cock". Gash's meaning as "a long, deep cut" is, by far, the most used meaning. Whereas "cock", nowadays, the slang term is pretty much the only used meaning. Peach, rod, purse, knob, sheath, pocket, meat, etc. All these words have alternate slang meanings as well. Should we stop using their original meanings? Like I said in another comment, language is all about context. I've only ever heard 'gash' used as slang in the U.K. I would imagine a very large chunk of the English speaking population only know the non-slang meaning.
Stallman's fanbase can call themselves the Bash Gash Terror Crew.
Why do you pronounce it like that, though? I pronounce it like "geesh" or "guish" or "guiche" (not sure how to write it phonetically). It is just the Catalan word for "chalk".
Not Guix, Gash: https://savannah.nongnu.org/projects/gash
Gash is a slang term for the female sexual organ.
Not a good name for a project.
Not a good name for a project.
If we were to reserve every word that is also used as slang for sexual organs we'd be out a lot of words. Peach, purse, shaft, sheath, tool, pocket, etc, these are all slang as well, yet we still use these for their original meaning. It's all about context. I'd also say 'gash' is quite regional. I've only ever heard it used in the U.K.
[deleted]
It's amazing that in 2020 people still use relatively common English words to name their software. Apart from all the confusion (context needed to understand what is being meant) and issues such as those you mentioned, the projects will be hard to google, risk collisions with other projects, have domain and trademark conflicts etc. ... Just make up artificial words, concatenate several terms etc. people. Though in this particular case, conventions like "has to end with 'sh' because ... cargo cult" and "must be easy to type" probably played a role.
I'd thank you for not making HN a worse place by bikeshedding. You may not care about this project, but some people here do.
It's not bikeshedding. The open source community has opened its eyes to how poor a job of inclusivity it's done, and one of the changes that resulted was a social taboo against names and terminology that serve as microaggressions, including "master", "slave", "blacklist", "cop", and "gimp". Given the context in which "gash" is often used in ordinary language, it's reasonable to at least question its use as a project name.
No reasonable person thinks "woman" when she encounters the word "gash". I'd wager there are fairly few unreasonable people who think that, but of course it only takes one to kick off a spriraling pointless bikeshedding thread. It's good that we've got this inanity flagged to the bottom, but when I commented it was at the top.
I would suggest "gnash" as a much more appealingly playful alternative
Already taken[1].
[1]: https://www.gnu.org/software/gnash/
[1]: https://www.gnu.org/software/gnash/
Is anybody using this? What do you like about it versus a more typical linux or unix? Is hardware support good enough to run on a relatively recent laptop?
I set it up on my laptop as an experiment, and am greatly enjoying using it: it's nice to work on a modern, well thought-out distribution in its early stages, with lots of opportunities to contribute.
The ease by which you can manage and roll-out new configurations means that it's slowly spreading to other systems I manage.
It's also interesting to work on a distribution that takes the GNU project seriously: the developers default to using GNU software where possible, and are clearly striving to make a coherent operating system out of its parts. This is less an ideological position than it sounds -- there's a lot of gold buried in nearly half a century of GNU work, and I've enjoyed learning about it all, and seeing how the Guix team go about improving and modernising it.
The ease by which you can manage and roll-out new configurations means that it's slowly spreading to other systems I manage.
It's also interesting to work on a distribution that takes the GNU project seriously: the developers default to using GNU software where possible, and are clearly striving to make a coherent operating system out of its parts. This is less an ideological position than it sounds -- there's a lot of gold buried in nearly half a century of GNU work, and I've enjoyed learning about it all, and seeing how the Guix team go about improving and modernising it.
I'm using Guix System on new Dell servers, old Sun servers, a Dell laptop, a Purism Librem laptop, an old Thinkpad --- it works just fine.
I think the fear of missing drivers when using Linux without blobs is extremely overstated. Yes, certain WiFi cards won't work without blobs, and yes, the 3D graphics situation is not great thanks to NVIDIA and AMD.
> What do you like about it versus a more typical linux or unix?
Oh, so many things... But most important for me is stateless configuration, reproducible builds, no-nonsense application bundles without all that Dockeresk cruft via "guix pack", ad-hoc environments, etc.
I think the fear of missing drivers when using Linux without blobs is extremely overstated. Yes, certain WiFi cards won't work without blobs, and yes, the 3D graphics situation is not great thanks to NVIDIA and AMD.
> What do you like about it versus a more typical linux or unix?
Oh, so many things... But most important for me is stateless configuration, reproducible builds, no-nonsense application bundles without all that Dockeresk cruft via "guix pack", ad-hoc environments, etc.
> 3D graphics situation is not great thanks to NVIDIA and AMD.
AMD is now one of the good guys when it comes to open source:
https://en.wikipedia.org/wiki/AMDGPU
Basically, since 2015, AMD has offered an official driver under an MIT license for Linux and *BSD. Personally, I'm definitely choosing AMD for my next laptop :).
AMD is now one of the good guys when it comes to open source:
https://en.wikipedia.org/wiki/AMDGPU
Basically, since 2015, AMD has offered an official driver under an MIT license for Linux and *BSD. Personally, I'm definitely choosing AMD for my next laptop :).
Unless things have changed recently, AMD GPUs still require proprietary firmware and thus do not work on a fully free system. I bought an AMD GPU a few years ago to try it out and it didn't work.
As do Intel[1] and Nvidia[2].
[1]: https://git.kernel.org/pub/scm/linux/kernel/git/firmware/lin...
[2]: https://git.kernel.org/pub/scm/linux/kernel/git/firmware/lin...
[1]: https://git.kernel.org/pub/scm/linux/kernel/git/firmware/lin...
[2]: https://git.kernel.org/pub/scm/linux/kernel/git/firmware/lin...
I have been using GNU Guix for over 4 years now on a modern Dell laptop (exchanged the WIFI card to keep my freedom), two older thinkpads, home server.
Since three years our development team at work uses Guix; the reproducible offload builds are awesome. Extending the package graph with your own version of packages is very helpful. Since about a year we also use server(s) at Digital Ocean running GNU Guix.
Since three years our development team at work uses Guix; the reproducible offload builds are awesome. Extending the package graph with your own version of packages is very helpful. Since about a year we also use server(s) at Digital Ocean running GNU Guix.
I am mostly using GUIX package manager as a package manager on multiple foreign distros. It makes it very easy to get up to date versions of free software, when the repositories of your distro lack behind.
I've also experimented recently with using it for creating environments (actually called profiles in GUIX) for programming projects. That also works.
There is a lot more to discover for me, once I get around to it.
I've also experimented recently with using it for creating environments (actually called profiles in GUIX) for programming projects. That also works.
There is a lot more to discover for me, once I get around to it.
Just a reminder, you can also use Guix as a package manager only on top of, for example, a Debian or Arch system (I am using it currently on top of both). This works very much like Python's pip / virtualenv, and is extremely helpful if you use many different libraries and new tools when developing software, or if you want to try out new things without changing your base system, and without wanting to set up a full VM.
That isn't the purpose. It isn't for end users to run. It's to be able to have confidence that the object code in a software distribution depends only on the source code, and not on something that a clever attacker has managed to sneak in, using a variant of the Thompson "trusting trust" attack.
I think dilandau is asking if anyone is using Guix.
Just compare the difficulty of trying to use the third party nix-bundle to produce a binary for another system versus guix pack.