?

Log in

Nuclear Lightning's Track
 
[Most Recent Entries] [Calendar View] [Friends]

Below are the 26 most recent journal entries recorded in Vadim Goncharov's LiveJournal:

[ << Previous 26 ]
Thursday, February 11th, 2016
12:37 am
"Астрологи объявили год БЕЗНЕФТИ! Население всех нефтебаксов уменьшилось вдвое!"
Попадалась недавно, кажется в ЖЖ magazine, ссылка о том, что астрологи, экстрасенсы, ясновидящие и т.п. публика — меньшее количество раз попали пальцем в небо в предсказании цены на нефть и курса бакса, нежели экономисты. Оно и понятно, предсказывать точные значения, особенно краткосрочные, похоже, в принципе невозможно. А что, если попробовать наоборот? То есть, пойти в обратную сторону, всё более обобщенно и расплывчато, пока оно не станет верным? :) Что ж, ловим ближайшего астролога за (кометный) хвост и допрашиваем на предмет того, что там на небе есть такого долгоиграющего.

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

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

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

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

Мощно.
Tuesday, November 17th, 2015
11:56 pm
Оказывается, их вокруг гораздо больше, чем кажется
Два поста про депрессию. Страшное дело, оказывается это куда более как распространено, чем можно подумать по оному слову. И да, тот кто не испытывал похожего - не поймет того, у кого она есть. Самое удивительное, что я например испытывал и понимаю - но вот никогда бы не подумал, что у меня бывала депрессия. Так что таки да, прочитать будет полезно.

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

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

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

Второй пост - у betrunkenfee в маленькие победы над большой депрессией: если страдает ваш близкий по ограниченю размера не влез, смотрите у автора (набор практических советов).
Wednesday, January 1st, 2014
3:30 pm
Из жизни синхронных машин
Выборка-свалка заметок из нескольких тем электричества-энергетики (при желании можно обратиться к специализированной литературе): синхронизация, некоторые термины, Выборгская вставка, двигатели предельной нагрузки (а также децл по 81-717 и ВЛ-80). Цитаты в основном по Википедии.

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



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

Если задуматься, это ведь, наверное, довольно сложная инженерная задача — обеспечить им всем синхронную работу, по всей стране? На самом деле, не очень. Во-первых, фазы в разных местах страны, конечно, отличаются, ввиду протяженности линий и скорости света (подробнее рассматривает теория Длинных Цепей), Read more...Collapse )
Monday, January 28th, 2013
1:34 am
Устройство 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 (инструкция по применению ниже). Но обо всём по порядку.

Read more...Collapse )
Sunday, December 2nd, 2012
12:59 am
Кое-что о 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) и других затратах на буфера для соединения можно прочитать тут.
Wednesday, July 4th, 2012
4:36 am
"Как удержать кого-то при себе навсегда"
Перевод статьи "How to keep someone with you forever" (с дополнениями в конце из наблюдений).

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

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

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

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

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

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

Желающие обсудить по делу — велкам в каменты (хотя я туда еще не все наброски оформил).
Tuesday, January 31st, 2012
11:59 pm
Управление памятью в сетевой подсистеме и ядре FreeBSD в целом
Эта статья будет полезна системным администраторам и программистам, работающим в ядре FreeBSD. Осмыслив изложенное здесь, можно понять, почему же бывает паника по kmem, что такое состояние keglim/zoneli, как читать непонятные циферки в выводе vmstat -m / vmstat -z, и что же такое эти самые mbuf и nmbclusters. Программистам, приступающим к работе не в сетевой подсистеме, всё равно будет интересно узнать о дополнительных интерфейсах, помимо привычных malloc()/free(), и отличиях этих стандартных функций.
Поскольку эта статья — введение в комплекс связанных обширных тем, она предполагает наличие некоторых базовых понятий (например, чем виртуальная память отличается от физической), и не углубляется в некоторые специфичные вещи (типа packet secondary zone), особенно появившиеся не так давно.
Read more...Collapse )
Friday, January 13th, 2012
6:23 pm
Как я играл в Яндекс.Root 2011
Пока на больничном, есть свободное время, решил записать воспоминания про олимпиаду для Linux-администраторов — а то уже не всё помню. В этом году её честно назвали олимпиадой для Linux-администраторов, и я, будучи фряшником, хотя сомневался, всё-таки пошел попробовать. Попробовал очень даже неплохо :) Причем, что любопытно, очень даже неплохо из BSD-админов "попробовал" не только я: если во 2-й тур прошло 5 человек из 36 с канала #freebsd (shattered, dmn42, Jay, imax и ваш покорный слуга) — то в финал пробралось четверо из них. Четверо из десяти. По-моему, эти 40% на чисто линуксовой олимпиаде вполне подтверждают тезис о том, что BSDшники профессиональнее =) Причем дело не в том, что эти люди просто "случайно" оказались универсалами, знающими несколько платформ (и случайно завсегдатаями канала #freebsd). Они, как и я, еще и предпочитают эту систему, а лично я — так и вообще имел не так много опыта с другими системами. Мой опыт общения с линуксами в основном ограничивается SLES на вычислительном кластере родного политеха. И сусю эту предписывалось трогать как можно меньше (суппорт, мол, есть), и был этот кластер толком никому не нужен — увы, провинциальные реалии... так что мы большую часть времени занимались если не виндой и суппортом не умеющих писать на Си юзеров, то, кхм, саморазвитием (и отнюдь не по линуксовой части).

