On Wed, Jan 4, 2012 at 10:40 PM, Olav Vitters <olav@xxxxxxxxxx> wrote: > On Wed, Jan 04, 2012 at 03:09:07PM +0900, Joel Rees wrote: >> I suppose I have to go to the gnome lists and raise Cain about this >> kind of fundamental mis-engineering? > > If you want bugs to be fixed, then please file bugreports. I'm wondering if I'm the only one who sees the problems here. I suppose I'm going to have to register over there, get on the list, file the bug, and start teaching them the meaning of problem complexity, which they will initially see as rabble-rousing from an outsider. (Much as I'm sure my first post is seen here.) More time I don't have, especially if I take the time to avoid looking like a troll. > Tracker > should NOT have a noticeable impact on performance (in the default > config). They keep saying that. They are wrong. They don't seem to understand some fundamental problems in the tech, which is demonstrated by their default setup. > Of course it'll have some measurable impact, but if you can > notice the impact in the default configuration, then something is wrong. How many cores, how much RAM, how fast are your CPUs, how much extra disk space before there is no measurable impact? What does this do to the low-power machines that we should all be switching to for our primary workstations? How does this scale across the network when you have, say, just 40 thin clients and a primary file/workload server in a classroom setting, for an easy example? And what does it do to security? Why is there a tracker-flickr that has to be turned off, and what was the user that tracker-flickr was running as? And what was it reporting back to who-knows-where through that social network? Who let that run that way and why? > From what I understood (before GNOME 3.0), tracker was changed so the > performance impact is not noticeable. E.g. I have tracker running but I > don't notice the impact of it. I do not have an SSD. > > I think I missed that other thread about misusing the kernel, so have to > read up on what was said there. What has been said has been missing the point. The sort of desktop search that they are trying to enable falls into a class of problem which must be solved by programs that, when you class them as mathematical languages, are known as an unrestricted grammars. Unrestricted grammars will sometimes go into serious recursion thrashing, trying different branches of solutions and throwing them away. That's the way they work. You avoid that somewhat in thjis case by pre-searching the file system, and that pre-search was what killed the overall system response time for the first several hours (days in some cases) after a new install. But the pre-search was searching things it should not have been searching (which is part of the reason for the huge startup load). By default, each user should have his own database, and nothing outside that user's own file (sub)system should be in it. By default, that database should not be built until the first time the user goes to use the thing, and should only be built for the parts that are being searched. But those defaults conflict with the desire to make search results available without wait the first time the user wants to search. They have not dealt properly with those sorts of conflicting definitions in the design. And then there are those programmers who think that this will be a cool way to finally get a handle on their source code. No. That does not work. Not if you expect to use the machine for any other job, not if you expect to develop code on the same machine. Even when the indexing operation doesn't clash with a running build, indexing all those source files would be a huge burden on however many cores you have. If you want to have /usr/share indexed, it should be a separate index, owned by a "man" user. (Don't get me started on ACLs and capabilities. Not today, not in this thread.) No one should ever want to use this desktop search function to index /bin or /usr/bin, much less /sbin or /usr/sbin. (And there's another tangent I want to avoid for now.) In fact, there is very little outside /home that should ever be indexed. Backup file systems, maybe, but the indexes in those cases should look quite a bit different. The locate databases should be sufficient for those. > PS: Didn't know the term raise Cain, but if you mean: > "To be 'raising Cain' is to be causing trouble or creating an uproar." Cain was a rebel and a rule breaker. Caused his parents a lot of grief. "Raising Cain" is often used as an idiom for causing trouble, but the proper use of the expression is the converse, the various ways his parents tried to teach him the error of his ways (which Cain, of course, considered a lot of trouble). > Don't do above @ GNOME, would only cause you to be banned. If I allocate the time for it, I'll be sure to do so carefully, and try not to sound as much like a stupid know-it-all as I'm sounding here. I'm posting here, using language that is more blunt than I would like, because I just don't have the time, and because Fedora needs to put some brakes on the impact this project is having. > -- > Regards, > Olav Thanks for not kill-filing me immediately. -- Joel Rees -- devel mailing list devel@xxxxxxxxxxxxxxxxxxxxxxx https://admin.fedoraproject.org/mailman/listinfo/devel
