LINUX.ORG.RU
ФорумTalks

Десктопные поисковики не нужны.


0

0

У них у всех наблюдается пренеприятная антифича: они подолгу молотят твой жесткий диск, кушая ценные ресурсы системы, так, что нормально работать на ней не представляется возможным, с целью «обновить индексы».

Но при этом, мля, у меня столько информации, что «обновление» (которое впору бы назвать полной перезаливкой) занимает по полдня.

Вот и нафиг упало такое счастье? Добавим ко всему, что некоторые примочки работают только с Beagle, другие только со Strigi, третьи только со Swish++.

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

Dixi.

★★★★★
Ответ на: комментарий от anonymfus

> Пока никаких письменно оформленных предложений нет, кроме высказанных здесь:)
> Начал писать пародию на RFC... Раз уж здесь так к этому относятся...
> anonymfus * (*) (31.10.2007 13:57:48)

Пиши мне на pacify@mail.ru - будем рожать вместе :)
ИМХО, идеи распределенных вычислений с децентрализованным управлением очень перспективны - и по этому пути пойдет развитие харда и софта в ближайшее будущее.

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

> ну и заодно попинать базы данных, lastlog, flow-tools и прочие инструменты, который - о ужас! хранят данные в бинарном виде, и требуют специальных утилит для извлечения

http://en.wikipedia.org/wiki/Unix_way

ps я не считаю базы данных не труЪ

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

>Аналогично, перед тем, как определять нужность индексаторов

так нужность не определяют. Вопят "индексатор не нужен!". Собсно, на этом спор можно и закончить

я привел юскейсы, которые показывают, что эти вопли - пустое место. Всё

не надо на меня вешать чужих собак.

>P.S. За грубости в этом треде извиняюсь.

ок, взаимно

>пытался выяснить - собираетесь ли Вы помогать сообществу в создании более совершенных программ ...

думал разделить тракер на монитор и собстно индексатор. Задача, когда нужно висеть на inotify встречается куда чаще, чем индексация. А кол-во хуков inotify ограничено, и на все программки может не хватить

собсно, вопрос только в наличии продолжительных кусков свободного времени

а далее - можно и Query-интерфейс стандартизировать, и сервис написать, куда могут подключаться программы/агенты, умеющие что-то искать и т.д. Идей масса, времени куда меньше

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

> Очень обидно видеть, что на UNIX-way все стали класть.

Очень обидно, что для некоторых UNIX-way из удобного средства превратился в фетиш и еще обиднее, что они не понимают, что UNIX-way тоже развивается.

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

Он поисковик по метаданным. Имя файла - тот же тэг на самом деле.

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

>А каким боком он контентный поисковик?

он не контентый. Просто индексатор имен файлов

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

> то что там написано - мне прекрасно известно. И индексаторы ничем не противоречат унхвею

Ты про бинарные форматы что-то там говорил.

defmacro
()

Что за дебильный подход ко всему "мне не нужно, значит никому не нужно"?

Ну я, скажем, не имею нужды в десктопном поиске, потому что у меня относительно мало локальных документов, как правило нужный мне документ находится online, на sciencedirect итд, и используется мною 1-2 раза. Так что мне по уши хватает стратегии "just fucking Google it." Но если есть много локальных документов, к которым нужен многократный доступ, то нужен и сравнимый по эффективности локальный поиск, и тут tracker, beagle итд незаменимы.

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

>Ты про бинарные форматы что-то там говорил.

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

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

> Вопят "индексатор не нужен!".
> я привел юскейсы, которые показывают, что эти вопли - пустое место. Всё

То, что индексы предназначены для ускорения поиска - это понятно.
Другое дело, что тупые средства построения индексов можно усовершенствовать -
построить событийно-ориентированную поисковую систему по unix-way, как предлагает anonymfous.

> Идей масса, времени куда меньше

Выкладывай идеи на свой сайт - сделаем LOR Web Ring ;)
"В единстве - наша сила" (с) Центризбирком

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

