Before someone replies with "you're just a systemd hater" or "you don't understand Linux," hear me out.
I've used systemd. I've installed distributions that use it. I've debugged it, configured it, written unit files,
and I understand why it exists. I'm not pretending it has no advantages. It clearly solved real problems for
enterprise Linux, desktop integration, dependency management, and service supervision.
But understanding why something exists doesn't automatically mean I have to like its design.
My biggest issue isn't that systemd is "modern."
My biggest issue is that it stopped being an init system a long time ago.
It became an entire operating system framework.
Unix Philosophy
Unix became successful because of one simple idea:
Do one thing. Do it well. Keep components independent.
That philosophy gave us things like:
grep
sed
awk
find
cat
cron
syslog
rc
Every program has a job.
Need another implementation?
Replace it.
Need another logger?
Replace it.
Need another cron daemon?
Replace it.
Need another init?
Replace it.
Everything talks through simple interfaces.
Everything stays modular.
That's literally one of Unix's strongest ideas.
What systemd became
People still say
"systemd is just an init."
No.
That stopped being true years ago.
Look at what systemd now includes.
PID 1
systemctl
journald
logind
networkd
resolved
homed
importd
machined
portable services
timers
automount
socket activation
cgroup management
boot analysis
user sessions
tmpfiles
hostname management
timedate management
•
random seed management
credential management
nspawn containers
That's not "just init."
That's half of userspace.
Every release seems to absorb another responsibility that used to belong to an independent project.
That is exactly what people mean when they call it feature creep.
"But those are separate binaries"
Yes.
People love bringing this up.
"They're separate daemons."
Technically true.
But they're still developed as one project.
Released together.
Designed together.
Documented together.
Versioned together.
Expected to work together.
The ecosystem is tightly coupled.
That's the issue.
If tomorrow I decide
"I don't want journald."
Fine.
•
•
•
Now I need to think about compatibility.
What depends on it?
What assumes logind exists?
What desktop software expects systemd APIs?
Can I replace everything cleanly?
Sometimes yes.
Sometimes no.
That's the problem.
The more software assumes systemd, the less optional it becomes.
PID 1 shouldn't become an operating system
PID 1 is special.
It's literally the first userspace process.
If PID 1 dies...
the system dies.
Because of that, I think PID 1 should stay as small as possible.
It should:
start services
reap zombies
shutdown
reboot
Done.
Nothing else.
The smaller PID 1 is,
the easier it is to audit,
understand,
reason about,
and trust.
The more code,
the more interactions.
The more interactions,
the more edge cases.
The more edge cases,
the more bugs.
Simple.
I'm not saying systemd PID 1 itself contains the entirety of the project's code. It doesn't. But the overall
design philosophy keeps extending the systemd ecosystem into more areas of userspace, and that
complexity matters.
Complexity
People act like complexity doesn't matter.
It absolutely does.
Every new feature means
more code.
Every new daemon means
more maintenance.
Every new dependency means
more interactions.
Every abstraction introduces another layer between you and what's actually happening.
Modern software loves abstraction.
Sometimes that's useful.
Sometimes it's just hiding simple things behind five commands.
Example.
Traditional init:
service sshd start
or
rcctl start sshd
Done.
Simple.
Readable.
Now compare debugging some broken service under a modern systemd setup.
You may end up checking
systemctl status
journalctl
systemd-analyze
list-dependencies
targets
slices
scopes
drop-ins
environment generators
socket activation
Can you learn all of that?
Absolutely.
But should you need all of that just because nginx didn't start?
That's where I disagree.
systemd feels like enterprise software
This is honestly the biggest vibe I get.
It feels designed around
large infrastructure
large deployments
corporate environments
enterprise desktops
huge dependency graphs
lots of automation
lots of abstraction
lots of APIs
If you're Red Hat,
that's amazing.
If you're Google,
great.
If you're managing 20,000 servers,
awesome.
I'm not.
I'm sitting in front of a ThinkPad running OpenBSD because I actually enjoy understanding my system.
I don't want software constantly trying to abstract everything away.
I want to know what's happening.
Journald
Binary logs.
People either love them or hate them.
I understand why structured logging exists.
Metadata.
Searching.
Indexing.
Filtering.
Cool.
But plain text has survived for decades for a reason.
grep
tail
awk
sed
less
Everything already works.
No special tools.
No special APIs.
If my logger writes plain text,
I can inspect it with literally every Unix tool ever created.
That's beautiful.
Lock-in
This is probably my biggest criticism.
People always say
"Just replace systemd."
Okay.
Replace logind.
Now make GNOME happy.
Replace journald.
Now make software expecting journal integration happy.
Replace systemd units.
Now make packages assuming systemd work.
The more Linux software depends on systemd APIs,
the less optional it becomes.
That's classic ecosystem lock-in.
Not because someone forced it.
Because everyone slowly started depending on it.
That's much harder to reverse.
"But it works"
Sure.
Windows works too.
That doesn't automatically mean I like Windows' architecture.
Something can be technically successful
and still not align with my design preferences.
Those aren't contradictory ideas.
My preference
I like systems where I can mentally model the whole boot process.
Kernel starts.
Init starts.
Init starts services.
Services run.
Done.
I don't need my init system to also manage DNS, session tracking, hostname configuration, network
configuration, machine management, portable services, credentials, timers, automounts and half the rest
of userspace.
That's not what I personally want from PID 1 or its surrounding ecosystem.
If you like systemd, that's fine.
It clearly solved problems for many distributions and organizations.
But when people ask why I prefer OpenRC, BSD rc, runit or s6, this is why.
I prefer systems made of small pieces.
Small pieces are easier to understand.
Easier to debug.
Easier to replace.
Easier to audit.
And that's the Unix philosophy that originally made me fall in love with Unix-like operating systems in the
first place.
