Advanced

Removing/Disabling The Semantic Deskop in KDE4 (and firing up Thunderbird) Part 1

Posted by Ridcully on Feb 8, 2014 9:46 PM · 88 comments
LXer Linux News ; By Dr Tony Young



As a result of the first article on KMail, three things emerged. First, while some users may like the semantic desktop, there is serious dislike for the semantic desktop (as has been implemented in KDE4) amongst a considerable number of other users, and these people set about disabling the software in various ways. Second, why does the implementation of the semantic desktop produce such apparent deterioration in the performance of the KDE4 desktop and what happens if you try to remove it altogether ? Third, what are some possible solutions ? This second article tries to explore those three items.

Removing/Disabling The Semantic Deskop in KDE4
Running on openSUSE 13.1
(and firing up Thunderbird)
Part 1


Dr Tony Young


Reference: LXer article "KMail Complexity - and a little Patience."

http://lxer.com/module/newswire/view/197664/index.html.



Introduction

In both the referenced article and its thread (http://lxer.com/module/forums/t/35181/), I indicated my disquiet over the direction KDE4/KMail developers had taken because I believe it impacts negatively on the stand-alone user's efficient and easy use of KMail. This stems from the fact that KMail's operation has been made dependent upon three other separate software packages or systems: semantic desktop software Akonadi and Nepomuk, and security software KWallet.

Without the semantic desktop, KDE4 remains an excellent DE in my opinion. I am familiar with its operation and I prefer to use its associated software such as K3b and Dolphin. Therefore it is an advantage to me if I can retain the KDE4 package while preventing operation of the unwanted semantic and security packages. While there are certainly users who praise the KDE4 semantic desktop, the article's publication opened a "Pandora's Box of Discontent". This came partly from the thread, but also from abundant results from searches based on various combinations of the words "disable, problem, remove, akonadi, nepomuk, kwallet".

I have learned three things from the above results. First, I have seen extensive confirmation that a significant set of user problems/dislikes have emerged subsequent to the implementation of the KDE4 semantic desktop structures (including KWallet), and they are so serious that KDE4 users are setting about disabling those structures in order to obtain an effective, rapid response desktop. Second, it would be useful to document what occurs in a new installation when attempts are made to either delete or disable the semantic desktop; in particular, it might explain why the unwanted effects of the semantic desktop software occur. Third, it may be possible to suggest some solutions to the problems. This article is the result.



Some Background

As noted above, internet searches soon showed that a very large number of KDE4 users would be delighted to get rid of Akonadi, Nepomuk and KWallet because they are considered to be so detrimental to the efficiency, usefulness and speed of the KDE4 desktop manager. Only two articles out of that number are mentioned here as examples. The first at "tweakhound" is very recent, December 1, 2013 and it describes a method of removing Akonadi and Nepomuk from the KDE4 desktop using the "Configure Desktop" menu. The second article, dated March 21, 2012 shows how to completely disable Akonadi by altering its configuration file.

http://www.tweakhound.com/2013/12/01/opensuse-13-1-tips-tric...

http://www.my-guides.net/en/guides/linux/how-to-disable-nepo...

It is difficult to escape the conclusion that all these complaints have been, and continue to be, ignored by the KDE4/KMail development teams because they are in conflict with their goal of producing a semantic desktop and therefore, ipso facto, the complaints must be wrong. In particular, any reader of the complaints soon realises that there is marked condemnation of what has been done by the semantic desktop (and KWallet) to what was previously considered a superb email client, KMail, as well as the KDE4 desktop itself.

Unfortunately, the author soon realised that the mandated dependency of KMail upon Akonadi meant that if Akonadi was disabled or removed, KMail was automatically prevented from functioning in any practical way (** See end note). KMail's functions are also curtailed if KWallet is disabled or removed. If I were to give vent to my personal feelings on both these matters, I would say at the very least that this is extremely poor planning on the part of the KDE4/KMail development teams, but because I wish to be polite, I will not go any further here....

I believe that as an email client, KMail itself should be wholly separate in every way from the semantic desktop and almost sandboxed on its own, given the constant internet attacks by malware and the fact that email clients are very often the first point of attack by malware. Whilst Linux is far more difficult to infect, I have little doubt that as it becomes more widely used, more intense activity will focus on infecting these systems - possibly using social factors. I have already experienced such malware attacks via emails and suffered an ISP lockout from Spamhaus. Whilst no harm was done and the lockout was made in error, the fact that it even occurred should indicate to the KDE4/KMail team that the present aim of interweaving KMail so tightly into the semantic desktop needs reconsideration.

The saddest consequence of the KDE/KMail developers' mandated dependencies is that a choice has to be made: KMail can be retained as the email client, but the problems of the wallet and semantic packages will continue; or, the semantic software and KWallet can be removed or disabled, but then one must also remove KMail and install an alternative email client. My decision was the second of the two choices: remove KMail. This is not as large a problem as might first be thought because at least two very good stand alone email clients are readily available. Claws and Thunderbird are easy to install and both have displays and layouts that should be readily acceptable to a previous user of KMail, although some of KMail's excellent abilities may no longer be available.



Plan of Action

The computer on which the tests were conducted is a Toshiba Satellite A660 laptop. It's an Intel chip i5/quad core computer. The hdd is a Seagate 500Gig drive and had never been used before this series of tests.

My proposed plan of action ran as follows:

1. Since KMail will no longer function when the three semantic/security packages are either removed or disabled, uninstall KMail completely if that is possible.

2. Completely disable Akonadi, Nepomuk and KWallet or even uninstall them if that is possible.

3. Install a suitable stand-alone email client such as Thunderbird or Claws.

Originally, I was also going to consider some other questions, such as: is there any perceived difference in KDE4's computing operations of speed, etc. after Nepomuk and Akonadi are disabled ? I decided against that simply because so many articles on the web have already covered the situation and they are universally positive in the sense that they approve the removing and/or disabling of the Nepomuk, Akonadi, KWallet trio. The only very serious question that needs to be answered is: "Does disabling the semantic desktop affect any other KDE4 packages so that their operation is halted or curtailed ?" Or to put it another way, is the impediment of KMail just the tip of the iceberg ?



Complete deletion of KMail and KWallet

A full installation of openSUSE 13.1 with KDE4 as the desktop manager was conducted on the Toshiba laptop hdd. No problems were encountered and the next steps were to move to folder view, use the classical menu for the application launcher and finally turn off all window effects. These steps were purely for my own convenience. At this stage absolutely no other software packages were started other than those named in the following text.

YaST2's Software Management application was then started. A search on "kmail" produced a display window where a single package called "kmail" was shown as having been installed in the operating system. YaST2 is excellent in that if a software package is selected for deletion and its removal will affect other dependent packages, then YaST2 will warn that there are problems with the deletion and suggest alternatives. KMail was then selected for deletion and the process commenced. No problems were indicated for KMail and its removal from the system proceeded smoothly. In a similar way, KWallet was selected for deletion and the above process was repeated without any problems. (Note: You can, if you wish, simply disable KWallet by using the Configure Desktop options: Configure Desktop - Common Appearance and Behaviour - Account Details - KWallet. Using this method, you can temporarily disable the package rather than delete it.)

From these results it would appear that removal of both KWallet and KMail completely from the operating system and the KDE4 desktop environment causes no discernible problems with dependencies. Moreover, it is a very simple matter to use YaST2 to re-install both packages should that ever be required.



Disabling the Semantic Desktop

This is a two step process. Disabling Nepomuk is relatively simple but stopping Akonadi's operation is a very different problem and despite suggestions to the contrary, I now believe it requires actual editing of the Akonadi start-up file. Again, this is a serious error on the part of the KDE4 team who should supply a suitable option in the Configure Desktop section so that it is made as easy as disabling Nepomuk.



Disabling Nepomuk

There is no installed software package named explicitly in YaST2's software manager as Nepomuk, nor did a simple search reveal any folder or file in the KDE4 desktop labelled "nepomuk". One begins to ask just where this "shadowy" application resides and under what name. However, Nepomuk can be dealt with by using the following steps:

Application Launcher - Configure Desktop - Workspace Appearance and Behaviour - Desktop Search

Figure 1 Disabling Nepomuk - Remove the tick in the box on the top line.

These steps will open the Desktop Search - System Settings Window shown in the image of Figure 1 above. There are three tabs: Basic Settings, Indexing and Backup. In the Basic Settings Window, untick the box labelled "Enable Nepomuk Semantic Desktop". Just to be certain, open the Indexing tab and untick every box, and finally in the Backup tab, make sure that the Backup frequency shows the line "Disable Automatic Backups". When all of this is complete, select the Apply button in the lower right hand corner, and Nepomuk is now fully disabled. If you return to the window shown in Figure 1, the bold script should indicate that Nepomuk is fully disabled.

Web articles suggest that there may be a possible disadvantage to this disabling, in that with Nepomuk disabled, Dolphin may have a reduced ability to find files. I was unable to demonstrate such a loss using Dolphin to conduct simple file searches in KDE4.6 with Nepomuk disabled.



What Happens if you Delete Akonadi ?

Since KMail and KWallet can simply be deleted using the software manager, it seemed logical that Akonadi might also be similarly deleted with little effect. This is most emphatically NOT the case. To understand what the KDE4 team has done it is best to start with YaST2 and search on "akonadi" and then examine what is found.

Figure 2 The akonadi files.

The results of such a search are shown in Figure 2 above. This clearly shows that "Akonadi" is not just a single file like KMail or KWallet, but is a whole "family of files" and all are related to the Personal Information Management system. If Akonadi is to be wholly removed from the operating system, all of those files have to be deleted. The problem that is now faced is that each of the Akonadi related files has several to a multitude of dependencies and just selecting the main file "akonadi" will produce a warning similar to that shown in Figure 3 below.

Figure 3 YaST2 reports problems with dependencies if akonadi files are deleted

However this is just the start. If you select the third option, the menu will then take you to another and similar window that details where more breaks will occur and this can happen up to three times. You then face similar problems for every one of the packages.

Just out of sheer curiosity, and knowing full well that I would probably have to do a re-installation of the entire openSUSE 13.1 package after I had finished, I actually did select all the options to remove the Akonadi file cluster. The results can only be called "catastrophic". The Akonadi software packages have been so interwoven with other software packages that utterly absurd consequences occur. YaST2 lists the deletions as they occur, and while it was too fast for me to count them, I have no doubt that removal of Akonadi from the OS and the KDE4 desktop environment probably resulted in the further deletion of at least 100 (and perhaps 200) other software packages crucial to the operation of the KDE4 desktop, but some of the file deletions are so unusual or strange as to defy the imagination. For instance, the innocuous game KMahjong is deleted by a supposed dependency on Akonadi.......The underlying reason for this may be known and obvious to the KDE4 developers, but it certainly escapes me. I cannot understand how any personal information regarding myself can be found embedded in a game of patience. Needless to say, the result was that I did have to conduct a re-installation of the entire openSUSE 13.1 software package, and to make sure it was a perfectly clean installation, I first reformatted the hdd being used. This reformatting is very important with openSUSE because the software aims to help by retaining data in the home directory and that would almost certainly now be corrupted.

The complexity of the Akonadi package and its operational dependency requirements allows one to understand why so many KDE4 users are reporting that disabling of Akonadi markedly improves the speed of computer activities, reduces hard disk drive activity and improves memory availability. It also allows deeper understanding of the angst that is rising over the actions of the KDE4 team to enforce their "semantic desktop aims and concepts" onto the general user without any easy or well published disabling mechanisms, together with the loss of the email client KMail. Suffice it to say that simple deletion of the Akonadi software package from the openSUSE 13.1 operating system (and its KDE4 desktop manager) is not an option if it is desired to retain a working DE. Deletion of Akonadi reduces the KDE4 desktop to a complete shambles because the semantic spider web is now interwoven so tightly and very widely through KDE4.

I would also like to record that I have had personal experience of the very heavy use of the hard disk drive by Akonadi when using an installation of openSUSE 12.1 with KDE4. While Akonadi was enabled, the hard disk drive would be literally "taken over" by the program for as much as 5-10 seconds at a time and during that period, the computer became virtually unusable. The activity was such that for the first time in my computing history I began to be concerned that the hard disk drive could be damaged by excessive use. These take-overs were random and frequent and I became extremely exasperated with the software. Eventually I discarded the idea of using the OS/DE combination and reformatted the drive.



Disabling Akonadi

Assuming it is desired to "remove" the problems of the Akonadi section of the KDE4 semantic desktop, the only remaining practical solution is to disable the Akonadi software package so that it no longer starts during the use of KDE4. However, my test laptop produced an additional and very surprising result due to the way I had deleted the initial packages of KMail and KWallet.

If the installation of openSUSE 13.1 and KDE 4.11.2 is completely new, it is possible to have circumstances in which the user need take no further action against Akonadi because it will never start. If KMail is started, that very action triggers the Akonadi/PIM package and a folder called "akonadi" is set up in the hidden file ".config". In that folder are a number of items, but the last file is called "akonadiserverrc" which contains instructions to automatically start Akonadi when the desktop is opened. If Akonadi has never been started, the "akonadi" folder will not appear in .config .

Therefore, if after installation, no other software is first started and then, using YaST2 the user immediately disables Nepomuk, and then deletes KMail and KWallet, Akonadi start-up is never triggered and so the "akonadi" folder never becomes written into the .config folder. You can find out if this is the case simply by opening the Configure Desktop settings and from the topline of Common Appearance and Behaviour, select Personal Information. If Akonadi has not been started it will state that fact clearly in a large window and offer to start it. My suggestion in this case is that you do start the software and allow it to produce the "akonadi" folder, because then you can take action which will ensure that Akonadi never starts in future unless you specifically wish it to do so.

A previous search of the internet located an article published in March, 2012:

http://www.my-guides.net/en/guides/linux/how-to-disable-nepo...

This article titled: "How to Disable Nepomuk,Strigi and Akonadi in KDE4", explains how to disable Akonadi by editing its start-up file. Because this file lies in the KDE4 desktop, there is no need to log in as root and the file can be easily changed with a text editor such as Kate or KWrite. The above article also briefly sets out the advantages of disabling the semantic desktop and these are stated as including not only less work for the CPU, but also advantages such as more hdd space, less hdd work, more memory space and less drain on a laptop battery. There is no doubt in the mind of the author of that article that disabling the semantic desktop of KDE4 is a large bonus. The only negative results I am able to see so far are the loss of KMail and probably the associated software items of Kontact and KAddressbook - and I never use either of those two items.

To start the procedure, open Dolphin the file manager and move to the home directory and from there, your own personal directory. From the menu bar select View followed by "Show hidden files" from the drop-down menu. A large series of previously hidden files starting with a full stop "." will now become visible.

Open the ".config" folder and there will be a sub-folder called "akonadi". Open this folder and you will have a series of files etc. but there will be a last file listed as : "akonadiserverrc".

If this file is selected by clicking on it, it will be opened by KWrite automatically and it should have the following lines (or very similar):
Quoting:

[%General]

Driver=QMYSQL

[QMYSQL]

Name=akonadi

Host=

Options="UNIX_SOCKET=/home/tony/.local/share/akonadi/socket-linux-7wqp.site/mysql.socket"

ServerPath=/usr/sbin/mysqld

StartServer=true

[Debug]

Tracer=null


The required action is to change the third last line so that it now reads:

StartServer=false

Now select the Save icon on the KWrite menu bar, or alternatively File on the menu bar and select Save from the drop down menu. Once that is done, log out and then reopen your desktop and Akonadi is present but prohibited from any activity in the KDE desktop. You can check that is the case by repeating the above process and checking the appropriate line in the file. The really excellent part about this method is that if ever it is desired to re-establish Akonadi, the process is so easily reversed.

A final note on this method is that I remain uncertain as to the efficacy of the method of disabling Akonadi given in the article at tweakhound (see section Some Background). I did as they suggested but it did NOT seem to affect the setting of the true/false line in the "akonadiserverrc" file. I suggest that the only certain way currently of disabling Akonadi is the method of editing the file as given above, and hence my final suggestions below for the KDE4 team.



Two Suggestions for the KDE4 Team

1. I suggest that the KDE4 team should consider the construction of a heading/option in the Configure Desktop labelled "Semantic Desktop" with separate tabs for each of the two packages with an included disabling option provided for BOTH Nepomuk and Akonadi so that it can be done completely, simply and easily.

Notes: No doubt there are many users who want to use the Semantic Desktop. Equally, there are many users who neither wish to use the Semantic Desktop, nor even want it to start but currently only Nepomuk's start up or disabling is controlled via the Configure Desktop options. The inclusion of an Akonadi tab would also have to carry warnings on which other KDE4 packages are now rendered inoperable by such disabling. Such an "inoperable list" would also remove the concern I expressed above in this article that "KMail might be just the tip of the iceberg". Providing an enable/disable option also puts ultimate choice back in the hands of the user and I think that return of such choice would at least partially remove the annoyance that I see in web articles.



2. I suggest very strongly to the KDE4 team that KMail, as an extremely important operational package, should be wholly separate in every way from the semantic desktop and that internal password storage be returned to KMail as a matter of user choice.

Notes: A user of KDE4 should be able to expect that every included KDE4 software package will be available to them for use without any impediment. This is no longer the case with KMail. The enforced dependency of KMail on Akonadi has reached sheer absurdity and a cohort of users is now being denied the use of an exceptionally good, stand-alone email client.

For all practical purposes, KMail is now "sabotaged" in the sense of: "Unless you run our semantic desktop, we will not allow you to run KMail". From my perspective, this is not choice, this is dictatorship. If you want to use KMail (as I certainly prefer), you surrender your choice on how the desktop will operate and I will not do that - I would rather walk away completely from KMail.

Choice is also at the heart of my dislike for KWallet. Originally, KMail stored its password in its software, but now that choice has been removed and KWallet is the only option available. The result is far less ease of use but even more worrying is the fact that KWallet then begins to enforce its strictures on other software in use such as the internet browsers.

I make my above suggestions partly based on security reasons, and partly for reasons of choice. To me, an email client is designed for a single purpose: the reception and transmission of emails. There is no reason why Akonadi should not be allowed to "peek into the KMail data files" if that is necessary for a semantic desktop, but the operation of KMail and its email data should NOT be subject to Akonadi's absence or presence. Semantic attributes should be an add-on at the choice of the user, not an enforced fundamental aspect of the email software and data. The same generalities apply to KWallet.



And So ?

How's about considering those two suggestions KDE4 team ? Also, I would like it clearly understood that my suggestions above are NOT in any way intended as a slur against KDE4. KDE in its forms of KDE3.5 and KDE4 have always been my only desktop manager and up to and including KDE4.6, I have had almost nothing but praise. I'm not a programmer, simply a very practical enthusiast, so I would like the KDE4 team to take my suggestions as those of a very dedicated user who wants nothing more than to see further success for his favourite desktop manager. At the moment, I remain deeply concerned at the direction it is being taken.



******************************




** Note: Just to confirm this situation, I re-installed KMail on the laptop after I had disabled Akonadi using the method of altering the "akonadiserverrc" file. KMail would start and at the same time, the PIM/Akonadi server attempted to start. After about 15 seconds Akonadi start-up was then halted and a large notice appeared on the screen overlaying the KMail window. This notice indicated that Akonadi had been disabled and the notice remained in the middle of any KMail screen that was produced. Any further attempts to use KMail were, for all practical purposes, rendered impossible; as well as the warning overlay, it's screens became semi-frozen and largely unresponsive. Summa: KMail will no longer function without Akonadi also running.

End Part 1

Return to the LXer Features

Comments (88)

Very nice article, totally insane situation!

32 earlier comments in the full thread.

Just to throw a few more cans of kerosene onto the fire, by sheer happenchance I logged onto a KDE4 site to see what improvements had taken place. Here's the site:

https://dot.kde.org/2014/02/24/kdes-next-generation-semantic...

It's dealing with questions and problems related to the semantic search desktop, the principal "mongrel piece of software" that began this whole series of my essays (last year) into what was wrong with KDE4. You'll see as you read the thread, that the developers are committed to making this "monster" work even though it is fighting back with each line of code. But even so, as late as February this year, at least one of its users was still yodelling the fact that Akonadi has sabotaged KMail. REALLY ? TRULY ? I mean to say, THAT was the principal theme of my "articles".

Here's a direct quote from the page:

Quoting:Akonadi ruined Kmail...

Akonadi continues to ruin Kmail. 3/4 times I start it up, it fails with akonadi errors. Every...single...workaround has been tried... By Joe at Wed, 2014/02/26 - 5:32am reply



I'm sorry it has been a bad...

I'm sorry it has been a bad experience for you. If you ever find a groupware suite which covers the ground KDE PIM does and works perfectly for everybody, I'd love to hear about it, especially if it is open source! By Jos Poortvliet at Thu, 2014/02/27 - 8:23am reply


Now that is one heck of a remarkable reply.....think about it.......I'm left sitting with mouth open.

I strongly suggest anyone with an interest in how KDE4's development team has botched up its attempts to deploy the semantic desktop should then read down to the next post by Heikki Välisuo at Mon, 2014/03/03 - 11:37am. It's a staggering indictment and it makes the implication that the developers consider "users are only an annoyance to be ignored". How very nice to see that truth on the actual KDE4 page. A little further down are comments that suggest that KDE4's PIM is simply a "mass of bugs".......how very, very nice.......Sorry, I am being cynical. :-), but at this stage, I think I am entitled to be just a teensy bit cynical ......possibly disgusted even.

Update I just read a little further down and encountered Hans Bezemer's comments about the semantic desktop. He made an obvious suggestion which I think is a very good one: "wouldn't it be smart to make it (the semantic desktop) OPTIONAL this time?" Jos Poortvliet's response is so arrogant in its "put-down" that I am no longer surprised that he continues to persevere with the mess that the KDE4 semantic desktop has become. Hans did NOT deserve such a childish response from a principal player in the KDE4 development arena. With respect to Poortvliet's final paragraph, I can only say that I have a similar opinion of his own work.
RE: B._R. -- 6 years. (?)

Meaning? Development years or prison term?

As always,

YBT
My Dearest, Nicest Mr./Dr./Professor(?) Ridiculous:

I finally, quickly scanned your article. I am astounded (seriously) at the effort expended on what must be perceived only as a steaming pile of what is unmentionable on LXer.

Your sincerity, your polite factual statements amaze me. To me those are none other than pearls dropped before swine. While known to be an extremely intelligent beasts, they are terribly uncouth in their dietary hhabits and personal hygiene.

Saying that, you only top it off with a degree of apparent naiveté I find breath taking. Reasonable suggestions given freely to the KDE development team that is known to be extremely hostile to any hint someone is piercing their bubble with objective questioning.

Are you mad? Or do you model yourself on persons that endured extreme, unnecessary pain being inflicted upon them? You must realize these stories stem from the myths either in the older or newer version of one sacred book. Take note, some of the evil heaped upon that first person were physically impossible. The latter version was written by those that were not even born at the time of their story's unfolding. And those that were there had met fairly early demises. Moreover, with respect to the latter there is another sacred book version that tells it completely differently. So please take care.

Seeing what you have opened yourself to, I will limit myself to no more than usual degree of derision aimed at your person. However, even I quake fearing the evil response that will befall you now that you have publicly posted your incendiary words of reason ...

As always,

YBT
It's been 6 years since KDE4.
> ...a steaming pile of what is unmentionable on LXer.

Politics?
> notbob, I think you are in error in the above post.

I would think LXers would by now be aware of my astonishing power to error. It's becomes ever more formidable, daily. Still, my apologies. ;)

> I don't think the article is "much ado about nothing" however

An understatement.

That you expended so much effort and went into such detail is commendable, if not entirely understandable. But IMO, it's still a non-issue. KDE, like Gnome, is a beast that is irrevocably lost to the arrogant developers and will never be the same no matter how logically eloquent the protests. This was made crystal clear when they abandoned Quanta+ and when the head of the Gnome development team bragged on how Gnome 3 was now easier than ever for developers to do their unbridled worst. I choose to use what I still find helpful in KDE and stifle the rest. Feel free to rage against the machine. ;)
Some might find it interesting, that the distribution mageia, when installed from a LIVE CD, does NOT install akonadi. This is true for version 4 and 5-alpha. Only one nepomuk pkg is installed and it can be disabled as noted above.

Gentoo did allow compiling kde4 with the USE flag -semantic-desktop. Not sure if it still works. No other distro, that I am aware of, can do this.

Makes you wonder: Why don't other distros do this?
Quoting: Makes you wonder: Why don't other distros do this?


Just a guess: Path of least resistance?!?!
Both Hans Bezemer and myself have made an obvious suggestion to the KDE4 development teams: Make the semantic desktop OPTIONAL....so that the USER has the choice whether to activate it .....or not. The fact that the KDE4 team has ignored this suggestion, spells out precisely the attitude that they have to the ultimate user base: "You will use what we give you and like it......and your comments, whether constructive or not, have no value to us." Jos Poortvliet has supplied this implied message "in spades" in the KDE4 blog cited above.

Arrogant ? Yes.

Contempt for the user base ? Yes.

Short-sighted ? Yes.

I do NOT understand this attitude in the developers. By making the entire semantic desktop package (including Nepomuk/Baloo and Akonadi) activation a user option, the developers would satisfy everybody on this particular aspect. You could install either KDE-PIM as a Unix based system, or KDE-PIM as an Akonadi dependent system. But wait.......it's probably too hard a development path for them to take; it may need really, really good coding skills; oh well, then, it probably can't be done - or can it ? Perhaps JaseP is right on target.....KDE4 developers have taken the path of least resistance.
I was thinking more in terms of the distribution packagers than KDE developers... It's easier just to build a package with the defaults than to tweak it...

Additionally,... As far as the KDE developers go, Ridcully's kinda right on target, himself. They give us want they want to give us,... no (or few) options. That travels right to the new settings for touchscreens. Apparently, if KDE detects a touchscreen, you get the touchscreen "activity" by default. I don't know how much choice you get as far as changing that default, or what it's like,... But if it's anything like the KDE netbook interface, it's cr@p.
> Why don't other distros do this?

Slackware has a policy of shipping a package as much as possible the way the developers set it up. It does give you the tools you need to compile your own packages, but something like KDE is not for the faint of heart.

As for other distros, who knows.
So, ridicully is "right on target". And everyone pretty much agrees. Now what?

The beauty of Linux is, it's infinitely customizable. Sure, you gotta do a little homework and dig in elbo deep, but that's the price of freedom. So, instead of whining about how KDE developers are insufferable sucktards, which amounts to essentially whizzing into the wind, do what it takes to resolve the situation on yer preferred distro. I've pointed out one solution. Install KDE, in its entirety, then use a different WM/DE to both enhance and limit KDE's bizarre functionality.

Ridicully, yer article was more than thorough, but to what point? You think KDE developers give a rat's patoot? Both KDE and Gnome devs have long ago made it painfully clear that the user's desires/needs are not on their agenda. Better you should put all that exemplary effort into finding ways to to get around KDE's shortcomings rather than jes pointing them out. ;)
> but something like KDE is not for the faint of heart.

So, instead of butting heads with KDE, go around it. Use its size/weight to yer advantage. Slack's fluxbox is already set up to take advantage. It's menus even reflect the change from 3.5 to 4.x, with apps like okular and gwenview already present on FB menus. I'm sure any slack user would be more than willing to give you copies of their .fluxbox files. Not sure if Slack's other DE menus (xfce, fvwm2, etc) have been similarly configured.
> Not sure if Slack's other DE menus (xfce, fvwm2, etc) have been similarly configured.

XFCE has. I haven't checked the others.
Hi Notbob,

Your masterly summation of: "You think KDE developers give a rat's patoot? Both KDE and Gnome devs have long ago made it painfully clear that the user's desires/needs are not on their agenda. Better you should put all that exemplary effort into finding ways to to get around KDE's shortcomings rather than jes pointing them out. ;)" is quite accurate. For your information, two days ago, I tried installing openSUSE 13.1 with the latest version of KDE4....and began my usual litany of disgust.......Even with Akonadi not yet activated (I didn't touch KMail), KWallet was already up and running (and I certainly didn't ask for that to happen). And so the usual immediately began to happen after I installed Chrome.....KWallet began to interfere with my use.

I have now made a decision which I am determined to adhere to......after I remove myself from openSUSE 11.4 and KDE 4.6 (my present system), I will be moving to openSUSE 13.1 and Xfce. There really is no alternative if I want a DE that does what I, me, myself want it to do. Xfce is familiar enough to me to be able to be modified and it doesn't try to tell me what I absolutely MUST do in order to operate the window manager. I do not have to bow to arrogant developers who believe that they have the right to operate my computer as THEY see fit...

It has reached the stage where I seriously believe that Microsoft Window's code of ethics is stencilled on the wall of every KDE4 developer - especially the sections on "removal of choice". Well, that's fine...but in the world of Linux there are always other options to be taken if one particular choice is taken away. What saddens me so much is that KDE has always, always, always been my DE of choice........that is no longer the case.

KDE4 in its latest versions is now, in my opinion, a clumsy, bloated, overdeveloped, overcomplex and interfering software package that demands that you WILL do as the developers wish. For this little user, that's not the case anymore - I am mature enough to make my own choices thankyou. Vale KDE - you have lost one of your most dedicated supporters and users. As I once remarked: I can no longer recommend KDE as a DE to any newcomer, and that's awfully sad. But true !
> will be moving to openSUSE 13.1 and Xfce.

Welcome to the club Ridcully. I've been using XFCE for years now, since both Gnome and KDE were too much for my older systems.

It's somewhat ironic that when I finally got a system powerful enough to handle them, they both self destructed.

XFCE isn't perfect, but as you said: It's familiar, it can be configured to work the way you want, and it doesn't get it your way.

> I seriously believe that Microsoft Window's code of ethics is stencilled on the wall of every KDE4 developer.

And Gnome developers. You know, if I were a conspiracy theorist, I could really make some hay with what's happened with KDE and Gnome over the past several years.
Thanks Jdixon......if I get into strife, I'll be calling on you for help. Not likely, but with a brand new DE, there will be some things to learn. Fun though......and I understand Xfce flies in comparison with KDE. It won't happen yet, but what I think I will do is dump the KDE/OpenSUSE 13.1 installation, format the hdd and install the same OS with Xfce from scratch......Best way to go I think......then in my many spare moments (said with very large tongue in cheek), I will begin to set the system and Xfce up the way I wish to have it. I am looking forward to it very much. Do please note that fact KDE4 team.........You and me ain't finished yet and I have a new motto:

"KDE4, the desktop manager you use when you wish to cede desktop control to the KDE4 Development Team."
> and I understand Xfce flies in comparison with KDE

Cinnamon (first exposed to it in Mint) is my current favourite at providing a nice blend of attractiveness and non-interference. It does seem to be in official opensuse repos too: http://linuxg.net/how-to-install-cinnamon-1-6-1-on-opensuse-...
> ...if I get into strife, I'll be calling on you for help.

I never make promises, Ridcully, but I'm always willing to try to help. :)

important problem, slightly misleading terminology

16 earlier comments in the full thread.

>the whole thing is almost meaningless

I use it almost on a daily basis, meaningless ? No, resistance to change is dreadful . As I said, I can understand why many will stay with other OSs.

Really, I see akonadi as something transparent, nepomuk as an add-on which can be disabled if one prefers, kwallet as something that can be set transparent by an empty password (I do it to be honest, and it never pops up again in any situation, be it for mail retrieval, web surfing...).

KDE devs have not forced anything through the users' throats, they are still free to choose. You seem to refuse to choose and want to force one view on every one, that's what is hard to understand.

Oh for goodness sakes nmset, read my first paragraph again. I do not force, I suggest. Also in that paragraph, I made it quite clear that I retain choice to do as I wish and if I do not wish to stay on KDE then I will move. I only insist that I have simplicity, efficiency and security. I have also simply put the facts as I know them in front of the readers - it's hard evidence.

Quoting:You seem to refuse to choose and want to force one view on every one, that's what is hard to understand.


And let me make it quite clear: I do NOT appreciate your clumsy attempt in your last paragraph to attribute things to me that do NOT appear in my posts. I have indicated in my first paragraph almost directly above that I retain my choice to move to a new DE if I wish. Moreover, I have never indicated or implied that I wish to force one view on everybody. May I suggest you withdraw your statement.

With respect to the KDE devs, and with due respect to you, I believe you are completely wrong. The KDE devs have taken away choice and done so quite deliberately. First they have removed choice on how the password is stored in KMail; second they have imposed the use of KWallet on security; third they have imposed the semantic desktop in such a way that if it is disabled by user choice, then the user also loses KMail. I've covered these aspects in the article and there's no need for me to spell it out again.

No-one is being forced by me to either use or not use KDE4....I have simply given my concepts of the matter as discovered during actual use of a computer. If you do not like them, that's your choice. And there are others like you who seem to enjoy the semantic desktop. Fine with me - go for it. I don't like the semantic desktop. Well, that's my choice, and there are many like me who feel the same.....Are you trying to enforce your choice on them as well as on me ?

This argument is pointless.
> No, resistance to change is dreadful

Resistance to change is a normal human reaction, and is the default state for most people.

> KDE devs have not forced anything through the users' throats

Well, not quite, no. But only because you have the option not to use KDE. Many user seem to have chosen that option.

> You seem to refuse to choose and want to force one view on every one...

A user wants the OPTION to disable a new "feature", and you think he's the one trying to force something on others?



@Ridcully... I only have one last comment on your rewritten paragraph, I promise :). But aside from this comment I think you are spot on.

