Introduction

In 2018 I reviewed Void Linux after learining that it had a build system that was similar to the Arch Build System, but even more integral to package management, allowing Void package management to be something of a hybrid binary/source system, which facilitates building and installing packages from its source repository on GitHub, building packages from third party software distributors, and contributing to packages to Void's binary repositories. My impression at that time was that Void Linux was responsive and had fast boot times, but I found runit to be impractical, lacking in reliability and capability, compared to systemd.

I had planned to revisit Void and was inspired to do so now because while browsing the Internet for X11 replacements, I came across a video on installing Xlibre on Void. About the same time I saw that there are now an increasing number of Void Linux derivatives created with its live ISO creation tools. I first installed Void on my secondary laptop, the Dell G5. I was so impressed with its speed, I installed it on my primary laptop, the Lenovo Legion. In both cases I used the Glibc only AgarimOS respin of Void to install the Plasma edition.

I should note, that I chose to install on a Btrfs partition, and after installation modified the subvolume layout to the openSUSE style after installation from a chroot. I also installed the grub-btrfs package to include Btrfs snapshots in the GRUB menu, and with AI assistance created a wrapper script around the XBPS package management commands to automatically create pre- and post- Btrfs snapshots using Snapper. The process to create the Btrfs subvolume layout, and the components to integrate GRUB and automatic Snapper snapshots is described in Void Linux on Btrfs with SUSE Style Subvolume Layout and Custom Snapper Integration with XBPS Package Management.

Review Summary

For readers who do not have the time to read the entire article, here are some of the highlights.

• AgarimOS builds on top of the Void Linux base using its Live ISO creation tools. It limits itself, at least in the tested Plasma edition, to fully customizing the appearance of the desktop environment and the interactive experience of its default shell, zsh.
• The theme uses the Catppuccin Mocha Mauve theme, making the theme available to user experience/interface appearance elements in the desktop environment, including a GRUB theme, SDDM theme, and Plasma splash screen.
• AgarimOS includes the modern terminal emulator WezTerm instead of Konsole. The zsh configuration through the user configuration ~/.config/zsh/.zshrc to incorporate numerous alternative utilities aliased to usual commands.
• The Void Linux base uses, instead of systemd the minimalistic runit as the Init Program, Service Supervisor, as well as the Process Supervisor, and Service Manager. For the distinction between this terms see the section Glossary and Definitinos at end of the article. This contributes to the extremely fast boot times and simple service administration, but requires learining its completely differenct mechanisms.
• Unlike some other distributions that use alternative init systems and associated programs, such as the Dinit
• Power management on a laptop is impressive in its reliability and speed. Of the five distribution's on the Lenovo Legion, Void performs the best in entering hibernation and resuming from hibernation, and only two of the others can enter and resume from hibernation, but not reliably. The difference with Void is that it does not rely on a systemd component for its power management.
• Void uses its own package management system called XBPS (X Binary Package Management System), which consists of numerous commands for differenct package managment tasks. It is the fastest of the various package managment systems used by other distributions. It is also comprehensive in its features, including, for example, local repository management, finding files owned by a package, finding a package that owns a file, and most impressive of all its integrated package building tool, xbps-src.

Recommendation

I highly recommend Void Linux for its minimalism, performance, and most of all for its comprehensive XBPS package management system with a closely associated build system. And for those who do not want the ever increasing scope of systemd, it is a solid distribution. However, for daily production use, I would recommend only installing it from the official distribution and not by using the AgarimOS respin ISO. One reason for this is that the AgarimOS ISO, unlike Void, distributes its ISOs without any GPG signatures or checksum files.

Another reason is that, while the customization's in AgarimOS are worthwhile, as the AgarimOS developer notes, it is intended to be a auto-pedagogical tool for his own development and not for production use by others. I do, however, recommend AgarimOS for exposure to what is possible with zsh configuration. I, myself, will be incorporating some of its .zshrc configuration elements with my existing zsh configuration.

Review

Default State

True to Void's minimal architecture, the default state of the AgarimOS respin of Void is also minimal in terms of applications. The only applications installed out-of-the-box are the WezTerm terminal written in Rust and configured in the Lua scripting language, Firefox Web Broser, the OctoXBPS GUI package manager, and a terminal system monitor application, bottom.

The installation is so minimal --whether intentional or by oversight, even standard Plasma applications such as System Monitor and Info Center are not installed by default. Components required by System Monitor to provide GPU information are also not installed, something which is not usually an issue in other distributions.

