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

Может ли Rust заменить C? Этот вопрос беспокоил меня много лет. Тем временем я успел написать upb — библиотеку C для работы с Protocol Buffers, и сейчас являюсь её техническим руководителем. Вполне понятно стремление обеспечить безопасность памяти в пределах всего программного стека — поэтому и возникла идея портировать upb на Rust.

Притом, что мне приятны базовые принципы Rust, я долгое время относился к этой идее скептически и сомневался, что, портировав upb на Rust, удастся сберечь её производительность и компактность кода, которые мы с коллегами так старались оптимизировать. На самом деле, исходно я собирался написать статью о том, почему именно применительно к upb языку Rust никогда не сравниться с C по производительности.

Но недавно я открыл для себя одну технику, которая заставила меня немного переосмыслить этот вопрос. Я назову её «Rust без паник». Притом, что этот метод определённо не нов, мне нигде не удалось найти подробного разбора, в котором бы рассказывалось, как именно этот метод используется и какие проблемы решает. Правда, интересная дискуссия по этому поводу велась в теме Enforcing no-std and no-panic during build, где есть ссылки на некоторые релевантные треды из почтовой рассылки, посвящённой разработке ядра Linux. Вот другой интересный тред: Negative view on Rust: panicking

Надеюсь, эта статья позволит заполнить данный пробел.

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

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

$ rustup update stable

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

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

🦀 Практическое руководство по работе с аудио в Rust: от захвата с микрофона через CPAL до эффективного сжатия в Opus. Реализация системы с задержкой <50 мс и сжатием 42:1. Исходный код, тесты и метрики производительности.

Материал отлично подходит для использования AI-агентами: поставил задачу ИИ-ассистенту и он написал работающий диктофон всего с одной правкой.

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

Осторожно: статья написана максимально простым языком. Так что если вы гик, но не умеете программировать — вам всё равно будет интересно!

Недавно я наткнулся на DIY-игровую консоль за 1.500 рублей — Waveshare GamePi13. Когда гаджет приехал ко мне, я запустил примеры игр от производителя... и оторопел от 5 FPS в Pong — это ж как плохо нужно код писать!

Не желая мириться с этим, я открыл схему устройства, даташит на RP2040 и принялся писать свой собственный BIOS. Если вам интересно узнать, как работают DIY-консоли «изнутри», можно ли запускать внешние программы на микроконтроллерах из RAM, как реализованы различные подсистемы BIOS, а в конце даже написать «Змейку» - добро пожаловать под кат!

Когда включаешь компьютер, видишь привычное окно с кнопкой «Пуск» и даже не задумываешься, что это результат десятков лет борьбы — технической, рыночной и даже судебной и политической. Операционная система Windows давно стала синонимом персонального компьютера. В этой статье мы разберём, как Microsoft смогла создать удобную систему и сделать её стандартом для всего мира: какие шаги, решения и ошибки привели Windows к господству на миллионах машин.

Всем привет! Меня зовут Виктор, и я программист. Восемь лет работаю в команде Т-Банка и все это время вместе с коллегами занимаюсь проектом «Т-Телефония». Моя команда разрабатывает сервисы, которые обеспечивают голосовую коммуникацию внутри и вне банка. 

Звонки — один из основных способов связи с нами, поэтому система критична для бизнеса с высоким требованием к доступности. Она обрабатывает более 2 млн звонков в день. Если происходит сбой в любой пользовательской системе и нашим клиентам плохо, количество звонков сразу увеличивается, а нагрузка на систему повышается в два-три раза.

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

В статье покажу, что такое дампы, какие есть инструменты для работы с ними и какие у них особенности, покажу наши примеры проблем, расскажу, как мы их решали.

Мост для тех кто привык к Systemd. Без эмуляции, без Systemd-зависимостей. Только переводит команды.

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

Технологические компании наподобие Ticketmaster, BookMyShow, Airbnb, Delta Airlines и так далее сделали бронирование делом одного клика, позволившим покупать билеты из дома.

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

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

Поэтому важно создать надёжное решение классической задачи — двойного букинга.

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

Мы рассмотрим различные архитектурные паттерны и разберёмся в их плюсах и минусах. Статья поможет вам обрести глубокое понимание и наработать знания в системном мышлении.

Всем привет!

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

Мне 22 года, я из Латвии. По образованию я судовой механик, но уже около 4 лет увлекаюсь программированием. Долгое время это оставалось хобби: пробовал сайты, простые игры — но они не приносили настоящего удовольствия. Я считал, что в программировании нужно было разбираться ещё со школы, и долго не верил, что могу найти себя в этой сфере.

Переломный момент наступил, когда я заинтересовался системным программированием. Каждый раз, когда узнаю, как работает низкоуровневая часть ОС, у меня будто открывается новый мир. Особенно зацепила тема процессорного планирования: все говорят «железо, CPU, видеокарта», но на практике даже реализация планировщика процессов может заметно влиять на производительность.

