Principles aside, in reality, systemd has been a complete non-issue for me and a massive quality of life improvement for Linux as a desktop operating system.
Is it not possible to turn off things like systemd’s DNS server, etc? I imagine if you care about such things you should be able to reconfigure your OS to use something else instead.
It is possible to disable stuff like systemd-resolved or systemd-timesyncd but it takes extra work which should be done by installing another package that accomplishes the same task (unbiound, chrony) just like as one MTA replaces another on Debian.
However, you ask a good question. Lots of people do like it, supposedly. But I think there's a large clue to its controversial nature in that people still call it an "init system", and pointing out that it isn't is interpreted by some as an attack.
Basically, it started out as an init system, which was used by Red Hat / Fedora, which was positioned well at a time when certain distros, notably Debian, used crufty SysV init scripts which they wanted to move on from. When Debian adopted systemd, after some debate, every Debian-based distro did too. This wasn't considered a particularly invasive change at the time. But systemd started to expand into its "middleware" position, absorbing vital system functions like udev. Distros which adopted systemd found themselves along for the ride, while distros that didn't increasingly found that software was starting to break, forcing them to maintain forks, or chisel out the piece of systemd that made it work and run it standalone. So was created a network effect that forced even more distros down the path of least resistance into systemd.
Meanwhile, amidst all the grumbling that this bait-and-switch was provoking, the systemd project leaders had an astonishingly bad attitude towards the maintainers of software that they were breaking, which fomented considerable personal animosity on top of the technical resentment. Not only were they driving a horse and cart through the standard ways of doing things, breaking a lot of stuff in the process, they were being rude about it.
So, more or less, people resent systemd because it's difficult to find - or build - a distro without it.
Your timing is off. udev became part of systemd in 2012. The big Debian debate was in 2013-2014, and was acrimonious enough to eventually cause several of the CTTE members to resign their position over it. One of the core issues driving the Debian systemd debate was the fact that GNOME was planning on dropping support for anything other than systemd-logind (or something like that), and there was definite concern that packages were already making decisions that were forcing everyone to adopt systemd as the only init system.
I eagerly await the publication of "SystemD: A History" and its subsequent adaptation into a dramatic screenplay.
Not true. From the start it was positioned as much more than an init system. This is clear just skimming the blog post announcing systemd http://0pointer.de/blog/projects/systemd.html
Among other things, it talks about:
-deferring launch of some services until they are needed, to speed up boot
-launching additional services and shutting down others in response to hardware changes (e.g. adding a usb device).
-taking some or all socket management away from daemons so that sockets can be ready before daemons are live or daemons can be shut down when there is no activity
-“babysitting” services including through cgroup based process management
-managing (some of the) access to /home and other directories
It’s quite a broad scoped announcement. Toward the end there is a “short list of other features”, numbered, ending at 20. Under “Where is this going?” he writes, “ The feature set described above is certainly already comprehensive. However, we have a few more things on our plate.”
systemd clearly started out as a broad based solution, and reading through that post, looking at the problems it addresses, and considering that launchd and upstart tackled similarly many issues, it’s clear why it is so broad - the world has changed. In the 70s on a pdp 11 it was sufficient to launch some daemons at boot, keep an eye on getty, and call it a day. Maybe ~50 years later a new, more comprehensive system makes sense? When Linux runs laptops and phones that are endlessly reconfiguring themselves in response to network, Bluetooth, usb, when systems are sleeping and waking routinely, when vastly more services run on a single machine, when conserving battery is important, when boot time can be reduced to seconds if things are better orchestrated? “standard ways of doing things” have changed in every other sector of society, basically, why wouldn’t they finally change in OS service management?
Now, no one will argue that systemd's service management capabilities far exceed what most historical init systems did. Heck, the traditional init system had interior service management to window's Service Control Manager implementation, since the classic init could not for example give a list of running services. And systemd is far more flexible and feature rich than Window's options now.
systemd-boot and timedated on the other hand are pretty darn disconnected from anything a classic init system was concerned with. It does feel like a lot of the non service/mount management parts of systemd are basically a grab bag of random stuff.
It was pretty invasive - I tried to keep using Debian without systemd, but indirect dependencies always brought it in. Until I switched to Devuan.
And the dependencies brought in EVERYTHING. You could no longer mix and match, pick one part from here if it worked for you, and another part from there.
Which lead to the criticism that "systemd is not modular". Which Poettering denied, pointing out that there are modules at systemd-compile time, completely missing the point.
> So, more or less, people resent systemd because it's difficult to find - or build - a distro without it.
And I wouldn't have minded systemd as an INIT SYSTEM - the existing scripts WERE pretty bad. But systemd is like the Borg - it tries to assimilate everything. And it broke quite a bit of existing functionaility along this path.
Red Hat produced systemd. Red Hat is the major contributor to Gnome. Gnome now refuses to run without systemd. Every major distro wants to carry Gnome, so...
Well, at least some distros offer a choice. Some other distros (Alpine, popular for containers, Void, which powers my laptop) live happily without it. Various shims exist, logind exists to allow running things like Xfce without systemd.
Is that true? The gentoo documentation says that you can chose your init system independently of your desktop manager, and puts openrc+gnome as an example:
https://wiki.gentoo.org/wiki/GNOME/GNOME_Without_systemd/Gen...
You can also install GNOME on OpenBSD, which of course does not run systemd.
> After the transition from GNOME 2 to GNOME 3, configuring GDM is only possible through systemd as it no longer supports other init systems.
https://access.redhat.com/documentation/en-us/red_hat_enterp...
You can see the same effect in e.g. politics.
It's one of those situations where the minority that doesn't like systemd is just a lot more noisy than the vast majority that likes it.
Easy as that.
The majority of people don’t give a hoot about it.
The short answer is...Red Hat has money and threw it behind systemd. Like them or hate them, they are in many ways the deciding fate of Linux systems. So, other distros fall in line. Ubuntu is a contender, but gave in and followed suit too.
Void and Solus are both good distros that don't use systemd. I'd go as far as to call Solus the best out of the box distro ive ever used.
IIRC the required parts of systemd are pretty much init-related, service-related (as in starting/stopping services based on certain conditions), udev and journald (which can and is often defaulted to forward to syslog).
Comments like yours make it seem like resolved, homed, nspawn, machinectl, networkd, cgtop, and all of the other utilites and optional daemons are required. They seem more like konquerour in your KDE analogy as in that they are nice if you want to buy into the whole ecosystem but by no means required to use the core program (and many seem to use alternatives instead).
I'm by no means an expert on this, so please correct me if I'm wrong.
[note] It describes itself as "a suite of basic building blocks for a Linux system" - although in my opinion that implies more modularity than it posesses.