For Linux people · the system underneath
Why Void.
Void Linux has been going since 2008, when Juan Romero Pardines, a former NetBSD developer, started it as a test bed for a new package manager. It is not based on Debian, Arch or anyone else: it has its own package manager and its own build system, and it uses runit instead of systemd. What you get is a rolling release that is fast, small, and simple enough to understand all the way down.
Boots in seconds, and you can read all of it.
Void uses runit instead of systemd. Starting the system is three short shell stages; after that, runit keeps each service alive. There are no unit files, no journal format, no dependency graph to debug.
A package manager built for this system.
xbps was written from scratch for Void, and it is fast and plain. Every package records which shared libraries it needs, and xbps checks the whole update first: if it would leave a program without a library, xbps stops before changing anything.
sudo xbps-install -Su # update all xbps-query -Rs ripgrep # search
New versions, no release upgrades.
Void is a rolling release, so there is never a big-bang upgrade to a new version of the distribution. But it aims for stability, not the bleeding edge: packages follow upstream's real releases, never betas or development snapshots. Kernels come as series packages, such as linux6.12, so you choose when to move.
One repo, built in the open.
Every package is a short template in void-packages on GitHub, built by xbps-src in a clean container, without root. You can build any package yourself the same way, and cross-compile it for ARM from your laptop.
Two C libraries, both official.
Void is one of the few distributions with official binary repositories for both glibc and musl: glibc on x86_64, i686, aarch64 and 32-bit ARM, and musl on all of those except i686. Vikix uses glibc, for the widest range of software.
You start with very little.
A fresh Void install is a shell, a network and a package manager. Nothing runs that you didn't ask for. That makes it a good floor to build a desktop on, which is exactly what Vikix does.
How a service works on Void
A service is a folder with a script in it.
Each service in /etc/sv/ has a run script that starts the program in the foreground. To switch a service on, link its folder into /var/service/. runit notices within seconds and starts it. To switch it off, remove the link.
That is the whole model. You can learn it in a coffee break, and when something goes wrong, the thing to read is a five-line shell script.
# the sshd service, complete $ cat /etc/sv/sshd/run #!/bin/sh exec 2>&1 ssh-keygen -A >/dev/null 2>&1 [ -r conf ] && . ./conf exec /usr/bin/sshd -D $OPTS # switch it on, check it, switch it off $ sudo ln -s /etc/sv/sshd /var/service/ $ sudo sv status sshd run: sshd: (pid 842) 12s $ sudo rm /var/service/sshd
For Linux people · the neighbours
Void and the other rolling releases.
Arch, openSUSE Tumbleweed and Gentoo are all good systems. Void makes different choices: fewer moving parts, one official repository, and a package manager that checks libraries before it changes anything.
| Void | Arch | openSUSE Tumbleweed | Gentoo | |
|---|---|---|---|---|
| INIT | runit: a few shell scripts, and a folder per service | systemd | systemd | OpenRC, or systemd |
| PACKAGES | xbps, written for Void | pacman | zypper and RPM | Portage, built on your machine; an optional binary host |
| EXTRA SOFTWARE | All in one official repo, reviewed as pull requests. Software that may not be redistributed is built locally with xbps-src. |
The AUR: build scripts anyone can upload. You read each one, or trust a helper to. | Community projects on the Open Build Service | Overlays |
| UPDATE SAFETY | xbps tracks the shared libraries each package needs, and stops an update that would break one | Partial upgrades are unsupported: update everything at once, and read the news first | Snapshots tested by openQA; roll back with Btrfs and Snapper | Portage resolves and rebuilds what depends on a changed library |
| C LIBRARY | glibc or musl, both with official binary repos (musl on all but i686) | glibc | glibc | glibc, or musl profiles |
| ARCHITECTURES | x86_64, i686, aarch64, armv6, armv7 | x86_64 (others are separate ports) | x86_64, plus ports | Many |
| FEEL | Small, quick, and quiet. It stays out of your way. | Huge community, and the best wiki in Linux | Polished and tested, with company backing | Total control, if you have the time |
Where Arch is ahead
More software, through the AUR, and many more users writing guides. The Arch Wiki is excellent, and most of it applies on Void too. If a package you need exists only in the AUR, that matters.
Where Void is ahead
No init system to learn, no third-party build scripts to trust, no AUR helper. Updates are one xbps transaction that checks libraries first. And the whole system is small enough to hold in your head.
Why that suits a desktop layer
A layer like Vikix has to change the system in ways it can repeat and check. On Void that is plain: install from lists, link a service folder, drop a file in /etc/xbps.d/. Each Vikix stage does exactly that, and nothing clever.
And on top of it
Vikix: the desktop that explains itself.
Every change Vikix makes to Void is one of the plain steps above, in a bash stage that checks before it changes anything, so running it twice is safe and --dry-run prints every change instead of making it. How it fits together has the stages one by one.