Void Linux and Artix — Quick Takes

Void Linux and Artix Linux occupy a specific corner of the Linux world: both are rolling-release, both reject systemd, and both reward users who want to understand what their init system is actually doing. That shared philosophy aside, they are quite different projects with different goals, package managers, and default experiences. This guide cuts through the surface-level comparisons and gives you concrete, operational knowledge of each.

Void Linux

Void is an independent distribution — not based on Debian, Arch, or anything else. It was started in 2008 by Juan Romero Piedra and maintains its own package manager, its own ports-style build system, and runit as the default init. It ships musl libc and glibc variants, which is unusual and occasionally relevant when you run proprietary software.

XBPS: the X Binary Package System

XBPS is Void's native package manager. It is fast, dependency-aware, and once you know the half-dozen commands you need daily, it stays out of your way.

Synchronize the remote repositories and upgrade all installed packages:

sudo xbps-install -Su

Search for a package by name or description:

xbps-query -Rs firefox

Install one or more packages:

sudo xbps-install -S mpv git neovim

Remove a package and any orphaned dependencies it pulled in:

sudo xbps-remove -Ro mpv

Show what files a package owns, or which package owns a specific file:

xbps-query -f mpv
xbps-query -o /usr/bin/mpv

The xbps-query -Rs command searches both installed packages and the remote index. Use -s alone to search only locally installed packages. One common trip-up: XBPS separates development headers into -devel subpackages, so if a ./configure or meson build complains about missing headers, add the -devel variant of whatever library is missing.

runit on Void

Void uses runit as its init system and service supervisor. The design is deliberately minimal: stage 1 sets up the kernel environment, stage 2 runs runsvdir which watches /var/service/, and stage 3 handles shutdown. Every enabled service is simply a symlink in /var/service/ pointing to a service directory under /etc/sv/.

Enable a service (symlink it into the active service directory):

sudo ln -s /etc/sv/sshd /var/service/

The service starts automatically the moment the symlink is created — no separate enable/start step. Disable it by removing the symlink:

sudo rm /var/service/sshd

Control a running service with sv:

sudo sv status sshd
sudo sv restart sshd
sudo sv stop nginx

List the status of every supervised service at once:

sudo sv status /var/service/*

Each service directory contains at minimum a run script. Many also have a log/run script that pipes stdout to svlogd, Void's built-in structured logger. Logs land in /var/log/SERVICE_NAME/current by default. If a service keeps crashing, read that file first before reaching for anything else.

Who Void is actually for

Void suits users who want an independent rolling release that is not Arch, who are comfortable at the command line, and who genuinely prefer a supervisor-based init over systemd. The musl variant is interesting for container base images and embedded use. The package repository is smaller than Arch's combined official + AUR ecosystem, so if you depend on obscure software you may end up writing your own void-packages template. That process is well-documented and approachable, but it is real work.

Artix Linux

Artix is a fork of Arch Linux that replaces systemd with a choice of init systems: OpenRC, runit, s6, or dinit. If you already know Arch, almost everything transfers directly — pacman, the ABS build system, PKGBUILDs, the wiki. You are trading the Arch default init for something else, with minimal friction everywhere else.

pacman on Artix

Artix uses pacman with its own repositories plus optional access to the Arch repositories and the AUR. The base pacman commands are identical to Arch:

sudo pacman -Syu          # sync and upgrade
sudo pacman -S htop       # install a package
sudo pacman -Rs htop      # remove with unused deps
pacman -Ss "screen recorder"  # search

To enable the Arch Linux repositories (for packages not yet mirrored in Artix), install the bridge packages and uncomment the relevant sections in /etc/pacman.conf:

sudo pacman -S artix-archlinux-support

Then append the Arch repos to /etc/pacman.conf. This gives you access to the vast Arch binary repository. AUR helpers like yay or paru compile and install from community-maintained PKGBUILDs and work without modification on Artix.

OpenRC on Artix

OpenRC is the most popular init choice on Artix and the one most familiar to people coming from Gentoo, Alpine, or older Funtoo installs. It uses dependency-based service startup and organises services into runlevels.

Enable a service so it starts at boot:

sudo rc-update add sshd default

Start, stop, or restart a service immediately:

sudo rc-service sshd start
sudo rc-service sshd restart
sudo rc-service sshd status

List all services and their current state:

rc-status

OpenRC service scripts live in /etc/init.d/. They are shell scripts that source /lib/rc/sh/openrc-run.sh and define start(), stop(), and optionally depend() functions. Writing a new one is straightforward if you have ever written a shell function. The depend() function is where you declare ordering relationships — equivalent to systemd's After= and Requires=.

runit on Artix

If you install the runit variant of Artix, the mechanics are nearly identical to Void. The active service directory is /run/runit/service/ and available service definitions live in /etc/runit/sv/. Enable a service:

sudo ln -s /etc/runit/sv/sshd /run/runit/service/

Control it with sv, same as on Void. The path difference is the only meaningful change.

Who Artix is actually for

Artix is the practical choice if you want to leave systemd but do not want to leave the Arch ecosystem. You keep pacman, the AUR, and the Arch wiki as a reference. You pick the init system you prefer at install time. The tradeoff is that some AUR packages have service files written only for systemd; you will occasionally need to write or adapt an OpenRC or runit script yourself. This happens less often than you would expect for mainstream software, but it is a real operational cost for anything niche.

Side-by-Side Comparison

Feature	Void	Artix
Base	Independent	Arch fork
Package manager	xbps	pacman
Default init	runit	OpenRC, runit, s6, or dinit
libc options	glibc and musl	glibc only
AUR access	No (xbps-src templates instead)	Yes
Release model	Rolling	Rolling
Installer	CLI only (live ISO)	CLI and calamares

Verification

After installing either distro, confirm your init is running and services are healthy before you rely on the system:

On Void (runit):

sudo sv status /var/service/*

On Artix with OpenRC:

rc-status --all

Any service showing down or crashed in runit, or stopped in OpenRC when it should be running, warrants immediate investigation via its log directory or rc-service NAME status respectively.

Troubleshooting

XBPS: "broken dependencies" during upgrade

A partial sync can leave the local index inconsistent. Force a full reindex before the upgrade:

sudo xbps-install -S && sudo xbps-install -u

runit service stuck in a restart loop

runit restarts a service that exits almost immediately. Add a brief sleep to the run script, or check /var/log/SERVICE/current for the real error. If you need to disable a crashing service quickly, create a file named down in the service directory:

sudo touch /etc/sv/problematic-service/down
sudo sv down problematic-service

OpenRC on Artix: service starts but crashes after login

Check whether the service depends on a network or filesystem service that starts after it. Add the dependency explicitly in the init script's depend() block, or use rc-update add SERVICE in the default runlevel rather than sysinit.

Artix + Arch repos: package conflicts

Some Arch packages pull in systemd as a hard dependency (e.g., packages that require libsystemd). Artix ships elogind as a drop-in for session management and stub libraries for libsystemd compatibility. If a package refuses to install, check whether an artix-prefixed replacement exists in the Artix repos before installing the upstream Arch version.