Void Linux

Void Linux is a minimalistic, stable Linux distribution that prioritizes speed and stability. It provides very little out of the box, but allows for a lot of manual customization, allowing you to tweak and customize your installation however you see fit. It's not derived from Debian or Redhat (or based on any distro for that matter), so don't plan on using any .deb or .rpm packages with it. It also doesn't use systemd, opting to use runit instead, which is a major plus in my book.

I'm planning to use it as the basis for Breezy, but I'm still learning and experimenting with it, so there's a chance that could change. It's worth noting that the core installation is not the most user friendly and is a headless (no GUI) operating system. They do provide a download that's preloaded with Xfce, but if you're taking the Void route, I'd recommend just checking out their documentation on "Graphical Sessions" and handpicking whichever one you want.

XBPS

Void uses XBPS as its package manager. Instead of apt or yum to do all your installation, you'd use one of a few xbps- commands to query for or install packages.

Out of the box, the first thing you'll want to do on Void is update your packages and (most likely) the package manager itself:

xbps-install -Su
xbps-install -u xbps

Then, to find a package to install, you'd use xbps-query with a -R flag to query remote repositories and a -s flag to specify a search term. For example:

xbps-query -Rs vim

To install the package, you'd use xbps-install with a -S flag to sync your local index with the server, and -u to ensure the package is updated to the latest version.

xbps-install -Su vim

When removing, use xbps-remove, making sure to use the -R flag to clean up dependent packages as well. If you ever forget the -R, you can run xbps-remove -o without a package name, and it'll remove any orphaned packages.

xbps-remove -R vim

xlocate

Sometimes you'll want access to some binary, but you're not sure which package it belongs to. xbps-query only queries package names and descriptions, but not the installed files for each package. To search for a specific binary belonging to some unknown package, you can install xtools and use the xlocate command it provides. For example, to search for iwlist:

# Install xtools (which has xlocate)
xbps-install -Su xtools

# Update the local search index
xlocate -S

# Search for a binary (like "iwlist")
xlocate iwlist

runit

runit is an alternative initialization system to what most Linux distributions use (systemd). They're about as opposite as you can get in terms of product mentality. systemd is a complex monolith that tries to control and do everything, whereas runit is simple and fast but doesn't try to cover nearly as much functionality as systemd does. I'm all for simple, especially if it means I'm also allowed to have options for the other software running on my system rather than being boxed in to systemd's ecosystem.

Enabling a Service

An initialization system is responsible for starting up (initializing) all the services your computer needs in order to work. For runit, the services that are enabled to autostart are found in /var/service/. The configurations for the services that are possible to enable are found inside /etc/sv/. To enable a configured service (ie, one that exists in /etc/sv/), you just need to create a symbolic link from its /etc/sv directory into the /var/service/ directory:

ln -s /etc/sv/my-service /var/service/

Creating a Custom Service

Most packages you install that would run as a service come with a configuration pre-created inside /etc/sv/, so for most things, you'd just need to run the above link command. If you have a custom program that you want to run as a service, you'll first need to create its configuration. To do that, you'd:

1. Create a new directory for its configuration: mkdir /etc/sv/my-service
2. Create a "run" file inside that new directory: vim /etc/sv/my-service/run
3. Make the run file executable: chmod +x /etc/sv/my-service/run
4. Enable the service: ln -s /etc/sv/my-service /var/service/

The run file created in step 2 should execute the final command it wants to run by prefixing it with exec. This allows runit to properly manage the process. It's just a shell script, so it might look something like this:

#!/bin/bash
exec /root/my-program/my-binary

If you want to inject environment variables into the process, or run it as a certain user or from a certain directory, you can set all these things (and more) using the chpst ("change process state") command. For example:

#!/bin/bash
exec chpst -e /etc/sv/my-service/env -u ben -C /root/my-program ./my-binary

The -e environment option is a directory containing files. Each filename is an environment variable to set, and the file contents are the variable's value.

Service Management

To manage runit services, you'll use the sv command:

sv status my-service
sv start my-service
sv stop my-service

Log Service

To collect stdout and stderr from a service, you'd configure a "log service" that runs alongside your main service. The log service is created within your main service's configuration, and is automatically started or stopped as needed alongside your main service.

To add a log service to one of your services, you'd first create a log directory within your main service's configuration directory:

sudo mkdir -p /etc/sv/myservice/log

Then create a "run" script within that log directory with the following contents:

#!/bin/sh
exec svlogd -tt /var/log/myservice

svlogd provides you with all sorts of fancy things like automatic log rotation, old log cleanup, and timestamped outputs. The /var/log/myservice directory is where the log files will be written, so make sure you create it:

sudo mkdir -p /var/log/myservice

Then lastly, make the log service executable:

sudo chmod +x /etc/sv/myservice/log/run