Главная | Настройки | NSFW
Тема:
Доски


[Ответить в тред] Ответить в тред

[Назад] [Обновить тред] [Вниз] [Каталог] [ Автообновление ] 24 / 8 / 8

Есть два стула: декларативный и императивный Anonymous No.628
group by anonym[...].jpg (787 KB, 1920x1080)
И нет, это тред не о программировании, а об организации софта в операционные системы. Или о блуждании границы между этими сущностями, если будет угодно.

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

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

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

Императивный метод установки софта — даблклик по setup.exe, выбор компонентов, далее → далее → далее → отказаться от перезагрузки, и так для каждой программы. Декларативный ­— apt install софтина1 софтина2 софтина3.

Однако, тот же apt install по сравнению с декларацией требуемого софта в конфиге операционной системы (как в nixos и guixsd) является императивным.

Ещё пример — разница между управлением сборкой софта в gentoo и debian: в gentoo администратор описывает нужные опции сборки в системных конфигах, тогда как в debian для этого нужно расковыривать пакеты и патчить их скрипты сборки, которые ещё и сами по себе представляют из себя тот ещё зоопарк.

Разница между gentoo и lfs — декларативный и императивный подходы в чистом виде: в gentoo описываются опции сборки, после чего запускается автоматическая сборка требуемого софта (в идеале, на практике это часто несколько иначе), тогда как в lfs всё нужно пошагово собирать
и устанавливать руками.

Эта модель также описывает разницу между sysvinit с километровыми шелл-скриптами костылей и systemd: к systemd демоны прикручиваются его средствами, единообразно, лаконично и переносимо на любую ОС с systemd или его эмуляцией (shepherd, nosh), в то время как на шелл-скриптах городятся костыли произвольным образом и рандомными средствами операционной системы.
Anonymous No.629
>Декларативные методы по сравнению с императивными являются более высокоуровневыми, т.е. позволяют меньшими усилиями добиться больших результатов, но ценой этому является меньшая контролируемость результата.
>Императивный метод установки софта — даблклик по setup.exe, выбор компонентов, далее → далее → далее → отказаться от перезагрузки, и так для каждой программы.
Мне кажется или тут есть противоречие?
А вообще, какая разница, какой метод установки используется.
Anonymous No.630
>>629
Не понял, в чём именно противоречие?
Anonymous No.631
>>630
Ну вроде куда уж более высокоуровневее, чем нажать пару кнопок далее-далее и усилий на это вообще не требуется.
Anonymous No.632
>>631
Усилия требуется на нажимание этих кнопок каждый раз руками. Запускаешь сетап, потом ещё что-то там в нём кликаешь, каждый раз своё, и так для каждой программы.

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

Да, я не ответил на вопрос, «какая разница». Разница в мощности инструментов: чем выше их уровень, тем проще решать с их помощью комплексные задачи вроде установки ОС на большое кол-во машин, а также эти машины проще в поддержке.
Anonymous No.633
>>632
s/весь указанный софт сразу/установит \0/
Anonymous No.634
Декларативный метод это только nixos и guix.
Anonymous No.635
>>634
А если debian устанавливать preseed-файлом с установкой и настройкой всего необходимого через него?

Олсо, ты не понял аналогий. Метод в отношении чего? В случае с GuixSD, NixOS и Debian установкой preseed-файлом объектом декларации является операционная система, но кто мешает рассматривать объектами деклараций сущности низшего порядка, вроде наборов устанавливаемого софта или настроек демона?
Anonymous No.636
>>632
На самом деле никакой метод ни лучше, ни хуже, они разные и в одном случае лучше будет один, в другом, другой. Если это рабочая станция с простым пользователем за ней, то ничего проще даблклик-далее-далее не может быть. А для сервера, конечно же, пакетные менеджеры намного удобнее, когда одной командой можно установить всю кучу нужного софта с зависимостями.
Anonymous No.637
>>635
>но кто мешает рассматривать объектами деклараций сущности низшего порядка, вроде наборов устанавливаемого софта или настроек демона?
Никто, guix и nix именно так и делают.
Anonymous No.638
group by junwoo[...].jpg (335 KB, 1280x1459)
>>636
> никакой метод ни лучше, ни хуже, они разные и в одном случае лучше будет один, в другом, другой.
В теории декларативные методы лучше до тех пор, пока не нужно ковыряться в ньюансах глубже, чем они предоставляют крутилок с простыми интерфейсом: они позволяют меньшими действиями добиваться тех же результатов. Проблема тут скорее не в самих методах, а в привычках пользователей: если пользователь привык всё делать императивными методами и они его не задолбали, то переход к декларативным вызовет у него только недовольство (т.к. они за него переставляют ноги, когда он привык ходить самостоятельно), что хорошо видно на примере противников systemd.

