пользователям source-based дистрибутивов

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

О, привет. Что-то мне подсказывает, что ты не полностью прочитал простыню текста. С каких пор Flatpak умеет управлять конфигурацией (как это делает Nix), делать rw-образы поверх неизменяемых и т. д.? От контейнеров они вообще явно открестились.

P.S. Учебник чешского тактически лежит на полке с 2018 🙃

Прочитал с позиций «NixOS, а на ней Flatpak» и не увидел великих различий.

В Nix(-shell) нет FHS-контейнеров, OCI, Bubblewrap/порталов.

В Flatpak нет дедупликации с системными пакетам (на самом деле как бы есть, но это не то и костыль), OCI, управления конфигурацией. Подозреваю, что система сборки там куда менее изощрённая, чем у Nix. И вообще, зачем тогда городят rpm-ostree, если уже есть Flatpak?

И ни Nix, ни Flatpak не помогают в ситуации «я разработчик, хочу поставить пользователям инсталлятор, чтобы установилось и работало на любом дистрибутиве, не ломалось со временем и само обновлялось».

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

Да читал я твою простыню, это не помогает.

В Nix(-shell) нет FHS-контейнеров

есть FHS-окружения, это оно?

Bubblewrap/порталов

Есть, смотреть на bubblewrap и flatpak соответственно.

В Flatpak нет дедупликации с системными пакетами

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

управления конфигурацией

А как бы оно выглядело? Интерфейс флатпака — install, uninstall, run; я не удивлюсь если там даже параметры командной строки открутят в него не входят во славу воинствующего минимализма, как в андроиде.

чтобы вышесказанное сразу было понятно.

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

Со вводной частью «почему все задница» я практически полностью согласен. Напишу о том где скользкие моменты (под не упомянутым считай что я цитирую и пишу да да да).

Если кратко - то ты явно недооцениваешь возможности Nix, но об этом подробнее в следующем посте.

А для распространения установщиков сторонними разработчиками должен использоваться формат .bundle

Есть nix bundle, можно допилить, практически это как AppImage только собирается путем запаковки куска nix store. В целом на этом можно повторить систему распространения софта из macOS. Есть бандл как скачиваемый файл, его можно прям так запускать, а можно установить (путем импорта в nix store содержимого бандла, например). Собственно ты нечто подобное и предлагаешь.

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

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

Вот это очень важный момент! У нас нет сотней нефти как у MS чтобы гарантировать обратную совместимость между версиями рантаймов, нет сотней нефти чтобы тестировать работу приложений в разных окружениях. Поэтому в идеале надо делать как в Nix - жесткие зависимости. Их нельзя подменять, обновлять независимо от приложения. Тогда возможны хоть какие-то гарантии. При этом снимается необходимость обеспечения обратной совместимости - а это огромная, колоссальная разгрузка разработчиков!

Давай посмотрим, как в Win/Mac приложение ставится - там почти все запаковано в бандл, и никто либы из бандла не подменяет. Даже там!

В нашем случае, как я уже писал выше, можно просто ипользовать nix bundle, при установке которого его содержимое просто импортируется в nix store. Не стоит это место экономить, тем более что внутри nix store дедупликация хардлинками пофайлово делается!

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

Естественно, что делать сборку приложения должно быть рекомендовано на текущей версии рантайма, как и делается по сути везде сейчас и в NixOS в том числе. Ное сли приложение уже собрано и поставляется бинарник - эффективнее запускать его именно в том окружении в котором он собран разработчиком. Иначе мы получаем космический геморрой с которым просто нет ресурсов бороться.

должна рекомендоваться как раз статическая линковка

По сути, Nix вообще всегда делает статическую линковку под соусом динамической, потому что он намертво прибивает бинарники к конкретным версиям библиотек при помощи rpath. При этом реально статическая линковка не очень то становится и нужна. Можно легко собрать приложение с урезанной, облегченной, пропатченной библиотекой, кладя ее как отдельный пакет в nix store (он там ничему мешать не будет), прямо влинковывать в бинарники совсем не обязательно.

