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

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

Нейросеть не ищет в своей памяти «похожую картинку», как это делал бы человек. Вместо этого она выделяет в кадре набор математических признаков (например: «объект круглой формы находится в верхней части другого объекта»). На основе миллионов заранее обученных весов (параметров) сеть вычисляет вероятность: «это каска — 96%», «это человек — 98%».

Откуда берутся весы? База знаний нейросети наполняется вручную на этапе обучения. Специалисты-разметчики показывают модели тысячи кадров, выделяя на них людей, каски, инструменты и другие нужные объекты.

«Брус-16» — это новая игровая приставка. За полтора месяца мы спроектировали ее архитектуру, а также создали виртуальную машину, компилятор и аппаратную реализацию на FPGA. Специально для Брус-16 написано более 10 игр. Если вам интересны “серьезные” темы системного программирования, компьютерных архитектур и цифровой схемотехники, а также темы “несерьезные” – разработка игр в духе ретро-инди, демосцена и эстетика минимализма, то читайте дальше. Кстати, картинка выше состоит ровно из 64 прямоугольников. Это важно. Впрочем, обо всем по порядку!

15 апреля 2026 года Pragmata, новый sci-fi экшен от Capcom, появилась на пиратских ресурсах. Игра официально вышла 17 апреля. Платящие клиенты ждали разблокировки в Steam, а пираты уже бегали по лунной станции. Денуво, который должен был защитить хотя бы первые недели — самые продажные дни, ради которых эту защиту и покупают — пробит через hypervisor bypass от команды DenuvOwO. И это не аномалия: с декабря 2025-го Denuvo проигрывает каждую неделю. Persona 5 Royal, Borderlands 4, Resident Evil: Requiem, Crimson Desert, теперь Pragmata.

Под капотом — модифицированный open-source отладчик HyperDbg, EfiGuard как UEFI-bootkit, патчинг PatchGuard через паттерн-матчинг Zydis, спуфинг CPUID и KUSER_SHARED_DATA через EPT. Технически — kernel rootkit, юридически — пакет «play & restore» из закрытого Telegram-канала. Денуво живёт в Ring 3, обход — в Ring -1, между ними четыре уровня привилегий: detection из user-mode принципиально невозможен.

В статье разбираю шесть слоёв защиты, которые приходится снять, чтобы загрузить пиратский гипервизор: Secure Boot, PatchGuard, DSE, CPUID/RDTSC, KUSER_SHARED_DATA, Steam ownership. Что держит — HVCI. Что может сделать Irdeto и почему все варианты плохи. И на закуску — voices38, который через 40 дней после релиза Resident Evil: Requiem опубликовал классический crack: +5% FPS и работа под Proton на Linux, чего hypervisor-метод никогда не умел.

Центральная идея: одно ядро, runtime-профили

Проблема, которую решает OptimaOS — фрагментация через форкинг. Android — форк Linux. Embedded-дистрибутивы — форки с кастомными патчами под каждый SoC. AI-стеки — отдельные кодовые базы. Каждый форк — это отдельный security-аудит, отдельная команда и свой накапливающийся регресс.

Большинство компаний уже умеют делать «нормальные» рассылки: есть шаблон, темы писем, календарь и какие‑то метрики. На этом уровне всё обычно и останавливается: письма что‑то рассказывают, но слабо влияют на процессы и не используют свой потенциал. Внутри всё выглядит прилично: open rate «нормальный», люди иногда переходят по ссылкам, новая политика безопасности или свежий релиз продукта формально донесены до адресатов. Но ощущение такое, будто рассылка живёт сама по себе, а жизнь компании — сама по себе.

В этой статье я соберу несколько нетривиальных методик корпоративных рассылок — не про то, «как правильно верстать в таблицах» или «почему нужен SPF/DKIM/DMARC», а про вещи, которые лежат чуть глубже. Как использовать прехедер и автоответы как инструмент, превратить статистику в личные письма, не бояться ошибок в рассылках, заставить письма двигать внутренние процессы, подружиться с отпиской и оживить самые скучные служебные уведомления. Каждый кейс дальше можно будет развернуть в отдельную статью, а сейчас — обзор с небольшими анонсами.

В первой статье я рассказывал историю «деда из деревни», который вместе с внуком поднял свой почтовый сервер вместо Gmail — на обычном VPS, с доменом, DNS‑записями и всеми сопутствующими приключениями. Эта иллюстрация продолжает ту линию: дед‑айтишник и внук уже не просто радуются первому письму, а разбираются, что происходит с их маленьким сервером в большом почтовом мире.

