nuclear lightning

Наш ответ попаданцам!

Всем надоели книги про "попаданцев" в прошлое, особенно переламывающих ход войны докладом лично Сталину? Давайте развернем ситуацию! Итак, представьте себе, ФИЛЬМ...

Москва, наше время. Лето, под утро, гроза пустырь из Терминатора 2 на безлюдной площади. В полномасштабный памятник Сталину ударяет молния! Спецэффекты, вжух — с памятника слетает скорлупа, и остается живой Сталин! Гроза резко прекращается, светает, а тот с недоумением смотрит на свои руки — морщины куда-то пропали, и вообще выглядит на 40 лет. Вот же, вчера еще дача, Берия... и Москва какая-то не та. Но светает — значит пора на работу, в Кремль! Слезает с пьедестала, идет и удивляется. Тут к нему подбегают девчушки "ой как настоящий, а почем с вами сфоткаться?!", всучивают 100 рублей и убегают. Так повторяется не один раз, так что деньгами Вождь обеспечен!

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

Кто придумает продолжение? :)
  • Current Music
    Василий К - Про Сталина
  • Tags
nuclear lightning

"Астрологи объявили год БЕЗНЕФТИ! Население всех нефтебаксов уменьшилось вдвое!"

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

И вдруг ВНЕЗАПНО оказывается да, есть такое, что можно описать до уровня почти что потери полезности "в такое-то время в НЕКОЕЙ области, связанной с нефтью, будут проблемы" (хер ж его знает, в какой некоей, у производителей или покупатетелей? но всё же проблемы отличаются от их отсутствия). Итак, внимаем мудрости из сфер: нефтью управляет Нептун. Наиболее долгоиграющий "злой фактор" из заметных на протяжении жизни одного поколения — это Сатурн. И, как выясняется, как раз в данное время он "ездит" негативным аспектом квадратуры по Нептуну. Длится это порядка года и случается раз в эдак в ~9 лет, но не так равномерно и не всегда, и вообще там Всё Сложно™ из-за эллиптических орбит, видимости ретроградного движения и проч. и проч. То бишь, для текущего периоды года даты точных аспектов, т.е. "центров временных промежутков длиной несколько месяцев":
  • 26 ноября 2015
  • 18 июня 2016
  • 10 сентября 2016

...но, на самом деле, не центров, потому что скорость меняется, и вообще там и другие факторы, типа. То есть, на резонный вопрос, фигли "коридор" начался в сентябре, а точный аспект был в ноябре, а просаживается-то цена на нефть (и курс бакса как следствие) до минимума в августе да в начале января? слышим, что, дескать, "в тонком мире формы подготавливаются раньше, чем в материальном", и что и Сатурн, и Нептун относятся к "тормозам", которые обычно срабатывают позже точного аспекта. Ну и до кучи, что по небу там и более быстрые тоже шастают — так что, например, в августе 2016 там будет ну вот ваще сильный удар со стороны еще нескольких, и всю осень до начала декабря они будут этот несчастный Нептун "добивать" своими негативными аспектами. Особенно во второй половине октября, но в начале ноября полегчает, а потом снова поплохеет, и лишь к Новому Году "отпустит" совсем.

Хорошо, это на текущий год, а что там в истории? Про цены нам подготовили ну например http://tass.ru/infographics/8156 график, а что там на небе? Что и когда там, без учета быстрых, с этим Сатурном с Нептуном раньше в истории аналогичное "напряженное" было? Звёзды говорят, что предыдущие интервалы:
  • июль 2006 — август 2007 (оппозиция)
  • май 1998 — май 1999 (квадрат)
  • июль 1979 — сентябрь 1980 (квадрат)
  • май 1971 — июнь 1972 (оппозиция)

Хм... что-то вполне заметно на графике, что-то нет. Что ж, посмотрим через год, будет смешно, если сбудется!
nuclear lightning

(no subject)

[...] был единственным, кто выступил против передачи руководства КБ сыну А.Н.Туполева — Алексею Андреевичу. А.Н.Туполев не согласился с позицией Л.Л.Кербера, а Л.Л.Кер­бер написал заявление об уходе, которое Туполев положил в сейф, после чего продолжал платить зарплату своему заму, хотя тот перестал ходить на работу. Причина неприятия Л.Л.Кербером Туполева-младшего в качестве руководителя КБ: по мнению Л.Л.Кербера, Туполев-младший был плохим организатором и не имел той «пробивной силы», какой обладал его отец, хотя и был разносторонне эрудированным и грамотным инженером (вследствие того, что отец провёл его через все подразделения «своей» фирмы).

