Rust *

Всем привет!

Меня зовут Артур Валиев. Недавно я уже рассказывал на Хабре о том, как мы собирали собственный RustDesk Pro при помощи патчей и кастомных сборок.

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

Начать стоит немного издалека.

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

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

Прошли годы, и теперь мы наконец сделали именно такой инструмент.

Так появился EvertyDesk Lite.

Это полностью нативный клиент удалённого доступа на Rust и egui. Один бинарник. Без браузера внутри. Без Electron, flutter. Без десятков зависимостей. Без необходимости тянуть половину интернета через репозитории.

Причём мы специально проектировали его так, чтобы он запускался даже там, где графический стек уже практически сдался. Astra Linux? РЕД ОС? Пожалуйста, старый марсианский корабль? Работает. Старая виртуалка без нормального OpenGL? Тоже запускается.

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

StillCore — лёгкое приложение для отслеживания энергопотребления, частоты, нагрузки, температуры и состояния батареи из строки меню macOS. Это анонс и небольшая история о том, как я его писал.

Недавно я решил завести собственный блог. Сначала посмотрел в сторону SSG, но они показались мне не слишком удобными для того сценария, который я хотел получить. Затем попробовал несколько CMS, однако быстро упёрся в другую проблему: мой сервер оказался слишком слабым для большинства современных решений.

В итоге ни одно из готовых решений так и не смогло закрыть все мои требования одновременно. Так и появилась идея сделать небольшую файловую CMS на Rust, которая не требует базы данных, не потребляет много памяти и при этом остаётся достаточно гибкой для повседневного использования.

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

Почитал у известного чела о пост-условиях (“посткондишнс”) на свифте - и знаете, раст все равно лучше. Тупо приятнее язык даже для создания торговой биржи со своей мудреной бизнес-логикой - тикерами, логикой стопов и лимитных ордеров, многопоточностью, паттерн матчингом, децентрализованной сетью, графиками, распределениями парето, гаусса, стьюдента. Не трогая деревативов и разницу форвард/фьючерс, есть “аск” и “бид”, три вида ордеров, тикеры, взлеты и падения, вискарь-тревоги-роботы - короче, что нужно сделаем (кроме роботов), а для всего остального мастер кард (или МИР, а для европейцев “е-ц” карты).

Простейшая реализаций биржы (тикера) складывается всего из двух куч (binary heap) или двух стаканов: “аск” (продажа) и “бид” (покупка), и следствием их пересечения является сделка. Кто-либо создает ордер на покупку, указывая количество, и ордер исполняется мгновенно по верхней цене в стакане. Если хочется купить дешевле, создается лимитный ордер с указанием цены, а сделка ожидает продавца, согласного продать вам по указанной цене. С точки зрения реализации нет особой разницы между “asap” и лимитными ордерами. Чуть сложнее стопы.

Когда я впервые увидел backtrace паники в Rust, я решил, что это просто аналог исключения. Вызвал panic!, стек раскрутился, деструкторы вызвались, поток умер. Примерно как throw в C++ или raise в Python. Потом я попытался передать панику через FFI-границу, и программа молча упала без backtrace. Потом обнаружил, что catch_unwind перестаёт работать, если в Cargo.toml поменять panic = "unwind" на panic = "abort". Потом выяснил, что двойная паника (когда деструктор паникует во время раскрутки) убивает процесс безусловно, и это не баг, а так задумано.

Оказалось, что за простым panic!("oops") стоит сложная система из сменных runtime-ов, платформозависимой раскрутки стека и кучи граничных случаев...

Как организовать шифрование на уровне протокола? На самом деле тема непростая и пожалуй (имхо) это как раз та самая тема, где прийти к компромиссу почти никогда не получается. Разве что просто не передавать чувствительные данные вовсе.

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

io_uring продавали как убийцу epoll. На деле на HTTP keep-alive разница 0-15%, иногда не в его пользу. Но на NVMe с queue depth 128 - в 3 раза быстрее. Честный разбор с бенчмарками, реальными граблями (SQPOLL, cancel race, partial recv) и почему Google отключил io_uring в ChromeOS.

