[prev in list] [next in list] [prev in thread] [next in thread] 

List:       kde-panel-devel
Subject:    Re: Scrap Baloo Thread Feedback
From:       Matthieu Gallien <gallien.matthieu () gmail ! com>
Date:       2017-03-28 9:21:11
Message-ID: CAKeq17fh-0xpX9gsTC=o58j1FWuVsZaVjDZE3XiMXnpATqTZRQ () mail ! gmail ! com
[Download RAW message or body]

Hello all,

Sorry to exhume this old thread, but

2016-12-29 13:47 GMT+01:00 Dominik Haumann <dhaumann@kde.org>:
> Hi all,
> 
> CC: plasma-devel, due to stability issues
> 
> On Fri, Oct 7, 2016 at 5:56 PM, Christoph Cullmann <cullmann@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&datase \
> > ts=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


[prev in list] [next in list] [prev in thread] [next in thread]