Something I've realized about systemd...

KGIII

Super Moderator
Staff member
Gold Supporter
Joined
Jul 23, 2020
Messages
11,499
Reaction score
9,995
Credits
95,342
Before I get to the meat of the matter, let me first state that I absolutely love systemd. I've learned to use it. It works well. There are few legitimate complaints and many of the earlier complaints turned out to be just people spreading FUD.

But, and I know that systemd has bloated its way well beyond being an init system, there were other init systems at the time. Those init systems still exist and people still use them. I'm noticing a problem that I didn't think of at the time, back when systemd was new...

We're losing knowledge. Those people not using systemd are limited in who they can ask for help. The knowledge is fading fast, as well. I've forgotten much of what I once knew about init systems that predated systemd. I see people ask questions and get fewer responses when they point out that they don't use systemd.

This is to be expected - but I never thought to expect it.

Let's face it, we've mostly standardized on systemd. With that comes the loss of familiarity of other options. With that comes a much smaller pool of people able to help.

I dunno if it matters. Sure, it sucks to be them, but they are the ones that decided to avoid systemd.

Anyhow, it's not something I thought of when the great systemd debates were taking place. I don't think any of us thought about it, even though it's nothing new. Give a random person a computer that boots to DOS and see how well they operate - even if they get to ask for help from their peers.
 


I like it for the fact with journalctl there is a straight forward way to access logs and specific ways with flags to drill down to get straight to any issues
 
The only difference I notice is some users aren't complaining about systemd taking over as they were in the beginning.

Systemd or init I can't tell a difference between the two.

Guess ya hafta be a true Linux geek to see tell a difference.
 
It is similar to when Grub took over from Lilo - The pool of distro using Lilo shrinks and I doubt you can find a dozen people today who could talk you through Lilo setup. Even though it worked very well at the time. Most likely still would.
systemd added some good features. How be it it's bloated in my opinion. The real problem back when it was introduced wasn't that it was not capable but that it was forced on communities and people had no say in the matter it simply appeared and no choice was given at all either use it or loose the Distro you've been using. Then the Developer over reacted to criticism and caused the problem and miss understanding to be worse that it needed to be.

Though I don't put a lot of stock in Distrowatch hit list you will notice that MX-linux has been on top and it is one of the only distros that give users a choice in Init systems. Is there a correlation don't know but worth the thought.

As for KGIII's premise that the knowledge of Init system other than systemd are loosing members who can help with them I guess that would be inevitable over time as more and more Distro turn to Systemd. Good or bad that's the way it is.
 
Systemd or init I can't tell a difference between the two.
That's because they're the same; systemd is an init helper tool, and init is the first process started during booting of the computer system. It is also a daemon process that continues running until the system is shut down. Some others init helper tools are SysV, runit, openrc, upstart and a couple more.
We're losing knowledge. Those people not using systemd are limited in who they can ask for help.
Not sure this is entirely true. I mean, there's still the guys from MX/Antix, Devuan, Gentoo, and some other few distros I don't remember now. So, yes, maybe they're not as many as the ones using systemd, but then I guess not many people run those anyway and those who do are probably using the aforementioned distros, so they should be asking for help in their respecting forums.
 
The real problem back when it was introduced wasn't that it was not capable but that it was forced on communities and people had no say in the matter it simply appeared and no choice was given at all either use it or loose the Distro you've been using. Then the Developer over reacted to criticism and caused the problem and miss understanding to be worse that it needed to be.
Similar to what Canonical is doing / has done with Snaps.
 
I guess not many people run those anyway
On a second thought
1656442354849.png

MX Linux is quite popular, however, it's #1 on that list, but the other 9 are all Systemd based distros.
Antix (16) and Slackware (15) are among the top 20, and both use System V. Also, this comparison chart https://wiki.gentoo.org/wiki/Comparison_of_init_systems has some interesting facts, and if I'm reading that right, then it seems that OpenRC and Systemd are the only ones full-featured. The rest lacking one or another, like Cross-service dependencies/events and Per-service configuration. I personally prefer Systemd; easier to use - no need to fiddle around with scripts, tho it's possible via services' files, too.
 
