Well, thanks for telling me how you see it. I can't say I agree with almost anything you've said, but it's definitely informative.

My perspective is that on the one hand, systemd is very 'cerimonial' in how it goes about things, while shell-based systems have the potential to be extremely well done. My go-to example is the OpenBSD init script - I once tried to boot OBSD over the network, and mount it on a RAM filesytem, and was able to simply open that boot script and change the mount commands. Ever since, I've been impressed by the clarity and simplicity of that shell script (in its original form, not after I was done with it (: ).

> Because sh and bash are horror shows.

I disagree. The syntax is obtuse, but it is at this point very well understood, and the rest of the system runs on it. Better to use fewer languages throughout, than more. Are you referring to something other than the syntax?

> Maintaining and creating new service init scripts is a real pain and difficult to do with consistency.

I'm not sure, but it sounds like you're talking about systemd services. If you are, I agree; multiple files with layers of cerimony are hard to compare to an extra line of shell core in an rc.local. If you're talking about non-systemd, I've never encountered this, and certainly found the process far less painful than the systemd way.

> Bash scripts can do anything, meaning they have to be audited one by one, every single time they are updated.

Just diff the scripts...not that hard. Just have to check the changes. That's no harder than any other program you care about.

> Every single distribution has its own way to run services via scripts.

vive la différence! No point to the stagnation caused by homogeniety; I don't see why I should expect debian services to run the same as FreeBSD.

> And that can change between upgrades.

Systemd is notorious for changing things. One great example is when they tried to change how processes can persist after the user logs out. I don't think you have a leg to stand on here.

In the systemd world, I can audit a unit file via a simple `systemctl cat <name>`, and edit it directly via `systemctl edit <name>`.

I can too: `cat /etc/rc.local` and `vim /etc/rc.local`. Added benefit, I'm using the same tools and interfaces that I do for the rest of my system administration.

> I can easily see services dependencies, I can easily change the user running the service, the workdir, etc.

Service dependencies are the strong point of systemd, I will give you that. However, `su` can change the user running the command, and `cd` is this awesome little tool I found for changing the directory I'm in. No extra benefit there, just new commands for doing the same old things.

> There is a standard interface to start, stop, restart, enable at startup.

That standard interface is only useful because the underlying complexity has increased so much that `systemctl start` has become a necessary abstraction to cover it up. Your standard interface is medicine for an ailment I do not have.

> All of this from one system that is consistent and the same between Linux systems.

Why is that beneficial? It just means that you've put all the innovation in the hands of the systemd devs. I'm over on systems like void, where my startup times are faster, my base system load is a third, and I can get my hands dirty in the system internals without googling for strange systemd incantations.

> But really the best features IMHO is journald.

You're going to have to spell that out, because I really like being able to use a proliferation of text-oriented tools to manage my logs. I'm not a fan of binary, no matter the supposed speed improvements.