Arranjament del sistema->Avançat->Cerca a l’escriptori

Habilita el nepomuk/strigi.

Si et surt un error dient que l’strigi no es pot iniciar (pot tardar una estona):

Vas a la consola:

java -version

T’hauria de sortir “OpenJDK Runtime Environment” o “Sun Java Runtime Environment”

Si tens “OpenJDK Runtime Environment”:

-per a 32 bits:

sudo ln -s /usr/lib/jvm/java-6-openjdk/jre/lib/i386/server/libjvm.so /usr/lib/libjvm.so

-per a 64 bits

sudo ln -s /usr/lib/jvm/java-6-openjdk/jre/lib/amd64/server/libjvm.so /usr/lib/libjvm.so

Si tens “Sun Java Runtime Environment”:

-per a 32 bits

sudo ln -s /usr/lib/jvm/java-6-sun/jre/lib/i386/server/libjvm.so /usr/lib/libjvm.so

-per a 64 bits

sudo ln -s /usr/lib/jvm/java-6-sun/jre/lib/amd64/server/libjvm.so /usr/lib/libjvm.so

Today I’ve got really frustrated that I cannot search through my documents quickly and made a quick research to see why Strigi (which is an file indexing service) cannot be integrated with Nepomuk under my KDE 4.3 installation. I won’t go in details why it was not working but if you would like to make that integration you can read first that blog post which I found very useful:

Nepomuk + Strigi –> Resolving the mystery

With two words – there is a missing part which is responsible for the nepomuk->strigi integration and this is the soprano backend. Reading the instructions in the above blogpost I’ve just recompiled the rpm for the current 4.3 version of KDE.

So what you need to do is grab and install this package

#yum localinstall –nogpgcheck soprano-backend-sesame2-2.3.0-3.fc11.i386.rpm

#yum install strigi

After this – its up to you – Either reboot or relogin to your KDE session and you should see something like this:

So – fire up dolphin and start your search now!

No. It’s not the countdown for launch of my start-up, neither is countdown for start of a new TV game show.
4 days remain for the start of my semester exams and I still don’t know where my books are. (Do I have them?). “Ah, I’ll just read them from internet”, is how I try to console myself.
All these days I’ve been busy at maintaining mukt.in and tasted the pressure of lead responsibilities. Today, after lots of effort into writing our own forms, the attendee registration is up finally. (Yes, we chose not to use CMS even this time).
I would like to thank sivaji, kidfoo, deepsa, AJuOnLiNE and sanjayb for their efforts at it, while I was merely debugging stuff. (Ok, I know some names sound weird, but those are IRC handles)

I thought, “Atleast today I should sit and read something today”. I use my blackbeauty(PC) for reading for exams/e-books, coding for KDragons and on lappie its django, PHP, MySQL.
It almost skipped my mind that I had messed up my Desktop yesterday. KDE4’s plasma was crashing and I didn’t fix that yet. The problem was that widgets support isn’t really great on my build.
Here’s how my desktop looked yesterday – orkut album link
While most of the google search look-up’s and chat at #kde(freenode) suggested deleting plasma* from $KDEHOME/share/config, I figured out that moving plasma-appletsrc to something like plasma-appletsrc.old should do for me. Really no reason to delete plasmarc for my problem.

And this was not the end of issues. My downloads stopped due to insufficient disk space. What in the world could fill up my 45GB of /home?
A quick du -h showed me 31GB being consumed by .strigi folder in my home directory.
There were no options to disable strigi from my systems settings and I was not finding a clue whether this belongs to KDED services.
After lot of head scratching I found strigi-daemon running in my process table and it was eating away my resource like a glutton. (77% of CPU time!) No wonder why I felt KDE4 was being slow.
A small work around for this problem is ’sudo apt-get remove strigi-daemon’ and then delete all items from ~/.strigi/clucene
This seems to work fine, just that I don’t know the after-effects of reboot. Let’s wait and watch.

Oh by the way, would someone want to help me lose the habit of going to sleep at 5:00 am?
I’ve got exams from 18th, and all of them are at 10:00am. Time is ticking like always…

Fata se uita la pamant, sapa adanc, da de mormant. Buzele fetei sunt ascunse, Ea m-a calcat cand pamantul se rotise.

Intr-o stare cum n-am mai vazut,
ma simt usor, demuuult, pierdut…
Intr-o stare cum n-am mai simtit,
ma simt ca un nesimtit smintit.

