Господа, обьясните пожалуйста:
Чем Рыжик лучше squidGuard?
Спасибо заранее
Сравнение
Просто любое сравнение субъективно. Конечно я могу расхваливать режик и ругать гуард, но кто мне поверит? Все подумают, что автор рекламирует свою программу. Потому и предложил воспользоваться поиском и почитать, что другие о режике пишут.Ильгиз писал(а):Отличный ответ, ничего не скажешь.
По докам я не видел того, что рыжик лучше.
А то, что второй ругают а рыжика нет вполне может быть следствием того, что гуардом пользуются....
Я же тоже вот наткнулся на рыжика и спросил.
Я не прошу ругать. Я прошу написать те причины, почему был "зачат" ежик. Что не нравилось в остальных, чего не хватало, и чего есть в ежике.
Кстати нашел только одно сравнение по адресу
http://www.mail-archive.com/oops@lists. ... 04693.html
Ниже приведены основные результаты оттуда. Если это действительно так, то попробовать стоит.
Вот кстати предварительные результаты:
Оба написаны на C, но в случае с rejik используется не встроенная в glibc
библиотека для работы с регулярными выражениями, а pcre (www.pcre.org).
Squidguard для работы с url использует libdb3. Но даже не принимая во
внимание работу с regex видно, что rejik опережает. Вот и хочу добавить в
этот же тест еще и oops (точнее модуль редиректора).
wc -l http.log: 661'625 (содержит только баннеры, счетчики, js,
~85Mb)
wc -l month.log: 4'557'435 (запросы за месяц в перемешку с нормальными,
~285Mb)
1. Проверка (по средним результатам из 3-х запусков) в случае использования
только urls для редиректов:
rejik (http.log): 0m5.8s
squidguard (http.log): 0m17.2s, почти в 3 раза медленнее
rejik (month.log): 0m34s
squidguard (month.log): 1m50s, ~3.2
2. Проверка в случае использования только regex для редиректоров:
rejik (http.log): 0m35s
squidguard (http.log): 1m30s, ~2.6
rejik (month.log): 3m7s
squidguard (month.log): 9m55s, ~3.2
3. Проверка в случае совместного использования (пункт 1+2):
rejik (http.log): 0m15s
squidguard (http.log): 1m23s, ~5(!)
rejik (month.log): 3m1s
squidguard (month.log): 11m30s, ~3.8
Кстати нашел только одно сравнение по адресу
http://www.mail-archive.com/oops@lists. ... 04693.html
Ниже приведены основные результаты оттуда. Если это действительно так, то попробовать стоит.
Вот кстати предварительные результаты:
Оба написаны на C, но в случае с rejik используется не встроенная в glibc
библиотека для работы с регулярными выражениями, а pcre (www.pcre.org).
Squidguard для работы с url использует libdb3. Но даже не принимая во
внимание работу с regex видно, что rejik опережает. Вот и хочу добавить в
этот же тест еще и oops (точнее модуль редиректора).
wc -l http.log: 661'625 (содержит только баннеры, счетчики, js,
~85Mb)
wc -l month.log: 4'557'435 (запросы за месяц в перемешку с нормальными,
~285Mb)
1. Проверка (по средним результатам из 3-х запусков) в случае использования
только urls для редиректов:
rejik (http.log): 0m5.8s
squidguard (http.log): 0m17.2s, почти в 3 раза медленнее
rejik (month.log): 0m34s
squidguard (month.log): 1m50s, ~3.2
2. Проверка в случае использования только regex для редиректоров:
rejik (http.log): 0m35s
squidguard (http.log): 1m30s, ~2.6
rejik (month.log): 3m7s
squidguard (month.log): 9m55s, ~3.2
3. Проверка в случае совместного использования (пункт 1+2):
rejik (http.log): 0m15s
squidguard (http.log): 1m23s, ~5(!)
rejik (month.log): 3m1s
squidguard (month.log): 11m30s, ~3.8
Наверное потому что хотелось иметь свою систему, в которой всегда можно что-то подкрутить под свои нужды.Ильгиз писал(а):Я не прошу ругать. Я прошу написать те причины, почему был "зачат" ежик. Что не нравилось в остальных, чего не хватало, и чего есть в ежике.
В принципе режик развился из перлового редиректора и желания помочь людям в деле фильтрации контекста. Как-то на форуме надоело постоянно отвечать на одни и те же вопросы "как заблокировать", "где взять", написал инструкцию по этому делу и выложил на бесплатном хостинге вместе со своими наработками. Как развивалось дальше можно прочесть в Changelog.
Посмотрите сколько лет назад вышла последняя версия squidguard.
Почитайте http://www.securitylab.ru/43996.html