Bug 331932

The current way to disable email indexing is to add your $HOME to the list of folders which should not appear in Desktop Search. I wanted to push people to make Desktop Search enabled by default. Hence there isn't a clear disable option any more.

Could you please open detailed bug reports about why your system is un-usable. Lets fix all them.

Closing this as WONTFIX.

Hi Vishesh,

Please provide an option to disable indexing from the UI. Adding $HOME is not "user friendly" at all.

People may want to disable baloo for many reasons:
1- They don't need it
2- Privacy concern (example : mounting encfs in ~/Private)
3- The resources baloo is using (older laptop with slower disk / CPU)
4- They are working with resource intensive stuff (game, dev, etc) and baloo is getting in the way.

I know you want to promote the use of this feature (I have read your blog post) but forcing user is not the good way to do it.

Dear Vishesh,
You can not force people to use this baloo garbage nor can you force people to use KDE. Luckily Xfce4 is an alternative which is good enough for me. KDE4 has some nice things but it I do not need a horribly slow desktop and that's exactly what this baloo crap gives me. I had hoped it would stop using massive IO casusing my 2014 computer to feel like one from 1999 after a few days of "indexing" but on.

Here is a protip for those of you who want to stay with KDE4 despite developers going the GNOME route and trying to force useless garbage on people: Just delete the following files and replace them with symlinks to /bin/true:

/usr/bin/baloo_file  /usr/bin/baloo_file_cleaner  /usr/bin/baloo_file_extractor  /usr/bin/baloosearch  /usr/bin/balooshow

This will work great and you don't have to worry about this baloo virus again.

>... I wanted to push people to make Desktop Search enabled by default.
> Hence there isn't a clear disable option any more. ...
> 
@Vishesh Handa
I sincerely hope you reconsider that.

Meanwhile, "Recoll" has just gained another user.

Reopening this bug. We're deciding what the best way to proceed would be - either adding a disable button or asking distros to split the baloo package to the point where it can easily be uninstalled without breaking functionality.

@Paul: Recoll does not provide real time updates of the index, nor does it integrate with dolphin. Nor does it provide email / contact indexing.

@Oywin: Did you report a bug about the massive IO usage? We tested Baloo out considerably and fixed most of the issues that were reported. Perhaps you could help us diagnose the problem you're having? If you're willing to, please file a fresh bug where we can ask for additional info. 

Also, there are ways to disable baloo, you can edit a config file or just add your HOME folder in the list of the exclude directories.

And finally, please respect the code of conduct. Calling someone else's work garbage / crap / virus is not a proper way of facilitating a discussion.