Oh, with the mention of GRUB, I'm reminded that 'systemd-boot' exists - but I don't think too many distros use it *at this time*. I first heard of it from some distro devs, so I'm not sure how much longer that'll be true. Though, really, GRUB just works and I like it. As memory serves, systemd-boot is actually easier than GRUB. So, there's that...

I think there's a bit of a trend there, with things like systemd (and even the mentioned Snap applications). If developers find it easier and/or more efficient, they use it. Unless we want to be developers, we're gonna go with what they go with. I mostly know how to build a distro and I'm sure I could figure out anything I don't know (as well as get help from others), but I'm not gonna. Most everyone here isn't going to.
 
One of the problems with systemd is that, although the promise was good (standardise the lifecycle of the system services and their logs), the implementation is plain horrible.

It should have followed a pattern called inversion of control (or dependency injection), where your code stays free of dependencies, and systemd calls it when needed through a standard interface (<-- this is the inversion of control part), sypplying what else would be needed, if any (<-- this is the dependency injection part).

If you are a service provider to a system that follows IoC, you can simply develop a "wrapper" on your own code that is systemd compatible (e.g.: a script), and therefore your service keeps working for both Initd and systemd.

But instead, that depcoupling layer wasn't promoted, designed, prescribed or expected, and somehow more and more parts of the system are coupling themselves to systemd as a result. This is leading to a monolithic status of the whole distribution where, if you want to pull out systemd, you end up dragging half of the system utilities. As a result, if you want to have a systemd-free system, you depend on the community effort on forking system components that are tighly-coupled to systemd, and rearchitecting them to be independent.

And, as systemd grows in a sort of amoebic fashion, engulfing more and more tools and system functions beyond its initial scope, this becomes more and more of a problem.

And this is complicated by the attitude of the lead developer, that refuses to walk down his particular hill and collaborate refining the implementation to be less of a problem. This is what leads many to think that the tightly coupling is an ill-intended feature more than a side-effect of a poorly driven implementation.
 
Last edited:
I remember the days of init, but I rarely dabbled, except to manage services here and there. Didn't get to know it all too well.

Many years later, and long since I've been an admin, I'm ok with systemd. That, even though it does want to be all things related to services, and veers away from the "everything is a file" concept.

Operating systems evolve, whether that means new features added to an existing application, or the application being supplanted altogether.
 
I'm reminded that 'systemd-boot' exists - but I don't think too many distros use it *at this time*
I think Fedora and Arch do. It only works in UEFI systems.

But instead, that depcoupling layer wasn't promoted, designed, prescribed or expected, and somehow more and more parts of the system are coupling themselves to systemd as a result. This is leading to a monolithic status of the whole distribution where, if you want to pull out systemd, you end up dragging half of the system utilities.
From here https://docs.fedoraproject.org/en-US/quick-docs/understanding-and-administering-systemd/
Systemd is a system and service manager for Linux, compatible with SysV and LSB init scripts.

I've never done it or even tried to remove systemd, but I think systemd utilities and system utilities are not the same; if you remove it, you'll only remove its "things", it won't remove bash and/or any of the GNU tools. Check in here to see what's installed: https://archlinux.pkgs.org/rolling/archlinux-core-aarch64/systemd-251.2-1-aarch64.pkg.tar.xz.html
Of course, removing its "things" such as systemctl, journalctl, and the rest of "ctl" tools, means you'll have to replace them with something else like SysV or OpenRC, or you could even write your own init helper scripts to regain some of the same functionality.
 
I think Fedora and Arch do.

Hmm... Thanks! I honestly hadn't noticed as my only Fedora use has been VMs for testing - and they've never broken to the point where I had to worry about that.

But, if it's in Fedora, I wonder if/when it'll make it into RHEL?

I mentioned that there are only a few (that I'm aware of, and I paid attention during the battles) legit complaints as far as I'm concerned - and one of them is that It has grown into far more than an init system, taking control of more and more aspects of our systems.

Devs still seem to like it, so it's gonna get used, with this being true for systemd-boot as well.

But, I've read some good things about it - words like 'simple' and 'easy'.
 
I only use the NordVPN browser extension. I'm not sure why I stick with Nord... They still haven't even built a GUI which should probably take like a day to write in Java or something. Seriously...

But, the browser extensions are pretty solid. So, I just use those.
 

Staff online

Members online


Latest posts

Top