Linux *

Небольшой квест о замене кухонного принтера заказов в ресторане на табло заказов 24" монитор с raspberryPi за вечер. Это актуально практически для любой системы erp (все современные 1С системы в торговом оборудовании поддерживают чековые принтеры, аналогично и с другими системами).

Файловая система proc (в дальнейшем просто procfs) является виртуальной файловой системой, которая предоставляет информацию о процессах. Она — “прекрасный” пример интерфейсов следующих парадигме “все является файлом”. Procfs была разработана очень давно: во времена, когда серверы в среднем обслуживали несколько десятков процессов, когда открыть файл и вычитать информацию о процессе не было проблемой. Однако время не стоит на месте, и сейчас серверы обслуживают сотни тысяч, а то и больше процессов одновременно. В таком контексте идея “открыть файл для каждого процесса, чтобы вычитать интересующие данные” уже не выглядит такой привлекательной, и первое что приходит на ум чтобы ускорить чтение — это получение информации о группе процессов за одну итерацию. В этой статье мы попробуем найти элементы procfs которые можно оптимизировать.

Фьютекс (futex — сокращение от «Fast userspace mutex») — это механизм, предложенный разработчиками Linux из IBM в 2002 году и вошедший в ядро в конце 2003 года. Основной идеей было предоставить более эффективный способ синхронизации пользовательских потоков с минимальным количеством обращений к ядру ОС.

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

Важный момент: фьютексы — это достаточно низкоуровневый инструмент, напрямую его использовать стоит лишь при разработке фундаментальных библиотек, вроде стандартной библиотеки C/C++. Очень маловероятно, что вам понадобится использовать фьютексы в обычном прикладном приложении.

… а также другие страшные слова! (с)

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

Краткое содержание предыдущих частей

Из-за ограничений на возможность использовать компиляторы C++ 11 и от безальтернативности boost'у возникло желание написать свою реализацию стандартной библиотеки C++ 11 поверх поставляемой с компилятором библиотеки C++ 98 / C++ 03.

Были реализованы static_assert, noexcept, countof, а так же, после рассмотрения всех нестандартных дефайнов и особенностей компиляторов, появилась информация о функциональности, которая поддерживается текущим компилятором. Включена своя реализация nullptr, которая подбирается на этапе компиляции.

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

Ссылка на GitHub с результатом на сегодня для нетерпеливых и нечитателей:

Коммиты и конструктивная критика приветствуются

Больше шаблонов C++ под катом.

Под «шаблонами» в контексте C++ обычно понимаются вполне конкретные языковые конструкции. Есть простые шаблоны, которые упрощают работу с однотипным кодом — это шаблоны классов и функций. Если у шаблона какой-то из параметров сам по себе шаблон, то это уже, можно сказать, шаблоны второго порядка и генерируют они другие шаблоны в зависимости от своих параметров. Но что если и их возможностей недостаточно и проще генерировать сразу исходный текст? Много исходного текста?
Любителям Python а также HTML-вёрстки знакомо средство (движок, библиотека) для работы с текстовыми шаблонами под названием Jinja2. На вход этот движок получает файл-шаблон, в котором текст может быть перемешан с управляющими конструкциями, на выходе получается чистый текст, в котором все управляющие конструкции заменены текстом в соответствии с заданными извне (или изнутри) параметрами. Грубо говоря, это что-то вроде ASP-страниц (или C++-препроцессора), только язык разметки другой.
До сих пор реализация этого движка была только для Python. Теперь же она есть и для C++. О том, как и почему так вышло, и пойдёт речь в статье.

От переводчика

Студент Университета Тафтса рассказывает, как подкалывал своего соседа по комнате. Он даже меня подколол, когда начал свою историю с того, что у них в общаге висит 4K-телевизор.

Краткое содержание предыдущих частей

Из-за ограничений на возможность использовать компиляторы C++ 11 и от безальтернативности boost'у возникло желание написать свою реализацию стандартной библиотеки C++ 11 поверх поставляемой с компилятором библиотеки C++ 98 / C++ 03.

Были реализованы static_assert, noexcept, countof, а так же, после рассмотрения всех нестандартных дефайнов и особенностей компиляторов, появилась информация о функциональности, которая поддерживается текущим компилятором. Включена своя реализация nullptr, которая подбирается на этапе компиляции.

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

Ссылка на GitHub с результатом на сегодня для нетерпеливых и нечитателей:

Коммиты и конструктивная критика приветствуются

Продолжение погружения в мир «шаблонной магии» C++.

Неумолимо приближается час «Ч»: «использование схемы подписи ГОСТ Р 34.10-2001 для формирования подписи после 31 декабря 2018 года не допускается!». И вот, наконец, 16 июля 2018 г. на сайте Федерального ситуационного центра электронного правительства появилось Уведомление о начале выпуска сертификатов ключей проверки электронных подписей подчиненных удостоверяющих центров на головном удостоверяющем центре в соответствии с ГОСТ Р 34.10-2012. Правда, все равно не ясно когда же прекратится выпуск старых сертификатов. Но «процесс пошел» и это радует.

Есть много шаблонов построения контейнеров. Контейнер – это всего лишь выполняемая версия своего же образа. Поэтому способ построения контейнера тесно связан с тем, как он запускается.

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



Ниже мы рассмотрим наиболее типовые сценарии использования контейнеров.

(Введение в терминологию контейнеров см. в первой части)

Краткое содержание предыдущих частей

