Сделай pull request на GitHub.

Я думал про какой-то другой способ. Это я видел, пользовался. И что-то из них синоним dry-run.

nixos-rebuild dry-run                                                              building the system configuration...

Напиши понятную формулировку, я сделаю PR. :)

Разметка неправильно скопировалась. nixos-rebuild dry-run то же самое nixos-rebuild dry-build судя по выводу. В манах почему-то нет dry-run

Я про опцию «nofail» которая в fstab обычно.

В nixos fstab генерируется.

Серьёзно, что с ним не так?

С ними всё Ок. Это просто ты ретроград и луддит. 😛

Сегодня, кстати, релиз 23.05

Все просто:

Для написания моноширинным текстом поставьте перед началом абзаца 4 пробела.

Это надо добавить в доку по маркдауну

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

nix реально нужен

Сильное заявление.

Они сами об этом кричат на каждом углу

I use nix btw теперь уже вместо I use arch btw?

Вырвано из контекста конечно, но я реально не понял одного в этом всем - ЗАЧЕМ?

перед началом абзаца

Предлагаю так:

Стили текста

*Курсив* и _Курсив_ даёт курсив

**Жирное начертание** и __Жирное начертание__ даёт жирное начертание

~~Зачеркнутый текст~~ даёт зачеркнутый текст

4 или более пробелов в начале строкимоноширинный текст даёт:

моноширинный текст.

Так тоже можно.

В чём профит правки fstab руками? NixOS как раз избавляет от помойки из кучи конфигов, распиханых по разным папкам. Нужных и ненужных. И от приложений, которые когда-то поставил напосмотреть, и которые потом лежат мёртвым грузом, потому что забыл, для чего ставил «а вдруг от них зависит что-то ещё?».

В NixOS всё в одном месте под гитом, всегда можно посмотреть историю, скопировать на другой комп. Все нужные программы, будь то в исходниках или в бинарях, оборачиваются в простые «скрипты» или в шеллы и сохраняются там же. Если для одной программы нужна особенная версия библиотеки, просто прописываешь это в скрипте и оно всегда будет работать. Ну и главное, нет помойки в системе, которая получается в любом случае, как бы не старался держать всё в порядке.

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

спасибо за подсказку. обязательно почитаю про эту опцию.

И они обычно решаются раз и навсегда, потому что всё записано

желательно записано с комментариями

Ну и документация всё ж похуже, чем в арче

А ещё документация от арча неприменима к никсос и наоборот. Разве что подсмотреть, как это было б сделано в мейнстримном дистриубтиве.

А ещё документация от арча неприменима к никсос и наоборот

В общем случае это справедливо для всех дистрибутивов

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

Ты же не в России вроде, почему шапку не юзаешь дома? Я б на шапке сидел.

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

В общем случае - для всех. А в частном они точно так же переносимы с незначительными отличиями и на NixOS, что меня не раз спасало

Как выяснилось есть и большая. В шапке есть даунгрейд, а в клонах нет.

Во, кстати, а в стриме есть, они хранят предыдущие версии пакетов? Дёрни даунгрей какого-нибудь пакета из основных реп, есть?

сложно или иногда вообще никак - это бинарные программы

Тут steam-run неплохо решает, тот же матлаб, при всей своей монструозности, ставится через него как в любом другом линуксе. Но фундаментальная проблема в том, что steam-run работает путем запуска контейнера bubblewrap, и если приложение само использует контейнеры или песочницы - оно может отказаться работать внутри bubblewrap. С nested применением этих контейнеров пока проблемы далеко не полностью решены (но это не проблема NixOS, собственно, а проблема всех этих бабблов).

С незначительными отличиями по сравнению с Guix или GoboLinux?

По поводу документации от NixOS - есть понятие «минимально работающий пример». Авторам документации NixOS почему-то это понятие в край, абсолютно не доступно. Поэтому в ней есть все, кроме минимально работающих примеров. И новичку въехать в это крайне сложно.

https://github.com/maxcom/lorsource/pull/1029

Также ёфицировал всё, что заметил. :)

И наткнулся на баг парсинга списков маркдауна, поэтому добавленный пункт без *.

Я для таких программ стараюсь настроить fhs. Но там те же проблемы, что и в steamrun. Например, не работает sudo.

Спасибо! Принял, на сайт выложу позже.

Я долго сидел на дебиане, на генте, на арче, по этому хорошо представляю их проблемы.

Какие проблемы в упомянутых дистрибутивах?

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

Какие проблемы в упомянутых дистрибутивах?

Общее:

1. Постепенное превращение в помойку, трудность восстановления до чистого состояния с сохранением настроек. Помойка получается в т.ч. из-за нестрогости пакетного менеджера. Можно ставить руками всё что угодно куда угодно, что нередко приводит к конфликтам или даже краху системы. Конечно, можно опакечивать то, что ставишь. Но кто это делает?
2. Нет общего механизма установки индивидуальных зависимостей (venv для питона, пути и LD_LIBRARY_PATH для Си, и пр.).