Но обо всём по порядку. Первые игры олимпиады — вопросы по теории, но это лишь отсев, а не что-то, способное действительно показать профессионалов в отрасли. Определяет практика, и первая практика на олимпиаде началась во втором туре. 25 октября нужно было починить, кроме мелочей, LDAP, Джумлу и Друпал (да, мне тоже было смешно), в виртуалках, доступ в которые был сделан через веб — типа консоль tmux. Видимо, специально затем, чтобы больше времени потратили — все ж к screen привыкли. Эта игра глючила и глючила, и довольно быстро вообще прекратилась, поскольку кто-то нашел дырку в реализации организаторами доступа к tmux через web — и пробрался из виртуалку и хост-машину, где еще и ответы лежали. Так что игру отменили, и я уже даже не помню, что там было.

Повторная игра 2-го тура была 27 октября, вот там уже был человеческий VNC. Правда, интерфейс "старт/стоп виртуальной машины" был сделан на вебе неудобно, впрочем, то мелочи (хотя у некоторых они вызвали большие нарекания). Итак, "физическая" консоль виртуалки по VNC, в виртуалке — Убунта. Тщательно сломанная (вообще это уровень уже даже не финала, а суперфинала прошлого года), настолько, что паникует при загрузке. И надо её починить — мониторинг снаружи проверяет сервисы этой машины, которые должны работать (ессно, пока на ней нет поднятой сети, всё горит красным). Сделать надо всё за 1 час, чем больше и раньше других сделано — тем выше место в таблице участников.

Вот тут начинается самое интересное. Я эту Ubuntu, как и вообще современный Линукс, видел вживую впервые в жизни. Камрад Jay описал чуть спустя то, что на этой игре было по заданиям. А у меня было интересное психологическое состояние, и многие из обсуждавшихся вещей меня удивили — я их не заметил, хотя и решил. Наверное, ближе всего будет описать это состояние, как "танк, рвущийся на прорыв через препятствия". Воля к победе, боевой дух, решимость, как её там еще?.. Короче, время пошло, взлетаем.
Под катом не без сисекCollapse )
Что можно сказать по итогу — в отличие от прошлого года, по этой олимпиаде уже вполне можно судить о положении дел в отрасли, её результаты показывают уже что-то реальное — всё стало гораздо ближе к практике. На прошлой было три теоретических теста (1 тур, 2 тур, финал), пусть и разных по форме, и лишь одна игра с практикой — суперфинал. В этой — только первый тур с отсевом по теории, но вот все 3 практики были однообразные — "починить упавший сервер за 1 час".

