This episode traces the origins of Void Linux, founded in 2008, the philosophy of stability, simplicity, and rolling release, and the reasons why Void chose runit, XBPS, and dual glibc-musl support. You will understand Void's unique position in the Linux distro ecosystem.

Before building something, it's important to know where it comes from. Episode 1 takes you into the history and philosophy of Void Linux: why it was made, who founded it, and which design decisions make it different from other distros. This understanding isn't just trivia — it explains almost every technical decision we'll put into practice in the following episodes.
Void isn't a derivative of Arch, Debian, or the Red Hat family. It's an independent distro that develops its own tooling. The combination of rolling release, the runit init system, and the XBPS package manager is what defines Void's identity.
Let's start from the very beginning of Void Linux.
Void Linux was founded in 2008 by Juan Romero Pardines, known by the handle xtraeme. Void initially grew from his personal desire to have a distro with full control over the system — especially in the area of package management. Pardines was an experienced contributor in the NetBSD ecosystem, and that experience shaped Void's technical style: simple, transparent, and avoiding unnecessary complexity.
After Pardines stepped down from development in 2019, Void has been maintained by a community that still actively maintains the distro to this day. Rolling release means Void has no release versions, so the community always works on a single package tree that keeps moving forward.
Another hallmark of Void's development model is the balance between the agility of rolling release and careful testing. New packages don't go straight into the current repository; they go through review by maintainers, including dependency testing and compatibility checks between packages. This is why upgrading Void feels calmer than most rolling releases.
What sets Void apart from most distros is its independence. Void is based on neither Arch nor Debian. All core tooling is developed in-house within its own ecosystem:
XBPS : native package manager (X Binary Package System)
runit : init system and service supervision
xbps-src : build system to compile packages from source
void-packages : package template repositoryThis independence means every design decision is made based on Void's needs, not by following in the footsteps of other distros.
Void's philosophy can be summarized in three words: stability, simplicity, and user control. Rolling release is usually synonymous with instability, but Void handles it with a careful policy — packages in the current repository aren't pushed blindly; they're tested by maintainers and the community.
Simplicity is reflected in runit's design: a service is just a directory with a run script, not a unit file with a dozen options. User control means there are no hidden layers — you know exactly what service is running, how it's run, and why.
Void is one of the major distros that consistently refuses systemd. This decision isn't just a battle of opinions, but a design choice: runit is smaller, simpler, and offers always-on process supervision. For those of you who want to understand a Linux system from the most basic layer, the absence of systemd is actually a learning advantage.
Void adopts the rolling release model: you're always on the latest version of packages without needing a big upgrade between releases. No more upgrade rituals from version 1 to version 2. All you need to do is a routine upgrade:
sudo xbps-install -SuThe xbps-install -Su command syncs the repositories and then upgrades all packages. Because packages are tested before entering the repository, routine upgrades rarely break the system.
Void is the only mainstream distro that provides glibc and musl in a single repository ecosystem. During installation, you choose which flavor to use:
ldd --version | head -n 1For glibc systems, the ldd --version command shows the glibc version. This flexibility is rarely found in other distros, and we'll explore it fully in episode 6.
XBPS is designed specifically for Void, so its integration with repositories and key signing is very tidy. The community is indeed smaller than Arch or Debian, but it's active on forums, IRC, and Matrix. The official documentation at docs.voidlinux.org is also concise and dense — perfect for those of you who like reading primary sources.
To be honest, Void isn't for everyone. If you need vendor enterprise support, a complete repository of commercial applications, or a large support team in the office, a Debian, RHEL, or SUSE-based distro might make more sense. Void's small user base also means some niche applications must be built yourself with xbps-src.
But this is exactly where Void's learning value lies: those shortcomings force you to understand the system, not just execute commands. Those skills are portable and will stay useful even if you later return to another distro.
After you successfully boot into an installed Void system, you can verify the distribution's identity directly from the shell:
cat /etc/os-release
head -n 1 /etc/issueThe /etc/os-release output shows ID=void and an empty ID_LIKE= — a sign that Void doesn't claim similarity to any distro. This is concrete proof of Void's independent status that we discussed.
One way to appreciate how lean Void is by counting the number of packages installed on a default installation:
xbps-query -l | wc -lOn a minimal server installation, the count is usually far lower than mainstream distros with equivalent features. The xbps-query -l command makes for an interesting comparison when you compare Void with other distros in episode 22.
Episode 1 gave you an understanding of Void Linux's origins: founded in 2008 by Juan Romero Pardines as an independent distro, built on XBPS, runit, and xbps-src, with the philosophy of stability, simplicity, and user control. You also know why Void is worth learning — rolling yet stable, no systemd, and dual glibc-musl support.
Key takeaways:
In the next episode, episode 2, we will discuss core concepts and main architecture — how the kernel, libc, runit as PID 1, and XBPS work together, plus the role of each XBPS component such as xbps-install, xbps-query, xbps-remove, and xbps-reconfigure. This is the architectural foundation that will become the main language of the whole series.