>Другое дело, что тупые средства построения индексов можно усовершенствовать - построить событийно-ориентированную поисковую систему по unix-way, как предлагает anonymfous.

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

>Выкладывай идеи на свой сайт - сделаем LOR Web Ring ;)

надо подумать, да. Собсно, одну идею я уже высказал =)

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

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

При чем здесь grep?

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

> не знаю. Просто некоторые считают, что унихвей - это обязательно plain text.

Write programs to handle text streams, because that is a universal interface." (c) Doug McIlroy

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

>Write programs to handle text streams, because that is a universal interface." (c) Doug McIlroy

cat не умеет обрабатывать текстовые потоки. cat - не юнихвей?

flow-cat, flow-nfilter, flow-stat - тоже. Они тоже не юнихвей?

может стоит понять, что есть программы, чья задача не заключается в обработке текста?

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

> может стоит понять, что есть программы, чья задача не заключается в обработке текста?

Ну тогда стоит уточнить также, что есть `обработка текста' :)

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

>Ну тогда стоит уточнить также, что есть `обработка текста' :)

фильтрация/редактирование.

собсно, можно ещё и требовать вывод результата в текстовой форме - ну так тот же трекер это делает.

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

> собсно, можно ещё и требовать вывод результата в текстовой форме - ну так тот же трекер это делает.

Ну тогда труЪ :)

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

>cat не умеет обрабатывать текстовые потоки
а что тогда это?!:
>{saahЯiktu} cat /etc/csh.logout - > file0
>text stream
>{saahЯiktu} cat file0
>#
># System-wide .logout file for csh(1).
>
>text stream

Суть в том, чтобы всё что только можно было прозрачно и человекочитаемо.
Это также упрощает автоматизацию, из-за чего UNIX'ы на этом-то и не одну собаку съели.
Понятное дело, что бинарные форматы уменьшают размеры медиа файлов - графика, музыка, видео,.. етц
Однако, и обработка этих файлов уже не является такой простой, хотя, это особо и не актуально - был бы вьювер/плэйер.
А вот работа с тэгами и прочей мета-инфой уже представляет собой ту еще задачу.

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

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

>а что тогда это?!:

ну какая же это обработка =) Это чтение и вывод

вот zcat ещё куда ни шло...хотя это и скрипт, дергающий gzip =)

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

Дык речь идёт об текстовых потоках в качестве универсальных интерфейсов.
Одна программа ложит текст на выход, который является входом для другой программы, которая его и читает со своего входа.
Благодаря чему и возможны конвейеры '|'.
Конвейеров в своём примере я не привёл, но всё работает и с ними.
Например:
head -n 1 /etc/csh.logout | cat -
#

Здесь head ложит на вход cat'а _текст_, который, как и в моём первом примере, вполне мог быть набран с клавиатуры.

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

>Дык речь идёт об текстовых потоках в качестве универсальных интерфейсов.

как быть с locate и find ? Не унихвей уже, да ?

geek ★★★
()

> где многогигабайтный срач в /home, как у меня

Спецы Far рекомендуют в таких случаях... ;-)

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

>как быть с locate и find ? Не унихвей уже, да ?
они тоже читают со входа и ложат на выход
example:
>find px/ -iname "*`ndate y`*" | head -n 4
>px/ascii/20070829.txt
>px/ascii/20070901.txt
>px/ascii/20070930.txt
>px/ascii/20071002.txt
здесь `ndate y` ложит на выход чило года, которое оболочка вписывает в командную строку, которая тоже, по сути, является входным текстовым потоком. результат find'а передаётся дальше head'у (конвейер).

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

>как быть с locate и find ? Не унихвей уже, да ?

Ето есть в любой UNIX-системе, а трекеры - далеко не везде.

Что уважаемый будет делать, если ему доведется че нить отыскать на файлопомойке на каком нить SCO (не к ночи будет помянуто) ?

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

>Что уважаемый будет делать, если ему доведется че нить отыскать на файлопомойке на каком нить SCO (не к ночи будет помянуто) ?

ну...каменному веку - каменные топоры, что делать. Если уж трекер не соберется

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

