Void is a general purpose operating system, based on the monolithic Linux® kernel. Its package system allows you to quickly install, update and remove software; software is provided in binary packages or can be built directly from sources with the help of the XBPS source packages collection.
It is available for the Intel x86®, ARM® and MIPS® processor architectures; Software packages can be built natively or cross compiling through the XBPS source packages collection.
Void Linux is an independent distribution, developed entirely by volunteers.
Unlike trillions of other existing distros, Void is not a modification of an existing distribution. Void's package manager and build system have been written from scratch.
Install once, update daily. Your system will always be up-to-date.
Thanks to our continuous build system, new software is built into binary packages as soon as the changes are pushed to the void-packages repository.
We were the first distribution to switch to LibreSSL by default, replacing OpenSSL.
xbps is the native system package manager, written from scratch with a 2-clause BSD license.
xbps allows you to quickly install/update/remove software in your system and features detection of incompatible shared libraries and dependencies while updating or removing packages (among others). See the usage page for a brief introduction.
xbps-src is the xbps package builder, written from scratch with a 2-clause BSD license.
This builds the software in containers through the use of Linux namespaces, providing isolation of processes and bind mounts (among others). No root required!
Additionally xbps-src can build natively or cross compile for the target machine, and supports multiple C libraries (glibc and musl currently).
Who of you ever wanted a pony for Christmas? Turns out, Void Linux already includes some. Don’t worry, they are just virtual yet just a command away:
# xbps-install ponysay
ponysay features over 400 illustrations of My Little Pony for your terminal. Look at all of them using
% ponysay-tool --browse /usr/share/ponysay/ponies
You even can make the ponies quote themselves using
Lots of fun for everypony! Whee!
cron(8) is a nice tool, but it has some long-standing problems, among them:
A little, but flexible alternative is to use snooze(1), which essentially just waits for a particular time, and then executes a command. To get recurring jobs ala cron, we can use this together with our runit service supervision suite. If we wanted at(1) instead, we can just run snooze once.
The time for snooze is given using the options
-d (for day),
-m (for month),
-w (for weekday),
-D (for day of year),
-W (for ISO week), and
-H (for hour),
-M (for minute),
-S (for second).
Each option of these can be comma-separated list
of values, ranges (with
-) or repetitions (with
The default is daily at midnight,
so if we wanted to run at the next full hour instead, we could run:
% snooze -n -H'*' 2017-12-24T17:00:00+0100 Sun 0d 0h 47m 33s 2017-12-24T18:00:00+0100 Sun 0d 1h 47m 33s 2017-12-24T19:00:00+0100 Sun 0d 2h 47m 33s 2017-12-24T20:00:00+0100 Sun 0d 3h 47m 33s 2017-12-24T21:00:00+0100 Sun 0d 4h 47m 33s
-n option disables the actual execution and shows the next five
matching times instead.
To run every 15 minutes, we’d use
% snooze -n -H'*' -M/15 2017-12-24T16:15:00+0100 Sun 0d 0h 1m 31s 2017-12-24T16:30:00+0100 Sun 0d 0h 16m 31s 2017-12-24T16:45:00+0100 Sun 0d 0h 31m 31s 2017-12-24T17:00:00+0100 Sun 0d 0h 46m 31s 2017-12-24T17:15:00+0100 Sun 0d 1h 1m 31s
More complicated things are possible, for example next Friday the 13th:
% snooze -n -w5 -d13 2018-04-13T00:00:00+0200 Fri 108d 6h 45m 33s 2018-07-13T00:00:00+0200 Fri 199d 6h 45m 33s no satisfying date found within a year.
Note that snooze bails out if it takes more than a year for the event to happen.
By default, snooze will just terminate successfully, but we can give it a command to run instead:
% snooze -H'*' -M'*' -S30 date Sun Dec 24 16:27:30 CET 2017
When snooze receives a SIGALRM, it immediately runs the command.
snooze is quite robust, it checks every 5 minutes the time has progressed as expected, so if you change the system time (or the timezone changes), it is noticed.
For additional robustness, you can use the timefiles option
which ensures a job is not started if its earlier than some
modification time of a file. On success, your job can then touch this
file to unlock the next iteration. Together with the slack option
this can be used for anacron-style invocations that ensure a task is
run, for example, every day at some point.