Hacker News Digest

Идея заменить ELF-формат исполняемых файлов на SQLite — не шутка, а прототип под названием SELF, где сам файл — это SQLite-база, которую можно запускать как обычную программу. Вместо readelf и objcopy теперь можно писать SQL-запросы: SELECT name FROM elf_symbols или SELECT soname FROM ldd, чтобы узнать зависимости. Формат хранит все метаданные — символы, секции, зависимости — как таблицы, а не как бинарные структуры, что делает анализ и модификацию тривиальной задачей.

ELF на самом деле уже похож на базу данных — он вручную реализует индексы, строковые интернирование и внешние ключи, но без схемы и надёжности. SELF использует встроенную стабильность SQLite: изменения вроде LD_PRELOAD становятся транзакциями — можно вставить строку в таблицу preload, запустить программу, получить другой результат, а потом откатить всё одним ROLLBACK. Это позволяет атомарно перехватывать функции везде в системе без пересборки. Прототип работает с glibc, поддерживает конвертацию ELF ↔ SELF и даже запускается в NixOS-виртуальной машине. Nix даёт возможность перестроить мир — и SELF показывает, как можно переписать фундаментальные соглашения операционных систем.

Идея использования SQLite в качестве формата исполняемых файлов (SELF) интересна как попытка унификации метаданных, но практически необоснованна: ELF уже структурирован, но жёстко привязан к конвенциям — SQLite не решает его основную проблему, а добавляет избыточность. Существующие инструменты (osquery, nushell, виртуальные таблицы над /proc) и форматы (PE/COFF, .NET) уже обеспечивают структурированный доступ к системным данным без изменения формата исполняемых файлов. SQLite упрощает манипуляции с ELF-секциями по сравнению с objcopy/readelf, но не оправдывает замену ELF — особенно из-за невозможности эффективного mmap BLOB-данных из-за структуры страниц, что критично для исполняемых файлов. Для SELF требуется загрузчик, преобразующий его в ELF — приемлемо для демонов, но не для коротких утилит. Удаление метаданных через sstrip уже распространено, так как секционная таблица не обязательна для загрузки. Идея напоминает проваленные WinFS, AS/400 и PICK — это не техническая, а системная проблема: унификация на уровне формата не решает архитектурных ограничений. SELF не добавляет распределённости или транзакционности, в отличие от DBOS. Реальное внедрение требует полноценной экосистемы инструментов — их сейчас нет, и разработка неоправданна. Лучше развивать стандарты метаданных (ELF-расширения, DWARF), а не переписывать всё на SQLite, что лишь заменяет один барьерный API (fopen) другим (SQLite) без реального упрощения.

Новый этап в управлении Nixpkgs: ядро‑команда официально распалась. За десять месяцев команда успела переработать процесс делегирования, добавить 19 новых коммитера, улучшить бот слияния и закрепить финансирование корпоративного облака.

Но роль оказалась тяжелее, чем ожидалось: поддержание «легкого» статуса оказалось несовместимым с активным техническим вкладом. После двух недель размышлений команда пришла к выводу, что продолжение ухудшит здоровье участников.

Система делегирования в Совете Структур (SC) оказалась не готова к реальной ответственности: постоянный микроменеджмент, неясность статусов и медленные ответы тормозят проекты — от GSoC до политики AI. Несмотря на попытки обсудить эти проблемы, они остаются системными и не могут решить отдельными людьми.

В результате SC перестал выполнять обещанную роль «репрезентативного бэк‑апа» и стал «тяжёлым» фактором, тормозящим развитие. Уход команды — не из‑за одного события, а итога длительных паттернов, включая плохую коммуникацию и отсутствие доверия со стороны сообщества.

Авторы подчёркивают, что решение не связано с отдельным инцидентом, а вызвано устойчивыми проблемами. Они планируют сократить участие в Nixpkgs и не будут баллотироваться в SC, но сохраняют веру в принципы лёгкой, согласованной и технически‑ориентированной политики. Благодарит всех, кто поддерживал их работу.

