Last updated on November 20, 2020 by Adrien Brochard
One of the most disliked features of the early KDE SC 4 releases was the developers' attempt to establish the semantic desktop. The tools to further this goal are Nepomuk and Akonadi. While Nepomuk tries to interconnect meta data from different desktop applications, Akonadi is a service that stores and retrieves data from PIM applications like mail, calendar and contacts. Together, they pave the road to allow users to find data, structured and connected by tags, ratings and comments, covering different file formats. On top of that, Strigi performs the indexing that enables users to find data with simple search terms in KDE's file manager Dolphin.
In the background, the Soprano framework acts as a repository to store information generated by Nepomuk. This information is then stored as Resource Description Framework (RDF), which is a fundamental standard for describing and modeling information in the semantic web.
With RDF, we are closing in on the crux of the matter that made Nepomuk hard to manage for many users. RDF seemed like a right tool for the job, but it proved to be oversized for the use with desktop systems. The initial indexing process hogged RAM and CPU resources to a point where a lot of PCs came to a grinding halt if the hardware involved was not of the latest make. On up-to-date hardware, the initial run could still take days, depending on the amount of data to crawl. So, a lot of users turned Nepomuk off, which in turn deprived the developers of much needed testing and bug reports. Things got better as KDE SC 4 moved along, but never to the point where developers or users were happy. At some point in the late KDE 4 cycle, development of Nepomuk was exhausted, and the resource usage was still not appropriate.
With KDE SC 4.13, a new tool moves in, and takes Nepomuk's place. Baloo was developed using a lot of Nepomuk code, but leaving RDF out of the picture. Instead of using a central database, it stores data decentralized in plugins. At the core of it, there are three services: Data Stores, Search Stores and Relations. A Data Store stores data permanently. Search Store is a plugin which offers search capabilities for a specific kind of data. So far, there are three search stores implemented as plugins: File Search, Email Search, and Contact Search. The data provided by the three services is stored using a combination of sqlite and xapian.
Relations can be defined as ties between two uniquely identifiable identifiers. For example, relations can exist between PIM data, still provided by Akonadi, and data from files that Baloo has in storage. There can be different types of relations. A TagRelation might map a tag to a unique identifier, or an ActionRelation could map a file received by a device to the device itself.
Besides the search mask in Dolphin, there is also a new graphical interface to perform your searches. It's a Plasma widget called Milou and is officially not yet part of KDE SC. Eventually, Milou is supposed to also take the place of Krunner, equipped with a new search library in the background by the name of Sprinter. Plasma developer, Aaron Seigo, has connected the bits and pieces on this for us in his blog post.
When I first upgraded to KDE 4.13, I took some precaution to make it a smooth move from Nepomuk to Baloo in regards to the already existing databases in the background. If you never used Nepomuk, you will not need to go through this. Let's look at System Settings for a start. There you will find an icon called Desktop Search. Next to it you might, depending on the packaging of your distribution, see a similar icon called Desktop Search Advanced. If the second one is missing, you can try to install
baloo-kcmadv, which should provide the alternative interface. At the moment of writing, there is no decision yet on which interface will survive, but let's hope for the advanced one, as it provides the user with more ways of configuring what gets indexed. Make sure indexing is deactivated for now.
When installing KDE 4.13 or updating to it, existing Nepomuk databases are supposed to be migrated to Baloo standards. That does not work reliably yet for everyone, but you can easily check if it did work for you. If the migration went smooth, the first line in the file
~/.kde4/share/config/nepomukserverrc looks like:
If that is not the case, you can manually start the process. First check if Nepomuk is running:
$ nepomukctl status
Towards the bottom of the output you should see the line:
Nepomuk Server is running
If that's not the case, start it with:
$ nepomukctl start
After this script has done its magic, you should find the migrated and converted data under either
~/.local/share/baloo, depending on your distribution.
Should the script also fail to do the job, and there is no database under one of the two possible locations mentioned above, you can go to
~/.kde4/share/apps/nepomuk/repository/main/data/virtuosobackend/ and delete the files in there to make a clean cut.
Now go back into
System Settings –
Desktop Search Advanced, and enable the file indexer. You will hopefully not be bothered by any signs of the activity running in the background. Baloo is by far not as resource hungry as its predecessor, and works fast and reliable for me. Over the past weeks, I have read complaints that said it was also slow and a memory hog. I tested Baloo on a couple of machines and can not second that.
One of the users having problems with Baloo ran KDE on a machine with one GB of RAM. KDE will run on that kind of hardware, but it will be no fun and you would have to turn indexing off. My recommendation is to have at least 4 GB RAM with KDE. This will give you a snappy desktop environment, and Baloo will run smoothly in the background. As KDE SC moves on to KF5, Baloo will be ported to Qt 5. Existing databases will stay compatible between versions. Nepomuk has come to its designated end-of-life and will not be ported. It will vanish from your computers as you upgrade to KF5.