Введение

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

В связи со всем вышеперечисленным, при разработке на C++, возникает потребность в реализации обработки событий тем или иным способом, решаемая за счет использования сторонних библиотек и фреймворков. Всем известный фреймворк Qt предоставляет механизм сигналов и слотов, позволяющий организовать взаимодействие классов, наследуемых от QObject. Реализация событий присутствует и в библиотеке boost. И конечно же в движке OpenSceneGraph не обошлось без собственного «велосипеда», о применении которого и пойдет речь в статье.

Введение

Мы уже говорили о том, что класс osg::Camera управляет связанным с ним графическим контекстом OpenGL. Графический контекст инкапсулирует информацию о том, как и куда происходит отрисовка объектов и какие атрибуты состояния к ним применяются. Под контекстом понимают графическое окно, вернее его клиентскую область, или пиксельный буфер OpenGL, который хранит данные пикселей без передачи их в кадровый буфер.

OSG использует класс osg::GraphicsContext для представления абстрактного графического контекста, и класс osg::GraphicsWindow, для представления абстрактного графического окна. Последний имеет метод getEventQueue() для управления событиями от элементов GUI. Вообще говоря графический контекст есть платформоспецифичное понятие, поэтому большую часть работы по созданию окна и связыванию его контекста с контекстом OpenGL, OSG берет на себя. При вызове метода createGraphicsContext() класса osg::GraphicsContext() требуемый код (а его не мало, поверьте!) будет сгенерирован препроцессором автоматически, в зависимости от платформы. От нас лишь требуется передать этому методу аргумент типа osg::GraphicsContex::Traits, содержащий описание того, какое окно мы хотим получить.

Согласитесь, приятно и полезно, когда в проекте исходный код выглядит красиво и единообразно. Это облегчает его понимание и поддержку. Покажем и расскажем, как реализовать форматирование исходного кода при помощи clang-format, git и sh.

*Ссылка на библиотеку и демо видео в конце статьи. Для понимания того, что происходит, и кто все эти люди, рекомендую прочитать предыдущую статью.

В прошлой статье мы ознакомились с подходом, позволяющим осуществлять "горячую" перезагрузку c++ кода. "Код" в данном случае — это функции, данные и их согласованная работа друг с другом. С функциями особых проблем нет, перенаправляем поток выполнения из старой функции в новую, и все работает. Проблема возникает с данными (статическими и глобальными переменными), а именно со стратегией их синхронизации в старом и новом коде. В первой реализации эта стратегия была очень топорной: просто копируем значения всех статических переменных из старого кода в новый, чтобы новый код, ссылаясь на новые переменные, работал со значениями из старого кода. Конечно это некорректно, и сегодня мы попытаемся исправить этот изъян, попутно решив ряд небольших, но интересных задач.

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

Введение

Говоря о приемах программирования, специфичных для OSG в прошлый раз мы говорили о механизме обратных вызовов (Callback) и его реализации в движке. Настало время посмотреть на то, какие возможности дает нам применение этого механизма для управления содержимым трехмерной сцены.

Если говорить об анимации объектов, то OSG предоставляет разработчику две возможности её реализации:

1. Процедурная анимация, реализуемая программным способом через трансформацию объектов и их атрибутов
2. Экспорт анимации из 3D-редактора и управление ею из кода приложения

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

Введение

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

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

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

Введение

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

OSG поддерживает несколько текстурных атрибутов и режимов текстурирования. Но, перед тем как говорить о текстурах, поговорим о том, как в OSG оперируют с растровыми изображениями. Для работы с растровыми изображениями предусмотрен специальный класс — osg::Image, хранящий внутри себя данные изображения, предназначенных, в конечном итоге, для текстурирования объекта.

В начале месяца специалисты по ИБ из Qualys обнаружили сразу три уязвимости в systemd — подсистеме инициализации Linux — позволяющие злоумышленнику получить права суперпользователя. Рассказываем, в чем их суть и какие дистрибутивы им подвержены.

Привет, Хаброжители! Мы уже писали о книге Майкла Керриска «Linux API. Исчерпывающее руководство». Сейчас решили опубликовать отрывок из книги «Управление буферизацией файлового ввода-вывода, осуществляемой в ядре»

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

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

Чуть меньше года назад увидела свет публикация, где мы рассказывали об учебно-лабораторном комплексе (УЛК) электропоезда ЭС1 «Ласточка», разработанном нашем университете. Тогда я обещал, что это будет не последняя публикация на данную тему, в частности грозился рассказать о проблемах создания трехмерной визуализации для подобного рода симуляторов и очертить основные подходы к их решению.

Прошедший год порадовал нас очередным релизом — УЛК высокоскоростного электропоезда ЭВС2 «Сапсан», который состоялся ещё в августе прошлого года. Сам по себе учебно-лабораторный комплекс данного электропоезда заслуживает отдельного рассказа, но в контексте этой публикации речь пойдет о наболевшем — проблеме создания адекватной подсистемы трехмерной визуализации, к решению которой наша команда подступалась с разных сторон около двух лет. Релиз симулятора «Сапсана» знаменателен (среди прочего) и тем, что определил вектор развития наших разработок в этой области.

