Re: [opensuse-kde] KDE update, some observations
Hello, thank You for all the information and patience. :-) Dne Čt 1. května 2014 16:38:27 jste napsal(a):
On Thursday 01 May 2014 12:26:12 Vojtěch Zeisek wrote:
Dne Čt 1. května 2014 12:07:51, Jos Poortvliet napsal(a):
On Monday 28 April 2014 05:22:25 Sam M wrote: The vast majority of computer users uses search. Sorry if that hasn't landed for some, but you ARE the exception. Win, Mac, Linux (yes, GNOME has it, too) all use that. 99% of computers can handle it just fine. Baloo indexes ~1000 times faster than Nepomuk and uses ~20 times less memory, putting it on par with the Mac, Windows and other Linux solutions. No reason to not enable it by default, thus. And those few who don't want it can disable it.
From my experience, its performance is much worst than of Nepomuk... And it seems I'm not the only one. There are some bug reports about that.
If you've read http://dot.kde.org/2014/02/24/kdes-next-generation-semantic-search you see that Baloo is much faster for everybody who ever gave feedback to the developers - by a factor 1000 and more. It can index gigabytes of data in a few minutes, emails go by the hundreds per seconds (Nepomuk could index 5 emails/second after YEARS of optimizations).
I still wonder, why destroy one system when it is already matured and working, but I can understand architectonial advances of Baloo and other arguments. It just looks for me as sort of wasting of energy...
Now it is so fast that it sometimes overwhelms the Linux kernel with I/O requests. This is something that heavily depends on your storage setup - SSD's, drives, how many, how they are partitioned, filesystem. Also on the kernel versions. We've introduced a few patches to slow Baloo down a little bit so that should help a lot.
OK, we'll see.
A related problem could be that there are files which are difficult or impossible to index. These are automatically identified by Search and then put in a 'ignore' list but the detection process is unfortunately slow. The initial version took at most 30 minutes per file, usually more like 15. A recent patch (should now be in the openSUSE packages) should shorten that to about 10 max, usually 5 minutes and it should stop trying when you take the powerplug out on a laptop.
You can find this and more information on http://userbase.kde.org/Nepomuk
Yes, baloo generates quite a bit of I/O, they've added a patch to throttle that now, I believe. It is actually a kernel issue (anything before 3.14 can not deal well with high I/O). This I/O problem shouldn't take long as Search indexes very fast - thousands of files per second.
This „bit“ means the computer is unusable. It lasted for several days, no change to better, so I disabled it. The bug is reported and I'm not the only one. I want use desktop search, but for me, latest Nepomuk worked fine.
Again, this is a problem in other parts of the system that we have to work around. Patches should be in the latest openSUSE packages but we're still working on more...
OK, I hope it will work with also with kernel 3.11...
In case it bumps into files which can't be indexed, it will try to determine what file is un-indexable and then disable indexing for that file for the future. Unfortunately, determining what file is hard to index takes a while - about 30 minutes of full cpu and IO at most, per broken file. This has been decreased for 3.14.1 to about 5 minutes at most and will stop/not happen on battery power.
openSUSE 13.1 has kernel 3.11, will it work there? Or do I have to add an extra repository for newer kernel?
Yes, Nepomuk never had this issue because it simply as so slow that it wouldn't eat the entire I/O of a system and I guess the devs use newer kernels that deal with it better so they didn't notice.
It's fixed and I think these patches are now in openSUSE Current.
OK, I'll give it one more try...
I looked around the internet some, and I found a funny post on the Kubuntu forum:
"After a few days baloo settled down on my system but on my wife's laptop baloo kept going and going for days making it really difficult to do anything. I found a message that ~/.kde/share/config/ baloofilerc has a line in it under [Basic Settings] Indexing-Enabled=true I changed that to Indexing-Enabled=false and the laptop was useable again, but lost a few search items. It's nice when it works but hell when it hogs the system."
I love the beginning where he says: "After a few days", and keep in mind that the 2.5" hard drive on his wife's laptop isn't exactly an icon for longevity. I can only imagine the wear and tear the first iteration of Baloo is doing to SSD's. Baloo shouldn't start automatically the first time a user logs into KDE, but I hate when OS's ask you questions through a dialogue box when you just want to get stuff done. I don't have an answer to how this should be done correctly, but I want to reaffirm that Baloo should _not_ start indexing anything without the user's permission. They're already talking about allowing it to be uninstalled by having the Baloo package be split. I want this, because I want to uninstall it. And if my supposition is correct, I don't think I'll ever be installing it again -- not that I don't think it can become better. I just don't need it.
It is easy to disable (add your home folder to the 'do not index' list in the GUI and it disables itself automatically) and as I said before, the vast majority of the computer users on this planet is already used to using search, both on the internet and on their home computers. The fact that you KNOW what it is in the first place makes you an exception (like me, yes).
One problem is performance. Second is total lack of configurability. Of course, it is good to optimize it for most of users. But it is not possible to meet everyone's needs. So that I (and not only I) consider lack of possibility of finer configuration as big problem.
What kind of configurability are you missing? You can disable indexing your files or exclude certain folders, at the moment. What else should be possible?
To exclude particular file type. And possibility not only exclude directory, but to index only explicitly listed paths/filetypes (not only blacklist way, but also whitelist way). Again, Nepomuk had it. Also (not)following symlinks and mounted FS. I understand not everyone need such tunning, but I hope those thinks are not so strange... And it is OK to have good defaults, but KDE was always giving a lot of possibilities to configure... All the best, Vojtěch -- Vojtěch Zeisek Komunita openSUSE GNU/Linuxu Community of the openSUSE GNU/Linux http://www.opensuse.org/ http://trapa.cz/
On 05/01/2014 10:58 AM, Vojtěch Zeisek wrote:
To exclude particular file type. And possibility not only exclude directory, but to index only explicitly listed paths/filetypes (not only blacklist way, but also whitelist way). Again, Nepomuk had it. Also (not)following symlinks and mounted FS. I understand not everyone need such tunning, but I hope those thinks are not so strange... And it is OK to have good defaults, but KDE was always giving a lot of possibilities to configure...
+1 I don't think they are strange, and as you say, many people had it set up this way. What Jos doesn't seem to understand is that I'm not anti-Baloo, I'm against the arrogant way its been delivered, not to say the attitude and touchiness of non-team. If baloo had been delivered as 'nepomuk but faster', honouring the defaults etc as Vojtěch outlines above, along with an entry in systemsettings just as there had been one for nepomuk, then about 98% of the uproar on this list would never have happened. -- The bitterness of poor quality lingers long after the sweetness of meeting schedules is forgotten. --Kathleen Byle, Sandia National Laboratories -- To unsubscribe, e-mail: opensuse-kde+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-kde+owner@opensuse.org
In data giovedì 01 maggio 2014 16:58:26, Vojtěch Zeisek ha scritto:
To exclude particular file type. And possibility not only exclude directory, but to index only explicitly listed paths/filetypes (not only blacklist
An alternative control panel is being developed, addressing exactly these issues, in cooperation with the main developer. -- Luca Beltrame - KDE Forums team KDE Science supporter GPG key ID: 6E1A4E79
Dne Čt 1. května 2014 17:29:29, Luca Beltrame napsal(a):
In data giovedì 01 maggio 2014 16:58:26, Vojtěch Zeisek ha scritto:
To exclude particular file type. And possibility not only exclude directory, but to index only explicitly listed paths/filetypes (not only blacklist An alternative control panel is being developed, addressing exactly these issues, in cooperation with the main developer.
Fantastic, thank You very much, I'm looking forward it. :-) All the best, V. -- Vojtěch Zeisek Komunita openSUSE GNU/Linuxu Community of the openSUSE GNU/Linux http://www.opensuse.org/ http://trapa.cz/
On Thursday 01 of May 2014 17:36:44 Vojtěch Zeisek wrote:
Dne Čt 1. května 2014 17:29:29, Luca Beltrame napsal(a):
In data giovedì 01 maggio 2014 16:58:26, Vojtěch Zeisek ha scritto:
To exclude particular file type. And possibility not only exclude directory, but to index only explicitly listed paths/filetypes (not only blacklist
An alternative control panel is being developed, addressing exactly these issues, in cooperation with the main developer.
Fantastic, thank You very much, I'm looking forward it. :-) Hi Vojtěch, the current state of the KCM can be found in KDE:Unstable:Extra repository, under baloo_kcm name. I'd advise just grabbing the package instead of adding the whole repo ;-)
Cheers, Hrvoje
All the best, V.
participants (4)
-
Anton Aylward -
Luca Beltrame -
Vojtěch Zeisek -
šumski