Hacker News Digest

Автор сравнивает производительность FreeBSD, SmartOS, NetBSD, OpenBSD и Linux для статического хостинга на мини-ПК Intel N150. Тестирование проводилось с использованием nginx по протоколам HTTP и HTTPS с почти стандартными настройками без оптимизации ядра под конкретную ОС. Автор скептически относится к бенчмаркам, так как они отражают лишь специфическую рабочую нагрузку на конкретной конфигурации, но признает, что иногда полезно провести сравнительные тесты.

В предыдущих исследованиях он уже сравнивал Proxmox KVM с FreeBSD bhyve, а также Jails, Zones, bhyve и KVM на том же железе. На этот раз фокус сместился на более практическую задачу — статический хостинг. Как отмечает автор, "с выбором ОС для обычного HTTP на этом мини-ПК дело обстоит не так критично, как многие думают", но ситуация усложняется с появлением TLS. Интересно, что бездействующие bhyve VM потребляют меньше ресурсов на хосте illumos, чем на FreeBSD, что демонстрирует эффективность платформы.

• Обсуждение охватывает вопросы от производительности и безопасности до совместимости и ценовой политики, но не упоминает включение kTLS и sendfile(), что могло бы повлиять на результаты теста.
• Участники обсуждают, что тест может быть ограничен количеством доступных портов из-за особенностей TCP, и что тест может не учитывать влияние HTTP/2 и HTTP/3.
• Также обсуждается отсутствие ECC-RAM в большинстве этих систем, отсутствие 2-го M.2 слота и отсутствие 2.5G/5Gbe NIC в большинстве этих устройств.
• Участники также обсуждают ценовую политику, дефицит RAM и SSD, и то, что эти устройства могут стоить дороже из-за этого.
• В конце обсуждение смещается к тому, что эти устройства могут быть использованы как NAS или эмулятор игровых приставок, и что в некоторых случаях эти устройства могут быть использованы как десктоп системы.

