Hacker News Digest

В NetBSD отсутствует полноценная технология sandboxing, в отличие от FreeBSD (jails) и Linux (namespaces). Существующий chroot считается слабым механизмом изоляции, так как ограничивает только представление файловой системы, но не изолирует сеть, IPC и монтирование. Предыдущие попытки реализации изоляции на уровне ядра с помощью инструментов gaols, mult и netbsd-sandbox не были интегрированы в систему.

В рамках Google Summer of Code 2025 планируется реализовать механизм, подобный Linux namespaces, используя bubblewrap. Проект фокусируется на двух типах namespace: UTS (для управления именем хоста) и mount (для изоляции файловых систем). Реализация будет использовать системные вызовы unshare или clone, а в ядре NetBSD - подсистему kauth для управления авторизацией и жизненным циклом credential. Это позволит не только добавить изоляцию приложений, но и улучшить совместимость с Linux-бинарниками через существующий compat_linux.

• Bubblewrap — основа песочницы Flatpak, используется для изоляции приложений (например, Claude Code/Codex/Gemini CLI) с контролем доступа к системе.
• NetBSD выделяется полной бит-в-бит воспроизводимостью бинарников и вендорингом GCC, что обеспечивает воспроизводимость всей цепочки инструментов; Golang также обеспечивает воспроизводимость реестра пакетов.
• Полные окружения рабочего стола (labwc, KWin, Plasma) могут запускаться через bwrap с привязкой устройств и временных файлов, с возможностью ограничения доступа.
• Sandbox-инструменты (bubblewrap, firejail) имеют ограничения в Linux, особенно на десктопе; AppArmor предлагает профили с автоматическим определением разрешений.
• Guix и FreeBSD (v15) также рассматриваются в контексте воспроизводимости сборок и безопасности.

SSA (Static Single Assignment) — это популярная форма промежуточного представления, используемая в большинстве современных компиляторов, включая LLVM, GCC, V8 и HotSpot. Её главная сила — в упрощении анализа и оптимизации программ. SSA преобразует императивный код с изменяемыми переменными в форму, где каждая переменная присваивается только один раз, что делает зависимости между значениями явными и легко отслеживаемыми.

Эта трансформация превращает программы с состоянием в комбинационные схемы без памяти, значительно упрощая оптимизации. Вместо отслеживания изменений переменных по всему коду компилятор может работать с чётко определёнными зависимостями. Например, программа с множественными присваиваниями одной переменной преобразуется в несколько переменных, каждая из которых имеет одно назначение, что позволяет легко находить и устранять избыточные вычисления.

• Обсуждение разошлось в сторону: от обсуждения SSA как формы IR и её влияния на оптимизации, к дискуссии о том, что такое SSA, как она соотносится с CPS и какие у неё есть trade-off'ы, а также к тому, что именно делает SSA «особенной» и как она влияет на компиляторы и языки.

Крупные компании, включая Google и Meta, вкладываются в развитие BPF для Linux, чтобы ускорить обработку сетевых пакетов и улучшить безопасность. Теперь инструментарий GCC тоже получает поддержку BPF, что расширяет возможности компиляторов для этой технологии.

Основное внимание уделяется интеграции BTF (формат типа BPF) и CTF (компактный формат типа C), которые позволяют эффективно работать с типами данных в BPF. Это важно, чтобы обеспечить совместимость и оптимизацию. В GCC добавлены атрибуты btf_decl_tag и btf_type_tag, которые помогают аннотировать код для лучшей проверки и безопасности.

Эти усилия направлены на то, чтобы GCC могла стать полноценной альтернативой существующим инструментам для BPF, таким как LLVM, что особенно важно для встраивания BPF в различные среды и системы. Работа также включает улучшения в тестировании и отладке, чтобы обеспечить надежность.

