GNU Guix and GuixSD 0.12.0 released | Hacker News Reader

GNU Guix and GuixSD 0.12.0 released

gnu.org

94 pointsrekado33 comments

Hi there,

I'm the person who made the release announcement and I happen to be one of the two co-maintainers of GNU Guix. I'm using Guix in production at a bioinformatics institute.

If you have specific questions about Guix or functional package management feel free to ask me.

To try to answer one common question: we aren't on bad terms with the Nix people or compete with them. We are working towards very similar goals, and the underlying paradigm of functional package management (pioneered by Nix) is the same. Members of both projects are involved in efforts towards reproducibility. We have different sensibilities when it comes to the actual implementation and that leads to different design choices.

Concerning the HURD support: Is there an image with GNU Hurd instead of the Linux kernel?

There is not (yet). In functional package management we build everything from source until we hit a small set of common bootstrap binaries.

In the case of the Hurd it is now possible to bootstrap all of the Hurd system in this manner. This means that we can use Guix as a package manager on top of a Hurd system (e.g. Debian GNU/Hurd), but GuixSD using the Hurd is not yet available. I think it's close, though.

What about the reproducible build project. Is there some regular communication channel with them ? or just friendly acknowledgement ?

Guix developers attend the Reproducible Build Summits, among other collaborative efforts.

Both Guix maintainers attended this years reproducible builds summit in Berlin. We're involved with them since before the summit in Athens.

At the most recent summit we start a new cross-distro project that I hope we can announce soon.

Is something more elegant than grafts [1] on the agenda for any functional package manager? Right now, it seems like the options are:

1) Forego timely and efficient security update deployment because the functional discipline demands that we rebuild the entire system if glibc is updated

2) Forego strictly functional package management and undermine the associated guarantees by deploying hacks that work around the functional model.

edited to add: does this perhaps tie into the work on reproducible builds, e.g. could that work yield tools able to prove that a given package need not actually be recompiled?

[1] https://www.gnu.org/software/guix/manual/html_node/Security-...

Grafts are still functional. We're not modifying existing builds. We generate new artifacts with updated references (think copy-on-write). However, these new artifacts don't need recompilation. They are copies with their embedded references recursively replaced such that they refer to the fixed variant of a library.

This mostly just works, but it can lead to problems when upstream introduces ABI changes in security fixes. This is very rare but it happened at least once (I think it was openssl) --- like any other distro that updated the library in place users experienced problems.

The assumption with grafts is that this doesn't happen, which is valid in the vast majority of cases that we encountered so far.

That said, in Guix we try to minimize the period during which grafts are needed by "ungrafting" as soon as a properly rebuilt artifact is available on the build farm. This doesn't help those users who build everything from source exclusively, of course. But this is where reproducible builds help. Users don't have to be building everything from source if they have the tools to gauge how much they can trust providers of binary substitutes.

> In addition to standard package management features, Guix supports ... unprivileged package management, per-user profiles, ...

That sounds really cool. I wish I could install DEB packages just for my local user, without needing root access. I wanted this back at my university's computer lab, and I still want this on my own systems today.

These days a lot of people use personal single-user machines, so having it mandatory that packages be installed to the root file system is very restrictive. For example, I have a lot of DEB-packaged games from HumbleBundle, and it feels weird to need admin privileges to install them all across /usr/games, /usr/local/share and all that instead of just a place of my choosing under /home/me.

Can't say for Guix, but nix can be installed standalone IIRC.

You can use Guix as a standalone package manager on pretty much any GNU+Linux distribution. It only affects /gnu, /var/guix, and /etc/guix/acl. It won't touch any global state (e.g. libraries in /usr, or binaries in /bin) and won't use any global state when building packages.

So from a security standpoint, it's actually a good idea to do it like this. I mean, provided the games contact the internet in any way - for purely offline games it doesn't matter.

