Hi,
Hi,
On 23-11-16 22:15,
carlosg(a)gnome.org wrote:
The problem we've at the moment is basically that we perform
pretty poorly on resource constrained devices, part of that
is a shitload of running services (on a 512MB device I need
to disable gdm and use startx because running gdm +
gnome-shell together results in swapping which is very
painful on a sdcard).
Oh, sure. Obviously the mobile scenarios I'm talking about didn't have that many
processes running, nor multi-user setups. However, this is not a Tracker problem per se,
rather a general one about minimum required memory to run a multi-user ready full-blown
gnome desktop.
My "solution" for that is to just dnf remove a whole bunch
of stuff, tracker only being one of them.
I must admit I've never noticed a problem specifically caused
by tracker, the whole experience just sucks, so I've pretty
much been disabling everything I can.
Well, if you concretize and turn into upstream bugs, I'll look into it. That's all
I can tell :).
I would prefer a better solution, but given how very bad sdcards
typically are at random access, something like tracker really
_might_ be a problem.
Question which directories does tracker actually scan / monitor by
default ?
XDG folders recursively, $HOME non-recursively. This is all configurable in the privacy
pane in the control-center fwiw.
Is that memory limit still there, but configurable and disabled
now, or ?
Can we re-instantiate it ? I would really like to be able
to offer close to the full gnome3 experience on resource
constrained devices, so I'm wondering if tracker can be
configured to behave a bit nicer there. Maybe we can even
get it to autodetect such systems. E.g. re-instate the
hardlimit on systems with less then 1GB of RAM ?
It can be restablished, I'm not sure you'd enjoy the extra abrtd activity when
tracker-extract "crashes" though :/, unless you disabled that too, that is...
I guess I can make it check low-resources scenarios and try to do the best out of the box
wrt i/o and cpu. But memory-wise I still think the best I can do is valgrinding the hell
out of it, and file bugs to leaky libraries [1], as I've done over the years.
Cheers,
Carlos
[1]
https://bugzilla.gnome.org/show_bug.cgi?id=748608 comes to mind