Especially systemd. Declarative management of services is a bad thing?
Some people just wanna complain
Some people just wanna complain
Some people just want to live in the 80s forever.
I think this shaming of free software users that want to make other choices is rather terrible.
Please don't insult me by insinuating that I think that sysvinit is anything other than a weird esoteric init program which has, in the past and on linux distros, been the supporting piece of a garbage heap of poorly written shell scripts (and which is currently on BSDs the supporting piece of a relatively okay designed heap of shell scripts which implement a silly service management model that I also don't like).
Yep. Today, I would tend to agree with this.
> switching to it caused no issues
Yeah, okay, there's no need to make wild untrue claims to support your position. The initial adoption was rough, things absolutely did break, and some of those rough edges are still around to bite the unwary (enable-linger/KillUserProcesses are my "favorite" footgun that will never be fixed because systemd thinks killing your stuff is a feature).
People who grew up on sysvinit based service management and can't handle change (the partially straw man group you are complaining about).
People who only know about sysvinit based service management and systemd and formed their opinions of systemd based on "sysvinit == terrible confusing shell scripts; systemd == config files" (you - as a first impression).
And people who actually know the advantages, disadvantages, and functional details of sysvinit based service management, systemd, and the plethora of other attempts/approaches at solving these issues and can support their arguments in favour of or against systemd with actually reasoned arguments.
The first group is easy to ignore, and a minority. The third group produces the biggest chunk of well informed content on systemd. And the second group seems to think that anyone in the third group who is in favour of systemd, must be one of them, and anyone who is against systemd, must be in the first group (note also: the false dichotomy).
Rather than straw manning your opponents in this discussion while pretending this is a discussion of the pros and cons of "declarative service management", could you instead contribute something useful? Lacking that, maybe just stop trying to contribute?
By saying stuff like this, you aren't going to convert sysvinit users to anything and you aren't going to convince anyone who has genuine criticism of systemd of anything.
There are other ancient service management systems that were much more coherent and which did not show any disadvantage in comparison with systemd, e.g. even the sysvinit-based service management of FreeBSD or other *BSD, which were and are much better than the "sysvinit-based" of old Linux.
An example of how a replacement for the traditional UNIX service management can be well designed was the daemontools of Daniel J. Bernstein, written more than a quarter of century ago, long before systemd. There are derivatives of daemontools that are brought up-to-date and they are much simpler and more secure than systemd, while systemd does not have any advantage that can justify its complexity, opacity and interference with other applications.
All the non-systemd service management solutions have the advantage that even if you are not familiar with a computer, it is easy to debug any problem because all the behavior is written in a bunch of text files. With systemd, you can never be sure what happens. The behavior implemented by systemd may change between versions, you might not have the source of systemd or the source of the particular version installed on the computer with problems, the source may be very complex in comparison with traditional shell scripts or with the very simplified scripts of something like daemontools.
Thus claiming that using systemd uses "descriptive" files is not really true, because the uncertainties about what those files describe are much greater than for any other service management solutions.
Even a set of shell scripts, like that of FreeBSD, can be as "descriptive" as the configuration files of systemd, when all the service scripts share a common set of definitions of functions and of configuration parameters.
There is nothing descriptive about `Wants`, `Before`, `After`, `Requires`, `Requisite`, `BindsTo`, `PartOf`, `Upholds`, `Conflicts`, ... we could go on. And we can stop there. (To clarify, _I_ know what these all mean, but certainly I didn't have a clue what they meant until I read the docs about and didn't fully understand the nuances of these until I re-read those docs many times and read the source code.)
But the "declarative"-ness of systemd's configuration files can also be put into question when it's incredibly common to find an `ExecStartPre` containing a shell oneliner.
That being said, my goal was not to start a discussion about systemd here. My goal was to call out the completely unproductive strawmanning of systemd critics by the person I was replying to.