LINUX.ORG.RU

Nix vs Flatpak

 ,


1

3

Поставим вопрос ребром.

Какие преимущества имеет Nix перед Flatpak на десктопе?

Опираюсь на такую статью

https://serokell.io/blog/what-is-nix

Интересно и достаточно доступно расписано про Nix. Но! Я не могу понять, чем это лучше Flatpak?

Вот такие преимущества у Nix:

  1. Повторяемая сборка. С Flatpak, имея манифест, я могу делать сборку пакета в том окружении, которое прописано в манифесте, и получать гарантированно такой же пакет каждый раз. Не всегда это так, хеш коммита используемого SDK может в манифесте указываться а может нет, но если надо - то так делают.

  2. Бинарный кеш - конечно же есть у Flatpak, только называется не кеш а сами пакеты. Кроме того есть все манифесты для их сборки в гите, и внутри каждого пакета. То есть все как у Nix.

  3. Разные версии пакета одновременно. И там, и там это конечно же возможно.

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

  5. Сборка без привилегий для пользователя. Точно так же flatpak-builder не требует никаких привилегий и не использует ничего из хостовой системы.

Как видим, все перечисленное в равной мере характерно для Nix и для Flatpak. Так в чем тогда преимущество Nix?

Далее - у Nix есть возможности еще и по управлению конфигами. Эта функциональность выходит за границы пакетного менеджера и у Flatpak вообще отсутствует. Я предлагаю пока разделить эти сферы, и обсудить отдельно непосредственно сборку и управление пакетами.

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

Флатпак оперирует пользовательскими десктопными приложениями и крупными «квазипакетами»-рантаймами, заточен на десктоп и ввиду этого игнорирует 99% problem space (но зато имеет встроенную песочницу). Nix оперирует абстрактными пакетами и их комбинациями, решает более общую задачу декларативного управления операционной системой.

intelfx ★★★★★
()
Последнее исправление: intelfx (всего исправлений: 1)

Nix покрывает те юзкейсы, в которых песочница Flatpak априори мешает: CLI, сервисы, инструменты разработки.

Например, с помощью Flatpak установлены прикладные программы, у которых заранее можно детерминировать требуемые права (мессенджеры, редакторы медиа, браузеры). С помощью Nix же устанавливается VS Code, Intellij IDEA, Emacs, TeX Live, Syncthing, mpv + youtube-dl etc. Примерно всё то же самое, что и в традиционных ПМ, доступное как общесистемно, так и внутри nix-shell.

По крайней мере у меня такое разделение в системе.


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

commagray ★★★★★
()
Последнее исправление: commagray (всего исправлений: 5)

Из преимуществ вижу

  1. орг.Отсутсвие.отсутствие_вот_таких_названий_сюда_же_тот_факт_,_что_приложения_запускаются_стандартным_путём.
  2. Большая база пакетов.
  3. Ну и флатпак тащит рантайм. Для графических приложений — ок, но для консольных утилит (или сервисов) будет так себе.

Далее - у Nix есть возможности еще и по управлению конфигами. Эта функциональность выходит за границы пакетного менеджера и у Flatpak вообще отсутствует. Я предлагаю пока разделить эти сферы, и обсудить отдельно непосредственно сборку и управление пакетами.

+1.

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

С помощью Nix же устанавливается VS Code, Intellij IDEA, Emacs, TeX Live, Syncthing, mpv + youtube-dl

У меня все это установлено, или могло быть установлено (я не использую IDEA), через Flatpak. Пока я не вижу причин которые бы этому мешали.

у которых заранее можно детерминировать требуемые права

Точнее, заранее можно задать дефолтные права. Как их менять - это решает пользователь. Например для VS Code мне нужны права на доступ к USB устройствам, чтобы использовать программатор. И я даю ему эти права. По дефолту их нет.

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

Отсутсвие.отсутствие_вот_таких_названий

Ну допустим, хотя это спорно

Большая база пакетов.

Вопрос текущей конъюнктуры.

Ну и флатпак тащит рантайм. Для графических приложений — ок, но для консольных утилит (или сервисов) будет так себе

Для консольных будет freedesktop рантайм который мегабайт 150 весит. Это никого не спасет. Хотя проблема есть, и она вынуждает полностью переходить на флатпак - ставить одно приложение через него бессмысленно.

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

Пока я не вижу причин которые бы этому мешали.

Часто эти программы вызываются другими программами. Например, mpv, TeX и Emacs уж точно — их нужно по-человечески экспортировать в $PATH без Java-нотации с бесконечным tld.source.author.program. И экспортировать множество бинарников из пакета, а не один.

У VS Code, IDEA и Emacs также бывает обратная ситуация: им нужно вызывать другие программы, находящиеся в $PATH. Это предлагается решать с помощью дополнений к рантайму, но это достаточно муторно и добавляет лишнюю нагрузку мейнтейнерам.

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

commagray ★★★★★
()
Последнее исправление: commagray (всего исправлений: 2)
Ответ на: комментарий от fernandos

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

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

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

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

