Removing/Disabling The Semantic Deskop in KDE4 (and firing up Thunderbird) Part 1
 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.  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.  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: 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 |
|
| Subject | Topic Starter | Replies | Views | Last Post |
|---|---|---|---|---|
| Very nice article, totally insane situation! | Alcibiades | 51 | 8,669 | Jul 21, 2014 9:14 AM |
| important problem, slightly misleading terminology | mfioretti | 35 | 6,875 | Feb 12, 2014 11:47 AM |
You cannot post until you login.