woodsman wrote:Fascinating that KDE devs recommend using non KDE apps to avoid the dicussion.

I'm not a PIM developer, but i am using KDE PIM full time. My suggestion was for everyone who thinks that the current framework is not of their liking (personally I think the switch was worth it, though).

Both closed as invalid exactly because adding this new option would outweigh the benefit (and has anyone thought about maintenance?)

The KAlarm developer resolved the request, although the solution is at compile time rather than run-time. By the way, neither bug report contains an explanation for closing as invalid. Only that PIM apps use Akonadi. End of discussion.

what devs are you refering to

I'm not a PIM developer, but i am using KDE PIM full time.

Fair enough --- I was referring to a comment in one of the bug reports links above but I was not clear about that reference.

"clear vote", a vote total of 12 you consider a proper sampling?

I agree such a conclusion is incorrect, but browsing the web reveals this request is as old as KDE 4.

personally I think the switch was worth it, though

Fair enough but consider the converse.

Akonadi duplicates files for its cache. Why duplicate all maildir files? The files all are text based and fully searchable by several methods. Yes, large hard drives are available these days to encourage wasteful designs, but hardly all people have such drives or can afford them. Hardly all users have bleeding edge hardware or are bleeding edge use cases. Hard drive space is not infinite nor are budgets or needs.

Akonadi is designed to fetch data without the respective application running. KMail is an example. When first testing KMail2 I noticed not only the increased $HOME directory size because of the duplicated maildir files, but Akonadi was fetching mails without me starting KMail. This is not expected or desired behavior for many users. Some folks might respond that this is the way the Akonadi framework is supposed to work. Yet this opens doors to questions. How does a user know when such connections are good or bad? How does a user know when network traffic is benign or malicious? Exactly what is being fetched and when? When a user runs a respective app the user then expects network traffic. The Akonadi framework is based on a presumption that all users store significant personal data online. Or that all users are personal information data junkies. Or that all users have unlimited bandwidth from their ISPs. Yes, KMail does have a configuration option to disable this prefetching behavior but that option is not enabled as the default, nor is there any obvious warning in KMail about this prefetching behavior. This is a matter of keeping users fully informed. Users should not have to read volumes of wiki pages or documentation to discover all of this.

Akonadi increases startup times. I configured KAlarm2 to start at login and the system tray icon does not appear for 30 to 45 seconds after the desktop. There seems to be some impact by this because I noticed opening the launcher menu would stall or hesitate for several seconds. Possibly a bug but that is another discussion.

I've spent time reading about Akonadi. I appreciate that certain types of users benefit from this framework. I'm not one of them. A lot of users are not. I'm not an enterprise user. I am not somebody who maintains personal data online. I have only three POP3 accounts, two of which are used seldom. I receive perhaps a mail or two a day. I don't keep KMail running all day but run the app about twice a day. There isn't anything I can't find in my mails with a simple KMail search or grep. I don't use any kind of contacts management or address book other than a simple text file I carry in my wallet. I don't subscribe to news groups. I don't use IM or IRC. I have a cell phone but I have no need to share or sync data. I'm not a news junkie. I subscribe only to 8 RSS feeds, none of which are high volume. I delete all feeds after viewing and don't need to search them. I use KAlarm rather than KOrganizer because I need only a handful of basic reminders and not a full calendaring app. With respect to PIM apps, I'm uncomplicated. Likewise for many other users.

This is not about buggy software. Akonadi seems to behave well enough in 4.10.1. I just don't need or want the service running on my system. Disabling a service should not kill an entire suite of apps. Akonadi is overkill and wasted overhead for users like me. This is all that such users have asked --- some way to disable or neutralize Akonadi and still use KDE PIM apps.

Akonadi is a good framework for people who want to coordinate a lot of personal information data. Many users do not fall into that category. There are a significant number of users who like KDE but are not personal information data junkies. KDE developers have responded in an unfriendly and terse manner to requests by such users to disable Akonadi. Most requests have not been an attack against Akonadi or the work developers have contributed to Akonadi. The requests have been fair and understandable from the perspective of users who are not personal information data junkies.

