Every operating system starts with a base, and the part of that base you can least afford to get wrong is the init system. 0dyssey is being built on Void Linux, which uses runit. This is the reasoning, and the half of it that generalises: the property we judged candidates on holds whether or not you ever touch Void.
The init system is the foundation, so treat it like one
The init system is the first process on the machine and the parent of everything else. It never goes away. If it is complex, that complexity lives at the root of your process tree forever, and every failure you debug afterwards gets debugged through it.
systemd is the default nearly everywhere, and it does a great deal. That is exactly the property worth weighing. It is an init system, a service manager, a logging daemon, a device manager, a network configurator, a login session tracker and a timer scheduler, bundled into a tightly coupled whole that wants to own PID 1 and most of what runs above it. For a general purpose desktop distribution that is a reasonable trade: it works, and almost nobody has to read it. For a base you intend to build a coherent product on top of, it is a lot of behaviour you neither control nor fully understand.
The property worth judging: is the state legible?
The question we kept returning to is not which init system is fastest or which has the most features. It is whether you can answer, from the machine itself and without a manual, three things: what is running, why it started, and what happens when it dies.
An init system passes that test when its state lives somewhere you can read: a directory, a file, a symlink. It fails when its state is a resolution graph computed at boot from unit files, drop-ins, generators and presets, where the only way to inspect the result is to ask the tool that computed it. The second kind is not necessarily wrong, but it means the tool is the only witness to its own behaviour.
A supervised service is a folder. To enable it, you symlink the folder. To check it, you ask. There is no hidden state, no generators, no unit-file resolution graph: the thing you wrote is the thing that runs.
What runit actually looks like
runit is small enough to read end to end in an afternoon. A service is a directory containing a run script. Supervision is a symlink into the active service directory. That is the entire mental model, and it is worth seeing a full lifecycle in one block.
# a service is a directory with a run script, and nothing else. a minimal
# one, /etc/sv/sshd/run, is three lines: merge stderr into stdout, then exec
# the daemon in the foreground so runit supervises the process it started
#!/bin/sh
exec 2>&1
exec /usr/bin/sshd -D
# install the package. xbps is Void's package manager
$ sudo xbps-install -S openssh
# enable it: symlink the directory into the supervised set
$ sudo ln -s /etc/sv/sshd /var/service/
# ask for its state. sv reports whether it is up, and its pid
$ sudo sv status sshd
# start, stop, restart: all explicit, all synchronous
$ sudo sv restart sshd
$ sudo sv stop sshd
# disable supervision: remove the symlink. There is no daemon-reload
$ sudo rm /var/service/sshdNo [Unit] / [Service] / [Install] stanzas. No reload step that silently leaves the running configuration out of sync with the file you just edited. A service is enabled when the symlink exists and supervised when runit sees it. The filesystem is the state, which makes ls a debugging tool.
When you can read your init system in an afternoon, you can reason about every failure mode in it. For a system we intend to ship and support, that is not a luxury. It is a prerequisite, and it is the reason this decision was made before almost any other.
What the choice cost
No base is free. A decision worth writing up names what it cost before it claims what it bought, so here is the bill:
- runit is unfamiliar to most Linux users, so our documentation has to carry weight that a systemd-based system would have inherited from the rest of the ecosystem.
- Upstream projects ship systemd units, not runit run scripts. Anything we package that assumes systemd is packaging work we do ourselves.
- Void's package repository is smaller than Debian's or Arch's, which occasionally means building upstream software ourselves.
- A thinner community means fewer copy-paste answers at three in the morning when something breaks.
We accepted all four, because the alternative was inheriting weight we would spend years trying to remove.
It is easier to add thoughtfully to a minimal base than to subtract from a maximal one. That asymmetry decided it.
Not a fork, a composition
0dyssey is not a fork of Void and it is not a reskin of anything. It is a careful composition of proven layers: the Linux kernel, runit for init and supervision, xbps for packages, i3 for window management, on a Void base, with our own UX layer on top. Each one does its job and hands off cleanly to the next.
That framing is deliberate rather than modest. A fork inherits an entire project's maintenance burden and its politics. A composition inherits only the interfaces, which means every layer stays replaceable the day the reasoning that chose it stops holding. Writing the reasoning down is what makes that possible: a decision you cannot reconstruct is a decision you can never revisit.
There is nothing to download. 0dyssey is in development, and this is a record of a decision rather than a release note. What can be published today is the decision and the argument behind it, which is also the part worth arguing with.