Hacker News Digest

Вышел OpenBSD 8.0 — 61-й релиз проекта, датированный 20 октября 2026 года. Песня релиза называется «The Simps on AI», а артворк подготовили yvaneht nioj и clanker. Опубликованы контрольные суммы и публичные ключи signify(1) для base, прошивок, пакетов и syspatch, а также страница errata и подробный список изменений между 7.9 и 8.0.

Среди ключевых изменений — резкое расширение адресного пространства ядра на amd64: с 4 ГБ до 512 ГБ, при этом прямая карта памяти (pmap(9)) теперь размещается по случайному адресу. На arm64 добавлена поддержка гибернации и bounce-буферы, а шифрование swap ускорено аппаратными инструкциями AES — это же сделано и на amd64. На riscv64 появилась поддержка векторного расширения «V», расширенной архитектуры прерываний (драйверы imsic(4) и aplic(4)), таймерного расширения Sstc и bounce-буферов, а сведения о расширениях CPU теперь передаются в userland через elf_aux_info(3). На sparc64 выполнены проверки границ таблицы релокаций и осуществлён переход на инструментарий LLVM. Поддержка архитектуры loongson прекращена из-за несовместимости с Clang 22.

В ядре также исправлены расчёт размера памяти в open_wmemstream(3), уничтожение идентификатора семафора в semop(2) при переключении контекста и улучшены эвристики очереди неактивных страниц. Исходники по-прежнему поставляются архивами src.tar.gz, sys.tar.gz и ports.tar.gz — это обычные CVS-деревья, дающие быстрый старт для обновления через AnonCVS.

Обсуждение дополняет анонс OpenBSD 8.0 реальными отзывами. Обновление через sysupgrade по SSH осталось простым, а система сохраняет стабильность даже на старом железе (например, на ноутбуке Lenovo 2012 года). Ключевые технические изменения: поддержка многопоточного VMM/VMD, улучшение SMP-сетевых функций и переход ssh с supercop ed25519 на libsodium. Пользователи запрашивают бенчмарки для сравнения версий 8.0 и 7.9, при этом отмечают, что нумерация релизов линейна и не имеет особого значения. Релиз-песня «The Simps on AI» получила положительные отзывы как традиционный элемент выпуска; рекомендуется изучить её текст на странице проекта. Графика «blowfish on bike» вызвала споры: одни видят в ней пародию на AI-генерации или комментарий к трендам, другие — просто странный рисунок. Также прозвучала критика размера дистрибутива (8 МБ), длительности загрузки (53 сек) и использования формата GIF. Важная оговорка: если при обновлении система перезагружается в старую версию, проверьте наличие монитора, иначе процесс может завершиться неудачей.

SQLDoom переносит оригинальный Doom 1993 года полностью в SQL: логика игры и рендерер реализованы как запросы к базе данных CedarDB. Игровой цикл работает с оригинальными 35 FPS, а рендерер генерирует полный буфер кадра 320×200 пикселей до 60 Гц на ноутбуке. Python используется только для обработки ввода, синхронизации таймингов и вывода полученного битмапа. Поддерживается мультиплеер — deathmatch на четырёх слотах, доступный через публичные серверы в ЕС и США. Для рендеринга используется BSP-дерево, как в оригинале, что позволяет корректно упорядочивать глубину, накладывать текстуры, обрабатывать наклонные стены и переменную высоту пола — в отличие от предыдущего проекта DOOMQL, основанного на упрощённом рейкастинге. Хотя SQLDoom медленнее нативного бинарника из-за множества уровней абстракции, разрыв оказался неожиданно мал благодаря оптимизатору CedarDB и JIT-компиляции в LLVM. Для запуска требуется CedarDB Community Edition, Python с psycopg2 и pygame, а также IWAD-файл Dooma (shareware-версия доступна через пакетный менеджер). Исходный код доступен на GitHub, а играть можно прямо сейчас via веб-интерфейс, где при заполненных слотах игрок помещается в очередь, но может продолжать исследовать игровое состояние через SQL-запросы. Проект демонстрирует, насколько далеко можно зайти, используя СУБД не только для хранения данных, но и как платформу для выполнения сложных вычислений в реальном времени. John Carmack называют гением за то, как он извлёк максимум из ограниченного железа 1993 года — подход, который теперь находит отклик даже в неожиданных средах вроде SQL.