Поскольку победителям прошлых лет запрещено участвовать в следующих олимпиадах, могу свободно высказать предположения, как можно было бы её еще улучшить. Например, в финале можно было бы не чинить сервер, а настраивать что-то с нуля. А в суперфинале — оттюнить медленно работающий сервер (привет, хайлоад). Или, там, разобраться с тем, почему в боевых условиях не работает поделие криворукого программера (это классическое бодание админов и программеров, вошедшее в байки и мемы, бывает даже в самом Яндексе). Одна беда — это требует больше времени, а в программе финального дня еще экскурсия в ДЦ Яндекса, затягивающаяся по московским пробкам... Может быть, стоило бы объединить финал и суперфинал, чтоб уместилось, но, наверное, это будет противоречить правилам, которых хочет придерживаться Яндекс...
Wednesday, January 11th, 2012
4:46 am
О корректности "работает — не трогай" и понятии "так правильно"
Давно известна фраза "работает — не трогай", типа принцип хорошего админа, всё такое. Понятно, откуда она взялась — есть такие неуемные личности, которым скучно, а разбираться, как работает система, чем может грозить поломка, им не хочется (обычно в силу возраста, соответствующего жопыта еще нет). Но нередко, особенно в последнее время, вижу в сообществе и другую сторону — когда этой фразой оправдывается консервативность и нежелание идти на любые перемены. Даже если они уже назрели и нужны. То есть сей афоризм несет полезный смысл, но в буквальном виде — всё-таки неверен.

Я для себя переформулировал его как "работает — не ломай" (улучшать можно, при условии, что ...), но это тоже несколько не то, отчасти из-за самоочевидности. И вот недавно в рассылке UAFUG пролетела такая цитата за авторством Michael Pigurnow:
Лень — враг прогресса (c)
имхо причина всего этого в 2-х факторах:
a. Лень в самом худшем ее проявлении. Когда в принципе "Работает — не
   трогай (улучшай)" забывается важная оговорочка: работает _правильно_.
   Из-за чего работающее уже через тухес воспринимается как само собой
   разумеющееся, что ведет к оплевыванию любых попыток переделки ЭТОГО по
   правилам и по уму.
b. Благодушная беспечность: "Чрезвычайные ситуации бывают исключительно редко
   и уж конечно же _не со мной_"

Вот тут всё становится на свои места, особенно если вспомнить не менее известное "make it work, make it right, make it fast" (именно в такой последовательности, и каждое следующее не раньше имеющегося предыдущего). Остается только с виду незаметный, но очень важный вопрос — а что же такое правильно? Вроде всем понятное слово, но каждый под ним понимает что-то свое, обычно интуитивно понимаемое и расплывчатое. Более того, никакого абсолютного "правильно", общего для всех и всегда, нет и быть не может. Тогда что же это?

Я бы определил "правильно" как 3 компонента — цели, ценности и приоритеты. Они неразрывно связаны друг с другом.
  • Правильно что-то делается или нет, зависит от цели, того, что требуется получить — что правильно в одной задаче, может быть неправильным в другой.

  • При той же самой цели, делать что-то можно разными способами. Как выбирается способ? Между задачами соблюдаются какие-то более-менее постоянные ценности, принципы. Например, "деньги не пахнут" или "всё надо делать качественно". Ценности для человека — это то, что значимо, к чему он неравнодушен, на что ему не похуй. То, что можно описать словами "хорошо" и "плохо", в отличие от всех остальных вещей, к которым нет ничего, кроме равнодушия. Ну типа, "писать понятный читаемый код — это хорошо", "ломать мне посреди ночи работавший сервер, который я поеду чинить — плохо". (Замечу в скобках, что речь стоит вести не о декларируемых ценностях — если человеку плевать на утверждение "уступать старушкам место в автобусе — хорошо", реальной ценности для него это не представляет. Но эти темы уже совсем-совсем оффтопик.)

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

Легко видеть, что, например, при наличии ценности "рабочий плохой код лучше перспективной идеи" получим следствие "если это не работает — это неправильно" (но при определенных обстоятельствах приоритеты могут изменить вывод на прямо противоположный, скажем, на отрезке в 10 лет).

Или что изо всех сил сидеть на FreeBSD 4.11 и бэкпортить патчи — неправильно, потому что трата времени админа на бэкпорты — не в целях и не в приоритетах.

И, возвращаясь к исходной фразе, становится понятно, когда же "трогать" — ведь и цели, и ценности, и приоритеты могут меняться со временем. Что было правильным год назад, может уже не быть таковым сегодня (ситуация меняется). Вот тогда влезать и менять работающее — не просто можно, а нужно.

