Re: Анонс: легковесная система полнотекстового поиска
Hello! On Wednesday 10 February 2010 21:17:24 Serhiy Storchaka wrote: > >> В идеале программа должна уметь принимать список файлов как из командной > >> строки, так и из файла или stdin (при указании специального ключа). > > > > poisk-cmdline file1 ... fileN | poisk-files-add > > Чем это лучше > (echo file1; ... echo fileN) | poisk-files-add > ? > > Особенно для одного файла. Для одного файла разницы нет. А вот для десятка... Best regards, Alexey Pechnikov. http://pechnikov.tel/
Re: Анонс: легковесная система полнотекстового поиска
Alexey Pechnikov wrote: > On Saturday 06 February 2010 12:01:25 Serhiy Storchaka wrote: >> В идеале программа должна уметь принимать список файлов как из командной >> строки, так и из файла или stdin (при указании специального ключа). > > poisk-cmdline file1 ... fileN | poisk-files-add Чем это лучше (echo file1; ... echo fileN) | poisk-files-add ? Особенно для одного файла. -- To UNSUBSCRIBE, email to debian-russian-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: Анонс: легковесная система полнотекстового поиска
Hello! On Saturday 06 February 2010 12:01:25 Serhiy Storchaka wrote: > В идеале программа должна уметь принимать список файлов как из командной > строки, так и из файла или stdin (при указании специального ключа). poisk-cmdline file1 ... fileN | poisk-files-add $ cat poisk-cmdline #!/bin/dash # Use as # poisk-cmdline args | ... for arg in "$@" do echo "$arg" done exit 0 Возможно, это решается стандартными утилитами, но xargs знаю, а чем сделать обратную операцию - не придумал. Best regards, Alexey Pechnikov. http://pechnikov.tel/
Re: Анонс: легковесная система полнотекстового поиска
Hello! On Sunday 07 February 2010 17:20:04 Feata`lion Nyere`` wrote: > Спасибо за ответ, я какраз думал о том, чтобы при невозможности расширения > до http делать зеркало интересующих ресурсов. Расширить-то можно, но полученное решение значительно проиграет связке файлового индексатора + wget. Впрочем, я, пожалуй, переименую утилиту poisk-add в poisk-add-file, предоставив желающим создание poisk-add-http и других. Best regards, Alexey Pechnikov. http://pechnikov.tel/
Re: Анонс: легковесная система полнотекстового поиска
Hello! On Sunday 07 February 2010 15:14:23 Feata`lion Nyere`` wrote: > Господин Печников, не могли бы Вы уточнить, возможна ли опция индексирования > удалённых файлов по http или простой способ добавления её? Индексирование списка html-страниц проблемы не представляет. Что касается прочих форматов, то их чрезвычайно сложно определить "на лету", не сохраняя файл на диск, а веб-сервера вроде апача абсолютно криво передают mime-тип. Кроме того, для индексирования удаленных ресурсов невозможно получить заранее список файлов, их необходимо обнаруживать непосредственно в ходе обработки. Далее, обработка удаленных архивов также невозможна, поскольку мы не имеем способа получить для индексации нужный нам файл из архива (при поддержке веб-сервером byte ranges можно кое-что сделать, но имхо довольно криво). Так что полагаю оптимальным делать зеркало средствами wget, к примеру, и после индексировать локальные файлы. С ftp проще - см. curlftpfs. Примечание: одна из основных причин, почему я взялся за разработку своего индексатора, это желание избежать использования временных файлов при индексировании. В результате мы тратим больше процессорного времени, но можем индексировать гиговый архив на ноутбуке с гигом памяти в фоне, не мешая работе остальных приложений и не нагружая жесткий диск. Так что смело создавайте зеркало http-ресурса и его индексируйте - это потребует больше места на диске, но вы легко сможете выполнять эту операцию на обычных сата-дисках даже для больших сайтов. В то же время следует учесть, что вызов внешнего скрипта для извлечения каждого отдельного файла из архива требует больше времени, нежели распаковка архива на диск или в ОЗУ и дальнейшая обработка всех файлов. Впрочем, никто вам не мешает проигнорировать все архивы, а потом распаковать по очереди внешним скриптом и проиндексировать точки распаковки. Best regards, Alexey Pechnikov. http://pechnikov.tel/
Re: Анонс: легковесная система полнотекстового поиска
Hello! On Saturday 06 February 2010 17:49:24 Yuriy Kaminskiy wrote: > впрочем, я в своих скриптах на существование таких файлов тоже забиваю ;-) > [но одно дело мои скрипты для локального использования, другое - программа для > пользования другими в непредсказуемом окружении; как минимум, непонимание > таких > имён файлов должно быть документированно БОЛЬШИМИ БУКВАМИ] Это разумно - именно документировать. Best regards, Alexey Pechnikov. http://pechnikov.tel/
Re: Анонс: легковесная система полнотекстового поиска
Hello! On Saturday 06 February 2010 18:15:00 Alexander Galanin wrote: > > Если сделать поддержку \n в именах, придется и здесь в выводе использовать > > \0, > > и сделать даже простой греп будет весьма проблематично. Получаемые же > > Можно экранировать \n так, как это делает ls -b. Тогда лишнего переноса > строк не будет и грепуемость сохранится. И потянется это далеко-далеко, во все утилиты, работающие с поисковой базой. И полученное в результатах поиска имя файла нельзя будет найти в базе, т.к. в первом случае используется экранирование, а во втором - нет. > С принятием имён файлов на stdin тоже можно разобраться путём введения > ключика -0 как в xargs. Т.е. если он задан, считаем вход разделённым > нулями, иначе читаем построчно. Таким образом будут удовлетворены и > роботы, которым нужны поддержка \n в имени, и люди. Проиндексировать-то несложно, проблема возникнет при работе с индексом. Best regards, Alexey Pechnikov. http://pechnikov.tel/
Re: Анонс: легковесная система полнотекстового поиска
Hello! On Saturday 06 February 2010 12:01:25 Serhiy Storchaka wrote: > В идеале программа должна уметь принимать список файлов как из командной > строки, так и из файла или stdin (при указании специального ключа). Об этом я тоже думаю, можно сделать так: find | poisk-add file1 file2 ... fileN Что касается \n в именах файлов, поддержку сделать возможно, но это та вещь, от которой необходимо избавляться - как минимум, потому, что uri такого не поддерживает и полученная база окажется непригодна для веб-поиска. Все утилиты поиска у меня заточены именно на однострочные имена файлов, т.к. это позволяет легко грепать результат и выполнять любую другую автоматизированную обработку. Пример: poisk-ls test.db 2 1 / ... poisk_count = 3 poisk_counter = 3 rowid = 1 mtime = 2004-04-09 size = 446976 uri = /Эра Фанка.doc dirname = / filename = Эра Фанка.doc mimetype = application/msword title = Эра Фанка Если сделать поддержку \n в именах, придется и здесь в выводе использовать \0, и сделать даже простой греп будет весьма проблематично. Получаемые же преимущества не просто сомнительны, а вовсе неуловимы, т.к. у пользователя подобных файлов не бывает - их нельзя скачать из интернет или создать офисными программами. Best regards, Alexey Pechnikov. http://pechnikov.tel/
Re: Анонс: легковесная система полнотекстового поиска
Artem Chuprina wrote: > Serhiy Storchaka -> debian-russian@lists.debian.org @ Sat, 06 Feb 2010 > 09:57:21 +0200: > SS> Достаточно -exec poisk-add. > > Я тоже сначала так подумал. Но это будет, вообще говоря, другая модель > использования. > > В stdin ты ему их сможешь передать сразу все, а через командную строку - > только по частям. В данном случае это несущественно, файлы можно обрабатывать независимо и в произвольном порядке. В командную строку влезет достаточно, чтобы издержки на запуск poisk-add были несущественными, принципиальной невозможности дозаписи (как с tar cz) нет. Плюсы — нет проблем с \n в имени файла, удобнее вызывать вручную для одного-нескольких файлов (не нужно городить (echo ...; echo ...)|... или даже (echo ...; echo ...)|tr '\n' '\0'), свободный stdin, через который можно передавать дополнительные данные. В идеале программа должна уметь принимать список файлов как из командной строки, так и из файла или stdin (при указании специального ключа). > При этом контент через stdin не передашь из-за > сложностей с преобразованием. Вот это предложение я не понял. -- To UNSUBSCRIBE, email to debian-russian-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: Анонс: легковесная система полнотекстового поиска
Artem Chuprina wrote: > Serhiy Storchaka -> debian-russian@lists.debian.org @ Sat, 06 Feb 2010 > 10:04:19 +0200: > SS> Нет-нет. Если это пользовательская утилита, то она должна быть > SS> простой в использовании для типичных применений. Указал в кронтабе > SS> poisk-scanner /var/www/mysite — и оно молотит все файлы с > SS> подкаталогами, пропуская CVS, .svn, .htaccess, poisk.db и указанные > SS> пользователем в настройках маску *.php, файл config.ini и > SS> подкаталог private. > > Это если пользователь этой утилиты - ты. А мне и, подозреваю, самому > Алексею, скажем, нафиг не нужно пропускать там CVS, *.php и config.ini - > их там, блин, нет и быть не может. Зато нужно пропускать .git и удалять > из базы то, что было удалено из файловой системы. Тогда poisk-scanner вообще не нужен. Просто скармливаем poisk-add список файлов. А если уж наделяем утилиту возможностью самой сканировать каталоги, то пусть умеет и отсекать ненужное. Хороший пример — svn add или git add. -- To UNSUBSCRIBE, email to debian-russian-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: Анонс: легковесная система полнотекстового поиска
Serhiy Storchaka -> debian-russian@lists.debian.org @ Sat, 06 Feb 2010 09:57:21 +0200: >> AP> find "$@" 2>/dev/null | poisk-add "$POISKDB" >> >> Ох... Вот бы не так топорно, а хотя бы find "$@" -print0, и poisk-add >> обучить по нуль-символу видеть границу имени файла. Ибо про перевод >> строки в имени только что дискуссия была. SS> Достаточно -exec poisk-add. Я тоже сначала так подумал. Но это будет, вообще говоря, другая модель использования. В stdin ты ему их сможешь передать сразу все, а через командную строку - только по частям. При этом контент через stdin не передашь из-за сложностей с преобразованием. SS> А лучше, конечно, включить код poisk-add в poisk-scanner. Потому, SS> что критерии, по которым можно принимать решение о переиндексации, SS> лежат в базе (и обновляются poisk-add). Ой, нет. Мухи отдельно, котлеты отдельно. -- Нужны две программы - одна с интерфейсом, а другая чтобы работу делала. Victor Wagner в -- To UNSUBSCRIBE, email to debian-russian-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: Анонс: легковесная система полнотекстового поиска
Serhiy Storchaka -> debian-russian@lists.debian.org @ Sat, 06 Feb 2010 10:04:19 +0200: >> SS> poisk-scanner-у нужно иметь возможность указать не только, что >> SS> индексировать, но и что пропускать. По маске имени, явно указывая >> SS> пути. >> >> Пусть сделает poisk-add. А poisk-scanner потом каждый нарисует себе под >> себя. Потому что универсального решения сразу для всех не получится, >> логика выбора (баланс между достоверностью отлова изменений и затратой >> ресурсов) у каждого своя. SS> Нет-нет. Если это пользовательская утилита, то она должна быть SS> простой в использовании для типичных применений. Указал в кронтабе SS> poisk-scanner /var/www/mysite — и оно молотит все файлы с SS> подкаталогами, пропуская CVS, .svn, .htaccess, poisk.db и указанные SS> пользователем в настройках маску *.php, файл config.ini и SS> подкаталог private. Это если пользователь этой утилиты - ты. А мне и, подозреваю, самому Алексею, скажем, нафиг не нужно пропускать там CVS, *.php и config.ini - их там, блин, нет и быть не может. Зато нужно пропускать .git и удалять из базы то, что было удалено из файловой системы. -- Пришел в гости математик, почитать новую рукопись. Вычитал из нее трех героев напрочь, и ушел. Gimli on #arda -- To UNSUBSCRIBE, email to debian-russian-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: Анонс: легковесная система полнотекстового поиска
Artem Chuprina wrote: > Serhiy Storchaka -> debian-russian@lists.debian.org @ Fri, 05 Feb 2010 > 23:22:07 +0200: > SS> poisk-scanner-у нужно иметь возможность указать не только, что > SS> индексировать, но и что пропускать. По маске имени, явно указывая > SS> пути. > > Пусть сделает poisk-add. А poisk-scanner потом каждый нарисует себе под > себя. Потому что универсального решения сразу для всех не получится, > логика выбора (баланс между достоверностью отлова изменений и затратой > ресурсов) у каждого своя. Нет-нет. Если это пользовательская утилита, то она должна быть простой в использовании для типичных применений. Указал в кронтабе poisk-scanner /var/www/mysite — и оно молотит все файлы с подкаталогами, пропуская CVS, .svn, .htaccess, poisk.db и указанные пользователем в настройках маску *.php, файл config.ini и подкаталог private. -- To UNSUBSCRIBE, email to debian-russian-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: Анонс: легковесная система полнотекстового поиска
Artem Chuprina wrote: > Alexey Pechnikov -> debian-russian@lists.debian.org @ Sat, 6 Feb 2010 > 00:51:38 +0300: > AP> find "$@" 2>/dev/null | poisk-add "$POISKDB" > > Ох... Вот бы не так топорно, а хотя бы find "$@" -print0, и poisk-add > обучить по нуль-символу видеть границу имени файла. Ибо про перевод > строки в имени только что дискуссия была. Достаточно -exec poisk-add. А лучше, конечно, включить код poisk-add в poisk-scanner. Потому, что критерии, по которым можно принимать решение о переиндексации, лежат в базе (и обновляются poisk-add). -- To UNSUBSCRIBE, email to debian-russian-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: Анонс: легковесная система полнотекстового поиска
Alexey Pechnikov -> debian-russian@lists.debian.org @ Fri, 5 Feb 2010 23:27:00 +0300: >> AP> А вот это не годится. Данные могут быть перемещены на другой диск >> AP> или даже на другой компьютер, это не повод их переиндексировать. >> >> А у тебя переиндексация точно существенно дороже, чем md5? AP> Убрал подсчет md5 сумм в конфигурации по умолчанию, при желании можно AP> легко добавить, раскомментировав пару строк в poisk-fileinfo. AP> Вопрос: где пользователю предоставить размещать его собственные фильтры? AP> Вижу следующие варианты - в /usr/local, /etc/sqlite3-poisk/ и ~. Дефолтовые AP> сейчас хранятся в /usr/share/sqlite3-poisk/. Или можно дефолтовые перенести в AP> /etc/sqlite3-poisk/, хотя имхо не удобно это, лично я не люблю от рута что-либо AP> настраивать. А что такое "собственный фильтр"? Если программа, то странно размещать ее в /etc. Программу можно размещать в /usr/share/sqlite3-poisk (ТОЛЬКО если она процессорно-независима) или в /usr/lib/sqlite3-poisk (если она процессорно-зависима). Админ системы будет класть свое такое же в нечто аналогичное, но вместо /usr будет /usr/local. В идеале - по тем же правилам (/usr/local/share vs. /usr/local/lib). Рядовой пользователь не будет делить share и lib. Резонно будет предложить ему использовать ~/.sqlite3-poisk/lib. -- hands-free BSD -- (С)энта -- To UNSUBSCRIBE, email to debian-russian-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: Анонс: легковесная система полнотекстового поиска
Alexey Pechnikov -> debian-russian@lists.debian.org @ Sat, 6 Feb 2010 00:51:38 +0300: >> > А, понял. В таком случае утилиту обработки файлов переименую в poisk-add, >> > велю ей список файлов принимать на stdin, а poisk-scanner сделаю оберткой. >> >> poisk-scanner-у нужно иметь возможность указать не только, что >> индексировать, но и что пропускать. По маске имени, явно указывая пути. AP> В разрабатываемой версии вот так: AP> POISKDB=test.db poisk-scanner /tmp AP> $ cat poisk-scanner AP> #!/bin/dash AP> if [ -z "$POISKDB" ]; then AP> exec 1>&2 AP> echo "Envinroment variable POISKDB doesn't not set" AP> exit 1 AP> fi AP> if [ ! -e "$POISKDB" ]; then AP> poisk-dbinit "$POISKDB" AP> fi AP> find "$@" 2>/dev/null | poisk-add "$POISKDB" Ох... Вот бы не так топорно, а хотя бы find "$@" -print0, и poisk-add обучить по нуль-символу видеть границу имени файла. Ибо про перевод строки в имени только что дискуссия была. -- Реляционная база данных - это не единственный способ сделать дурацкий поиск. Victor Wagner -- To UNSUBSCRIBE, email to debian-russian-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: Анонс: легковесная система полнотекстового поиска
Serhiy Storchaka -> debian-russian@lists.debian.org @ Fri, 05 Feb 2010 23:22:07 +0200: >> А, понял. В таком случае утилиту обработки файлов переименую в >> poisk-add, велю ей список файлов принимать на stdin, а poisk-scanner >> сделаю оберткой. SS> poisk-scanner-у нужно иметь возможность указать не только, что SS> индексировать, но и что пропускать. По маске имени, явно указывая SS> пути. Пусть сделает poisk-add. А poisk-scanner потом каждый нарисует себе под себя. Потому что универсального решения сразу для всех не получится, логика выбора (баланс между достоверностью отлова изменений и затратой ресурсов) у каждого своя. -- The Eclipse Platform is an open and extensible platform for anything and yet nothing in particular. -- apt-cache show eclipse-platform -- To UNSUBSCRIBE, email to debian-russian-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: Анонс: легковесная система полнотекстового поиска
Hello! On Saturday 06 February 2010 00:22:07 Serhiy Storchaka wrote: > > А, понял. В таком случае утилиту обработки файлов переименую в poisk-add, > > велю ей список файлов принимать на stdin, а poisk-scanner сделаю оберткой. > > poisk-scanner-у нужно иметь возможность указать не только, что > индексировать, но и что пропускать. По маске имени, явно указывая пути. В разрабатываемой версии вот так: POISKDB=test.db poisk-scanner /tmp $ cat poisk-scanner #!/bin/dash if [ -z "$POISKDB" ]; then exec 1>&2 echo "Envinroment variable POISKDB doesn't not set" exit 1 fi if [ ! -e "$POISKDB" ]; then poisk-dbinit "$POISKDB" fi find "$@" 2>/dev/null | poisk-add "$POISKDB" Еще думаю добавить poisk-scanner-daemon на основе inotifywait Best regards, Alexey Pechnikov. http://pechnikov.tel/
Re: Анонс: легковесная система полнотекстового поиска
Alexey Pechnikov wrote: > А, понял. В таком случае утилиту обработки файлов переименую в poisk-add, > велю ей список файлов принимать на stdin, а poisk-scanner сделаю оберткой. poisk-scanner-у нужно иметь возможность указать не только, что индексировать, но и что пропускать. По маске имени, явно указывая пути. -- To UNSUBSCRIBE, email to debian-russian-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: Анонс: легковесная система полнотекстового поиска
Hello! On Friday 05 February 2010 22:22:01 Artem Chuprina wrote: > AP> А вот это не годится. Данные могут быть перемещены на другой диск > AP> или даже на другой компьютер, это не повод их переиндексировать. > > А у тебя переиндексация точно существенно дороже, чем md5? Убрал подсчет md5 сумм в конфигурации по умолчанию, при желании можно легко добавить, раскомментировав пару строк в poisk-fileinfo. Вопрос: где пользователю предоставить размещать его собственные фильтры? Вижу следующие варианты - в /usr/local, /etc/sqlite3-poisk/ и ~. Дефолтовые сейчас хранятся в /usr/share/sqlite3-poisk/. Или можно дефолтовые перенести в /etc/sqlite3-poisk/, хотя имхо не удобно это, лично я не люблю от рута что-либо настраивать. Best regards, Alexey Pechnikov. http://pechnikov.tel/
Re: Анонс: легковесная система полнотекстового поиска
Hello! On Friday 05 February 2010 22:58:10 Victor Wagner wrote: > > Откуда стремление засунуть эту логику обязательно в индексатор? > > Пожалуй, и проверку > > Ну юзерский это подход. Индексатор это та штука, вызов которой надо > засунуть в crontab, чтобы потом поиск работал. > > А вовсе не то, что кладет в базу данных информацию о конкретном файле. > > Потому что юзер имеет дело с индексатором именно в этом месте - > прописать в кронтаб, и добавить - здесь читать, здесь не читать, здесь > рыбу заворачивали. А что там оно будет внутри себя делать с тем, что > велели читать - его глубоко внутреннее дело. А, понял. В таком случае утилиту обработки файлов переименую в poisk-add, велю ей список файлов принимать на stdin, а poisk-scanner сделаю оберткой. Best regards, Alexey Pechnikov. http://pechnikov.tel/
Re: Анонс: легковесная система полнотекстового поиска
On 2010.02.05 at 22:14:15 +0300, Alexey Pechnikov wrote: > > Откуда стремление засунуть эту логику обязательно в индексатор? > Пожалуй, и проверку Ну юзерский это подход. Индексатор это та штука, вызов которой надо засунуть в crontab, чтобы потом поиск работал. А вовсе не то, что кладет в базу данных информацию о конкретном файле. Потому что юзер имеет дело с индексатором именно в этом месте - прописать в кронтаб, и добавить - здесь читать, здесь не читать, здесь рыбу заворачивали. А что там оно будет внутри себя делать с тем, что велели читать - его глубоко внутреннее дело. -- To UNSUBSCRIBE, email to debian-russian-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: Анонс: легковесная система полнотекстового поиска
Alexey Pechnikov -> debian-russian@lists.debian.org @ Fri, 5 Feb 2010 19:03:57 +0300: >> >> Можно проверять дату последней модификации файла до вычисления хэша и >> >> определения типа mime. Это значительно ускорит повторное сканирование. >> > >> > Проверка по mtime имхо совершенно ненадежна, предпочитаю по хэшу. >> >> Можно ещё размер проверять (всё равно хранится). Или, для параноиков, >> idev:inode. AP> А вот это не годится. Данные могут быть перемещены на другой диск AP> или даже на другой компьютер, это не повод их переиндексировать. А у тебя переиндексация точно существенно дороже, чем md5? -- If a `religion' is defined to be a system of ideas that contains unprovable statements, then Godel taught us that mathematics is not only a religion, it is the only religion that can prove itself to be one. -- John Barrow -- To UNSUBSCRIBE, email to debian-russian-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: Анонс: легковесная система полнотекстового поиска
Hello! On Friday 05 February 2010 21:34:35 Dmitri V. Ivanov wrote: > > Хэш - он не для поиска новых файлов, а для проверки необходимости > > переиндексировать. Если хэш совпадает, индексатор с чистой совестью может > > игнорировать файл. > > Если система у нас - linux или freebsd (есть тонкие моменты в стандарте > posix), > то для того, чтобы знать, что файл не менялся - достаточно ctime и списка > каталогов > с их inode numbers. И можно с чистой совестью игнорировать. А посчитать хэш - > это как > минимум прочесть файл с диска. Тот же gnu tar такое внутри себя умеет. > Впрочем - дело > ваше. Откуда стремление засунуть эту логику обязательно в индексатор? Пожалуй, и проверку хэша нужно выкинуть, оставив только безусловную индексацию. А вот описанный вами алгоритм очень подходит в качестве обертки к индексатору, как я уже и писал выше. Best regards, Alexey Pechnikov. http://pechnikov.tel/
Re: Анонс: легковесная система полнотекстового поиска
On Fri, Feb 05, 2010 at 08:36:11PM +0300, Alexey Pechnikov wrote: > Hello! > > On Friday 05 February 2010 20:15:18 Dmitri V. Ivanov wrote: > > Вообще-то я писал на эту тему скриптик (поиск файлов, измененных с > > предыдущего > > прохода в posix-овой файловой системе) и могу поделиться, если интересно. > > На perl. > > Да, интересно, в качестве обертки к индексатору. > > > А хэш IMHO излишество. > > Хэш - он не для поиска новых файлов, а для проверки необходимости > переиндексировать. Если хэш совпадает, индексатор с чистой совестью может > игнорировать файл. Если система у нас - linux или freebsd (есть тонкие моменты в стандарте posix), то для того, чтобы знать, что файл не менялся - достаточно ctime и списка каталогов с их inode numbers. И можно с чистой совестью игнорировать. А посчитать хэш - это как минимум прочесть файл с диска. Тот же gnu tar такое внутри себя умеет. Впрочем - дело ваше. WBR Dmitri Ivanov -- To UNSUBSCRIBE, email to debian-russian-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: Анонс: легковесная система полнотекстового поиска
Hello! On Friday 05 February 2010 20:15:18 Dmitri V. Ivanov wrote: > Вообще-то я писал на эту тему скриптик (поиск файлов, измененных с предыдущего > прохода в posix-овой файловой системе) и могу поделиться, если интересно. > На perl. Да, интересно, в качестве обертки к индексатору. > А хэш IMHO излишество. Хэш - он не для поиска новых файлов, а для проверки необходимости переиндексировать. Если хэш совпадает, индексатор с чистой совестью может игнорировать файл. Best regards, Alexey Pechnikov. http://pechnikov.tel/
Re: Анонс: легковесная система полнотекстового поиска
On Fri, Feb 05, 2010 at 07:11:29PM +0300, Alexey Pechnikov wrote: > Стоит решать названную задачу совсем другим методом. А именно - команда find > с нужными параметрами выбирает файлы, к примеру, изменившиеся за последние > 24 часа и скармливает их список индексатору. Задача последнего - обновить > поисковый индекс при необходимости. Сам, кстати предпочитаю запускать > утилиту inotifywait, которая при добавлении/удалении файла вызывает нужный > скрипт обновления поискового индекса. Команд find не отследит переименования каталога, содержащего файл (к нему не обращались, timestamp изменился у самого переименованного каталога или его предка). WBR Dmirti Ivanov -- To UNSUBSCRIBE, email to debian-russian-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: Анонс: легковесная система полнотекстового поиска
On Fri, Feb 05, 2010 at 06:18:57PM +0300, Alexey Pechnikov wrote: > Hello! > > On Friday 05 February 2010 18:13:24 Serhiy Storchaka wrote: > > Можно проверять дату последней модификации файла до вычисления хэша и > > определения типа mime. Это значительно ускорит повторное сканирование. > > Проверка по mtime имхо совершенно ненадежна, предпочитаю по хэшу. Вообще-то я писал на эту тему скриптик (поиск файлов, измененных с предыдущего прохода в posix-овой файловой системе) и могу поделиться, если интересно. На perl. А хэш IMHO излишество. WBR Dmitri Ivanov -- To UNSUBSCRIBE, email to debian-russian-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: Анонс: легковесная система полнотекстового поиска
Hello! On Friday 05 February 2010 19:25:15 Victor Wagner wrote: > > > Можно ещё размер проверять (всё равно хранится). Или, для параноиков, > > > idev:inode. > > > > А вот это не годится. Данные могут быть перемещены на другой диск или даже > > на > > другой компьютер, это не повод их переиндексировать. > > Это повод пересчитать хэш, и убедиться что данные те же самые. Совершенно верно. Потому у меня индексатор как раз пересчитывает хэш, полагая, что вызвавшее его приложение уже подумало о mtime и проч. А если всю логику засунуть в индексатор, получим очередного монолитного монстра, который нельзя для себя настроить именно так, как хочется. Best regards, Alexey Pechnikov. http://pechnikov.tel/
Re: Анонс: легковесная система полнотекстового поиска
On 2010.02.05 at 19:03:57 +0300, Alexey Pechnikov wrote: > Hello! > > On Friday 05 February 2010 18:47:19 Serhiy Storchaka wrote: > > > On Friday 05 February 2010 18:13:24 Serhiy Storchaka wrote: > > >> Можно проверять дату последней модификации файла до вычисления хэша и > > >> определения типа mime. Это значительно ускорит повторное сканирование. > > > > > > Проверка по mtime имхо совершенно ненадежна, предпочитаю по хэшу. > > > > Можно ещё размер проверять (всё равно хранится). Или, для параноиков, > > idev:inode. > > А вот это не годится. Данные могут быть перемещены на другой диск или даже на > другой компьютер, это не повод их переиндексировать. Это повод пересчитать хэш, и убедиться что данные те же самые. -- To UNSUBSCRIBE, email to debian-russian-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: Анонс: легковесная система полнотекстового поиска
On 2010.02.05 at 17:54:25 +0200, Serhiy Storchaka wrote: > Victor Wagner wrote: > > On 2010.02.05 at 18:18:57 +0300, Alexey Pechnikov wrote: > >> Проверка по mtime имхо совершенно ненадежна, предпочитаю по хэшу. > > > > Зато - быстра. И то недостаточно Вот FBReader при старте делает mtime > > всем файлам, которые уже видел, так если его на миррор lib.rus.ec > > напустить, будет несколько минут взлетать (в смысле при повторном старте, > > когда индекс библиотеки уже построен). > > А при повторном запуске (пока дисковые кеши свежи)? Не проверял. Но для случая ежесуточно запускающегося дискового индексатотора это все равно неактуально. > > -- > To UNSUBSCRIBE, email to debian-russian-requ...@lists.debian.org > with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org > -- To UNSUBSCRIBE, email to debian-russian-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: Анонс: легковесная система полнотекстового поиска
Hello! On Friday 05 February 2010 18:25:46 Victor Wagner wrote: > > Проверка по mtime имхо совершенно ненадежна, предпочитаю по хэшу. > > Зато - быстра. И то недостаточно Вот FBReader при старте делает mtime > всем файлам, которые уже видел, так если его на миррор lib.rus.ec > напустить, будет несколько минут взлетать (в смысле при повторном старте, > когда индекс библиотеки уже построен). > > То есть при каждой перенидексации домашней директории (в которой лежат > сотни гигов всякого барахла - кино, исходников, фотографий) считать хэш > от всего этого безобразия - недопустимо большие накладные расходы. Стоит решать названную задачу совсем другим методом. А именно - команда find с нужными параметрами выбирает файлы, к примеру, изменившиеся за последние 24 часа и скармливает их список индексатору. Задача последнего - обновить поисковый индекс при необходимости. Сам, кстати предпочитаю запускать утилиту inotifywait, которая при добавлении/удалении файла вызывает нужный скрипт обновления поискового индекса. Best regards, Alexey Pechnikov. http://pechnikov.tel/
Re: Анонс: легковесная система полнотекстового поиска
Hello! On Friday 05 February 2010 18:47:19 Serhiy Storchaka wrote: > > On Friday 05 February 2010 18:13:24 Serhiy Storchaka wrote: > >> Можно проверять дату последней модификации файла до вычисления хэша и > >> определения типа mime. Это значительно ускорит повторное сканирование. > > > > Проверка по mtime имхо совершенно ненадежна, предпочитаю по хэшу. > > Можно ещё размер проверять (всё равно хранится). Или, для параноиков, > idev:inode. А вот это не годится. Данные могут быть перемещены на другой диск или даже на другой компьютер, это не повод их переиндексировать. > >> И разве в tcllib нет реализации md5, что дёргается внешний бинарник? > > > > Покамест tcllib не использую, ради md5 не хочется лишнюю зависимость > > тянуть. А так в моей сборке sqlite есть функция вычисления md5 для файла, > > но это не всем удобно будет. > > Ещё меня удивляет, зачем там утилиты на C. Ведь на том же тикле можно > записать проще и понятнее. Можно, только время запуска тиклевого интерпретатора на порядок больше. И если логика индексации достаточна сложная и требует времени, то поиск должен быть максимально ускорен. Раньше у меня в веб-портал была встроена работа с БД поискового индекса, а теперь использую вызов внешних утилит - на коре квадро порядка 1000 поисковых запросов в секунду отрабатывает, что значительно превышает мои потребности (насколько помню, у яху пиковая нагрузка несколько лет назад составляла около 15 000 запросов в секунду). Собственно, сейчас делаю вариант, где и листинг директорий шелловским скриптом генерируется. Накладные расходы выше, зато легко можно индексировать и архивы, причем как распаковывая их, так и монтируя через fusе и т.п. Потом можно оптимизировать, переписав требуемые скрипты на тикле и включая их в индексатор лишь единожды при запуске. Best regards, Alexey Pechnikov. http://pechnikov.tel/
Re: Анонс: легковесная система полнотекстового поиска
Victor Wagner wrote: > On 2010.02.05 at 18:18:57 +0300, Alexey Pechnikov wrote: >> Проверка по mtime имхо совершенно ненадежна, предпочитаю по хэшу. > > Зато - быстра. И то недостаточно Вот FBReader при старте делает mtime > всем файлам, которые уже видел, так если его на миррор lib.rus.ec > напустить, будет несколько минут взлетать (в смысле при повторном старте, > когда индекс библиотеки уже построен). А при повторном запуске (пока дисковые кеши свежи)? -- To UNSUBSCRIBE, email to debian-russian-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: Анонс: легковесная система полнотекстового поиска
Alexey Pechnikov wrote: > On Friday 05 February 2010 18:13:24 Serhiy Storchaka wrote: >> Можно проверять дату последней модификации файла до вычисления хэша и >> определения типа mime. Это значительно ускорит повторное сканирование. > > Проверка по mtime имхо совершенно ненадежна, предпочитаю по хэшу. Можно ещё размер проверять (всё равно хранится). Или, для параноиков, idev:inode. >> И разве в tcllib нет реализации md5, что дёргается внешний бинарник? > > Покамест tcllib не использую, ради md5 не хочется лишнюю зависимость > тянуть. А так в моей сборке sqlite есть функция вычисления md5 для файла, > но это не всем удобно будет. Ещё меня удивляет, зачем там утилиты на C. Ведь на том же тикле можно записать проще и понятнее. -- To UNSUBSCRIBE, email to debian-russian-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: Анонс: легковесная система полнотекстового поиска
On 2010.02.05 at 18:18:57 +0300, Alexey Pechnikov wrote: > Проверка по mtime имхо совершенно ненадежна, предпочитаю по хэшу. Зато - быстра. И то недостаточно Вот FBReader при старте делает mtime всем файлам, которые уже видел, так если его на миррор lib.rus.ec напустить, будет несколько минут взлетать (в смысле при повторном старте, когда индекс библиотеки уже построен). То есть при каждой перенидексации домашней директории (в которой лежат сотни гигов всякого барахла - кино, исходников, фотографий) считать хэш от всего этого безобразия - недопустимо большие накладные расходы. > > И разве в tcllib нет реализации md5, что дёргается внешний бинарник? > > Покамест tcllib не использую, ради md5 не хочется лишнюю зависимость тянуть. Не хочется тянуть - выгрызи ее оттуда и положи к себе в скрипт. -- To UNSUBSCRIBE, email to debian-russian-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: Анонс: легковесная система полнотекстового поиска
Hello! On Friday 05 February 2010 18:13:24 Serhiy Storchaka wrote: > Можно проверять дату последней модификации файла до вычисления хэша и > определения типа mime. Это значительно ускорит повторное сканирование. Проверка по mtime имхо совершенно ненадежна, предпочитаю по хэшу. > И разве в tcllib нет реализации md5, что дёргается внешний бинарник? Покамест tcllib не использую, ради md5 не хочется лишнюю зависимость тянуть. А так в моей сборке sqlite есть функция вычисления md5 для файла, но это не всем удобно будет. Best regards, Alexey Pechnikov. http://pechnikov.tel/
Re: Анонс: легковесная система полнотекстового поиска
Можно проверять дату последней модификации файла до вычисления хэша и определения типа mime. Это значительно ускорит повторное сканирование. И разве в tcllib нет реализации md5, что дёргается внешний бинарник? -- To UNSUBSCRIBE, email to debian-russian-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: Анонс: легковесная система полнотекстового поиска
Hello! On Friday 05 February 2010 13:59:21 Artem Chuprina wrote: > AP> Это похоже на правду. Но в таком случае от использования exec весьма > AP> сомнительная польза, а на серверах так и вовсе. > > На двух четырехъядерниках (в смысле один сервер с двумя > четырехъядерниками) все тот же самый закономерный результат - от exec в > среднем около 20% выигрыша. Хорошо, сделаю фильтры с exec. Частота у меня на лаптопе действительно плавающая, так что именно на ноутбуке результаты можно считать казусом. Best regards, Alexey Pechnikov. http://pechnikov.tel/
Re: Анонс: легковесная система полнотекстового поиска
Alexander Galanin wrote: > On Thu, 4 Feb 2010 22:17:31 +0300 > Alexey Pechnikov wrote: > >> Итого с exec почти вдвое медленнее. >> >> cpu cores: 2 > ^^^ --- наверно, тут собака зарыта > > Потому как я на однопроцессорных машинах проверял и exec закономерно > выигрывал. У меня двухъядерник. На 4-ядернике та же картина. -- To UNSUBSCRIBE, email to debian-russian-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: Анонс: легковесная система полнотекстового поиска
Alexey Pechnikov wrote: > = > $ cat ./x-c > #!/bin/dash > > exec /bin/cat > > $ time seq 1000 | xargs -n 1 ./x-c /dev/null а) 1, а не 1000. б) Куда делся "$1"? в) Отсутствует >/dev/null. У меня это на тенденцию не влияет, а как у вас — не знаю. -- To UNSUBSCRIBE, email to debian-russian-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: Анонс: легковесная система полнотекстового поиска
Hello! On Thursday 04 February 2010 22:25:12 Alexander Galanin wrote: > > Итого с exec почти вдвое медленнее. > > > > cpu cores : 2 > ^^^ --- наверно, тут собака зарыта > > Потому как я на однопроцессорных машинах проверял и exec закономерно > выигрывал. Это похоже на правду. Но в таком случае от использования exec весьма сомнительная польза, а на серверах так и вовсе. Best regards, Alexey Pechnikov. http://pechnikov.tel/
Re: Анонс: легковесная система полнотекстового поиска
Hello! On Thursday 04 February 2010 22:09:23 Alexander Galanin wrote: > On Thu, 4 Feb 2010 22:03:38 +0300 > Alexey Pechnikov wrote: > > > Hello! > > > > On Thursday 04 February 2010 21:37:49 Alexander Galanin wrote: > > > cat в некоторых шеллах встроенный, потому и может оказаться быстрее. Для > > > чистоты эксперимента надо вызывать /bin/cat. > > > > Да как ни вызывай, с exec медленнее: > > Следи за руками :) Вы результаты не иначе как в текстовом редакторе набираете? :-) > $ cat x-c > #!/bin/dash > exec /bin/cat > $ /usr/bin/time sh -c "seq 1000 | xargs -n 1 ./x-c /dev/null" > 0.42user 0.98system 0:01.41elapsed 100%CPU (0avgtext+0avgdata 0maxresident)k > 0inputs+0outputs (0major+341097minor)pagefaults 0swaps $ /usr/bin/time sh -c "seq 1000 | xargs -n 1 ./x-c /dev/null" 0.76user 1.93system 0:02.70elapsed 99%CPU (0avgtext+0avgdata 5504maxresident)k 0inputs+128outputs (0major+317926minor)pagefaults 0swaps > $ cat x-c > #!/bin/dash > /bin/cat > $ /usr/bin/time sh -c "seq 1000 | xargs -n 1 ./x-c /dev/null" > 0.54user 1.21system 0:01.77elapsed 99%CPU (0avgtext+0avgdata 0maxresident)k > 0inputs+0outputs (0major+395531minor)pagefaults 0swaps $ /usr/bin/time sh -c "seq 1000 | xargs -n 1 ./x-c /dev/null" 0.34user 1.18system 0:01.68elapsed 91%CPU (0avgtext+0avgdata 5520maxresident)k 0inputs+248outputs (0major+370276minor)pagefaults 0swaps Итого с exec почти вдвое медленнее. $ uname -a Linux veter-laptop.mobigroup.ru 2.6.32-trunk-686 #1 SMP Sun Jan 10 06:32:16 UTC 2010 i686 GNU/Linux $ cat /proc/cpuinfo processor : 0 vendor_id : GenuineIntel cpu family : 6 model : 15 model name : Intel(R) Core(TM)2 Duo CPU T5470 @ 1.60GHz stepping: 13 cpu MHz : 800.000 cache size : 2048 KB physical id : 0 siblings: 2 core id : 0 cpu cores : 2 apicid : 0 initial apicid : 0 fdiv_bug: no hlt_bug : no f00f_bug: no coma_bug: no fpu : yes fpu_exception : yes cpuid level : 10 wp : yes flags : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm pbe nx lm constant_tsc arch_perfmon pebs bts aperfmperf pni dtes64 monitor ds_cpl est tm2 ssse3 cx16 xtpr pdcm lahf_lm ida bogomips: 3191.94 clflush size: 64 cache_alignment : 64 address sizes : 36 bits physical, 48 bits virtual power management: ... Best regards, Alexey Pechnikov. http://pechnikov.tel/
Re: Анонс: легковесная система полнотекстового поиска
Hello! On Thursday 04 February 2010 21:37:49 Alexander Galanin wrote: > cat в некоторых шеллах встроенный, потому и может оказаться быстрее. Для > чистоты эксперимента надо вызывать /bin/cat. Да как ни вызывай, с exec медленнее: = $ cat ./x-c #!/bin/dash exec /bin/cat $ time seq 1000 | xargs -n 1 ./x-c /dev/null real0m2.726s user0m0.728s sys 0m1.948s = $ cat ./x-c #!/bin/dash /bin/cat $ time seq 1000 | xargs -n 1 ./x-c /dev/null real0m2.135s user0m0.496s sys 0m1.552s = И аналогично с баш: = $ cat ./x-c #!/bin/bash exec /bin/cat $ time seq 1000 | xargs -n 1 ./x-c /dev/null real0m4.778s user0m2.300s sys 0m2.352s = $ cat ./x-c #!/bin/bash /bin/cat $ time seq 1000 | xargs -n 1 ./x-c /dev/null real0m2.681s user0m1.204s sys 0m1.472s Best regards, Alexey Pechnikov. http://pechnikov.tel/
Re: Анонс: легковесная система полнотекстового поиска
Alexander Galanin wrote: > cat в некоторых шеллах встроенный, потому и может оказаться быстрее. Для > чистоты эксперимента надо вызывать /bin/cat. Да, это бы объяснило. -- To UNSUBSCRIBE, email to debian-russian-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: Анонс: легковесная система полнотекстового поиска
Alexey Pechnikov wrote: > On Thursday 04 February 2010 21:28:23 Serhiy Storchaka wrote: >> > Еще какая разница - с exec _втрое медленнее_. >> >> Не верю. Можно объяснить ускорение, можно понять отсутствие заметной >> разницы, — замедление объяснить нельзя. > > Попробуйте свой же тест выполнить, сами увидите. Чего и вам желаю. -- To UNSUBSCRIBE, email to debian-russian-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: Анонс: легковесная система полнотекстового поиска
On Thu, 04 Feb 2010 20:28:23 +0200 Serhiy Storchaka wrote: > Alexey Pechnikov wrote: > > On Thursday 04 February 2010 19:43:40 Serhiy Storchaka wrote: > >> Не только. Вероятно сам fork (за которым потом всё равно следует exec) > >> всё же дорог. Попробуйте > >> > >> time seq 1 | xargs -n 1 ./x-c /dev/null >/dev/null > >> > >> и то же с exec в x-c. Разница есть. > >> > > > > Еще какая разница - с exec _втрое медленнее_. > > Не верю. Можно объяснить ускорение, можно понять отсутствие заметной > разницы, — замедление объяснить нельзя. cat в некоторых шеллах встроенный, потому и может оказаться быстрее. Для чистоты эксперимента надо вызывать /bin/cat. -- Alexander Galanin pgpJLBRpqEMwp.pgp Description: PGP signature
Re: Анонс: легковесная система полнотекстового поиска
On Thu, 4 Feb 2010 20:32:39 +0300 Alexey Pechnikov wrote: > Hello! > > On Thursday 04 February 2010 20:15:48 Alexander Galanin wrote: > > > > > Recommends и depends нынче эквивалентны. Разве что в Suggests > > > > > поставить. > > > > > > > > От Recommends отказаться можно. От Depends — нет. > > > > > > Э-э-э, по дефолту они ведут себя одинаково, так что разница неощутима. > > > > Это такой новый подстиль мазохизма "сидеть с дефолтными настройками"? > > Имхо первое правило - на серверах оставлять дефолтовые настройки и дефолтовое > ядро. Иначе не обессудьте, если вскоре вам придется лететь через полстраны, > если Да-да, и пароль "пароль". Добавляет пикантности то, что это говорит любитель накладывать "левые" патчи на qmail. > не через полмира (за свой счет, разумеется). Кроме того, мантейнер обязан > обеспечивать работу пакета именно на дефолтовой системе. И обязательно в вакууме, иначе никак. Самому не смешно? -- Alexander Galanin pgpKA00oK4ruX.pgp Description: PGP signature
Re: Анонс: легковесная система полнотекстового поиска
Hello! On Thursday 04 February 2010 21:28:23 Serhiy Storchaka wrote: > > Еще какая разница - с exec _втрое медленнее_. > > Не верю. Можно объяснить ускорение, можно понять отсутствие заметной > разницы, — замедление объяснить нельзя. Попробуйте свой же тест выполнить, сами увидите. Best regards, Alexey Pechnikov. http://pechnikov.tel/
Re: Анонс: легковесная система полнотекстового поиска
Alexey Pechnikov wrote: > On Thursday 04 February 2010 19:48:25 Serhiy Storchaka wrote: >> > Recommends и depends нынче эквивалентны. Разве что в Suggests >> > поставить. >> >> От Recommends отказаться можно. От Depends — нет. > > Э-э-э, по дефолту они ведут себя одинаково, так что разница неощутима. Ну, пакет ваш, дело ваше. -- To UNSUBSCRIBE, email to debian-russian-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: Анонс: легковесная система полнотекстового поиска
Alexey Pechnikov wrote: > On Thursday 04 February 2010 19:43:40 Serhiy Storchaka wrote: >> Не только. Вероятно сам fork (за которым потом всё равно следует exec) >> всё же дорог. Попробуйте >> >> time seq 1 | xargs -n 1 ./x-c /dev/null >/dev/null >> >> и то же с exec в x-c. Разница есть. >> > > Еще какая разница - с exec _втрое медленнее_. Не верю. Можно объяснить ускорение, можно понять отсутствие заметной разницы, — замедление объяснить нельзя. -- To UNSUBSCRIBE, email to debian-russian-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: Анонс: легковесная система полнотекстового поиска
Hello! On Thursday 04 February 2010 20:15:48 Alexander Galanin wrote: > > > > Recommends и depends нынче эквивалентны. Разве что в Suggests поставить. > > > > > > От Recommends отказаться можно. От Depends — нет. > > > > Э-э-э, по дефолту они ведут себя одинаково, так что разница неощутима. > > Это такой новый подстиль мазохизма "сидеть с дефолтными настройками"? Имхо первое правило - на серверах оставлять дефолтовые настройки и дефолтовое ядро. Иначе не обессудьте, если вскоре вам придется лететь через полстраны, если не через полмира (за свой счет, разумеется). Кроме того, мантейнер обязан обеспечивать работу пакета именно на дефолтовой системе. Best regards, Alexey Pechnikov. http://pechnikov.tel/
Re: Анонс: легковесная система полнотекстового поиска
On Thu, 4 Feb 2010 19:59:42 +0300 Alexey Pechnikov wrote: > Hello! > > On Thursday 04 February 2010 19:48:25 Serhiy Storchaka wrote: > > > Recommends и depends нынче эквивалентны. Разве что в Suggests поставить. > > > > От Recommends отказаться можно. От Depends — нет. > > Э-э-э, по дефолту они ведут себя одинаково, так что разница неощутима. Это такой новый подстиль мазохизма "сидеть с дефолтными настройками"? -- Alexander Galanin pgptUcUWfYdSE.pgp Description: PGP signature
Re: Анонс: легковесная система полнотекстового поиска
Hello! On Thursday 04 February 2010 19:43:40 Serhiy Storchaka wrote: > Не только. Вероятно сам fork (за которым потом всё равно следует exec) всё > же дорог. Попробуйте > > time seq 1 | xargs -n 1 ./x-c /dev/null >/dev/null > > и то же с exec в x-c. Разница есть. > Еще какая разница - с exec _втрое медленнее_. Best regards, Alexey Pechnikov. http://pechnikov.tel/
Re: Анонс: легковесная система полнотекстового поиска
Hello! On Thursday 04 February 2010 19:48:25 Serhiy Storchaka wrote: > > Recommends и depends нынче эквивалентны. Разве что в Suggests поставить. > > От Recommends отказаться можно. От Depends — нет. Э-э-э, по дефолту они ведут себя одинаково, так что разница неощутима. > > Suggests придется ручками доставлять, а мне бы хотелось автоматизма. > > Вот sqlite3, насколько я понимаю, можно в Suggests или вообще убрать. Да, можно, эскулайтовский шелл не требуется, достаточно либы. Best regards, Alexey Pechnikov. http://pechnikov.tel/
Re: Анонс: легковесная система полнотекстового поиска
Alexey Pechnikov wrote: > Recommends и depends нынче эквивалентны. Разве что в Suggests поставить. От Recommends отказаться можно. От Depends — нет. > Suggests придется ручками доставлять, а мне бы хотелось автоматизма. Вот sqlite3, насколько я понимаю, можно в Suggests или вообще убрать. -- To UNSUBSCRIBE, email to debian-russian-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: Анонс: легковесная система полнотекстового поиска
Artem Chuprina wrote: > Alexey Pechnikov -> debian-russian@lists.debian.org @ Thu, 4 Feb 2010 > 16:28:42 +0300: > AP> А можете подробнее рассказать? Я не в курсе, что с exec может быть > быстрее. > > На самом деле быстрее - вряд ли. Это потеря скорее в памяти. exec - > запуск без fork, с заменой бинаря по месту. В результате запустивший > процесс не ждет завершения запущенной команды, оставаясь шеллом и тратя > память, а сам ею становится. Не только. Вероятно сам fork (за которым потом всё равно следует exec) всё же дорог. Попробуйте time seq 1 | xargs -n 1 ./x-c /dev/null >/dev/null и то же с exec в x-c. Разница есть. -- To UNSUBSCRIBE, email to debian-russian-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: Анонс: легковесная система полнотекстового поиска
Hello! On Thursday 04 February 2010 17:36:32 Artem Chuprina wrote: > Alexey Pechnikov -> debian-russian@lists.debian.org @ Thu, 4 Feb 2010 > 16:28:42 +0300: > > >> Тогда уж exec cat — ещё 20% выигрыша. > > AP> А можете подробнее рассказать? Я не в курсе, что с exec может быть > быстрее. > > На самом деле быстрее - вряд ли. Это потеря скорее в памяти. exec - > запуск без fork, с заменой бинаря по месту. В результате запустивший > процесс не ждет завершения запущенной команды, оставаясь шеллом и тратя > память, а сам ею становится. Попробую. > >> От untex, unrtf и т.п. зависимость должна быть мягкой. > > AP> Это можно, поправлю. > > >> А кое где даже > >> вариативной — wv и unrtf можно заменить catdoc, antiword или word2x, для > >> w3m тоже куча альтернатив (включая w3mmee). Recommends и depends нынче эквивалентны. Разве что в Suggests поставить. > AP> Нельзя заменить - форматирование слетит. > > Зато, возможно, начнут читаться документы от доюникодного ворда - catdoc > это умеет, а wv, помнится, нет. У тебя там как раз в примерах был файл, > title у которого, судя по выводу, еще с тех времен тянется :-) Метаинформация утилитой extract из одноменного пакета обрабатывается, фильтры здесь ни при чем. А наибольшие проблемы с pdf возникают. > AP> А при указанных сейчас зависимостях полученный plain text сохраняет > AP> даже вордовские таблички, так что можно оригинальный документ и > AP> вовсе не скачивать, обходясь без опенофиса и малой толикой > AP> интернет-трафика. > > Ну, собственно, если сделать зависимости мягкими, то все станет гораздо > лучше. Ибо если уперлось, то подсунуть фильтром catdoc, я думаю, > реально - исходник-то есть... Suggests придется ручками доставлять, а мне бы хотелось автоматизма. Best regards, Alexey Pechnikov. http://pechnikov.tel/
Re: Анонс: легковесная система полнотекстового поиска
Hello! On Thursday 04 February 2010 15:20:45 Serhiy Storchaka wrote: > Тогда уж exec cat — ещё 20% выигрыша. А можете подробнее рассказать? Я не в курсе, что с exec может быть быстрее. > От untex, unrtf и т.п. зависимость должна быть мягкой. Это можно, поправлю. > А кое где даже > вариативной — wv и unrtf можно заменить catdoc, antiword или word2x, для > w3m тоже куча альтернатив (включая w3mmee). Нельзя заменить - форматирование слетит. А при указанных сейчас зависимостях полученный plain text сохраняет даже вордовские таблички, так что можно оригинальный документ и вовсе не скачивать, обходясь без опенофиса и малой толикой интернет-трафика. Best regards, Alexey Pechnikov. http://pechnikov.tel/
Re: Анонс: легковесная система полнотекстового поиска
Alexey Pechnikov wrote: > On Thursday 04 February 2010 11:29:40 Serhiy Storchaka wrote: >> Разве dash распространён за пределами Дебиана? > > Не могу сказать. Но запускается он вдвое быстрее, чем bash, > и на обработке большого количества небольших документов > выигрыш при использовании dash весьма заметен. Так что для > запуска в другой ОС или поставить dash или поправить в > фильтрах на bash (потеряв около 20% в производительности). Тогда уж exec cat — ещё 20% выигрыша. От untex, unrtf и т.п. зависимость должна быть мягкой. А кое где даже вариативной — wv и unrtf можно заменить catdoc, antiword или word2x, для w3m тоже куча альтернатив (включая w3mmee). -- To UNSUBSCRIBE, email to debian-russian-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: Анонс: легковесная система полнотекстового поиска
Hello! On Thursday 04 February 2010 11:29:40 Serhiy Storchaka wrote: > Разве dash распространён за пределами Дебиана? Не могу сказать. Но запускается он вдвое быстрее, чем bash, и на обработке большого количества небольших документов выигрыш при использовании dash весьма заметен. Так что для запуска в другой ОС или поставить dash или поправить в фильтрах на bash (потеряв около 20% в производительности). Best regards, Alexey Pechnikov. http://pechnikov.tel/
Re: Анонс: легковесная система полнотекстового поиска
Разве dash распространён за пределами Дебиана? -- To UNSUBSCRIBE, email to debian-russian-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: Анонс: легковесная система полнотекстового поиска
Hello! On Thursday 04 February 2010 01:44:58 Artem Chuprina wrote: > Эээ... А ты не мог бы это описание по-русски написать? Я б тогда тебе > его на английский перевел... А то... нет, по большей части можно > догадаться, что ты имел в виду. Но смысл из этой грамматики приходится > выковыривать. Добавил и русскоязычное описание. Best regards, Alexey Pechnikov. http://pechnikov.tel/
Re: Анонс: легковесная система полнотекстового поиска
Alexey Pechnikov -> debian-russian@lists.debian.org @ Wed, 3 Feb 2010 23:48:34 +0300: AP> Ранее я уже упоминал, почему меня не устраивают существующие. AP> Вот добрался сделать краткое описание своей разработки, AP> используемой для некоторых коммерческих веб-проектов. Пакет AP> содержит набор из нескольких утилит, каждая из которых выполняет AP> определенную задачу. Все утилиты, кроме файлового сканера, AP> написаны на С и работают достаточно быстро для того, чтобы их AP> запускать как отдельные процессы даже на нагруженной системе. AP> http://sqlite.mobigroup.ru/src/wiki?name=sqlite3-poisk Эээ... А ты не мог бы это описание по-русски написать? Я б тогда тебе его на английский перевел... А то... нет, по большей части можно догадаться, что ты имел в виду. Но смысл из этой грамматики приходится выковыривать. Впрочем, надо еще на код посмотреть... -- Пришел в гости математик, почитать новую рукопись. Вычитал из нее трех героев напрочь, и ушел. Gimli on #arda -- To UNSUBSCRIBE, email to debian-russian-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