>они тоже читают со входа и ложат на выход

>find

помедленнее, я записываю. Что в данном примере find берет из stdin?

а класть в stdout и tracker-search умеет

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

На что ж люди не идут дабы стандартными утилитами не пользоваться.

А компилять под СКО - дело надо сказать геморное, ето не гента...

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

>На что ж люди не идут дабы стандартными утилитами не пользоваться.

люди могут и стандартными утилитами пользоваться, только зачем, если есть инструменты лучше? Ну а там где нет - то да, старые утилиты

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

>помедленнее, я записываю. Что в данном примере find берет из stdin?
не из stdin, а из переменных своего окружения, что сути связывания программ текстовыми интерфейсами в цепочку не меняет.
вот если бы оно всегда пускалось с дефолтными аргументами и не могло быть связано в цепочку с другим софтом - тогда это бы было винвэем
а так - это юниксвэй
>а класть в stdout и tracker-search умеет
ну и прекрасно

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

>не из stdin, а из переменных своего окружения, что сути связывания программ текстовыми интерфейсами в цепочку не меняет.

я тогда вообще не понял, чем find юнихвейнее трекера. Трекер делает ровно тоже самое. Апчом спорим?

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

> Апчом спорим?

ИМХО о том, что все большее массовое засилье бинарной каши (pdf, djvu) для текстовых документов суть зло и никак не тот самый вей...

Bod ★★★★
()

снос бигля - одно из первых дел после установки системы

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

>ИМХО о том, что все большее массовое засилье бинарной каши (pdf, djvu) для текстовых документов суть зло и никак не тот самый вей...

я весь внимание. Какая альтернатива есть?

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

А какая у зла может быть альтернатива? ;) Это не конструктив, это крик души... Я вообще слабо понимаю суть и важность упомянутых форматов. С декларируемым "...ваш документ будет одинаково выглядеть на любом компьютере.." легко справляется всякий графический формат. А Adobe еще и постоянно меняет PDF...

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

> справляется всякий графический формат.

Текст таскать в виде рендеренных превьюшек? Или вместе? И в каком разрешении? Сжатие с потерями или без? А что на счет цветового пространства? А устройства вывода у нас будет гвоздями вколочено "односторонний А4"? PDF действительно выглядет везде одинаково: и на экране и на принтере.

Надоели студенты не печатавшие чего-то сложнее отчета по лабе в ворде.

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

>А какая у зла может быть альтернатива? ;)

а почему зло?

>легко справляется всякий графический формат

это даже не "бугога"

geek ★★★
()

> Десктопные поисковики не нужны.

+1. Достаточно просто не срать (хотя, произнося подобное на ЛОРе, мне кажется, что я требую невозможного).

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

> Апчом спорим?
Спор в данном треде заходил о многих вещах.
Начиная от трушности бинарных форматов до юниксвэйности текстовых программных интерфейсов и юниксвэйности cat'а, find'а и иже с ними.

Бинарные форматы некошерны из-за человеконечитаемости и сложной автоматизации их обработки (см. выше).
Если рассматривать альтернативу PDF'у именно как рецепту переносимости документов, то это - DVI.
dvi2tty быстр как медвежья болезнь. только в классическом виде у него с кириллицей вообще никак. прикручивать, однако, надо.
а так, кошерными форматами документов являются TeX, XML, html, plain text.
сам я храню всё в plain text'е

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

Ага, скажи еще что бы мы и не ссали.

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

>Бинарные форматы некошерны из-за человеконечитаемости и сложной автоматизации их обработки (см. выше).

ну, как раз бинарные данные обрабатываются легче, хотя и non-human-readable. Что удобно компу - неудобно человеку, и наоборот. Так что это всё лирика, хотя, кончено, такая позиция вполне понятна.

>Если рассматривать альтернативу PDF'у именно как рецепту переносимости документов, то это - DVI.

придется убить всех человеков, и наделать новых

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

>Достаточно просто не срать

в этом треде уже неоднократно было показано, почему такая позиция является идиотской

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