8 ms·

Attempting to Use GNU Guix

120 points by stargrave 7y ago

adilsaju 7y ago
asffs
pmoriarty 7y ago
Guix in general just needs a lot more contributors and lot more work to come anywhere close to being a competitor to the mainstream (or even near-mainstream) distros and package managers. I'm coming from Gentoo myself, and I've tried to get Guix working on Gentoo a couple of times over the years, and have always been frustrated by how much work and hacking was involved in doing so. I'm no Linux novice, either. I've been a professional Linux/UNIX admin for decades, I know and love Scheme, and am no stranger to putting in a lot of work to get something to run on Linux, but I failed in two major attempts with Guix, despite having lots of thorough assistance from Guix developers on #guix on IRC. So back to Gentoo's package manager I went. A typical user would not have put in nearly that much work to trying it out, nor would they have had the skills or knowledge to get nearly as far as I did. Though, to be honest, I did have some requirements (like doing my own compilation of everything on my own old, slow laptop, just as I'd been doing with Gentoo, and not trusting their binary distribution) that a typical user would not. The other lesson I got from my last attempt was that trying to compile everything in Guix from scratch on an old laptop is just way too slow. Doing this on Gentoo is slow and painful enough, but it's way worse on Guix, and simply unworkable. You really have to have a fast, modern system (or offload your compilation to another machine which will crank away for weeks on end and that you can then download the binaries from) to constantly compile everything you need for Guix. That said, Guix has really come a long way over the years, and it's impressive to see how far they've come, and I'd absolutely love to see them succeed, but they've got a long, long, long way to go.
- martinflack 7y ago
  > trying to compile everything in Guix from scratch on an old laptop is just way too slow. Doing this on Gentoo is slow and painful enough, but it's way worse on Guix, and simply unworkable Would you elaborate on why you think compilation on Guix is slower than Gentoo? Thanks.
  - pmoriarty 7y ago
    It's not that compilation itself was slow with Guix, but (to my memory) it was because all Guix packages are completely separate by design and have dependencies which are not shared, so you might have to compile, say, five different versions of guile to satisfy those five different dependencies in five different packages. Compiling guile from scratch was, by the way, insanely slow, and because I struggled to get Guix working right on my first try, I had to compile it over and over again, which took about a day each time. A "guix pull" took four hours on my system, and I had to do it twice each time, once for root and once for my own user. My first "guix pull" took two weeks due to all the errors, toubleshooting and restarts the process took as I tried to get Guix working as it should. In addition, it seems that Guix packages don't have optimizations enabled, which is a deal breaker for me, as optimizing the packages I install is a significant reason I compile them from scratch in the first place, as I'm running on an old, slow machine which could use all the performance boosts it can get. Finally, I might have a broken environment on my system which makes compilation even slower still than it otherwise would be, but until I get it fixed I have to live with it, and so for all of these reasons compiling everything from scratch on Guix is just not practical for me right now. Maybe with a newer, much faster machine I'd be ok with it.
    - 70rd 7y ago
      Just out of curiosity, why not use distcc? I have a recent i7 and still compile essentially all packages on my homelab, I feel that the benefit would be even more marked for you.
p0cc 7y ago
Thank you for shedding light on a distro I didn't know existed! One tip: The contrast on your code blocks is terrible with white text against a light white background. Consider changing the `background` of line 3 of style.css to `purple`, `darkorange`, or some other dark color.
- chaorace 7y ago
  Seems like normal Solarized to me?
  - XaspR8d 7y ago
    Must be rendering differences among us -- I don't think solarized uses white on yellow... EDIT: Ahh it's probably that the site uses `prefers-color-scheme` media queries, but missed a couple cases.
  - Arnavion 7y ago
    It's broken for dark mode due to a `body { color: white }` rule in style.css. The code block background is not overridden so it remains light yellow while the text is white.
- daptaq 7y ago
  Oops, sorry for that. I don't have a browser that supports dark mode, so I just tried something that I thought may work. Then I changed some CSS earlier this morning that probably messed something up. I'll try to fix it as soon as possible.