• Обсуждение вращается вокруг лицензии LLVM и Apache 2.0, их совместимости с GPL и влияния на свободное ПО.
• Участники спорят о том, что означает «свободное ПО» и какие лицензии считаются «свободными» в 2024 году.
• Обсуждается, что означает «свободное ПО» и какие лицензии считаются «свободными» в 2024 году.
• Участники обсуждают, что такое «свободное ПО» и какие лицензии считаются «свободными» в 2024 году.

Ричард Столлман выступает против превращения GCC бэкенда в библиотеку, аргументируя это защитой свободного программного обеспечения. Он предупреждает, что компании неизменно стремятся сделать ПО несвободным, и некоторые создали бы несвободные дополнения к GCC, если бы им это позволили. Именно требование GPL заставило авторы фронтендов для C++ и Objective-C сделать их свободными, так как они не могли использовать их иначе. Столлман подчеркивает: "Все, что упрощает использование GCC бэкендов без фронтендов, ставит под угрозу наше влияние на то, чтобы новые фронтенды оставались свободными".

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

• Пропущенное предложение интегрировать LLVM в GCC стало ключевым событием в истории компиляторов, но оно было упущено из-за сбоя в почтовой переписке.
• Это стало причиной того, что LLVM вместо того, чтобы стать частью GCC, стал основой для большинства новых языков и проектов.
• Парадокс в том, что GCC и LLVM сегодня по сути предлагают одинаковую производительность, но LLVM лицензирован более свободно, что способствует его популярности.
• В то же время, GCC остаётся под GPL, что отталкивает некоторых разработчиков, которые не хотят, чтобы их код был связан с GPL.
• В конечном счёте, это привело к тому, что LLVM стал основой для большинства новых языков программирования, в то время как GCC медленно движется к облесению.

В проекте Git предложено постепенное внедрение Rust в ядро системы, начиная с версии 3.0. Это тестовый шаг, аналогичный прошлым экспериментам с C99, чтобы дать сообществу время адаптироваться к новым требованиям инструментария. Первым кандидатом для перевода выбран модуль varint.c из-за его простоты и отсутствия зависимостей — уже реализованная версия на Rust прошла все тесты.

Пока поддержка Rust добавлена только в систему сборки Meson, с планами расширения на Makefiles. Также предстоит настроить CI-задачи для проверки сборки, форматирования кода и других аспектов. Это позволит поэтапно развивать инфраструктуру без немедленных обязательств, фокусируясь на процессе интеграции, а не на конкретных функциях.

• Предложение сделать Rust обязательной частью инфраструктуры сборки Git 3.0, пока как опциональная зависимость, с переходом на обязательную после появления поддержки в GCC.
• Высказаны опасения о снижении портируемости из-за ограниченной поддержки платформ Rust, сложности инструментария и повышении порога входа для новых разработчиков.
• Часть сообщества видит в этом ненужное усложнение для зрелого проекта и сомневается в целесообразности из-за малого объема нового кода.
• Другие считают, что Rust улучшит безопасность и консолидирует код, заменив существующие скриптовые языки, и что изучение нового языка — норма для разработчиков.
• Обсуждение включает технические детали о кросскомпиляции, поддержке различных архитектур и влиянии на такие проекты, как libgit2.

Проект предлагает необычный взгляд на C++ как на интерпретируемый язык, оспаривая традиционное представление о нём исключительно как о компилируемом. Автор демонстрирует, что с помощью современных инструментов и техник C++ можно использовать в интерактивном режиме, подобно Python или JavaScript. Это открывает возможности для быстрого прототипирования и экспериментальной разработки без необходимости полной перекомпиляции.

Ключевая идея заключается в использовании JIT-компиляции и REPL-окружений, что делает C++ более гибким и доступным для исследовательских задач. Такой подход может сократить время разработки и упростить тестирование идей, сохраняя при этом все преимущества производительности и низкоуровневого контроля, характерные для C++.

