LINUX.ORG.RU

strigi 0.3.11


0

0

Вышла новая версия программы локального поиска strigi, которая позиционируется как альтернатива beagle для kde (и не только т.к. поддерживает различные фронт- и бэкенды и позволяет легко создавать новые, в т.ч. более легковесные)

изменения:

- исправления для SunOS, BSD и 64-х битных платформ
- в интерфейсе клиента появились гистограммы
- поддержка Ogg Vorbis
- улучшена работа с заголовками писем
- поддержка qtdbus
- и некоторые исправления

>>> Подробности

★★★★★

Проверено: Shaman007 ()

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

>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 и все такое кдешное :)

as33 ★☆☆
()

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

vadiml ★★★★★
()

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

Aceler ★★★★★
()

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

pento ★★★★★
()

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

anms234
()

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

anonymous
()
Ответ на: комментарий от anonymous

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

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

funny_falcon
()
Ответ на: комментарий от Aceler

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

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

adarovsky ★★★★
()
Ответ на: комментарий от anms234

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

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

YesSSS ★★★
()
Ответ на: комментарий от pento

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

YesSSS ★★★
()

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

cod
()
Ответ на: комментарий от funny_falcon

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

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

anonymous
()
Ответ на: комментарий от anonymous

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

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

KRoN73 ★★★★★
()
Ответ на: комментарий от Aceler

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

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

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

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

Syncro ★★★★★
() автор топика
Ответ на: комментарий от sin_a

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

Syncro ★★★★★
() автор топика
Ответ на: комментарий от YesSSS

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

Syncro ★★★★★
() автор топика
Ответ на: комментарий от KRoN73

>> locate

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

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

sin_a ★★★★★
()

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

sabonez ★☆☆☆
()
Ответ на: комментарий от sin_a

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

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

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

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

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

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

KRoN73 ★★★★★
()
Ответ на: комментарий от KRoN73

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

ivon
()
Ответ на: комментарий от KRoN73

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

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

sin_a ★★★★★
()
Ответ на: комментарий от KRoN73

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

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

anonymous
()
Ответ на: комментарий от KRoN73

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

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

Evgueni ★★★★★
()
Ответ на: комментарий от anonymous

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

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

KRoN73 ★★★★★
()
Ответ на: комментарий от Evgueni

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

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

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

KRoN73 ★★★★★
()
Ответ на: комментарий от KRoN73

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

sdio ★★★★★
()
Ответ на: комментарий от sdio

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

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

KRoN73 ★★★★★
()
Ответ на: комментарий от sin_a

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

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

YesSSS ★★★
()
Ответ на: комментарий от Syncro

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

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

Skull ★★★★★
()
Ответ на: комментарий от KRoN73

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

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

c0ff
()
Ответ на: комментарий от Evgueni

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

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

AP ★★★★★
()
Ответ на: комментарий от KRoN73

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

Syncro ★★★★★
() автор топика
Ответ на: комментарий от Syncro

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

YesSSS ★★★
()
Ответ на: комментарий от Skull

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

Syncro ★★★★★
() автор топика
Ответ на: комментарий от YesSSS

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

Syncro ★★★★★
() автор топика
Ответ на: комментарий от sin_a

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

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

MYMUR ★★★★
()
Ответ на: комментарий от KRoN73

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

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

argin ★★★★★
()
Ответ на: комментарий от KRoN73

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

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

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

argin ★★★★★
()

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

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

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

AsphyX ★★★
()
Ответ на: комментарий от AsphyX

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

Syncro ★★★★★
() автор топика
Ответ на: комментарий от Syncro

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

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

Skull ★★★★★
()
Ответ на: комментарий от KRoN73

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

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

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

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

anonymous
()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.