LINUX.ORG.RU

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

 


7

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. Но оно тоже странное то есть то нет… В общем закономерности я не заметил но у себя наблюдал.

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

★★★★★

Моей предыдущей системой была гента поэтому и свои сравнения я буду проводить непосредственно с ней.

Ээээ, расходимся. Хотелось бы увидеть впечатление о никс не через призму садомазо, а с точки зрения нормального человека…

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

Хотелось бы увидеть впечатление о никс не через призму садомазо, а с точки зрения нормального человека…

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

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

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

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

Ну про нормальных это я перегнул, но хотя бы не маргиналов из маргиналов.

А если серьёзно, есть ли у никсос будущее в энтерпрайзе? Свой амазон с блекджеком ты стал бы на нём строить?

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

Так, а хотите тогда другой тред про NixOS, но не в жанре хвалебной оды, а скорее ругательно-осмыслительный, в комедийном жанре «свитчер с Arch Linux переходит на NixOS и ничего не понимает»? Можно устроить!

toyo-chi ()

Если у меня обновилась какая-нибудь libblabla с версии 2.2.10 на 2.2.11 без изменения заголовочных файлов, то дохренадцать пакетов, которые от неё зависят, всё равно потребуют перекомпиляции?

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

А если серьёзно, есть ли у никсос будущее в энтерпрайзе? Свой амазон с блекджеком ты стал бы на нём строить?

Не ну так если сравнивать NixOS с любым прочим GNU/Linux дистром то результат сравнения будет заранее будет в пользу NixOS. Ну если кроме разве что guix.

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

Если у меня обновилась какая-нибудь libblabla с версии 2.2.10 на 2.2.11 без изменения заголовочных файлов, то дохренадцать пакетов, которые от неё зависят, всё равно потребуют перекомпиляции?

Здесь решена проблема [s]DLL[/s] Dependency hell. Т.е. в системе одновременно могут быть libblabla хоть всех существующих версий. А воотвественно и весь софт который зависит от libblabla каких то там конкретных версий. Про перекомпеляцию дальше надеюсь понятно?

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

Нет, не понятно.

Заголовочные файлы и .so — разные объекты, нужные для разного.

Для сборки приложения нужны заголовочные файлы, но не нужен .so.

Для запуска приложения нужен .so, но не нужны заголовочные файлы.

Ну в общем судя по полному непониманию вопроса, проблема никак не решена. Хочешь запустить прикладуху с другим .so — пересобирай сорцы с нуля. Весело и ненужно.

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

Не ну так если сравнивать

Ну а как ещё. Не десктоп же с кедами и гномом обсуждать. Про маргиналов вроде как уже поговорили.

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

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

Какие могут быть причины?

Ещё недавно нас было сколько там? 1,5%? Пользователи ставят не то что интересно а то что на слуху. А на слуху всякие убунты либо то что посоветует знакомый с линуксом.

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

Даже более того: если обновить runtime-зависимость какого-нибудь пакета, которая вообще никак не влияет и в принципе не может влиять на то, в какие бинарники этот пакет скомпилируется — этот пакет всё равно потребует полной перекомпиляции. Например, если локально обновить youtube-dl, которую мейнтейнеры как-то не вдруг доносят до stable — придётся перекомпилировать mpv. Потому что, видите ли, хэш деривации изменился. И вот так каждый раз!

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

Можно ли там теперь нормально завести Sway

Про это к сожалению ничего не могу тебе сказать ибо у мну plasma.

как долго нужно ждать нового ядра после релиза?

А этим я переболел ещё в районе Slackware 10.0

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

Даже более того: если обновить runtime-зависимость какого-нибудь пакета, которая вообще никак не влияет и в принципе не может влиять на то, в какие бинарники этот пакет скомпилируется — этот пакет всё равно потребует полной перекомпиляции. Например, если локально обновить youtube-dl, которую мейнтейнеры как-то не вдруг доносят до stable — придётся перекомпилировать mpv. Потому что, видите ли, хэш деривации изменился. И вот так каждый раз!

Ясно. By design кривые алгоритмы вычисления хэшей.

Ну вот и ответ на вопрос, почему оно не внедряется массово.

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

В 5.6 WireGuard из коробки, очень надо.

Принципиально при желании можно натягивать любое. Только надо быть готовым к тому что оно будет компилится на твоей машине в то время как дефолтное просто скачается готовое.