Речь в этой статье пойдёт о небольшой security-фиче, добавленной в GNU ld к релизу 2.30 в декабре 2018 года. На русском языке это улучшение упоминалось на opennet с такой аннотацией:

режим "-z separate-code", повышающий защищённость исполняемых файлов ценой небольшого увеличения размера и потребления памяти

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

В предыдущей статье я описывал мой эксперимент с приложением «HelloWorld» из Kurento-туториала. В этой статье я продолжу обзор Web приложений на Java Spring и Kurento Media Server-a.

Следующее приложение из туториала называется WebRTC Magic Mirror. Из названия следует, что зеркало отражает немного приукрашенную действительность. В этом приложении в дополнение к предыдущему применяется фильтр компьютерного зрения «FaceOverlay filter». При обнаружении в камере лица человека Kurento Media Server «надевает» на голову кепку Супер Марио. Если в обьективе несколько лиц, каждому надевается кепка.

Рост популярности контейнеров и их использование в совокупности с контрольными группами выявили серьезную проблему масштабируемости, которая приводит к значительному падению производительности на больших машинах. Проблема в том, что время обхода SLAB-кэшей зависит квадратично от количества контейнеров, а активное потребление больших объемов памяти за короткий период может стать причиной ухода системы в busy loop, потребляющий 100% процессорного времени. Сегодня мне хотелось бы рассказать, как мы решили эту проблему, изменив алгоритм учета использования контрольной группой memcg объектов SLAB-кэшей и оптимизировав функцию shrink_slab().

Сборка kernel

Объясню, почему не подходят существующие образы. Основная их проблема в том что они собраны на старом ядре 3.4, а это сразу накладывает ограничение на компилятор максимум версии 4 и ubuntu 12.04 точно, 14.04 не помню. Вот и выходит что если хочешь использовать последний софт и библиотеки то придется пересобирать последнее ядро. Конечно можно в исходниках снять ограничение на компилирование не ниже 5 версии gcc и исправить код чтоб собрался и под 4 версией, но это тот еще геморой. Не говоря уже о том что в нашем случае графическая часть линуха лишняя.

Для начала с kernel.org выкачиваем ядро 4.14.57 на тот момент это была последняя стабильная версия.

В папке с исходником создаем скрипт запускающий конфигурирование:

#!/bin/sh
make  	O=../olimex-kernel-4.14.57 		# папка где будет собрано ядро
	-j2 					# собирать в два потока
	ARCH=arm 				# тип процессора под который собирать
	CROSS_COMPILE=arm-linux-gnueabihf-  	# кросс компилятор
	xconfig				# запуск конфига

Получим что то вроде этого:

Существует уже немало медиа сервисов, но люди продолжают их создавать. Решил и я заняться изобретением своего велосипеда.

Натолкнувшись на проект Kurento, понял что это то, что мне надо. Данная статья является частично переводом Kurento Documentatin, частично это заметки о моих экспериментах с KurentoTutorial. Надеюсь что разработчикам, приступающим к изучению данного вопроса, этот материал поможет быстрее освоить тему создания медиа сервисов.

Аннотация статьи.

• Использование GtkApplication. Каркас приложения. Makefile.
• Отрисовка библиотекой librsvg.
• Экспорт изображения в GtkImage и его масшабирование.
• Масштабирование SVG самописными функциями.
• Получение полного пути в приложениях.
• Тесты быстродействия GtkDrawingArea vs GtkImage.

* Ссылка на библиотеку в конце статьи. В самой статье изложены механизмы, реализованные в библиотеке, со средней детализацией. Реализация для macOS еще не закончена, но она мало чем отличается от реализации для Linux. Здесь в основном рассматривается реализация для Linux.

Гуляя по гитхабу одним субботним днем, я наткнулся на библиотеку, реализующую обновление c++ кода налету для windows. Сам я слез с windows несколько лет назад, ни капли не пожалел, и сейчас все программирование происходит либо на Linux (дома), либо на macOS (на работе). Немного погуглив, я обнаружил, что подход из библиотеки выше достаточно популярен, и msvc использует ту же технику для функции "Edit and continue" в Visual Studio. Проблема лишь в том, что я не нашел ни одной реализации под не-windows (плохо искал?). На вопрос автору библиотеки выше, будет ли он делать порт под другие платформы, ответ был отрицательный.

Сразу скажу, что меня интересовал только вариант, в котором не пришлось бы менять существующий код проекта (как, например, в случае с RCCPP или cr, где весь потенциально перезагружаемый код должен быть в отдельной динамически загружаемой библиотеке).

"Как так?" — подумал я, и принялся раскуривать фимиам.

Мы уже рассказывали о нововведениях, которые были сделаны в Linux kernel 4.18. Сегодня поговорим о том, что внедрили в 4.20, и проведем краткий обзор последующего релиза.

С большой долей вероятности он будет назван «5.0».

Привет, Хабр! Предлагаю вашему вниманию перевод статьи Брендана Грегга, посвящённой изучению 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 можно найти на сайте производителя. Или вот вырезка из даташита.