Rust *

Как устроен SFU изнутри: Publisher, Subscriber, комната-маршрутизатор и никакого перекодирования. Дневник разработки на Rust.

0.86.0-beta.1 - это большой бета-цикл: агент получил единый дом в интерфейсе, у Yttri появился первый плагин (интеграция с Obsidian) и сама платформа плагинов, на Mac с Apple Silicon заработал альтернативный локальный движок MLX, а голосовой ввод и запись прошли через плотную серию фиксов стабильности. Ниже - по разделам, что из этого видно пользователю.

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

Обзор асинхронности WASM с выходом WASI 0.3

WASM уже вышел за пределы браузеров и выглядит как перспективная технология для серверной разработки. Однако в вопросе серверного компьюта рано или поздно встает вопрос асинхронной обработки I/O-bound нагрузки. В данной статье попробуем разобраться, что как отвечает экосистема WASM на данный вызов. Статья особенно актуальна в свете того, что совсем недавно официально представлен WASI 0.3

Недавно попалось на глаза поворотное устройство для видеокамер PTZ 3050DZ, которое заинтересовало меня невысокой стоимостью и приличным заявленным весом поворачиваемой видеокамеры в 10 килограмм. Подумалось, что оно вполне может подойти для использования с небольшими спутниковыми антеннами. По ходу дела пришлось смастерить для него еще и дистанционное управление с применением модулей LoRa. Жмите кнопку ниже, чтоб узнать подробности.

Я написал с нуля инструмент для изоляции Linux‑приложений на Rust — Hajiz. Это учебный проект по системной безопасности, который вырос во что‑то, чем можно реально пользоваться. Хочу рассказать, как он устроен изнутри: почему порядок применения механизмов изоляции критичен, как работает eBPF‑аудит с privilege separation, и зачем всё это когда есть Docker.

→ github.com/hag19/hajiz

AngaraBase — OLTP/HTAP СУБД, написанная с нуля на Rust. Совместима с PostgreSQL по протоколу — работает с psql, JDBC, psycopg2 и стандартными драйверами. UNDO-log MVCC без VACUUM, векторизованный исполнитель с SIMD-батчами — транзакции и аналитика под одним SQL и одним снапшотом, без ETL и второго хранилища. Fail-closed контракты ресурсов, USDT-пробы без рестарта, EXPLAIN с разбивкой по фазам исполнения. Dev preview доступен на angarabase.dev.

Если совсем коротко: я написал свой VPN на Rust — побайтово-корректный TLS 1.3 с заёмом чужого сертификата, гибридное постквантовое рукопожатие, пять режимов маскировки и под 700 Мбит/с на скачивание. Ниже — как это устроено изнутри и десяток шишек, на которых я учился. Но начать хочется издалека.

Как дать админу доступ к виртуальным машинам на удалённом хосте без агента внутри гостевой ОС — на примере VirtualBox и Hyper-V. Один RDP-движок на оба гипервизора, три бага VirtualBox по дороге и таймаут, который переписал всю архитектуру.

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

На практике же стоит копнуть глубже, и оказывается, что каналов в экосистеме Rust целый зоопарк: std::sync::mpsc, crossbeam-channel, tokio::sync, flume, async-channel, kanal и ещё несколько менее известных. Они отличаются моделью, поддержкой асинхронности, скоростью и кучей мелких деталей, о которые легко споткнуться. В этой статье разберёмся, какие каналы бывают, чем они отличаются и какой брать под конкретную задачу.

Я хотел одну простую вещь: чтобы на втором мониторе тихо играло lo-fi, а за виджетами крутилась уютная анимированная сцена. Готового решения не нашлось — зато нашёлся чужой MIT-проект, у которого я в итоге выкинул главный модуль и собрал из остатков совсем другой продукт. Это девлог о том, что я удалил, что добавил и на каких граблях потанцевал.

Под задачу подходящих инструментов хватало, но каждый закрывал только часть. Wallpaper Engine — живые обои, но без радио. Lofi.co — музыка в браузере, но не обои рабочего стола. Noisli — эмбиент, но без всего остального. Покупать три подписки ради фона под код было жалко, поэтому я полез на GitHub смотреть, что можно собрать самому.

Нашёл meel-hd/lofi-engine под MIT — аккуратный Tauri-проект со встроенным генеративным движком, который синтезировал lo-fi прямо в браузерном рантайме. Идея красивая, но мне быстро стало понятно, что я хочу совсем другого продукта. Так появился форк, который я в итоге назвал LoFiTyan.

