4 ms·

What are "useless packages" and why were they made?

by chirau 7y ago

diffeomorphism 7y ago
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.
- stragies 7y ago
  So why then did you choose the "Windows among the Linux-distributions" as a base?
  - diffeomorphism 7y ago
    > So why then did you Who? I am not the author.
cxr 7y ago
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#self-culling-services 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 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.

What are "useless packages" and why were they made?

by chirau 7y ago

What are "useless packages" and why were they made?

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.

stragies 7y ago
So why then did you choose the "Windows among the Linux-distributions" as a base?
- diffeomorphism 7y ago
  > So why then did you Who? I am not the author.

cxr 7y ago

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#self-culling-services 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 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.