В 47 мои увлечения стали Си, Radare2 , Биты, Логика, Память. Изучая память зацепился за адреса. На адрес 0x7ffe10b284 можно смотреть бесконечно долго. Трудно сказать с ходу насколько удачно ваши данные легли в память. Влезают они в одну кеш-линию или размазаны по двум. Чтоб не заниматься битовой арифметикой в уме, я написал утилиту на Си для Linux и Termux. Она раскладывает младшие 12 бит адреса на 4 строки визуализации. Теперь сразу видно, попали мы в "Голову" или застряли в "Хвосте" кеш-линии.

Утилита максимально легковесная. Вам не нужны сложные дебаггеры, достаточно gcc. Работает, как на десктопном Linux, так и в Termux на Android. Можно проверить выравнивание даже лёжа на диване.

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

Эта статья — о mechanical sympathy, подходе, который помогает смотреть на производительность как на следствие понимания базовых ограничений и привычек железа: от строк кэша и ложного разделения до принципа одного писателя и естественной пакетной обработки. Для тех, кто строит или эксплуатирует highload‑системы, это хороший способ заново посмотреть на причины тормозов там, где код вроде бы уже давно «нормально работает».

Привет, Хабр! Летом мы рассказывали о сложном, но очень интересном пути в создании UEFI-загрузчика для серверных продуктов компании OpenYard. Теперь хочется перейти к его постоянному спутнику ― BMC, без которого сегодня трудно представить полноценную серверную платформу. 

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

При этом на STM32 обычно очень легко регулировать частоту, заполнение и инвертировать фазу меняя полярность.

Однако как непрерывно регулировать фазу PWM?

В этом тексте я написал четыре способа управлять фазой PWM сигнала.

Я хочу показать вам, как одна буква в ассемблере может стоить 3× производительности. Не в теории — на живых замерах. По дороге мы заглянем внутрь процессора: Register Alias Table, partial register merge, scheduler, latency vs throughput, и даже обнаружим, что делитель выдаёт остаток раньше частного.

Но начнём с основ. Приготовьтесь: кроличья нора окажется глубже, чем кажется.

Если у вас уже установлена предыдущая версия Rust через rustup, вы можете получить 1.95.0 командой:

$ rustup update stable

Если у вас еще не установлен Rust, вы можете получить rustup на соответствующей странице нашего сайта, а также ознакомиться с подробными примечаниями к выпуску 1.95.0.

Если вы хотите помочь нам, тестируя будущие релизы, попробуйте локально переключиться на beta-канал (rustup default beta) или nightly-канал (rustup default nightly). Пожалуйста, сообщайте о любых найденных ошибках!

Если у вас уже установлена предыдущая версия Rust через rustup, вы можете получить 1.94.0 командой:

$ rustup update stable

Если у вас еще не установлен Rust, вы можете получить rustup на соответствующей странице нашего сайта, а также ознакомиться с подробными примечаниями к выпуску 1.94.0.

Если вы хотите помочь нам, тестируя будущие релизы, попробуйте локально переключиться на beta-канал (rustup default beta) или nightly-канал (rustup default nightly). Пожалуйста, сообщайте о любых найденных ошибках!

Вы сделали open source проект. Потратили на него недели или даже месяцы: продумали архитектуру, аккуратно написали код, добавили нужные фичи. Даже сами начали им пользоваться.
А потом открыли GitHub… и ничего не произошло. Ни пользователей. Ни обсуждений. Ни pull request’ов. Иногда даже звёзды не появляются.

И в этот момент возникает вполне логичный вопрос:
“Что не так?”

Разбираем, что мешает проектам получать пользователей и контрибьюторов, и как это изменить.

— Дед, Gmail опять всё перекрутил. Письма теряются, половина — реклама, интерфейс другой, ничего не понятно. Ты же у нас главный по всяким проводам, придумай что‑нибудь.

Я посмотрел на него, потом на старый систем ник в углу комнаты, на наш деревенский интернет, который любит падать в самый неподходящий момент, и вдруг поймал себя на мысли: а действительно, почему бы не попробовать завести почту «по‑стариковски» — на своём домене, на своём сервере, со своими правилами. Не потому что я лучше Google, а потому что интересно понять, сколько сегодня стоит «своя почта» для обычного человека из глуши и можно ли на ней жить в реальном, а не лабораторном деревенском быту.

Начал я, как ни странно, не с железа, а с имени.
Объяснил внуку, что домен — это человеческое имя вместо голых цифр. Ящик vnyuk@ded-v-derevne.ru звучит всё‑таки повеселее, чем vanya2008_mega@какой‑нибудь‑бесплатный‑сервис. Домен зарегистрировали, я зашёл в панель и занялся тем, что обычно никого не волнует, пока всё работает, — настройкой записей, которые говорят остальному миру, куда нести письма.