Мощно.
nuclear lightning

Оказывается, их вокруг гораздо больше, чем кажется

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

Оригинал взят у halemaumau в Эттэншн плиз
Дорогие друзья, я имею сказать и это очень серьезно. Не про политику.

2620137
В общем, так. Меня зовут Оля, я довольно молода и буду довольно молодой еще лет десять-двадцать, даже если продолжу бухать в лучших традициях русской интеллигенции. У меня нет (во всяком случае, пока) рака, спида, гепатита, рассеянного склероза и родильной горячки. Близорукость весьма умеренная, гастрит успешно залечен. Все мои родственники и друзья живы, плюс-минус здоровы и обитают далеко от зон каких-либо боевых действий. Я живу в Москве, и у меня хватает денег, чтобы каждый день покупать кофе в старбаксе (честно говоря, даже на сэндвич хватает, и еще остается). Я люблю смешные картинки, велеречивость, секс, текст, тыкать пальцем в закаты над Строгино и ни с хрена пить шампанское середь недели.

Я бы не стала так кудряво себя анонсировать, не будь всей этой разлюли-малине от роду неделя. В том смысле, что примерно неделю назад антидепрессант, который я принимаю, наконец-то достиг в моем организме нужной концентрации и начал действовать. Предшествовали этому знаменательному событию - внимание, сейчас будет драматический пафос - Три. Года. Ебаной. Пустоты. Если без пафоса, то у меня была самая обыкновенная депрессия, если образно - то это были три года в обнимку с дементором из "Гарри Поттера". Если в разрезе "на что я трачу жизнь свою" - три года, которые примерно с тем же успехом можно было пролежать в коме (хоть выспавшейся была бы, наверное). За эти три года я получила диплом, сменила четыре места работы, купила машину и научилась ее водить, еще что-то, еще что-то - короче, если проводить аналогию с комой или летаргическим сном, я неоднократно заслужила приз "Почетный лунатик".
Collapse )

Второй пост - у betrunkenfee в маленькие победы над большой депрессией: если страдает ваш близкий по ограниченю размера не влез, смотрите у автора (набор практических советов).
nuclear lightning

Из жизни синхронных машин

Выборка-свалка заметок из нескольких тем электричества-энергетики (при желании можно обратиться к специализированной литературе): синхронизация, некоторые термины, Выборгская вставка, двигатели предельной нагрузки (а также децл по 81-717 и ВЛ-80). Цитаты в основном по Википедии.

Синхронизация с энергосистемой



Все в курсе, зачем нужна Единая энергетическая система — чем больше объединено, тем в целом система устойчивее при авариях, да и в условиях 9 часовых поясов выравнивание суточной нагрузки — весьма полезно. Но мало задумывается над тем, что все эти генераторы на всех входящих в состав ЕЭС электростанциях, на всей территории и всех 9 часовых поясах — работают синхронно (синфазно). То бишь, в каждый момент времени выдаваемая каждым часть синусоиды (угол поворота ротора) — одинакова! Зачем это нужно? Предположим, какой-то генератор работает "не в такт", тогда, из-за различия угла, будут отличаться напряжения на его выходах и в сети. А значит, он станет не то генератор, не то нагрузка, возникнут громадные встречные токи, которые потекут по его обмоткам, т.е. потоком сети его сожжет нахрен. То есть, синхронность работы необходимо обеспечить до включения генератора в сеть, и далее с высокой точностью постоянно поддерживать. А еще необходимо с достаточно большой точностью поддерживать частоту — отклонение от 50 Гц допустимо очень небольшое. А любое изменение мощности в сети тут же приводит к изменению частоты — нагрузка повысилась, валы турбин тормозятся, частота падает. Надо поднимать выдаваемую мощность. И наоборот. И т.д.

Если задуматься, это ведь, наверное, довольно сложная инженерная задача — обеспечить им всем синхронную работу, по всей стране? На самом деле, не очень. Во-первых, фазы в разных местах страны, конечно, отличаются, ввиду протяженности линий и скорости света (подробнее рассматривает теория Длинных Цепей), Collapse )
nuclear lightning

Устройство DLZ (Dynamically Loadable Zones) в BIND 9

