Hacker News Reader

Comment by 0x8BADF00D | Hacker News Reader

It’s relatively easy to implement search - you need only minimize the Levenshtein distance between the search string and the file name string. The difficult part is actually indexing all file names and their string contents on the system. Grep is a different tool, mainly using regular expressions to match strings within files and I don’t think it is feasible to be continually loading the contents of all strings contained in all files into memory to perform fuzzy string matching.

View on HN

I was always very skeptical about the need for search indexing for local files - how often do you search for stuff to need indexing in the first place? I have a ton of files, certainly more than the average Windows user and i do search for things often enough (at least once a day). To search i use Total Commander (allows for both wildcard/regex searches, archive searches, content search with a bunch of options) which doesn't use indexing at all and search speed was never something i had as a problem (and in general i hate waiting for the computer to do stuff).

In what workflows is search needed so often and for so many files that it necessitates indexing? Even back when i first encountered it (in Vista - AFAIK it existed in XP and before but it wasn't enabled by default) i thought it was a waste of resources and unnecessary complexity.

Totally agree. Back then in XP I'd always disable search indexing, prefetch and superfetch in order to reduce that constant disk activity.

Agreed. updatedb from the locate package is typically the first thing that I uninstall on a new Linux installation. The nightly cronjob definitely consumes a lot more resources over time then it will ever save me waiting time.

Every time?

Searching everything takes lots of time, searching through an indexed database takes less than a second. When in windows I use a locate-port[1] that I use to index any local disks as well as remote network shares of interest. It would take about an hour to search everything.

But an hour wouldn't be that bad, the problem arises when you are not quite sure what you are looking for. Getting the response back instantaneous is invaluable because you can refine your search in seconds.

[1] https://locate32.cogit.net/

And your use case makes sense; but your use case is not typical for 99% of desktop OS users.

And instantaneous results mean nothing if they're worthless. I'd rather let you turn on indexing because you need it and it matches your use case. Leave the other 99% alone.

Indexing benefits the other 99% as well.

Windows default was ok but slow in XP and absolutely unusable since. Any benefit to search would be a massive benefit to millions of people.

Doesn't have to be indexed but would certainly help. I guess SSDs are quick enough many times but it is absolutely essential if a regular hard drive is in the picture.

I use Everything [0], a similar program which is designed to stay resident and essentially become part of your keyboard muscle memory. I have a couple custom shortcuts configured so I can easily open the result, open the result and hide the Everything dialog, or open the folder containing the result.

[0] https://www.voidtools.com/support/everything/

> The difficult part is actually indexing all file names

okay, ...

> and their string contents on the system

... why would you even do that? ls-lR.gz works. And that’s exactly what people wants 80% of time.

Reply on news.ycombinator.com