I've been considering a switch to KDE.

While researching Kmail, I came across a slew of threads involving issues with Adkonadi, Nepomuk, Strigi, and others.

It was hinted at in those threads that disabling all the databasing and cross-app integration was not recommended, requiring of manual removal, problematic when updates get pushed out, and capable of breaking basic applications like Kmail.

I have no use for desktop search, unified indexing, tagging, metadata, social sharing, or any of these technologies. I also haven't ever seen a need for comprehensive address books or password managers. At best, I'll never make use of them. At worst, they'll consume memory, CPU, SSD space, and cause information to leak out of applications.

I have no need for my applications to get too smart for their own good through crosstalk and centralization. For my own peace of mind, and resource optimization, I'd have to completely remove all of this stuff.

I know many people consider this a feature, not a bug, and I'm not here to start flamewar or diminish the value of these applications to those who desire the functionality.


Is there any way to keep the DE clean of this stuff, and each app rather self-contained, or is KDE simply the wrong fit for my needs, now and through future development evolution?

If you don't use KDE PIM applications ( ie. for email, contacts, whatever ) then you likely don't need to worry about Akonadi. It will only start if needed ( although Plasma's clock will cause this unfortunately )

Strigi and Nepomuk can be disabled in System Settings > Desktop Search. However, note that Akonadi will automatically start Nepomuk as it uses it to power it's own search regardless of this setting.

In terms of being able to self compile KDE, you can exclude Nepomuk and Akonadi from being built, but this will block building of kdebase and kdepimlibs respectively.

Note that on my system, Nepomuk's memory use itself, without Strigi, is about 20mb. Akonadi uses about 22mb excluding MySQL. Some distributions have configured it to use SQLite though.

Thanks for the reply.

bcooksley wrote:If you don't use KDE PIM applications ( ie. for email, contacts, whatever ) then you likely don't need to worry about Akonadi. It will only start if needed ( although Plasma's clock will cause this unfortunately )

Well, I had been hoping to use the default applications, because so far, I like what I've seen. Each application seems perfect in isolation, it's just the crosstalk which is a bit inappropriate for what I need to do. For example, I don't want to worry about information bleeding over from a business email account in Kmail to personal IM in Kopete, and vice versa.

I also like keeping information modular so if an application should be compromised, by something such as a buffer overflow, the damage stays in that process, and can't access all personal information through a cross-app API, and can't break out of that application's scope in AppArmor.

My first thought had been to find a way to remove the information exchange capabilities totally, as to not be caught offguard by a new feature coming down from upstream. No framework, no surprises.

bcooksley wrote:Strigi and Nepomuk can be disabled in System Settings > Desktop Search. However, note that Akonadi will automatically start Nepomuk as it uses it to power it's own search regardless of this setting.

In terms of being able to self compile KDE, you can exclude Nepomuk and Akonadi from being built, but this will block building of kdebase and kdepimlibs respectively.

Will that stop the daemon and indexing/tagging completely, or just revert it to a run-as-needed model?

I'd have no problem with a custom build, but something tells me kdebase and kdepimlibs are probably necessary dependencies.

bcooksley wrote:Note that on my system, Nepomuk's memory use itself, without Strigi, is about 20mb. Akonadi uses about 22mb excluding MySQL. Some distributions have configured it to use SQLite though.

The memory isn't so much a killer as an annoyance. I could live with the daemons, if I could be certain information isn't leaving each individual app.

MySQL would be running anyway, so there's no additional loss from that.

The information between the address book, email client, todo, etc. is all shared, both prior and after Akonadi. Prior to Akonadi they accessed common files, with Akonadi, they talk to the Akonadi Server daemon, which accesses the files on their behalf. I believe Kopete does access the address book.