(In reply to comment #5)

@Vishesh
> Reopening this bug. We're deciding what the best way to proceed would be -
> either adding a disable button or asking distros to split the baloo package
> to the point where it can easily be uninstalled without breaking
> functionality.
> 
> @Paul: Recoll does not provide real time updates of the index, nor does it
> integrate with dolphin. Nor does it provide email / contact indexing.
> 
Appreciate the rethink on this one. Thinking ahead, perhaps the UI should offer a "simple / advanced" interface. In terms of configuration options, compared to Nepomuk, (for my own use scenario), Baloo in it's present state of development is a retrograde step.

Re Recoll - I don't want to start Recoll versus Baloo. However, I will point out that Recoll has indeed real time updates of the index, and fully indexes email. 

Regards, Paul

(In reply to comment #1)
> I wanted to push
> people to make Desktop Search enabled by default. Hence there isn't a clear
> disable option any more.

This is SO wrong. Please reconsider, and give users a proper option to turn it off.

(In reply to comment #5)
> Reopening this bug. We're deciding what the best way to proceed would be -
> either adding a disable button or asking distros to split the baloo package
> to the point where it can easily be uninstalled without breaking
> functionality.

If you want to "to push people to make Desktop Search enabled by default", as you said, just make it enabled by default. When people start looking for a way to disable it, it means that they already decided they do not want this feature, and making it hard for them to disable desktop search will NOT make them reconsider, but just annoy them. In order to disable the indexing I had to spend half an hour looking for a solution, and that is just wrong. Even now, 2 (two!!) hours after disabling it and re-logging into my account, baloo_file_cleaner is still running, spinning my HD endlessly and making my system barely usable. And all this for cleaning up metadata that was created in only two weeks of indexing (that's the amount of time baloo has been running)! Again, this is just not right.

Please, do add the option to disable indexing in the system configuration panel, like any user would expect. Removing the package is just not an option: ArchLinux already provides a separate package for baloo, but kdebase-dolphin, kactivities, kdegraphics-gwenview and kdepim-libkdepim are all dependent on it, so there is no way it can be uninstalled without breaking KDE. And how can a packager compile dolphin both with and without suport for baloo in the same package? And even more than that, why would you force dozens of distro packagers to make efforts for every new KDE release for allowing people to disable desktop search when you can just let them do so by adding a few lines of code?

Vishesh Handa, with all do respect: please, let USERS decide what they want. Not allowing them to do so is an anti-feature, and very much against all open source stands for.

I am so angry right now over the decision KDE devs made to put this Orwellian garbage in KDE by default, and didn't put in a GUI option to disable it. That is a terrible decision, and look how angry you are making people! I've already lost hours of productivity because of this virus, and I want KDE 4.13 but not Baloo! And guess what, it can't be uninstalled because of dependency breakage! Yes, it should be a no-brainer to split the baloo package; that shouldn't even be a question!

baloo_file_cleaner got stuck in an infinite loop for hours and was causing my HD to go completely nuts; baloo goes crazy with torrents and BOINC, and it runs by default upon logging into KDE. At least ASK the user if they want Baloo on or not when first logging in.

@Bob: The cleaner problem has been fixed with 4.13, and you can always disable it. Also, you can uninstall it, if your distro packages it properly. OpenSuse allows you to uninstall Baloo. Please take it up with them.

Also, some specific bugs about what is wrong would be nice - http://community.kde.org/Baloo/Debugging

(In reply to comment #10)
> Also, some specific bugs about what is wrong would be nice -
> http://community.kde.org/Baloo/Debugging

@Vishesh

What is wrong is that baloo is integrated with kde to such an extent that it is *not* possible to remove it without breaking parts of kde - dolphin & gwenview for example.  This has nothing to do with packaging, it's your unshakeable belief that everyone will want baloo.

It's time you took a reality check and realise a lot of people don't! - end of story.

I believe it is very arrogant of a developer to believe they "know" what is best for the user.

The *entire* baloo package should be optional - without breaking other packages.

Bottom line is simple.  If baloo offers us something useful, we choose to install. If it doesn't, we don't.

Choice Vishesh, Choice. 

Regards - Paul

Vishesh has probably spent a lot of time on this Baloo so I will take some time 
to write a bit about it.

THE BIGGEST PROBLEM with it as I see it is that you notice it, specially when you login to the latest KDE for the first time. You _really_ notice it.

I use a raid5 with encryption for my $HOME. Baloo initially made my desktop really slow and unresponsive. It was just horrible to use it during the initial indexing. This indexing did not last for minutes for hours, it went on for days. The computer was on 24/7 wasting energy during this time, it would have taken weeks if I had turned it off normally like I would if it was not to get this baloo to "get through" what it was doing and and be done.

Baloo eventually stopped making my desktop completely unresponsive. My .local/share/baloo/ is now 3.0G. That is not a small amount of data.

IF I DID NOT NOTICE baloo then it would not annoy me and everyone else. I think this would be the first thing to fix, actually. A trade-off Vishesh should consider here is to let baloo indexing take weeks not days. I am serious. Put some sleep() in there. My personal opinion is that it does not need to have a complete index immediately.

If it had indexed very slowly and I had never noticed it "doing it's thing" in the background at all then it would not be a problem. As it is now you really notice that something is hogging system resources. My system disk is a SSD in raid1 with an older harddrive in --write-mostly. I click on a program in XFCE4 and it's there. During baloo indexing in KDE it took ages for a program to start. That is the kind of thing you really notice.

Another issue: When logging into KDE I would get this Policykit dialog asking me for the root password. The process asking for this was "kde_baloo_filewatch_raiselimit". I just removed that and made a symlink to /bin/true and that stopped. I do not know why it would need root permission but baloo asking for that each time you login (unless you tell it to remember your password) is just really annoying and I don't see why it would need root access all the time.

I'm back with XFCE4 now, I used to use KDE all the time long ago and I like to see how it works from time to time. It's just too slow now (even after baloo is done hogging IO), I have no idea why it takes a lot longer to start programs in KDE and there should be no reason for it but fact is that if you click on a program in XFCE4 it's there immediately and when you click even the simplest little thing in KDE it takes a noticeable amount of time to start.

I have a fairly new and modern computer and I am guessing baloo would make any older computer imbarable to use for weeks. First thing to fix would be to make it possible to turn this thing off, next would be to make it pause / sleep between doing what it is doing enough so you do not notice that it is doing something in the background because I think that is the real issue here.

I'd like to add a somewhat tamer comment and reply. I agree it is quite rude to insult someone who is contributing to a community project.  I've been using KDE since the very first version, and while usability waxes and wanes, I for one would like to thank the developers for producing an excellent product overall.

That said, I would like to give you a detailed use-case where desktop search is undesirable, and why this issue raises so many negative feelings. When I upgraded to a new linux release that came with a spiffy new KDE a year or two ago, I noticed that my machine had slowed to a crawl, and it was persisting for hours. I could not figure out what was going on. Then I discovered that something (which at the time I had never heard of) called neopmuk had been enabled by default to let me do "easy searches" on my machine. Well, let me tell you, my small desktop machine at home has about 10 TB of storage on it, much of that occupied, and my work machine has a 24 TB RAID, all linked in to my home directory in various ways. Most of this data is in binary data files which would not be recognized by any normal "exclusion" filters. So it tries to index the whole mess. The problem is that I installed my machine, and had an immediate bad user experience. It took me 2 hours of research to figure out what was causing the issue and disable it. This is very very frustrating, particlularly when you go in blind, not knowing where the problem is coming from. Running an indexer with "nice" does absolutely nothing useful, since such tasks are I/O limited. That is, it causes the disks to churn, and the machine can easily become completely unresponsive.

Anyway, dealt with nepomuk, then I upgrade again, and a similar problem appears, now a completely new indexing tool, and to top it off, the developers decided I shouldn't be able to disable it!  Then, when I follow the various suggestions: 

- add your home folder to the exclusion list -> no effect
- reboot the machine - > still no effect
- add a disabling option to a configuration file -> option wasn't there, added it, set to false, still no effect
- and so on

Finally in desparation I followed the "remove the individual programs and link them to /bin/true" instructions, which made the indexing go away, but I fear that the next time I do a minor system update it's going to come right back again  :^(

There are a LOT of very valid reasons why people don't use and don't want to use desktop indexing tools. I know that many people live their lives without using a single menu and simply search for everything. However, when you have 20 TB of data on your machine and routinely generate hundreds of GB in temporary files each day, you too will want a little box where you can disable indexing!  There is virtually no time I have EVER said "gee I need to find file with the word 'frog' in it, I wonder where it is?"  on my linux box, and bringing my machine to its knees, to accomplish something I never need to do is not a good thing.

Hope that helps. Please do add a simple disable button somewhere...

Gnome has made serious errors with many users by the "we know best" attitude. While the efforts to integrate Baloo and make "search" a more popular thing can be applauded, it is wrong to assume it is "one size fits all". Most of the KDE users are running Linux for a myriad of different reasons, but I'll wager one common reason is the freedom to choose -- software, functionality, look, etc.

The common denominator is CHOICE. Contrary to many peoples' opinion, you have not removed our choices -- but you have made them more consequential. Instead of staying with KDE and choosing to use Baloo or not to use Baloo, you have made the only choice for many user to be use KDE or not use KDE.

From a marketing perspective, having users chose NOT to use your product at all is worse than having them chose not to use a portion of your product.

Please just provide a choice. A simple checkbox to use or not use Baloo. Is that so much to ask?

One other request please, is to provide a simple gui control to clear out the index files once they are created by baloo.  Although once you know what to do it is possible to create the appropriate file in the user area before logging in to the updated system containing baloo and thereby stop the initial indexing process.  However if a user logged in and then discovered the baloo indexation had started then during the time that the $HOME directory was added to the avoid list, or using the other techniques to stop indexing, and then logging out and back in to a quieter machine, there will have been a significant amount of index file space consumed even once it is stopped.  There needs to be some information about which files and directories can be safely deleted so as not to break KDE4.  By the time I stopped baloo on one of my system it had already created about 0.5 GiB of index files - but can I simply delete the entire .local/share/baloo directory or will that cause problems when $HOME is avoided? Since I won't be using the index files it seems reasonable I should be able to delete them - can you say which directories should be removed please?

Also it seems there is some intimate connection between baloo and nepomuk/akonadi - which of their directories can also be safely removed without breaking KDE4 please?  I think my system still has residual directories associated with these and although I had switched off the desktop search prior to baloo arriving I am guessing I have files I don't need but it is not clear what is safe to delete.

I would like the ability to completely remove baloo. It should be a seperate package, and not linked to dolphin, gwenview, etc. The whole idea about Linux is that everything is a file, and each file does one thing well. I don't want Baloo, and I don't trust it, and it made me lose hours of productivity time. I didn't even know it was indexing and didn't know how to turn it off until Googling and seeing in KSysGuard what was taking CPU time. And BTW, baloo_file_cleaner is NOT fixed; it got stuck in an infinite loop after installing KDE 4.13 from openSUSE's current repo.

I really am not liking the attitude of the KDE developers or their response to problems. I've read numerous other reports of people's laptops indexing for days, and people not knowing how to shut it off. How could such a stupid decision have actually gotten into the final release? That's what's perplexing. And what's even more perplexing, is the current attitude of, "No, we're not gonna let you remove it, and that's that. Deal with it."

(In reply to comment #16)
> I would like the ability to completely remove baloo.

you can, on openSUSE at least, remove baloo-file package safely, w/o removing any other applications. that would remove relevant binaries which do actual indexing (cleaner included).
you *cannot* remove all baloo packages (e.g. libbaloofiles4) as other apps and libs link to it.

I opened a bug report for Archlinux to ask for the baloo package to be split:
https://bugs.archlinux.org/task/40161
a decision hasn't been taken yet, but consensus is NOT to do that. One of the reasons for that is that on a multi user system it should be possible to disable/enable baloo on a user basis, and not system-wise: the option should be clearly provided in the system settings window. Another reason is that the package should be split upstream (by the baloo developer themselves) into a library package and the indexer package.

The biggest problem here is the security risk. If I shred a file, it may remain in the index. Or, as someone has said, it may index a file on an encrypted filesystem, and write the index on an unencrypted one.

This shouldn't be enabled by default without asking the user or encrypting the index. This applies to any desktop search system. It exposes users to a security liability without their knowledge. Actually I'm glad it ate my CPU, otherwise I may have not noticed it.

I can't recommend Kubuntu 14 to anyone until a bugfix release comes out with this checkbox.

The absence of a disable button is seriously flawed thinking, the mind boggles how on earth the decision was arrived at not to include one especially as Baloo is really still in the beta phase. Good grief even in Windows you can easily kill indexing by disabling the indexing service. 

I do appreciate that there are people who want semantic search but please do appreciate that there are a sizeable amount of users who do not want to use it.

(In reply to comment #21)
> The absence of a disable button is seriously flawed thinking, the mind
> boggles how on earth the decision was arrived at not to include one
> especially as Baloo is really still in the beta phase. Good grief even in
> Windows you can easily kill indexing by disabling the indexing service. 
> 
> I do appreciate that there are people who want semantic search but please do
> appreciate that there are a sizeable amount of users who do not want to use
> it.

"Seriously flawed thinking" is, I would say, rather an understatement!

For those of us who do not wish to have a "semantic desktop" disabling baloo's indexing is *not* sufficient.

I have, in the relevant sections of baloofilerc, "Indexing-Enabled=false",
"exclude folders[$e]=$HOME/", and just for fun, "folders[$e]=" -- Which, we are told, "disables indexing".

However:

With those settings, baloo *still* gathers "semantic" data, which is stored at
~/.local/share/baloo/file/, comprising an sqlite3 and xapian database. Data is also written to the extended attribute user namespace in the actual file.

As far as I've been able to establish:

The sqlite3 file contains the complete path and filename of *any* file which has been accessed. The xapian database contains any metadata that could be extracted from the file. 

Extended attributes that could be written to the file (as far as I can tell) are: baloo.rating, xdg.tags and xdg.comments. Probably others as well ?

*User beware!* -- I see a very serious privacy/security issue there.

The ability to disable, preferably remove, baloo in it's entirety wouldn't go amiss.

Personally, I see baloo tainting KDE just as Nepomuk had done previously. "Re-branding" isn't always the solution to a problem. 

Interestingly(?) a simple Google search for KDE + baloo I just did returned "About 52,500 results (0.36 seconds)", looking at the first thirty does not give a favourable impression...

Also, even if you exclude ~ from the indexed directories, it will still index your mail (Bug 332195), and there is no UI to disable that.

With all respect to FOSS-contributors, Vishesh does not deserve what some ascribe to him. 
Simply by being a contributor does not permit him to *decide* that we all need desktop searches; and in his blog he wrote that nobody cares if this baloo-thingy makes people considering to leave KDE.

Sorry, but he effectively needs to get a cold shower. I simply have no idea whom to get involved in providing the bucket and whom to fill in the water. It rather sounds like Vishesh is running the show.

Guys, this is not the place to rant. I've re-opened the bug and may/may-not add an explicit button for 4.13.1.

@Uwe: In KDE we have a Code of Conduct, please follow it while posting comments.

@Everyone Else: It would be awesome if you could help solve the problems you're having. Follow the guide over here - http://community.kde.org/Baloo/Debugging and report detailed bugs. Unless you just want to complain, in which case please do that on the forums.

PS: If you use Kubuntu, you should change the default io scheduler to 'cfq', instead of 'deadline'. Ubuntu's default, aka deadline, does not offer priorities and will make your system unusable.

ArchLinux bug report mentioned above closed. Result: WON'T FIX. This is mainly due to the fact that Arch ships vanilla software: baloo provides a single tarball, so they do. If you want to have distros splitting the packages to allow users to remove baloo, this needs to be done at the KDE level first. Is it going to happen?

Vishesh, I understand that the attacks you've received over this have gone too far. But let's have an open, technical discussion: why do you say "may/may-not add an explicit button"? What are the reasons for which you think having one might be a problem? Can you elaborate here on the plus and cons of that? Being open, and trasnparent on the implementation choices is what the Code of Conduct suggest, isn't it?

Among many attacks (which, again, are bad and totally uncalled for), I think some of the comments above provided quite a number of reasons for wanting to disable baloo: privacy/encryption, over-the-net disks, etc. Because that's the problem we are having here: we just want to disable baloo. How more can we help solve that?

@vishesh
Does it not seem a bit unreasonable to you to say that A) everyone is forced to use your product (because the official mechanisms for disabling it do not work), and B) that to use your product you need to fundamentally alter your system tuning (changing 'deadline' to 'cfq'). Clearly the Ubuntu/Kubuntu developers feel that 'deadline' offers superior interactivity for desktop machines. If you believe that 'deadline' should never be used under any circumstances, surely this is a discussion you should have in the linux Kernel forums before attempting to force this change on anyone wanting to use KDE? You are putting the end-users (to many of whom the advice you offered here would be meaningless technical jargon) in a very very bad situation. The vast majority of KDE users will know their machines became unusable but only a very tiny fraction will know enough to even  findin this posting where the issue is being discussed. Most will just silently suffer, not knowing what is going on, and wonder why people think KDE is so good when it clearly makes their machines so unresponsive. 

Understand I am in no way trying to be abusive or insulting. My group develops open-source software as well, and I'm quite familiar with how annoying it is when you develop something for free, and all you get is criticism. I believe you are trying to produce a valuable product, and indeed, desktop search offers some excellent possibilities for many normal users. However, you need to also understand that your current strategy is having a _severe_ impact on the productivity of MANY people, and that your project does not exist in a vacuum, but in a community.

(In reply to comment #25)
> Guys, this is not the place to rant. I've re-opened the bug and may/may-not
> add an explicit button for 4.13.1.
> 
> @Uwe: In KDE we have a Code of Conduct, please follow it while posting
> comments.
> 
> @Everyone Else: It would be awesome if you could help solve the problems
> you're having. Follow the guide over here -
> http://community.kde.org/Baloo/Debugging and report detailed bugs. Unless
> you just want to complain, in which case please do that on the forums.
> 
> PS: If you use Kubuntu, you should change the default io scheduler to 'cfq',
> instead of 'deadline'. Ubuntu's default, aka deadline, does not offer
> priorities and will make your system unusable.

(In reply to comment #26)
> ArchLinux bug report mentioned above closed. Result: WON'T FIX. This is
> mainly due to the fact that Arch ships vanilla software: baloo provides a
> single tarball, so they do. If you want to have distros splitting the
> packages to allow users to remove baloo, this needs to be done at the KDE
> level first. Is it going to happen?
> 

For frameworks, more parts of Baloo are being split up. But I don't think it's ever going to reach a state where one can just remove Baloo without affecting anything else.

> Vishesh, I understand that the attacks you've received over this have gone
> too far. But let's have an open, technical discussion: why do you say
> "may/may-not add an explicit button"? What are the reasons for which you
> think having one might be a problem? Can you elaborate here on the plus and
> cons of that? Being open, and trasnparent on the implementation choices is
> what the Code of Conduct suggest, isn't it?
> 

Yes. I mostly haven't responded to comments because of the language used. It's highly demotivating.

Here is my thinking (which may just be faulty) -
- I find it distasteful that when you go to configure a software the first thing you see is how to disable it. I understand that you may dis-agree, but that is my opinion.
- The people who seem to complain about performance / disk io / etc - complain after seeing the baloo_file_* process. This process doesn't give them much info that they need to go to Desktop Search -> Disable. They need to search online for an answer. In this case, they get the answer they are looking for, it's just not an obvious button.
- Privacy Concerns / NFS - That's exactly what the exclude folder is for. You care for your privacy and do not want 'x folders' ever indexed, so you disable them from searching over there. That is exactly the case we envisioned.
- It's not intuitive - Yes, it's not terribly intuitive if your sole aim is to disable it. But then as previously mentioned you're do a google search anyway, you can edit the config file or add HOME to the list of exclude folders. 
- I still haven't seen a proper use which is not "But it's not intuitive on how to disable it". Yes, it's not intuitive, but do you really care? Disable it and move on.

Reasons for adding it again -
- A few vocal minority are complaining a lot.

This is why I say may or may not add it again.

Just realised, Vishesh is right... hey after all, we're only the ignorant users.

What on earth would we want to *disable* his wonderful creation for?

Sorry Vishesh ... End of tether reached.  

Guys, give up... we're banging our heads against a thick brick wall....

Subscribe to some of the (developer) KDE mailing lists, all is not happy in KDE land.

Until sanity is restored setting the permissions on ~/.local/share/baloo to 1000 is a pretty good opt out.

I'm off, where's my coat?

Regards to all... well, all but one.

OK, I tried to be calm, understanding and patient. Apologies in advance, but here is what I heard/inferred from your last email, Vishesh:

1) *I* don't like disable options visible in software.
2) *I* think some comments are demotivating.
3) *I* think people need to do an online search to fix their problem with this AFTER finding the baloo_xxx process.
4) *I* think fixing the problem is not intuitive, but Google helps people that are serious about disabling it, because I'm not going to make it easy to fix.
5) *I* think people should change all the settings that were fine in 4.12, just so they can add all these "ignore" folders if they don't want them searched for security reasons. Trust me -- that works. (Even though I've already said "Trust me -- Baloo 'just works'!")

And my question for you is:

1) *Who* are you that with lack of foresight, or over-reaching arrogance decide that me as a user should have to redo/reconfigure/Google-search answers to a problem that wasn't there before *you* made your changes?