Nixpkgs столкнулся с кризисом управления и governess-структурой, приведшим к распаду core team. Пользователи расходятся во мнениях: одни видят в этом системные проблемы и избыточную политизацию, другие — отдельные случаи и сохраняют положительный опыт использования Nix. Некоторые считают Nixpkgs непригодным для личного использования, другие — ценным инструментом для управления зависимостями. Рекомендуется осторожно подходить к использованию Nixpkgs, рассматривая альтернативы, такие как direnv, stagex.tools и LLM-агенты. Распад Nixpkgs может повлиять на всю экосистему Nix.

Автор делится положительным опытом использования Linux на ноутбуке Fujitsu Lifebook U729, отмечая, что система работает безупречно, а всё оборудование работает "из коробки". Основная сложность заключалась в отключении Secure Boot. После поломки экрана MacBook Air автор решил перейти на стационарную конфигурацию, но осознал необходимость портативного устройства. Вернувшись к Linux, особенно NixOS, он выбрал этот ноутбук благодаря отличному соотношению цена/характеристики: 16 ГБ оперативной памяти, 512 ГБ SSD за 250 австралийских долларов, компактным размерам и весу 1,1 кг.

Для отключения Secure Boot потребовался нетривиальный процесс: сначала установка Windows 11 с обновлением драйверов Fujitsu через Windows Update, затем обновление BIOS утилитой DeskUpdate. Только после обновления BIOS с версии 2.17 до 2.31 появилась возможность отключить Secure Boot и установить NixOS. Ноутбук также поставлялся с корпоративным шпионским ПО Absolute Persistence для защиты от краж. Автор подчеркивает, что несмотря на первоначальные сложности с Secure Boot, в целом опыт использования Linux на этом устройстве оказался исключительно положительным.

• Б/у корпоративные ноутбуки (ThinkPad, Dell) оптимальны для Linux: хорошее соотношение цены и качества, ремонтопригодность, совместимость.
• Критерии выбора: проверка заблокированного BIOS, репутация производителя по ремонту, избегание Intel из-за проблем с перегревом и батареей.
• Рекомендуемые модели: Lenovo Yoga Slim 7, Asus ProArt px13, старые MacBook Air, ARM-ноутбуки (Lenovo Chromebook Plus 14).
• Проблемы Windows 11: обязательная учётка Microsoft, сложный обход Secure Boot; критика Fujitsu из-за скандала с почтовыми отделениями.
• Переход с macOS: "тысячи порезов" в Linux, но ценится кастомизация; важны обновление BIOS перед установкой и проверка совместимости железа.

Debian GNU/Hurd 2025 — неофициальный релиз Debian, но официальный порт.
Основан на «sid» в момент выхода «Trixie».

• ISO: hurd-i386 | hurd-amd64
• Образы и инструкции: hurd-install

Архитектуры: i386, amd64; покрытие ~72 % архива Debian.

Новое

• 64-бит полностью готов, драйверы дисков через Rump (NetBSD).
• xattr по умолчанию для трансляторов; mmdebstrap из других ОС.
• Порт Rust, USB-диски и CD через Rump.
• SMP, xkb-раскладки, framebuffer, acpi, rtc, apic, hpet.
• Исправления irqs, nfsv3, libports, pipes и др.

Документация

• FAQ
• Translator primer

Присоединяйтесь: contributing

• Hurd — давний проект с микроядром Mach, фактически движимый одним человеком (Samuel Thibault), и сегодня выглядит скорее хобби-экспериментом, чем реальной альтернативой Linux.
• Участники обсуждают низкую поддержку железа, архаичную архитектуру и отсутствие прогресса: «ждать совершенства — значит никогда не стать готовым».
• Предлагаются новые микроядра (seL4, L4, Viengoos) и языки (Rust, Zig), но критика считает это погоней за хайпом.
• GUIX/Nix и GNU Shepherd упоминаются как более живые GNU-ориентированные проекты; GUIX уже умеет запускать Hurd в виртуалке.
• Итог: Hurd остаётся интересным музейным экспонатом и источником идей, но не готов к «повседневному» использованию.