Хелп! Ломанули сервер!

[UStas_rinet 43]

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

Відредаговано 2013-06-03 17:30:51 UStas_rinet

[UStas_rinet 43]

Сообщение:

"Доброго времени суток, администрация сайта xxxxxx. По своей инициативе хочу сообщить вам об уязвимости вашего сайта по портам TCP: 21, 22, 80, 81, 10000, а также по портам UDP: 123, что может подтвердить скриншот, ссылку на который я оставлю в конце данного сообщения. Я предполагаю, что вам дорог ваш сайт, и вы не хотите по - пусту его терять. Я могу помочь вам с закрытием уязвимостей сайта, также исправить некоторые баги в коде, мне для этого не потребуется никаких админских прав. Я сам благодаря уязвимостям установлю связь с сайтом по FTP протоколу, и сделаю всё, что нужно. Советую задуматься над моим предложением, обойдется это вам в 100 русских рублей, такое бесплатно никто делать не будет. У меня достаточно навыков и знаний, и я помог уже около 30 сайтам, если захотите, предоставлю список. Если что, пишите на мой e-mail magnickolas@rambler.ru. Ссылка на скриншоты: 1)   (открытые порты) 2)  (чрезвычайно долгий ping с сайтом) С уважением, Николай."

[UStas_rinet 43]

  Цитата

 

Открою огромный секрет: dns amplification подвержен любой днс сервер, открытый в мир. А закрыть сервер в мир прову, у которого свое доменное имя - бред редкостный... А вот ограничить флуд, лимитировав кол-во пакетов в секунду - легко.

 

Простите, но вы не правы http://askubuntu.com/questions/170728/how-to-disable-external-dns-recursion

 

По крайне мере если мы говорим про вездесущий бинд.

Или:

 

acl corpnets { 192.168.1.0/24; 192.168.2.0/24; };
options {
  allow-recursion { corpnets; };
};

Відредаговано 2013-06-03 17:49:01 UStas_rinet

[UStas_rinet 43]

  В 03.06.2013 в 11:50, AoW сказав:

а http://www.fail2ban.org/ кто-то юзал?...  вопрос так..ради интереса -)

Больше юзал log2ban как инструмент борьбы с атаками. Идея в том что у фейла мы считаем срабатывания наблюдаемого ПО, а у лог2бан на лету собираем вроде как даже и не ошибки но можем всяко яко посчитать и настроить под новое поведение атакующего.

 

http://habrahabr.ru/post/134331/ - вот от сюда когда то почерпнул.

[NiTr0 585]

  В 03.06.2013 в 17:09, ttttt сказав:

Какой-то детский лепет уже

Вот допустим эксплоит в апаче, как вы зарежите его файрволом, например ipfw? Естественно, что апач должен продолжать отвечать на запросы.

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

И да, я к примеру у себя вообще апач нах выпиливаю поэтапно, переводя новые инсталляции на nginx+php-fpm/perl-fpm/прочие fastcgi. Несколько возросшая сложость настройки с лихвой компенсируется производительностью и меньшей ресурсоемкостью.

  В 03.06.2013 в 17:09, ttttt сказав:

Другие бд тоже не смотрям в мир, есть своего рода бд прокси, который раскладывает данные по шардам/серверам. Вот он смотрит в мир, но ему тоже не нужен файрвол для ограничения доступа.

Не нужен? Вы уверены, что в нем нет remote code execution дыр? Вы тщательно изучали код его, прогоняли через особый набор юнит-тестов на предмет обработки некорректных данных пакета? Или таки нет?

  В 03.06.2013 в 17:09, ttttt сказав:

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

С чего вы взяли, что его нельзя использовать для амплификатора? Он что, не будет отвечать на запросы с фейковых ип?

  В 03.06.2013 в 17:09, ttttt сказав:

Нет конечно.

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

  В 03.06.2013 в 17:09, ttttt сказав:

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

Итого - имеем зоопарк версий библиотек, которые жрут память, плавающие от сервиса к сервису дыры (или вы помните, какой версии в каком сервисе та же libpng к примеру, или pam?), и огромные проблемы с обновлением.

  В 03.06.2013 в 17:09, ttttt сказав:

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

