Продолжаем цикл статей о механизмах контейнеризации. В прошлый раз мы говорили об изоляции процессов с помощью механизма «пространств имён» (namespaces). Но для контейнеризации одной лишь изоляции ресурсов недостаточно. Если мы запускаем какое-либо приложение в изолированном окружении, мы должны быть уверены в том, что этому приложению выделено достаточно ресурсов и что оно не будет потреблять лишние ресурсы, нарушая тем самым работу остальной системы. Для решения этой задачи в ядре Linux имеется специальный механизм — cgroups (сокращение от control groups, контрольные группы). О нём мы расскажем в сегодняшней статье.

Тему обновления патчей ядра без перезагрузки мы уже рассматривали в статье, опубликованной в 2014 году. В ней речь шла о KernelCare — инструменте, разработанном нашими партнёрами из компании Cloud Linux. На момент написания статьи KernelCare был чуть ли не единственным пригодным для полноценного использования инструментом для наложения патчей.

Как бы вы руководили разработкой крупнейшего проекта с открытыми исходниками, в котором порядка 15 тыс. разработчиков и 222 компании вносят более 12 тыс. изменений между релизами или 7 / 8 правок каждый час? Чем пользуются создатель кернела Линус Торвальдс, мейнтейнер стабильной ветки Грег Кроа-Хартман (GKH) и другие товарищи, чтобы успешно координировать работу проекта и обеспечивать своевременный выход каждой новой версии?

Этим чудо-инструментом является текстовый клиент электронной почты: Mutt у GKH и Alpine у Линуса Торвальдса. Третий по рангу разработчик ядра Эндрю Мортон, также вовсю использует электронку для управления mm веткой.

With the wide variety of more “modern” development tools such as github, gerrit, and other methods of software development, why is the Linux kernel team still stuck in the 1990’s with ancient requirements of plain text email in order to get patches accepted? This talk will discuss just how the kernel development process works, why we rely on these “ancient” tools, and how they still work so much better than anything else.^[1]

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

— Феденька, ты очень интеллигентный мальчик, ты мне очень нравишься, но Я БУДУ СТАВИТЬ ДВА В ГОДУ!!! — визжала моя школьная учительница по французскому и делала примерно такое лицо.

Моя школьная учительница по английскому языку делала другое лицо:

Прочитал весьма занимательную статью про важность алгоритмов, вывод из которой показался мне весьма спорным

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



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

Это перевод достаточно важной статьи про GitLab Flow, альтернативе Git flow и GitHub flow. Статья была написана в 2014, так что скриншоты успели устареть. Тем не менее сама статья более чем актуальна:

---

Ветвление и слияние веток в git устроено гораздо проще, чем в более ранних системах контроля версий, таких как SVN. Поэтому есть много способов организации командной работы над кодом, и большинство из них достаточно хороши. По крайней мере, они дают много преимуществ по сравнению с тем, что было до git. Но сам по себе git — не серебряная пуля, и во многих командах организация рабочего процесса с git имеет ряд проблем:

• Не описан точным образом весь рабочий процесс,
• Вносится ненужная сложность,
• Нет связи с трекером задач (issue tracker).

Мы хотим представить вам GitLab flow — чётко определённый набор практик, решающий эти проблемы. Он объединяет в одну систему:

• Практику разработки, управляемой функциональностью (feature driven development),
• Использование feature-веток (feature branches),
• Трекер задач.

Меньше всего говорят о том, что будет после того как ты окончишь лагерь по программированию — когда ты пытаешься занять позицию разработчика с шестизначным окладом.


< 3% заявлений становились предложениями

Я окончил Hack Reactor в июле 2016, и мне потребовалось почти 3 месяца, прежде чем я принял предложение от Radius Intelligence. Я подавал заявления в 291 компанию, прошел 32 собеседования по телефону и 16 обычных, а также выполнил 13 задач по программированию, 11 из них — в офисах. И получил в итоге 8 предложений. Мне предлагали 60-125 тысяч долларов в компаниях США. В общем 2.8% заявок обернулись для меня выгодными предложениями.

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

Иллюстрированная проекция модели сетевого взаимодействия OSI на универсальную последовательную шину.

Три «замечательных» уровня стека USB

Меня не устроил вид стека USB, который можно встретить чаще всего на просторах сети:


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

Если у читателя бывали сходные ощущения, предлагаю альтернативное, явившееся мне неожиданно ясно в перегретом мозгу видение стека USB, по мотивам любимой 7-уровневой модели OSI. Я ограничился пятью уровнями:



