On 09/03/11 19:23, Niels Mayer wrote:
On Mon, Mar 7, 2011 at 8:09 AM, Arjan van de
Ven<[email protected]> wrote:
To be clear, this does not mean that "tracker" is completely
removed; tracker is still being used (together with tumbler) for
indexing media on the device. At this point we are seeing serious
issues (performance/stability) with this solution, but the first
attempt will be to fix the deficiencies rather than a replacement.
Actually, where exactly are tracker's results used in the Netbook UX
for indexing media? I thought banshee was independently indexing
media as well... sometimes they even get into a fight about it:
http://lists.meego.com/pipermail/meego-community/2011-February/003597.html
There is no evidence on that link that proves Banshee and Tracker fight
with each other, the syslog has no relation as far as I can see to
Tracker. What are you basing this claim on?
At least on the 1.2 Netbook release, tracker does cause problems --
I've disabled its media scanning to prevent issues ongoing issues:
http://lists.meego.com/pipermail/meego-community/2011-February/003605.html
What version is being used in this release?
This link suggests people really don't know what Tracker is doing. There
is no churn when downloading a file, we only index it once it is written
with CLOSE_WRITE.
Clearly Banshee is the problem there. What makes sense is to have a
plugin for Banshee to Tracker to avoid competing for processor time so
they can work together.
Also, if files are being copied around, it is possible to tell Tracker
to ignore certain directories, this may improve things too.
For Maemo issues with tracker -- and potential customizations to
prevent performance issues:
http://lists.meego.com/pipermail/meego-community/2011-February/003598.html
The above link references another link from talk.maemo.org where they
discuss version 0.6.95.x of Tracker. We're not at version 0.10.1. These
versions are worlds apart.
Performance wasn't great for that version and it is supremely better now.
If people turn off Tracker, what happens to the other applications using
it? Do they just suffer?
There appears to be duplicated functionality between tracker and
banshee's media indexing. If other tracker functionality has been
removed for 1.2, and tracker's media indexing results seem to be
unused by banshee, what about removing tracker entirely from the 1.2
Netbook UX?
Because you're taking a step backwards. The data is then not shared or
useful between applications on the device and certainly not for 3rd
party applications.
We've already seen this sort of approach before with Maemo, each group
decides to sit in their corner writing their own DB for their own
solution and then one day, someone wants information from another
component in the system and wonders how to share it. This seems to be
what Banshee have done.
there's a lot of impact from this currently, both in terms of just
raw CPU cycles to power impact to stability (we're seeing quite
some crashes, which worries me from a security pov)
I'm glad this is being considered and I concur. One other issue for
indexing: if a gstreamer codec needs to be invoked first, e..g. for
indexing or thumbnailing media, then is that potentially untrusted
or closed-source codec sandboxed, when executing? What of the
security of the gstreamer pipeline against media-based attack
vector?
Tracker (like applications) go through GStreamer for codec support,
that's nothing to do with us. If it is inherently insecure, that's not
Tracker's fault. Do you have proof or evidence this is the case?
--
All in all, I am quite concerned. I see a lot of random comments about
Tracker not being good enough, generally based on old data or old
threads or without evidence. That combined absolutely NO communication
with core maintainers and channels upstream is not a recipe for success.
Note: We're handling bug reports and patches from 4 bug trackers,
watching 2 IRC channels and 4 mailing lists all the time.
--
Regards,
Martyn
_______________________________________________
MeeGo-dev mailing list
[email protected]
http://lists.meego.com/listinfo/meego-dev
http://wiki.meego.com/Mailing_list_guidelines
