LINUX.ORG.RU

Для тех, кто думает перейти на NixOS

 


8

5

Собственно по мотивам ТЫЦ но про NixOS и на основе моего опыта эксплуатации сабжа в течение как минимум одного года восьми месяцев и двух дней или шестьсот двенадцати дней кому как угодно. Ибо именно столько у меня стоит NixOS основной системой тыц.

Моей предыдущей системой была гента поэтому и свои сравнения я буду проводить непосредственно с ней. Все написанные мною слова выражают мои собственные мысли и не были призваны разжигать какие бы то ни было конфликты и/или жжения в любых частях тела прилегающих к седалищному нерву.

Так вот детки. Гента местами хороша… хотел бы я так написать но увы нет. Есть кардинальные проблемы с которыми она не справиться. Основная это toolchain. У вас попросту не может быть консистентной системы с самым распоследним toolchain-ом и довольно старыми выдержанными проверкой временем программами (Либо наоборот). Это не значит что такую проблему нельзя решить костылями chroot-а или некими иными методами… Это значит лишь то что такая проблема у дистрибутива как минимум есть в наличие.

Ты сейчас задвинул некую чушь. {У меня нет}/{Мне не нужны} старые программы.“ - Да дело ведь не только в этом. Те кто прожил с гентой достаточно припомнят не один случай неудачного обновления glibc в результате которого всему приходил северный полярный лис. „Бэкап спасёт“ да не без этого. Однако бэкап не исправляет саму изначальную проблему.

Так вот последние два абзаца написаны собственно только ради того что… Да детки в NixOS таких проблем нет. И быть не может by design. И я скромно умалчиваю про другие архитектуры, контейнера, FHS environment и прочие побочные плюшки.

Дальше меня ждала «ломка» поскольку во всех дистрибутивах корень системы это важная штука которую можно пощупать своими загребущими ручёнками… Да а в то время как в NixOS из всего корня так сказать материальны только /etc/nixos, /root и /nix а остальное симлинки… Тудумс! Занавес.

Немного про установку. Генту можно собрать за время от пары часов до нескольких дней. Развернуть из бинпакетов можно минут за сорок ну плюс минус около того. NixOS бинарный дистрибутив поэтому кампелять тут ничего не нужно.

Канпельять нинада. nixos ацтой. Моя отсельда мухожук.“ Однако стоит лишь переопределить дефолт и если это столь необходимо пакетный манагер сам пересоберёт то что нужно пересобрать. Вкуснятина!

Дальше сам процесс разработки. Про генту я скромно умолчу. А вот NixOS разрабатывают на гитхабе открыто, свободно и без бюрократии и 1770 запросов на слияние и 3753 проблемы тому доказательство.

Я скажу так в генте для меня всегда была головной болью настроить gnome/kde/plasma. Полные метапакеты натащат столько что ппц а минимальные как правило просто обрезаны по самое немогу и для комфортного существования приходилось искать ту самую золотую середину самостоятельно. В NixOS просто дефолтный выбор мне что называется зашел на ура. Одной проблемой меньше.

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

В NixOS пакетный менеджер заведует не просто версией хромиума но и всеми его настройками и да даже его расширениями.

Любые нативные игрушки steam-run спасает и делает не просто хорошо а прям прекрасно.

Да ладно… Вот прям взял и описал идеал. Не верю.“ Есть и баги. Дальше о них.

Ну не то чтобы это было проблемой но как с самой первой инсталлиции так и до сих пор - Only english language available in plasma regional settings #33987, Missing a lot of translation in plasma5-based system. #37741 Да все преведенные решения перепробовал но баг как был так и есть.

Из того что заметил в последнее время HDD not mounted, system don't boot #32588 это про btrfs на luks. Но оно тоже странное то есть то нет… В общем закономерности я не заметил но у себя наблюдал.

Ну и покамест на этом всё. Надеюсь мои многобукав помогут кому нибудь сделать свой выбор.

★★★★★

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

Я ничего не путаю, «опция» в конфиге по сути = пакет. Точнее просто ссылка на сборочный файл .nix

Нет, не пакет, а именно опция. Пакетом это уже точно назвать не выйдет, максимум деривацией. Например, в списке опций верхнего уровня есть такие, как filesystems, fonts, i18n, networking, services, sound и users. Опции могут зависеть от пакетов, но сами они всё же не есть пакеты. Просто в NixOS очень явно разнесены действия «установить» [=подсунуть файлы пакета в системный или пользовательский $PATH] и «настроить» [=сделать так, чтобы оно ещё и работало каким-нибудь определённым образом]. В классических дистрибутивах эти два действия либо слеплены в одно, как в Debian, где post-install скрипты часто просто берут и запускают свежеустановленный демон (или даже что-нибудь в /etc меняют), либо второе может быть переложено на пользователя, как в Arch — в расчёте на то, что он прочтёт прекрасную документацию в Wiki и сам поймёт, что и как он хочет с этим пакетом делать.

