Hacker News Digest

Автор исследует, сколько усилий требуется для реализации собственных примитивов BEAM, создавая упрощенную версию виртуальной машины на Elm. Используя стиль передачи продолжений (CPS), он избегает необходимости писать парсер, CLI и другие компоненты полноценного компилятора, сосредоточившись на ядре системы. Этот подход позволяет сосредоточиться на основных концепциях, таких как планировщик, процессы и их взаимодействие.

Начав с базовых инструкций End (завершение программы) и Work (имитация выполнения работы), автор добавляет примитив Spawn для создания процессов, что требует изменения структуры планировщика для отслеживания нескольких процессов. В планах реализация обмена сообщениями, выборочного приема и связывания процессов для создания деревьев надзора. Ключевой особенностью подхода является использование CPS для упрощения реализации, где продолжения обрабатывают управление потоком выполнения.

• Обсуждение в основном вращается вокруг BEAM: его происхождение, ограничения и будущее.
• Участники обсуждают, что BEAM не переносим между дистрибутивами Linux, в отличие от JVM, и требует компиляции из исходников.
• Поднимается вопрос о том, что написание статьи не объясняет читателям, что такое BEAM, и что это значит для них.
• Некоторые участники предлагают использовать Nix или статически слинкованный BEAM для решения проблемы портируемости.
• Также обсуждается, что исходный код BEAM доступен, и что ранние версии BEAM, возможно, были бы полезны для изучения.

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

Fil-C - реализация C и C++ с безопасной памятью, позволяющая существующему коду работать безопасно без изменений. Несмотря на молодость проекта и одного активного разработчика, Fil-C уже компилирует весь безопасный пользовательский Linux. Это форк Clang с лицензией Apache v2.0, который изначально был медленным, но после оптимизации работает всего в несколько раз медленнее оригинала. Тест с Bash показал практически незаметную разницу в производительности.

Основная сложность проекта - обработка указателей. Текущая реализация "InvisiCaps" разделяет указатели на доверенную "capability" и недоверенную "address" части, позволяя им соответствовать естественному размеру архитектуры. Для поддержки безопасности Fil-C использует другую внутреннюю ABI, чем Clang, что требует полной перекомпиляции проекта. При выделении объекта в куче Fil-C добавляет два слова метаданных для проверки границ доступа и хранения дополнительной информации о указателях.

• Fil-C — это компилятор C → C, добавляющий проверки безопасности памяти, но при этом оставляющий программы полностью совместимыми с существующим кодом и не требующий изменений в исходном коде.
• Проект разрабатывается в рамках Nix, что позволяет легко собирать любые пакеты с Fil-C, а также предоставляет кэш сборок.
• Обсуждение выявило, что Fil-C в первую очередь ориентирован на безопасность, а не на производительность, и что он не решает проблему безопасности в полном объеме, но является важным шагом вперед.
• Некоторые участники обсуждения выразили обеспокоенность по поводу того, что Fil-C может быть непрактичен из-за производительности, но другие отметили, что для некоторых приложений безопасность важнее производительности.

Команда Bellroy автоматизировала работу с ERP-системой, где каждый запрос к API требует предварительных шагов — например, чтобы создать запись, нужен ID другой сущности, что требует дополнительных запросов.

Умный подход: вместо цепочки запросов "запроси A, затем с результатом запроси B" они используют аппликативные функторы. Эти структуры позволяют собрать все нужные запросы в один пакет (отсюда "free applicative"), отправить их разом и потом разобрать ответы, сопоставляя каждый с исходным запросом.

Так они избегают проблем "callback hell" и сохраняют код декларативным. Например, вместо ручной обработки каждого ответа они описывают граф запросов через Free Applicative, а исполнение — дело интерпретатора, который может батчить запросы и парсить ответы.

Особенно изящно это работает с "handle pattern", где каждая операция (типа "получить цену товара") представлена как handle, а реализации могут быть разными (реальная БД vs. мок для тестов). Аппликативы же позволяют комбинировать эти handles в сложные запросы, оставаясь агностичными к источнику данных.

В итоге, Bellroy получает код, где бизнес-логика описана как композиция handles, выполнение оптимизировано (батчинг, кеширование), а тесты пишутся просто — подменой handles на заглушки.

• Bellroy, известный своими кошельками и аксессуарами, использует Haskell и Nix, что вызывает удивление и вопросы о масштабе и прибыльности компании.
• Пользователи обсуждают, как компания, которая начиналась как производитель кошельков, может позволить себе такой стек технологий.
• Обсуждение также затрагивает вопрос о том, как язык программирования и инструменты разработки могут влиять на продукт и его качество.
• Участники также обсуждают, как компания, которая начиналась как производитель кошельков, может позволить себе такой стек технологий.
• В конце, участники обсуждения приходят к выводу, что, возможно, это просто "разработчики, которые ушли в бизнес кошельков", и это может быть просто пример того, как красивые вещи могут появиться из самых неожиданных мест.