Сколько времени обновление одного сервера до актуальных версий занимает? Не просто накатка бинарников, а анализ конфигов?

И чем ваше решение принципиально лучше банального apt-get install ..... (если надо - со своим репозиторием модифицированных пакетов) ?

[ttttt 195]

  Цитата

 

Которые в мир торчать не должны принципиально

Это принципиальность опять про религию. 

 

  Цитата

 

И да, я к примеру у себя вообще апач нах выпиливаю поэтапно, переводя новые инсталляции на nginx

Я апач только в пример привел, пусть тогда эксплоит для какой-то новой дыры в nginx, вот недавно как раз CVE в парсере была, можно тоже код исполнять. 

 

  Цитата

 

 Вы уверены, что в нем нет remote code execution дыр? Вы тщательно изучали код его, прогоняли через особый набор юнит-тестов на предмет обработки некорректных данных пакета?

Да, при условии, что таких дыр нет в процессоре, сетевой карте, стэке tcp ядра. И потому что а) это не Си и дибильных ошибок с арифметикой указателей, ручным управлением памяти и т.д. нет и б) ограничение доступа происходит сразу после accept(), всего две строчки кода, а дальше по коду уже не страшно. Даже если бы на Си было, тоже не было бы опасностью, обычно у всех же ограничение доступа по IP сразу после accept().

 

  Цитата

 

С чего вы взяли, что его нельзя использовать для амплификатора? Он что, не будет отвечать на запросы с фейковых ип?

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

 

  Цитата

 

Итого - имеем зоопарк версий библиотек, которые жрут память, плавающие от сервиса к сервису дыры (или вы помните, какой версии в каком сервисе та же libpng к примеру, или pam?), и огромные проблемы с обновлением.

 

Очень сильно ошибаетесь. Как раз не имеем ни зоопарка, ни дыр, ни проблем с обновлением вообще. Это почти как свои пакеты, только без зависимостей и всего софта вперемешку в одном дереве. 

 

  Цитата

 

Сколько времени обновление одного сервера до актуальных версий занимает? Не просто накатка бинарников, а анализ конфигов?

В смысле одного сервера до актуальных версий? И какой еще анализ конфигов? Конфиги только генерируются, старым версиями неоткуда взяться, все обновляется на всех серверах одновременно. Если во время деплоя на одном каком-то выпало с ошибкой - можно посмотреть что там случилось и передеплоить на него еще раз. Если нужен новый сервер или пару - добавили ssh ключи и запустили деплой, оставив в конфиге только эти два сервера и через 5 минут или пол часа (смотря какой cpu и диск) имеем два новых полностью настроенных сервера.

 

  Цитата

 

И чем ваше решение принципиально лучше банального apt-get install

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

 

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

Відредаговано 2013-06-03 21:29:08 ttttt

[UStas_rinet 43]

  Цитата

 

С чего вы взяли, что его нельзя использовать для амплификатора? Он что, не будет отвечать на запросы с фейковых ип?

  Цитата

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

Да нет же, пакет запроса на корневые, раз в 10 прироста трафика дает. ))) Ответ проще - а зачем вообще к себе в сеть пропускать адреса у которых стоят сорс адреса твоей сети ? Антиспуфинг обычное дело, делается явно не на днс сервере а где то ближе к пограничке. Так что если там все грамотно и запрещена рекурсия на бинде то к нему не пробиться )

Відредаговано 2013-06-04 04:09:34 UStas_rinet

[NiTr0 585]

  В 03.06.2013 в 20:53, ttttt сказав:

Это принципиальность опять про религию.

Эта принципиальность следует из осознания того факта, что дыра может быть в любом демоне. И чем меньше сервисов торчит в мир - тем выше безопасность. Не?

  В 03.06.2013 в 20:53, ttttt сказав:

Я апач только в пример привел, пусть тогда эксплоит для какой-то новой дыры в nginx, вот недавно как раз CVE в парсере была, можно тоже код исполнять.

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

 

  В 03.06.2013 в 20:53, ttttt сказав:

