Su Beagle, Tracker, la luccicanza¹ …e Strigi
In News e altre Sciccherie il 22/05/07 @ 14:04 , trackback
Loading ...
Era un po’ di tempo che volevo ribadire l’insensatezza di un confronto tra due software molto chiacchierati: Beagle e Tracker. Questo post di Michele Mattioni mi ha dato l’ispirazione a farlo, finalmente. Cercherò di riportare le cose su un piano moderato, visto che ultimamente percepisco aumentare la tensione tra chi sostiene Tracker e chi Beagle …come se si trattasse non di valutazioni su software, ma di tifo calcistico.
Beh, non che un po’ di tifo calcistico sia così male :)
Farò solo qualche piccola precisazione, e invito tutti a prendere le mie opinioni per quello che sono. Non ho mai detto che possiedo il vostro cervello e non ho mai tentato di convincere nessuno di niente, a dispetto di ciò che blatera qualche cerebroleso… altrimenti avrei cercato di convincervi a comprarmi un atollo nell’oceano indiano :D
Beagle, il segugio sovrappeso
Beagle è un semplice strumento per indicizzare/ricercare file di vario tipo, e dopo anni di sviluppo sovvenzionato da Novell non si può dire che il software sia del tutto maturo. In ogni caso fa il suo dovere, e ha raggiunto gli obiettivi principali che il team di sviluppatori si era prefisso o che il design del progetto suggerisce e permette. Niente più.
Ok, questo non è un segugio… e scommetto che non sa nemmeno cosa significhi indicizzare
Beagle serve a trovare i file, e in effetti funziona. Ciuccia un mare di RAM come tutte le applicazioni Mono, ma funziona. Lo ritengo amorale e pericoloso, ma funziona. (cfr. “Mono, come monopolio“). Se non vi fidate del mio giudizio negativo, sappiate che Fedora 7 non avrà Beagle proprio per i demeriti tecnici del relativamente maturo Beagle, lo apprendo proprio adesso dalla MessageBox (grazie gian!), mentre è risaputo che il team di Tracker sia in contatto con Ubuntu per provare ad integrare la tecnologia in maniera stabile in future versioni.
Tracker, la lente sfocata
Tracker è un progetto giovane che mira a fornire molto più che un banale strumento di ricerca. Potrà essere usato come software per indicizzare/ricercare file, alla stessa stregua di Beagle, ma l’obiettivo dichiarato fin da subito dagli sviluppatori è quello di creare un database centralizzato a cui si possa accedere da tutte le applicazioni e da ogni parte del desktop, e non solo per la ricerca di documenti.
Anche Tracker ha i suoi problemi, in fondo si tratta di software molto giovane
(Dopo aver messo insieme questa splendida immagine ho capito che io dovevo fare il grafico)
La giovane età del progetto si nota in varie imperfezioni nella ricerca e nell’uso di CPU/HD durante l’avvio e l’indicizzazione. Non credo di aver mai scritto che Tracker sia già perfetto, men che meno che sia più maturo di Beagle. Sarebbe una stupidaggine sostenere una cosa del genere, visto che Beagle è sostenuto da un’azienda che paga sviluppatori per implementare funzionalità mentre a Tracker lavorano pochi volontari, per giunta osteggiati dagli stessi sviluppatori GNOME.
Attualmente Tracker non restituisce fedelmente tutti i risultati che ci aspetteremmo, e alcune sue interfacce (es. Deskbar) non sono sempre in sincrono con lo sviluppo del “core”. Manca ancora una API che faciliti l’integrazione delle funzionalità di Tracker in GNOME e per quello si è scelto di aspettare che il progetto Xesam maturi. Nessuno ha mai nascosto questi piccoli difetti di gioventù di Tracker. Non io almeno, perché quello che mi piace di Tracker deve semplicemente ancora venire.
La luccicanza e altri fenomeni di ricerca paranormale
Tracker riprende vecchie idee che formano, insieme a nuove intuizioni, una visione di uno GNOME in cui un unico indice centralizzato è disponibile per tutte le applicazioni che abbiano bisogno di interagire con documenti di diverso tipo, consci del fatto che Tracker tratta ogni file in maniera adeguata, per cui un MP3 avrà metadati come “artista” e “titolo” mentre un JPEG avrà metadati “EXIF”, un video avrà lunghezza e risoluzione, eccetera.
Questo significa che potrò copiare una cartella piena di MP3 sul mio PC e, una volta lanciato Rhythmbox (o qualsiasi altro player), trovare tutti i nuovi brani già pronti, catalogati e ordinati per artista, titolo, traccia, bitrate, ecc direttamente dentro la collezione musicale, senza dover importare niente. E la stessa cosa varrebbe per tutti gli altri lettori multimediali, eliminando così la barbara abitudine di creare una “collezione musicale” ogni volta che si usa un lettore diverso.
Potrò scaricare decine di documenti, pdf, doc, xls e quant’altro nella mia cartella dei documenti, certo che qualsiasi applicazione ne sarebbe consapevole e avrebbe accesso diretto al database centralizzato di Tracker, che si aggiorna ogni volta che il kernel avverte un cambiamento nelle cartelle monitorate. Così OpenOffice.org Writer saprebbe cercarmi tutti i file doc scaricati giorno XYZ e contenenti la parola XYZ.
Potrò assegnare ad ogni file che meriti particolare attenzione, dei “tag” o “etichette”: delle parole chiave arbitrarie utili a ritrovare ciò che si cerca, concetto ormai familiare a tutti gli utenti del cosiddetto web 2.0. Inoltre, grazie a TrackerFS, potrei creare delle cartelle virtuali contenenti risultati di ricerca per “tag” o “etichette”. Immaginate una cartella virtuale che corrisponda al criterio di ricerca: “file Immagine in tutto il Sistema etichettati come Spiaggia“, sarebbe aggiornata ogni volta che scarichiamo, creiamo, importiamo una foto e le applichiamo quella etichetta.
Tutto ciò è possibile con Tracker e non con Beagle, perché il primo non dipende da Mono e voglio sperare che non si voglia fare dipendere tutto GNOME da funzionalità del genere.
Ok, e questo quando accadrà?
Perché questo (e molto, molto altro) accada, serve che Tracker maturi ancora e venga accettato come modulo di GNOME, con buona pace di tutti. Le divergenze, le lacune, le mancanze sarebbero sicuramente colmate in breve tempo. Tracker idealmente appartiene già a GNOME, e potrebbe renderlo un desktop ancora più grandioso di quello che è; ma finché GNOME non lo accetta non potrà integrarsi, e finché non potrà integrarsi difficilmente verrà accettato in GNOME… un classico.
Tracker ha dunque qualche fisiologico problema di gioventù, nessuno si è mai sognato di negarlo, qui su pollycoke o altrove, ma questo succede perché il progetto è giovane e ambizioso. Personalmente, come ho scritto altrove, amo i progetti ambiziosi. La differenza tra Tracker e Beagle è semplice:
Tracker mi regala una visione …quindi l0 uso, e con profitto (i difetti sono tanti ma sicuramente sopportabili).
Noi discutiamo pure…
Proprio mentre io scrivo so già che ci sarà qualcuno che dissente, che ci potrebbero essere risposte date da gente molto competente e che quanto scritto è potenzialmente materiale per discussioni, e non c’è assolutamente niente di male in questo. O almeno credo :)
Beh, mentre si discute c’è chi crea soluzioni a velocità incredibile, in maniera propositiva e pratica. Quello che Seth Nickell auspicava per GNOME con la sua impeccabile lungimiranza già anni fa (tanto, troppo tempo), sta succedendo proprio adesso in KDE. Strigi è entrato da qualche tempo già direttamente dentro le librerie di quello che sarà KDE 4 e questo significa che tutto il desktop avrà accesso al database centralizzato di Strigi.
In KDE si sta già attuando adesso quella che potrebbe essere la visione di un “Desktop Semantico”, quella stessa promessa da Tracker e già parzialmente mantenuta, almeno sulla carta, con KDE Nepomuk.
Non vedo nessuno raccogliere realmente la sfida dalla parte di GNOME, solo una serie di compromessi, discussioni, polemiche… e che fine ha fatto la luccicanza?
— Pagine forse correlate:
- KDE4: Video anteprima di Nepomuk e Dolphin
- Tracker, la presentazione al GUADEC [odp] + bonus API
- Tracker Desktop Search: sempre più efficiente
- KDE e il kernel Linux insieme
- Dopo Beagle e Strigi, ecco “Tracker”
- debug: Strigi Tracker Beagle KDE semantico luccicanza¹ Su Desktop
Commenti »
a me tracker funziona egregamente.. beagle non l ho mai provato, non ho metro di giudizio..
egregiamente *
E’ per questo che uso _ancora_ Beagle.
Quando verrà superato da un programma più maturo, allora sarò ben felice di eliminarlo.
Ma, fino a quel momento, ho bisogno di un indicizzatore _funzionale_.
MENOMONO RULEZ.
In effetti un software fatto bene per la condivisione dei metadati è la cosa fondamentale per fare il salto avanti.
il progetto Xesam ha come obbiettivo di creare questa libreria di accesso ai metadati in modo tale che tutti i programmi che vorranno accedere ad un determinato metadato utilizzeranno questa libreria.
Questo porterà alla possibilità di avere tutte le cose che felipe ha detto.
C’è parecchio movimento su questo fronte ed la cosa include gli sviluppatori di tutti i maggiori indicizzatori che sono presenti là fuori.
C’è un lavoro comune, all together. Non c’è nessuna contrapposizione. Quindi non facciamole. Teniamo i profili bassi e miglioriamo.
Io voglio un Desktop migliore. Tutto lì. :)
non è che poi dopo la luccicanza cominci a scrivere con la macchina da scrivere vero?? :-)
====== filipe ha scritto =======
Tutto ciò è possibile con Tracker e non con Beagle, perché il primo non dipende da Mono e voglio sperare che non si voglia fare dipendere tutto GNOME da funzionalità del genere.
=======================
NOn voglio a tornare al post precedente con commenti PRO/ VS mono, ma che c’entra il fatto ceh non lo faccia (perchè non è programmato per farlo) con il fatto che sia sviluppato con mono?
Vabbè, probailmente tu resterai del tuo parere, ma non vedo perchè ci si ostina a vedere il male in mono (anche se è solo una opinione).
@ Mavimo
Prova a togliere un banco di RAM dal tuo pc, avvia F-SPOT e poi riparliamo di mono.
(in simpatia) Ciao ;)
Il cane in foto non sa nemmeno cosa significhi movimento.
@ http://pollycoke.files.wordpress.com/2007/05/tracker-blur.png
LoL, potevi fare di meglio.
Mannaggialapupattola non ci va mai bene niente eh! Si dai, devi fare il grafico ;-)
Ah, per parlare del topic, io preferisco traker , ma ammetto che la mia è una posizione da tifo, pertanto non mi dilungo più di tanto…
beh un confronto non si può fare in quanto beagle è NETTAMENTE superiore a tracker…almeno per adesso.
tracker ciuccia molte più risorse di beagle(ma moooooolte) e vista “la giovane età del progetto” e tutti i difetti che ha, e cioè non indicizza e non ricerca bene, praticamente ora come ora non serve a un c*##o.l’unico vantaggio di tracker è di essere scritto in c quindi a margini di miglioramento infiniti ;D
ps
ma chi sono sti cerebrolesi?? ma non si era detto che qui non si offende?? o tu puoi o sommo felipe?
Il discorso di Felipe, che tra l’altro io condivido in pieno, è collegato ad un problema più ampio che secondo me è il “blocco del proogrammatore” degli sviluppatori di GNOME.
Ci sono molte idee nuove e molto promettenti che gravitano attorno al “piedone”, ma agli sviluppatori interni sembra non importare. Come traker, il menù unico “alla apple”, compiz e altri meno noti.
Mentre KDE avanza in direzioni condivisibili o meno, GNOME sembra stare fermo anche come prospettive future, non solo nel presente.
A mio parere prima si risolverà questo problema all’interno di team di GNOME e prima si potrà cominciare veramente a lavorare spediti verso queste direzioni assolutamente fondamentali per qualsiasi DE del futuro…
@ Felipe
Per scrivere con tanta attenzione verso i tuoi lettori, significa che c’è molta gente che ti vuole male, no?
Per usarlo l’ho usato, Tracker.
Ma continuo a credere che faccia veramente pena.
Si potrebbe replicare che è un prodotto giovane, per carità.
E’ anche vero però che è molto stagionato per potersi dire giovane. E’ stato riscritto N volte, ed ancora non ha una roadmap sensata.
E tutto ciò, inevitabilmente, si riperquote sulle sue caratteristiche, che lo rendono un prodotto davvero inutile. Fa indexing praticamente solo dei file su disco, che poi è anche il modo più inutile di usare un software del genere.
A parte essere programmato in un linguaggio diverso qual è la differenza tra Tracker e Beagle? Se non erro anke Beagle si propone ANCHE come aggregatore di Metadati. O sbaglio?
Ah, dimenticavo: non voglio passare per difensore di Beagle, preciso che al momento non uso nessun’indexer sul mio pc.
Tracker è osceno, e Beagle mi ciuccia troppa batteria quando funziona.
Insomma, nessuno dei due imho è adatto ad un uso serio.
OT
Povero cane! :-(
OT
Io ho provato tracker, ma come indicizzazione direi che non ci siamo.
Ho poi provato beagle, ma sul portatile cmq non è cosa, succhia troppa cpu.
Per cui, se devo cercare un file, uso il “classico” tool di gnome, che per ora ve benone.
1. elenchi come meriti di tracker praticamente tutto ciò che è il suo più grande difetto al momento e cioè la mancanza di un api decente per poterlo integrare in tutte le applicazioni di cui parli (player musicali eccetera)
2. chi ha detto che se beagle è basato su mono tutti i programmi che lo utilizzano debbano dipendere da mono? basterebbe un interfaccia basata su dbus..
3. in realtà la questione tracker beagle mi interessa davvero poco.. però secondo me in questo e in molti dei tuoi post entri in merito in questioni tecniche senza averne le competenze. (vedi tutte le critiche su mono, o le critiche a scelte coscienti degli sviluppatori di gnome)
Io sarei pro Tracker…. se funzionasse… ed è uno dei motivi per cui sono dovuto tornare a Beagle.
Le promesse saranno anche molte, e non discuto al buona volontà di chi ci sta dietro, ma quelli che vengono detti “problemi di gioventù” non sono piccole inezie…..
Un software di ricerca deve trovare i miei file,e se non lo fa, poco da dire, non funziona.
Non so se è una configurazione del mio portatile, ma tracker, in quanto sete di risorse, non invidia nulla a Beagle, anzi, a tratti parte una guerra tra lui e la mia ram, che vinco io con il kill process.
Concludendo:
Tracker ha le carte in regola per diventare un buon software, ma al momento attuale non lo è.
Beagle ha il podio più alto, a mio parere. Integrato e funzionale.
Strigi l’ho provato di sfuggita e , forse, da Gnome non ne ho colto i vantaggi, perchè non mi ha entusiasmato per nulla.
@ Mavimo
beh, la considerazione di felipe “perché il primo non dipende da Mono e voglio sperare che non si voglia fare dipendere tutto GNOME da funzionalità del genere” e’ abbastanza condivisibile, essendo Mono un framework osteggiato da alcuni e comunque molto di alto livello (lo stesso sarebbe valso per Java…).
Per quanto riguarda l’equazione Mono=evil, anch’io la vedo come te(in parte), ma solo per la parte NON coperta da brevetto: tutto ADO.NET e System.Windows non andrebbe affatto implementata nel progetto perche’ e’ solo un cavallo di troia di M$. dopotutto mono e’ GPL come linux.
find / -iname *cosa_cerchi*
Ma l’indicizzatore siamo sicuri che sia così utile?
La prima cosa che ho fatto quando ho cambiato pc qui in ufficio è stato disinstallare Google Desktop…
E di accrocchi simili non so cosa farmene nemmeno su Linux.
Alla organizzazione dei miei file ci penso io dividendo il tutto nelle directory apposite.
Vabbé che nei pc odierni c’è tanta ram inutilizzata, ma sprecarla così…
@giovanni recchia #8:
Purtropo di banchi ne ho solo 1 da 512, quindi se tolgo qullo il PC non parte ;)
SONO PERFETTAMENTE D’ACCORDO sul fatto che mono sia ESOSO DI RISORSE (ma in ogni caso meno di Java, per lo meno sul mio PC), quello che non capisco è questo accanimento.
@c1k0 #20:
Spè un moento.. io posso indicare come classe System.Windows.Forms e poi usarla tranquillamente, semplicemente come codice che uso sotto non è il codice che usa .NET, ma una implementazione della classe per avere gli stessi risultati (usando le GTK# per esempio).
In pratica si mantiene il nome delle classi e la struttura dei Namespace nel framework, e non si viola il codice che ci sta dentro. Una volto che espongo gli stessi metodi / proprietà /..dove sta il problema?
RIPETO: non voglio proseguire qui la conversazione su mono, quindi si può tranquillamente continuare nell’articolo originale.
@ Mavimo
il problema e’ che l’implementazione in Mono sarebbe ILLEGALE (almeno nei Paesi in cui i brevetti software hanno validita’), in quanto le tecnologie sono coperte da brevetti USA e soggetti al pagamento del pizzo.
usare DIRETTAMENTE gtk# invece e’ perfettamente legale
felipe un OT grande come una casa
mi serve una foto di tux con il basso a buona risoluzione, devo metterla sulla mia torta per i 18anni :D se ce l hai passamela in irc stasera, è importante >__>
@c1k0 #24:
Forse non mi sono spiegato, io come codice non tengo nula di quello MS, semplicemente chiamo un namespace System.Windows e ci aggiungo la classe Forms (che poi è renderizzata usando le GTK#). In pratica uso le GTK# mantenento il nome delle classi originali previste su .NET e in questo caso non credo, ma se mi sbaglio smentitemi, si possa parlare di violazione di brevetti. Se così dovesse essere Basterebbe lasciare il nome delle classi GTK# come sono ora (e se le classi sono complete basta un replace per avere cdice comunque compilabile).
A prescindere dall’utilità che si attribuisce ai motori di ricerca (Michele ha ragione, in effetti per ricercare contenuti in file di testo è sufficiente lanciare
find / -iname *nome_file_parziale* -exec grep testo_da_cercare {} \; da una shell) non capisco perchè questi debbano dipendere da librerie di front end grafico come gnome.
Politica a parte è antipatico anche *tecnicamente* che si dipenda da sistemi architetturali come MONO (o anche JAVA).
Per quanto riguarda l’adozione di un formato dato comune a tutte le applicazioni di front end, credo che non si raggiungerà mai.
ma sono l’unico che non usa nè beagle nè tracker e si affida solo ai comandi da shell (find/locate&c.) ?!?
Io uso Strigi e mi sembra funzioni abbastanza bene già ora e non vedo l’ora di vederlo in azione con KDE4.
Mi sa che tra i due litiganti il terzo se la gode parecchio.
Felipe, tempo fa si parlava di una sorta di convergenza tra tracker e strigi, se ne sa niente?
[@Felipe] Non voglio fare il saputello o altro, però, detto con molta tranquillità e nel rispetto di tutti, mi permetto (In caso cancella, no problem): attento a voler rimarcare ogni volta come dici le cose.. corri il rischio di ritrovarti a rispiegare sempre le solite cose alle solite persone, perdendo un sacco di tempo a ritritare cose che alcuni non digeriscono e forse non digeriranno mai (E annoiando chi s’è fatto il callo :p!). Tutto sommato sei abbastanza politically correct quando vuoi spiegarti il più possibile in modo ultra calmo, ultra pacato e ultra esemplificativo. Credo anche tu ci riesca.. però non puoi neanche rischiare di dover arrivare a dover fare i disegnini a chi non capisce come e perché dici le cose :D
GNOME deve pensare ad una API di indirezione verso il desktop semantico, poi sotto ci potrà stare quel che si vorrà, basterà avere i wrapper dedicati per ogni motore di indicizzazione !!!
che ne dite ?
@Mavimo
forse non sono stato chiaro io… il problema e’ che il brevetto copre l’IDEA e non l’implementazione. Tu puoi scrivere un wrapper che usi le API di Windows.Forms e le tramuti in GTK#, ma, a parte l’intrinseca difficolta’ della cosa visto che le classi Windows.forms sono create attorno a Win - quindo difficilmente tramutabili in chiamate crossplatform come gtk#; ma rischi comunque di essere trascinato in tribunale da MS perche’ hai usato un meccanismo troppo simile a quello usato da loro per fare la stessa cosa.
Dal sito di mono si legge:
“For people who need full compatibility with the Windows platform, Mono’s strategy for dealing with any potential issues that might arise with ASP.NET, ADO.NET or Windows.Forms is: (1) work around the patent by using a different implementation technique that retains the API, but changes the mechanism; if that is not possible, we would (2) remove the pieces of code that were covered by those patents, and also (3) find prior art that would render the patent useless.”
Vuol dire in soldoni: cercheremo di stare attenti a non implementare le classi con tecniche differenti da quelle di MS e se non ci riusciamo rimuoviamo le classi.
A me sembra un procedimento un po’ rischioso e che genera un prodotto zoppo. Molto meglio usare le solo GTK# e mandare affanc**o gli sgambetti made in Redmond. Diciamo che M$ e’ piu’ brava di noi in tribunale, non diamole l’occasione…
GNOME deve pensare ad una API di indirezione PER il desktop semantico, così poi sotto ci potrà stare quel che si vorrà, basterà avere i wrapper dedicati per ogni motore di indicizzazione !!!
che ne dite ?
Bhe, chi ha lanciato il progetto Mono è lo stesso che ha iniziato Gnome e che tuttora lo guida :D. L’idea è che programmare con Mono taglierà i tempi di sviluppo….
Strigi, Tracker e Beagle, ma perché tutta questa ridondanza di librerie e demoni, che sono progettati per fare la stessa cosa?
Non sarebbe interessante un unico progetto, condiviso da Gnome e KDE, magari sotto la bandiera di FreeDesktop?
Sinceramente speravo che freedesktop potesse portare più integrazione (e comunicazione) di base tra i due più grossi desktop manager.
Non ho competenza in merito e quindi le mie “fantasie” potrebbero essere fuori luogo, ma gradirei sentire il vostro parere.
Saluti,
Ale
Io voglio dire solo una cosa:
- se lascio il computer acceso senza fare niente beagle mi manda la cpu al 98% con ventola perennemente accesa;
- se lascio il computer acceso senza fare niente tracker non fa niente!
Ergo -> tracker è migliore di beagle!
API COMUNI, poi chissenefrega del motore !!!
KDE4 sta lavorando bene sotto questo aspetto con:
phonon e solid
così mettendo un livello di astrazione in più si possono permettere di transitare su qualsiasi engine
( in questo caso per il sistema audio e video e per la gestione hardware )
il trucco sarebbe questo anche per il desktop semantico !!!!
@Shinji01
sei sicuro ?
l’idea di far si di sfruttare i tempi morti del PC per indicizzare non mi sembra una cattiva idea !!
Blah, blah, blah … Ma chi è la tipa della foto O:-) ?
condivido gli ultimi commenti! GNOME dovrebbe collaborare con KDE e per prima cosa implementare le specifiche di NEPOMUK (che di per se non hanno niente a che vedere con KDE), poi è anche possibile integrare strigi in GNOME visto che comunque il core non è dipendente da KDE se non erro. in questo momento c’è solo bisogno di collaborazione e se GNOME si chiede cosa fare la risposta è collaborare, non creare innumerevoli progetti senza meta
Ciao,
io onestamente non intravedo la definizione di una visione / di un percorso futuro da intraprendere da parte del team di Gnome e questo sicuramente influisce sulla possibilità di un “desktop semantico” in cui Tracker sia integrato in Gnome e sia solo la parte di un progetto più ampio.
Da questo punto di vista vedo più avanti KDE con KDE4 (Strigi in questo caso, ma anche le altre librerie Phonon, Solid, ecc); forse non ancora molto avanti come righe di codice ma almeno una progettazione dell’impianto complessivo c’è.
@ Tobe Bofh
E la gui non serve che ai n00b :o)
serve, serve
e ci servirà (nel senso che farà cose per noi, non che ne abbiamo solo bisogno) sempre di più
@asbrubale
se fosse questo il motivo andrebbe bene!
Il problema che l’utilizzo della CPU è praticamente al massimo mentre l’hard disk non dà segni di vita, quindi dubito che beagle stia indicizzando!
Te lo dico perché era la stessa cosa che mi accadeva ai tempi in cui usavo windows… stava acceso senza fare nulla e la CPU schizzava al 100%! Poi basta spostare leggermente il mouse ed ecco che la CPU si calmava…
Ripeto… dubito che beagle stia indicizzando…
@asdrubale
“GNOME deve pensare ad una API di indirezione PER il desktop semantico, così poi sotto ci potrà stare quel che si vorrà, basterà avere i wrapper dedicati per ogni motore di indicizzazione !!!”
Ti quoto in pieno … piu’ che una api di traker serve una api di GNOME fatte di “interfacce” o “stub” che dir si voglia, insomma una specifica astratta che deve essere implementata da chi voglia interfacciare un motore di indicizzazione a gnome.
Per chi dice find e’ la stessa cosa … permettetemi ma e’ na grossa boiata, un conto e’ ricercare su indici gia’ costruiti una cosa e ricercare sui vari file, il fattore tempo e’ enorme.
La api a mio avviso dovrebbe poter gestire anche piu’ motori di indicizzazione, che so uno tramite traker o beagle per il disco, uno per open search uno per google ad esempio … insomma un unico punto a cui gnome chiede e chi si adegua risponde.
Ma c’e’ la volonta’ e la disponibilita’ di risorse per fare tutto cio’??
@c1k0 #31:
grazie per il chiarimento, a questo punto System.Windows -> Cestino e usiamo le GTK#, non per questo dobbiamo buttare tutto il resto (non è riferito a te, ma in generale).
@tutti:
Tornando IT, perchè freedesktop non crea delle specifiche per il tracking? che ne so, un aspecie di tabella per cui ID, Nome file (con percorso), Tipo di file (con un numero limitato di possibilità), parole chiave principali. altra tabella a cui i file con tipo = Music appartengono e campi Autore, Titolo, Album, Anno, … e così via.
A questo punto un motore (o più motori differenti) che inseriscono i dati nel DB così creato (SQLLIte) e poi chi vuoi può andare a prelevarsi le informazioni, quindi se KDE/GNOME/Altro vuole andare a usare i dati può farlo con ogni applicativo che vuole. Ovviamente non ci si basa su interfaccie grafiche, quindi chiunque può fare come vuole per visualizzare i dati (anche tramite GUI, ma non necessariamente).
Per quanto riguarda l’uso di find.. ma per piacere!!! volete mettere la velocità tra un DB e un find su i file? Per non parlare delle limitazioni che questo porta..
Una “sensazione”, che non ha nessuna pretesa di esser una verità: Gnome è impegnato in altre “faccende”, lontane anni~luce dall’uso desktop.
KDE4 “forse” (non usandolo, né seguendolo, ho solo informazioni di seconda mano..) sarà il DE più improntato al desktop.
XFCE non ho idea di cosa vogliano fare. Se anche lì Mono avrà un certo peso o no.Ad oggi, mi pare, è lo Gnome di un paio di anni fa.
Altri DE non ne conosco, ma mi paiono ben lontani dall’uso desktop (a prova di utonto).
La prospettiva, messa così (ripeto, non ho alcuna presunzione che sia la verità, ed invito chi “di dovere” a smentirmi..), è piuttosto magra.
Soprattutto confrontando altre innovazioni presenti altrove.
Resto in attesa, alquanto titubante.
Nel frattempo, me tapino, valuto la concorrenza.
Saluti.
ma in pratica quando esce KDE 4 si deve passare tutti di la :D?
tracker sarà anche figo, ma non indicizza una mazza. Almeno se cerco un file beagle lo trova, consumando, per inciso, la stessa ram del applet per regolare il volume.
Sarebbe una stupidaggine sostenere una cosa del genere, visto che Beagle è sostenuto da un’azienda che paga sviluppatori per implementare funzionalità
Questa è una balla: Novell paga una sola persona per lavorare su Beagle, vale a dire Joe Shaw. Tutto il resto del lavoro è fatto da volontari.
E vi pare poco?
Date un’occhiata alla mole di aggiornamenti per beagle e contro le 2 modifiche in croce che vengono fatte a tracker.
Sono d’accordo che è meglio scrivee in altri linguaggi un software importante come deve essere un indexer.
“Luccicanza”, idee, figate per tracker sono soltanto “aria fritta” dal momento che nessuno ci sta lavorando con il dovuto tempo/impegno.
Non ce ne facciamo niente delle promesse o degli “scenari futuri”.
E’ come se vi raccontassi che scriverò un Engine Gtk che cambia i colori a tempo di musica con bottoni e widgets animati. Finchè non scrivo una riga di codice è soltanto FUMO.
Tracker al momento è inutile oltre che controproducente, mi prosciuga la batteria del portatile visto che mi porta la CPU sempre a 100% per un indexing che beagle fa indolore, e per di più non svolge il compito per il quale è stato creato.
Ed il “MARE DI RAM CHE CIUCCIA” (citando l’articolo) sono quei 20 MB in più di tracker, che non fanno minimamente la differenza su 512-1024 MB medi… La ram non rallenta il computer, avere 200 mega liberi o 400 non fa rallentare manco una applicazione, E’ IL CONSUMO DELLA CPU CHE RALLENTA. E tracker rallenta…
Speriamo sì che questo Tracker superi Beagle, non vedo l’ora anche io che questo avvenga… E sarò il primo a togliere Beagle!
Ma ora usare Tracker è veramente ridicolo, perchè non serve a niente… piuttosto usate updatedb/locate :) ma per il resto… LOL.
perchè quando cerco un file mp3 con deskbar-beagle mi dice impossibile mostrare l’url??? e non mi apre niente
perchè è buggato l’handler di deskbar… va sistemato quel file, in locale avevo fatto delle modifiche ma non mi entusiasmavano anche se funzionavano
appena posso faccio un commit sull’svn
per cui me lo devo tenere così? i file mp3 sono la cose che cerco di + :(
[...] Su Beagle, Tracker, la luccicanza¹ …e Strigi Era un po’ di tempo che volevo ribadire l’insensatezza di un confronto tra due software molto […] [...]
ma certo che no!
Ecco il link alla patch: http://svn.gnome.org/viewcvs/deskbar-applet/trunk/deskbar/handlers/beagle-live.py?r1=1109&r2=1178
anzi non è ancora sufficiente perchè questo mi sa che non lo risolve…
@ felipe
mi spiace…. ma ha perfettamente ragione cimi #51… oggi non siamo d’accordo… capita ;)
@Cimi: E’ come se vi raccontassi che scriverò un Engine Gtk che cambia i colori a tempo di musica con bottoni e widgets animati. Finchè non scrivo una riga di codice è soltanto FUMO.
io questo lo voglio.
é truzzo e probabilemente non lo userei un secondo, ma tri prego fallo! (anche usando Mono se ti può essere utile)
concordo con cimi, già lo accennavo nel commento sopra, e nel mio blog.
Ha tutte le carte in regola per essere… ma ora non è…
(il soggetto era tracker, ovviamente….)
scusate il doppio post
ottimo articolo
aggiungo che kbfx ha gia’ un plugin che utilizza strigi..anche se piuttosto sperimentale
di default invece si puo’ gia’ trovare la strigi-applet..oltre ad un immancabile kio_slave per konqueror..;)
Ritengo che il problema non sia la ricerca di file in quanto tale… ma il modo in cui utilizziamo un tipico sistema desktop, l’indicizzazione automatica dei file utente e la possibilità di “taggarli” e/o catalogarli in vari modi, vista in un contesto Linux, prescinde dal DE utilizzato e se vogliamo essere pignoli, il tutto non si limita ai singoli file, ci sono bookmark, e-mail e appunti vari ralizzati con varie applicazioni.
Quindi IMO, Beagle e Tracker sono inadeguati, acerbi e poco funzionali, avidi di risorse e integrati malamente con gli altri programmi, purtroppo Cimi a più che ragione…
Strigi pare sulla buona strada, ma i problemi di totale trasparenza al DE rimangono.
Ritengo che Google stia lavorando a GoogleDesktop per Linux e stanno incontrando notevoli difficoltà…. che fare?
Purtroppo dopo la mia disquisizione devo ammettere candidamente che non ho nemmeno un abbozzo di soluzione, nel frattempo rimango fedele a find e locate…
[...] quello è stato il giorno che felipe ha linkato un mio articolo su [...]
Your comment box has unuseful labels for form elements.
When I click it, appropriate form element isn’t focused.
la mia idea…
io credo che il futuro sia un progetto tipo tracker ma che sia integrato nel FS…
un FS che abbia integrato una specie di database e che tutti i file in realtà sono soltanto record e che quindi tutto sia indicizzato di per se…
comunque tra i 2 quello che apprezzo di piu … anche solo per le ambizioni è tracker…