GNU Guix System

System services, defined in Guile Scheme,[20] enable the user to declaratively compose the configuration of daemons and background services and specify configurations. This enables the user, within a single configuration file or modularized configuration, to configure the whole operating system (e.g., to have a tor proxy, an sshd server, and a webserver serving guix-web via nginx on a specific port at bootup). They can:[21]

• generate files in the filesystem (needed by some applications e.g. files in /etc)
• run any code for setting up daemons
• create specific user and group accounts (e.g. a database user for postgresql)

The Guix System uses the GNU Daemon Shepherd, formerly known as "dmd" ("Daemon managing Daemons"), as its init system, which is developed in tandem with Guix and is written and configurable in Guile.[22] It supplies user-space functionality asynchronously as services, which under Shepherd are generic functions and object data types which it uses to extend the base operating system in a defined way. In contrast to systemd, a userspace shepherd process runs as the user. Central to the Shepherd model of user space initialization is the concept of the extension, a form of composability whereby services are designed to be layered onto other services, augmenting them with more elaborate or specialised behaviours as desired.[23] This expresses the instantiation-based dependency relationships found in many modern init systems,[24] making the system modular, but also allows services to interact variadically with other services in arbitrary ways, e.g. a service which extends two other services, requiring only one to be present, but readily extending the second one if it is later instantiated without the need for any further reconfiguration or setup.

Shepherd also provides virtual services which allow dynamic dispatch over a class of related service objects, such as all those which instantiate a mail transfer agent (MTA) for the system.[25] A system governed via the Shepherd daemon can represent its user space as a directed acyclic graph, with the "system-service," which is responsible for early phases of boot and init, as its root, and all subsequently initialized services as extensions to system-service functionality, either directly or transitively over other services.[23][26]

It is intended to be highly programmable by the system administrator using Guile, but it can also be used to manage per-user profiles of unprivileged daemons and services.[27] Its services and configuration are stored uniformly as object-oriented Scheme code, and while a core set of services are provided with the basic Guix System,[28] arbitrary new services can be flexibly declared, and through Guile's object system, GOOPS, existing services can be redefined at the user's discretion by asking the Shepherd to dynamically rewrite services in specified ways on instantiation.[29][30]

GNU Shepherd was originally designed to work with GNU Hurd, and was later adopted by Guix System.[31]

With Guix's model of building every package from source, Guix is able to take advantage of this and include compile-time options for almost all of its packages. Parameterized packages represent an innovative package transformation approach that extends its capability to finely adjust compile-time settings. This includes tasks like eliminating redundant dependencies or configuring a package to support only specific locales. The applications of this advancement are diverse, spanning from high-performance computing to embedded systems. Additionally, it has the potential to address some of Linux's challenges, such as oversized binary files and complex dependency structures. In the case of substitutes, it is still unknown how the combination of parameters will be treated, however it is suggested that important combinations should be included in the repository. If you are familiar with Gentoo Linux, this should remind you of their USE flags. This is all still being worked on, and as such is yet to be seen in an official Guix release. [32]

Packages in Guix are generally very up-to-date thanks to the lack of a package maintainer bottlenecks. Anyone can contribute an update subject to community approval and the process is assisted by tools such as guix refresh.[35]

Changes to the git repository are peer-reviewed by community members and committed by one of the 45 people with commit access.[36] In practice these builds sometimes cause system breakages for users because of a typo or similar error, but these are often solved within minutes. The way Guix pull operates means users retain a working system in the meantime.

If a system update leaves users with a broken system, users can easily roll back individual packages as well as the whole system state with a simple command:
guix package --roll-back[37]
This means that the kind of stable channel that is very common in other Linux distributions is no longer needed for users who are willing to report a bug and wait a few minutes, when trying to update via guix pull. This is accomplished by a combination of Guix's functional package manager, which treats each package and system configuration as an immutable and reproducible entity,[38] and the generation system which maintains a history of system configurations as "generations." These generations are stored as separate profiles, which allow you to roll back to any previous configuration,[39] and you can see these generations with
guix package --list-generations.