Intr-o zi cu soare,
uit sa ma spal pe picioare.
Azi e cam innorat,
Picioarele nu-s de ignorat.

O talpa apasa pe cord,
talpa Ei nu e de-acord
Plimba degetele usor, usor…
Gura, de ce nu strigi dupa ajutor?!

{[(+)]}

Cuvant de intrare in confuz: fata. Cuvant de iesire din mica incurcatura: FAŢA.

Hurray… Now I can get in to KDE 4.0.0… What I did was.. I updated the online repositories using urpmi.update and installed the strigi libraries again. Then I try to start KDE 4… amazing…it just worked.

From the beginning itself, I used to check .xsession-errors* files in my home folder.. They used to complain about one strigi library named libstreamanalyzer0.so file.. some unknown symbol lookup error… Now everything seems to be fine .

Now is the time to get in to the new desktop mania which is at its childhood days. I want to explore it, test it and have to look for some bugs. Also have to think about various ways by which we can improve the user experience. Then have to submit bugs as well as suggestions to the core developers.

Day before yesterday I finished downloading KDE 4.0.0 Mandriva RPMs. After surviving many connection breakage issues on my internet connection, almost 3 partial days of downloading came to an end. Yesterday I installed it and try to start… disappointment… the strigi indexing engine having some problem to start which causes kde4init keep on failing. I tried a number of times, but all resulted same. From various online discussion forums I went to know that its due to some bug in strigi indexing library. I really want to make this first stable release of KDE 4 running so that I can test it properly and be the part of QA in the next stable release .

Let me see what can I hope for today.

Pur nella laboriosa quiete che contraddistingue il modo di operare degli sviluppatori KDE, sappiate che il lavoro su Strigi procede a gonfie vele.

Ce ne da notizia il “nostro” Flavio Castelli, che in un suo recente post ha segnalato l’interessante novità che riguarda il supporto a Xesam in Strigi.

Di Strigi ho scritto spesso: è l’indicizzatore e motore di ricerca ad alte prestazioni che fornisce una delle basi a Tenor Soprano (grazie per la “ripresa”) e tutto il framework di ricerca di KDE4, nelle parole degli sviluppatori è una estensione di Spotlight di Apple e il motore di ricerca di Google.

Xesam è uno sforzo non legato a Strigi in particolare, ma volto ad unificare il modo in cui differenti software analoghi a Strigi (es Tracker, il mio preferito per GNOME) possano essere utilizzati dalle stesse applicazioni. Un “linguaggio” studiato per poter effettuare ricerche come:

type:music tag:preferiti hendrix size>=5MB

Che restituirebbe tutti i file musicali che contengono la parola chiave “hendrix”, il tag “preferiti” e maggiori di 5 MB. Non male, eh?

Complimenti vivissimi a Flavio. So che c’entra solo in parte, ma le prove che ho effettuato con Dolphin + Nepomuk sono state semplicemente entusiasmanti e non vedo l’ora di “assaggiare” Strigi appieno! Continuo ad avere altissime speranze per questo KDE4

Tempo fa vi avevo segnalato un ottimo articolo a proposito di Nepomuk-KDE: “Nepomuk-KDE: il *vero* desktop semantico sarà KDE4” (lettura consigliatissima), oggi vi segnalo il seguito.

Liquidat ha scritto un nuovo capitolo della serie “desktop semantico”, aggiornandoci su cosa sia Soprano. In parole povere, Soprano è il “collante” che permetterà a tutto il desktop KDE4 di accedere alle informazioni raccolte tramite Strigi o KMetaData.

Si profila adesso questa situazione: due metodi per popolare l’indice dei metadati di KDE4, e un unico database centralizzato per accedervi a partire da qualsiasi applicazione.

• KMetaData lo si vede in funzione grazie a Dolphin, Digikam, Amarok e tutte le applicazioni capaci di applicare dei “tag” ai file, ossia metadati creati dall’utente per ogni file che si vuole etichettare in qualche modo specifico, ad esempio file più importanti o difficili da ritrovare.
• Strigi è invece indipendente dal lavoro dell’utente, si limita a collezionare quante più informazioni e metadati possibile per conto suo, senza che l’utente lo istruisca su cosa/come/quando immagazzinare dati. Un po’ quello che fa Tracker attualmente.
• Soprano è una libreria che fornisce un sistema unificato grazie al quale le applicazioni potranno accedere all’indice di metadati, secondo specifiche RDF.

