@ska@sertonix (there is also all the icky things that people with good taste hate, like “dbus service activation”, but sadly dbus is here to stay whether anyone wants it or not)
@ariadne@sertonix the problem with dbus service activation is that dbus is horrible; "service activation" in itself is just on-demand service start, which is reasonable and possible if you couple a supervisor with an event listener. The difficult part of this is dependency management: what do you do if service A is started on-demand but depends on service B? Do you also start service B? recursively? etc.
A lot of issues I have with s6-rc v1 could disappear instantly if we decided that dependencies are not a real thing, and that events can trigger service-local state change. Then I could just couple an event listener with s6 and be done with it!
@ariadne@sertonix the problem with dbus service activation is that dbus is horrible; "service activation" in itself is just on-demand service start, which is reasonable and possible if you couple a supervisor with an event listener. The difficult part of this is dependency management: what do you do if service A is started on-demand but depends on service B? Do you also start service B? recursively? etc.
@ska@ariadne@sertonix Dbus service activation was an intentional bypass of admin/distro policy to launder unsafe automatic launching of services across privilege domains past folks who would say no.
Gregory's Server
@ariadne
@ska
Oh no, not "dbus service activation"! It's awfull. I still have hope to get rid of it.
As far as I could find the way it communicates with systemd is just a hack.
Maybe s6-rc could establish a proper communication.