GNU Guix package and system manager | Hacker News Reader

GNU Guix package and system manager

guix.gnu.org

63 pointssimonpure19 comments

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.

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.

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.

> "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.

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).

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.

Nix uses SystemD just fine though

But still requires slight variation in the commands compared to other distros

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

I use guix as a package manager in a Debian based distro and it works fine with systemd.

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.

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

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).

You know the rollback aspect is something I really overlooked! Thanks for pointing that out

Guix let's you create "inferior" channels that are pinned to older channel commit(s) and build packages from them into your system, so if you have a particular package that's broken beyond a point, you can still pin it and roll everything else forward. I do wish there was a branch that was pinned to eg. the latest commit with a successful CI build of the Guix installer, but CI load is currently it's own issue, so I'd be as happy to see a mechanism for creating your own CI that merges master like weekly and runs custom tests (a la "guix system test"'s VM-based test suite).

Nix uses to channels for this sort of versioning, which is pretty analog to ubuntu’s versions. It basically freezes a set of lib versions and everything builds against that, so far nothing different from what other distros do. What makes Nix and Guix superior is that you can still install a package depending on an older/newer/compiled with specific flag or whatever version of libc or anything basically, and it will be removed once it is no longer in use. And also, if a package worked at a particular nix repo state, you can be almost sure that it will work again.

Oh right, I keep forgetting Nix has official stable channels :). I think they're pretty short lived though. 6 months from what I remember. Nonetheless definitely a leg up on GUIX. Thanks!

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

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/...

Reply on news.ycombinator.com