Hey Fedi! If you use Linux and use an init system / service manager other than systemd, what do you like about what you are using? Everybody asks how these compare to systemd, so I wanted to see what people thought of them stand-alone.

Edit: Please do not turn this into a bashing systemd thread. systemd is fine, but I want to see why other setups are *also* fine.

#Linux #OpenRC #SystemD #RunIt #s6 #whathaveyou

@justsoup I’m using sysV right now, and the better part is that is simple, easy to use, and just do what I want it to do
@justsoup SysV, the default of Slackware. Reliability and easiness to understand.
I like how my init system doesn't contact projects and snivel connivingly until they agree to make their binaries depend on my init system, to force people to use my init system. But Pottering aside, S6 is just nice to write services for, and it has killer logging capabilities, that don't save logs in an unreadable, binary format like systemd does. Truth be told, the only system daemon I really need is something that runs a shell script every 2 minutes. Servers that freeze don't exit their process, so waiting on the PID won't always identify when something's wrong. But just like...

test_service || warn_admin && restart_service

repeatedly.
@justsoup in OpenRC, I like that they are simple scripts in a single directory. Its just simple and straightforward. Also OpenRC has a user service manager now and it makes starting desktop portals and co a lot simpler
@justsoup OpenRC does precisely what I need it to do, and it does it well.

@justsoup

  • OpenRC on my Alpine server because it's much simplier. Thus more lightweight and safer (btw, when i need sandboxing, i just use containerd).
  • Runit on my Void desktop because it's not systemd and the default on Void.
  • Custom shell scripts (init and supervisor) on Android Alpine-PRoot servers.
@justsoup I used Gentoo based for 2 years. Now I'm on #Void (#runit).

@justsoup SystemD, last I face-planted on it, no work with `chroot` environments :-|

So for devices that run via Termux on Android, and non-security related sandbox applications, init-like service managers are the way to go.

@justsoup openrc on Alpine Linux. I prefer the simplicity, minimalism.
@justsoup i really like that i can run Shepherd to manage user services independently of the system's init daemon, even as an unprivileged user on a foreign (eg. macos or systemd) system. because it's composable, i think it breaks down (system -> user -> project) into the kind of job control and service orchestration done by container tools like docker-compose and nomad (iirc, at least the latter can orchestrate unsandboxed processes). i liked the mental model of openrc's run-levels, and don't remember if it managed user-services with a seperate per-user process or not. i don't think this is something you can do by eg. running sysd as a user-daemon on macos, but maybe i'm wrong
@justsoup I really was sold on process supervision and capturing stdout/stderr using djb svscan/supervise/multilog when those tools came out, which I understand runit has a similar model, but I haven't felt the need to explore these other systems when the built-in tools provide the features I care about and are good enough
@justsoup runit because Void Linux. it works really well, fast etc. I like how you add services by symlinking them, and then enable them with a command, and its easy to keep track of all the files involved.
@justsoup i mostly use Alpine Linux with OpenRC. I really like its simplicity :)

@justsoup dinit or openrc.

With openrc: like that it works on any system I decide to crank up, (most of which are non-glibc-based, usually musl) and that I can use the same system everywhere. Including at embedded-linux cases where systemd is just impossible to use.

Dinit, because I think it might in the future do the same, but better, if it gains traction outside Chimera Linux.

s6 is nice technically, but I think it forgets that tech is built for humans. I like its technical properties a lot, but I wouldn't want to impose its use on anyone.