Привет, Хабр! Предлагаю вашему вниманию перевод статьи Брендана Грегга, посвящённой изучению eBPF

На конференции Linux Plumbers было как минимум 24 выступления по eBPF. Он быстро стал не просто бесценной технологией, но и востребованным навыком. Возможно, вам хотелось бы поставить какую-то цель на новый год — изучите eBPF!

Термин eBPF должен означать что-то существенное, как например Virtual Kernel Instruction Set (VKIS), но по своему происхождению это расширенный Berkeley Packet Filter. Он применим во многих областях, таких как производительность сети, фаерволлы, безопасность, трассировка и драйвера устройств. По некоторым из них есть много свободно доступной информации в интернете — например, по трассировке, а по другим ещё нет. Термин трассировка относится к инструментам анализа производительности и наблюдения, которые могут генерировать информацию по каждому событию. Возможно, вы уже использовали трассировщик — tcpdump и strace являются специализированными трассировщиками.

Этим постом я собираюсь описать процесс изучения использования eBPF в целях трассировки, сгруппированный в разделы для начинающих, опытных и продвинутых пользователей. В итоге:

• Начинающим: запуск инструментов bcc
• Опытным: разработка инструментов bpftrace
• Продвинутым: разработка инструментов bcc, вклад в bcc и bpftrace

Все это собиралось из под Ubuntu 16.04.

Решение собрать прошивку родилось из за отсутствия в свободном доступе образа для этой платы (Olimex A13-Olinuxino). А производитель предлагал преобрести SD карту с образом и стоило что то около 10 евро на тот момент, что очень не устроило, к тому же она была рассчитана на наличие монитора.

Конфигурирование загрузчика будем формировать для загрузки с SD карты. Поскольку NAND памяти на плате нету а все остальные варианты загрузки слегка кривоваты (у кого получиться собрать uboot для загрузки с USB носителя, пусть сделает два шага вперед и поделится). Алгоритм загрузки процессора allwinner a13 можно найти на сайте производителя. Или вот вырезка из даташита.

Однажды в старой коробке была найдена была найдена борда Olinuxino от Olimex на процессоре A13 от Allwinner, с 512Мб на борту. Порывшись, там же был найден старый самодельный преобразователь интерфейсов USB – uart/spi на FT-шке (который когда то делался для прошивки AVRок) и блок питания от какого то радиотелефона, все это хозяйство на фотографии ниже.

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

Лонгрид варнинг: вас предупредили, много букв.

Уже давно ведётся разработка формата дистрибуции приложений, которые были "свободны" от общесистемных зависимостей. Ubuntu очень, очень активно продвигает свой snap, gnome — flatpack. Оба обещают рай и свободу от rpm/deb. Давайте же подумаем про проблему, которую они хотят решить, и цену, которую они просят за решение этой проблемы.

Когда мы говорим о дистрибутиве операционной системы, то речь впервую очередь идет не об ядре операционной системы, а о тех приложениях, которые входят в состав дистрибутива. А когда мы говорим об импортозамещение операционных систем, то речь идет о той или иной версии Linux. Ничего другого на российском рынке для импортозамещения не предлагается. Что касается ядра linux, то за его развитие отвечает Ли́нус Бенедикт То́рвальдс. И честно говоря мне ничего неизвестно, про российское ядро linux. А вот окружение любого дистрибутива linux разрабатывается различными организациями, все их и не перечислить: KDE, Mozilla, Google, IBM и т.д. и т.д. И следовало бы ожидать, что с появлением отечественных ОС аля linux этот список будет расширен отечественными разработками или модификациями. Но этого нет. Нет, это не обязательно отечественный браузер или почтовый клиент в этих дистрибутивах. Но что-то доработанное с учетом российских реалий в цифровой экономике хотелось бы видеть. Остановимся на этом.