SQL способен реализовать сложную игровую и бизнес‐логику: 5900 строк SQL заменяют ~9000 строк C, обеспечивая полноценный цикл рендеринга и физики. Хранение состояния в таблицах гарантирует атомарность и согласованность, устраняя потерю данных. Однако при большом числе игроков возникают проблемы с блокировками и масштабируемостью. Отладка хранимых процедур, отсутствие контроля версий и культурные барьеры делают такой подход спорным в реальных проектах. В полупроводниковом производстве процедуры использовались для ежедневного изменения правил сотнями пользователей на копии продакшн‐БД, но копировать продакшн‐БД ежедневно нереально для крупных систем из‐за объёма данных. Современные альтернативы (например, функции SpacetimeDB) и ограниченный набор стандартных функций в MSSQL снижают привлекательность чистого SQL для сложной логики. Рекомендуется держать меняющуюся и сложную бизнес‐логику в приложении, а в базе оставлять только ограничения и простые процедуры как резерв. Использование планировщика запросов как конечного автомата считается инженерным злоупотреблением, несмотря на сокращение кода. Выбор места логики часто определяется корпоративной культурой, а не только техническими факторами: многие избегают «болота» SQL‐логики. Существуют языки, компилирующиеся в SQL, которые можно использовать для реализации алгоритмов внутри БД. Проект уже развернут на EU и US серверах, подтверждая практическую возможность мультиплеерного режима в SQL‐базе. Опыт разработки многопользовательских игр с атомарными транзакциями показывает, что паттерн работает при правильном решении проблем конкурентного доступа (см. Designing Data‐Intensive Applications).

За последние два месяца компилятор Rust стал значительно быстрее: среднее время компиляции снизилось на 4,57%, при этом 555 из 629 бенчмарков улучшились, а только 74 ухудшились — многие показали двузначный процент роста производительности. Ключевые улучшения включают оптимизацию rustdoc от Ноя Лева, включение PGO для Clippy (до 18% ускорения в лучшем случае) и обновление LLVM до версии 23, которое дало среднее улучшение на 1,2% за один PR.

Одновременно были включены экспериментальные компоненты — новый заимствование-проверяющий Polonius Alpha и новый решатель trait’ов Pineapple Häagen-Dazs — которые, будучи более точными, увеличивают нагрузку в некоторых случаях (например, для crate serde), но их регрессии компенсируются общим прогрессом. Джек Хью уменьшил нагрузку Polonius через ленивые вычисления живучести и оптимизацию структур данных, а Яна Дёнцелманн работает над производительностью нового решателя. Кроме того, массовый приток PR с улучшениями привёл к созданию «rollup»-слияний — например, одного с 10 PR — чтобы не задерживать прогресс из-за ограничений CI, при этом каждый эффект проверяется постфактум через бенчмарк-сuiten. Автор поста скоро присоединится к Hexcat для работы над целью оптимизации производительности компилятора Rust на 2026 год.

Компиляция Rust остаётся узким местом при масштабных параллельных нагрузках, особенно без кэша. Сообщество предлагает практические решения: настройка sccache или kache для кеширования артефактов, использование инструментов вроде mbx для управления инкрементальной компиляцией, разделение тяжёлых crate‐ов на меньшие модули для повышения параллелизма, включение глобального блокировщика сборки (cargo wrapper) для избежания конкуренции за CPU (ускорение до 300 %), а также использование альтернативных линкеров (lld, mold) и инкрементальной линковки для ускорения линковки. Анонсированы будущие улучшения компилятора: раннее эмитирование метаданных (до 40 % ускорения wall‐time, требует доработки обработки ошибок), параллельный фронтенд и TPDE. Основные причины медленной компиляции — макросы, мономорфизация и кодогенерация в LLVM; переход на Cranelift может ускорить dev‐сборки, но пока не готов для продакшна. Некоторые пользователи переходят на Go из‐за текущих задержек, утверждая, что даже с кешем и модульностью Rust медленнее; другие считают, что правильная архитектура проекта устраняет проблему.

NVIDIA представила CUDA Rust — набор инструментов для написания GPU-ядер на Rust, устраняя необходимость использовать другие языки для ядер, даже если остальная часть стека уже на Rust. Поддерживаются две модели программирования: SIMT (как в CUDA C++), где разработчик указывает действия одного потока, и Tile — более абстрактная модель, где описывается обработка блока данных, а компилятор сам определяетMapping на архитектуру. Tile рекомендуется как отправная точка благодаря переносимости, а SIMT оставлен для случаев, требующих низкоуровневого контроля.