Дистроспецифичные проблемы нет смысла писать, их у всех достаточно.

Можно ставить руками всё что угодно куда угодно

То есть эта проблема сводится к тому, что пользователя не бьют линейкой по рукам?

Вот вообще не понимаю этот момент. Руками софт устанавливается в /opt, в отдельные директории. Помойку можно организовать только если специально сорить.

Нет общего механизма установки индивидуальных зависимостей

Очень размыто. Это какой-то способ бороться с последствиями make install?

Дистроспецифичные проблемы нет смысла писать, их у всех достаточно.

Специфичные для дистрибутивов проблемы и есть самое интересное.

Ну что могу назвать я:

1. Дебиан. Протухший софт, высокая сложность создания пакетов.
2. Гента. Не слишком много софта, если не подключать оверлеи, а последние являются верным путём к помойке. Очень долгая компиляция софта.
3. Арч. Крайне частые обновления(даже для роллинга это часто), сложно ставить конкретные версии софта, но зато очень приятный пакетный манагер, как для пользователя, так и для мейнтейнера(ну и для самостоятельного пакетирования соответственно).
4. Убунта. Сама по себе является одним большим недостатком, имеет все проблемы дебиана + добавляет своих в виде багов и всяких снапов.

Это из того, с чем я имел дело.

Арч. Крайне частые обновления

Проблема решена в Манжаре - даже на тестинге апдейты прилетают раз в неделю, если нет ничего срочного

Если в вики написано «добавить опции x y z в файл /etc/someshit» - в чём собственно неактуальность этой информации для NixOS? Принципиально что путь к файлу другой? Софт же не начинает магически по-другому работать и принимает точно такие-же конфиги.

добавить опции x y z в файл /etc/someshit

И чтобы это сделать нужно прочитать мануалы по никсос, потому что половина файлов не просто ссылки на файлы, но и на генерируемые из конфига файлы. И там не только файлы конфигов надо менять. Для примера какой-нибудь snapper можно взять. В nixos про него статьи в вики нет, опции есть. Как пользоваться services.snapper.snapshotRootOnBoot? В какой момент создать снапшот - до switch или он сам создаст все снапшоты и сабволюмы? Или restic.

Или rclone, у которого в пакете, как оказалось, нет файла mount.rclone, поэтому не работает монтирование юнитом .mount и через filesystem. Хотя это баг, наверное.

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

Дебиан. Протухший софт, высокая сложность создания пакетов.

«Протухший софт» относится к stable или к testing тоже?

Гента. Не слишком много софта, если не подключать оверлеи, а последние являются верным путём к помойке. Очень долгая компиляция софта.

Разве оверлеи не используют основной пакетный менеджер? Есть какие-то проблемы с удалением софта, поставленного с использованием оверлеев?

1. Протухший, насколько я знаю, как стейбл, так и тестинг. Более-менее свежий sid, но в арче пакеты всё равно новее. А ещё дебиан страдает патчингом софта, забыл упомянуть в недостатках.
2. Оверлеи не лучше PPA но и не хуже, главная проблема то, что оверлей явлется левым источником софта, где может попасться что угодно. Проблема особенно острая из-за не слишком обширных официальных репозиториев генты. AUR в этом плане тоже далёк от идеала, но он хотя существует в количестве одной штуки, а не зоопарка.

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

По всем программным продуктам нужно читать мануалы. По дебиану, по арчу, по генте, по никсосу, по снаперу, по рклону, по ситемде, и так далее. Без этого никак

Как пользоваться services.snapper.snapshotRootOnBoot?

man 5 configuration.nix

В какой момент создать снапшот - до switch или он сам создаст все снапшоты и сабволюмы?

Как настроишь так и будет, как в любом другом дистрибутиве

Или restic.

Снова-ж таки, man 5 configuration.nix

Или rclone, у которого в пакете, как оказалось, нет файла mount.rclone, поэтому не работает монтирование юнитом .mount и через filesystem. Хотя это баг, наверное.

Бывает. Можно начать с https://github.com/NixOS/nixpkgs/issues, либо самостоятельно починить.

Впрочем вот, пользуйся на здоровье. Можешь в nixpkgs отправить, всем доброе дело сделаешь.

{
  nixpkgs.overlays = [
    (self: super: {
       rclone = super.rclone.overrideAttrs (old: {
         postInstall = old.postInstall + ''
          ln -s $out/bin/rclone $out/bin/mount.rclone
          ln -s $out/bin/rclone $out/bin/rclonefs
         '';
       });
    })
  ];
}

Мне уже в телеграмм канале предложили конфиг, работает:

