Guix Gets Grafts: Timely Delivery of Security Updates

paroneayea writes: GNU Guix, the functional package manager (and with GuixSD, distribution) got a nice feature yesterday: timely delivery of security updates with grafts. Guix's new grafts feature recursively produces re-linked packages as dependencies without waiting for all to compile when a time-sensitive security upgrade is an issue. This came just in time for this week's OpenSSL security issues, and has been successfully tested by the community. It worked so well that it was able to reproduce the ABI break issue that other traditional distributions experienced also!

Comments

So...

[Anonymous Coward]

The news seems to be something like this:
- GNU has a package manager. Didn't know that.
- The package manager is functional in many ways.
- Because it's functional in many ways, it also sucks in some ways.
- They managed to reduce the suckage, which is good for them.

What would be news for me is something like this:
- Why do I care?

Re:So...

[Anonymous Coward]

The news seems to be something like this:
- GNU has a package manager. Didn't know that.
- The package manager is functional in many ways.
- Because it's functional in many ways, it also sucks in some ways.
- They managed to reduce the suckage, which is good for them.

What would be news for me is something like this:
- Why do I care?

It's a relatively new thing (2012) so I'm guessing most haven't heard of it. The GNU folks took an existing package manager, Nix and modified it to use Guile Scheme instead of Nix's own language for describing functions (packages). You're right that it's functional (in the functional programming sense), which gives it its own set of pros and cons compared to traditional package managers.

As for why you might care, this comment on SN briefly covers what it means to be a functional package manager, including some of the pros and cons of it. It's about Nix, not Guix, but since Guix is based on Nix the information should apply equally to both. It's kind of long so I don't want to copy/paste the whole thing here, but it focuses heavily on the "why should I care?" aspect so it's worth a read if you're seriously curious about what's interesting about Guix or Nix.

Not mentioned in the writeup is that, because they're so new, documentation can be difficult to come by and it's all command line. Might be a mood killer for some, but I've found it worth the trouble so far.

So... Which is it?

[Zontar The Mindless]

Is Guix a window cleaner, a dessert topping, or both?

Re:So... Which is it?

[Zontar The Mindless]

I'm sorry about your butthurt, but it's not my fault that your devs don't understand how to name things in a fashion that it doesn't require 20 minutes to puzzle out and leave you feeling dissatisfied even then.

So if I understand correctly

[guruevi]

GNU doesn't like dynamically linking to libraries, instead preferring to statically link all the code. This results in (obviously) all statically linked packages having to be recompiled from scratch every time something in a core package (like OpenSSL) changes.

Now, however they've figured out a way to dynamically link dependent packages so that their statically linked packages will recompile correctly. Oh, and wanton disabling SSLv2 breaks shit.

Re:So if I understand correctly

[Anonymous Coward]

> GNU doesn't like dynamically linking to libraries

No, you don't understand it correctly. Where did you get this strange notion from?

Re:So if I understand correctly

[Tool Man]

If "wanton disabling SSLv2" breaks shit, it's shit that needs breaking. Dodgy old crypto protocols are deprecated for a reason, and massive, cheap security lossage is a good example here.

finally!

[Gravis Zero]

thank you for finally explaining wtf the thing is that you want to tell us more about. congratulations slashdot, you did it!

Why not turn the symbols to NO-OP's

[Anonymous Coward]

Another lovely fun fail from the OpenSSL people. They could have disabled/removed SSLv2 support while still exporting symbols like SSLv2_server_method but leaving them as NO-OP's. This way they would avoid TONS of immediate breakage all over the place.

Parent needs more upmods.

[jeffb (2.718)]

This isn't a topic I follow closely, and so when I saw "functional package manager" I didn't immediately make the association with "functional programming". The SN comment was enlightening.

This is a case where insider terminology ("functional package manager") not only fails to convey meaning to outsiders, it doesn't even provide a hint that the outsiders are missing something -- "functional" masquerades quite well as a bit of marketing fluff. ("We're not like the dysfunctional PMs you've had to put up with in the past!") So, the fact that you don't get a bunch of "what does THAT mean?" comments doesn't mean that the summary has done a good job; in fact, the opposite is more likely.

Re:Parent needs more upmods.

[DuckDodgers]

That's a fair point. In any event, I think if Nix or Guix ever get wide adoption it will be a long road because the way they store and manage packages is so fundamentally different from traditional Unixes and Unix package managers. Interesting idea, though.

Re:Parent needs more upmods.

[Anonymous Coward]

This isn't a topic I follow closely, and so when I saw "functional package manager" I didn't immediately make the association with "functional programming". The SN comment was enlightening.

This is a case where insider terminology ("functional package manager") not only fails to convey meaning to outsiders, it doesn't even provide a hint that the outsiders are missing something -- "functional" masquerades quite well as a bit of marketing fluff. ("We're not like the dysfunctional PMs you've had to put up with in the past!") So, the fact that you don't get a bunch of "what does THAT mean?" comments doesn't mean that the summary has done a good job; in fact, the opposite is more likely.

Yeah, that's probably everyone's first reaction. It was mine at least. It sounds like "functional" is implying that it functions (e.g. works correctly) while others do not, sort of a sideways dig at traditional package mangers. It's definitely worth a try if you're willing to wrangle with the lack of documentation. For a basic "install stuff from the repo" use it doesn't differ much from other systems, aside from giving you better rollback features and the nix-shell to try things out, but those two things might be worth it even without getting into the more "functional" aspects.

However, what really makes it shine is when you start creating your own expressions. It defines packages programmatically, as expressions, so you declare what your package needs as dependencies, even including source files, and get a reproducable way to create, compile, and install. That means you can add some code to your config file (or include another file to keep the config clean) that describes new packages or redefines existing ones in the same way you write functions in a programming language. Doing so gives you something akin to dpkg's metapackages, except that they're contained in one place and exist alongside the package repository. You can think of it like a hybrid of an emacs init.el and dpkg in that sense.

For an example of why this is cool, you can write expressions for a development or testing environment, including compiler, langauge docs, editor, and even your own custom configurations. nix-shell makes it easy to do temporary installs of different compiler versions to test building with each, and reinstalling your dev environment on a new machine is as easy as moving the config file to a new system. It can even pull in (and compile, if needed) files from sources like a git repo, zip files, etc. so you could store your editor configs online somewhere and make them part of the install process. Once you write an expression like, you can also give it to others and guarantee they can recreate the same build environment you use.

There's definitely a learning curve and it comes with its own set of warts, but I'd say it's still worth spending some time with one (or both) of them. I still use Debian repos for most things, but the nixpkg repository and custom expressions fill a niche for me, and Guix likely does the same but I haven't compared them directly to determine which is more comprehensive..

I have tried guix for a few months

[Anonymous Coward]

I have tried guix for a few months. I installed it in parallel to my regular package manager, they coexist so you can try it out without upsetting anything. It's actively being developed. It's main thing, in the long term view is the absolute security and traceability of the software chain from source to executable. I think it will be big in the long term.