Because it was originally advertized as an optional init replacement. The acrimonious debates were because a number of people did not believe that's all is going to be, given the history of its designers.
Of course, nowadays many people would flat-out deny that systemd was sold as an init replacement, and claim that what you see was the original intention all along.
For example many of the larger DEs use logind because it is good at what it does and consolekit at that time was not really active anymore. That meant that for example freebsd had to either make the DEs work with consolekit (and maintain it) or make a logind implementation work with their implementation.
This is one of the confusing things about the discussion. The systemd project very much follows the "unix way" in that there are lots of subprojects that do one thing well, but is developed in a cathedral style (just like the *BSDs are) and not easily reusable, which kinda loses the benefit.
More that ConsoleKit developers and logind/systemd overlapped. For GNOME, logind seemed better and used to be separate. A warning that it would not always stay decoupled was underestimated/ignored.
Once logind was tied to systemd all hell broke loose :-P
Having something like systemd is great; e.g. GNOME has various user services running. Nowadays systemd manages those user services. But as great as that is, it makes non-Linux more difficult. IMO systemd on Linux makes things very easy and it's better to standardize on it.
No need to use networkd for example, networkmanager works great along systemd.
Actually most my systems use only systemd and journalctl to my knowledge. I prefer my established tools for all other jobs.
I think systemd actually won when they absorbed udev.
Can you? The whole premise of systemd revolves around ability to use existing init files, written by upstream developers.
Upstream init files are going to use arbitrary parts of systemd functionality, which may include network and container management, timers and God knows what else.
So in effect you HAVE to use those parts of systemd — unless you are insisting on writing all your init files from scratch (at which point you may as well use any of systemd alternatives).
And unless you are working with e.g containerized services (which you create yourself), why would a service need anything from networkd? I have never encountered a unit file like that on my system, and I don't run anything apart from systemd and journalctl. No networkd (I prefer NetworkManager), no systemd containers, no systemd ntp. I wonder if I even have those installed, why should I?
And all my services run just fine.
It leaks into user land.
The alternative for systemd would've been to shutdown the system without waiting for a clean unmount, which can lose data, which is what used to happen with SysV. The alternative for you would be to unmount your filesystem yourself before shutdown, which is what people used to do with SysV. Some SysV distros even had scripts that tried to automatically clean up mounts before shutdown, which is exactly what systemd does now, and your 90-second hangs would've shown up there too.
> It leaks into user land.
Init has always been in user land.
There are many premises for which systemd was designed, but this is not one of them, let alone "the whole premise".
1. Before systemd, upstream developers were never precluded from supplying their own init files, and many often did.
2. Even in systemd, downstream maintainers and users were never precluded from modifying, overriding, or even completely replacing upstream-supplied init files.
The difference is that with SysV upstream-provided init files were often bad because upstream developers had to use a bunch of hacks in shell scripts to (necessarily reinvent and) supply features that were essential but SysV couldn't provide. The distro maintainers and users were thus sometimes _forced_ to try and fix upstream-supplied init files, but even they could do only so much because ... shell scripts on SysV.
Systemd allows everyone (upstream and downstream) to write better, cleaner, more maintainable init files.
> which may include network and container management, timers and God knows what else.
1. Timers are a core requirement of service management, and they're correctly a part of the service manager that is systemd.
2. network management (systemd-networkd, systemd-resolved, and .link, .network units) and container management (/var/lib/machines, machinectl etc) are _not_ service management features and are _not_ implemented in pid-1 systemd. I have also not seen any upstream package that used them. In fact, these features _cannot_ be used from service unit files.
> ... unless you are insisting on writing all your init files ...
It's not an all-or-nothing affair. It never was, not with systemd not with SysV.
> ... at which point you may as well use any of systemd alternatives
Only if you mistakenly believe that the "whole premise" of systemd was to disallow downstream of touching any unit files at all, which is false.
Not to mention, systemd is much better than the alternatives in terms of allowing the sysadmin to override parts of the config for a service without needing to merge in updates from upstream later on. I can just add an override for e.g. PrivateTmp=yes and if there's some update to the original unit file later on, it'll apply that update but it won't mess with my override that I set up.
With SysV I'm stuck with updates being a pain that I'd need to manually merge every time there's some change if I didn't want it to just nuke my changes.
It's a nice design rule for CLI utilities, it doesn't work for systems.
Similarly, curl supporting both HTTP and HTTPS is not a violation of "do one thing and do it well" - if you fail to support at least those two protocols, you've built a shitty tool.
It's best to consider "do one thing" in the context of "what does the user want the software to do". A web browser having lots of functionality baked in is not necessarily a violation of this principle if all of that functionality is used to solve one user problem (I want to view YouTube, or I want to use GMail). At that point, the factoring issue lies somewhere else - the definition of the web platform, etc.
Systemd attempts to solve very many user problems all at once, with varying levels of success, and other software packages have solved one or two of them at once instead. In that case there is a clear way to separate the ones that probably apply the "unix philosophy" and the ones that obviously do not.
The Linux kernel and related components themselves sort of violate this, but that's mostly a matter of necessity - super-modular microkernel designs have not worked out great in practice. However, it still is built around relatively narrowly-scoped drivers for individual devices or services, instead of massive Megadrivers that handle every component in your system. Your PC may have an Intel GPU integrated on the CPU die, but it's still using a separate video driver, and the video driver is probably separate from things like the compositor and the actual PnP layer beneath that detects what hardware you have.
If you look at the average USB device in Windows' device manager (this is probably true in Linux as well but I don't know how to dump the data), you can see a given device like a mouse or a phone is actually split up into a bunch of sub-capabilities exposed by the device, and those can each have their own driver. Same thought process there.
Realistically, one tends to take or leave an upstream package since picking and choosing pieces of it is far more work than a typical package maintainer takes on. Also, upstream design decision changes can make doing so problematic down the road.
Not necessarily. RHEL does not ship gummiboot, timesyncd or networkd for example; it uses grub, chrony, NetworkManager. On my raspberry pis running Debian I have systemd as pid 1, one runs ConnMan (it connects to wireless) and the other runs networkd (it connects to Ethernet).
Everybody does that. Are you using networkd? Every distro makes different choices and user can then further configure what they want to use.
You can already configure systemd as you like, there is no need to 'take it apart'.