| 1 |
On 11 Feb 2010, at 00:01, Jörg Schaible wrote: |
| 2 |
>> ... |
| 3 |
>> your understanding is wrong. Completely wrong. Seriously it hurts. |
| 4 |
>> |
| 5 |
>> start here: |
| 6 |
>> |
| 7 |
>> http://en.wikipedia.org/wiki/NEPOMUK_(framework) |
| 8 |
>> |
| 9 |
>> and then proceed with the links. |
| 10 |
>> |
| 11 |
>> google-desktop is something completley different (and something |
| 12 |
>> that can |
| 13 |
>> be replaced with find, locate and grep). |
| 14 |
> |
| 15 |
> Well, in 4.3.x I eliminated it after the first try, because it took |
| 16 |
> so many |
| 17 |
> resources of my machine, that I could not use it for something else. |
| 18 |
> So, you |
| 19 |
> mean, in 4.4.x it takes only a 10% of the resources it took with |
| 20 |
> 4.3.x? LOL, |
| 21 |
> although I really like the idea of the semantic desktop, I rather |
| 22 |
> have a |
| 23 |
> usable machine ... |
| 24 |
|
| 25 |
I don't use KDE, but when I freshly install Mac OS (or migrate to a |
| 26 |
new hard-drive) the Spotlight indexing hammers the drive for several |
| 27 |
hours. It is not reasonable to compare performance during this initial |
| 28 |
indexing period. |
| 29 |
|
| 30 |
There is no way the likes of `find`, `grep` and `locate` - useful as |
| 31 |
they are - can operate as efficiently as this kind of indexing (and |
| 32 |
Spotlight is pretty damn poor - your KDE implementation is surely |
| 33 |
loads better). I love `find`, `grep` and `locate` - they're fantastic, |
| 34 |
but my typical usage of them is to perform strict batch operations. If |
| 35 |
I just want to open a document then why would I wait for `find`, |
| 36 |
`grep` - or go hunting around manually in sub-directories of sub- |
| 37 |
directories - when I can just type a keyword into the search box and |
| 38 |
find it immediately? |
| 39 |
|
| 40 |
I cannot for a moment believe that you (Roy) can organise your files |
| 41 |
so that you can find them easier than typing a search term & clicking |
| 42 |
on the correct result. You just don't want to try it because your |
| 43 |
current methods are "good enough" for you, but this isn't good grounds |
| 44 |
on which to complain about KDE moving on with their development of a |
| 45 |
state-of-the-art desktop which will actually make life easier for |
| 46 |
millions of other people (people who aren't afraid to try it). |
| 47 |
|
| 48 |
After the initial index, data is only indexed when you save a file, |
| 49 |
using inotify [1], which is built into the kernel for maximum |
| 50 |
efficiency. (Please correct me if I'm wrong about KDE's |
| 51 |
implementation). So in actual real world usage, the result is that it |
| 52 |
takes a fraction of a second longer when you save an Open Office |
| 53 |
document. My 5 year old desktop can handle this overhead just fine. A |
| 54 |
£100 Core 2 Duo + motherboard combo would surely handle it MUCH |
| 55 |
better. I trust you can see why I'm dubious of claims of poor |
| 56 |
performance. |
| 57 |
|
| 58 |
I don't wish to seem rude, being strident with my arguments here. This |
| 59 |
is just the way I see it. |
| 60 |
|
| 61 |
Stroller. |
| 62 |
|
| 63 |
|
| 64 |
|
| 65 |
[1] http://en.wikipedia.org/wiki/Inotify |
Archives