@icedquinn if this level of unfathomably based requires systemd I'll happily accept systemd. Besides, I still haven't heard sensible arguments against it, only variations of "but it enforces a sensible API", "but it uses 5M of memory, that's way too much" or "but there's a bunch of related tools you can optionally also install so systemd itself is bloated "

@Amikke probably because people want pid 1 to just boot and start some stuff, not be a massive behemoth that tries to do everything, steals kernel resources for itself (cgroups) and has a massive and ever growing attack surface racking up CVEs

@icedquinn I think I count as people and I expect PID 1 to not just start stuff but also monitor it and make it available under a consistent API and consistent logs, so that I can use it to control the system instead of babysitting every single daemon their own way.

From what I can tell trying to muh unix philosophy to split it into different services that still do those things instead of falling back into bad ol' anarchy would just require a few different services that have the same basically infinite permissions and accomplish the same thing but with more bloat, attack surface and weird shit.

I guess if you prefer the anarchy disliking it makes sense tho.

@Amikke not really.

https://www.cvedetails.com/vulnerability-list/vendor_id-4204/Runit.html
https://vulners.com/search/products/Fcron

vs

https://vulners.com/search/products/Systemd

@icedquinn oh yeah, udev functionality is cool too, from what I see runit only sets up things once and doesn't respond to changes. So I'd have to install something that does that. I assume there's a lot of other "bloated" systemd functionality that is quite useful and installing separate tools to do all of them so that they don't have to be coupled with the pid 1 would exceed the bug surface.