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. Важная оговорка: если при обновлении система перезагружается в старую версию, проверьте наличие монитора, иначе процесс может завершиться неудачей.

В списке рассылки openbsd-ports представлен новый порт Wine для OpenBSD — вероятно, самый неожиданный за год. Это коллективная работа: прорыв обеспечило программное решение Андрея для проблемы с регистром %gs — «нельзя установить gsbase, поэтому мы эмулируем префикс %gs на командах». Основную нагрузку взяли на себя Андрей и Фабьен.

Интерес к Wine заметно вырос по сравнению с ситуацией 5–10 лет назад, поскольку множество Windows-программ перешло на 64-битную архитектуру. Уже протестированы десятки 64-битных приложений, в основном успешно: есть скриншоты и записи трансляций, а недавно вышедший ремастер The Witcher 3 работает хорошо (требуется добавить vkd3d-proton). Главное ограничение — не работает WoW64, поэтому 32-битные программы пока не запускаются; проверить разрядность файла можно утилитой file(1). Встроенные тесты временно отключены: для них нужен доступ к X-серверу, и часть тестов зависает, хотя в реальных играх этого не наблюдалось. Для проверки советуют Notepad++ как простое 64-битное приложение, запускать на свой риск и лучше под отдельным непривилегированным пользователем — возможно, удастся ограничить его через unveil(2).

Обсуждение дополняет статью реальными реакциями сообщества: от восторга по поводу запуска Windows‐приложений на OpenBSD до скептицизма относительно графической поддержки, вопросов о поддержке CVS и стратегии поддержания порта, а также упоминаний о потенциальных преимуществах безопасности и объёме требуемых усилий. Большинство комментаторов радуются появлению Wine на OpenBSD, отмечая рост интереса к играм и приложениям Windows в BSD‐сообществе. Совет: Автор t‐3 советует помечать все изменения как OpenBSD‐only, чтобы упростить поддержку, с возможным будущим upstream‐проектом. Спор: С одной стороны, пользователи (greyw) опасаются, что OpenBSD отстанет в графике, а с другой – есть вопросы о наличии 3‐D драйверов и их качестве. Несмотря на то, что OpenBSD всё ещё использует CVS, комментатор ninjin подчёркивает, что система работает надёжно для всех поддерживаемых платформ. Совет: Maken отмечает, что VKD3D работает «из коробки», но стек абстракций хрупок, поэтому рекомендуется тщательное тестирование. raverbashing задаёт вопрос о текущем состоянии поддержки 3D/OpenGL в OpenBSD, указывая на неопределённость практической игровой совместимости. Совет: j45 указывает, что наличие Wine на BSD может обеспечить безопасный способ запуска устаревших Windows‐приложений, изолируя их от основной системы. throwaway27448 интересуется, сколько работы и какие OpenBSD‐специфичные детали требуются для создания работающего порта, показывая интерес к оценке усилий.

В 2026 году автор запустил коммерческий веб-сервис — marketyour.games — полностью на C через CGI, без фреймворков, контейнеров или отдельного сервера баз данных. Стек: OpenBSD, httpd, SQLite и статически скомпилированный бинарник. Все активы встроены в исполняемый файл, запросы обрабатываются через fork-процессы, а обновление — заменой одного файла без простоя. Использованы только три библиотеки: libcurl, libsodium и libcjson (включён как один файл), SQLite — в виде амальгамации. Система работает без JavaScript, поддерживает Stripe, Postmark и пользовательские аккаунты, при этом полностью изолирована через pledge, unveil и chroot.

Преимущества — полная прозрачность: нет слоёв абстракции, отладка — как у обычной программы через gdb, HTTP-логика проста и неизменна с 2004 года. SQLite устраняет необходимость в управлении сервером БД. Недостаток — отсутствие базовых утилит: автор сам написал cgi.h для обработки кук, параметров и валидации, но хотел бы стандартных библиотек в стиле stb. CGI не устарел — современные ядра эффективно оптимизируют fork, а FastCGI остаётся простым шагом вперёд. Стек оказался проще, надёжнее и легче в поддержке, чем любые современные решения.

Чистый C‐CGI‐подход прост, но в реальных проектах требует дополнительных мер: наблюдаемости (метрики, логирование, алертинг отсутствуют), конкурентного доступа к SQLite (каждый запрос открывает отдельный процесс, риск блокировок при записи), безопасности (уязвимости, риск RCE — нужна проверка кода и дополнительная защита) и удобства деплоя. Альтернативы: Go‐бинар без CGO (всё в одном файле, удобен для контейнеров), Rust‐фреймворки (Tokio, Actix — безопасность и производительность без проблем с памятью), FastCGI на C (стабильно работает, например, на FreeBSD с PostgreSQL). Простота архитектуры выигрывает в небольших проектах, но минимализм требует компромиссов. BusyBox содержит CGI‐bin — позволяет быстро развернуть веб‐интерфейс без отдельных серверов. Nginx не поддерживает CGI из коробки — нужен сторонний модуль или Lighttpd. Исторически в 1990‐х CGI‐скрипты писали на Perl, а не на C. Для безопасности C‐кода полезны инструменты вроде Fil‐C (проверка памяти). Отсутствие примеров кода в статье усложняет понимание — полезно добавить демонстрации запросов и ответов. Критика простоты C‐подхода в обсуждении почти отсутствует — возможно, недостаточно обсуждены потенциальные проблемы. Bash‐скрипты показывают минималистичный веб‐сервер, но не подходят для продакшна.

Компиляция 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) остаются.