Ахноледж

А может ты напишешь какую-то обзорную телегу про эти Guix и GuixSD в General? Народу ведь явно интересно. Подписался на соответствующие тэги.

Запрос принят. Возможно напишу.

Guix->Emacs

Ппц, зачем у guix в зависимостях emacs?

Это вы где такое обнаружили? Guix и Emacs сильно дружат, в последнем есть режим для работы с первым, получается что-то вроде aptitude, только в Emacs'е и для Guix'а. В терминах Debian'а Emacs для Guix должен быть в Recommends или Suggests, но не Depends.

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

networking.extraHosts =
''
192.168.0.1 lanlocalhost
192.168.2.1 somehost
...
'';

Выглядит интересно. И идеи здравые... Одно только непонятно - как Guix считает DAG зависимостей для пакетов с build parameters? И считает ли вообще? То есть возможно ли управление системой типа use-флагов Gentoo? Киньте ссылку, если не трудно.

Невозможно

То есть возможно ли управление системой типа use-флагов Gentoo?

Такого пока нет. Есть multiple outputs, но до USE-флагов как до Китая раком.

программу нельзя поставить просто разбросав файлы в /usr/bin и /usr/lib, не заработает

Почему? У них свой ld.so?

ls /bin
sh

ls /sbin
No such file or directory

ls /lib
No such file or directory

ls -R /usr
/usr:
bin

/usr/bin:
env

ls /lib/ld*
No such file or directory

Почему так, читаем параграф «NixOS and the FHS» http://sandervanderburg.blogspot.ru/2011/11/on-nix-nixos-and-filesystem-hiera...

Как в этом идеальном мирке запустить сторонний блоб?

• Отдельное окружение

  Вышел NixOS 14.04 (комментарий) +

  shellHook = ''
  LD_LIBRARY_PATH+=":${xorg.libX11}/lib"
  ...
  '';
  

• Патчинг бинарника: путь до ld.so, RPATH

  https://nixos.org/patchelf.html

• chroot, линки руками и прочие методы

  https://nixos.org/wiki/Steam#Approaches

А есть истории успеха больших и сложных продов у крупных компаний, или это только для десктопов разработчиков GuixSD?

годнота!

а между тем, msys2 вполне себе неплохой арч под винду.
в nix из коробки есть cygwin /etc/portage/profile, так что вполне себе хакабельная идея проекта: спортировать в guix «ебилды под винду» частично из msys2, частично из nix.

тащем-та, всю эту скобкоту можно кодогенерировать полуавтоматически, оттранслировав через наколенный DSL из ебилдов или арчбилдов, в стиле org-mode babel literate programming.

Почему? У них свой ld.so?

1. там есть каноничный костыль под названием patchelf, чтобы обеспечить воспроизводимость билдов.

каноничным способом в nixos считается при сборке жёстко прописывать RPATH. patchelf — это попытка прописывать нужный ld.so прямо в бинарнике, сохраняя воспроизводимость билдов

а то вдруг сломается ABI и старая glibc не заработает с новым пакетом, — что, пересобирать полсистемы через revdep-rebuild как в генте например?

нет уж, проще (с их точки зрения) прописать нужный glibc, ld.so и т.п. сразу в бинарнике и канонiчно обеспечить воспроизводимость сборок, до последнего тулчейна.

там конфигами тоже забавным образом управляют — обеспечивая воспроизводимость и версионность.

функциональщина во все поля, же ну.

и объектно-ориентированное хранилище (content storage), почти как в git. даже сборка мусора тоже есть, и симлинки на конкретный артефакт, и костыль над симлинками.

программу нельзя поставить просто разбросав файлы в /usr/bin и /usr/lib, не заработает
почему?

2. потому что разбрасывать нужно всё nix-closure — замыкание в объектном хранилище. а потом по транзитивности замыкания, вытаскивать весь дом который построил джек, вплоть до glibc и тулчейна.

хотя потом над этим всё равно /usr/bin, /usr/lib маскирует симлинками в объектное хранилище.

плюсы ещё и в том, что по идее работает дедубликация хардлинками и в принципе должно работать обновление бинарных пакетов сборок из CI фермы (Hydra)  — дельтами, разницей от предыдущей сборки.

тыц

use-binary-caches

If set to true (the default), Nix will check the binary caches specified by binary-caches and related options to obtain binary substitutes. binary-caches

A list of URLs of binary caches, separated by whitespace. The default is https://cache.nixos.org. binary-caches-files

