A few months ago I started tinkering with Guix. The docs are clear, they used an existing language (Guile Scheme), the CLI is coherent, the error messages mostly make sense. I’ve had to put the side project on hold, but overall it’s been a really positive experience and I’m looking forward to getting back to it.
Checking back for the repost, I see the bug I filed that Nix’s “hello world” doesn’t build is still open. Looks like the commenters have found a solution, and I see the docs have changed, so maybe it’s solved.
As a user I’ve been happier with guix than I have been with nix. Like you I found the docs to be clear and the CLI to be coherent. Where it falls short for me is there doesn’t seem to be consistent support for things like GNOME or KDE.
Guix looks great and after hitting many frustrating roadblocks with Nix I was also hoping to use it. The problem is that it suffers from the same disease that many GNU projects do. It prefers ideological purity over actually working for users. I’m not allowed to have CUDA support, MKL, etc. There’s a reason why Nix has far more users even though it appears to be inferior.
It goes against the principles of the Guix developers, but if you don’t share all their principles, you can immediately install the nonguix Guix channel from nonguix
It’s not so easy. I can’t ask questions about these packages or get help with them:
Please do NOT promote or refer to this repository on any official Guix communication channels.
They’re also very thin, for example, there are no CUDA packages.
Guix developers can of course use whatever principles to guide their development, but it is sad that some types of thoughts are ideologically forbidden in the community. I don’t want to be a part of that personally. It’s also a huge waste of developer time.
CUDA isn’t really something that with be on the guix maintainers to make work. Like most community projects it will be a matter of growing the community and waiting for people to take up the task of packaging CUDA.
There is a guix HPC group and while they haven’t added CUDA support that is one of those things I sort of expect to be coming with time and as interest in guix mounts.
For sure, the Guix maintainers don’t need to get it working, but it’s not that they don’t care about CUDA or any of these other packages. They are actively hostile by not even allowing people to discuss them in their presence. They also refuse to, for example, test if any Guix changes break these packages. You cannot even file a bug report that a Guix change breaks a non-free package!
There is a big difference between “it’s not up to the devs to do this” and the “devs are actively opposed”. Compare the Guix approach to the Debian one. Debian also doesn’t want people to use non-free software and it lives in a separate directory. But I am allowed to discuss such packages on the mailing list and IRC. I can ask questions if I have difficulty with a package, of course, the devs don’t need to answer, but someone else maybe can. I can file a bug report to say that a change affects me. All of these are forbidden and enforced by the Guix developers.
It’s a shame that Guix developers are so dogmatic and politicized that they actively expend effort to hurt users when they could just let them be.
I know it’s annoying, but nobody is stopping you from writing derivations (or whatever the Guix equivalent is called) for those features. It’s just not supported by the Guix developers and project in an official capacity, because it goes against the push for people to use Free Software and hardware which supports that.
because it goes against the push for people to use Free Software and hardware which supports that.
This is why Nix will always have more users. Programers need to solve problems and sometimes the easiest/best solution involves proprietary software. Nix gives its users the freedom to (more easily) use non-free software.
At work when I have a deadline or for personal projects where I have limited free time, I don’t want to have a lot of extra work just because the best solution uses some proprietary code. In a perfect world I would only use free software, but I have work to do.
That is a fair point. My worry is that that target audience for this very useful piece of technology would be much greater if they were slightly less dogmatic with their approach to non-free software.
This is quite a great overview of Nix and lists exactly the downsides that frustrate(d) me. There is (2020) some push to bring documentation to a better state and better consistency, but I fear it just increases the entropy (we now have nix-build and nix build`, both taking different arguments…).
The CLI rewrite should help out a lot, especially by adding a consistent style. Where it still falls short for me is a lot of tools have been created by third parties, particularly importers, but they remain non-intuitive for me and many of them have very poor quality man pages.
Let me ask this, as a Nix-curious person (and I realize I’m more focused on Nix packaging than NixOS per se here): can one’s involvement with Nix be limited to providing and using consistent/reproducible/{insert your favorite qualifier here} development environments? In other words, do you need to adopt the whole Nix “lifestyle” to reap value from it, or can you pick pieces from it you like and have it coexist peacefully within a larger system? I’m guessing the answer is “yes” but I’m interested in folks’ experience and drawing out the subtleties and possible landmines.
In other words, do you need to adopt the whole Nix “lifestyle” to reap value from it, or can you pick pieces from it you like and have it coexist peacefully within a larger system? I’m guessing the answer is “yes” but I’m interested in folks’ experience and drawing out the subtleties and possible landmines.
Yep, its as opt in as you want it to be. Bite off a bit at a time is all I’ve done on my mac as an example, as time goes on i move more and more into it but thats more out of wanting as much of my environment setup through nix and reproducible than anything.
As a longtime NixOS user for a variety of purposes who has recently switched over to macOS for work and has never used Nix for packaging…I will say “no” to this. I’m using it happily as a substitute for brew or homeports or whathaveyou. I think the hardest part is introducing it…and building packages (but it’s doable, clearly). Has many warts that basically have been boiling down to: “it’s mostly an issue with the documentation”. Maybe so. In any case, having Nix around has made my life both harder and simpler at the same time.
A few months ago I started tinkering with Guix. The docs are clear, they used an existing language (Guile Scheme), the CLI is coherent, the error messages mostly make sense. I’ve had to put the side project on hold, but overall it’s been a really positive experience and I’m looking forward to getting back to it.
Checking back for the repost, I see the bug I filed that Nix’s “hello world” doesn’t build is still open. Looks like the commenters have found a solution, and I see the docs have changed, so maybe it’s solved.
As a user I’ve been happier with guix than I have been with nix. Like you I found the docs to be clear and the CLI to be coherent. Where it falls short for me is there doesn’t seem to be consistent support for things like GNOME or KDE.
Guix looks great and after hitting many frustrating roadblocks with Nix I was also hoping to use it. The problem is that it suffers from the same disease that many GNU projects do. It prefers ideological purity over actually working for users. I’m not allowed to have CUDA support, MKL, etc. There’s a reason why Nix has far more users even though it appears to be inferior.
It goes against the principles of the Guix developers, but if you don’t share all their principles, you can immediately install the nonguix Guix channel from nonguix
It’s not so easy. I can’t ask questions about these packages or get help with them:
They’re also very thin, for example, there are no CUDA packages.
Guix developers can of course use whatever principles to guide their development, but it is sad that some types of thoughts are ideologically forbidden in the community. I don’t want to be a part of that personally. It’s also a huge waste of developer time.
CUDA isn’t really something that with be on the guix maintainers to make work. Like most community projects it will be a matter of growing the community and waiting for people to take up the task of packaging CUDA.
There is a guix HPC group and while they haven’t added CUDA support that is one of those things I sort of expect to be coming with time and as interest in guix mounts.
For sure, the Guix maintainers don’t need to get it working, but it’s not that they don’t care about CUDA or any of these other packages. They are actively hostile by not even allowing people to discuss them in their presence. They also refuse to, for example, test if any Guix changes break these packages. You cannot even file a bug report that a Guix change breaks a non-free package!
There is a big difference between “it’s not up to the devs to do this” and the “devs are actively opposed”. Compare the Guix approach to the Debian one. Debian also doesn’t want people to use non-free software and it lives in a separate directory. But I am allowed to discuss such packages on the mailing list and IRC. I can ask questions if I have difficulty with a package, of course, the devs don’t need to answer, but someone else maybe can. I can file a bug report to say that a change affects me. All of these are forbidden and enforced by the Guix developers.
It’s a shame that Guix developers are so dogmatic and politicized that they actively expend effort to hurt users when they could just let them be.
I know it’s annoying, but nobody is stopping you from writing derivations (or whatever the Guix equivalent is called) for those features. It’s just not supported by the Guix developers and project in an official capacity, because it goes against the push for people to use Free Software and hardware which supports that.
At work when I have a deadline or for personal projects where I have limited free time, I don’t want to have a lot of extra work just because the best solution uses some proprietary code. In a perfect world I would only use free software, but I have work to do.
Well yeah, I’m not saying you’re wrong, I’m saying you’re not the target audience for Guix.
That is a fair point. My worry is that that target audience for this very useful piece of technology would be much greater if they were slightly less dogmatic with their approach to non-free software.
This is quite a great overview of Nix and lists exactly the downsides that frustrate(d) me. There is (2020) some push to bring documentation to a better state and better consistency, but I fear it just increases the entropy (we now have
nix-build andnix build`, both taking different arguments…).The CLI rewrite should help out a lot, especially by adding a consistent style. Where it still falls short for me is a lot of tools have been created by third parties, particularly importers, but they remain non-intuitive for me and many of them have very poor quality man pages.
Let me ask this, as a Nix-curious person (and I realize I’m more focused on Nix packaging than NixOS per se here): can one’s involvement with Nix be limited to providing and using consistent/reproducible/{insert your favorite qualifier here} development environments? In other words, do you need to adopt the whole Nix “lifestyle” to reap value from it, or can you pick pieces from it you like and have it coexist peacefully within a larger system? I’m guessing the answer is “yes” but I’m interested in folks’ experience and drawing out the subtleties and possible landmines.
Yep, its as opt in as you want it to be. Bite off a bit at a time is all I’ve done on my mac as an example, as time goes on i move more and more into it but thats more out of wanting as much of my environment setup through nix and reproducible than anything.
As a longtime NixOS user for a variety of purposes who has recently switched over to macOS for work and has never used Nix for packaging…I will say “no” to this. I’m using it happily as a substitute for brew or homeports or whathaveyou. I think the hardest part is introducing it…and building packages (but it’s doable, clearly). Has many warts that basically have been boiling down to: “it’s mostly an issue with the documentation”. Maybe so. In any case, having Nix around has made my life both harder and simpler at the same time.