Попробовал поставить GuixSD

И в NixOS так-же, или более человеколюбиво?

Да (более человеколюбиво).

Сам использую NixOS на серверах и основной рабочей машине.

Но у NixOS тоже есть проблемы — сейчас у меня, внезапно, начал падать qemu.

Я так понял, дупликация пакетов там тоже присутствует? Несмотря на то, что в мейллистах есть какое-то объяснение этому, мне всё равно не совсем понятна причина.

И уж очень медленно всё, Nix не такой?

Но у NixOS тоже есть проблемы — сейчас у меня, внезапно, начал падать qemu.

Дык откатился, завёл баг и живёшь дальше.

Это вообще правильное поведение ...?

Да. Шаг влево, шаг вправо и все превращается в наихудший source-based дистр. Поиграйся и вернись на стабильный дебиан, или на арч, если школьник.

Поиграйся и вернись на стабильный дебиан, или на арч, если школьник.

Стабильный дебиан давно в прошлом. Уже лет 5 Арч, и это пока лучшее из того, с чем я имел дело (а дело я имел почти со всем - от LFS и Gentoo до Дебиана и Красношапки). Но вот наверное засиделся я на Арче, душа требует кибер-секса, только боюсь тело уже не осилит.

Это вообще правильное поведение и я просто ничего не понимаю

Мусор собрал?

Всего несколько строчек в конфиге, два новых пакета и в результате несколько часов раобты компьютера по установке зависимостей.

Вам что, бинарный кэш не завезли?

Во-вторых, и это самое главное и непонятное, почему в системе по несколько пакетов одинаковой версии, но с разными хэшами?

Самая банальная причина - у них разная архитектура. Полезно понимать, что в Nix-подобных системах управления пакетами любое изменение зависимостей вызывает пересборку зависимого пакета с изменением его хэша - именно это практически гарантирует, что если что-то собралось и заработало, то никакие обновления его не сломают, т. к. оно всегда будет использовать те экземпляры зависимостей, с которыми оно собралось и заработало. Возможно, ты установил что-то в пользовательский профиль и оно зацепило экземпляр общей зависимости, собранный не с тем набором зависимостей, что уже имеющийся в системе, а другим - более ранним или более поздним. Полагаю, если между обновлениями дерева выражений (пере)собираются все устанавливаемые пакеты, то избыточность может быть только из-за мультилиба. В NixOS избыточность занимаемого места в основном устраняется оптимизатором, который объединяет идентичные файлы в разных экземплярах хардлинками.

Вам что, бинарный кэш не завезли?

Завезли. Но если тебя угораздит пропатчить что-то вроде systemd, будешь пересобирать мир.

Мусор собирал, но предыдущие генерации не удалял.

Как-то всё грустно получается. В обычном дистрибутиве я могу поставить пакет за 10 секунд (особенно, если без зависимостей). Здесь же, пока, установка любого пакета (в системный или пользовательский профиль, без разницы) влечет за собой десятки минут-часы ожидания.

NixOS в такой херне уличён не был. Из исходников собираю только то, что сам патчу.

Nix тоже не очень быстрый, но побыстрее guix по моим ощущениям.

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

У меня в NixOS все ставится за десятки секунд. Из исходников собирался только вайн. Правда, если я захочу оптимизировать систему, его придется пересобрать с последними версиями зависимостей.

Почему блин «генерация»? Это же очевидно «поколение», даже по смыслу подходит.

Ну справедливости ради кэш иногда медленноват, особенно в РФ.

Потому же, почему дистрибутив, а не распределение.

Так без удаления предыдущих генераций мусора и не будет.

Сейчас удалил лишнее и запустил system reconfigure с кастомным ядром. Пойду пообедаю, с дефолтным конфигом меньше чем за час не соберется. Надеюсь, после всех манипуляций всё соберется таки.

Попробуй для начала NixOS, если понравится и зайдёт, то разбирайся с GuixSD. NixOS поудобнее для новичка.

Попробуй для начала NixOS

Да я уже начал с Guix, не бросать же на пол пути. Надо дожать. А если тепрение кончится, попробую Nix.