В феврале я публиковал первую статью про Yttri: что это за приложение, зачем я его делаю и почему мне не хватало Obsidian, Notion, почтового клиента, таск-трекера и AI-чата по отдельности.

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

С тех пор Yttri сильно изменился. Это уже не просто «единый интерфейс для всего», а более взрослая local-first среда: с открытыми markdown-данными, локальными моделями, агентом, почтой, задачами, заметками, финансами, записями встреч и нормальной доставкой тяжёлых AI-компонентов.

Сейчас я расширяю бета-тестирование и хочу позвать новых пользователей.

Каждый раз, когда вы пишете .await, происходит не магия, а вполне конкретный механизм: Future, Waker и опрос состояния. Чтобы увидеть это своими глазами, я написал собственный async-рантайм на Rust с нуля - с executor, reactor на epoll и рабочим TCP-эхо-сервером. По пути разобрался, как именно tokio будит ваши задачи, и нашёл баг, который тихо висел у меня в проде. Внутри - весь код целиком и объяснение без отсылок к чёрным ящикам.

GPUI является быстрым и производительным UI фреймворком на Rust c GPU ускорением от команды разработчиков, создавших редактор кода Zed, который как раз его использует для UI части. Данный фреймворк вышел относительно недавно, поэтому его API немного нестабильный, во многих источниках, на которые Вы могли наткнуться на просторах Интернета, включая примеры в официальном репозитории, написаны на более старой версии, из-за чего изучать данный фреймворк становится ещё сложнее. Он поддерживает такие платформы как macOS, Windows, Linux и FreeBSD. В данной работе применяется версия 0.2.2.

Писал парсер строго под свой проект, а получился быстрый декларативный движок для парсинга текстовых форматов. Как?

Я публиковал перевод Too Many Linked Lists по мере готовности, поэтому каждая отдельная глава представлена отдельной статьёй на Хабре.

Книгу в таком виде читать неудобно, так как приходиться искать статьи в ленте автора. Поэтому я собрал Оглавление в одном месте, а именно здесь. Теперь не заблудитесь!

Вот мы и добрались до конца. Перед вами последняя, седьмая глава книги Learn Rust With Entirely Too Many Linked Lists.

И немного дурацких списков. Как вам список, размещённый не в куче, а на стеке? Невозможно? Ещё как возможно! Читаем!

В Tauri фронтенд дёргает Rust-команды через invoke("get_user", { userId: 42 }) — строка, объект, никакой проверки типов. После очередного вечера, убитого на расхождение snake_case и camelCase, я написал генератор, который превращает Rust-команды и serde-типы в готовые TypeScript-файлы — без аннотаций и правок в коде приложения.

Под катом — почему генерировать надо не то, что написано в коде, а то, что serde реально шлёт по проводу; как я выпустил три релиза за один день, воюя с макросами; и при чём тут юникод-эскейпы в TOML на Windows.

Ладно, забудьте всё, что было раньше. Весь этот детский лепет про ссылки и указатели.

Настало время писать настоящий продуктовый код. Посмотрим, как он выглядит на языке Rust.

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

Новая статья из цикла про нашу OLTP-СУБД на Rust.

С самого начала мы выбрали MVCC на UNDO-логе вместо версионирования в heap, как в PostgreSQL. И годами повторяли свой же лозунг: «нет VACUUM, нет bloat». Оказалось, это правда ровно наполовину.

Heap и правда не пухнет от истории версий. Но bloat никуда не делся: он переехал в индексы, в мёртвые слоты и в сам UNDO-лог. А сборка мусора из одного механизма незаметно превратилась в пять, и мы только сводим их к единому координатору.

В статье разобрали без прикрас обе стороны. Что UNDO-модель дала: стабильный TID (UPDATE, который не трогает индексы), rollback пропорционально размеру транзакции, аналитику, не дорожающую от write-нагрузки, и AS OF как «машину времени» почти даром. И чем за это платим: главная эксплуатационная цена это долгоживущий снапшот, который молча останавливает очистку для всех.

Вопрос к тем, кто эксплуатировал MVCC-базы под нагрузкой: что меньшее зло — блокировать GC ради долгих транзакций или отдавать «snapshot too old»? Любопытно ваше мнение в комментариях.