Heck I hadnt used Linux for a few years and when I got back to it systemd was on every distro I use. I just use it. I dont see the big deal. I grep the piped output of services if I want to narrow things down more just as you would the output of cat or ls or anything on Linux.
But there have been reasons given. They want to use standard tools to deal with the log. They want to see the scripts that manage the system and poke around in it, which has the implicit reason to learn about the system and being able to easily modify it.
> They want to use standard tools to deal with the log.
I have a little sympathy for this one as an old habit if you don't know any better. It's also an extremely inefficient way to work with logs. If you've used a system like Splunk seriously, the idea of going back and grepping through logs on a host with the shell is just frustrating.
> They want to see the scripts that manage the system and poke around in it, which has the implicit reason to learn about the system and being able to easily modify it.
I have no sympathy for this one. Scripts are a terrible place to define policy. They are nigh impossible to audit. They are brittle. They multiply complexity by making everything a special case. They make integration of different parts of the system nearly impossible.
Aren't systemd units simple text files with no hidden magic? In fact, all systemd configuration is plain text files and symbolic links. The only binary format is the journal.
> Aren't systemd units simple text files with no hidden magic?
Compared to something like a shell script, systemd unit files are magic because you have to know a lot about how systemd works to figure out how your config file translates into actual behavior.
Whenever systemd comes up, someone appears to counter any criticism with words suggesting you'll get left behind if you don't follow us. No justification beyond that.