Это llvm-6.0.1, которых в /gnu/store уже 4 штуки (ставится пятый). До этого поставился четвертый cups-2.2.6, а cups-2.2.8 уже 8 штук.

Хейтеры и неосиляторы динамической линковки должны страдать, всё нормально :)

Поиграйся с nix/guix заодно флатпаками, шнапсами, апимиджами и поймешь, как можно превратить динамическую линковку в статическую, взяв все самое худшее ради сомнительного плюса.

Поиграйся с nix/guix заодно флатпаками, шнапсами, апимиджами и поймешь

мне это и так понятно, зачем время тратить

Тогда не понятен наезд на счет динамической линковки. С ним и них все хорошо

Так в nix вполне себе используется динамическая линковка, причём без дебильного подхода flatpakов и snapов с appimagами. Одна и та же либа будет использоваться многими программулинами. Когда двум программулинам нужны разные версии либы, вполне очевидно, что эти версии будут различаться и нужно качать два файла. Это остальные дистры делают сасай с проглотом, когда нужна, например, старая glibc.

За guix сказать не могу.

llvm

gnu

Лол.

В nix/guix прописываются жесткие и конкретные зависимости пакетов, не выводятся на основе уже установленных. Что захочет конкретный пакет, та версия будет установлена. В nixpkgs есть почти какбы центральный список пакетов и их версий, которые дергаются через общие переменые, но это не мешает каждому пакету иметь свою версии в обход политики партии. В guix давно не копался, там прикрутили модульную систему лиспа как способ задания зависимостей, то есть каждый пакет имеет свою версию, как повезет. Нет задания условных зависимостей, например: gtk больше или равно 2, но меньше 3 версии). Все это ведет к барадаку из версий без пространства для оптимизации. Статика, поверх динамики. Одним словом, извращение.

По сути, в NixOS ядро с фирмвайрью, а в GuixOS - нет? Как оно может работать иначе, если смысл тот же - при пересборке патченого пакета будут пересобираться все от него зависящие пакеты, не?

В общем, в пол первого запустил system reconfigure, до сих пор ковыряется. Большую часть пакетов собирает из исходников, но при этом ооочень долго - за время сборки svn я был по нормальному успел собрать компилятор и ядро. Оставлю до завтра, надеюсь доделает (без ошибок).

Идея GNU - свободное ПО. Возможно, Ваши проблемы с зависимостями ядра.

Оперирование несколькими версиями пакетов - странное поведение. Обычно компилится последняя версия пакета и обновляются зависящие от него пакеты.

Больше 4 часов компиляция бывает при компияции Раст и IceCat у меня на проце 2,1 ГГц. Вам стоит написать в bug-guix

Утверждение о том, что решение Nix эквивалентно статической линковке - ересь.

В nix/guix прописываются жесткие и конкретные зависимости пакетов

Только для собранных. Причем рекурсивно, что при ленивых обновлениях приводит к росту числа экземпляров пакетов одних и тех же версий. Заметь, ничто не мешает жестким и конкретным зависимостям быть общими для многих зависящих пакетов - в отличие от статической линковки. Если собирать все снизу доверху - никаких лишних экземпляров не будет.

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

Ты путаешь выражения и деривации. Нет никакого обхода, просто при частичной пересборке множества пакетов остаются зависимости, которые нужны непересобранным пакетам, в том числе тех же версий, что и вновь собранные, но собранные со старыми версиями своих зависимостей - с точки зрения Nix это разные экземпляры и в этом есть смысл.

Нет задания условных зависимостей, например: gtk больше или равно 2, но меньше 3 версии).

Да, меня это тоже сначала смутило. Видишь ли, когда ничего не мешает ставить сколько угодно гтк параллельно - нету смысла зависеть от какой-либо, кроме последней подходящей.

ересь

Конкретный вопрос: ты писал свою систему пакетов nix? Не пакеты для nixpkgs. А именно с нуля, с бутстрапом glibc, gcc и тп. Я написал свою кривую, но самодостаточную. И выкинул, как и сам nixos c nixpkgs, полностью понимая, что это такое.
Если нет, то не нало мне приводить цитаты с официальной документации nixos. Ты используешь слова не понимая, что за этими словами стоит, не понимаешь смысла.