Одним тёплым холодным зимним вечером, хотелось согреться в офисе и проверить теорию одного коллеги, что C++ vector мог бы быстрее справиться с задачей, чем CPython list.

В компании мы разрабатываем продукты на базе Django и случилось так, что нужно было обработать один большой массив словарей. Коллега предположил, что реализация на C++ была бы гораздо быстрее, а меня не покидало чувство, что Гвидо и сообщество наверное немного круче нас в Си и возможно уже решили и обошли все подводные камни, реализовав всё гораздо быстрее.

Для проверки теории, я решил написать небольшой тестовый файл, в котором решил прогнать в цикле вставку 1М словарей одинакового содержания в массив и в vector 100 раз подряд.

Результаты хоть и были ожидаемые, но так же и внезапные.

Я занимаюсь разработкой, внедрением и эксплуатацией систем автоматического управления технологическими процессами (АСУ ТП). Поначалу работал со SCADA-системами. Потом довольно быстро переключился на работу с протоколами обмена промышленных устройств. Как самостоятельное написание драйверов, так и настройка систем сбора данных. В настоящий момент моя работа проходит атмосфере Modbus-ов, МЭКов-101/104-х, ОРС и прочих протоколов.


Рис. 1. Многообразие протоколов обмена, используемых в АСУ ТП

Несколько дней назад вышла в свет с опережением графика очередная версия классической Unix/Linux системы инициализации sysvinit 2.92. Предыдущий выпуск 2.91 вышел чуть больше месяца назад.

Что же примечательного в выходе минорной версии старинной системы инициализации (СИ), от которой отказались почти все современные дистрибутивы Linux, и какая от этого радость сообществу сторонников открытого кода и пользователям Debian Linux?

После решения Линуса Торвальдса о временном уходе из проекта в сентябре 2018 года совет директоров Linux Foundation принял новый кодекс поведения для разработчиков ядра Linux — Code of Conduct (CoC), чтобы «решить проблемы, связанные с дискриминацией, и улучшить эмоциональную обстановку среди разработчиков».

У новых правил было много сторонников, но объявились и недоброжелатели, которых вообще не привлекла идея подобной «доброжелательности». Разгорелись жаркие дебаты. 30 ноября эти споры вышли на новый уровень, потому что что один из авторитетных разработчиков Яркко Саккинен из компании Intel начал применять кодекс поведения на практике — и исправил несколько комментариев в коде ядра, заменив слово fuck (многозначное слово) на hug («обнимашки»).

«Мы ленивы и нелюбопытны»

На сей раз поводом к посту послужила статья в неплохом журнале, посвященном ОС Linux (далее по тексту Л), в которой привлеченный «эксперт» хвалил драйвер подключения ЖКИ к плате Raspbery. Поскольку подобные вещи (подключение, не ОС) входят в сферу моих профессиональных интересов, статью просмотрел с вниманием, потом нашел собственно текст «драйвера» и был слегка удивлен, что ЭТО можно хвалить. Ну, в общем то, уровень эксперта можно определить хотя бы потому, что он упорно именовал программу драйвером, несмотря на то, что она им никоим образом не является. Казалось бы, и фиг с ним, мало ли кто что пишет для себя, но выкладывать подобное в открытый доступ — «я и не знал, что так можно».

Особенно порадовало то обстоятельство, что адрес устройства на шине I2C напрямую задавался в тексте программы и для его изменения требовалась ее перекомпиляция (хорошо, что не всего ядра). Я, кстати, заметил, что на форумах, посвященных Л, наиболее популярный ответ на любой вопрос о проблемах в ПО, «пересобери последнюю версию ядра». Мне данный подход представляется несколько странным, наверное, я чего-то не знаю. Но, тем не менее, возник вопрос, а как в Л действительно реализуется (внутри, не снаружи — там все просто и понятно) параметризация драйвера, ответу на который и посвящен данный пост.