By separating the owner and the account running the game, you can ensure that local write bugs cannot affect the executed code. Not a huge issue, but if you can prevent that at close to no cost, then why not? (ideally we should have simple user-accessible sandboxing instead, but that's not always easy at the moment)

What's the current position of Nix vs Guix?

I tried NixPkgs for a while on a mac about a year ago, but it wasn't really functional (I submitted a half-dozen or so bug reports, several were fixed, but I could see there was a long way to go towards a usefully working system...)

Nix is used / usable in production. Guix is still pretty far away.

This is not correct. There are at least three big bioinformatics clusters where Guix is used quite successfully (I know of large-scale deployments in Germany, the Netherlands, Australia). One of the deployments with 250 cluster nodes and uncounted GNU+Linux workstations is managed by me.

I'd say it is very much usable and in fact used in production.

I dunno, honestly, if you're capable of using Nix in production, you're capable of using Guix in production almost certainly. I say this as a NixOS maintainer (though I'm relatively dormant these days).

I see this as a thing of relative scale. Most people aren't going to run Nix, and in practice, using Nix requires a fair amount of work in practice (often including upstream work). If you're prepared to go through all that, you can probably use Guix in principle, too. (Barring some technicalities, of course, but in general I think this is still true.)

I use Guix in production to handle a very complicated dependency tree for some private speech recognition software.

NixOS and nixpkgs is very functional, we use it in production at the company I work for and I also use it as my full-time laptop OS (it's great as a laptop OS).

Nixpkgs on a mac actually has a really bad reputation as being undersupported.

I use NixOS as my main OS though and it works fine.

Now that nixpkgs' CI has an osx build, this may well get better.

nixpkgs for Mac has never really been a priority, what's there is mostly contributed by a handful of people. It's certainly not got the same level of testing and use as e.g. Homebrew. It works wonderfully on Linux - especially under its own distribution, NixOS, which I run on my laptop.

Bad timing. Yosemite broke basically everything in nixpkgs-darwin, and it took a long time to get everything fixed. I think that was mainly due to the switch from GCC to Clang and the accompanying toolchain, library and runtime changes.

The good news it that the darwin stdenv is now "pure" in the functional sense. It bootstraps using /usr/bin/curl, and symlinks libSystem into the nix store, but otherwise doesn't rely on macOS at all. That makes it much more resilient to changes in macOS and Xcode.

So scheme is not a purely functional language - I take that to mean Guix will not be as well? It will be more like "Unix as emacs"?

Saddens me, because NixOS does all I want - except having s-expressions...

The packaging is functional, the scripting is not. Guix still uses a fork of the nix-daemon, and thus derivations. The "functional packages, no side effects" part is still guaranteed in the build & install part.

I'd say it's largely what you want, minus probably some GNU-isms in their packaging choices.

To be fair, a huge part of the functionality in nixpkgs and NixOS is provided by a ton of bash code, both standalone files and big strings in .nix files.

Replacing that with Scheme sounds like a long-term win to me; although in the short term I imagine it makes packaging the contents of a bash-dominated world more frustrating.

NixOS is missing some things for me personally, such as multilib support (I play a game that's only available using 32-bit libraries). Unfortunately I didn't read the documentation and arrived at a situation where I couldn't install my game. I ended up re-installing Debian.

It sounds trivial, but unfortunately it was a deal-breaker for me. I really liked the centralised configuration and package management offered by NixOS.

It is most definitely possible to plan 32-bit games (at least via Steam) on NixOS. The only things not to forget is to enable "hardware.opengl.driSupport32Bit" and "hardware.pulseaudio.support32Bit". Other than that, just installing the Steam package usually should work.

It's possible to build FHS environments with multilib [1]. In fact it's what I use to run games and other binary only software: It works perfectly for me. I will share my setup.

The expression `games.nix` [2] I use for my games builds a chroot environment with both 32bit and 64bit /lib and a command `start-game` to launch games from the environment. I store them in ~/game/$gamename, with a `$gamename/start.sh`, which is a slightly tweaked or cleaned up version of what it's usually found in gogs and humble bundle games.

To use it you do `nix-env -if games.nix` to install it the first time and the just `start-game $gamename` to play. To fiddle around uncomment the trailing `#.env`, run `nix-shell games.nix` and you will land in the chroot environment with everything you need.

Most of Nix features like this one are not really documented but fortunately there's github search and folks in #nixos are always available.

[1]: https://nixos.org/wiki/FHS_environments

[2]: https://hastebin.com/fopelaseyo.nix

Nix and Guix don't need multilib support because every build is isolated, unlike in other package managers that stuff everything in /usr which is the reason multilib exists in the first place. You can just build the package for the desired architecture and run it.

I thought Guix reimplemented nix the purely functional language in scheme.

No, Guix uses a DSL for packages that's embedded in Guile. Pretty much everything else is also written in Guile with the current exception of the Nix daemon (C++).

The DSL is mostly declarative. Here's an example:

    (define metal
      (package
        (name "metal")
        (version "2011-03-25")
        (source
         (origin
           (method url-fetch)
           (uri (string-append "http://csg.sph.umich.edu/abecasis/Metal/"
                               "download/generic-metal-" version ".tar.gz"))
           (sha256
            (base32
             "1bk00hc0xagmq0mabmbb8bykl75qd4kfyirba869h4x6hmn4a0f3"))))
        (build-system gnu-build-system)
        (arguments
         `(#:tests? #f
           #:make-flags
           (list (string-append "INSTALLDIR="
                                (assoc-ref %outputs "out") "/bin")
                 "all")
           #:phases
           (modify-phases %standard-phases
             (delete 'configure))))
        (inputs
         `(("zlib" ,zlib)))
        (home-page "http://csg.sph.umich.edu/abecasis/Metal")
        (synopsis "Facilitate meta-analysis of large datasets")
        (description "METAL is a tool for meta-analysis genomewide
    association scans.  ...")
        (license license:bsd-3)))

The stuff that's in the "arguments" field is a quoted expression, which is evaluated on the builder's side, at build time. We make use of code staging in several places, which seems like a perfect fit for Scheme.

Note that the `,zlib` thing means that the value bound to the variable name "zlib" is injected as is. All package expressions are "live" values in Scheme and can be inspected in a REPL.

The subset of Scheme that we use in Guix is mostly functional. (It's quite unlikely to find things like `set!` in the code for package expressions, for example.)

Then there's patching of sources (e.g. to replace shebangs to point to the actual location of the interpreter). Obviously, you want to have side effects there, so that's not purely functional. That's unrelated to Scheme as a language or the DSL we use to describe packages (Nix does something similar because without patching functional package management wouldn't quite work).

"So scheme is not a purely functional language"

No language is purely purely functional, otherwise it wouldn't be able to have inputs/outputs.

Reply on news.ycombinator.com