и под виндой это уже было, начиная с Altavista ЧтоТоТам...

"html даты" это пять...

>статья про то зачем нежен локальный поиск

И правда, зачем он так нежен?

Похоже на маркетинговый бред для ламеров. Слово "искусственный интеллект" уж очень скомпрометировано. Слишком часто за ИИ пытались выдать тупые и бесполезные алгоритмы. Еще одно ругательное слово - "эвристический".

> Как насчёт видео, аудио, картинок, XML, PDF ?

а как на счет закрытых форматов типа doc,xls?

Включить в парсер catdoc?

>И правда, зачем он так нужен?

Он очень нужен. Прсто очень.Когда пытаешься что-то найти. А если не надо искать - не нужен ))

уже давно есть для emacs friendly юзеров - http://www.remem.org

Googlr Desctop Search привлекает именно своей простотой, малыми размерами, небольшим требованиям к ресурсам и самое главное - это готовое решение.
Здесь же опять конструктор типа "сделай сам", в самых нужных файлах по дефолту не ищет, жрет по всем признакам немало...

> В общем, статья про то зачем нежен локальный поиск

Нежный и ласковый локальный поиск... ;)

Теперь агент без вашего ведома может притыривать информацию с вашего компа, да еще и разложенную по полочкам!

Вообще-то, подобных хреновин, в том числе, и расширяемых, и "out-of-box", и, вероятно, учитывающих особенности русского словообразования, под линуксом, ну, не вагон, не не одно точно. Я еще в 97 году глимпсом пользовался. И даже, ужас-ужас, с веб-интерфесом.

Стаью не читал... т.к. мне хватает find (slocate) + grep

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

Блин, точно матрица какая-то и агенты Смиты :)

Не ту цитату привел :) Вот к этой относится:

...Организация памяти близкой по типу к человеческой гарантирует увеличение продуктивности в процессах коммуникации, благодаря чему практически все приложения системы могут быть так называемыми агентами. Агент, наделённый целевым поведением и инструментами работы с ассоциативной памятью, даёт фантастическую полезность практически в любой области применения, будь то натуральный язык общения или поиск информации (DataMining), осуществляемый целями другого агента...

Гугель скоро будет уметь искать в видеофайлах кадр по субтирам. Вот.

И как только с этим справились разработчики опенсорсного Beagle... :)

>Google Desktop Search привлекает именно своей простотой, малыми размерами, небольшим требованиям к ресурсам и самое главное - это готовое решение.

Гы, минимум гиг для базы :D Форматов мало, наверное пока, но сам никакой формат не прикрутишь. Технология закрыта, кода нет. afaik никуда саму прогу не прикрутишь, кроме как веб.

>Здесь же опять конструктор типа "сделай сам", в самых нужных файлах по дефолту не ищет, жрет по всем признакам немало...

Могу только перечислить остальные "минусы" конструктора сделай сам:

- Можно указать каталог где индексировать, вместо индексации всей системы, чтобы уменьшить количество документов, время поиска и размер базы.

- Можно сделать обертку на любой формат. были бы проги которые его понимают.

- Можно прикрутить не только к вебинтерфейсу

- Код открыт, сомнений в конспирации нет, было бы желание его посмотреть.

Вывод: имхо, гуглдескпоиск пролетает по фичастости ... эээ, пролетал бы, если бы не их суперский поисковой движок ...

btw, по идее так и должно быть :) они писали для конечных пользователей винды а не для программистов и админов никсов ;) пользователи виндов не будут компилировать что-нить, копатся и разбираться и тем более писать скрипты-обертки на свои форматы - противоречит идеологии виндов.

> Гы, минимум гиг для базы :D

Где Вы такую траву берёте?

Сподобились. В виндовз такое уже 100 лет.

Правда тормозит сильно, но на сильных машинах этого не чувствуется.

>> Гы, минимум гиг для базы :D

>Где Вы такую траву берёте?

Принято, не так выразился, да еще и не точно, в какой-то статье
переврали ... посмотрел в официальном факе: http://desktop.google.com/about.html#sysreq

