Distro Walk – Void Linux

DistroWatch lists 278 active distributions, but these numbers are misleading. Many distributions are minor variations of a half dozen major distributions, distinguished by their default software selection or oriented to a particular task. A notable exception is Void Linux [1], a small project organized more like the distributions of two decades ago, with every part of its structure carefully considered. The result is one of the more original distributions available today. To learn more, I contacted Michael Aldridge, who answered my questions after consulting with other core members of the development team.

Originally released in 2008 by Juan Romero Pardines, Void Linux served as a testbed for the XBPS Package Manager. Since then, Void has changed direction several times. Currently, Void Linux is a rolling release distribution with an emphasis on making system management and contribution easy.

Aldridge describes Void as "a barely controlled anarchy" with "quasi-appointed leads spread across infrastructure, platform support, the package manager itself, and the creature comforts such as docs and debugging tools …. Because we have so few members, and all of them are volunteering their time, we simply cannot spare the clock cycles to have a stricter organization." Developers tend to control what interests them, while every core maintainer has the right to vote on decisions about the project as a whole, such as accepting new members.

Currently, Void has 17 core maintainers. Since January 1, 2021, 266 maintainers have contributed to the distribution's packages and 16 to the official handbook. The project is run on minimal hardware: three build servers, plus another seven servers and a handful of mirrors. Aldridge says, "We rely on the generosity of other projects and organizations to mirror packages to end users."

Over 8,000 packages for nine supported architectures are officially maintained, and additional ports are maintained unofficially by project members. "As a project that highly respects the privacy of our end users," Aldridge says, "we don't track metrics across any large pool, in terms of ISO downloads or mirror usage." However, Void's default mirror delivers an average of 38TB of data each month, a testimony to the distribution's growing popularity.

Design Philosophy

Void's name was chosen for lack of a name and stands for nothing. In the same way, Aldridge notes that "Void's lack of philosophy is a philosophy in itself." Nonetheless, several general principles have evolved over the years. First, the only changes to upstream applications are those needed to compile Void, just as in Arch Linux. As much as possible, configuration is left to the user. "This approach has led many users to label Void as minimalistic," Aldridge notes, "but our simplicity comes from Void trying to not interfere in upstream's decisions, not a drive for minimalism."

Second, Void Linux discourages nonstandard templates for packages, instead encouraging a standard build logic. "This means," Aldridge explains, "that tooling changes, compiler flags, new lints, and any other changes are immediately applied to all newly built packages. Furthermore, wide reaching changes can be coordinated within a single repository, and we don't have to keep our tooling compatible with old style templates if there changes. Anybody who maintains their own private templates needs to rebase [using] our work, because our repository is the source of truth at any given commit." This insistence on consistency makes packaging easier for developers and makes consistency in the distribution easier to maintain.

This consistency is also partly responsible for Void's third design principle: the ability to maintain what its website calls a "stable rolling release." As Aldridge points out, whether this description is a contradiction depends on the definition of "stable." In a number of distributions, a rolling release means a high risk of problems when updating. By contrast, Void uses a number of mechanisms to avoid such problems. For example, its build system has checks for shared library compatibility, which minimize the chances of partial updates. Similarly, xbps-src, its build system, includes a large number of sanity checks. In addition, when a kernel is updated, the older one is not immediately deleted, which ensures that the system remains bootable if the new kernel has problems. Users can also use a tool called vkpurge, which allows a controlled removal of old kernels and a choice of current kernels for replacement, including long-term support kernels. Another tactic to maintain a stable rolling release is to use only stable upstream releases in most cases. "Admittedly, it's a moving target," Aldridge says. "We heavily rely on what the upstream considers stable, and there will be always issues and bugs slipping through. But, again, rolling releases give us a tool to quickly fix those issues as they occur."

Distinguishing Features

Besides the features required for a rolling release, Void has several distinguishing features. Its default installation is minimal, and much of the configuration is left to users. In addition, unlike most distributions, all the supported architectures are built from a single source, using the XBPS Package Manager as a wrapper for build functions. "No matter if you choose glibc on x86_64 or ARMv7 with the musl libc," Aldridge says, "the very same package definitions are used. This is true for all our platforms except our ports, such as PowerPC platforms, which are currently developed in a fork that regularly is synchronized with the Void Linux project, but we strive to include it in the main project. Our software supports several architectures (MIPS, ARMv5) [that] we as a project do not officially support – mostly because computing resources are scarce, and we need to decide how to spend them."

Another unusual feature is Void's C library diversity: the support of multiple libraries such as musl libc and glibc in the same system. Originally, this support was included simply because it was possible, according to Aldridge. Then the development team realized that each library had its own advantages. For instance, it turned out that using musl libc made it easier to explore the use of glibc. "It was just the logical conclusion that if we rely on musl for development, why not make it a target for the distribution?" Aldridge explains. "With our approach, we give ourselves and users the choice: rely on a very clean and readable solution like musl libc or opt for a more widely used solution like glibc, which contains more platform-specific optimizations and is what most upstreams use to test their software. This flexibility makes it easier to run closed source, third-party software."

Probably, however, Void is best known for using runit as an init system. Void was among the first distributions to run systemd, but the developers quickly found that it had portability issues and that upstream projects largely did not support Void's alternate C library implementations. Consequently, Void has used runit since 2014. Runit is not feature complete, because it lacks support for features such as oneshot services, but on the whole, Void is simple enough that runit meets most of its needs. "We've been keeping an eye out for init systems that fit our needs," Aldridge says, "but … a new system would have to meet our requirements in simplicity and not be a step backwards into SysVinit-like systems. All in all, because of the simplicity of the concept, the service scripts are easy to read, easy to understand, and given runit's small feature space, easy to write. [Runit] somehow came to fit our ethos, even if we only adopted it because of portability issues."

What's Next

Aldridge says, "We are very satisfied with the current state of both the project and the system." However, the expansion of multiple library support and improvements to the XBPS Package Manager remain ongoing goals. In addition, Void is considering expanding the use of containers on its services to make the introduction of new hosts easier and to allow machines to be pulled out of service for updates and maintenance. Void Linux is also considering the introduction of other hardware architectures into the distribution.

As for other features, who knows? By going its own way, Void has produced not only an original distribution, but an efficient one – and one that makes contributing relatively easy. Sometimes publicity – such as from participating in Hacktoberfest the past few years – results in a patch load that strains the project's maintainers, but the low barrier to participation remains a point of pride. "We enjoy being a serious project where some people make their very first FOSS contributions," says Aldridge.