Hacker News Digest

mold 3.0.0 — это первый релиз линкера, переписанного с C++ на Rust, и он позиционируется как drop-in-замена версии 2.42.1. Переписанная версия сохраняет те же параметры командной строки, поддерживает те же архитектуры и выдаёт идентичный вывод, за исключением исправленных ошибок. Производительность линкования осталась на уровне предыдущей версии, а совместимость проверена запуском тестов на всех целевых платформах, сравнением вывода на реальных нагрузках и сборкой всех пакетов Gentoo — регрессий не обнаружено.

Переход на Rust повысил безопасность: теперь при повреждённых входных файлах mold не падает с segmentation fault, а останавливается с паникой благодаря bounds-checked чтению памяти. Изменена система сборки — вместо CMake используется Cargo, требуется Rust 1.95+ и C-компилятор. Сборка выполняется через cargo build --release, установка — ./install-mold.sh с поддержкой PREFIX и DESTDIR. Убрана зависимость от oneTBB, оставлено статическое связывание mimalloc, а системный аллокатор можно включить через --features system-allocator. Тестовый запуск теперь осуществляется через cargo test, а зависимости для тестов устанавливаются скриптом install-test-deps.sh. Среди исправлений — устранение крахов при работе с version script, при совпадении входного и выходного файла, при использовании --gc-sections с --init/--fini, при обработке общих символов разного размера, а также улучшена работа ICF и обработки версионных ссылок в共享 библиотеках. Исправлены архитектурно-специфические ошибки для SH4 и SPARC64. Проект продолжает получать поддержку от спонсоров, включая Cybozu, SAP, Mercedes-Benz и других.

Переход mold на Rust вызывает споры из-за проблем бутстрапа: Rust-инструменты недоступны на ранних этапах сборки дистрибутива, что делает использование mold невозможным без поддержки C-версии mold2 как отдельного форка. Автор mold @rui314 признаёт проблему, но предлагает использовать mold 2.x для бутстрапа, а затем переходить на mold 3 после сборки Rust — как практичный компромисс. Пользователь @lrvick настаивает на необходимости сохранения C-версии для ранних этапов. Советы по решению: - @danudey и @karavelov предлагают использовать LLD для бутстрапа и линковки Rust, так как LLVM уже требуется для сборки Rust, что устраняет дополнительные зависимости. - @Orphis и @rui314 отмечают, что воспроизводимые и герметичные сборки с кэшированием бинарников позволяют использовать последнюю версию mold для сборки следующих версий Rust, минимизируя пересборки. - @mohamedkoubaa предлагает рассмотреть Eurydice как альтернативу для управления цепочками сборки, без уточнения деталей. - @nicce предлагает добавить #[no_mangle] и поддержку extern C в mold 3.0 для ABI-совместимости, но не связывает это с бутстрапом. - @avadodin предлагает использовать сэкономленное время на переписывании mold для создания chibirustc — упрощённого компилятора Rust для быстрой локальной сборки, чтобы решить проблему бутстрапа. Дополнительно: - @rui314 утверждает, что переписывание mold на Rust ускорено AI, называя AI-assisted coding крупнейшим прорывом в производительности за свою карьеру. - @tialaramex опровергает утверждение о транспиляции кода, отмечая, что для транспиляции нужен исходный код на другом языке, чего в случае mold нет. - @sillysaurusx подчёркивает, что Wild — другой быстрый линкер, но ориентирован на инкрементальную линковку, тогда как mold фокусируется на скорости полной линковки. - @BoingBoomTschak отмечает, что Cargo.lock mold содержит ~600 строк против ~2200 у Wild, что снижает поверхность атаки, несмотря на общую зависимость от крейтов в Rust. Все факты и оговорки сохранены, повторы и канцелярит удалены, мысли объединены. Ничего не добавлено. Текст на русском, латиница только в именах и терминах.

Cobalt — открытая платформа, превращающая Kobo‑ридер в мини‑маркет приложений. После единожды установленного через USB‑кабель каждый новый софт загружается, обновляется и удаляется по Wi‑Fi, а процесс каждого приложения изолирован в отдельном unprivileged‑процессе. Главное преимущество — полная автономность: после перезагрузки возвращается обычный Kobo‑интерфейс, а установленные приложения живут независимо от платформы.

