Хочу также добавить, что contributing в nixpkgs по сравнению с тем же в базы пакетов какого-либо дистрибутива — это рай. Никаких ручных раскладываний meta files и директорий, ручных сборок и запакечиваний в архивы. Ты просто присылаешь небольшие текстовые патчи в виде Pull/Merge Request. Это обычный репозиторий с текстовыми файлами, с кодом. А сборка в бинарный кеш происходит на «гидре» через CI.
Могу сказать только что Вы, вероятно, просто не разобрались и Ваш скептицизм не основан на фактах. Я привёл пример из личного опыта, как тот же Steam, который и есть «бинарный установщик» (там *.deb пакет для Ubuntu/SteamOS, если не путаю), совершенно инородный для NixOS, «устанавливается» и успешно работает. По сути всё, что нужно чтобы его запустить, это: nix run nixpkgs.steam -c steam, т.е. для пользователя это совершенно прозрачно. Я лично на данный момент не представляю как это могло бы было быть реализовано лучше. Ваш скептицизм может быть уместен только по отношению к «бинарным установщикам» для которых ещё не написаны Nix-конфиги, т.к. Вы, как неопытный пользователь Nix, на начальных этапах можете не справиться с написанием такого Nix-конфига. Я подчеркну, что речь именно о «бинарных установщиках» коих может быть зоопарк и там везде могут быть использованы разные решения для того чтобы они работали за пределами их ожидаемой среды выполнения. Большинство программ «опакечиваются» под Nix совершенно тривиальным образом, банально подглядывая в уже существующие конфиги для других программ. А для разных ЯП есть уже просто готовые функции/утилиты, которые генерируют Nix-конфиг из конфиг-файла пакета, а список зависимостей в nixpkgs для того или иного ЯП автоматически генерируется из публичной базы пакетов для того или ного ЯП. Т.е. иной раз даже писать Nix-конфигов не приходится, т.к. это автоматизированно.
Могу отметить, что написание того или иного derivation (Nix-конфига для сборки пакета) — это по сути некоторый build script в изолированной sandboxed-среде. Где у вас есть текущая временная директория /build/ и есть $out который указывает в автоматически-сгенерированный путь куда-то в Nix Store. Если Вы знаете набор комманд, необходимых для «установки» некоего «бинарного пакета», то просто переносите их в этот build script и результат всех манипуляций складываете в $out и всё. Можно в таком build script использовать/вызывать/линковать любые другие derivation. Если в процессе сборки там нужны какие-то программы в /usr/bin, то в изолированной среде можно это всё сэмулировать, либо хоть тот же steam-run вызывать внутри build script.
От себя могу только сказать, что я тоже до последнего был уверен что NixOS не работает, что есть какие-то фундаментальные «подводные камни». У меня довольно хитрый сетап системы и я думал, что не смогу его портировать, чтобы вот так просто Nix-конфига было достаточно без ручных манипуляций. Но однажды, когда я сломал EFI для Fedora, которую использовал последние года, я представил, сколько нужно затратить усилий чтобы просто реплицировать свой сетап, руками, решил что почему бы и не попробовать NixOS, раз появился повод. Вот и проверю, как это работает для меня лично, а уж если это работает, то может не нужно будет каждый раз проходить через болевой порог муторного воспроизведения того, что я уже имел ранее, установку всех пакетов, расфасовки конфигов, кастомных программ со спец. правами куда-нибудь в /opt/ и т.д. А через пару дней у меня уже была вся основная машинерия готова к использованию, и даже amdgpu-драйвер работал, который конфигурировался в NixOS тривиально, и который на Fedora я безуспешно пытался «завезти» не один год. И даже Real-Time-патч для ядра предельно тривиально накладывается (см. https://nixos.wiki/wiki/JACK) и всё собирается, а на Fedora и других дистрибутивах если у меня и получалось это успешно провернуть пару раз в жизни, то оставалось только перекреститься и побить в бубен, чтобы это продолжило работать, и не трогать руками, чтобы не сломалось. Потому что воспроизвести предыдущий опыт после всех ручных манипуляций, и вычислить какие изменения были ключевыми, решающими, не представляется возможным, либо съедающим столько времени, сколько я не готов был на это тратить.
А самое главное, что я все это пробовал и инкрементально расширял на одном компьютере, а потом просто парой команд взял и получил полную реплику на другом, где я поломал ранее EFI. Это был практически магический экспириенс видеть как это просто взяло и заработало, после воспоминаний о том, как в процессе работы и обнаружения «недостачи», на воспроизведение состояния системы после переустановки ОС на другом компьютере может уйти неделя. Собственно по этой причине последние года я был крайне ленив до переустановки системы и сидел на старых версиях дистрибутива, отстающих на несколько мажорных релизов. С NixOS просто начать с условного нуля становится тривиальной задачей. Потому что условный нуль — это уже заготовленный слепок того, что необходимо для повседневного использования.
Так или иначе, я оставляю за каждым право вариться в собственном болоте. Я всего-лишь предлагаю решение целому ряду поставленных в статье вопросов. Кроме Nix (ну и Guix, который по сути дериватив Nix) этих решений полноценно никто/ничто не предлагает. Где-то с 2010-ого года мне довелось перепробовать множество разных дистрибутивов, в попытках понять какой подходит для моих задач лучше. И я бы очень хотел, чтобы кто-нибудь мне указал на NixOS ранее (а ему уже 18 годиков, т.е. всё это время у меня была возможность с ним ознакомиться), как вот сейчас я предлагаю его попробовать другим людям, потому что это именно то решение, о котором я только мечтал последние годы. Идея автоматизации воспроизведения своего сетапа, автоматизированная синхронизация его между машинами, икрементальное его расширение, у меня уже сама натуральным образом в голове нарисовалась как решение своих задач ещё до того как я узнал о существовании Nix. Но до знакомства это казалось скорее утопией, решением, которое годы нужно разрабатывать и ещё годы обкатывать, а оказалось что это всё прямо за спиной уже происходило ещё до полного моего переезда на GNU/Linux.
P.S. Я не говорю что NixOS идеален и/или является silver-bullet. Где-то встречаются шероховатости, которые впрочем полируются со временем, эти шероховатости в большинстве своём исправимы. Где-то может нехватать Nix-конфига для вашей любимой программы (может и для какой-нибудь не тривиальной проприетарной с «бинарным установщиком»). Но общее впечатление очень положительное, это просто работает. И те бенефиты, которые даёт NixOS на мой взгляд с лихвой покрывают всякие его минорные недостатки. В любом случае, альтернатив NixOS (Guix я не беру в счёт, т.к. это просто дериватив Nix) просто не существует. Всё, что более-менее похоже по принципу работы — это полумеры.
UPD: Я сам использую Nix & NixOS как в быту, так и для работы. Моё первое знакомство с Nix (в моём слуаче за пределами NixOS, под Fedora) было именно на работе, т.к. Nix исползуется как в рабочих проектах (provisioning зависимостей для проекта), т.к. и в самих производимых продуктах как составная часть. И заразили меня коллеги в моей комманде, которые почти все использовали NixOS, многие из которых при приходе на работу тоже использовали что-то другое, а потом мигрировали на NixOS. Т.е. меня лично окружает целая группа людей, которые также используют NixOS каждый день для самых разных задач.
Я имею в виду что руками класть это никуда не нужно, система сама разбирается куда ей сохранить файл. А в зависимости от настроек системы путь до Nix Store (как правило /nix/store) может отличаться. А Nix Store в свою очередь — это некий black box, мы вручную им напрямую никогда не манипулируем. И никогда вручную пути вроде /nix/store/blablabla не пишем. Это Nix сам производит связывание с этими путями, подстановку и т.д.
Зависит от конкретного «бинарного установщика», они все разные и везде могут быть разные подходы. В целом пишется специальная Nix конфигурация, и для пользователя это в идеальном сценарии прозрачный процесс (запуска такой программы). Можеть быть например взят «бинарный установщик», из него извлечены файлы, наложены патчи при необходимости, файлы расфасованы куда нужно (в Nix Store). При необходимости эмуляции некоей среды (файловой иерархии Ubuntu например) исполняемый файл(ы) может быть обёрнут в скрипт, который предоставляет эмулированную среду (см. упомянутый steam-run). Это всё происходит в процессе сборки derivation, т.е. Nix-конфига. Я не знаю как по-другому ещё объяснить. Можете также поспрашивать тут: #nix:nixos.org.
То, что вы просто кладете скаченный драйвер в нужную папку
Нет, драйвер ни в какую специальную папку не кладётся. Его можно положить в любую папку, главное запустить nix-prefetch-url для этого скачанного драйвера. После этот файл из той папки, где он был, можно и удалить. Если бы файл можно было автоматически откуда-то скачать, то и этого не нужно было бы делать.
Речь о таких программах, как например SES (segger embedded studio).
Я не знаю что это такое и сам никогда не пользовался. Одна из первых ссылок по поиску:
Забыл добавить что в Nix есть механизмы для наложения патчей. Так что какой-нибудь строптивый исходник, который разработчики отказались править, чтобы исправить проблемы за пределами их любимого дистрибутива, можно пропатчить на стадии сборки.
Также можно патчить и бинарники. Таким образом кстати, на сколько мне известно, раньше запускали Steam. Патчив ELF, чтобы подменять пути к слинкованым библиотекам.
Вот к примеру на днях была новость. Что реплицируемость NixOS помогла восстановить какой-то национальный архив, где использовался какой-то древний ветшалый софт для БД. Просто взяли на современной машине древний снапшот nixpkgs и запустили древний софт.
Nix is the real deal: Today it helped the National Archives recover some data from a very old database. They used a recent and up to date machine with Nix, and software from the NixOS 13.10 channel.
NixOS — это революция, которую озонавать начали только сейчас, спустя почти 20 лет. В отличии от всего зоопарка дистрибутивов, которые отличаются в основном названиями пакетных менеджеров и набором нескучных обоев, и прочими малозначительными деталями, NixOS — это на ряду с какой-нибудь Gentoo, совершенно новый подход к вопросу. Но с Gentoo например путать не нужно, Gentoo не решает те же проблемы, которые решает NixOS. Но NixOS вполне может решать то, что решает Gentoo. Можно просто отключить бинарный кеш и пересобирать весь мир из исходников, если угодно. Аналоги USE-флагов тоже есть, многие пакеты всячески конфигурируются, а также вообще все пакеты кастомизируются (например можно версию подменить не переписывая весь конфиг заново).
Не так же, а сильно проще. Ничего руками архивировать не нужно, и копировать исходники, клонировать репозитории руками не нужно. Просто пишется Nix файл в пару десятков строк и всё.
А как оно будет работать с бинарными установщиками (полно же всякой проприетарной фигни, на которую нельзя повлиять)?
Ну вот возьмём из моего личного опыта пример. Есть проприетарный драйвер для DisplayLink-а (это чтобы DisplayPort-ы работали на хабе для лаптопа, в который ничего кроме USB-Type-C от этого хаба не воткнуто), который нельзя просто где-то взять по ссылке, сначала нужно пойти на сайт, прочитать EULA и расписаться под нейкровью из анальной трещины согласиться со всеми непотребствами и обременениями. Таким образом драйвер не может быть распространён (легально) через какие-либо источники свободного ПО, включая nixpkgs. Т.е. сам бинарный драйвер не может быть распространён, но Nix-конфиг может. В NixOS (точнее в nixpkgs, вообще большинство поддержки всяких драйверов и прочее, это не часть ОС непосредственно даже, а репозитория с пакетами, который может быть заменён любым другим парой консольных комманд, словно магия, сам не верил что это всё работает, пока не попробовал) есть поддержка для для этого драйвера (Nix-конфигурация). Но обо всём по-порядку.
Драйвер включается следующим образом (можно добавить и другие, у меня в начале стоит также intel для встроенного дисплея на лаптопе):
N.B. Подобным же образом включается и amdgpu например [1][2] (он не проприетарный, просто для примера).
При попытке пересборки система в первую очередь выругается на то, что у вас в дереве зависимостей затесался несвободный derivation (программа, библиотека, пакет, и т.д.). В NixOS у пакетов (они же derivations в оригинальной терминологии) есть маркировка лицензий. И по-умолчанию допускаются только свободные. При желании в конфиг можно добавить опцию nixpkgs.config.allowUnfree = true; и дать картбланш системе на обмазывание проприетарщиной по самую макушку, никак за это пользователя не возброняя. Но приличный человек желает контролировать количество собственных пороков, для этого есть прицельный механизм (разрешаем отдельный пакет по его имени):
Тут на сцену выходят Nix функции и операторы. Ничего сверхъестественного, но так сделано в данной опции для гибкости. pkg: это аргумент функции (наличие такого(их) аргумента(ов) и определяет разницу между функцией и обычным Nix выражением/expression), в который поступает derivation, хелпер lib.getName получает имя пакета, без версии и всего остального, просто имя. Ну а оператор == очевидно сравнивает результат lib.getName pkg с именем "displaylink" на равенство. Вообще количетсво сущностей в самом языке Nix можно пересчитать на пальцах рук, это простой и минималистичный декларативный/чисто-функциональный язык. Bash для примера несоизмеримо сложнее.
После дачи разрешения на этот проприетарный пакет при попытке пересборки выпадет ошибка, что проприетарный архих не найден в Nix Store (по дефолту Nix Store располагается в /nix/store/, там располагаются все сборки пакетов и их инструкции к сборке, с описанием зависимостей и чек-сумм). И вам будет предложена инструкция в действию. Будет дана ссылка куда пойти почитать EULA и скачать драйвер. После скачивания драйвера нужно его вручную загрузить в Nix Store, допустим драйвер загружен в /home/vasian/Downloads/displaylink.zip:
Я расписал очень подробно. Всё сводится по сути к:
Добавление имени драйвера в список драйверов X11
Добавление разрешение на использование этого проприетарного пакета
Ручной вызов nix-prefetch-url для архива со скачанным драйвером после подписи EULA
Пересборка системы
С пакетами для других дистрибутивов (тоже проприетарных, разумеется)?
Отличный пример — Steam. Вот инструкции: https://nixos.wiki/wiki/Steam. В NixOS по пути /usr/bin/ не лежит ничего кроме env для совместимости с общепринятым вариантом шебанга:
λ ls -lA /usr/bin/
total 0
lrwxrwxrwx 1 root root 66 May 26 21:10 env -> /nix/store/vr96j3cxj75xsczl8pzrgsv1k57hcxyp-coreutils-8.31/bin/env
Сам Steam же зависит от всяких программ, которые ожидает увидеть по этому пути. Для этого есть пакет steam-run, который с помощью каких-то манипуляций с chroot эмулирует файловую иерархию бубнты. Эта утилита может быть использована и для других проприетарных программ, которые уповают на какую-то популярную конвенцию расположения файлов в системе. Так или иначе для пакета steam используется под капотом эта утилита.
В целом для конечного пользователя это просто установка пакета steam. Разве что нужно опять же дать разрешение на использование проприетарной программы. Можно в домашней директории положить файл gaming.nix следующего вида:
Вот фаза make install (в $out лежит заранее зарезервированый путь в Nix Store):
installPhase = ''
make install PREFIX=$out
'';
А вот указание откуда брать исходники, по сути просто pin на коммит в репозитории (это может быть любой репозиторий, любой URL на тарболл какой-нибудь):
Любой такой репозиторий с make install можно легко запакетить под Nix просто взяв похожую программу из nixpkgs и внеся некоторые изменения при необходимости.
Технически вы можете запустить nix-shell -p make -p pkg-config -p glib -p libsndfile -p ...etc и там уже запускать что нужно, в качестве префикса указав локальную директорию. Но зачем, когда можно легко запакетить в Nix, по сути написать Nix конфиг по примеру из ссылки, и получить воспроизводимый результат. Можно даже добавить pin на конкретный коммит в nixpkgs и получите железобетонную воспроизводимость по чек-сумме, с точно таким же деревом зависимостей, со всеми точно такими же версиями.
Надеюсь достаточно исчерпывающе ответил на вопросы.
Если есть какой-то проект, над которым идёт работа, то не обязательно все программы, нужные для его работы, пихать в системный конфиг. Пишется файл shell.nix подобного вида в директории проекта:
Идём в директорию где лежит этот файл и там запускаем просто nix-shell и в открытой сессии шелла будут предоставлены эти зависимости (исполняемые файлы в PATH например).
UPD:
λ python
The program ‘python’ is currently not installed. You can install it by typing:
...
λ nix-shell shell.nix # (shell.nix argument is optional, shell.nix is default one)
[nix-shell:~]$ python --version
Python 2.7.18
Или так, без файла shell.nix:
λ nix-shell -p gcc -p python
[nix-shell:~]$ python --version
Python 2.7.18
[nix-shell:~]$ gcc --version
gcc (GCC) 9.3.0
Copyright (C) 2019 Free Software Foundation, Inc.
This is free software; see the source for copying conditions. There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
UPD2: А можно взять и более старый снапшот пакетной базы, если есть нужда (таким же образом можно взять какой-нибудь unstable или даже master для более свежих версий, можно одновременно одну программу брать из одного снапшота, другую из другого):
λ nix-shell -I nixpkgs=https://github.com/NixOS/nixpkgs/archive/refs/tags/20.03.tar.gz -p gcc -p python
[nix-shell:~]$ python --version
Python 2.7.17
[nix-shell:~]$ gcc --version
gcc (GCC) 9.2.0
Copyright (C) 2019 Free Software Foundation, Inc.
This is free software; see the source for copying conditions. There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
Да ничем. Под GitOS я имел ввиду, когда полное состояние машины представлено деревом комитов, и ты можешь сделать чекаут в любую точку а не просто откатить/накатить. В идеале, конечно, без перезагрузки). А просто хранить конфиги под гитом это известная тема для любого софта.
Я может не совсем понял что имеется в виду, но по сути так и есть. Любая программа или библиотека в NixOS, или не весть ещё что (derivation по сути может быть чем угодно) представляет из себя полное дерево зависимостей. Можно иметь одновременно одну и ту же программу с деревьями ответвляющимися от одной точки. Можно взять любую библиотеку из этого дерева отдельно, и использовать в другой программе. Т.е. ответвиться от определённой точки. И никакой перезагрузки не нужно (если это не что-то корневое вроде ядра, работающего в данный момент, те же systemd-сервисы автоматом переопределятся и перезапустятся пре пересборке при необходимости). Подменяя любую точку в дереве (делая override версии библиотеки например), дальнейшие ветви будут иметь отличную чек-сумму, прямо как в Git-е ведь, нет?
Я так и не понял, будет ли оно работать без кодинга. И насколько глубокое проникновение этого кода в настройки. Каковы параллели с обычным линуксом? Вот есть у меня, допустим, XFCE Panel. Будет она настраиваться так же, как в дебиане, или надо кодить?
И запустить sudo nixos-rebuild switch. Ну там можно ещё по вкусу добавить nixpkgs.config.pulseaudio = true;. Если нужна отдельно XFCE Panel без всего XFCE, то добавить:
Я вот запустил например без всякого добавления в систему так (для запуска программ можно использовать nix-shell или nix run на месте, не обязательно всё пихать в конфиг, когда вам это нужно раз или два, или только для отдельного проекта):
nix run nixpkgs.xfce.xfce4-panel -c xfce4-panel
По умолчанию она конфиги хранить будет там,… ну где она по умолчанию их хранит. Надо полагать где-то в домашней директории. Если нужна реплицируемость, то можно использовать Home Manager:
Или сделать wrapper, используя аргумент, например vim какой-нибудь взять для примера:
{ pkgs, ... }:
let
vimrc = pkgs.writeTextFile ".vimrc" ''
set number
'';
myVim = pkgs.writeScriptBin "vim" ''
#! ${pkgs.dash}/bin/dash
exec ${pkgs.vim}/bin/vim -u ${vimrc} "$@"
'';
in
{
# ...
configuration.environment.systemPackages = [
myVim
];
}
В простых случаях это больше похоже на редактирование JSON или YAML файла. Nix — язык декларативный, без вызова функций это обычный конфигурационный файл.
Официальный клиент Element (бывший Riot) для относительно децентрализованной сети Matrix не поддерживает пиринговые коммуникации в офлайн-режиме и формирование mesh-сети.
Вообще это строго говоря не совсем так. Можно сказать что на данный момент стабильного решения нет. Но разработки P2P велись и ведутся, в прошлом году было много демок с P2P.
Теоретически вокруг построения этих конфигов можно построить графический интерфейс. Но мне неизвестны реализации. Мне, как разработчику, нравится работать именно с кодом, и использовать преимущества этого подхода, software-defined environment.
Чем она отличается от Guix
Guix — это по сути тоже самое, только с более бедной базой пакетов и меньшей пользовательской аудиторией. Её создатели решили, что новый язык Nix это «умножение сущностей», и решили что нужно взять уже существующую реализацию Lisp-а (Guile Scheme) и использовать его в качестве языка конфигов. И умножили сущности в виде нового дистрибутива, несовместимого напрямую с NixOS. Guix построен поверх библиотеки Nix, т.е. вполне можно сказать что это такой обратно-несовместимый NixOS, только с Lisp-ом вместо Nix-а.
Тут главное не путаться с терминологии, т.к. Nix означает разные вещи.
Nix — пакетный менеджер (может быть использован за пределами NixOS, под практически любым GNU/Linux дистрибутивом, а также под MacOS или как правильно называется ОС от Apple)
Nix — язык программирования, используемый одноимённым пакетным менеджером
nix — исполняемый файл как пакетного менеджера, который также может быть использован для исполнения выражений ЯП Nix (e.g. nix eval '(1 + 1)')
NixOS — это ОС построенная поверх пакетного менеджера Nix
С учетом дешевизны дискового пространства странно, что никто не сделал GitOS.
Откройте наконец для себя NixOS! Я понимаю что писать конфиги системы на языке программирования Nix — это не для рядового пользователя пожалуй (хотя если не прибегать к изощрённостям, и обоычный пользователь освоить в состоянии, добавить пакет в список, или включить сервис в системе путём добавления флага из документации). Но автор писал так убедительно, что это именно его проблема, а не абстрактного юзера. Что автор в самом деле не занет о существовании NixOS. Бросил в середине, т.к. когнитивный диссонанс не давал покоя. Буквально после каждого предложения «вот это сделать нельзя», «на данный момент нет решения» в голове звучит «как же нет, если есть NixOS?» Если не у постороннего пользователя, то у автора точно жизнь станет слаще, если он для себя откроет NixOS. И сотни поднятых вопросов из статьи отпадут сами собой. И диффы конфигов будут, и синхронизация, и воспроизводимость, сколько угодно разных версий любых зависимостей, и даже преимуществ разделяемых библиотек не потеряете для приложений, которые пользуются одной и той же версией, и чего у вас только не будет. Переезд на новую версию системы уложится скорее всего в пару команд. А самое главное — любые изменения инкрементальны, вам никогда не нужно начинать с чистого листа, вы дополняете то, что уже имеете.
И да, БД можно стартовать успешно из любой локальной для проекта директории, практикую ежедневно, по несколько запущенных БД. Выглядит примерно так в ps:
Напомню про акцию программиста, который написал скрипт для Raspberry PI и круглые сутки напролёт копировал какую-то песню в /dev/null, чем генерировал миллиардные убытки «недополученной прибыли» по логике безмозглых копирастов, которые путают понятие частной собственности и обыкновенного нахлебничества лейблов на артистах, заставляя платить деньги за загрузку на устройства определённых больших простых чисел, просто потому что у них где-то есть юридический росчерк, что это большое простое число принадлежит именно им. И даже если автор («авторское право») большого простого числа к ним отношения не имеет, и даже давно мёртв, то они всё-равно овнят это число («имущественное авторское право»), и все обязаны платить налог за пользование этим числом, его запись на цифровые носители информации (да даже и на бумагу, если кто-то станет распечатывать такое закодированное тем или иным образом число).
Это вопрос скорее к аудио-интерфейсу, а не к аудиоредакторам и аудиопроигрывателям. Например JACK. Можно конфигурировать ALSA для подобных манипуляций. Возможно также PulseAudio, но конкретно на распределение на 2 девайса я не пробовал с последним, но по идее API это повзоляет сделать без перезапуска аудиосервера. В любом случае нужно иметь в виду что clock rate (или как это правильно называется? цифровая тиковая синхронизация устройств) у разных девайсов будет разный, там могут быть свои проблемы, XRUN-ы например на коротких задержках.
Хочу также добавить, что contributing в nixpkgs по сравнению с тем же в базы пакетов какого-либо дистрибутива — это рай. Никаких ручных раскладываний meta files и директорий, ручных сборок и запакечиваний в архивы. Ты просто присылаешь небольшие текстовые патчи в виде Pull/Merge Request. Это обычный репозиторий с текстовыми файлами, с кодом. А сборка в бинарный кеш происходит на «гидре» через CI.
Могу сказать только что Вы, вероятно, просто не разобрались и Ваш скептицизм не основан на фактах. Я привёл пример из личного опыта, как тот же Steam, который и есть «бинарный установщик» (там *.deb пакет для Ubuntu/SteamOS, если не путаю), совершенно инородный для NixOS, «устанавливается» и успешно работает. По сути всё, что нужно чтобы его запустить, это:
nix run nixpkgs.steam -c steam, т.е. для пользователя это совершенно прозрачно. Я лично на данный момент не представляю как это могло бы было быть реализовано лучше. Ваш скептицизм может быть уместен только по отношению к «бинарным установщикам» для которых ещё не написаны Nix-конфиги, т.к. Вы, как неопытный пользователь Nix, на начальных этапах можете не справиться с написанием такого Nix-конфига. Я подчеркну, что речь именно о «бинарных установщиках» коих может быть зоопарк и там везде могут быть использованы разные решения для того чтобы они работали за пределами их ожидаемой среды выполнения. Большинство программ «опакечиваются» под Nix совершенно тривиальным образом, банально подглядывая в уже существующие конфиги для других программ. А для разных ЯП есть уже просто готовые функции/утилиты, которые генерируют Nix-конфиг из конфиг-файла пакета, а список зависимостей в nixpkgs для того или иного ЯП автоматически генерируется из публичной базы пакетов для того или ного ЯП. Т.е. иной раз даже писать Nix-конфигов не приходится, т.к. это автоматизированно.Могу отметить, что написание того или иного derivation (Nix-конфига для сборки пакета) — это по сути некоторый build script в изолированной sandboxed-среде. Где у вас есть текущая временная директория
/build/и есть$outкоторый указывает в автоматически-сгенерированный путь куда-то в Nix Store. Если Вы знаете набор комманд, необходимых для «установки» некоего «бинарного пакета», то просто переносите их в этот build script и результат всех манипуляций складываете в$outи всё. Можно в таком build script использовать/вызывать/линковать любые другие derivation. Если в процессе сборки там нужны какие-то программы в/usr/bin, то в изолированной среде можно это всё сэмулировать, либо хоть тот жеsteam-runвызывать внутри build script.От себя могу только сказать, что я тоже до последнего был уверен что NixOS не работает, что есть какие-то фундаментальные «подводные камни». У меня довольно хитрый сетап системы и я думал, что не смогу его портировать, чтобы вот так просто Nix-конфига было достаточно без ручных манипуляций. Но однажды, когда я сломал EFI для Fedora, которую использовал последние года, я представил, сколько нужно затратить усилий чтобы просто реплицировать свой сетап, руками, решил что почему бы и не попробовать NixOS, раз появился повод. Вот и проверю, как это работает для меня лично, а уж если это работает, то может не нужно будет каждый раз проходить через болевой порог муторного воспроизведения того, что я уже имел ранее, установку всех пакетов, расфасовки конфигов, кастомных программ со спец. правами куда-нибудь в
/opt/и т.д. А через пару дней у меня уже была вся основная машинерия готова к использованию, и даже amdgpu-драйвер работал, который конфигурировался в NixOS тривиально, и который на Fedora я безуспешно пытался «завезти» не один год. И даже Real-Time-патч для ядра предельно тривиально накладывается (см. https://nixos.wiki/wiki/JACK) и всё собирается, а на Fedora и других дистрибутивах если у меня и получалось это успешно провернуть пару раз в жизни, то оставалось только перекреститься и побить в бубен, чтобы это продолжило работать, и не трогать руками, чтобы не сломалось. Потому что воспроизвести предыдущий опыт после всех ручных манипуляций, и вычислить какие изменения были ключевыми, решающими, не представляется возможным, либо съедающим столько времени, сколько я не готов был на это тратить.А самое главное, что я все это пробовал и инкрементально расширял на одном компьютере, а потом просто парой команд взял и получил полную реплику на другом, где я поломал ранее EFI. Это был практически магический экспириенс видеть как это просто взяло и заработало, после воспоминаний о том, как в процессе работы и обнаружения «недостачи», на воспроизведение состояния системы после переустановки ОС на другом компьютере может уйти неделя. Собственно по этой причине последние года я был крайне ленив до переустановки системы и сидел на старых версиях дистрибутива, отстающих на несколько мажорных релизов. С NixOS просто начать с условного нуля становится тривиальной задачей. Потому что условный нуль — это уже заготовленный слепок того, что необходимо для повседневного использования.
Так или иначе, я оставляю за каждым право вариться в собственном болоте. Я всего-лишь предлагаю решение целому ряду поставленных в статье вопросов. Кроме Nix (ну и Guix, который по сути дериватив Nix) этих решений полноценно никто/ничто не предлагает. Где-то с 2010-ого года мне довелось перепробовать множество разных дистрибутивов, в попытках понять какой подходит для моих задач лучше. И я бы очень хотел, чтобы кто-нибудь мне указал на NixOS ранее (а ему уже 18 годиков, т.е. всё это время у меня была возможность с ним ознакомиться), как вот сейчас я предлагаю его попробовать другим людям, потому что это именно то решение, о котором я только мечтал последние годы. Идея автоматизации воспроизведения своего сетапа, автоматизированная синхронизация его между машинами, икрементальное его расширение, у меня уже сама натуральным образом в голове нарисовалась как решение своих задач ещё до того как я узнал о существовании Nix. Но до знакомства это казалось скорее утопией, решением, которое годы нужно разрабатывать и ещё годы обкатывать, а оказалось что это всё прямо за спиной уже происходило ещё до полного моего переезда на GNU/Linux.
P.S. Я не говорю что NixOS идеален и/или является silver-bullet. Где-то встречаются шероховатости, которые впрочем полируются со временем, эти шероховатости в большинстве своём исправимы. Где-то может нехватать Nix-конфига для вашей любимой программы (может и для какой-нибудь не тривиальной проприетарной с «бинарным установщиком»). Но общее впечатление очень положительное, это просто работает. И те бенефиты, которые даёт NixOS на мой взгляд с лихвой покрывают всякие его минорные недостатки. В любом случае, альтернатив NixOS (Guix я не беру в счёт, т.к. это просто дериватив Nix) просто не существует. Всё, что более-менее похоже по принципу работы — это полумеры.
UPD: Я сам использую Nix & NixOS как в быту, так и для работы. Моё первое знакомство с Nix (в моём слуаче за пределами NixOS, под Fedora) было именно на работе, т.к. Nix исползуется как в рабочих проектах (provisioning зависимостей для проекта), т.к. и в самих производимых продуктах как составная часть. И заразили меня коллеги в моей комманде, которые почти все использовали NixOS, многие из которых при приходе на работу тоже использовали что-то другое, а потом мигрировали на NixOS. Т.е. меня лично окружает целая группа людей, которые также используют NixOS каждый день для самых разных задач.
Я имею в виду что руками класть это никуда не нужно, система сама разбирается куда ей сохранить файл. А в зависимости от настроек системы путь до Nix Store (как правило
/nix/store) может отличаться. А Nix Store в свою очередь — это некий black box, мы вручную им напрямую никогда не манипулируем. И никогда вручную пути вроде/nix/store/blablablaне пишем. Это Nix сам производит связывание с этими путями, подстановку и т.д.Зависит от конкретного «бинарного установщика», они все разные и везде могут быть разные подходы. В целом пишется специальная Nix конфигурация, и для пользователя это в идеальном сценарии прозрачный процесс (запуска такой программы). Можеть быть например взят «бинарный установщик», из него извлечены файлы, наложены патчи при необходимости, файлы расфасованы куда нужно (в Nix Store). При необходимости эмуляции некоей среды (файловой иерархии Ubuntu например) исполняемый файл(ы) может быть обёрнут в скрипт, который предоставляет эмулированную среду (см. упомянутый
steam-run). Это всё происходит в процессе сборки derivation, т.е. Nix-конфига. Я не знаю как по-другому ещё объяснить. Можете также поспрашивать тут: #nix:nixos.org.Нет, драйвер ни в какую специальную папку не кладётся. Его можно положить в любую папку, главное запустить
nix-prefetch-urlдля этого скачанного драйвера. После этот файл из той папки, где он был, можно и удалить. Если бы файл можно было автоматически откуда-то скачать, то и этого не нужно было бы делать.Я не знаю что это такое и сам никогда не пользовался. Одна из первых ссылок по поиску:
https://forum.segger.com/index.php/Thread/7359-SOLVED-Headless-Install-Nixos-installation/
Забыл добавить что в Nix есть механизмы для наложения патчей. Так что какой-нибудь строптивый исходник, который разработчики отказались править, чтобы исправить проблемы за пределами их любимого дистрибутива, можно пропатчить на стадии сборки.
Пример: https://github.com/NixOS/nixpkgs/blob/f9b26b91a44df64e8e6c03ed2236c7f7b6a56d35/pkgs/applications/audio/audacity/default.nix#L74-L87
Также можно патчить и бинарники. Таким образом кстати, на сколько мне известно, раньше запускали Steam. Патчив ELF, чтобы подменять пути к слинкованым библиотекам.
Вот к примеру на днях была новость. Что реплицируемость NixOS помогла восстановить какой-то национальный архив, где использовался какой-то древний ветшалый софт для БД. Просто взяли на современной машине древний снапшот nixpkgs и запустили древний софт.
Источник: https://mobile.twitter.com/DeterminateSys/status/1385303500318511112
Не придётся, NixOS как-никак 18 годиков уже, совершеннолетие, подобные вещи за года уже обкатали. См. https://habr.com/ru/company/ruvds/blog/556124/?reply_to=23081052#comment_23086566
NixOS — это революция, которую озонавать начали только сейчас, спустя почти 20 лет. В отличии от всего зоопарка дистрибутивов, которые отличаются в основном названиями пакетных менеджеров и набором нескучных обоев, и прочими малозначительными деталями, NixOS — это на ряду с какой-нибудь Gentoo, совершенно новый подход к вопросу. Но с Gentoo например путать не нужно, Gentoo не решает те же проблемы, которые решает NixOS. Но NixOS вполне может решать то, что решает Gentoo. Можно просто отключить бинарный кеш и пересобирать весь мир из исходников, если угодно. Аналоги USE-флагов тоже есть, многие пакеты всячески конфигурируются, а также вообще все пакеты кастомизируются (например можно версию подменить не переписывая весь конфиг заново).
Будет, и ряд проприетарных программ уже успешно поддерживается. Тот же Steam в пример. См. подробнее:
https://habr.com/ru/company/ruvds/blog/556124/?reply_to=23081052#comment_23086566
См. комментарий:
https://habr.com/ru/company/ruvds/blog/556124/?reply_to=23081052#comment_23086566
Интеграция происходит очень просто. Ручной работы по минимуму.
Не так же, а сильно проще. Ничего руками архивировать не нужно, и копировать исходники, клонировать репозитории руками не нужно. Просто пишется Nix файл в пару десятков строк и всё.
В этом комментарии я описал как это происходит:
https://habr.com/ru/company/ruvds/blog/556124/?reply_to=23081052#comment_23086566
Ну вот возьмём из моего личного опыта пример. Есть проприетарный драйвер для DisplayLink-а (это чтобы DisplayPort-ы работали на хабе для лаптопа, в который ничего кроме USB-Type-C от этого хаба не воткнуто), который нельзя просто где-то взять по ссылке, сначала нужно пойти на сайт, прочитать EULA и
расписаться под нейкровью из анальной трещинысогласиться со всеми непотребствами и обременениями. Таким образом драйвер не может быть распространён (легально) через какие-либо источники свободного ПО, включая nixpkgs. Т.е. сам бинарный драйвер не может быть распространён, но Nix-конфиг может. В NixOS (точнее в nixpkgs, вообще большинство поддержки всяких драйверов и прочее, это не часть ОС непосредственно даже, а репозитория с пакетами, который может быть заменён любым другим парой консольных комманд, словно магия, сам не верил что это всё работает, пока не попробовал) есть поддержка для для этого драйвера (Nix-конфигурация). Но обо всём по-порядку.Драйвер включается следующим образом (можно добавить и другие, у меня в начале стоит также
intelдля встроенного дисплея на лаптопе):N.B. Подобным же образом включается и amdgpu например [1][2] (он не проприетарный, просто для примера).
При попытке пересборки система в первую очередь выругается на то, что у вас в дереве зависимостей затесался несвободный derivation (программа, библиотека, пакет, и т.д.). В NixOS у пакетов (они же derivations в оригинальной терминологии) есть маркировка лицензий. И по-умолчанию допускаются только свободные. При желании в конфиг можно добавить опцию
nixpkgs.config.allowUnfree = true;и дать картбланш системе на обмазывание проприетарщиной по самую макушку, никак за это пользователя не возброняя. Но приличный человек желает контролировать количество собственных пороков, для этого есть прицельный механизм (разрешаем отдельный пакет по его имени):Тут на сцену выходят Nix функции и операторы. Ничего сверхъестественного, но так сделано в данной опции для гибкости.
pkg:это аргумент функции (наличие такого(их) аргумента(ов) и определяет разницу между функцией и обычным Nix выражением/expression), в который поступает derivation, хелперlib.getNameполучает имя пакета, без версии и всего остального, просто имя. Ну а оператор==очевидно сравнивает результатlib.getName pkgс именем"displaylink"на равенство. Вообще количетсво сущностей в самом языке Nix можно пересчитать на пальцах рук, это простой и минималистичный декларативный/чисто-функциональный язык. Bash для примера несоизмеримо сложнее.После дачи разрешения на этот проприетарный пакет при попытке пересборки выпадет ошибка, что проприетарный архих не найден в Nix Store (по дефолту Nix Store располагается в
/nix/store/, там располагаются все сборки пакетов и их инструкции к сборке, с описанием зависимостей и чек-сумм). И вам будет предложена инструкция в действию. Будет дана ссылка куда пойти почитать EULA и скачать драйвер. После скачивания драйвера нужно его вручную загрузить в Nix Store, допустим драйвер загружен в/home/vasian/Downloads/displaylink.zip:После этого pre-fetch-а архив попадёт в Nix Store и у него будет чек-сумма, эта чек-сумма записана в конфигурации к драйверу (https://github.com/NixOS/nixpkgs/blob/f9b26b91a44df64e8e6c03ed2236c7f7b6a56d35/pkgs/os-specific/linux/displaylink/default.nix#L27), по этой чек-сумме Nix и найдёт требуемый архив с драйвером при сборке. Пробуем пересборку и всё собирается, готово.
Я расписал очень подробно. Всё сводится по сути к:
nix-prefetch-urlдля архива со скачанным драйвером после подписи EULAОтличный пример — Steam. Вот инструкции: https://nixos.wiki/wiki/Steam. В NixOS по пути
/usr/bin/не лежит ничего кромеenvдля совместимости с общепринятым вариантом шебанга:Сам Steam же зависит от всяких программ, которые ожидает увидеть по этому пути. Для этого есть пакет
steam-run, который с помощью каких-то манипуляций сchrootэмулирует файловую иерархию бубнты. Эта утилита может быть использована и для других проприетарных программ, которые уповают на какую-то популярную конвенцию расположения файлов в системе. Так или иначе для пакетаsteamиспользуется под капотом эта утилита.В целом для конечного пользователя это просто установка пакета
steam. Разве что нужно опять же дать разрешение на использование проприетарной программы. Можно в домашней директории положить файлgaming.nixследующего вида:И запускать следующим образом:
Не храня это в конфиге системы, как и не храня глобальных разрешений на установку проприетарных пакетов.
Ни разу не сталкивался с необходимостью использования AppImage под NixOS. Не могу ничего рассказать из личного опыта.
Под капотом Nix многие пакеты именно так и реализованы. Просто оно происходит в изолированном sandbox-е, и попадает в Nix Store, а не куда попало.
Для примера взял совершенно рандомную команду из nixpkgs грепнув
make install:https://github.com/NixOS/nixpkgs/blob/f9b26b91a44df64e8e6c03ed2236c7f7b6a56d35/pkgs/applications/audio/lv2bm/default.nix
Там всё в целом интуитивно понятно, вот описаны зависимости:
Вот фаза
make install(в$outлежит заранее зарезервированый путь в Nix Store):А вот указание откуда брать исходники, по сути просто pin на коммит в репозитории (это может быть любой репозиторий, любой URL на тарболл какой-нибудь):
Любой такой репозиторий с
make installможно легко запакетить под Nix просто взяв похожую программу из nixpkgs и внеся некоторые изменения при необходимости.Технически вы можете запустить
nix-shell -p make -p pkg-config -p glib -p libsndfile -p ...etcи там уже запускать что нужно, в качестве префикса указав локальную директорию. Но зачем, когда можно легко запакетить в Nix, по сути написать Nix конфиг по примеру из ссылки, и получить воспроизводимый результат. Можно даже добавить pin на конкретный коммит в nixpkgs и получите железобетонную воспроизводимость по чек-сумме, с точно таким же деревом зависимостей, со всеми точно такими же версиями.Надеюсь достаточно исчерпывающе ответил на вопросы.
Если есть какой-то проект, над которым идёт работа, то не обязательно все программы, нужные для его работы, пихать в системный конфиг. Пишется файл
shell.nixподобного вида в директории проекта:Идём в директорию где лежит этот файл и там запускаем просто
nix-shellи в открытой сессии шелла будут предоставлены эти зависимости (исполняемые файлы вPATHнапример).UPD:
Или так, без файла
shell.nix:UPD2: А можно взять и более старый снапшот пакетной базы, если есть нужда (таким же образом можно взять какой-нибудь
unstableили дажеmasterдля более свежих версий, можно одновременно одну программу брать из одного снапшота, другую из другого):Если я не ошибаюсь, то этот Silverblue по сути переизобретённый NixOS. В основе лежат те же идеи.
Я может не совсем понял что имеется в виду, но по сути так и есть. Любая программа или библиотека в NixOS, или не весть ещё что (derivation по сути может быть чем угодно) представляет из себя полное дерево зависимостей. Можно иметь одновременно одну и ту же программу с деревьями ответвляющимися от одной точки. Можно взять любую библиотеку из этого дерева отдельно, и использовать в другой программе. Т.е. ответвиться от определённой точки. И никакой перезагрузки не нужно (если это не что-то корневое вроде ядра, работающего в данный момент, те же systemd-сервисы автоматом переопределятся и перезапустятся пре пересборке при необходимости). Подменяя любую точку в дереве (делая override версии библиотеки например), дальнейшие ветви будут иметь отличную чек-сумму, прямо как в Git-е ведь, нет?
https://nixos.wiki/wiki/Xfce
Согласно инструкции вот этот кусочек нужно добавить в
/etc/nixos/configuration.nix:И запустить
sudo nixos-rebuild switch. Ну там можно ещё по вкусу добавитьnixpkgs.config.pulseaudio = true;. Если нужна отдельно XFCE Panel без всего XFCE, то добавить:Я вот запустил например без всякого добавления в систему так (для запуска программ можно использовать
nix-shellилиnix runна месте, не обязательно всё пихать в конфиг, когда вам это нужно раз или два, или только для отдельного проекта):По умолчанию она конфиги хранить будет там,… ну где она по умолчанию их хранит. Надо полагать где-то в домашней директории. Если нужна реплицируемость, то можно использовать Home Manager:
Или сделать wrapper, используя аргумент, например vim какой-нибудь взять для примера:
В простых случаях это больше похоже на редактирование JSON или YAML файла. Nix — язык декларативный, без вызова функций это обычный конфигурационный файл.
Вообще это строго говоря не совсем так. Можно сказать что на данный момент стабильного решения нет. Но разработки P2P велись и ведутся, в прошлом году было много демок с P2P.
https://matrix.org/blog/2020/06/02/introducing-p-2-p-matrix
Вот даже старый прототип, который можно опробовать самому: https://p2p.riot.im
Про меш-сети там тоже шла речь, я всех деталей не помню.
Помимо прочего в экосистеме Nix есть решения на самые разные случаи жизни, вроде nixops, можно docker-контейнеры собирать, управлять внешними зависимостями и многое другое.
Теоретически вокруг построения этих конфигов можно построить графический интерфейс. Но мне неизвестны реализации. Мне, как разработчику, нравится работать именно с кодом, и использовать преимущества этого подхода, software-defined environment.
Guix — это по сути тоже самое, только с более бедной базой пакетов и меньшей пользовательской аудиторией. Её создатели решили, что новый язык Nix это «умножение сущностей», и решили что нужно взять уже существующую реализацию Lisp-а (Guile Scheme) и использовать его в качестве языка конфигов. И умножили сущности в виде нового дистрибутива, несовместимого напрямую с NixOS. Guix построен поверх библиотеки Nix, т.е. вполне можно сказать что это такой обратно-несовместимый NixOS, только с Lisp-ом вместо Nix-а.
Тут главное не путаться с терминологии, т.к. Nix означает разные вещи.
nix— исполняемый файл как пакетного менеджера, который также может быть использован для исполнения выражений ЯП Nix (e.g.nix eval '(1 + 1)')Ну в конце-концов, чем вам NixOS не GitOS? Конфиги как правило хранят под гитом. См. например мой: https://github.com/unclechu/nixos-config/
Откройте наконец для себя NixOS! Я понимаю что писать конфиги системы на языке программирования Nix — это не для рядового пользователя пожалуй (хотя если не прибегать к изощрённостям, и обоычный пользователь освоить в состоянии, добавить пакет в список, или включить сервис в системе путём добавления флага из документации). Но автор писал так убедительно, что это именно его проблема, а не абстрактного юзера. Что автор в самом деле не занет о существовании NixOS. Бросил в середине, т.к. когнитивный диссонанс не давал покоя. Буквально после каждого предложения «вот это сделать нельзя», «на данный момент нет решения» в голове звучит «как же нет, если есть NixOS?» Если не у постороннего пользователя, то у автора точно жизнь станет слаще, если он для себя откроет NixOS. И сотни поднятых вопросов из статьи отпадут сами собой. И диффы конфигов будут, и синхронизация, и воспроизводимость, сколько угодно разных версий любых зависимостей, и даже преимуществ разделяемых библиотек не потеряете для приложений, которые пользуются одной и той же версией, и чего у вас только не будет. Переезд на новую версию системы уложится скорее всего в пару команд. А самое главное — любые изменения инкрементальны, вам никогда не нужно начинать с чистого листа, вы дополняете то, что уже имеете.
И да, БД можно стартовать успешно из любой локальной для проекта директории, практикую ежедневно, по несколько запущенных БД. Выглядит примерно так в
ps:И разные версии одной БД и прочие мелкие радости жизни.
Напомню про акцию программиста, который написал скрипт для Raspberry PI и круглые сутки напролёт копировал какую-то песню в
/dev/null, чем генерировал миллиардные убытки «недополученной прибыли» по логике безмозглых копирастов, которые путают понятие частной собственности и обыкновенного нахлебничества лейблов на артистах, заставляя платить деньги за загрузку на устройства определённых больших простых чисел, просто потому что у них где-то есть юридический росчерк, что это большое простое число принадлежит именно им. И даже если автор («авторское право») большого простого числа к ним отношения не имеет, и даже давно мёртв, то они всё-равно овнят это число («имущественное авторское право»), и все обязаны платить налог за пользование этим числом, его запись на цифровые носители информации (да даже и на бумагу, если кто-то станет распечатывать такое закодированное тем или иным образом число).Это вопрос скорее к аудио-интерфейсу, а не к аудиоредакторам и аудиопроигрывателям. Например JACK. Можно конфигурировать ALSA для подобных манипуляций. Возможно также PulseAudio, но конкретно на распределение на 2 девайса я не пробовал с последним, но по идее API это повзоляет сделать без перезапуска аудиосервера. В любом случае нужно иметь в виду что clock rate (или как это правильно называется? цифровая тиковая синхронизация устройств) у разных девайсов будет разный, там могут быть свои проблемы, XRUN-ы например на коротких задержках.