Why Artix Linux Ships Four Init Systems — and How to Actually Pick One

The problem: your distro chose your init for you

Most mainstream Linux distributions made a quiet decision on your behalf years ago: PID 1 — the first process the kernel starts, which then supervises everything else — will be systemd. For most users that's fine. But systemd isn't just an init system; it's a suite that also handles logging, device management, login sessions, DNS, and more. If you want a system where those jobs are separate, replaceable pieces, you're mostly on your own.

Artix Linux is the engineering answer to that: an Arch-based distribution built around the premise that init should be a choice, not a default you can't escape. Its core decision is to remove systemd entirely and offer four alternatives — OpenRC, runit, s6, and suite66 — while keeping pacman and (with caveats) access to the Arch ecosystem.

What "systemd-free" actually means in practice

Artix maintains its own repositories layered on top of Arch's, providing rebuilt packages that don't link against systemd components. Two compatibility pieces do the heavy lifting:

• elogind — a standalone fork of systemd's logind, which desktop environments (GNOME, KDE Plasma, etc.) expect for session and seat management. Without it, most graphical desktops won't log you in.
• libsystemd shims — stub libraries so packages compiled against systemd's libraries can still install and run, as long as they don't call init-specific APIs.

This is a pragmatic compromise: Artix doesn't try to purge every trace of systemd's interfaces, just its role as PID 1 and system manager. The trade-off is that software which genuinely requires systemd APIs — not just the libraries — will still fail. That's rare for typical desktop and server software, but it happens.

Choosing an init: runit vs. OpenRC

The two most popular Artix variants sit at opposite ends of the complexity spectrum:

runit's model is strikingly simple: a service is a directory containing an executable run script. Enabling it means symlinking that directory into /var/service/, which runit's supervisor watches. OpenRC is closer to what older Debian or Gentoo users know, with runlevels and dependency declarations.

Worked example: managing a service under runit

Say you've installed Artix with the runit ISO and want the SSH daemon running at boot. From a root shell (or with sudo):

# Install the service package (Artix ships -runit variants)
sudo pacman -S openssh-runit

# Enable it by symlinking into the supervised directory
sudo ln -s /etc/runit/sv/sshd /var/service/

# Check status
sudo sv status sshd

Expected result: sv status reports the service as run along with its PID and uptime. The symlink alone is enough — runit's runsvdir notices new entries in /var/service/ within a few seconds and starts the service automatically. To disable, remove the symlink: sudo rm /var/service/sshd. This changes system state (the service stops), so only do it if you actually want sshd gone — on a remote machine, that could lock you out.

Two sanity checks for any fresh Artix install:

ps -p 1 -o comm=

Should print something like runit or init — not systemd. And systemctl should simply not exist as a functional command.

The trade-offs you should weigh

• Arch wiki mismatch. Many Arch guides assume systemctl. You'll need to translate service-management steps to your init's syntax, and occasionally a guide simply won't apply.
• Per-init knowledge. OpenRC, runit, s6, and suite66 have different configuration conventions. Picking one means learning it; switching later means relearning.
• Edge-case breakage. Software hard-wired to systemd APIs (some VPN clients, certain enterprise agents, parts of GNOME's deeper integration) may not work despite elogind.
• Smaller safety net. Artix is a community distribution; its repos trail Arch's and the support community is smaller.

What you get in return: a boot process you can read end-to-end, service definitions that are often a few lines long, and a system where logging, device management, and init are separate, swappable tools.

Where to start

If you're curious, install Artix in a VM first — the runit variant is the gentlest introduction, since its service model takes about ten minutes to understand. Verify PID 1 with ps -p 1 -o comm=, enable one service via /var/service/, and see whether the transparency is worth the smaller ecosystem for your use case. If you rely on software with hard systemd dependencies, check that first — it's the one limitation no compatibility layer fixes.