Особенно стоит отметить несколько ярких решений: arXiv просматривает новые предпечати и отображает их полностью на экране; Sudoku и Morse демонстрируют работу UI‑элементов и даже Morse‑код на переднем свете; Gutenbird позволяет читать любые OPDS‑библиотеки, включая Project Gutenberg. Всё это работает на реальном железе — ARM‑бинарники запускаются без root‑доступа, подписи проверяются перед запуском, а установка требует лишь rustup и cargo для сборки. Главное правило: поддерживаются только проверенные модели (на данный момент — Clara BW), и любые изменения можно откатить, перезагрузив устройство.

Тред отражает поляризацию между пользователями, ценящими расширяемость ридеров (Obsidian, Zotero, Libby, KOReader, NickelMenu) и теми, кто настаивает на изоляции от цифрового шума, считая ридер одноканальным инструментом. Критики отмечают, что e-ink не гарантирует фокус — Kindle с браузером и iPad с отключенными уведомлениями демонстрируют это. Технически: двухъядерный процессор критичен для стабильной работы модификаций — он есть в цветных моделях Kobo (Color), но отсутствует в черно-белых (BW). На некоторых устройствах (например, Clara) возможна установка PostmarketOS для Linux-приложений, но это сложнее, чем Cobalt. Пользователи требуют нативную интеграцию с Libby, Zotero, Obsidian и RSS-сервисами, чтобы избежать конвертации в EPUB. Некоторые критикуют использование LLM для описаний и кода как «slop», другие шутят, что ИИ заметил детали, упущенные людьми. Владельцы Kindle выражают зависть к открытости Kobo, полагая, что аналогичная платформа вернула бы их к активному использованию. Для чистого текста черно-белые экраны считаются четче, чем цветные, несмотря на лучшую производительность последних.

В августе 2026 года в cargo.io появилась поддельная версия arrayref 0.3.10. В её зависимостях скрыт типосквот proc-macro1, чей скрипт сборки скачивает и запускает удалённый бинарный файл во время компиляции. Поскольку выполнение происходит на этапе сборки, любой проект, использующий эту версию, автоматически активирует вредоносный код.

Ключевой факт: злоумышленники использовали поддельный аккаунт dtolney, имитируя dtolnay, и разместили в proc-macro1 build‑script сервер‑команду hxxps://23[.]254[.]165[.]112:9089. Декодированные фрагменты указывают на адрес 23.254.165.112 и порт 9089 (payload) и 443 (C2). На Linux‑системах бинарник сохраняется в /tmp/rust-setup и запускается в фоне, а на Windows — в %TEMP%\rust-setup.ps1 через скрытый VBScript‑launcher, что позволяет процессу продолжать работу после завершения сборки.

Эти детали позволяют быстро распознать индикаторы компрометации: запросы к 23.254.165.112:9089 и 443, появление /tmp/rust-setup или %TEMP%\rust-setup.ps1. Удалённый код может выполнять любые действия, пока сборка уже завершена, поэтому важно сразу откатывать все зависимости от arrayref 0.3.10 и ниже, а также проверять целостность публикуемых crates.

Rust-экосистема уязвима к атакам на этапе сборки из-за отсутствия sandboxing для build.rs и proc-macro, слабого контроля зависимостей и чрезмерной фрагментации — что повторяет ошибки npm. Вредоносный код скрывается от сканеров, не попадая в финальный бинарник, а действуя только во время компиляции. Атаки типа left-pad (например, append-only-vec) показывают, что даже тривиальные зависимости увеличивают поверхность атаки. Необходимо: — реализовать sandboxing для build.rs (например, через Seatbelt на macOS, Landlock/seccomp на Linux, microVM или bubblewrap); — ввести min-release-age для зависимостей, чтобы дать время на обнаружение вредоносных пакетов; — требовать явного разрешения на новые build.rs и proc-macro, как в pnpm; — выполнять сборки в изолированных средах, исключающих доступ к ключам и чувствительным данным хоста; — применять статический анализ и AI-сканирование изменений перед публикацией на crates.io; — развивать стандартную библиотеку, чтобы снизить зависимость от сторонних пакетов для базовых операций; — внедрять языковые механизмы эффектной типизации для декларативного запрета сетевого доступа, FFI и записи в файл до компиляции; — использовать локальные репозитории для контроля версий, как в Conan для C++; — избегать автоматических обновлений зависимостей без проверки (пример: arrayref 0.3.10). Спор о том, хуже ли Rust, чем npm, несущественен: проблема — не в языке, а в политике управления зависимостями и отсутствии изоляции.

