The Discussions and Opinions forum is a place for open discussion regarding everything related to KDE, within the boundaries of KDE Code of Conduct. If you have a question or need a solution for a KDE problem, please post in the apppropriate forum instead.
Reply to topic

Your opinion about KDE's dependency to SQL & Akonadi

Should KDE have the option to run without an SQL server?

Poll ended at Sat Mar 30, 2013 9:59 am

Yes, there should be an option
75%
No, there should be no option
17%
I don't care
8%

Total votes : 12


User avatar einar
Administrator
Posts
2288
Karma
5
OS
It is not even planned for openSUSE. It's merely an option offered for those who want it.


"Violence is the last refuge of the incompetent."
Image
Plasma FAQ maintainer - Plasma programming with Python
dgingrich
Registered Member
Posts
3
Karma
0
woodsman wrote:Having been a long time KDE3 and Trinity user, I stayed away from KDE4 until 4.10.1. I'm pleased with 4.10.1 in many ways, but I'm not using the PIM apps. Other than KMail and a few dozen KAlarm events, I don't use any of the other PIM apps and never have.

I used KMail2 and KAlarm for a couple of weeks. KAlarm behaved very well although KAlarm needed about 30 seconds to start after KDE had loaded (dual core SATA II system). KMail2 has problems and I filed bug reports and posted forum requests for help. I'm certain the bugs will be resolved eventually but until then I'll keep using KMail1.

The akonadi caching backend doubled the size of my home directory. I don't understand why text files need to be duplicated. Drive space might be relatively inexpensive these days, but I have no need to search through my mails other than with the basic search tools provided by KMail. As they all are plain text maildir files, I can grep them any time as well. Likewise with KAlarm data files.

I did not notice any performance hits during my couple of weeks using KMail and KAlarm, but I did not like my files being duplicated in such a manner.

Likewise for nepomuk. I see the potential for a desktop search engine and desktop sharing. I just don't need them. Possibly one day I will but not today. At the moment, because I'm not using the latest PIM apps, I don't have akonadi or nepomuk enabled.

Developers are working hard at making KDE great and usable, but a search of the web and this forum indicate akonadi and nepomuk are the overwhelming highest complaints, even with the recent improvements.

Akonadi and nepomuk have much potential but only for certain types of users. KDE "pillars" or not, they both should be optional, either at run-time or build time. Non enterprise and non power users don't want or need that kind of overhead. I believe this is where most of the uneasiness derives. Such users feel ignored and second class. A lot of people love what KDE has finally matured into, but they still run single personal computers and don't have huge data crunching needs.

Despite all of this great work, I fear akonadi and nepomuk will forever be a wedge in the KDE community and that is sad.


I largely agree with this post. I actually have been using Kontact for a while
and have a significant investment in filter rules.

I was frustrated on the initial switch because it took quite a while to figure
out where my mbox/maildir structure had moved to. This is a consideration
for me because I want the ability to easily login in text mode with ssh and
to access my mail with mutt as an alternative mail tool. Hiding everything
was quite simply a PITB.

There is a further problem in that kmail is not very responsive in the
new configuration. I've got a system with a quad-core CPU and 8GB RAM,
so it should be fairly responsive. But I find that if I want work through a
bunch of messages from a mailing list to quickly check for items of interest,
I rapidly get a message telling me to wait while the mailbox is loaded.

This essentially did not happen in the earlier versions of kmail.

Presumably this is supposed to make it quicker to search for messages,
but this has not been my experience. (But then I don't search all that often.)
Which comes back to the primary point -- massive overheads to support
fast searching is not a good trade-off. It might be OK if I did a lot of searching,
But I can live with a slow search on the rare occasions when I do search
in exchange for faster day-to-day performance.

And, as someone previously pointed out, grep is your friend. :)

I tried killing nepomuk and Akonadi -- kmail was a lot faster, but search
did not work at all. (And I hadn't forund the directory at that stage, so
grep was not an option.) I do search once in a while, so I'd shot myself in
the foot with that effort. :-\

Just give us a choice, please. This is open source, for heavens' sake!! We
really don't need the equivalent of vendor lock-in, please.

-Don
dgingrich
Registered Member
Posts
3
Karma
0

Re: Klyde

Thu Jul 11, 2013 6:15 am
rwolf wrote:Suse has a project called Klyde aimed at making Akonadi and Nepomuk optional packages. What do you think of this effort?


Yes, Please, bring it on!

-Don
goro
Registered Member
Posts
38
Karma
0
OS

Re: Klyde

Sun Jul 14, 2013 7:02 pm
rwolf wrote: Klyde


HOW TO install it on ARCH?
User avatar bcooksley
Administrator
Posts
18657
Karma
83
OS
At the moment, there is no direct way you can install Klyde on Arch. However, it is for the most part default configuration and some build time configuration (dependencies, etc) so it should not be too hard to port to Arch, as long as someone puts the time in to examine the Klyde packaging.


System Settings and Device Actions KCM maintainer
Image
christiang
Registered Member
Posts
3
Karma
0
OS
woodsman wrote:...
The akonadi caching backend doubled the size of my home directory. I don't understand why text files need to be duplicated. Drive space might be relatively inexpensive these days, but I have no need to search through my mails other than with the basic search tools provided by KMail.
...

