По просьбам трудящихся, начинаем потихоньку разворачивать тему стриминга при помощи VLC, но для начала немного вводной информации, о которой стали часто спрашивать после Двух серьезных разговоров о VLC

Власти любой страны мира фильтруют сетевой контент. Это естественно. Каждый фильтрует что-то своё. В Америке блокируют сайты казино, в Европе — сайты c нацистской символикой, в Китае и Беларуси блокируют сайты политических оппонентов. Недавно к числу «цензоров» присоединился Иран, причём некоторые технологические методы, применявшиеся там, представляют собой нечто новое, такого мы не видели даже в Китае.

Вот список технологий, которые использовали власти Ирана для цензуры в интернете во время недавних массовых народных волнений. Список приводится по документу, составленному правозащитной хакерской организацией NedaNet.

Блокировка по IP
Стандартная методика, которая используется правительствами многих стран, в том числе Беларуси и России. Неэффективна против P2P-коммуникаций, а также против сети прокси-серверов.

Классификация трафика (QoS)
Более продвинутая технология контроля, когда порче подвергается трафик, передающийся по определённым протоколам и определённым портам. Это делается для того, чтобы уменьшить общее количество трафика в местном сегменте интернета (пропускная способность внешних каналов связи оценивается в 6 Гбит/с), и уменьшить нагрузку на системы мониторинга, которые довольно ресурсоёмки, особенно в случае глубокой фильтрации по контенту.

Диаграмма показывает количество трафика на иранских бэкбонах в неделю выборов (TCP, порт 80). Как видим, в определённый момент власти просто перекрыли внешний канал.

Внимание!

Сия статья ориентирована на людей которые по тем или инным причинам являются владельцами смартфонов на базе Symbian OS, но не смотря на это используют свой девайс исключительно для вскрытия пивных пробок звонков. В статье присутствуют элементы пренебрежения авторскими правами некоторых забугорных софт контор, но учитывая мои исключительно благие намерения я позволю себе такую слабость. В конце концов, если захотите приобрести ту или инную софтину — вас никто не держит. У меня, например, около 30% софта чесно куплено (ибо я в нем действительно нуждаюсь), 60% — свободнораспространяемого, и всего лишь 10% — вареза, платить за который я отказываюсь принципиально, в силу несоответствия цены и качества у онного.

Я, при содействии и снабжении меня необходимым запасом провианта и очень стимулирующими (правда, очень) пинками со стороны моего незабвенного товарища которого зовут Олегом, пишу статью-мануал, такую себе азбуку начинающего смартовода, которая поможет ему (смартоводу) разобраться в азах смартовединея и достойно заюзать сии прекрасные девайсы как на то полагается по праву. С чего это вдруг? Хе-хе… В один прекрасный день я узрел своего старого знакомого. Он такой себе среднестатистический писи пользователь, кодит даже немного на питоне (джаст фор фан)… Так вот, попросил он меня помочь ему освоить новый гаджет (который он виду врожденной паталогической лени не захотел осваивать с Божей и (или) Гугла помощью). Ну помог я человеку ес-но, как уж тут отказать-то. И задумался. А ведь сколько народу имеют в своем распоряжении смартфон, но в виду лени/отсутсвия времени даже не желают им пользоваться. Может и среди хабранарода есть такие? Вот в сегодняшней статье я расскажу вам о том, как из безжизненного куска железа на безе Symbian OS сделать то, чем не стыдно и даже приятно пользоваться.

Думаю, что все знают, что такое модульные тесты, все знают или, по крайней мере, слышали, что такое непрерывная интеграция, и многие программируют на C++. Но я столкнулся с тем, что в интернете не так много информации о том, как же это все объединить и заставить работать вместе. Эта статья является попыткой дать новичками пошаговую инструкцию, которая позволит сделать первый шаг в создании модульных тестов для C++ проектов и организовать покоммитный прогон модульных тестов при помощи CI сервера.
Update: План:

1. Напишем HelloWorld
2. Настроим сборку HelloWorld на Jenkins
3. Напишем модульный тест для HelloWorld
4. Настроим прогон модульных тестов на Jenkins

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

Покупка заводов в Сибири была стратегически правильным решением для компании “Лифт ми Ам”. После того, как лифты стали ездить не только вверх, но и вниз, дела компании пошли… нет полетели, вверх. Лифты начали разбирать, как горячие пирожки со стола. Название уже не соответствовало действительности и было принято решение о ребрендинге. (На самом деле их замучила судебная тяжба с Моби).
Итак, под крыло ЛинкМиАп планируется взять заводы в Новосибирске, Томске и Брно. Самое время подумать о том, как это хозяйство подключить к имеющейся сети.