Пакетные менеджеры — зло

Пакетные менеджеры автоматизируют ад зависимостей: скачивают пакет → его зависимости → зависимости зависимостей… и ты в аду. Вручную хотя бы думаешь: «а надо ли?»

Большинство языков не знают, что такое «пакет», поэтому менеджер сам его придумывает. В итоге появляются «менеджеры менеджеров» (npm, yarn, pnpm…).

Языки с толстой стандартной библиотекой (Go, Odin) откладывают ад: 90 % задач решаются без сторонних пакетов.

Каждая зависимость — это долг: баги, security, поддержка. Мы взяли SDL2 — и год убили на чужие баги; проще написать своё, чем обновиться до SDL3.

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

• Критика менеджеров пакетов сводится к тому, что они «автоматизируют ад зависимостей», скрывая от разработчика реальные издержки и риски.
• Автор предлагает вручную копировать и фиксировать нужные версии библиотек, чтобы осознанно контролировать, что именно попадает в проект.
• Оппоненты считают идею регрессом: ручное управление не масштабируется, тормозит разработку и не решает проблему транзитивных зависимостей.
• Поддержка Cargo, npm и прочих инструментов признаётся необходимой, но критикуется культура «микро-зависимостей» и отсутствие вендоринга.
• Компромисс видят в строгом вендоринге (Google), фиксации версий, feature-gates и использовании «batteries-included» стандартных библиотек (Go).

Rust повышает производительность разработки, несмотря на сложность.
Ключевые факторы:

• Жёсткий компилятор ловит ошибки до запуска, уменьшая время отладки.
• Модель владения устраняет гонки и утечки памяти, снижая количество багов.
• Инструменты: Cargo, Clippy, rustfmt и rust-analyzer ускоряют цикл «написание → проверка → запуск».
• Сообщество предлагает качественные крейты и быструю помощь.
• Производительность кода сравнима с C/C++, но без segfault и UB.

В итоге меньше времени тратится на отладку, больше — на новые функции.

• Автор статьи рассказал, как Rust позволяет безболезненно рефакторить большие кодовые базы благодаря строгой типизации и проверкам компилятора.
• Многие участники согласились, что статическая типизация (Rust, Haskell, OCaml-подобные языки) повышает уверенность при изменениях, особенно в многолюдных проектах.
• Часть комментаторов считает сравнение с TypeScript «нечестным»: TS компилируется в JS и наследует его недостатки, а приведённый баг с window.location.href — это особенность DOM, а не языка.
• Некоторые отметили, что Rust тоже не идеален: async/синхронные блокировки, медленная компиляция и «множество способов сделать одно и то же» могут снижать удобство.
• Общий вывод: преимущество Rust в безопасности и рефакторинге особенно заметно на больших проектах, но язык требует времени на изучение и не всегда лучше «классических» статически типизированных альтернатив.

Я написал What the Fork — кроссплатформенный визуализатор сборки C/C++ (и не только).
Запуск: wtf make, wtf cargo build, wtf gradle build, wtf -x для Xcode и т.д.

Инструмент показывает все процессы, включая скрытые вызовы ld, и ищет типичные проблемы:

• отсутствие -j у make,
• однопоточная компиляция,
• повторяющиеся cmake/make-шаги,
• непараллельные CI-сборки.

Как работает
Сборка = дерево команд. Чтобы увидеть всё, ловим системные вызовы fork/exec/exit:

• macOS — Endpoint Security API,
• Linux — ptrace,
• Windows — Event Tracing (самое мерзкое API).

Что уже нашли

• cargo собирал зависимость одним потоком вместо 10× ускорения.
• ninja при сборке LLVM держит 12 задач на 10 ядрах — почти идеал.
• CMake 85 раз подряд вызывает xcode-select, sw_vers, cmake/make → clang, не используя параллелизм.

Инструмент открыт для тестов — попробуйте на своём проекте.

