Part of the reason I wrote this piece is that I keep stumbling onto threads like this:
This is a companion discussion topic for the original entry at https://blog.tjll.net/the-systemd-revolution-has-been-a-success
This is a companion discussion topic for the original entry at https://blog.tjll.net/the-systemd-revolution-has-been-a-success
I’m one of those people who used to passionately hate SystemD, and to some extent I probably still carry some of that bias. But I’m not really trying to argue for or against it anymore — I’ve used it enough that it’s grown on me in many ways. What I keep coming back to, though, is a usability issue rather than an ideological one.
Specifically, the experience of developing, configuring, and launching new services often feels cognitively heavy. There are a lot of directives, edge cases, ordering semantics, and subtle gotchas, and even when things work, it can feel like you’re navigating a large configuration surface area with many possible wrong turns.
The problem isn’t that the system lacks power — quite the opposite — it’s that the amount of flexibility creates decision overhead and mental friction, particularly for tasks that conceptually should be simple.
Barry Schwartz’s The Paradox of Choice is relevant here. It sounds counter-intuitive to complain about having too many options, but psychology research shows that beyond a certain threshold, more choice actually reduces usability and satisfaction because it increases cognitive load, uncertainty, and fear of making the wrong decision.
In that sense, SystemD may have crossed a complexity boundary where additional configurability stops feeling empowering and starts feeling burdensome for some users. To be clear, this doesn’t mean SystemD is “bad,” and it has undeniably standardized a lot of things across distributions, which reduces choice at a macro level.
But at the micro level — when you’re writing or debugging units — the combinatorial flexibility can make the experience harder than it needs to be. That tension between power and ergonomics is really the point I’m trying to highlight.
Why a great wizard doesn’t really exist (important insight)
This is the most interesting part. There are structural reasons.
Reason 1 — systemd is a combinatorial configuration space
There are hundreds of directives. A wizard must decide:
- Which ones matter?
- Which defaults?
- Which security options?
- That’s a hard UX problem.
Reason 2 — users have wildly different needs
A daemon could be:
- forked legacy process
- container wrapper
- oneshot job
- timer
- socket activated
- sandboxed service
- mount dependent
- dynamic user
A universal wizard risks being wrong.
Reason 3 — expert culture
Linux infrastructure culture tends toward:
- Learn the primitives rather than hide them.
- So investment into beginner tooling is lower.
The closest thing to what you’re imagining
If someone wanted to build the ideal tool today, it would likely be a CLI wizard like:
$ svc-init create
What type of service?
1) Long-running daemon
2) Scheduled job
3) One-shot task
4) Socket activated
Command to run?
User?
Restart policy?
Needs network?
Security profile? (basic / hardened / strict)
→ Generates unit + explanation
With:
- sensible defaults
- progressive disclosure
- optional hardening presets
- inline docs
That tool does not really exist in a polished mainstream form.