P.S. Конечно, понятие правильности всё равно останется субъективным — не только от различия целей, но и от разницы в охватываемом в данной ситуации количестве ценностей и приоритетов у разных людей, учитываемых факторах (зависит от всё того же жизненного опыта). Тем не менее, осознавать свои цели, ценности и приоритеты (и общаться об этом с другими людьми, если есть такая необходимость) несколько проще, если понимать, откуда у своих представлений о "правильности" ноги растут.
Saturday, December 31st, 2011
11:54 pm
С новым 1905 годом!
А я тут в результате http://root.yandex.ru (кстати, тема для отдельного поста — в десятке финалистов линуксовой олимпиады было четверо фряшников) из Томска переехал в Москву понаехал в Нерезиновую. Успел, наконец, разобраться со всеми тяготами и хлопотами переезда до наступления нового, по всем прогнозам тяжелого, года. Некоторые из которых проводят некоторые исторические параллели (вот Николай II — тоже взошел на престол примерно за 11 лет до первых событий). Что ж, год будет тяжелый, но пока — отдыхаем и пьем.

Пять минууут, пять минуууут... С Новым 1905 годом вас всех, товарищи!
Friday, August 5th, 2011
6:59 am
Каковы проблемы FreeBSD и пути их решения? Часть 2: анализ и опрос
Продолжение предыдущего поста, рекомендуется прочитать из него хотя бы введение.

...Таким образом, имеется два утверждения (подробно рассматриваемые далее), причем оба истинные и друг другу не противоречат (по второму вопросу — высказывайте в комментах ваши взгляды на то, каковы еще проблемы FreeBSD и как их можно решить.):

Часть I. Конкретно в случае Рампочты уход с FreeBSD затеян из-за неадеквата руководства, внутри у них полный бардак (по словам инсайдеров).

Часть II. У FreeBSD действительно есть серьезные проблемы, или мы их решаем, или нам каюк.
Read more...Collapse )
Wednesday, August 3rd, 2011
7:14 am
Каковы проблемы FreeBSD и пути их решения? Часть 1: Рампочта.
Три недели назад Андрей Шетухин, руководитель отдела почты Rambler, сообщил о начале миграции своего почтового кластера (порядка 500 серверов) с FreeBSD на Linux (Debian/Ubuntu), поскольку FreeBSD перестала его устраивать. Дискуссия в комментах, которых уже более полутысячи, разгорелась нешуточная. В комментах также стало известно, что аналогичный переход планирует Яндекс на своем поисковом кластере, который в данный момент работает целиком на FreeBSD, а это примерно 25000-30000 серверов, и порядка 60% мощностей Яндекса. Такая потеря — это для FreeBSD уже серьезно. С такими тенденциями система, к радости ликующих подонков, станет таки умирать.

Очевидно, что подобные решения не принимаются на ровном месте, и существуют определенные причины, проблемы, которые мы, FreeBSD, можем начать исправлять, пока не стало слишком уж поздно. BSD-сообщество привыкло закрывать глаза на многие проблемы, считая их несущественными. Более так поступать нельзя — легко списать всё на тараканы в голове менеджмента и ничего не делать, вот только постоянное повторение такого образа действий приведет к тому, что лет через 5 работу BSD-администратора будет уже не найти (Вы такую перспективу себе хотите? Я лично — нет). Однако, с другой стороны, тот же Шетухин 3 месяца назад писал "Вывод простой: миграция на Linux нецелесообразна, так как затраты на нее не окупятся" о том, что разницы в производительности FreeBSD и Linux для их целей не выявлено. То бишь, следует отделить зерна от плевел и решать те проблемы, которые действительно есть.

Таким образом, имеется два утверждения (которые будут более подробно рассмотрены далее), причем оба истинные и друг другу не противоречат:

I. Конкретно в случае Рампочты уход с FreeBSD затеян из-за неадеквата руководства, внутри у них полный бардак (по словам инсайдеров).
II. У FreeBSD действительно есть серьезные проблемы, нам необходимо их решать, иначе нам каюк.

По второму вопросу — в следующем посте предполагается анализ, каковы еще проблемы FreeBSD и как их можно решить, с опросом мнения читателей. Но сначала — о том, почему держателям акций Рамблера стоит продавать их, пока курс еще хороший.
Read more...Collapse )
Wednesday, June 1st, 2011
11:59 pm
Астрологический портрет FreeBSD

Гороскоп FreeBSD


 А Водолей — это вон те 2 резистора?
IT-шник, впервые увидевший натальную карту

Давно подмечал, что у больших программных проектов, особенно операционных систем, есть нечто вроде характера — разные проекты вызывают разные ощущения. Причем сюда входит как сам проект, так и составляющее его сообщество людей. И вот как-то раз наткнулся на http://avi.alkalay.net/1991/08/linux-astral-map.html, где описывается характер Linux, правда, очень кратко. Поскольку меня больше интересует FreeBSD, я обратился к двум знакомым астрологам с просьбой описать характер родной ОС.