• Участники обсуждают техническую реализацию проекта, предполагая использование метапрограммирования шаблонов, DSL и специальных флагов компилятора (GCC/Clang).
• Высказывается недоумение и замешательство по поводу принципов работы проекта, а также желание получить более подробное текстовое объяснение.
• Предлагаются альтернативные инструменты для интерпретации C++ (Clang-Repl, Xeus cling, AngelScript).
• Несколько пользователей делятся положительными впечатлениями от видео и творческого подхода автора.
• Один из комментариев содержит ироничное замечание о значении слова "based" в данном контексте.

• AMD на IFA-2025: «x86 уже не менее экономичен, чем Arm»
• Компания уверена, что ноутбуки на Ryzen и Core живут столько же, сколько Arm-решения, при этом сохраняют совместимость с огромной экосистемой x86
• AMD считает, что энергоэффективность определяется не архитектурой, а всей платформой: ядро, GPU, память, ПО
• Проект K12 на Arm был закрыт: выгоды от перехода на другой ISA оказались несоразмерны потерям совместимости

• Эксперты сходятся: ISA (x86, ARM, RISC-V) почти не влияет на энергоэффективность; решают микроархитектура, техпроцесс, uncore, PMIC и ОС.
• Apple M — лидер не из-за ARM, а благодаря интеграции памяти, тонкому управлению питанием и приоритету эффективности.
• Современные x86 (Lunar Lake, Strix Halo) подтянулись по idle, но при нагрузке всё ещё уступают M4 в производительности/Вт.
• ARM-системы всё ещё страдают от хаоса загрузки (no UEFI, vendor-kernel), тогда как x86/PC стандартизированы с BIOS/UEFI.
• Для мелких ядер (MCU) простой ISA важен; для высокопроизводительных ядер декодер «съедает» <1 % площади и энергии.
• Всё сводится к реализации: тот же GCC на x86 генерирует RISC-подобные инструкции, а различия даёт предсказатель, кэши, техпроцесс.

Guix, функциональный менеджер пакетов вдохновлённый Nix, скоро исчезнет из Debian 12 и 13. Причина — серьёзные уязвимости (CVE-2025-46415/6) в guix-daemon, позволяющие повысить привилегии, и невозможность безопасного бэкпорта: исправления перемешаны с другими изменениями, а проект не выпускает стабильные ветки. Последний релиз Guix 1.4.0 вышел в 2022 г.; проект использует rolling-release. Мэйнтейнер Debian Вагрант Каскадиан признал, что изолировать патчи безопасности «сложнее, чем раньше». Denis Carikli собрал ≈50 патчей в стороннем репозитории, но их качество не подходит для дистрибутивов. Удаление Guix из Debian повлечёт за собой исчезновение пакета из других дистров, использующих его как upstream.

• Guix в Debian отстаёт из-за политики «одна стабильная версия библиотеки» и заморозки релизов; обновить до свежей «ванильной» Guix мешают правила только-багфиксов и совпадение с CVE.
• Пакет не собирается GCC ≥ 2025-04 из-за несовместимости со стандартами C23/C++23.
• Popcon показывает <230 установок, но большинство пользователей Debian отключают статистику, так что реальная аудитория выше.
• Некоторые считают, что Guix лучше запускать bare-metal или в Hurd, а не пытаться вписать в Debian.
• Общий вывод: разные философии релиз-циклов приводят к конфликту, и поддержка Guix в Debian требует непропорционально много усилий.

Ultrassembler — библиотека RISC-V-ассемблера, встроенная в проект Chata.
В отличие от as и llvm-mc, она вызывается прямо из C++, без system() и временных файлов, что критично для встроенных систем.

Скорость

Тест на 16 тыс. инструкций:

• Ultrassembler ≈ 10× быстрее as, 20× быстрее llvm-mc.
• 1 RISC-V инструкция ≈ 1000 x86-инструкций (у конкурентов 10–20 тыс.).
  Код на чистом C++; можно добавить ассемблерные вставки.