Ну допустим, хотя это спорно

Не хватает утилиты, которая автоматически бы делала алиас.

Для консольных будет freedesktop рантайм который мегабайт 150 весит. Это никого не спасет. Хотя проблема есть, и она вынуждает полностью переходить на флатпак - ставить одно приложение через него бессмысленно.

Да, но из-за п.2, увы, пока приходится ждать.

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

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

А не слишком ли жирно? Тем более, если мы идём к светлому кроссдистрибутивному будущему, то и так будет стоять куча консольных утилит, freedesktop.sdk должно хватить.

Так, ЕМНИП, делает неовим.

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

их нужно по-человечески экспортировать в $PATH без Java-нотации с бесконечным org.github.author.program.

Вот тут бы поподробнее - почему нужно, кому и почему мне не нужно?

Это предлагается решать с помощью дополнений к рантайму, но это достаточно муторно

Спорно, в полностью-флатпак системе, как у меня, это вполне естественно, и все нужное засунуто в дополнения. Да, это не стандартно, но и Nix мягко говоря ломает FHS и там тоже многое нестандартно и требует усилий. То есть недостаток как бы есть, но тут плюс-минус.

James_Holden ★★★★
() автор топика

флатпак тормозной

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

Не хватает утилиты, которая автоматически бы делала алиас.

Это может обломиться, если у двух пакетов окажется одинаковое «верхнее доменное» имя.

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

А не слишком ли жирно?

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

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

Пускай устанавливаются org.com.dot.slah.developer_name.program.name, в юзерспейс можно запускать под доменным именем, тогда максимум, что произойдёт — перекрытие. Пользователь же сможет менять имя на то, которое захочет.

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

С одной стороны да, можно это сделать, добавив такую функциональность во flatpak.

С другой - не совсем понятна задача запускать эти приложения из командной строки. Зачем это так нужно?

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

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

Из таких приложений, которые прямо приложения, а не утилиты юникса, я могу назвать только ffmpeg и mpv, и то, их использование не через GUI во многих случаях просто от бедности, а не от того что реально нужна командная строка.

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

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

Ну или flatpak run org.unixway.RedEyes у которого command=bash в манифесте, и дальше запускаем любые консольные утилиты.

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

По поводу базы пакетов.

Вот возьмем банальный клиент Spotify. И что мне делать в NixOS, ставить его через Flatpak? Или прикручивать изолентой через steam-run?

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

Ага, ну spotify это оно, внезапно. Но почему-то в Wiki про это не написано, а предлагается открывать порт (что понятно) и ставить неофициальный клиент.

Или скорее, даже в Wiki написано, но как-то чисто по-своему.

Отсюда вопрос. Как узнавать про то, какой пакет нужно ставить для какого приложения?

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

Nix управляет пакетами самым лучшим, гибким и прекрасным на 2021 способом. То, что он пригоден для управления конфигами — лишь побочка.

Flatpak занимается изоляцией, но зачем-то ещё и из рук вон плохо распространяет предкомпилированную фигню большими кучами.

Как их можно сравнивать — понятия не имею. pacman и Steam друг к другу ближе.

t184256 ★★★★★
()
Последнее исправление: t184256 (всего исправлений: 2)
Ответ на: комментарий от James_Holden

А можно не страдать фигнёй и юзать Nix. Потому что флатпак никогда не сможет даже банальное «дай мне шелл с rsyslog, у которого пропатчен gnutls».

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

Nix управляет пакетами самым лучшим, гибким и прекрасным на 2021 способом. То, что он пригоден для управления конфигами — лишь побочка.

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

самым лучшим, гибким и прекрасным

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

А конкретнее? Это какие-то гуманитарного уровня оценочные суждения. Вот я и создал тред чтобы мне пояснили конкретно, чем одно прекрасно а второе из рук вон плохо.

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

Вот возьмем банальный клиент Spotify. И что мне делать в NixOS, ставить его через Flatpak?

Можно. А можно поставить Firefox, купить через него телефон и поставить Spotify туда. А можно нормально опакетить. Свобода!

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

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

Нет, поздно, это уже тред про флатпак.

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

Потому что флатпак никогда не сможет даже банальное «дай мне шелл с rsyslog, у которого пропатчен gnutls».

Как это не даст? Что этому помешает? Элементарно можно пропатчить.

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

Можно. А можно поставить Firefox, купить через него телефон и поставить Spotify туда. А можно нормально опакетить. Свобода!

Со spotify мне уже пояснили, да, проблем нет.

Нет, поздно, это уже тред про флатпак.

Можно без этой хрени гуманитарной? Чисто по техническим аргументам.

Ну серьезно, я решаю а действительно не перейти ли на NixOS.

Только блин никто не может объяснить толком.

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

Второе негибко. Может твой флатпак собрать мне вон тем тулчкейном раста вон ту софтину? Перекомпилировать Firefox с musl? Банально плагины для вима поставить? Флатпак на шкале пакетного менеджмента ближе к «завести под каждую программу отдельный ЖД с отдельной ОС», чем к Nix.

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