Да, при условии, что таких дыр нет в процессоре, сетевой карте, стэке tcp ядра. И потому что а) это не Си и дибильных ошибок с арифметикой указателей, ручным управлением памяти и т.д. нет и б) ограничение доступа происходит сразу после accept(), всего две строчки кода, а дальше по коду уже не страшно. Даже если бы на Си было, тоже не было бы опасностью, обычно у всех же ограничение доступа по IP сразу после accept().

 

Чего-чего? Демон на интерпретируемом языке? И сколько кппс его скукожат?

  В 03.06.2013 в 20:53, ttttt сказав:

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

 

Любой пакет. Не обязательно огромный. Ответ 200-300 байт (хоть ANY) на 64 байт - уже неплохая амплификация. Даже если NS на сотню байт - тоже неплохо.

  В 03.06.2013 в 20:53, ttttt сказав:

Очень сильно ошибаетесь. Как раз не имеем ни зоопарка, ни дыр, ни проблем с обновлением вообще. Это почти как свои пакеты, только без зависимостей и всего софта вперемешку в одном дереве.

 

Имеете. Один пакет тянет скажем 1.0.4 библиотеку, другой - 1.0.7, третий сборанный 3 года назад - 0.9.5 еще пользует, в итоге работа превращается в русскую рулетку или в слежение за всеми библиотеками. И каждая из библиотек висит в памяти и жрет ее.

Накатка обновлений, соответственно, тоже превращается в печаль.

  В 03.06.2013 в 20:53, ttttt сказав:

В смысле одного сервера до актуальных версий? И какой еще анализ конфигов? Конфиги только генерируются, старым версиями неоткуда взяться, все обновляется на всех серверах одновременно. Если во время деплоя на одном каком-то выпало с ошибкой - можно посмотреть что там случилось и передеплоить на него еще раз. Если нужен новый сервер или пару - добавили ssh ключи и запустили деплой, оставив в конфиге только эти два сервера и через 5 минут или пол часа (смотря какой cpu и диск) имеем два новых полностью настроенных сервера.

Есть у вас машина. Работает на ней сервис, эксим допустим. Тюните вы ему конфиг по мере изменения характера спама. Работает год, другой, накатываете на него минорные апдейты. Как в вашем видении это должно происходить?

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

И да, вы для каждого пакета мониторите багтрек для оперативного обновления с целью закрытия 0-day уязвимостей?

  В 03.06.2013 в 20:53, ttttt сказав:

 

 

  Цитата

И чем ваше решение принципиально лучше банального apt-get install

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

 

 

А смысл в изоляции зависимостей? Смысл в отвязке от дистра, если не разводить зоопарк дисторов? Не проще репозиторий свой оформить?

Опять же - установить все из пакетов можно, дав одну-единственную команду. Для дебиана - apt-get install <список пакетов>, для RHEL/клонов - yum install <список пакетов>. Все. Максимум - конфиги поправить (или скопировать преднастроенные).

  В 03.06.2013 в 20:53, ttttt сказав:

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

Наоборот - с пакетами гораздо легче обслуживать большой парк машин. Особенно с большим кол-вом сервисов. Особенно - если задача стоит в обслуживании, а не разворачивании и бросании насамотек инсталляций. Відредаговано 2013-06-04 16:59:43 NiTr0

[NiTr0 585]

  В 04.06.2013 в 03:59, UStas_rinet сказав:

Ответ проще - а зачем вообще к себе в сеть пропускать адреса у которых стоят сорс адреса твоей сети ?

А кто сказал, что атака - на вашу сеть?

[ttttt 195]

  Цитата

 

Чего-чего? Демон на интерпретируемом языке?

Причем тут интерпретируемые языки? На пальцах: системный вызов, типа accept() жрет в 50-100 раз больше ресурсов, чем пару команд проверки доступа - на любом языке. Но за ним еще один - close(). Они и будут узким местом, а не проверка доступа и не язык. 

 

  Цитата

 

Ответ 200-300 байт (хоть ANY) на 64 байт - уже неплохая амплификация.

Ну скажем так, за 5x никто париться не будет, в среднем с большого списка серверов будет даже ниже, а открытые рекурсивные позволяют получить ответ 70x.

 

  Цитата

 

