If you’ve been around Linux long enough, you’ve seen the argument loop endlessly:
- Pro-systemd: faster boots, dependency-aware service startup, consistent tooling, and a coherent “it just works” layer.
- Anti-systemd: do one thing well matters, PID 1 should stay boring, and bundling half the OS under one umbrella increases blast radius.
Both sides are right. And that’s why the debate refuses to die.
The real shift: systemd stopped being “just init”
Technically, systemd still is an init system when it runs as PID 1—but in practice it’s a system and service manager that pulled related responsibilities into its orbit: service supervision, logging (journald), DNS/resolution (resolved), user sessions, timers, socket activation, resource control, and more. That integration is the feature and the controversy.
I often describe systemd like IKEA: you go in for a shelf and leave with a whole home organization system, a set of candles, and Swedish meatballs. Does it work? Absolutely. Did you need all of it? Depends on your use case.
Why embedded engineers keep caring in 2026
I work with embedded and industrial setups—NXP i.MX, NVIDIA Jetson, TI Sitara AM6x, Raspberry Pi Compute Modules, payment kiosks with industrial hardware—where:
- every megabyte matters,
- startup needs to be predictable and reproducible,
- you want fewer moving parts in early boot,
- and “debugging PID 1” is the kind of day you want to avoid.
In those environments, a minimal init and a simple supervision model can feel like the right tool. In enterprise-ish deployments—kiosks at scale, long lifecycle, monitoring expectations, vendor tooling—systemd’s standardization often saves more time than it costs.
So yes: systemd won the default across mainstream Linux. But it did not “win the argument,” because the argument was never purely technical. It’s also about architecture philosophy, operational risk, and what you want PID 1 to be responsible for.
Table 1 — 15 distros where systemd isn’t mandatory (default non-systemd or official alternatives)
The nuance matters: some distros are systemd-free by default, others officially support multiple inits (sometimes with systemd as default), and a few are “init-choice” projects on principle.
| Distro | Default / primary init (or init family) | Notes for sysadmins & devs |
|---|---|---|
| Gentoo | OpenRC (common default) | Can run systemd too; choice is a core Gentoo feature. |
| Alpine | OpenRC | Minimal footprint; popular for containers/edge. |
| Void Linux | runit | Simple supervision-first model; great for “boring init” fans. |
| Artix | OpenRC / runit / s6 / dinit | Arch-like without systemd; init choice is part of the distro. |
| Devuan | sysvinit by default (plus OpenRC/runit options) | “Init freedom” explicitly; Debian lineage without mandatory systemd. |
| Slackware | sysvinit with BSD-style init scripts | Classic, editable init scripts; conservative design. |
| Chimera Linux | dinit | Modern supervision without systemd’s full suite. |
| antiX | sysvinit (default) or runit | Explicitly systemd-free; good low-resource option. |
| MX Linux | sysvinit (default) or systemd | “Dual init” focus returned in MX 25.1. |
| Hyperbola | OpenRC / runit (systemd-free) | Listed as init-freedom distro; niche but notable. |
| Parabola | systemd default, but alternatives exist | Devuan lists OpenRC/sysvinit/s6 options; not systemd-free by default. |
| Obarun | s6 supervision suite (+ “66” tooling) | Arch-like built around s6; different mental model than OpenRC/runit. |
| Adélie Linux | OpenRC for service management | Uses OpenRC service control in docs; built for admin clarity. |
| Guix System | Shepherd | Declarative services with Scheme; very different (and powerful) model. |
| KISS Linux | BusyBox init (+ runit-style service mgmt) | Extreme minimalism; you trade convenience for control. |
Table 2 — init systems compared (what actually matters in the trenches)
Here’s the “admin view” comparison: not ideology, but the things you end up caring about at 03:00.
| Init / supervisor | What it optimizes for | Strengths | Typical pain points | Best fit |
|---|---|---|---|---|
| systemd | Integrated system layer | Mature dependency model; uniform tooling; tight integration (logging, DNS, timers, sockets). | Complexity; larger blast radius; harder to reason about “what changed” across updates. | General-purpose Linux, fleets, enterprise ops |
| SysVinit (+ distro scripts) | Simplicity & transparency | Easy to audit; minimal moving parts; very “understandable” boot. | Weak native supervision; ordering/dependencies mostly manual; varies by distro. | Old-school servers, minimal systems, conservative shops |
| OpenRC | Lightweight init + service mgmt | Smaller footprint; familiar to Gentoo/Alpine users; good middle ground. | Still script-heavy; some dependency handling but less “batteries included” than systemd. | Embedded/edge, minimal server builds |
| runit | Supervision-first minimalism | Small codebase; strong service supervision; very predictable. | Fewer integrated “system services”; you assemble the rest. | Minimal distros, appliances, container-like hosts |
| s6 (+ ecosystems like 66) | High-control supervision | Powerful composition; extremely robust supervision patterns. | Learning curve; configuration style is different; fewer “standard defaults.” | Embedded/industrial, high-control environments |
| dinit | Modern supervision without systemd | Clear service model; supervision built-in; simpler than systemd. | Smaller ecosystem; fewer “standard expectations” across distros. | Minimal desktops/servers, modern-but-light setups |
| Shepherd | Declarative service mgmt (Scheme) | Extremely flexible; services as code; fits Guix’s model. | Niche outside Guix; requires different mindset/tooling. | Reproducible systems, Guix users |
| BusyBox init | Minimal footprint | Tiny; very predictable; pairs with other supervisors as needed. | You build a lot yourself; fewer standard conventions. | Ultra-minimal devices, custom embedded |
The uncomfortable engineering lesson
This debate survives because it’s not just about boot speed or log formats—it’s about tradeoffs:
- Standardization vs. composability
- Integration vs. blast radius
- “Fewer tools, more glue” vs. “one suite, one way”
And that lesson scales beyond Linux. The solution that wins adoption isn’t always the “best” in some absolute sense—it’s the one that aligns with ecosystems, tooling, and operational reality.
My pragmatic rule of thumb (especially for embedded)
- Enterprise kiosk / managed fleet / SOC tooling expects systemd → use systemd and move on.
- Container base image / tight embedded footprint / deterministic boot → OpenRC or runit (or s6 if your team is comfortable) tends to feel like the right-sized tool.
So… what are you running day to day: Team systemd, or the stubborn village that still cares about PID 1 staying boring?