Проект FreeBSD намерен сменить GCC на LLVM+Clang

>Ж)))
>Нифуя себе! Два года! ААААААААААААА!

Да-да.

>Профессионал выбирает FreeBSD, потому что у него нет времени "год-два" разбирать глюки stable.

Два года разбираются не глюки стэйбла, а планомерно обновляется большая инсталляция из сотен машин. FreeBSD такого времени мне не даст. Времени хватит на поддержание работы лишь десятков машин.

>А как безопасно обновить программы, если нет стабильной ветки портов/пакетов, где бы просто патчились дыры?

>Ещё раз для слепоглухонемых: новая версия порта программы == патчи и закрытие дыр этой программы. Здесь работают два персонажа: тот, кто выпустил ПО (автор-издатель), и тот, кто интегрировал ПО в коллекцию (мантейнер). Два раза не ошибаются.

Вы удивитесь, но схема разработчик+мэнтейнер принята не только в FreeBSD. И несмотря на ваш оптимизм, ошибки всё же случаются, причём потрясающе огромные - дырка в OpenSSL из Debian из той же оперы.

Мэнтейнер спрашивает: "Вот тут во время компиляции вылазит какое-то предупреждение, можно ли его убрать вот таким способом?" Один из разработчиков, почесав репу: "Да х.з., вроде можно." Мэнтейнер: "Отлично, тогда я исправлю." Получилось, что даже два персонажа сумели накосячить. При этом других хоть сколь-нибудь подобных косяков за всю историю Debian больше не припоминается. Инициатива наказуема.

>>А как часто нужно обновлять? Не превратятся ли эти обновления в перманентные обновления без ясной цели?

>Как выйдет — так и обновляй. Хуже не будет. :))

Это слова профессионала? Писец, я еле сдерживаюсь от смеха! Вот что значит обновление без целей: "Обновляйся, хуже не будет!"

>>В Debian нет понятия базовой системы, поэтому при переходе x.y-RELEASE => (x+1).z-RELEASE обновляется всё.

>Поэтому и риск обновлений в Debian большой.

Ну если мсье пользуется только базой без портов, то тогда пожалуй соглашусь. А вообще в целом Debian со всеми его пакетами тестируется _несравненно_ более тщательнее, чем одни только порты. Можно сказать что порты вообще не тестируются, а ошибки в них исправляются постфактум, то есть когда уже кто-то наступит на грабли и напишет багрепорт. Причём выбора нет - ты не можешь отказаться наступать на грабли: у тебя есть только current-ветка портов.

>>Например так. У меня есть старая система, допустим FreeBSD 5.x.

>Ветка 5.x не поддерживается. Потому вменяемым администраторам ниразу не нужна, кроме линуксойдов-неудачников.

Прихожу я на новое место после FreeBSD'шника-неудачника, а там FreeBSD 5.x. Сверхнадёжная и неуязвимая, а потому не обновлявшаяся несколько лет. И мне этот хлам даже раскрутить нормально без компиляции не удастся - даже грёбаный rsync поставить без обновления базы, портов, компиляции, обновления зависимостей. Пионерия в чистом виде. Если кто-то вовремя не обновил систему, а я знаю как правильно тратить своё время, то значит я теперь неудачник?

>Например так. У меня есть старая система, допустим FreeBSD 5.x.

Разве это старая??? :) Вот наш боевой сервер:

> uname -a
FreeBSD www.avias.local 4.11-STABLE FreeBSD 4.11-STABLE #7: Sun Jan 8 21:33:59 MSK 2006 root@www.avias.local:/usr/obj/usr/src/sys/WWW i386

:D

> Разве это старая??? :) Вот наш боевой сервер:

Тю! У меня 4.2-RELEASE FreeBSD 4.2-RELEASE #4 пашет. Под системой сменилось несколько материнок, несколько винтов, начиналось всё ещё на PII-233. Со временем нагрузка несколько уменьшилась, перенесли часть функцционала на пупер-друпер новотехнологичные системы с оракловыми серверами. С некоторым (реально малозначащим) ростом возможностей и катастрофическим падением юзабилити и скорости.

