Comment by Morgawr | Hacker News Reader

Comment by Morgawr | Hacker News Reader

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.

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.

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.

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.

Leaving aside the fact that anybody intended on snooping on you doesn't really need the semantic desktop to accomplish his goal, I would argue that while on your setup disabling baloo is clearly the right thing to do, when dealing with TB of (local) storage baloo is faster than find/grep (also, grep cannot read inside odf files). In this sense it is similar to akonadi: there is a threshold after which, if you have a fast connection, it makes dealing with 20GB of email better than using an email client which uses sqlite. In a sense I always felt that while nepomuk and akonadi where plagued with implementation issues, part of the hostility in the KDE community was due to selection bias: people who like KDE in general grok the "hierachical filesystem" metaphor, viz. how kcm is structured. However the random Windows/OSX user (to which a desktop environment like KDE has also to cater, to a certain extent) more often than not has a terrible time organizing files: he creates "dumping ground" folders, and then nest them eight times, or simply puts everything on the desktop and ends up relying on finder for everything. Thankfully baloo now can be easily disabled (and works better than the old nepomuk), and users who need a fast Qt-based IMAP client can use Trojità.

Turning on search for special cases like 20GB of local email sounds like the perfect reason to opt-in to some sort of specialized search system of the user's choosing.

even if you're "good at" hierarchical filesystems they have a few inherent problems:

1) there's overhead associated with coming up with a hierarchical file structure, keeping it updated whenever your problems or your understanding of them change, etc.

2) there's overhead associated with always remembering to put a file in the "right" place every time you save it, actually navigating there to save it, and then fishing it out of the "right" place every time you need a file (getting to a file with search can sometimes be faster than navigating to it even if you know exactly where it is)

3) there is no perfect hierarchical structure for information; there will always be situations where x/y makes as much sense as y/x and both are sometimes inconvenient

this is not to suggest that search, tags and other alternative mechanisms don't have their own problems.

There is also the locate command. When combined with grep, they make a fast way to find files and search within them. For example, to find a Java class anywhere on the system:

    sudo updatedb

    for i in $(locate "*.jar");
      do echo $i; jar -tvf $i | grep -Hsi classname;
    done

The best you can do with vanilla Windows is search from the root directory, but it could take a while:

    for /R %G in (*.jar) do @jar -tvf %G | find "ClassName" > NUL && echo %G

For an experience similar to locate on Windows + NTFS systems, there is Everything [1]. It also has a command line tool that you can use (well) from the command line.

[1] http://www.voidtools.com/

Reply on news.ycombinator.com