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

С весны на собесах стабильно спрашивают про Green Tea. И ответ, который я слышу в девяти случаях из десяти, звучит так: «ну, он на 40% быстрее». Дальше начинаешь уточнять — быстрее что? — и человек плывёт. Проценты там действительно есть.

Просто относятся они не к тому, о чём все думают.

Профайлер показывает write() и worker файлового логгера среди верхних стеков. Однако системный профайлер не знает, какая из тысяч строк вывода в лог породила нагрузку. Отключать логирование совсем — ужасное решение. Как же связать файловый ввод-вывод с конкретными строками вывода в лог, каналами и backend?

Я заменил std::deque на boost::circular_buffer в надежде получить прирост производительности. В реальности получил загрузку процессора в 25% вместо 2%.

Производство пожаловалось: модуль WB-MGE v.3 на ESP32 шьётся слишком долго — 42 секунды на устройство. Что начиналось как простое «склеить вызовы esptool в один», превратилось в копание в исходниках загрузчиков на Си и Расте, патч прошивальщика, разгон системной шины, физику NOR-флеша (туннелирование Фаулера–Нордхайма — теперь я знаю что это такое), и в итоге ускорение почти в четыре с половиной раза. И да, совы оказались совсем не тем, чем казались.

О гиперавтоматизации обычно говорят как о способе быстро сократить издержки и избавиться от рутины. Это подход к автоматизации, сочетающий в себе набор технологий, включая RPA и AI. На презентациях все выглядит просто: выбрали процесс, настроили робота c ИИ, получили экономический эффект.

На практике все оказывается сложнее — многие проекты заканчиваются успешным пилотом, но дальше автоматизация не масштабируется. Меня зовут Мирза, я руководитель проектов ROBIN компании SL Soft и за время работы я сопровождал десятки инициатив, в которых RPA использовалась вместе с ИИ, поэтому сегодня я поделюсь с вами самыми распространенными ошибками внедрения, из‑за которых гиперавтоматизация не оправдывает ожиданий.

Встречайте FancyArgumentParser

Парсинг аргументов командной строки в C++ нередко превращается в набор громоздких решений или самописных костылей. Я решил упростить эту задачу и написал FancyArgumentParser — небольшую библиотеку для обучения и пет-проектов. В статье рассказываю, как она устроена, чем удобна и как быстро подключить её к своему проекту.

Меня зовут Самир, мне 16 и я хотел бы поделиться с вами одним из моих текущих проектов: Veo (https://github.com/SamirShef/veolang). Veo это системный язык программирования. Я хочу использовать его для написания своих программ в будущем. А ещё я разрабатываю его потому что мне интересны комплияторы и потому что мне нечего делать.

Я больше года занимаюсь компиляторострением.

Всем привет! Давно не писал статей и вот наконец решил вернуться.

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

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

Меня зовут Анна Мелехова, я старший архитектор ПО в «Лаборатории Касперского». Вместе с командой занимаюсь разработкой микроядерной KasperskyOS.

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

В этой статье, основанной на моем докладе для OS DevConf 2025, разберем, почему механизмы харденинга могут эффективнее работать в микроядре, чем в монолите; как «закрутить гайки» при передаче данных из user space; и насколько отличаются защитные механизмы в микроядерной архитектуре и в монолитной.

Если список литературы по Go на лето уже прочитан, пора переходить от теории к живым кейсам. 23 июля собираемся в Москве и онлайн на встрече Go-сообщества от YADRO и Postgres Professional. Начинаем в 19:00 — подключайтесь к трансляции и слушайте тех, кто работает с Go каждый день.

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

И почему тогда Apple платит до двух миллионов долларов за одну найденную уязвимость и выстраивает многоуровневую аппаратную защиту — а айфоны всё равно взламывают по нажатию одной кнопки?

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

Перед нами — Data-Only атаки, где взлом превращается в программирование на «невидимом» процессоре. Процессоре, команды которого — лишь побочный эффект работы нашей собственной программы.

Но чтобы понять, как мы здесь оказались, придётся вернуться на двадцать лет назад.

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

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

$ rustup update stable

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

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

MIK32 Амур (К1948ВК018) — первый российский 32-битный микроконтроллер на ядре RISC-V от АО «Микрон». Для работы с ним разработчики предлагают связку VS Code + PlatformIO. Казалось бы, всё просто — но на практике сталкиваешься с множеством неочевидных шагов, которые нигде не собраны в одном месте. В этой статье я пошагово покажу, как развернуть полноценную среду разработки для MIK32 Амур на Windows.

Привет, Хабр! На связи Дмитрий, инженер по инфраструктурным решениям в компании РЕД СОФТ. Сегодня будем расширять парольные политики в РЕД АДМ — минимум теории, больше практики. Покажу, как подготовить инфраструктуру, создать и применить расширенную политику, а также расскажу, какие нюансы стоит учитывать при работе со схемой. Даже самый требовательный офицер безопасности будет вами гордиться.

В первой части мы загрузили своё ядро на настоящий телефон, вывели «Hello world» в UART и нарисовали квадратик на экране. Во второй — научили ядро управлять памятью и завели кучу.

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

В этой статье разберёмся, что такое capability и handle и при чём здесь seL4 и Zircon, запустим свой процесс-"калькулятор" на телефоне и поговорим с ним по IPC, а под конец напишем userspace-драйвер часов для устройства, про которое в ядре нет ни строчки.

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

Для управления четырьмя vpn-клиентами использовался полноценный многопользовательский веб-сервис на PHP с MySQL, который требовал отдельного сервера.

История о том, как я перебрал популярные панели управления WireGuard и написал свою.

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

Привет, Хабр! Меня зовут Александр, я работаю в IT с 2006 года, последние годы занимаюсь системным анализом и управлением командами аналитики.

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

Для кого-то T-Shaped — это специалист, который понимает систему шире своей основной области и умеет эффективно взаимодействовать со смежными ролями. Для кого-то — тот, кто должен «уметь всё понемногу». А иногда под этим термином вообще начинают подразумевать сотрудника, который фактически совмещает несколько ролей одновременно. Короче говоря, с T-Shaped все далеко не так однозначно.

Выбор языка программирования (ЯП) отражает стиль мышления разработчика. Однако если какой-то язык называют «популярным», это вовсе не значит, что он самый перспективный и единственно достойный глубокого изучения. Просто в данный момент он чаще на слуху по разным причинам. Это может быть следствием лёгкости освоения, востребованности в какой-то быстро растущей и специфической отрасли, ошибкой интерпретации статистических данных или просто хайпом. В этой статье вместе с разработчиками и исследователями компании «Криптонит» мы проследим динамику рейтингов ЯП, разберёмся, что скрывается за всплесками интереса к разным языкам, какие из них действительно востребованы и почему.

Для понимания общей картины рассмотрим подробнее, что говорят о популярности ЯП в источниках с разной методологией и оценим динамику.

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