Akonadi disaster

O. Sinclair o.sinclair at gmail.com
Sat Oct 8 05:37:20 BST 2016

On 10/08/16 00:54, Martin Steigerwald wrote:
> Am Mittwoch, 5. Oktober 2016, 15:24:19 CEST schrieb Wolf Drechsel:
>>>> Can we just get rid of Akonadi, Xapian, MySql and so on and have
>>>> plain simple maildir/mobox.
>>>> I know absolutely noone that search for mails outside their mail
>>>> app, be it Outlook or whatever.
>> I left KdePIM more than a year ago for the continuous akonadi trouble.
>> Recently I tried to come back, but still these things seem to be
>> persistant - my first step was to make my CalDAV client work, and I got
>> stuck there, syncing with owncloud failed from the very beginning.
>> KdePIM (Kontact) is a really great piece of software, IFAIK unique in
>> in *nix world, really powerful, hardly lacking any features. It's such
>> a pity that this wonderful product is pulled down so much by the
>> akonadi problems.
>> I really appreciate the hard work all the people put into akonadi, and
>> I absolutely understand that it would be hard to dismiss all that work.
>> But - to achieve a useable product, wouldnt it be a good idea to create
>> a second branch "non-akonadi" of Kontact? - Maybe a little less
>> performant, but reliably working very soon. You know that there's a guy
>> called Pali (and probabely some other people), who got ahead with that
>> idea:
>> https://launchpad.net/~pali/+archive/ubuntu/kdepim-noakonadi
>> Maybe the akonadi option is one for the long run. But during the last
>> year, obviously that beast could not be domesticated.
> Its really interesting how much experiences differ.
> For me the current Akonadi is the best one I ever had. It never has been this
> fast and reliable. Is it perfect? No. Does it have still some issues? Yes.
> Does it still have areas where it is highly inefficient? Yes. But its better
> than any Akonadi I had on this laptop so far. Way better.
> That is my experience.
>> Let's do a try to the "without" approach!
> Pre-Akonadi KMail has its own set up partly quite serious issues. Like for
> example…
> not starting up for *minutes* and more on index file corruption since it first
> rebuilds the index files, but also …
> doing all of the mail handling within KMail itself and thus blocking out
> KMail.
> Granted, even with Akonadi´s single-task at a time, this can still happen, but
> with most recent Akonadi versions its way less annoying for me.
> I agree tough that Akonadi needs more improvement. Its still not as stable and
> reliable and as fast when it comes to latencies regarding user requests as it
> should be.
> I still use KMail nonetheless, cause well I didn´t have an Akonadi crash in a
> very long time… and I see no viable alternative to KMail. For me KMail just
> crushes every other GUI based mail client I tried into pieces in terms of
> features, usability and working just in the way I like it to.
> Anyway, for any users who wants to try out other MUAs, do it. Especially if
> Akonadi doesn´t work for you.
> But if you want to see Akonadi fixed a "it doesn´t work, remove it from KMail"
> to upstream is just not going to work. Upstream was very clear that KMail will
> continue to use Akonadi *unless* another backend becomes more viable. And I
> think upstream still has this oppinion. Maybe at one time the new Akonadi 2 =>
> aka I forgot the new name that Kubemail uses. But not just yet. Maybe not even
> in half a year or year.
> So when you want to continue to use KMail, for now you have to deal with
> Akonadi. Or rely on third party efforts to maintain and develop an akonadi-
> free KMail.
> Honestly, I rather stick with upstream. Upstream KDEPIM already has few
> developers. But at least a few are paid to work on it. A fork of KMail is
> unlikely to have more developers behind it and may not even have even one paid
> developer behind it.
> So to conclude this mail:
> I think that any mount of requesting "make KMail not use Akonadi" is a
> complete waste of energy and time and has no potential to change the situation
> of the one who does the requesting.
> Thanks,
For me this started with the Plasma5 version. In whatever version I was 
using in KDE4 I had very few problems, mainly to do with filtering. But 
right now I have ghost mails all over, certain mails appear in different 
folders, akonadi_imaap eat 20% of my CPU

It constantly reimportant my accounts from the cache (I guess, it could 
be from the database).

And as noted, Contacts search and so on went belly up again, dist lists 
are not working. Again.

The basic problem is: it is a too complex and fragile chain that quite 
often breaks on an upgrade. And that is not how an otherwise fantastic 
mail client should work.

no offence meant to the devs in any way but my hair is getting greyer by 
the day at the moment as I have to go on either webmail or my android 
phone to check that I am not missing out on important business mail.

kind regards, Sinclair

More information about the kdepim-users mailing list