есть FHS-окружения, это оно?

1. Почему тогда по умолчанию не используются?

2. Что, даже для базовой системы?

Есть, смотреть на bubblewrap и flatpak соответственно.

Так я не хочу Bubblewrap и Flatpak. Я хочу интеграцию/изоляцию, как у Flatpak, но для пакетов, управляемых через Nix.

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

А я хочу, чтобы в моём дистрибутиве использовался этот самый «кросс-дистрибутивный рантайм» в качестве основного. Остальные пусть сами выбирают.

А как бы оно выглядело? Интерфейс флатпака — install, uninstall, run;

Так мы про систему управления вообще всей системой говорим.

Как прикажешь заращивать пропасть?

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

В Nix(-shell) нет FHS-контейнеров, OCI, Bubblewrap/порталов.

Про OSI не скажу, я не интересуюсь серверной контейнеризацией пока, но все остальное есть. Конечно же есть.

FHS-контейнеры Nix создает на ура. Например, у меня установлен обычный, проприетарный монстр Matlab. Официально он поддерживает Ubuntu, патчить его бинарники, этой монстрины, под не-FHS систему дело провальное. При этом он еще использует системный тулчейн, на лету порождая бинарники и запуская как свои же плагины (по сути). То есть полнейший фарш. Но - все работает, для него создано FHS окружение. Делается это в NixOS тривиально.

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

Bubblewrap - это совершенно отдельная от flatpak штука. Он конечно же есть в NixOS и через него можно запустить в изоляции прямо что угодно, любое приложение прямо из Nix store. Чего нету - так это обвязки над bubblewrap, которая позволит пользователю рулить этой изоляцией. Надо делать.

Порталы - штука так же совершенно не привязанная к flatpak, и порталы в NixOS опять же есть, конечно (как бы флатпак то без них работал). Пробитие изоляции через порталы работает через dbus, тут опять же флатпак не нужен и все уже в NixOS есть. Нету сущности, которая все это соберет воедино и заставит работать именно через порталы.

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

Я собрал такую систему, сейчас стоит параллельно с NixOS.

Я взял последний org.kde.Sdk от флатхаба, долил туда недостающие компоненты и получил базовую систему. Если ее закоммитить в OSTree репозиторий флатпака - то произойдет дедупликация между такой хостовой системой и kde рантаймом флатпака. То есть опа и нет дублирования.

В этом плане хорошо, но - в ходе сборки я столкнулся с фундаментальной проблемой. Флатпак не предоставляет готовых пакетов, по сути это LFS чистый. Чтобы собирать все эти контейнеры, все равно должен быть какой-то ПМ.

А из ПМ явный лидер - Nix. Но он устроен так, что по сути заменяет собой OSTree. Вот и непонятно, что с этим делать дальше.

Во-первых, полной воспроизводимости достичь невозможно: нужно чтобы и ядро, и драйверы, и Glibc, и прочие системные пакеты были той же версии (и чтобы железо одинаковое было). Ведь выпускают же обновления для пакетов из «рантаймов» Flatpak. Да и даже старые добрые «тарболы» зачастую без проблем работают.

Во-вторых, как быть с обновлениями безопасности?

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

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

Со статической линковкой должно быстрее запускаться. И бинарник должен быть более оптимизирован за счёт LTO.

FHS-контейнеры Nix создает на ура.

См. комментарий. Плюс нужна возможность делать rw-оверлей поверх неизменяемого образа, где можно заниматься всевозможными непотребствами вроде ручного редактирования конфигов и складирования бинарников в /usr/local/bin. И другие вещи, которые я уже описал в простыне.

Чего нету - так это обвязки над bubblewrap, которая позволит пользователю рулить этой изоляцией. Надо делать.