И документация в NixOS не то чтобы отсутствует: она просто неполна, специфична и разрознена. Составлять конфиг не то чтобы сложно, даже напротив: систему в простых случаях можно наконфигурировать прямо по одному только списку опций — берём и копируем себе одну за одной в /etc/nixos/configuration.nix. Даже сразу становится видно, что именно может делать та или иная часть системы. Но едва только захочется странного, как немедленно вылезает необходимость программизма на ровном месте. Если вы не умеете программировать, то неизбежно страдаете. NixOS — программируемый дистрибутив для программистов!

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

Просто настройка отталкивается не от пакетов, а от опций. А опции могут зависеть от пакетов, но разумеется не наоборот. Иногда даже есть возможность выбрать, какой именно пакет использовать в контексте выбранной опции. В категории services таких особенно много. И вот уже названия опций вбивать очень даже можно, как-то примерно вот так: https://nixos.org/nixos/options.html#services.tor. Можно увидеть как сами опции (те, которые есть), так и краткие пояснения к ним. А вот списка обратных зависимостей опций от пакетов нет. То есть, из списка пакетов уже не выйдет посмотреть, в каких опциях тот или иной пакет потенциально может быть замешан применён. А было бы полезно.

А ещё в NixOS практикуется такая концепция, как разнесение интерфейса и реализации. Причём многоуровневое. И согласно этой концепции, за одной аккуратной строчкой интерфейса может быть спрятано множество строчек реализации, которые в противном случае пришлось бы выполнять руками. Ну хорошо, пусть и не в таком объёме, но явно заметно больше, чем одна-две строчки интерфейса. Вон та кошмарная лапша на 700+ строк — это не интерфейс, это реализация, её трогать вообще не нужно! (Но приходится, чтобы понять, что там вообще внутри происходит и почему оно работает не так, как задумано.) А списки опций — это и есть интерфейсы, и вот прямо в таком виде их и можно копировать в configuration.nix.

(Наглядные примеры нужны? А то текст и так несколько раздутым получился.)

И ещё немного про документацию. Тот самый список опций отчасти может заменить такую сущность, как файл конфигурации с комментариями от разработчиков внутри. Как минимум листать будет намного удобнее. Вот только чтобы опция в этом списке появилась — мейнтейнер должен её самостоятельно обернуть в код на Nix lang и добавить к ней описание. Каждую! А это значит, что в сколь-нибудь сложных случаях у нас неизбежно появляется секция вроде extraConfig, предназначенная для внесения в себя фрагмента конфига в виде простого текста, который потом будет совмещён с тем конфигом, что сгенерировал Nix. Никакой встроенной документации в этом случае естественно не будет.

Про Wiki и официальный мануал. В NixOS очень много Nix-специфики, и потому неудивительно, что то и другое в основном посвящено вопросу «А на Слак NixOS это работает»? Тому, как справиться с этой Nix-спецификой, в общем. И в каких-нибудь сложных случаях, когда ещё желательно про особенности самой программы узнать поподробнее, Nix-wiki (неофициальная) отсылает читателя куда? Правильно, в Archwiki. Как говорится, без комментариев :3

toyo-chi ()

Когда несколько лет назад пробовал NixOS, жутко не понравилось, что нельзя так просто взять, открыть терминал, склонировать сорец в хомяк и скомпилить его. Сразу сыпятся ошибки типа «bash not found» и так далее. На тот момент решением было - создать свой собственный пакет и в нем собирать. Что-нибудь поменялось?

Diesel4Power ()
Ответ на: комментарий от toyo-chi

Нет, не пакет, а именно опция. Пакетом это уже точно назвать не выйдет, максимум деривацией. Например, в списке опций верхнего уровня есть такие, как filesystems, fonts, i18n, networking, services, sound и users. Опции могут зависеть от пакетов, но сами они всё же не есть пакеты. Просто в NixOS очень явно разнесены действия «установить» [=подсунуть файлы пакета в системный или пользовательский $PATH] и «настроить» [=сделать так, чтобы оно ещё и работало каким-нибудь определённым образом]. В классических дистрибутивах эти два действия либо слеплены в одно, как в Debian, где post-install скрипты часто просто берут и запускают свежеустановленный демон (или даже что-нибудь в /etc меняют), либо второе может быть переложено на пользователя, как в Arch — в расчёте на то, что он прочтёт прекрасную документацию в Wiki и сам поймёт, что и как он хочет с этим пакетом делать.