Может твой флатпак собрать мне вон тем тулчкейном раста вон ту софтину?

Конечно, а как по-твоему собирается растовый софт во флатпаке? Так и делается. Указывается расширение SDK с нужным тулчейном раста и собирается софтина. Я так helvum собираю, которого на flathub пока нет, но выкладывают манифест флатпаковый. Там прописан тулчейн растовый.

Перекомпилировать Firefox с musl?

Детский сад, ну неужели ты думаешь что нельзя? Как по-твоему вообще софт во флатпаки собирается? Пишется манифест, по нему собираются все зависимости. Надо musl - ну соберется musl.

Банально плагины для вима поставить?

Банально у флатпака есть специальные пакеты для этого. Чтобы плагины к софту ставить. У меня тут для работы с аудио плагинов вагоны стоят.

Более того, я сам выпускаю аудио плагины и они есть на flathub.

Флатпак на шкале пакетного менеджмента ближе к «завести под каждую программу отдельный ЖД с отдельной ОС», чем к Nix.

Откуда такой вывод?

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

Какую команду надо? Консольную? Это не консольной командой делается, как и в Nix, насколько я понимаю.

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

Руками на спор можно что угодно, хоть LFS собрать и в deb-пакет засунуть. Ты composable образом в одну строку давай.

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

Не понимаю что ты от меня просишь. Давай так - дай пример как c Nix вот это в одну строку делается, буду плясать от этого.

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

В Nix это все делается одним Nix-выражением умеренной длины. Например для пример с Firefox и musl вообще есть шорткат: pkgsMusl.firefox, лол. rsyslog с пропатченным gnutls будет уже где-то символов 70-120. Покажешь хоть один из этих примеров на flatpak?

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

Например для пример с Firefox и musl вообще есть шорткат

Это не интересно, шорткат с неба не падает.

rsyslog с пропатченным gnutls будет уже где-то символов 70-120

Вот это интересно, как это выглядит?

И еще вопрос - вот эту строку куда мне писать надо?

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

[шелл с] rsyslog с пропатченным gnutls будет уже где-то символов 70-120

Вот это интересно, как это выглядит?

Примерно как nix-shell -p 'rsyslog.override({ gnutls = gnutls.overrideAttrs(oa: {patches = oa.patches ++ [./some.patch]; }); })'.

И еще вопрос - вот эту строку куда мне писать надо?

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

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

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

Ну блин

flatpak install org.james_holden.python3_with_numpy.Sdk.Extension
flatpak run --command=bash org.freedesktop.Sdk

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

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

А вообще это все высосано из пальца - есть pip и virtualenv для этого.

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

Ну блин, смысл приводить примеры где просто используется готовый пакет. flatpak install org.james_holden.python3_with_numpy.Sdk.Extension

Смешно.

Во-первых, а что ты будешь делать, когда тебе понадобится еще scipy и оба внутри python 3.11, заново перепакечивать? Смысл в composability.

Во-вторых, даже без composability, ну и где этот готовый пакет для флатпака?

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

Вот этот пример мне уже намного больше нравится. Тут более понятно в чем преимущества.

Конечно с флатпаком так не делается. Допустим опять же что есть флатпак с rsyslog, тогда надо взять его манифест и туда дописать накладывание патча (это та же одна строчка). Потом собрать через flatpak-builder –install – user, потом запустить через flatpak run … если уж по аналогии с virtualenv’ами.

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

А вообще это все высосано из пальца - есть pip и virtualenv для этого.

Ага. А еще cargo, npm и еще какая-нибудь мерзота.

Покажи мне как сделать virtualenv с flask и пятью какими-нибудь пакетами из npm. Или даже давай еще менее надуманно, с python-evdev и хедерами ядра.

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

И вот мы уже и в каменном веке, со правкой сразу нескольких спекфайлов и ручной установкой gnutlsов в разные префиксы. LFS с дополнительными препятствиями в виде флатпака.

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

ну и где этот готовый пакет для флатпака?

Готовое меня не интересует, иначе я бы поставил убунту и не дурил голову. Интересуют возможности того, что можно сделать.

а что ты будешь делать, когда тебе понадобится еще scipy и оба внутри python 3.11, заново перепакечивать?

Тут задница.

А что делать, если в Nix не окажется готового пакета в этой же ситуации?

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

Интересуют возможности того, что можно сделать.

Все. Только в случае флатпака это будет вопреки флатпаку, а Nixу просто достаточно написать, что тебе от него надо.

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

А что делать, если в Nix не окажется готового пакета в этой же ситуации?

«Опакетить», написав соответствующее Nix-выражение. Тебя же уже предупредили, что не «опакетив» ты на Nix ничего не запустишь?

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

как сделать virtualenv с flask и пятью какими-нибудь пакетами из npm

Сначала надо придумать, зачем это нужно. Я пока не придумал.

с python-evdev и хедерами ядра

pip install evdev, а хедеры и так есть, зачем их именно в virtualenv?

James_Holden ★★★★
() автор топика
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.