It is "the" functional package manager for GNU OS. But it's only "a" functional package manager, as there are others that also deserve consideration, like http://nixos.org/nix/

Dependable. In addition to standard package management features, Guix supports transactional upgrades and roll-backs, unprivileged package management, per-user profiles, and garbage collection.

Hackable. It provides Guile Scheme APIs, including high-level embedded domain-specific languages (EDSLs), to describe how packages are built and composed. Read more...

Liberating. Guix is used as the basis of the GNU system distribution, which respects the freedom of computer users. Read more...

Guix is based on the Nix package manager.

Taken from gnu/software/guix

> In addition to standard package management features, Guix supports > transactional upgrades and roll-backs, unprivileged package > management, per-user profiles, and garbage collection. It also offers > a declarative approach to operating system configuration management. > Guix uses low-level mechanisms from the Nix package manager, with > Guile Scheme programming interfaces.

It used to be that features like ACID transactions and checkpoints were called just that -- ACID transactions and checkpoints. When did they become "functional?"

That's not what "functional" is referring to in this context; the builds are (mostly) deterministic, so given a set of inputs (configuration settings, version preferences, extra patches, etc) you're guaranteed the same build artifacts (regardless of the current state of the system). Transactions and checkpoints don't imply determinism, and vice versa. Without determinism, the presence of other installed packages could impact subsequent builds (regardless of transaction support). Also, if the package language is imperative, you could change the values of inputs after producing build artifacts, and your system would become inconsistent.

So functional here is referring to the fact that the package language is functional, and the build system is deterministic.

There's no reason to want a package manager to be non-deterministic (i.e., unpredictable). I gather that functional is meant to encompass more than those two properties; I just didn't want to list them all.

What bugs me a little is that there are Programming Languages folks that are into functional programming and Computer Systems folks that work on things like filesystems. I liked Systems in college. It seems like the PL camp has somehow found a way to rename systems concepts that already had names and call them functional.

> There's no reason to want a package manager to be non-deterministic (i.e., unpredictable).

I agree with that assertion. However, it's an important distinction, as almost all other package managers produce non-deterministic build artifacts.

GUIX is a scheme frontend relying on Nix.

Id love to see more work on dmd and possibly stronger containers or chroots on Guix, for the build stages.

In what ways could the chroots be stronger than they already are? Anything that helps us have more deterministic builds is good.

I don’t know about a chroot, but I was thinking for deterministic Docker/LXC builds that it’d be good to have namespaces for:

A. the seed value of /dev/[u]random, and

B. the system clock (it’d be especially great if namespaces could have clocks that ticked at different rates, or which only ticked when the namespace's parent process told them to, etc.)

With these two things in place, you’d be able to implement something like ZeroVM just using LXC.