Quoting: permitted to read its own files


My understanding of the KDEPIM architecture is that the individual PIM programs (kmail, kaddressbook, korganizer, etc...) no longer have their own files. Akonadi is the only thing that stores and manages the PIM data.

Basically, kmail has no understanding (other than for an import) of what a maildir or mbox file is. It doesn't know what a pop server is or what an imap server is. It only knows what Akonadi resources are and that is how it gets access to those. Akonadi is the abstraction layer if you will.

Why did they do this? It gives access to the PIM data to any program on the machine in a common way. Thus both korganizer and the calendar widget talk to Akonadi to get calendar information. In theory someone could write another email client and just have it use Akonadi and it will have access to the same email resources that kmail has. Changing something in one program is automatically reflected in the other. In Gnome the Evolution Data Server is providing similar functionality for at least contacts and calendar, I don't know about mail.

So while I understand their vision, it certainly does make things more complex if someone just wants to have a simple functional mail program. I have not ever been able to treat Akonadi as being transparent (I'm not saying it cannot be, it just wasn't my experience). So I have moved on.
Quoting: [url=https://launchpad.net/~pali/ archive/kdepim-noakonadi]https://launchpad.net/~pali/ archive/kdepim-noakonadi[/url]


After reading up on that, it looks like it should work fine. The developer took the pieces of KDEPIM 4.3 and 4.4 to create that (Akonadi migration started in 4.4 with kaddressbook).

After scanning the git commits I am making the assumption that the developer is not attempting to backport any non-akonadi functionality/fixes that appeared in later versions, but if folks thought Kmail was stable in 4.4 then it probably is not an issue.
>the semantic desktop in such a way that if it is disabled by user choice, then the user also loses KMail

That's not true, kmail still works if you disable Nepomuk in systemsettings, as least on my laptop.
Ummm.....nmset, you again miss the point. Nepomuk is NOT the basis problem, Akonadi is. Nepomuk is a program that adds meta-tags to your data files etc. so that Akonadi can find them and add them to its database.

I agree with you totally: disabling Nepomuk does more or less nothing to KMail's essential operations, other than KMail then warns you that some of its capabilities may not work. But the other side of the semantic desk-top "coin" so to speak, is Akonadi and it is the program that sets up and controls the server and search side. I strongly suspect/believe that Akonadi's activities are the ones that cause excessive CPU usage, hdd activity, etc. etc. and if you disable Akonadi, KMail becomes inoperable. That's it in a nutshell.....try stopping the Akonadi server as I explain how to do in the article and you'll find out the "hard way". Then you can reverse it and get your KMail back. But the KDE team have left no other options left open to you: You want KMail ? Okay, fine, but you MUST also have Akonadi running. Read the discussion in this thread between frankiej and myself - you'll soon appreciate why.



@ frankiej......Again, my sincere thanks. All I can say at this point is: Where were you when I was writing the Part 1 article ? It would have been so helpful because for the first time I have finally put some very confusing bits of the jigsaw into place. Your explanation thoroughly fits the facts as I knew them and additionally allows me to understand, for the first time, exactly why this method has been chosen by the KDE team. I can very much appreciate the "subtlety" of the KDE team's approach and procedures, but I certainly do not approve of them. Messy and over complex are my final thoughts on the matter. I shall be referring back to this thread in Part 2 and in particular this dialogue between you and I because your text is rather crucial if an outsider is to come to an understanding of the semantic desktop construction.

KMail has therefore been "emasculated" in one sense - it can do nothing on its own without the Akonadi database. And your comments on the KDEPIM sequence also fit pretty much what I know already. KDE4.6 still allows KMail to run traditionally, but all further KDE4.x, no.

I'd make one last comment here......I am sure you can STILL get openSUSE 11.4 with KDE4.6 and even though Akonadi is enabled, it seems to do little or nothing and I have never bothered to disable it.....If it ain't broke, why fix it ? If enough people want this earlier, "normal KDE" and plug into the Evergreen project, there will be strong impetus for the project to keep openSUSE 11.4 supported for much longer. But honestly, more and more I am coming to the position that for the future, KMail is a "gone goose", and KDE4 has now been made much less attractive for me as a DE.....Forgeddit and find another DM, and then an email client that will perform in the traditional sense......Hello Thunderbird and Claws.
Hmm M. Set In His Ways,

Tell me were you one of those obtuse individuals that screamed at Ubuntu for not making KDE 4.0 a default when it was first released?

You are so persistent misinterpreting Mr. Ridicules statements citing how easy it is to turn off Nepomuk when he has stated repeatedly that "transparent" Akonadi is the core problem.

I doubt KDE has the funds, but you remind me of that verity: an individual cannot understand what endangers their paycheck. Otherwise you are a shill as I am. [But I do it for MS, they pay well when they pay, which is not often.]

YBT
IOW, Txt, they still haven't ponied up the dough?

When they do, it's gonna be HUGE!
My Dearest August Gus III,

Just a pittance in pence, no more such a pity ...

YBT
Maybe you should contact the new CEO directly with your grievance, Txt.
>Nepomuk is a program that adds meta-tags to your data files etc. so that Akonadi can find them and add them to its database.

Totally wrong. Nepomuk looks at Akonadi to find data from mail, calendars, notes... to index. File tags have nothing to do with akonadi. Just switch off Nepomuk, your file tags are no longer accessible. Concerning system resources, Nepomuk could consume much when it's virtuoso database is empty, i.e, recreated, certainly not alonadi. Nowadays, in such a situation, nepomuk will be a CPU burner in idle time only.

>the semantic desktop in such a way that if it is disabled by user choice, then the user also loses KMail >Nepomuk is NOT the basis problem, Akonadi is.

Semantic desktop : this is Nepomuk's functionalities, not Akonadi.
@nmset........I'm no longer debating. Go read this:

http://userbase.kde.org/Nepomuk

I would however add that there is some truth in what you are suggesting. The complexity of the Akonadi Nepomuk Strigi situation is such that I have no doubt there are errors in some of the picture I am trying to assemble. Even in the link I gave you above, it is extremely difficult to understand exactly what is going on and they themselves spin you off to different articles to try to explain aspects of what they are doing. You WILL find web articles describing Nepomuk as producing meta-tags:

https://bugs.kde.org/show_bug.cgi?id=230049

and there is so much conflicting information about this unbelievably complex desktop that one nearly throws one's hands in the air and consigns the whole lot to perdition.

You might also like to look at this article which is one of the best I have seen so far as it includes the third essential package which contributes to the semantic desktop, Strigi.

http://thomasmcguire.wordpress.com/2009/10/03/akonadi-nepomu...

A better picture, I think, possibly, maybe, is that Akonadi has the database but does not know what the heck to do with it. Strigi acts like a "spider" and trawls through your desktop and finds data to feed to Nepomuk. (Strigi is disabled when you disable Nepomuk)...Nepomuk sorts it and collates it and presents the search summary you require. In that sense only, you can say that Nepomuk is the sematic desktop, but I repeat, Nepomuk is only one side of the coin, Akonadi is the other. The Nepomuk half is useless without the Akonadi half, and simply disabling Nepomuk does NOT stop Akonadi from continuing to assemble its cache....both must be disabled if the entire "semantic system" is to be stopped.
Quoting: The Nepomuk half is useless without the Akonadi half


That isn't quite true. Nepomuk does not need Akonadi nor does Akonadi need Nepomuk.

Nepomuk is the core of the semantic desktop as nmset has been saying. But Akonadi and Strigi are both components of it as well. In fact, I believe (I have nothing to back this up) that Akonadi would not exist if it weren't for the concept of the semantic desktop.

Nepomuk can exist and be useful without either Akonadi or Strigi. It is at its heart a database full of metadata. Other programs feed this metadata into the Nepomuk database and queries can be made against.

The most common way that Nepomuk is populated is via Strigi which will search our home directory (or whatever you configure) and populate Nepomuk with basic metadata that it can obtain from those files. But once again, Strigi doesn't have to be active to use Nepomuk.

Another way to populate Nepomuk is when other applications use it to store metadata. Gwenview for example will store your photo tags in the Nepomuk database. If you have Nepomuk disabled you cannot tag your photos in Gwenview. I think Amarok has or is going to be using Nepomuk to store a lot of its metadata.

Then we get to Akonadi. Akonadi serves a dual purpose. One half of its purpose is to manage PIM data. It manages it, caches it in its own database, and provides an API to PIM or PIM related applications that need to get at that data (e.g. Kmail getting to an Akonadi resource for an IMAP server). The other purpose of Akonadi is to take all of that metadata about the PIM information and automatically feed it to Nepomuk which will store it in its database.

I have run Nepomuk with Akonadi disabled because I was using Thunderbird. The only functionality missing is that I don't get the metadata for my mail, contacts, and calendar (Lightning) in my Nepomuk database. I have also run Akonadi (and Kmail) without Nepomuk enabled. The functionality that I do not have in that situation is I cannot search my email and my contacts are not auto-completed.
This link might be of help to those who want to understand the architecture of Akonadi and how it functions.

This link might also be helpful

I stand corrected Frankiej...no problems; Like I said, I have now read so much and inhaled so many contradictory views on this blankety blank "thing" that I am as I said above, ready to throw my arms in the air and just scream "Lemme out of here".

When I began this saga, I thought I knew what was going on.......the more I got into it, the less I knew and the more confused I got. You have helped enormously. It was not until I got the link to the Thomas McGuire article that I finally began to understand the concepts of Strigi.......it's a "spider" that trawls your desktop and finds things to feed to Nepomuk, as I understand it...... but Nepomuk is not dependent on Strigi........Again, here's another bit. You say above that "Nepomuk is at its heart, a database of metadata".....whereas McGuire indicates its a library of "standard ontologies".......Now both may be correct, but is it any wonder when there are so many conflicting word definitions that somebody trying to thread a path through this horrible chaos goes slightly nutty ? Huh ?...Exits stage left in hysteria and gibbering.......attendants with white coats and straight jacket are waiting :-)

