Void Linux 20171007 Review

Introduction

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!

Network Manager Applet Hidden by Default in Xfce Live ISO

I have no idea why the NetworkManager service would be enabled but the Network Manager Applet be hidden.

Review

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.

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.

runit

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.

# /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).

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:

# touch /etc/sv/sddm/down

# ln -s /etc/sv/sddm /var/service/

# rm /var/service/lxdm

# systemctl disable lxdm && systemctl enable sddm

The contents of /var/service

Services are enabled by creating symlinks to files in /etc/sv at /var/service.

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.

XBPS

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'.

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

xbps-src

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.

Quick Facts

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!

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.

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

$ cd void-packages
$ ./xbps-src pkg google-chrome
$ sudo xbps-install --repository=hostdir/binpkgs/nonfree google-chrome.

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.

Recommendation

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.