[prev in list] [next in list] [prev in thread] [next in thread] 

List:       kde-bugs-dist
Subject:    [Baloo] [Bug 332195] Allow to disable akonadi_baloo_indexer
From:       ash <narutoplasma14 () yahoo ! com>
Date:       2014-05-10 23:53:36
Message-ID: bug-332195-17878-dwRcopKoWH () http ! bugs ! kde ! org/
[Download RAW message or body]

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

ash <narutoplasma14@yahoo.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |narutoplasma14@yahoo.com

--- Comment #15 from ash <narutoplasma14@yahoo.com> ---
@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

-- 
You are receiving this mail because:
You are watching all bug changes.
[prev in list] [next in list] [prev in thread] [next in thread]