• Пользователи восторженно реагируют на новый визуализатор сборки, особенно те, кто застрял на CMake/GCC/Make без clang/ninja и не может понять, почему сборка тормозит.
• Просят сразу показать GIF-демонстрацию под заголовком статьи и спрашивают, будет ли macOS-версия и открытый код.
• Некоторые делятся опытом: strace/dtruss, ninjatracing, vcperf, cargo --timings, Instruments и другие инструменты уже решали похожие задачи.
• Предложения расширить функциональность: добавить flame-графы процессов, поддержку fork(), интеграцию с Bazel Build Event Protocol, оценку «осталось времени» по историческим данным.
• Отдельные комментарии касаются маркетинга (сменить название), сравнения с VS/Xcode, а также шуток про TEEP/OEE завода и «LLVM, завари кофе».

Представьте, вы пишете проект и вам нужна библиотека — назовем ее libpupa.

Вы находите текущую версию 1.2.3 и добавляете в зависимости: "libpupa": "1.2.3" Автор libpupa 1.2.3 в свою очередь зависел от liblupa версии 0.7.8 и записал это: "liblupa": "0.7.8" То есть libpupa 1.2.3 навсегда зависит от liblupa 0.7.8. Алгоритм разрешения зависимостей простой и детерминированный: берем версии верхнего уровня, затем версии их зависимостей, и так далее. Достаточно указать только верхние уровни — транзитивные получатся одинаковыми всегда. Зачем отдельный lockfile?

Но люди изобрели lockfile из‑за диапазонов версий. Диапазоны делают сборку зависимой от времени: сегодня вы получите liblupa 0.7.8, через 10 минут — 0.7.9. Это определяется не при публикации, а при сборке: вы можете подтянуть версию, которой не существовало на момент выпуска libpupa 1.2.3. Откуда автор libpupa знает, что будущая 0.7.9 не сломает его код? Семантическое версионирование — это лишь намек, не гарантия.

И смешно то, что эти диапазоны все равно «замораживают» в lockfile, и вы не получаете предполагаемой пользы. «Перегенерируй lockfile и обновись» — это ничем не отличается от обновления верхнеуровневых зависимостей. «Lockfile решает конфликты версий?» — нет: библиотека либо работает с новой версией, либо нет; запись «0.7.*» не помогает — все равно нужно выбрать рабочую версию.

«Но раз lockfile существует, значит, нужен!» — не обязательно. Пример: Maven. Экосистема Java 20 лет обходится без lockfile, при этом тянет сотни библиотек — и все детерминировано.

Вывод: lockfile усложняет без достаточных причин. Менеджеры зависимостей могут работать без него.

UPD: В Maven при конфликте транзитивных зависимостей выбирается версия, ближайшая к корню. Это детерминированно и позволяет переопределять версии. Если вышла d 2.1 с патчами безопасности, добавьте ее в корень — она и будет выбрана, не дожидаясь обновлений у всех. Если автоматически брать самую большую версию, вы потеряете возможность переопределения.

• Обсуждение крутится вокруг необходимости lock-файлов и версионирования: одни считают, что фиксированные версии и детерминированные алгоритмы достаточно, другие настаивают, что lock-файлы критичны для воспроизводимости и безопасности.
• Приводят примеры из экосистем Maven/Java, Go (MVS), Cargo/Rust, .NET, Scala: у каждого свои компромиссы; даже при детерминированном резолве сеть/репозитории делают сборки недетерминированными без lock-файлов и хэшей.
• Аргументы за версии-диапазоны: автоматическое получение патчей безопасности без вмешательства авторов верхнеуровневых библиотек; но это ломается при конфликтующих транзитивных зависимостях и несовместимых API/ABI.
• Много комментариев о том, что lock-файлы особенно нужны приложениям (прод, стейджинг, аудит), а для библиотек — меньше, но всё равно полезны из-за пересборок и целостности (хэши артефактов).
• Подчёркивают проблемы разных языков: в компилируемых — типы из разных версий несовместимы; в JS Node могут сосуществовать несколько версий, но это не решает безопасность/детерминизм.
• Некоторые отмечают, что главная путаница — не в lock-файлах, а в культуре семвера, централизованных репозиториях и UX инструментов; предлагают BOM/snapshot-подходы и периодические обновления с тестами/реновейтом.
• Отдельная ветка критикует дизайн сайта с анимированными иконками, мешающими чтению.