The other important aspect of the default installation of note regards graphics. There is no option to install proprietary graphics drivers in the installer, so only the FOSS Nouveau is installed and available, by default. In the Plasma version of the distribution both X11 and Wayland sessions are available, and the X11 session is enabled by default.

Initial Issues

The numerous minor problems and one major problem I encountered during my previous use of Void in 2018 were not present in the current installation. However, there were several other minor problems and one other major problem in the current installation. The major problem required resolution before I could use the OS reliably, and the minor ones before I could use it comfortably. The minor problems were:

• The xf86-input-synaptics touchpad driver was installed by default, causing conflicts such that the Plasma System Settings touchpad settings could not be modified. This required uninstalling the conflicting driver and modifying the X configuration by creating a file, /etc/X11/xorg.conf.d/30-touchpad.conf, and adding:

  Section "InputClass"
            Identifier "touchpad"
            MatchIsTouchpad "on"
            MatchDevicePath "/dev/input/event*"
            Driver "libinput"
            Option "Tapping" "on"
  EndSection

• The first time I moved to a new wireless network after installation, NetworkManager would not update the nameserver settings in its /run/NetworkManager/resolv.conf file, which is linked to /etc/resolv.conf. This required manually modifying the settings in this file to connect, then tinkering with nmcli, disabling the wpa_supplicant service, installing iwd, enabling its service, and more tinkering with one of its command line program, iwctl. Somehow, after reestablishing the link between /run/NetworkManager/resolv.conf and /etc/resolv.conf, the wireless networking worked.

There major problem was insidious. It was one that I suspect was not due to any Void process, but possibly due to an oversight in the AgarimOS developer's process in using the Void ISO and live system creation tools. It is also possible I caused this problem after creating subvolumes and moving the contents of these directories to the new subvolumes, however, I don't think so since I've used the process successfully on Fedora and other distributions successfully.

The problem was that the /etc/ and /usr/ directory ownership was set to the regular user specified during installation. I didn't notice this in my initial use of AgarimOS/Void on the Dell G5, but suddenly, the system became unstable and commands would not execute successfully. I changed the ownership on these directories, using chown with the -R option. This was not the appropriate method for correcting the problem as the setuid permission was removed on the sudo and su commands. I gave up on fixing this issue on the Dell, but used a script from a chroot to correct the permissions of each file in these directories individually and treating the files with setuid and setgid permissions separately on the Lenovo Legion.

AgarimOS Customizations

Agarim's customizations of Void are focused on the appearance of the desktop environment and the interactive terminal experience.

Plasma Theme

AgarimOS's appearance is largely governed by its consistent use of the Cattpuchin theme. It provides a Plasma global theme called Catppuccin Mocha Mauve and associated theme components of the same name: color scheme, Plasma (Plasmashell) theme, window decoration theme, ponter theme, splash screen, as well as a Catppuccin Mocha SDDM theme. The theme configuration also uses Kvantum as the application style engine, with a theme consistent with the other elements named -- Catppuccin Mocha Mauve. A wallpaper called ChessCatppuccin is also included. The theme even extends to the preboot environment with a Catppucin styled GRUB theme.

Although Catppuccin is not my favorite of all available Plasma themes, it is a good choice because it has the benefit of being adapted to many applications and appearance elements of many user interfaces and experiences, presumably for 362 applications, interfaces, and experiences, based on the number of repositories in the Catppuccin GitHub portal. For example, it has been adapted to provide many variants of Neovim colorschemes. As a desktop environment theme, it has been applied to more elements of a DE. For example, there is a Yakuake skin available for this theme -- in contrast to other themes which neglect this terminal.

The themeing is complete -- at least in availability of all elements by default on the installation, however there are a few issues in how it is applied in AgarimOS:

• Although available in System Settings, the theme wallpaper is not applied on the desktop and or the SDDM greeter, which seems to expect it based on the setting's preview. The actual wallpaper applied to the desktop and the greeter seems to be one created by theme designer L4K1.
• The colorscheme applied to Dolphin is hardcoded into the application's configuration file at ~/.config/dolphinrc. This is unnecessary as applying the systemwide theme elements, including Kvantum to Catppuccin Mocha Mauve appropriately sets the Dolphin theme. The choice by AgarimOS to hard-code the style prevents the normal Plasma behavior where changing the system theme also changes the Dolphin theme. I found this to be annoying, as it first required me to troubleshoot the issue, then remove the colors section from ~/.config/dolphinrc

