Surely for each individual distro, they get to make their own decision about how to build their system.
I can’t stop you from hating, but if your pitch is that distros shouldn’t be allowed to make their own choices about what to include if you disagree… I guess your option is to start your own distro.
No linux distro was forced to adopt systemd. They did it on the merits, from their determination.
I have to strongly disagree on the last one. Systemd is pretty much a canonical (pun intended) example of a solution in search of a problem.
Systemd as PID1 is nice on merits. I wouldn't want to get back to sysv initscripts.
Everything else is incredibly hostile to practical unix philosophy and solely exists out of spite and politics. This is my opinion and I realize I'm in the minority.
How does that account for the distros using systemd-networkd, timesyncd, resolved, etc, where they’re separate binaries and services, instead of their predecessors?
If the other binaries aren’t better for maintainers and their users, why are they replacing other tools with them?
I think it's change for the sake of change. I think it's mostly politics coming down from Red Hat. How exactly I'm not sure, but I fail to see any sane reason behind replacing things that worked well for decades with new things that are oftentimes inferior on merits.
Anyway. systemd vs unix philosophy is an insurmountable ravine and I chose to stay in what I think is sane camp.
I think maybe it's worth considering the possibility that the things being replaced did not work well, and were replaced because the new options solved problems and user pain.
To pick on cron, just from my own experience:
"I wonder where this scheduled task is configured" -> "Lemme check /etc/crontab" -> "nope, I guess maybe /etc/cron.d?" -> "Nope, lemme check /etc/cron.hourly/daily/weekly" -> "hmm, not there... maybe I want `crontab -l`... or it's running as a user, lemme check that list and run through `crontab -l -u $USER"
Finding out that I didn't notice a cronjob was failing because the stock methodology for notifications is email, and relies on the system having SMTP configured and having MAILTO set in cron.
Realizing a cronjob wasn't running because some, but not all, of the cron options have character limitations like "the file name can't contain any dots".
The total lack of dependency management, so anything I wanted to run @reboot needed to handle its own dependency checks and sleeps to make sure I didn't say, try to run puppet before the network was up.
On the networking side, I started using Arch when the config flow was "edit bash arrays in /etc/rc.local". I've used netcfg, netctl, and now systemd-networkd. systemd-networkd is easier to reason about, easier to debug, more powerful, and more portable between systems.
As much as I don't want to, I have to admit you have merit here on all points.
My question though: how did we manage to run infrastructure using cron for decades and did not feel any of that pain?
My take on the answer is this. Failures: we have /var/log/something for this and typically it's obvious something is not being executed. Many files: yes, there are different configs but don't you remember where you typically put your cronjobs? For example I always use user's crontab, so this is where I would look for the job spec.
Dependency check is one of the main reasons for systemd as PID1 if not the main, so hands down, that's valid and true.
We did feel pain. You could mitigate the pain by never making mistakes (like by ensuring all your cron scripts log to somewhere in /var/log, or that you have alerting, or that you always put them in crontab).
But also what we consider to be painful has evolved. When all systems were to some extent a hand-gardened entity, maintained by some specific system administrator, it was easier for them to have a personal standard. It didn't matter if I used cron.d and you used crontab, as long as on our own systems we kept one method. Increasingly, servers are more ephemeral, more horizontally scaled, and more automated, and systemd timers are just easier to work with in that model.
In a decade or so, I'm sure we'll have further modified how we handle systems, and something else will come along that solves painful things about systemd.
I can’t stop you from hating, but if your pitch is that distros shouldn’t be allowed to make their own choices about what to include if you disagree… I guess your option is to start your own distro.
No linux distro was forced to adopt systemd. They did it on the merits, from their determination.