4. What are the system requirements for running Google Desktop Search?

Google Desktop Search is currently available for Windows XP and Windows 2000 Service Pack 3 and above. To install, you must have administrator privileges (home users shouldn't have this problem; people in offices might). It also requires 500MB of space available on your hard disk. We also recommend a minimum of 128MB of RAM and a 400MHz Pentium processor.

минимум 500 метров для установки :)

>Стаью не читал... т.к. мне хватает find (slocate) + grep

Ну и сколько у тебя уйдет времени на поиск?
То о чем ты говоришь и то о чем идет речь разные вещи.

Создание индексов и поиск по ним --- не новость. Просто активно это никто не продвигал. Не считая всяких там EMC конечно :)

Отсутствие хорошего локального поисковика для десктопа - проблема действительно серьёзная. При этом обязательно должны поддерживаться все типы документов + содержание писем и история IM.

Я думаю, наилучшее решение проблемы - принятие организацией типа freedesktop.org стандарта на плагины, позволяющие вести текстовый поиск в различных источниках данных.

2pitekantrop: лучшим решением бы было использование многопоточных fs - данные отдельно, форматирование отдельно...:)

2Irsi WTF fs? Неужели file system? %-)

И ещё раз: www.gnome.org/projects/beagle/ :)

2pitekantrop: она родимая... если форматирование документа будет содержаться в одном потоке, а содержание, в другом, то никаких плагинов не потребуется, индексация такого документа не будет ничем отличаться от индексации обычного тестового файла.
Картинки, видео и аудио? Если описание картинки, видео или аудио (те же EXIF или MP3 Tag к примеру) потока хранится в отдельном потоке, то их индексация тоже практически не отличается от индексации текстового файла...

Больше того, не просто разделить заголовок от "туловища", но и стандартизовать разметку заголовков. Что нибудь вроде Dublin Core Metadata.

Зачем это всё когда давно уже есть OWL и RDF?
В данном случае идеально подошёл-бы OWL-lite.

2Irsi
Решение абсолютно далёкое от народных масс. Вместо того, чтобы встроить поисковик в десктоп надо встроить всю систему в поисковик.
Диагноз: жертва научной фантастики.

Мнэээ... А народные массы тут каким боком? Для них всё равно всё прозрачно.

> Больше того, не просто разделить заголовок от "туловища", но и стандартизовать разметку заголовков. Что нибудь вроде Dublin Core Metadata.

Ёпрст! Какой заголовок, какое туловище? Есть какие-то данные в уже существующих форматах с вкраплениями текста. Надо уметь искать в этом тексте и обеспечить удобную навигацию по результатам поиска.
Посмотри ссылку, которую ты давал, особенно разделы для разработчиков.

>малыми размерами, небольшим требованиям к ресурсам

А нам - жаба программерам на резурзы насрать. Наш любимый размер - 40М, а ОЗУ - 1G! РЕЗУРЗЫ НЫНЧЕ ДЕШЕВЫ! РЕЗУРЗЫ ЧТОБ ТРАТИТЬ А НЕ БЕРЕЧ!

greenstone.org

2pitekantrop: Да ну? Ах да - Ваш ник говорит о том что Вам поиск вообще нафиг не нужен, Вам достаточно каменного топора...:)
Опять ведь мелкософт догонять будете...:)

2AP: для описания всяких картинок, аудио, видео и т.д.? Согласен. Но это уже не как интересно - интересен именно поиск в документах (тексты, эл. таблицы), почте и IM-сообщениях.

>> 2pitekantrop: лучшим решением бы было использование многопоточных fs - данные отдельно, форматирование отдельно...:)

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

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

конечно идеал это отсутствие файловой системы вообще и DB API как полная замена FILE API но революции не происходят и всё изменяется инерционно,

поэтому можно только предложить один вариант - индексация файла при появлении файла в файловой системе(например создание или загрузка из сети) - может кто нить что слышал о таком ?

> Здесь же опять конструктор типа "сделай сам",