Рассказывал внуку на пальцах: вот у нас есть «адрес дома» — запись, где написано, на какой IP смотреть, когда кто‑то ищет ded-v-derevne.ru. Есть особая запись для почты — мол, «письма складывать вот сюда, в этот ящик на сервере». Есть ещё строка с перечислением тех, кому вообще можно доверять отправку писем от нашего имени — чтобы спамеры не прикидывались нами. Для него это звучало как какая‑то бюрократия, для меня — как привычная настройка, которой просто давно не занимался.

Вызов инструментов в LLM сегодня воспринимается как решённая задача: модели научились стабильно работать с функциями, а API – ограничивать доступ. Но на практике остаётся неприятный класс сбоев, который не выглядит как баг, пока не становится инцидентом. В определённых условиях модель может «придумать» инструмент и успешно его вызвать – если он существует в окружении. В статье разберемся, почему это происходит, как это связано с архитектурой агентных систем и к каким последствиям приводит в реальных сценариях работы с данными и доступами.

Год назад запуск модели на 35 миллиардов параметров подразумевал облако, очередь на GPU, и счёт от провайдера в конце месяца. Сегодня я покажу, как мы сделали это на одной потребительской видеокарте AMD за $500 — без ROCm, без CUDA, без MLX, одним бинарником на Zig.

Это пост про ZINC — inference engine, который мы строим с нуля под железо, которое люди реально покупают. Не как proof of concept, а как рабочий инструмент с OpenAI-совместимым API, потоковой генерацией и встроенным чатом.

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

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

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

Естественное желание — привязать лог не к месту вызова, а к самой задаче. Самый прямой путь — передавать контекст через параметры (например, инстанс логгера), но довольно быстро это начинает протекать через весь код и превращается в обязательный шум в сигнатурах. Гораздо более устойчивый подход — привязать контекст к потоку выполнения. В библиотеке logme это делается через thread channel:

Привет, Хабр! Меня зовут Aloncie. Пока в моем окружении часто спорят о том, какой язык программирования учить первым, я решил не выбирать легких путей и закопаться в «кишки» системного программирования.

Мой проект Rwal — это CLI-утилита (с перспективой перехода на GUI) для управления обоями, которая должна одинаково хорошо чувствовать себя в разных окружениях: от KDE и GNOME до Windows. В этой статье я подробно разберу архитектуру проекта, работу с D-Bus, интеграцию со стандартами C++20 и то, как я организовал сборку.

Всё началось на второй паре по системному программированию. Нам дали задачу: написать CLI-утилиту для анализа логов - парсить файл, фильтровать записи по уровню ошибок, считать статистику, выводить красиво в консоль. "Ну понятно", - открыл я vim и началось мое долгое приключение...

Неделя. Две. Утилита называлась logz, она умела читать логи nginx и apache, фильтровать по уровню (DEBUG, INFO, WARN, ERROR), по дате, по IP, выводила топ адресов с наибольшим числом ошибок, рисовала простенький bar-chart прямо в терминале через unicode-символы. Только вот я сидел как-то вечером, запустил wc -l main.c - 3147 строк. И смотрел на это число минуты три с таким лицом - O_O.

Сама утилита работала. Но открывая её осознаешь что - это месиво. Одна функция process_file на 400 строк. Сегфолты раз в неделю. Valgrind как лучший друг. И каждый раз когда надо добавить фичу - сначала полчаса вспоминаешь что вообще происходит в коде.

Потом я случайно прочитал пост про Zig на lobste.rs. Заинтересовался и попробовал. Через месяц у меня была та же утилита, но теперь на 1089 строках, которая работала быстрее и не падала.

Тут я понял что вот золотая жила и расскажу о том - зачем Zig, как переписывал, где облажался и что вышло в итоге.

Есть конференции, куда идут за нетворком. А есть такие, куда идут за средой, в которой вырастают сильные инженеры, исследователи и создатели сложных технологий. СПИСОК — именно такая конференция.

С 27 по 30 апреля 2026 года на базе матмеха СПбГУ пройдет всероссийская научная конференция по проблемам информатики СПИСОК-2026.

В этом году конференция посвящена памяти Андрея Николаевича Терехова — доктора физико-математических наук, профессора, многолетнего руководителя кафедры системного программирования СПбГУ, человека, который во многом сформировал эту школу и заметно повлиял на развитие российской ИТ-среды.

Свое участие в конференции уже подтвердили:

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

