Системное программирование *

Как только я узнал, что книга Making Embedded Systems 2nd Edition (русская версия: «Создание встраиваемых систем. Паттерны проектирования отличных программ. 2-е издание») доступна для предзаказа, я не раздумывая отправился на Amazon и раскошелился за неё.

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

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

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

Просмотрев на сайте O'Reilly предметный указатель и выложенные для просмотра главы, я обнаружил, что такой «конфигурационной» главы в книге нет. Также в предисловии прямо рекомендовалось не прыгать по книге от главы к главе, а проработать её всю по порядку.

Нередко при оптимизации приложений, написанных на языках со статической компиляцией (C, C++, Rust), наступает момент, когда стандартные методы оптимизации, такие как улучшение алгоритмов, подбор структур данных, флаги компиляции вроде -O3, перестают давать дополнительный прирост производительности. В этот момент многие вспоминают про фундаментальное ограничение статических компиляторов. В отличие от JIT, они не знают, какой код будет горячим, а какой холодным. JIT-компиляторы (JVM, V8, .NET) получают эту информацию в runtime и адаптируют оптимизации под реальную нагрузку. Статические компиляторы генерируют машинный код заранее и лишены информации о поведении программы в runtime. Для решения этой проблемы используется подход Profile Guided Optimization (PGO). Он позволяет собрать данные о выполнении программы и передать их компилятору для принятия более оптимальных решений при генерации кода. По сути, PGO - это способ дать статическому компилятору некоторые преимущества JIT, сохраняя при этом все преимущества ahead-of-time компиляции: отсутствие пауз на перекомпиляцию и полный контроль над билдом.

По данным отраслевых опросов, в 2025 году 84% разработчиков использовали ИИ-инструменты для написания, отладки и автоматизации кода. А в 2026 году ожидается, что более 80% компаний будут применять генеративный ИИ в разработке своих продуктов. Но у LLM есть ограничения, которые не позволяют им быть одинаково эффективными для всех языков программирования — например, для С++.

Тему ограничений AI в пайплайне «плюсовой» разработки обсудили Андрей Золотых и Илья Казаков из YADRO, Константин Владимиров из Синтакор, Илья Шишков из Сбертех и Денис Фокин из LRI. К каким выводам пришли эксперты, читайте под катом. 

Кен Томпсон с Деннисом Ритчи являются соавторами Unix — операционной системы, которая лежит в фундаменте современной ИТ-индустрии. Важно заметить, что он начал работать над Unix раньше Ритчи. По словам Томпсона, он в одиночку написал первые версии Unix и делал в Bell Labs предшественников Unix и С — ОС Multics, языки Bon и B — ещё до того, как туда пришёл юный аспирант Деннис, помог всё улучшить и разработал язык С. Но вообще их карьера очень похожа: обоих после вуза направили в Bell Labs, где они трудились почти всю жизнь.

Томпсон неоднократно входил в топ-10 программистов всех времён и тому подобные рейтинги. Кроме Unix, в его послужном списке операционная система Plan 9, язык программирования Go и несколько выдающихся программ.

Это история о том, как мы несколько недель искали странные скачки latency в продакшене и в итоге уткнулись в поведение кэша процессора. Не в аллокатор, не в GC, не в сеть. В кэш. В статье — реальные эксперименты, код, метрики, гипотезы, которые не подтвердились, и довольно неприятные выводы о том, насколько процессор может быть непредсказуемым, когда система нагружена по-взрослому.

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

Рассказываем, как найти актуальный проект, не утонуть в заброшенных Issue и грамотно отправить свой первый PR. А если вы сами развиваете проект то узнаете, как дать ему шанс получить: звёзды, обсуждение, интерес со стороны других разработчиков и первые контрибьюты в дружелюбной среде.

Как Вы могли заметить, у микроконтроллеров STM32F4 секторы NOR Flash памяти обладают разным размером: 16kByte(4 шт), 64kByte (1 шт), 128kByte ( 7+ шт.).

Это накладывает определенную специфику на программирование микроконтроллеров STM32F4.

Из каких секций обычно состоит Flash память микроконтроллерной программы?

В этом тексте я предлагаю простое решение проблемы разметки памяти для случая работы с микроконтроллерами STM32F4.

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

Часто SDET-инженеры, работающие со встраиваемыми системами, не приступают к работе, пока не получат реальное железо: датчик, микроконтроллер или плату с новым чипом. Такой подход обычно оправдывают тем, что без физического девайса «на столе» писать корректно работающий софт невозможно. Очевидный минус: увеличивается время выхода продукта и нового функционала на рынок. Но разработку можно начать, даже не имея в своем распоряжении устройства: все дело в договоренности между командами.

Меня зовут Рустам Ахмадуллин, я старший инженер по системной верификации аппаратуры в YADRO. Расскажу на примере датчика температуры LM75A, как написать API без физического доступа к устройству и его прошивке. Разберем методологию Test Driven Development, при которой разработка начинается с написания автоматизированных тестов, а не самого кода.