A list of names of files that will be read to obtain additional binary cache URLs. The default is /nix/var/nix/profiles/per-user/username/channels/binary-caches/*. Note that when you’re using the Nix daemon, username is always equal to root, so Nix will only use the binary caches provided by the channels installed by root. Do not set this option to read files created by untrusted users! trusted-binary-caches

A list of URLs of binary caches, separated by whitespace. These are not used by default, but can be enabled by users of the Nix daemon by specifying --option binary-caches urls on the command line. Unprivileged users are only allowed to pass a subset of the URLs listed in binary-caches and trusted-binary-caches. extra-binary-caches

Additional binary caches appended to those specified in binary-caches and binary-caches-files. When used by unprivileged users, untrusted binary caches (i.e. those not listed in trusted-binary-caches) are silently ignored. signed-binary-caches

If set to *, Nix will only download binaries if they are signed using one of the keys listed in binary-cache-public-keys. binary-cache-public-keys

если не юзать бинарные substitutes, то должен собирать с 0 из «почти ванильных» (какие-то патчи всё-таки есть, да и костыли с patchelf) сырцов. кучи USE-флагов как в генте тут нет, что также доставляет к воспроизводимости билдов.

Самая большая трудность, что программу нельзя поставить просто разбросав файлы в /usr/bin и /usr/lib, не заработает. Я думаю это отпугивает 90% разработчиков, у которых и так всё работает в Debian'е и Fedor'е, где суть пакетных менеджеров как раз в раскидывании файлов.

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

к примеру, какой-то пакет требовал симлинк на libOpenGL*.so, и конфликтовал в конфигурациях MESA/nvidia blob: ставишь один пакет, затем другой, он сносит симлинк из первого, после чего третий пакет не собирается — не находит библиотеки.

первое время приходилось руками симлинк пересоздавать, и обновлять мир аккуратно, помня об этом.

половина поломанных зависимостей в генту — из-за такой вот неявной невоспроизводимости билдов.

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

другое дело, если жёстко-принудительно прописыывать ВСЕ зависимости (вклюая неявные).

чето вслух

хитрая философия насчёт необходимости patchelf описана по идее здесь, на 11 странице (и ещё подробнее в диссере с примерами на тему «The Purely Functional Software Deployment Model.», см. также хелловорд экзампле от disnix, nixops, вот это всё на тему «Declarative distributed systems modeling» и CI, devops)

:

Software packages Nix has no /bin, /usr, /lib, /opt or other “stateful” directories containing software packages, with a single exception: there is a symlink /bin/sh to an instance of the Bash shell in the Nix store. This symlink is created by the activation script. /bin/sh is needed because very many shell scripts and commands refer directly to it; indeed, the C library function system() has a hard-coded reference to /bin/sh. To our surprise, /bin/sh is the only such compromise that we need in NixOS. Other hard-coded paths in packages (e.g., references to /bin/rm or /usr/bin/perl) are much less common and can easily be patched on a per-package basis. Such paths are uncommon in widely used software because they are not portable in any case (e.g., Perl is typically, but not always installed in /usr/bin/perl). They are relatively more common in Linux-specific packages that we needed to add to Nixpkgs to build NixOS. An interesting class of packages to support are binary-only packages, such as Adobe Reader and many games. While Nix is primarily a source-based deployment system (with sharing of pre-built binaries as a transparent optimisation, as discussed in Section 3), binary packages can be supported easily: they just have a trivial build action that unpacks the binary distribution to $out. However, such binaries won’t work as-is under NixOS, because ELF binaries (which Linux uses) contain a hard-coded path to the dynamic linker used to load the binary (usually /lib/ld-linux.so.2 on the i386 platform), and expect to find dependencies in /lib and /usr/lib. None of these exist on NixOS for purity reasons. To support these programs, we developed a small utility, patchelf, that can change the dynamic linker and RPATH (runtime library search path) fields embedded in executables. Thus, the derivation that builds Adobe Reader uses patchelf to set the acroread program’s dynamic linker to /nix/store/...-glibc-.../lib/ld-linux.so.2 and its RPATH to the store paths of GTK and other

Был dmd. Это он и есть, просто переименованный.

хорошо, а то c Digital Mars D комплиятором референсным явный конфликт имён.

В чём отличие guix от nix? Почему в них используется сборка мусора?

Уборка чистого

В чём отличие guix от nix?

Guix отличается от nix примерно так:

https://pbs.twimg.com/media/CouOwSdW8AAXrkF.jpg

В одном Scheme и скобочки, в другом свой специфичный DSL без скобочек.

Почему в них используется сборка мусора?

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

Благодарю за ответ.

Да, вы правы. https://nixos.org/wiki/Install/remove_software#Garbage_collection

лукиш, уйди

Почему в них используется сборка мусора?

сборка мусора происходит в объектном хранилище (контент-адресуемой памяти, с адресом = хешу от содержимого) /nix/store/..., в котором хранятся файлы устанавливаемого пакета ($out, nix-closure — то есть, «замыкание» от пакета).

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

в типичные пути /usr/{lib,bin,share,doc,...} прописываются симлинки на объекты в «замыкании»

можно поставить два пакета разных версий одновременно, переключив симлинки (хвосты в объектном хранилище)

при деинсталляции чистится замыкание из объектное хранилище и симлинки.

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

в объектном хранилище git команда git gc делает примерно то же самое.

nix-env --delete-generations old nix-collect-garbage

ну при деинсталляции не сразу чистится, да.

рефлексивность, симметричность, транзитивность, матеша, мамка, борщ

Если при удалении пакета удаляются все соответствующие ему симлинки, откуда возникают «бессылочные» неудалённые пакеты?

cast tailgunner

а LGBT считает такой подход свободным

Исправленому верить.