>Прихожу я на новое место после FreeBSD'шника-неудачника, а там FreeBSD 5.x. Сверхнадёжная и неуязвимая, а потому не обновлявшаяся несколько лет.

Ещё раз повторю аксиому: винчестеры столько не живут, сколько установленные на них системы. Железо, особенно механика, которая в режиме "24x365" ломается быстрее, чем операционные системы.
Может стоит задуматься об аппаратном апгрейде, пока не начали случаться чудеса?

>А вообще в целом Debian со всеми его пакетами тестируется _несравненно_ более тщательнее, чем одни только порты.

Может быть. Но из-за задержек на тестирование в репозиториях Debian появляется не совсем свежее ПО, в котором другие (на FreeBSD) давно уже исправили ошибки и/или пользуются новыми, более актуальными версиями.

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

Откуда такой вывод образовался?

>Причём выбора нет - ты не можешь отказаться наступать на грабли: у тебя есть только current-ветка портов.

Выбор всегда есть.

Например, деинсталлировать свежий пакет, который не понравился из-за своего поведения, и инсталлировать пакет старой версии — бинарный откат. Ранее собранные пакеты (.tbz) никуда не исчезают, если их не удаляют из каталога $PACKAGES специально.

>Разве это старая??? :) Вот наш боевой сервер:

>> uname -a
>FreeBSD www.avias.local 4.11-STABLE FreeBSD 4.11-STABLE #7: Sun Jan 8 21:33:59 MSK 2006 root@www.avias.local:/usr/obj/usr/src/sys/WWW i386

>:D

Количество дырок в ней и в установленном ПО неизвестно. Поставить на неё внезапно понадобившуюся фигню вроде какого-нибудь rsync неоткуда.

>Ещё раз повторю аксиому: винчестеры столько не живут, сколько установленные на них системы. Железо, особенно механика, которая в режиме "24x365" ломается быстрее, чем операционные системы.

Кстати, большинство поломок электроники обычно происходит при включении-выключении, то есть во время переходных процессов.

>Может стоит задуматься об аппаратном апгрейде, пока не начали случаться чудеса?

Аппаратный апгрейд аппаратным, а операционную систему без особой необходимости зачем обновлять?

>Но из-за задержек на тестирование в репозиториях Debian появляется не совсем свежее ПО, в котором другие (на FreeBSD) давно уже исправили ошибки и/или пользуются новыми, более актуальными версиями.

На момент выхода stable все обнаруженные в ПО критические ошибки исправляются. Критические ошибки - это ошибки в системе безопасности или ошибки, не позволяющие пользоваться основной функциональностью программы. С Debian stable я по крайней мере уверен, что программа не просто соберётся и запустится, но и будет выполнять своё основное предназначение. Некритические ошибки исправляются по мере возможности, иногда путём бэкпортирования патчей из более новых версий программ.

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

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

>Откуда такой вывод образовался?

Ну скажите мне, 19 вы поставили себе снапшот gcc от 17 числа.

>Вижу обновления порта ports/lang/gcc43: gcc43 4.3.4_20090517
>С формулировкой:
>"Update to the 20090517 snapshot of GCC 4.3.4.

Думаете его за два дня успели протестировать и исправить все ошибки? Насколько я знаю, gcc считается разработчиками стабильным, если в нём не более 100 известных неисправленных ошибок. То, что вы установили, это ветка для разработчиков gcc, там ошибок может быть несколько сотен. Вы разработчик или считаете этот снапшот стабильным?

>Причём выбора нет - ты не можешь отказаться наступать на грабли: у тебя есть только current-ветка портов.

>Выбор всегда есть.

Стабильную ветку портов в студию.

>Например, деинсталлировать свежий пакет, который не понравился из-за своего поведения, и инсталлировать пакет старой версии — бинарный откат. Ранее собранные пакеты (.tbz) никуда не исчезают, если их не удаляют из каталога $PACKAGES специально.

И так до посинения. Спасибо, поржал =D