Итак, сегодня рассматриваем
1) Возможные варианты подключения, их плюсы и минусы
2) Site-to-Site VPN на основе GRE и IPSec
3) Большая тема: динамическая многоточечная виртуальная сеть (DMVPN) в теории и на практике.

В традиционном видео лишь ёмкая выжимка из статьи, посвящённая работе и настройке DMVPN.

Сегодня мы проведём экскурсию по цеху разработки Badoo, в котором создаётся новый функционал нашего сайта, расскажем о самом процессе — от постановки задачи и до момента выкладки в боевое окружение.

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

Не могу не поделиться с общественностью прекрасным переводом статьи The Limoncelli Test: 32 Questions for Your Sysadmin Team

Слова «облако», «облачные вычисления», «облачный» используются для чего попало. Новое модное слово, buzzword. Мы видим «облачные антивирусы», «облачные блейд-сервера». Даже именитые вендоры сетевого оборудования, не стесняются выставлять коммутаторы с ярлыком «for cloud computing». Это вызывает инстинктивную неприязнь, примерно, как «органические» продукты питания.

Любой технарь, который попытается разобраться с технологиями, лежащими в основе «облака», после нескольких часов борьбы с потоком рекламных восторгов, обнаружит, что это облака — это те же VDSы, вид сбоку. Он будет прав. Облака, в том виде, как их делают сейчас — обычные виртуальные машины.

Однако, облака, это не только маркетинг и переименованные VDS. У слова «облако» (или, точнее у фразы «облачные вычисления») есть есть своя техническая правда. Она не такая патетичная и восхитительно-инновационная, как рассказывают маркетологи, но она всё-таки есть. Придумана она была много десятилетий назад, но только сейчас инфраструктура (в первую очередь, Интернет и технологии виртуализации x86) доросла до уровня, который позволяет реализовать её в массовом порядке.

Итак, сначала о причине, которая вообще породила потребность в облаках:

Вот как выглядит предоставляемая услуга для обычного VDS (на месте этого графика может быть любой ресурс: процессор, память, диск):


Обратите внимание: это недельный график. Существующие технологии временного увеличения лимита потребления ресурса (burst, grace period) не способны решить эту проблему на таких длинных интервалах. Т.е. машина недополучает ресурсы тогда, когда они ей больше всего нужны.

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

Возникает проблема: человек вынужден заказывать ресурсов больше, чем нужно в среднем, для того, чтобы переживать без проблем пики. В остальное время ресурсы простаивают. Провайдер видит, что сервер не нагружен, начинает продавать ресурсов больше, чем есть (это называют «оверселл»). В какой-то момент, например, из-за пика нагрузки на нескольких клиентов, провайдер нарушает свои обязательства. Он обещал 70 человекам по 1Ггц — но у него есть только 40 (2.5*16 ядер). Нехорошо.

Продавать полосу честно (без оверселла) невыгодно (и цены нерыночные получаются). Оверселлить — снижать качество сервиса, нарушать условия договора.

Эта проблема не связана с VDS или виртуализацией, это общий вопрос: как честно продавать простаивающие ресурсы?

Именно ответом на эту проблему и стала идея «облачных вычислений». Слова хоть и модные, но своей основой уходящие во времена больших мейнфреймов, когда продавалось машинное время.

Облачные вычисления делают то же самое — вместо лимитов и квот, которые оплачиваются вне зависимости от реального потрбления, пользователям предоставляется возможность использовать ресурсы без ограничения, с оплатой реального потребления (и только того, что было реально использовано). Это и есть суть «облака».

  Думаю каждому (а если и не каждому, то многим) из нас (сисадминов) хоть раз, да ставилась задача об объединении нескольких удаленных офисов в единую корпоративную сеть, и каждый находил/выбирал свое решение.
  В настоящие время, существует множество различных решений, для реализации которых можно использовать как специальные аппаратные решения, так и обычные компьютеры, с любой ОС на борту.
  В данной статье, хочу рассказать о том, как объединить три удаленных офиса в одну корпоративную сеть, с разными подсетями для каждого подразделения. Все это я предлагаю поднять используя только дистрибутив OpenBSD.

Нам понадобится:

• Три ПК средней конфигурации (CPU 1,7Ghz, RAM 512Mb, HDD 20Gb, 2x Lan100Mb)
• Статические IP адреса на WAN портах
• Дистриб OpenBSD
• 40 минут вашего драгоценного времени (включая установку ОС)

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

Чаще всего встречается подход «добавим кучу RBL (DNSBL) и будем радоваться жизни». Подход не верный чуть более, чем полностью. Второй по популярности — контент-фильтры, зачастую купленные за бешеные деньги. Такой подход тоже в большинстве случаев совершенно неоправдан.

