strigi 0.3.11

Синтаксис поискового запроса на скриншотах по ссылке просто великолепный! :)

>pluggable backend, currently clucene and hyperestraier, sqlite3 and xapian are in the works communication between daemon and search program over an abstract interface with two implementations: DBus and a simple unix socket.

а это что-то интересное, потому что пытавшийся написать хэндл к beage на лоре не смеется. Жалко, что оно на qt-dbus и все такое кдешное :)

И написан на нормальном (более нормлаьном, так скажем) языке.

это приятно, а то ставить моно только из-за beagle рука не подымается

Странно что его позиционирует как альтернатива beagle для KDE, а не как альтернатива Kat...

Насколько оно губительно для дисков в виду постоянной переиндексации базы?

Насколько я понимаю суть этого и подобных поисковиков, прежде чем что-то искать, надо перебрать все, что есть на диске (дисках). Правильно?

Развелось столько дерьма, что выход любой программы, написанной на C/C++ (а не на java/python или под mono) и не привязанной к gnome/kde откровенно радует.

locate

> написанной на C/C++ (а не на java/python или под mono)

Имеешь что-то против питона? Если да. то послушаю. Просто из любопытства. Не сочти за наезд.

>Странно что его позиционирует как альтернатива beagle для KDE, а не как альтернатива Kat...

ЕМНИП, kat уже не живой

Да, но часто они работают в режиме демона, и индексируют когда система не нагружена. Т.е. не обязательно специально отводить для этого время.

P.S. Прикольно, ~5Гиг pdf/html/doc/.... индексирует ~час, индекс - 200Мб

Там вроде-бы inotify используется => переиндексируется только то, что изменяется.

Так он что, только маски понимает? Тогда locate без вопросов

> Имеешь что-то против питона?

Ничего не имею, боже упаси. Имею против софта, на нам написанного.

>locate

Оно тексты в PDF ищет?

>Имею против софта, на нам написанного.

Что ты, скажем, в качестве альтернативы тому же gajim назовёшь? Psi малофункционален, SIM не умеет MUC, kopete дико тормозит с моими аккаунтами (4 аккаунта на 600+контактов), gaim - глючит и тоже тормозит, tkabber - я не в состоянии сделать у него приличный GUI...

kat похоже умер так и не научившись индексировать русскоязычные, например, документы, но:

> We'll try to reuse the kat plugins, although native plugins

кроме него на kde-apps.org есть интерфейс к биглу, но тянуть ~ 50 мб зависимостей ..

не исключено, кстати, что для бигла таки появится бэкэнд к strigi

У strigi с русскив все ок, нормально ищет.

локейт как уже заметили не полнотекстовый, даже если написать скрипт еще и парсящий файлы это будет намного дольше и менее удобно (т.е. индексирующие движки различают резльтаты например по почте, адресной, книге, документам и т. п.)

значит, будем надеятся, в КДЕ4 проблем с поисковиком не будет;)

>> locate

> Оно тексты в PDF ищет?

Там хотели ТруЪ. А кто хочет ТруЪ - тот теги и метаинформацию в название и путь впендюривает. Наверно.

Сначала прочитал как СТРИНГИ! Долго думал 0.3.11 - ето размер чтоль?

>А кто хочет ТруЪ - тот теги и метаинформацию в название и путь впендюривает.

А если мне слеш нужен в метатэгах? Например, с/х или к/ф? :)

А, вообще - маразм.

Блин, когда же появятся массовые DBFS?? Хочу иметь возможность "SELECT path, name WHERE mime_type RLIKE 'audio/.*' AND load+count=0 AND create_time > NOW()-86400*3"

И чтобы ответ, как и положено нормальной БД за 0.01 сек выдавался...

Тогда, кстати, и надобность в индексирующих поисковиках отпадёт как страшный сон. FULLTEXT индекс на контент файла - и опаньки :)

хахаха, centericq конечно :)))) или уж совсем труъ -- ysm.

Что хранить в БД? Например храним информацию по живописи. Что было файлами - поле изображения. А дальше - дата, художник, "типа стиль", местоположение. Если хранится информация (картина) - значит она нужна, значит и хранить надо не вторичную информацию "дата/художник/техника" а содержание.

А пока нет возможности хранить и работать с содержанием - простые файловые системы никуда не денутся. И такие индексаторы-поисковики будут очень полезныю

>Блин, когда же появятся массовые DBFS?? Хочу иметь возможность "SELECT path, name WHERE mime_type RLIKE 'audio/.*' AND load+count=0 AND create_time > NOW()-86400*3"

Новерное, когда kernel level sql engine напишут. К тму-же прикинь, сколько быдыт занимать полнотекстовые индексы на контекст всех файлов?

> Тогда, кстати, и надобность в индексирующих поисковиках отпадёт как страшный сон. FULLTEXT индекс на контент файла - и опаньки :)

А что мешает какую-нибудь виртуальную систему над PostgreSQL создать?

> не привязанной к gnome/kde откровенно радует.

recoll , фронтенд к какому-то Xapian http://sourceforge.net/projects/recoll

>К тму-же прикинь, сколько быдыт занимать полнотекстовые индексы на контекст всех файлов?

Мало. Несколько процентов от общего объёма текстов. Учитывая, что их объёмы итак невелики, это ж не музыка, не видео - копейки.

>А что мешает какую-нибудь виртуальную систему над PostgreSQL создать?

Это должна быть настоящая FS. Чтобы банальный mv из консоли не терял данные :)

