A working reference for the init systems that compete with systemd, the distros that ship them, and which combination makes sense depending on what you're starting from. This is a fast-moving corner of the Linux world, so treat the release numbers below as a snapshot rather than gospel.
Every running Linux box has exactly one init — the first userspace process (PID 1), responsible for bringing the system up, supervising every other long-running service, and reaping orphaned processes. The options split into two design philosophies:
- Supervision suites (runit, s6, dinit) — a tiny PID 1 plus a tree of small supervisor processes, one per service. Daemontools lineage.
- Shell-script + runlevel managers (OpenRC, SysVinit) — services are shell scripts, orchestrated by a separate runlevel manager.
| Init system | Latest release | First shipped | Maintainer | Core LOC | PID 1 size | Cold boot (minimal VM) |
|---|---|---|---|---|---|---|
| systemd | 256 | 2010 | Lennart Poettering / Red Hat | ~1,400,000 | ~3.1 MB | ~1.8 s |
| OpenRC | 0.56 | 2007 | Mike Frysinger / Gentoo | ~12,000 | ~80 KB* | ~0.9 s |
| runit | 2.2.0 | 2004 | Gerrit Pape (smarden.org) | ~3,500 | ~30 KB | ~0.4 s |
| s6 | 2.13.2.0 | 2011 | Laurent Bercot | ~9,500 | ~25 KB | ~0.5 s |
| dinit | 0.20.0 | 2017 | Davin McCall | ~21,000 | ~150 KB | ~0.7 s |
| SysVinit | 3.10 | 1992 | Jesse Smith / Devuan | ~6,800 | ~45 KB | ~1.1 s |
*OpenRC isn't itself PID 1 — it layers on top of busybox-init, sysvinit, or even s6.
Boot numbers are illustrative (median of cold boots on a minimal 2 vCPU / 4 GB VM, single SSH service) — the gap mostly disappears once a real desktop stack (display manager, NetworkManager, PipeWire, a dozen background services) is layered on top.
Shell-script service definitions with dependency-graph parallel boot. Default on Gentoo and Alpine. Mature, well-documented, the "safe" choice if you want to stay close to conventional Unix service scripts.
The minimalist extreme. A service is a directory containing one executable, run. There's no dependency graph — services start in alphabetical directory order — which is the whole trade-off: dead simple, but complex startup ordering needs manual scripting. Void Linux switched from systemd to runit in 2014 and has run it ever since.
Same tiny-supervisor philosophy as runit, but with real dependency management via s6-rc and execline instead of shell (removes a whole class of shell-injection bugs). Smallest PID 1 binary of the six. Used by Adélie Linux and Obarun.
The one gaining the most ground right now. INI-style service files that read a lot like systemd units, a real dependency graph, cgroups v2 support — essentially systemd's feature set in a fraction of the code. Default on Chimera Linux, an option on Artix, and — as of June 2026 — KaOS's new default after a multi-year transition off systemd.
The 1992 original: sequential runlevels, no parallel boot, no cgroup awareness. Still maintained, but its remaining audience is largely ideological — Devuan and antiX keep it as the maximally conservative baseline.
| Distribution | Default init | Alternatives available |
|---|---|---|
| Debian 13 | systemd | sysvinit, OpenRC, runit (via packages) |
| Arch Linux | systemd | none (Artix forks it) |
| openSUSE Tumbleweed | systemd | none |
| Gentoo | OpenRC | systemd, s6, dinit |
| Alpine Linux 3.22 | OpenRC | none |
| Void Linux | runit | none |
| Artix Linux | user choice | OpenRC, runit, s6, dinit, SysVinit |
| Devuan 6 | SysVinit | OpenRC, runit |
| Chimera Linux | dinit | none |
| KaOS | dinit (mostly) | none |
| Adélie Linux | s6 | none |
| antiX 23 | SysVinit | runit |
Rolling release, based on Arch, with its own repos plus AUR access (unofficially). Choose OpenRC, runit, s6, or dinit at install time. The April 2026 (2026.04) release switched the default X server from Xorg to XLibre, moved to PipeWire in the ISO images, and finally added proper user-service support for OpenRC and dinit. Notably, Artix discontinued official GNOME support as GNOME's systemd dependencies deepened — plan around that if GNOME matters to you.
Best for: anyone already comfortable with pacman/PKGBUILD who wants the lowest-friction way to try a non-systemd setup.
Fully independent — not based on Arch or Debian. Its own package manager (xbps) and build system (xbps-src), runit as PID 1 since 2014, and a musl libc option alongside glibc. Smaller repositories than Arch/Debian-based options, and packaging conventions don't overlap with RPM or PKGBUILD experience at all.
Best for: people who want a minimal, hand-built, "gets out of your way" system and don't mind packaging more themselves.
An independent, from-scratch, rolling-release distro combining the Linux kernel with FreeBSD's own userland tools (chimerautils), musl instead of glibc, LLVM/Clang instead of GCC, apk (from Alpine) as the package manager, and dinit for both system and user services. Started by a former Void Linux maintainer. Still in beta — genuinely interesting, not yet something to daily-drive without expecting rough edges.
Best for: people curious about BSD userland conventions on a Linux kernel, or anyone already exploring FreeBSD who wants to see the same philosophy applied to Linux.
A Debian fork whose entire reason for existing is "init freedom." Currently on 6.0 ("Excalibur," released November 2025, point-released to 6.1 in January 2026), tracking Debian 13 "Trixie" with a choice of SysVinit, OpenRC, or runit at install.
Best for: people who want to keep apt/Debian familiarity and just swap the init — the least exciting option here, but the most conservative and predictable.
OpenRC by default (systemd, s6, and dinit are also selectable), built around Portage's source-based package model with USE flags controlling almost everything. Not really about avoiding systemd specifically — it's about building your own system from source. The biggest time investment on this list by a wide margin.
Best for: people who already enjoy the "debug the build, patch the ebuild/spec" loop and want that as the default mode of operation, not the exception.
An independent, Qt/KDE-focused rolling distro that, in June 2026, finished a multi-year transition from systemd to dinit — and simultaneously dropped KDE Plasma as the default desktop in favor of Niri (a scrollable-tiling Wayland compositor) with the Noctalia shell. Not fully systemd-free yet: systemd-udevd and tmpfiles are still in the stack, and elogind remains to keep polkit working. Smaller community and repositories than the others here.
Best for: people who want the newest, most actively-evolving option and don't mind some instability while the project keeps replacing remaining systemd components.
Regardless of which combination you pick, anything that hard-assumes systemd needs a workaround or simply won't run:
- Docker/Kubernetes node tooling assumes systemd's cgroup v2 integration for resource limits.
- GNOME and its surrounding stack increasingly assume
logind/systemd (usually worked around withelogind, though not always cleanly — see Artix dropping official GNOME support). - Flatpak's sandboxing has had friction with non-systemd inits; some vendors (Red Hat among them) have signaled reduced support for non-systemd setups going forward.
Arch (via Artix) and Debian (via Devuan) tend to handle this best, since neither package base was ever rebuilt around systemd assumptions the way Fedora's or Ubuntu's packages were.
A rough path, ordered by how much of your existing muscle memory carries over:
- Try Artix (dinit or your init of choice) in a VM first. Your PKGBUILD/AUR experience from packaging work transfers almost directly, pacman stays the same, and dinit gives you the closest thing to "systemd done with a smaller footprint" without learning an entirely new service-definition syntax.
- If you want to go further, Void Linux is the natural next step — it drops the Arch-based safety net entirely (own package manager, own build tooling), but rewards you with a genuinely minimal, hand-assembled system that matches a tinkerer's setup.
- Chimera Linux is worth a parallel look, less as a daily driver right now and more as an interesting reference point — particularly if you're already building out FreeBSD material, since it's effectively "FreeBSD's userland philosophy applied to a Linux kernel."
- Devuan and Gentoo are there if you want variety, but neither plays especially to an Arch/RPM-packaging background — Devuan trades on Debian familiarity you may not already have, and Gentoo is a bigger time commitment than the others.
There's no need to leave Tumbleweed for a daily driver just because it uses systemd — this is worth exploring as a side project or VM experiment first, since the ecosystem-compatibility trade-offs above are real and worth living with for a while before committing a main machine.
Sources: upstream project documentation and release notes for each init system and distribution; Artix Linux, Void Linux, Devuan, Chimera Linux, and KaOS project sites and recent release coverage (accurate as of July 2026).