Возможно, Ваши проблемы с зависимостями ядра.

Вряд-ли зависимости стокового ядра отличаются от кастомного. Да и как-то многовато зависимостей (не могу посмотреть, потому что не дождался установки graphviz).

Я когда делал pull получил ошибку, что пакета нет, и сделал pull --fallback. Возможно этот пакет и потянул сборку других.

Да хрен бы с ней, со сборкой. Почему так медленно? Ни на Генте ни на Арче таких тормозов со сборкой из исходников никогда не было.

Может быть я что-то не так делаю? Может быть есть какие нибудь best practices для guix/nix?

Вряд-ли зависимости стокового ядра отличаются от кастомного.

От конфига ядра (какие опции включены/выключены), которая часть пакета ядра, зависит очень много базовых библиотек/пакетов. Так как ты изменил корень дерева (хешей), то у тебя будет новое дерево. Пересборка мира по понятиям генту. Но только guix/nix - это намного хуже чем портаж с этой точки зрения. Шаг влево, шаг вправо - <сам знаешь что>

Может быть есть какие нибудь best practices для guix/nix?

Кастомизировать можешь только листовые или близкие к листам пакеты, конечные приложения, от которых ничего не зависит. (Лист, глубина - все в смысле дерева зависимостей). Чем более глубокий пакет изменишь, то большее поддерево пакетов будет пересобрано исключительно только под тебя. Сам понимаешь в какие ресурсы для этого нужны, если знаком с source-based дистром.
В твоем случае, когда нужно ядро с nonfree сразу ставь NixOS. Скорее всего будет уже готовый собранный пакет ядра и нужные библиотеки/утилиты. То есть, будет по крайней мере рабочая основа для экспериментов. Сам язык nix очень ущербный по сранению с полноценным лисп-языком у guix. То есть с точки зрения кастомизации guix удобнее. Но шаг в стороны очень дорог по ресурсам.

Идея обречена находиться в вечной стадии задротства, тк наследует и будет наследовать, по другому невозможно, совершенно угрёбищную идею src-based подхода.

С src-based ты всегда будешь что-то бесконечно конпелять и подкручивать. Запомни, парниша, конпелять должны дистростроители и только. Если это делаешь ты, по какой-то причине, то либо ты дистростроитель, либо муфлон.

Choose your destiny.

Смерть гентушникам! Смерть кедерастам! Дави нахрен никсотсосы и просие гуиксы-хуюиксы!

Эк те припекло.

Можно глянуть? Что-то не верится, что кто-то решился переписать nixpkgs, при этом не переписывая довольно идиотский с точки зрения практического применения nix.

Ничего себе припекло… А то, что патчить гораздо удобнее в src-based, и собственно разработку нового кода nix капитально упрощает - это насрать, конечно, ведь собирать должны только мейнтейнеры…

Лорчую.

В целом согласен, только вот скорее всего ты понимаешь, что «условные зависимости» невозможны по причине их нечистоты по-умолчанию (т.е. input hash будет у них очевидно разный). Насчёт оптимизации - так есть же специальный оптимизатор стора, который высвобождает кучу места с помощью хардлинков одинаковых файлов. Но вот проблема с низкой оптимальностью сборки из-за сложностей инкрементации присутствует.

Статика, поверх динамики

Да. Только вот это позволяет избежать кучи ошибок, поэтому кмк это хорошо.

Одним словом, извращение.

В каком-то роде.

Это не зависимости ядра пересобираются, а пакеты, зависящие от ядра.

Ты думаешь, я буду хранить более 2 лет (я даже не помню когда это было) попытку переписать lfs на ущербном nix-lang? Я почти сделал вывод зависимостей вида «gcc >5.0 <6.0». Каждая обновление (сборка мира) по новой строило полный граф сборки, разрешая такие зависисмости, нещадно шурша по всем директориям, которая по структуре повторяла портаж. И то что было новое, то собиралось. Это была перл-баш-никс лапша, на которую было страшно смотреть.

Я почти сделал вывод зависимостей вида «gcc >5.0 <6.0».

Это невозможно внутри nix из-за архитектуры. Если ты делал это снаружи nix, то это убивает весь смысл идеи, ибо действительно nix для этого не подходит примерно никак.

