I have to wonder if this is some kind of statistical bias based on the type of engagement.
There are some people who are vehemently opposed to systemd, for a variety of reasons with varying degrees of merit. I think it's fair to say that systemd's developers broadly ignored those people, figuring out (correctly) that if they convinced a majority of distribution maintainers, and made the user experience for the average user smooth enough, that was actually going to be successful. As it should be: distro maintainers get to pick how their distros work, and users determine which distros they use.
And systemd has a clear sell for those groups: distro maintainers can standardize their service scripts, often just using what an upstream package author can write agnostically to distro, and users can handle the majority of base system functionality without having to pick things like "which of these cron daemons should I install".
I'd also add that systemd appeals to application developers (no daemon code, one file for all distros). And it appeals to sysadmins too (no more /etc conflicts on any package update! Modify any system service! etc..)
Which brings me to the question of which category systemd does not appeal to? I am guessing "minimalists" and "people who like things done the old way" - and those are simply not that numerous compared to others.
> pick things like "which of these cron daemons should I install".
And we're back at it: systemd seemingly has plans to eliminate cron. I was not impressed when I have been pulling my hair out on why certain jobs in Ubuntu still run despite being removed from cron files. Turns out, systemd now has 'timers'.
So, mark my words: a few Ubuntu releases down the line, cron will become an optional package and after a couple more it won't even be available.
Many parts of systemd were available for long time but fortunately were not used in distros. And then out of the blue Canonical decided that socket activation for sshd is the way.
Yes. Systemd timers are an order of magnitude better for the average distro maintainer and the average user than the various ways of invoking and running cron.
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.
Related, it's also blatantly ignoring that it's the first software that even allows interoperability in its space, and was thus in huge demand by both developers and administrators.
(Edit: Other anti-systemd rant sites sometimes mention these obliquely as "upstream dependencies" and "workplace-mandated", while ignoring the fact that those people have reasons to demand those things)
But HN really doesn't need to litigate this all again.
Conformity is not interoperability. If anything, systemd is like Chrome, so popular that it persuades people to drop interoperability outright and just run with its nonstandard APIs.
Upstart and OpenRC both came years prior. As a matter of course anything which was self contained and standardized could have allowed interoperability. Systemd just actually convinced everyone to standardize not least because its integration with other parts of systemd provided both a carrot: standardization and simplicity for distro maintainers and a stick: the extra work required to use only part of it or especially if one used none of it and was expected to both write ones one unit files AND integration with stuff like gnome which was and remains the most popular singular GUI.
I (and this applies both with my dev hat and with my admin hat) can now write a unit file, depending on a different unit file, that works the same across all distros (note that this includes random end users whose systems I don't directly have access to). This even works for services that start per-user; no more write-only modifications to user startup files or DE-specific autostart dirs.
Pre-systemd this was unthinkable.
(similar stories apply to non-systemd-proper parts of the systemd project, but I personally haven't used them as much)
in the bad old times, every linux distro implemented its init scripts in a slightly different way, often with distro specific tooling and commands for accomplishing most management tasks
systemd unit files require minimal modification by distro repackagers.
With SysV-init, it was/is necessary to modify /etc/init.d/servicenamed shell scripts to get consistent logging and respawning behavior. With SysV init it's not possible to add edges between things to say that networkd must be started before apached; there are 6 numeric runlevels and filenames like S86apache, which you then can't diff or debsums against because the package default is S80apache and Apache starts with A which alphabetically sorts before the N in networkd.
And then add cgroups and namespaces to everything in /etc/init.d please
It's possible to pipe stdout to syslog through logger by modifying the exec args. But I'd rather take journald's word for it.
Supervisord (and supervisorctl) are like s6. I don't think any of these support a config file syntax for namespaces, cgroups, seccomp, or SyscallFilter. Though it's possible to use process isolation with any init system by modifying the init script or config file to call the process with systemd-nspawn (which is like chroot, which most SysV-init scripts also fail to do at all, though a process can drop privs and chroot at init regardless of init system).
systemd works in containers now without weird setup. Though is it better to run a 'sidecar' container (for e.g. certbot) than to run multiple processes in a container?
That's not really the case, though. The Debian folks had a very transparent discussion and vote about using it:
https://www.debian.org/vote/2019/vote_002