Analysis A new version of Linux distro NixOS has been released, just one day after a contentious blogpost that asked "Will Nix overtake Docker?"
For DevOps folk, this was tantamount to clickbait: Nix and Docker are different tools for different jobs, and anyway, it's possible to use Nix to build Docker images.
The distro, which hit version 21.11 on the last day of November, was built around the purely functional Nix package manager.
Nix is one of several responses to the many complexities of Linux software packaging. Given the issues around dependencies, updates, and the many problems they can cause – which in some contexts is becoming a joke – some of the more alternative-minded Linux developers thought that the best way to tackle this would be to re-engineer how OSes are built and installed.
There are many such efforts, and functional package managers lie at one extreme. Nix is the most mature such tool, dating back to 2003; the conceptually similar GNU Guix is a decade younger. Nix uses its own definition language, while the GNU Project uses the Guile dialect of Scheme.
Both profoundly modify the traditional Unix directory hierarchy. Instead, they take a formal specification of a desired system state, written in a declarative, functional language, and then solve this automatically. The approach has a number of benefits: reliable, reproducible system builds; guaranteed consistency; atomic upgrades with rollback; the ability to have multiple versions of the same programs installed concurrently without clashing; and more.
But the side effect of this is too much for some techies to swallow: the resulting filesystem layout is no longer easily human-readable. Programs live in folders with names based on cryptographic hashes. There are other costs, too, such as slow build times, although there are binary-caching tools to help.
It's not necessary to use either distro to get the benefits of the packaging system – both can run on other distros and indeed operating systems, including macOS.
The other extreme of this scale is GoboLinux. The same age as Nix, this experimental distro also completely discards the traditional Unix filesystem layout, but this time it's replaced with a more human-readable directory tree with plain-English names.
- The rocky road to better Linux software installation: Containers, containers, containers
- Utopia? Echoes of Delphi and Dreamweaver in new visual editor for React
- Crims target telcos' Linux and Solaris boxes, which don't get enough infosec love
- Undebug my heart: Using Cisco's IOS to take down capitalism – accidentally
- Wine pops cork on version 6.0 of the Windows compatibility layer for *nix systems
The traditional Unix directory layout combines unrelated files according to their type, or the system roles for which they're required, into a semi-standardised [PDF] tree. The result is large, complex, and somewhat cryptic – although there are efforts to simplify it – but millions of Unix users are familiar with it.
Gobo turns this layout on its head. Each app, along with all of its components and dependencies, is kept in its own separate directory tree. Because directory names are versioned, different versions of the same app can co-exist. Installation is as simple as copying a directory, and de-installation just means deleting one. It resembles the macOS way of doing things, but it's more radical, restructuring the entire OS far below the GUI level.
Sadly, GoboLinux has never really caught on, and functional package managers seem to be just a bit too radical for most distro maintainers – just as functional programming languages are for many programmers. Although Nix or Guix definitely offer advantages, to use them, overworked sysadmins have to learn a lot of complex new tools and methods. In contrast, tools like Docker are relatively simple to understand and to use.
So, instead of re-architecting the way distros are built, vendors are reimplementing similar functionality using simpler tools inherited from the server world: containers, squashfs filesystems inside single files, and, for distros that have them, copy-on-write filesystems to provide rollback functionality.
All the enterprise Linux vendors are working away on this. The goal is to build operating systems as robust as mobile OSes: periodically, the vendor ships a thoroughly tested and integrated image which end users can't change and don't need to. In normal use, the root filesystem is mounted read-only, and there's no package manager.
Red Hat was working on an immutable OS with transactional updates under the banner of "Project Atomic", but then it acquired CoreOS. This resulted in considerable overlap, and the Atomic Host edition of RHEL is now "sunset" without a clear replacement. In the interim, the Fedora project offers CoreOS for servers hosting containers, an Internet of Things variant, and desktop editions with either GNOME or KDE.
Because Red Hat doesn't currently use a filesystem with snapshots, it had to invent a transactional-install system (think "Git for binaries") called OStree and layer it on top of a conventional filesystem.
SUSE uses Btrfs and leans heavily on its snapshot and copy-on-write functionality, meaning that it can offer transactional updates and rollback, a root filesystem that in normal operation is mounted read-only, but also end user package installation and updates, without needing OStree or anything like it.
Since Canonical cancelled its touch UI and phone/tablet OS, the company's only immutable OS is Ubuntu Core, its IoT distro.
It doesn't get much airplay, but there is already a mature immutable-image-based desktop Linux, based around OStree and Flatpaks: EndlessOS. Since there's no package manager, it's somewhat moot, but Endless is in fact based around a Debian core. It has a read-only root filesystem, a version of GNOME Shell slightly customised to be a little more Windows-like, and all applications are managed as Flatpaks.
The design of Linux distros is changing, and as with packaging systems, the lightweight efficient approaches look set to lose out against simpler but more pragmatic designs… but the evolutionary pressure from tiny smart devices with very limited storage and bandwidth might yet change that. ®