Users are told to use something else. Users are told they are free not to use KDE. In some ways these responses are like kicking sand in a person's face. These are users who like KDE, want to support KDE, and then are told not to use KDE apps.

I waited five years to return to KDE. After testing 4.10 I decided KDE finally had matured into the desktop environment envisioned so long ago. I installed and now use KDE as my primary desktop. I like 4.10 --- except the Akonadi framework.

My opnion and I don't 1) dev 2) work for KDE - I don't care, I don't use Akonadi nor Nepomuk and I don't see any repercussions from these technologies being installed. Maybe because I'm running 4.10.x or I have suffient resources (to me the mysqld and Akonadi processes ram usages appears pretty minimal and the cpu usage is non-existant).

That you responded implies you do care in some form or fashion.

I'm not using Nepomuk or Akonadi right now either. Yet I would like to use KMail, KAlarm, and Akregator. I have used them for a long time, both with KDE3 and Trinity. There is no way to use those apps in KDE4 without Akonadi. (Akregator is not yet converted to Akonadi but is in progress. KAlarm can be compiled without Akonadi but that is beyond reach for many users.)

As I shared, I have no complaint against those who use the Akonadi framework (or Nepomuk). They probably need that framework. Many users don't.

Will it make sense to file a new bug report regarding Akonadi?
The Trinity fork was cute but dead on arrival because Qt3 was dead already. KDE 4.4.11.1 is not dead at all. A complete fork to form a KDLite would not get momentum yet. How about offering KDE apps with lite dependencies? Even Gnome/Unity/XFCE users would be happy to install say Kwrite without pulling in 300 MBytes of dependencies. To avoid name clashes in the Ubuntu repository a new name should be found, say KDLiteWrite KDLiteMail, etc.. Can such a development be done in the KDE context? If not, will KDE lawyers sue the fork for the use of too similar names?

The Trinity fork was cute but dead on arrival because Qt3 was dead already.

The Trinity users would disagree. Trinity is alive and well.

KDE 4.4.11.1 is not dead at all.

That would be an option. One challenge with forking only that package set is continually backporting non-Akonadi related patches and bug fixes. KDE PIM apps remain a wee bit more buggy than other packages and having those fixes would be important.

A complete fork to form a KDLite would not get momentum yet.

Some folks are already doing this. I believe the developers at the Slax project produce the equivalent of a KDE Lite. Nepomuk is not built nor any of the PIM apps. Some other packages are not built. Of course, using that type of KDE Lite means using something else for PIM apps.

If not, will KDE lawyers sue the fork for the use of too similar names?

Probably not sue, but probably cause noise. Nothing stops anybody from using the GPL code in a fork, just don't use some of trademarked and registered names.

With regards to the "300 megabytes of dependencies" issue, part of that should be solved in theory with KDE Frameworks 5, which centres around reducing dependencies in between parts of kdelibs. It remains to be seen how much effect this will have on the main applications however.

google01103 wrote: a vote total of 12 you consider a proper sampling?

I believe there are lots of users who don't like the dependancy of KDE to nepomuk/anokadi/sql.

Fortunately there's hope for them:

https://blogs.kde.org/2013/04/11/hackweek9-lightweight-kde-desktop-project-updated