Для SIMT доступен проект cuda-oxide — собственный бэкенд rustc, который компилирует функции с атрибутом #[kernel] в PTX через MIR, Pliron и LLVM. Для Tile — cutile-rs, предоставляющий Rust-биндинги к cuTile API. Оба примера демонстрируют поэлементное сложение 1024 float-значений и выводят одинаковый результат. Требуются Linux, GPU с compute capability ≥8.0, CUDA Toolkit 12.x+, clang и зафиксированная ночная цепочка Rust. Инструменты проверяются через cargo oxide doctor. Документация, примеры и ссылки на репозитории доступны в блоге NVIDIA, а также планируется доклад на RustConf 2026. Interoperability с другими языками остаётся приоритетом.

Обсуждение подтверждает, что CUDA Rust может снизить сложность написания GPU-ядер, но вызывает опасения по поводу вендор-локкита, стабильности pre-1.0 инструментов и качества официальных анонсов.

• Спор: Некоторые считают CUDA вредным из-за вендор-локкита и требуют открытых альтернатив вроде Metal/OpenCL, другие утверждают, что CUDA — лучший GPGPU API на данный момент, и критика его только замедляет прогресс в UX.

• Спор: Один участник критикует ручной запуск ядер как ошибко-чувствительный и трудоёмкий, а другой отмечает, что компиляторная проверка и единое выражение для запуска ядра — ключевое преимущество CUDA, а не просто артефакт C++.

• Совет: Пользователи с опытом в CUDA отмечают, что CUDA Rust требует nightly Rust и pre-1.0 инструментов, что делает его нестабильным для продакшена и усложняет отладку из-за множества слоёв (Rust, cuda-oxide, CUDA, Tile).

• Многие согласны, что Rust для GPU-программирования — важный шаг вперёд, особенно для повышения надёжности кода ядер и уменьшения боли от отладки по сравнению с CUDA C++.

• Отмечается, что NVIDIA открыла CUDA Tile IR, что делает проект частично открытым, и это воспринимается как позитивный сигнал, несмотря на критику вендор-локкита.

• Совет: Опытные разработчики предупреждают, что использование CUDA Rust может привязать код к NVIDIA, если не использовать абстракции, и советуют оценивать альтернативы вроде rust-gpu или WebGPU.

• Поддержка Rust в GPU-программировании усиливается трендами: интеграция Rust в Linux-ядро, использование Rust в Amazon/Microsoft для верифицированного ПО и рост популярности Candle от Hugging Face.

• Спор: Некоторые критикуют стиль анонса NVIDIA как 'автоматически сгенерированный Claude', считая это признаком безразличия команды, в то время как другие воспринимают это как норму для корпоративных анонсов.

• Совет: Пользователь с опытом в WGPU и cudarc отмечает, что CUDA-oxide позволяет делить структуры между хостом и устройством, но требует перехода на экспериментальный диалект, что может быть риском.

• Несколько участников отмечают, что CUDA Rust — это шаг в правильном направлении, особенно для Rust-экосистемы, и благодарят NVIDIA за поддержку, несмотря на прошлые проблемы с Linux.

• Спор: Один участник спрашивает, можно ли использовать CUDA Rust для WebGPU/Vulkan, а другой отвечает, что это нецелевое использование — CUDA Rust ориентирован на CUDA-совместимые GPU, а не на веб-стандарты.

• Совет: Пользователь с опытом в GPU-программировании отмечает, что несоответствие порядка элементов в примерах (a,b,c vs z,x,y) указывает на непоследовательность в API, что может ввести в заблуждение новичков.

Компиляция Zig становится значительно быстрее благодаря многолетней работе над оптимизацией компилятора. Например, сборка скрипта build.zig в версии 0.15 заняла всего 1,7 секунды против 7,2 секунд в версии 0.14. Полная сборка проекта Ghostty без кеша сократилась с 41 до 32 секунд, даже с использованием LLVM.

Особенно впечатляет скорость инкрементных сборок: пересборка библиотеки libghostty-vt после изменения одной строки теперь занимает менее секунды (975 мс против 2,9 секунд ранее). Это уже ощутимо ускоряет рабочий процесс, а в будущем, с отказом от LLVM и внедрением инкрементной компиляции, результаты станут ещё лучше — ожидаются миллисекундные задержки.

• LLVM рассматривается как ловушка из-за сложности тонкой настройки финальных оптимизаций и линковки, несмотря на преимущества в скорости начальной разработки и поддержке платформ. Cranelift и другие бэкенды могут стать альтернативой.
• Zig фокусируется на скорости компиляции для разработки, используя собственный бэкенд для debug-сборок (x86_64) и LLVM для релизов. Есть баги, но инструментарий ценится за простую кросс-компиляцию и статическую линковку.
• Быстрая компиляция (TCC, Go, Vlang) важна для итеративной разработки, но trade-off с оптимизацией кода неизбежен. Интерпретаторы или JIT-компиляция (Julia) предлагают альтернативы для интерактивности.
• Интеграция Zig с системами сборки (Bazel) возможна через правила, но Turing-полные скрипты сборки могут усложнить кеширование. Библиотеки часто обходятся без кастомных скриптов.
• Поддержка платформ (OpenBSD) требует доработки низкоуровневого IO (kqueue). Статическая линковка зависимостей в Zig упрощает деплой, но динамические библиотеки (libc, GUI) остаются.