Асинхронное логирование давно считается “очевидной оптимизацией”: вынесли запись в отдельный поток — и всё стало быстрее.

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

В предыдущей статье я разбирал производительность популярных C++ логгеров и показывал реальные цифры:
👉 https://habr.com/ru/articles/1012874/

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

В этой статье разберёмся, почему async logging не делает логирование быстрее само по себе, и что на самом деле происходит внутри:

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

Чтобы с этим бороться придумали уровни логирования Log Levels.

Суть в том, чтобы из shell консоли в run time можно было включать или отключить логи для конкретных программных компонентов. Отдельными командами вы можете увеличивать или уменьшать многословность логирования.

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

Наверняка многие и не задумываются: а как на самом деле происходит возврат структур и других типов значений из функций? Что происходит под капотом, какие приемы задействует компилятор? В данной статье я постараюсь дать ответы на эти вопросы и сделать это просто и понятно.

Архитектура в ИТ — это не «нарисовать диаграмму» и не «выбрать стек». Это работа со сложностью: там, где одной команде уже тесно, где требования конфликтуют, а решения нужно держать в голове годами.

В этом интервью я, Александр Шулепов (телеграм-канал Shulepov Code), поговорил с Филиппом Дельгядо — архитектором финтех-продуктов и создателем сайта lekton.io — о том, с чего начинается архитектура, почему «монолит vs микросервисы» не решается одной фразой и какие навыки действительно определяют уровень специалиста.

В этом тексте я написал как реализовать CLI на CAN шине.

В разработке электроники часто делают электронные плату без UART, но с CAN .

Как же отлаживать софт и железо в таких случаях?

Кейс полностью автономного траблшутинга нетривиальной системной проблемы с неработоспособностью NVENC в Docker-контейнере на Jetson Orin NX с помощью Claude Opus 4.6, как пример выхода больших языковых моделей за пределы квалификации middle-grade инженера. Около 40 минут заняло расследование проблемы, по мотивам которого, я попросил сеть написать статью, которую и предлагаю вашему вниманию как пример того, на что я мог потратить целый день, а большинство middle-grade инженеров бы не справилось вообще. Весь траблшутинг и статья сделаны в полностью автоматическом режиме без участия человека.

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

Логирование есть практически в каждом C++ проекте. Почти любой сервис, демон или библиотека рано или поздно обрастает строками вроде LOG_INFO(...) или logger.debug(...).

Чаще всего библиотека выбирается по привычке или популярности — spdlog, quill, easylogging++ и т.п. При этом редко кто проверяет, какую цену приложение платит за логирование.

В высоконагруженных системах логирование может выполняться:

А вы знаете что в СССР у нас были свои языки программирования? Что ж, почему бы нам не посмотреть что мы можем возродить?

Иногда старые проекты дают о себе знать в самый неожиданный момент — так случилось и с моим Linux GPIO Daemon. Коллеги из департамента методик и автоматизации тестирования в YADRO заинтересовались разработкой, и я наконец решил довести его до ума. Расскажу о демоне, который реагирует на события линий: текстовым сообщением об изменении состояния в сокет либо запуском скрипта. Это аналог incron-ng, только мониторит он не файлы, а линии GPIO. А в конце обсудим, как найти и затем не терять нужный нам gpiochip.

Эта статья скорее всего будет полезна тем, кто продолжает разбираться или работать на платформах .NET . Предупреждаю! Здесь будет далекое плавание в разные места, и с точки ОС будет упомянуто достаточно много!

На просторах Хабра есть несколько хороших статей про устройство и поведение .NET. Мне хотелось бы стать "чем-то по связующим" между ними.

В данной статье мы подробно поговорим об устройстве RPC. Также для лучшего понимания применим знания на практике и напишем свое RPC-приложение под Windows.

Привет, Хабр! Меня зовут Владлен, я ― инженер-программист отдела разработки РЕД ОС. Ко мне пришли с предложением рассказать об утилите, которую мы создали для быстрого ввода устройств на базе РЕД ОС в домен. Тема интересная, ведь join-to-domain умеет в несколько механизмов подключения, пережил перенос на другой язык программирования и дружит с РЕД АДМ. Итак, сегодня я расскажу подробнее о том, как мы создали join-to-domain и как использовать его на благо вашей ИТ-инфраструктуры.

Древний дисковод ожил и издавая чудовищный скрежет стал медленно загружать мое послание. Через какое-то время на экране появились строки:

NE PUERO GLADIUM, DR. KRIGER. 04.03.2026

Три пары глаз повернулись ко мне в немом изумлении.

— Это длинная история, нам лучше присесть.