Десять лет назад для BIND 9 появился DLZ, Dynamically Loadable Zones — механизм, позволяющий описывать данные зон не в обычных текстовых файлах (и конфигах), а брать их из внешних источников непосредственно во время обработки запроса. Например, из SQL-базы или LDAP. Таким образом, сервер заранее не знает, какие у него есть зоны, производительность чуть-чуть ниже (обычные файлы зон целиком есть в памяти, а здесь нужно делать запросы), но зато данные можно обновлять в реальном времени, не требуя долгих перезагрузок зон. Сначала существовал в виде отдельных патчей, затем был интегрирован в состав поставки BIND. С тех пор мало что менялось, на сайте автора осталась документация: http://bind-dlz.sourceforge.net/. Однако, сайт не обновлялся с 2004 года, и вообще сайт (и автор) очень своеобразный — так, оказалось, что на странице по модулю DLZ для MySQL (да и другим) документация больше для программиста — какие методы и функции вызываются.

Статья будет полезна системным администраторам и программистам, желающим расширить/изменить SDLZ-компоненты BIND 9 (предполагается, что начальное знакомство с темой уже имеется, по собственно сайту или какому-нибудь howto по конфигурации DLZ — поэтому здесь будут не азы, а объяснение "вглубь"). Админу нужно понимать некоторые особенности работы модулей DLZ, с точки зрения программирования, потому что конфигурирование, скажем, DLZ_MYSQL и DLZ_POSTGRESQL — довольно нетривиально, и чтобы разобраться с ним, нужно иметь представление об устройстве DLZ. При этом документация на сайте весьма ориентирована на программиста, и «сходу» может оказаться непонятной. Здесь в основном пересказываются доступным языком фрагменты документации с сайта DLZ (например, описание работы dlz_mysql), а также текстовые файлы с описанием API для программиста, распространявшиеся в предыдущих версиях DLZ (например, из архива DLZ-0.7.0.tar.gz — программисту, после чтения этой статьи, стоит прочитать и те документы). Кроме этого, здесь описываются некоторые другие особенности программирования внутренностей BIND 9 (с документацией разработчика в ISC вообще всё плохо), и наконец, в качестве примера описывается создание своего собственного SDLZ-модуля DLZ_WILDCARD (полный код доступен), который может использоваться и администраторами для отдачи статической зоны по шаблону FQDN (инструкция по применению ниже). Но обо всём по порядку.

Collapse )
nuclear lightning

Кое-что о TCP-стеке, атаках synflood, accept_filter и параметре listen backlog

При высоких нагрузках и DoS-атаках типа SYN flood бывает необходимо тюнить параметры системы. При этом надо помнить, что последовательность «рубежей защиты» обычно такова, с отсевом на каждой стадии, и глючить может каждый прежде всего надо смотреть их настройки:

  1. Входные балансировщики, например Cisco SLB

  2. Файрвол/IDS на самом хосте, например, pf (synproxy, лимит стейтов и др.)

  3. TCP/IP стек ядра FreeBSD

  4. Наконец, само приложение (например, nginx)


Ниже речь будет о последних двух, это, по большому счету, пересказ http://sysoev.ru/freebsd/netstat.html и фрагментов man-страниц listen(2) и accf_data(9) с мелкими добавками и приложением к современной ситуации. Следует понимать разницу между разными параметрами настройки (например SYN flood имеет лишь опосредованное отношение к длине очередей), поэтому и ведется сей рассказ.

У слушающего сокета в ядре есть 2 очереди: соединений с завершенным TCP 3-way handshake и незавершенных. Последовательность подключения нового клиента по TCP на сервере классически выглядит так:

  1. Клиент прислал SYN. Ядро сервера создает новый сокет и TCP Control Block на новое соединение (сравнительно затратно, можно посмотреть в vmstat -z сумму socket+tcp_inpcb+tcpcb).

  2. Соединение в состоянии SYN_RCVD помещается в incomplete-очередь сокета. Ядро отсылает SYN+ACK, с таймерами перепосылки.

  3. Клиент прислал ACK. Соединение переходит в состояние ESTABLISHED и помещается в очередь готовых соединений


Далее должны произойти, в заранее неизвестной последовательности:

  • Сервер должен сделать на сокете accept(), чем вынет готовое соединение из очереди. После этого ядро выделит еще память на файловый дескриптор — сравнительно немного, но сервер затратит на нового клиента уже свои ресурсы в юзерленде, обычно куда более значительные (вплоть до форка целого процесса).

  • Клиент пришлет данные запроса (протоколы, где сначала должен ответить сервер, рассматривать не будем), которые сервер может читать и обрабатывать.


