LINUX.ORG.RU
решено ФорумAdmin

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

 , , ,


0

5

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

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

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

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

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

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

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

★★★★★

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

Не знаю, что такое гидра

/thread

Хочешь мою гипотезу, что такое гидра? Это билд система, которая строит целевой хеш, если есть готовые хеши-зависимости. То есть он не строит с нуля весь граф зависимостей. А так как nix позволяет подменять хеши-зависимости, то как-то обесцениваются эти проценты. Поэтому нужен натурный экперимент - берешь и собираешь nixos без бинарного кеша, предварительно конечно проинспектировав nixpkgs на предмет хаков.

anonymous
()

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

Закончил с GuixSD, начал с NixOS. Поставил почти всё, чем пользуюсь, кроме VMWare Player, пока не знаю с какой стороны к нему подходить (есть у кого-то опыт?). Nix работает побыстрее, чем Guix, но язык мне не нравится :(

PS: забыл добавить: Столлман конечно молодец, много сделал для свободного ПО, но вот это его фанатичное ограничение несвободной свободы иногда напрягает.

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

Попробуй юзать steam-run для запуска всякой проприетарной проприетарщины. Иногда всё работает хорошо. Если не работает хорошо, то придётся ручками patchelf или buildFHSUserEnv.

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

Да, спасибо, я вроде понял что нужно делать, вечером попробую. Кстати, подглядываю в твой конфиг. Ты конечно с душой подошел к этому делу :)

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

attr и acl зависять от (конфига) ядра? Не говорю про coreutils. Должны зависеть? По ответу на этот вопрос можно говорить, что такое nixpkgs и кто такие его пользователи.

Ты или туп, или троллишь по кругу.

Есть:

а) вероятность того, что пользователю нужно будет кастомизировать пакет;

б) вероятность того, что кастомизация пакета приведет к неожиданной для пользователя поломке зависимых от него приложений;

в) количество пакетов, прямо или косвенно зависящих от пакета;

г) возможность одновременно использовать разные версии пакета в одной системе.

В случае с ядром:

а) достаточно высока;

б) минимальна;

в) максимально;

г) отсутствует.

Следовательно, учитывать зависимости от ядра практически нецелесообразно.

Никому не нужна чистая функциональность(тм). Нужна система, эффективно решающая задачи при минимальных трудозатратах на обслуживание.

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

в) не так уж и много пакетов зависят от самого ядра, по большей части зависимость идёт от его заголовков. Заголовки вынесены в отдельный пакет. г) Ой-вей, правда чтоли? То-то я смотрю nixos-rebuild build-vm не существует.

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

Никому не нужна чистая функциональность(тм)

Она нужна, причём многим. Именно поэтому nix вообще существует.

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

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

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

ИМХО проблема Nix в том, что если билдхэши инпутов пакета изменились, он будет пересобран даже в том случае, если содержимое дериваций всех непосредственно используемых при его сборке инпутов осталось неизменным.

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

в) не так уж и много пакетов зависят от самого ядра, по большей части зависимость идёт от его заголовков. Заголовки вынесены в отдельный пакет.

Я говорю не про зависимости, указанные в никсе, а про фактические. По факту от ядра зависят ВСЕ пакеты, т. к. все они прямо или косвенно используют ядро. Если бы не ABI stability promise - это было бы проблемой.

г) Ой-вей, правда чтоли? То-то я смотрю nixos-rebuild build-vm не существует.

Я специально написал «в одной системе». Никто в здравом уме не будет после пересборки ядра гонять виртуальную машину для приложений, которые были собраны с использованием предыдущей сборки ядра, чтоб обеспечить им 100% сохранность среды исполнения.

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

Если бы проблем, которые решает Nix, не было - она бы не появилась. И, если ты еще не понял, NixOS не 100% чистая, т. к. не сохраняет полностью неизменной среду исполнения, в которой было однажды собрано приложение. И речь не только про ядро. Например, те же библиотеки DRI, которые я приводил как пример, в NixOS не являются зависимостью приложений. Причем, в отличие от ядра, это является проблемой и приводит к поломкам.

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

Всё-таки нужно разделять build-time зависимости и runtime зависимости. Nix управляет именно build-time зависимостями (как ты верно заметил коментом ниже). Зависимость приложений от ядра и DRI - именно run-time, (в build-time знать об конкретной версии DRI и ядра не нужно) и поэтому не подпадает под «зону ответственности» nix. Зависимость приложений/библиотек от заголовков ядра - build-time, и nix с ней прекрасно справляется.

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

это является проблемой и приводит к поломкам.

Точно так же, как и любые run-time зависимости в любой другой системе. В nix такими же проблемами страдают Qt-приложения с их плагинами (которые ищутся и подключаются в run-time).

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

Пардон, ещё одно замечание. Нужно понимать, что иногда nix частично управляет run-time зависимостями, но он не может гарантировать их частоты (по определению run-time зависимостей, на самом деле)

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

Да, но именно такая ситуация встречается не очень часто. Обычно изменение хэша приводит к реальному изменению выхода derivation.

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

Я про то, что в пакетах должен быть не конкретный fetch*, а какой-то fetchFromMagnet, где бы можно было указать разные локаторы (всё равно после распаковки/экспорта можно проверить подлинность). И хорошо бы ещё, что бы можно было переопределить конкретный источник сорцов.

