| > I have done the work in removing the "resistance" for you. Sorry, you misunderstand. The "resistance" was on the day that the system was installed and while casually scanning a list of installed packages and selecting ones to be removed, and then having the package manager complain about unsatisfied dependencies. Your message is a path to achieving the original goal. But it's not a magic eraser that made the original resistance disappear. Your message here suggesting how one might get down to the bottom of things now is neither unwelcome nor welcome. It's simply moot. > the point of the service is to sit idle for a really long time (potentially on the timescale of months/years I'd wager that the difference in size between these two groups: - those who go months or years without ever having used the thing, and then suddenly change their patterns and start getting use out of it; versus - those who go months or years without using it, and never end up doing so ... is probably an order of magnitude (or maybe a couple) in favor of the latter group. Even ignoring that, there's an implementation strategy up for adoption that facilitates the former use case but doesn't involve persistent services sitting by idly, waiting for the first instance to come along. It doesn't have to be a trade-off; that's not an intrinsic consequence of the problem here. |
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.