Hello all, Sorry to exhume this old thread, but
2016-12-29 13:47 GMT+01:00 Dominik Haumann <dhaum...@kde.org>: > Hi all, > > CC: plasma-devel, due to stability issues > > On Fri, Oct 7, 2016 at 5:56 PM, Christoph Cullmann <cullm...@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