Simon Ser

I'd really prefer this to be backed by service managers.

What are they? I don't consider that s6 supports it (it supports a similar mechanism, but not READY_FD). Isn't it possible to discuss with service manager maintainers and ask what...

>Lennart shared his thoughts about the spec on twitter already. Not particularly interested in interacting with him further on this subject. For reference, discussion on Twitter: https://twitter.com/pid_eins/status/1094611367938674688 (Why shouldn't we...

Makes sense. Moving forward, I'd be interested in what OpenRC, s6 and runit maintainers think about this. Would it be possible to get in touch and ask their thoughts?

I think it would be useful to send a message on the s6 mailing list and open an issue on the OpenRC repo to ask if they would be interested...

>There is no need to patch s6 for READY_FD support, it will work out of the box. Just have the run script start with env READY_FD=n ... if n is...

https://github.com/swaywm/swayidle/issues/117 mentions dropping logind support altogether.

Hm, I really don't think we should unlock the screen when the OOM killer kicks in. An explicit Sway IPC command to unlock the screen would be less dangerous.

Right. Can we document this new behavior in the man page? Maybe under a new SIGNALS section? What is the use-case for the `--disable-unlock-on-sigusr` flag?

> Disabling the feature if it is unwanted. I think this was more relevant when it was on SIGTERM - with SIGUSR1 it's not likely someone will be sending it...