А ведь всё так просто, для спокойной жизни достаточно всего лишь пристально присматриваться к трём заголовкам входящей SMTP сессии. Порывшись на Хабре и в закоулках интернета так и не нашёл исчерпывающей статьи на тему правильной настройки SMTP сервера с точки зрения противодействия спаму. Поэтому решил расписать всё, что знаю на эту тему сам и чем успешно пользуюсь.

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

Итак, если вы хотите обезопасить своих пользователей от спама или наоборот, хотите чтобы кто-то случайно не обезопасил пользователей от ваших писем — добро пожаловать под кат.

В мире железа есть понятие сертификации, которое говорит о том, что данное оборудование сертифицировано для выполнения конкретных задач, работы в конкретных условиях и т.д. Такое же понятие есть в мире ПО, например: операционная система сертифицирована для работа на конкретном оборудовании, или программа сертифицирована выполнять определенные расчеты. Это понятие говорит о том, что клиент (покупатель) может быть уверен в том, что продукт, который он покупает, выполнит его задачи на все 100%.
Точно такое понятие сейчас применимо и к специалистам. Сертификация специалиста — проверка его на наличие необходимых знаний, навыков и опыта для выполнения задач, связанных с технологией или продуктом, для которого он сертифицируется. В случае успешного прохождения сертификации специалист получает сертификат (бумажный или электронный) и, по идее, считается экспертом в данной технологии в рамках направленности и уровню сертификационного экзамена.

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

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

Так как большинство авторов не удосуживается хотя бы залезть в документацию, то обычно в таких статьях вся информация базируется на неких слухах и пересказах слухов. Эти слухи бродят по сети и поражают википедию, хабрахабр и другие уважаемые ресурсы. В результате получаются опусы вроде "Вы наверное шутите, мистер Дал, или почему Node.js" (пунктуация автора сохранена): она, в основном, верная по сути, но изобилует неточностями, содержит ряд фактических ошибок и изображает предмет с какого-то непонятного ракурса.

Мне было сложно пройти мимо статьи, изобилующей фразами вроде «эффективные реализации polling'а на сегодняшний день имеются лишь в *nix-системах» (как будто poll() есть где-то, кроме некоторых *nix). Этот пост начинался как комментарий, разъясняющий уважаемому inikulin ошибки в его статье. В процессе написания оказалось, что проще изложить предмет с самого начала, что я собственно и делаю отдельным постом.
В моем очерке нет срыва покровов или каких-то неизвестных трюков, здесь просто описываются преимущества и недостатки разных подходов человеком, который проверял, как всё это работает на практике в разных операционных системах.
Для желающих просветиться — добро пожаловать под кат.

Многим разработчикам знакома ситуация когда кешировать страницы сайта, скажем, на 5-10 минут нельзя всего из-за одного небольшого блочка, актуальность которого нужно поддерживать если не в реальном времени, то с временем «старения» не больше 5-10 секунд. При этом посещаемость сайта продолжает расти, растет время генерации страниц и c этим надо что-то делать…

• Вариант решения 1: Подкрутить то, до чего не доходили руки последнее полгода. Все Вас поймут и передвинут сроки на другие задачи. Вы будете в роли «Супермена» один спасать сайт от непомерной нагрузки, решая проблему «бесплатно» (без доп. вливаний в оборудование). Вам может пригодиться статья «Тюнинг nginx».
   
• Вариант решения 2: Улучшить техническую базу (докупить мозгов на сервер, улучшить дисковую систему, поставить под БД отдельный сервер). В принципе проблема не решена, а скорее отложена. Теперь у Вас есть время «окопаться» и подготовиться ко второй волне наплыва нагрузки, она будет больше и накроет сильнее.
   
• Вариант решения 3: Ваш вариант, о котором я, вероятно, узнаю из комментариев.
   

Позвольте предложить и мне проверенное и относительно простое решение на базе одной из старейших технологий в Web-разработке.

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

Будут рассмотрены следующие средства: POSIX ACL, sudo, chroot, PAM, SELinux, AppArmor, PolicyKit. Виртуализация, хотя и относится в какой-то мере к средствам безопасности, рассматриваться не будет, тем более что это отдельная обширная тема.

Что я понимаю под правильной обработкой:

