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

Алгоритм сортировочной станции (Shunting Yard) был предложен Дейкстрой ещё в 1961 году и служит для преобразования математических выражений из привычной всем инфиксной записи (где операторы стоят между операндами, как в 1 + 2 * 3) в постфиксную (обратную польскую нотацию, 1 2 3 * +), удобную для дальнейшего вычисления. Однако есть один важный момент, который почти всегда упускается или замалчивается: алгоритм предполагает, что входное выражение уже синтаксически корректно.

Ни в Википедии, ни в большинстве обучающих статей вы не встретите слов о том, что выражения вроде + (1 2, 3 * 4 + ) или sin(+) должны вызывать ошибку. В лучшем случае они просто не вычисляются (что будет понятно лишь на этапе обработки в обратной польской записи), в худшем – дают бессмысленный результат. Алгоритм продолжает работать, даже если выражение изначально некорректно – и мало кто задумывается, почему это плохо.

Эта статья – попытка исправить эту несправедливую ситуацию, в которой мы не только реализуем алгоритм сортировочной станции «на максималках» с поддержкой констант, переменных, функций, унарных операторов, приоритетов и ассоциативности, но и добавим полноценную проверку корректности выражения по ходу разбора.

Odin — это универсальный язык для системного программирования, придуманный Биллом Холлом aka «gingerBill». Odin задумывался как современная альтернатива C, и в нём делается акцент на простоте, производительности и удобочитаемости, но при этом не упускается контроль над низкоуровневыми деталями.

На сайте об этом языке Odin охарактеризован как «ориентированный на данные», именно поэтому в нём присутствуют, например, структуры массивов (SOA) и неявная инициализация значения в ноль. Удивительно, что, несмотря на такие приоритеты, в языке есть динамические словари и массивы, встроенные в сам язык. Притом, что памятью всё-таки приходится управлять вручную, такие встроенные вещи встречаются нечасто.

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

Во вселенной распределённых систем существует древний цифровой организм — Wormhole, или, как его называют в инженерных кругах, Хранитель туннелей.

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

Он не говорит. Он доставляет.

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

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

Здравствуй, читатель. С моих прошлых статей про NVRAM прошло некоторое количество времени (за эти почти 10 лет мало что изменилось, и все эти форматы до сих пор с нами практически без модификаций), а моя работа на одну фруктовую компанию не позволяла мне писать статьи, тесты и посты без одобрения кучей непонятных людей, но теперь эта работа осталась в прошлом, а желание писать так и не пропало. 

Эта статья - практическая реализация этого желания, а поговорим мы в ней о формате Dell DVAR, и немного о декларативном языке для написания парсеров Kaitai Struct, на котором я недавно переписал парсеры всех известных UEFITool NE форматов NVRAM. 

Здравствуйте, уважаемые читатели!

В этой статье я хотел бы поделиться необычным и вдохновляющим проектом — реализацией арканоида в текстовом VGA-режиме, написанного полностью на Rust, без использования стандартной библиотеки и даже без аллокации памяти (#![no_std] + no_alloc).

Проект работает напрямую с VGA-памятью и PS/2 клавиатурой через порт 0x60, создавая абсолютно нативную игру в стиле 80-х, но с современным вниманием к качеству кода. И всё это — с участием милого талисмана Platinum-tan.

Книга «Rust. Профессиональное программирование» (Code Like a Pro in Rust, by Brenden Matthew) — авторское руководство по языку Rust, претендующее на то, чтобы быть пособием для разработчиков уровня джун и выше, стремящихся овладеть приемами, которые отличают уверенного разработчика от новичка.

Жил-был в норе под землей… разработчик группы разработки защитных решений безопасной платформы. Привет! Я Максим Жуков, занимаюсь безопасностью различных аспектов KasperskyOS. Расскажу про один из них, ELF-парсер.

Эта история не про то, как мы в «Лаборатории Касперского» сделали парсер с нуля. А про то, как я отправился в долгое исследовательское путешествие в поисках способа сделать наш существующий парсер безопаснее, что узнал о разных инструментах в пути и какую неожиданную помощь получил от Темного Владыки Мелькора.

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

Давненько я ничего не публиковал на Хабре — пора это исправлять.

В этот раз хочу поделиться темой, которая кажется простой, но на деле вызывает интерес у многих разработчиков и системных администраторов: как создать свою легковесную систему планирования задач на Python. Что-то вроде мини-аналога cron, но под свои задачи и со своими фишками.

Ведь часто бывает так: хочется, чтобы какие-то проверки или скрипты запускались в определённое время — например, в обеденный перерыв у сотрудников можно поставить автоматическую проверку всех машин на наличие вредоносного ПО. Или наоборот — распределить рутинные проверки так, чтобы они не мешали основной работе.

Вторая часть уже здесь.

В первой части мы:

• посмотрим, как работать с памятью и регистрами 8086

• узнаем, как написать простую программу на ассемблере прямо в отладчике

• изучим работу механизма прерываний и сделаем демонстрационный пример

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

Примеры в бинарном виде доступны по ссылке

На примерах попробую показать, почему enum в Rust это несколько больше, чем обычно принято считать. Рассмотрю расширенное использование enum в типовых ситуациях. Сразу забегая вперед скажу, что в рамках статьи я не затрагиваю паттерны и мэтчинг.

Первое, что приходит в голову, когда речь заходит об enum, — это идея: «А давайте заменим все константы на enum». :) Желание логичное, давайте на него посмотрим...

