[cxr]

Here's a subset of active processes on my system, where I know that these have never fulfilled their purpose, given the way that I use my computer:

- /usr/lib/evolution/evolution-source-registry

- /usr/lib/evolution/evolution-alarm-notify

- /usr/lib/evolution/evolution-calendar-factory

- /usr/lib/evolution/evolution-calendar-factory-subprocess

- /usr/lib/evolution/evolution-addressbook-factory

- /usr/lib/evolution/evolution-calendar-factory-subprocess

- /usr/lib/evolution/evolution-addressbook-factory-subprocess

- /usr/lib/evolution/evolution-calendar-factory-subprocess

- /usr/lib/evolution/evolution-calendar-factory-subprocess

Side note: I blogged about this last year, outlining a policy that distro package maintainers could adopt:

https://www.colbyrussell.com/2019/05/15/may-integration.html...

The idea is that any background service should be sufficiently self-aware, i.e., able to understand that (a) it is a service was installed by default (without explicit action on the part of the user; it was just included in the default install) so that it may at some point be of use, and (b) in the last (say) 4 months since the system was first installed, the service has never been exercised for its original purpose. Given those conditions, the system should retire the service for the foreseeable future, so that it no longer runs in the background.

[cycloptic]

Using a heuristic like that is mostly unnecessary when your daemon supports socket/dbus activation. In that case it's only brought up on-demand when another program tries to send a message to it.

The programs you listed are part of evolution-data-server and are used as the backing store for your calendar, clock and address book, which the GNOME panel integrates with. You can kill them but gnome-shell will start them right back up again when you open the calendar and it does a query to see if you have any events.

If you're in a non-GNOME session (like i3) and systemd is still starting those daemons, you can turn them off with some stop and disable commands:

    systemctl --user stop evolution-addressbook-factory 
    systemctl --user disable evolution-addressbook-factory
    systemctl --user stop evolution-calendar-factory
    systemctl --user disable evolution-calendar-factory
    systemctl --user stop evolution-source-registry
    systemctl --user disable evolution-source-registry

Or you can try your luck with removing the evolution-data-server package.

[cxr]

> try your luck with removing [...]

Sure, I could. But refer to my comments in that post:

> I'll uninstall these sorts of things, unless there's any resistance at all [...] in which case I tend to immediately write it off as not worth the effort

My comment was not a StackOverflow-style cry for help. It was only meant to provide some data points in response to the person who asked, 'What are "useless packages"' and an alternative to the other person who dismissed the reference to "useless packages" on the basis that they "were made and included because lots people want them".

EDIT: Thanks for the detailed response, anyway. Since you've written it here, it might be indexed and become useful to someone who is trying to get to the bottom of things—and who maybe otherwise wouldn't have ever found out how to deal with this—and now they can.

[cycloptic]

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 longer) and occasionally send notifications when the user has a calendar event coming up.

[cxr]

> 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.

[cycloptic]

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.

[cxr]

> 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 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.