7 ms·

I always found Guix more appealing, because it uses a programming language that is useful for other things as well (GNU Guile). I really can't stand having to l

I always found Guix more appealing, because it uses a programming language that is useful for other things as well (GNU Guile). I really can't stand having to learn a new language for each thing I want to manage.

yaysyu 5y ago
Does guix also have any equivalent to patchelf?
- georgyo 5y ago
  Guix uses patchelf. Patchelf is very useful anytime you want to change the location of dynamic loaded libraries but don't want to set LD_LIBRARY_PATH. It is used in more places than you might originally think.
  - lillecarl 5y ago
    GoboLinux also uses patchelf.
  - rekado 5y ago
    We don't use patchelf for any official package definition. We have a package for patchelf, but it's only really useful when you have pre-built binaries that you can't rebuild from source.
    - georgyo 5y ago
      The main guix monorepo may set that hard requirement the everything just be built from source, but if you want to run closed source software than your only two options are make a fake FHS or use patchelf. Both methods have pros and cons. Only patchelf makes the result work well with other closed source programs. While from a philosophical point of view guix is pure, real world usage often needs closed source software.
      - rekado 5y ago
        Yes, for pre-built binaries you can't really get around patchelf. For example, that's also how CUDA is packaged for Guix.
globular-toast 5y ago
Is the author aware of Guix?
- alpaca128 5y ago
  Apparently not, or forgot about it when writing the article: > it's so clearly the only operating system that actually gets how package management should be done
  - Filligree 5y ago
    He might be one of the many, many people whose hardware isn't supported by Guix.
    - alpaca128 5y ago
      Oh right, I forgot it's a purely Free Software distro.
  - xxpor 5y ago
    Isn't Guix just nix with guile?
mplanchard 5y ago
I completely agree, but the main benefit nix has over guix is some amount of MacOS compatibility. I don’t currently use a Mac, but I know that next time I have to use one for work, my home-manager-mediated config, which contains almost all of my user-specific configuration, will port right over just fine. The guix team doesn’t seem particularly interested in supporting MacOS, and I can’t blame them. The other benefit is mindshare, so things tend to get updated more quickly in nix than in guix. I do really wish I could use guile rather than the nix language though. I’ve gotten used to it, but the complicated abstractions in nixpkgs are still often inscrutable.
- ninjin 5y ago
  I have had NixOS as my daily driver for nearly three years now and maintain a small number of packages in Nixpkgs. From my perspective, macOS support is a headache as it all of the sudden may require you to debug on a proprietary OS that you lack access to and that runs on two different hardware architectures in order to get a patch accepted. I am probably not going to make any friends for saying so, but I would much prefer if Nixpkgs for macOS was maintained separately. My personal reasons for not going with Guix is that it is a GNU project and thus you have to buy into the entire FSF philosophy. Sadly I do need to run on “problematic” hardware from time to time and would prefer if doing so did not require me to add unofficial extensions and be wary of uttering such heresy in the company of my fellow users. That being said, I like what Guix is doing and their documentation does frankly look better compared to the grass where I am standing. Lastly, yes, NixOS is a damn curse. Once you get the taste of having a declarative operating system it is really hard to go back. Trying out tiny tweaks to your audio, kernel, etc. all with the confidence that you know how to get back to what you had before is so very addictive. We need more diversity in this space.
  - mplanchard 5y ago
    Oh yeah no doubt MacOS is a huge pain. We use nix for installing system deps at work, and it seems like once every six months or so something will inexplicably stop working on Mac. Luckily I have an old Mac at home, but the new architecture means that one is becoming pretty much useless now for debugging some of the stuff that comes up. Still, being able to guarantee everyone working on the project has the same versions of everything is pretty nice. No need to worry about ancient Mac versions of bash or awk or sed or whatever, so we can script confidently.
valyagolev 5y ago
as much respect as I have for Guile, I'd love the nix configuration language to have at least partially enforced types...
- agumonkey 5y ago
  time for hix .. and lets revive http://lambda-the-ultimate.org/node/299 http://lambda-the-ultimate.org/node/299
- eadmund 5y ago
  It really is a pity that Guix didn't go for Common Lisp instead — it does allow for gradual typing. And it has standardised a ton of stuff that Guile had to implement on an ad hoc basis.
  - dannyobrien 5y ago
    Honestly, I kind of like how Guix and Guile have been growing together. Like Rust and Servo (and the Rust compiler), I think the constraint of having a general-purpose language, but a general purpose language that is also responsive to a bigger project, has been beneficial to both.