• Универсальное решение, которое можно вставить в любой существующий код;
• Легко расширяемое решение;
• В PHP аж три «механизма ошибок»: собственно ошибки (error), исключения (exception) и утверждения (assertion). Свести три механизма к одному — exception. В комментариях к предыдущей статье на эту тему выражалось мнение, что exception это плохой и/или сложный метод обработки ошибок. Я так не считаю и готов это обсудить в комментариях;
• Опциональное логирование;
• Общий обработчик exception, который будет поддерживать разные форматы вывода и debug/production режимы;
• В debug режиме должен выводится trace. Требования к trace: компактный, понятный и по возможности ссылки на открытие файлов в IDE.

Наткнулся на Stackoverflow.com на интересный топик с вопросом о новом в программистском жаргоне. Предлагаю здесь подборку наиболее интересных выражений.

Египетские операторные скобки

if (a == b) {<br>  printf("hello");<br>}<br><br>

Чуть раньше я писал про тонкие клиенты. Мол, зачем они нужны, кому они нужны и какой с них прок.

А теперь немного грустной правды о том, что есть тонкий клиент на самом деле.

Сколько бы не завывали маркетологи про особые свойства ТК, это просто компьютер. Зачастую с обычным биосом, в котором вы можете взять и загрузить свою ОС. В особо запущенных случаях вам придётся к этой ОС собрать особое ядро или играться с параметрами ядра, но обычно — это просто компьютер. В формате mini-itx или меньше. Без вентиляторов. Такие компьютеры до выхода Атома были экзотикой, с момента появления Атома — практически «компьютер как компьютер», только меньше.

Я не видел ни одного мейнстрим производителя, который бы делал тонкие клиенты примерно так, как делают принт-сервера (очень специальная плата, минимум лишнего...). Основная причина состоит в том, что тонкий клиент, хоть и является dumb terminal с логической точки зрения, на самом деле должен обладать очень и очень приличной производительностью.

Прежде чем мы подробно рассмотрим известные технологии сокрытия своего настоящего IP-адреса, нам следует узнать свой IP-адрес и выяснить некоторые вещи, обличающие наш компьютер в сети, например адрес DNS-сервера. Для этого достаточно зайти на любой сервис проверки анонимности, например www.whoer.net, главное чтобы он обладал интерактивной проверкой вашего компьютера с помощью Java, ActiveX, Flash и Javascipt. Изменить свой IP-адрес, например с помощью Socks или VPN, недостаточно, т.к. существует множество технологий, позволяющих его выявить, которые нужно либо отключить на своем компьютере, либо обмануть. Также не лишним будет изменить передаваемые НТТР-заголовки, это позволит «сбить» определение установленного ПО и географическое место расположения компьютера. Более детально проверить свой компьютер можно в расширенной версии www.whoer.net/ext.

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

При этом я не обращал внимания на то, можно ли атаковать сервер целиком, проверял только сами сайты на наличие базовых уязвимостей – XSS, SQL-инъекции, инъекции команд. Просмотрел не все, штук сорок, то есть около половины. Из них:

• 5 сайтов подвержены пассивному XSS,
• 1 сайт подвержен слепой SQL-инъекции,
• 1 сайт подвержен SQL-инъекции с возможностью внедрения UNION,
• 3 сайта раскрывают некоторые детали внутреннего устройства, из них 2 предоставляют доступ к phpinfo, а 1 выдаёт сообщения об ошибках с отладочной информацией,
• 1 сайт подвержен внедрению команд, это наиболее серьёзная проблема из всех, что мне встретились.

В общем, я бы не сказал, что всё плохо, несмотря на наличие отдельных проблем.

Но вот что я хотел бы узнать – имеется ли какая-то единая служба, которая отвечает за информационную защищенность всех сайтов министерств и ведомств (хотя бы за защищенность, функциональность оставим в стороне)? Или каждый отвечает сам за себя?

Часто, при работе с memcached, возникает ситуация, когда необходимо удалить данные в самых различных местах. Например, при добавлении нового комментария, необходимо обновить не только кеш самих комментариев этой страницы, но и ленты комментариев на главной странице, списока комментариев пользователя, счетчика комментариев пользователя, общего счетчика комментариев сайта, счетчика комментариев статьи и т.д. Можно запомнить все ключи этих данных и множество раз вызвать delete() с этими ключами.

<?php
$cache->delete('comments_art123');
$cache->delete('comments_tape');
$cache->delete('comments_user123');
$cache->delete('comments_counters_art123');
$cache->delete('comments_counters_user123');
......
?>

* This source code was highlighted with Source Code Highlighter.

Как известно, memсached хранит данные плоско, то есть одному ключу соответствует всегда одно значение. Вложенных ключей не существует. Так же нет возможности удалить группу ключей, скажем по маске. Хорошо бы было, если бы можно было сделать, например, так: $cache->delete('comments*'); Но так нельзя.

Но если нельзя, но очень хочется, то можно ;)