system.fsPackages = [ 
    (pkgs.runCommand "mount-rclone" { } ''
      mkdir -p "$out/bin"
      ln -sfn "${pkgs.rclone}/bin/rclone" "$out/bin/mount.rclone"
    '')
  ];

или так с добавлением пакета в environment.systemPackages

  nixpkgs.overlays = [
    (final: prev: {
      mount-rclone = prev.runCommand "mount-rclone" { } ''
        mkdir -p "$out/bin"
        ln -sfn "${prev.rclone}/bin/rclone" "$out/bin/mount.rclone"
      '';
    })
  ];

По всем программным продуктам нужно читать мануалы.

С NixOS нужно читать на один больше.

man 5 configuration.nix

Там тоже самое что на сайте. Понятнее не становится. Смотреть исходники этой опции надо тогда.

Как настроишь так и будет, как в любом другом дистрибутиве

А вот не как в любом. Snapper при запуске команды создает конфиг и нужные снапшоты. В nixos:

# snapper -v -c test create-config /mnt/root_btrfs/test_snap
Creating config failed (cannot access template config).

А если сначала вбить данные в configuration.nix, будет ругаться, что конфиг уже есть и не создаст снапшоты. Вот и приходится делать ручками эти снапшоты «инициализации».

То есть эта проблема сводится к тому, что пользователя не бьют линейкой по рукам?

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

Это какой-то способ бороться с последствиями make install?

Нет. Это если у тебя одна программа хочет одну версию зависимости, а другая - другую. Qt разных версий, например. Или зависимости питоновской программы.

Специфичные для дистрибутивов проблемы и есть самое интересное.

Мы же обсуждаем отлисия NixOS от остальных дистров. В общем, а не каждого по отдельности.

Snapper

Они ещё и в новом обновлении поменяли опции. Куда теперь писать вот это всё TIMELINE_LIMIT_HOURLY загадка.

Там тоже самое что на сайте. Понятнее не становится. Смотреть исходники этой опции надо тогда.

Как всегда стоит начать с изучения софта и того как он работает (читать маны, да). А смотреть исходники всегда полезно, рано или поздно захочется писать свои модули.

А если сначала вбить данные в configuration.nix, будет ругаться, что конфиг уже есть и не создаст снапшоты. Вот и приходится делать ручками эти снапшоты «инициализации».

Могу посоветовать обратиться в https://github.com/NixOS/nixpkgs/issues и тегнуть авторов модуля. Я пользуюсь только zfs, так что не могу подсказать по btrfs или его инструментам, но то что create-config делает какие-то действия кроме создания конфигов - это конечно знатный идиотизм.

Как всегда, нужно читать маны: https://nixos.org/manual/nixos/stable/release-notes.html#sec-release-23.05-incompatibilities

The attributes used by services.snapper.configs.<name> have changed. Migrate from this:

services.snapper.configs.example = {
  subvolume = "/example";
  extraConfig = ''
    ALLOW_USERS="alice"
  '';
};
to this:

services.snapper.configs.example = {
  SUBVOLUME = "/example";
  ALLOW_USERS = [ "alice" ];
};

Это я прочитал. Внезапно оно работает в таком виде:

services.snapper.configs.example = {
  SUBVOLUME = "/example";
  ALLOW_USERS = [ "alice" ];
  TIMELINE_LIMIT_HOURLY="5";
};

Но этого нет в опциях (ALLOW_USERS есть) https://search.nixos.org/options?channel=23.05&from=0&size=50&sort=relevance&type=packages&query=LIMIT_HOURLY , что возвращает нас к проблеме неполной документации.

Но этого нет в опциях (ALLOW_USERS есть) https://search.nixos.org/options?channel=23.05&from=0&size=50&sort=relevance&type=packages&query=LIMIT_HOURLY , что возвращает нас к проблеме неполной документации.

Name
services.snapper.configs
Description
Subvolume configuration. Any option mentioned in man:snapper-configs(5) is valid here, even if NixOS doesn’t document it.

Что возвращает нас к проблеме нечитания манов.

Что возвращает нас к проблеме нечитания манов.

ALLOW_USERS есть

Тогда не понимаю, почему на это отдельную опцию написали. Убрали б всё.

Проблема решена в Манжаре - даже на тестинге апдейты прилетают раз в неделю, если нет ничего срочного

Только манжаро - сам по себе одна большая проблема: https://manjarno.snorlax.sh/

Хардкодят или опции с дефолтными значениями, или для обратной совместимости. Например, в том же снаппере сделали assertion, который намекает об изменениях: https://github.com/NixOS/nixpkgs/blob/d7f6d76ec36f3548b11c13ba284e05a3f7112151/nixos/modules/services/misc/snapper.nix#L229-L252

Но вообще касательно документации на nix - мне лично гораздо проще зайти в гит и через поиск найти нужный кусок. У языка есть свои особенности, да, но в целом он довольно понятный.