В общем, надо ещё изучать систему... А то я поставил отдельно (nix`ом, не через NixOs) пару GLных приложений, которые у меня не взлетели.

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

Не понимаю значения терминов «локаторы». Ты имеешь ввиду трэкеры bittorrent-magnet ссылок?

И хорошо бы ещё, что бы можно было переопределить конкретный источник сорцов.

Это легко делается через оверрайды.

Если шлангую, прошу простить.

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

Надуманная проблема. Искуственно придумать такой пакет-константу, да еще в инфраструктуре nix - раньше встретишь хеш-коллизию.

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

Развивая тему, предполагая о чем ты думал во время написания этой проблемы.
В nix надо добавить альтернативные «рецепты» получения одной и той же цели, заодно прикрутить проверку (опциональную), что альтернативы дают один и тот же результат. За одно решится проблема получения исходников из разных источников без встроенных хаков для fetch.

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

Не, проверка должна быть обязательной (по крайней мере в pure mode). Иначе рушится hash chain. Но вообще идея хорошая. Ещё можно прикрутить некоторые «приводители-к-минимальному-виду» (скрипты, которые берут файл, и выкидывают из него всё лишнее; типа strip, только для скриптов и прочего текста. И добавить в mkDerivation дефолтный хук на исполнение этих скриптов). Тогда можно будет ещё уменьшить количество собираемых derivations.

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

Не, проверка должна быть обязательной

Ага, щас-с-с, «борцы с полной пересборкой» начнут качать со всех зеркал исходники хромиума для сверки хеша. Да чо там хеша, полное побайтное сравнение и никак иначе. Я еще не настолько ярый фанатик-хейтер-никса.

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

Ещё можно прикрутить некоторые «приводители-к-минимальному-виду»

Эти все «неминимальные вариации» - есть «альтернативные рецепты» для получения цели. Проблема уже решена. Тут надо придумать, как выдавать уникальные ключи таким целям.

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

Это централизованное решение, что есть неправильно. Я не хочу, чтобы у меня лазила какая-то гидра.

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

Я имею в виду, что от изменения комментария сырцы не меняются и соответственно мы получаем

Source1 (SHA256_1) -> Minimize (SHA256_2) -> Final_output (SHA256_3)
                                             ^
Source2 (SHA256_4) -> Minimize (SHA256_5) -> |

Таким образом, при изменении комментария, например, у нас изменится SHA исходников и минимизированной версии, но конечный output сорцов останется прежним (ибо сорцы в минимизированной версии остались неизменными). Таким образом, меньше пересборок -> профит.

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

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

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

Я тебя не понимаю. То есть я понимаю, что ты хочешь в этом сообщении. Но твои идеи с изменением/подменой исходников и тому подобное - это открытая диверсия.

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

Это не подмена исходников. Это безопасный и чистый способ разорвать hash chain, чтобы уменьшить количество собираемых derivations.

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

Ты смотрел на схему, которую я предлагал? Естественно, сначала input пропускается через минимизатор, только после этого сравнивается. Или я неправильно понял твоё изначальное предложение?

или ты троллируешь

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

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

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

1. В магнет ссылках наряду с хэшами допустимы разные локаторы данных: адреса трекеров, HTTP ресурсов и т.д. Т.е. одну ссылку можно скачать несколькими способами.

2. А в вашем nixos-config есть пример такого оверрайда, что бы мне лучше поять, как это работает?

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

Ну конкретно в моём nixos-config именно оверрайда src нет, но есть например пропатчивание Телеграма. Если нужен именно оверрайд src, то он выглядит примерно вот так:

    compton = old.compton.overrideAttrs (oldAttrs: {
      src = builtins.fetchGit {
        url = "https://github.com/BlackCapCoder/compton";
        ref = "master";
      };
    });

И мы получаем compton с анимациями (правда, глючноватый, но это не nix виноват).

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

Да, именно так. Поспав с этой идеей, до меня дошло, что это невозможно реализовать в чистом виде в nix. Для этого нужна немного другая система.

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

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

Говорят что Xmonad хорошо написан и документирован. Так что даже особо в нем несведущий(в этом страшном и ужасном Haskell) может без особого труда кастомизировать его, хотя сам его не пробовал.

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

А что, в Nix смена ссылки на архив с исходниками (пусть даже на тот же самый архив, но в другом месте) меняет хэш итогового пакета?

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

Традиционная рубрика глупых вопросов

Input хэш — это хэш архива с исходниками, или что-то другое?

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

Так, а nix с включёнными в них урлами, разве не считаются?

allter149
()
Ответ на: Традиционная рубрика глупых вопросов от anonymous

Читайте документацию про встроенные функции fetch*
https://nixos.org/nix/manual/#builtin-fetchTarball
Особо догадливый прочитав поймет, что эти функции очень-очень интересные для любителей покопаться в грязи.

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

Сам то прочитал? Ты еще попробуй в эти «модные» режимы включить у себя на боевой системе. Я не удивлюсь, если «модный» nix(pkgs|os) все равно будет работать (обновляться). Потому что есть более грязный <fetch.nix> (вроде так назывался). А ты посчитаешь что так и должно быть.
По твоим сообщениям ты как-то относишься к разработчикам nix(os), которые усердно борются с идеей, на которой они выехали.

anonymous
()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.