В итоге в рамках локалхоста эта Nix-специфика получается избыточной, если намеренно не красноглазить. Проще сконфигурировать всё стандартным способом\ носить конфиги с собой через git или другим способом.

И документация в NixOS не то чтобы отсутствует: она просто неполна, специфична и разрознена. Составлять конфиг не то чтобы сложно, даже напротив: систему в простых случаях можно наконфигурировать прямо по одному только списку опций — берём и копируем себе одну за одной в /etc/nixos/configuration.nix. Даже сразу становится видно, что именно может делать та или иная часть системы. Но едва только захочется странного, как немедленно вылезает необходимость программизма на ровном месте. Если вы не умеете программировать, то неизбежно страдаете. NixOS — программируемый дистрибутив для программистов!

Конфигурирование\программирование ? NixOS не освобождает от знания самих конфигов, то есть мне всё равно надо знать конфиг awesomeWM, tor, и другого софта ( за малым исключением).

Как я понимаю опции не могут охватить весь спектр всех конфигов, всё остальное надо самому пилить на nix-lang.

А ещё в NixOS практикуется такая концепция, как разнесение интерфейса и реализации. Причём многоуровневое. И согласно этой концепции, за одной аккуратной строчкой интерфейса может быть спрятано множество строчек реализации, которые в противном случае пришлось бы выполнять руками. Ну хорошо, пусть и не в таком объёме, но явно заметно больше, чем одна-две строчки интерфейса. Вон та кошмарная лапша на 700+ строк — это не интерфейс, это реализация, её трогать вообще не нужно! (Но приходится, чтобы понять, что там вообще внутри происходит и почему оно работает не так, как задумано.) А списки опций — это и есть интерфейсы, и вот прямо в таком виде их и можно копировать в configuration.nix.

Было бы намного практичней если бы было сделано так, что ты конфигурируешь систему как хочешь, через стандартные средства, после чего пишешь какую нибудь nix-abrakadabra и он тебе всю твою систему заварачивает в configuration.nix со всеми опциями и тд.

Ну или хотя бы иметь что-то вроде старого rc.conf на арче, только более продвинутый.

Про Wiki и официальный мануал. В NixOS очень много Nix-специфики, и потому неудивительно, что то и другое в основном посвящено вопросу «А на Слак NixOS это работает»? Тому, как справиться с этой Nix-спецификой, в общем. И в каких-нибудь сложных случаях, когда ещё желательно про особенности самой программы узнать поподробнее, Nix-wiki (неофициальная) отсылает читателя куда? Правильно, в Archwiki. Как говорится, без комментариев :3

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

Конечно может это специфика обычных бинарных дистрибутивов, и их пользователи привыкли всё время вносить мелкие изменения в систему. Как я понял Nix-os это про то, что бы накросноглазить конфиг один раз и забыть.

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

Там наконец исправили проблемы с Эльфами вне пакетного менеджера?

С чего ты взял что это кто-то собирался исправлять? И да где твои патчи? Где заведённый bug?

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

В итоге в рамках локалхоста эта Nix-специфика получается избыточной, если намеренно не красноглазить. Проще сконфигурировать всё стандартным способом\ носить конфиги с собой через git или другим способом.

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

  • Неявная конфигурация системы через установку пакетов так или иначе происходит: есть как настройка через post-install скрипты обычных пакетов, так и через пакеты, весь смысл которых прямо состоит в изменении некоторых настроек;
  • Но происходит она откровенно как попало: пользователь по прежнему может что-то отредактировать руками, а что-то прямо вынужден. Неконсистентно!
  • Так почему бы не сделать так, чтобы она ВСЯ происходила единообразно и через пакетный менеджер?

Ну точнее, в случае NixOS эта сущность, как мы уже выяснили, всё же несколько более всеобъемлюща. Похоже, в классических дистрибутивах пакетный менеджер просто не осознал своей роли в конфигурации системы и делает это полубессознательно. А вот в NixOS наконец осознал!

Вот например, что в Archlinux раздражает сильнее всего? Конечно же, когда в .pacnew/.pacsave прилетают файлы, которые обычно руками в принципе не трогаешь! Редко, но метко. И вот сидеть их потом, разбирать, вникать в их формат и совмещать со своими настройками, пытаясь ничего не сломать случайно. А вот в NixOS такое в принципе исключено, как и *{new/save}-файлы в целом, потому что конфигурацию всегда генерирует Nix при пересборке. Руками в обход configuration.nix её вообще особо не потрогаешь.