The AgarimOS developer has created a complete and consistent theme based on a popular style that will be appreciated by many users, but I eventually created a theme that suits my preferences and my habit of choosing colorshemes that match a distribution identity (I used the AgarimOS installer to expose myself to a new experience, but I really wanted a Void system) based on Everforest and Leaf If interested you can see it here.

Terminal Experience

This aspect of AgarimOS's customization is achieved through an alternative terminal emulator, additional terminal-centric applications which alter the appearance and functionality of the terminal in interactive use, and an alternative login shell to what is typically used by Linux distribtutions.

zsh

The login shell and the interactive shell is zsh. Although not the typical choice, especially for a login shell, it is in my opinion, the best choice. In offers the same advanced completion, syntax highlighting, and convenience features of fish but with better compatiblility and similar behavior and syntax to Bourne type shells like Bash, as well as incorporation of POSIX features.

The choice of zsh, and the extensive configuration for interactive use through .zshrc, is the largest added value to the Void Linux base. The configuration uses the applications listed in the following table to alter the appearance and behavior of commands and to improve the user experience.

Applications

The utilities, incorporated through aliases for common commands, or shell functions with the same command as those that they replace, are listed below, and their functionality is shown in the above set of images. The most impressive and useful, simply form a convenience perspective, is the alias of cd to z, which executes zoxide instead of cd. This command allows changing directories by using a part of the target path. For example one can change to the directory /home/brook/DataEXT4-16ITH6/ordinatechnic.com/content/distribution-reviews from home by typing:

The configuration is not without pproblems, however. For example, the function named cat defined in .zshrc, to replace the normal command with bat causes a nicely formatted, syntax-highlighted output with bat but also -- presumably with the intention of providing a fail-safe -- causes a redundant output produced by cat.

z revie

The other most notable addition is the use of fzf, a utility that fuzzily filters through lists, where lists can be file paths in a directory tree, possible command completions in zsh. For example, starting to type a command produces a nice looking list of possible completions (this is shown in the first slide in the above set of images).

Unfortunately, the AgarimOS configutation is missing two pieces of convenience functionality that is possible with some of the available configuration snippets provided on the Arch Wiki page for zsh. One is the list of possible options displayed with a brief description when typing a command followed by -. The command can be completed by selecting it with the down arrow key. Another convenience shows values of environment variables when typing part of the environement variable name or even typing echo $ gives a shadow suggestion on the commadn line and also displays a list of completions for the environemnt variable names and and their values. The top left window in the following image shows this missing functionality, available through simple configuration, in Artix with the Arch Wiki snippets included in its .zshrc.

Some of the

WezTerm

Another unusual choice, this one probably not so useful for most users, is installing WezTerm as the only terminal emulator. This is a so-called modern emulator that is capable of directly using the GPU to render the text objects in the emulator. It uses the Kitty Terminal Protocls which improve the graphics and input capabilities of terminals which support it. It also written in Rust.

The drawback of this terminal is it is configured solely through through a Lua confiuration file, which is empty in noromal installations. AgarimOS does some configuration, but it is not nearly enough, in my opinion, for comfortable use. Users will need to go through the extensive WezTerm documentation to cutomize it to their liking. In addition, the Xterm-style formatted escape sequences are not processed properly by the terminal, so even typing special characters, for example, END, HOME, Up-Arrow, produces:

 ;1F;1H;1A

Because of this, instead of tinkering with WezTerm -- which is really only beneficial when interacting with AI agents which produce vast amounts of output -- configuration, I installed Konsole, KDE's own terminal, The experience is much better, and because the login shell is zsh, it becomes the interactive shell in Konsole, without any adjustment to its settings, and uses the customizations in ~/.config/zsh/.zshrc.

runit Init Program and Service Manager

