3 ms·

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/

• cycloptic 7y ago
  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 7y ago
    > 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 7y ago
      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 7y ago
        > 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.