Am Freitag, 26. August 2011 schrieb Ritesh Raj Sarraf: > Are people here using akonadi or any of the tools using the akonadi > framework, in their regular workflow? > (Email, PIM)
I use Akonadi for contacts with KDE 4.6.5 from Debian Sid. This works quite nice. I switched the backend to SQLite however, although after having switched from a ThinkPad T42 with 2 GiB RAM to a T520 with 8 GiB I wouldn´t bother about MySQL anymore and it might even make more sense, since threading for database processes then happens within MySQL, not akonadi server. And I am not even sure whether it would need that much more RAM. It can add up when I run two KDE sessions as I do sometimes. Completion of mail addresses works a bit differently, now I often have to type a complete part of the name with space before it offers any completion choice. I find this quite irritating and often thought that it wouldn´t work. Actually everyone without custom packages who uses KAdressBook is using Akonadi since Squeeze. > Also, the same with Nepomuk. Are people using it or is it just sitting > disabled in everyone's config? Nepomuk is enabled but I basically do not use it. I disabled Strigi, since it crashes on a file it wouldn´t tell me. To what I know a developer improved this for KDE 4.7. Nepomuk Strigi in KDE 4.7 uses separate processes for indexing. Hopefully its also added that it tells one on which file it crashes. And that it skips that file or adds it to a black list. Calling DrKonqi for offering writing a bug report would be nice as well - cause I consider it a bug when a Strigi analyzer crashes on a file. The root bug. Putting Strigi indexers in seperate processes is just a work around - that might serve well when the offending file is reported so that I can write proper bug reports (and hopefully include the file if its not too private). Actually honestly spoken I am - for KDE 4.6 that is - still quite disappointed regarding the state of nepomuk strigi. Its there since ages but it never worked for me or even reported on which file it crashed. I do think asking the regular user to strace -e file nepomuk strigi processes to get down to that information is quite a bit too much to ask. I really hope that the maturity of Nepomuk in KDE 4.7 will be better. I am still reluctant about KMail 2. There have been several data loss reports on kdepim-users mailing lists and elsewhere and I have a ton of mails still on POP3 account I wouldn´t want to loose. I am also concerned regarding the performance. I do know that a MySQL based mail meta data storage can be blazingly fast - with Zimbra at work that opens a +200000 mail folder for linux kernel mailing list as if it was nothing. It does so by first listing just the most recent 200-300 mails and updating the folder contents as I move the scroll bar. Also the lucene based search index build by the server in background is very fast. I do hope that KMail 2 can handle at least 35000-40000 mails in one folder and can handle 100-200 of folders easily. In a mixed maildir / mbox environment. I use mbox for archiving. For that AFAIR it needs some performance fixes for mixedmaildir Akonadi resource that are in maildir resource already. Well as a work-around I might be able to separate the mboxes to a different resource and just use a maildir resource for the maildirs. Actually I wonder whether you Debian Qt/KDE developers are waiting for some fixes for almost fully akonadi based KDEPIM to appear before letting KDE 4.7 loose to us early adoption users. Maybe you are battling with migrating / importing your mail boxes at the moment? That written, I do think that Akonadi is a great idea. I do also like desktop search. I might even find Nepomuk as is useful, as soon as it also writes back metadata to files as much as possible, cause I like it to remain when copying a directory to a different machine with rsync. I would really like if xattrs would be used when the fileformat doesn´t allow for meta data. Its just that these all seem to need quite a bit of maturing. And this processes takes quite long already. It seemed to me that KDE developer have chosen to tackle enormous tasks and then got overwhelmed by it. Good news for me is: Since KDE 4.5/4.6 in most other areas and in KDEPIM as well KDE developers tend to concentrate on bug fixing. It seems in general that KDE 4 finally has landed in some stabilization phase. It needs it strongly IMHO. Also good to know is that KDE 5 is not to be intended as such a big change-it-all-at-once-(and-see-what-breaks). -- Martin 'Helios' Steigerwald - http://www.Lichtvoll.de GPG: 03B0 0D6C 0040 0710 4AFA B82F 991B EAAC A599 84C7 -- To UNSUBSCRIBE, email to [email protected] with a subject of "unsubscribe". Trouble? Contact [email protected] Archive: http://lists.debian.org/[email protected]