The only things I am sure of at this stage is that "lots of user don't like it" and give their reasons. Eventually, as I am doing, you begin to ask :

Is all of this fuss worth it ? The KDE devs are going to do what they like and their goal is centered totally on the polishing of the semantic desktop goal.....They aren't going to change just because a little rabbit in Australia gets all caustic and upset - he'll just be ignored and they will do as they darn well please !!

So, really, the question I should ask is: Is KDE4 the desktop manager I want to continue to use ? Does it fit my requirements ? Would I be better off cutting my losses and moving to another DM ? That last question is becoming more and more entrenched as the days go by. It's very, very upsetting, but if KDE4 no longer does what I personally want from a DM, why try to force it into the shape I want ? Just move on and find something that does do what I want. Would Trinity be much better as is being suggested strongly on the other thread attached to this article ? It possibly would be....I could keep a version of KMail and it is based on dear old KDE3.5 but vastly updated and improved.....And it DOESN'T have a semantic desktop to annoy the heck out of me.......or KWallet for that matter. And there are other options as well.......For the moment though, my system runs perfectly and I am very content with KDE4.6

Now there's a thought......I wonder if you could put KDE4.6 on top of openSUSE 13.1 ? Naaaah.....forgeddit.

> hbut is it any wonder when there are so many conflicting word definitions...

