KDE's Nepomuk Doesn't Seem To Have A Future

[anda_skoa]

That was exactly my point! Since plain old grep can find stuff in what I called "proper" PDFs, and nepomuk cannot OCR the innumerable "bogus" PDFs created by document scanners, the value of the index -- and nepomuk -- is limited for many users.

True, but an OCR indexer could be added while it would be difficult to add that functionality to grep (aside from an indexer OCR'ing once per document and grep OCR'ing per search).

Still a good point, but also a good example where and index that can be built using various tools can improve over the base functionality available elsewhere

Cheers,
_

[tuuker]

most horrible invention ever in KDE history, finally they will get KDE cleaner and less dependencies.

[justinzane]

thanks for the code snippet and useful grep's.

Here is the biggest problem with society: LAZY! Nepomuk shouldn't be strictly needed...

"Say you received a photo from a friend of yours, 2 weeks ago. You saved it somewhere on your computer. Now how to you find that file? If you don't remember the location, you're out of luck." http://userbase.kde.org/Nepomuk

Its not that hard to organize your damn files... /home/user/pictures/2014/trip_to_x /home/user/pictures/2013/downloads_from_net /home/user/pdfs/categoryXYZ /home/user/projects/xyz.

There is no reason to NEED to search /home/* if you have ANY sense of organization skills... So therefore, indexers are not very useful.

Email, on the other hand, sure, index it, cache it, metadata, tag the crap out of it. Google Desktop Search is WAY better then Outlook for searching my Exchange email at work for instance. and that is more useful than organizing emails into folders.

My sentiments exactly.

[justinzane]

I don't think anybody suggested that Nepomuk was able or even asked to do any OCR.

That was exactly my point! Since plain old grep can find stuff in what I called "proper" PDFs, and nepomuk cannot OCR the innumerable "bogus" PDFs created by document scanners, the value of the index -- and nepomuk -- is limited for many users.

[justinzane]

Yes, it's not strictly needed..
I know exactly in what folders I put all my stuff..

It's more work to open up a file manager and navigate to those folders than to press Alt+F2, type in a tiny part of the filename and have it instantly appear there, no matter what folder it is in.. No waiting for a find / search to find the file, no navigating folders in a file manager, and no opening up a terminal to "cd" to the file! Nepomuk is far superior in every way, not sure why more people dont use it, but I assume it's just that they don't have the hardware for it.

Being lazy is ok, if it saves you time and work!

Tell me, how does nepomuk know how to find the DEMS http://asterweb.jpl.nasa.gov/gdem.asp that are needed to do a viewshed of 41.123456N,-122.334455E? Whatabout the OSM http://www.openstreetmap.org/ shapefiles with the roads in that area?

[Wed 14/02/19 16:34 UTC][pts/2][x86_64/linux-gnu/3.12.9-2-ARCH][5.0.5]
<[email protected]:~>
zsh/2 1190 % nepomuksearch bt.sisx 

  /mnt/shared-docs/software/symbian/1.bt.sisx
  ... bt.

[Wed 14/02/19 16:52 UTC][pts/2][x86_64/linux-gnu/3.12.9-2-ARCH][5.0.5]
<[email protected]:~>
zsh/2 1191 % nepomuksearch bt.sis 

[Wed 14/02/19 16:52 UTC][pts/2][x86_64/linux-gnu/3.12.9-2-ARCH][5.0.5]

Oops, apparently it cannot help me if I do no remember that that ancient Symbian S60 utility ends with an "x". `locate` happens to find it though. Seems like that little indexing utility works well.

[justinzane]

Multitasking has nothing to do with it. Multitasking lets you do other things while you wait, but it does not reduce the wait in any way.

Caching reduces wait. Just like firefox maintains a copious ram and disk cache, and kmail stores local copies of imap mails, and akregator stores local copies of RSS data.

For searching purposes, it is called indexing.

Multitasking in the human brain, silly.

After all, as I tried to point out, an index or cache is rather useless if it has no content -- which is almost guaranteed to be the case for all but the most common text-derived content.

And, no, kmail does **not** by-definition store local IMAP copies. Though it can be setup to do so, it also can be setup to store nearly nothing locally, leveraging tiny clientside flash/SSD storage and gigabit networks.

And, no, firefox does **not** necessarily store anything in a disk cache. As with kmail, this is configurable to individual needs and circumstances. The instance of firefox that I am using right now does not cache anything to disk, though it does use a large RAM cache.

Please stop generalising with that example. It is not relevant to tremendous corpora of user data in all but the most simple and common formats.

[Sidicas]

Here is the biggest problem with society: LAZY! Nepomuk shouldn't be strictly needed...

Yes, it's not strictly needed..
I know exactly in what folders I put all my stuff..

It's more work to open up a file manager and navigate to those folders than to press Alt+F2, type in a tiny part of the filename and have it instantly appear there, no matter what folder it is in.. No waiting for a find / search to find the file, no navigating folders in a file manager, and no opening up a terminal to "cd" to the file! Nepomuk is far superior in every way, not sure why more people dont use it, but I assume it's just that they don't have the hardware for it.

Being lazy is ok, if it saves you time and work!

[TheBlackCat]

My feelings exactly. I use Akonadi and to think that now I'm only getting 80% of the features of Akonadi going forward? Kidding me right?

*sigh* As I have already explained in this thread several times, Akonadi was NOT using those 20% of features. No user-facing KDE software was.

That is why they are removing those features. They simply are not useful for desktop, laptop, or tablet systems.

[GreatEmerald]

My feelings exactly. I use Akonadi and to think that now I'm only getting 80% of the features of Akonadi going forward? Kidding me right? It doesn't have enough features as it is. I don't care what bad things people say about KDE's desktop indexing, I use it all the time, the way it is.. and now I'm not going to be able to..

If you're going to replace something, it should have at the very least, feature parity.. Replacing a solution with another solution that does only 80% what the old solution did is not a solution! It's a regression..

Ya, the other solution might be faster, but I don't care if it's faster. Learn to buy a faster PC. I'm sure they could make Akonadi a lot faster too! By cutting out 20% of the features that slow it down the most! What's the point of this??

Argh, again, it's Nepomuk! Nothing is being done to Akonadi!

[Sidicas]

Why does the KDEPIM community always replace components when they are not yet finished? Nepomuk and Akonadi were forced onto the user's desktop in an unfinished state and now you are doing it again. Didn't you learn anything?

Many people have Akonadi disabled, so they won't mind. There are people however, who actually use Akonadi and now they get a replacement which is only 80% feature complete? I really hope those 80% features are at least stable or KDEPIM will be running into the next disaster. You guys really know how to annoy your users the most.

My feelings exactly. I use Akonadi and to think that now I'm only getting 80% of the features of Akonadi going forward? Kidding me right? It doesn't have enough features as it is. I don't care what bad things people say about KDE's desktop indexing, I use it all the time, the way it is.. and now I'm not going to be able to..

If you're going to replace something, it should have at the very least, feature parity.. Replacing a solution with another solution that does only 80% what the old solution did is not a solution! It's a regression..

Ya, the other solution might be faster, but I don't care if it's faster. Learn to buy a faster PC. I'm sure they could make Akonadi a lot faster too! By cutting out 20% of the features that slow it down the most! What's the point of this??