FOSDEM 2026: Desktop Search Interview

It could be a extremely big step to have technology and instruments like this I feel. What's everyone's opinion on utilizing this technology as a substitute of a very new one? KDE can ship an entire atmosphere of applications that make the most of this expertise from day 1. these purposes will make all of the difference IMO. Do not get me incorrect, I don't have a problem with Postgres, I simply hate to see KDE use the identical argument in opposition to one thing that has been leveled against us. It's licensed under Apache license, Ansi SQL, portable (pure java), has a small footprint and is supposedly very easy to use. I'm stunned too, sqlite could be very small and is in public domain license. It would be cool if the backend was developed using Qt4, so it would be a pleasant small dependency that different tasks might use. Time. And that i imply that in just a few ways - we'd like time to complete fleshing out the concepts, time to let the stuff mature inside of KDE and properly, the couple of us working on it may use extra time for such.

I did the unique mockup prior to the KDE conference this summer time with SQLite and the performance for the kind of queries that we're doing was so dangerous that it merely isn't an choice. So KDE is going to choose a database that's LGPL due to licensing restrictions from utilizing a straight GPL'ed database when we use a GPL'ed toolkit to do Everything associated to Qt? About 5% of the time, it will be less efficient but they will not know that going in, so they're going to use it anyway. What is going to take a very good whereas will likely be porting over purposes to make use of it where applicable. I say.. good luck? That some of the information isn't on-line does not change that categorization is a good way to prepare it. I believe this is an efficient decision. Think horsepower. OS/2 had a useful means within the Workplace Shell where you could possibly have a folder containing documents, and if you opened or closed the folder, the paperwork would be opened or closed, ie. In fact, that might be discovered just by the fact that I do know the title, however there are some issues that aren't so simply tracked by identify, haven't any searchable contents, and are rarely used but important.

Reiser and RDBMS's are like X Window: low stage technologies that gives a means to perform the duty (with various levels of success); things like what this interview is about are like Qt: a layer that makes application growth leveraging the possibilities of the platforms possible. The middleware, what data is archived and listed, and the way contexts and patterns are matched is the key. I want one thing that recognizes contexts of exercise. Perhaps I am missing something here, but what I want to start out with is that I have a directory with a bunch of HTML information in it and i want to be in a position to look them for content just like Google searches the online. I've began playing with reiser4 a while ago to write a plugin to enumerate modified information fast and reliably. Does your plugin have a webpage? E.g. I would have /residence/bryan, and mark it recursive and hidden As root I'd add /usr/share/music (all my oggs and many others., shared between customers), and mark it as recursive and visible to all. For each directory have a sqlite DB in the root of that directory called .dirindex.sqlite or something. SQLite also locks your entire database on write, which simply isn't acceptable in a software used steadily by a number of processes.

But I do wish it could all be independent of the particular database used. Then the initiatives that I work on, ie taxes, planning a visit, researching a specific topic, work tasks such as proposals and product research, etc. For example, in june of final yr I used to be researching travel in europe since my daughter was travelling there, and that i wanted to determine how you can her get somewhere. I found interesting sites, some helpful emails got here in, including correspondance with my daughter. The only model for this that I've discovered to be helpful is that of categorization. I was referring to storing solely the categorization info in the filesystem, not the remainder, and that simply being a mirroring. Another vast font of ineffective info thrown in your face. Nat Freidman at RealWorld Linux last year communicate on something related simply to repeat Scott right here: Beagle and this mission really aren't the identical sort of factor. A traditional Unix model filesystem is only one factor that you would make utilizing this sort of system, but way more could be potential. No joins, far less memory, and far more pace! Not to say that a wealthy filesystem plus a complicated code rights system (a la jail) will lead to a really secure, highly effective and stable system - way more abuse tolerant and versatile than has ever been generally out there ("Open all the attachments you need - they run fine, something they alter rolls again, and they can't ship Spam").