OpenRC + AUR + Wine с DXVK/VKD3D + модульный TUI-установщик. Всё это — QuasarLinux, основанный на Artix, но независимый от него.

Последняя релизная версия ReactOS 0.4.15 выпущена 21 марта 2025 г.
А в начале октября 2025 Вадим Галянт выпустил экспериментальную сборку ReactOS, предназначенную для отработки загрузки операционной системы на реальном железе. Сборка должна быть совместима с железом, предназначенным для загрузки Windows XP (NT5.x). На более новом железе система скорее всего грузиться не будет.

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

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

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

Если вы создали сокет, попытались его открыть и отвалились по таймауту - не переиспользуйте его! Для новой попытки обязательно создавайте новый сокет!

Это не вполне очевидно и в документации порой лишь вскользь упомянуто, либо не упомянуто вообще. Ниже немного подробностей с кодом, но в общем вся суть в этой фразе. Не переиспользуйте!

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

Виртуализация позволяет отлаживать драйверы и приложения в идеально воспроизводимых условиях, параллельно работать над разными фичами и начинать писать код еще до того, как готово физическое устройство. Особенно это актуально при разработке и тестировании embedded-решений, где часто требуется работа с периферией — например, I2C-устройствами: датчиками температуры, давления, влажности, EEPROM-памятью и другими компонентами.

Рассказ о самой полезной части Nix — управление пакетами из репозитория nixpkgs.

Я использовал и использую разные языки. В Rust есть прекрасный пакетный менеджер cargo и инсталлятор rustup, для JavaScript — npm. Мне также нравится conda в мире Python.

Мне всегда не хватало чего-то подобного для проектов на Си и C++. Пакетные менеджеры для этих языков часто оставляют желать лучшего. Даже если они работают, в их репозиториях может не быть нужных библиотек. Даже если вроде всё работает хорошо, может оказаться, что для работы бинарного кэширования нужно прилагать усилия, а когда это что-то вроде разных версий Qt — собирать всё на машине разработчика неприятно.

Я хотел, чтобы инструмент из коробки давал максимум без дополнительной настройки.

Поэтому я расскажу, как использовать Nix в качестве пакетного менеджера для Си и C++.

Сегодня Rust активно используется не только как язык для написания приложений, в том числе системных, но и как язык для написания библиотек, которые подключают к существующим проектам на C и C++. Это удобно: новую функциональность можно писать на Rust, но при этом не переписывать весь код на нём.

Крис Латтнер (Chris Lattner) — создатель CPU-компилятора LLVM и соавтор Swift — предложил новый язык программирования Mojo, спроектированный для одновременного программирования CPU, GPU и TPU (тензорные ядра, оптимизированные для матричного умножения, а это и есть инференс LLM), без всяких лишних библиотек типа CUDA, ROCm и XLA.

Mojo — это надмножество Python с производительностью С и потенциальная замена Rust. Код на нём легко переносится между различными GPU, при этом платформа Modular быстрее обновляется под новые модели GPU, чем сама Nvidia выпускает обновления для своего софта (новые attention kernels).

Простой и мощный язык для написания и деплоя LLM-приложений независимо от оборудования (AMD, Nvidia, Intel и проч.), с метапрограммированием во время компиляции и прочими штуками. Что-то вроде единой «LLVM для AI». Унифицированная программная платформа, которая запускается на любом железе. Это ещё и самый простой способ ускорить Python-приложение в 10−1000 раз, не переписывая его фрагменты на Rust или C++ (что по сути делают NumPy и PyTotch).

Некоторые уязвимости, связанные с повреждением памяти, невероятно сложны для эксплуатации. Они могут вызывать состояния гонки, приводить к сбоям системы и накладывать разные ограничения, которые усложняют жизнь исследователя. Работа с такими «хрупкими» багами требует значительно больше времени и усилий. CVE-2024-50264 в ядре Linux — как раз одна из таких сложных уязвимостей, которая получила премию Pwnie Award 2025 в категории «Лучшее повышение привилегий» (Best Privilege Escalation). В этой статье я представлю свой проект kernel-hack-drill и покажу, как он помог мне разработать прототип эксплойта для уязвимости CVE-2024-50264.

Перед вами - известное письмо Линуса Торвальдса, где он написал, что если бы единственная причина использовать С, а не С++, была в том, чтобы отпугивать программистов на С++ - это уже была бы весомая причина.

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

Линус Торвальдс в своём классическом стиле категорически высказался против предлагаемой поддержки режима big-endian для архитектуры RISC-V в ядре Linux. Всё началось с вопроса в рассылке о том, смогут ли патчи для RISC-V BE попасть в текущий цикл разработки ядра.