Liquidat riporta un esempio pratico (ma è solo una bozza, niente di reale per adesso) di cosa tutto ciò potrebbe comportare:

Nell’immagine qui sopra potete ammirare qualcosa che al momento non esiste, ma che potrebbe essere implementata come conseguenza diretta delle potenzialità introdotte dalle novità segnalate in questo articolo. In questo caso le informazioni sul mittente di un messaggio email, contengono anche file connessi, persone che hanno a che fare con lui, eventuali tracce di scambi di documenti…

Beh, sembrerebbe interessante, e anche parecchio. Aspetto di vederlo realizzato (e già lo è, in parte) ma l’idea di fondo sembra ancora una volta incontrare le aspettative che avevo riposto in GNOME/Tracker. Al momento l’integrazione con Dolphin è già funzionante.

I complimenti a KDE si sprecano, e non solo per lo sbrilluccichìo dorato, vedete?

Qualcuno di voi mi ha fatto notare che ultimamente do molto peso alle vicende legate ad aspetti “frivoli” di KDE. È vero, dopo aver parlato di Strigi e il desktop semantico, del nuovo file manager, della razionalizzazione delle applicazioni, dei nuovi moduli di KDE4… ultimamente seguo molto di più l’evoluzione dell’impatto visivo di KDE4

Volete gradire?

Tornando alla notizia, vi chiederete cosa c’entri l’oro con KDE? C’entra eccome: da adesso potrebbe diventare il vostro colore preferito, oppure no, ma il punto non è questo. Il punto è che gli sviluppatori e gli artisti di Oxygen hanno fatto trapelare una piccola chicca che trovo molto interessante… e guarda caso, ha a che fare con l’oro:

Quella che vedete qui sopra è una rappresentazione dei quattro stati di un pulsante: normale, mouse sopra, premuto, selezionato. La prima parte interessante è l’abbandono (finalmente!) del blu/azzurrino. Non so quanto ho aspettato una mossa del genere, ho sempre detestato quella tonalità azzurra un po’ triste di KDE3 e sembra proprio che il team artistico non ne stia sbagliando una

Al posto dell’azzurro come tonalità di fondo adesso c’è una bella tonalità, che vedete nella piccola bozza qui sopra e che avrete probabilmente apprezzato in alcuni video passati (cfr. “KDE4: istantanea attuale del lavoro sul nuovo stile Oxygen“). Quello che inoltre hanno “osato” con un pizzico coraggio, devo dirlo, è stato individuare un colore “attivo” molto particolare: l’oro. Se anche non del tutto originale (vedi Enlightenment), l’idea di sfruttare un colore del genere è comunque coraggiosa.

Beh, come dicevate: sto seguendo molto le vicende legate all’impatto grafico di KDE4, ma dopotutto non capita così spesso che il team di Oxygen si riunisca per una tre-giorni di brainstorming… Se poi considerate che il team di Oxygen parla abbondantemente italiano con David Vignoni e Riccardo “ruphy” Iaconelli, non c’è molto da stupirsi che attragga la mia attenzione

Mentre passano i mesi aspettando che Tracker, Beagle, Xesam, Pinot e Vattelappesca vengano in qualche modo riconosciuti come la direzione da intraprendere per GNOME… il team di KDE procede a gonfie vele per creare quello di cui blatero da non so quanto tempo… il famigerato desktop semantico, secondo le specifiche Nepomuk.

Qui sopra vedete Dolphin, il futuro file manager di KDE4, che mostra la capacità di applicare giudizi (qui 4 su 5 stelle), commenti (testo libero) ed etichette (tag) ad ogni tipo di file, per poi poter all’occorrenza ritrovare con facilità ciò che si è contrassegnato. Leggo che si sta lavorando all’integrazione con Strigi e che questa funzionalità dovrebbe essere diffusa un po’ in ogni parte di KDE4.

[originale: liquidat]

Come al solito meno sbandierato e meno sensazionalista, il lavoro degli hacker di KDE continua senza sosta. Adesso è la volta di Strigi, il motore di indicizzazione e ricerca di KDE4 che starà alla base del “desktop semantico” Nepomuk per KDE.

La novità del giorno è che il codice di Strigi è stato spostato all’interno della directory kdesupport dell’svn di KDE.

Questa operazione, banale in sè, significa che da adesso Strigi è considerato un progetto su cui dipende parte di KDE stesso.