Fil-C — это C/C++-совместимый язык с безопасной памятью и современным инструментарием. Его сердце — FUGC, параллельный, конкурентный, точный, неперемещающий сборщик мусора.

Ключевые черты FUGC

• Параллельность: маркировка и очистка выполняются на всех ядрах.
• Конкурентность: потоки-мутаторы не останавливаются; блокировки только на медленных путях аллокации.
• On-the-fly: нет глобальной паузы; «мягкие рукопожатия» просят потоки асинхронно сканировать стек.
• Grey-stack: повторное сканирование стеков до фикс-поинта; барьер только при записи, быстрая сходимость.
• Dijkstra-barrier: при записи указателя объект помечается CAS-relaxed.
• Точность: LLVM-плагин FilPizlonator точно знает, где все указатели.
• Неперемещаемость: объекты не двигаются; освобождённые блоки «перенаправляются» через InvisiCap.

Safepoint-механизм

• Компилятор вставляет pollcheck: быстрая проверка или колбэк для GC.
• «Мягкое рукопожатие» запускает колбэк на всех потоках.
• Состояния enter/exit позволяют блокироваться в syscall без pollcheck’ов; GC сам выполняет колбэк для «exited» потоков.
• Safepoint защищает от гонок: загруженный указатель будет жив до следующего safepoint’а.

По желанию можно включить полный stop-the-world (FUGC_STW=1) для fork(2) или отладки.

• Fil-C — это С-компилятор с точным параллельным GC (FUGC) и capability-указателями, позволяющий запускать «как есть» CPython, SQLite, OpenSSH и др., теряя в худшем случае 4× производительности.
• Вместо ручного free и UB-оптимизаций LLVM код живёт под барьером Дейкстры и soft-handshake safepoint’ами; указатели превращаются в «InvisiCap» (base+offset), теряющие силу при приведении к integer.
• Проект исследовательский, но уже промышленно полезен: нет сборок под 32-бит, Windows и embedded без MMU, нет пока поколенческого GC и ARM/RISC-V.
• Споры: «lock-and-key» предсказуемее RAM, но требует атомиков; GC = «мусор потом» vs compile-time проверки; можно ли дождаться AI-стат-анализа вместо Rust-переписей.

Я написал What the Fork — кроссплатформенный визуализатор сборки C/C++ (и не только).
Запуск: wtf make, wtf cargo build, wtf gradle build, wtf -x для Xcode и т.д.

Инструмент показывает все процессы, включая скрытые вызовы ld, и ищет типичные проблемы:

• отсутствие -j у make,
• однопоточная компиляция,
• повторяющиеся cmake/make-шаги,
• непараллельные CI-сборки.

Как работает
Сборка = дерево команд. Чтобы увидеть всё, ловим системные вызовы fork/exec/exit:

• macOS — Endpoint Security API,
• Linux — ptrace,
• Windows — Event Tracing (самое мерзкое API).

Что уже нашли

• cargo собирал зависимость одним потоком вместо 10× ускорения.
• ninja при сборке LLVM держит 12 задач на 10 ядрах — почти идеал.
• CMake 85 раз подряд вызывает xcode-select, sw_vers, cmake/make → clang, не используя параллелизм.

Инструмент открыт для тестов — попробуйте на своём проекте.

• Пользователи восторженно реагируют на новый визуализатор сборки, особенно те, кто застрял на CMake/GCC/Make без clang/ninja и не может понять, почему сборка тормозит.
• Просят сразу показать GIF-демонстрацию под заголовком статьи и спрашивают, будет ли macOS-версия и открытый код.
• Некоторые делятся опытом: strace/dtruss, ninjatracing, vcperf, cargo --timings, Instruments и другие инструменты уже решали похожие задачи.
• Предложения расширить функциональность: добавить flame-графы процессов, поддержку fork(), интеграцию с Bazel Build Event Protocol, оценку «осталось времени» по историческим данным.
• Отдельные комментарии касаются маркетинга (сменить название), сравнения с VS/Xcode, а также шуток про TEEP/OEE завода и «LLVM, завари кофе».