I've been a KDE user for a couple of years now. I've moved between DEs a lot in the past, XFCE, LXDE, Gnome2/3, Cinnamon, Unity... I think I've tried them all, even more obscure WM like AwesomeWM, XMonad and similars. I have to say KDE beats them all on plenty of things. It is absolutely amazing and I couldn't be happier using it.<p>However, on the other side of the coin, I've always hated semantic search and indexing. Maybe it's because I'm a power user, but even when I was using windows I hated the indexing of files. I hate the idea of something going through my entire hard drive multiple times at intervals to track and scan all my data, index it and make it readily available for me. Why? Because it's the perfect invitation to have people more easily snoop on your stuff, because it consumes resources, spins up disk I/O unnecessarily, introduces unexplainable slowdowns. All of this for a comfort that I really don't require. I know where I put my files, thank you very much. If I can't find a file, good ol' find/grep can do the job equally well.<p>I had this massive problem with Baloo on KDE slowing down my entire machine, I had to run iotop to figure out what the issue was. I run multiple sshfs mounted partitions in my home and Baloo in its indexing would constantly crawl through them multiple times every day, which means it'd send a lot of network requests, slow down I/O operations everywhere and grind my machine to a halt.<p>It took me a while to figure out how to disable the entire thing (I wasn't even aware KDE did indexing before that, to be honest) but now my machine is better than ever. The first thing I do when I install a fresh KDE setup is to turn off all that stuff and I would advice every power user on KDE to do that as well.
The many times I did whatever it took to make Nepomuk and/or strigi stop using CPU time, I always felt a vague sense of guilt.<p>Am I a bad person for depending on the combination of having an SSD + endless variations of the find command, strings, and grep? Such as find ./ -iname '<i>.c' -or -iname '</i>.h' -exec grep -Hn pattern \{\} \; ?<p>I just want my data in text; I don't care about semantic anything, and I'm sorry :( I wish I had time to appreciate whatever the hell it is these processes I must stop are trying to accomplish, but I'm relieved they are going away or being cut down to doing just one thing in a well defined role.
Good riddance. It was a bad idea at the time and still is, just like the Semantic Web itself. Nepomuk was complex and fragile, as was Akonadi; I've lost count of the number of times I was unable to read my email because this supposedly "optional" piece failed (usually due to an akonadi problem). In the end I resorted to <a href="https://www.trinitydesktop.org/" rel="nofollow">https://www.trinitydesktop.org/</a> - KDE3 which was less flashy, but worked.<p>This post is a good sign - maybe KDE is belatedly paying attention to user-facing functionality rather than academic technology exercises. Maybe I can switch back to "mainline" KDE.
Nepomuk was nothing else, to me, than a series of repeated Segfaults.<p>The semantic web bring ideas for structuring informations, enabling machines-exploitable databases to exists. The Semantic Desktop was -maybe- ahead of its time, but certainly too poorly implemented.
Almost everybody I know, that was using KDE, did it because of the pure desktop and not because of the semantic Desktop. Every time, the discussion came to the later, it was how to disable it.<p>I think, it was a bold idea, but not well implemented. Maybe it also was to soon for such a bold move. With the advent of more cores and faster disks (eg. SSD) there might come the time for an other desktop to implement such thing. When you have eight or more cores, you don't have to worry when one is doing an indexing job all the time.
When I hear the words "desktop" and "innovation", I reach for my revolver.<p>My current fervent hope is that Xfce just does 4.x versions forever and never goes to a CADT-cursed 5.x.
I would say "Baloo", based on Xapian search engine and SQLite, is still a "desktop search": <a href="http://en.wikipedia.org/wiki/Desktop_search" rel="nofollow">http://en.wikipedia.org/wiki/Desktop_search</a><p>The older KDE desktop search implementations Strigi (based on C++ based Lucene port) and the EU sponsored ontology based Nepomuk research project failed. <a href="http://en.wikipedia.org/wiki/NEPOMUK_(framework)" rel="nofollow">http://en.wikipedia.org/wiki/NEPOMUK_(framework)</a>. I remember KDE "D-Bus" cause many problems in the early days of Strigi and Nepomuk.<p>Gnome and Ubuntu use/used the Nepomuk ontology as well: <a href="http://en.wikipedia.org/wiki/MetaTracker" rel="nofollow">http://en.wikipedia.org/wiki/MetaTracker</a><p>The <i>desktop search engine war</i> era (2003-2006) between Microsoft Windows Longhorn WinFS (2003-2006), Microsoft Windows Vista desktop search (2006), Apple MacOS X 10.4+ Spotlight (2005) and Google desktop search (2004-2011) also brought desktop search to the Linux desktop. <a href="http://en.wikipedia.org/wiki/Windows_Search#Windows_Desktop_Search" rel="nofollow">http://en.wikipedia.org/wiki/Windows_Search#Windows_Desktop_...</a> , <a href="http://en.wikipedia.org/wiki/Spotlight_(software)" rel="nofollow">http://en.wikipedia.org/wiki/Spotlight_(software)</a> , <a href="http://en.wikipedia.org/wiki/Google_Desktop" rel="nofollow">http://en.wikipedia.org/wiki/Google_Desktop</a><p>One of the reason why WinFS failed was its complex ontology (and it was coded in C# in user mode, so it was very slow). Windows Vista shipped with traditional desktop search with an advanced search dialog and a very good basic onotolgy (sadly the advanced search dialog is missing since Windows 7). WinXP already had the optional "indexing service" predecessor and the desktop search was also available as "MSN" addon download. <a href="http://en.wikipedia.org/wiki/Windows_Search#Windows_Desktop_Search" rel="nofollow">http://en.wikipedia.org/wiki/Windows_Search#Windows_Desktop_...</a><p>Edit: to the downvoter: D-Bus was inspired by OLE, DCOM, CORBA, KParts, Bonobo (<a href="http://en.wikipedia.org/wiki/D-Bus" rel="nofollow">http://en.wikipedia.org/wiki/D-Bus</a>). Search on Google for "strigi dbus problem", "nepomuk dbus problem". D-Bus caused problems in the early days of KDE4, strigi and later nepomuk era.
It's very rare that I have to search my whole machine. Mostly my search need is to find a string in a specific directory using grep.<p>I am happy to get rid of the automatic indexing, it has caused me nothing but pain.
I have used KDE for a few years now. Fundamentally, I don't mind the idea of a semantic desktop, but I don't want the indexer to be running unpredictably, and I want to construct my own layers of meaning.<p>The way I have addressed this is: I have a large blob of files; I've ordered them through typical directories. This is portable through Linux/Windows/OSX (some of these files have migrated from DOS). The directory structure and naming itself is my semantic categorization. It's a bit hinky in places, but it is (1) portable and (2) supported by any operating system work using on the desktop.<p>At some point I will probably write an indexing system designed to handle tagging to deal with my files: however, at present, I get what I want when it comes to files.
I feel about Activities the same way I feel about nepomuk and virtual desktops: great idea, but useless for my workflow.<p>That said, KDE 5 (even with huge showstopping kwin_x11 bugs in latest Arch) is light years beyond every other desktop, including Yosemite and Aero.
Too bad this semantic desktop concept did not work out.<p>I have two Linux laptops, and as I started reading the article, I was thinking of installing KDE, only to be disappointed to read that the project is basically dead.<p>I have written two Semantic Web books and have had some semantic markup on my web sites for about ten years, but my view of the SW is changing. Google Knowledge Graph, which I worked with in 2013, is basically a huge triple store, but different than SW because it is one giant curated repository, and not a distributed interlinked graph comprised of many sources.