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

Posted by Ridcully on Feb 8, 2014 10:46 PM EDT
LXer Linux News ; By Dr Tony Young
Mail this story
Print this story



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

  Nav
» Read more about: Story Type: Editorial, LXer Features; Groups: Developer, KDE

« Return to the newswire homepage

Subject Topic Starter Replies Views Last Post
Very nice article, totally insane situation! Alcibiades 51 8,391 Jul 21, 2014 9:14 AM
important problem, slightly misleading terminology mfioretti 35 6,650 Feb 12, 2014 11:47 AM

You cannot post until you login.