Вообще, microsoft очень большую свинью подложила, убив WinFS. Теперь у линукса нет стимула к развитию DBFS :)

Все замечательно, но как подумаю что надо будет возле домашнего компа держать команду DBA ... по ночам просыпаюсь в холодном поту с криком "Мама!" ...

dbfsck тебе будет просто перестраивать все индексы с нуля, например :D В особо запущенных случаях. Ну а просто метаданные с файлами - это и сегодня FS умеют. И это никого не пугает.

Нет, ну правда, зачем гемороиться с привязкой тех же mime-types к расширению (а, может, не хочу я его), когда его можно сохранить в метатаг.

Rules, он ожил, и даже мой патч включили!

У них поддержка доп. типов файлов вообще легко пишется. На bash =) . По крайней мере так было раньше.

> kat похоже умер так и не научившись индексировать русскоязычные, например, документы, но:

Брехня! ODT прекрасно индексировал. :)

> Вообще, microsoft очень большую свинью подложила, убив WinFS. Теперь у линукса нет стимула к развитию DBFS :)

По текстовым данным поиск работает и так. А по всем остальным - системе придётся полагаться на тэги, назначенные пользователем. А основная проблема поиска файлов в том, что люди название файлам/каталогам придумать не могут, не то что тэги. То есть имеем ту же самую проблему, что и сейчас.

> А что мешает какую-нибудь виртуальную систему над PostgreSQL создать?

Ничего :) Есть и FUSE-модуль dbfs, и http://tech.inhelsinki.nl/dbfs/ :)

для хранилищ очень бы полезно конечно, но как / или /tmp, например, очень накладно, представь себе постоянные бд запросы на инсерты/делеты для сотен файлов, простые операции копирования для тысяч мелких файлов растянутся надолго и все это будет грузить именно ядро (т.е. все остальное) т.к. в отличии от висящего себе и втихушку индексирующего демона фс драйвер не может позволить себе сначала провернуть операцию с данными, а остальное отложить на потом (уж сколько проблем возникает при отключении sync для флешек. А M$ не сможет объяснить домохозяйкам, что под фотки/фильмы/книжки надо разметить раздел в винфс, а для Цэ: использовать старый нтфс, саппорт погибнет от нагрузки. Вот если пользователь находясь в зравом уме выделит раздельчик и начнет складывать туда только данные это, конечено совсем другое дело. Вобщем тут надо думать, а пользователи дружественных ОС это не умеют.

Можно например /home так хранить, но всеравно как-то плохо себе представляю совместимость такого хранилища с сегодняшним софтом.

у меня намного большье PDF'a и текстовых в разных кодировках, а если даже индексатору надо причесывать кодировки к одной какой-нибудь, то теряется то ради чего они и задуманы: лекгость и оперативность использования, тогда удобнее вести каталог с отображением в basket например.

у меня хоум только для конфигов (легче бэкапить), их индексировать незачем, все остальное вынесено на отдельную большую партицию (как-то пугает меня идея создания большого /home и хранения в нем видео, музыки и проч.) вот на нее и надо травить инексатор.

У меня так-же, но по причине dual-boot-а.

а qemu/cedega/wine не спасают от оффтопика:) ?

Не всегда =(

>Там хотели ТруЪ. А кто хочет ТруЪ - тот теги и метаинформацию в название и путь впендюривает. Наверно.

Тот кто реально ТруЪ, тот в название и путь впендюривает всё содержимое файла =)

Рейзер мечтал о том же самом, и рейзер4 по моему считал именно такой системой, к которой надо лишь плагины дописывать.

Ну или одним из важных этапов на пути к реализации такой системы

>Вообще, microsoft очень большую свинью подложила, убив WinFS. Теперь у линукса нет стимула к развитию DBFS :)

Я недавно читал, что Балмер говорил, что мы и сейчас работаем над этой системой, но будем ее включать только когда она будет готова.

В общем неясно, он это говорил только для того, чтобы спасти лицо, или реально работают.

Вообще не понимаю, почему бы не склепать тулзу в стиле slocate (или на базе оного) с аналогичной политикой хранения базы и секьюрностью.

Осталось добавить:
1. Индексирование содержимого
2. Поддержку inotify:
2.1. При изменении inode добавляем оный файл в очередь на переиндексирование (очередь хранится во внутреннем буфере демона).
2.2. По cron'у производим собственно переиндексирование путём посылки некоего сигнала демону.

В базе сохраняем пермишены, дабы юзер не искал, где ему не положено. Проверка пермишенов осуществляется утилитой поиска (как в случае со slocate, где проверка делается на уровне утилиты locate).

что по объему работ будет сравнимо с написанием нового;) + время на рабирательство в чужом коде (slocate разве на плюсах ? если нет то разработчики на C++ врядли захотят дописывать все на C) + затраты на борьбу с противниками изменений, которые обязтально найдутся в т.ч. среди разработчиков slocate

> тогда удобнее вести каталог с отображением в basket например.

За Basket - ЗАЧОТ! :)

>>Имею против софта, на нам написанного.

>Что ты, скажем, в качестве альтернативы тому же gajim назовёшь?

Я не об этом. Я об том что пионерия учит с горем пополам питон, у нее от счастья вылезают глаза, и оно начинает пихать его туда, куда не надо, в результате чего получается тормозное дерьмо.

А gajim'ов ваших я в глаза не видел - сами ищите альтернативы. У меня есть centericq.