[imtringued]

I could have gotten behind the first three paragraphs until you started mentioning systemd. After that everything you've written sounds like the rambling of a crazy person.

systemd won the init system wars because it is pretty damn good from a technical perspective. The competition didn't even try to participate.

>Barely functional, broken in inane ways, and leaving any professional in a situation of endless masking of a myriad of barely cogent and horribly malign services.

Everything you're complaining about was even more true of previous init systems and barely true for systemd at all.

Meanwhile Ubuntu is a garbage fire from a technical perspective. Snaps are garbage and forced down your throat.

[b112]

systemd won because of politics, and absolutely nothing more. Debian, the root of the most used tree of Linux distros, only adopted systemd due to pressure from Redhat/Gnome, and threats that if it didn't?

Gnome would no longer work on Debian.

Understand, that many of the issues "resolved" by systemd, were redhat issues. And further, not even init issues.

For example, the most predominant being "predictable NIC names", which were already a thing with Debian. Or bootup times, of which Debian had excellent parallelization and boot times of a similar scope to how "fast" systemd was.

There's really nothing good, from a technical perspective, when something is enlarged 1000x the requirement. If you look at the code for sysvinit, it's maybe 10k lines. Systemd is > 1M lines of code, likely approaching 1.5M by now. So I suppose, 100x the size.

It needs to be understood that the more code you have, the more bugs. It's just the way it is. There have been more security issues in core systemd yearly, than sysvinit in its entire lifespan. That's not even systemd's fault, it's just a simple fact, you have more code, you have more bugs.

And when you say "systemd", you're likely referring to all the inane nonsense it does? How broken it is managing mounts, which really isn't an init's job anyhow? Or the absurd nature of having shutdown and startup identical, with automatic ordering, so you end up in all sorts of ridiculous edge cases?

Why would anyone presume that start and stop MUST be mirror images of each other. The very logic is broken, and shows an immense lack of comprehension of how the real world works.

And you speak of "it won" for superior this and that? At the start, it didn't even have an easy way to extend stop time. Hell, even now it just sends SIGTERM and a nanosecond later SIGKILL, as if shutting down a box FAST FAST NOW NOW is more important that data integrity or properly closed tcp connections or processes doing any form of proper cleanup.

The number of mysql/database issues caused by this behaviour in the early days was insane.

Look, I get you like systemd. But it's provided no real value, and certainly, even if there is some? The detractors outweigh it as the sun turns meat to leather.

[tristan957]

> There's really nothing good, from a technical perspective, when something is enlarged 1000x the requirement. If you look at the code for sysvinit, it's maybe 10k lines. Systemd is > 1M lines of code, likely approaching 1.5M by now. So I suppose, 100x the size.

The systemd repo is a mono repo for other tools in addition to the init system.

I've heard from many sysadmins and distribution maintainers that systemd has been amazing. We went from ad hoc shell scripts to declarative plain text files. I think that's a huge win.

[bayindirh]

b112 wrote a substantial comment already, but I'll give a single line summary:

yes, systemd changed how I manage my systems, but it didn't bring in speed, safety or integration I didn't have before them. Moreover, they brought out secure-boot related shenanigans in house and integrated to everything it touches. Before that the line was drawn at the bootloader.