5 ms·

GNU Guix package and system manager

63 points by simonpure 5y ago

marcodiego 5y ago
One thing I don't like about GNU Guix: they despise systemd. Not that I like it, I like the fact that its adoption was entirely transparent for me and I like the fact that if I ever have any problem with it, it is easy to google for solutions. When one chooses to use GNU Guix, you're already entering the "exotic distros" terrain. Not using the most used initialization system definitely doesn't help here.
- MayeulC 5y ago
  Systemd would be at odds with config.scm's declarative approach to system management here. I mean, it could work, but part of Guix's appeal is using the same language (scheme) for managing all aspects of the system. I admit that's a steep requirement (I'm a beginner at lisp/scheme).
  - 3836293648 5y ago
    Nix uses SystemD just fine though
    - guilhas 5y ago
      But still requires slight variation in the commands compared to other distros
  - kodah 5y ago
    We've been using declarative config to configure most aspects of the system for quite some time. SystemD would be nothing new. What you would need is a bunch of built-in a in the language to support SystemD, much like how they have rich configuration of login and openssh.
- guilhas 5y ago
  The amount of things you already have to learn to use Guix or NixOS that seems like pretty small issue How to start/stop/restart services, write a startup script, check logs... have been a common google search for anyone using more than one Linux distro, or docker/lxd
- laerus 5y ago
  I use guix as a package manager in a Debian based distro and it works fine with systemd.
  - creatornator 5y ago
    Pretty sure they meant Guix the OS not the package manager. The OS uses GNU Shepherd. Of course if you install the package manager on another OS, you get whatever that OS chose for an init system.
- rekado 5y ago
  > "they despise systemd" That's really not true. We just don't use it. The reason is that GNU Shepherd is also written in Guile, so we can extend it with code that's already in Guix, e.g. for containerization of services. Nobody can claim that the Shepherd is objectively better or more feature rich than systemd. It's not. Nor is it more "unixy" --- it most definitely is not. If systemd-haters come to Guix because they despise systemd and want something small and simple they won't be happy with the Shepherd.
nanna 5y ago
My experience of GNU Guix is using it as a package manager on a 'foreign' distro like Debian. For standalone apps it works pretty faultlessly, allowing me to easily install new version of packages like blender, krita and inkscape and have all of the advantages of guix at my service. My experience of trying to install things like Python via Guix were frustrating: I often seemed to struggle to import modules, and in the end I went back to conventional installation methods.
- rekado 5y ago
  Python from Guix has been extended to respect the GUIX_PYTHONPATH variable. If a module you installed via Guix isn't found in your Python from Guix then that's what I'd check. Guix sets this variable (via the generated etc/profile) when you have Python installed. One thing you shouldn't do or expect to be able to do: mix Python modules installed with your system's toolchain with those installed via Guix.
chajath 5y ago
What I wanna see is a guix equivalent of NixOps. That would be an interesting and viable alternative to Terraform
- LanternLight83 5y ago
  It's not super polished or well documented yet (I think you still need to provision the machine), but guix deploy implements work in this direction, including explicit support for providers like Digital Ocean. https://github.com/guix-mirror/guix/blob/master/gnu/machine/digital-ocean.scm https://github.com/guix-mirror/guix/blob/master/gnu/machine/...
geokon 5y ago
I'm not a unix guru, but from my experience with C++ build systems I feel the reproducible build thing seems completely at odds with rolling releases. When I have a reproducible built with C++/CMake/Hunter, what I want is a stable package base that everyone is building against - that's got a ton of eyeballs on it and that is patched and maintained. You do whatever you want on top of that and you can deterministically reproduce your whole stable setup. You do it all carefully enough and you can even build against any architecture. You take the example of Ubuntu LTS - everyone eventually adjusts their libraries and applications to be able to run with the suite of library versions they provide and everyone is on the same page. Sure, sometimes you may need a particular package at a different version. You can either static link that in, or bring it in separately with a PPA (as long as you're careful to not link two versions of the same library) - but generally that's not really necessary By contrast a rolling release seems sorta nuts... Sure I can reproduce the GUIX/NIX package world at some random point in the past - but I'll be basically the only person stuck at that version. If libraries have issues all I can do it try to rebuild at a newer version.. but then why do I care about reproducibility if I'm rolling? Or I end up with a hodge-podge of libraries at different versiosn that work for one application, but don't quite work for another. Orrrr I have a soup of libraries/dependencies all at different version.. but then I might as well statically link everything and forget about package management! From a lot of the blog posts and tooling I get the sense that people don't really care about having a stable system frozen in time. Is that right? I admittedly haven't played with either system (b/c they're really hard to grok) - but I feel I must be missing the point a bit. Or maybe I'm not seeing an obvious usecase for reproducible rolling releases
- rgoulter 5y ago
  Right, I've seen "an LTS set of packages would be nice" as a point before, I agree that it would be good to have.. but I think the communities for this are too small to support it. I've not used Guix, but have used Nix. > I must be missing the point a bit In terms of reproducing how software is built/run? At the risk of starting a flamewar, I believe one of the reasons use of Docker is so popular is how easy it made it to deploy software in a way that you've got confidence it will run the same way. But I'd suggest a point worth considering about Nix/Guix is more that advantages like "reproducible package behaviour" or "straightforward installation rollback" etc. are easy with Guix or Nix, but difficult to get elsewhere (or even benefits you can't get with other tooling).

63 points by simonpure 5y ago

One thing I don't like about GNU Guix: they despise systemd. Not that I like it, I like the fact that its adoption was entirely transparent for me and I like the fact that if I ever have any problem with it, it is easy to google for solutions. When one chooses to use GNU Guix, you're already entering the "exotic distros" terrain. Not using the most used initialization system definitely doesn't help here.

MayeulC 5y ago
Systemd would be at odds with config.scm's declarative approach to system management here. I mean, it could work, but part of Guix's appeal is using the same language (scheme) for managing all aspects of the system. I admit that's a steep requirement (I'm a beginner at lisp/scheme).
- 3836293648 5y ago
  Nix uses SystemD just fine though
  - guilhas 5y ago
    But still requires slight variation in the commands compared to other distros
