balooctl and its file-indexing is the worst that plasma ever created. please stop to implement it as activated as default. this piece of software is a waste of power-consumption that drives me nuts and i’m convinced that i’m talking for most of us users. it creates a waste of cpu-load without any real effort.
1 Like
settings > file search is where to disable it if you do not wish to use it.
whether this setting is on by default is a distro specific issue and not a KDE issue.
kubuntu for instance does not have this turned on by default, the user must enable it.
and while baloo is far from perfect, your characterization is rather harsh… it does accomplish the task speeding up file searches if you set it up properly.
3 Likes
touche, i agree that some distros disable it.
i disagree, my words sound harsh but baloo isn’t far from perfect, it’s just a total design-flaw that is wasting cpu-power, producing wasted eletrical energy and has no, absolutely no effort to a usual desktop-computer. this piece of software is a total design-flaw that should be banned imho.
1 Like
ymmv, i guess.
i use it and as long as it’s not trying to index files/folders with a lot of churn it works well enough at speeding up searches, and esp for adding meta data to dolphin or being able to quickly find content within my documents.
i specifically exclude the ~/snap directory and any hidden files tho, so that’s probably helping my experience.
all that said, i believe KDE is working on a more comprehensive file search feature that will be built into dolphin so that you won’t need these external tools/helpers.
It’s only really bad on some users’ data, and then unpredictably. For some users it can wear out hardware, or at least it could the last time I let it run, years ago now.
While I don’t entirely agree with the arguments, I am very much on team “Baloo is bad”.
From the early days of single core processors and incredibly power/performance constrained laptops. To even the early days of SSDs and how quickly you could wear through the limited life on the NAND. I very quickly realised that no matter how much time I put into figuring out baloo, it would eventually start indexing while I was in the middle of a game or if I was in a class in university and kick the fan on the laptop into high gear. It’s not as bad as what Microsoft would eventually try to do with “Cortana”, but for years it has been bad.
It’s always one of the first things I disable if I install a distro that comes with it enabled.
1 Like
How do you know it’s a design flaw?
A recently version of the indexer in GNOME stuck in an endless loop of crashing on a OpenOffice file. I don’t assume it a design flaw. It’s a bug and fixed in the next version.
1 Like
I disagree, it always worked perfectly for me - until I started messing in the settings… but once I’d fixed it, never another issue.
2 Likes
I think most user issues would be solved if Baloo was by default set up to index the xdg standard Documents, Music, Video, Projects etc. folders, instead of the whole home dir.
2 Likes
I can’t comment, it’s been soooo long since I installed and set it up that I have no idea what the default is, or even if that default is the same for all distributions.
I’m confident that, for example, if Manjaro users complain in the forum - then the developers read and parse those complaints, and that the developers would already have ‘tuned’ their releases to align with the greater common good.
The problem with overly selecting folders to be indexed is that then, files in other non-hidden folders, or newly created folders, would not be indexed…
My ~/Notes folder, for example… shouldn’t need to be added manually.
Without specific and detailed information about individual cases, it becomes a witch-hunt with no benefit.
The behaviour of Baloo is such that it will pick up newly created files and folders - and the only real benefit of limiting this would be to slighly limit the initial indexing load.
It is absolutely deliberate and intentional, and I think absolutely correct.
Minimalists are free to disable, or limit Baloo as they see fit.
This thread is pretty useless. The original post is a rant about how bad a particular piece of KDE software is, with no specific complaint, let alone an actionable bug report that developers can look into.
KDE isn’t a big company; there’s no point in making a public stink as if you’re yelling into the void of a faceless corporation that doesn’t care. That’s a habit to un-learn as you make your journey into the FOSS world, where the separation between users and developers is somewhere between small and non-existent.
@olli72 If you’re having a problem with Baloo, the best approach is to troubleshoot the issue a bit and then, once you’ve found out the proximate cause of the issue, open an actionable and neutrally-worded bug report. That way the issue stands a good chance of actually being fixed, and you can have a better experience going forward rather than seething with barely-contained rage.
11 Likes
The only thing I changed (probably, same thing, not completely sure anymore but I almost always make sure that is the setting at least) is to index file names only and not the content.
And I don’t see any unexpected cpu spikes here (with a cpu widget at a second monitor).
But I’m pretty sure if that would be the default (if it is not) people would complain about not finding their documents immediately.
content is fine… tho slower and makes the index bigger.
the real churn comes from indexing hidden files… esp .cache
run this in a window and watch what files are changed as you go about your day.
watch "find -type f -mmin -1 -printf '%C+%p\n' | sort -n | tail -10"
if you use snap, a lot churn comes from the ~/snap directory, which is why i exclude it.
2 Likes
It sounds like Baloo should exclude this location by default. That would be a sensible thing for it to do.
4 Likes
So… bug report please 
3 Likes
That’s insane, a quick search reveals a lot of ubuntu based forum comments specifically explaining how to remove this from baloo - the ~/snap/data directory especially…
So - another reason to justify hating on snap 
2 Likes
flatpaks have their churn too, it’s the nature of the beast when you have a mini operating system running in a folder.
but at least with flatpak it’s contained in ~/.var which is a hidden directory and why i also do not recommend running baloo on hidden folders.
no idea why ~/snap couldn’t also be hidden as in ~/.snap but here we are.
Yes - as does Plex - with the millions of cached bits 'n pieces… but Snap is an exception.
It was a DELIBERATE decision to make it all visible, for ‘transparency’ appearently.
Canonical knows what’s best for you, don’t argue. Maybe everyone at Canonical uses Gnome and don’t like Plasma…
Snap’s security sandbox demands strict confinement for security, and the interface can only have access to non-hidden files and directories at the top level of the home directory.
Flatpak is more ‘Linux’ like in it’s character - and it’s quite possible to dive into the hidden folders and find settings (similar to .config) and I had success linking configs in the past, such that I could swap/delete a flatpak install with a repo binary install and the settings persisted.
Solution?
sudo snap set system experimental.hidden-snap-folder=true
That’s right, an experimental feature to move data to ~/.snap/data
Here you go
… in the process I triaged a bunch of revelant issues too.
2 Likes
so if i were to run that, then everything from /snap would be moved to /.snap ?
i’m not going to try it, but that would seem like logical thing for a distro to do, if they were going to use snap.