Эта статья — не руководство по написанию ОС и не туториал. Это срез архитектуры работающего ядра, которое прошло путь от вечных Page Faults и Segmentation Faults (в ring 3) до системы с 95 системными вызовами, сетевым стеком, COW и MLFQ-планировщиком. Все исходники открыты под GPLv3.

С момента последней (и вроде единственной) статьи о brec прошло какое-то время, и мне кажется, что будет полезно лишний раз напомнить о проекте. Даже неожиданно для меня самого он продолжает развиваться. Пусть я пока не могу похвастаться значимым интересом со стороны сообщества, но в паре локальных проектов он уже появился. Да, скорее как эксперимент. Тем даже лучше: можно провести, что называется, полевые испытания.

Я пишу FFI-код на Rust уже несколько лет и за это время понял одну неприятную вещь: на FFI-границе всё, что может сломаться, ломается молча. Компилятор не предупреждает, тесты проходят, а данные на C-стороне оказываются просто мусором. Или, что хуже, оказываются почти правильными, первые три поля совпадают, а четвёртое сдвинуто на два байта, и ошибка всплывает через недели.

Большинство этих проблем связано с двумя вещами: как структура лежит в памяти (layout) и как данные передаются при вызове функции (ABI). В чистом Rust-коде об этом можно не думать, компилятор всё решает за вас. Но на границе с C эти детали становятся вашей ответственностью.

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

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

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

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

Двусвязный список на Rust. Это вообще возможно? Ну… да. С некоторыми оговорками. Что за оговорки, узнаем из четвёртой главы.

Срочно переписывайте свои устаревшие bloom фильтры на мой богоподобный lz77-фильтр. Совершенно бесплатно! Спасибо великому нанабанана за обложку!

Как я улучшил универсальный код Элиаса 1975 года, заменив длину на popcount — и получил 36% экономии на метаданных. С бенчмарками! Картинка на обложке кринжовая, но тут вроде так принято? 😅

Полгода я давал LLM писать unsafe Rust в боевых проектах и разбирал каждый блок под miri и санитайзерами. Категории ошибок, которые модели делают стабильно: aliasing, провенанс, layout в alloc/dealloc, забытый ManuallyDrop, гонки в FFI-колбэках, ручные Send/Sync, uninit-память, Pin. Каждая категория идёт с минимальным примером и фиксом.

Календарь, задачи, заметки, почта. Мы используем десятки инструментов, но они не умеют жить вместе. Данные размазаны по сервисам. Команда в Битрикс24, семья в WhatsApp, клуб в Google Calendar. Везде свой интерфейс, свои правила, своя изоляция.

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

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

Можно ли написать на Rust устойчивый список? Думаю, вы уже догадались, что да. А как — узнаете из третьей части перевода Too Many Linked Lists.

Вчера автор побывал на прекрасной конференции Backend Talks 360 от компании Yandex и не в силах спокойно спать, не ответив конструктивной критикой на доклад Ильи Абрамова о работе Яндекс.Диска, автор принялся писать очередной «В интернете кто‑то не прав». Что из этого вышло — добро пожаловать под кат.

Полгода использовал Claude, GPT и Cursor как полноценного второго разработчика на Rust в проде. Собрал семь категорий ошибок, которые модели стабильно делают и которые проходят cargo build, cargo test, иногда cargo clippy и при этом являются UB или скрытыми архитектурными ловушками. Lifetime laundering, std::sync::Mutex через .await, Drop у транзакций, unaligned read, async cancellation, orphan rule и массивы на стеке. Разбираю, почему именно Rust ломает LLM и что с этим делать.

Под катом рассказываю про 3a формат для ASCII анимаций, тулинг для работы с ним и коллекцию opensource ASCII артов для ваших cli/tui приложений, игр и постов в r/unixporn.