Порталы - штука так же совершенно не привязанная к flatpak, и порталы в NixOS опять же есть, конечно (как бы флатпак то без них работал). Пробитие изоляции через порталы работает через dbus, тут опять же флатпак не нужен и все уже в NixOS есть. Нету сущности, которая все это соберет воедино и заставит работать именно через порталы.

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

А из ПМ явный лидер - Nix. Но он устроен так, что по сути заменяет собой OSTree. Вот и непонятно, что с этим делать дальше.

Нужна вышеупомянутая обвязка, чтобы Nix умел не только OSTree заменять, но и Flatpak с Appimage. (Ну и, конечно, хотелось бы, чтобы синтаксис был больше похож на YAML, а не на VerboseFuck.) И всё это дело как-то «втюхнуть» RH, иначе так и останется поделкой для энтузиастов.

Почему тогда по умолчанию не используются?

Потому что это легаси и антицель. Используется по умолчанию для легаси.

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

Это значит либо пересадить мир на Nix, что и так решит все проблемы, либо взять что там в флатпаке сейчас.

Я хочу интеграцию/изоляцию, как у Flatpak, но для пакетов, управляемых через Nix.

«Я хочу Теслу мощную как 747ой и дешёвую как Ока».

Ведь большая часть работы уже сделана.

Все трое существуют и это никак не помогает.

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

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

Для программистов, админов, DevOps и прочих рептилоидов она системно и последовательно решает чуть ли не все проблемы чуть ли не самым лучшим способом.

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

4.2, нет такого пакета.
Ну есть руби и есть, давай еще питон, раст, гцц и шланг выбросим

Плюс нужна возможность делать rw-оверлей поверх неизменяемого образа

Довольно удобно реализуется при помощи overlayfs. Сейчас все livecd так устроены.

чтобы синтаксис был больше похож на YAML

Флейки по синтаксису вроде лучше.

Потому что это легаси и антицель. Используется по умолчанию для легаси.

1. Не вижу смысла выкидывать совместимость просто ради выкидывания совместимости. FHS-образы выглядят куда лаконичнее и чище, чем костыли с переменными окружения на sh (которые нужно городить заново для каждой «щели») и мишура с хэшами в rpath.

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

Это значит либо пересадить мир на Nix, что и так решит все проблемы, либо взять что там в флатпаке сейчас.

Если бы мы решали только эту конкретную проблему, то достаточно было бы реализовать интерфейс между Flatpak и системным ПМ, а пакеты самого дистрибутива перевести на версии из «рантайма». Странно, что шапка этим ещё не озаботилась. Но а в нашем случае да. Нужно обеспечить возможность сборки стандартного «рантайма» и системы на его основе при помощи Nix.

«Я хочу Теслу мощную как 747ой и дешёвую как Ока».

Ладно бы так на остальные мои хотелки ответил. Но ведь нет особой разницы, к какому ПМ прикручивать изоляцию от Flatpak. И это в любом случае нужно делать. (Тащить в систему зоопарк «рантаймов» ради изоляции — берд, и меня раздражает, что эту проблему тупо игнорируют.)

Все трое существуют и это никак не помогает.

«Трое» — это кто? Nix, Flatpak и Appimage?

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

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

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

Ну и убрать наконец зоопарк из /etc по образцу Clear Linux. Это вообще никак от остальных изменений не зависит, можно начать реализовывать в любой момент.

Кстати, ты неправ, когда утверждаешь, что в Nix в принципе не существует проблемы конфликта зависимостей (а не что в Nix существует для неё решение). Ещё как существует. Попробуй в nix-shell запихнуть два пакета, которым нужны несовместимые версии одной и той же зависимости. Закономерно получишь фигу.

Довольно удобно реализуется при помощи overlayfs. Сейчас все livecd так устроены.

А разве не AUFS? В overlayfs есть rw? В любом случае нужна именно обвязка. Чтобы можно было, например, вручную отредактировать автоматически сгенерированный конфиг и хранить изменения в Git. А если система обновится и он сгенерируется по-другому, то показывать предупреждение.

