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

[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]

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

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

 

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

[NiTr0 584]

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

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

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

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

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

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

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

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

Нет конечно.

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

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

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

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

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

И чем ваше решение принципиально лучше банального 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 584]

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

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

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

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

 

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

 

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

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

 

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

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

 

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

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

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

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

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

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

 

 

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

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

 

 

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

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

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

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

[NiTr0 584]

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

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

[ttttt 195]

 

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

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

 

 

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

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

 

 

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

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

 

 

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

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

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

 

 

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

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

[madf 279]

 

 

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

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

 

 

 

 

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

[ttttt 195]

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

[madf 279]

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

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

[UStas_rinet 43]

 

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

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

 

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

[NiTr0 584]

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

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

 

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

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

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

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

 

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

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

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

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

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

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

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

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

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

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

 

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

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

[UStas_rinet 43]

 

 

 

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

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

 

 

 

 

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

[NiTr0 584]

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

[ttttt 195]

 

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

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

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

 

 

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

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

 

 

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

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

[madf 279]

 

 

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

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

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

...

 

 

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

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

[NiTr0 584]

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

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

 

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

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

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

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

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

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

[madf 279]

...

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

В самом лучшем случае интерпретатор с 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к циклов.