init_6 ★★★★★ ()

она не справиться

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

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

Ну вот и ответ на вопрос, почему оно не внедряется массово.

Уважаемый а что изобретен способ не перекомпилировать дохренадцать пакетов зависящих от какой-то libblabla при её обновлении с версии 2.2.10 на 2.2.11?

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

Уважаемый а что изобретен способ не перекомпилировать дохренадцать пакетов зависящих от какой-то libblabla при её обновлении с версии 2.2.10 на 2.2.11?

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

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

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

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

Уважаемый а что изобретен способ не перекомпилировать дохренадцать пакетов зависящих от какой-то libblabla при её обновлении с версии 2.2.10 на 2.2.11?

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

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

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

А я верю да.

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

Но почему-то большая часть здесь сидит на своих убунтах, дебианах, арчах, минтах, манжарах.

Размер сообщества играет большую роль. Я не использую ничего из перечисленного, Винду тоже снёс 8 лет назад.

Пользователь Линукса, если пытливый, всегда находится в поиске.

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

Когда нет знаний, остаётся лишь вера.

А если по не пересобрано под новую версию либы, остаётся лишь надежда. И утверждение „Ни в одном нормальном дистрибутиве не перекомпилируются зависящие пакеты просто так при изменении библиотек. Ни библиотек, ни тулчейна.“ очень сильное. Настолько что… Ну прям вот так на слово хочется верить.

init_6 ★★★★★ ()

Всё хочу попробовать, но непонятно как обстоят дела с пакетами.
Большинство нужных мне приложений имеют инструкции по установке только под Centos/Ubuntu и вряд ли их разработчики парятся про Nixos.
Какой общий алгоритм в таких случаях?

zolden ★★★★★ ()

Лол. У них даже отдельный костыль есть, чтобы не пересобирать мир, когда надо запатчить дыру.

# Replace a single dependency in the requisites tree of drv, propagating
# the change all the way up the tree, without a full rebuild. This can be
# useful, for example, to patch a security hole in libc and still use your
# system safely without rebuilding the world. This should be a short term
# solution, as soon as a rebuild can be done the properly rebuild derivation
# should be used. The old dependency and new dependency MUST have the same-length
# name, and ideally should have close-to-identical directory layout.
Deleted ()
Последнее исправление: Deleted (всего исправлений: 1)
Ответ на: комментарий от Deleted

Вот, отличный вопрос! Ведь в некотором смысле ядро — это тоже такая runtime-зависимость для всей остальной системы. Нет, при смене версии ядра ничего существенного не пересобирается — пакеты с ядром обрабатываются каким-то отдельным хитрым образом. (А точнее говоря, от ядра зависит пакет деривация «моя локальная система», которая, в свою очередь зависит и от всего остального, что в эту систему добавлено. Вот она — пересобирается, а всё остальное нет. Ну или как-то так, тут пусть знатоки подробнее комментируют.) Сменить версию ядра достаточно просто, не трогая всё остальное.

Но изменение версии (да что там версии — даже опций компиляции и всего остального, от чего рассчитывается тот самый хэш деривации) любого обычного пакета действительно вызывает пересборку всего, что от него зависит. Даже если ничего не переопределять локально, и ставить только то, что есть в бинарном кэше — это всё равно будет заметно по объёму обновлений, потому что пересобранные пакеты будут скачиваться каждый раз в огромных количествах. Для каждого обновления (если обновляться где-то раз в неделю или реже) необходимо скачать около десяти гигабайт пакетов! И это всё на stable и довольно обычном десктопном наборе.

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

Большинство нужных мне приложений имеют инструкции по установке только под Centos/Ubuntu и вряд ли их разработчики парятся про Nixos. Какой общий алгоритм в таких случаях?

Проверить опакечено ли это по в nixos? Если да проблем вообще нет. Иначе всегда можно использовать любой готовый бинарник.

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

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

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

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

Модули ядра не включенные в ваниллу но добавленные в систему при обновлении ядра пересобираются.

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

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

Ну это и логично на самом деле. Управление сборкой и управление конфигурацией — два отдельных шага. Так должно быть сделано вообще всё, а не только пакет ядра.

Воспроизводимая сборка бинарников — это один шаг. А воспроизводимая конфигурация машины — это уже другой шаг.

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

Deleted ()