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.
Some time after using the Enlightenment based installation and having installing Plasma and resolving numerous
issues and enhancing the usability of the system, 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.
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.
Review
In all three installations, I had to 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.
The installation experience is described fully in the supplement to this article, Void Linux 20171007 Review Supplement: Installation.
Enlightenment (Default Theme)
Void includes Enlightenment's connman and EConnMan, and doesn't try to force non-native components, such as a NetworkManager applet or system tray in the Enlightenment installation. The Voidl Linux and Enlightenment
combination makes a very lightweight system.
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.
Void LXQt
The LXQt live ISO was the worst of the three Void live ISOs I used.
The other issues I discovered affecting all installations, discussed on 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.
Some of the Files Used by runit
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 Commands
| 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.
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'.
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)
.
Using Bash and UNIX Utilities to Augment XBPS Capability
When uninstalling the Xfce meta package left some Xfce packages, I had to combine some XBPS commands and
UNIX utilities and Bash concepts to remove all packages matching the string "xfce".
Other features and usage examples of XBPS are given below in Package Management.
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.
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 xbps-src usage is given below in Package
Management.
Software
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
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 Commands
| XBPS Command |
Function |
Examples |
| 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 |
uninstall packages |
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.
Using XBPS
On the surface XBPS is very similar to Arch and derivatives' pacman, however it is very different.
Image 1: The four stages of an XBPS transaction - 1) Download all packages 2) Verify signature of each package 4) Unpack package files 4) Configure packages
Image 2: Updating - The initial output when starting an update provides information on packages to be updated.
Image 3: Using xbps-query. The first xbps-query execution is in local mode and the second is in
repository mode.
Image 4: Installing a Package - Installing ffmpegthumbnailer and ffmpegthumbs.
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. This can be done by, 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.
xbps-src usage for building third party software is described in Void Linux:
Creating Binary Packages Using xbps-src