The single feature that differentiates Void Linux from other distributions, and by extension AgarimOS, is the use of runit as the init program and service manager, or as Void documentation calls it upervision suite. (See the end of this article for useful definitions.) As used in Void, runit supplies the init program that runs as PID 1, instead of systemd, and starts services in theree stages, and continues to supervise services until shutdown. (For a good introduction to runit as an init program, see the section Runit as the init system on Gentoo's Wiki page on the subject.

runit is an extremely simple program and makes administering a Void system transparent. As an example of its simplicity and transparency, consider its operation in booting and shutting down the system. These operations are simply an execution of a series of shell scripts in two stages during startup, and an execution of a series of shell scripts in a single stage during shutdown. These stages -- Stage 1, Stage 2, and Stage 3 -- are runlevels, and roughly correspond to some of systemd's targets.

Stage 1

When runit or its helper, runit-init start, themselves started probably by a kernel command line parameter included in the dracut settings. runitexecuts the shell script /etc/runit/1. This script sources /etc/runit/functions and /etc/rc.conf then executes the scripts in /etc/runit/core-services in shell expansion order.

brook  …/ordinatechnic_content_20250311   exp ✘!?   00:53  ls -la /etc/runit/core-services
drwxr-xr-x 398 B root root 15 Aug 26 01:23:44 PM --  .
drwxr-xr-x 148 B root root 15 Aug 26 01:25:26 PM --  ..
.rw-r--r-- 2.5 KB root root 15 Aug 26 01:07:28 PM --  00-pseudofs.sh
.rw-r--r-- 229 B root root 15 Aug 26 01:07:28 PM --  01-static-devnodes.sh
.rw-r--r-- 276 B root root 15 Aug 26 01:07:28 PM --  02-kmods.sh
.rw-r--r-- 491 B root root 15 Aug 26 01:07:28 PM --  02-udev.sh
.rw-r--r-- 687 B root root 15 Aug 26 01:07:28 PM --  03-console-setup.sh
.rw-r--r-- 2.1 KB root root 15 Aug 26 01:07:28 PM --  03-filesystems.sh
.rw-r--r-- 118 B root root 15 Aug 26 01:07:28 PM --  04-swap.sh
.rw-r--r-- 640 B root root 15 Aug 26 01:07:28 PM --  05-misc.sh
.rw-r--r-- 557 B root root 15 Aug 26 01:07:28 PM --  08-sysctl.sh
.rw-r--r-- 167 B root root 15 Aug 26 01:07:28 PM --  10-runit-control.sh
.rw-r--r-- 188 B root root 15 Aug 26 01:07:28 PM --  97-dmesg.sh
.rw-r--r-- 317 B root root 15 Aug 26 01:07:28 PM --  98-sbin-merge.sh
.rw-r--r-- 408 B root root 15 Aug 26 01:07:28 PM --  99-cleanup.sh
.rw-r--r-- 167 B root root 09 Jul 23 03:02:51 PM --  99-live-audio.sh
        

Stage 2

When /etc/runit/1 completes, the init program runs /etc/runit/2, which sets the runlevel mode (single-user or default multi-user), creates the directory /run/runit/runsvdir, and links /etc/runit/runsvdir/current to /run/runit/runsvdir/current, which starts the enabled services and sets up monitoring of the enabled services for the runlevel mode with the command:

runsvdir -P /run/runit/runsvdir/current

Stage 3

This stage is the shutdown process. /etc/runit/3 sources /etc/runit/functions and /etc/rc.conf and then executes the scripts in /etc/runit/shutdown.d, shown in the following listing.

brook  …/ordinatechnic_content_20250311   exp ✘!?   01:03  ls -la /etc/runit/shutdown.d
drwxr-xr-x 230 B root root 15 Aug 26 01:23:44 PM --  .
drwxr-xr-x 148 B root root 15 Aug 26 01:25:26 PM --  ..
.rw-r--r-- 90 B root root 15 Aug 26 01:07:28 PM --  10-sv-stop.sh
.rw-r--r-- 44 B root root 15 Aug 26 01:07:28 PM --  20-rc-shutdown.sh
.rw-r--r-- 96 B root root 15 Aug 26 01:07:28 PM --  30-seedrng.sh
.rw-r--r-- 139 B root root 15 Aug 26 01:07:28 PM --  40-hwclock.sh
.rw-r--r-- 8 B root root 15 Aug 26 01:07:28 PM --  50-wtmp.sh
.rw-r--r-- 89 B root root 15 Aug 26 01:07:28 PM --  60-udev.sh
.rw-r--r-- 148 B root root 15 Aug 26 01:07:28 PM --  70-pkill.sh
.rw-r--r-- 334 B root root 15 Aug 26 01:07:28 PM --  80-filesystems.sh
.rw-r--r-- 347 B root root 15 Aug 26 01:07:28 PM --  90-kexec.sh
        

runit is also simple in day to day managment by the user, which typically involves enabling, starting, stopping, restarting, and querying the status of a service. Available services are stored in /etc/sv (Image 4 in the above set) in a subdirectory for each service. Each subdirectory contains, most importantly, a shell script called run which is the actual service file, somewhat equivalent to a systemd service unit file. Some service directories also contain a finish script that runs when a service is stoppped, and a log directory which itself contains a log directory containing its own run script to set up logging for the service. These are shown in the following image and in Image 2 of the above set of images.

These directories and the files they contain are the essence of service management with runit. A service is enabled by linking a service directory in /etc/sv/ to a target inside /var/service. This is shown in the Konsole window in Image 2 of the above set where the power-profies-daemon is enabled with the command:

sudo ln -s /etc/sv/power-profiles-daemon /var/service/

The image also shows checking the status of the command with:

sudo sv status power-profiles-daemon

Performance

Most discussions about Void mention its exceptional performance, due to its minimalism, and the lack of systemd bloat. I found this to be the case also; in fact one of the reasons I installed Void (through the AgarimOS respin) on my primary laptop was due to the impressive performance I experienced on my secondary laptop. The boot times are the fastest I have seen on any distribution. The impressive boot times were in the default state with the open source Nouveau driver. After installing the proprietary Nvidia driver, there was an in increase in boot times. This can be imporved by forcing early loading of Nvidia drivers as described below in the section Fixes and Enhancements -> Force Early Loading of Nvidia Drivers.

Laptop Power Management

Power management was another aspect of Void that pleasantly surprised me. On the Lenovo Legion, only the Arch based installations and Siduction seem to reliable for the most part in this regard, while openSUSE Tumbleweed and Ultramarine (Fedora) have more problems. Hibernation works reliably on Void Linux, which I believe is due to the lack of systed-sleep components which handle suspend and hibernate in a systemd based system.

tlp tlp and tuned are installed by default for battery power optimization. Unfortunately, tlp is incompatible with the Plasma desktop's Battery and Power widget which allows controlling the power-profiles-daemon state. So, I replaced tlp with power-profiles-daemon which required the removal of tuned.

Package Management and Infrastructure

Void Linux has a comprehensive package management system called XBPS (X Binary Package System) a Void custom developed system, that includes a ports like build system as in BSD called xbps-src that allows easy package building and customization of packages , as well as simple management of local and third-party repositories.

XBPS

XBPS is very similar to Arch's pacman, at least in the characteristics that are readily visible to the user, with succinct command options and outputs that are barely distinguishable from pacman -- especially in the command to update the system:

xbps-install -Su

Unlike Arch, but like Debian, it splits its capability among different commands, shown in the following table.

The most commonly used of these will be xbps-install for updates and installations, xbps-remove for uninstalling, and xbps-query for querying the repositories and the installed system, and even an xbps-alternatives for listing and setting alternatives for packages.

I found this binary package manager to be very good, especially considering that it provides features that pacman doesn't provide without add-on helper scripts, such as the ability to search for a package in a remote repository that provides a particular file. This can be done with the command

xbps-query -Ro '*/filename'

The use of this combination of options is discouraged because it causes excessive use of repository resources as it causes -- according to Void documentation -- xbps-query "to download parts of every package to find the file". A suggested alternative, from the xtools set of XBPS helper programs, is the xlocate command:

xbps-locate '*/filename'

which searches the locally available package cache.

However, like pacman, XBPS still requires users to be adept at various UNIX utilities for some advanced tasks, such as uninstalling all packages that match a certain string, which are provided out of the box by some command line package managers. For example, when I wanted to uninstall Xfce, I had to pipe one xbps command output as an input to a UNIX utility program and use this result as the input to another XBPS command as in:

$ sudo xbps-remove -F $(xbps-query -s xfce | cut -d ' ' -f 2)

Other features and usage examples of XBPS are given below in Package Management.

xbps-src

The most impressive component of XBPS is xbps-src, the package build system and source package manager. This is the standout feature of Void that prompted me to try Void. Void users may use it to build and install packages from Void's source package GitHub repository as it is the only way Void distributes some proprietary packages. The unofficial third-party repository VUP is also available (see below).

Where xbps-src shines however is not in managing Void's own source packages, but in building packages distributed by third parties as source archives. In my current installation of AgarimOS/Void, I used xbps-src to package an AI generated fork of envycontrol as shown in the following image. This required:

1. cloning the Void Linux void-packages GitHub repository.

   git clone https://github.com/void-linux/void-packages

2. creating a directory for my custom package in the void-packages, as in:

   brook  …/ordinatechnic_content_20250311   exp ✘!?   20:07  tree -L 3
   ~/void-packages/srcpkgs/envycontrol-void
   /home/brook/void-packages/srcpkgs/envycontrol-void
   ├── files
   │   ├── envycontrol-void
   │   └── envycontrol-void.1
   └── template
   
   2 directories, 3 files

3. from within the -void-packagesdirectory, building the package with

   .xbps-src pkg envycontrol-void

For a complete discussion on the use of xbps-src for building packages, see Void Linux: Creating Binary Packages Using xbps-src, prepared during my previous use of Void Linux in 2028.

Void User Packages (VUP)

For software not packaged by Void, an alternative to building packages locally is the VUP (Void User Packages). This is an unofficial repository, similar to the AUR, but unlike the AUR, it does not simply provide package recipes, known as templates in Void or PKGBUILD's in Arch. The build is actually performed by the repository build system. For more control users can build the package locally.

Nvidia and Optimus

The default AgarimOS/Void installation only includes the Nouveau driver by default. However, the Nvidia proprietary driver is available from Void's void-repo-nonfree repository, enabled by installing a package of the same name, as earlier in this article. After enabling this repo, the nvidia package can be installed as shown below.

Unfortunately, Void does not include any Optimus management utilities. I was able to generate a Void compatible fork of EnvyControl and create a package locally for Void, as described above, in order to flexibly take advantage of the Nvidia card as described in The Continuing Usefulness of X11 and Optimus Management Programs in the Age of Wayland and Switcheroo-Control. I also prefer X for some functionality that will never be available with Wayland, such as support for GTK application's menus to be available for display in Plasma's Global Menu widget. For information on the original EnvyControl utility, see EnvyControl: A Distribution Agnostic Nvidia Optimus Management Utility for Linux

Issues

Backlight Level Persistence

Backlight control with keyboard shortcuts and Plasma's Brightness and Color widget work as expected. However, the backlight level does not persist accross reboots and upon resuming from suspend and hibernate.

Touchpad Issues

On both Dell and Lenovo the touchpad had problems. In Plasma System Settings touchpad settings could not be modified because the Apply button was grayed out. Solviing this problem required uninstalling xf86-input-synaptics, adding my user to the input group, creating /etc/X11/xorg.conf.d/30-touchpad.conf and adding:

Section "InputClass"
          Identifier "touchpad"
          MatchIsTouchpad "on"
          MatchDevicePath "/dev/input/event*"
          Driver "libinput"
          Option "Tapping" "on"
EndSection

Plasma Keyboard Shortcuts

Default keyboard shortcuts for the Plasma desktop are not set other than the Super key to activate the launcher. Shortcuts for snapping windows to screen edges, which I use frequently were not set as they usually are in other distribution's Plasma implementations. This had to be fixed in the System Settings -> Keyboard -> Shortcuts.

Permissions and Ownership Issue

In both the Dell and the Lenovo, the /etc/ /usr/ directories had user and group ownership of the created user at installation instead of the root user. This may have been due to my conversion of the original installation on the top level Btrfs subvolume to a hierarchical subvolume layoyt where it was necessary to copy the contents of these directories to newly created root subvolume. Or, it could have been due to a problem with the live ISO creation process, a problem equally as severe as the most serious in my previous use of Void in which the user specified in the installer was not actually created in the installed system. Solving the current problem required generating a script to individually change permissions of each file and directory without setuid and setguid bits inside the /etc/ /usr/, then separately correct permissions for the files with setuid setguid permissions.

Package Management

A screenshot of the basic package manageent transaction is shown in the following screenshot, where a package that enables the Void void-repo-nonfree repository

Some examples of XBPS usage is presented in the following table.

Fixes and Enhancements

Force Early Loading of Nvidia Drivers

1. Enable early KMS (Kernel Mode Setting) to load Nvidia driver early in the intiramfs stage of system startup. Edit /etc/dracut.conf.d/nvidia.conf and include

   force_drivers+=" nvidia nvidia_modeset nvidia_uvm nvidia_drm "

2. Regenerate the initramfs.

   sudo dracut --regenerate-all --force

3. Ensure DRM modesetting is enabled in the GRUB configuration to include the modesetting kernel parameter. Modify /etc/default/grub to include nvidia-drm.modeset=1 in the GRUB_CMDLINE_LINUX_DEFAULT parameter value list.
4. Regenerate /boot/grub/grub.cfg with:

   sudo update-grub

Install Plasma Applications

Replace wpa_supplicant

Touchpad Confuguration

References

1. Void Linux Documentation: Services and Daemons - runit
2. Void Linux Documentation: XBPS Package Manager

Glossary and Definitinos

The content in this reference section was generated by Google Gemini.

Terminology

[The] terms [below] are often used interchangeably because modern software (like systemd) handles all of these roles simultaneously, they refer to distinct concepts in a Linux/Unix system architecture.

• Init Program: The actual binary executable (traditionally with PID 1) executed by the kernel as the first user-space process during boot.
• Init System: The entire suite of tools, scripts, configuration files, and software components that surround the init program to boot and manage the system state.
• Process Supervisor: A mechanism designed to monitor a single process (or tree of processes), continuously checking its health and automatically restarting it if it crashes.
• Service Supervisor: A specific type of process supervisor focused on managing long-running background tasks (daemons/services), tracking their runtime state, standard output/logging, and lifecycle events.
• Service Manager: A higher-level management layer that handles service dependencies, startup sequencing, parallel execution, targets/runlevels, and user interfaces (e.g., systemctl).

Characteristics

Classification of Major Init Systems

SysVinit

• Init Program: Yes (traditional /sbin/init, PID 1).
• Init System: Yes. Orchestrates runlevels (0–6) via shell scripts (/etc/init.d/).
• Process Supervisor: Minimal/Primitive. Reaps orphaned processes and can restart processes marked respawn in /etc/inittab, but lacks active health checking or dynamic monitoring.
• Service Supervisor: No. Once a daemon forks into the background, SysVinit loses direct tracking of its process state.
• Service Manager: Primitive. Relies on sequential execution of shell scripts using PID files to track and stop daemons.

OpenRC

• Init Program: No. OpenRC is not an init program; it requires a primary init program (like SysVinit, runit, or s6-linux-init) to run as PID 1.
• Init System: Yes (as a dependency-based init framework).
• Process Supervisor: Optional. Integrates with supervisors like supervisord or start-stop-daemon (with --respawn), but does not supervise natively.
• Service Supervisor: No. Relies on external tools or PID files to track status.
• Service Manager: Yes. Provides dependency resolution, parallel service startup, and named runlevels via rc-service and rc-update.

runit

• Init Program: Yes (runit stage 1/2/3, with runit or runsvdir running near PID 1).
• Init System: Yes. Uses a simple three-stage shell-script model for boot, runtime, and shutdown.
• Process Supervisor: Yes (runsv).
• Service Supervisor: Yes. runsv manages individual service directories, monitoring run scripts, pipes standard logging to svlogd, and handles clean restarts.
• Service Manager: Primitive (sv). Operates on individual services or symlinked service directories, but lacks complex dependency graph capabilities.

s6

• Init Program: Yes (s6-linux-init generates a minimal PID 1 init binary).
• Init System: Yes (when combined with s6-rc).
• Process Supervisor: Yes (s6-supervise).
• Service Supervisor: Yes. Uses individual s6-supervise processes per service for reliable process isolation, state tracking, and logging handling.
• Service Manager: Yes (s6-rc). An explicit state-machine and dependency manager that transitions the system between compiled service states.

Dinit

• Init Program: Yes (dinit runs as PID 1).
• Init System: Yes. Fully manages system boot, service execution, and power management/shutdown.
• Process Supervisor: Yes. Tracks process life cycles directly from PID 1.
• Service Supervisor: Yes. Supervises background services natively without requiring forking/PID files, keeping stdout/stderr pipes open for log capturing.
• Service Manager: Yes. Uses a fast, service-dependency engine built directly into the core daemon, supporting clean service activation, parallel boot, and state resolution.

systemd

• Init Program: Yes (systemd binary as PID 1).
• Init System: Yes. Provides complete end-to-end boot orchestration, target handling, device management, and socket activation.
• Process Supervisor: Yes. Leverages Linux cgroups to monitor every process spawned in a service unit, preventing processes from escaping supervision via double-forking.
• Service Supervisor: Yes. Tracks state, restarts crashed services based on unit properties (Restart=always), and routes output to journald.
• Service Manager: Yes (systemctl). Computes full dependency graphs, manages target units, supports dynamic socket/bus activation, and controls service lifecycles.