Ho spesso seguito le interessanti evoluzioni di Strigi in passato ed è uno dei “Progetti che seguo“, quindi trovate molte info nella categoria “Strigi“, ma se volete potete dare un occhio alla splendida presentazione fatta da Flavio Castelli, del team di Strigi, al FOSDEM di Bruxelles (abstract, pdf, odp). Sapevate che esiste perfino un handler di Strigi per la Deskbar di GNOME?

Prossimo passo sarà quello di cominciare ad integrare le funzionalità di Strigi direttamente nelle kdelibs. Non vediamo l’ora di provare qualcosa di usabile!

Complimenti!

In irc si vedono molte cose interessanti. Come lo scambio di opinioni e suggerimenti tra jammiecc e vandenoever su come abilitare uno standard tra i vari index, su come meglio implementare la ricerca per le wildcars e vari altri pensieri.

Questo è uno dei punti di forza dell’open-source. La voglia di fare le cose subito, e nel migliori dei modi, in maniera molto dinamica.

Mentre ardour2 compila io cerco di trovare un modo di installare il kernel a bassa latenza sulla edgy senza sputtanare tutto.

P.s.: Jamiecc –> main developer di Tracker . Vandenoever –> main developer di Strigi .

Quella che oggi vi consiglio caldamente di leggere è un’analisi condotta da Michal Pryc e Xusheng Hou, di Sun Ireland, sui principali strumenti di indicizzazione e ricerca desktop attualmente esistenti per GNU/Linux: Beagle, Jindex, Tracker e Strigi.

Di Beagle, Tracker e Strigi ho parlato in passato. Jindex è un nuovo software che è attualmente in sviluppo da Sun, e sospetto sia il motivo per cui è stato condotto questo studio: verificare come si colloca Jindex a confronto con le attuali soluzioni. Non ho mai nascosto la mia predilezione per Tracker, che sono contento abbia incontrato anche il favore di Ubuntu e sarà probabilmente adottato in Feisty e forse anche in GNOME 2.20

L’analisi, molto accurata, tiene conto di diversi fattori e si divide grossomodo due parti: prestazioni (velocità, utilizzo di RAM/CPU, consumo di risorse…) e funzionalità (tipi di file indicizzati, risultati trovati…). Le conclusioni sono abbastanza aperte e il test è stato condotto con il massimo dell’obiettività. Vi mostro qualche grafico saliente:

I tempi d’avvio dei quattro servizi: Beagle il più lento, Strigi il più veloce. Maluccio Tracker

L’uso in percentuale della CPU indicizzando file di testo. Strigi il più pesante, Jindex il più leggero. Anche qui, maluccio Tracker

L’uso di memoria. Malissimo Beagle e Jindex, che usano rispettivamente Mono e Java, ottime le prestazioni di Tracker e Strigi.

L’analisi, intitolata “Indexers comparison“, contiene molti più grafici e in realtà è un po’ lunghetta ma interessantissima: in ogni caso vi consiglio di leggerla! Qui ho inserito i grafici che bastonano maggiormente Tracker, per evidenziare le aree in cui deve essere migliorato, ma l’impressione è che tra i quattro sia il software che ha più potenzialità e meno impedimenti “gravi”. In conclusione dell’analisi i giudizi sui singoli progetti, li riporto più fedelmente possibile:

Beagle