Опасная уязвимость в GitHub Actions позволила бы злоумышленникам выполнять произвольный код в CI/CD пайплайнах проектов с открытым исходным кодом, используя функцию pull_request_target.

Основная проблема заключалась в том, что некоторые рабочие процессы в nixpkgs использовали pull_request_target и доверяли коду из форков, выполняя команды вроде xargs над именами файлов из PR. Это позволило бы атакующему создать файл с именем вроде --help, который интерпретировался бы как флаг для утилиты, что привело бы к выполнению произвольного кода.

Более серьёзный случай включал симлинки: рабочий процесс проверки CODEOWNERS мог быть обманнут для чтения произвольных файлов с диска, включая файлы учётных данных. Если бы атакующий смог заставить систему прочитать файл с учётными данными, он мог бы украсть токены GitHub.

К счастью, эти уязвимости были обнаружены и исправлены до того, как их могли эксплуатировать. Авторы рекомендуют всем, кто использует pull_request_target, тщательно проверять свои рабочие процессы и избегать доверия к коду из форков.

• Проблема в том, что pull_request_target в GitHub Actions позволяет уязвимости, но при этом остаётся единственным способом запуска CI для форков в организациях, не использующих форки.
• Подверженность pull_request_target в действии: злоумышленник может украсть токены и секреты, используя триггер, что приводит к тому, что вредоносный код может быть запущен в контексте базовой ветви.
• Предложение: GitHub должен либо полностью отключить pull_request_target, либо предоставить безопасный способ запуска CI для форков.
• Параллельно обсуждается, что если бы NixOS принял предложение обеспечивать подпись коммитов и независимые воспроизводимые сборки, как это делает Guix, то подобные атаки были бы невозможны.

Инструмент mise теперь поддерживает задачи в монорепозиториях, позволяя запускать команды в нескольких проектах одновременно. Это упрощает управление зависимостями и скриптами, особенно при работе с большими кодовыми базами. Например, можно выполнить mise run build для сборки всех проектов или mise run test для запуска тестов.

Ключевое преимущество — автоматическое определение контекста и зависимостей между проектами, что сокращает рутинные операции. Интеграция с существующими инструментами вроде npm scripts делает переход плавным. Такой подход экономит время и снижает вероятность ошибок при ручном управлении задачами.

• Пользователи высоко оценивают mise за универсальность в управлении версиями языков (Node, Python, Rust, Go) и инструментами в одном конфиге, упрощающую onboarding в проектах.
• Отмечается удобство встроенного раннера задач, который заменяет Makefile/Just и работает в монорепозиториях, обеспечивая единый интерфейс для задач независимо от языка.
• Высказываются опасения по поводу сложности PATH-менеджмента и возможного чрезмерного расширения функциональности (например, отсутствие кэширования задач и поддержки Windows).
• Некоторые пользователи сравнивают mise с более сложными системами (Bazel, Nix), отмечая его как более простую альтернативу с низким порогом входа.
• Обсуждаются интеграции с другими инструментами (uv, moon, turborepo) и необходимость улучшения документации, особенно для новичков.

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

• Журнал на Nix, Vim, coreutils, dateutils; вдохновлён Bullet Journal.
• Структура: каталог journal/2023/ → 12 файлов 01…12.
• Календарь: :read !cal -m в начале месяца.
• Недельные записи:

  week 1
  · apply leaves
  × dload boarding pass
  > reply to dan
  

• Символы:
  · todo, × done, - заметка, o событие, > перенесено.
• Сортировка: gqip после :set formatprg=sort\ -V группирует и поднимает «todo».

• Участники спорят, нужен ли Nix для простой системы ведения дневника: кто-то считает его избыточным, кто-то ценит детерминированные окружения и воспроизводимость.
• Показаны альтернативы: email-аккаунт-«бутылка», Org-mode, Org-journal, vimwiki, аудиозаметки и даже pen-and-paper.
• Обсуждаются тонкости календаря: ncal -w/ncal -wb для номеров недель и ISO-8601.
• Некоторые считают Nix «религией» и игрушкой для тех, кто гонится за трендами; другие используют NixOS или гибридные решения.
• Итог: метод прост, но выбор инструментов (Nix, Org, email, голос) зависит от личных приоритетов и готовности заморачиваться.