- kodah 5y ago
  We've been using declarative config to configure most aspects of the system for quite some time. SystemD would be nothing new. What you would need is a bunch of built-in a in the language to support SystemD, much like how they have rich configuration of login and openssh.
guilhas 5y ago
The amount of things you already have to learn to use Guix or NixOS that seems like pretty small issue How to start/stop/restart services, write a startup script, check logs... have been a common google search for anyone using more than one Linux distro, or docker/lxd
laerus 5y ago
I use guix as a package manager in a Debian based distro and it works fine with systemd.
- creatornator 5y ago
  Pretty sure they meant Guix the OS not the package manager. The OS uses GNU Shepherd. Of course if you install the package manager on another OS, you get whatever that OS chose for an init system.
rekado 5y ago
> "they despise systemd" That's really not true. We just don't use it. The reason is that GNU Shepherd is also written in Guile, so we can extend it with code that's already in Guix, e.g. for containerization of services. Nobody can claim that the Shepherd is objectively better or more feature rich than systemd. It's not. Nor is it more "unixy" --- it most definitely is not. If systemd-haters come to Guix because they despise systemd and want something small and simple they won't be happy with the Shepherd.

nanna 5y ago

My experience of GNU Guix is using it as a package manager on a 'foreign' distro like Debian. For standalone apps it works pretty faultlessly, allowing me to easily install new version of packages like blender, krita and inkscape and have all of the advantages of guix at my service. My experience of trying to install things like Python via Guix were frustrating: I often seemed to struggle to import modules, and in the end I went back to conventional installation methods.

rekado 5y ago
Python from Guix has been extended to respect the GUIX_PYTHONPATH variable. If a module you installed via Guix isn't found in your Python from Guix then that's what I'd check. Guix sets this variable (via the generated etc/profile) when you have Python installed. One thing you shouldn't do or expect to be able to do: mix Python modules installed with your system's toolchain with those installed via Guix.

chajath 5y ago

What I wanna see is a guix equivalent of NixOps. That would be an interesting and viable alternative to Terraform

LanternLight83 5y ago
It's not super polished or well documented yet (I think you still need to provision the machine), but guix deploy implements work in this direction, including explicit support for providers like Digital Ocean. https://github.com/guix-mirror/guix/blob/master/gnu/machine/digital-ocean.scm https://github.com/guix-mirror/guix/blob/master/gnu/machine/...

geokon 5y ago

I'm not a unix guru, but from my experience with C++ build systems I feel the reproducible build thing seems completely at odds with rolling releases. When I have a reproducible built with C++/CMake/Hunter, what I want is a stable package base that everyone is building against - that's got a ton of eyeballs on it and that is patched and maintained. You do whatever you want on top of that and you can deterministically reproduce your whole stable setup. You do it all carefully enough and you can even build against any architecture. You take the example of Ubuntu LTS - everyone eventually adjusts their libraries and applications to be able to run with the suite of library versions they provide and everyone is on the same page. Sure, sometimes you may need a particular package at a different version. You can either static link that in, or bring it in separately with a PPA (as long as you're careful to not link two versions of the same library) - but generally that's not really necessary By contrast a rolling release seems sorta nuts... Sure I can reproduce the GUIX/NIX package world at some random point in the past - but I'll be basically the only person stuck at that version. If libraries have issues all I can do it try to rebuild at a newer version.. but then why do I care about reproducibility if I'm rolling? Or I end up with a hodge-podge of libraries at different versiosn that work for one application, but don't quite work for another. Orrrr I have a soup of libraries/dependencies all at different version.. but then I might as well statically link everything and forget about package management! From a lot of the blog posts and tooling I get the sense that people don't really care about having a stable system frozen in time. Is that right? I admittedly haven't played with either system (b/c they're really hard to grok) - but I feel I must be missing the point a bit. Or maybe I'm not seeing an obvious usecase for reproducible rolling releases

rgoulter 5y ago
Right, I've seen "an LTS set of packages would be nice" as a point before, I agree that it would be good to have.. but I think the communities for this are too small to support it. I've not used Guix, but have used Nix. > I must be missing the point a bit In terms of reproducing how software is built/run? At the risk of starting a flamewar, I believe one of the reasons use of Docker is so popular is how easy it made it to deploy software in a way that you've got confidence it will run the same way. But I'd suggest a point worth considering about Nix/Guix is more that advantages like "reproducible package behaviour" or "straightforward installation rollback" etc. are easy with Guix or Nix, but difficult to get elsewhere (or even benefits you can't get with other tooling).