Beagle moc, locate málo?

5.1.2007 19:49 | Přečteno: 1856× | Linux | | poslední úprava: 5.1.2007 19:50

Rádi byste chtěli něco podobného, jako mají uživatelé MacOS nebo Visty, tedy rychlé prohledávání metadat? V Linuxu sice existují nástroje, například Beagle, jenže to je žrout prostředků napsaný v jazyce C#. A projekt Kat je mrtvý. Co teď?

Tracker je šikovný malý démonek, který docela rychle umí indexovat mnoho obsahu. Je napsán v jazyce C a sám o sobě zná mnoho formátů, namátkou HTML, PDF, PS, OLE2 (DOC, XLS, PPT), OpenOffice (sxw/odt), StarOffice (sdw), DVI, MAN, MP3, OGG, EXIF, JPEG, GIF, ZIP a další. Dále umí číst přímo z API rozhraní mailových klientů KMail, Evolution a Thunderbird. Navíc se umí napojit na kdovíjaké D-BUSy a hlídat změny v souborech.

Tracker má dobrý UNIXový návrh (démon, utility, GUI, knihovna) a má opravdu fajnový footprint (autor uvádí 4 MB v klidovém stavu). Zdrojáky jsou v dobrém stavu, program prodělává bouřlivý vývoj, ale směřuje to už od začátku správně. Všechny potřebné knihovny jsou součástí balíku, žádné velké závislosti se nekonají.

Také proto, že pokud si s nějakým formátem Tracker neví rady, pustí na to utilitu, která to odedře za něj. A to je myslím správné -- tak například PDFka zpracovává pdftotext, na DOCy zase antiword. Je zbytečné snažit se naprogramovat tucty modulů, které by to stejnak asi nedělaly tak dobře, jako ten nejlepší dostupný program v Linuxu. Program samotný umí číst jen OpenOffice.org soubory, HTML/XML a metainformace z datových souborů (MP3, videa, obrázky).

Indexace probíhá přímo bleskově, vyhledávání je okamžité. K dispozici je také nějaké GUI, to jsem ale neinstaloval (stačí mi řádkový klient, jinak kdyby vás to zajímalo, je postaven na GNOME knihovnách). A existuje i jakási nadstavba pro Nautilus. Ten také nepoužívám, ale vsadím pět dukátů, že je skvělá. Stejně jako nadstavba pro Deskbar.

Co se týče kvality samotného indexátoru, musím jej pochválit. Přítomna je "lámací" knihovna doktora Portera (stemming algoritmy pro mnoho jazyků -- češtinu nehledejte, je to nestemovatelný jazyk). Stoplisty program zná taky, lze také nakonfigurovat omezení pro délku slov. Program předpokládá kódování UTF-8 u textových souborů, co se týče dokumentů (DOC, ODT), tak tam je za převedení do UTF-8 textu zodpovědný delegovaný program.

Všechno ten malý ďáblík strká do ~/.Tracker, používá jakousi kombinaci binárních souborů a SQLite3 databáze. Celý index měl na mém stroji necelých 20 MB. Ve stejném adresáři najdete konfigurační soubor, ve kterém specifikujete jazyk, další adresáře pro indexaci, spojení s poštovními klienty a mnoho jiných užitečných parametrů.

Tracker nabízí velmi zajímavou vlastnost -- tagování. Pomocí příkazu tracker-tag můžete přidávat souborům metainformace, které vám pak pomohou data zařadit.