Атаки типа SYN flood направлены, как известно, на исчерпание ресурсов ядра — на шаге 1 они сразу выделяются на полноценное соединение. Во FreeBSD 4.5 появился механизм syncache(4), который выделяет лишь минимальные данные вместо полноценного соединения (хранение опций пакета и таймер перепосылки для шага 2) — порядка 100-150 байт, точное значение можно посмотреть в vmstat -z | grep syncache. Теперь соединение (новый сокет и TCP Control Block) создается только на шаге 3 (технически сначала в SYN_RCVD, как по-старому, но лишь на микросекунды). Размер кэша регулируется в loader.conf, на 9.0 значение по умолчанию:
# sysctl net.inet.tcp.syncache.cachelimit
net.inet.tcp.syncache.cachelimit: 15360


При нехватке и этого кэша можно использовать механизм syncookie (описан в том же мане), он вообще не использует память на сервере — данные хранятся в опциях SYN-пакета, естественно, ценой потери возможности window scaling, MSS и др. (существует и потенциальная вероятность атак на файрволы). Поэтому их обычно предпочитают не использовать.

Время существования записи в syncache зависит от числа перепосылок, настраивается в sysctl net.inet.tcp.syncache.rexmtlimit. Для значения по умолчанию исходники сообщают, что 3 retransmits corresponds to a timeout of 3 * (1 + 2 + 4 + 8) == 45 seconds. Надо заметить, что здесь не следует путать значение по умолачнию 3 в sysctl с множителем 3 в формуле — это константа в секундах, то есть, если задать 4 в sysctl, то станет уже 3 * (1 + 2 + 4 + 8 + 16) == 93 секунды, и т.д. (подробнее см. описания работы TCP, например, у Стивенса).

Поскольку при этих механизмах соединение создается сразу готовым, incomplete-очередь более не используется. Текущий размер очередей можно посмотреть так:
# netstat -Lan
Current listen queue sizes (qlen/incqlen/maxqlen)
Listen         Local Address        
2/0/3000       *.80                  
0/0/5          *.22                  

Здесь qlen — очередь готовых соединений, а incqlen будет всегда равен нулю. Но, на самом деле, не всегда: с FreeBSD 4.1 появился механизм accept-фильтров — модулей ядра, которые задерживают передачу соединения приложению в accept() до тех пор, пока клиент не пришлет данные запроса, чтобы сэкономить на числе вызовов (переключении контекста) при большой нагрузке. Такие соединения, хотя и находятся в ESTABLISHED, отображаются теперь под incqlen, считаясь в этой очереди. Для того, чтобы accept-фильтры использовались, они должны быть явно запрошены в коде самим приложением (а модуль ядра должен быть загружен до этого).

Остается параметр maxqlen. Он всегда равен параметру backlog, передаваемому в вызов listen(2) (под именем backlog информацию о нем и можно найти в разных источниках). Этот параметр исторически имел размытое определение и трактовался по-разному на разных ОС. На *BSD его значение определяло сумму длин разных очередей, а потому умножалось на полтора, чтобы «с запасом». Сейчас, ввиду всего вышесказанного, он работает несколько иначе, суммы уже нет, есть два отдельных параметра:

  • длина очереди incomplete-соединений (incqlen) в точности ограничена значением backlog

  • длина очереди готовых соединений может быть больше backlog в полтора раза


