Re: Akonadi disaster
Dave Stevens <[email protected]>
| Newsgroups | gmane.comp.kde.users.pim |
|---|---|
| Message-ID | <[email protected]> |
Quoting Martin Steigerwald <[email protected]>: > 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