so we all know systemd is literally the devil, but what is the best init system, given the choice?
hint: its openrc
considering package compatibility, adoption features, and most importantly: how the boot log looks.
So we all know systemd is literally the devil, but what is the best init system, given the choice?
Benjamin Morris
Other urls found in this thread:
wiki.gentoo.org
twitter.com
Nicholas Ortiz
does it have parallel startup?
David Rodriguez
a future stripped-down systemd-like init daemon that's not made by poettering
Angel Morales
Upstart was unironically good. It would be the best init systemd if someone forked it and dropped all of the legacy sysvinit shit
Elijah Taylor
>but what is the best init system, given the choice?
systemd, unironically
>considering package compatibility, adoption features, and most importantly: how the boot log looks.
systemd, unironically
>Upstart was unironically good
kek no
Carson Parker
it's runit
Julian Bailey
CopenRC can't even do cgroups.
Lincoln Cox
Yes
Owen Cooper
the ascended choice is systemd for servers and openrc for desktop usage
Christopher Gomez
You mean systemd for both and openrc in the trashbin
Hudson Perry
>literally the devil
kek. continue being schizos boys...I will enjoy distros that don't die out in
Ethan Martin
It's runit, specifically void's runit for me.
Connor Ward
>A stop job is running for ......
Landon Sanchez
complex bloat. runit is what you should be using
Gavin Brown
just press the reset button
Asher Robinson
>
And that's as much information as OpenRC will give you when a service gets stuck. Imagine shooting the messenger, fucking retard.
Gavin Jenkins
>systemd is literally the devil
>uses a system with literal daemons in it
>running the "bourne again" shell from an organization created by an blasphemous atheist jew that calls himself a saint and mocks God
sure thing buddy.
Brayden Butler
Whatever comes with CRUX
Kevin Ward
>fapping over your unigz philofuckery
I am
$ find /usr/bin -name 'systemd*'
/usr/bin/systemd-delta
/usr/bin/systemd-escape
/usr/bin/systemd-tty-ask-password-agent
/usr/bin/systemd-resolve
/usr/bin/systemd-cat
/usr/bin/systemd-repart
/usr/bin/systemd-machine-id-setup
/usr/bin/systemd-tmpfiles
/usr/bin/systemd-socket-activate
/usr/bin/systemd-sysext
/usr/bin/systemd-creds
/usr/bin/systemd-run
/usr/bin/systemd-detect-virt
/usr/bin/systemd-cgtop
/usr/bin/systemd-stdio-bridge
/usr/bin/systemd-hwdb
/usr/bin/systemd-analyze
/usr/bin/systemd-firstboot
/usr/bin/systemd-ask-password
/usr/bin/systemd-cryptenroll
/usr/bin/systemd-mount
/usr/bin/systemd-cgls
/usr/bin/systemd-dissect
/usr/bin/systemd-umount
/usr/bin/systemd-sysusers
/usr/bin/systemd-path
/usr/bin/systemd-notify
/usr/bin/systemd-id128
/usr/bin/systemd-nspawn
/usr/bin/systemd-inhibit
Ethan Hernandez
false
wiki.gentoo.org
OpenRC is modular - it can interact with cgroups, it can use a supervisor to run services if you want, the powers are limitless.
You can forcibly cancel startup/stop of a hung service on OpenRC - useful so that you don't have a system that can't be booted.
Charles Wood
>false
>wiki.gentoo.org
OpenRC's cgroup handling is worthless trash. From the link you posted:
>This option should not be set globally as it will kill all service's child processes e.g. SSH connections or apache workers, as OpenRC doesn't support automatic process cgroup-relocation as it is done in logind services.
One of the biggest benefits of cgroup-based supervision is that it's impossible for services to escape the supervisor's grasp. OpenRC can't make use of that feature reliably.