И что характерно — нет, не проще носить с собой конфиги всей системы, сконфигурированные классическим путём. Один раз сконфигурировать систему локально действительно проще, а вот унести эти настройки с собой — нет. В них попадёт слишком много всего ненужного и системоспецифичного, выстроены они вокруг логики программ, а не собственной логики пользователя, и их довольно сложно сделать модульными. Вот допустим, захотелось вот что-то подкрутить в /etc. В классических дистрибутивах эту настройку в любом случае следует положить в некий довольно жёстко заданный каталог. И забыть о ней. Нет, правда, попробуй вспомни, где она лежит и зачем, где там системное, а где собственное! В NixOS же такая настройка прекрасно отправляется в тематический модуль, который лежит там и называется так, где и как удобно пользователю, а не системе. Главное, include не забыть сделать из основного файла конфигурации.

И Git тут не особенно поможет, хоть клади в него, хоть не клади. Ну разве что если в лог в таких случаях каждый раз заглядывать. Но на практике применение какого-нибудь etckeeper превращается в сплошное «commiting unsaved changes», или как оно там было. А всё потому, что в одном большом /etc системное и пользовательское вообще никак не отделено друг от друга! В NixOS, соответственно, явным образом разделены и эти две сущности. Апстримное отдельно, пользовательское отдельно, локальная система — результат пересечения того и другого.

Конфигурирование\программирование ? NixOS не освобождает от знания самих конфигов, то есть мне всё равно надо знать конфиг awesomeWM, tor, и другого софта ( за малым исключением).

Как я понимаю опции не могут охватить весь спектр всех конфигов, всё остальное надо самому пилить на nix-lang.

Ага. Чисто технически не могут охватить, хоть и пытаются от них абстрагироваться. Так что тут всё зависит от мейнтейнеров и того, насколько тщательно они напишут тот или иной системный модуль. Нет ведь никакого возможного способа заранее формально описать абсолютно все возможные сочетания абсолютно любых странных случаев. Конечно, порой бывает так, что набор опций для некоего странного случая есть, так как мейнтейнер заботливо написал их реализацию. Вот тогда всё просто прекрасно, фундаментально лучше, чем в классических дистрибутивах: остаётся только взять и включить их. Особенно заметно, когда для него требуется скоординировано изменить что-то в разных частях системы, а не только в рамках какого-то одного пакета. Но вот если не написал…

Вот тогда и начинается неизбежность программирования! Ну или неизбежность страдания. Так что на практике выходит, что NixOS весьма неплохо помогает подходить к каким-то полностью незнакомым вещам. Но вот углубляться в них и изучать способы их применения скорее мешает. Хоть и делает вид, будто бы и с этим помогает тоже. И в итоге не только вынуждает знать ещё и конфиги нижележащей программы, но ещё и вникать в то, как именно их к нему приложить. Что местами бывает совершенно неочевидно.

Было бы намного практичней если бы было сделано так, что ты конфигурируешь систему как хочешь, через стандартные средства, после чего пишешь какую нибудь nix-abrakadabra и он тебе всю твою систему заварачивает в configuration.nix со всеми опциями и тд.

Ну нет, вот так точно не взлетит. Не считая самой первой автоматической настройки, когда NixOS генерирует «рыбу» configuration.nix и вдобавок к этому hardware.nix с аппаратно-специфичными настройками, которые ему удалось обнаружить. А не взлетит потому, что стандартные средства нестандартны! Сгенерировать конфиг по шаблону — это одно. И вот пусть его потом та программа читает, для которой он предназначен. Она это лучше всего умеет делать, в конце концов. Но очевидно, что сделать обратное действие — автоматически распарсить и корректно стокенизировать каждый конфиг для каждой программы, в которых ещё и пользователь что-то там руками напишет, это уже совсем, СОВСЕМ другое. Тогда уж стоило бы двигаться в сторону какой-нибудь специальной библиотеки, через которую программа могла бы сообщать системе, какие у неё есть опции и что из них можно натворить. (Гномеры с dconf, молчать!)

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

Чистая правда, после Arch ждать каждый раз, пока NixOS перетряхнёт все свои чистейшие функции для установки одной-единственной маленькой программки совершенно невыносимо. В итоге проще оказалось задействовать nix run — это такая специальная команда для потыкать какой-нибудь новый софт. Она кладёт пакет в /nix/store (как и положено), и подсовывает его каталог во временный $PATH для текущего шелла. По скорости почти как Pacman, потому как никаких дополнительных NixOS’ных сущностей при этом не пересобирается. И вот если пакет годится, вот тогда его можно включить в список системных и отправить систему на пересборку. Что, впрочем, никак не избавляет от давящего функционального ожидания при изменении любых других системных опций, не связанных с одной только установкой пакетов.

