Removing/Disabling The Semantic Deskop in KDE4 Running on openSUSE 13.1 Part 2
References: 1. LXer article "KMail Complexity - and a little Patience." http://lxer.com/module/newswire/view/197664/index.html 2. LXer article "Removing/Disabling The Semantic Desktop in KDE4 Running on openSUSE 13.1 (and firing up Thunderbird)" http://lxer.com/module/newswire/view/198081/index.html 3. NEPOMUK - The Social Semantic Desktop http://nepomuk.semanticdesktop.org/ 4. Akonadi, Nepomuk and Strigi Explained http://thomasmcguire.wordpress.com/2009/10/03/akonadi-nepomu... 5. Stop Press......KDE's Nepomuk Doesn't Seem To Have A Future http://www.phoronix.com/scan.php?page=news_item&px=MTYwNjM The rest of my article should be read with this little gem from Phoronix in mind. I am not an exceptionally cynical person, but I could be over this "little act". The developers were told almost from "day 1" by the users that the structure was faulty in various ways. If the sum quoted is correct, the obscene waste of $US23.3 million dollars to produce something that is now being turfed out onto the software scrap heap staggers me and leaves me very angry. Candidly, I think that replacing Nepomuk with Baloo is somewhat akin to removing a flat tyre and replacing it with a tyre that has a slow leak. Both come to the same end. In my opinion, KDE was a great DM until the semantic software was thrust into it. Introduction This second article of this two part series needs some threads of information to be drawn together. Also, as a result of the astonishing news in Reference #5, all references to Nepomuk still remain accurate for the current KDE4 versions, but future releases of KDE4 may need to be referenced to the "Baloo" package. First, there is a cluster of software packages that ultimately form (or contribute to) the operations of the KDE4 semantic desktop: Nepomuk, Strigi and Akonadi (Reference #4) but it also includes the software package KDEPIM. Nepomuk is the actual semantic software ontological library, Strigi is a "spider" which trawls the user's computer files and sends information back to Nepomuk while Akonadi stores its data in an sql cache for the use of the KDEPIM (KDE Personal Information Manager) of which the most frequently used item is probably KMail but which includes KAdressbook, KOrganiser and Kontact. (I accept that more learned readers may find the above is a rough approximation, but I think my summation should be good enough for most purposes.) The Akonadi cache contains all the data previously held in all the separate data locations of the mail client, the calendar appointment book and the address book and so it provides a single data pool for all these PIM packages and Nepomuk. Those data locations still exist and are updated by Akonadi, but cannot be addressed by any of the packages in KDEPIM. This makes very good sense for complex semantic operations, but conversely, it seriously damages the simplicity of the previous "non-semantic" KDE "Unix operated" data structures which were ideal for the single user who had very limited or simple computing requirements. Second, many users make no differentiation between the packages of KDEPIM, Nepomuk, Strigi and Akonadi and simply refer to the aggregate as the "semantic desktop". For the rest of this article, this very loose definition of "semantic desktop" will be used and will always be placed in quotation marks, but where necessary, the individual components will be so designated. Third, a modern computer usually relies on two types of software package which allow the user to communicate with the outside world: an email client and a browser. KDE4's own email client, KMail, has now been modified by the requirements of the KDE "semantic desktop" so that it can no longer directly access the "maildir" folder where the emails are actually stored. Instead, it obtains its information from the intermediate cache produced by the sql server Akonadi from the data in the "maildir" folder. Unless Akonadi is running, KMail cannot function (References #1, #2 and #4). Traditional and previously accepted Unix file operations on the "maildir" folder are therefore no longer recognised by KMail because they have not been processed via an Akonadi sql cache operation. Fourth and finally, many KDE4 users dislike the semantic desktop package because it is considered to produce considerable negative effects on computer operations (excessive activity for both the CPU and the hdd, lost hdd storage space and temporarily unavailable memory), and alternative solutions are now being proposed. These solutions include disabling of the entire "semantic desktop" package. If a user exercises his/her choice and (except for the KDEPIM package) disables the "semantic desktop" software (in this case, specifically Nepomuk, Strigi and Akonadi) in order to obtain greater computer efficiency, it leads to the instant loss of the KDE email client KMail (References #2 and #4), and so the user is immediately deprived of one of the two essential communication links through the dependencies of the "semantic desktop". This situation means that if the benefits of disabling the KDE4 "semantic desktop" are so great, then an alternative email client needs to be installed, if indeed the user wishes to retain the use of KDE4 as their desktop manager. This article deals with the installation and setting up of an alternative email client for the KDE4 desktop where the "semantic desktop" package has been disabled. A Little Background When I began writing this series of articles, my unshaken belief was that for a personal desktop or laptop, KDE in its successive iterations was, and is, one of the best desktop managers in the Linux world, especially for the individual user. Unfortunately however, the alterations in KDE4 that have produced the "semantic desktop" mean that for an individual user who has no need of such a complex and demanding desktop, the current versions of KDE4 may not be the best solutions for his/her computing requirements. I believe most of the problems now described by numerous users who dislike the latest KDE4 versions, can be attributed to the operations of its "semantic desktop" structures (Reference #2 and its dependent threads). For a large computer network, a "semantic desktop" is likely to be an extremely useful tool. It would allow almost instant location of personal and business/operational data contained in emails, calendars and personal diaries and collate all relevant information. Further, if we assume that the hardware on which the KDE4 "semantic desktop" is running are high powered network servers, the additional load of the "semantic desktop" is negligible, but this may not be so for an individual desktop or laptop. The basic problem for the individual, stand-alone user is whether he or she wants this additional complexity and computer activity........or not. The best explanation I have so far found on how the "semantic desktop" packages work is given in Reference #4. It is a complex document, but the writer has managed to separate the three "semantic desktop" components (Nepomuk, Strigi and Akonadi) and explain what each does. The Reference #4 document also explains why KMail no longer works with its own "maildir" folder - that task has been taken over by Akonadi whose cache not only acts as an intermediary between KMail and the "maildir" folder but also for the data folders of the other elements of the KDEPIM. Personally I think it's rather sad, but I now better understand where the KDE4 team is coming from and why their actions have previously caused so much additional work for the CPU and the hard disk drive. I frankly admit I have not tested the latest version of KDE4 with just Nepomuk/Strigi disabled and it is possible that the developers have managed to markedly reduce resource usage of the remaining Akonadi component, and that in turn opens the possibility of re-use of KMail - apart from the frustrations of KWallet. (Note: The Strigi component (hitherto never mentioned in these articles) of the "semantic desktop" is also automatically disabled when Nepomuk is disabled by using the Configure Desktop options). There are so many articles opposing the KDE development team's deployment of the "semantic desktop" that it is pointless to go through all of them here, however one in particular is well worth mentioning. A group of users has now produced versions of the KDEPIM package which are independent of Nepomuk, Strigi and Akonadi. While these KDEPIM packages are as yet only available for Ubuntu, it certainly indicates the depth of frustration of this group over what they consider is the negative direction now being taken by the development of the KDE4 desktop management package with respect to the effects of the "semantic desktop". You can find this site at: http://launchpad.net/~pali/+archive/kdepim-noakonadi An interesting web site was recently brought to my attention (thank you "jazz") and it confirms one of my newly formed concepts. This site contains the web document listed as Reference #3. The site contains only a single paragraph, apart from various administrative links, but the short text is so "revealing" that it is repeated here: Quoting:NEPOMUK brings together researchers, industrial software developers, and representative industrial users, to develop a comprehensive solution for extending the personal desktop into a collaboration environment which supports both the personal information management and the sharing and exchange across social and organizational relations. My perception of the above "mission statement" is that it is a brilliant piece of circumlocution that has been "cooked by a master" - and English is my native tongue. One has to admire the usage of ornamental and apparently enormously impressive words that really carry very little information about exactly what a "semantic desktop" is and does. There is however a general concept which can be gleaned from the statement and it confirms what I originally implied/suggested in the text of Reference #1: The "semantic desktop" of KDE4 (and by implication, KMail) is now primarily aimed at large networks in research, industry and social/government organisations. QED, I think. And if you really want to rejoice in circumlocution, try reading this - it's brilliant: http://nepomuk.semanticdesktop.org/Project+Objectives.html There is an idea I want to share in this background information and I am indebted to my daughter Fiona, a library technician, for this statement. She uses Windows in her daily work in a very large legal library and Linux on her personal laptop at home. She read through the text of the Part 1 published article and then emailed this response: Quoting:"Reading your article, and freely admitting not being able to understand it fully, it seems that the KDE programmers are going in the same direction as Apple and Windows. YOU WILL have this programming and YOU WILL have no choice in the matter...." From what I am seeing, I don't think I could improve on her statement. Choices to either use or disable the "semantic desktop" completely as well as choices to be able to use KMail, with or without the "semantic desktop" or KWallet, are presently lacking in KDE4. The only real choices remaining are: 1. Use KDE4 "as is"; 2. Use a very modified KDE4 that disables the "semantic desktop"; or, 3. Walk away. If you select option #3, choices still remain and one obvious one is the Trinity desktop manager, (http://www.trinitydesktop.org/) but there are plenty of alternative desktop environments such as Xfce and so on. The classic article "The Cathedral and the Bazaar" comes to mind. There is one aspect however, that I think can be cleared up. In my earlier article (Reference #2) I indicated that I had concern that KMail was just the "tip of the iceberg" and that numbers of software packages in KDE4 might be affected by the disabling of the "semantic desktop". I am quietly confident that with what I now know, this is not the case. The "semantic desktop" is currently only "seriously interactive" with the data of the KDEPIM packages via the Akonadi cache, and those are defined in the introduction to this article. Disabling of the "semantic desktop" should, from all I am able to understand, therefore only affect that relatively small package cluster and leave the remainder of the desktop software untouched. All of this is leading to the fact that this article follows on from Part 1. In that article, I showed that KDE4 (and especially its KDEPIM package) is subject to the operations of a "semantic desktop" comprising Nepomuk, Strigi and Akonadi, but as far as I am concerned (and for many others) this "semantic desktop" is an unwanted encumbrance on KDE4. In the previous article, I explained how to wholly disable the semantic desktop, but in so doing, the use of KMail as an email client was also lost. This article will demonstrate how you can replace the disabled and deleted KMail with Thunderbird as the email client. Installing Thunderbird 24.3 The test computer remains the Toshiba Satellite A660 laptop described in Part 1. The operating system of openSUSE 13.1 and its version of KDE remain the same. Prior to this section of the series, the laptop system had KMail and KWallet deleted, and Nepomuk and Akonadi were disabled fully. As noted previously, the desktop was operating in folder view, classical menu for the application launcher and all window effects were off - this form of display was purely for my own convenience. Prior to installing Thunderbird, the laptop was connected for the first time to the internet and all patches and upgrades for openSUSE 13.1 were installed. No other software was added; however in order to ensure the internet was connected correctly, the Firefox browser was started and it was confirmed as running perfectly. The first step was to install Thunderbird and to do this, YaST was opened and version 24.3 of the software was installed on the system. All installation was done from the internet repository and as well as the Thunderbird package, other additional files were added to the system to make a total of approximately 90Megabytes download. After completing the installation, YaST was closed. The software package automatically puts an item in the Application Launcher Menu under Internet and selecting this item starts the Thunderbird package and the user is presented with the information window shown in Figure 1 below.  Figure 1. The opening window of Thunderbird 24.3 The user now has the choice of using his/her existing email address and password, or the additional option of setting up an entirely new account under a different email provider. In my particular case, I wished to retain my normal email account and therefore selected the lower left option. Once this is selected, Thunderbird immediately moves to a second option as shown in Figure 2 below.  Figure 2. Email address and password insertion. My personal email address has been partially deleted for privacy purposes, however this window indicates the style of password insertion that was once used so very successfully by KMail when it was aimed specifically at the independent user. It always works and Thunderbird retains this simplicity. To ensure that the password for the POP3 server is permanently held in Thunderbird's storage, the "Remember password" box must contain a "tick". I found that once Thunderbird had the information in the three entry areas above, it began automatically to try to find the mail server on which my account is held. This in turn led to an interesting situation which needs some explanation. In a previous paper, I indicated that I had Thunderbird "up and running" in as little as two minutes, and indeed that was the case. However, I am now aware that this very short period resulted from the fact that the computer on which I was testing Thunderbird had previously had a working installation of KMail installed. As a result, the correct names for the mail server and its settings were already present in some KMail datafile to which Thunderbird gained access. In the case of the present new installation, KMail had never been set up and therefore that datafile did not exist. What then happened was that in the large blank area of Figure 2, Thunderbird indicated it was searching for the information, but after about 2-3 minutes I stopped the process by selecting "Continue" and Thunderbird then presented the following window in Figure 3 so that the account could be set up manually.  Figure 3. Manual setup of Thunderbird The setting up window is fairly straight forward and Thunderbird will proceed to try to set the account up automatically once you have given the details as indicated above. There is however one very silly trap which is purely a matter of my own situation. And it is displayed very nicely in Figure 4 below.  Figure 4. Mail Account Setup window showing all details. It is always recommended that you use secure transmissions wherever your ISP supports them. After completing the information as shown in Figure 4, I pressed the "Re-test" button and was extremely surprised to receive the information that either my user name or password was incorrect. I replaced both and got the same message and then after a bit of head scratching realised what had happened.....The answer lies in the Outgoing line which is labelled as SMTP. At the moment, this shows a required Authentication of "Normal password"......however my ISP email server does NOT have this requirement. It was the matter of a moment to select "None" from the drop down menu on that line and Thunderbird instantly acknowledged that all was well and proceeded to the window as shown in in Figure 5.  Figure 5. The opening window of the Thunderbird 24.3 email client. As can be seen, the window "sort of looks" like KMail, but the user has only just started to "whip this very nice email client into shape". The side menu tree always remains....I haven't looked for an option that would remove it, but one probably exists. But in any event, I cannot imagine any email users would want to remove the best general search tool of the Thunderbird client. If you select "Inbox", the view will immediately re-orient itself to show email lists in the upper half and the contents of the selected email in the lower half.....just like KMail. An example of what you will get is shown in Figure 6.  Figure 6. The simple working view of Thunderbird showing top area for email lists and lower area for email contents. Note that the software tells you that the main menu bar is hidden by default. There is however one last thing to do before the user begins to really set the software up exactly as they desire, and this is shown in the last image of Figure 7 below.  Figure 7. Thunderbird with main menu bar displayed. To obtain the main menu bar, place the cursor in the blank grey area above the line that contains the "Address Book" option and right click.....A drop down menu will be displayed and you can select to permanently display the Menu Bar.......Once you have this bar in place, you have access to all of Thunderbird's drop down menus, options and layouts. I have already "played" with this aspect and have confirmed that I can produce a Thunderbird layout that has almost no differences between it and the layout that I prefer to use in KMail. I leave it to the reader to enjoy ferreting out the options for this remarkably good piece of software.....I'm impressed. Thunderbird may not do exactly what KMail does, but if you cannot have KMail, then I think Thunderbird is a darn good replacement and it is simple and effective to use. Once Thunderbird is in place and the "semantic desktop" software removed, KDE4 should go like a "scalded cat" as that dreadful old saying is. One last thing: I found there was a last little hangover from my removal of Nepomuk, Strigi and Akonadi. KMail, of course, had been removed, but not the other parts of the KDEPIM. I found that Kontact and the other members of the KDEPIM began to put up opening windows with a graphic that showed that they were trying to start Akonadi. You begin to understand a little more why so much of the computer's resources is taken up by the KDEPIM and the "semantic desktop" because the other members of the PIM section automatically begin to do their work whether you asked them to do so or not. I suspect the easiest way (and I haven't tried this yet) would be to disable them using the Configure Desktop startup options.......or you might try simply uninstalling them as each pops up because each of the items is like KMail - it consists of a single file in the openSUSE 13.1 repository and provided there are no dependencies, each should be able to be easily and completely uninstalled. And there we are. And After All of This, The Real "Semantic Desktop" Problem is CHOICE I firmly believe that any reader should be in no doubt whatsoever that: The issues that I (and others in the threads) have raised in this two part series will have not the slightest effect on the KDE4 development team (and its aims) for the foreseeable future. The arguments raised by all of us will be ignored or set aside by the KDE4 developers as of little or no consequence in their march to produce a "semantic desktop". It would produce too much "loss of face" to do otherwise and they are also convinced that the path they have taken is wholly correct. Whether or not they alienate any of their own users in the process of that march is irrelevant; the production of the "semantic desktop" is the only goal in front of them and they have devoted too much of their time and resources to stop now. It's simply not going to happen. One is almost tempted to suggest that there could be a large, hidden "corporate structure" of some form pushing/advising/backing the KDE4 team in order to get the desired network structure out of the developers - that suggestion is pure hypothesis but the Nepomuk "mission statement" and the Phoronix article, (References #3 and #5) do give some credence to the idea. There is ample evidence that many KDE users are unhappy with the direction KDE4 development has taken. If you really want to do it, then: 1. Yes, you can disable the "semantic desktop" software; 2. Yes, you can remove KWallet; and finally, 3. Yes, you can remove KMail and replace it with Thunderbird. But I am compelled to ask the KDE4 team: Why should you have to do so in the first place ? More to the point, why should "we the users" have to replace an excellent inbuilt email client and personal information manager just to satisfy YOUR desire to produce a "semantic desktop" ? One could argue that all I have done in this article is prove the point that it is possible, but should all that hassle be necessary when it is all done and dusted ? Why should any KDE user have to force such alterations and settings onto KDE4 when they should be made available by the software itself through offering a series of user choices ? And I think that is the real crux of the present situation as my daughter Fiona so penetratingly implied: CHOICE has been taken away from KDE4 and if you are going to use KDE4, YOU WILL do as the developers have decided for you - just like Apple and Windows. This is no longer the "bazaar", this is the "cathedral". As a consequence, you are no longer free to: 1. Reject the use of KWallet password storage facility without any penalty from other KDE4 software; 2. Reject the use of the "semantic desktop" components of Nepomuk, Strigi and Akonadi and still retain the full use of the KDEPIM complex of software so that KDEPIM then accesses its normal data files under traditional Unix operations. The present structure of KDE4 has been developed to produce only the single, "semantic desktop" outcome that is desired by the developers. And of course, we know that that they are free to make that choice, but in so doing, they deprive the rest of us of our choices. Of course, we are free to use, or not use, KDE4 - under the conditions they impose of course. But from the point of view of the KDE4 developers, they have given us just one slightly modified choice: Apart from being able to disable Nepomuk using the Configuration Desktop controls, we are only free to use their entire developed package "as is", .........or not, and if we disable any more of it, we must accept the consequences and lose highly desirable computing facilities. I'd mention here too that despite anything stated by fans of the KDE4 "semantic desktop", its activities MUST have a detrimental effect on the operations of KDE4 as far as the CPU and other computing components are concerned. We can assume that the Akonadi server is constantly running in order to update its sql accessed cache; we also know that components of the KDEPIM are constantly active whether they are being used or not; and finally, we know that unless they are disabled, the Nepomuk/Strigi component is constantly active and ready to produce results to a query. No matter how you twist the logic, this MUST and DOES produce loads on the CPU that previously did not exist; further hdd space has to be taken up by the cache that is required by the Akonadi server, and finally, at least some memory must be utilised for all these operations. It is no wonder that users report that removal of the "semantic desktop" improves computer operations. It may be possible to reduce these negative effects, of course, but some will ALWAYS be there. From my perspective, the situation has become much clearer. I am finally asking myself whether or not KDE4, as it has become, is the desktop that is suitable for my needs. Certainly, I can force it into the structure I want, but is it truly worth the trouble, when there are other desktop managers that will give me what I want with far less difficulty ? It remains a large problem question. Perhaps my concerns are shared by very few people.....in which case, the "semantic desktop" of KDE will become the standard format of the software....But my present feeling is that there is so much dislike for the complex DM that has now been produced that it will drive the uptake of alternative desktop managers rather than KDE4 even if "big network" takes it up.. I'm not happy if that is the outcome either because KDE is still my preferred DM, but that's my present view of the matter. On the other hand, I have confirmed that removing the entire "semantic desktop", KWallet and the KDEPIM package can be done without excessive penalty, and that Thunderbird can be installed as a direct replacement of KMail. A KDE4 user thereby retains the use of his/her most desired DM, has markedly reduced CPU, memory and hdd usage and still has an excellent email client option. Very, very, very satisfying. I have no doubt that there will be other FOSS packages that replace Kontact and KAdressBook. Perhaps there is ultimate choice after all, for we can exercise our own choice NOT to do what the KDE4 developers want, even against the restrictions of their own software. The bazaar rules again. Acknowledgement My sincere thanks to the KDE4 team whose unceasing march to the "semantic desktop" made all of this possible - and necessary. I've learned an enormous amount from my three articles on KMail and the "semantic desktop" and for that I acknowledge their "assistance", even if they never knew that they had given such help. If I hadn't been so irritated with their development path, I'd never have either written these articles or bothered to work my way through their incredibly complex packages. I must also congratulate the KDE team for having finally recognised that the Nepomuk portion of their "semantic desktop" is so poor (Reference #5). It's what the users were saying more and more loudly. However the decision to immediately move onto Baloo as the semantic software leaves me concerned that sooner or later, the same position will be reached. Assuming the accuracy of the sum quoted, $US 23.3 million is an incredibly large amount of money to be discarded onto the software scrap heap. Note: Interestingly, a recent poll conducted by FOSSForce (http://fossforce.com/2014/02/kde-tops-desktop-poll/) indicated that 70% of their respondents preferred KDE as their desktop manager. It would have been very worthwhile asking further questions in order to find out how that 70% user base deploys KDE4 and the usage of KDEPIM/KMail, KWallet, Nepomuk and Akonadi. |
|
| Subject | Topic Starter | Replies | Views | Last Post |
|---|---|---|---|---|
| Semantic desktop and web is the future | tuxchick | 19 | 5,514 | Feb 26, 2014 3:13 PM |
| Clarfications | anda_skoa | 0 | 4,521 | Feb 26, 2014 11:49 AM |
| Dumbing-down | penguinist | 10 | 5,168 | Feb 20, 2014 2:28 AM |
You cannot post until you login.