Even in today's times of cheap disk space from the home depot: many professional environments still use NFS for home directories. Here, doubling $HOME of dozens or hundreds of users just for indexing and 'semantic desktop' means expensive upgrades to complex RAID and NAS systems!

Furthermore, indexing at "normal office hours" from many workstations at will puts a high I/O load on network and fileservers. And in today's global companies, there's no such thing as off-hours anymore!

Such tools thus need to be kept optional at runtime (not compile time!) - for attentive and cautious sysadmins to disable them beforehand...
User avatar wakou222
Registered Member
Posts
14
Karma
0
OS
I have only just joined the forum, so am disappointed that the poll is closed. I have suffered (and yes I mean suffered) from nepomuk problems for most of the last four years, (howls of frustration going back to Jan 2010 on another forum) and have joined here because of another problem with it.
Of course complex, buggy and unfinished software should not be a mandatory part of a DE.
I visited the #KDE IRC group the other day to ask for some advice. All respondents advised "switch off nepomuk" None of them actually used it.


openSUSE 12.3(kernel 3.11.xxxx/KDE 4.11/nVidia 6150se IGP/nVidia driver 304.108/AMD Athlon 64 X2 Dual Core Processor 5600/4Gb DDR2 RAM
User avatar orbmiser
Registered Member
Posts
45
Karma
1
Have to thumbs up on woodsman eloquently laid out argument. As sums up my feelings on the subject.

And am seeing this more and more with distro's first with Ubuntu change of directions. Then Elementary OS ignoring request for added functioning to Gnome 3 removing functionality that Gnome 2 use to have then back-peddling to add it back. All the while shushing the userbase and stating we won't do it as we know what is good for you.

With KDE's dependency to SQL & Akonadi seems to be directly aimed at the future. And many of the Distro's seem to hopping on the Mobile / Tablet/ Phone "Social Crowd Me this Twitter-Twatter/Facebook " on the Cloud technologies. Many Distro Makers & Dev's have erroneously come to the conclusion the Desktop is now a second class citizen that will have to embrace the extra cruft that I believe the majority Do Not Use!

I was adding up my linux and specifically KDE contacts which are around 50 people. Of those that require that kind of integration and databasing of all files. Maybe 10 or 12 that are using it in a self-employed business type situation.

I am a photographer with over 30,000 images taking up 350Gb's of space. Also with a music collection composed of over 10,000 tracks and maybe 500 albums. Another few hundred video clips and a few hundred documents,manuals and over 300 e-books on my system. And I still don't need that kind of desktop integration. As have specific apps that has all the organization,searching and tagging I need.

So Why Do We Need This Desktop integration Again?
I'm listening but the only responses I get is you can turn of Nemopunk or your free to not use KDE.
Which I also find a tad demeaning and condescending. As makes me wonder if a Distro is being made for the average user?
Or some Developers Vision based on their assumption of some possible future scenario ? And don't want user's trying to change that vision.
.


User avatar einar
Administrator
Posts
2288
Karma
5
OS
orbmiser wrote:With KDE's dependency to SQL & Akonadi seems to be directly aimed at the future. And many of the Distro's seem to hopping on the Mobile / Tablet/ Phone "Social Crowd Me this Twitter-Twatter/Facebook " on the Cloud technologies. Many Distro Makers & Dev's have erroneously come to the conclusion the Desktop is now a second class citizen that will have to embrace the extra cruft that I believe the majority Do Not Use!

I don't really follow the reasoning. How is Akonadi related to mobile / tablet / phone? (IIRC, it took quite an effort to port to Windows CE for the first version of Kontact Mobile).

I'm listening but the only responses I get is you can turn of Nemopunk or your free to not use KDE.

Because that's the easiest option, and you can even keep Nepomuk on without any form of indexing active (meaning that you put what you want in its database - even nothing if need be). Such decisions on what to keep on or off is best done by downstreams (distros) not KDE.


"Violence is the last refuge of the incompetent."
Image
Plasma FAQ maintainer - Plasma programming with Python
xdarma
Registered Member
Posts
10
Karma
0
OS
I totally agree with woodsman.
Thanks for your effort to improve kde, but I think there's no hope: they are "blind" to users requests.
But we still free enough to change DE. :-\
shevegen
Registered Member
Posts
5
Karma
0
Should definitely give us the option to avoid mandatory use of SQL.

I don't mind to lose features here - more flexibility is good.

I myself am not a heavy DE user, I just use KDE because it is convenient.

The more flexible I can be while using KDE the better.

The more you mandatory add to KDE; the harder it will be for me to keep on using KDE.

Make the default depend on SQL, but offer alternatives, otherwise you will lose out on users who want or need more flexibility.

 
Reply to topic

Bookmarks



Who is online

Registered users: alake, Alexa [Bot], Baidu [Spider], Bing [Bot], bshah, Exabot [Bot], Google [Bot], grubaugh, Hans, Naver Yeti [Spider], onesandzeros, orbmiser, pedrorodriguez, pvonz, qwach, searchfgold6789, Uri_Herrera, Yahoo [Bot]