yaysyu 5y ago

Does guix also have any equivalent to patchelf?

georgyo 5y ago
Guix uses patchelf. Patchelf is very useful anytime you want to change the location of dynamic loaded libraries but don't want to set LD_LIBRARY_PATH. It is used in more places than you might originally think.
- lillecarl 5y ago
  GoboLinux also uses patchelf.
- rekado 5y ago
  We don't use patchelf for any official package definition. We have a package for patchelf, but it's only really useful when you have pre-built binaries that you can't rebuild from source.
  - georgyo 5y ago
    The main guix monorepo may set that hard requirement the everything just be built from source, but if you want to run closed source software than your only two options are make a fake FHS or use patchelf. Both methods have pros and cons. Only patchelf makes the result work well with other closed source programs. While from a philosophical point of view guix is pure, real world usage often needs closed source software.
    - rekado 5y ago
      Yes, for pre-built binaries you can't really get around patchelf. For example, that's also how CUDA is packaged for Guix.

globular-toast 5y ago

Is the author aware of Guix?

alpaca128 5y ago
Apparently not, or forgot about it when writing the article: > it's so clearly the only operating system that actually gets how package management should be done
- Filligree 5y ago
  He might be one of the many, many people whose hardware isn't supported by Guix.
  - alpaca128 5y ago
    Oh right, I forgot it's a purely Free Software distro.
- xxpor 5y ago
  Isn't Guix just nix with guile?

mplanchard 5y ago

I completely agree, but the main benefit nix has over guix is some amount of MacOS compatibility. I don’t currently use a Mac, but I know that next time I have to use one for work, my home-manager-mediated config, which contains almost all of my user-specific configuration, will port right over just fine. The guix team doesn’t seem particularly interested in supporting MacOS, and I can’t blame them. The other benefit is mindshare, so things tend to get updated more quickly in nix than in guix. I do really wish I could use guile rather than the nix language though. I’ve gotten used to it, but the complicated abstractions in nixpkgs are still often inscrutable.

ninjin 5y ago
I have had NixOS as my daily driver for nearly three years now and maintain a small number of packages in Nixpkgs. From my perspective, macOS support is a headache as it all of the sudden may require you to debug on a proprietary OS that you lack access to and that runs on two different hardware architectures in order to get a patch accepted. I am probably not going to make any friends for saying so, but I would much prefer if Nixpkgs for macOS was maintained separately. My personal reasons for not going with Guix is that it is a GNU project and thus you have to buy into the entire FSF philosophy. Sadly I do need to run on “problematic” hardware from time to time and would prefer if doing so did not require me to add unofficial extensions and be wary of uttering such heresy in the company of my fellow users. That being said, I like what Guix is doing and their documentation does frankly look better compared to the grass where I am standing. Lastly, yes, NixOS is a damn curse. Once you get the taste of having a declarative operating system it is really hard to go back. Trying out tiny tweaks to your audio, kernel, etc. all with the confidence that you know how to get back to what you had before is so very addictive. We need more diversity in this space.
- mplanchard 5y ago
  Oh yeah no doubt MacOS is a huge pain. We use nix for installing system deps at work, and it seems like once every six months or so something will inexplicably stop working on Mac. Luckily I have an old Mac at home, but the new architecture means that one is becoming pretty much useless now for debugging some of the stuff that comes up. Still, being able to guarantee everyone working on the project has the same versions of everything is pretty nice. No need to worry about ancient Mac versions of bash or awk or sed or whatever, so we can script confidently.

valyagolev 5y ago

as much respect as I have for Guile, I'd love the nix configuration language to have at least partially enforced types...

agumonkey 5y ago
time for hix .. and lets revive http://lambda-the-ultimate.org/node/299 http://lambda-the-ultimate.org/node/299
eadmund 5y ago
It really is a pity that Guix didn't go for Common Lisp instead — it does allow for gradual typing. And it has standardised a ton of stuff that Guile had to implement on an ad hoc basis.
- dannyobrien 5y ago
  Honestly, I kind of like how Guix and Guile have been growing together. Like Rust and Servo (and the Rust compiler), I think the constraint of having a general-purpose language, but a general purpose language that is also responsive to a bigger project, has been beneficial to both.