LINUX.ORG.RU

Guix: a purely functional package manager

 


0

4

Собственно захожу на страничку

http://www.gnu.org/distros/free-distros.en.html

И читаю в описании к GuixSD:

Guix System Distribution is an advanced GNU/Linux distro built on top of GNU Guix (pronounced “geeks”), a purely functional package manager for the GNU system.

Я не очень понял формулировку:

a purely functional package manager

Кто-нибудь может объяснить?

★★★★★

Вроде близкий аналог Nix, про второй много информации можешь найти.

loz ★★★★★
()

Я недавно NixOS пробовал. Guix основан на Nix, так что, думаю, они похожи. После установки нескольких пакетов пробовать их обоих расхотелось. Это адов бред.

Если кто разубедит и объяснит прикол, буду благодарен.

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

Прикол в том, что в системе могут сосуществовать куча версий одного и того же пакета. Причём для каждого юзера «активной» будет своя версия. Зачем это может понадобиться — понятия не имею.

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

Знаю что он на scheme. И что из этого следует?

Scheme — функциональный язык. Это позволяет разработчикам зачем-то назвать и то, что на нём написано «функциональным». Смысл? Ну должна же быть какая-то особенность.

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

скорее всего то что там дслво все поля... что еще на схемке можно написать?

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

Зачем это может понадобиться — понятия не имею.

Чтобы свободно и безболезненно откатываться на ту, где меньше всего багов. Ну и для простой реализации «веток» стабильных и нестабильных пакетов с размаскированием а-ля гента.

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

Главное тут - несколько версий конфликтующих пакетов, это особенно полезно при разработке, но и простому пользователю сильно уменьшает количество проблем.

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

Всегда работает

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

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

А ещё пользователь без прав root'а может ставить себе любое ПО в $HOME, и пользоваться им без вреда для прочего ПО в системе.

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

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

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

Чисто функциональный

Кто-нибудь может объяснить?

purely functional означает, что одинаковый файл конфигурации гарантирует одинаковое поведение системы, независимо от версий ПО в репозитарии и фазы луны. Когда в guix'е просишь поставить определённую версию программы, то получаешь всегда один и тот же до последнего байта бинарник, который связан с одними и теми же до последнего байта библиотеками.

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

Camel ★★★★★
()
Ответ на: Всегда работает от Camel

А ещё пользователь без прав root'а может ставить себе любое ПО в $HOME, и пользоваться им без вреда для прочего ПО в системе.

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

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

Категорически согласен

устраняет «странные» баги в деплое и развертывании серверов.

Категорически устраняет. Потому что ПО на всех серверах в кластере, а до того на ЭВМ разработчиков до последнего байта одинаковое.

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

Я поставил Smplayer. По идее, пакетный менеджер должен был подтянуть или спросить, какую из зависимостей поставить? А тут, поставил, а воспроизводить не может. Надо ставить mplayer...

Поставил firefox, захожу на ютуб, а он не может видео воспроизводить. Догадайтесь, почему?

Скайп ставить даже не стал пробовать, но все проги были так пораздербанены. Сиди гадай, чего она ещё может хотеть.

Да и синтаксис Nix... его точно емаксовцы придумывали, инопланетный.

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

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

Я поставил Smplayer. По идее, пакетный менеджер должен был подтянуть или спросить, какую из зависимостей поставить? А тут, поставил, а воспроизводить не может. Надо ставить mplayer

Хм, его я еще не ставил, но у него вполне может не быть бэкенда в зависимостях, это уже вопрос конкретного пакета / «ебилда».

Поставил firefox, захожу на ютуб, а он не может видео воспроизводить. Догадайтесь, почему?

Ставил хромиум, на ютуб работает (но у него вроде встроенный флеш), гугловые конференции работают полностью и камера, и микрофон, и видео.

Скайп ставить даже не стал пробовать

Прекрасно заработал :3

