wander_homer

5 ms·

1.
by wander_homer 3mo ago
Fender recently won a case in a german court, from which they assumed to own the copyright to the famous Stratocaster guitar shape. They then sent out cease and desist letters to many manufacturers who build and sell such guitars in Europe,
2.
by wander_homer 3mo ago
What's the problem with GNOME's approach to file system dialogs? I really like their portals approach. On GNOME you get a Nautilus based picker, on KDE a GNOME app gives you the KDE file picker and if a platform doesn't provi
3.
by wander_homer 3y ago
> Those are two different claims, and the latter is obviously possible if the application performs queries by querying a daemon that is always running with an in-memory index. But the daemon also has to start at one point (you're ju
4.
by wander_homer 3y ago
> I wasn't planning to; it's a once-off cost - the user experience while using any software isn't degraded by the installation time, is it? This whole topic started with you claiming that you can even beat Everything in th
5.
by wander_homer 3y ago
> And yes, it can be done purely by monitoring filesystem changes. Sure, a full index needs to be built the first time, but that's a one-off cost And how do you build the full index initially without recursively walking the filesyst
6.
by wander_homer 3y ago
> I wasn't intending to include transient filesystems in the index. There's absolutely no difference between transient and persistent filesystems in regards to that problem. Every time a filesystem gets mounted, you have no ide
7.
by wander_homer 3y ago
> Basically, how fast can we update the index? The two core issues are: 1) How do you quickly get a list of all files and their attributes from the filesystem, without recursively visiting all directories? The kernel has no such function
8.
by wander_homer 3y ago
> I hope that I didn't come off as dismissive of your hard work or of being disrespectful of what you have delivered. Not at all, I'm just incredibly curious of how you'd solve the issue of creating an index of a filesyste
9.
by wander_homer 3y ago
> Not a problem. And no, I'm not talking about inotify either, and I'll additionally index the contents of (text) files as well with a negligible additional performance hit. It can be done as fast as, or faster than, `Everythin
10.
by wander_homer 3y ago
You mean like being able to read the plocate database with FSearch? I don't see much point in that, because the plocate database is missing some crucial data, which FSearch uses to make searching and sorting quicker. For example file a
11.
by wander_homer 3y ago
Recoll serves a different purpose as it's primarily build to index and search within your personal documents. That's why it doesn't work well when you point it to the root folder, in an attempt to search within the entire sys
12.
by wander_homer 3y ago
> Does it support find in files? No, not yet.
13.
by wander_homer 3y ago
Maybe, but I'm not sure if there's much benefit to that. The most inefficient part of the inotify or fanotify solution is that you have to walk the file system before monitoring can even start, because you first need to know which
14.
by wander_homer 3y ago
I'm not familiar with the internals of plocate, but I'll have a brief look at it.
15.
by wander_homer 3y ago
Yes, it's simply using stat on every file/folder. There's probably some room of improvement there with clever parallelization, but it'll remain a bottleneck. Everything is parsing a file called the MFT to build its index
16.
by wander_homer 3y ago
Most definitely code and documentation contributions and to a degree donations — although I clearly prefer the former, simply because it keeps me engaged the most by talking with others about this project, getting new ideas, etc. But I real
17.
by wander_homer 3y ago
Hi, author here. Likely the most significant benefit is the more powerful query language. For example you can also search by file modification date or size and use boolean operators. https://github.com/cboxdoerfer/fsear
18.
by wander_homer 3y ago
Author here. The app works in two steps: Step one is building an index of the file system. This is simply done by walking the filesystem. The resulting index is stored in RAM and a file. On the next app start the index ia loaded from that f
19.
by wander_homer 3y ago
Hi, I'm the author of this little piece of software. > Also this is anbandoned apparently, which makes me extra sad, because it lacks few crucial features like: PersonalIy I wouldn't call it abandoned. I'm still working on
20.
by wander_homer 3y ago
Nowadays there are several "knock-offs" on the market with higher quality and at a cheaper price.
21.
by wander_homer 3y ago
Because this means the game runs even worse on pretty much every PC out there, since the majority of gamers don't use the most powerful GPU on the market. And it's not like this game has some outstanding visuals which would someho
22.
by wander_homer 3y ago
There's obviously a big difference between your own kid and some other kid. When my own kids do something terrible, I'm obviously going to reflect on whether I did something wrong as well when I raised and educated them and hence
23.
by wander_homer 3y ago
If you'd be running Qalculate on a Linux desktop system, where all the "heavy" dependencies (ICU, GTK or Qt) are already present and shared between all applications, Qalculate wouldn't require 70MB. Of course you could a
24.
by wander_homer 3y ago
> It's also slow to start. It's launching instantly here, with cold caches.
25.
by wander_homer 3y ago
Files get deleted immediately, the USN Journal only keeps track of the events (including delete events). It's basically a log of all filesystem events (up until a certain point in time, due to size restrictions).
26.
by wander_homer 3y ago
Everything is using the MFT as well.
27.
by wander_homer 3y ago
No, upon start Everything loads its database file into RAM and queries the USN journal for all file system changes since the last time it was running. By applying those changes to its current database it automatically gets a consistent repr
28.
by wander_homer 3y ago
locate is much slower than Everything and it also has a much less powerful query language. With Everything you usually get results in way less than 100ms, whereas with locate it's several hundred milliseconds for a database with more t
29.
by wander_homer 3y ago
That's because this is a ThinkPad keyboard. I'll highly doubt that they will get a license to use those by default. They either have to come up with their own design or make it compatible with a ThinkPad keyboard, which you then h
30.
by wander_homer 3y ago
No, you suggested that leaving insert mode to navigate by words is somehow less efficient (since navigating by word is your primary way to navigate in lines) and that maybe that's why you're happy you stopped using vi. Now we foun

More ›