Всем привет! Я работаю в Veeam над проектом Veeam Agent for Linux. С помощью этого продукта можно бэкапить машину с ОС Linux. «Agent» в названии означает, что программа позволяет бэкапить физические машины. Виртуалки тоже бэкапит, но располагается при этом на гостевой ОС.

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

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

Всех заинтересовавшихся прошу под кат!

Некоммерческий консорциум The Linux Foundation объявил о формировании сразу двух новых фондов: GraphQL Foundation и Ceph Foundation. Далее — подробнее о каждом из них.

Во время разговоров о cgroups пользователи Red Hat довольно часто задают один и тот же вопрос: «У меня есть одно приложение, очень чувствительное в смысле задержек. Можно ли с помощью cgroups изолировать это приложение от остальных, привязав его к определенным процессорным ядрам?»



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

Нет, я не собираюсь рассказывать, как написать своего шифровальщика-вымогателя, майнера или эксплуатировать супер-новую уязвимость, как вы могли подумать. И тем более я не горю желанием поднимать холивар «Linux безопаснее Windows?(да)». Моей целью было написание простого вируса для linux, некого, так сказать, «Just for Fun», единственной функцией которого является распространение своей копии. О том, что у меня получилось, я расскажу в этой статье. В конце я приведу ссылку на GitHub с исходниками.

Введение

Как правило, работая с параметрами рендеринга, OpenGL действует как конечный автомат. Состояние рендеринга — это совокупность атрибутов состояния, таких как источники света, материалы, текстуры и режимы отображения, включаемые и выключаемые функциями glEnable() и glDisable(). При установке определенного состояния оно действует до тех пор, пока какая-либо другая функция не изменит его. Конвейер OpenGL поддерживает стек состояний для сохранения и восстановления состояний в любой момент времени. Машина состояний предоставляет разработчику полный контроль над текущими и сохраненными в стеке состояниями рендеринга.

Однако такой подход неудобен при работе с OSG. По этой причине машина состояний OpenGL инкапсулируется классом osg::StateSet, который берет на себя операции по работе со стеком состояний и их установке в процессе обхода графа сцены.

Цель, которой я задался, была весьма проста: узнать введённый в sshd пароль, используя ptrace. Конечно, это несколько искусственная задача, так как есть множество других, более эффективных, способов достичь желаемого (и с гораздо меньшей вероятностью получить SEGV), однако, мне показалось клёвым сделать именно так.

Введение

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

Развитие программных инструментов, реализующих трехмерную графику пришло, вне зависимости от того, какой из них вы выбираете, примерно к одинаковой концепции как математического, так и алгоритмического описания вышеупомянутых трансформаций. Идеологически и «чистые» графические API типа OpenGL, и крутые игровые движки типа Unity и Unreal, используют схожие механизмы описания преобразования трехмерной сцены. Не является исключением и OpenSceneGraph.

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

Введение

OpenGL, являющийся бэкэндом для OpenSceneGraph, использует геометрические примитивы (такие как точки, линии, треугольники и полигональные грани) для построения всех объектов трехмерного мира.

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

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

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

Открываем Red Hat Enterprise Linux 8 Beta – одновременно со всем миром!



И прежде, чем мы перейдем к представлению важных изменений и новых возможностей, скажем главное – разработчики могут начать тестировать наше новое чудо при помощи Red Hat Developer Program.

Введение

В прошлой статье мы рассмотрели сборку OpenSceneGraph из исходников и написали элементарный пример, в котором в пустом фиолетовом мире висит серый самолет. Согласен, не слишком впечатляет. Однако, как я говорил раньше, в этом маленьком примере присутствуют главные концепции, на которых основан данный графический движок. Рассмотрим их подробнее. В ниже приведенном материале использованы иллюстрации из блога Александра Бобкова об OSG (жаль, что автор забросил писать об OSG...). Статья базируется так же на материале и примерах из книги OpenSceneGraph 3.0. Beginner’s Guide

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