Я не хочу сказать, что весь софт и библиотеки уже сделаны или должны проектироваться, исходя из этой модели. Из инженерных соображений код c уровнями будет сильно перемешан. Но я хочу помочь тем, кто начинает своё знакомство с шиной USB, кто хочет понять протоколы обмена устройств и терминологию предметной области, подобраться поближе к готовым примерам, библиотекам и лучше ориентироваться в них. Эта модель не для загрузки в МК, но в ваши блестящие умы, дорогие друзья. А ваши золотые руки потом всё сами сделают, я не сомневаюсь:)

Всем привет! Сегодня речь пойдет о не самом известном алгоритме сортировки — трехпутевая поразрядная быстрая сортировка. Этот алгоритм является гибридом широко известных быстрой сортировки и поразрядной сортировки.

Подробности — под катом.

Команды разработчиков ПО часто принимают решения о программной архитектуре или технологическом стеке, основываясь на ошибочных мнениях из социальных сетей и на всем том, что является скорее модным, чем хорошо изученным, без серьезной оценки возможного влияния на их проекты. Я называю эту тенденцию «Hype Driven Development (HDD)», считаю ее вредной и выступаю за более профессиональный подход. Давайте посмотрим, как обстоят дела, и что мы можем противопоставить.

Новые технологии — новые надежды

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

Дано:

# pciconf -lv | grep -i device | grep -i network
    device     = I350 Gigabit Network Connection
# dmesg | grep CPU:
    CPU: Intel(R) Core(TM)2 Duo CPU     E7300  @ 2.66GHz (2666.69-MHz K8-class CPU)
# uname -orp
    FreeBSD 9.1-RELEASE amd64

Задача:
Необходимо на данном оборудовании и ОС создать нагрузочную вилку в виде tcp(syn)-генератора трафика производительностью не менее 500kpps.

Решение:

Многие пользователи Bash знают о существании со-процессов, появившихся в 4-й версии Bash'a. Несколько меньшее количество знает о том, что сопроцессы в Bash не какая-то новая фича, а древний функционал KornShell'a появившийся ещё в реализации ksh88 в 1988 году. Ещё меньшее количество пользователей shell'ов умеющих сопроцессить знают синтаксис и помнят как это делать. Вероятно, я отношусь к четвёртой группе — знающих о сопроцессах, периодически умеющих ими пользоваться но так и не понимающих «зачем?». Я говорю «периодически», так как иногда я освежаю в голове их синтаксис, но к тому моменту, когда мне кажется что «вот тот случай когда можно применить co-proc» я уже напрочь забываю о том как это делать.

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

В заголовке статьи у нас 3 вопроса. Пойдём по порядку.

Что?

Что же такое co-process? Со-процессинг — это одновременное выполнение двух процедур, одна из которых считывает вывод другой. Для его реализации необходимо предварительно запустить фоновый процесс выполняющий функционал канала. При запуске фонового процесса его stdin и stdout присваиваются каналам связанными с пользовательскими процессами. Соответственно, один канал для записи, второй для чтения. Пояснять это проще на примерах, поэтому сразу перейдём ко второму вопросу.

Эта заметка навеяна мелькавшими последнее время на хабре постами двух тематик — «интересные команды unix» и «как я подбирал программиста». И описываемые там команды, конечно, местами интересные, но редко практически полезные, а выясняется, что реально полезным инструментарием мы пользоваться и не умеем.
Небольшое лирическое отступление:
Года три назад меня попросили провести собеседование с претендентами на должность unix-сисадмина. На двух крупнейших на тот момент фриланс-биржах на вакансию откликнулись восемь претендентов, двое из которых входили в ТОП-5 рейтинга этих бирж. Я никогда не требую от админов знания наизусть конфигов и считаю, что нужный софт всегда освоится, если есть желание читать, логика в действиях и умение правильно пользоваться инструментарием системы. Посему для начала претендентам были даны две задачки, примерно такого плана:
— поместить задание в крон, которое будет выполняться в каждый чётный час и в 3 часа;
— распечатать из файла /var/run/dmesg.boot информацию о процессоре.

К моему удивлению никто из претендентов с обоими вопросами не справился. Двое, в принципе, не знали о существовании grep.



Поэтому… Лето… Пятница… Перед шашлыками немного поговорим о grep.