>В-третьих, админу FreeBSD очень трудно понять твой «плачь Ярославны» по поводу отсутствия пакетов для 6.3-RELEASE, ведь вполне доступны свежие 6.4-RELEASE. В мире FreeBSD переход на следующую версию в пределах одного STABLE, признанного Production Release, — это всего лишь улучшение безопасности и стабильности. Без изменения функциональности и совместимости — редкие MFC привносят только тщательно выверенные модификации, не ломающие API/ABI для внесистемных приложений.

Спешу Вас разочаровать - это НЕ ТАК.

В 6.4 ЕСТЬ глюки в работе сети и некоторых RAID-контроллеров, которых НЕТ в 6.3. Не верите - архив freebsd-stable в руки и поиском его. MFC из семерки, знаете-ли... Кривой притом.

"Не ломающие API/ABI" - опять заблуждение. Ломоется периодически. См. мой пример про изменения ATA/ATAPI, которые УБИЛИ все утилиты с прямой работой со структурами драйвера.

P.S.: Слепая вера - это вредно.

>Железо, особенно механика, которая в режиме "24x365" ломается быстрее, чем операционные системы.

Перестаньте-же уже покопуть железо в той помойке, где Вы его в прошлый раз брали! ;-)

Есть вот сервер. Куплен в 2001-м году и поставлен под нагрузку 24x7. В нем с того времени НИЧЕГО не поломалось. (Тьфу-тьфу на него ;-). Ни диски, ни вентиляторы, ни БП... Вообще ничего.

Intel ISP1000 (PIII-750 БЕЗ вентилятора, БП 125(!!!) Вт, Adapatec 2940UW, Seagate Cheeta 10k 9Gb, Quantum Atlas V 32 Gb...)

С нагрузки сняли около месяца назад - таки перестал с нагрузкой справляться. В FreeBSD внесли долгожданные изменения в fxp(4) и при ftp на 100 мегабитах без polling процессор стал вставать колом. С polling получше, но pf процессор ВСЕ РАВНО колом ставит при более мелком пакете.

Улучшения, блин... Теперь вот на него lenny поставил. Пока все пучком, только под другими задачами теперь работает.

>Тю! У меня 4.2-RELEASE FreeBSD 4.2-RELEASE #4 пашет. Под системой сменилось несколько материнок, несколько винтов, начиналось всё ещё на PII-233. Со временем нагрузка несколько уменьшилась, перенесли часть функцционала на пупер-друпер новотехнологичные системы с оракловыми серверами.

Вы ещё пиписьками померьтесь :)

>С некоторым (реально малозначащим) ростом возможностей и катастрофическим падением юзабилити и скорости.

Золотые слова!

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

>Не забывайте, вы всё ещё не ответили на вопрос зачем вам новый Deluge? Там есть какая-нибудь жизненно важная галочка в настройках, позволяющая отключить запрос подтверждения выхода из программы?

Отвечаю.
После обновления библиотек Gtk (2.14 -> 2.16) и GNOME (2.24 -> 2.26) окно необновлённой программы Deluge после запуска представляло собой некликабельный и ни на что не реагирующий прямоугольник.
Почему я не стал обновлять Deluge? Потому что сборка компилятора GCC 4.3, который к тому моменту был удалён мной из системы, занимает всё же ощутимое время, а без него Deluge не собирается. В итоге пришлось устанавливать из порта и GCC 4.3, и обновлять Deluge. После обновления работоспособность восстановилась.

>Ну скажите мне, 19 вы поставили себе снапшот gcc от 17 числа.
>Думаете его за два дня успели протестировать и исправить все ошибки?
>Насколько я знаю, gcc считается разработчиками стабильным, если в нём не более 100 известных неисправленных ошибок. То, что вы установили, это ветка для разработчиков gcc, там ошибок может быть несколько сотен. Вы разработчик или считаете этот снапшот стабильным?

По этому поводу скажу, что GCC 4.3 нужен для сборки некоторых новых программ (по ходу, у меня ТОЛЬКО Deluge 1.1.5 его требует, в ближайшем будущем, возможно, большая часть ПО будет собираться именно им).

То, что я его установил, не значит, что он основной инструмент сборки — его требуют (как зависимость сборки) порты программ, которыми я пользуюсь. Только и всего. А что там до ошибок в компиляторе, ну раз мантейнер считает подходящим внесение новой версии (снапшота) в коллекцию портов и откомпилированные программы не падают и не вызывают серьёзных нареканий, то так тому и быть. Почему нет?

