Hacker News Digest

Автор столкнулся с загадкой в Nix: имея бинарник Ruby, он не мог найти соответствующий .drv файл, хотя база данных и кэш NixOS указывали на его существование. Команда nix-store --query выдавала ошибку, а файл отсутствовал в системе, хотя nix derivation show находил совершенно другой .drv файл для того же бинарника. Это противоречило его пониманию работы Nix.

Ключ к разгадке — "fixed-output derivations" (FOD). Автор демонстрирует, что изменения в FOD (даже добавление мусорных атрибутов) изменяют путь самого .drv файла, но не затрагивают выходной путь (/nix/store/...). Это свойство "modulo" означает, что выходные пути зависят только от содержимого, а не от метаданных. В результате для одного бинарника может существовать несколько .drv файлов с разными хэшами, что объясняет парадокс: кэш NixOS указывает на один .drv, а nix derivation show находит другой, но оба ведут к одному и тому же выходному пути.

• Проблема deriver в Nix — это давняя проблема, которая не решается, потому что она не может обеспечить трассируемость от вывода к исходному выражению, что и было первоначальной целью.
• Пользователи сталкиваются с путаницей, когда кэш бинарников не совпадает с локальной оценкой, что приводит к непониманию и неэффективному использованию кэша.
• Появление CA-derivations и фиксированных выводов (fixed-output derivations) усугубляет ситуацию, делая проблему более заметной, но не решает ее.
• Сообщество обсуждает, что необходимо переписать Nix с нуля, чтобы устранить такие архитектурные проблемы, включая проблему deriver.
• Некоторые участники обсуждения подчеркивают, что Guix может быть альтернативой, но его недостаток в количестве пакетов делает его менее привлекательным.

• TinyKVM путают с PiKVM/PicoKVM (аппаратные KVM-переключатели) из-за схожего названия.
• Основной вопрос: можно ли использовать TinyKVM для изоляции GUI-приложений (например, Firefox) с ограниченным доступом к сети и файлам.
• TinyKVM сравнивают с Firecracker VM, но его фокус — на быстрой изоляции для серверного JS, а не на GUI.
• Упомянуты альтернативы: Qubes OS, Guix для изоляции и воспроизводимости, а также традиционные инструменты вроде bwrap/chroot.

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 требует непропорционально много усилий.