Nah, it's fine. Boot times are considerably faster than sys.v in most cases, and it has a huge amount of functionality. Most people I work with have adopted it and much prefer it to the old init.d and sys.v systems.

People's problem with systemd (and there are fewer people strongly against it than before) seem to break down into two groups:

1. They were happy with sys.v and didn't like change. Some were unhappy with how distros adopted it. (The debian wars in particular were really quite vicious)

2. It does too much. systemd is modular, but even so does break one of the core linux tenets - "do one thing well". Despite the modularity, it's easy to see it as monolithic.

But regardless of feelings, systemd has achieved what it set out to do and is the defacto choice for the vast majority of distros, and they adopted it because it's better. Nobody really cares if a user tries to make a point by not using it any more, they're just isolating themselves. The battle was fought and systemd won it.

The traditional init systems suited me just fine, i saw no need to change them. If they were so bad, then they could've been fixed or replaced.

The migration to systemd felt forced. Debian surprised everyone with the change. Also systemd's development is/was backed by corporate Red Hat, their lead developer wasn't exactly loved either and is now working for Microsoft. Of course Canonical's Ubuntu adopted it as well. Overall feels like Windows' svchost.exe, hence people accusing it of vendor lock-in.

It's not just an init system, it's way waaay more. It's supposed to be modular, but good luck keeping only its PID1 in a distro that supports systemd. It breaks the "do one thing right" approach and, in practice, does take away choice which pisses me off.

I had been using Debian since Woody, but that make me change to Gentoo on my desktop which, to me, took the best path: they default to OpenRC but you're free to use systemd if you want to. That's choice. For servers i now prefer Slackware and the laptop runs Devuan whenever i boot it up.

To be fair systemd hasn't shown its ugly face in the Ubuntu VMs i'm forced to use at work.

YMMV. If you're happy with it, fine. This, of course, is only my opinion.

Ok, so I have a very unique background in systemd. I worked at Red Hat supporting it basically as the primary support and I've worked with the developers of systemd at Red Hat directly. I no longer work there.

So first off, it's "systemd" all lower case. I don't care, but for some reason Lennart Pottering (creator) does.

systemd was a MASSIVE change. And Red Hat did a TERRIBLE job relaying it. To the point where I'm still trying to get my company to understand that it can NOT be treated like the old init systems. You can NOT just drop an init script in place and walk away and hope it works. Because a LOT of times it doesn't. Due to forks, switch users, etc.

systemd is NOT an init system. RHEL 5 and older had sysvinit as it's init systemd. RHEL 6 had UpStart as it's init system and looked exactly like sysvinit that no one even noticed. systemd again is NOT an init system. Init system is 1 part of systemd. systemd does a lot of cool things. It bundles applications together, it manages those applications and can restart them or kill children, it can do resource constraints, it separates out users from the system, and lots more.

Because it is not an init system there is a LOT LOT LOT of bad recommendations out on the internet where someone has X problem and person suggests Y and IT WORKS! ... except it doesn't REALLY work as far as systemd is concerned and you'll hit other issues or your application takes longer to start or stop and people just blame systemd.

It is systemd's fault that it has done an ATROCIOUS job of helping people adapt. It's a great example of RTFM. systemd's man pages are INCREDIBLE and extensive, but when you drop so much knowledge it becomes more difficult to find what you want/need. systemd.index and systemd.directives are your best bet.

So systemd does a lot of amazing things that sysvinit never attempted to do. It's never attempted to explain anything it expects everyone just learn magically. it's INCREDIBLY complex, but once you understand it's basics you can more easily get an application running, but as soon as there's a problem it'll just break your brain.

To give you an example, sshd's old init script is like 250 lines of bash. systemd's unit file comparative is like 12. Because systemd handles a LOT of what you manually had to handle before. BUT to get to that 12 you literally have to learn EVERYTHING new.

There is no "is it good or bad" here really imo. It's a completely different fundamental design. Red Hat made it for themselves. Other distros picked it up. It can be argued that lots of folks followed Debian and Debian had a few Red Hat board members that were pushing it. Whether they pushed it of their own accord or because they were with Red Hat I don't have a clue.

