When comparing systemd vs sysvinit, the Slant community recommends sysvinit for most people. In the question“What are the best Linux init systems?” sysvinit is ranked 3rd while systemd is ranked 4th.
Ranked in these QuestionsQuestion Ranking
Pro Default for many popular distributions
Systemd is the default init system for many popular Linux distributions (Arch, Debian, Ubuntu, openSUSE, Fedora, etc..). It should also be noted that some of those distributions allow users to use a different init system if they want.
Pro Login management out of the box
Systemd contains a daemon called logind which is used for managing user logins.
Pro Cgroups processes control
Systemd groups all processes by services using Linux's cgroups. Think about memory/cpu/tasks/IO/Net limits and accounting for any service.
Does one thing and does it well.
Pro Simple to understand
Pro Very stable
Since sysvinit does only one thing (initialize the system) and one thing only, it's very stable and it's impossible for it to fail for any problems unrelated to booting the system.
Pro Better boot time and overall performance
Con Not UNIX-like
One of the main argument that people who are against using systemd is that it does not follow on of UNIX'S core philosophies. 'Do one thing and do it well', instead systemd represents a collection of dozens of tightly coupled libraries. With responsibilities that exceed those of a simple init system because it also tries to handle things like device management, power management, mount points, cron, encryption, syslog, network configuration etc...
Con Makes dependent products difficult to port
Software dependent on systemd. Becomes difficult to port to systems that lack systemd.
Con Too monolithic
It tries to do too much. I don't think most people who use systemd are even aware of most of the features as they don't really use them. It makes it really complicated to deal with sometimes, and it's possible that in a few years this project will be a nightmare to maintain, and with that the users of it will start to feel the fallout.
Con Runs only on Linux
Con Need glibc
Con Lead developer shows near complete lack of care for standards of quality needed for developing a part of an OS as integral as the init system is
Con Can lead to slow boot
Since init starts tasks serially, it has to wait for a certain task to finish in order to start the next one. But when startup processes end up I/O blocked, this leads to considerable delays during boot.
Con Duplicated implementation for every service
Every init script needs to reinvent the wheel for every script: argument processing, start/stop/restart/reload/status/whatever processing, finding/clearing/creating PID files, sourcing defaults, building and setting configuration options, so on and so forth.
Con Launches a bunch of processes to launch a process
Every init script spawns at least sh/dash/bash, and probably also additional processes such as cat, echo, start-stop-daemon, etc, just to start a single daemon that may not even be needed at the time of boot. This massive overhead results in poor performance, and is a killer for embedded systems.
Con Initscripts is not portable
It is virtually impossible to write portable sysvinit-scripts
Con Hard to write sysv-initscripts
As one needs programming skills (opposed to a declarative style).