Jako hlavní nevýhodu vidím to, že program ignoruje přípony, které nezná. Například historie klienta PSI mají připonu .history, budu se muset podívat na způsob, jakým donutit Tracker, aby četl i soubory tohoto typu (nejlépe jen v daném adresáři -- zde v ~/.psi/*/history).

Projekt je zatím řekněme v beta stádiu, ale je dobře použitelný. Při prvotní indexaci jsem zaznamenal asi v polovině citelné zpomalení při indexaci mých zdrojových souborů (je jich hodně), takže jsem démona zastavil, poté znovu spustil. Zřejmě se z toho otřepal a dokončil indexaci ve standardní rychlosti (disk skoro nestíhá). Za 10 minut nebylo co řešit (mám asi 2 GB "smysluplných" dat -- dokumenty, zdrojáky atd).

Jistě, není to asi tak pohodlné, GUI mi nezobrazí náhledy na dokumenty nebo snad kontexty textu, ale kdoví, kam se tenhle projekt za rok posune... Šuškanda -- bude v GNOME 2.18.

Ukázka sezení

lzap@teevee:~$ tracker-stats

-------fetching index stats---------

Videos : 10
Text Files : 334
Other Files : 502
Documents : 632
Images : 1167
Folders : 1749
Development Files : 1820
Total files indexed : 6214
------------------------------------

lzap@teevee:~$ tracker-search qwertzuiop

lzap@teevee:~$ echo "qwertzuiop" > test.txt

lzap@teevee:~$ tracker-search qwertzuiop
/home/lzap/test.txt

lzap@teevee:~$ tracker-tag -a hohohoo test.txt

lzap@teevee:~$ tracker-search hohohoo
/home/lzap/test.txt

lzap@teevee:~$ tracker-tag
hohohoo : 1
testing : 1

lzap@teevee:~$ rm test.txt

lzap@teevee:~$ tracker-search qwertzuiop

lzap@teevee:~$

Odkazy

Home page
Článek na osobním blogu
Článek na portále LinuxEXPRES        

Komentáře

[Michal Karas]

Mno, ja nevim. Takovehle nastroje jsem nikdy nepouzival a ani necitim potrebu na tom neco menit. I kdyz je zase pravda, ze jsem asi vyjimka v tom, ze krom adresare ~/tmp/ mam v datech poradek a presne vim, kde co je. Jake veci pomoci toho napriklad vyhledavas?

Jinak zapisek moc pekny.

[Michal Kubeček]

Já pořádek moc nemám, ale zastávám názor, že (a) inteligent zvládá chaos, (b) find je find… :-)

[Käyttäjä 11133]

Držím se (a)

[Jiří (BoodOk) Kadeřávek]

Co takhle firemní datové sklady. Tam je to na jednoho vždy moc a i Beagle je k nezaplacení.

[Michal Karas]

Na tohle se spis pouzivaji databaze, ne? Ale nevim, o tomhle tematu jsem cetl snad jen jeden clanecek... Spise me ale zajimalo nejake beznejsi, desktopove, pouziti. Datove sklady, data mining a podobne veci mi uz pripadaji jako docela profi zalezitost.

Ale vicemene mi odpovedel xvasek nize. Takze uznavam, ze nejaky ten Beagle/Tracker hodne pomuze, pokud musi clovek pracovat s daty ostatnich (tedy asi hlavne to firemni prostredi).

[Lukáš Zapletal]

Datový sklad je trochu obecný pojem a ve smyslu data miningu to je skutečně něco jiného.

[Jiří (BoodOk) Kadeřávek]

1) Zužovat pojem datový sklad na databáze je sice možné, ale dosti omezující. Já ten pojem chápu podle toho co vyjadřuje v českém jazyce. Totiž prostor, kde se skladují data, a to v libovolné formě a uspořádání.

2) Pokud se bez databází neobejdete, pak věřte, že Beagle, Spotlight apod. se bez ní taktéž neobejdou a dokonce ji sami vytvářejí. Téměř by se dalo říci, že provádějí data mining

[xvasek]

Já bych to tady rozdělil na dvě oblasti - zaprvé lidi, co se snaží mít v datech pořádek a za druhé lidi, kterým je pořádek cizí.

První skupina by potřebovala spíše nějaký databázový filesystém, kde je možno mít jeden dokument na více místech, nejlépe automaticky. Například "Implementační smlouva" je stejně dobře součástí výběrového řízení i implementace samotné, takže není úplně zřejmé, kam ji umístit - nehledě na to, že můžu z fleku vymyslet další tři adresáře, kde bych ji chtěl mít taky. Bez ohledu na to, jak jsem moc pořádkumilovný, tato situace nemá bez nějakého symlinku řešení. Databázový filesystém by v mé představě řešil tento problém automaticky a umístil by implementační smlouvu všude tam, kde je relevantní.

Druhá skupina (bordeláři, kam spadám třeba i já) se potřebuje rychle dostat k datům. Ono je totž z tohoto pohledu veškeré úsilí na systematizaci dat zbytečné, pokud mám efektivní způsob přístupu k dokumentu, což nemusí obecně znamenat jenom hledání. Osobně si myslím, že ukládání všech dokumentů do jednoho adresáře není (až na přístupová práva v multiuživatelském prostředí) zase až tak špatný nápad, protože vždycky vím, kde daný dokument je. Pokud se k němu navíc dostnu pomocí nějakého nástroje rychle, tak můžou jít všichni "pořádkoví fašisté" do háje (což si rozhodně neber osobně :).

V praxi je pak potřeba obojí cesta, tzn. například ve firemním prostředí je typicky spousta uživatelů pořádných a spousta chaotiků, ale já bych samozřejmě chtěl pro přístup k datům jeden nástroj. Pak je tady to různé vyhledávací nářadí velmi robstním kompromisem.

Každopádně díky původnímu autorovi za fajn čtení.

[Michal Karas]

Ja uz si ani moc nedokazu predstavit, jak si v domovskem adresari ten bordel vytvorit. Proste mi to prijde automaticke, ze kdyz mam napriklad nejake video, tak ho plesknu nekam do adresare multimedia/video. Je to film, tak pujde mezi filmy, prednaska do adresare prislusneho predmetu v prednaskach a nejaky kratky vtipny filmecek hezky do adresare zabava. Hotovo, rozdeleno, nijak slozite to myslim neni a navic si tim usetrim spoustu problemu s hledanim.

Mimoto si myslim, ze prave tenhle zpusob systematizace je i docela efektivni pri dostavani se k datum pri praci v terminalu. Pomoci automatickeho doplnovani se da rychle dostat kam clovek potrebuje a kdyz do toho tabulatoru bouchne dvakrat, tak se v tom i rychle zorientuje (opravdu nemam rad scrollovani po vypisu a hledani neceho na vic jak dvou obrazovkach). A prinasi to vyhody i jinde. Napriklad si nemusim neustale stezovat na GtkFileChooser jako Michal Kubecek, protoze zmacknu CTRL+L a uz je to stejne jako v shellu. :-P (Ale uznavam, ze by to opravdu chtelo moznost mit tento dialog implicitne rozbaleny.)

Ale poradkovy fasista opravdu nejsem. Kazdy at si to dela tak jak chce. I kdyz priznavam, ze kamarad Windowsak, ktery ma vse na plose (a kdyz uz se neco nevejde, tak to dale rozhazuje nejlepe do slozek jako "1", "2", "blabla"), me opravdu dokaze pekne pobavit, kdyz neco hleda.

[Michal Kubeček]

Ja uz si ani moc nedokazu predstavit, jak si v domovskem adresari ten bordel vytvorit. Proste mi to prijde automaticke, ze kdyz mam napriklad nejake video, tak ho plesknu nekam do adresare multimedia/video. Je to film, tak pujde mezi filmy, prednaska do adresare prislusneho predmetu v prednaskach a nejaky kratky vtipny filmecek hezky do adresare zabava. Hotovo, rozdeleno, nijak slozite to myslim neni a navic si tim usetrim spoustu problemu s hledanim.

Já vám to ani nemůžu mít za zlé, protože přesně takhle jsem si to také kdysi představoval. Jenže když pak množství těch souborů po letech poněkud naroste, přestane to být tak jednoduché. Buď totiž budete mít v příslušném adresáři těch souborů několik set (a pak začnou mít nejen Gtk, ale i Qt filepickery značné problémy) nebo těch adresářů bude trochu víc. Jen pro představu, právě jsem si to nechal spočítat a pod svým domácím adresářem mám 35094 adresářů a 389629 souborů. Když vynechám ~/source, klesne počet v obou případech asi na třetinu, ale i tak je to pořád příliš mnoho na to, aby fungoval tak jednoduchý systém, jak jste tu nastínil.

[Michal Karas]

Já doufám, že do takových problému se dostanu až za hóóódně dlouhou dobu (a v lepším případě nikdy). Ale připadá mi, že velké množství adresářů/souborů je problém vždycky a moc si s ním neporádí ani vyhledávání v již zindexovaných datech.

[xvasek]

Kdo měl někdy Palm, ten si musel na "efektivitu" adresářů vytvořit názor. Adresáře tam prostě nejsou a přístup k datům je (troufám si tvrdit) opravdu efektivnější. Řešení Palmu není sice zrovna vzorem škálovatelnosti, ale minimálně námět k zamyšlení je to aspoň pro mě silný. Dalším příkladem budiž Google, který taky informace netřídí do nějakých adresářů. A pak třeba Gmail...

[Josef Kufner]

Záleží na povaze dat. Na PIM jsou adresáře hodně nešikovné, ale třeba pro software je to celkem fajn.

IMHO by nemusel být moc velký problém vytvořit s pomocí fuse a mysql nějaký virtuální filesystém, který by splňoval i ty nejzvrhlejší požadavky a přitom se vzhledem ke zbytku systému a dat choval celkem slušně – jen takový divný adresář ~/data.

[Kyosuke]

Fuj, proč zrovna MySQL? Taková mamutí závislost pro něco principielně velmi jednoduchého?

[Michal Kubeček]

První skupina by potřebovala spíše nějaký databázový filesystém, kde je možno mít jeden dokument na více místech, nejlépe automaticky. Například "Implementační smlouva" je stejně dobře součástí výběrového řízení i implementace samotné, takže není úplně zřejmé, kam ji umístit - nehledě na to, že můžu z fleku vymyslet další tři adresáře, kde bych ji chtěl mít taky. Bez ohledu na to, jak jsem moc pořádkumilovný, tato situace nemá bez nějakého symlinku řešení.

Za prvé má řešení bez symlinku, konkrétně hardlink. Za druhé přesně tohle je důvod, proč byly linky obou druhů vymyšleny, tak nevím, proč pracně vymýšlet něco jiného.

[xvasek]

Protože linky nevznikají samy automaticky při uložení.

[Michal Kubeček]

Samy od sebe nevzniknou ani v databázi. Ale pokud mám soubor nalinkovaný ve třech adresářích a upravím jednu instanci, změna se projeví ve všech.

[xvasek]

Právěže by v databázovém FS měly vazby (aspoň podle Microsoftu) vznikat samy. Já jsem pro.

[Michal Kubeček]

Samy??? To jako systém sám pozná, jestli chci, aby to byl link nebo kopie? Zejména v souvislosti s Microsoftem taková představa zní až děsivě…

[xvasek]

Nepozná, nerozlišuje. Soubor by měl být něco jako hardlinkovaný, tedy na více místech. Pokud bych například nahrával fotky z foťáku, dostaly by se automaticky samy do adresářů (nebo jako tomu říkat) "obrázky", "fotky", "fotky z mého foťáku", "obrázky z ledna 2007" (popř. i podle exif informací), explicitně bych je pak přiřadil ještě například do "dovolená", "přátelé" a "osobní". Mazal bych pak buď jenom z jednoho "adresáře", nebo celý soubor dohromady. Vyhledávat by se pak mělo pomocí jednoho nebo více kritérií, tedy například "fotky", "osobní", "prosinec 2006". Jenom to Microsofti bohužel nedotáhli a možná ani nedotáhnou...

[Michal Kubeček]

Ale dotáhnou, odhadem tak rok poté, co se to objeví v nějakém *BSD… :-)

[xvasek]

:) No hlavně aby to bylo brzo v Linuxu.

[Jiří (BoodOk) Kadeřávek]

Adresáře jsou IMHO přežitek, resp. fyzicky vytvářené adresáře na disku. Adresář je právě tím jedním pohledem, jednou cestou k souboru. Proto by adresář měl být vlastností souboru, nikoliv soubor vlastností adresáře (jak to implementují současné filesystémy). To samozřejmě nevylučuje existenci jednoho implicitního adresáře a vícero virtuálních adresářů existujících jako stromová struktura zatříděných metadat. Tagovat, tagovat a ještě lépe automaticky tagovat Samozřejmě lze vše tohle pomocí hardlinků dosáhnout. Je na znalejších nechť posoudí zda je to ale ta nejefektivnější cesta. Pikantní bude až budeme jednou provádět ls nad souborem, abychom si vylistovali v jakých adresářích je zařazen

[xvasek]

Konečně spřízněná duše, chápající moje alternativní myšlení v tomto masovou kulturou řízeném světě...

[Michal Vyskočil]

Vypadá hezky, akorát netuším, proč je to závislé na Gnome, když je afaik (až na GUI) k ničemu nepotřebuje. Škoda, že vývojáři KDE/Gnome jsou tak egocentričtí* a nedokáží užitečné nápady přetavit ve společně používané knihovny ...

* vhodnější slovo mě nenapadlo

[Marián Kyral]

No tak to nainstaluj bez gnome

# echo "app-misc/tracker -gnome" >>/etc/portage/package.use
# emerge -av tracker

Tohle bude spíše problém tvé distribuce, že z toho neudělají dva balíčky. Za to nikdo z Gnome ani KDE nemůže

[Michal Vyskočil]

Já to instalovat nezkoušel, jen jsem tiše předpokládal, že když jde o Gnome projekt (a v blogpostu je závislost uvedena), tak na něm záviset bude.

[Käyttäjä 11133]

Všechny potřebné knihovny jsou součástí balíku, žádné velké závislosti se nekonají.

[Botanicus2]

Hehe, gentooisti aby se neozvali...neboj, treba nas skvely arch to muze v poho delat taky :)

[Lukáš Zapletal]

Na GNOME je závislá jen ta GUI aplikace.

[Michal Vyskočil]

Jo, už mi to došlo.

[Marián Kyral]

Vypadá to pěkně, ještě nějaké gui pro KDE a jdu do toho

[Marián Kyral]

Tak vida, něco jsem dokonce i našel: [Meta] Tracker frontend

No raději to nechám na ráno...

[Lukáš Zapletal]

No ale to je jen Kommander skript... Asi by to chtělo applet

[kotyz]

kfind a locate ruluje. a taky pomaha mit veci smysluplne pojmenovany a rozstrkany po adresarich podle druhu. pak se ani moc hledat nemusi protoze clovek vi kde co ma ...

a beagle byla vzdycky prvni vec co sem zastavoval a odinstalovaval (jakoz i jiny indexovaci nastroje - treba kat). akorat to zpomalovalo ...

zase na druhou stranu, podari-li z toho udelat rychlej, lehkej a presto schopnej program a bude k tomu gui v qt nebo primo kde, tak by to za hrich jiste stalo. precijen clovek je linej a nechce se mu prolyzat tech par adresaru ... plus naka ta statistika kde mam kolik souboru jakyho druhu a jak sou asi velky a stary - to se taky hodi

[Martin Stiborský]

Pěkná věcička akorát mě neposlouchá :( spustím trackerd, proběhne indexace a program vypíše že čeká na další události, vytvořím tedy nějaký soubor, trackerd ho logne, všechno ok .. akorát když se pokusím o tracker-search nebo stats, dostanu error o nemožností spojit se s démonem .. :(

[Lukáš Zapletal]

Nespouštějte search pod rootem.

[Martin Stiborský]

Nene, to nedělám ..

[Lukáš Zapletal]

Tak potom je pod rootem spuštěnej trackerd ne? Měl jsem přesný problém...

[Martin Stiborský]

ne..obojí jsem určitě zkoušel pod normálním, svým userem ..

[Martin Lebeda]

řešení (pokud máte stejný problém) jsem našel tady: http://jamiemcc.livejournal.com/5630.html?thread=57342

Stručně - musí být před spuštěním démona i klienta spuštěn dbus. Tj. spustit dbus-launch a ty dvě proměnné co vyplivne nastavit do prostředí a teprve potom začít spouštět trackerd a klienty. Pak mi to začalo fungovat.

[Martin Stiborský]

Zkusím .. jenom jediný dotaz, kam nastavit proměnné co vyplivnul dbus ?

[Mikos]

Musí být nastavené jako proměnné prostředí, tzn. můžete použít např. tento skript:

if test -z "$DBUS_SESSION_BUS_ADDRESS" ; then
    # if not found, launch a new one
    eval `dbus-launch --sh-syntax --exit-with-session`
fi

Pokud používáte KDE spolu s KDM (či jiným display managerem), tak ho přidejte do adresáře /opt/kde/env (případně ~/.kde/env) a učiňte spustitelným (chmod +x nazev_skriptu). Pokud nepoužíváte žádný display manager (Xka spouštíte z konzole pomocí startx), tak by možná mohlo stačit přidat ten skript do vašeho ~/.bashrc. Je prostě potřeba aby ty proměnné prostředí byly nastavené ještě před startem vašeho prostředí. Spustíte li ten skript až z Xek, je už pozdě, protože ostatní spouštěné programy ty proměnné neuvidí.

[Martin Stiborský]

Paráda, funguje, dík moc .. skript už sedí x .bashrc, trackerd v .xinitrc .. spokojenost ..

[Mikos]

Tracker není jediný z dobrých indexovacích systemů - IMHO ještě lepší (a snad i rychlejší co jsem tak četl) je Strigi. Navíc má z mého pohledu tu výhodu, že její vývoj je KDE-centrický a dost možná bude součástí KDE 4.

[Martin Lebeda]

Já raději Hyper Estraier (http://hyperestraier.sourceforge.net/). Také jej používám na příkazovém řádku, nikoliv přez webové rozhranní .