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

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

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

RT-11 — это операционная система из 1970-х годов для популярного в то время мини-компьютера PDP-11 фирмы DEC. В СССР известна под именами Электроника 60, ДВК, БК 0011М. Для тех, кто любит изучать чужой код в поисках инженерной эстетики — дальнейшее изложение.

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

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

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

Недавно я наткнулся на статью о том, что в ICMP-пакеты можно вставлять произвольные данные. Сразу возникла мысль: а почему бы не попробовать загнать весь трафик через ICMP (да, о существовании ICMP-туннеля я тоже ничего не знал). Так появился проект — ICMP?туннель на уровне ядра, который:

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

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

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

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

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

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

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

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

$ rustup update stable

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

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

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

Если у вас уже установлена предыдущая версия 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 можно было включать или отключить логи для конкретных программных компонентов. Отдельными командами вы можете увеличивать или уменьшать многословность логирования.

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