Bad coding practices in Fedora packages

[Denys Vlasenko]

I installed F16 on a new machine, trying to keep the installation
more or less lean. Meaning - not installing tons of packages w/o
thinking and ending up with tons of installed stuff I don't even know
what it is.

Today, I'm looking at my process list, sorted by amount of dirtied pages
(which very closely matches amount of malloced and used space - that is,
malloced, but not-written to memory areas are not included).
This is the most expensive type of pages, they can't be discarded.
If we would be in memory squeeze, kernel will have to swap them out,
if swap exists, otherwise kernel can't do anything at all.

And this is what I see (DIRTY column):

   PID   VSZ VSZRW   RSS (SHR) DIRTY^(SHR) STACK COMMAND
  1974  593m  392m  233m 14900  200m    64   208 /usr/lib/thunderbird/thunderbird-bin
  2030  589m  393m  188m 16568  156m   684   344 /usr/lib/firefox/firefox
  1375 27976 14100 14288  5752  9912  3896   132 /usr/bin/Xorg
  1888 71748 55152 14056  4268  9536     0   132 /usr/libexec/tracker-store
  1953  145m 44672 17588  6812  8880    88   132 /usr/libexec/xfce4/panel-plugins/xfce4-mixer-plugin
  2057  167m  9036 18944 10124  8236   280   204 xchat
  4292 15728  8344 10236  1440  7848     0   132 /usr/bin/mc -u -d -C
  1892 36464  7608 16396  7116  7296     0   136 {applet.py} /usr/bin/python /usr/share/system-config-printer/applet.py
  1874 48464 27060 12408  5568  6180     0   132 /usr/libexec/tracker-miner-fs
  1941  107m 13872 14784  8968  5620   768   132 Terminal
  1901 44748 26400 10872  5012  5560     0   132 /usr/libexec/tracker-miner-flickr
...

thunderbird, firefox, xorg are the largest ones, but this
is not a surprise.

Whoops. What is tracker-store? I don't even know what's that
and why is it running, and it's eating ~10 mbytes in DIRTY.
Hmm. There are more of those things - tracker-miner-fs,
tracker-miner-flickr. There go another 12 megs...
And - flickr??
I did not ask anything flickr-related to be *run* on my machine!

Let's see...


$ rpm -qf /usr/libexec/tracker-miner-flickr
tracker-0.12.8-2.fc16.i686
$ rpm -q --info tracker
...
Description :
Tracker is a powerful desktop-neutral first class object database,
tag/metadata database, search tool and indexer.
It consists of a common object database that allows entities to have an
almost infinte number of properties, metadata (both embedded/harvested as
well as user definable), a comprehensive database of keywords/tags and
links to other entities.
It provides additional features for file based objects including context
linking and audit trails for a file object.
It has the ability to index, store, harvest metadata. retrieve and search
all types of files and other first class objects

Ok. I did not ask for this crap to be installed, much less to *run*!
What pulled it in?

# yum erase tracker
...
========================================================================
  Package            Arch     Version              Repository       Size
========================================================================
Removing:
  tracker            i686     0.12.8-2.fc16        @updates        4.6 M
Removing for dependencies:
  grilo-plugins      i686     0.1.18-1.fc16        @updates        405 k
  totem              i686     1:3.2.1-2.fc16       @anaconda-0     8.1 M
  totem-nautilus     i686     1:3.2.1-2.fc16       @anaconda-0     212 k
Transaction Summary
========================================================================
Remove        4 Packages
...


Oh. I see. Looks like it's totem.


In my opinion, a "search tool and indexer", even if it brands itself
"a powerful desktop-neutral first class object database", has no valid
technical reasons to run on the machine all the time, even at times when
nothing is using it, as was the case at the moment I took the above snapshot.
I am pretty sure I did not start totem today (or ever) on this box.

Ok, I get it, not every piece of software is written by geniuses.
It might be f***ed up by design and does require to be run all the time.
But, at the very least, it must not consume tens of megabytes of RAM
while it is idle.


So. My questions for fedora-devel:

Can we do something to either beat this sort of crappy software into
some sort of better shape; or it's upstream would not listen, drop it
from Fedora?

Or are we going to contribute to the continued bloat?

-- 
vda