I am now done with KDE. A checkbox, man. That was all it would have taken.

And guys, Vishesh may be a fine PERSON (I'm sure he is -- I would gladly buy him lunch and chat with him), but he is an arrogant developer that is being PAID to do this job. I will be contacting Blue Systems about his apparent "non-caring" attitude towards the end users.

Vishesh, I've been a developer for 30 years. If I EVER told any of my customers that after a change *I* made that caused them a problem, and the fix was as simple as providing a checkbox they requested, AND I refused to do it because *I* though they needed find a way to deal with it themselves, *I* would be hunting another job!

Sometimes the role of "software developer" is thankless. Suck it up, make the change to allow turning off Baloo, chalk it up to being young and making a bad decision and move on. Otherwise this will eat you up and your reputation will suffer.

But as for me, I'm done with this.

(In reply to comment #28)
> (In reply to comment #26)
> > ArchLinux bug report mentioned above closed. Result: WON'T FIX. This is
> > mainly due to the fact that Arch ships vanilla software: baloo provides a
> > single tarball, so they do. If you want to have distros splitting the
> > packages to allow users to remove baloo, this needs to be done at the KDE
> > level first. Is it going to happen?
> > 
> 
> For frameworks, more parts of Baloo are being split up. But I don't think
> it's ever going to reach a state where one can just remove Baloo without
> affecting anything else.
> 
> > Vishesh, I understand that the attacks you've received over this have gone
> > too far. But let's have an open, technical discussion: why do you say
> > "may/may-not add an explicit button"? What are the reasons for which you
> > think having one might be a problem? Can you elaborate here on the plus and
> > cons of that? Being open, and trasnparent on the implementation choices is
> > what the Code of Conduct suggest, isn't it?
> > 
> 
> Yes. I mostly haven't responded to comments because of the language used.
> It's highly demotivating.
> 
> Here is my thinking (which may just be faulty) -
> - I find it distasteful that when you go to configure a software the first
> thing you see is how to disable it. I understand that you may dis-agree, but
> that is my opinion.
> - The people who seem to complain about performance / disk io / etc -
> complain after seeing the baloo_file_* process. This process doesn't give
> them much info that they need to go to Desktop Search -> Disable. They need
> to search online for an answer. In this case, they get the answer they are
> looking for, it's just not an obvious button.
> - Privacy Concerns / NFS - That's exactly what the exclude folder is for.
> You care for your privacy and do not want 'x folders' ever indexed, so you
> disable them from searching over there. That is exactly the case we
> envisioned.
> - It's not intuitive - Yes, it's not terribly intuitive if your sole aim is
> to disable it. But then as previously mentioned you're do a google search
> anyway, you can edit the config file or add HOME to the list of exclude
> folders. 
> - I still haven't seen a proper use which is not "But it's not intuitive on
> how to disable it". Yes, it's not intuitive, but do you really care? Disable
> it and move on.

Hi Vishesh. I would agree with this, but there IS a real bug here, at least with the Kubuntu 14.04 implementation. If this bug hadn't existed, I imagine this thread wouldn't exist either.  I can report it as a separate bug if you like. This was my experience on two different computers after upgrading from Kubuntu 13.04 -> 14.04:
- My machine literally grounded to a halt after logging in. Literally, my mouse pointer would only move jerkily around the screen for periods of several seconds at a time. Both computers are high-end machines, one with only 4 cores, the other with 16 cores and 128 GB of RAM. Both exhibited this behavior.
- Top didn't reliably report Baloo as the problem since it was an issue of saturating the machine's I/O, not using a lot of CPU.
- When I did identify Baloo as the problem, as you suggested, I googled it, and came up with a few solutions:
 - As you say, exclude your home folder. I did this, and it had no effect. Baloo was still using massive resources.
 - Tried rebooting (with my home folder excluded). Still using massive resources.
 - Added the disabling flag to the buried config file. Still running.
 - Killing the baloo jobs.  They restarted themselves

Finally in desperation, I deleted the baloo programs and created the symbolic links to '/bin/true' as suggested in one of the forums. Unfortunately this means I can't help you with any debugging, as I no longer have the binaries on my machine, but my machine was flatly unusable until I did this. After doing this everything has worked perfectly.  I don't know if this is an inherent baloo problem, or something with Kubuntu's configuration, but this was my experience. I have talked to others who had very similar experiences. 



> 
> Reasons for adding it again -
> - A few vocal minority are complaining a lot.
> 
> This is why I say may or may not add it again.

Vikesh says: "- It's not intuitive - Yes, it's not terribly intuitive if your sole aim is to disable it. But then as previously mentioned you're do a google search anyway, you can edit the config file or add HOME to the list of exclude folders. "

If adding /home to the list of exclude folders actually worked (it doesn't) then I bet people would be complaining less. 

But i already tried adding /home to the list of exclude directories before I started googling about how to disable baloo. From my observations, the exclude folders feature of balloo indexer doesn't work either. But that is a different issue. Personally, I don't care as long as I can disable it with a checkbox.

Vishesh, I have to say that I agree with some of the things you wrote. I guess that a compromise solution could be adding to the desktop search control panel a note on the lines of "Note: adding your home directory will effectively disable indexing entirely (that is, anywhere on the system)." I agree that the wording could be better... ;)
This could work, provided that adding the home directory does trigger the "Indexing-Enabled=false" flag in the configuration. Apparently, it doesn't for some. In my case it did work, but when I added more directories to the black-list it reverted to "true", even though my home dir was still there. It is also important that this "disabling" behavoir does not change in the future (for instance, when external devices are not blacklisted by default).
All in all, such information might even prove useful for user that do *not* want to disable it on the whole system.

@Paolo,

sorry, but you can't be serious! $HOME != [Disable]. I despise silly stuff like that; and I'm sure the majority around me likewise.
Imagine, the avalanche of fun poked on Microsoft by all and sundry, if your only chance to completely disable Desktop Search was to enter "SteveB" as search term! 

I can only hope someone in the higher echelons of KDE / sponsors get wind of this charade and put an end to it.

Nothing at all, by the way, against Vishesh the coder. Though we should be spared Vishesh the benevolent dictator. We have - I think - two, and two are just enough. And both have earned their mettle by more than a decade of dedicated work .... (I better stop here).

@ Paolo:
> Finally in desperation, I deleted the baloo programs and created the
> symbolic links to '/bin/true' as suggested in one of the forums.
> Unfortunately this means I can't help you with any debugging, as I no longer
> have the binaries on my machine, but my machine was flatly unusable until I
> did this. After doing this everything has worked perfectly.  I don't know if
> this is an inherent baloo problem, or something with Kubuntu's
> configuration, but this was my experience. I have talked to others who had
> very similar experiences. 
> 

It may very well be a Kubuntu issue. I didn't know about adding the HOME directory not working. If you're still keen on debugging this, please email me privately or open a new bug report

@ Vishesh (@ kubuntu)

perish the thought! - I have complained enough / too much. But *that* has worked for me, thrice, on kubuntu. Once I pointed the exclusion to /home/me, the thing was gone. 

Now I am still looking for a method to get rid of the data; the file_cleaner has been going rounds and rounds of now the third session and 60 hours of wall time, well above 2 hours of CPU time. Yes, the bug report has been filed. No, I didn't dare to delete the database. There is not THE database, there's a bunch and I don't want to break anything further.

My fault, my mistake && my excuses!
I run 3 kubuntus, and actually (incidentally?) the 32-bit kubuntu did write the 'false' and does not restart the indexer; while the 2 others (64 bit, but can be unrelated) also wrote the 'false', but the indexer *is* started, though correctly doing nothing:
"No index information found" and consumes no CPU time.

Hi Vishesh,

While I'd be happy to help debug the issue, I'm not sure what I can do to help at this point. I was using 64 bit Kubuntu 14.04, stock install on two different computers. I can give more specs if you think it's useful.  Followed the instructions to add my home directory to the list of excluded paths, and it seemed to have no impact on Baloo. It continued to run very aggressively. As I mentioned, the only way I found to stop it was to delete the two baloo daemon binaries, so I can't readily start it up again, without reinstalling KDE packages...


On May 2, 2014, at 10:33 AM, Vishesh Handa <me@vhanda.in> wrote:

> https://bugs.kde.org/show_bug.cgi?id=331932
> 
> --- Comment #35 from Vishesh Handa <me@vhanda.in> ---
> @ Paolo:
>> Finally in desperation, I deleted the baloo programs and created the
>> symbolic links to '/bin/true' as suggested in one of the forums.
>> Unfortunately this means I can't help you with any debugging, as I no longer
>> have the binaries on my machine, but my machine was flatly unusable until I
>> did this. After doing this everything has worked perfectly.  I don't know if
>> this is an inherent baloo problem, or something with Kubuntu's
>> configuration, but this was my experience. I have talked to others who had
>> very similar experiences. 
>> 
> 
> It may very well be a Kubuntu issue. I didn't know about adding the HOME
> directory not working. If you're still keen on debugging this, please email me
> privately or open a new bug report
> 
> -- 
> You are receiving this mail because:
> You are on the CC list for the bug.

> - I find it distasteful that when you go to configure a software the first
> thing you see is how to disable it. I understand that you may dis-agree, but
> that is my opinion.

If it's an automatically started program (which has side effects) that should be the norm. Most programs don't have a disable option because if you don't need them, you just don't start them. (Actually here a disable option would actually be an option of KDE (whether to start Baloo) and not of Baloo.)

> - Privacy Concerns / NFS - That's exactly what the exclude folder is for.
> You care for your privacy and do not want 'x folders' ever indexed, so you
> disable them from searching over there. That is exactly the case we
> envisioned.

What about mail (akonadi)?

> Now I am still looking for a method to get rid of the data

This worked pretty fine for me:
find ~/.local/share/baloo/ -type f -exec shred {} \;
rm -R ~/.local/share/baloo

@ Grósz Dániel : Me old *nix person. Know how to do *that*.
But - so I am told - gwenview segfaults without these files, and Dolphin starts throwing errors. And since the file utility - so it seems - gets metadata from baloo instead of the file system, and I *guess* that it takes the data from baloo and falls back gracefully if the database doesn't have it, in my personal capacity I'd prefer a dummy baloo database that knows nothing, forwards the request to the file system, and keeps gwenview and Dolphin happy.
Correct me if I'm wrong, and the gwenview crashes and Dolphin serious errors do not come as a result of unreadable baloo-database files, please!

@ Uwe Dippel
This came through on an openSUSE update today for baloo*
- Add 0007-catch-db-setup-fails.diff to ensure dolphin works
  even without the baloo databases (kde#333763)

@ Paul.

many thanks for the confirmation of my / our suspicion; and the link to the appropriate bug report.
Alas, this makes a political re-think even more pressing, when basic KDE applications fail from a missing baloo database. (QA-wise it is wrong that applications need to be patched instead of the offender. QC-wise it casts a glim light on the overall policy that allows the desktop framework to go haywire by the loss of function of an insufficiently tested new application.

[Many years ago we were poking fun at Microsoft for some 40 layers of software stacked on each other to get a Desktop application running - IE 4, anyone? In those days we proudly proclaimed that the beauty of Unix was modularity and choice. The youngsters of today seem to be unaware of these proven philosophies?]

And to finish: The diff helps little, I run Kubuntu, want to get the whole thing fixed (including gwenview and Kmail). And if I still wanted to recompile from diff-s as patches, I would have gladly and comfortably and securely stayed with OpenBSD.

> - I find it distasteful that when you go to configure a software the first
> thing you see is how to disable it. I understand that you may dis-agree, but
> that is my opinion.

This issue is not about personal taste. You are not developing your personal software. KDE is used by thousands of users. 

The Code of Conduct -that you mentioned- states: "Any decision you take will affect other community members, and we expect you to take those consequences into account when making decisions. As a contributor, (...) bear in mind how your changes affect others."

It looks plainly clear that for a significant number of users the provision of baloo, as well as its predecessor, have given major problems.  It is surely only fair to users overall to provide desktop search as an "opt-in" facility rather than an "opt-out" facility.  

For those users who updated their systems and then discovered that their machines were using significant CPU time and disk space that they had not anticipated, and did not want, that the installation of baloo would have been better implemented by provision of a simple switch in the settings gui, with ample advertising that desktop searching was a new facility and explaining why it was useful.  

This would mean that every user who updated to the version that included baloo would not have been inconvenienced at all, and this long running thread would likely have been avoided.

Hence my suggestion is that in the next iteration baloo is provided with an on/off software switch, with the default being "off", with clear information about where to find this control in the System Settings area.

I have seen that the baloo author stated that in 4.13.x that when baloo has $HOME included in the avoid list then it will simply delete the associated database files that have been created without the user's explicit authority, and this is a move forward. However it would also be very useful to provide a "clean-up" switch to explicitly remove not only baloo index files but also any previous akonadi files that were created before the user had a chance to stop akonadi from indexing when that was first introduced.

At least this way I believe that those users who were severely impacted by the default introduction of baloo starting to index when they did not want it to might be placated and this whole vehement angst might calm down.

(In reply to comment #45)
> I have seen that the baloo author stated that in 4.13.x that when baloo has
> $HOME included in the avoid list then it will simply delete the associated
> database files that have been created without the user's explicit authority,

For security reasons that should be with "shred". Otherwise it makes the security problem worse: the user is not even left with an option to shred the database after adding $HOME.

On a side note: why add $HOME to disable, and not / ? Also, if adding $HOME disables everything, how does the user (who likes Baloo) add directories outside of $HOME?

Yes, but shred should never happen automatically! On some drive types (SSDs), shred does not work properly, and can dramatically reduce the lifespan of the drive.

----------------------------------------------------------------------------
Steven Ludtke, Ph.D.
Professor, Dept of Biochemistry and Mol. Biol.         (www.bcm.edu/biochem)
Co-Director National Center For Macromolecular Imaging        (ncmi.bcm.edu)
Co-Director CIBR Center                          (www.bcm.edu/research/cibr)
Baylor College of Medicine                             
sludtke@bcm.edu





On May 4, 2014, at 12:09 PM, Grósz Dániel <groszdanireg@gmail.com> wrote:

> https://bugs.kde.org/show_bug.cgi?id=331932
> 
> --- Comment #46 from Grósz Dániel <groszdanireg@gmail.com> ---
> (In reply to comment #45)
>> I have seen that the baloo author stated that in 4.13.x that when baloo has
>> $HOME included in the avoid list then it will simply delete the associated
>> database files that have been created without the user's explicit authority,
> 
> For security reasons that should be with "shred". Otherwise it makes the
> security problem worse: the user is not even left with an option to shred the
> database after adding $HOME.
> 
> On a side note: why add $HOME to disable, and not / ? Also, if adding $HOME
> disables everything, how does the user (who likes Baloo) add directories
> outside of $HOME?
> 
> -- 
> You are receiving this mail because:
> You are on the CC list for the bug.

(In reply to comment #47)
> Yes, but shred should never happen automatically! On some drive types
> (SSDs), shred does not work properly, and can dramatically reduce the
> lifespan of the drive.

True. Ideally it should be overwritten many times (as in default shred) on HDDs and just once on SSDs, but I'm not suggesting that it's your job to write this code. :) I'd just leave the index as it is, and let the user decide whatever he does with it.

All these converging points of view surrounding one that's fairly unanimous -- putting a on/off switch in the GUI, and the developer still remains obstinate because that's not how *he* feels? Can we put somebody else on the project since he obviously is clueless about anybody else besides himself?

I believe that the author changed baloo to have no on/off switch because there were already indications that there were insufficient users who had switched on the previous desktop search facility - so the evidence that users in reasonably significant numbers had already made the decision to actively "not" use desktop search was already known.  Making the decision to effectively try to force all users to then accept the default and remove the ability to switch off desktop search with a simple switch was perhaps already likely to alienate users.  It looks like the net result could have been predicted ahead of releasing baloo in the current form.

It would really be a valuable way forward to accept that there are sufficient numbers of KDE users who really don't want to have desktop searching on their systems, and design the updated system to allow that to happen without having to find workarounds to avoid having baloo or any other desktop search replacement running on their system. Of course it should remain a free choice and naturally users should be able to easily switch desktop searching on simply through the settings gui. Although I would not want to restart the old flame war that took place when the other major desktop in Linux was changed to dramatically differ from its previous presentation and ergonomics, it is perhaps worth remembering that users left the other desktop in large numbers and moved to KDE.  It might be best to try to bring KDE users back smiling and happy to continue to use KDE.

" Making the decision to effectively try to force all users to then accept the default and remove the ability to switch off desktop search with a simple switch was perhaps already likely to alienate users."

Nepopuke already had a feature with a switch to enable or disable search functionality. If alienation were to occur, don't you think it would've occurred back then and users would have already gotten it out of your system? Your logic makes zero sense. Speaking of flame wars, maybe that's what needs to happen. I do not want this "feature" foisted on me, and neither do numerous other users. This is not Windows; if someone wants to remove Baloo packages entirely, then that should be possible. Even Windows doesn't suck the amount of CPU and disk I/O that Baloo does upon initial boot. On a Windows machine, you don't even notice that it's indexing. My point here is that Baloo is a poorly coded program, and because of that and because of it's performance implications, it should be able to be disabled, removed. Baloo is probably the worst part of KDE that I have ever seen in all my Linux years, and the file cleaner infinite loop bug is _not_ fixed; it still took up 100% of 1 core for endless hours doing _nothing_, and this was after 4/22.

Having desktop search enabled by default (with appropriate security measures such as encrypting the index or warning the user) is reasonable, since it is enabled by default at the competitors so users expect it.

IIRC there were similar issues with Windows Vista too (just as with every desktop search on Linux I've seen, since Beagle). Does someone know if disabling the desktop search is still a common post-installation procedure for Windows folks too, or they sorted out the performance problems?

Disabling Windows Indexing Service (and later Windows Search) is my standard post-install step amongst other things. I realize it's always on by default  and I appreciate that it is always possible to just switch off ths server from the control panel.  KDE has to be at least as friendly as Windows in that area.

When we are back on the topic of the political decision behind this - and, I agree, off-topic w.r.t. this specific bug report - firstly, reading the kde-devel mailing list, there was a huge acceptance visible of this software. So the author did not simply run his own ideas. So much to his defense. 

Secondly, of course semantic desktop is the way to go. However, only when it actually works! As of now, it doesn't. Not only so in KDE. 
I am reminded of the old days and the presentation manager. Before, all applications had their fonts, printer drivers, and whatnot. Then (in my case with OS/2) a presentation manager came ahead, and I had a somewhat unified UI, and a font or a printer would be just available. No need to ask to go back! - And so with a semantic search. Once it just works (it should still have an option to disable it!) the large majority of users will be utmost happy.
BUT - and that's the mistake GNOME made twice already; the first time with GNOME 2 and then with GNOME 3, again - I *still* want to be able to configure my search; if /etc is included or not. And I want it included! Over. This has always been one of the major arguments for FOSS; and it would be fatal to take this choice away!

Thirdly, I am totally opposed to silly hacks like typing strange keywords into almost invisible places to stop indexing. Look, with my old eyes I can enjoy 1024*768 pixels on a 21" screen. And nobody is allowed to purge this liberty with arguments of 'resolution' or 'real estate', nor 'beauty'. It is my computer, and I can do with it whatever I like, including testing its resistance to a sledge hammer.

And I won't give in for less.

"Having desktop search enabled by default (with appropriate security measures such as encrypting the index or warning the user) is reasonable, since it is enabled by default at the competitors so users expect it."

Wrong. Linux users are more times than not more technically inclined than Windows users, hence we're talking about two different camps. And many in the KDE don't want any type of indexing. Therefore, the KDE developers are out of touch with reality.

(In reply to comment #55)
>  Linux users are more times than not more technically inclined than
> Windows users

If they are technically inclined, they could switch it off if there was an option. Btw it is enabled on GNOME too, not just windows, isn't it? (Well, KDE users may be more technically inclined than GNOME users too...)

To clarify a bit about deadline: it seems that Ubuntu changed to deadline io scheduler (elevator) with the 14.04 release (its release notes mention the change). Deadline, unlike the previous default io scheduler, cfq, doesn't support io priorities or classes (unless something changed and the available documentation is outdated), so with it you can't tell processes to use the disk only when other processes aren't using it. Cfq seems to be a better desktop option (while deadline might be preferable on servers), if only because of those io priorities/classes (it should generally offer better interactivity/responsiveness, including starting programs quickly when the disk is busy with something else[1]; in the Windows world, Vista introduced io priorities, and their search takes advantage of that). It is a mystery to me why Ubuntu made the change (cfq is still the kernel default; Ubuntu started using one kernel for desktops and servers some time ago, thus they stopped having a server kernel with deadline as default). I fail to google out any discussion concerning the change in Ubuntu. It seems some people were having better boot up/KDE loading performance with deadline, some years back.

baloo is a program that would be the prime beneficiary of io priorities/classes, and, as luck would have it, in one of the most popular distros introduction of baloo coincides with the change to an io scheduler not supporting them. There's now a bug report open about it[2].

One can change the default io scheduler to cfq by adding "elevator=cfq" to the bootloader's kernel line or it can be changed on the fly by issuing "echo cfq > /sys/block/sdX/queue/scheduler", although I don't know if it would have an instant effect on the running baloo processes. 

I would be interested to hear from people having problems with baloo if changing the io scheduler helps. 

My 8 years old PC works well with baloo indexing.

[1] http://algo.ing.unimo.it/people/paolo/disk_sched/results.php
[2] https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1310402

(In reply to comment #57)
> baloo is a program that would be the prime beneficiary of io
> priorities/classes, and, as luck would have it, in one of the most popular
> distros introduction of baloo coincides with the change to an io scheduler
> not supporting them. There's now a bug report open about it[2].

oooo!!! very bad luck!!!  I feel sad now for the authors of Baloo. 
thanks lucke@o2.pl for the explanation. That was the most interesting post in this entire comment thread.

Git commit 77a4ec2cd7e59035efe895e12912c0695b11deef by Vishesh Handa.
Committed on 22/04/2014 at 14:29.
Pushed by vhanda into branch 'KDE/4.13'.

Add an explicit disable checkbox for Baloo

This adds a new string "Enable Desktop Search"
FIXED-IN: 4.13.1
CCMAIL: kde-i18n-doc@kde.org

M  +7    -0    src/file/kcm/configwidget.ui
M  +26   -3    src/file/kcm/kcm.cpp
M  +2    -0    src/file/kcm/kcm.h

http://commits.kde.org/baloo/77a4ec2cd7e59035efe895e12912c0695b11deef

It doesn't directly concern this bug, which has been already resolved anyhow, but for complexity sake in regards to my previous deadline comment, here's what man pages have to say about cpu and io scheduling classes used by baloo (with cfq):

man ionice:
 Idle   A program running with idle I/O priority will only get disk time when no other program has asked for disk I/O for a defined grace period. The impact of an idle I/O process on normal system activity should be zero.

man schedtool:
SCHED_BATCH [ since 2.6.16 in mainline ] SCHED_BATCH was designed for non-interactive, CPU-bound applications. It uses longer timeslices (to better exploit the cache), but can be interrupted anytime by other processes in other classes to guaratee interaction of the system. Processes in this class are selected last but may result in a considerable speed-up (up to 300%). No interactive boosting is done.

*** Bug 335021 has been marked as a duplicate of this bug. ***

(In reply to comment #2)
> Hi Vishesh,
> 
> Please provide an option to disable indexing from the UI. Adding $HOME is
> not "user friendly" at all.
> 
> People may want to disable baloo for many reasons:
> 1- They don't need it
> 2- Privacy concern (example : mounting encfs in ~/Private)...........

Yeah,  privacy is important. Privacy if you are using a shared computer, and privacy for possible malware/intrusion.
I really do not know how Baloo works, but everything related to indexing and collection of personal data I do not like it and it gives me a bad feeling. It should be possible to disable it for those who think like me.

(In reply to comment #62)
> (In reply to comment #2)
> > Hi Vishesh,
> > 
> > Please provide an option to disable indexing from the UI. Adding $HOME is
> > not "user friendly" at all.
> > 
> > People may want to disable baloo for many reasons:
> > 1- They don't need it
> > 2- Privacy concern (example : mounting encfs in ~/Private)...........
> 
> Yeah,  privacy is important. Privacy if you are using a shared computer, and
> privacy for possible malware/intrusion.
> I really do not know how Baloo works, but everything related to indexing and
> collection of personal data I do not like it and it gives me a bad feeling.
> It should be possible to disable it for those who think like me.

This bug is resolved as FIXED. I'm not sure what you are complaining about.

Oh dear god this is a mess. I don't tag files, I don't search files, I don't need the services Baloo is providing me therefore and most importantly I don't want to see it running. Updatedb, locate and grep is all I need! So naturally I did disable Baloo as soon as the option was available. The problem is that I just noticed that dolphin, other than the size of the file itself, is not showing me any file related options any more.

So here is my question: is this a sideffect of disabling Baloo? 
Ohh and by the way I still see the Baloo fileextractor running in iotop sometimes. 

If my assumptions are correct than this is totally not fixed. I still have a not completely disabled Baloo while my desktop environment is now missing the most simplistic features.

I hate to be that guy, I love kde, but Nepomuk / Baloo in my eyes is a cancerous spreading disease and for some reason no one can stop it.

Three ways to disable Baloo -

1. $ balooctl disable
2. System Settings -> File Search -> Disable
3. Edit the ~/.local/baloofilerc file manually

I cannot make it simpler.

(In reply to Vishesh Handa from comment #65)

> Three ways to disable Baloo -

Here is what I get following all three:

> 1. $ balooctl disable
$ balooctl disable
Disabling the File Indexer
$ ps ax | grep aloo
 2972 ?        SN     0:00 /usr/bin/akonadi_baloo_indexer --identifier akonadi_baloo_indexer

> 2. System Settings -> File Search -> Disable
[done]
$ ps ax | grep aloo
 2972 ?        SN     0:00 /usr/bin/akonadi_baloo_indexer --identifier akonadi_baloo_indexer

> 3. Edit the ~/.local/baloofilerc file manually
$ cat /home/myhome/.kde/share/config/baloofilerc | grep Enabled
Indexing-Enabled=false
$ ps ax | grep aloo
 2972 ?        SN     0:00 /usr/bin/akonadi_baloo_indexer --identifier akonadi_baloo_indexer

> I cannot make it simpler.

$ ps ax | grep aloo
 2972 ?        SN     0:00 /usr/bin/akonadi_baloo_indexer --identifier akonadi_baloo_indexer
$ kill 2972
$ ps ax | grep aloo
11113 ?        SN     0:00 /usr/bin/akonadi_baloo_indexer --identifier akonadi_baloo_indexer

How to kill this bug? ;-)

@Uwe: Ah. The akonadi parts are completely separate. They use the name Baloo since it was easier to write all the indexing code in one repo.

Currently there possibly are ways to disable the Akonadi bits, but It would have adverse effects on the other parts, and I'm not sure if it would be permanent. You could say it is non-optional for now.

Vishesh, we've had this conversation before. I have even contact KDE sponsors about this intrusion in the past. Listen, it's simple: make this search thing -- whatever you want to call it -- able to be disabled. You and KDE do NOT know what is best for everyone.

"Non-optional for now" seems to be a thinly veiled way of saying "I am superior in knowing what people must have and will o it this way." KDE seems to be a wonderful collection of software, but this fiasco makes it very Gnome-like. The Gnome developers have already publicly stated that they do not think their users need to make decisions. Why don't the Baloo/Akonadi developers do the same and just settle this?

It is a BUG. Make these search tools OPTIONAL because we -- the USERS -- decide what runs on our machines. If we wanted no choice, we'd just run Windows and be done with it.

Just like to add my 2 cents about this.  Kdevelop is now worthless for me.  Indexing takes a long time, and while it's indexing, I can't do anything!  I can't type.  It hogs up all the cores when it runs.  Every time I save a file, it does this.  Sometimes, it even crashes.

https://bugs.kde.org/show_bug.cgi?id=392336

I run into this often, which is closed.  Unless the indexing feature is flawless, which it's not, there should be an option to disable it.

After using kdevelop for over a decade, I will most likely switch to using a different IDE.   It's just not usable right now.  I regret upgrading to the latest version.

Just like to add my 2 cents about this.  Kdevelop is now worthless for me.  Indexing takes a long time, and while it's indexing, I can't do anything!  I can't type.  It hogs up all the cores when it runs.  Every time I save a file, it does this.  Sometimes, it even crashes.

https://bugs.kde.org/show_bug.cgi?id=392336

I run into this often, which is closed.  Unless the indexing feature is flawless, which it's not, there should be an option to disable it.

After using kdevelop for over a decade, I will most likely switch to using a different IDE.   It's just not usable right now.  I regret upgrading to the latest version.

@thang - KDevelop is unrelated to baloo

(In reply to Stefan Brüns from comment #71)
> @thang - KDevelop is unrelated to baloo

and your point? no one's talking about baloo.