LINUX.ORG.RU

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

 , , ,


0

6

Здравствуйте, товарищи!

Давно хотел попробовать Guix(SD) с последующим переходом на него, как на основную систему, и вот на выходных решился. Прое...лся три дня и теперь в недоумении, как оно всё работает?

Установилось в общем просто и понятно, но дальше начались какие-то непонятные мне вещи.

Во-первых, я попытался поставить кастомное ядро с фирмваре для WiFi карты. Всего несколько строчек в конфиге, два новых пакета и в результате несколько часов раобты компьютера по установке зависимостей. В конце концов, ядро и фирмварь успешно собрались, но зависимости не доставились из-за ошибки в сборке пакета ImageMagic (зачем он там??) - просто архива с такой версией пакета не оказалось на серверах.

Во-вторых, и это самое главное и непонятное, почему в системе по несколько пакетов одинаковой версии, но с разными хэшами? Из-за этого я уже пол часа ставлю graphviz - сейчас собирается тринадцатый пакет из зависимостей. Это llvm-6.0.1, которых в /gnu/store уже 4 штуки (ставится пятый). До этого поставился четвертый cups-2.2.6, а cups-2.2.8 уже 8 штук.

Это вообще правильное поведение и я просто ничего не понимаю, или нужно что-то сделать, чтобы оно работало нормально?

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

★★★★

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

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

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

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

jollheef ★★★★★ ()
Ответ на: комментарий от jollheef

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

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

Puzan ★★★★ ()

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

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

anonymous ()
Ответ на: комментарий от anonymous

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

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

Puzan ★★★★ ()

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

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

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

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

shatsky ★★ ()
Ответ на: комментарий от shatsky

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

Puzan ★★★★ ()
Последнее исправление: Puzan (всего исправлений: 1)
Ответ на: комментарий от Puzan

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

shatsky ★★ ()
Ответ на: комментарий от Puzan

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

shatsky ★★ ()
Ответ на: комментарий от shatsky

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

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

Puzan ★★★★ ()
Последнее исправление: Puzan (всего исправлений: 1)

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

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

Harald ★★★★★ ()
Ответ на: комментарий от Harald

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

anonymous ()
Ответ на: комментарий от anonymous

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

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

balsoft ()
Ответ на: комментарий от balsoft

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

anonymous ()
Ответ на: комментарий от balsoft

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

PtiCa ★★★★★ ()
Ответ на: комментарий от Puzan

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

Puzan ★★★★ ()

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

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

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

znavko ★★ ()
Ответ на: комментарий от anonymous

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

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

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

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

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

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

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

shatsky ★★ ()
Ответ на: комментарий от shatsky

ересь

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

anonymous ()
Ответ на: комментарий от znavko

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

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

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

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

Puzan ★★★★ ()
Ответ на: комментарий от Puzan

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

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

anonymous ()
Ответ на: комментарий от Puzan

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

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

anonymous ()

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

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

Choose your destiny.

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

anonymous ()
Ответ на: комментарий от anonymous

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

balsoft ()
Ответ на: комментарий от anonymous

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

balsoft ()
Ответ на: комментарий от anonymous

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

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

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

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

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

balsoft ()
Ответ на: комментарий от balsoft

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

anonymous ()
Ответ на: комментарий от anonymous

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

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

ущербном nix-lang

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

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

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

balsoft ()
Ответ на: комментарий от balsoft

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

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

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

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

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

anonymous ()
Ответ на: комментарий от anonymous

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

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

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

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

balsoft ()
Ответ на: комментарий от balsoft

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

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

allter149 ()

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

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

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

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

EXL ★★★★★ ()
Ответ на: комментарий от allter149

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

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

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

balsoft ()