Конечно может это специфика обычных бинарных дистрибутивов, и их пользователи привыкли всё время вносить мелкие изменения в систему. Как я понял Nix-os это про то, что бы накросноглазить конфиг один раз и забыть.

Ага, что-то вроде этого. Как там было про Linux в целом: «…линуксоид после установки неделю бьётся головой об стенку, а потом начинает наслаждаться» :3 Просто в случае с NixOS это длится… ну, несколько дольше недели. Заметно. Особенно если не уметь программировать.

Ну и ещё NixOS про то, чтобы однажды скрафченный конфиг ещё и носить везде с собой без изменений — на десктоп, на сервер, куда угодно. В нём можно сделать так, чтобы в зависимости от разных состояний применялись только специфические для системы части. А общие, соответственно, оставались общими. Ну там, настройки шелла, консольные программы, алиасы, пользователи, PKI…

toyo-chi ()
Ответ на: комментарий от JustAnotherUser

Это не проблема, это особенность! По крайней мере, логика NixOS выглядит именно так. Осложняется это ещё и тем, что половины зависимостей может просто не быть в системном $PATH, даже если они и есть в системе в целом. Так что для прекомпилированных бинарников проще всего применять steam-run, который воссоздаёт FHS-окружение в chroot и запускает бинарник внутри него. Как можно догадаться по названию, основное его назначение — это запуск игр, но ничто не мешает запускать в нём также и что угодно ещё. Звучит странно, но… ничего не поделать!

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

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

anonymous ()

Надеюсь мои многобукав помогут кому нибудь сделать свой выбор.

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

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

ВНЕЗАПНО environment.noXlibs. По крайней мере, так оно задумано. Однако на практике…

https://github.com/NixOS/nixpkgs/blob/release-19.09/nixos/modules/config/no-x-libs.nix

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

toyo-chi ()

В Gentoo ставится пакет plasma-desktop вместо plasma-meta и система будет действительно иметь минимум без дополнительных программ, которые в основном занимаются настройками самой плазмы и их можно доустановить вручную. Учитывая то, что рабочий стол может состоять из Sway или WM в иксах установка достаточно быстрая. Компилировать браузер необязательно, офис тоже, так как есть инициатива с бинарными пакетами. Создать пакет можно самостоятельно. Ни одного падения при обновлении за годы. Void все же поинтереснее как альтернатива Gentoo из-за runit+musl+xbps-src, выбора ветки ядра и наличия консольного менеджера пакетов с xbps-UI. А еще в Gentoo можно свежими держать только избранные программы.

anonymous ()

В NixOS есть возможность даунгрейда (не загрузка «среза» системы до обновления, а именно даунгрейда одного пакета до версии X.Y.Z-1)? Пытался гуглить, но вразумительного ответа так и не нашел.

hopheynananey ()

Однако стоит лишь переопределить дефолт и если это столь необходимо пакетный манагер сам пересоберёт то что нужно пересобрать

Интересно. Допустим, я хочу пересобрать кеды. Это значит, что мне в configeration.nix нужно прописать не просто пакет plasma, но и какие-то опции, с которыми я хочу его собрать?

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

нужно прописать не просто пакет plasma, но и какие-то опции, с которыми я хочу его собрать?

Подозреваю, что нужно писать свой plasma.nix (или как он там называется в git). А в configuration.nix, имхо, давно не пользовался, отсылка к бинарному репозиторию. Могу и ошибаться.

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

Интересно. Допустим, я хочу пересобрать кеды. Это значит, что мне в configeration.nix нужно прописать не просто пакет plasma, но и какие-то опции, с которыми я хочу его собрать?

Да. Вот так это делается: https://nixos.org/nixos/nix-pills/nixpkgs-overriding-packages.html#idm1407373...

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

Решил, от нечего делать, поиграть с NixOS в роли десктопа. С файлом конфигурации разобрался, сделал себе минимум из которого ставиться все что нужно и теперь возник вопрос к тем кто хорошо знает дистрибутив. Мне нужно в аналог /etc/tor/torrc прописать опции

ExcludeNodes {ru}
ExcludeExitNodes {ru},{kz},{by},{cn},{kg},{tj},{uz},{ir}

Что мне для этого написать в configuration.nix? Беглый гуглеж не помог, надежда на тех кто знаком с NixOS хорошо.

anonymous ()