hpr-knowledge-base/hpr_transcripts/hpr3903.txt

Episode: 3903
Title: HPR3903: Why I don't love systemd (yet)
Source: https://hub.hackerpublicradio.org/ccdn.php?filename=/eps/hpr3903/hpr3903.mp3
Transcribed: 2025-10-25 07:44:48

---

This is Hacker Public Radio Episode 3903 for Wednesday the 19th of July 2023.
Today's show is entitled, Why I Don't Love System D Yet.
It is part of the series' information underground.
It is hosted by Deep Geek, and is about seven minutes long.
It carries a clean flag.
The summary is, Clotu reads a script by Deep Geek about System D.
Hey everybody, this is Clotu, but I'm not speaking as Clotu today.
I am speaking as Deep Geek.
This is a script for an episode that Deep Geek sent to me and requested that I read more
or less in his voice, except not literally in his voice.
I don't do impressions.
So here it is.
This is him.
This is Deep Geek, not me.
I don't like System D yet.
I've been meaning to put down my thoughts about System D for the HPR community for some
while.
So here it goes.
I want to say that I'm not a System D hater.
When System D was a hot topic of debate, many became irrational over it.
But I want to start by saying that I don't think it's a bad technology.
I think it's a rather good technology.
I just don't want it on my personal computer.
So I'd like to run things down in this order.
What is it, as in what is it really?
What makes it a good technology?
Why I don't want it now, but might later.
And a few tips for you if you decide that you don't want to use System D yourself.
System D is not an init system.
System D includes an init system.
System D init was faster than sysv init.
That System D init isn't the fastest init system.
And sysv init now has a parallelization helper at least on Debian.
So if System D init is not System D, then what is System D?
To understand this, we must first understand something about Linux.
Linux operates under a model where there are root processes and there are user processes.
These two kinds of processes are usually called layers.
System D is actually a third layer.
This can be called a system layer.
So when System D is added to a Linux system, that changes the system so that there are three
layers.
A root layer, a user layer, and a system layer.
As such, you now ask System D to set how the system runs.
This is why System D includes things like an init system.
Because if you want to change what the system is running, you ask System D to change it.
System D then messages an appropriate system to implement the change.
Like messaging it's init system to bring up or bring down a system demon.
Once you play out this in your head of it, you really realize that System D acts more
like a message passing system in a certain aspect.
So why do I say System D is a good technology?
Because this can standardize system control.
Without System D, a fleet of computers becomes like individual fingerprints or unique snowflakes.
If you manage many computers as many professional IT people do, you want them to all run the
same.
All have the same profiles and general configurations.
So if you have a bunch of computers, you are running.
You can run a lot more if they are all running the same way.
If your job requires you to run 10,000 web servers, you want them to run identically because
it is impossible to keep an understanding of 10,000 unique configurations in a human head.
System D really shines in its support of virtualization as well.
So to speak of servers, I used to run an email server for a few friends.
Each of us had a user ID and number as Unix users.
The mapping of Unix user IDs and post-fix user IDs can get confusing when it gets really,
really big.
Thanks to System D's virtualization work, you can actually put a service like email into
a namespace situation.
So it has only the user's root and the demon user ID like post-fix.
So System D greatly enhances security for server installations.
This might help explain its dominance in Linux distributions that have been traditionally
server-centric like Debian and Red Hat.
So why don't I want it?
Well, I've been doing a lot of talking about professional computer work and corporate
work environments, but I use a personal computer as a hobby.
I've been out of industry for decades now, and when I say personal computer, I'm not
talking about a hardware specification, rather, I'm talking about this is my personal
computer where I do things my way as opposed to my work computer where I do my companies
way.
Dear listener, please remember that I did the first community show contribution to
HPR and my topic was about personalization.
For me, a hobbyist interested in operating system experimentation, I don't want a system
layer.
I want a traditional Unix-like system that operates on a two-layer model and does things
my way, nobody else's way.
So what advice can I give to those who don't want System D now?
Well, recently I've left Debian.
Debian, you see, supports init system diversity, but as you now know, dear listener, that
is different than being without System D. You may have heard that System D is Linux-specific.
That is to say that it runs only on Linux, not anything like BSD or Windows.
But what you might not know is that it is also GNU-Lib-C-specific, which means that
the C compiler must use GNU-Lib-C standard library.
Thus, if you have a system built around the Musil-C standard library, like on Alpine
or Void, or a system like Android that runs on the Bionic-C standard library, you won't
have a System D system.
I'm personally learning Void as its package manager supports both Binary and a Port's
collection, much like the BSDs, but that's what I'm doing on my personal computer.
I leave you with the freedom to do things your way on your personal computer.
This has been Clat 2, reading a script by DeepGeek.
These have been DeepGeek's thoughts and words, not mine, although frankly, I agree with
everything he has said, except his use of Void Linux, of course, I'm a Slackware user,
but the Spirit certainly, I agree with what he's saying about System D, about layers of
the system.
I think that was really great insight.
I hope you enjoyed it.
Thanks for listening.
You have been listening to Hacker Public Radio at HackerPublicRadio.org.
Today's show was contributed by a HBR listener like yourself.
If you ever thought of recording podcasts, then click on our contribute link to find out
how easy it really is.
Hosting for HBR has been kindly provided by an onsthost.com, the Internet Archive and
our Sync.net.
On this advice status, today's show is released on our Creative Commons Attribution 4.0 International
License.