mmahut 7y ago
Go Nix.
ninjin 7y ago
Sad to see GNU Guix struggling, they are young though and I have hopes for the future. About a year ago I made a choice between trying out GNU Guix and NixOS, since this week I now run NixOS on all my servers and desktops after gradually phasing out my old Ubuntu stack. It has generally been smooth sailing, with the occasional hick up that required me to draw upon my general Unix skills. What caught me off guard is how having a solid configuration to revert to has made me start tinkering with my operating system again akin to how I did when I started using Linux/BSD in the early 00s. But, enough about NixOS, I hope GNU Guix continues to make progress as there needs to be more competition in this space. If you have an evening to spare, I highly recommend trying a distribution like this out in a VM to get a taste of what it feels like to use it – it is, different… but in a good way.
- deleted 7y ago
  [deleted]
- zaphirplane 7y ago
  Something I couldn’t get about nix by skimming the documentation is how it manages application configuration. Using traditional systems when you upgrade the package responsible for the network configuration my current configuration is carried thru or merged into the new format if the package changes it’s configuration syntax. How does nixos manage /etc ?
  - evil-olive 7y ago
    For the majority of changes, it "just works". For example, here's the part of nixpkgs that configures wireless networking via wpa_supplicant, as well as the actual package build of wpa_supplicant: https://github.com/NixOS/nixpkgs/blob/nixos-19.09/nixos/modules/services/networking/wpa_supplicant.nix https://github.com/NixOS/nixpkgs/blob/nixos-19.09/nixos/modu... https://github.com/NixOS/nixpkgs/blob/nixos-19.09/pkgs/os-specific/linux/wpa_supplicant/default.nix https://github.com/NixOS/nixpkgs/blob/nixos-19.09/pkgs/os-sp... Because they're contained within the same git repo, if a new version of wpa_supplicant changed the syntax of wpa_supplicant.conf, the upgrade could be handled easily (assuming the user-facing options in NixOS didn't need to change). For more complicated changes, there's `system.stateVersion`: https://nixos.wiki/wiki/FAQ/When_do_I_update_stateVersion https://nixos.wiki/wiki/FAQ/When_do_I_update_stateVersion An example of this would be if NixOS version A ships with Postgres version X by default, while NixOS version B upgrades to Postgres version Y. stateVersion allows a sane upgrade path where you can update to NixOS version B without breaking your database immediately (because stateVersion is still A).
MrBingley 7y ago
I understand and perhaps admire the GNU project's insistence on being blob-free, but that also means Guix won't run out of the box on 99% of all people's computers. The options are buy (old) hardware that doesn't need blobs (which sometimes isn't even possible), or compile the default kernel to include the binary firmware yourself (which the Guix documentation won't explain for ideological reasons). Both of these will sadly limit the appeal of this distribution to enthusiasts-only, which is unfortunate since Guix probably has the most advanced package manager of any Linux system.
- dorfsmay 7y ago
  True for workstations, but most services are running on VMs these days. OS shouldn't need blobs to run on VMs.
  - big_chungus 7y ago
    Right, but now you have two separate operating systems to manage which are different at the kernel level (as your host is probably linux, bsd, esxi, etc.) This means you often have to manage twice the amount of tooling, documentation, scripts, etc. and makes it impractical for many cases.
- m463 7y ago
  I guess it depends on what you're optimizing. Hard for a user, but simple for distribution or legal.
- enriquto 7y ago
  There's already hundreds of distributions with binary blobs. It is very important that at least a few respect user's freedom. So it's great that Guix exists and that it has a serious stance against secret blobs.
jwilk 7y ago
> For a new package to be accepted into the [Debian] stable branch, it has to pass a number of days without any bug reports. Um, that's not even remotely close to what the actual stable inclusion rules look like.
- justinsaccount 7y ago
  It is close to the rules for a package to get included into 'testing' from unstable, they must have gotten the branches mixed up.
  - daptaq 7y ago
    (I wrote the text) I mixed the two up, will fix.
enriquto 7y ago
i feel very alienated by the guix developers due to the way they are betraying the gnu leadership. This is sad because it is such a nice and important project. But I cannot easily separate the work from the people who did it.
- rowanG077 7y ago
  Yep... I don't really want to interface with morally corrupt people. Fortunately NixOS exists.
- jwilk 7y ago
  > they are betraying the gnu leadership What do you mean?
  - cwyers 7y ago
    My guess is that they're referring to the open letter from people working on many GNU projects calling for Stallman to resign.
    - jwilk 7y ago
      I think this is the letter in question: https://guix.gnu.org/blog/2019/joint-statement-on-the-gnu-project/ https://guix.gnu.org/blog/2019/joint-statement-on-the-gnu-pr...
      - takeda 7y ago
        I still don't know what Stallman did.
        bugbug99 7y ago
        Got caught up in an organized witch-hunt to remove him from power. Too much freedom of speech for the current FSF.
        7y ago
foopdoopfoop 7y ago
I don't know that much about Guix, other than "super-free Nix with scheme" (and the article wasn't particularly illuminating other than boiling down to "Guix isn't really ready for most users right now"), but it's neat that there's momentum in the declarative OS-space. I hope that both Guix and NixOS keep growing and that more people start switching. After switching to NixOS, I'd find it very frustrating to go back to an OS with imperative-style package/service management. It's clearly the better way. A frustrating thing about NixOS--coming from Arch Linux and being used to the AUR--is that adding packages/updating packages can be a bit slow due to the sheer volume of PRs/Issues on the nixpkgs repo. There's always the NUR[1] but it hasn't picked up that much momentum yet (probably because it's kind of hard to search the darn thing). Eitherway, the packages are just Nix expressions and repos are just collections of these expressions, so nothing's preventing a real AUR alternative other than momentum. It's interesting that Guix uses scheme instead of a home-baked configuration language like NixOS. While I don't find Nix particularly offensive, I don't find it particularly great either. And maybe this is naivity/Nix-inexperience on my part speaking, but I really wish that Nix had a proper type system and was strictly typed. I guess my pipe dream is "HaskellOS" that's basically NixOS configured with Haskell (just think of xmonad-style configuration for your whole OS). That'd be really nice. And my secondary-pipe dream is a baked in, extremely-comprehensive home-manager[2] so we can bid dotfiles goodbye once and for all and have your entire system-state defined in a single file. Maybe one day :) [1] https://github.com/nix-community/NUR https://github.com/nix-community/NUR [2] https://github.com/rycee/home-manager https://github.com/rycee/home-manager
- agumonkey 7y ago
  In the tradition of name monad suffixing, it shall be called Sysmonad
- justinsaccount 7y ago
  It's probably more similar to NixOps, but there is https://propellor.branchable.com/ https://propellor.branchable.com/ http://joeyh.name/blog/entry/unifying_OS_installation_and_configuration_management/ http://joeyh.name/blog/entry/unifying_OS_installation_and_co... kinda talks about this sort of thing
- 7y ago
ArchLinuxBtw 7y ago
Given the recent shakeup at GNU, perhaps the "GNU" branding should be dropped, in order to make this project more welcoming to women and the oppressed.
m45t3r 7y ago
I would recommend the author to try NixOS instead. It is not like that you wouldn't have issues however mostly things works (never had the kind of issue the author reported in this post, for example). I think the difference between NixOS and Guix, excluding the language of choice of course, is that NixOS has the community to make it work. For example, I had a issue last night that I opened a issue in GitHub, and in a few hours the maintainer of the problematic package answered me and the problem was fixed.
Someone 7y ago
”Just run guix package --roll-pack to “undo” an installation.” I don’t know guix, but that looks like a typo to me. Shouldn’t that be back, not pack?
- opan 7y ago
  'guix package --rollback' is what's in my shell history, so it should probably say that.
Iv 7y ago
I love the style of packets organization that they describe. I think it has a name, I have seen it promoted as an alaternative to the typical mess that is "install everything in various parts of /usr/ and /opt/, put things in /etc/ or ~, silently overwrite old versions"

120 points by stargrave 7y ago

asffs

Guix in general just needs a lot more contributors and lot more work to come anywhere close to being a competitor to the mainstream (or even near-mainstream) distros and package managers. I'm coming from Gentoo myself, and I've tried to get Guix working on Gentoo a couple of times over the years, and have always been frustrated by how much work and hacking was involved in doing so. I'm no Linux novice, either. I've been a professional Linux/UNIX admin for decades, I know and love Scheme, and am no stranger to putting in a lot of work to get something to run on Linux, but I failed in two major attempts with Guix, despite having lots of thorough assistance from Guix developers on #guix on IRC. So back to Gentoo's package manager I went. A typical user would not have put in nearly that much work to trying it out, nor would they have had the skills or knowledge to get nearly as far as I did. Though, to be honest, I did have some requirements (like doing my own compilation of everything on my own old, slow laptop, just as I'd been doing with Gentoo, and not trusting their binary distribution) that a typical user would not. The other lesson I got from my last attempt was that trying to compile everything in Guix from scratch on an old laptop is just way too slow. Doing this on Gentoo is slow and painful enough, but it's way worse on Guix, and simply unworkable. You really have to have a fast, modern system (or offload your compilation to another machine which will crank away for weeks on end and that you can then download the binaries from) to constantly compile everything you need for Guix. That said, Guix has really come a long way over the years, and it's impressive to see how far they've come, and I'd absolutely love to see them succeed, but they've got a long, long, long way to go.

martinflack 7y ago
> trying to compile everything in Guix from scratch on an old laptop is just way too slow. Doing this on Gentoo is slow and painful enough, but it's way worse on Guix, and simply unworkable Would you elaborate on why you think compilation on Guix is slower than Gentoo? Thanks.
- pmoriarty 7y ago
  It's not that compilation itself was slow with Guix, but (to my memory) it was because all Guix packages are completely separate by design and have dependencies which are not shared, so you might have to compile, say, five different versions of guile to satisfy those five different dependencies in five different packages. Compiling guile from scratch was, by the way, insanely slow, and because I struggled to get Guix working right on my first try, I had to compile it over and over again, which took about a day each time. A "guix pull" took four hours on my system, and I had to do it twice each time, once for root and once for my own user. My first "guix pull" took two weeks due to all the errors, toubleshooting and restarts the process took as I tried to get Guix working as it should. In addition, it seems that Guix packages don't have optimizations enabled, which is a deal breaker for me, as optimizing the packages I install is a significant reason I compile them from scratch in the first place, as I'm running on an old, slow machine which could use all the performance boosts it can get. Finally, I might have a broken environment on my system which makes compilation even slower still than it otherwise would be, but until I get it fixed I have to live with it, and so for all of these reasons compiling everything from scratch on Guix is just not practical for me right now. Maybe with a newer, much faster machine I'd be ok with it.
  - 70rd 7y ago
    Just out of curiosity, why not use distcc? I have a recent i7 and still compile essentially all packages on my homelab, I feel that the benefit would be even more marked for you.

p0cc 7y ago

Thank you for shedding light on a distro I didn't know existed! One tip: The contrast on your code blocks is terrible with white text against a light white background. Consider changing the `background` of line 3 of style.css to `purple`, `darkorange`, or some other dark color.

chaorace 7y ago
Seems like normal Solarized to me?
- XaspR8d 7y ago
  Must be rendering differences among us -- I don't think solarized uses white on yellow... EDIT: Ahh it's probably that the site uses `prefers-color-scheme` media queries, but missed a couple cases.
- Arnavion 7y ago
  It's broken for dark mode due to a `body { color: white }` rule in style.css. The code block background is not overridden so it remains light yellow while the text is white.
daptaq 7y ago
Oops, sorry for that. I don't have a browser that supports dark mode, so I just tried something that I thought may work. Then I changed some CSS earlier this morning that probably messed something up. I'll try to fix it as soon as possible.

mmahut 7y ago

Go Nix.

ninjin 7y ago

Sad to see GNU Guix struggling, they are young though and I have hopes for the future. About a year ago I made a choice between trying out GNU Guix and NixOS, since this week I now run NixOS on all my servers and desktops after gradually phasing out my old Ubuntu stack. It has generally been smooth sailing, with the occasional hick up that required me to draw upon my general Unix skills. What caught me off guard is how having a solid configuration to revert to has made me start tinkering with my operating system again akin to how I did when I started using Linux/BSD in the early 00s. But, enough about NixOS, I hope GNU Guix continues to make progress as there needs to be more competition in this space. If you have an evening to spare, I highly recommend trying a distribution like this out in a VM to get a taste of what it feels like to use it – it is, different… but in a good way.

deleted 7y ago
[deleted]
zaphirplane 7y ago
Something I couldn’t get about nix by skimming the documentation is how it manages application configuration. Using traditional systems when you upgrade the package responsible for the network configuration my current configuration is carried thru or merged into the new format if the package changes it’s configuration syntax. How does nixos manage /etc ?
- evil-olive 7y ago
  For the majority of changes, it "just works". For example, here's the part of nixpkgs that configures wireless networking via wpa_supplicant, as well as the actual package build of wpa_supplicant: https://github.com/NixOS/nixpkgs/blob/nixos-19.09/nixos/modules/services/networking/wpa_supplicant.nix https://github.com/NixOS/nixpkgs/blob/nixos-19.09/nixos/modu... https://github.com/NixOS/nixpkgs/blob/nixos-19.09/pkgs/os-specific/linux/wpa_supplicant/default.nix https://github.com/NixOS/nixpkgs/blob/nixos-19.09/pkgs/os-sp... Because they're contained within the same git repo, if a new version of wpa_supplicant changed the syntax of wpa_supplicant.conf, the upgrade could be handled easily (assuming the user-facing options in NixOS didn't need to change). For more complicated changes, there's `system.stateVersion`: https://nixos.wiki/wiki/FAQ/When_do_I_update_stateVersion https://nixos.wiki/wiki/FAQ/When_do_I_update_stateVersion An example of this would be if NixOS version A ships with Postgres version X by default, while NixOS version B upgrades to Postgres version Y. stateVersion allows a sane upgrade path where you can update to NixOS version B without breaking your database immediately (because stateVersion is still A).

MrBingley 7y ago

I understand and perhaps admire the GNU project's insistence on being blob-free, but that also means Guix won't run out of the box on 99% of all people's computers. The options are buy (old) hardware that doesn't need blobs (which sometimes isn't even possible), or compile the default kernel to include the binary firmware yourself (which the Guix documentation won't explain for ideological reasons). Both of these will sadly limit the appeal of this distribution to enthusiasts-only, which is unfortunate since Guix probably has the most advanced package manager of any Linux system.

dorfsmay 7y ago
True for workstations, but most services are running on VMs these days. OS shouldn't need blobs to run on VMs.
- big_chungus 7y ago
  Right, but now you have two separate operating systems to manage which are different at the kernel level (as your host is probably linux, bsd, esxi, etc.) This means you often have to manage twice the amount of tooling, documentation, scripts, etc. and makes it impractical for many cases.
m463 7y ago
I guess it depends on what you're optimizing. Hard for a user, but simple for distribution or legal.
enriquto 7y ago
There's already hundreds of distributions with binary blobs. It is very important that at least a few respect user's freedom. So it's great that Guix exists and that it has a serious stance against secret blobs.

jwilk 7y ago

> For a new package to be accepted into the [Debian] stable branch, it has to pass a number of days without any bug reports. Um, that's not even remotely close to what the actual stable inclusion rules look like.

justinsaccount 7y ago
It is close to the rules for a package to get included into 'testing' from unstable, they must have gotten the branches mixed up.
- daptaq 7y ago
  (I wrote the text) I mixed the two up, will fix.

enriquto 7y ago

i feel very alienated by the guix developers due to the way they are betraying the gnu leadership. This is sad because it is such a nice and important project. But I cannot easily separate the work from the people who did it.

rowanG077 7y ago
Yep... I don't really want to interface with morally corrupt people. Fortunately NixOS exists.
jwilk 7y ago
> they are betraying the gnu leadership What do you mean?
- cwyers 7y ago
  My guess is that they're referring to the open letter from people working on many GNU projects calling for Stallman to resign.
  - jwilk 7y ago
    I think this is the letter in question: https://guix.gnu.org/blog/2019/joint-statement-on-the-gnu-project/ https://guix.gnu.org/blog/2019/joint-statement-on-the-gnu-pr...
    - takeda 7y ago
      I still don't know what Stallman did.
      - bugbug99 7y ago
        Got caught up in an organized witch-hunt to remove him from power. Too much freedom of speech for the current FSF.
        7y ago

foopdoopfoop 7y ago

I don't know that much about Guix, other than "super-free Nix with scheme" (and the article wasn't particularly illuminating other than boiling down to "Guix isn't really ready for most users right now"), but it's neat that there's momentum in the declarative OS-space. I hope that both Guix and NixOS keep growing and that more people start switching. After switching to NixOS, I'd find it very frustrating to go back to an OS with imperative-style package/service management. It's clearly the better way. A frustrating thing about NixOS--coming from Arch Linux and being used to the AUR--is that adding packages/updating packages can be a bit slow due to the sheer volume of PRs/Issues on the nixpkgs repo. There's always the NUR[1] but it hasn't picked up that much momentum yet (probably because it's kind of hard to search the darn thing). Eitherway, the packages are just Nix expressions and repos are just collections of these expressions, so nothing's preventing a real AUR alternative other than momentum. It's interesting that Guix uses scheme instead of a home-baked configuration language like NixOS. While I don't find Nix particularly offensive, I don't find it particularly great either. And maybe this is naivity/Nix-inexperience on my part speaking, but I really wish that Nix had a proper type system and was strictly typed. I guess my pipe dream is "HaskellOS" that's basically NixOS configured with Haskell (just think of xmonad-style configuration for your whole OS). That'd be really nice. And my secondary-pipe dream is a baked in, extremely-comprehensive home-manager[2] so we can bid dotfiles goodbye once and for all and have your entire system-state defined in a single file. Maybe one day :) [1] https://github.com/nix-community/NUR https://github.com/nix-community/NUR [2] https://github.com/rycee/home-manager https://github.com/rycee/home-manager

agumonkey 7y ago
In the tradition of name monad suffixing, it shall be called Sysmonad
justinsaccount 7y ago
It's probably more similar to NixOps, but there is https://propellor.branchable.com/ https://propellor.branchable.com/ http://joeyh.name/blog/entry/unifying_OS_installation_and_configuration_management/ http://joeyh.name/blog/entry/unifying_OS_installation_and_co... kinda talks about this sort of thing
7y ago

ArchLinuxBtw 7y ago

Given the recent shakeup at GNU, perhaps the "GNU" branding should be dropped, in order to make this project more welcoming to women and the oppressed.

m45t3r 7y ago

I would recommend the author to try NixOS instead. It is not like that you wouldn't have issues however mostly things works (never had the kind of issue the author reported in this post, for example). I think the difference between NixOS and Guix, excluding the language of choice of course, is that NixOS has the community to make it work. For example, I had a issue last night that I opened a issue in GitHub, and in a few hours the maintainer of the problematic package answered me and the problem was fixed.

Someone 7y ago

”Just run guix package --roll-pack to “undo” an installation.” I don’t know guix, but that looks like a typo to me. Shouldn’t that be back, not pack?

opan 7y ago
'guix package --rollback' is what's in my shell history, so it should probably say that.

Iv 7y ago

I love the style of packets organization that they describe. I think it has a name, I have seen it promoted as an alaternative to the typical mess that is "install everything in various parts of /usr/ and /opt/, put things in /etc/ or ~, silently overwrite old versions"