Well, when people are making up terms to describe something new, different people often make up different terms.

> Is all of this fuss worth it ?

IMO, no. But YMMV. :)

Hi Jdixon......very true as regards your last statement over mileage may vary. One does get a bit despondent/depressed over the fact that you think you are belting your head against a whacking great establishment brick wall......but, somebody gotta.

Even if it appears that no-one in the KDE4 camp is reading or listening to what is going on with respect to both these articles and these threads, and nothing appears to be happening........Don't you believe it !!!! Oh yes, they ARE reading and yes, they KNOW and probably don't like it much, but are saying nothing. But then that's the great thing about the world of FOSS.....you are free to express your opinions and make your choices for yourself......Currently they have chosen to put themselves on a path that I believe tends to disadvantage the small stand alone user who needs a simple, unencumbered, fast desktop; or at least that's how I see it. But that's their choice, bless them, and may it work for them. There's plenty of big businesses and governments out in that world.

Perhaps someone, somewhere in the ivory tower of the KDE4 team will have taken the information in these articles and threads on board and sooner or later something will happen that will bring the single individual user back into the fold. But if it doesn't happen......what the heck !! KDE4 continues its moves to the industrial/research/commercial/government large scale networks and that's that......And we mere mortals who just want simplicity, speed and reliability will find that there is plenty around to satisfy those needs........and once more there will be mass migration away from KDE....The picture I am painting is of course, mere hypothesis, but it could happen and KDE will become a DE that is only meant for the "big boys" with massive networks......Fine......if that's what the devs want, so let it be. But it's certainly not a picture that appeals to me. Rather sad really, when you think about the fact that KDE was originally an individual user desktop manager.
@Ridcully,

