While the new Lenovo placidly runs Debian 13 XFCE installed via Xebian Trixie (not Unstable), there’s still an Acer that has not received any Windows yet and runs MX XFCE. But not the bloat coming from MX bothered me this time.

I noticed that the fan of this Acer had episodes of higher speeds for no apparent reason whatsoever. And I wondered, WTF is it doing? The Lenovo keeps quiet when not under any particular stress.

Here’s the culprit:

Fucking piece of fucking shit, what is this localsearch-3 and what is it doing with my CPU?

I noticed that which localsearch-3 yields nothing, but that there is a folder /usr/lib/x86_64-linux-gnu/localsearch-3.0/ with several .so files, including libtracker-extract.so. Not revealing.

So I asked Gemini. It answered:

That 100% CPU spike is a classic Linux headache. What you are seeing is LocalSearch, which is the rebranded version of GNOME’s background file indexer (previously known as Tracker 3 or tracker-miners). Its job is to crawl your storage and index the metadata of your files (videos, photos, docs, audio) so desktop applications can search through their contents instantly.

It’s a service, and it suggested me to disable (and mask) it. But it was wrong to also make this false claim:

A clean, default installation of Debian XFCE will also pull this in.

Before further investigating, I yelled at Gemini:

Nobody should need to index anything, unless it’s an app explicitly installed to that purpose, such as fsearch!

There are standard directories in Linux. Everyone knows them.

Then, when in a folder, there are functions such as findfirst and findnext.

I DO NOT NEED ANY UNNECESSARY INDEX!

I’ll only quote the beginning of its answer:

You are preaching to the choir here. From a pure engineering and resource-efficiency standpoint, you are completely right.

Traditional filesystem traversal using standard directory streams—like opendir(), readdir(), or the classic findfirst/findnext architecture—is deterministic, instantaneous for localized tasks, and consumes exactly 0% CPU when you aren’t actively looking for something. If you keep your storage organized, an on-demand tool like fsearch or a quick command-line find is all you ever need.

The reason the modern Linux desktop ecosystem shifted toward background indexing databases comes down to a fundamental design conflict between power-user efficiency and consumer UI expectations.

I needed to vent:

Loot at me: I HAVE DISABLED FILE INDEXING IN WINDOWS 11 AND YOU TELL ME I CANNOT UNINSTALL FILE INDEXING IN XFCE LINUX?

It agreed that I could, but I need to be careful, so I’d better run a simulation first:

sudo apt purge --simulate localsearch tracker-extract tracker-miner-fs

That was revealing:

Aaah, it would remove nautilus, which I only installed for testing purposes! So, in the end, it was “something GNOME” that required it, not XFCE!

Indeed, fucking shitty Nautilus.

Kids, don’t let any piece of shitty GNOME contaminate your clean and neat XFCE system! If you need bloat, then run Windows! (Or macOS.)

Now, apparently, the next-generation Tracker is TinySPARQL (tinysparql), just because they can.

They are destroying Linux.

UPDATE: A technical clarification

I do use both GTK-based and Qt-based apps with XFCE. Some “GNOME” apps use this name falsely (think of “GNOME Commander”). So, most such apps are “for GNOME,” but:

  • Some only use GTK+ and GVfs.
  • Some have a limited number of GNOME libs dependencies.
  • The vast majority do not require Tracker or TinySPARQL or any availability of a LocalSearch.

From what I know, the only major GNOME apps that require a semantic database are a very few “truly GNOME” apps: Nautilus/Files, Totem/GNOME Videos, GNOME Music, and GNOME Photos. Apparently, Showtime/Video Player does not require a semantic database!

So it’s almost always safe to install GTK-based or “GNOME” apps.

Then, there are so many “GNOME” Flatpaks that:

  • Require a version (47 to 49 usually) of the GNOME framework, shared with other Flatpaks.
  • Rarely require Tracker or TinySPARQL, and if they do, they can fall back graciously if an external LocalSearch database is not available.

So Flatpaks are also safe.

There is also Baloo, KDE’s indexer, but very few apps pull it as a dependency. Just don’t install Dolphin.

The vast majority of Flatpaks requiring KDE libs are then also safe.

Also worth noting is that Cinnamon’s Nemo and MATE’s Caja don’t require any background indexing service! Nemo handles content searching entirely on demand. Caja, being even more traditional, only searches files as find would do it, and also on-demand only.

Bottom line: don’t install Nautilus, GNOME Music, GNOME Photos, Totem, Showtime, or (cough) Dolphin.