С другой стороны, я вполне бы мог не удалять раннюю версию GCC 4.3 из системы и не обновлять её для пересборки Deluge — заморозка обновлений конкретного (или по маске) ПО делается в конфигурационном файле portupgrade. Либо устновить ранее собранный мной пакет gcc-4.3.4_20090510.tbz или gcc-4.3.4_20090503.tbz и обновить Deluge без особых проблем. Но как я уже сказал, изменения минорных версий портов (даже если это снапшоты) с большой вероятностью устраняет выявленные ошибки предыдущих минорных версий (снапшотов). Тем более, что GCC 4.3 признаётся стабильной на текущий момент коллекцией компиляторов, а экспериментальная работа сосредоточивается в ветках GCC 4.4 и GCC 4.5. Так что ничего не потерял.

>Стабильную ветку портов в студию.

Это зависит от того, что вы понимаете под понятием "стабильная". Ту ветку, в которой библиотеки GNOME 2.26 или ту, в которой библиотеки GNOME 2.26.2? ;)

>Есть вот сервер. Куплен в 2001-м году и поставлен под нагрузку 24x7. В нем с того времени НИЧЕГО не поломалось. (Тьфу-тьфу на него ;-). Ни диски, ни вентиляторы, ни БП... Вообще ничего.

Это УЖЕ не сервер, это сейчас барахло, которое сосёт из вас деньги за электричество, занимает время на обслуживание и неэффективно использует ЧУЖИЕ аппаратные ресурсы, занимая часть полосы пропускания в сети.
Железо по-хорошему вырабатывает свой ресурс за пять лет. Дальше — только проблемы с его содержанием и головняки с различными отказами из-за неравномерного износа частей оборудования.

>С polling получше, но pf процессор ВСЕ РАВНО колом ставит при более мелком пакете.

man pc.conf: Секция OPTIONS
Настройте нормальные таймауты, напишите "scrub in all" и где нужно "keep state" в правилах PF — это спасёт ОРД от разноса и затыка колом.

>Улучшения, блин... Теперь вот на него lenny поставил. Пока все пучком, только под другими задачами теперь работает.

"Маленькие дети — маленькие заботы, большие дети — большие заботы."

>Отвечаю.
>После обновления библиотек Gtk (2.14 -> 2.16) и GNOME (2.24 -> 2.26) окно необновлённой программы Deluge после запуска представляло собой некликабельный и ни на что не реагирующий прямоугольник.

Собственно ничего другого услышать и не ожидал. Вы всё ещё не способны сделать два простых вывода:
1. Новое не всегда лучше старого.
2. Порты фактически не тестируются и стабильная ветка им бы не помешала.

Собственно, если вы не можете сделать для себя эти два простых вывода, то я могу сделать для себя вывод о ваших умственных способностях.

Хотя можно ещё попытаться поиздеваться над вами и спросить: зачем вы обновили Gtk и GNOME? Предвижу продолжение лулзов в направлении "патамучта новое лучше старого".

>По этому поводу скажу, что GCC 4.3 нужен для сборки некоторых новых программ [поскипано]

>То, что я его установил, не значит, что он основной инструмент сборки — его требуют [поскипано]

>С другой стороны, я вполне бы мог не удалять раннюю версию GCC 4.3 [поскипано]

Типичная пионерия! Героическое преодоление трудностей, созданных собственным инструментом, сопровождаемое яростной _фанатичной_ защитой идеальности и непогрешимости этого инструмента. ФАНАТИК!

>Это УЖЕ не сервер, это сейчас барахло, которое сосёт из вас деньги за электричество, занимает время на обслуживание и неэффективно использует ЧУЖИЕ аппаратные ресурсы, занимая часть полосы пропускания в сети.

Это "барахло" надёжно работает непрерывно в течение 8 лет. Это - настоящая вещь, которые сейчас редко встретишь.

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

Советую избавиться от психология потреблядства.

>Железо по-хорошему вырабатывает свой ресурс за пять лет.