Ключевые оптимизации

Исключения

GCC-реализация «zero-overhead»: штрафа нет, пока исключений нет.
Ошибки встречаются редко и видны человеку, поэтому даже 1 с на обработку незаметна.
std::expected дал −10 %, так как нормальный путь стал дороже.

Быстрые структуры

2000+ RISC-V-инструкций требуют мгновенного поиска.
Вместо std::unordered_map используется perfect-hash таблица от gperf, генерирующая O(1) без коллизий.
Размер таблицы компактен, кэш-эффективен.

Парсинг

• Регистры идентифицируются по первым 2–3 символам через switch.
• Нет std::string, только std::string_view и статические буферы.
• Лексемы разбираются за один проход без регулярных выражений.

Кодогенерация

• Шаблоны на этапе компиляции формируют битовые маски инструкций.
• Варианты одной инструкции разворачиваются в constexpr-таблицы, что убирает ветвления в рантайме.

Память

• Все выделения через стековые std::array/std::string_view.
• Нет new/malloc, следовательно, нет аллокационных штрафов и кэш-промахов.

Платформенные трюки

• [[likely]]/[[unlikely]] для подсказок ветвления.
• __builtin_expect там, где компилятор не догадывается.
• LTO + PGO дают ещё 5–7 %.

Итог

Ultrassembler показывает, что «низкоуровневый» C++ без искусственных ограничений может обгонять даже оптимизированные GNU-утилиты.

• В обсуждении разобрали миф о «системном вызове при каждом росте контейнера» — реальные аллокаторы переиспользуют память и делают syscall лишь при нехватке.
• Участники напомнили, что исключения в C++ не «zero-overhead»; есть компромисс между временем и памятью, и g++ выбирает экономию места.
• Автор статьи подтвердил: пробовал хеширование, но дерево разбора оказалось быстрее; flex/bison тут не при чём, скорее gperf.
• Некоторые посоветовали LLVM C++ API, memory-mapped I/O и std::pmr для ускорения и упрощения кода.
• Большинство сходится: современные ассемблеры и так быстрые, задача скорее академическая, но как «посмотреть, насколько можно ускорить» — интересна.

Debian 13 «trixie» вышла после двух лет разработки: 14 000 новых пакетов, APT 3.0 по умолчанию и официальная поддержка 64-битного RISC-V.
Версии ПО: GNOME 48, Plasma 6.3, Xfce 4.20, Emacs 30.1, LibreOffice 25.2, ядро 6.12.41 LTS, GCC 14.2, Rust 1.85, Python 3.13, systemd 257.
Поддерживаемые архитектуры: amd64, armhf, arm64, ppc64el, s390x, riscv64. i386 исчез, armel последний релиз.

Обновление из bookworm возможно: конвертируйте sources.list в DEB822 (команда apt modernize-sources появится только в trixie), удалите сторонние пакеты и проверьте, что имена сетевых интерфейсов могут измениться.

Установка: от 64 МБ netboot-ISO до образов Blu-ray; для больших образов рекомендуют BitTorrent или jigdo.

• Некоторые пользователи считают «unstable» (sid) вполне стабильной для ежедневной работы, другие подчеркивают, что всё же бывают серьёзные сбои.
• Многие узнали о новом инструменте extrepo для подключения внешних репозиториев, но на Trixie пока встречаются проблемы с зависимостями.
• Trixie хвалят за «дружелюбие» к пользователю и свежие пакеты, однако NVIDIA-драйверы и CUDA-репы пока не обновлены, что вызывает головную боль.
• Для более новых версий ПО советуют backports, Flatpak или официальные deb-пакеты Mozilla, чтобы не ждать ESR.
• Серверные админы считают Debian лучшим выбором для продакшена, но на десктопе ему иногда не хватает свежести.

Краткий обзор

