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 _______________________________________________ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