PRO: progetto maturo e ben documentato, supporto a molti tipi mime, buona interfaccia grafica, stemming (riconosce parole simili)
CONTRO: elevato uso della CPU per file PDF, elevato uso della memoria, limite massimo di 100 risultati, linguaggio di programmazione (C#)

Tracker

PRO: ricerca tramite potenti script RDF, stemming (rinconosce parole simili), uso della memoria ridotto, API di ricerca comune con Strigi (in futuro)
CONTRO: uso della CPU elevato, problemi indicizzando molti txt, operatori di ricerca e caratteri speciali non supportati, ricerca RDF non documentate, niente ricerca avanzata nell’interfaccia

Strigi

PRO: usa “jstreams” di KDE, e non direttamente i file, questo permette di cercare dentro archivi compressi e cose simili, uso ridotto della memoria, tempi ridotti di indicizzazione, trova duplicati dei file,API di ricerca comune con Tracker (in futuro)
CONTRO: elevato uso della CPU per file PDF, lascia pdftotext “zombificato”, problemi con alcune ricerche e con maiuscole/minuscole, standard di ricerca, documentazione mancante, interfaccia disegnata male, codice non chiaramente ANSI C / POSIX

Le mie conclusioni? Ovviamente soggettive

Io non sono per niente oggettivo e non mi interessa fare paragoni equi, chi mi ha letto in passato sa che preferisco e supporto Tracker per tanti motivi, primo fra tutti la leggerezza, l’efficienza e il fatto che sia svincolato dal pesantissimo e poco efficiente Mono (“Niente fottutissimi .exe nella mia box!“), al contrario di Beagle.

Bene, dico solo che tutto sembra confermare la bontà di Tracker, e i contro che pesano sulla sua adozione si limitano ad un uso eccessivo della CPU, che confermo. Per il resto, in tutta l’analisi si nota la maturità di Beagle e delle caratteristiche che il progetto ha maturato, tanto da essere usato un po’ come punto di riferimento.

Beh, Tracker cresce a velocità incredibile, e il punto di riferimento Beagle resta tale solo per il supporto a più formati e alla maturità di un progetto sviluppato da anni. Per il resto ci stiamo avvicinando

In questi giorni di aKademy ci dovrebbero essere molti post interessanti nei blog degli sviluppatori di KDE, almeno per chi ha curiosità di sapere qualche anteprima sulla fantomatica quarta revisione del dekstop più diffuso per ambienti unix.

A dire il vero la nota mancanza di senso del marketing nel progetto KDE porta alla solita situazione in cui nonostante la mole impressionante di novità non trapela quasi nessuna notizia degna di nota.

Tra queste poche notizie ce n’è però una che ci interessa e che riguarda Strigi. Vi ricordate? Ne avevo scritto qualche tempo fa in questi vecchi post. Se non vi va di leggerli dico in sintesi che sarebbe l’equivalente di Beagle di GNOME, o secondo questa notizia …meglio, più come l’equivalente di Spotlight di Apple

Bene, vado alla notizia. Secondo quanto riportato dall’autore di Strigi, nella presentazione fatta ieri sono spuntate alcune succose novità che noi ci auguravamo speranzosi: Strigi dovrebbe diventare il motore di ricerca per Tenor di KDE4, se non sapete cosa è Tenor fate una ricerca all’interno di questo sito, ne abbiamo parlato in passato.

La spinta maggiore è arrivata dal nostro eroe personale Aaron Seigo, che ha suggerito che Strigi potrebbe essere usato direttamente da KMetaFileInfo per recuperare i metadati. Avete capito, questo significa integrare Strigi direttamente dentro il cuore di KDE! Esattamente quello che manca a Beagle/GNOME: integrazione.

Noi che abbiamo provato Strigi sappiamo che è veramente potente, e possiamo solo immaginare che nel frattempo stia continuando a migliorare. Dopo l’abbandono definitivo di Kat, che era una cosa più o meno simile sviluppata da un programmatore italiano di cui non si hanno più notizie, direi che Strigi è una delle migliori opportunità che siano capitate a KDE.

Inoltre ricordo a tutti che Strigi, come praticamente tutto KDE, è scritto in C++ quindi niente Mono (Beagle?) e niente questioni etiche e strani rimorsi… Aspettiamo con fiducia! Nel frattempo ecco il PDF della presentazione di Strigi all’aKademy.

Chiunque legga queste pagine anche saltuariamente si sarà accorto dell’attenzione che viene dedicata ai software che si occupano della nuova mania nei desktop del nuovo millennio: l’indicizzazione e la ricerca dei file presenti sui nostri PC.

Abbiamo più volte trattato di Beagle e di Strigi, sottolineando l’immaturità del secondo e lo spreco di risorse del primo. Oggi è la volta di Tracker, un software che stavolta è – come viene definito – “desktop neutral”. Ciò significa che idealmente non dovrebbe dipendere da GNOME o KDE, almeno questo vale per quanto riguarda il server che indicizza e cataloga silenziosamente i nostri dischi, mentre per adesso, a livello client è disponibile soltanto l’integrazione con Nautilus, ossia GNOME.

L’autore di Tracker ci segnala in questo post che la sua creatura comincia a ricevere l’attenzione di cui ha bisogno, e che ad esempio in questo post su ubuntuforums.org si è accesa un discussione a riguardo. Invece in questo articolo vengono resi disponibili dei pacchetti deb per debian / ubuntu di Tracker e di Nautilus modificato per interagire con Tracker!

Come potete vedere nello shot qui sopra… funziona! E anche bene

E’ velocissimo nell’indicizzare e nel ritrovare i file, una volta installati i pacchetti è bastato lanciare il server con (l’opzionale) percorso da indicizzare:

$: trackerd /usr/local/Dati

Aspettare qualche minuto, riavviare nautilus, premere Ctrl-F sul desktop e cercare una parola chiave a caso. Adesso credo che per un po’ userò Tracker per vedere come si comporta a lungo andare, e se continua a funzionare bene ed esiste un modo per fare collaborare Tracker e Deskbar elimino Beagle una buona volta

Aggiornamento! Ecco già un plugin (handler) per fare comunicare Deskbar e Tracker, wow! Eccolo qui: http://mail.gnome.org/archives/track…/msg00000.html Non funziona ancora benissimo ma continuo a stupirmi della reattività del popolo OSS!

Di Strigi ne abbiamo parlato in questo post in cui ero un po’ scettico sulle mirabolanti qualità di questo nuovo “sostituto di beagle” per KDE.

Beh ho installato il “demone” e con sorpresa ho dovuto ammettere che funziona! e pure bene… cosa che a distanza di parecchi mesi di sviluppo e di dollari investiti non si può dire di beagle. Pure essendo in fare pre-pre-pre-alpha il softwre funziona alla perfezione, e soprattutto senza toccare minimamente la linea di comando!

Il comodo frontend Qt4, è lo stesso che vedete qui a sinistra, serve sia a configurare che a lanciare il demone, e inoltre funziona da client per cercare semplici stringhe. Non è elegante e anzi non è nemmeno bello, ma funziona come “proof-of-concept” e questo ci riempie di speranza per le sorti di KDE4 e il suo motore di ricerca “Tenor”, che sembrava non voler decollare dopo le prime promesse scintillanti.

Eccovi i pacchetti pronti per essere installati sulla vostra Kubuntu, occhio che le dipendenze ve le dovete sviluppare voi… vi anticipo che servono libqt4, libmagik, openssl

Ho più volte scritto – in maniera contraddittoria – di beagle e della sua integrazione con GNOME. Non sono arrivato ad una decisione chiara, ma ammetto che sto usando beagle sul mio OS, con la comodissima integrazione con nautilus e soprattutto deskbar. Bene, questo post è dedicato a KDE quindi basta GNOME

I molteplici problemi di beagle, ossia lentezza, uso assurdo di risorse e instabilità, sembrerebbero risolti con Strigi, una nuova “mini-suite” di applicazioni, composta da demone + applet, che dovrebbe svolgere il compito di catalogare indicizzare e ricercare i documenti sparsi per i nostri PC. Perché mai Strigi dovrebbe aver risolto i problemi che invece affliggono beagle? Poche semplici ragioni:

• Strigi non usa Mono, ma C++ e non voglio aggiungere altro
• Al momento Strigi si appoggia a clucene con alcune modifiche per fare il lavoro sporco, ma è in corso l’aggiunta del supporto ad altri “motori. Beagle usa clucene “liscio”
• Strigi usa i kio-file di KDE, che sono sicuramente un gradino più in alto di gnome-vfs
• L’architettura prevista è completamente modulare, ogni plugin fornirà una funzionalità
• Strigi calcola un “hash” per ogni file, così sarà semplice trovare duplicati!

L’autore del progetto riporta che Strigi non occupa selvaggiamente RAM e CPU mentre svolge le sue funzioni, e soprattutto che – a suo dire – fa il suo lavoro di indicizzazione in modo molto più veloce di beagle. Al momento non ho una distro con KDE installato, ma la prima cosa che farei sarebbe provare a installarlo e verificare personalmente

Colgo l’occasione per ricordare che i precedenti tentativi di fare una cosa del genere sembrano essere falliti o finiti nel nulla: Kat è rimasto ad una versione stabile di qualche tempo fa, dopo che lo sviluppatore principale, l’itailano Roberto Cappuccio, è sparito. Nessuna notizia per Tenor quindi, il “desktop search” che si basava su Kat.

Speriamo che Strigi riesca a creare attorno a se un po’ di attenzione e magari attiri un po’ di sviluppatori. Da questo potrebbe dipendere il futuro di una delle idee più interessanti che stanno alla base di KDE4!