Story

It's mostly sentimental, not much information in it. However, there are legitimate reasons to why systemd sucks. First of all, it was designed with the wrong goal. It tries to emulate the Windows services framework and fails badly. In the Windows world, a service conforms to a published (and even maybe stable) API. I don't know much about it but I would guess that it contains mechanisms to stop, restart and indicate success/failure. Everything systemd is trying to emulate with signals, polling etc. It doesn't work so well. Sometimes a server has a fatal flaw in it (or its configuration) and has no way of indicating "I'm no longer functional, don't restart me". So systemd tries to restart it and all its dependencies on and on, wasting my time. If it was intended to be a boot-time tool only, it wouldn't get so bloated and get in the way.

Second, it carries on the idea of 'file system is a configuration file' mentality. It did work for the SysV-init because that system was already very simple and was easy to discover. Not so with the systemd, you need to create your 'script' in a particular folder, link to it from the things which depend on it, and then do some more soft linking in order to start its dependent services. It's so complicated and undocumented, makes me wonder whether these guys know how to program at all. I mean, just parse a fucking config file for dependencies, what's so hard about it?

Which brings me to the third point. The alleged "eases developers' job" applies only to RedHat developers, not the guys who write the actual servers being run or the users who want to get out of the distribution's boundaries. The whole thing only works if you use your system in the way your distributor intended for you to do. This of course eases the work of RedHat developers since they don't have to deal with silly things like documentation, stable design etc.

On the computer I had before this one, I had sysv-init. I had reduced the whole thing into inittab + one script since I didn't have anything complicated on it. Of course it booted blazingly fast since it didn't need to read hundreds of mini config files. I couldn't do it starting from systemd. Everything is spread around in so many files (and so many soft links), it's impossible for me to wrap my head around.

I do think that sysv-init could be replaced with something better but systemd isn't it. Something which can read a configuration file and start processes (not services, eww) in parallel would be a way forward. There is a lot more to talk about how systemd fails and I'm sure many people have done a more thorough job elsewhere but this is just my two cents.