В чём суть дистра?

NixOS a great system for DevOps use.
они делают Hydra для CI и Disnix для CD

В том что можешь одновременно иметь любое количество любых версий любых пакетов и ничего не поломается и это гарантировано математически.

чтобы это сделать нужно все зависимости держать при себе

Автор никса просто проанализировал все существующие пакетные менеджеры, без труда заключил что они все мягко говоря плохие, и написал свой. Вот его диссертация в которой все ясно и подробно объяснено: https://nixos.org/~eelco/pubs/phd-thesis.pdf

Объясни что значит «держать при себе».

Но snapper работает так же с ext4.

Пошёл читать каким таким образом он работает с ext4 и оказалось что только с форком next4, в общем нужное кастомное ведро.

Я выше писал, что выкидывание wvdial - как серпом по яйцам.

Дык, он же умер (последний коммит в 2009) и не компилируется с новыми версиями openssl о чём и указано в release notes.

Нет, для этого нужно их изолировать, «держать при себе», как в каком-нибудь snap — не единственный способ этого добиться.

Пишется патч либо делается форк..

Выкидывать не самое лучшее решение.

wvdial всеж может использоваться для выхода в интернеты)

Видимо, никто не хочет форкать и писать патч. Неподдерживаемые пакеты _нужно_ выкидывать.

т.е. по-вашему если что-то случится с мейнтейнером GLIBC его тоже надо выкинуть?

все зависимости держать при себе

И будет как с докером:

Almost 40% of general images have high priority vulnerabilities. Even if we just look at images created this year or ones with the latest tag, the percentage of vulnerable images hovers between 30-40%. If we include images that have medium vulnerability, this number jumps up to more than 70% for all the time frames.

У вас все с ног на голову перевернулось. Пакеты - это не статичные файлики, если они остаются без апстрима или без поддержки мейнтейнеров дистрибутива, то со временем ломаются и лежат мертвым грузом. Люди, развивающие дистрибутив не могут взять и выделить людей на их поддержку, потому что community дистрибутивы не распоряжаются людскими ресурсами. Какое-то время такие пакеты лежат, пока их кто-нибудь не подберет. Если такого не происходит - их просто убирают из дерева.

В случае с glibc - его довольно быстро подберут или форкнут. В случае с wvdial - ну, видимо, он совсем никому не нужен, раз не подобрали.

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

я, например, версионировал конфиграцию системы с помощью гита

т.е. можно откатиться на нужный тэг и запустить никс-билд

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

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

хотя, из-за самодельного языка в никсе, guile кажется гораздо более интересным

хотя, из-за самодельного языка в никсе, guile кажется гораздо более интересным

ну хз мерзкие портянки

https://git.savannah.gnu.org/cgit/guix.git/tree/gnu/packages/autotools.scm?id...

ну так давай сравним с аналогичным конфигом из никса

ну, плюс к этому, лиспы обычно лучше читаются в редакторе с rainbow parentheses

в никсовых пакетах я такого ужаса не вижу. потому что 1) нет такой дикой вложенности, там как там это решается неймспейсами 2) все кроме декларативного описания - это обычные команды баша, как если бы ты собирал пакет руками, так что чтобы написать пакет не требуется писать программу, как в случае с гуиксом

К примеру есть такой пакет как systemd-swap. Каким образом будет в едином конфиге помечено что я в нём менял?

хотя, из-за самодельного языка в никсе, guile кажется гораздо более интересным

Писать на +1 языке не проблема, проблема когда софт отсутствует в репах

не уверен, что правильно понял вопрос, но вот пример кастомного юнита:

  systemd.services.myservice = {
    description = "My service is responsible for ...";
    after = [ "multi-user.target" ];
    wantedBy = [ "multi-user.target" ];
    path = [ pkgs.bash ];
    environment = {
      MY_SERVICE_HOME = "/my/path/here";
      MY_SERVICE_MAX_CONNS = toString myVar;
    };
    serviceConfig = {
      User = "myuser";
      ExecStart = path;
      Restart = "always";
    };
  };

а для существующух сервисов можно, соответственно, переопределить только отдельные параметры

--------------

касательно количества пакетов в репах — если чего-то нет в официальных репах, то можно поискать конфиг для нужного пакета в неофициальных источниках, вот пример простого: https://github.com/actionless/dotfiles/blob/master/workstation-dell/nixos/pkg...

обычные команды баша

Нафиг такое счастье.

Писать на +1 языке не проблема

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

проблема когда софт отсутствует в репах

А кто должен пакетить, как не юзеры? Вспомним Арч с Ауром

если чего-то нет в официальных репах, то можно поискать конфиг для нужного пакета в неофициальных источниках, вот пример простого: https://github.com/actionless/dotfiles/blob/master/workstation-dell/nixos/pkg...

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

Нафиг такое счастье.

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

Ну конечно всякие шаблонные вещи типа "(c)make; make install" описываются декларативненько одной строчкой на никсланге, а вот какие-нибудь нешаблонные манипуляции с файлами - на баше. Да потому как я уже сказал, это банально удобно. В простынях также можно обращаться к зависимостям (типа ${pkgs.bash}/bin/bash), если нужно.

я знаю, просто не пользуюсь им уже больше года как

это уже почти из разряда bash scripts vs ansible

От баша то требуются в основном шел команды (cp, rm, ...), да циклы. Этой чистый дебилизм выражать сие на непривычном всем язычке. У тебя же в качестве шелла не лисп репл используется, я надеюсь? :D

