> 1) systemd is a solution for a problem that doesn't exist for me. I've
> been using Linux in server, PC, embedded setup since 1995 and never in
> my life I have experienced a situation where I couldn't implement
> something by modifying existing SysV-based based setup. I'm not alone, I
> heard similar sentiments from others.
How about myth 19:
[Y]ou can do with it whatever you want, and that includes not using it.
> Yeah, boot time is a bit better. I don't care, my systems have months
> and years of uptime.
Myth 2 and myth 3?
> 2) Entire SysV based boot can be understood on the spot by reading the
> code of the scripts. Compared to this, systemd is a black box, to fully
> understand its internals you have to go outside the command line: hunt
> for the docs on the Web, download the source code.
Myths 5 and 11, I guess.
> 3) systemd makes the boot process non-linear and complex to comprehend
> and predict. I cannot easily see the boot process visually as it is
> happening and I have to rely on external utilities to understand the
> order in which everything will be started.
Myths 5 and 11 again.
> With systemd, I get a feeling that I'm booting Windows - I don't have a
> feeling that I'm in control anymore.
Other peoples feelings are bit hard to discuss, but myth 10 comes close.
> 4) systemd is more difficult to troubleshoot. Starting a SysV script, I
> get output and errors straightaway on the screen. With systemd, at best
> this information is hidden somewhere in the logs which I have to hunt
> for.
Myth 25.
> 5) systemd has a steep learning curve. There are lots of config files
> and interaction between them is not obvious. It'll be quite difficult to
> explain it to a junior system administrator.
Myths 5 and 11 again.
So to me it seems your issues are basically addressed. You may disagree with the author's view. That's another story.