I'd argue the Wayland hate is much worse. Not that it might be bigger than the hate on systemd, but contrary on the case of the systemd, there are no other real alternatives to wayland nor x. Wayland is attempting to improve over x but some (really noisy) people just suffer from fear of the new.
Yeah Wayland I get. It's still kind of janky even after almost 20 years. Complaining about Systemd makes no sense though. It works very reliably, switching to it caused no issues, and it has fixed a number of problems with the Linux desktop.
> It works very reliably, [...], and it has fixed a number of problems with the Linux desktop.
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).
Most of systemd's critics are not people that just want to use another init system. They object to it on stupid philosophical grounds for which they should be shamed.
Most of systemd's proponents are not people that care about what service management system they use. They defend systemd despite their ignorance of both systemd and the proposed alternatives solely to feel part of the "in group" of people who moan about people who moan about systemd.
People who defend systemd do so because they want their system to work reliably and quickly. It does that. Before you say "so does sysvinit", no it does not. It was janky-but-workable on servers and desktops in the 90s, that basically never did anything except startup and shutdown. Most modern computers aren't like that.
More straw man arguments. You have just confirmed that you have _no idea_ what alternatives exist, that you have _no idea_ what systemd actually does, and you have _no idea_ what my actual stance is in this discussion.
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).
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.
The ancient Linux sysvinit-based service management is a strawman, because the scripts available in various distributions were very heterogeneous and many were quite bad.
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.
Interesting that you're saying the BSDs use something sysvinit-based. i never saw any runlevel idea there, which i thought was the primary marker of sysvinit? arch used to have an init system that felt very BSD-like. unfortunately they moved to systemd, and i went to void, but not happy with the init system there either. using linux used to be so much easier when "learning an init system" wasn't really a thing yet.
But haven't you heard that systemd is an evil project made by Microsoft to somehow destroy Linux and make everyone use Windows? It must be true because I saw it on Reddit.