I have been totally quiet while following this subject because last time we discussed it we reached to the same conclusion you outlined so eloquently in your last comment.

In my opinion, I believe the KDE developers are set in their minds to keep the path they chose for KMail, and PIM in general, mainly because of their strong belief that desktops and even other small computer devices (Phones, Tablets, Netbooks) are no longer used to just manage files, but rather mostly intertwined information stored locally and on cloud storage. Whether the information belongs to multiple users or to an individual, it makes no difference, semantic search is required and essential to effectively accomplish that.

In terms of using too much resources, that was very true in the past. I recently activated KMail to read my mail on Google. I am running KDE 4.12.1 on a Toshiba NB205 Netbook with dual Intel(R) Atom(TM) CPU N280 @ 1.66GHz with 1GB of memory only. I have Nepomuk Server turned off but Akonadi running and I have no issue with resources. Heck, Firefox uses 25% of CPU most of the time and I hardly notice Akonadi running in System Guard Monitor.

The KDE developers did a tremendous job on improving performance in both Akonadi & Nepomuk in their latest releases. I believe most of the complains you found on the Internet were about earlier versions, which I agree they were in pretty bad shape and was the reason I wasn't using KMail before.

Quoting: You say above that "Nepomuk is at its heart, a database of metadata".....whereas McGuire indicates its a library of "standard ontologies"......