Есть у вас машина. Работает на ней сервис, эксим допустим. Тюните вы ему конфиг по мере изменения характера спама.

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

 

  Цитата

 

Далее, окончилась поддержка вашей ветки - что вы будете делать?

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

А вот я могу обновить, если надо. А если конфиг несовместимый, то придется править, но и вам тоже, когда вы обновитесь, если вообще обновитесь, дебиан же  

 

  Цитата

 

А смысл в изоляции зависимостей? Смысл в отвязке от дистра, если не разводить зоопарк дисторов? Не проще репозиторий свой оформить?

Чтобы зависимости не задевали все сервисы, если в них что-то случилось или другие сервисы еще не готовы к новому API. Чтобы можно было использовать разные дистры, и что за бредятина про привязку к одному дистру? Завтра ребята из дебиана решат, что ну его нафиг, будем делать новый дистр и новую систему пакетов и вы останетесь ни с чем, ну или решат удалить какой-то софт, или перестанут обновлять или не обновят вовремя - и у вас будут проблемы. MySQL еще не удалили? Интересно будет посмотрить на реакцию админов, когда MySQL удалят, некоторые дистры уже поудаляли. А репозиторий свой оформить (даже для одной системы пакетов) совсем не проще, чем создать свою систему, независимую от дистра. А раз не проще, то зачем? 

[madf 279]

  В 04.06.2013 в 20:14, ttttt сказав:

 

 

  Цитата

Чего-чего? Демон на интерпретируемом языке?

Причем тут интерпретируемые языки? На пальцах: системный вызов, типа accept() жрет в 50-100 раз больше ресурсов, чем пару команд проверки доступа - на любом языке. Но за ним еще один - close(). Они и будут узким местом, а не проверка доступа и не язык. 

 

 

 

 

Вот это вы зря заявили. Или приведите доказательства, или признайте что вы ничерта не разбираетесь в предмете и делаете голословные замечания.

[ttttt 195]

Что я зря заявил? Какие доказательства, конкретнее.

[madf 279]

Если бы вы сказали что „accept и close отрабатывают медленнее проверки доступа“, я бы просто поинтересовался почему. Но вы авторитетно заявляете что accept жрет аж в 100 раз больше неких мифических ресурсов, а такие заявления надо подкреплять фактами.

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

[UStas_rinet 43]

  В 04.06.2013 в 17:02, NiTr0 сказав:

 

  В 04.06.2013 в 03:59, UStas_rinet сказав:

Ответ проще - а зачем вообще к себе в сеть пропускать адреса у которых стоят сорс адреса твоей сети ?

А кто сказал, что атака - на вашу сеть?

 

А если не на нашу то и рассуждать не о чем, так как рекурсия условно говоря разрешается только для своих адресов.

[NiTr0 585]

  В 04.06.2013 в 20:14, ttttt сказав:

Причем тут интерпретируемые языки? На пальцах: системный вызов, типа accept() жрет в 50-100 раз больше ресурсов, чем пару команд проверки доступа - на любом языке. Но за ним еще один - close(). Они и будут узким местом, а не проверка доступа и не язык. 

Угу, угу. Одна "команда" интерпретируемого языка равна нескольким сотням команд компилируемого (в лучшем случае).

 

  В 04.06.2013 в 20:14, ttttt сказав:

Ну скажем так, за 5x никто париться не будет, в среднем с большого списка серверов будет даже ниже, а открытые рекурсивные позволяют получить ответ 70x.

Уверены? Я - нет.

  В 04.06.2013 в 20:14, ttttt сказав:

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

А если конфиги разные на разных серверах - что тогда? Для каждого сервера тянуть свой недо-пакет с конфигом? Хранить их все в одной большой куче на одном сервере?

 

  В 04.06.2013 в 20:14, ttttt сказав:

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

А вот я могу обновить, если надо. А если конфиг несовместимый, то придется править, но и вам тоже, когда вы обновитесь, если вообще обновитесь, дебиан же

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

  В 04.06.2013 в 20:14, ttttt сказав:

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

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

  В 04.06.2013 в 20:14, ttttt сказав:

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

