|
|
|
|
|
|
by cycloptic
2236 days ago
|
|
|
This is an asynchronous forum. If you find my information moot or unwelcome, you can just ignore it. It would be impossible for a daemon to categorize its users into those two groups and decide when to stop itself from running because it cannot see months into the future. The other implementation strategy already exists and I talked about it, it's to use socket/dbus activation to start the service on-demand. But that doesn't work in all cases such as with idle notifications, so I would argue that it is a trade-off. |
|
|
The scheme I outlined doesn't ask anyone to look into the future. It asks that the service look into the past.
> I would argue that it is a trade-off.
Argue if you want—it seems you're predisposed to it. I said it's not an inherent trade-off. The developers/package maintainers are certainly making a trade-off. That's not the same thing as that trade-off being unavoidable.