Scrap Baloo Thread Feedback

[Matthieu Gallien]

Hello all,

Sorry to exhume this old thread, but

2016-12-29 13:47 GMT+01:00 Dominik Haumann <dhaumann at kde.org>:
> Hi all,
>
> CC: plasma-devel, due to stability issues
>
> On Fri, Oct 7, 2016 at 5:56 PM, Christoph Cullmann <cullmann at absint.com> wrote:
>> Hi,
>>
> [...]
>> Actually, the bugs.kde.org page tells you the facts: The bug number
>> was constant increasing since > 1 year. The thread lists some other facts
>> what is wrong ATM and should be fixed.
>
> Btw, the bug count is increasing again, just as before. So it seems
> problems remain.
>
> [...]
>
>>> Right now, random requirements such as NFS and 32bit systems are
>>> coming up. Are these really that important?
>
> Yes, it is, see below.
>
>>> I specifically designed
>>> Baloo to not care about both network mounts and 32-bit systems. Yes,
>>> Baloo has bugs and it won't handle more than 32bit-inodes. These
>>> things, as all others, can be fixed. It's really a question of what is
>>> important. Lets not target the outliers. Many of these decisions were
>>> deliberately taken.
>> That are no random requirements, sorry, you could call it random restrictions, too.
>> That is not that productive, or?
>>
>> 1) 32-bit systems are still there and if that is a design decision to NOT support them,
>> that is ok, but then bad for Plasma, no official support for 32-bit systems, baloo is IMHO
>> the only framework with such requirements. And I see not that we have hinted any distro
>> that they shall not compile it for 32-bit.
>>
>> 2) No NFS: Ok, fair game, but then, it should check that and disable itself completely if $HOME
>> where the db is stored is a NFS, can live with that, too, but not with the current "we random
>> crash" behavior. => That is a user experience we don't want, or?
>
> The reason why I am writing this mail is exactly this point:
>
> At the university where I was previously working, $HOME is mounted via
> NFS. After an upgrade from KDE4 to Plasma 5.8, the desktop crashes
> very often. And the very reason is baloo.
>
> The problem, however, is that even the sysadmins do not know that
> baloo is the reason for all the crashes. In other words: Hundreds of
> users probably get the impression of an unstable Plasma 5.8 - or even
> worse - it boils down to "KDE sucks" or "I don't have these issues
> with Ubuntu".
>
> This is a perfect example of extremely negative impact - the Plasma
> devs can work as hard as they want, the desktop in this context will
> *never* be stable unless baloo is deactivated.
>
> That said: Baloo needs to disable itself for everything that touches
> NFS, or maybe even disable itself after it crashes several times.
>
> There were many more issues listed and discussed, but as far as I can
> see, we did not make real advances besides some prototype based on
> tracker (just a test), and some minor fixes in baloo that do not
> address the hard problems.
>
> Sorry that this reads like a rant. This is not the intention. Instead,
> the goal is to underline the still severe issues in order to get
> closer to a stable desktop for our users.
>
> Greetings
> Dominik
>
>
>
>> 3) > 32-bit inodes: That is normal and should work, but even if it should not: Atm you get inconsistent
>> and then later assertion fails or crashs.
>>
>> => I can live with all restrictions but the current handling of them, that always ends in "crash" is
>> IMHO not that acceptable. But that is "my" opinion, that might vary in the eyes of others.
>>
>>>
>>> How about requirements such as resource consumption, ease of
>>> integration, search speed are taken into consideration? Come on guys.
>>> We're engineers over here.
>> What is the argument here? If you take a look at bugs.kde.org, you see that people are complaining about all
>> of that with baloo. I see no evidence nowhere that e.g. baloo is "superior" to what GNOME uses
>> or any other solution (perhaps beside nepomuk, ok...).
>>
>> I fixed in a few days more bugs than were fixed in 1 year and triaged more than ever, still a lot is to be done.
>> (and I did really not do a lot, just remove things like 'self destruct if index > 5GB' or 'crash for ever on
>> db corruption')
>>
>> A graph tells more than words:
>>
>> https://bugs.kde.org/reports.cgi?product=frameworks-baloo&output=show_chart&datasets=CONFIRMED&datasets=ASSIGNED&datasets=REOPENED&datasets=UNCONFIRMED&datasets=RESOLVED&banner=1
>>
>> Given the current open bugs, one will need to:
>>
>> 1) review all extractors, they have still close to zero error handling and will just crash or OOM you on bad files
>> 2) review + fix the complete data base handling to handle errors and perhaps swap the DB
>> 3) fix the indexer to have some resource limits to avoid OOM and Co. if e..g extractors fail
>> ...
>>
>> Therefore there was my proposal, given we lack manpower, to implement baloo API on top of e.g. tracker to avoid all this
>> and let tracker handle that.
>>
>> To check if that is at all feasible, I did some quick and dirty implementation (still modulo filling of the metadata in the results + tagging,
>> which is a problem, but that was only to see if e.g. search works)
>>
>> https://quickgit.kde.org/?p=clones%2Fbaloo%2Fcullmann%2Ftbaloo.git
>>
>> That is just a proposal and then I started the discussion.
>>
>> Until now, we have one other proposal, by Boudhayan, to fixup baloo.
>>
>>>
>>> (If the discussion continues on kde-frameworks-devel, I probably won't see it)
>> I won't see it on kde-devel, please, frameworks related stuff should really
>> be discussed on the frameworks list.
>>
>> Greetings
>> Christoph

Is there a common agreement on the best path forward for Baloo versus
the current situation ?

I have an interest in having a global KDE solution where I would help
(as time allows). Still, I will only work after an agreement has been
reached.

Best regards