При разработке драйверов GPIO для нашей операционной системы реального времени "Нейтрино" исторически имеется одна неприятность — отсутствие общего дизайна для таких драйверов. Причин для этого несколько: они считались и считаются тривиальными, разрабатывают их разные организации и разработчики. Из-за этого каждый инженер нередко писал реализацию «под себя»: кто-то в виде сервиса, кто-то даже в виде статической библиотеки. Такой подход, хоть и кажется удобным на первых этапах, со временем приводит к фрагментации кода, усложнению поддержки и невозможности систематизировать накопленный опыт. Чтобы избежать этих проблем в будущем мы решили перейти на унифицированную подсистему управления GPIO устройствами и выработать подход, который будет считаться best practices в нашей ОС.

Доводилось ли вам раскупоривать системник с Linux, который не грузится ни в какую – даже  после того, как вы убедились в корректности настроек BIOS и в том, что никаких серьёзных аппаратных ошибок в машине нет?

Если да – то вам просто необходимо изучить chroot. Он станет для вас настоящей палочкой-выручалочкой.

Например, мне пару недель назад удалось таким методом восстановить устройство Nanopore GridION, после того, как мне совершенно не помог официальный метод переустановки через  .iso-файл образа. Поэтому я решил задокументировать проделанные шаги.

Этот метод я нащупал только после того, как Linux более десяти лет был моей рабочей лошадкой (спасибо, Мэтт !). Поэтому у меня есть основания полагать, что этот метод очень полезен и заслуживает вашего внимания. Надеюсь, этим постом мне удастся помочь тем, кому не доставало такого рассказа.

За всю свою работу инженером-программистом в области разработки встраиваемых систем, а это более 15 лет, мне ни разу не приходила в голову идея спросить у своего руководителя о том, что мне нужно сделать для того, чтобы перейти с одной категории на другую. Всё что я делал, это решал поставленные перед мной задачи разного характера. Интерес был именно в решении задач, а не в получении категорий. Категории как-то сами по себе назначались…

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

Однажды на работе техлид порекомендовал мне проштудировать книгу Understanding the Linux Kernel Бове и Чезати. В ней рассмотрена версия Linux 2.6, сильно не дотягивающая до более современной версии 6.0. Но в ней явно ещё много ценной информации. Книга толстая, поэтому на её изучение мне потребовалось немало времени. Занимаясь по ней, я решил настроить такую среду разработки, в которой я мог бы просматривать и изменять новейшую версию ядра Linux — чтобы было ещё интереснее.

Есть и другие статьи, в которых рассказано, как собрать ядро Linux. Но в этой статье я немного иначе организую и подаю информацию.

Ну блин короче :-)

Знаете ли вы, куда уходит время и ресурсы при сборке проектов на Java? Сейчас покажем и расскажем, как сберечь время, нервы и кофе.

Мы ускорили javac вдвое и теперь можно экономить на сборке.

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

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

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

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

$ rustup update stable

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

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

В первой части статьи мы рассмотрели общую семантику применения функции в различных языках программирования и реализацию императивного вызова функции в машинном коде в стековом и бесстековом вариантах. Теперь мы рассмотрим теорию и практику реализации императивного вызова функции в модели продолжений (continuations): что такое продолжения, зачем нужны явные и неявные продолжения, как при помощи продолжений реализовать различные используемые в языках программирования управляющие конструкции.

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

Сергей Каличев, старший разработчик, Angie Software

Однажды, давным-давно, я наткнулся на одну хорошую статью по разработке переносимого кода и решил её перевести. Когда же это было... ё-моё, в 2008 году, 17 лет назад! Обалдеть, как время летит. Статья называлась "Fighting the Lemmings", автор Martin Husemann. Выложил перевод на LOR. С тех пор много воды утекло и, когда я попытался поискать статью в Интернете, то обнаружил, что ни оригинальной статьи, ни перевода, найти практически невозможно. Перевод ещё сохранился в глубоких закромах OpenNet, а оригинал только в архиве Интернета. Ссылки на PDF-ки тоже протухли и больше не работают. Обидно, это ведь такая нетленка для системщиков. Понятно, что переносимость уже сто раз пережёвана в других статьях и книгах, но тут всё было сконцентрировано и написано доходчиво. При этом актуальность до сих пор не потеряна. Ну а что, собственно, кардинально поменялось в разработке переносимого кода на C с тех пор? Если не обращать внимание на упоминания некоторых архитектур и ОС, которые сейчас, да и во времена перевода, звучат, как придания старины глубокой, то в остальном, обо всех особенностях разработки переносимого кода, описанных в статье, надо помнить и сегодня. Выкладываю текст, как он есть, без каких-либо современных правок.

Для тех, кому удобнее читать в PDF, вот ссылки:

PDF оригинальной статьи

PDF перевода

А теперь сама статья.