Note that this is simply a packaging change, rather than a code change (I'm involved in the openSUSE KDE team).

After struggling for days to half-way migrate my kmail from kde-4.4 to kde-4.10 I (as a may be 'naive' user)
would definitlely like to see again a working kmail without akonadi/kwallet/nepomuk !

Suse has a project called Klyde aimed at making Akonadi and Nepomuk optional packages. What do you think of this effort?

If you compile without nepomuk and dont use any akonadi based program I thought you was free from sql and akonadi? I have not tried as I use both

That is correct. Please note that Nepomuk has a setting to disable itself as well, which is often the better option to use as some parts of KDE do depend on Nepomuk being available at compile time.

Two things to watch out for with Akonadi - the Digital Clock applet and the Contacts runner use Akonadi and may be triggering it to start under some circumstances - disabling the Contacts running and adjusting all Digital Clock applet settings will fix this though.

Hi guys,

just want to provide a "field testimony" so that you have an idea how it hurts down there in "userland".

While I'm not a KDE contributor myself, I'm an early Linux adopter from the 90's and use Unix computers everyday for a living.
I have accumulated lots of emails in the mbox format over the years (reading with emacs), switched smoothly to KDE in ~2005 and re-imported the whole thing
without a glitch and lived happily everafer with my 3GB mailbox / agenda / log (I use log to trace my activity for my company accounting). You
then probably understand that I have absolutely no desire to "hack" a mail/agenda/log/addressbook application everyday. If it works, it works period.

And when I met KDE3.5 landmark release, I thought I had met my wishlist. Lightning fast, no eye candy, just the job and only the job (which gives me
time to concentrate on my real job which is about gcc C/ANSI natural language processing apps). I was keeping a lazy eye onto the rumors about KDE4.x
and thought I'd be wise to leave it some time ahead to stabilize.

When my computer crashed my sysadmin brought a shiny new computer with shiny new hardware *and* shiny new distrib + kernel that goes with it.

Importing my 3Gb maildir structure into kmail was just a nightmare (no progression bar, CPU 100% for a night, ...). Then moving mail directories around becomes a fool's operation. Then mysql eating a whole CPU on my shiny new quadcore... I just thought "what have they done with all that CPU and memory when a single core was doing the job fine!?".

According to me the reason why Unix has survived from the 70's is mostly the suppremacy of its design around a file system (/dev /proc etc are part of the file system), which means that whenever we access things through the file system we generally have the warranty that we're going to get the best out of the machine (i.e. efficient disk cache, efficient directory structures...). A maildir containing 30,000 emails is no hassle. If you have a machine with 500Mb RAM, well it will work, if you have a machine with 8Gb RAM it will work faster when you access multiple times because system handles caching and optimization for you.

I think you now follow how we get back to the original discussion: when PIM was dependent on the power of the file system alone, it was just a question of how fast your harddrive is rotating and how fat your RAM is to allow faster access when you click twice on your emails/contact/agenda etc. Once the system is tied to SQL & Akondi, whatever the merit of those application (I'm not questionning usefullness, those are usefull for those who have extra CPU/RAM etc) then you hand over your computer resources to those tools. But I frankly think they should be 2nd layer in the background, running on another time scale... to talk Unix again this is the difference between the "find" command and the "locate" command. I don't want the locate/updatedb running at daylight, stealing hard-drive bandwidth from me.

And the worst thing is is that when I question people around me: "are you using a power user solution to handle email/agenda/log/addressbook" ? Most people answer "thunderbird", which is a good answer for emails, but definitely not for agenda & log, then people give hints of loosely coupled gmail/calendar solutions. So, in a word I discover too late that KDE no only had something very reliable but also very unique.

Writing from a KDE4.8.5 (kubuntu LTS)... I just unstable and slow and unprofessional

The PRISM spy attack showed that a war is going on. Therefore I simply do not want certain software on my computer. Maybe one day I want it but today definitely not. I know that there are settings for not starting Akonadi Nepomuk and friends. I did try it but then for various reasons there were error messages, functional errors or server starts despite opting for A+N to stay away. KDE, are there any plans to embrace the Klyde project?

rwolf wrote:The PRISM spy attack showed that a war is going on. Therefore I simply do not want certain software on my computer. Maybe one day I want it but today definitely not. I know that there are settings for not starting Akonadi Nepomuk and friends. I did try it but then for various reasons there were error messages, functional errors or server starts despite opting for A+N to stay away. KDE, are there any plans to embrace the Klyde project?

Wow, now that is a good example of bridging 2 unrelated topics and making buzz where is none
Please don't bring those 2 things together, KDE and PRISM are totally unrelated and it is highly unlikely that akonadi and/or nepomuk do any data spying or providing secret backdoors.

To my knowledge, there are no plans to make the Klyde setup the KDE default at this time.