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.
Your opinion about KDE's dependency to SQL & Akonadi
Tags:
None
Administrator 
|
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."
 Plasma FAQ maintainer - Plasma programming with Python |
Registered Member
|
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 |
|
Registered Member
|
Yes, Please, bring it on! -Don |
|
Registered Member
|
|
Administrator
|
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.
KDE Sysadmin
[img]content/bcooksley_sig.png[/img] |
|
Registered Member
|
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... |
Registered Member
|
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
|
Registered Member
|
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. . |
|
Administrator
|
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).
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."
Plasma FAQ maintainer - Plasma programming with Python |
|
Registered Member
|
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. 
|
|
Registered Member
|
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. |
Bookmarks
Who is online
Registered users: Baidu [Spider], Bing [Bot], Google [Bot], Yahoo [Bot]
