Void Linux
Void Linux is an independent, general-purpose Linux distribution developed entirely by volunteers, based on the monolithic Linux kernel and designed as a stable rolling release system rather than a fork of any existing distribution.[1] It emphasizes simplicity, performance, and user control, utilizing the XBPS package manager for handling binary packages and source builds via xbps-src, while supporting both the GNU libc and the lightweight musl libc implementations.[1] Unlike many mainstream distributions, Void employs the runit init and service supervision system instead of systemd, providing a minimalist and dependency-light alternative for system initialization.[2] The project originated in 2008 with the initial Git import of its package repository by Juan Romero Pardines, a former NetBSD maintainer, who developed the XBPS package manager as a core component to enable efficient software management without relying on external tools like RPM or Debian's formats.[3] Key milestones include the addition of musl libc support in 2013, a switch from systemd to runit in 2014 for greater modularity, and full aarch64 architecture support by 2015, reflecting its commitment to cross-platform compatibility and security-focused choices like LibreSSL and later OpenSSL integrations.[2] As of 2025, Void offers its general-purpose distribution for everyday use and the Enterprise Edition, launched in April 2025 and tailored for business-critical applications such as data centers and cloud environments, with a community-driven ecosystem that includes thousands of packages available in its repositories.[4][1] Notable for its avoidance of bloat and focus on stability over bleeding-edge features, Void Linux appeals to users seeking a customizable, efficient operating system suitable for desktops, servers, and embedded devices.[5] Its volunteer-led development model fosters ongoing contributions through GitHub repositories and forums, ensuring regular updates while maintaining a reputation for reliability in diverse hardware environments.[1]History
Founding and early development
Void Linux was founded in 2008 by Juan Romero Pardines, a former NetBSD developer known online as xtraeme, with the primary goal of serving as a testbed for the XBPS package manager that he had begun developing.[6][7][8] Pardines, drawing from his experience maintaining packages in NetBSD, sought to create a dedicated environment to refine XBPS without dependencies on existing Linux distributions. This initiative marked the project's roots in fostering an original package management approach tailored for efficiency and portability. The design of XBPS and its companion build system, xbps-src, was influenced by NetBSD's pkgsrc framework and the broader BSD ports collections, which prioritize source-based package construction for flexibility across systems.[6] Early efforts emphasized reproducibility, leading to the development of xbps-src as a tool for compiling packages from source within isolated chroot environments to minimize contamination and ensure clean builds.[9] The project's inaugural Git repository, void-packages, was imported on September 26, 2008, establishing the foundation for the source packages collection. This was soon followed by the initial import of the core XBPS repository on August 17, 2009, enabling the first practical implementations of the package system.[2] From the outset, Void Linux differentiated itself by pursuing a lightweight and fully independent structure, avoiding reliance on binaries or infrastructures from major distributions such as Debian or Arch Linux. Instead, it was constructed from the ground up by a volunteer community, prioritizing minimalism and self-sufficiency in its core components.[10][1] This approach allowed for rapid iteration during the formative years, with a focus on core utilities and a rolling release model that would later incorporate alternatives like the runit init system. By the mid-2010s, these elements had solidified Void's identity as a distinct, volunteer-driven Linux distribution.Recent developments
In May 2018, the Void Linux project underwent a significant infrastructure relocation following the disappearance of its founder and lead developer, Juan Romero Pardines, which led to loss of access to the original GitHub organization and domain controls due to serious operational issues. The community responded by migrating to a new GitHub organization under void-linux and securing alternative domain arrangements to ensure continuity, allowing development to proceed without interruption.[11] The unofficial PowerPC port discontinued support in early 2023, while Void Linux officially discontinued the mini flavor for container images to streamline maintenance efforts. This decision focused resources on more actively maintained platforms like x86_64 and ARM, reducing the burden on a volunteer-driven team while preserving core functionality for primary users.[12][13] In May 2024, Void Linux achieved the highest ranking among Linux distributions on DistroWatch based on user reviews, attaining a score of 9.26 out of 10, reflecting strong community appreciation for its stability and performance. The project continued to leverage its XBPS package manager and expanded musl libc support in subsequent updates.[14] Enhanced ARM64 support was introduced in the February 2025 image release, emphasizing compatibility with ARM devices such as Raspberry Pi models and Apple Silicon hardware through arm64 UEFI live ISOs for both glibc and musl variants. On April 1, 2025, the community issued a satirical announcement for "Void Linux: Enterprise Edition," poking fun at corporate Linux adaptations with exaggerated features like premium support and ROI optimization, underscoring the project's lightweight, independent ethos.[15][4] In June 2025, the project released XBPS 0.60, featuring fixes for package updates in unpacked states, memory leaks, dependency resolution improvements, and a new staging flag for using staged packages.[16]Technical features
Init and service management
Void Linux employs runit as its default init and service supervision system, a choice made since switching from systemd in July 2014 to prioritize simplicity and independence from complex dependencies.[2] Runit serves as a lightweight, dependency-free process supervisor that replaces traditional init systems, enabling reliable management of daemons and services without the overhead of more monolithic alternatives.[1][17] This approach aligns with Void's philosophy of minimalism, allowing compatibility with alternative C libraries like musl while maintaining a small codebase that facilitates auditing for bugs and security issues.[5] The boot process in Void Linux follows runit's three-stage structure, executed as process ID 1 (PID 1). In stage 1, runit runs the script/etc/runit/1 to perform basic system initialization tasks, such as setting up the console and essential devices; if this stage fails critically (exiting with code 100), the system skips to shutdown without starting services.[18] Stage 2 executes /etc/runit/2, which typically launches runsvdir to supervise services defined in /var/service, continuing until a shutdown signal is received; this stage handles ongoing system operation and restarts itself on certain failures (exit code 111).[18] Finally, stage 3 invokes /etc/runit/3 for cleanup and shutdown procedures, such as unmounting filesystems, followed by halting or rebooting based on the presence of specific files like /etc/runit/reboot.[18] This staged design ensures a clean, predictable boot sequence with minimal interference, promoting stability in diverse hardware environments.
Service management under runit is handled through directory-based configuration in /etc/sv, where each service resides in a subdirectory containing an executable run script that defines how to start the daemon.[17] To enable a service, administrators create a symbolic link from the service directory to /var/service, allowing runit's supervisor (runsv) to automatically start and monitor it; for example, enabling the DHCP client involves linking /etc/sv/dhcpcd to /var/service/dhcpcd.[17] Services can be controlled dynamically using the sv utility—for instance, sv up <service> starts it, sv down <service> stops it, and sv status <service> checks its state—while disabling requires removing the symlink or adding a down file to the service directory.[17] Each service runs in a clean process environment with dedicated logging via a companion log service, ensuring that logs persist as long as the main process is active, which simplifies troubleshooting.[17]
Runit's design emphasizes lightweight operation, with its compact implementation contributing to faster boot times and reduced resource usage compared to init systems that centralize extensive functionality in PID 1.[17][10] The separation of service supervision from the init process also eases debugging, as individual services can be isolated and inspected without affecting the core boot mechanism, avoiding the complexities often associated with dependency-heavy systems.[17] For desktop environments requiring systemd-specific features like session tracking, Void integrates elogind, a standalone extraction of systemd's logind component, which manages user sessions, power events, and D-Bus interactions independently of runit.[19] Installing the elogind package and enabling its service (along with system D-Bus) provides compatibility layers for tools like GNOME or KDE, ensuring seamless operation without adopting systemd fully.[19]
Package management system
Void Linux employs the X Binary Package System (XBPS), a package manager developed from scratch by the Void Linux team to handle binary packages efficiently.[20] XBPS supports installation, updates, and removal through dedicated commands such asxbps-install, xbps-query, and xbps-remove, while incorporating built-in integrity checks using SHA256 hashes to verify package contents and detect issues like missing files or unresolved dependencies.[20] Additionally, it enforces cryptographic verification via RSA signatures on remote repositories, ensuring package authenticity and preventing tampering.[21]
Complementing XBPS is the xbps-src tool, which facilitates source-based package building in a clean chroot environment to isolate the process and maintain system hygiene.[9] This setup promotes full reproducibility, with features like the --reproducible flag in xbps-install enabling deterministic builds by standardizing timestamps and other variables.[22]
The package ecosystem adopts a hybrid binary/source model tailored for Void Linux's rolling release cycle, where users can synchronize the system via xbps-install -Su to fetch the latest binaries.[20] Updates operate atomically through transactional mechanisms, ensuring that operations either complete fully or roll back entirely to avoid partial failures and maintain system stability.[21]
Default repositories include main for core open-source software, nonfree for proprietary components, multilib for 32-bit compatibility on 64-bit systems, and debug for debugging symbols, collectively offering over 10,000 packages as of 2025.[23][24]
Since April 2017, Void Linux has integrated Flatpak support directly into its repositories for both musl and glibc variants across all architectures, allowing seamless installation of third-party applications outside the XBPS ecosystem via xbps-install [flatpak](/page/Flatpak) followed by Flathub repository addition.[25]
Library and kernel support
Void Linux provides dual support for two implementations of the C standard library: the GNU C Library (glibc), which serves as the standard option for broad compatibility with existing software, and musl libc, a lightweight alternative designed for simplicity, standards compliance, and reduced resource usage.[26] This dual approach is facilitated by maintaining separate repositories for glibc and musl variants, ensuring that packages built against one library do not conflict with those using the other and allowing users to select based on their needs, such as portability or performance in constrained environments.[1] For instance, musl-linked binaries are available directly in official repositories alongside glibc versions, with developers patching upstream software to enhance musl compatibility where necessary.[26] In terms of cryptographic libraries, Void Linux defaulted to LibreSSL as its primary SSL/TLS implementation from 2014 until March 2021, when it switched back to OpenSSL to address challenges in maintaining LibreSSL.[2] The transition, effective March 5, 2021, was driven by difficulties in backporting security patches from upstream LibreSSL and replicating performance optimizations available in OpenSSL, which had become essential for modern applications.[27] This change minimized disruptions for most users while improving long-term maintainability and efficiency in handling cryptographic operations.[27] The distribution employs the standard monolithic Linux kernel without custom modifications by default, offering users flexibility through multiple kernel series available in its repositories.[1] These include long-term support (LTS) variants such as linux5.15 and linux6.6, as well as the latest mainline releases like linux6.12, allowing installation of specific versions via the package manager to suit stability or feature requirements.[28] Kernel packages are named according to their series (e.g., linux6.12), and users can query and switch between them seamlessly, with no proprietary or altered kernel provided out-of-the-box.[28] Void Linux supports cross-compilation for a range of architectures through its xbps-src build system, enabling the creation of packages for targets beyond the host machine.[9] Supported architectures include x86_64, i686, aarch64, armv6l, armv7l, and mips64el, with optimizations tailored for embedded systems such as ARM-based devices, where reduced footprint and static builds are prioritized.[9] This capability, powered by cross-compiler packages like cross-armv7l-linux-gnueabihf, facilitates development for diverse hardware without native environments.[29] The base system of Void Linux is designed to be minimal, prioritizing a small footprint and reduced dependencies through the encouragement of static linking, particularly when using musl libc.[26] Musl's architecture supports static compilation more readily than glibc, allowing binaries to be self-contained and portable across systems, which aligns with Void's philosophy of simplicity and efficiency in core components like the XBPS recovery tools.[30] This approach results in a lean installation that avoids unnecessary shared libraries, enhancing reliability in resource-limited setups.[31]Installation and configuration
Installation process
The installation of Void Linux typically begins with downloading an official live ISO image from the project's website, available in variants for different architectures (x86_64, i686, ARM) and C library implementations (glibc or musl).[32] Users select the appropriate ISO based on their hardware and preferences, such as musl for a lighter footprint or glibc for broader software compatibility. Verification of the download using checksums is recommended to ensure integrity.[33] To create bootable media, write the ISO to a USB drive or SD card. On Linux systems, identify the target device (e.g.,/dev/sdX for USB or /dev/mmcblkX for SD) using [fdisk](/page/Fdisk) -l, unmount it with umount, and use the dd command: dd bs=4M if=path/to/void-live-image.iso of=/dev/sdX status=progress && sync. This process erases all data on the device. On Windows, tools like Rufus can be used in DD Image mode to write the ISO to the USB drive. For CD/DVD media, burn the ISO using standard disk-burning software.[33]
Boot the system from the prepared media by entering the BIOS/UEFI settings (typically via F2, F10, or Del key) and selecting the USB or optical drive as the first boot device. Determine in advance if the system uses BIOS (legacy) or UEFI mode, as this affects partitioning: MBR for BIOS or GPT with an EFI partition for UEFI. Upon booting the live environment, log in as root with the default password voidlinux. If the system has sufficient RAM (at least 2 GB recommended), optionally load the image fully into memory by appending toram to the boot parameters in the GRUB menu for a faster installation process.[34]
Launch the ncurses-based installer by running void-installer as root. The interface guides through sequential steps: first, select the keyboard layout (e.g., us for QWERTY). Next, configure networking by choosing the primary interface; for wired connections, DHCP is automatic, while wireless requires entering the SSID, encryption type (WPA or WEP), and password—manual setup may involve wpa_supplicant and dhcpcd if needed. Select the package source as "Local" (using cached packages from the live image) or "Network" for online mirrors.[34]
Proceed to set the hostname (lowercase, no spaces), locale (glibc images only; musl lacks locale support), and timezone from predefined options. Enter and confirm the root password, then create a user account with username (default void), full name, password, and group memberships (default includes wheel, which requires enabling sudo separately). Select the target disk for bootloader installation—GRUB2 is the default, with an option for a graphical menu—or skip to "none" for manual setup later.[34]
Next, proceed to disk partitioning using the integrated cfdisk tool for manual setup. Create partitions as needed—for UEFI, include a 200 MB to 1 GB FAT32 EFI system partition mounted at /boot/efi; for BIOS, use an MBR or BIOS boot partition. After partitioning, assign filesystems (e.g., ext4 for root) and mount points via the installer's prompts, then confirm with "Done." The installer installs the base system, incorporating the runit init system. Review all settings, then initiate the installation, which formats filesystems, installs the base system packages, generates the initramfs, and configures the bootloader. Upon completion, shut down, remove the media, and reboot into the new system.[34]
For ARM devices like the Raspberry Pi, the process differs as pre-built rootfs images are provided instead of live ISOs with the installer. Download the compressed image (e.g., .img.xz) for the specific model (Pi 1/Zero: armv6l; Pi 2: armv7l; Pi 3/4/5: aarch64), verify it, and decompress with unxz. Flash to an SD card using dd if=image.img of=/dev/mmcblk0 bs=4M status=progress && sync. Insert the SD card, power on the device, and the root partition auto-expands on first boot. For serial console access (useful for headless setup), enable the UART via device tree overlays in /boot/config.txt (e.g., enable_uart=1) and connect a USB-to-TTL adapter; log in as root with password voidlinux. Post-boot, install device-specific packages like rpi-kernel for full hardware support.[35][36]
Post-installation setup
After the initial boot into the newly installed Void Linux system, the first step is to update the package database and installed packages to ensure the system is current with the latest security patches and software versions. This is accomplished by running the commandsudo xbps-install -Su as root or a user with appropriate privileges, which synchronizes the repository indexes and upgrades all packages.[20] If the xbps package itself is updated during this process, the command may need to be executed a second time to complete the transaction, as updates to the package manager occur in a separate step.[20]
Void Linux utilizes the runit init system for service management, where services are enabled by creating symbolic links from their definition directories in /etc/sv/ to /var/service/, allowing them to start automatically on boot. For example, to enable the OpenSSH server for remote access, execute ln -s /etc/sv/sshd /var/service/ followed by sv up sshd to start it immediately; this links the service and supervises its operation without requiring a reboot.[17] Similar commands apply to other services, such as dhcpcd for networking, ensuring they run persistently across sessions.[17]
Network configuration post-installation typically involves enabling and customizing the appropriate services based on the hardware. For wired Ethernet connections using DHCP, the dhcpcd service is often pre-enabled for default interfaces, but for a specific interface like enp3s0, copy the service directory with cp -R /etc/sv/dhcpcd-eth0 /etc/sv/dhcpcd-enp3s0, edit the run file to replace eth0 with the target interface using sed -i 's/eth0/enp3s0/' /etc/sv/dhcpcd-enp3s0/run, and enable it via ln -s /etc/sv/dhcpcd-enp3s0 /var/service/.[37] For wireless networks, the wpa_supplicant package is installed by default; configure it by editing /etc/wpa_supplicant/wpa_supplicant.conf to add network blocks, such as generating a WPA-PSK entry with wpa_passphrase <SSID> <passphrase> >> /etc/wpa_supplicant/wpa_supplicant.conf, then enable the service with ln -s /etc/sv/wpa_supplicant /var/service/ and adjust options in /etc/sv/wpa_supplicant/conf for the interface and driver if needed.[38] Interfaces can be verified with ip link show or wireless status checked via rfkill.[37]
To set up a graphical user interface, install a desktop environment using the XBPS package manager, such as XFCE with sudo xbps-install xfce4, which pulls in necessary dependencies like Xorg for display server support.[20] For display manager integration, packages like KDE Plasma automatically include SDDM upon installation via sudo xbps-install kde-plasma, enabling the service with ln -s /etc/sv/sddm /var/service/ to handle user logins and session starts.[39] In minimal setups without a display manager, users can initiate X11 sessions manually by configuring ~/.xinitrc to execute the desired environment, for instance, adding exec startxfce4 at the end of the file and launching with startx, which sources the script to set environment variables and start the window manager.[40]
User-specific customizations enhance usability and security. Although the installation adds the user to the wheel group, sudo is not enabled by default; to grant sudo privileges, edit /etc/sudoers with visudo as root and uncomment the line %wheel ALL=(ALL) ALL to allow password-authenticated administrative commands for wheel members, as Void's base installation provides root access directly but recommends user accounts for daily operations.[41] The .xinitrc file in the user's home directory further allows personalization of X11 sessions, such as launching specific applications or setting variables before the desktop environment starts, ensuring a tailored graphical experience.[42]
Basic security hardening involves configuring a firewall and maintaining updates. Install the runit-iptables package with sudo xbps-install runit-iptables to integrate iptables rules into the runit boot process, then define rules in /etc/iptables.rules (e.g., allowing SSH on port 22 with -A INPUT -p [tcp](/page/TCP) --dport 22 -j ACCEPT and default drop policy) and apply them via iptables-restore < /etc/iptables.rules; enabling the service ensures rules persist on boot.[43] Regular system updates via xbps-install -Su address vulnerabilities, with tools like xcheckrestart from the xtools package identifying and restarting outdated processes post-update.[20]