Обычно гороскопы делают для людей, но можно сделать для чего угодно — например, для фирмы/предприятия. Собственно, эти товарищи далеки от IT, потому и делалось как для фирмы. Так как информации из гороскопа можно вытянуть очень много, а нормальный анализ всего этого — большая работа, занимающая много времени и стоящая денег, мне описали довольно кратко. При том каждого астролога я расспрашивал только о части карты, дабы не напрягать лишний раз, и свёл вместе сам. Что, однако, всё равно вылилось в большой пост, хотя и является относительно малой частью того, что вообще можно вытащить из гороскопа.

Итак, гороскоп — карта положения ряда объектов на небе, как они видны в месте рождения в момент рождения. Что считать моментом рождения человека, понятно, а вот что будет таковым для программного проекта? На сайте в архивных материалах обнаружилось http://www.freebsd.org/news/1993/freebsd-coined.html — фрагмент переписки отцов-основателей. Здесь проект впервые получил имя, чем не момент рождения? Естественно, нужно проверить, тот ли самый это момент. Для человека процедура уточнения времени рождения называется ректификацией, и производится по датам крупных событий в жизни (требуется 6-10). Нужна она затем, что в роддомах время бывает записано с округлением или погрешностью, а для прогнозирования событий по некоторым методам ошибка в 4 минуты дает сдвиг на год, да и вообще за сутки всё очень сильно меняется.

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

Поскольку в опенсорсе всё приходится делать самому, то и картинку натальной карты (гороскопа рождения) тоже пришлось добывать самому. Поставил ports/misc/astrolog, и получилось вот такое:
Трактовка гороскопа следуетCollapse )
Tuesday, April 26th, 2011
4:23 am
01:23:39
Ну что, четверть века прошла, и вот полку прибыло. С праздником!
Wednesday, April 13th, 2011
2:44 am
50 лет
Пора выпить 50 грамм и пересмотреть "Укрощение огня". Они были первыми.

...И немедленно выпил.
Friday, February 11th, 2011
5:11 am
"Netgraph для пользователя" и литературная критика; подходы к интерфейсам систем
Получил я на днях вот такую критику своей статьи "Netgraph для пользователя", в IRC (разговор сокращен):

<A_Z> Следует помнить, что в этом формате как узлы, так и хуки netgraph являются узлами изображенного графа — просто узлы netgraph изображены как прямоугольники (подписаны имя, ID, тип), а хуки netgraph — как восьмиугольники, и ребра, соединяющие узел со своими хуками, более жирные. Так сделано для большей наглядности и выделенности хуков, а также потому, что при обычном рисовании графа не получилось бы у одного ребра написать два названия (ведь ребро netgraph состоит
<A_Z> если кто-то прочитает и переварит это с первого раза, тот герой.
<A_Z> если помнить, что масло на котором мы жарим картошку является подсолнечным маслом, то можно предположить, что картошка является жареной и это потому, что мы жарили картошку
<levsha> ну может ведь и салом оказаться!
<Miha> картошка может оказаться салом!
<A_Z> Если название вызвало у Вас ассоциации из наркоманской фени. Вы правильно подумали. Netgraph действительно представляет собой краб^Wгриб
<nuclight> A_Z: конструктивные предложения есть?
<A_Z> nuclight: рассказывать? я уже говорил а) стиль изложения a-la петросян б) сложное построение предложений в) множесто неудачных аналогий и варваризма г) есть сомнения, что это для пользователей
<nuclight> A_Z: конструктивная критика направлена на то, чтобы исправить/улучшить, для чего необходимо указывать на конкретные вещи, и способы их исправления. Из чего следует, что 2 строчки никак не могут быть конструктивной критикой — ты к каждому пункту не привел даже пяток примеров, из которых можно было бы проследить тенденцию твоих субъективных впечатлений.
<nuclight> A_Z: стиль изложения — в каком месте? почему не давно изветсный прием отдыха читателя среди горы информации, напрмер? Сложное построение предложений — где? примеры, как было бы построить лучше (я вообще-то следил и слишком сложные предложения не делал)? Множество неудачных и варваризма — какие именно? в чем их неудачность и варваризм для тебя? какие были бы лучше? Есть сомнения — в чем это выражается? где следовало разжевать еще?
<nuclight> A_Z: уже сам факт того, что я тебе должен встречные вопросы задавать говорит, что это не была конструктивная критика. Литературные критики во времена оные целые эссе писали, тебе же нужно было написать от силы килобайта два, а не сорок два, как мне.
<A_Z> nuclight: вот тебе мои два килобайта