Кто утвердил такой норматив? Вам знакомы экономические понятия самоокупаемости и амортизации?

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

>Собственно ничего другого услышать и не ожидал. Вы всё ещё не способны сделать два простых вывода:
>1. Новое не всегда лучше старого.

Вывод неверен в случае рассинхроизации версий взаимодействующего ПО. Что я и привёл в качестве доказательства несостоятельности ВАШЕЙ точки зрения на то, что к обновлениям нужно подходить тогда, когда "всё будет готово". Нужное ПО устаревшей версии не работает в окружении прикладных библиотек новых версий.

>2. Порты фактически не тестируются и стабильная ветка им бы не помешала.

Вывод неверен.
Использования разных версий ПО, несинхронных со срезом дерева портов, выливается в глюки!

Ещё раз для слепоглухонемых: стабильная ветка портов эта та, которая у вас в текущий момент, а ПО, установленное в системе, синхронно с ней.

>Собственно, если вы не можете сделать для себя эти два простых вывода, то я могу сделать для себя вывод о ваших умственных способностях.

Идиот.

>Хотя можно ещё попытаться поиздеваться над вами и спросить: зачем вы обновили Gtk и GNOME? Предвижу продолжение лулзов в направлении "патамучта новое лучше старого".

Потому что моё рабочее окружение (Java, Eclipse, OpenOffice, Xfce/Firefox/Thunderbird/Deluge) целиком и полностью зависит от библиотек GNOME и Gtk.

Оставаясь на сарых версиях GNOME и Gtk я обрекаю себя на ВНЕЗАПНЫЕ столкновение с глюками и уязвимостями прикладных библиотек при работе с приложениями новых версий. Новые версии приложений, устанавливаемых из портов, требуют новых версий прикладных библиотек GNOME и Gtk. Приложения переднего плана рассчитаны мантейнерами на то, что будут запусткаться и работать в том окружении, в котором находится дерево портов на момент их портирования, а не на вчерашний и не на годичной давности снапшот дерева портов.

>>С другой стороны, я вполне бы мог не удалять раннюю версию GCC 4.3 [поскипано]

>Типичная пионерия! Героическое преодоление трудностей, созданных собственным инструментом, сопровождаемое яростной _фанатичной_ защитой идеальности и непогрешимости этого инструмента. ФАНАТИК!

"Героическое преодоление" — это не то определение для "зуда обновлений". :)) Когда обновления происходят прозрачно и быстро, так легко, что даже не хочется делать: pkg_add /path/to/packageg/package-previous_version.tbz, говорит о том, что проблемы с обновлениями из портов ВАМИ_НАДУМАННЫ и МИФОЛОГИЗИРОВАНЫ.

Фанатик — Вы, ждущий момента "когда всё будет готово" (© Debian) и продолжающий работать на завирусованном ПО до этого самого момента. :)

>>Это УЖЕ не сервер, это сейчас барахло, которое сосёт из вас деньги за электричество, занимает время на обслуживание и неэффективно использует ЧУЖИЕ аппаратные ресурсы, занимая часть полосы пропускания в сети.

>Это "барахло" надёжно работает непрерывно в течение 8 лет. Это - настоящая вещь, которые сейчас редко встретишь.

Марш читать учебник по теории надёжности!
Изучите U-образную кривую частоты отказов, в особенности её правую ветвь.

>Фанатик — Вы, ждущий момента "когда всё будет готово" (© Debian)

Я не жду, я занимаюсь своими делами. Ждут те, кто страдает потреблядством.

>и продолжающий работать на завирусованном ПО до этого самого момента. :)

Вы моё ПО на вирусы уже проверили? У вас libastral.so глючит, обновитесь.

>Марш читать учебник по теории надёжности!
>Изучите U-образную кривую частоты отказов, в особенности её правую ветвь.

Там написано про 5 лет, о которых вы говорите?

Я знаю, что у механизмов есть понятие "обкатки". Только что изготовленный механизм сломается с большей вероятностью, чем тот, который уже проработал определённое количество времени. Есть износ и есть усталостные напряжения. Со временем они увеличиваются, поэтому в более долгосрочной перспективе вероятность отказа возрастает.