ущербном nix-lang

Ну кстати да, nix как язык довольно ущербен.

Это была перл-баш-никс лапша, на которую было страшно смотреть.

Почему бы не переписать собственно nix (который генерирует деривации, а не собирает их) на чём-нибудь поприличнее a-la Haskell, OCaml или что-то в том же функциональном духе и оставить nix the package manager (который собирает деривации)? Получилось бы уменьшить лапшевидность кода.

Я почти сделал вывод зависимостей вида «gcc >5.0 <6.0».

Это невозможно внутри nix из-за архитектуры.

Дергаешь внешнюю программу (если извратиться, можно на nix-lang написать), которая эту строку превращает в конретный удовлетворяющий условиям nix-файл «gcc/X.Y.Z/default.nix». А дальше сам nix разберется какие зависимости уже есть, каких нет. В общем, если не понимаешь как это сделать, объяснять не буду. Это не спасает от пересборки мира при изменении версии. Сделал вывод подходящей версии зависимости для всех дергающих таким образом. И вообще, тут нужно какой-нибудь SAT-solver прикрутить.

Почему бы не переписать собственно nix...?

Потому что нет смысла. Одному не осилить. Народу это не нужно, потому что ничего нет готового. У самого nix-store|build есть некоторые косяки, которые вылезут в виде эксплуатации уязвимостей, если будет достаточная популярность.

Дергаешь внешнюю программу (если извратиться, можно на nix-lang написать), которая эту строку превращает в конретный удовлетворяющий условиям nix-файл «gcc/X.Y.Z/default.nix». А дальше сам nix разберется какие зависимости уже есть, каких нет. В общем, если не понимаешь как это сделать, объяснять не буду. Это не спасает от пересборки мира при изменении версии. Сделал вывод подходящей версии зависимости для всех дергающих таким образом. И вообще, тут нужно какой-нибудь SAT-solver прикрутить.

Понял тебя. Этот способ не добавляет по сути никаких преимуществ, если не никакого солвера. Тогда получится, что каждое условие парсится отдельно, и ничем не будет отличаться от просто указания конкретной версии. Если есть солвер, который определяет необходимые версии для определенного набора софта, то это уже интереснее, но убивает повторяемость nix, а из преимуществ - только (возможно) чуть меньший размер скачиваемых файлов. Такое себе.

У самого nix-store|build есть некоторые косяки, которые вылезут в виде эксплуатации уязвимостей

Видел, слышал, даже чуть-чуть помогал исправлять. Я как раз в тот момент подумал, что неплохо бы было переписать nix на каком-нибудь Pure Functional Language, где уязвимостей будет поменьше, аудит полегче. Хаскел сам собой напрашивается, вроде бы даже идёт работа в этом направлении (hnix, но он пока не допилен).

А в Nix можно сказать «хочу систему с gcc x.y.z, clang k.l.m и т.д»? Или это только с каким-то программным генератором nix файлов получится?

И еще. Я поставил Nix и пару пакетов из кэша, так даже несмотря на то, то я не просил комплект для разработки, мне поставили аж 2 копии gcc. А есть возможность удалять с целевой стстемы такие зависимости (что бы снизить периметр проникновения)?

NixOS можно пользоваться.

GuixSD пользоваться невозможно.

но зависимости не доставились из-за ошибки в сборке пакета ImageMagic (зачем он там??) - просто архива с такой версией пакета не оказалось на серверах.

О, типичные проблемы GuixSD. Тоже сталкивался с таким.

Да, так сделать можно. Конкретно конпеляторы, интерпретаторы и некоторые другие важные пакеты в nixpkgs лежат с версиями. Товарищ пилил именно авто-выбор нужной версии по заданным условиям.

И еще. Я поставил Nix и пару пакетов из кэша, так даже несмотря на то, то я не просил комплект для разработки, мне поставили аж 2 копии gcc. А есть возможность удалять с целевой стстемы такие зависимости (что бы снизить периметр проникновения)?

gcc входит в stdenv-linux, так что скорее всего просто так удалить его не получится. Можешь собирать всё под макосьным stdenv, там вроде бы шланг вместо gcc.