Да и синтаксис Nix... его точно емаксовцы придумывали, инопланетный

Там помесь хаскеля и json, но это фигня, и не к такому привыкали.

Ни одна программа так и не появилась в меню, хотя запустить из командной строки могу. Спрашивается, зачем тогда примотали КДЕ?

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

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

Забавно, я заметил только положительные стороны а ты - отрицательные. Истина, как говорят, где-то рядом)

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

Чтобы свободно и безболезненно откатываться на ту, где больше всего дыр, потому что патчить все 100500 версий со времён Ноя никому не упёрлось :}

Deleted
()
Ответ на: Категорически согласен от Camel

Потому что ПО на всех серверах в кластере, а до того на ЭВМ разработчиков до последнего байта одинаковое.

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

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

Зачем их патчить? Можно брать из апстрима. Тегировать стабильные и нестабильные версии, правильно расставлять зависимости — вот главная проблема, на которой погорела гента.

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

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

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

ixrws ★★★
()

Nix из NixOS — «чисто функциональный» пакетный менеджер в том смысле, что «рецепты сборки» (типа ебилды) пишутся на функциональном языке программирования. Типа как LaTeX: набор макросов к императивному паскаль-подобному TeX, а lout/nonpareil — функциональный язык разметки.

Из «чистой функциональности» следует отсутствие побочных эффектов и воспроизводимость сборок. Например, чтобы обеспечить воспроизводимость в типичном Makefile нужно иметь возможность определить, что переменные окружения везде одинаковы. Что при сборке драйверов например, используется версия ядра, версия libc, версия gcc, binutils, make и т.п. всё по цепочке. Поэтому стандартного Linux ABI не существует: есть некоторый произвол относительно версий тулчейна и ядра, ведь оно собиралось на предыдущей конфигурации, а она у всех разная. Другое дело, что обычно например изменения в glibc не ломают бинарную совместимость (типа не работающего memmove) поэтому на различия в ABI можно положить.

Поэтому для полной воспроизводимости сборок нужно зафиксировать ВСЕ зависимости, включая неявные и описать их явно. В пакетном менеджере Nix ровно это и происходит: окружение, конфиги типа etc.d, сервисы и демоны описываются явно, как очередная версия. Плюс обычные зависимости времени сборки. Плюс зависимости времени выполнения.

closure пакета , замыкание в NixOS представляет собой транзитивное замыкание: все файлы этого пакета, со ссылками на зависимости. Собственно Nix pkg представляют собой объектное хранилище типа git blobs, а вместо файлов конкретных версий — идут симлинки на объекты хранилища. Есть сборка мусора, как в git.

из-за отсутствия побочных эфектов by design составить такое замыкание особенно просто.

а Guix — это по сути другой DSL к Nix. Guix построен на базе схемы Guile поверх Nix пакетного менеджера, основное отличие в том, что «рецепты сборки» можно писать не на функциональном своём особенном nixpkg, а на обычной схеме, в стиле, похожем на ебилды. При этом это всё равно функциональный язык, просто в виде лиспа. Что удобно тем, что можно например, генерировать эти S-выражения, а не писать руками.

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

Прям до последнего байта

Компилятор же может по-разному заоптимизировать, даже с одинаковыми параметрами, разве нет?

Нет. Любой пакет в GuixSD ставится в /guix/<hash>-package_name-version. hash это контрольная сумма от рецепта сборки этого пакета, которая содержит ссылки (по аналогичным хэшам) на конкретные версии компилятора, сборщика и прочего и конкретные инструкции по сборке. Конкретные версии компилятора и сборщика это даже не просто номера версий, а конкретные бинарники. Собирая пакет одинаковыми бинарниками компилятора с одинаковыми оптимизациями получаем одинаковые бинарники*.

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

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

Критично

А что если софту будет критично systemd работает или традиционная система?