И вот текст собственно рецензии (кладу тут для истории, чтоб не потерялся):
Рецензия без запятых.

После прочтения статьи Вадима Гончарова "Netgraph для пользователя" я окунулся
в мир грибов и дисктретной математики. Read more...Collapse )
Tuesday, February 8th, 2011
6:09 am
Netgraph для пользователя: некоторые типы узлов
Как известно, инженер не должен помнить наизусть кучу формул, констант, свойств материалов, ключей командной строки и прочей информации: он должен помнить общие принципы, и уметь пользоваться справочниками, в которых и можно посмотреть нужное. А также уметь эту справочную информацию найти (знать, в какие справочники смотреть). Общие принципы netgraph были описаны в предыдущем посте, справочниками служат man-страницы и исходные тексты. Остается рассказать, какие узлы netgraph существуют (куда смотреть), и что они умеют — обзор того, что система умеет, какие задачи можно решать, что же именно можно комбинировать друг с другом.

Конечно, уделить внимание всем типам узлов не получится (ведь всего их уже более 60!), но хотя бы по некоторым будет иногда и такая информация, которой нет непосредственно в справочнике. Кроме того, этот пост можно рассматривать как приложение к предыдущему (ограничения на объем поста ЖЖ не позволяют даже поставить ссылку там сюда), для понимания материала необходимо его прочитать. Возможно, здесь будут и другие дополнения к нему.
Итак, узлы можно условно разделить на...Collapse )
Wednesday, January 26th, 2011
8:24 pm
26
26! Круглая дата! Столько бывает только раз в жизни!

Вот и дожил наконец до эпохального. Ура!

И природа со мной солидарна - сегодня 15000 день от начала эпохи:
$ echo `date +%s` / 86400 | bc
15000


Пожелаю себе следования путем 26, яркого и огненного. Вперед, к вершинам и победам!
Tuesday, January 18th, 2011
4:01 am
Netgraph для пользователя
Многие слышали о сетевой подсистеме Netgraph во FreeBSD, но далеко не все представляют себе, что же это такое, как оно работает, и зачем оно нужно — кроме того, что на нем работает mpd (известная очень производительная реализация PPP/PPTP/L2TP). Да еще по сети ходят многочисленные Howto типа "как считать Netflow на нетграфе", где приводят примеры решения конкретных задач, о самой же подсистеме рассказывая "галопом по Европам" (пишите, мол, так, "синтаксис такой-то").

Проблема в том, что вся документация по netgraph рассчитана на программистов: как маны, так и единственная достаточно подробная статья от автора подсистемы "Все о Netgraph" — в ней дается общий обзор, а за подробностями читатель отсылается в исходники. Что, разумеется, отпугивает новичков, поскольку кажется слишком сложным, а читатели, привыкшие к другим ОС, часто не понимают суть системы и зачем она нужна, если есть vtun, ipt_netflow и другие решения для типовых частных случаев.

Между тем netgraph — это реализованный в ядре коммуникационный фреймворк общего назначения, и в использовании он не сложнее, чем длинная командная строка вида "prog1 | grep | sort | sed | prog2 | awk", просто для начала необходимо понять ряд вещей, о которых я и попытаюсь рассказать доступным языком.
(Примечание: далее будут использованы некоторые фрагменты упоминавшейся выше статьи "All about NetGraph", и кое-где будут примечания с пометкой AANG, показывающие места, в которых та статья уже устарела)
А поскольку понять всё целиком с наскоку нельзя, запаситесь терпениемCollapse )
Wednesday, November 3rd, 2010
11:35 pm
Мск
В связи с http://root.yandex.ru/ буду с 18 по 21 число в Москве. Желающие пересечься - велкам в комменты ;)

