Наш умозрительный провайдер linkmeup взрослеет и обрастает по-тихоньку всеми услугами обычных операторов связи. Теперь мы доросли до IPTV.
Отсюда вытекает необходимость настройки мультикастовой маршрутизации и в первую очередь понимание того, что вообще такое мультикаст.
Это первое отклонение от привычных нам принципов работы IP-сетей. Всё-таки парадигма многоадресной рассылки в корне отличается от тёплого лампового юникаста.
Можно даже сказать, это в некоторой степени бросает вызов гибкости вашего разума в понимании новых подходов.

В этой статье сосредоточимся на следующем:

• Общее понимание Multicast
• Протокол IGMP
• Протокол PIM
• >>>PIM Dense Mode
• >>>Pim Sparse Mode
• >>>SPT Switchover — переключение RPT-SPT
• >>>DR, Assert, Forwarder
• >>>Автоматический выбор RP
• >>>SSM
• >>>BIDIR PIM
• Мультикаст на канальном уровне
• >>>IGMP-Snooping
• >>>MVR

Существуют три вида лжи: ложь, наглая ложь и статистика (источник)

Есть такой замечательный жанр — "вредные советы", в котором детям дают советы, а дети, как известно, всё делают наоборот и получается всё как раз правильно. Может быть и со всем остальным так получится?

Статистика, инфографика, big data, анализ данных и data science — этим сейчас кто только не занят. Все знают как правильно всем этим заниматься, осталось только кому-то написать как НЕ нужно этого делать. В данной статье мы именно этим и займемся.


Hazen Robert "Curve fitting". 1978, Science.

Структура статьи:

1. Введение
2. Предвзятая выборка (Sampling bias)
3. Правильно выбираем среднее (Well-chosen average)
4. И еще 10 неудачных экспериментов, про которые мы не написали
5. Играем со шкалой
6. Выбираем 100%
7. Скрываем нужные числа
8. Визуальная метафора
9. Пример качественной визуализации
10. Заключение и дальнейшее чтение

У многих людей, как-либо связанных с безопасностью, периодически возникает желание заняться pentest'ом, то есть тестом на проникновение. И чаще всего начинают все с pentest'а веб-приложений. Порог вхождения довольно мал (простейшая sqli определяется добавлением кавычки в параметр и эксплуатируется не особо сложнее), но при этом встречаются и довольно сложные задания, которые заставляют потратить пару-тройку дней на ковыряние.
Но возникает вопрос — где применять теоретические знания, без страха внезапного появления маски-шоу? Под катом проведу небольшой обзор полигонов для экспериментов по pentest'у.

Введение

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

Один в поле – ИТ-директор!

Время от времени меня приглашают в небольшие компании чтобы «разобраться» с их единственным системным администратором. Список претензий к работе их штатного специалиста всегда примерно одинаков: медленно выполняет поставленные задачи, часто «ничего не работает», а даже был вот такой случай…
При этом зачастую уровень претензий к работе системного администратора никак не коррелирует с его уровнем технической компетенции, а, в основном, связан с отсутствием у системных администраторов минимальных управленческих компетенций, столь необходимых для работы в компании, в которой ты единственный понимающий в ИТ человек.

Вдоволь насмотревшись на совершенно незаслуженные страдания штатных системных администраторов, я решил написать эту небольшую инструкцию, которая, надеюсь, поможет им избежать конфликтов с руководством и уберет из вакансий системных администраторов такое понятие как «стрессоустойчивость».

Эта статья рассказывает о времени выполнения и о расходе памяти большинства алгоритмов используемых в информатике. В прошлом, когда я готовился к прохождению собеседования я потратил много времени исследуя интернет для поиска информации о лучшем, среднем и худшем случае работы алгоритмов поиска и сортировки, чтобы заданный вопрос на собеседовании не поставил меня в тупик. За последние несколько лет я проходил интервью в нескольких стартапах из Силиконовой долины, а также в некоторых крупных компаниях таких как Yahoo, eBay, LinkedIn и Google и каждый раз, когда я готовился к интервью, я подумал: «Почему никто не создал хорошую шпаргалку по асимптотической сложности алгоритмов? ». Чтобы сохранить ваше время я создал такую шпаргалку. Наслаждайтесь!

Привет Хабр, или введение

Расскажу свою небольшую предысторию.

Как то в очередной раз надоело ковырять очередной контроллер, схему и pcb, и удрученный средней по рынку зарплатой рядового электронщика решил — хочу опять в программисты.

Не могу сказать, что я уже был в программистах, но образование получил 3 года назад по специальности «Информационные системы и технологии» в Военмехе. А судьба занесла в схемотехники-электронщики еще во времена универа. Раньше спасали частые командировки на объекты (пока молод и холост — интересно), а последний год все окончательно надоело.
Читая Хабр, выбрал себе Python.

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

Хвост виляет собакой. ("Wag the dog") — чтобы избежать большого скандала или «замять», оставить незамеченным какое-нибудь важное, но неприятное событие, часто используется простой, но хитрый и ловкий приём, который англоязычные политтехнологи называют «Wag the dog», а русскоязычные — «Хвост виляет собакой». Он заключается в том, чтобы вовремя поднять волну обсуждения вокруг вопроса второстепенной важности, на фоне которой другое, более важное событие или действие пройдёт незаметно.
Примеры таких вопросов: Отмена перехода на зимнее время, российское гражданство Депардье, поездка Путина или Саши Грей на Ладе Калине по России, полёты со стерхами и т.д.
Своё название этот приём получил в честь английского выражения tail wagging the dog, который, в свою очередь, появился из следующего народного пассажа:

