Add to Chrome
Add to Edge
Add to Firefox
Add to Opera
Add to Brave
Add to SafariWhen comparing systemd vs OpenRC, the Slant community recommends OpenRC for most people. In the question“What are the best Linux init systems?” OpenRC is ranked 1st while systemd is ranked 7th. The most important reason people chose OpenRC is:
OpenRC follows the UNIX philosophy of 'do one thing and do it well', while it's true that it has more features than sysvinit, it does not stay away from its primary function with unnecessary added features.
Specs
Question Ranking
Pros
Pro Full use of kernel features
No POSIX.
Pro GPL Licence
Pro Free and open source
Pro Easy to manage
Pro Easy to understand
Pro Doesn't cripple your hardware
Instead of assuming your computer is a static machine, systemd is designed with modern computers plug and play design in mind.
Pro Backed by Red Hat
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.
Pro Login management out of the box
Systemd contains a daemon called logind which is used for managing user logins.
Pro Default for many popular distributions
Systemd is the default init system for most popular Linux distributions (Arch, Debian, Ubuntu, openSUSE, Fedora, etc.) Therefore there is an insane amount of support behind Systemd. Choosing Systemd means running with the herd, which comes with it's pros and few (or none for some people) cons.
Pro No feature creep
OpenRC follows the UNIX philosophy of 'do one thing and do it well', while it's true that it has more features than sysvinit, it does not stay away from its primary function with unnecessary added features.
Pro Extremely simple
All configuration is done via shell scripts and symlinks. Shell scripts can then use various specialized utilities to ease the development of init scripts.
Pro Fast
OpenRC builds on top of sysvinit and adds some more useful features (like parallel booting) while still the simplicity that sysvinit is know for. Because of this it generally boots faster than other init systems, especially when parallel booting is enabled.
Pro UNIX-Like
Does one thing and does it well.
Pro Less dependency creep
Using OpenRC does not lock in a distribution by providing specific NON-POSIX extra services which programs then would rely on.
Pro A very balanced compromise
Basically OpenRC doesn't replace SysV init, but rather works with it, providing features that SysV is lacking while taking advantage of its benefits. It's also used by a fair amount of reasonably popular distros and is well supported and developed.
Pro Very efficient on system resources
Uses multi-core and ram very efficiently.
Pro Portable
It can be ported to other UNIX and UNIX-like operating systems.
Pro Flexible and extensible
I can add a new startup script for most cases in under five minutes. The ability to quickly insert new applications into the system is a big help.
Pro Not bloated
Pro Deterministic
It always initializes a system the same way; if OpenRC booted and ran a system properly today, it will boot and run properly tomorrow, and the next day.
Cons
Con UNIX-like isn't the same as the UNIX philosophy
One of the main argument that people who are against using systemd is that it does not follow one of UNIX'S core concepts: '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, since 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 Binary logging
A binary log structure means that any tools you want to use to parse it will have to be aware of its format, and know how to deal with the ways it can become corrupted. Otherwise, it's not really possible in the easy sense.
Con Too monolithic
It tries to do too much - most people who use systemd aren't even aware of most of the features and don't really use them. It makes can be with complicated to deal with, and it's possible that in a few years this project will be a nightmare to maintain, and the users will feel the effects.
Con Overkill as an init system, resulting to unsafe init system
1.2 million code lines...
How this monster is controlled with such a huge size, for security leaks and other aspects?
How about if, the homed new service fails and your home folder may become unreadable or useless?
Con Aggressive marketing
It's trying to deprive people of freedom of choice.
Con Frequently change APIs
Con Makes maintaining a hassle
Con It's all or nothing
While it is technically possible to use software without SystemD, it really is true that it is "almost impossible" to use software without it, given that all the hard porting work to other init systems has not been done already for you, or given the fact that you are trying to install unported packages directly from the authors (either from binary, like a DEB file, or from source.) Consider the following:
Every major Linux distribution runs SystemD as an only option for init systems.
Around %95 of GNU/Linux users use SystemD, give or take.
SystemD makes things easier for lazy developers (at a cost, however.)
Therefore, most software packages that depend on an init system are developed with inherent and sole SystemD support, in favor of the status quo. While distributions such as Artix-, Gentoo-, and Void Linux have been able to correct packages that depend on SystemD, it is not the easiest to do so. Developers and users wanting to package their own software or build software from source may give up trying to work without SystemD since the software may need to be edited for extra compatibility.
Con The new version does not consider backward compatibility
They just remove the features they think are "incorrect".
Con Connects to Google DNS servers by default
Con Mindset of monopoly is behind it
Con Need glibc
Con Low-quality code
Con Unstable
Con Kills background processes after the user logs out by default
Con DDNS is done poorly between DHCP and DNS
Unlike ISC DHCP server/client, systemd-dhcp-client and systemd-dhcp-server cannot do DNSSEC, SVC, and many RRCODE. Stick with Bind9 and isc-dhcp-server instead.
Con systemd-networkd has poor network event handling for cable disconnect
When you disconnect the LAN cable, nothing happens in systemd-networkd. If you used non-systemd DHCP, you get a new subnet (if it changed).
Con systemd-DHCP cannot update subnet after reconnecting LAN from work to home
DHCP client that is builtin the systemd is really simple and rudimentary. Won't work with Verizon/Comcast DHCP ISP servers directly (must use their modem).
Other DHCP client can, like ISC dhclient, or dhcpcd.
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 Runs only on Linux
Con No socket activation
OpenRC does not have socket activation yet. It will be added in the future though.
Con Not widely offered across distrubutions
From Distrowatch, only ten distributions (of which 8 Linux, 1 BSD) officially support OpenRC, and offer it through their standard repos.
Con Not GPL
