find and sed, and it is much easier to work with.
Build-side modules also include support for fetching files over HTTP (using Guile’s web client module) and FTP, as needed to realize the derivation of origins (line 5 of Figure 4). TLS support is available when needed through the Guile bindings of the GnuTLS library.
EVALUATION AND DISCUSSION
This section discusses the current status of Guix and its associated GNU/Linux distribution, and outlines key aspects of their development.
Status
Guix is still a young project. Its main features as a package manager are already available. This includes the APIs discussed in Section 3, as well as command-line interfaces. The development of Guix’s interfaces was facilitated by the reuse of Nix’s build daemon as the storage and deployment layer.
The guix package command is the main user interface: it allows packages to be browsed, installed, removed, and upgraded. The command takes care of maintaining meta-data about installed packages, as well as a per-user tree of symlinks pointing to the actual package files in /nix/store, called the user profile. It has a simple interface. For instance, the following command installs Guile and removes Bigloo from the user’s profile, as a single transaction:
$ guix package --install guile --remove bigloo
The transaction can be rolled back with the following command:
$ guix package --roll-back
The following command upgrades all the installed packages whose name starts with a ‘g’:
$ guix package --upgrade ’^g .*’
The --list-installed and --list-available options can be used to list the installed or available packages.
As of this writing, Guix comes with a user-land distribution of GNU/Linux. That is, it allows users to install packages on top of a running GNU/Linux system. The distribution is self-contained, as explained in Section 4.3, and available on x86_64 and i686. It provides more than 400 packages, including core GNU packages such as the GNU C Library, GCC, Binutils, and Coreutils, as well as the Xorg software stack and applications such as Emacs, TeX Live, and several Scheme implementations. This is roughly a tenth of the number of packages found in mature free software distributions such as Debian. Experience with NixOS suggests that the functional model, coupled with continuous integration, allows the distribution to grow relatively quickly, because it is always possible to precisely monitor the status of the whole distribution and the effect of a change—unlike with imperative distributions, where the upgrade of a single package can affect many applications in many unpredictable ways.[1] From a programming point of view, packages are exposed as first-class global variables. For instance, the (gnu packages guile) module exports two variables, guile-1.8 and guile-2.0, each bound to a <package> variable corresponding to the legacy and current stable series of Guile. In turn, this module imports (gnu packages multiprecision), which exports a gmp global variable, among other things; that gmp variable is listed in the inputs field of guile and guile-2 .0. The package manager and the distribution are just a set of "normal" modules that any program or library can use.
Packages carry meta-data, as shown in Figure 4. Synopses and descriptions are internationalized using GNU Gettext— that is, they can be translated in the user’s native language, a feature that comes for free when embedding the DSL in a mature environment like Guile. We are in the process of implementing mechanisms to synchronize part of that meta-data, such as synopses, with other databases of the GNU Project.
While the distribution is not bootable yet, it already includes a set of tools to build bootable GNU/Linux images for the QEMU emulator. This includes a package for the kernel itself, as well as procedures to build QEMU images, and Linux "initrd"—the "initial RAM disk" used by Linux when booting, and which is responsible for loading essential kernel modules and mounting the root file system, among other things. For example, we provide the expression->derivation-in-linux-vm: it works in a way similar to build-expression->derivation, except that the given expression is evaluated in a virtual machine that mounts the host’s store over CIFS. As a demonstration, we implemented a derivation that builds a "boot-to-Guile" QEMU image, where the initrd contains a statically-linked Guile that directly runs a boot program written in Scheme.[2]
The performance-critical parts are the derivation primitives discussed in Section 3. For instance, the computation of Emacs’s derivation involves that of 292 other derivations— that is, 292 invocations of the derivation primitive corresponding to 582 RPCs.[n 1] The wall time of evaluating that derivation is 1.1 second on average on a 2.6 GHz x86_64 machine. This is acceptable as a user, but 5 times slower than Nix’s clients for a similar derivation written in the Nix language. Profiling shows that Guix spends most of its time in its derivation serialization code and RPCs. We interpret this as a consequence of Guix’s unoptimized code, as well as the difference between native C++ code and our interpreted bytecode.
Purity
Providing pure build environments that do not honor the "standard" file system layout turned out not to be a problem, as already evidenced in NixOS.[3] This is largely thanks to the ubiquity of the GNU build system, which strives to provide users with ways to customize the layout of installed packages and to adjust to the user’s file locations. The only directories visible in the build chroot environment are /dev, /proc, and the subset of /nix/store that is ex-
- ↑ O. Crameri, R. Bianchini, W. Zwaenepoel, D. Kostić. Staged Deployment in Mirage, an Integrated Software Upgrade Testing and Distribution System. In In Proceedings of the Symposium on Operating Systems Principles, 2007.
- ↑ L. Courtès. Boot-to-Guile!. February 2013. http://lists.gnu.org/archive/html/bug-guix/2013-02/msg00173.html
- ↑ E. Dolstra, M. d. Jonge, E. Visser. Nix: A Safe and Policy-Free System for Software Deployment. In Proceedings of the 18th Large Installation System Administration Conference (LISA '04), pp. 79-92, USENIX, November 2004.
- ↑ The number of
derivationcalls andadd-to-storeRPCs is reduced thanks to the use of client-side memoization.