Что происходит, когда вы вводите ls в терминале? Как 2 буквы превращаются в список файлов на экране? Я решил разобраться и написал свой терминал с нуля на C++.

В этой статье я объясняю через метафору ресторана, как работают три магических системных вызова — fork(), exec() и wait() — которые лежат в основе любого терминала. Вы узнаете, почему cd нельзя сделать обычной программой, как работает перенаправление >, и какой коварный баг я поймал из-за непонимания процессов. Без сложной теории — только практика и понятные объяснения.

В предыдущих сериях (От стартапа к протоколу, Почему финтеху нужен капитальный ремонт, Почему мы терпим факс в эпоху ИИ) мы обсуждали, почему современный финтех - это "Ferrari на грунтовке", и зачем мы начали писать с нуля свой леджер Qazna (на Rust) и ERP-систему Orda (на Go).

В комментариях вы справедливо спрашивали: "Зачем изобретать велосипед, если есть PostgreSQL и Kafka?" и "Чем это отличается от Hyperledger/Ripple?".

Сегодня я отвечу на эти вопросы кодом и архитектурой. Мы не просто "переписали базу". Мы построили суверенный стек, который делает три вещи, невозможные в legacy-системах:

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

Но возможна ли работа ядра Linux без этих, вроде бы обязательных компонентов? Ответ на вопрос — да, возможна, но использовать такие возможности в конечном продукте не стоит.

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

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

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

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

Современный Deep Learning уперся в производительность вычислений с плавающей точкой (float) и пропускную способность памяти. Мы предлагаем архитектуру «Обратного Хэша», где нейрон — это не сумма произведений, а битовая функция.

Ноль умножений. Ноль сложений. Только логика (XOR), статистика и скорость света.

11 000 строк кода, 95% Zig, 0% стандартной библиотеки: история создания NovumOS с поддержкой SMP, FAT32 LFN и Huge Pages.

Привет, Хабр! 👋

Меня зовут Антон, и я хочу поделиться историей создания своей собственной операционной системы.

Это моя первая статья и первый серьезный релиз системы (v0.20). Многие разработчики мечтают написать свою операционную систему. Обычно этот путь заканчивается на выводе "Hello World" в VGA-буфер. Я тоже начинал с малого (C# COSMOS), потом уходил в Ассемблер, бросал, возвращался... Но в этот раз я решил пойти до конца.

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

Встречайте NovumOS...

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

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

В этой части я покажу, как улучшилось ядро за это время: поддержка новых устройств (запуск и отладка в QEMU и Raspberry Pi 5), разбиение на модули, и, наконец, полноценный менеджер памяти. В этом нам очень поможет система типов Rust.

Что делать, если в твоём очередном самописном движке внезапно понадобилась сеть, да ещё и на корутинах из C++ 20, а подходящая библиотека не поддерживает Windows? Правильно - лезть под капот, разбираться что такое epoll, почему он несовместим с IOCP, затем вкатиться в Open Source, сделав огромный PR, выгореть на полгода, чтобы потом вернуться и начать делать нормально.

Небольшая история о том, почему первый PR не должен быть огромным и как (не) нужно переписывать сетевую библиотеку.

Для пользователя может показаться, что переход с HTTP/2 на HTTP/3 — это просто замена TCP на UDP в конфиге. Но для серверного ПО с многопроцессной архитектурой этот шаг превращается в настоящую «головную боль». Классическая схема с accept(), на которой годами строилась работа с TCP‑соединениями, в мире QUIC попросту не существует. Пакеты летят в UDP‑порт, и ядро ОС больше не знает, какому именно рабочему процессу их отдать.

В оригинальном nginx это привело к тому, что поддержка HTTP/3 уже долгое время остается «экспериментальной» и ограниченной: она страдает от проблем с обрывами сессий и деградации сервиса при обновлении конфигурации. Для многих это стало стоп‑фактором для внедрения протокола в реальный продакшен.

В этой статье мы расскажем, как в Angie 1.11 нам удалось устранить эти фундаментальные недостатки. Мы не просто добавили поддержку протокола, а пересмотрели механику взаимодействия с ядром. Путь от простых хешей до создания полноценного аналога accept() для QUIC с помощью BPF‑программ позволил нам заявить: реализация HTTP/3 в Angie закончена, лишена «детских болезней» nginx и полностью готова к эксплуатации в высоконагруженных средах.

Добро пожаловать под капот современного транспорта данных.

Как-то при разработке UEFI мне посчастливилось разбираться с таблицами описания системы в исходниках ASL (ACPI Source Language). Тема оказалась не тривиальная и моего багажа в несколько лет опыта, достаточно плотной embedded-разработки, не хватало для полного понимания работы подсистемы ACPI (Advanced Configuration and Power Interface). Поэтому пришлось исследовать доступные материалы на тему. 

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