We are pleased to announce the release of GNU Guix version 1.4.0!
The release comes with ISO-9660 installation images, a virtual machine image, and with tarballs to install the package manager on top of your GNU/Linux distro, either from source or from binaries—check out the download page. Guix users can update by running guix pull.
It’s been 18 months since the previous release. That’s a lot of time, reflecting both the fact that, as a rolling release, users continuously get new features and update by running guix pull; but let’s face it, it also shows an area where we could and should collectively improve our processes. During that time, Guix received about 29,000 commits by 453 people, which includes important new features as we’ll see; the project also changed maintainers, structured cooperation as teams, and celebrated its ten-year anniversary!
A happy frog sitting at a Guix-powered computer with an almighty benevolent Guix humanoid in its back.
Illustration by Luis Felipe, published under CC-BY-SA 4.0.
This post provides highlights for all the hard work that went into this release—and yes, these are probably the longest release notes in Guix’s history, so make yourself comfortable, relax, and enjoy.
Bonus! Here’s a chiptune (by Trevor Lentz, under CC-BY-SA 3.0) our illustrator Luis Felipe recommends that you listen to before going further.
Improved software environment management
One area where Guix shines is the management of software environments. The guix environment command was designed for that but it suffered from a clumsy interface. It is now superseded by guix shell, though we are committed to keeping guix environment until at least May 1st, 2023. guix shell is a tool that’s interesting to developers, but it’s also a useful tool when you’re willing to try out software without committing it to your profile with guix install. Let’s say you want to play SuperTuxKart but would rather not have it in your profile because, hey, it’s a professional laptop; here’s how you would launch it, fetching it first if necessary:
guix shell supertuxkart -- supertuxkart
In addition to providing a simpler interface, guix shell significantly improves performance through caching. It also simplifies developer workflows by automatically recognizing guix.scm and manifest.scm files present in a directory: drop one of these in your project and other developers can get started hacking just by running guix shell, without arguments. Speaking of which: --export-manifest will get you started by “converting” command-line arguments into a manifest. Read more about guix shell in the manual.
Another guix shell innovation is optional emulation of the filesystem hierarchy standard (FHS). The FHS specifies locations for different file categories—/bin for essential command binaries, /lib for libraries, and so on. Guix with its store does not adhere to the FHS, which prevents users from running programs that assume FHS adherence. The new --emulate-fhs (or -F) flag of guix shell, combined with --container (-C), instructs it to create a container environment that follows the FHS. This is best illustrated with this example, where the ls command of the coreutils package appears right under /bin, as if we were on an FHS system like Debian:
$ guix shell -CF coreutils -- /bin/ls -1p /
bin/
dev/
etc/
gnu/
home/
lib/
lib64
proc/
sbin/
sys/
tmp/
usr/
Another big new feature is Guix Home. In a nutshell, Home brings the declarative nature of Guix System to your home environment: it lets you declare all the aspects of your home environments—“dot files”, services, and packages—and can instantiate that environment, in your actual $HOME or in a container.
If you’re already maintaining your dot files under version control, or if you would like to keep things under control so you don’t have to spend days or weeks configuring again next time you switch laptops, this is the tool you need. Check out this excellent introduction that David Wilson gave at the Ten Years celebration, and read more about Guix Home in the manual.
Package transformation options give users fine control over the way packages are built. The new --tune option enables tuning of packages for a specific CPU micro-architecture; this enables the use of the newest single-instruction multiple-data (SIMD) instructions, such as AVX-512 on recent AMD/Intel CPUs, which can make a significant difference for some workloads such as linear algebra computations.
Since the 1.3.0 release, the project started maintaining an alternative build farm at https://bordeaux.guix.gnu.org. It’s independent from the build farm at ci.guix.gnu.org (donated and hosted by the Max Delbrück Center for Molecular Medicine in Berlin, Germany), which has two benefits: it lets us challenge substitutes produced by each system, and it provides redundancy should one of these two build farms go down. Guix is now configured by default to fetch substitutes from any of these two build farms. In addition, a bug was fixed, ensuring that Guix gracefully switches to another substitute provider when one goes down.
Those who’ve come to enjoy declarative deployment of entire fleets of machines will probably like the new --execute option of guix deploy.
Stronger distribution
The distribution itself has seen lots of changes. First, the Guix System installer received a number of bug fixes and it now includes a new mechanism that allows users to automatically report useful debugging information in case of a crash. This will help developers address bugs that occur with unusual configurations.
Application startup has been reduced thanks to a new per-application dynamic linker cache that drastically reduces the number of stat and open calls due to shared library lookup (we’re glad it inspired others).
Guix System is now using version 0.9 of the GNU Shepherd, which addresses shortcomings, improves logging, and adds features such as systemd-style service activation and inetd-style service startup. Speaking of services, the new guix system edit sub-command provides an additional way for users to inspect services, completing guix system search and guix system extension-graph.
There are 15 new system services to choose from, including Jami, Samba, fail2ban, and Gitile, to name a few.
A new interface is available to declare swap space in operating system configurations. This interface is more expressive and more flexible than what was available before.
Similarly, the interface to declare static networking configuration has been overhauled. On GNU/Linux, it lets you do roughly the same as the ip command, only in a declarative fashion and with static checks to prevent you from deploying obviously broken configurations.
Screenshot of GNOME 42.
More than 5,300 packages were added for a total of almost 22,000 packages, making Guix one of the top-ten biggest distros according to Repology. Among the many noteworthy package upgrades and addition, GNOME 42 is now available. KDE is not there yet but tens of KDE packages have been added so we’re getting closer; Qt 6 is also available. The distribution also comes with GCC 12.2.0, GNU libc 2.33, Xfce 4.16, Linux-libre 6.0.10, LibreOffice 7.4.3.2, and Emacs 28.2 (with just-in-time compilation support!).
In other news, motivated by the fact that Python 2 officially reached “end of life” in 2020, more than 500 Python 2 packages were removed—those whose name starts with python2-. This includes “big ones” like python2-numpy and python2-scipy. Those who still need these have two options: using guix time-machine to jump to an older commit that contains the packages they need, or using the Guix-Past channel to build some of those old packages in today’s environments—scientific computing is one area where this may come in handy.
On top of that, the Web site features a new package browser—at last! Among other things, the package browse provides stable package URLs like https://packages.guix.gnu.org/packages/PACKAGE.
The NEWS file lists additional noteworthy changes and bug fixes you may be interested in.
More documentation
As with past releases, we have worked on documentation to make Guix more approachable. “How-to” kind of sections have been written or improved, such as:
“Writing Manifests”
“Replicating Guix”
“Using TeX and LaTeX”
“System Troubleshooting Tips”
“Foreign Architectures”
“Using Guix Interactively”
The Cookbook likewise keeps receiving how-to entries, check it out!
The Guix reference manual is fully translated into French and German; 70% is available in Spanish, and there are preliminary translations in Russian, Chinese, and other languages. Guix itself is fully translated in French, with almost complete translations in Brazilian Portuguese, German, Slovak, and Spanish, and partial translations in almost twenty other languages. Check out the manual on how to help or this guided tour by translator in chief Julien Lepiller!
Supporting long-term reproducibility
A salient feature of Guix is its support for reproducible software deployment. There are several aspects to that, one of which is being able to retrieve source code from the Software Heritage archive. While Guix was already able to fetch the source code of packages from Software Heritage as a fallback, with version 1.4.0 the source code of Guix channels is automatically fetched from Software Heritage if its original URL has become unreachable.
In addition, Guix is now able to retrieve and restore source code tarballs such as tar.gz files. Software Heritage archives the contents of tarballs, but not tarball themselves. This created an impedance mismatch for Guix, where the majority of package definitions refer to tarballs and expect to be able to verify the content hash of the tarball itself. To bridge this gap, Timothy Sample developed Disarchive, a tool that can (1) extract tarball metadata, and (2) assemble previously-extracted metadata and actual files to reconstruct a tarball, as shown in the diagram below.
Diagram showing Disarchive and Software Heritage.
The Guix project has set up a continuous integration job to build a Disarchive database, which is available at disarchive.gnu.org. The database includes metadata for all the tarballs packages refer to. When a source code tarball disappears, Guix now transparently retrieves tarball metadata from Disarchive database, fetches file contents from Software Heritage, and reconstructs the original tarball. As of the “Preservation of Guix Report” published in January 2022, almost 75% of the .tar.gz files packages refer to are now fully archived with Disarchive and Software Heritage. Running guix lint -c archival PKG will tell you about the archival status of PKG. You can read more in the annual report of Guix-HPC.
This is a significant step forward to provide, for the first time, a tool that can redeploy past software environments while maintaining the connection between source code and binaries.
Application bundles and system images
The guix pack command to create “application bundles”—standalone application images—has been extended: guix pack -f deb creates a standalone .deb package that can be installed on Debian and derivative distros; the new --symlink flag makes it create symlinks within the image.
At the system level, the new guix system image command supersedes previously existing guix system sub-commands, providing a single entry point to build images of all types: raw disk images, QCOW2 virtual machine images, ISO8660 CD/DVD images, Docker images, and even images for Microsoft’s Windows Subsystem for Linux (WSL2). This comes with a high-level interface that lets you declare the type of image you want: the storage format, partitions, and of course the operating system for that image. To facilitate its use, predefined image types are provided:
$ guix system image --list-image-types
The available image types are:
- rock64-raw
- pinebook-pro-raw
- pine64-raw
- novena-raw
- hurd-qcow2
- hurd-raw
- raw-with-offset
- iso9660
- efi32-raw
- wsl2
- uncompressed-iso9660
- efi-raw
- docker
- qcow2
- tarball
That includes for example an image type for the Pine64 machines and for the GNU/Hurd operating system. For example, this is how you’d create an QCOW2 virtual machine image suitable for QEMU:
guix system image -t qcow2 my-operating-system.scm
… where my-operating-system.scm contains an operating system declaration.
Likewise, here’s how you’d create, on your x86_64 machine, an image for your Pine64 board, ready to be transferred to an SD card or similar storage device that the board will boot from:
guix system image -t pine64-raw my-operating-system.scm
The pine64-raw image type specifies that software in the image is actually cross-compiled to aarch64-linux-gnu—that is, GNU/Linux on an AArch64 CPU, with the appropriate U-Boot variant as its bootloader. Sky’s the limit!
Nicer packaging experience
A significant change that packagers will immediately notice is package simplification, introduced shortly after 1.3.0. The most visible effect is that package definitions now look clearer:
(package
;; …
(inputs (list pkg-config guile-3.0))) ;👍
… instead of the old baroque style with “input labels”:
(package
;; …
(inputs `(("pkg-config" ,pkg-config) ;👎
("guile" ,guile-3.0))))
The new guix style command can automatically convert from the “old” style to the “new” style of package inputs. It can also reformat whole Scheme files following the stylistic canons du jour, which is particularly handy when getting started with the language.
That’s just the tip of the iceberg: the new modify-inputs macro makes package input manipulation easier and clearer, and one can use G-expressions for instance in package phases. Read our earlier announcement for more info. On top of that, the new field sanitizer mechanism is used to validate some fields; for instance, the license field is now type-checked and the Texinfo syntax of description and synopsis is validated, all without any run-time overhead in common cases. We hope these changes will make it easier to get started with packaging.
The guix build command has new flags, --list-systems and --list-targets, to list supported system types (which may be passed to --system) and cross-compilation target triplets (for use with --target). Under the hood, the new (guix platform) module lets developers define “platforms”—a combination of CPU architecture and operating system—in an abstract way, unifying various bits of information previously scattered around.
In addition, packagers can now mark as “tunable” packages that would benefit from CPU micro-architecture optimizations, enabled with --tune.
Python packaging has seen important changes. First, the python package now honors the GUIX_PYTHONPATH environment variable rather than PYTHONPATH. That ensures that Python won’t unwillingly pick up packages not provided by Guix. Second, the new pyproject-build-system implements PEP 517. It complements the existing python-build-system, and both may eventually be merged together.
What’s great with packaging is when it comes for free. The guix import command gained support for several upstream package repositories: minetest (extensions of the Minetest game), elm (the Elm programming language), egg (for CHICKEN Scheme), and hexpm (for Erlang and Elixir packages). Existing importers have seen various improvements. The guix refresh command to automatically update package definitions has a new generic-git updater.
Try it!
There are several ways to get started using Guix:
The installation script lets you quickly install Guix on top of another GNU/Linux distribution.
The Guix System virtual machine image can be used with QEMU and is a simple way to discover Guix System without touching your system.
You can install Guix System as a standalone distribution. The installer will guide you through the initial configuration steps.
To review all the installation options at your disposal, consult the download page and don't hesitate to get in touch with us.
Enjoy!
About GNU Guix
GNU Guix is a transactional package manager and an advanced distribution of the GNU system that respects user freedom. Guix can be used on top of any system running the Hurd or the Linux kernel, or it can be used as a standalone operating system distribution for i686, x86_64, ARMv7, AArch64, and POWER9 machines.
In addition to standard package management features, Guix supports transactional upgrades and roll-backs, unprivileged package management, per-user profiles, and garbage collection. When used as a standalone GNU/Linux distribution, Guix offers a declarative, stateless approach to operating system configuration management. Guix is highly customizable and hackable through Guile programming interfaces and extensions to the Scheme language.
https://guix.gnu.org/blog/2022/gnu-guix-1.4.0-released/