Умножение производится только при создании нового соединения; собственно же умноженное значение нигде не хранится и не показывается, в netstat отображается всегда то, что передало приложение. Код syncache вызывает на шаге 3 sonewconn(lso, SS_ISCONNECTED);, где код выглядит примерно так:
struct socket *
sonewconn(struct socket *head, int connstatus)
{
        over = (head->so_qlen > 3 * head->so_qlimit / 2);
        if (over)
                return (NULL);
        if (на сокете включен SO_ACCEPTFILTER)
                connstatus = 0;
...
        if (connstatus)
                добавить в complete-очередь, qlen++
        else
                добавить в incomplete-очередь (убив при необходимости самое старое), incqlen++ 

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

Что происходит, если очереди переполняются? Соединение просто сбрасывается, возвращается TCP RST (Connection refused).

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

Приложения, проблемы

Обычно настройку длины очереди можно найти по упоминавшемуся имени, либо она по умолчанию имеет достаточное значение, не требующее настройки. В том же nginx директиве listen можно задать так и называющиеся параметры — backlog=32000 accept_filter=httpready. Но, например, BIND отличился — в нем иначе и то, и другое. BIND 9 Administrator Reference Manual (Bv9ARM.pdf) именует параметр backlog иначе:

tcp-listen-queue

The listen queue depth. The default and minimum is 3. If the kernel supports the accept filter ”dataready” this also controls how many TCP connections that will be queued in kernel space waiting for some data before being passed to accept. Values less than 3 will be silently raised.

То есть, в принципе до запуска BIND можно делать:
kldload accf_data

Еще следует отметить, что раньше были только accf_data и accf_http. В последнее время появился еще accf_dns, но пока BIND его не поддерживает. Стоит вернуться к этой теме в будущем.

Разработчики nginx считают (пост 1, пост 2, что реализация accept_filter'ов (и TCP_DEFER_ACCEPT, аналога accf_data в Linux) в их нынешнем виде — скорее зло, чем благо. Почему? Потому что соединение может висеть в этом состоянии сколь угодно долго, и будет вытеснено только при достижении хвоста очереди. Такие приложения, как nginx, могли бы контролировать поступление данных по своим таймаутам.

Теоретически, механизм accept_filter'ов во FreeBSD позволяет это сделать вполне безболезненно — в вызове setsockopt(2) имеется аж 240 байт на передачу аргумента в фильтр. Так что желающие вполне могут реализовать, patches are welcome, как говорится.

И, в тему к обсуждению проблем — тот же accf_http имеет несколько ограничений в своей работе, из-за чего он в некоторых случаях как бы не работает. Точнее, любой accept_filter при возникновении любых непонятных ситуаций ложится спать ведет себя так, как будто его нет: тут же передает соединение в приложение — приложению лучше знать, что делать. Так вот, accf_http поступает так при отличающейся от 1.0 или 1.1 версии HTTP (если включен соответствующий sysctl), если буфер сокета заполнился — а также, если HTTP-метод был им не распознан. А понимает он их только два — GET и HEAD. Причем именно так, большими буквами, с начала строки. Если что-то не так — всё, коннект сразу идет в приложение. В общем, тоже имеется простор для улучшений...

Ссылки: об управлении памятью в ядре FreeBSD (упоминавшемся vmstat) и других затратах на буфера для соединения можно прочитать тут.
nuclear lightning

"Как удержать кого-то при себе навсегда"

Перевод статьи "How to keep someone with you forever" (с дополнениями в конце из наблюдений).

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

Вам нужно создать извращенную систему (в оригинале sick system — прим. перев.).

Извращенная система имеет четыре основных правила:
Collapse )
Оригинальная англоязычная статья вызвала бурное обсуждение в комментариях, некоторые из интересных ссылок были добавлены в конец оригинального поста. Для одной из ссылок в Сети также доступен перевод на русский язык:

Не все вампиры сосут кровь — Антон ЛаВей обсуждает психических вампиров — людей, которые изображают беспомощность, чтобы держать других под своим контролем. Это в точности тот типаж людей, которые устраивают извращенные системы.

Collapse )
Распространение текста приветствуется, при условии сохранении ссылки на оригинал, без постскриптума ниже.

P.S. Это мой первый перевод не-технического текста, просьба сильно ногами не пинать, лучше конструктивные замечания в комменты :)
nuclear lightning

IpfwNg

В честь 26 годовщины 26 апреля уволился с текущей работы и таки наконец начал проект http://wiki.freebsd.org/IpfwNg — хотя на работе FreeBSD и была основной системой, реальную возможность пилить ядро я так и не получил (хотя тот же NAT64 нам бы понадобился не через полгода, так через год). В ближайшие недели посижу дома и надеюсь сделать хотя бы скелет, который можно будет потом уже в свободное время потихоньку пилить — работы по проекту предстоит очень много.

Желающие обсудить по делу — велкам в каменты (хотя я туда еще не все наброски оформил).
nuclear lightning

Управление памятью в сетевой подсистеме и ядре FreeBSD в целом

Эта статья будет полезна системным администраторам и программистам, работающим в ядре FreeBSD. Осмыслив изложенное здесь, можно понять, почему же бывает паника по kmem, что такое состояние keglim/zoneli, как читать непонятные циферки в выводе vmstat -m / vmstat -z, и что же такое эти самые mbuf и nmbclusters. Программистам, приступающим к работе не в сетевой подсистеме, всё равно будет интересно узнать о дополнительных интерфейсах, помимо привычных malloc()/free(), и отличиях этих стандартных функций.
Поскольку эта статья — введение в комплекс связанных обширных тем, она предполагает наличие некоторых базовых понятий (например, чем виртуальная память отличается от физической), и не углубляется в некоторые специфичные вещи (типа packet secondary zone), особенно появившиеся не так давно.
Collapse )