Re: [Tracker] Tracker and Zeitgeist

On 15/07/09 11:19, Richard Hughes wrote:
2009/7/15 Martyn Russell<martyn lanedo com>:
On 12/07/09 18:28, Richard Hughes wrote:
Being blunt, to make it into gnome3, you'll going to have to make
tracker much easier to use, and also make trackerd use much less power
and disk space.
Have you tried 0.7 (and it has not had anywhere near the polish that 0.6

Yes, and this seems to get stuck at 100% cpu much less, but it still
uses significant power when starting up. For me that's a bit issue, as
if 1,000,000 machines all are using 1W extra (not that much) for 1
hour every day because of tracker, then you're using an extra 1MWh
every day. Also, when tracker is hammering the disk and doing the
initial index, it's using _substantially_ more than 1W. I can provide
power graphs if anyone is interested.

OK, interesting.

There are couple of points here.

1. We need to (because of inotify) crawl the file system to set up monitors right now. With the new work alexl and others are doing in the kernel with FANotify, we should be able to avoid this in the future.

2. We get all files and directories anyway because we don't know what changed since tracker was last run. We can circumvent this by having a "last checked" timestamp in the database perhaps and by not doing this on every boot. We only do this in the unlikely case tracker crashes or someone creates content while it is not running. This is quite unlikely of course and we could just force a scan like fsck does every n days and rely on tracker being constantly running for the rest of the time. We may even be able to just provide some applet menu item to recheck the system if files are missing.

With 0.7 the time taken to check all files is pretty small. Only on an initial index is it intensive, but I don't think you can change that much anyway. all need to
stop talking about ontologies and start talking about use-cases and

The number of people who actually understand all this stuff, and are
capable of a SPARQL query without copy and pasting could probably be
counted on one hand. My advice: get a working search bar that real
users can use as soon as possible.

Precisely what I was suggesting at the summit actually. It is a steep learning curve and that's why tracker-sparql has a man page with some examples now. But I would like to also provide some simply common use cases (in another binary?) or with tracker-sparql for users to do some quick checks which are common.


[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]