>>636
> никакой метод ни лучше, ни хуже, они разные и в одном случае лучше будет один, в другом, другой.
В теории декларативные методы лучше до тех пор, пока не нужно ковыряться в ньюансах глубже, чем они предоставляют крутилок с простыми интерфейсом: они позволяют меньшими действиями добиваться тех же результатов. Проблема тут скорее не в самих методах, а в привычках пользователей: если пользователь привык всё делать императивными методами и они его не задолбали, то переход к декларативным вызовет у него только недовольство (т.к. они за него переставляют ноги, когда он привык ходить самостоятельно), что хорошо видно на примере противников systemd.

> Если это рабочая станция с простым пользователем за ней, то ничего проще даблклик-далее-далее не может быть.
Не согласен. Найти пакет в каком-нибудь gnome-software (https://wiki.gnome.org/Apps/Software) и кликнуть единственную кнопку «install» проще. Было бы проще, если б этот зоопарк абстракций поверх абстракций и притворяющихся десктопными приложениями демонов поменьше глючил. Впрочем, эти проблемы могли уже и пофиксить, я в последний раз это дело тыкал года два назад.

Об отличии пакетных менеджеров guix и nix от классических пакетных менеджеров, таких как apt, portage и прочих.

Чего такого случилось, что их решили называть декларативными, причём в противоположность существующим решениям? Где тут дыра между стульями?

Ключевым различием тут является повышение уровня абстракции. Guix и nix управляют не отдельными пакетами, а сущностями на шаг более высокого порядка — состояниями операционных систем, пользовательских профилей и сред для выполнения задач (и уже в контексте перечисленных сущностей — отдельными пакетами, так что >>637 может оставаться верным). Этими сущностями они позволяют по всякому жонглировать — в т.ч. перекатываться между ними и воспроизводить их на других машинах, в то время как классические PM вообще о таких штуках ничего не знают и максимум, что могут себе в этом плане позволить — снэпшоты файловых систем (здравствуй, скрючивающаяся от хардресетов btrfs).

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

Однако, я залез не вполне в ту сторону, о которой тут хотел поговорить. Но это уже для следующих постов.

>>642
> Зачем отучать?
Для репродуцируемости.

Если пользователь гадит в управляемую классическим пакетным менеджером систему make install'ом от рута, то он теряет эту управляемость: ПМ не сможет при своей работе учесть зависимости и конфликты того, чем насрано, а также обеспечить его обновление и удаление.

Если в декларативной ОС пользователь меняет что-то в /etc/, то получается уход от соответствия декларации, и повторно из тех же конфигов точно такая же ОС уже не получится.

> А если нужно самому подправить конфигурации?
Средствами пакетного менеджера, через декларацию требуемых правок в конфигурационном файле операционной системы.

> А если вообще нужно из исходников собрать?
Опять же — средствами пакетного менеджера. Создаёшь свой репозиторий, а в нём — описания пакетов со сценариями сборки. В инструментарии dpkg, кстати, этот процесс организован далеко не лучшим образом, если что — в portage, guix и nix намного проще всё.

> Впрочем, может ты про десктопные ос говоришь?
Я обобщаю. Про серверные — тоже.

Понимаю, что совсем от правок /etc/ не уйти — в нём даже автоматически появляются уникальные конфиги вроде хост-ключей sshd. Но учиться сводить их к минимуму стоит.

>>646
> Оверкилл, имхо
Это вопрос поддержания порядка в операционной системе. Ты же не руководствуешься тем, что мусор проще кинуть на пол, а не нести до помойного ведра, верно? С моей точки зрения, порядок в операционной системе — это в т.ч. единообразное управление всем установленным софтом. При установке софта руками тебе самому приходится помнить о том, где там и что лежит и как работает, что через два года может быть проблемой и совершенно точно будет проблемой при передаче сервера другому человеку.

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

> А править конфиги средствами пакетного менеджера, а это как вообще?
Следующий уровень, https://nixos.org/nixos/options.html.

Наглядный пример превосходства декларативного подхода можно наблюдать в соседнем треде: >>657 видит в задаче настройки впски кучу гемора, а >>658 продекларировал установку и настройку всего нужного в скрипте и теперь решает эту задачу одним действием. Запустил скрипт — через пару минут (в зависимости от объёма устанавливаемого софта) сервер готов.

>>720
> Зачем
Для воспроизводимости, в т.ч. отделения мух от котлет (железо-специфичной части конфигурации от задаче-специфичной).

> он не поддерживает правку конфигов для всех программ
Поддерживает. В nixos:
environment.etc."имя_файла".text = ''
текст
'';

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

>>725
Это та задача, для которой LFS непригоден. Он для подробного изучения софта, а не для глубокой автоматизации установки, что есть вещи противоположные, хоть и взаимосвязанные: подробное изучение облегчает дальнейшую автоматизацию, раскрывая возможности её тонкой настройки и границы функционала компонентов.