Orwelluan

It's because you now need to do systemctl restart sshd instead of /etc/init.d/sshd restart, I see no other reason than having to learn new syntax.

Arguably, init.d scripts were easier to understand, and systemd is a bit of a black box, it somehow works, but who knows where it writes logs or saves the process pid (it's all in the documentation somewhere), with init.d script you can just open the script itself and look.

I have the following complaints about systemd:

1. It was created basically by lennart because after RHEL 6 did pretty much the worst implementation ever of upstart he got NIH syndrome about it
2. Red Hat played a lot of dirty politics early on to get systemd everywhere (my tinfoil hat theory is that Red Hat let Lennart's NIH syndrome run away with it because they thought having more control over the init system would be beneficial)
3. It's subsuming everything, often with no real benefit over what it replaces.

The first two aren't actually issues with systemd, but rather are political issues I have around the way Red Hat bullies the rest of the Linux ecosystem. I'm not going to let that become a stopping point for my using what is actually a fairly good piece of tech. The third is actually an ongoing issue, but it's not enough for me to try throwing the baby out with the bathwater. It is, however, IMO a continuation of Red Hat's sketchy political play.

Windows isn’t controversial since everyone has adopted it. No one is making you use it but keep in mind you are a very small minority.

I'm about 2 decades in too, really not here to argue since everything has already been said multiple times. I do see systemd in a somewhat similar light as Pulseaudio. Yes, some good ideas there and it's a useful tool, but it wasn't the be-all end-all solution.

It's new and different, and the Linux boomers who are still stuck on ALSA and ext2 hate it.

Everything else aside, my biggest gripes are with service control. Instead of just "service" they had to invent a new name that was super close to an existing function (systemctl vs sysctl) and reverse the switch order. (service sshd stop vs systemctl stop sshd.service)

Besides that, I absolutely hate that all the service configs are not in a standard location. Well, you get things like sshd.conf which are still in etc, but the systemctl configs are who knows where.

There are more important things to hate on with systemd, but I went for the superficial this time and I absolutely hate service management with systemd now.

Bad usability, binary logs, crummy architecture.

Are we used to choosing comfy things despite [...] concerns

People have been choosing convenience above everything else for a while, personally I find that doing so is even glorified at times.

If you like Arch you might like Void, it has roughly similar ideals and a very fast package manager. No AUR equivalent though.

1. It was doing new things.
2. It was easier to learn.
3. The other init systems were (are) stagnant.

Imagine trying to get new, young developers to adopt C or Pascal when the likes of Rust and Python exist. You can make arguments for a thing's superiority based on moral standards (which are always subjective), but morality is a poor metric. If everything was done based on that, the Linux ecosystem would be in the same state as the GNU Hurd kernel.

It's pretty good at starting services. It just keeps adding bundled things people wouldn't use otherwise, in a fairly microsoft fashion

The choice of init system is up to the distro maintainers because init scripts are usually created and maintained by the packager of a given application. Debian for example chose its init system via a democratic vote. Distros that focus on different init systems exist, like the Debian fork Devuan.

It sort of is, the whole elogind thing.

It was cropped and this is being passed off as new content