Не бредтина, а вполне здравое стремление к однообразию в софте. Вас же тянет почему-то на дикий зоопарк, при этом - без какого-либо рационального объяснения сего факта. Зоопарк ради зоопарка. Поверх которого слеплена своя корявая личная система пакетов. На обслуживание которой, уверен, тратится гора времени.

  В 04.06.2013 в 20:14, ttttt сказав:

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

Открою вам еще один огромный секрет: в рамках одной ветки софт не удаляется. Вообще. На протяжении всей ее поддержки.

А в новой версии дистра - ну и пускай удаляют. Будет повод перейти на оптимизированный форк (mariadb или percona).

 

  В 05.06.2013 в 07:17, UStas_rinet сказав:

А если не на нашу то и рассуждать не о чем, так как рекурсия условно говоря разрешается только для своих адресов.

А кто говорит исключительно о рекурсии?

[UStas_rinet 43]

  Цитата

 

 

 

  В 05.06.2013 в 07:17, UStas_rinet сказав:

А если не на нашу то и рассуждать не о чем, так как рекурсия условно говоря разрешается только для своих адресов.

А кто говорит исключительно о рекурсии?

 

 

 

 

Если поделитесь опытом кудой еще можно налить через провайдерский днс в разы больше трафика чем сам запрос то буду примного благодарен, в хорошем смысле этой фразы ) Длинные ответы на записи крайне редко встречается на авторитативных днасах провов, т.е. чего то типа dig in a i.ua там практически не увидеть.

[NiTr0 585]

Несколько NS/MX - вполне пару сотен байт дадут минимум... Запрос - 40 байт. Итого - минимум 5-кратная амплификация; негусто, но и не мало. Бот на 100мбит канале генерит 500+мбит траффика..

[ttttt 195]

  Цитата

 

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

Ой, факты, возьмите любой пример TCP сервера, скомпилируйте и померяйте.

accept() в обычном режиме будет делать аж 2 переключения контекста, в ядро и обратно, это хз сколько, 10к циклов или больше, а доступ к L3 кэшу два раза и вычисление хэша из 32-битного айпишника - до 100 циклов, вот вам и в 100 раз разница. 

 

  Цитата

 

Одна "команда" интерпретируемого языка равна нескольким сотням команд компилируемого (в лучшем случае).

В самом лучшем случае интерпретатор с JIT быстрее, чем компилируемый язык (AOT), потому что может оптимизировать машинный код на лету, зная как он исполняется и речь вообще не об этом. 

 

  Цитата

 

Не бредтина, а вполне здравое стремление к однообразию в софте. Вас же тянет почему-то на дикий зоопарк

Какой зоопарк, сколько можно уже? У меня как раз однообразнее и проще, чем зоопарки любой пакетной системы. И когда-то это все было в бинарных пакетах и занимало просто немеряно времени, сейчас вообще времени не занимает, потому что выкинули бинарные пакеты. Какое тут вообще может быть объяснение. И проблема даже не в самих пакетах, а в системе с зависимостями вообще. Мне нужно свой софт держать, а вы рассуждаете с точки зрения использования только того, что вам предлагают в пакетах и небось мейнтенить какой-то пакет даже не пробовали. 

[madf 279]

  В 06.06.2013 в 02:58, ttttt сказав:

 

 

  Цитата

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

Ой, факты, возьмите любой пример TCP сервера, скомпилируйте и померяйте.

accept() в обычном режиме будет делать аж 2 переключения контекста, в ядро и обратно, это хз сколько, 10к циклов или больше, а доступ к L3 кэшу два раза и вычисление хэша из 32-битного айпишника - до 100 циклов, вот вам и в 100 раз разница. 

...

 

 

Что вы нас тут сказками кормите? Я просил конкретных фактов — результатов измерений или исходников. Не говорите мне что делать а я не буду говорить куда вам пойти.

Откуда вы взяли 10к циклов и почему нет переключения контекста во втором случае? Файлы hosts.allow и hosts.deny нужно перечитывать каждый раз — это переключения контекста. И в кеше L3 данным взяться неоткуда.

