> Systemd as a project run by people abuses this confusion. In the minds of most normal people, when you prefix a name with another name, you're implying a deep association. Apple Watch, Apple iPhone. Systemd Journal, Systemd resolver.
The confusion is your own. You somehow came to believe that systemd is a project that only builds an init system.
You could have come to the same confusion with apple, to use your example; you could have thought "Apple only makes ipods.. wait, they're making phones? Apple's abusing confusion by doing more things".
The systemd project is fairly similar. All those things are closely related; they're made by the same people and work well together. They are not all related to init, just like everything apple makes isn't related to the ipod or the apple II or whatever the first product of theirs you heard of is.
> they point at it being "modular" (despite it being a rapidly moving target with no real alternative replacements - i.e. modular in the purely theoretical sense of the word), and then take criticisms of the individual parts as criticisms of the whole in an attempt to shout the detractors down strawman-style.
That does happen some, but I think that's largely because the detractors of systemd constantly turn criticism of any small component to criticism of the whole thing. It's the same fallacy in reverse.
Also, systemd is not modular in the sense that components are perfectly interchangeable; rather the majority of systemd components are optional and you can keep using whatever you were before (e.g. journald has a configuration to forward to rsyslog or whatever your old syslog daemon was and to not save on disk, thus being as before, resolved is optional, timesyncd is optional, networkd is optional, etc etc).
All of that optionalness is not theoretical. There are distros that take advantage of it, including to the extreme of running full linux systems with no systemd at all.
> Most of the problems with systemd can be chalked up to its leadership and utterly toxic cultural impact, rather than its technical merits (or lack thereof).
I think the toxic cultural impact is a huge problem with systemd, but that impact came not from systemd, but from trolls around it, from people spreading FUD, etc. I don't actually think the systemd leadership or project has actively worked to create such an environment, but rather all of systemd's detractors have intentionally made it a polarizing and political subject which resulted in a toxic environment.
Proving this in either direction is near impossible unfortunately, so we could each see different reasons for the same environment.
> creeping monstrosity that keeps eating services that have worked fine for decades in the name of objectively worse replacements
If it's objectively worse distros wouldn't be adopting it. Have you ever read syslog-ng's code? bind's? glibc's? Have you ever configured your network with rc scripts and hacks? Have you then tried to do the same network configuration on a different distro and found it to be different?
It's clearly better in some metrics in that distros have switched to it.
Because of the cultish political toxicity around the project, all of systemd's issues get amplified a hundredfold and make a perception of it being worse, but people only rarely see the convenience and benefits it brings.
> Did name resolution, NTP, and so forth really gain anything tangibly meaningful from their assimilation
Networking gained consistent configuration formats which don't vary by distro. ntp didn't really change meaningfully (though I like that it's an ntp client, not a client and server bundled into one for no discernible reason).. it did gain better man pages and a better CLI, but that's only a small detail.
Name resolution gained a number of security features that typically weren't available,
Networking in general gained ordering with services, which was nearly impossible before and was typically powered by luck and spit.
> We did not need yet another new NTP, DNS, cron, logger, auditd, and fucking QR code library tied into the system internals!
Maybe, maybe not. It turns out that once you're starting, restarting, and managing FDs for processes, it's really convenient to also integrate with a logging system, and syslog was utter garbage for that sort of integration.
Once you've got the facilities an init has for starting and stopping processes, it's also pretty natural to do a cron-like thing; that's just starting and starting processes too (and timers are much more featureful than cron, including things like '4 hours after the last time this exited', random skew, and much more readable formats).
Once you're managing processes, it also kinda makes sense to manage containers; afterall containers need something to start/stop/manage them too...
and once you're managing containers, networking tools, logging,and so on make even more sense.