Из-за ограничений на возможность использовать компиляторы C++ 11 и от безальтернативности boost'у возникло желание написать свою реализацию стандартной библиотеки C++ 11 поверх поставляемой с компилятором библиотеки C++ 98 / C++ 03.

Были реализованы static_assert, noexcept, countof, а так же, после рассмотрения всех нестандартных дефайнов и особенностей компиляторов, появилась информация о функциональности, которая поддерживается текущим компилятором. Включена своя реализация nullptr, которая подбирается на этапе компиляции.

Настало время type_traits и всей этой «особой шаблонной магии».

Ссылка на GitHub с результатом на сегодня для нетерпеливых и нечитателей:

Коммиты и конструктивная критика приветствуются

Погрузимся же в мир «шаблонной магии» C++.

Краткое содержание предыдущих частей

Из-за ограничений на возможность использовать компиляторы C++ 11 и от безальтернативности boost'у возникло желание написать свою реализацию стандартной библиотеки C++ 11 поверх поставляемой с компилятором библиотеки C++ 98 / C++ 03.

Были реализованы static_assert, noexcept, countof, а так же, после рассмотрения всех нестандартных дефайнов и особенностей компиляторов, появилась информация о функциональности, которая поддерживается текущим компилятором. На этом описание core.h почти закончено, но оно было бы не полным без nullptr.

Ссылка на GitHub с результатом на сегодня для нетерпеливых и нечитателей:

Коммиты и конструктивная критика приветствуются

Итак, продолжим.

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

О том, что будет сделано и что уже реализовано — рассказываем под катом.

В начале месяца британская компания Micro Focus объявила о продаже старейшей компании-разработчика дистрибутивов SUSE Linux за 2,5 млрд долларов. Обладателем SUSE стала шведская фондовая группа EQT, занимающаяся инвестициями в технологические компании.

Далее — почему заключили сделку, и как отреагировало сообщество.

Краткое содержание предыдущих частей

Из-за ограничений на возможность использовать компиляторы C++ 11 и от безальтернативности boost'у возникло желание написать свою реализацию стандартной библиотеки C++ 11 поверх поставляемой с компилятором библиотеки C++ 98 / C++ 03.

Помимо стандартных заголовочных файлов type_traits, thread, mutex, chrono так же были добавлены nullptr.h реализующий std::nullptr_t и core.h куда были вынесены макросы, относящиеся к компиляторозависимому функционалу, а так же расширяющие стандартную библиотеку.

Ссылка на GitHub с результатом на сегодня для нетерпеливых и нечитателей:

Коммиты и конструктивная критика приветствуются

Вместо предисловия

Пожалуй с этой картинки должно начинаться любое повествование о boost, Loki, самостоятельных, да и так же поставляемых с компиляторами реализациях стандартной библиотеки C++.

Да-да, и если вы думали что разработчики стандартной библиотеки для того же g++, clang, Visual Studio или, прости господи, C++ Builder (бывший Borland, а нынешний Embarcadero) — гуру, что не городят костылей, не ломают стандарт под свой компилятор и не пишут велосипедов, то, скорее всего, вы не так активно используете стандартную библиотеку C++ как вам казалось.

Статья написана как рассказ, и содержит много «воды» и отступлений, но я надеюсь, что мой опыт и получившийся код будет полезен тем, кто столкнулся с похожими проблемами при разработке на C++, особенно на старых компиляторах. Ссылка на GitHub с результатом на сегодня для нетерпеливых и нечитателей:

https://github.com/oktonion/stdex (коммиты и конструктивная критика приветствуются)

А теперь, обо всем по порядку.

Ну или почти вся...

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

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

Anyone can wield an axe, but it takes a true warrior to make it sing melees melody.

Я предполагаю, что читатель знаком с epoll, по крайней мере прочел страницу man. О epoll, poll, select написано достаточно много, чтобы каждый кто разрабатывал под Linux, хоть раз о нем слышал.

Под катом расположен перевод вступительной части документа Detecting Kernel Memory Disclosure with x86 Emulation and Taint Tracking (Статья Project Zero) от Mateusz Jurczyk.

В переведенной части документа:

• специфика языка программирования C (в рамках проблемы раскрытия памяти)
• специфика работы ядер ОС Windows и Linux (в рамках проблемы раскрытия памяти)
• значимость раскрытия памяти ядра и влияние на безопасность ОС
• существующие методы и техники обнаружения и противодействия раскрытия памяти ядра

Хотя в документе пристально рассматриваются механизмы общения привилегированного ядра ОС с пользовательскими приложениями, суть проблемы можно обощить для любой передачи данных между различными доменами безопасности: гипервизор — гостевая машина, привилегированный системный сервис (демон) — GUI приложение, сетевые клиент — сервер и т.д.

Вы можете спросить, зачем разбираться с терминологией, если концепция контейнеров выглядит вполне простой и понятной? Однако, довольно часто неверное использование терминов создает препятствия на пути к освоению контейнеров. Например, люди часто считают, что термины «контейнеры» и «образы» взаимозаменяемы, хотя на самом деле между ними есть важные концептуальные различия. Другой пример: в мире контейнеров «репозиторий» означает вовсе не то, что вы думаете. Кроме того, контейнерные технологии – это гораздо больше, чем только docker.



Так что, не владея терминологией, будет сложно понять, чем docker отличается от CRI-O, rkt или lxc/lxd; либо оценить роль Open Container Initiative в деле стандартизации контейнерных технологий.

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