FHS-образы выглядят куда лаконичнее и чище, чем костыли с переменными окружения на sh (которые нужно городить заново для каждой «щели») и мишура с хэшами в rpath.

FHS-образы несовместимы с reproducibility. Да и городить их на каждый чих дорого и ненужно, если можно не городить, но это уже какой-то шаг. Итак, каждый процесс в своём личном FPS-образе? Что дальше?

«Трое» — это кто?

Ока, боинг и тесла.

Ладно бы так на остальные мои хотелки ответил. Но ведь нет особой разницы, к какому ПМ прикручивать изоляцию от Flatpak.

Это не на Nix+изоляция, это на Nix+кроссдистрибутивный базовый образ. Тесла, скотч, Ока.

Кстати, ты неправ, когда утверждаешь, что в Nix в принципе не существует проблемы конфликта зависимостей

В Nix принципиально не существует такой нерешенной проблемы конфликта зависимостей, которую создал бы сам Nix. Две версии либы в двух разных процессах — тривиально, два бинаря с одним путем в один PATH — разруливается приоритетами, а вот две разные версии либы в один процесс нельзя и Nix тут не поможет. Но это фундаментальные «хочу невозможного», между ядрами на ходу Nix тоже не переключится, но это и не ПМами созданная проблема.

Я не менеджер и не работаю в Red Hat, поэтому мои выдумки вряд ли будут похожи на реальный план.

Мне все равно интересно.

начал бы я с попытки собрать образ какой-нибудь Fedora при помощи Nix. Для этого нужно как минимум описанную выше интеграцию с FHS реализовать.

Это на каком уровне? Просто готовый в деривацию сунуть? Скомпоновать из RPMок? Сами RPMки собрать никсом?

FHS-образы несовместимы с reproducibility.

Поясни.

Да и городить их на каждый чих дорого и ненужно, если можно не городить, но это уже какой-то шаг. Итак, каждый процесс в своём личном FPS-образе? Что дальше?

Зачем каждый процесс (и в чём заключается дороговизна)? Я хочу, чтобы от запуска nix-shell был примерно такой же эффект, как от flatpak run --command=$SHELL. Ну и чтобы вход в системный образ при загрузке происходил таким способом.

Мне все равно интересно.

Это на каком уровне? Просто готовый в деривацию сунуть? Скомпоновать из RPMок? Сами RPMки собрать никсом?

Ну вот чем сейчас собирают образ системы? Я LFS не собирал, поэтому с этим процессом особо не занком. Но предлагаю это дело перевести на Nix. Чтобы базовый образ получался не из дружбомагии, а из конкретных декларативных файлов. При загрузке мы первым делом заходим в этот образ. Если мы создавали образ Fedora, то получим систему, по большей части аналогичную Fedora. Только никакого управления пакетами там, конечно, не будет (как если бы LFS прикидывался «Федорой»). Для изменения системы (в т. ч. установки пакетов) использовать Nix, для взаимодействия с которым изнутри образа тоже предусмотрен какой-нибудь механизм. Необязательно пересобирать именно базовый образ. Можно под ним создать отдельный, в который пользователь будет ставить дополнительные пакеты и конфигурацию, и загружаться в него. По мере надобности создавать параллельные образы. Для костылей можно создать rw-образ (и если нужно, загружаться в него).

base                    (ro)
└─pkgs                  (ro)
  ├─parallel-universe-1 (ro)
  ├─parallel-universe-2 (ro)
  └─dirty-workarounds   (rw)

В итоге получается как в FCOS/Silverblue, но без потери гибкости. Можно адаптировать образы для совершенно разных целей.

Потом уже заняться интеграцией функциональности Flatpak/Appimage/OCI и прочими вещами, о которых я писал.

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

которую создал бы сам Nix

Так ведь и остальные ПМ её не создают. Просто не все её решают. При этом содание параллельных вселенных — это тоже далеко не всегда то, что нужно пользователю, и решение требуется уровнем выше.