НО! Самая главная мысль, которую я хочу до вас донести заключается в том, что у "настоящих" вещей, например у серверного железа, время наработки на отказ значительно больше.

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

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

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

>Это УЖЕ не сервер, это сейчас барахло, которое сосёт из вас деньги за электричество, занимает время на обслуживание и неэффективно использует ЧУЖИЕ аппаратные ресурсы, занимая часть полосы пропускания в сети.

Неверно. Со своими задачами (DNS+WWW+FTP) оно ПРЕКРАСНО справляется сейчас под debian/lenny. А эффективность... Если оно 100 мегабитный поток обслуживает при среднем размере пакета в 500 байт, при этом жрет не больше 125 ватт, то покажите мне хваленый современный сервер у которого будет такая-же эффективость?

>man pc.conf: Секция OPTIONS
>Настройте нормальные таймауты, напишите "scrub in all" и где нужно "keep state" в правилах PF — это спасёт ОРД от разноса и затыка колом.

А то, блин, я не знал! Спасибо Вам о Великий Гуру! ;-)

Особенно про "scrub in all" порадовало - ЭТО не УМЕНЬШИТ затраты процессорного времени а только УВЕЛИЧИТ. (man ВНИМАТЕЛЬНО почитайте - может дойдет).

С "keep state" - аналогично (просмотр по таблице в несколько ТЫСЯЧ состоянии занимает больше времени, чем прогон пакета по полутара десяткам сравнений). И даже хуже - при употреблении "keep state" к месту и не к месту можно начать периодически наступать на грабли с размером таблички.

Фишка не в этом. Фишка в том, что в районе 6.2 БЕЗДУМНЫМ избавлением от giant lock в драйвере и сетевом стеке добились ОГРОМНОГО уменьшения производительности на конкретном железе (fxp).

>Со своими задачами (DNS+WWW+FTP) оно ПРЕКРАСНО справляется сейчас под debian/lenny. А эффективность... Если оно 100 мегабитный поток обслуживает при среднем размере пакета в 500 байт, при этом жрет не больше 125 ватт, то покажите мне хваленый современный сервер у которого будет такая-же эффективость?

Проснулись!

В продаже есть ГИГАБИТНЫЕ мыльницы с "Wireless N" с возможностью обслуживания подключаемых по USB-дисков и флэшек, встроенные сервера DNS, FTP NTP, CIFS/SAMBA, torrent-агент,. Всё вместе в сборе потребляет до 30 Ватт. Не нуждается в принудительной вентиляции, шум только от винта. Стоит порядка 8 тысяч рублей (~5т.р. гигабитная мыльница и ~3т.р. внешний или внутренний 2,5"диск). Торренты такие коробочки не хило обслуживают. ;)

>С "keep state" - аналогично (просмотр по таблице в несколько ТЫСЯЧ состоянии занимает больше времени, чем прогон пакета по полутара десяткам сравнений). И даже хуже - при употреблении "keep state" к месту и не к месту можно начать периодически наступать на грабли с размером таблички.

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

>В продаже есть ГИГАБИТНЫЕ мыльницы с "Wireless N" с возможностью обслуживания подключаемых по USB-дисков и флэшек, встроенные сервера DNS, FTP NTP, CIFS/SAMBA, torrent-агент,. Всё вместе в сборе потребляет до 30 Ватт. Не нуждается в принудительной вентиляции, шум только от винта. Стоит порядка 8 тысяч рублей (~5т.р. гигабитная мыльница и ~3т.р. внешний или внутренний 2,5"диск). Торренты такие коробочки не хило обслуживают. ;)

И динамический контент на апаче поддерживают? Нет? Толды - ф топку.
Да. У этих Dlink/Acorp и иже с ними еще и ОЧЕНЬ больное место есть - БП называется. Горит, гад, когда ему захочется. Маде ин сина, блин...

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

А я о чем? Вы что подсказали? "keep state" поставить?

Дык вот - ХЕРНЮ сказали. О чем я и отписался.

За сим раскланиваюсь. Дальнейшее обсуждение считаю безсмысленным. Ибо трудно разговаривать с человекок, который СВОИХ высказываний не помнит...

>И динамический контент на апаче поддерживают? Нет?

Поставите Apache — будет. :))