знание перла ОЧЕНЬ повышает продуктивность труда

> в самых нужных файлах по дефолту не ищет,

по дефолту ищет в PDF, DOC, XML, HTML, C, ...
притом, что "не по дефолту" сделать очень легко - всё что нужно, ПЕРЛ ПАРСЕР, которых в сети тысячи для всех типов файлов.

> жрет по всем признакам немало..

Жрёт очень не много. Для хорошей индексации 100 Мб html кода на индексы нужно примерно 20Mb, то есть коеффициент=0.25
Но самая классная черта - СКОРОСТЬ индексации. Равных пока не видел.
У меня например 100Мб хатээмэла на локальном винте с ext3fs индексирует за 12 сек.
(Атлон 1,3 512рама)

Но конечно же, имеет смысл сделать демона индексации который правда должен откуда то получать сведения о "появляющихся или изменяющихся" файлах - кто даёт такую инфу - драйвер файловой системы ?

> то есть коеффициент=0.25
ошибся, 0.2

Ну так Бигл и делает это -- ищет в документах, почте, IM. Он работает с байтовым потоком, потому может закэшировать что угодно. Потому его используют в Dashboard, идею которого Microsoft, чего уж стесняться, откровенно скоммуниздил у Зимиана.

Неее, я наверно не очень толково мысль сформулировал :)

Я, собственно, о том, что на будущее неплохо бы проектировать форматы так, чтобы метаданные вшивались в них по некоему общепринятому стандарту, так чтобы добавить фильтр для нового формата не было проблемой. Стандарт Dublin COre Metadata, насколько я помню, предписывает использование RDF для описания метаданных. Можно посмотреть реализацию в векторном редакторе Inkscape.

Ах, зачем этот поиск так нежен...

2Irsi Дугих аргументов нет, раз начал ник парсить? :) Требовать от всех, чтоб под тебя переделали все форматы файлов по-моему не очень умно по крайней мере если ты не M$. Представь, где был бы Гугль сейчас, начни он требовать от всех сайтов, чтоб ему давали текстовое содержимое отдельно в text/plain.

> знание перла ОЧЕНЬ повышает продуктивность труда
Меня тошнит от перла, мне НЕ НРАВИТСЯ этот язык.

> Но самая классная черта - СКОРОСТЬ индексации.
А как там со скоростью работы перл парсера? И вообще - нафиг мне нужна индексация хтмл? Для меня (да и не только) скорость индексации хтмль это сферический конь в вакууме. Мне гораздо интересней индексы офисных документов, текстовых файлов, почтовых и IM-сообщений.

>Но конечно же, имеет смысл сделать демона индексации который правда должен откуда то получать сведения о "появляющихся или изменяющихся" файлах
Ктоб спорил...

2pitekantrop: я говорю об идеальном решении. Понятно что придется поддерживать уже существующие форматы файлов, но имхо и новый подход стоит попытаться продвинуть. Если конечно хотите сделать что-то свое и действительно оказаться впереди, а не в привычной роли догоняющих мелкософт.

Решение найдено

Я сейчас думаю начинать писать модуль ядра который будет демону сообщать название файла при write или create file, что бы индексация сама незаметно существовала ! Это и есть решение ! а все препарсеры будут как модули к демону индексации !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
YES !
Индексация должна происходить незаметно при изменении или создании файлов, вот и всё.

нужен человек асс в перле для написания парсеров для различных файловых форматов, так как я сам с баша на перл сейчас только перешёл

если кто заинтересован в участии, напишите vm@compuvisor.net

> Я, собственно, о том, что на будущее неплохо бы проектировать форматы так, чтобы метаданные вшивались в них по некоему общепринятому стандарту, так чтобы добавить фильтр для нового формата не было проблемой.

Да, конечно согласен. Но для баз данных, почтовых и IM клиентов стандарт на интерфейс к поисковой системе по-моему нужен всё равно. Кроме того единый стандарт на метаданные не решает проблемы удобного отображения результатов поиска.