Давай тогда сделаем перерыв до следующего года. Мысль услышана, я постараюсь её обдумать максимально непредвзято. Спасибо!

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

Я б сначала просто позвонил/поговорил, а то звучит действительно монументально.

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

мне вот интересно, а как вы боретесь (если боретесь вообще) с идиотскими зависимостями для сборки софта?

Что значит идиотскими? Зависимость на то и зависимость что без неё не собрать код, она не может быть идиотской. Бывают опциональные зависимости, если среди них ненужные и тяжёлые, отключаю. В остальном проблем не испытываю.

пихаете все это непотребство в систему?

А в чём проблема? Да, всё что нужно для сборки у меня стоит в системе.

используете бинарные сборки от разработчика?

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

Что значит идиотскими? Зависимость на то и зависимость что без неё не собрать код, она не может быть идиотской

еще как может. если программа без этой зависимости не теряет своей функциональности, но оторвать эту зависимость штатными средствами нельзя - это идиотская зависимость. как пример - claws-mail. если у тебя в сборочной системе установлен libnotify, то хочешь ты того или нет - когти соберутся с libnotify. еще пример - многие пионеры-неосилляторы roff кинулись man-ы в markdown строчить. хрен бы с ним, но одни придурки используют для генерации манов пистоний asciidoc, другие - рубиновый asciidoctor. несовместимости у них по мелочам, но в результате приходится или дополнительно править код, или держать в системе ненужное тебе барахло. и таких примеров могу привести до черта

Это и невозможно, потому что они не заведутся с системными зависямостями

спокойно использую firefox и libreoffice в сборках от разработчиков. второй вообще в deb-ах беру. особого дискомфорта не испытываю, единственная зависимость, которой у меня нет, но требуется этим бинарям - dbus-glib, что спокойно решается на этапе перепакетирования

Ах, вы об этих зависимостях - тех которые напрягают только неадекватных крохоборов с воспалённым чувством прекрасного? Как пользователь конечно же не борюсь, зачем мне бороться с фичами софта? У меня стоят и libnotify, и asciidoc, и asciidoctor, и pandoc и даже doxygen c latex. Как автор я после агрессивной просьбы такого же вот супчика (может даже и вас) переключить опциональную зависимость в OFF по умолчанию, решил делать все потенциально опциональные зависимости неотключаемым. По мне так такой невоспитанный и неблагодарный контингент не строит даже двух строчек #ifdef.

идиотская

пионеры-неосилляторы

одни придурки

Как автор я после агрессивной просьбы такого же вот супчика (может даже и вас) переключить опциональную зависимость в OFF по умолчанию, решил делать все потенциально опциональные зависимости неотключаемым

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

пихаете все это непотребство в систему?

иногда приходится

отказываетесь от использования в принципе?

Если есть альтернативы, а с зависимостями все весьма плохо - да

используете бинарные сборки от разработчика?

нет

еще какие варианты?

поправить исходники/мейкфайлы. иногда это не трудно.

юз флагами отключаю то что не используется и все. никаких проблем

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

Приложения есть в Android…

Вообще, было бы интересно посмотреть на аналог flatpak с nix вместо ostree. Или guix.

Так это и есть nix или guix как таковой. Можешь натянуть поверх практически любого дистрибутива.

Вместо appimage можно guix pack:

The ‘guix pack’ command creates a shrink-wrapped “pack” or “software
bundle”: it creates a tarball or some other archive containing the
binaries of the software you’re interested in, and all its dependencies.
The resulting archive can be used on any machine that does not have
Guix, and people can run the exact same binaries as those you have with
Guix.  The pack itself is created in a bit-reproducible fashion, so
anyone can verify that it really contains the build results that you
pretend to be shipping.

Мне пофиг на appimage и guix pack. Но в flatpak помимо собственно технологии ostree также есть сендбокс для каждого приложения и порталы. Без этих технологий ни о каком аналоге флатпака речь идти не может.