> 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. Yeah, boot time is a bit better. I don't care, my systems have months and years of uptime.
You don't seem to dispute that systemd is valuable for others. Some of the ways it's valuable to others, like fast server boot times, even appear in the article. You're not even making the case here that systemd makes things *worse* for you in terms of capability or performance. Certainly, you understand that not every change in Fedora or other FOSS projects has to personally benefit you.
> 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.
Your experience with SysV init seems to obscure its rougher edges to you. There's nothing obvious at all about SysV init in terms of the metadata-in-comments at the top of init scripts, run levels, rc.d, and the inconsistent suite of service-management utilities like update-rc.d and chkconfig. There's also the litany of executables invoked from within the init scripts like daemonize, start-stop-daemon, and runsv. Subtle errors in using these tools can open many security errors related to improper privilege dropping and inheriting too much of the admin's session.
As for needing to leave the CLI, systemd's docs are fully available as man pages. There's even an index of topics in those man pages. There is no equivalent documentation for someone on the CLI of a system running SysV init. You'd have to already know which utilities you'd need to invoke before being able to find the man pages.
> 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
systemd shows service startup the same way most init scripts always have. It's actually *more* consistent because systemd handles the formatting rather than a bunch of init scripts that have more-or-less converged on standard startup output. systemd even includes a "notify" API for services to inform systemd, semantically, from within each service that startup was successful and the daemon is fully online. There is no equivalent for SysV init; output generally stops after the service daemonizes but before it's fully operational.
The problem here seems to be with tools like Plymouth hiding text startup information. That is not a systemd issue.
> and I have to rely on external utilities to understand the order in which everything will be started. With systemd, I get a feeling that I'm booting Windows - I don't have a feeling that I'm in control anymore.
It's actually pretty simple once you dive in:
* If any two services don't have an ordering dependency, start and stop them in parallel.
* If any two services do have an ordering dependency, start and stop them in a way respectful of the specified Before= or After= ordering.
This is all configurable by the packager or admin. Usually, an admin shouldn't have to worry about ordering and should just be able to enable or disable services.
The vast majority of services in systemd either start on-demand (like CUPS) or in parallel with the multiuser target, which is equivalent to the highest few traditional runlevels.
systemd provides a superset of the ordering control present in SysV init. Any lack of control you feel probably comes from unfamiliarity with systemd rather than any actual lack of control. I learned everything I know about systemd's service ordering from the man pages; I have not browsed the source code in that area.
> 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.
That SysV init output is visible to the admin manually running the script, but it is pretty hard for any other admin or automated tool (that isn't directly running the scripts) to view or collect.
The systemd journal, which has been included since Fedora 17, has made structured logging associated with services more streamlined than it's ever been. Running "systemctl status" on a service provides a quick last-ten-entries log output while providing many more options to filter, tail, and view the data.
There's even work on the selinux side to push access auditing entries into the journal associated with the service, making it far less of a mystery why a service is failing when the cause is selinux.
> 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.
This has been improved a bit in later releases with more built-in help in systemctl output, more natural defaults (assuming a .service suffix to most systemctl calls), and ever-improving man pages.
systemd's documentation is remarkably well-maintained and extensive. It's certainly better than you'll find for any distro on any other init system, especially SysV init. For example, compare systemctl's man page to documentation for chkconfig.
I think the "steep learning curve" is also an illusion created by experience with SysV. Basic service management is no more complex with systemd than the bundle of distro-specific SysV helpers. Creating new services and performing advanced tasks is considerably more straightforward and less error-prone with systemd than writing new init scripts or hacking in non-standard runlevels.
That said, we're always open to suggestions of how to make the tools more comfortable for new users. We do value capability and correctness over SysV init familiarity, though.
> PS: My experiences are based on FC16. Perhaps these issues have been addressed in newer Fedora releases - I'll be happy to hear about that.
I've included notes on this with my other responses.