Akonadi disaster

Dave Stevens geek at uniserve.com
Sat Oct 8 00:16:39 BST 2016



Quoting Martin Steigerwald <martin at lichtvoll.de>:

> 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 left mail for claws a few years ago and immediately got a nice small  
fast MUA, a lot like what kmail once was. It has its own flaws but  
it's fast and doesn't waste my time. For example it will thread a  
mailbox with 40k mails on a very indifferent processor in about 2  
seconds. I know ymmv but that's been my experience.

Dave

>> > >
>> > > 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,
> --
> Martin
>



-- 
"As long as politics is the shadow cast on society by big business,
the attenuation of the shadow will not change the substance."

-- John Dewey







More information about the kdepim-users mailing list