> Если это рабочая станция с простым пользователем за ней, то ничего проще даблклик-далее-далее не может быть.
Не согласен. Найти пакет в каком-нибудь gnome-software (https://wiki.gnome.org/Apps/Software) и кликнуть единственную кнопку «install» проще. Было бы проще, если б этот зоопарк абстракций поверх абстракций и притворяющихся десктопными приложениями демонов поменьше глючил. Впрочем, эти проблемы могли уже и пофиксить, я в последний раз это дело тыкал года два назад.
Anonymous No.641
group by kannar[...].jpg (486 KB, 1200x654)
Об отличии пакетных менеджеров guix и nix от классических пакетных менеджеров, таких как apt, portage и прочих.

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

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

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

Однако, я залез не вполне в ту сторону, о которой тут хотел поговорить. Но это уже для следующих постов.
Anonymous No.642
>>641
>если с пакетными менеджерами надо было отучать людей ставить софт руками, то теперь их надо отучать ставить пакеты руками и лазить руками в /etc/: теперь за них это делает PM.

Зачем отучать? А если нужно самому подправить конфигурации? А если вообще нужно из исходников собрать? Впрочем, может ты про десктопные ос говоришь? Там такое и правда, наверное, редко когда надо.
Anonymous No.643
group by 14 (vi[...].png (235 KB, 935x652)
>>642
> Зачем отучать?
Для репродуцируемости.

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

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

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

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

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

Понимаю, что совсем от правок /etc/ не уйти — в нём даже автоматически появляются уникальные конфиги вроде хост-ключей sshd. Но учиться сводить их к минимуму стоит.
Anonymous No.646
>>643
>Создаёшь свой репозиторий, а в нём — описания пакетов со сценариями сборки.
Оверкилл, имхо, для сервера, где это надо раз в пару лет, точно. Если мне нужно собрать новую версию софтины, которой нету в репозиториях или со своими модулями, я ее просто собираю, при этом установить зависимости вручную не очень напрягает.
А править конфиги средствами пакетного менеджера, а это как вообще? Даже не слышал, что так можно.
Anonymous No.647
group by rekka.[...].png (1628 KB, 949x858)
>>646
> Оверкилл, имхо
Это вопрос поддержания порядка в операционной системе. Ты же не руководствуешься тем, что мусор проще кинуть на пол, а не нести до помойного ведра, верно? С моей точки зрения, порядок в операционной системе — это в т.ч. единообразное управление всем установленным софтом. При установке софта руками тебе самому приходится помнить о том, где там и что лежит и как работает, что через два года может быть проблемой и совершенно точно будет проблемой при передаче сервера другому человеку.

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

> А править конфиги средствами пакетного менеджера, а это как вообще?
Следующий уровень, https://nixos.org/nixos/options.html.
Anonymous No.659
group by viscou[...].png (295 KB, 1000x742)
Наглядный пример превосходства декларативного подхода можно наблюдать в соседнем треде: >>657 видит в задаче настройки впски кучу гемора, а >>658 продекларировал установку и настройку всего нужного в скрипте и теперь решает эту задачу одним действием. Запустил скрипт — через пару минут (в зависимости от объёма устанавливаемого софта) сервер готов.
Anonymous No.720
Зачем мне править конфиги средствами пакетного менеджера, если он не поддерживает правку конфигов для всех программ? Мне придется использовать костыли в виде bash-скриптов, не лучше ли тогда просто написать bash-скрипт, который развертывает нужную мне конфигурацию?
Anonymous No.721
group by barasu[...].jpg (2176 KB, 2024x2000)
>>720
> Зачем
Для воспроизводимости, в т.ч. отделения мух от котлет (железо-специфичной части конфигурации от задаче-специфичной).

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


> не лучше ли тогда просто написать bash-скрипт
Во первых, он будет намного больше и сложнее.
Во вторых, классические дистрибутивы не поддерживают смену таких конфигураций на лету, это можно сделать только через переустановку, что вызывает в т.ч. и сложности в их отладке.
Anonymous No.723
В LFS надо встраивать свой скрипт для сборки всей системы, модульный, с отключаемыми модулями для сборки отдельных программ.
Anonymous No.724
>>723
Это тогда уже будет не LFS, а новый дистрибутив. Суть LFS в ручной сборке, в максимально императивном подходе к установке системы для изучения всех тонкостей этого процесса.
Anonymous No.725
>>724
Хуясе, а если надо много образов систем для разных платформ сделать? Это было бы неудобно.
Anonymous No.727
group by kazu.4[...].jpg (572 KB, 1316x1328)
>>725
Это та задача, для которой LFS непригоден. Он для подробного изучения софта, а не для глубокой автоматизации установки, что есть вещи противоположные, хоть и взаимосвязанные: подробное изучение облегчает дальнейшую автоматизацию, раскрывая возможности её тонкой настройки и границы функционала компонентов.
Anonymous No.728
>>628 (OP)
Декларативный подход более программерский, императивный - более хакерский. В императивном проще изучать систему, менять, экспериментировать копаться в ней. В декларативном проще сделать как надо, держать систему под контролем, обеспечить воспроизводимость.

[Назад] [Обновить тред] [Вверх] [Каталог] [ Автообновление ]
24 / 8 / 8

[Ответить в тред] Ответить в тред

Ответ в тред No.628
15000
Файлы. Макс объем: 20 MB, макс кол-во файлов: 4

Ответ в тред No.628X
15000
Файлы. Макс объем: 20 MB, макс кол-во файлов: 4
Кликни/Брось файл/ctrl-v
НастройкиX
X
Избранное
Топ тредов