Add to Chrome
Add to Edge
Add to Firefox
Add to Opera
Add to Brave
Add to SafariWhat is the best alternative to SysVinit?
Top Pro
Top Pro
Top Pro
Top Con
Top Con
Top Con
Top Pro
One of the runit project's principles is to keep the code size small. As of version 1.0.0 of runit, the runit.c source contains 330 lines of code; the runsvdir.c source is 274 lines of code, the runsv.c source 509. This minimizes the possibility of bugs introduced by programmer's fault, and makes it more easy for security related people to proofread the source code. The runit core programs have a very small memory footprint and do not allocate memory dynamically. See More
Portable: Linux, BSD, Solaris POSIX. Can be compiled with musl. A lot of features including dependencies service management. Easy to implement with the conjunction of 66 which provide frontend file for service declaration, automatic logger creation,nested supervision tree,user service,instantiated services and many more. Best alternative ever. Work out of the box, PROC was made on Gentoo, Funtoo, Devuan, KISS linux, Adelie, Void, Antix. Default init system and service manager on Obarun and from a long time ago. See More
Since it is event based, it was simple to have interdependent services emit status messages each other. Service start ordering and shutdown was easily managed in one conf file. The "lazy" start of systemd is BS and is a mess to debug . service unit files have no clue what another service state is. The maintainers add arbitrary timers that add more complexity and more init hangs. The systemd documentation is poor. When a service fails to start (or stop) systemd follows the Microsoft model of not telling the reason why. See More
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... See More
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. See More
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. See More
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. See More