В Open Source под лицензией Apache License 2.0 выложен проект Grok Build — это терминальный агент для разработки программного обеспечения на основе искусственного интеллекта от SpaceXAI.
Решение работает в виде полноэкранного интерфейса пользователя, который понимает код, редактирует файлы, выполняет команды оболочки, осуществляет поиск в интернете и управляет длительными задачами — в интерактивном режиме, в безголовом режиме для написания скриптов/CI или встроен в редакторы через протокол Agent Client Protocol (ACP).
Представлен лёгкий браузер для парсинга данных и ИИ‑агентов — открытый Obscura на Rust работает в разы быстрее подобных проектов и занимает меньше ресурсов, чем Сhrome или Firefox:
без графического интерфейса — максимальная автоматизация;
Stealth Mode, который скрывает признаки ИИ‑агентов. Так сайты не будут распознавать устройство как бота;
использует лишь 30 МБ оперативной памяти;
сам браузер весит около 70 МБ;
грузит страницы за 85 мс;
после запуска браузер готов к работе практически сразу без дополнительных настроек.
18 июня в 16:00 (Мск) состоится бесплатный вебинар «Rust: зачем выбирать этот язык в 2026 году?». Разберем, как Rust устраняет проблемы безопасности памяти и data races, сохраняя производительность уровня C++. Также развеем мифы про обучение Rust в 2026 году и обсудим гибридный подход интеграции с C++ через C-ABI.
На вебинаре:
✔️ Rust в 2026: цифры, тренды, кейсы
✔️ Проблемы C/C++ (use-after-free, data races) и как Rust их устраняет на уровне компиляции
✔️ Система владения и заимствования: примеры кода
✔️ Производительность: Rust vs C++ (бенчмарки)
✔️ Инструментарий: Cargo vs CMake
✔️ Гибридный подход: интеграция Rust с C++ через C-ABI
✔️ Кривая обучения в 2026 году: мифы и реальность
Предварительная подготовка:
Базовое понимание работы с памятью в C/C++ и общее представление о компиляции. Знание синтаксиса Rust не требуется.
📆 Когда: 18 июня, 16:00 — 17:00 (Мск)
👨🎓 Спикер: Самсонов Максим, эксперт в области разработки ПО (C/C++, Python, Rust, TypeScript, Java, JavaScript, R)
Microsoft представила порт набора утилит Coreutils для платформы Windows. В состав входит несколько десятков утилит, включая sort, cat, chmod, chown, cp, find, sleep, sort, tee, echo, uptime и ls. Инструментарий позволяет напрямую использовать в Windows типовые утилиты, доступные в Linux и macOS, без использования прослойки WSL. Целью проекта заявлено упрощение перехода между Unix‑подобными системами, WSL, контейнерами и Windows, и предоставление единого набора команд, флагов и методов, позволяющих переносить существующие скрипты из других систем без переписывания. Код написан на Rust и PwerShell, и распространяется под лицензией MIT.
Реализация основана на коде проекта uutils (Rust Coreutils), развивающего вариант GNU Coreutils на языке Rust, а также реализациях утилит find и grep на Rust. Утилиты собраны в виде одного универсального исполняемого файла "C:\Program Files\coreutils\coreutils.exe", отдельные команды к которому привязаны при помощи жёстких ссылок в NTFS.
Из‑за конфликта с имеющимися штатными утилитами Windows или привязки к специфичным возможностям из поставки исключены утилиты dd, dir, dircolors, shred, sync, uname, expand, kill, more, paste, timeout и whoami. Из состава также исключены утилиты, завязанные на не поддерживаемые в Windows концепции POSIX: chcon, chgrp, chmod, chown, chroot, groups, hostid, id, install, logname, mkfifo, mknod, nice, nohup, pathchk, pinky, runcon, stdbuf, stty, tty, users, who.
Из ограничений и особенностей отмечается необходимость использовать NUL вместо /dev/null, отсутствие поддержки сигналов (SIGHUP, SIGPIPE, SIGUSR), возможность создания символических ссылок только после включения режима для разработчика, недоступность некоторых операций с правами доступа. При работе с каталогами принимаются как пути с символом "/", так и c "\".
Rust Coreutils 0.9.0 вышел с важным обновлением: закрыли 44 уязвимости, но форма
льная совместимость с GNU Coreutils просела до 90,58%.
Звучит как откат, но причина в другом. Тестовый набор обновили до GNU Coreutils 9.11, туда добавили 25 новых проверок. После этого uutils прошёл 625 тестов, а 56 завалил. В прошлой версии было 630 успешных и 21 неуспешный тест, отсюда падение с 94,74%.
После аудита Zellic исправили 44 уязвимости. Много проблем было связано с расхождением поведения относительно GNU Coreutils и гонками файловой системы. Типичный сценарий: программа проверяет файл, а между проверкой и действием его успевают заменить на симлинк.
Для обычного запуска это неприятно. Для cp, chmod или mv от root это уже критично: можно добиться копирования, изменения прав или перезаписи чужого файла. Для защиты усилили безопасное копирование через uucore::safe_copy.
- для ln, dd, mktemp, tty добавили сборку под WebAssembly/WASI
Хороший релиз именно для системного Rust. Здесь видно, что переписать coreutils на Rust - это не только «убрать C ради безопасности». Нужно годами догонять поведение GNU, ловить тонкие файловые гонки, вычищать unsafe и сохранять производительность на низком уровне.
ASMLings - это набор из ~32 коротких упражнений на ассемблере Intel 8086, выстроенных по возрастанию сложности: от mov ax, 0x1337 до 32-битного сложения через carry flag, циклов, подпрограмм, работы с памятью и стеком.
Полный русскоязычный гайд по asmlings - интерактивной песочнице для изучения ассемблера Intel 8086, в которой 16-битный x86-эмулятор написан на Rust.
Внутри: что это, как устроено под капотом, как установить, как читать и решать упражнения, разборы реальных задач из репозитория, готовые примеры в examples/ и шпаргалки.
Разбор 100+ вопросов с собеседований Rust Полезный реподля подготовки к собеседованиям
Rust Interview Questions - это подборка вопросов, ответов и практических задач по Rust для тех, кто готовится к техническому интервью или хочет проверить, насколько хорошо понимает язык.
Внутри есть материалы по ключевым темам Rust:
ownership и move-семантика
borrowing и ссылки
lifetimes
traits и generics
Option и Result
обработка ошибок
память и безопасность
практические задачи с кодом
ответы и разборы
Rust нельзя нормально выучить только по синтаксису. Нужно понимать, почему borrow checker ругается, как работает владение, где появляются lifetime-ограничения и чем Rust отличается от языков с GC.
Этот репозиторий как раз про это: короткие вопросы, практические проверки и постепенное прокачивание Rust-мышления.
Подойдёт начинающим, которые уже знают базу, и разработчикам, которые хотят освежить Rust перед интервью.
✔️ Отец русской математики, без которого не было бы современного ML: 205 лет Пафнутию Чебышеву
16 мая 1821 года в селе Окатово Калужской губернии родился Пафнутий Львович Чебышев. Человек, без работ которого современный data science выглядел бы совсем иначе: ни тебе закона больших чисел в привычной форме, ни оценок отклонений, ни нормальной теории приближений. Чебышев основал петербургскую математическую школу и почти 35 лет вёл кафедру математики в Санкт-Петербургском университете. Через его руки прошли Ляпунов, Марков и Стеклов, то есть люди, чьи имена сегодня встречаются в любой книге по статистике и теории вероятностей.
Главное, чем он остался в математике: многочлены Чебышева, неравенство Чебышева, результаты по распределению простых чисел и фундамент теории приближений. Если кто-то когда-то открывал учебник по ML, он сталкивался с этим неравенством в первой же главе про концентрацию меры. Многочлены Чебышева до сих пор используют в численных методах, фильтрах и аппроксимациях, на которых построены реальные инженерные системы.
Теперь обещанная история. Чебышев с детства хромал на одну ногу из-за врождённого дефекта, обычные детские игры были для него почти недоступны, и мать делала ставку на учёбу. Именно эта хромота, по воспоминаниям современников, и подтолкнула его всю жизнь возиться с механизмами: он хотел понять, как можно превратить вращательное движение в прямолинейное, чтобы шаги людей и работа машин были ровными. В итоге он построил больше 40 механических устройств, включая знаменитую стопоходящую машину, которая на Всемирной выставке в Париже в 1878 году ходила как настоящее живое существо. Это был один из первых в истории шагающих механизмов, фактически прадед современных шагающих роботов.
Ещё один штрих: Чебышев почти всю свою преподавательскую зарплату тратил на инструменты и модели для собственной мастерской, а женат так и не был, говорил, что наука для него важнее. При этом в Европе его называли просто «русский Эйлер», а Французская академия наук избрала его иностранным членом ещё при жизни.
t.me/rust_code - пишу про вайбкодинг, Rust, тестирую модели и делюсь с вами подписывайтесь!
С версии 1.0 многое изменилось, но история языка всё ещё пишется.
От первого стабильного релиза до сегодняшнего дня Rust вырос в топовые язык, сформированный, аккуратным дизайном и крутым сообществом, которое постоянно поднимает планку качества в разработке ПО.
AI-агенты уже переписывают не пет-проекты, а инфраструктуру уровня Bun
История с Bun выглядит как новый уровень вайбкодинга: не лендинг, не CRUD и не маленький сервис, а почти миллион строк системного кода.
Bun изначально был написан на Zig. После покупки Anthropic проект стал ещё важнее: на нём завязана инфраструктура Claude Code, поэтому любые проблемы runtime напрямую бьют по продукту.
И вот Джарред Самнер начал эксперимент с переносом Bun на Rust при помощи Claude. Сначала это звучало как черновой ресёрч, который легко могут выбросить.
Но через несколько дней Rust-ветка уже проходила около 99.8% тестов на Linux x64 glibc, а в обсуждениях всплыл масштаб порядка 960 тысяч строк портированного кода.
AI-агенты выглядят как инструмент для радикальных миграций: язык, runtime, архитектура, огромная кодовая база.
Да, качество такого порта ещё будут долго разбирать. Да, миллион строк от агента - это не автоматически production-ready. Но сам факт уже меняет планку.
Раньше переписывание большого проекта на другой язык было историей на месяцы или годы.
Теперь это может начинаться как эксперимент на неделю.
Rust Roadmap 2026 на русском: от нуля до production-кода
Недавно я стал фанатом Rust, к чему и вас призываю)
Если давно хотели нормально зайти в Rust, а не прыгать между случайными статьями, вот хороший маршрут: полный roadmap на русском, бесплатный курс для начинающих и большая подборка полезных ресурсов.
Что внутри:
базовый синтаксис и первые программы
ownership, borrowing и lifetimes
Option, Result, traits и generics
обработка ошибок и тестирование
std, smart pointers и многопоточность
async/await и Tokio
macros, unsafe и FFI
web, CLI, embedded, WASM, gamedev и ML
мини-проекты на каждом этапе
Главная ценность roadmap в том, что он ведёт по Rust постепенно: сначала база, потом ключевая модель памяти, затем практические направления и реальные проекты.
Rust сложный не потому, что «невозможный», а потому что его нельзя учить хаотично. Здесь как раз есть нормальная траектория: от первых строк кода до уверенной разработки.
Сохраняйте себе и отправляйте тем, кто всё ещё боится borrow checker.
Rust + LLM: новая и сильная “ОПГ” против C++ и его друзей…
Есть такая штука с Borrow Checker - он ненавидит людей. Не потому, что он плохой, а потому, что требует держать в голове графы данных всего приложения всё время, пока пишешь. Люди устают, раздражаются, и в итоге - unsafe, чувство стыда перед собой и коллегами, и понеслась. А LLM на это просто… скажем, кхм, “не важно”. Ну, надо так надо. LLM итерирует. И самое забавное - ей можно запретить unsafe прямо в промпте, и она не будет искать обходные пути(ну, может, разок другой - Opus попробует, но это ловится простым поиском по файлам, даже PVS-Studio не нужен, хотя с ним было бы фееричнее). Скорее всего, LLM просто найдёт решение в рамках safe Rust. И это круто.
Про Python и JS - там ведь основная проблема не скорость даже(и синтаксически значимые пробелы у некоторых), а то, что деплоится не программа, а среда. Интерпретатор, зависимости, версии, “а на проде другой питон”… Сейчас с линковщиком от Zig можно прямо из Windows собрать бинарник под Linux - статически, без танцев(привет musl!), одним пинком. И это не какой-то хак, это просто работает. Получаешь один файл, который либо запустится, либо нет - без сюрпризов в середине.
C++ тут проигрывает не потому, что он сложный или плохой - он интересный, мощный, с огромной историей и экосистемой. Но именно эта мощность становится проблемой когда код - генерирует LLM(можно выстрелить себе в ногу из гранатомёта, и, самое страшное - не заметить этого). Модель получает слишком много способов сделать что-то, и часть из них - UB. Rust убивает целый класс таких подходов к реализации на уровне компилятора. Это не договорённость и не линтер - это просто не скомпилируется.
Мне кажется, уникальность этой связки тут в том, что задачи разделились очень чисто: LLM думает про логику, компилятор думает про корректность. И они не мешают друг другу. В C++ - см. выше. Именно то, что делает Rust тяжёлым для людей(кроме евангелистов и стримеров), делает его почти идеальным для этой связки.
Ну и если кто был травмирован неудачным опытом с “вайб-кодингом”, и сложилось впечатление, что вся эта пляска с LLM, это не серьёзно - попробуйте отложить китайщину(MiniMax, GLM, DeepSeek...), взять фронтир-модель типа “OpenAI Codex GPT-5.5 на XtraHigh” - и дать ей хотелку в виде описания какого-нибудь серверного приложения на Rust, и просто посмотреть что будет через 15-20 минут. Забейте на клоунов со “змейкой” и прочей мелочёвкой из бенчмарков на ютубе, попробуйте реальную задачку(многохопывый релей между серверами со своим протоколом КВН например и клиентами для Win/Linux). Оно сделает. Быстро. Качественно. Это довольно странное ощущение, честно говоря, видеть такое…
Просто мысли вслух, хотелось поделиться)
-s. TekMetrics certified “Master C programmer”, July 1999
Я давний пользователь Geeknote - это cli для Evernote. Несколько лет назад проект застрял на втором Питоне - и никто не хотел его портировать на третий. Я ждал что кто-то займётся этим - но пришлось самому - так что я форкнул, починил, и даже связался с Виталием Роденко - одним из создателей Geeknote и администратора на PyPI, чтобы получить право туда пушить. За десяток лет я видел как Geeknote переходил из одни руки в другие - и как он забрасывался, и через несколько лет находился новый мантейнер. Было забавно осознать, что теперь и я стал мантейнером программного продукта, который всегда установлен на все мои машины.
Как и большинство из нас, я стал пробовать LLM - как замену поиску, для анализа кодов, советов, и вот наконец - несколько проектов - даже не читая кода - только давая команды и тестируя результат. Известная шутка - переписать на Rust. Почему бы у нет - Geeknote не велик - около пяти тысяч строк на Питоне, что я и попробовал - через Codex gpt-5.5. Несколько десятков итераций, "добавь это", "добавь то", "пропали теги", "пропала анимация" - и за несколько часов я получил рабочий Geeknote на Rust, назвал его reeknote.
Результат: быстрее работает, раза в два. Теперь буду им пользоваться.
P.S.: CLI хороши для перфоманса, SSH, быстрее разработка без GUI, а ещё похоже и для LLM - можно попросить сохранить ответ в Evernote. Как и прочие интеграции, в том числе в скриптах.
Это не туториал, а карта‑шпаргалка, чтобы не потеряться среди десятка библиотек и быстро понять, куда копать под свою задачу.
Перед выбором любого фреймворка — откройте areweguiyet.com. Там видно зрелость, лицензию, платформы и число скачиваний. Лучшая страховка от «библиотека умерла через месяц».
Чтобы не путаться в терминах, стоит уточинить, в чем разница архитектурных подходов.
Immediate Mode (пересобирается каждый кадр). Суть: «Опиши, что должно быть на экране прямо сейчас». Не «создай кнопку и запомни её», а линейная пересборка каждый кадр: «если сейчас здесь нажали — сделай действие, и в любом случае нарисуй кнопку вот здесь».
— egui, Ply, Rust bindings dear imgui
Retained Mode (дерево виджетов в памяти). Суть: «Измени то, что уже есть». Один раз описывается структуру UI (создал кнопку, положил в layout), а потом меняются её свойства: текст, цвет, видимость. Кнопка «живёт» в памяти как объект.
— GTK и FLTK.
Reactive (реактивный режим). Суть: «UI — это функция от состояния». UI описывается как отображение некоторого состояния. Когда состояние меняется, фреймворк сам пересчитывает, что именно в UI нужно обновить.
Hybrid Mode (декларативный API + оптимизированный retained‑рендеринг)
— GPUI(Zed)
Теперь — к конкретным фреймворкам, которые сейчас на слуху.
Tauri. Аналог Electron. Бэкенд пишется на Rust, фронтенд — с помощью JS фреймворков (React, Vue, Svelte). Но архитектура платформы не ограничивается этим стеком. Благодаря поддержке WebAssembly можно использовать и полностью Rust-решения. Например, фреймворк Leptos компилируется в WASM-модуль и запускается во встроенном WebView Tauri.
Egui. Не требует отдельного связывания UI с моделью данных. Отрисовка интерфейса описывается в коде линейно, без колбэков и событий, что ускоряет прототипирование. При этом Egui поддерживает адаптивный рендеринг.
Iced. Кроссплатформенная библиотека, вдохновленная Elm Architecture (TEA). Типобезопасность и простота использования заявляются как ключевые принципы.Проект находится в активной разработке.
Dioxus. Фреймворк, похожий на React. Использует собственный Virtual DOM и макрос rsx!, позволяя писать HTML‑подобный код прямо внутри Rust. Dioxus Native: экспериментальный рендерер на базе WGPU, отрисовывает дерево компонентов напрямую, без использования WebView или CSS‑движка. UI‑логика и бэкенд выполняются в одном процессе, в отличие от Tauri, где фронтенд и бэкенд разделены.
Slint. Фреймворк, нацеленный на легковесность, вплоть до использования на встраиваемых устройствах. Для описания интерфейса используется собственный язык разметки (.slint), для кода доступны биндинги к Rust, C++ и JavaScript. Предлагает инструмент Live‑Preview для визуальной разработки.
Xilem. Экспериментальный фреймворк от команды Linebender на основе оригинальной архитектуры (Xilem architecture), вдохновленной Elm, SwiftUI и Flutter. Разрабатывается как преемник библиотеки Druid, работа над которой была прекращена.
Следующий шаг.
Выбор фреймворка по документации и отзывам — это половина дела. Вторая половина — попробовать его руками на минимальном примере.
Многие Rust‑фреймворки требуют системных библиотек для графики и оконных систем. Настройка «на голой» машине может занять ощутимое время и зависеть от ОС. Чтобы не разворачивать отдельное окружение под каждый вариант, удобно использовать dev‑контейнеры в VS Code. Контейнер фиксирует эту настройку один раз, и она работает одинаково на Windows, macOS и Linux (с учётом специфики Docker).
Преимущества контейнеров:
Изолированное, воспроизводимое окружение для каждого фреймворка.
Отсутствие конфликтов версий и зависимостей на основной машине.
Возможность переключаться между фреймворками параллельно, не теряя контекст.
проверка интерфейса
Этот подход позволяет за пару часов собрать минимальные приложения в 3–4 фреймворках и сравнить ощущения от кода, скорость сборки, поведение окна, качество документации к старту.
Наконец-то поднял публичную демку Aximo на Hugging Face Spaces 🎙️
Это локальный speech-to-text API, который работает на CPU, использует Parakeet v3 и позволяет тестировать транскрибацию прямо из браузера через Swagger UI с записью с микрофона, о котором писал в одном из своих предыдущих постов.
Aximo — локальный STT API на Rust для CPU-only inference
Недавно сделал Aximo — self-hosted микросервис для speech-to-text, который можно запускать локально без облака и без зависимости от внешних SaaS.
Идея была довольно простая: хотелось собрать вменяемый STT API, который работает на CPU, поднимается как обычный сервис и при этом остается достаточно прозрачным с инженерной точки зрения.
В основе — Rust, локальный inference через Parakeet v3, HTTP API для обычной транскрибации и WebSocket-слой для realtime-сценариев. Из коробки также добавил Docker, OpenAPI и разбиение на несколько crates, чтобы проект не выглядел одноразовой демкой и оставался удобным для дальнейшего развития.
На текущем этапе это скорее крепкий MVP, чем законченный production-ready продукт, но уже сейчас сервис можно запускать локально, тестировать на своих аудиоданных и использовать как основу для дальнейших экспериментов.
Из интересного: доработал Swagger, добавив возможность отправки записи с микрофона:
Может многие и не задавались вопросом, но я думаю это интересная тема, которую можно прояснить.
Допустим, мы пилим какой-нибудь интересный сервис. Ну вот написали мы бэкенд, а как пользователь будет с ним взаимодействовать? По моему мнению сейчас есть несколько основных вариантов: веб-приложение, мобильное прилижение и телеграм-бот. Конечно, если есть много лишних рук, можно написать всё и сразу, но это не мой варик.
В моём случае каждая строчка кода дорога. Работаю я в одиночку.
Сейчас я разрабатываю сервис по изучению иностранных слов и на основе моего опыта хочу сделать некое сравнение этих подходов.
Телеграм-бот
Вообще начал я user-side телеграм-ботом. Поначалу это, конечно, может, и казалось достаточным, но всё-таки для какого-либо функционала простого телеграм-бота не хватает.
Да и ещё в добавок в Russian Federation начали блокировать тг, поэтому пользоваться им приходится с костылями, а бот перестал стабильно работать.
Вывод: тг-бот - для простого функционала, но довольно нестабилен и ограничен функционал
Хотя, есть mini-app, но в их подробности я не вдавался.
Веб-приложение
Следующий очень популярный вариант - веб-приложение. Этот вариант намного более гибок. Но по моему мнению всё же не максимально стабилен, так как его работа зависит от состояния браузера. Но у этого варианта есть огромное преимущество: он работает на всех устройствах, на которых можно открыть веб-сайт. Это, так сказать, униварсальный вариант.
Но есть проблема. Допустим, человек пользуется чем-то на постоянной основе и хочет максимально быструю и адаптированную работу. Он будет постоянно заходить в браузер и копаться во вкладках? Или лучше тогда выбрать мобильное приложение?
Мобильное приложение
Наверное самый сложный и трудозатратный, но по моему мнению в нынешнее время самый перспективный вариант. Да, по сравнению с веб-собратом работать оно будет не везде, а только на мобилке, при том на определённой (IOS или Android).
Но при этом мобильное приложение даёт реализовать максимально удобное и оптимизированное управление, потому что почти всё можно настроить под свой продукт.
Небольшая сводка
Для чего бот: для простого функционала. Можно использовать как небольшое дополнение к какой-либо инфраструктуре. Этот подход наименее трудозатратен.
Для чего веб-приложения: для продуктов, где нужна кроссплатформенность и довольно широкая кастомизация. Подход не сильно трудозатратный.
Для чего мобильные приложения: для продуктов где важна максимальная быстрота и удобство и наилучшии возможности кастомизации. По моему мнению наиболее подходит для каких-то интересных и уникальных сервисов. Это самый трудозатратный подход из перечисленный, но в некоторых случаях он более чем себя оправдывает.
Что кому разрабатывать в первую очередь зависит от самого проекта, универсального варианта здесь нет по моему мнению.
PS: интересно узнать чужое мнение, так как возможно здесь много субъективщины.
Открытый проект Cheat-Sheets предоставляет учебны материалы для Python, Rust, Swift, JavaScript, Kotlin, Go, Git, и других проектов. Там есть все важнейшие концепции, правила, стили программирования, фреймворки, библиотеки и прочее. Внутри также курсы по Git, Docker, базам данных, а также алгоритмам. Все материалы разделили по уровням сложности, к каждой главе есть контрольные вопросы и десятки задач. Все концепции авторы объясняют на конкретных примерах и разжевывают до последней строчки кода.
Работаем из Java с устройствами с serial-интерфейсом (COM и USB) без JNI — по TCP.
Раньше пользовались rxtx, затем jssc. После очередных крэшей JVM в коде нативных библиотек решил не выбирать замену, а отказаться от них полностью.
В качестве прокси serial-TCP можно взять ser2net или поэкспериментировать с socat, но я запилил свое простое (Rust, mio), под конкретную задачу:
Запускается из основного приложения, свой процесс для каждого устройства
Конфигурация через аргументы запуска и переменные окружения
Завершает работу при отсутствии или отключении устройства (для USB), отключении или отсутствия подключения TCP-клиента
В качестве TCP-клиента Netty. Для интеграции с легаси данные читаются в кольцевой буфер ( OneToOneRingBuffer из agrona), а оттуда уже используются по месту в удобное время.
За счет неблокирующего чтения и использования epoll в mio и Netty минимальные задержки, моментальное оповещение о наличии данных (без Thread.sleep) и об отключении USB-устройства.
Задержки настолько меньше, что пришлось адаптировать кривой код, который не был готов к тому, что драйвер железного serial-порта в Linux отдает данные порциями по 8 байт. Решилось реализацией ByteToMessageDecoder, где возможно, а где нет — буферизацией на стороне прокси и отправкой по таймеру.
Для надежной работы уменьшаем и выравниваем буферы записи, пишем через writeAndFlush с ожиданием завершения, чтобы устройство успевало читать.
Бонус: можно работать с устройством, подключенным к другому системному блоку (например, для разработки) и использовать TCP-эмуляторы вместо реальных устройств без изменения кода интеграции.
Слышу уже от второго человека, что язык Rust не дает нормально работать с указателями в связанных списках, деревьях и графах (в моей вселенной ЯП без этого - это как свадьба без невесты). Взял ChatGPT, задал промпт: "write a code to insert a node into a doubly linked list in rust". Оно сгенерило нечто с кучей дополнительных слов, которых не было ни в Си, ни в Паскале 40 лет назад: borrow, as_ref, and_then, upgrade, map, downgrade, Some, clone, borrow_mut. Это все реально нужно или они там совсем озверели?
Российская компания Selectel, развивающая Linux-дистрибутив Selectel OS на пакетной базе Debian, представила инициативу OpenFix, в рамках которой начнёт выплачивать энтузиастам денежные вознаграждения за участие в работе над задачами, связанными с развитием и исправлением ошибок в открытом ПО. Код выполненных проектов будет публиковаться под пермиссивной лицензией с сохранением авторства участников.
Вознаграждения назначается индивидуально и выплачивание после принятия изменения в Debian или Ubuntu и закрытия сообщения об ошибке.
Предложено три направления деятельности, выполнение задач в которых Selectel готов оплачивать:
переписывание известных открытых проектов на язык Rust. В настоящее время доступны три задачи, связанные с переписыванием с языка С на Rust кода проектов xz, c‑ares и libxml2 c сохранением поведения оригинала.
вознаграждение за переписывание библиотек libxml2 и c‑ares и определено в 350 тысяч рублей, а библиотеки xz в 200 тысяч рублей, но в случае xz указано, что достаточно переписать критические части библиотечных обвязок и связать с существующей Си‑реализацией алгоритма LZMA.
формирование и последующее сопровождение (подготовка обновлений) пакетов для Debian GNU/Linux. Приложения для которых предлагается создать deb‑пакеты (c опциональным продвижением созданного пакета в Debian Unstable): apache‑pulsar, bash‑it, bazel, bitwarden‑cli, composefs, cve‑bin‑tools, doh‑cli, dupd, dyff, firecracker, griddb, jailhouse, keycloak, oauth2-proxy, phoronix‑testsuite, photodedupe, purritobin, shh, skim, sssh‑tpm‑agent, uv, vaultwarden. Размер вознаграждения от 30 до 160 тысяч рублей. Премии меньше 50 тысяч рублей определены для uv, dyff, doh‑cli, purritobin и bash‑it, а больше 100 тысяч для jailhouse, bazel, sssh‑tpm‑agent, keycloak, griddb, firecracker и apache‑pulsar.
Исправление ошибок в существующих открытых проектах. Участники на своё усмотрение могут выбирать проблемы, подтверждённые в системах отслеживания ошибок Debian и Ubuntu (Launchpad), после чего согласовать возможность получения вознаграждения за их исправление с Selectel. Вознаграждения назначается индивидуально и выплачивание после принятия изменения в Debian или Ubuntu и закрытия сообщения об ошибке.
Лутаем Open Source #24. Они наконец-то починили MongoDB! Перенеся его на PostgreSQL...
DocumentDB – БД от Microsoft, которая состоит из 3-х частей:
PG расширение, добавляющее BSON формат (написанный, на С)
CRUD API поверх него (С)
Сервис трансляции Mongo Query в SQL (Rust)
GitHub - documentdb/documentdb: MongoDB-compatible database engine for cloud-native and open-source workloads. Built for scalability, performance, and developer productivity.
И вроде как: "PG – классная база, а MongoDB Query + BSON популярные технологии" – и можно было бы поразмышлять чем это круто, но сначала важно ответить на один туманный вопрос: "кому такая БД может быть нужна?"
Классический PG
Сначала рассмотрим кейс, когда мы накладываем DocumentDB на обычный PostgreSQL.
Те, кто используют MongoDB если попробуют переехать на такой сэтап столкутся с тем, что:
Там нет шардинга (и насколько бы он не был сложно реализован в MongoDB, он есть и им активно пользуются)
Придется использовать двойной тулинг: Compas, чтобы наблюдать за корректностью данных с MongoDB Query, и SQL если надо посмотреть что там внутри
MongoDB поддерживает Uncommitted Read и Write Majority, что странно накладывается на PG: если разраб достаточно продвинутый и намеренно использовал Uncommitted, то с PG он потеряет скорость и Availability из-за PG Committed, а если он использовал Write Majority, то PG не совсем дает такую гарантию (обвал диска при WAL репликации – менее надежен, чем Write Majority)
А самое главное: когда ты работаешь с MongoDB ты можешь открывать 1000 коннекшенов и он вполне себе все это сожрет, потому что (1) коннекшен это тред, (2) при запросах нет никакой проверки реляционной целостности, да и в целом проверка сильно проще, чем в PG, а значит придется потанцевать с пуллерами и даже менять где-то запросы, чтобы не упасть по скорости
То есть, у mongo-юзеров это заберет все особенные фичи MongoDB и при этом не даст фишки PostgreSQL.
Distributed PG-like
А что, если мы положим DocumentDB на что-нибудь из серии CockroachDB, YugabyteDB, AWS Aurora, Citus или Neon?
Все 3 проблемы решаются:
Шардинг из коробки
Достаточно высокая скорость записи и чтения
Отсутствие проблем с коннектами
В такой ситуации DocumentDB начинает играть новыми красками.
Но если в Neon и Citus (и может YugabyteDB) еще есть шанс добавить текущий DocumentDB BSON плагин, то в для других представителей придется писать его с нуля (причем под каждый свой, потому что они построены каждый на своем KV хранилище).
Переезд в Linux Foundation
А еще они сейчас в процессе переезда из Microsoft в Linux Foundation, из плюсов они будут полностью под MIT лицензией и пейвола, за который будут прятать полезные фичи, из минусов, Microsoft могут и забросить, а никто другой не подхватить.
Итоги
Неоднозначная технология, пока имеет смысл в каких-то тонких кейсах, но в общем и целом, не вижу пока где тут middle-ground, может, вы что-то подскажете?
Привет Хабр! Это мой первый пост, и я просто хотелось спросить, стоит ли уходить в Go? У меня есть небольшая база в программировании, делал сайты на реакт и ларавел, реализовывал бэкенд с Солид и паттернами, писал на нативном пхп файловые обменники и апи. Не много знаю базы данных соответственно, гит, докер. Сейчас засматриваюсь на Go, где то вычитал что мол крутая штука для бигтехов в России, а сам я студент и пока сижу на шее у родителей, но в следующем году я окончу к курс, и хочу где то месяца за 4-5 изучить все нужное в го и во всех других сопутствующих технологиях для разработки высоконагруженных приложений и микросервисов и всякого подобного. Стоит ли сворачивать на этот путь, или добить стек ларавел плюс вью? Немного боюсь, так как слышал что в го нужны уже 25 летние синьоры со стажем работы минимум в 20 лет, но и не хочется проторчать всю жизнь в челябинской галере на фуллстеке за 70 деревянных на руки.
Спойлер: принципиальное решение проблемы - найдено. Купил маленькую коробочку на "мейнстримной" архитектуре, на которой все цветет и пахнет.. кроме моего внутреннего(ну и внешнего, че уж там) инженера) Так что решение выкинуть железку - можно не предлагать
Так вот, пока я писал код, и готовил сборочные скрипты ничто не предвещало беды - я спокойно потестил код локально, написал Dockerfile для сборки на poetry. Настало время развернуть это все на NAS - казалось бы ARM уже давно мейнстрим, но тут понеслось
python как всегда лишь удобный биндинг к куче платформозависимого кода) подавляющее большинство python-зависимостей под arm/v7 приходится компилировать
готовых бинарников polars под arm/v7 - тоже нет
Никаких блокеров к тому, чтобы собрать polars под arm/v7 я не нашел. Но скомпилить его нативно на 4Гб ОЗУ - не получится, даже с минимальными оптимизациями. Нужна кросс-компиляция. Благо с rust и maturin(которым собирается polars) - это несложно, target armv7-unknown-linux-gnueabihf в хорошем tier-е поддержки
забегая чуть вперед указываем окружение для сборки аллокатора jemalloc(по умолчанию в polars) под 32k страницу
Итак, усложняем сборку Docker(см. repro) - используем кросс-компиляцию, энв-переменные, QEMU, охапку дров и теперь у нас есть приложка, которая успешно стартует в докере на целевой железке. Вот только за рамками самых примитивных тестов - OOM-ится, причем память точно есть, никакой OOM-киллер процесс не убивает(на всякий случай смотрим лимиты cgoup) - оно "шамо":
memory allocation of 1345920 bytes failed
(подробные логи можно посмотреть по ссылкам в конце поста)
Что же делать?
пробуем mimalloc - он использует для конфигурации рантайм(getconf), эффект - тот же
пробуем env-крутилки, в частности arena_reserve может стоит просто меньше резервировать - но нет, просто больше попыток, но по факту все равно OOM
И вот на этом месте я застрял. Я не большой спец по системному программированию - не понимаю куда копать
Общение с поддержкой QNAP свелось к
Справедливости ради они еще дали советов что попробовать, но это я уже попробовал до них
Пытался отлаживать приложение в gdb - никаких аномальных трейсбэков во время OOM не увидел: rust честно пытается аллоцировать большой raw_vec(трейс есть в вопросе на stackoverflow)
Как-то глубоко копать переменные не получается, т.к. дебаг-символы для бинарника polars получаются слишком большими
BFD: error: /app/.venv/lib/python3.12/site-packages/polars/polars.abi3.so(.debug_str) is too large (0x498a9fd1 bytes)
Я сделал небольшое repro на голом расте - там эта проблема не воспроизводится, значит базово бинарная совместимость - в порядке
Есть несколько гипотез, но я не знаю как их проверить
возможно, кривая вся адресация, но ее проверить я тоже не могу
возможно, стоит чего-нибудь половить в ядре bpf-ом, но что..
кастомное ядро 4.2.8 кастомный дистриб(QTS) не богат средствами отладки - как я понял там запускается busybox набор утилит
А мне бы хотелось все-таки дожать диагностику и однозначно ответить на вопрос: это лыжи не едутя не умею собирать приложения под нужное окружение или все-таки целевая платформа не умеет выполнять корректно собранное? Не потому что эту проблему нельзя решить по-другому, а потому что в том, чем пользуешься - хочется разбираться.
Пишите в комментах ваши соображения. Если что-то удастся прояснить - буду держать читателей поста в курсе
По этой ссылке https://www.youtube.com/watch?v=rWMQ-g2QDsI обнаружилось видео (11:16) с тучей прелюбопытнейших отсылок объединённых идеей использования Rust для написания консольных приложений.
А за ним занятный канал, Автор которого, помимо носительности качественного английского языка, вроде как является приверженцем следующих идей
не плоди сущности без необходимости
используй меньше чтобы сделать больше
велик C и Rust наследует ему
всё преходяще, кроме вечного
Рекомендуется к ознакомлению вкатунам и начинающим пользы ради, а остальными удовольствия для.
Генерация последовательностей случайных чисел с помощью DRAM — возможно ли это? Проверим с помощью RISC-V
На основе DRAM мы создали модель одноканального источника шума, который возвращает один случайный бит за один условный такт. Память разбита на два региона, которые не пересекаются. Первый отвечает за инициализацию одноканального сигнатурного анализатора (ОСА), который инициализирует второй подобный анализатор. Затем мы сможем взять другой регион памяти и заново инициализировать первый ОСА, что абсолютно случайным образом изменит выход второго ОСА. Такая схема позволит не перезагружать память после каждой генерации числовой последовательности — ведь в реальных проектах это, как правило, невозможно.
Далее мы направляем данные из DRAM PUF в два подмодуля — постобработки, а также тестирования, анализа и оценки качества данных. Первый частично запускается на «железе», второй — на собранных данных на машине хоста.
Для постобработки мы протестировали шесть комбинаций. Последняя нам кажется наиболее перспективной:
сырые данные,
чистый корректор фон Неймана,
одноканальный сигнатурный анализатор,
чистый корректор фон Неймана + одноканальный сигнатурный анализатор,
одноканальный сигнатурный анализатор + чистый корректор фон Неймана,
многоканальный сигнатурный анализатор (МСА).
Зимняя школа RISC-V дала начало множеству интересных проектов. В отдельной статье мы рассказали об одном из них, где команда из БГУИР проверила гипотезу о наличии PUF в динамической памяти и создала модель одноканального источника шума. А затем реализовала постобработку и тестирование, измерила производительность генератора и оптимизировала код.
Новый тайпчекер для Python от авторов ruff и uv, написанный на Rust
Вышло видео про новый тайпчекер и lsp: ty (старое название red-knot) от авторов ruff и uv. Пока по первым впечатлениям – бомба! Не смотря на версию 0.0.0a8 🌚
Из плюсов:
Быстрый
На расте
Куча новых фичей для типов
Полная спецификация
Интеграция с ruff и IDEшками
Из минусов:
Пока есть баги (но их поправят, конечно же)
Нет плагинов (и скорее всего никогда не будет)
Софт от молодой и маленькой компании
Как сделать поддержку ty и mypy вместе? А если использовались ty_extensions?
fn main() {
let a = 10;
let b: i32 = 20;
let c = 30i32;
let d = 30_i32;
let e = add(add(a, b), add(c, d));
println!("(a + b) + (c + d) = {}", e);
}
fn add(i: i32, j: i32) -> i32 {
i + j;
}
Определение функции начинается с ключевого слова fn. Точка входа в Rust-программы - это функция main. Она не получает никаких аргументов и не возвращает никаких значений.
В следующих строках let используется для привязки переменной. По умолчанию переменные неизменяемые, то есть предназначены только для чтения, а не для чтения-записи.
Также можно указывать конкретный тип данных разными способами:
Через двоеточие
Числовые литералы могут включать аннотации типов
В последней строке вызывается макрос println! для вывода текста.
В строках используются двойные, а не одинарные кавычки, а для символах используются одинарные.
И наконец, функция add имеет аргументы с указанными типами данных и возвращает нужный тип данных. Как вы видите, возврат значения происходит автоматически, для этого не используются ключевые слова по типу return.
Поговорим о создании переменных. В Rust они бывают мутабельными (mutable) или немутабельными (unmutable), то есть изменяемые и неизменяемые. Неизменяемые переменные можно сравнить с константами.
Разберем пример:
fn main() {
let a = 10;
a = 15;
}
Если мы скомпилируем данную программу, то получим ошибку:
error[E0384]: cannot assign twice to immutable variable `a`
--> src\main.rs:25:5
|
24 | let a = 10;
| - first assignment to `a`
25 | a = 2;
| ^^^^^ cannot assign twice to immutable variable
|
help: consider making this binding mutable
|
24 | let mut a = 10;
| +++
Т.к. все переменные в rust изначально неизменяемые, то мы не можем изменить переменную. Компилятор нам подсказывает, что для изменения значений надо добавить ключевое слово mut.
Добавим:
fn main() {
let mut a = 10;
a = 15;
println!(a);
}
Программа успешно скомпилируется и мы получим 15.
Но также существуют константы. Подобно неизменяемым переменным, константы — это значения, которые связаны с именем и не могут изменяться, но между константами и переменными есть несколько различий. Во-первых, нельзя использовать mut с константами. Константы не просто неизменяемы по умолчанию — они неизменяемы всегда. Для объявления констант используется ключевое слово const вместо let, а также тип значения должен быть указан в аннотации.
Имя константы - THREE_HOURS_IN_SECONDS, а её значение устанавливается как результат умножения 60 (количество секунд в минуте) на 60 (количество минут в часе) на 3 (количество часов, которые нужно посчитать в этой программе). Соглашение Rust для именования констант требует использования всех заглавных букв с подчёркиванием между словами. Компилятор может вычислять ограниченный набор операций во время компиляции, позволяющий записать это значение более понятным и простым для проверки способом, чем установка этой константы в значение 10 800.
Константы существуют в течение всего времени работы программы в пределах области, в которой они были объявлены. Это свойство делает константы полезными для значений в домене вашего приложения, о которых могут знать несколько частей программы, например, максимальное количество очков, которое может заработать любой игрок в игре, или скорость света.
Еще момент - в листингах выше мы не декларировали тип данных переменных.
Вообще, типизация в Rust несет полу строгий характер. Разработчик может не указывать тип данных. Это может укоротить код, если сама программа небольшая. Но всегда рекомендуется описывать тип данных, иначе могут возникнуть ошибки. Например:
fn main() {
let mut a = 10;
a = "hello"; // возникнет ошибка
}
Мы не можем поменять тип данных, которые хранятся в переменной. Обычно типы данных указывают так:
В Rust, также как и в большинстве ЯВУ, можно "затенять переменные", то есть создавать вторую переменную с таким же именем, используя значение первой переменной:
fn main() {
let x = 5;
let x = x + 1;
{
let x = x * 2;
println!("The value of x in the inner scope is: {x}");
}
println!("The value of x is: {x}");
}
Эта программа сначала привязывает x к значению 5. Затем она создаёт новую переменную x, повторяя let x =, беря исходное значение и добавляя 1, чтобы значение x стало равным 6. Затем во внутренней области видимости, созданной с помощью фигурных скобок, третий оператор let также затеняет x и создаёт новую переменную, умножая предыдущее значение на 2, чтобы дать x значение 12. Когда эта область заканчивается, внутреннее затенение заканчивается, и x возвращается к значению 6. Запустив эту программу, она выведет следующее:
The value of x in the inner scope is: 12
The value of x is: 6
Область видимости
Связывание переменных происходит в локальной области видимости — они ограничены существованием внутри блока. Блок — это набор инструкций, заключённый между фигурными скобками {}.
fn main() {
// Эта переменная живёт в функции main
let long_lived_binding = 1;
let shadowed_variable = 1;
// Это блок, он имеет меньшую область видимости, чем функция main
{
// Эта переменная существует только в этом блоке
let short_lived_binding = 2;
let shadowed_variable = 2;
println!("shadowed variable: {}", shadowed_variable);
println!("inner short: {}", short_lived_binding);
}
// Конец блока
println!("shadowed variable: {}", shadowed_variable);
println!("outer long: {}", long_lived_binding);
}
На картинке — код на Rust, и в нём затаилась ошибка. Я специально попросила её сделать моих коллег, разработчиков ИТ-компании «Криптонит».
Зачем? Чтобы потом попросить её найти и написать о ней в комментариях (ох, уж эти сммщики).
Итак, где тут ошибка?
СЕЙЧАС БУДЕТ СПОЙЛЕР!
Так в чём же ошибка?
В третьей строке возникает ошибка попытки доступа к элементу за пределами массива. for i in 1..=numbers.len() выполнит итерацию по элементам, начиная со второго, а не с первого.
Ошибка заключается в попытке доступа к элементу с индексом [5] на последней итерации цикла. Такого элемента в массиве нет, в результате получаем аварийное завершение программы.
Также следует обратить внимание, что первый элемент массива с индексом [0] игнорируется. Это не является ошибкой с точки зрения выполнения программы, однако скорее всего является логической ошибкой в коде
Итак, в языке rust индексация элементов начинается с 0 и заканчивается len() - 1. В массиве из 5 элементов допустимо обращение к [0], [1], [2], [3] и [4] элементам.
Рекомендуемый способ перебора элементов коллекции с автоматической индексацией на rust — использование цепочки вызовов iter().enumerate().
Вот как это выглядит
fn main() {
let numbers = vec![10, 20, 30, 40, 50];
for (index, number) in numbers.iter().enumerate() {
println!("Элемент {index}: {number}");
}
}
Этот вариант позволяет также упростить выражение println, поместив печатаемые значения сразу в скобки на свои места. Это исключает возможность ошибиться в порядке печати значений и повысив наглядность кода.
А ты такой холодный: представим технологии Rust-дебаггеров в виде айсберга
На верхушке айсберга видим технологии DWARF, PTRACE и ELF, а внизу — набор более редких технологий.
Сегодня будем говорить только о верхушке. Хорошая новость: чтобы понять большинство возможностей дебаггера, достаточно иметь представление об этих трех технологиях:
PTRACE — системный вызов, который позволяет одному процессу (tracer) управлять и исследовать другой процесс (tracee).
ELF (Executable and Linkable Format) — формат исполняемых двоичных файлов.
DWARF (Debugging With Arbitrary Record Formats) — стандарт, описывающий формат .debug_xxx секций в ELF.
Что касается «подводных» технологий, упомянутых на картинке: применяя закон Парето, можно смело сказать что 80% знаний необходимы, чтобы реализовать только 20% функционала (и не самого важного). Но если хотите узнать о них больше, напишите в комментариях.
Подробнее о PTRACE, ELF и DWARF, а также о функциях, которые они реализуют в отладчиках на Rust, читайте в статье.
Это представляется мне отличным объектом приложения сил ищущих что бы такое с Medium перевести.
Downfall, в пределах доступного мне начала текста, обосновывается отказами ряда заметных проектов от использования Rust, первым из которых выбран https://daniel.haxx.se/blog/2024/12/21/dropping-hyper/ - отказ от от написаного на Rust бэкенда в curl. Каким образом указанный текст позволяет увидеть downfall - мне понять не удалось, скорее просвечивает ubiquitous presence. Максимум - доказательство существования столь кривого С кода к которому Rust с разумными трудозатратами не прикручивается.
Случай, ИМХО, крайне интересен, поскольку может указывать на то, что либо сам Rust либо его растущая популярность кому-то начинают мешать.
Стабилизировано начало миграции на новый trait solver, что исправляет ошибки преимущественно теоретического характера, простых смертных просят не беспокоиться.
Добавлен strict provenance API, позволяющий превращать указатели в целые числа и обратно с особым изяществом.
Стабилизированы четыре десятка API и во всей троице Rust, Cargo и Clippy куча мелких изменений.
Подробности под катом на rust-lang.org. Телеграмм канала не держу, подписывайтесь куда нравится.
Не знаю на сколько это свежая новость ибо прочитал в новостях, но факт занимательный. JetBrains (опять) изменила лицензирование сделав IDE для Rust, JavaScript, C# и тестирования бесплатными для некоммерческого использования.
На сколько это следствие продвижения ИИ в средствах разработки - поди знай, но уж больно совпало по времени.
Всем привет! Кто хочет поучиться кодить на Rust присоединившись к Open Source проекту? Проект rustsn представляет собой инструмент на языке Rust, который выполняет следующие функции:
Генерация, компиляция и тестирование кода с использованием моделей машинного обучения (LLMs).
Разрешение зависимостей.
Предоставление объяснений существующего кода с помощью встраиваний (embeddings).
Представлен выпуск Aura 4.0.0. Это проект пакетного менеджера для дистрибутива Arch Linux, расширяющий возможности штатного пакетного менеджера Pacman.
Проект создан в 2012 году и изначально был нацелен на предоставление средств для сборки пакетов для репозитория AUR (Arch User Repository), применяемого для распространения сторонними разработчиками своих пакетов, не входящих в основные репозитории дистрибутива Arch Linux.
Кроме специфичных для AUR функций в Aura также предоставляются и другие возможности, расширяющие функциональность Pacman (в настоящее время только 1/3 расширенных возможностей Aura связаны с AUR). Например, доступны средства для наглядного анализа зависимостей, работы со снапшотами наборов пакетов (для сохранения и восстановления состояния), управления остаточными зависимостями и отката отдельных пакетов или всей системы на прошлые версии.
Aura полностью обратно совместим с Pacman и поддерживает все его команды и опции. Связанные с AUR дополнительные возможности вызываются через указание опции командной строки «‑A», а средства работы со снапшотами и версиями через опции «‑B» и «‑С», не пересекающиеся с опциями Pacman.
В Aura 4.0.0 переведена вся кодовая база с Haskell на язык Rust. Смена языка позволила значительно повысить производительность, упростить установку, задействовать готовые Rust-биндинги к libalpm, сделать проект более привлекательным для новых разработчиков.
Проект Redox OS, представляющий собой операционную систему с открытым исходным кодом, написанную с нуля на языке программирования Rust, теперь имеет работающий веб-сервер, среди прочих улучшений, добавленных в код проекта в течение июля.
Среди заметных новых программных работ в Redox OS — запуск Simple HTTP Server в качестве первого веб-сервера (HTTP) для платформы. Сам Simple HTTP Server также написан на Rust. Также ведутся постоянные усилия по переносу Apache HTTP-сервера в Redox OS.
Ещё одним важным достижением приложения является программа wget, которая теперь работает в Redox OS. Также была проделана большая работа по запуску настольных приложений COSMIC в Redox OS, внесены улучшения в системы сборки, продолжалась работа по созданию более сложных программ в Rust, улучшение ядра ARM64, улучшения UEFI и различные исправления драйверов.