[NiTr0 585]

  В 06.06.2013 в 02:58, ttttt сказав:

В самом лучшем случае интерпретатор с JIT быстрее, чем компилируемый язык (AOT), потому что может оптимизировать машинный код на лету, зная как он исполняется и речь вообще не об этом.

Факты, факты. Пока что это - голословные заявления.

 

  В 06.06.2013 в 02:58, ttttt сказав:

Какой зоопарк, сколько можно уже? У меня как раз однообразнее и проще, чем зоопарки любой пакетной системы.

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

  В 06.06.2013 в 02:58, ttttt сказав:

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

Пробовал мейнтейнить, пробовал. Ничего сложного. Времени практически не занимает.

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

И да, вы что, держите исключительно свой софт?

[madf 279]

  В 06.06.2013 в 02:58, ttttt сказав:

...

  Цитата

Одна "команда" интерпретируемого языка равна нескольким сотням команд компилируемого (в лучшем случае).

В самом лучшем случае интерпретатор с JIT быстрее, чем компилируемый язык (AOT), потому что может оптимизировать машинный код на лету, зная как он исполняется и речь вообще не об этом. 

...

 

 

В самом лучшем случае дедушка-паралитик быстрее пересечет финишную черту на беговой дорожке чем спринтер-олимпиец. Например когда он уже стоит на черте.

О производительности JIT был модно говорить 5 лет назад, с тех пор энтузиазм подупал. Сравнением нативного кода и managed с JIT уже никто не занимается, чтобы не опозориться.

Более того, Google пилит свой NaCl, а Microsoft уходит (ну или по крайней мере существенно пересмотрели свое отношение) от managed к native code. В 8-ке C++ снова стал first class citizen, да и название прошлогодней конференции "Going Native 2012" говорит само за себя.

JIT хорошая штука, но это не панацея. Это просто решение проблем managed языков. Проблем которых у native нет и никогда небыло.

[ttttt 195]

  Цитата

 

Откуда вы взяли 10к циклов и почему нет переключения контекста во втором случае? Файлы hosts.allow и hosts.deny нужно перечитывать каждый раз — это переключения контекста. И в кеше L3 данным взяться неоткуда.

Причем тут tcp wrappers? Почитайте о чем речь вообще. Если важна производительность - никто не будет перечитывать hosts.allow каждый раз, а будет стараться сделать все в своих силах, чтобы производительносьт была максимальная, т.е. будет что-то типа хэш таблицы с разрешенными адресами, может быть даже с маленьким блум фильтром, чтобы он весь в одну cache line влез и отказ был за одно обращение к L3. А если не важна производительность, то зачем вообще рассуждать о производительности? 

 

 

  Цитата

 

О производительности JIT был модно говорить 5 лет назад, с тех пор энтузиазм подупал. Сравнением нативного кода и managed с JIT уже никто не занимается, чтобы не опозориться.

Я не вижу здесь аргументов, вижу только камень в огород PL research. Кому-то что-то модно, кому-то позорно, да уж. Не позорьтесь.

 

  Цитата

 

Более того, Google пилит свой NaCl, а Microsoft уходит (ну или по крайней мере существенно пересмотрели свое отношение) от managed к native code. В 8-ке C++ снова стал first class citizen, да и название прошлогодней конференции "Going Native 2012" говорит само за себя.

 

И что? У них есть проблема - arm дико медленные и нужно очень сильно экономить ресурсы, чтобы юзеры комфортно себя чувтсовали на таких системах и пока ее можно решить только нативными приложениями.

 

В тоже время в других местах не так, например гугл продолжает пилить JIT в v8, а все попытки нативных приложений в браузере ни к чему не привели.

 

  Цитата

 

JIT хорошая штука, но это не панацея. Это просто решение проблем managed языков. Проблем которых у native нет и никогда небыло.

Надоели уже ваши глупости. Managed языки - это что вообще, языки на vm'ах microsoft'а? Какое отношение они имеют к интерпретаторам? Причем тут вообще microsoft, их чудо-софт и их отношение к чему-то? 

[madf 279]

Ок, фиг с ним со всем. Скажите только откуда 10к циклов.