User: Password:
|
|
Subscribe / Log in / New account

Fifteen years of KDE

Fifteen years of KDE

Posted Oct 19, 2011 1:07 UTC (Wed) by sml (subscriber, #75391)
In reply to: Fifteen years of KDE by tshow
Parent article: Fifteen years of KDE

Don't forget that all those extra features are totally configurable and can be disabled if you like.


(Log in to post comments)

Fifteen years of KDE

Posted Oct 19, 2011 1:17 UTC (Wed) by jackb (guest, #41909) [Link]

Don't forget that all those extra features are totally configurable and can be disabled if you like.
That's what they say but no matter how many thing I tried to disable I still could run into situations like this.

This thread inspired me to install xfce and I already notice a substantial performance boost.

Fifteen years of KDE

Posted Oct 19, 2011 15:34 UTC (Wed) by martinfick (subscriber, #4455) [Link]

You can no longer use kmail without akonadi, so that isn't very useful.

Fifteen years of KDE

Posted Oct 20, 2011 12:51 UTC (Thu) by tshow (subscriber, #6411) [Link]

You can, but it looked to me like Akonadi and Nepomuk were gradually becoming core libraries, which (unless things have changed) also means running MySQL. You can (sort of) disable them, though in my experience that means the notification tray fills up with complaints and some programs refuse to start.

If the useful parts of KDE all become reliant on Akonadi and Nepomuk, it becomes a lot harder to call the result "modular" with a straight face.

Fifteen years of KDE

Posted Oct 20, 2011 13:10 UTC (Thu) by mpr22 (subscriber, #60784) [Link]

Common dependencies do not imply non-modularity, unless it's impossible to swap in a replacement because the dependent items rely on internal implementation details of the common dependencies. (Otherwise, pretty much nothing is modular - how many programs have no direct dependency on libc?) Admittedly, there probably doesn't exist an alternative implementation of the interfaces presented by Nepomuk and Akonadi.

Fifteen years of KDE

Posted Oct 20, 2011 13:18 UTC (Thu) by anselm (subscriber, #2796) [Link]

I'm mystified as to why there is no »no-op« version of Akonadi. It is a caching framework, so it should be straightforward to come up with an implementation that always returns a cache miss and/or falls back on the real data sources with no actual caching taking place. This would get rid of the »why do I need to run MySQL?« issue, among other things. I have kmail from KDE 4.6 running with Akonadi disabled, and it is plenty fast enough for me to not bother trying to get Akonadi to run properly. Akonadi with no caching shouldn't be a lot worse than what I have now.

Besides, if I were to develop Akonadi, a »no-op« cache would be the first thing I'd come up with, simply to be able to debug the rest of the framework.

Fifteen years of KDE

Posted Oct 22, 2011 17:34 UTC (Sat) by krake (subscriber, #55996) [Link]

"It is a caching framework..."

It can do caching. It doesn't have to use the database for that (it doesn't above a configurable data size).

"...so it should be straightforward to come up with an implementation that always returns a cache miss and/or falls back on the real data sources with no actual caching taking place."

Would kind of also ruin the offline support.

"This would get rid of the »why do I need to run MySQL?« issue, among other things."

You would still need one of the database options for the relational data.
Not necessarily MySQL, but then why remove the caching and offline capability if all you want is to use a different DB engine?

Fifteen years of KDE

Posted Oct 23, 2011 0:05 UTC (Sun) by dlang (subscriber, #313) [Link]

some people don't want the caching and offline support (and all the resource use that comes with that)

right now there appears no way to turn this off.

Fifteen years of KDE

Posted Oct 23, 2011 8:45 UTC (Sun) by krake (subscriber, #55996) [Link]

True, minimum cache timeout is one minute, so one will have bear that obviously huge overhead of at least 60 seconds.

I guess if someone wants to have their mail client download headers for all mails every time they click on an IMAP folder they will find an alternative mail client that never ever accesses local storage.

But such a person would have not used KMail at any prior version anyway, because it also did cache headers.

Fifteen years of KDE

Posted Oct 23, 2011 16:25 UTC (Sun) by dlang (subscriber, #313) [Link]

or they will use a smarter IMAP client that doesn't have to download all headers every time you open a folder. from your comment this means not using kmail (I haven't used it so I can't say

Fifteen years of KDE

Posted Oct 23, 2011 17:11 UTC (Sun) by krake (subscriber, #55996) [Link]

When the user tells an IMAP client to open a folder, it basically has three options:

(1) show no content
(2) download headers and populate folder with the recevied data
(3) use cached data to populate folder

Now you have made it abundently clear that you don't want option (3), you seem to be somewhat opposed to option (2) so that leaves option (1).

A valid choice, though I am not sure how many others would use a term like "smarter" to describe such behavior.

KMail (with or without Akonadi) uses option (3), based on the assumption that its target users prefer folders to be populated automatically upon open and prefer not to download headers every single time.

Fifteen years of KDE

Posted Oct 23, 2011 19:47 UTC (Sun) by dlang (subscriber, #313) [Link]

it doesn't need to download all header information, it only needs to download the information needed to display the screen

so not all information and not all headers.

it normally needs to download sender, date received, message size and subject for somewhere between 30 and 60 messages.

this is a far cry from downloading all header information for a folder with 10's of thousands of messages in it.

this does assume that you are using a decent IMAP mail server that can support things like server-side sorts, etc.

Fifteen years of KDE

Posted Oct 23, 2011 16:35 UTC (Sun) by anselm (subscriber, #2796) [Link]

Would kind of also ruin the offline support.

I couldn't care less about KMail's offline support. I run offlineimap, which works a lot better for me, anyway.

[…] but then why remove the caching and offline capability if all you want is to use a different DB engine?

I'd prefer not to have to run a DB engine for the exclusive benefit of my mail program at all, thank you very much. I've been using KMail for years and years without the added complication of a »DB engine«, and I can frankly see no benefit whatever in the added complication. Show me one compelling reason why I would even want to run a complete MySQL or PostgreSQL server just to power my mail reader and I might reconsider. I can tell you right off the bat that caching and offline support are not compelling reasons.

Fifteen years of KDE

Posted Oct 23, 2011 18:10 UTC (Sun) by krake (subscriber, #55996) [Link]

"I couldn't care less about KMail's offline support. I run offlineimap, which works a lot better for me, anyway."

Fair enough, but I hope you understand that it's not a viable option for everbody. A caching service that can be configured through GUI or does not require any configuration at all is targetted at a different type of user.

Mail clients such as KMail or Thunderbird (and most likely also Evolution) acknowledge that this other type of users exists and thus are capabable of providing caching themselves.

I am confident that there are mail clients which target users such as yourself who can take care of such features externally.

"I've been using KMail for years and years without the added complication of a »DB engine«, and I can frankly see no benefit whatever in the added complication."

Choosing to use software components developed by experts in their respective area is considered a common and recommendable practise, i.e. using established libraries and services instead of implementing everything again (often referred to as as "reinventing the wheel").

A couple of years back a lot of programs used to have their own handcrafted code to deal with relational data, usually using some program specific binary format for data and index files.

Nowadays most of these programs have switched to using existing relational data handling code, usually written by people with a lot more experience in dealing with such data than the end user application developer using the library.

KMail used to be one of the applications that still had its own way of dealing with such data, using its own proprietary index format, etc.
It has just followed the trend to use established and well maintained external code for that. If you need any examples of other software doing that check your package manager's reverse dependencies for libsqlite.

It might look like a weird choice from a user's perspective but a lot of software developers seem to agree that this is a good thing.

"Show me one compelling reason why I would even want to run a complete MySQL or PostgreSQL server just to power my mail reader and I might reconsider."

There is quite a range of possible implementations for relational data handling, the two you are referring to here use a service based approach where engine runs in its own process and clients commmunicate with it.
Other implementation run the engine within the client process, e.g. SQLite.

Depending on factors such as size of data set, access concurrency, support for transactions, etc. some implementations will have different advantages and disadvantages.

Therefore different weighting of these factors will result in different ranking of solutions. If your needs are better matched by an in-process implementation then you should be using one. I don't see any value in trying to persuade you otherwise, after all you know your requirements a lot better than anyone else.

Whether some software you are using is capable of using different implementations is of course dependent on whether its developers anticipated a need to have this kind of customizablity.
In the case of KMail, or more specific Akonadi, this is possible.

Fifteen years of KDE

Posted Oct 23, 2011 22:25 UTC (Sun) by anselm (subscriber, #2796) [Link]

Fair enough, but I hope you understand that it's not a viable option for everbody.

I'm a big believer in Heuer's Law: »Any feature that cannot be turned off is a bug.«

A couple of years back a lot of programs used to have their own handcrafted code to deal with relational data, usually using some program specific binary format for data and index files. Nowadays most of these programs have switched to using existing relational data handling code, usually written by people with a lot more experience in dealing with such data than the end user application developer using the library.

True, but KMail doesn't actually appear to use »relational data«. The Akonadi docs say that in the case of e-mail, everything is stored where it used to be stored (maildirs, IMAP server, …) and cached by Akonadi, except for e-mail flags, which hardly require a relational database infrastructure to store. Hence, in the case of KMail, using something like MySQL appears to be an unnecessary complication. It should be reasonably straightforward to offer the alternative of not caching anything and continuing to use the already-existing code (or something else simple) for e-mail flags in KMail. If I was an Akonadi developer I'd do this just to make debugging easier.

It might look like a weird choice from a user's perspective but a lot of software developers seem to agree that this is a good thing.

This is the logical fallacy known as argumentum ad populum, a.k.a. »if everybody does it, it must be right«. »A lot of software developers seem to agree« that using Java or Windows is a good thing, but even so KDE isn't written in Java for Windows. Go figure.

Whether some software you are using is capable of using different implementations is of course dependent on whether its developers anticipated a need to have this kind of customizablity. In the case of KMail, or more specific Akonadi, this is possible.

According to KDE TechBase, you get to pick your database for Akonadi as long as that database is MySQL. If the Akonadi developers have finally got their act together enough to support a less wasteful storage option then that news does not appear to have made it into the documentation, but then again documentation has never been KDE's strong suit.

Fifteen years of KDE

Posted Oct 23, 2011 16:45 UTC (Sun) by dlang (subscriber, #313) [Link]

by the way, it's not the disk space that is taken up that's the big issue for me, it's the memory that these caching processes eat up even when I don't use kmail or any other software that they support. On my laptop with 'only' 2G of ram, these processes eat up a very noticeable amount of it (close to 1/4 of the available ram)

Fifteen years of KDE

Posted Oct 23, 2011 18:36 UTC (Sun) by krake (subscriber, #55996) [Link]

If "these caching(sic) processes" is referring to Akonadi services, then you are most likely unknowingly running "or any other software that they support."

Akonadi is neither autostarted nor restored by a session manager (unless one manually adds autostart support files, which is highly unlikely in your case), but started on-demand by first client.

I think there is a list of less known clients on userbase.kde.org which are known to cause Akonadi startup for users who are strictly against PIM data integration features.

Fifteen years of KDE

Posted Oct 23, 2011 19:53 UTC (Sun) by dlang (subscriber, #313) [Link]

Ok, the only windows I have open are firefox chromium, and xterms. nepomuk is disabled through system settings (kubuntu 11.10)

what did I do to demand that 26 processes with a fairly significant memory footprint start up?

output of smem

Command Swap USS PSS RSS
/usr/bin/akonadi_agent_laun 3024 476 493 1396
/usr/bin/akonadi_agent_laun 3708 512 529 1432
/usr/bin/akonadi_agent_laun 3700 524 541 1444
/usr/bin/akonadi_agent_laun 3688 532 549 1452
/usr/bin/akonadi_agent_laun 3768 532 549 1452
/usr/bin/akonadi_agent_laun 3764 532 549 1452
/usr/bin/akonadi_agent_laun 3664 540 557 1460
/usr/bin/akonadi_agent_laun 3716 540 557 1460
/usr/bin/akonadi_agent_laun 3716 548 565 1468
/usr/bin/akonadi_agent_laun 3732 564 581 1484
/usr/bin/akonadi_agent_laun 3732 568 585 1488
/usr/bin/akonadi_agent_laun 3732 568 585 1488
/usr/bin/akonadi_agent_laun 3728 568 585 1488
/usr/bin/akonadi_agent_laun 3688 568 585 1488
/usr/bin/akonadi_agent_laun 3692 568 585 1488
/usr/bin/akonadi_agent_laun 3724 572 589 1492
/usr/bin/akonadi_agent_laun 3720 576 593 1496
/usr/bin/akonadi_agent_laun 3752 580 597 1500
/usr/bin/akonadi_agent_laun 3708 584 601 1504
/usr/bin/akonaditray 3896 624 644 1612
/usr/bin/akonadi_maildispat 3716 708 732 1720
/usr/bin/akonadi_nepomuk_ca 3668 740 775 1796
/usr/bin/akonadi_nepomuk_co 3388 748 783 1804
/usr/bin/akonadi_control 800 1028 1047 1760
akonadiserver 2712 1096 1145 1792
/usr/bin/akonadi_nepomuk_em 6212 1188 1306 2588

Fifteen years of KDE

Posted Oct 22, 2011 17:25 UTC (Sat) by krake (subscriber, #55996) [Link]

"...which (unless things have changed) also means running MySQL."

or PostgreSQL or SQLite. MySQL is the default though


Copyright © 2017, Eklektix, Inc.
Comments and public postings are copyrighted by their creators.
Linux is a registered trademark of Linus Torvalds