Одинаковые системные конфиги дают одинаковое поведение систем. Теоретически демон инициализации мог бы прописываться в системном конфиге. На практике NixOS это строго systemd, GuixSD это строго dmd. Так что как бы критично не было бы для какой-нибудь программы будет её дёргать systemd или dmd, на практике её поведение в GuixSD всегда будет одинаковым, потому что её всегда будет дёргать только dmd.

И таки да, одинаковое поведение гарантируется для одинакового окружения. То есть одни и те же программы с одними и теми же бинарниками могут себя повести по разному на ЭВМ разработчиков и сервере если там, например, разные ядра и/или разные процессоры. Ядра можно принудительно поставить одинаковые там и сям. А баги от разных процессоров штука редкая.

Camel ★★★★★
()
Ответ на: Прям до последнего байта от Camel

Конкретные версии компилятора и сборщика это даже не просто номера версий, а конкретные бинарники. Собирая пакет одинаковыми бинарниками компилятора с одинаковыми оптимизациями получаем одинаковые бинарники*.

С одинаковыми бинарниками, оптимизациями, но на разном железе, это не может включать разные алгоритмы в компиляторе?

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

Скорее нет, чем да

С одинаковыми бинарниками, оптимизациями, но на разном железе, это не может включать разные алгоритмы в компиляторе?

Насколько разном железе? POWER и SPARC?

И вообще, это вопрос не к Guix'у, а компилятору. В gcc оптимизации определяются не хостовой системой, а целевой.

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

Один из вариантов - можно без особых проблем держать софтины несовместимые по версиям зависимостей. Этакой костыль вокруг dll hell.

Dark_SavanT ★★★★★
()
Ответ на: Всегда работает от Camel

А ещё пользователь без прав root'а может ставить себе любое ПО в $HOME, и пользоваться им без вреда для прочего ПО в системе.

А в других дистрибутивах что мешает ставить любое ПО в $HOME и пользоваться? У меня в хомяке, например отдельный lib с самосборными либами и LD_LIBRARY_PATH прописан в ~/.bashrc, вместе с нужными $PATH.

DELIRIUM ☆☆☆☆☆
()
Ответ на: комментарий от loz

Маразм vs Дебильность

Да банальное intel vs amd64

Ещё раз, это вопрос к канпелятору. Может ли канпелятор выдать одинаковый бинарник при одинаковых опциях?

Не скажу за всех, но кажися для gcc имеет значение не хостовая архитектура, а целевая. Целевая архитектура задаётся в рецепте сборки, в Makefile или где-то ещё в подобном месте. Хостовая архитектура при этом значения не имеет.

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

Левой пяткой правое ухо

А в других дистрибутивах что мешает ставить любое ПО в $HOME и пользоваться?

Ну оукэй, а ставите вы библиотеки в $HOME/lib apt-get'ом? Удобно?

Camel ★★★★★
()
Ответ на: Критично от Camel

Думаю - теперь я понял достаточно. Спасибо за объяснение.

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

а Guix — это по сути другой DSL к Nix. Guix построен на базе схемы Guile поверх Nix пакетного менеджера

Прям поверх? То есть когда ставишь Guix у тебя будет установлен и Nix? И можно поставить и использовать Guix на NixOS?

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

Можно

И можно поставить и использовать Guix на NixOS?

Можно хоть на Debian. Но нельзя заставить Guix использовать пакеты из NixOS'а и наоборот, они не взаимозаменяемы.

Прям поверх? То есть когда ставишь Guix у тебя будет установлен и Nix?

nix взят за основу, но guix это не просто обёртка для nix. Часть вещей там могли уже давно переписать, что-то добавить.

Camel ★★★★★
()
Ответ на: Можно от Camel

Guys, this is not a dick-sucking contest

И таки названия они себе придумывают будто участвуют в конкурсе. Одно хуже другого.

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

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

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

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

Я наврал, все появилось в меню.

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

Хз, я менюшку открыл, а там и пиджин и хромиум и скайп, ну и все остальное есть.

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