Добрый день! Продожим работу с платой от NAS WesternDigital MyBook Live и подключенным к ней ЖК индикатором. Итак, в предыдущей части мы нашли на плате место для подключения к шине I2C, подключили расширитель портов с индикатором, убедились что все работает. Сегодня выведем на индикатор состояние системы.

Однажды, появилась необходимость использования в нашем устройстве мультиплексного канала обмена информацией (МКИО), он же ГОСТ Р 52070-2003, он же MIL-STD-1553В. Первоначальный результат поисков несколько удивил: типовые решения выдаваемые поисковой системой, как правило, основывались на использовании ПЛИС. Поскольку решать проблему нужно было быстро, появилась мысль сделать конвертер протокола из MIL-STD-1553 в MODBUS RTU. При этом постараться использовать достаточно недорогие технические решения и микроконтроллер из семейства STM32.



На фото из Википедии: F16, на котором впервые был использована шина MIL-STD-1553В. Наши устройства не летают :), поэтому каких либо ограничений по применению элементной базы нет. Просто у Заказчика приборная сеть построена на основе этой шины. Первая часть статьи описывает прием и передачу по шине МКИО, вторая часть будет про конвертер в MODBUS.

В четверг, 12 мая, в 20:00 в петербургском офисе Одноклассников состоится встреча CodeFreeze с Константином Ушаковым, директором OKTET Labs. Тема встречи — Solarflare OpenOnload, сетевой стек, для Linux, уменьшающий задержки, нагрузку на процессор и увеличивающий скорость передачи пакетов.

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

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

Это схема отлично работает до тех пор, пока не появляются объекты, ссылающиеся друг на друга. Самый простой пример — узлы какого-то дерева, хранящие ссылки на свои дочерние и родительский узлы. Узлы продолжат ссылаться друг на друга, даже когда не останется других внешних ссылок ни на один из них. Самое неприятное, что такие узлы могут ссылаться на какие-то другие данные и не давать их освободить. Чтобы устранить такие циклические ссылки, в Питоне существует второй механизм освобождения памяти — сборщик мусора. Он запускается время от времени, ставя выполнение остального кода на паузу, и анализирует все неосвобожденные объекты.

Формально, циклические ссылки нельзя назвать утечками: сборка мусора рано или поздно уничтожит такие объекты. Беда только в том, что Питон не может сам определить, когда еще рано, а когда уже поздно. В моем случае система просто прибивала процесс с Питоном, если сборка мусора не начиналась вовремя.

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

Intel SR-IOV

Не совсем технология от Intel, но пощупать удалось только их реализацию. Вкратце, физический адаптер (PF) делится на несколько виртуальных (VF). Трафик внутри одного vlan по умолчанию не выходит за границы PF, и обеспечивает наиболее минимальные задержки по сравнению с виртуальными адаптерами на софтовых бриджах.


С помощью использования Intel FlowDirector в принципе можно изменить поведение и указать правила по которым трафик должен ходить между VF или наружу из PF. Также можно сделать ручное распределение трафика по RX очередям или хардварный дроп трафика сразу при входе на карту. Поддержка конфигурации flow есть в драйверах, но отдельного api конкретно для Flow Director я не нашел. Кто хочет поиграться — можно покопаться в исходниках ethtool, либо использовать Intel DPDK, в нем API реализован, но карта отцепляется от kernel драйвера со всеми вытекающими.

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

Плюсы: работа как в VMWare, так и KVM. Везде быстрее софтовых бриджей как по задержкам, так и пропусной способности. И CPU не жрет.

Минусы: виртуальный свитч в данном кейсе — нужно превращать в реальный на отдельном железе, куда втыкаются PF от сервера с виртуальными машинами.
И 64 VF на один PF сейчас достаточно мало.

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

Меняется ли от этого суть работы? Мы в 1cloud попробовали разобраться в том, какую работу подразумевают такие специализации как «Programmer», «Software Engineer» и «Computer Scientist».

В пятницу выдался свободный вечер, такой когда срочных дел нет, а несрочные делать лень и хочется чего-то для души. Для души я решил посмотреть какой-нибудь доклад CppCon 2015 которая прошла чуть больше месяца назад. Как правило на видео доклады вживую у меня никогда времени не хватает, но тут все так уж сложилось — прошел месяц, C++-17 уже на носу и конференция должна была быть интересной, но никто еще ничего о ней не писал, а тут еще и вечер свободный.В общем я быстренько ткнул мышкой в первый привлекший внимание заголовок: Andrei Alexandrescu “Declarative Control Flow" и приятно провел вечер. А потом решил поделиться с хабрасообществом вольным пересказом.