41–43 of 43 posts
Earlier quoted context omitted.
A completely vague term for "stuff I don't personally need". They were made and included because lots people want them and consider them useful, obviously. That said, their definition of "useless" is completely at odds with mine, with them preinstalling slack, zoom, spotify and balena etcher.
So why then did you choose the "Windows among the Linux-distributions" as a base?
Who? I am not the author.
Earlier quoted context omitted.
My comment was to give a practical alternative to the solution you were floating which is not really going to work in this scenario. I have done the work in removing the "resistance" for you. Trying to guess which services are inactive and kill them off won't fly when the point of the service is to sit idle for a really long time (potentially on the timescale of months/years, i.e. just as long as you suggested if not…
> 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 origin…
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.
Earlier quoted context omitted.
> 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 origin…
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…
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.