Bug 332195

The Akonadi Baloo indexer can be removed via akonadi console.

I removed Akonadi Baloo Indexing Agent in Akonadi Console but after akonadi server restart agent appeared again.

So how it can be disabled permanently?

(In reply to comment #3)
> So how it can be disabled permanently?

in a 'hackish' way, 3 steps:
1) as Vishesh indicated
2) placing akonadibalooindexingagent.desktop to ~/.local/share/akonadi/agents/
3) removing Autostart from X-Akonadi-Capabilities

(In reply to comment #4)
> (In reply to comment #3)
> > So how it can be disabled permanently?
> 
> in a 'hackish' way, 3 steps:
> 1) as Vishesh indicated
> 2) placing akonadibalooindexingagent.desktop to
> ~/.local/share/akonadi/agents/
> 3) removing Autostart from X-Akonadi-Capabilities

I removed Autostart in ~/.local/share/akonadi/agents/akonadibalooindexingagent.desktop but "Akonadi Baloo Indexing Agent" still shown as Ready after KDE restart.

strange, i did all 3,  the indexer is neither running nor shown in akonadiconsole (restarted akonadi meanwhile, and ran kbuildsycoca4 just in case)

(In reply to comment #6)
> strange, i did all 3,  the indexer is neither running nor shown in
> akonadiconsole (restarted akonadi meanwhile, and ran kbuildsycoca4 just in
> case)

Sorry, I frogot step 1 and only edited desktop file. 
Now agent not shown in akonadiconsole.

The user shouldn't have to disable Baloo in a hackish way. There should be a GUI option, especially now that it's new and is giving me problems already. Not all experienced users are going to know how to turn it off. First Nepomuk, now it's Baloo...I wonder what the next kludge will be thought of next.

(In reply to comment #8)
Can you provide a reference to the problems you mention? (preferably links to bug reports)

This is a security risk!

If you delete a confidential e-mail, it may remain in the index.

This looks like another attempt to shove something users don't want down their throats.

There should be an option in the system settings to disable indexing.

Period.

No hacks, no renaming the program, no fiddling with configuration files.

Agree with alancio.

Can someone please be kind enough to explain in comprehensible terms ( I *am* an old *nix-person!) what those items on the recipe actually mean; and how to do it? (I would not remember the term 'akonadi console' in Unix; would not know about some 'Autostart from X-Akonadi-Capabilities', etc.)

Can someone provide a script for the rest of the world to kick baloo out of action, since it cannot be uninstalled, please!?

Please contact your distro about providing an option to uninstall it. Some distros (OpenSuse) package it properly so that it can be uninstalled.

(In reply to comment #13)
> Please contact your distro about providing an option to uninstall it. Some
> distros (OpenSuse) package it properly so that it can be uninstalled.

@Vishesh:  Having parts of Baloo uninstallable is not an option for multi-user systems (yes, they still exist). Please really consider making a simple, immediately-acting, easy-to-find "off" button that is backportable to 4.13.0

@Packaging it properly in distros :

In some other distros like Arch Linux, it is packaged separately, but programs still require it in the default build. Removing it through package management while forcibly ignoring dependencies leads to Dolphin, file management part in Konqueror, Gwenview and probably other stuff too failing to work

I am experimenting now with recompiling the packages on Arch Linux and it seems that packages can be built to work without baloo

I'd like to know what is meant by "packing it properly" so that i can talk the packagers at Arch Linux into doing it



@Reasons why baloo should be user disable-able :

Whats allready have been mentioned :
 - It may hog resources, no matter how efficient it is
 - It may cache secret information the user would think is securely deleted

And more reasons :
 - It is not possible to predict how it will interact with present or future stuff like weird FS's (shares etc) mounted to some folder
 - It may cache personal information in a public computer (KDE running on a school, inet-cafe, etc computer) where the same user account is used by many actual users
 - It may touch data the user wants untouched (in a computer used by IT professional)
 - It may waste battery power (and not necessarily on a device that KDE itself detects as a portable... for example desktop on UPS or laptop that was not detected as one due to driver issues)
 - It may waste write cycles of Solid State Drives

And one answer that says it all :
 - It is unacceptable that he cannot control a module in his system due to somebody deciding "it should be fine for all users". We are KDE, not a "dont confuse the user" kind of DE and not any locked-down proprietary environment. In KDE the user has access to the circuit breakers panel. period

(In reply to comment #15)
> @Packaging it properly in distros :
> 
> In some other distros like Arch Linux, it is packaged separately, but
> programs still require it in the default build. Removing it through package
> management while forcibly ignoring dependencies leads to Dolphin, file
> management part in Konqueror, Gwenview and probably other stuff too failing
> to work

The same is true in Kubuntu; Gwenview, Dolphin, KMail, etc etc are built with Baloo as a dependency.  Baloo was causing my system to be very slow, so without an easy way to turn it off, I decided to remove it.  It took a fair bit of my system with it, but I guess that's the price I pay for my distribution and desktop choice.  An "Off" button is a must.

(In reply to comment #16)
> (In reply to comment #15)
> > @Packaging it properly in distros :
> > 
> > In some other distros like Arch Linux, it is packaged separately, but
> > programs still require it in the default build. Removing it through package
> > management while forcibly ignoring dependencies leads to Dolphin, file
> > management part in Konqueror, Gwenview and probably other stuff too failing
> > to work
> 
> The same is true in Kubuntu; Gwenview, Dolphin, KMail, etc etc are built
> with Baloo as a dependency.  Baloo was causing my system to be very slow, so
> without an easy way to turn it off, I decided to remove it.  It took a fair
> bit of my system with it, but I guess that's the price I pay for my
> distribution and desktop choice.  An "Off" button is a must.

It looks like Bug 331932 (as a See Also I missed) handles this.  Excellent; thank you.

I'll second this. There should be a simple way of deactivating the indexer, even without the performance issues, baloo will take several gigabytes of disk space for its index files, there's no way of making it non-intrusive for the user.

(In reply to tylergschmidt from comment #17)
> It looks like Bug 331932 (as a See Also I missed) handles this.  Excellent;
> thank you.

unfortunately, disabling Desktop Search doesn't disable the akonadi_baloo_indexer for me (KDE 4.13.3, Fedora 20).

So please fix akonadi_baloo_indexer to automatically switch itself off once desktop search is disabled.

Just checked in 4.14.0. Akonadi_baloo_indexer processes still running, while the main checkbox in baloo KCM disabled, and remains like that even after a reboot

Removing stuff in the Akonadi Resource Configuration KCM does not help, and when i remove "Local Folders" it respawns immediately

Looks like all the issues since 4.13.1 (remaining after the addition of the checkbox in Baloo KCM) are still here

__

Please also take a closer look at Bug 331932 referred to at the above comment

The bug was originally asking for the above mentioned checkbox, and so is fixed as of 4.13.1

But please take a look at comment 8 :

Paolo Palmieri :
"
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?
"

This may not be as critical for your typical home or office desktop user, who generally have the entire KDE SC installed and will suffice with switching off Baloo if he wishes

However from a software maintenance point of view, it makes simply no point that Gwenview or Dolphin or PIM won't work without Baloo. The functionality provided by Baloo is just a minor part of the main functionality of each of those programs

Imagine Dolphin hard-depending (to the point of not compiling and not starting) on some minor plugin for the preview of some format of multimedia files. That would be ridiculous - This functionality is very minor, and with or without it dolphin is a file manager. Perhaps as a software maintainer i would like to drop this plugin in order to legally ship a distro in a country with enforced software patents covering the format of those multimedia files

Same goes for Baloo, it is an extra functionality but logically not crucial. In the case of Baloo, there may be a myriad other reasons why a software maintainer would want to ship a distro where, say, Dolphin is installed with the least possible dependencies

Or me - an IT and i often do custom installations for special purpose systems, where i just want to have control and avoid potentially troublesome modules for the purpose i am tailoring the system for

It would make perfect sense if Baloo integration in apps would work according to this checklist :

For example, i fire up Dolphin, Gwenview or PIM

<1> Detect the presence of installed Baloo, if it is installed, continue to checklist item <2>, if it is not, just switch off the semantic search features and do the basic task of managing files, viewing pictures or reading email

<2> If baloo is installed and capable of working, check the user's settings for Baloo, including not only the self-contained file indexing, but also the user's settings to enable/disable integration with akonadi or other application

Those 2 items sum up all the showstoppers concerning Baloo IMHO. <1> reduces dependencies in packages where they dont make sense, <2> enables users complete control over Baloo's activity, and in a computer shared by few users (while not being a special-purpose system as in <1>), enables each to configure Baloo independently

This looks the best way to me to provide options for all existing KDE users set up everything as they want and ultimately make everyone happy about Baloo

ye- akonadi is back with 4.14.0 although I kicked it off before - realized it b/c my backup solution wasted space with the backup of the akonadi db files ...

In fact i did not see the backup options at all there. The entire Akonadi is hidden under "Personal Information"

If anything is wrong with Akonadi i think its a topic for a separate bug report

Agree with all said! Stupid name 'Baloo' does stupid needless function. Seems like another M$-monkeying.  It ate 16 gigs in my home without even giving me consent.

Please, let us choose. Please, add the button.

Removing execute permission of the 'akonadi_baloo_indexer' binary seems to work for me.

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

I'm the person who filled Bug 341957 and I believe it is a "same-same but different" issue.

I don't want to be able to disable baloo_indexer.

I'm asking for the option to selectively disable indexing of emails as was previously possible with nepomuk.

And I'm asking for a new option to disable indexing emails contacts as a workaround to get rid of the insanity that I'm offered as address completion in kmail. Of course this would be a temporary measure until the suggestions get smart and useful (no duplicates, no typos, no addresses from 5 years ago, etc.) or a way to configure what addresses are suggested gets added.

[a little offtopic, I have an issue that is connected to what have been said here, so sorry for hijacking this bug, I'd just like to bring the connection to attention then to continue on the new bug]

(In reply to Vishesh Handa from comment #13)
> Please contact your distro about providing an option to uninstall it. Some
> distros (OpenSuse) package it properly so that it can be uninstalled.

This seems impossible. I've opened bug 342015 for a compilation failure, but it got closed with an argument that Baloo is not optional. I've reopened it based on the abovementioned comment - before it gets closed again, could you please elaborate (comment on bug 342015) what exact steps do allow "proper" packaging, so Baloo doesn't need to be present?

Please implement the "disable e-mail indexer" option for baloo. I have 2 mailboxes, ~7GiB all together; akonadi eats up *additional* 4.5GiB; and then baloo eats up *another* ~2.5GiB. This is unacceptable.

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

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

There no longer is any relationship between akonadi and baloo indexes.