Void Linux is an independent rolling distribution that only includes FOSS software by default. It is reminiscent of Arch Linux in its minimalism, use of a custom package management and build system, and some other aspects of its design. Like Arch it is a distro suitable for advanced users who want to configure their OS as they see fit. It does, however, offer live ISOs which can be used to easily install a system, either from a local source on the ISO or from a network source which provides the latest packages during install. Unlike Arch, it is systemd free, using instead runit as the init system. Also unlike Arch, it uses the dracut utility to generate the initramfs -- an unusual choice for a minimalist distro. Additionally, it supports the Musl implementation of the C Standard Library as well as the more common Glibc, the GNU version of the Library, for developing the system, distrinuting two versions of each live ISO -- one using Musl and the other Glibc. This article reviews installations using the Enlightenment, Lxqt, and Xfce ISOs built with Glibc released on October 7, 2017.
I had been aware that one of the strengths of Arch was the Arch Build System, but upon a cursory investigation of this feature, it seemed like it was distinct from core package management. When I learned that Void also features a similar build system, but one that seemed to be 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 -- I became interested in trying it. I was also attracted to its purported speed resulting from its minimalist nature.
Since a live ISO featuring my preferred desktop environment -- KDE's Plasma -- was not available from Void, I chose the Enlightenment live ISO as a starting point for installing Plasma because of the Enlightenment desktop's novelty and my fondness for its uniqueness. (Screenshots of using the Void installer within the Enlightenment live environment are available in Void Linux 20171007 Review Supplement: Installation.)
Some time after using the Enlightenment based installation and having installing Plasma and resolving numerous issues and enhancing the usability of the system -- discussed in Void Linux 20171007 Review Supplement: Required Fixes and Enhancements, I broke the installation when attempting to replace the default Nouveau graphics driver with hybrid Intel/Nvidia switchable graphics.
I then reinstalled the distribution using the LXQt live ISO and immediately installed the Plasma desktop, this time opting to leave the Nouveau driver and postponing replacing it with a hybrid Intel/Nvidia graphics driver configuration until I learned more about the distribution. This installation had a problem also, which was that the battery component of the Plasma system notifications was reporting that a battery was not found. Even before I encountered this problem, there were major frustrations with network control on the LXQt installation because NetworkManager is not part of the default installation from the local source found on the LXQt ISO. I tried to use wpa_supplicant to connect to the Google Starbucks (where I happened to be) wireless network and install NetworkManager and managed to connect to the network using wpa_supplicant, as instructed in the Void Wiki Network Configuration page, but the captive portal detection wouldn't work when I opened the default browser included with the LXQt edition, Qupzilla. So I tethered my mobile phone to install NetworkManager, disabled conflicting network services, enabled the NetworkManager service. At this point there was more frustration because there was no network control applet in the LXQt panel. Suggestions in the Void Wiki involved installing GTK based solutions, but I didn't want to mix GTK components in the panel of a desktop environment based on Qt. At this point I gave up on Void's LXQt, rebooted into Manjaro, chrooted into my Void installation and installed Plasma. Rebooting into the Void Plasma, I had the native Plasma network control component found in the system notification area. Now the battery system notification component was reporting that a battery was not found.
So I decided to install again, incorrectly assuming that my installation of Plasma by chroot was problematic, this time using the Xfce live ISO. This live ISO provided the best experience, with the network management service options that would be used by most users -- NetworkManager -- already installed and enabled. The only minor problem, but possibly hard to find, was that the NetworkManager panel applet, normally displayed in Xfce's system notifications panel plugin, was hidden by default!
I discovered this almost by accident and enabled it. This correction wasn't necessary in the installed system. After a while, I saw this installation also had the system notification battery applet problem -- which by now I had learned was caused by an update to upower which broke its configuration -- solved by reinstalling it using the --force option.
In all three installations I had to resolve numerous issues before I had a system I could use comfortably. In fact, in all cases, before I could even log into the freshly installed system, I had to log in as root using a console and create my user, even though creating a user was one of the steps of the installer provided on the live ISOs. Somewhere in the Void Wiki there is an intimation that this problem is the result of modifying the default group memberships of the user being created instead of accepting the default during this step of the installation. This explanation of the cause of the issue doesn't make sense to me because if the installer allows the created user group modification to be modified in the first place, it shouldn't cause an issue, and if changing the default group membership of the user created at this step, the installer shouldn't allow changes. Also, this explanation seems to be incorrect or at least apply to the installers found in only some of the installation media, because by the third installation I didn't need to modify the default group membership, as the created user is added to the wheel group by default, the only change I would make. This problem of the user account not being available seems to be a known issue since the Void Wiki Post Installation Steps mentions it. It seems to be an issue too important to still exist as a known issue.
The next step after creating a user, in the case of the Enlightenment and LXQt installations, was to select a more automatic network management service than the default combination of dhcpcd and wpa-supplicant. In order to do so, both installations require users to disable the defaults and enable the appropriate more automatic service as is typically found in other distributions, connman -- Enlightenment's own analogue to NetworkManager -- and NetworkManager for LXQt. While this was easily done in the Enlightenment installation, it was nearly impossible in the LXQt installation for the reason described above.
In the case of the Xfce installation, the NetworkManager service was already enabled and the conflicting services were already disabled. While I had to unhide the NetworkManager panel plugin in the live ISO, I did not have to do this in the installed system, and could immediately connect to a wireless network using the panel plugin.
I found my experience with the three installations and the live ISOs to be inconsistent, as may be evident from the above. I had an initial positive impression of Void using the Enlightenment installation and thought it was better than the last implementation of this desktop I used -- provided by openSUSE -- because Void includes connman and its GUI, EConnMan.
I later had an even more positive initial impression of the Xfce installation, especially since the networking service was preconfigured, the minor issue of the networking panel plugin being hidden in the live ISO notwithstanding. This positive impression lasted until the battery status problem which not only affected Plasma but Xfce as well.
My impression of the LXQt installation, however, was that it was horrible from the very beginning due to the networking issue mentioned above, and a default theme which I found to be quite ugly and broken, with a default icon set that would not even display icons in the file manager.
The other issues I discovered affecting all installations, discussed on Void Linux 20171007 Review Supplement: Required Fixes and Enhancements along with issues common to all ISOs, were that tapping on the touchpad was not enabled, and that the necessary packages for a working Bluetooth were not installed and/or that the bluetooth service was not enabled, and that the regular user was not added to the bluetooth group, necessary to be able to make changes to Bluetooth settings as a regular user. The existence of some issues seemed to be dependent on the ISO used, or maybe it seemed so because of my inattention to what I was installing in my zeal to get a working installation, but some installations required the ntfs-3g package to be installed in order to be able to write to my NTFS data partition, while in others it was already installed. There was also an inconsistency in screen locking on suspend, where in the Enlightenment ISO and LXQt based installations the system would not display a lock screen, prompting for a password upon resuming from suspend. Somehow by the third installation, screen locking on Plasma when resuming from suspend was working, although not as well as in other distributions.
The above issues -- which can possibly be attributed to simple quality control, packaging errors, or configuration decisions -- should not overshadow the unique design features in Void Linux, the most notable being that the distribution uses runit as the init system and process and service manager. As used in Void, runit supplies the init program that runs as PID 1, sets the runlevels, starts and manages the services appropriate for the runlevel, and supervises processes. (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.
Proponents of runit will presumably appreciate most the simplicity and transparency of the program, especially compared to systemd, and will appreciate its increased efficiency and reliability over SysVinit. As an example of its simplicity and transparency, consider its function in booting the system. When runit or its helper, runit-init start, themselves started probably by a kernel command line parameter included in the dracut settings, they first run the file /etc/runit/1, which is just a shell script -- thus human readable. This script in turn runs all of the -- human readable -- shell scripts in /etc/runit/core-services in shell expansion order. When /etc/runit/1 completes, the init program runs /etc/runit/2, which sets the runlevel mode (single-user or default multi-user), creating the appropriate symlinks to start the enabled services for the runlevel mode.
These scripts also access /etc/rc.conf and /etc/rc.local, shown below, which are also human readable.
# /etc/rc.conf - system configuration for void # Set the host name. # # NOTE: it's preferred to declare the hostname in /etc/hostname instead: # - echo myhost > /etc/hostname # #HOSTNAME="void-live" # Set RTC to UTC or localtime. #HARDWARECLOCK="UTC" # Set timezone, availables timezones at /usr/share/zoneinfo. TIMEZONE=America/New_York # Keymap to load, see loadkeys(8). KEYMAP=us # Console font to load, see setfont(8). #FONT="lat9w-16" # Console map to load, see setfont(8). #FONT_MAP= # Font unimap to load, see setfont(8). #FONT_UNIMAP= # Amount of ttys which should be setup. #TTYS=
# Default rc.local for void; add your custom commands here. # # This is run by runit in stage 2 before the services are executed # (see /etc/runit/2).
The messages that appear on the console during boot are clearly implemented from these scripts.
Runit is certainly simple and transparent, but in my experience it doesn't seem as capable and as trouble-free in the context of desktop/laptop use as systemd. For example, often the system seems to hang when attempting to reboot, where the process starts, displaying the console messages and then gets stuck forcing me to use the power button. As another example, consider that systemd can make a distinction between system-wide services and per-user services. I recently discovered this was possible when setting up mpd on a recent Sabayon installation.
While runit's method of manually symlinking files to enable a service is transparent to the user, I found the default behavior of starting a service immediately after enabling it to be problematic for me when switching display managers. There doesn't seem to be a way to switch display managers in Void such that the new display manager is in effect on the next boot without causing the display manager to restart immediately -- interrupting the session -- with the available methods described on the Void Wiki:
|runit service management command||Result|
# touch /etc/sv/sddm/down
|to prevent the sddm display manager from automatically starting|
# ln -s /etc/sv/sddm /var/service/
|to enable the sddm service|
# rm /var/service/lxdm
|to disable the lxdm service|
When switching from lxdm to sddm, if the symlink enabling lxdm is removed first, this breaks the session without any graphical login on the next boot. If the sddm service is enabled first, this causes a conflict and also immediately causes an unstable session with what looks like the display alternating between two sessions, one on a console and one with the existing desktop session. If the "down" file is created first to prevent the display manager from starting automatically, the sddm service enabled second, the lxdm service disabled third, then on next boot there would be no display manager. When I tried to switch from lxdm to sddm, the result was conflicting display managers and I had to power off then boot into recovery mode and prevent lxdm from automatically starting by creating the file that prevents a service from automatically starting -- for the lxdm service /etc/sv/lxdm/down -- and later remove the enabling symlink. With systemd however, this would be possible with a simple:
# systemctl disable lxdm && systemctl enable sddm
such that the system uses sddm beginning with the next boot without interfering with the current session by restarting the display manager or without having conflicting display managers.
Also, consider the fact that in systemd systems, suspending and hibernating, including hybrid suspending, work without issues and reliably. In Void Linux, which relies on the zzz and ZZZ scripts, these features also work on the command line, maybe except hybrid suspend. However, when used in conjunction with acpid events monitoring, such as lid close, they don't work as they should. When the lid is opened, a blank screens is shown with the X Window System drawn pointer, then the previous state of the screen is displayed dimly momentarily, the screen flickers, then the lockscreen is displayed. I have never seen this type of erratic behavior in my current "daily driver" installations on the primary SSD of my Acer Nitro -- Sabayon and Manjaro -- which both use systemd.
The other significant unique feature in Void is its package management system which consists of the XBPS (X Binary Package System), Void's custom developed binary package manager and its companion source package manager and build system xbps-src. 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. Unlike Arch, but like Debian, it splits its capability among different commands, among which are 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 adequate, 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'.
However, XBPS still requires users to be adept at various UNIX utilities for some 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.
The complement to Void's XBPS is xbps-src, the package build system and source package manager. This is one of the standout features of Void and the feature that prompted me to try Void. Nearly all Void users will 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 such as Google Chrome and Adobe Flash for NPAPI browsers. The process required to prepare the system for this use are described in Void Linux 20171007 Review Supplement: Required Fixes and Enhancements.
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. I can't address its technical strengths as do some champion's of Void Linux, but I did appreciate xbps-src's flexibility and ease of use in building and installing third party software. Unfortunately, the success in building and installing third party apps using this Void tool depends on related aspects of Void to be working and maintained. This wasn't the case in my experiments building Firefox Developer Edition and Opera Developer as described in Void Linux: Creating Binary Packages Using xbps-src.
Some examples of basic xbps-src usage is given below in Package Management.
Void offers several methods of installing the OS. Live ISOs featuring one of several desktop environments are available, each including the simple and effective, yet not bug free, void-installer ncurses type program. A notable feature of the live ISOs is that users can choose to install the system from packages included on the ISO or from a network source, avoiding the need to perform an upgrade after installation, although there is a warning on the Void Linux Download Page
PLEASE NOTE: To install the desktop environment, DON’T choose “install from network” choose the local install. VERY IMPORTANT!
|Architecture||x86, x86_64, ARMv6, ARMv7|
|Installation Types||void-installer program on Live ISOs, chroot|
|Desktop Environments||Enlightenment, Cinnamon, LXDE, LXQt, Xfce, Plasma, Lumina, Gnome, Budgie|
|ISO Environments||Enlightenment, Cinnamon, LXDE, LXQt, Xfce,|
|above ISOs at https://repo.voidlinux.eu/live/current/|
|above ISO at https://repo.voidlinux.eu/live/20170825/|
Necessary Fixes and Enhancements
The issues I encountered and the solutions, in instances where I was able to solve them, are described on Void Linux 20171007 Review Supplement: Required Fixes and Enhancements.
All three ISOs I used include little or no useful software by default. Of the three Xfce has the most, including Firefox-ESR, Parole Media Player, Ristrestto Image Viewer, Mousepad, Orage Calendar, Orage Globaltime, Xfce Terminal, and Thunar. Enlightenment and LXQt have the least, both offering Firefox-ESR, and some native system utility applications, Terminology and Enlightenment File Manager in the case of the Enlightenment ISO, and PCmanFM, Qterminal, and Q Image Viewer, and a screenshot tool. All three ISOs install the LXDM display manager.
Despite the lack of software provided by the installer, software availability in the Void repos is good. I was able to find some software that is typically is not found in larger distributions, such as the Kvantum theme engine for Plasma, which is not available in the normal repositories of Fedora, openSUSE, or Sabayon; glances, which is not available from the normal repositories of Sabayon or openSUSE; and tlp, which is not available from Sabayon, without using their relatively new, yet apparently defunct by lack of maintenance, SCR which will destabilize the system.
But there was one piece of software that I missed, Kmail, which I recently rediscovered as it is included in the KDE Spin of Fedora. Void maintains the KDE 4.14 of Kmail, included in the kdepim package for KDE 4. When I asked about this in the Void Forum, I received a quick response indicating that nobody uses it, thus it is not packaged for Plasma 5 and that it would require a rebuild of all Plasma packages, but that it would be available the next day. It has been a week, but still no Kmail for Plasma 5. Even a template is not available in Void's GitHub source repository, in order to build and install it using xbps-src.
And, most importantly for reliability in a rolling distribution, older kernels and their corresponding headers and modules are not removed from the repositories or from the installed system. If some software breaks on a major kernel update, which typically happens with VMware Workstation, users have the option of using an older kernel that exists on the system or installing an older kernel that is available in the repos.
Package management is performed using the custom XBPS (X Binary Package Management System), a program that seems to be inspired by Arch's Pacman, but with some extended functionality. Even with some more built in functionality it is still missing some capability of more mature package managers as mentioned in the Review, above. Some examples of XBPS usage is presented in the following table.
|xbps-install||install, reinstall, and update packages||xbps-install -Syy synchronizes remote repsository
xbps-install -S kate synchronizes remote repsository and installs kate
xbps-install okular gwenviewinstalls okular and gwenview
|xbps-query||query package and repository information||xbps-query -R okularshows information for package okular in repository mode
xbps-query -R -s ffm lists packages with metadata that matches the pattern "ffm"
xbps-remove -R okular uninstalls okular and recursively its dependencies
xbps-remove -o removes all orphan packages
|xbps-reconfigure||configure or reconfigure packages||xbps-reconfigure evolution configure evolution
xbps-reconfigure -f evolution force (re)configuration of evolution
|xbps-pkgdb||repair and manage package database||xbps-pkgdb -a check for errors in installed packages|
|xbps-rindex||manage local repositories||xbps-rindex -a /home/brook/local-repo/*.xbps create local repo at /home/brook/local-repo|
|xbps-alternatives||manage package alternatives|
Some screenshots depicting XBPS in use are presented below.
Void users will also need to use the Xbps-src build system to install some proprietary software that is only distributed by Void as source packages. Void Linux 20171007 Review Supplement: Required Fixes and Enhancements provides the process for preparing the system to use the Void source repository, briefly:
xbps-install xtools git clone https://github.com/voidlinux/void-packages
and installing Google Chrome:
$ cd void-packages $ ./xbps-src pkg google-chrome $ sudo xbps-install --repository=hostdir/binpkgs/nonfree google-chrome.
These processes and the installation of Adobe Flash for NPAPAI Browsers are described in Void Linux 20171007 Review Supplement: Required Fixes and Enhancements. xbps-src usage for building third party software is described in Void Linux: Creating Binary Packages Using xbps-src
Documentation and Help
Void Linux offers its user's clear instructions for downloading and verifying the installation media, which is not always the case with some distributions. It also offers documentation in the form of a Wiki, which although not extensive by any means, is just enough to help users get started successfully. It also provides a detailed manual for using xbps-src in addition to a Wiki page on this subject.
Void also provides a well designed and modern forum platform, with automatic weekly summary email subscription and updates to responses to posts. As I mentioned in Void Linux 20171007 Review Supplement: Required Fixes and Enhancements, I found a solution to one crucial problem very quickly in existing posts. I also received responses to questions I asked very quickly, one response with a solution regarding the upower problem, and one promising a resolution to my issue -- the lack of a Kmail binary package for Plasma 5.
When I decided to install Void Linux on the secondary hard drive of the Acer V15 Nitro, I had high hopes that with its flexible source package manager and high performance derived from its minimalist nature, I had found a distribution I could use long term and grow into, replacing Sabayon on the primary SSD, as a distribution designed from the beginning with hybrid package management in mind. It is true that the performance is subjectively very good, with fast boot time and high level of responsiveness that rivals the distributions installed on the SSD.
But, from a purely practical, not philosophical perspective, I found runit lacking in reliability and capability compared to systemd, forcing me to give up on the notion of replacing one of the semi-permanently installed distributions on the primary SSD. I will, however, return to Void later when a new ISO is released to further experiment with its excellent build system.