P.S. Если по части FreeBSD/*nix, то у #freebsd@RusNet намечается коннект, соответственно, лучше на него :)
Thursday, July 15th, 2010
4:15 am
Модификация ToS/DSCP/TTL/etc. на FreeBSD: ng_patch
Патчи, позволяющие матчить и изменять ToS/DSCP на FreeBSD, ходят в разных вариантах по сети уже лет шесть, вот очередная инкарнация, например. К сожалению, ни один из них так и не попал в базовую систему, хотя пример по ссылке, скажем, для конкретной задачи удобнее того, что описано ниже. Даже возникает подозрение, что это всё потому, что предыдущие решения были недостаточно общие :) Вот Maxim Ignatenko написал ноду ng_patch(4) - и её, наконец, закоммиттили, а недавно смержили в 8-STABLE (r209843) и вчера - в 7-STABLE (r210019). Работает также на 6.4, если убрать в коде CSUM_SCTP, я проверял.
В настоящее время ng_patch - единственный штатный способ поменять что-то в проходящем пакете. Зато, в отличие от других решений (в том числе на других ОС), эта нода позволяет производить последовательность операций над произвольными байтами пакета, не только ToS или TTL. В мане рассмотрены примеры изменения ToS и TTL, я же расскажу чуть подробнее, с примером для DSCP.Read more...Collapse )
Wednesday, July 7th, 2010
6:48 am
Torrent: альтернативный способ детектирования
Со времени событий вокруг uTP прошло более 4 месяцев, разработчики uTorrent на месте не стояли, в теме на nag.ru тоже накатали уже более сорока страниц. Придумал и я принципиально новый способ ловить соединения торрентов, но обо всём по порядку.Рабочий скрипт с демонстрацией концепта прилагаетсяCollapse )
Wednesday, March 3rd, 2010
11:09 pm
недостающий кусок к "ipfw: порядок прохождения пакетов, сложные случаи"
К посту http://nuclight.livejournal.com/124348.html в свое время не всё влезло, из-за ограничений на объем поста в ЖЖ (судя по всему 65535 в байтах, причем UTF-8, так как для разной пропорции русского текста длина переменная и непредсказуемая). Ниже идет недостающий кусок, с того места, где там прервалось. Может быть, со временем, что-нибудь еще добавится :)
Итак, продолжение UPD2 про IPSEC в 6.xCollapse )

UPD3: По состоянию на 17.09.10 выше только описание порядка IPSEC для 6.x (в других версиях уже другое), да и то, как выяснилось, неточное. Кроме того:UPD3 про kern/147720 и несколько таблиц при tableargCollapse )
Sunday, February 28th, 2010
11:59 pm
Фильтрация uTP (Torrent UDP) внутри PPTP GRE
Краткое содержание: как отфильтровать uTP на FreeBSD в теме на Наге уже сказали, однако для случая пакетов внутри туннеля PPTP GRE решения не было, о чем здесь и будет рассказано, но сначала - предыстория.

У вас вдруг стал хуже работать Интернет?..


В конце 2008 года разработчики uTorrent собрались заменить транспортный протокол с TCP на UDP, реализовав поверх него свою прослойку под названием чTP - дескать, так будет эффективнее. Тогда же исследователь по имени Ричард Беннет заявил, что это будет полная жопа для всего Интернета - UDP менее 2% во всём трафике, он используется для приложений реального времени (игры, телефония) и для критически важного DNS, в общем, пострадают все, из-за отсутствия в нём нормального congestion control (обработки перегрузок сети). Разработчики на это ответили, что они сделают congestion control еще лучше, чем в TCP, и торрент станет даже меньше забивать каналы и мешать другим, чем сейчас. И включили по умолчанию новый протокол uTP в бета-версиях uTorrent 1.8 (правда, сначала только на прием). Время шло, обещанной жопы всея Интернета не было...
До этого февраля. Буквально в понедельник админы бывшего СССР начали спрашивать друг друга, у всех ли отмечено сильное возрастание нагрузки за последние дни. Таки да, оказалось у многих. Выяснилось, что месяц назад вышел uTorrent 2.0, у кучи народа вылезло окошко с предложением обновиться, и с начала февраля пошел рост PPS (нагрузки по пакетам в секунду), причем обратите внимание, не трафика. Много где оборудование к такому неожиданному повороту сюжета было не готово, и проблемы работы Интернета ощутили на себе все, не только "качки". Более того, не только оборудование провайдеров - у многих стали гнать домашние роутеры и ADSL-модемы (вот пост на Хабре на тему), хотя опять же человек может не связать обновление у себя uTorrent и начать обвинять провайдера.
Read more...Collapse )
[ << Previous 26 ]
About LiveJournal.com