• Проблема: компилятор Solidity (solc) падает на Ubuntu 22.04 при компиляции корректного кода.
• Причина: сочетание трёх факторов
  1. 12-летний баг G++ (< 14) в разрешении перегрузок.
  2. Устаревший паттерн сравнения в Boost.
  3. Новые правила симметричных сравнений C++20.

Цепочка событий

1. Баг G++ (2012, GCC-53499): при boost::rational<T> == 0 компилятор до 14-й версии выбирает нечлен-шаблон вместо член-шаблона.
2. C++20 добавляет автоматическую перестановку аргументов: 0 == rational<T> → rational<T> == 0.
3. Boost 1.74 предоставляет обе версии оператора, что приводит к бесконечной рекурсии и переполнению стека.

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

template<typename T>
struct rational {
    template<class U>
    bool operator==(const U&) const { return true; }
};

template<class U, class T>
bool operator==(const rational<T>&, const U&) { return false; }

int main() {
    rational<int> r;
    return r == 0;   // g++11 выбирает free-функцию
}

Как починить

• Обновить GCC ≥ 14 или Clang, или
• Собрать Solidity без C++20 (-std=c++17), или
• Патч Boost/использовать свежий Boost ≥ 1.82.

Итог
Ни один компонент по отдельности не «сломан», но их комбинация приводит к крашу компилятора на валидном коде.

• 12-летний баг разрешения перегрузок в GCC + новый оператор <=> C++20 = краш компилятора Solidity.
• Проблема в том, что «каждый компонент по отдельности не сломан», но вместе дают сбой.
• Участники обвиняют чрезмерную сложность C++, отсутствие тестов при обновлении стандарта и «бесконечные надстройки» вроде spaceship-оператора.
• Кто-то предлагает «python2to3-момент» для C++, другие считают смарт-контракты плохой идеей из-за неизбежных багов.
• Лицензия SPDX в примере вызывает вопросы, но Solidity требует её наличие, иначе ошибка компиляции.

Ampere One 192-ядерный сервер, 1 ТБ ОЗУ, цель — запустить максимум виртуальных IoT-устройств на Nerves.

Прошлый раз добрались до 500 экземпляров; теперь с KVM и новым загрузчиком little_loader от Frank Hunleth удалось 5000 одновременных виртуальных ARM64-машин.
little_loader — минимальный ARM64-бутлоадер, читающий переменные u-boot, загружающий ядро Linux и сохраняющий механизмы A/B-обновлений Nerves.

Что изменилось

• KVM/HVF ускоряет старт до 1-2 с и экономит ≈ 500 МБ ОЗУ на гость.
• EL1 вместо EL2: EL2 нужен для вложенной виртуализации, нам не требуется.
• Баг компиляции: release-сборка зависает, debug-версия работает (GCC 15, вероятно, чинит).

Команда запуска (упрощённый пример):

qemu-system-aarch64 \
  -machine virt,accel=kvm \
  -cpu host -smp 1 -m 150M \
  -kernel little_loader.elf \
  -netdev user,id=eth0 \
  -device virtio-net-device,netdev=eth0 \
  -drive if=none,file=disk.img,format=raw,id=vdisk \
  -device virtio-blk-device,drive=vdisk \
  -nographic

Итог: 5000 «эрлангов» на 192 ядрах, 1 ТБ ОЗУ, стартуют за секунды, потребляют по 150 МБ RAM.

• Речь идёт о запуске 5000 узлов BEAM (Erlang-машин), а не процессов — каждая BEAM может держать миллионы лёгких процессов.
• Сервер с 192 Ampere-ядрами позиционируется как «облачный» или «edge» для телекомов; Hetzner предлагает 80-ядерный Ampere за ~200 $/мес.
• Пользователи сомневаются в полезности без тестов под нагрузкой и обсуждают, как масштабировать память и шину при таком числе ядер.
• Всплыли исторические примеры (Azul для Java) и шутки про «ручное ткачество» Erlang-потоков и «фермерский» байт-код.