Yes, "metadata" was entirely my own way of describing it lacking a better, more official description.

Quoting: > Is all of this fuss worth it ?

IMO, no. But YMMV. :)


Completely agree with that :)

Post a comment

A free account is needed to post. Write your comment here first: your text is kept in this browser while you sign up or log in, and is waiting for you when you come back.

Your message:
|||||
10
Markdown: **bold**, *italic*, [text](https://link), - lists, > quotes, $x^2$ for math. Formatting help

Sign up and post (it is free)  or  Log in and post

LXer

  Latest Features
bob: LXer now speaks Markdown
Oct 27, 2026

bob: How to protect against PHP2Shell
Oct 26, 2026

Scott Ruecker (San Diego, U.S.): Linux That's Small
Oct 14, 2024

penguinist: Encryption, Trust, and the Hidden Dangers of Vendor-Controlled Data
Aug 27, 2024

Scott Ruecker (San Diego, U.S.): My Linux Mint Tribute
Aug 23, 2024

Scott Ruecker (San Diego, U.S.): How I Turned My Chromebook Into A "Mintbook"
Jul 08, 2024

Scott Ruecker (San Diego, U.S.): Adventures With My New Chromebook
Jun 10, 2024

Scott Ruecker: My Linux Laptop
May 08, 2022

Scott Ruecker: Laptop Dual Boot Project: Part 2
Nov 30, 2021

Scott Ruecker: Laptop Dual Boot Project
Nov 30, 2020


View all

  Search Features

Search LXer Features:

[ Copyright © LXer | All times are recorded in Central Daylight Time (CDT) ]

[ Contact Us | Privacy Policy | Terms of Service | About us | rss | Mobile ]

Login