What I can say is at my current company they're suffering from a LOT of systemd issues and they don't even realize it. I've been working with Red Hat to try to get Insights to alert people to the failures and we're making progress.

To see if you have issues just to start run the two following commands:

# systemctl list-units --failed
# systemd-cgls

If you have any units that are failed, investigate those. If you don't need them, disable them. As for the systemd-cgls this shows HOW systemd is grouping things. ANY application that runs as a service (or daemon or application or runs in the background or however you wanna say it) should be under system.slice. ONLY humans logging into the system (meat bags NOT applications switching to users) should be in user.slice. A LOT of times what happens is an old init script is dropped in place, they start it, it has a switch user and systemd assumes it's a user and puts it into user.slice. systemd does NOT treat anything in user.slice the same as in system.slice and this WILL eventually cause problems.

So again, is it good or bad? Eh. It does a lot of cool things, but they did a MASSIVE disservice to ALL of us by just expecting to relearn absolutely EVERYTHING.

1. systemd hasn't become a better project built by better, smarter people to deliver a better set of features. It's still hot garbage.
2. it's okay to continue pointing out it's hot garbage, in the hopes we can go forward or back or just get on something better/else (same thing).

1. Is the current SystemD rant derived from years ago (while they’ve improved a lot)?

No it's almost always been derived from people's behinds.

2. Should Linux community rant about bigger problems such as Wayland related things not ready for current needs of normies?

Yes.

Systemd is spectacular in many ways. Every modern OS has a process management system that can handle dependencies, schedule, manage restarts via policy and a lot more. Systemd is pretty sophisticated on that front. I've been able to get it to manage countless services in many environments with great success and few lines of code.

Keep in mind that it all started 20 years ago with Pulseaudio. Pottering was not really a nice guy (on mailing lists ofc, I don't know him personally) whose software I wanted on my machine.

Problem was never speed or even technical, problem was trust on original author and single-mindedness that they were promoting. Acting like it is the only way forward, so anyone believing in freedom part of free software was against it. Additionally, it was looking like tactics used by proprietary software companies to diminish competition.

It looked scary to some of us, and it still does, even worse is that other software started having it as hard dependency.

All of this looks like it was pushed from one place: Portering and RedHat.

While after 20 years I might have gotten a bit softer, you can imagine that 15 years ago some agresive and arogant guy who had quite a bad habbit of writing (IMHO) stupid opinions wanted to take over my init system... no, I will not let him, not for technical reasons but for principal.

I want solutions to come from community and nice people, even if they are inferior, I will not have pottering's code on my machine so no systemd and no pulseaudio for me, thank you, and for me it is an important choice to have.

Not against systemd (although it’s bad and needs replacing), just against pottering.

Just try to implement user session management on a non systemd distro...

Systemd is way better than others init system. I'm using Alpine Linux on my phone and I really wait for a Fedora/Arch like PMOS project (it's on the way)

The problem of systemd is that it hasn't been just a replacement of init as they initially claimed, and now deny they ever did. Things like Mono, Gnome and systemd are bad for the ecosystem long term.

An init done by constructive people wouldn't be a problem at all.

Speaking as someone who uses OpenRC on all my machines . . . no, systemd is not necessarily slow, and personally I don't care about the speed of my init system anyway. Thing is, systemd also has nothing that makes it more useful to me than OpenRC, so I have no incentive to change. Plus, I dislike the philosophy behind it, the bloat, and the obnoxious behaviour the project showed when interacting with others in its early days. I'm a splitter, not a lumper, and systemd's attempts to absorb All The Things strike me as rather . . . Windows-like.

So, in a technical sense I have no reason to believe that systemd is inferior to OpenRC + sysv, and it may be superior for some use cases which are not mine. I don't spend a lot of time ranting about it, and I see no point in trying to convince people not to use it if it fits their needs. But I still won't use it if I have another option.

As a guy that's been installing Linux since you had to compile network drivers and adjust the init scripts to use them; SystemD rocks.

It would be fine if it kept to system init rather than growing like a cancerous tumor.

https://wiki.gentoo.org/wiki/Hard_dependencies_on_systemd