Unfortunately if you think also how all the decision was been taken, you can't avoid to smell something burn starting from the wiki:
Well designed especially when is behavior is, for same admission of his Author, unpredictable.Why Debian should default to systemd ?
Fedora, OpenSuSE, Arch and Mageia have already made the choice to use systemd, and it is getting excellent upstream support for a growing number of packages.
Architecture
Systemd is well designed. It was conceived from the top, not just to fix bugs, but to be a correct implementation for the base system services.
Systemd makes the boot process much simpler, entirely removing the need to specify dependencies in many cases thanks to D-Bus activation, socket activation, file/inotify activation and udev integration.
Systemd can handle the boot process from head to toe, without needing to use any of the existing shell scripts.
Systemd is straightforward. The command-line interface is probably the best existing for service management. The unit file format (like .desktop or “ini” files) is completely declarative, can be parsed using standard tools, and is a breeze to maintain.
Systemd unit files, unlike SysV scripts, can usually be shipped by upstream, or at least shared with other distributions (already more than 1000 existing unit files in Fedora) without any changes, the Debian specifics being handled by systemd itself.
Systemd is incredibly fast (1 second to boot). It was not designed with speed in mind, but doing things correctly avoids all the delays currently incurred by the boot process.
The transition plan is easy, since existing init scripts are treated as first-class services: scripts can depend (using LSB headers) on units, units can depend on scripts. More than 99% of init scripts can be used without a modification.
That is interesting because the "contra" of leaving sysvinit for another init are more of the sum of the "pro" of the three others challengere.Contra change to another initsystem
Any change at all involves work, learning something new, and therefore should be a choice; this decision feels somewhat forced upon us by some who insist it is better for us.
If GNOME requires logind which requires systemd, it is unreasonable to impose such a change on the whole distribution, and ought to find an alternative which doesn't.
Unless the new initsystem retains backward compatiblity, and packages continue to provide sysvinit-style initscripts:
Estimates are that up to 1200 Debian packages may be required to adapt to, and continue to support, such a change.
If packages remove their current initscripts, ports like kFreeBSD and Hurd may be unable to use software that was working before this. (Unless the new initsystem can be ported; this is most likely for OpenRC but completely ruled out for systemd).
Much third-party software outside of the Debian archive, or in-house projects within business, may no longer work without taking effort to port them to a new initsystem.
Some maintainers object to maintaining separate initscripts to support alternate systems.
Declerative systems are nice to look at and might cause fewer problems, but if there is a problem, they are almost impossible to debug. Even more so if you only have a non-working system (as the problem would be in the init system).
At least judging from their documentation they all support significant logging.
Even given the disadvantages of editing init scripts (hard to merge with upgrades, ...) and the resulting reluctance of admins to edit them directly, almost every admin has used this ultima ratio at some time, which indicates the missing flexibility to do so might be a problem with other init systems.
Contra systemd, upstart
Not all functionality can be controlled by configuration files and is instead contained in compiled code and if you need to change something it is difficult.
(mainly systemd) Principle of all-mighty solutions is in its nature authoritarian. All-in-one "solutions" are a characteristic of big companies that want to seduce its users into a vicious circle of using their integrated software, while sacrificing other tools that would give them more benefit, thereby realizing abusive psychological advantage above the user.
Init system supported by a big company may have better support but that support is influenced by interests of that company.
They depend on DBus, which means that if DBus is not working system initialization cannot begin.
Key feature of free software is forking, which saves the software from falling into hands of corrupted people. When a project is corrupted, good developers can fork it and make a new project. But if a software is to complex, than forked project is either also complex, and that could demotivate developers to work on such project.
If makers of systemd and upstart really wanted to contribute to F/OSS community, they could just improve sysvinit, init scripts and add additional software that can be used from shell scripts to achieve the same features they provide. Which is basically what openrc did.
Complex software has more bugs. Software requiring a complex SysV init script at the moment (e.g. Squid) may still need a complex Upstart or systemd definition.
Features provided by these init systems are often compensations for lack of features in software that should have those features, and which should not be in init system; e.g. 'start daemons when they are first used' feature compensates lack of support for inetd in server software.
Boot speed may not be important enough to justify a new init system; BIOS POST, option ROMs, EFI boot may take a long time already, and most server systems are rarely restarted anyway.
Contra systemd
Not portable, by design; uses Linux-specific functionality not available on other platforms.
Binds Debian to being a Linux distribution; even some Linux ports may have to be dropped if systemd stops supporting them.
Violates traditional UNIX principles of simplicity and the separation of kernel/initsystem/userland duties such that components are interchangeable.
Begins a precedent for disruptive change, which may happen again if systemd changes its APIs or deprecates some interfaces (has been described as resembling 'vendor lock-in'; really meaning we must continue to keep up with changes mandated by upstream).
logind can no longer be used standalone, as of systemd v205
plans to replace ifupdown scripts too
conflicts with busybox-syslogd
Questions over agenda / conspiracy theories surrounding GNOME, systemd, and Linux, particularly Red Hat's interest in them.
We don't need the stress associated with ever changing to the newest thing and being lead by the nose down another "rabbit hole". Debian should be a rock amidst the sands, not dust blown by the wind.
Attitudes expressed by those pushing systemd:
disinterest in Debian's ports, in "choice" and the ability to "combine everything with everything else":
misunderstanding of the 'modular' concept; having "some 80+ binaries around" is bloat, it is not modular if they depend on using systemd and its interfaces together as a whole
http://bugs.debian.org/684396#10
http://bugs.debian.org/684396#30
https://plus.google.com/115547683951727 ... RmiAQsW9qf
Lennart Poettering: "The only thing we won't take is patches that make systemd portable to the BSDs or Hurd."
Throwing POSIX completely out of the window: where does reinvention end?
"Systemd ships a growing number of useful, unified command-line interfaces for system settings and control (timedatectl, bootctl, hostnamectl, loginctl, machinectl, kernel-install, localectl)."
"unified" is a bad replacement for complying to standards (such as POSIX) and conventions and power must go along with responsibility
Minimum system dependencies for systemd:
acl dbus glib2 hwids kmod libcap libgcrypt pam attr glibc expat libcap openssl pam perl cracklib db libtirpc libgssglue
Anyway, this is the funniest part:
This is the saddest, because this part is magically appeared after the "victory" of systemd, someone wanted to investigate after the forced selection of systemd and he revised a lot of inaccuracies about openrc just to support systemd.Community
Systemd is a lively project with dozens of developers from various companies, including Red Hat, Samsung and Intel. It integrates contributions from even more individual contributors: to this date, 438 authors, with 63 having at least 10 commits. It can also be noted that two of the Debian maintainers have commit permissions.
Other distributions who switched to systemd were also confronted to a lot of controversy before the switch. After it became clear that rivers didn’t turn into blood, the complaints have only been sporadic.
Systemd’s upstream is very accommodating to distributors. They are taking a lot of Debian’s needs into account, even though it has not yet been decided to make it the default.
Systemd developers participate to a lot of conferences, they hold regular hackfests and always ask for feedback on their plans from downstreams (including Debian) before going ahead with them.
Systemd ships high quality documentation, including manual pages for all tools and configuration files, as well as design documents and administration tutorials.
Is that really so funny?Rebuttals
From the Systemd page: "one of the primary improvement of OpenRC over the sysinit is cgroups" - it's wrong, cgroups are just a minor feature that can extend some use-cases, however pros on this page describes much more features that come with OpenRC (to not duplicate them here). Systemd authors and supporters are trying to let everyone believe that cgroups is the best thing invented since sliced bread, and that it is very complex, which isn't truth.
From the Systemd page: "The primary selling point of OpenRC is that it is portable. Otherwise, it is merely a sysvinit on steroids.". Well, again, that's not truth, OpenRC does a lot more than just this, this shows very little understanding and investigation from the author of these words.
From the Systemd page: "There have been many comments on supposed lack of documentation on systemd’s internals or interfaces. 10% of the source code (14 kLoC) are comments. Each component has its detailed manual page." Then we can read suppositions about the hardness/ease of reimplementing Logind. Well, what has been said by the authors of OpenRC is that re-implementing logind isn't hard, but making a replacement behave exactly like it means that one needs to reverse engineer Logind and read the source code, which shouldn't be the case. This has nothing to do with the (useless) hard dependency on Systemd that has been added on version 205 of Systemd.
From the Systemd page: "Many discussions are centered on systemd-logind as in being the only problem to address by other proposals, wildly proposing seemingly easy-to-develop replacements." Well yes, because it seems that it's being forced to everyone (for example by Gnome), and it imposes systemd starting at version 205. So having a way to replace it is important, otherwise, we are effectively locked-in both systemd and logind. Then on the same page, we can read: "It is hard because without systemd, you are missing the necessary features to implement this service."
The systemd page uses Linux as being monolithic as an argument, which has absolutely nothing to do with the discussion about too many things in the PID1 (it is by the way my opinion that Linux is a way too monolithic though).
From the systemd page: "Many are complaining about the absence of shell scripts, quoting ease of administration or embedded systems. Shell scripts are not easy to maintain or debug; systemd unit files are." Probably. Though Upstart jobs and OpenRC runfiles are equally easy to maintain, and that's not what has been discussed: others wrote that systemd is hard to maintain, and debugging a system which refuses to boot with systemd isn't as easy as it use to be systemd. Anyone who pretends something else is just lying.
Overall, the systemd page is using very aggressive tone like: "boil down to rumors or irrelevant political stances". Saying that your opponent is just "spreading FUD" or that all arguments just "boil down to rumors" isn't helping the debate. Plus highlighting that the systemd author clearly stated that he would refuse any non-linux port is very relevant, and is about a policy from the upstream authors.
From the sysvinit page: "Was only really brought up as a counter-argument for a switch to Systemd, there may not have been such motivation to switch to this from sysvinit otherwise." This is untruth. My interest for OpenRC came after discussing (face to face) with one of the OpenRC upstream maintainers (Patrick Lauer also lives in Shanghai), and after searching for ways to more or less do what OpenRC is capable of (I even went to start writing my own lib, then scrapped that project), with as motivation to offer an interface for simplifying existing init scripts in Debian packages without changing every components of the system.
From the sysvinit page: "No objections seen yet [note: to OpenRC] in discussions, but this init system is the least familiar to us yet". Well, to a degree, this is the init system with which everyone is already familiar with, since it doesn't change any of the interfaces we are already used to: update-rc.d and invoke-rc.d have been re-implemented so that they call rc-update transparently, runscripts live at the exact same place were init scripts use to live and just need to replace them. Read what's below (the example runscript and so on) and you will have to agree!
Systemd is a lively project with dozens of developers from various companies, including Red Hat, Samsung and Intel.