| 4 Sep 2023 |
 raitobezarius | If we implement the solution in systemd, while it's true that the latency of getting those changes in systemd takes time, it does not prevent anyone running them inside of an organization :) | 12:53:46 |
| raitobezarius | I am biased either way as a systemd and NixOS developer and see the value of having this upstream rather than specialized here | 12:54:48 |
| raitobezarius | So don't take my opinion as a blocker or whatever | 12:55:06 |
 osnyx (he/him) | In reply to @raitobezarius:matrix.org
The question is for whom are you solving this such urgently? Whether this is urgent for NixOS upstream is partly your decision as the maintainers team (as a personal user I'd say yes as well), but the implementation I am doing for FlyingCircus. | 12:55:25 |
| raitobezarius | From my personal perspective as a NixOS developer, there's an appetite for anti concurrency for any systemd service honestly | 12:55:59 |
| raitobezarius | Giving a pass to ACME is probably fine because of the importance | 12:56:14 |
| raitobezarius | But I don't think we could accept the proliferation of this ad-hoc everywhere | 12:56:25 |
| raitobezarius | Hence my desire to solve it at the primitive level | 12:56:35 |
| raitobezarius | Therefore I don't think there's an emergency beyond ACME large users (you and some folks, including me) | 12:57:16 |
| osnyx (he/him) | AFAIK keeping patches on NixOS modules downstream is not that easy, correct me if I'm wrong. Additionally to being good citizens in the NixOS community and trying to wor upstream-first for apparent bugs, I'd of course also want to prevent having to maintain a downstream module fork. | 12:57:38 |
| raitobezarius | (of course I say this and microman is the maintainer of this subsystem) | 12:57:42 |