bash — это худший недоязык программирования. Единственная область его применения — мелкие, некритичные к надёжности скрипты на пару десяток строк кода (просто потому что на таких масштабах недостатки баша не успевают проявиться) и скрипты инициализации системы (проще дебажить если нормальная загрузка не удалась). Да и в последнем случае rc из plan9 предпочтительнее.

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

Господи, какое программирование из-за простого пакетирования? Ну ты чего

Господи, какое программирование из-за простого пакетирования?

А зачем тогда bash? Тут eDSL в самый раз.

Там и есть DSL. Называется Nix. Баш для билд-инструкций и только. Не нравится тебе bash, можешь мысленно заменить sh'ом. Ничего башеспецифичного я в пакетах не видел. Еще раз: билд-инструкция это то что человек набивал бы в терминале, операции над файлами и запуск команд в основном. У большинства людей шел sh совместимый, а не что-то другое.

Что тут обсуждать из пустого в порожню. Посмотри сам пример никсового пакета https://github.com/NixOS/nixpkgs/blob/master/pkgs/development/compilers/pakcs... Очень легко читается и пишется в сравнении с гуиксом

Нужно.

Значит конфиг юнита встраивается в единый конфиг. Понятно.

касательно количества пакетов в репах — если чего-то нет в официальных репах, то можно поискать конфиг для нужного пакета в неофициальных источниках

Несколько лень менять дистрибутив и опакечивать то что уже есть

Ну знаешь, такое себе удовольствие

Что scheme что nix для меня одинаково незнакомы.

Писать программу ради опакечивания очередного софта.

Это нужно в любом дистре. Разве что кроме тех в которых делают make install

А кто должен пакетить, как не юзеры? Вспомним Арч с Ауром

В nix есть некторые пакеты, в guixsd нет. Если нет какой-то автоматической миграции(с добавлением в официальный реп), то у пользователя прибавится проблем.

Посмотри сам пример никсового пакета

Неструктурированная простыня плохочитаемого текста без корректной проверки входных данных и контроля ошибок. Скажем дружно ...

Неструктурированная простыня плохочитаемого текста без корректной проверки входных данных и контроля ошибок. Скажем дружно ...

Как же это напоминает все остальные системы сборки пакетов

Не готов

Кто-нибудь его юзает на десктопе? Искренне пытался сабж с кедами на запасном ноуте. Всюду сырость. Если сделать nixos-rebuild switch с-под кед - всё умирает, т. к. меняются пути в /nix/store. Если сделать nixos-rebuild switch не из-под кед - ломается восстановление сессии, т. к. меняются пути в /nix/store. Из-за этого случаются неочевидные баги, когда перестаёт отображаться статус батареи из-за незапущенного powerdevil и т. д. Или недавно пропали уведомления о прогрессе копирования файлов. И вот как-то так оно всё. На серверах оно уже употребимо и даже очень круто. Прозреваю ему великое будущее. Наконец-то цельное решение, а не эта puppet/ansible/docker/rkt/coreos/четамщасмодно костыльная клоунада. Но для десктопа в 2017 году чё-то пока не готово.

Неструктурированная простыня плохочитаемого текста

(Съешь (ещё (этих (вкусных (обрезков ногтей))) (да (выпей (йаду))))).

без корректной проверки входных данных и контроля ошибок

Поздравляю, гражданин, в лужу пёрднувши.

(Съешь (ещё (этих (вкусных (обрезков ногтей))) (да (выпей (йаду))))).

Между прочим код на лиспоподобных языках вполне можно раскрасить для удобного чтения

А на других нельзя?

Довольно интересный дистр, но так его и не попробовал.

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

Что scheme что nix для меня одинаково незнакомы.

Там и учить нечего. Смотришь как в других пакетах сделано + мануал. Их ревьюверы скажут, что поправить в случае чего.

Это нужно в любом дистре. Разве что кроме тех в которых делают make install

Ну на гуиксе надо писать именно программу. А в никсе все практически также как в других пакетных системах, обычная последовательность установочных шагов. И совсем небольшой процент Nix'а, там где он нужен.

В nix есть некторые пакеты, в guixsd нет. Если нет какой-то автоматической миграции(с добавлением в официальный реп), то у пользователя прибавится проблем.

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

Неструктурированная простыня плохочитаемого текста

Где? В гуиксе? Тут ты прав

без корректной проверки входных данных и контроля ошибок

Nix типизирован и ленив. Чо тебе еще надо? try съешь еще этих мягких булочек catch да выпей чаю. Может тебе еще монадок в чай положить? Тут люди вообще пакеты левой пяткой строчат, для такой задачи что угодно сгодится, лишь бы зависимостями само рулило.

Какой тебе контроль нужен? Сфейлилась у тебя команда в installPhase допустим -> сфейлился пакет. Чем не контроль.

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

Maxx? Серьезно? Нагуглил тут что это такое Дефолт MaXX ну вроде ок ссылки, все запущено на скрине. Firefox только сломан, но он в состав этого макса не входит.

Но я не знаю зачем юзать эту жесть :D

Где? В гуиксе?

В guix приняли правильное решение использовать полноценный язык программирования.

Какой тебе контроль нужен?

Ну, почитай что-нибудь на тему defencive bash programming.

В guix приняли правильное решение использовать полноценный язык программирования.

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

Ну, почитай что-нибудь на тему defencive bash programming.

Everything is local

Переменные и есть локальные, т.к. область видимости ограничена phase'ом.

Everything is a function

Функции там не используются.

Короче это не баш :D Тебя тупо триггернуло на слово. Сразу думаешь, что используется баш во всем его безобразии.

у меня есть дела поважнее.

Экранировать символы, пробрасывать переменные из bash в awk и обратно, может ещё чего.