— Почему собака виляет хвостом?
— Потому, что собака умнее, чем хвост. Если бы хвост был умнее, он вилял бы собакой.

Эпоха путешествий во времени еще не наступила, а человечество уже давно пытается разрешить сопутствующие им парадоксы. Мы поговорим о самом очевидном из них: что же все-таки произойдет при вмешательстве в ход истории? Существует несколько вариантов того, как поток времени реагирует на действия путешественника из будущего. Эти модели можно увидеть в фантастических фильмах, о них все больше начинают говорить ученые, но какая модель ближе к истине — единого мнения пока нет. Мы только начинаем проникать в тайны времени, и еще не обладаем возможностью экспериментировать с перемещениями в прошлое. Что же можно прояснить в данном вопросе уже сейчас? Под катом нас ждет экскурсия по основам механики времени, мы порассуждаем о парадоксах, и проведем небольшой эксперимент. Да, это будет испытание виртуальной машины времени, построенной на основе алгоритма «Жизнь»!

Вступление

В этом докладе будут рассмотрены сервисы AWS, которые использует наша платформа и с которыми я знаком не по наслышке. Я работаю над проектом, который использует почти все возможные сервисы, а так же мы нацелены в ближайшем будущем охватить ещё больше возможностей, которые предоставляет нам Amazon.

Управление AWS осуществляется как с помощью веб интерфейса (AWS console), так и с помощью Command Line Tools. В консоли собраны все сервисы AWS, но функциональность настройки несколько обрезана. В командной строке же можно более гибко настроить тот или иной сервис, так же доступны закрытые в консоли функции.

Amazon Elastic Compute Cloud (EC2)

Описание

EC2 — это облачный сервис, предоставляющий виртуальные сервера (Amazon EC2 Instance), 2 вида хранилищ данных, а так же балансировщик нагрузки (Load Balancer).

Должен признаться, что я плохой программист. Я не люблю настраивать Maven и писать конфигурации для Spring Framework. Я не знаю в деталях, как работает JVM (да и в общих чертах представляю это себе довольно смутно). Я плохо понимаю паттерны проектирования, а любая новая технология вводит меня в уныние. И тем не менее, я люблю программировать.

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

Минуточку внимания.

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

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

Для простоты, будем рассматривать 2D случай, частицы круглые, радиус частиц у всех одинаковый.

Содержание

1. Обзор алгоритмов
1.1. Полный перебор
1.2. Sweep & Prune
1.3. Регулярная сеть
2. Некоторые оптимизации
2.1. Sweep & Prune
2.2. Регулярная сеть
3. Сравнение скорости выполнения
4. Приложение (программа и исходный код)
5. Заключение

My God, it's full of stars!

Arthur C. Clarke

Кто из нас в детстве не мечтал «бороздить просторы вселенной», как капитан Пикард, прогуливаться по неизведанным планетам далёких миров, встречать рассветы двойных или тройных звёзд, погружаться в атмосферы газовых гигантов, ронять корабли в чёрные дыры? И я тоже не исключение. Конечно, частично эту мечту воплощали книги, фильмы и «Элит»-ные игры. Но вся романтика в них разрушалась банальными купи-продай и «пиу-пиу» в «жидком» космосе на скоростях самолётов времён первой мировой войны. Да и тем немногим виртуальным миркам не хватало свободы, детальности и масштабов реальной вселенной.

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

Но вот, чуть больше года назад, я совершенно случайно наткнулся на вселенную Space Engine, и она просто взорвала мне мозг и размазала его по полу своим масштабом и невероятной детализацией.

Исчерпана ли она Твиттером? Последний, говорят, хорош для быстрого распространения новостей. Ок, что может быть еще? Есть простой тезис: людям легче генерировать контент в малых форматах. А еще людям легче над сложными вещами работать коллективно. Например, подавляющее большинство современных научных статей пишутся в соавторстве. Причем научная статья — это относительно крупный формат, который когда-то был задан существованием бумажных журналов. Там просто невозможно было бы публиковать короткие тезисы в одно предложение. На самом деле идеи статей часто можно представить коротко «на пальцах», почти в твиттер-формате. Научная активность не единственный здесь уместный пример. Интересен также опыт Хабра — на размер постов влияет позиционирование ресурса как серьезного, где вы не можете злоупотреблять вниманием большой аудитории, публикуя короткие мысли немедленно после их появления в голове. Кстати, насколько я понимаю, на Хабре нельзя опубликовать пост в соавторстве, что повышает требования к единственному автору.

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

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

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

Не так давно промелькнула ссылка на достаточно свежее (осень 2011) англоязычное голосование со скромным названием "самая впечатляющая книга, которую должен прочесть каждый разработчик программного обеспечения" и описанием:

Если бы вы могли вернуться в прошлое, к самому началу своей карьеры разработчика и сказать самому себе: «прочитай именно эту книгу», в самой начале своей карьеры разработчика, какую бы книгу вы рекомендовали?

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

Однако в данном небольшом посте я возьму на себя смелость перечислить ТОП-5 тех самых книг, победивших в голосовании, переведенных на русский язык. И дать небольшие комментарии, ведь книги действительно этого достойны. Да, лично я бы поменял некоторые места, однако положимся на «мнение зала» ресурса Stack Overflow.