>>А я о чем? Вы что подсказали? "keep state" поставить?
>Дык вот - ХЕРНЮ сказали. О чем я и отписался.

Да, вот налицо проблемы аппаратного характера: CPU не справляется с просмотром таблиц состояний. ;) Весьма аппаратная проблема и меньше программная — либо тюнить файервол на количество одновременных соединений/время ответа, либо менять железо на более быстрое. :))

>Фишка не в этом. Фишка в том, что в районе 6.2 БЕЗДУМНЫМ избавлением от giant lock в драйвере и сетевом стеке добились ОГРОМНОГО уменьшения производительности на конкретном железе (fxp).

Фишка в том, что сейчас, когда есть 6.4 и 7.2, использование FreeBSD 6.2 является самоистязанием.

>Фишка в том, что сейчас, когда есть 6.4 и 7.2, использование FreeBSD 6.2 является самоистязанием.

КТО сказал, что там стояла 6.2?

Я сказал, что "в районе 6.2". Т.е. 6.2 и ВЫШЕ.

>Да, вот налицо проблемы аппаратного характера: CPU не справляется с просмотром таблиц состояний.

Не отходите от топика!

Посоветовали ДЛЯ УСКОРЕНИЯ сделать scrub и keep state? Да?

ХЕРНЮ посоветовали - это только замедление!

> тюнить файервол на количество одновременных соединений/время ответа, либо менять железо на более быстрое.

Или поставить линукс. Там таких проблем НЕТ. Не ДОУСКОРЯЛИСЬ еще.

А "за новой дозой железа" - это к игрунцам и форточникам. Зачем менять то, что и так прекрасно работает? Софт кривой стал. Так не проще именно ЕГО и сменить?

>Посоветовали ДЛЯ УСКОРЕНИЯ сделать scrub и keep state? Да?

Да! Ценой увеличения потребления памяти на буфер для сборки фрагментированных пакетов и ценой хранения состояния соединений.

Читайте PF FAQ, что это даёт.

>Софт кривой стал. Так не проще именно ЕГО и сменить?

Это не софт кривой стал. Это нагрузка возросла и изменились требования к системе.
А софт откатить назад на версию или сменить — это всегда успеется.

>>Посоветовали ДЛЯ УСКОРЕНИЯ сделать scrub и keep state? Да?
>Да! Ценой увеличения потребления памяти на буфер для сборки фрагментированных пакетов и ценой хранения состояния соединений.

Нет!

1) Packet assembler жрет процессор на отработку проверки состояний, пересмотра окон и т.п. С точки зрения безопасности - scrub рулит. С точки зверия производительности - сосет.

2) keep state также дает увеличение безопасности и ускорение при малом количестве (тысяч до полутора-двух) соединений. Дальше - сосет и причмокивает. ;-)

Не верьте всему, что Тео понаписал. Такой уровень паранойи требует скептичского подхода. ;-)

В частности, старый добрый ipfilter (NetBSD-шный, не Linux-овый!) на FreeBSD дает существенный прирост скорости при вдумчивом использовании. Ценой уменьшения удобства, правда. Причем значительного уменьшения - количество правил фильтрации разростается на более-менее нагруженной системе в 3-4 раза за счет отсутствия удобных сокращений и таблиц. Да и еще ipf и mpsafenet не дружит.

>Это не софт кривой стал. Это нагрузка возросла и изменились требования к системе.

Нет. По крайней мере не так значительно чтобы загрузка процессора с 10 процентов поднялась до 100.

>А софт откатить назад на версию или сменить — это всегда успеется.

Что и было сделано. ;-)

> Ай молодца, в 2009 году не осилить установку на сервак какого нибудь мегалегковесного fluxbox, и по старинке управлять фряхой с висты по ssh экономя 20 мегабайт памяти

А ничего что у меня на сервере 64Мб оперативной памяти,целерон 400МГц и иксы на нем при сборке мира это <censored>

Free BSD from GNU!