Автор обнаружил удивительное поведение shebang (#!) в Unix-системах: ядро Linux, FreeBSD и OpenBSD поддерживает не только абсолютные, но и относительные пути в shebang. Например, можно использовать "#!python3", "#!bin/python3" или "#!../../../usr/bin/python3", и они будут работать при правильном расположении текущего каталога. Это поведение существует с 4.2 BSD (1983 год) и реализовано через вызов namei(), который разрешает пути так же, как и для обычных файлов.

Несмотря на потенциальные проблемы безопасности, такое поведение сохранилось во многих системах. Автор предполагает, что это связано с простотой реализации в ядре и законом Хайрума (Hyrum's Law) - вероятно, кто-то уже использует эту функциональность и зависит от неё. Интересно, что даже OpenBSD, известный вниманием к безопасности, не изменил это поведение.

• Проблема с #!/bin/bash в NixOS и других системах, где bash не в /bin, подчеркивает важность использования #!/usr/bin/env bash для переносимости.
• Обсуждение подчеркивает, что #!/usr/bin/env bash является наиболее переносимой формой, так как она использует $PATH для поиска bash.
• Несколько участников подчеркивают, что #!/bin/bash может не работать в некоторых системах, где bash не в /bin.
• Обсуждение также затрагивает безопасность: #!/usr/bin/env bash может быть опасен, если не указан полный путь, так как это может привести к запуску нежелательного кода.

• OpenBSD 7.8 вышел, и участники обсуждают его достоинства: минимализм, безопасность и отсутствие лишнего кода.
• Пользователи делятся опытом: кто-то использует OpenBSD как основную систему, кто-то как фаервол, кто-то как маршрутизатор.
• Обсуждается поддержка различного оборудования, включая Raspberry Pi 5 и ThinkPad.
• Участники обсуждают, что OpenBSD не поддерживает некоторые современные технологии, такие как Bluetooth и Wi-Fi 6.
• Некоторые пользователи отмечают, что OpenBSD не поддерживает некоторые современные технологии, такие как Bluetooth и Wi-Fi 6.

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

Поисковая система DuckDuckGo второй год подряд пожертвовала 25 тысяч долларов Фонду Perl и Raku для поддержки развития языка программирования. Эти средства направляются в Фонд поддержки ядра Perl, который финансирует ключевые улучшения языка.

Среди недавних достижений — модуль builtin, система классов, лексические методы и стабилизация экспериментальных функций вроде сигнатур и try/catch. Разработчик Пол Эванс, получающий финансирование от фонда, внёс значительный вклад в эти нововведения. Многолетняя поддержка спонсоров позволяет фонду увереннее планировать будущее и продолжать работу над развитием Perl.

• DuckDuckGo пожертвовала $25k проекту Perl в рамках благотворительных взносов на общую сумму $1.1M
• В сообществе ведутся дебаты о современной релевантности Perl, где одни отмечают его упадок после неудачи с Perl 6, а другие защищают его как мощный и полезный язык
• Участники делятся личным опытом работы с Perl, отмечая его влияние на их карьеру и сложности, такие как проблемы с версиями библиотек
• Perl продолжает использоваться в крупных компаниях (Craigslist, eBay) и проектах с открытым исходным кодом (OpenBSD)
• Обсуждается необходимость и способы поддержки open-source проектов через публичные пожертвования от брендов

• Модуль: src

• Изменил: mglocker@cvs.openbsd.org, 01.09.2025

• Файлы:
  distrib/arm64/iso/Makefile
distrib/arm64/ramdisk/Makefile install.md list

• Суть: добавлена поддержка Raspberry Pi 5 Model B в RAMDISK.

• Проблемы:

  • Не грузится с PCIe-накопителей (нет U-Boot).
  • Wi-Fi на платах «d0» не работает.
  • Кулер не крутится — отсутствуют драйверы PWM/clock.

Утверждено: kettenis@, deraadt@

• На Raspberry Pi 5 и CM5 в OpenBSD пока не работает Wi-Fi (на «d0»-ревизии плат) и не крутится активный кулер — не хватает драйверов PWM/clock.
• Поддержка всё ещё неполная: аппаратный старт происходит через GPU, документации мало, поэтому U-Boot и драйверы догоняют медленно.
• На Pi 4 OpenBSD уже запускается стабильно, но нужны свежие прошивка и UEFI, а также сторонний firmware для использования >3 ГБ ОЗУ.
• Плюсы OpenBSD на ARM: чистая и последовательная система, «всё в базе» (httpd, spamd, WireGuard через ifconfig), можно носить «сервер в кармане».
• Минусы: нет power-saving на ARM64, после неожиданного отключения могут поломаться системные файлы, а список поддерживаемого «железа» ограничен.

Коллега нашёл в ARM-дизассемблере кучу «лишних» инструкций d4d4 (bmi #-0x58), которые никогда не выполняются.

Минимальный пример:

00020100 <one>:
   20100: 4770  bx lr
   20102: d4d4  bmi …

bx lr возвращает из функции, так что d4d4 недостижима.
Мысль: выравнивание? Thumb-команды 16-битные, но компилятор не выравнивает функции на 32 бита.

Добавляем вторую функцию — d4d4 исчезает.
Третья — d4d4 снова появляется, но только после последней функции.

Смотрим объектный файл: компилятор d4d4 не вставляет. Значит, линковщик lld добивает секцию до 32-битной границы именно этой командой.
Меняем порядок файлов — «лишняя» инструкция перемещается в начало следующего модуля, подтверждая гипотезу.

GNU ld вместо d4d4 ставит нули.

• Коммит 2017 года в OpenBSD закладывал «trapsleds» — заполнение «дырок» в исполняемых секциях инструкциями-ловушками (trap), чтобы сорвать NOP-sled-эксплойты.
• На ARM32/Thumb ожидалось 0xD4 (BRK) или 0xBE (BKPT), но в режиме Thumb та же последовательность байтов декодируется как условный переход назад, превращая «ловушку» в потенциальный ROP-гаджет.
• Это делает защиту нерабочей на Cortex-M (только Thumb), что участники признают ошибкой/«сломанной» митигацией.
• Некоторые считают, что описание механизма в коммит-сообщении достаточно, другие требуют комментариев в коде, чтобы избежать подобных недоразумений.

OpenBSD быстрее Linux в 10 раз?
Тест Jann Horn: создаём поток, оба потока открывают по 256 сокетов.

Linux

elapsed: 0.017–0.026 s

OpenBSD

ulimit -n 1024
elapsed: 0.002–0.006 s

Машины примерно равны. Подсказка в коде (не в сетевом стеке).
Обычно OpenBSD проигрывает в странных тестах, а тут — наоборот.

• Обсуждение выросло из «патологического» теста, который на Linux показывает замедление из-за роста таблицы файловых дескрипторов и блокировок, а на OpenBSD — нет.
• Участники спорят, что считать «быстрым»: OpenBSD жертвует скоростью ради безопасности, тогда как Linux активно оптимизирует критические пути.
• Для микробенчмарков советуют использовать __rdtsc(), но предупреждают о проблемах синхронизации TSC между ядрами и на ARM.
• Несколько человек отвлеклись на «пасхалку» в статье — плавающие «пушки», стреляющие курсором.
• Общий вывод: измеряйте свою нагрузку на одинаковом железе; универсального «быстрее» не существует.