Уложи это в одно предложение и будет простыми словами.

Я хочу понять, где я что-то (или все) неправильно понял

про flatpak runtime ни слова

http://docs.flatpak.org/en/latest/available-runtimes.html

Расскажите, что это.

Задача Flatpak и Snap - упростить для конечного пользователя процесс установки программ, которые не содержатся в менеджере установки ПО его дистрибутива, но не избавляет авторов flatpak-файла или snapa от необходимости найти или скомпилировать необходимые бинарные файлы для различных дистрибутивов - разные виды rpm и deb, разместить их на определенном сервере или найти такой сервер и указать на все нужные файлы ссылки.

у флатпака есть среда исполнения, не надо прям всё-всё собирать, это к аппимейджу относится. Про снап не знаю, врать не буду как там.

Flatpak (и Snap) не является универсальной альтернативой для систем DEB и RPM, объединяющей все семейства дистрибутивов

Для прикладных программ являются. Уже есть Endless OS и готовится к выпуску Fedora Silverblue — в них все приложения, кроме системных предлагается флатпачить, система же находится в режиме только для чтения.

Flatpak (и Snap) не является ZIP-подобным архивом, содержащим бинарные файлы устанавливаемых программ или их исходные коды

Да.

Flatpak (и Snap) является скриптом, который содержит информацию об устанавливаемой программе и списке ее зависимостей

Нет.

Flatpak (и Snap) осведомлен о том, на каком конкретно дистрибутиве Linux он запущен, какие зависимости уже удовлетворены в системе, и какие необходимо удовлетворить

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

Flatpak (и Snap) содержит информацию об источниках установки необходимых пакетов (само приложение и зависимости), но не требует их добавления в систему как репозиториев - это просто ссылки (нужный пакет берем отсюда)

Это что то вообще.. Каша. Это полноценные пакеты ПО, только другие.

Приложения, устанавливаемые через Flatpak и Snap, и все их зависимости устанавливаются в песочницу и не заменяют собой системные версии файлов и библиотек, при этом все уже установленные зависимости копируются в ту же песочницу, что и сама программа (либо разработчик решает этот вопрос при сборке Flatpak / Snap)

В принципе правильно, но ни чего не копируется ни куда, если не включено в пакет, а есть в рантайме или системе.

Snap - это то же самое, что Flatpak, но с единым «магазином», который контролируется Canonical, плюс нужно подписать с Canonical соглашение для его использования, но кардинальных различий между snap и flatpak нет, поэтому, если разработчик уже поддерживает flatpak, то единственная причина поддерживать еще и snap - выделенное место на серверах Canonical для хранения его файлов.

Хз, подождем убунтоводов прошаренных, самому интересно.

«Зоопарк» различных версий пакетов для дистрибутивов это навсегда и реальных альтернатив для DEB и RPM нет и не предвидится, так как основная проблема несовместимости различных дистрибутивов даже не в самой разнице форматов DEB и RPM, а в наборах используемых в разных дистрибутивах библиотек, структуре файлов, расположении каталогов и т.д., и нет надежды на то, что разработчики Red Hat, Debian, Ubuntu, Arch и OpenSuse когда-нибудь решат сесть за стол переговоров и утвердить единый общий для всех стандарт и унифицированный менеджер пакетов...

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

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

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

Окружение которое содержит все необходимые компоненты для большинства пакетов, те же библиотеки. Экономит ресурсы разработчиков конечных флатпаков. Большинство пакетов сегодня зависят от трех основных сред выполнения (гном, кеды и фридесктоп). Можно конечно собрать свой совсем самодостаточный флатпак со своим реалтаймом — но это на порядок сложнее.

Т.е. на примере Endless OS и Fedora Silverblue как эталонов мы имеем такие слои:

• Система
• рантайм (или несколько)
• конечный флатпак

Задача Flatpak и Snap - упростить для конечного пользователя процесс установки программ

Не совсем. Их задача - упростить сборку и распространение программ для разработчиков.

1. Flatpak (и Snap) не является универсальной альтернативой для систем DEB и RPM, объединяющей все семейства дистрибутивов

Являются. Для обеспечения независимости от дистрибутива они используют собственные рантаймы. В отличие от Appimage, кстати.

Flatpak (и Snap) не является ZIP-подобным архивом

Flatpak использует OSTree, Snap - squashfs.

3. Flatpak (и Snap) является скриптом, который содержит информацию об устанавливаемой программе и списке ее зависимостей

Нет.

4. Flatpak (и Snap) осведомлен о том, на каком конкретно дистрибутиве Linux он запущен

Ты имеешь в виду сам flatpak/snap или программу в нём? Если второе, то в случае Flatpak - нет.

5. Flatpak (и Snap) содержит информацию об источниках установки необходимых пакетов

Нет, они оба не имеют никакого отношения к пакетам.

6. Приложения, устанавливаемые через Flatpak и Snap, и все их зависимости устанавливаются в песочницу

Да, они самодостаточны и независимы от системы.

7. Snap - это то же самое, что Flatpak
кардинальных различий между snap и flatpak нет,

Нет, у них много технических отличий и они существенные.

нет надежды на то, что разработчики Red Hat, Debian, Ubuntu, Arch и OpenSuse когда-нибудь решат сесть за стол переговоров

Провоцирует фрагментацию тут, на самом деле, только кое-кто один.

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

В-первых, никакой песочницы в AppImage нет. Во-вторых, это он всё ещё зависим от среды запуска и не гарантирует одинаковую работу во всех ОС (в отличие от flatpak/sna).

Почитал про Endless OS, многое стало яснее.

Ну, вот я скачал Flatpak Gimp 2.10 на Mint 19v2. Весит он что-то около 9 килобайт, когда запускаю его, у меня открывается «магазин» Mint и вместо Gimp 2.8, который там искался бы по-умолчанию, у меня там появляется Gimp 2.10 - жму Install, ставлю (или как-то так). Отсюда делаю вывод, что внутри файла флэтпака нет ничего, он все ему нужное откуда-то должен скачать - это не исходники, ничего не компилируется. Получается это бинарники, но не RPM'ы и DEB'ы, а универсальные линуксовые бинарники? Мне вот с этим хочется разобраться.

Про фрагментацию - о ком речь? Просто интересно, а я не в курсе. Или скажите, что погуглить, сам разберусь

Ты скачал файл .flatpakref, который действительно не содержит полезной нагрузки, а только метаданные с указанием, откуда её взять. Там данные репозитория (Flathub в твоём случае), который будет подключён (если ещё не), его открытый ключ и всё такое.
Flatpak поддерживает файлы, таки содержащие полезную нагрузку - у них расширение .flatpak.

Тут всё еще интереснее

Endless OS до недавнего прошлого (может что именилось или изменится в обозримом будущем, я не слежу пристально за ними) имел существенный недостаток — реадонли образ системы был некастомизируемым ни как. Ноутбуки поставляются до сих пор с полурабочей осью и невозможностью ее починить, т.к. образ системы один на всех и он не идеален. Лично у меня были проблемы с настройками цветопередачи. Кстати, у меня в профиле есть в галерее есдинственный пост и он про Эндлесс.

А вот Fedora Silverblue хоть так же рилдонли образ системы с «атомарным» обновлением, но имеет уже инструмент rpm-ostree — им можно вносить изменения в систему. https://www.opennet.ru/opennews/art.shtml?num=48552

Классических дистрибутивов всё это не касается (пока, по крайней мере). Т.е. флатпак тут еще один вид распространения пакетов просто в дополнение к классическому. И да, у меня две версии hexchat — системная и флатпак. Флатпаковской не пользуюсь, не смотря на наличие всех ключей не удается скормить ему мой профиль, а чистый внутри флатпака меня не устраивает (вообще профиль юзера внутри флатпака дичь). Но это косяк мейнтейнера который просто болт клал, так что не всё еще так радужно в нашем мире...

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

Может ли разработчик Gimp или Shotcut или любой другой программы на сегодня забить и не делать ни RPM, ни DEB, вообще, а собрать Flatpak, оттестить его на Mint/Ubuntu или какой-нибудь Fedore (и больше ни на чем) и быть уверенным, что скачавшие этот Flatpak юзеры получат полностью рабочую программу?

Да, только зачем? Лучше публиковаться на том же Flathub'е.

Уже понятнее! Спасибо! А вот еще вопрос, если разработчик публикуется на Flathub, он прилинковывает уже загруженные туда депенденсы и они тянутся как отдельные... flatpak'и? Или бинарники? И, вообще, что это - Flathub? Это конкретная группа серверов, которую мейнейнит некая организация добра, или это скорее формат размещения файлов?

А многие и сегодня не собирают ни чего сами, мейтейнеры дистров всё делают.

быть уверенным, что скачавшие этот Flatpak юзеры получат полностью рабочую программу?

Привяжут к фреедесктоп и будут уверены. А юзеру придется ради условного гимпа выкачивать жирный runtime. Отсюда и стремление максимум пакетов перевести в поставку флатпаками — runtime имеет смысл для пользователя когда у него десятки пакетов на нем крутятся.

runtime тянется целиком и один раз

Во флатпаке есть несколько рантаймов (KDE, Gnome, Freedesktop), в снапе только один (core snap). Кроме рантайма, у приложения нет отдельных зависимостей, всё необходимое упаковывается вместе с ним.

И, вообще, что это - Flathub?

Это репозиторий flatpak. Де-факто стандартный магазин флатпаков, если угодно.

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

1. Не очень понятно что хотел сказать, но да, не являются. Оба чуть лучше подходят для обособленного прикладного софта, типа браузера или аудиоплеера, но плохо для компонентов DE, и прочих частей окружения ОС.
2. Строго говоря, не является. Но в общем смысле вещи того же порядка. То есть да, все бинарные файлы содержит, только для Snap - это образ SquashFS, для Flatpak - OSTree.
3. Да, но у обоих это декларативные описания на JSON/YAML, а не скрипты в строгом смысле.
4. Нет. Оба используют собственные рантаймы с зависимостями, и безразличны к составу дистрибутива. Snap вроде использует что-то с дистра, но в любом случае подтянет это как часть зависимостей самого snap.
5. Да, но нет. Добавленные в Snap или Flatpak источники становятся доступными источниками для установки через Snap или Flatpak соответственно, но никак не связаны с источниками для пакетного менеджера дистра.
6. Да.
7. Нет. Системы похожие, но отличия в технических деталях. Snap позволяет создавать свои источники, да и для Flatpak теперь появился единный репозиторий Flathub, хотя он и не является дефолтным. IMO, в долгосрочной перспективе системы могут стать аналогичными, передрав друг у друга особенности реализации.
8. Начнем с того что DEB и RPM - только две более популярные системы. Надежда на стандартизацию всегда есть, но альтернативные реализации никто не запретит делать, так что да, зоопарк будет всегда, но его состав может стать другим.
9. Нет. Начиная с того что AppImage - это исполняемый бинарник, который никуда не ставится, а просто исполняется и несет в себе большую часть необходимых зависимостей. Песочницы там никакой нет, прикручивается она уже при желании заинтересованными пользователями, при этом тот кто собирает AppImage не предполагает что она будет.

   работает в любом дистрибутиве линукс.
   

   Нет. Но есть инструкции как собрать AppImage так, чтобы он работал в популярных дистрах.

У меня замечаний нет вроде...

5. Flatpak (и Snap) не требует добавления в систему новых репозиториев, но требует установки рантайма (-ов).

Требует. Но репозитории свои и не имеют отношения к «классическим» репозиториям deb/rpm.
Ещё, поскольку репозиторий (snap store) и рантайм (core snap) у Snap'а только один, можно считать, что рантаймы и репозитории есть только для Flatpak'а.

2. файл .flatpak может физически содержать бинарные файлы устанавливаемых программ и их зависимости, но разработчики предпочитают использовать онлайн-сервис flathub

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

.flatpak - это OCI совместимый бандл. Не основной способ распространения приложений, но доступный. И да, зависимостей там не будет, они все равно будут требовать рантайм. Который тоже можно сформировать ввиде .flatpak файла. Потом, например, закинуть оба файла на флешку, и использовать где и когда надо.

Теоретически их можно даже пускать другими системами умеющими работать с OCI-контейнерами (в скором времени поддержку завезут в systemd-nspawn), но про флатпакспецифичные штуки вроде пермишнов придется забыть.

Я бы сказал иначе. Если разработчик делает deb или rpm, то ему лучше распротранять самодостаточные приложения. Для дистров лучше же обеспечивать безпроблемную сборку, потому что модель дистров работает так, что собирает мейнтейнер дистра, а не разработчик. Проприетарщину вообще лучше исключительно самодостаточными приложениями распространять.

в снапе только один (core snap)

В снапе есть и дополнительные рантайм-модули, например с gtk и кедолибами.

поэтому перспективность AppImage под вопросом, а вот у flatpak будущее однозначно есть.

Не совсем. AppImage и Flatpak/Snap решают несколько разные задачи.

Flatpak/Snap - это системы, которые предлагаю универсальные форматы распространения приложений и инструменты для их устрановки и исполнения.

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

От репозиториев ухходят в сторону установки софта как в мак оси и винде, т.е. перетягиванием папок с прогой, тока перетягивает за тебя робот со своего проприетарного сервера :)

готовится к выпуску Fedora Silverblue

У разработчиков Silverblue был план сделать его основой Fedora Workstation к 30 версии, но из-за общей сырости отказались от этого. Поговаривают, что полностью рабочий вариант будет года через 1-1.5, там и podman с buildah избавит от основных ошибок и добавят дополнительный функционал, flatpak тоже нуждается в определённых доработка (в задумках реализовать gui для разрешений и т.п.) и т.д.

Вообще задумка Silverblue с его root ro, flatpak, buildah/podman открывает окно возможностей. Про модули тоже не стоит забывать.

Нужно, жду.

flatpak будущее однозначно есть

Flat pack завязан на десктоп, поэтому будущее его сомнительно.

Уложи это в одно предложение и будет простыми словами.

В «Не нужно»? :)

На минуточку, сравните юзабилити:

10 years ago

https://www.techrepublic.com/blog/how-do-i/how-do-i-create-desktop-icons-in-k...

2018

https://www.maketecheasier.com/create-desktop-file-linux/

Так, а что нам предлагают монстры snap и flat в качестве интеграции? Черный ящик, одинаковые иконки и названия: https://imgur.com/8fyqRaf

штуки вроде пермишнов

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

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

а на самом деле получаем

косяк мейнтейнера который просто болт клал

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

В Ubuntu со Snap кстати знатная помойка получается

https://askubuntu.com/questions/851615/why-does-the-blender-tpaw-package-exis...

то есть получаем ещё более безответственный подход ментейнера, который ещё не факт что он непосредственный разработчик пакета

Именно, поэтому мои ожидания от флатпака не оправдались. На flathub _уже_ лежит черте что, а это считают нормальным. Продолжаю юзать скачанные бинари с офсайтов, кладя их в opt. В этом случае, можно хотя бы обратиться к разработчику софта в трекер. А в случае неофициального флатпака никто не будет слушать, спишут на «неофициальность» (и во многих случаях будут правы).

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

Одно из причин, по которой мне не нравится chrome - абсолютно неструктурированная помойка дополнений без разделения на категории. Найти что-то, о чём ты заранее не знаешь крайне сложно. Даже в opera этим озаботились и там с этим намного лучше.

спишут на «неофициальность»

я бы на месте разработчика апстрима тоже сначала перенаправил к ментейнеру:особенно, если пользователь не может предоставить данные о рантайме. Кстати, а можно ли запускать приложение из флатпака/снапа пропуская его через strace, gdb, ldd? Ведь их вывод могут попросить.

В Snap Srore вот добавили проверенных разработчиков. У них звёздочка стоит 🌟

Но как-то всё равно чего-то не то.

Ещё один минус в копилку flatpak - невозможно получить рабочий flatpak с Chrome. Это же касается любого софта со своим sandbox.

А вот Opera у меня стоит как раз из Snap Store, ибо это единственная дистрибуция её под линуксы без пляски с кодеками.

Flatpak запуск, отладка

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

Это да, я правда в той же генту редко закидывают новую версию кодека. Widevine они начиная с 54 версии поломали и не чинят, поэтому, например, больше не воспроизводятся фильмы с ivi (даже бесплатные) и кинопоиска (из списка покупок). Ладно хоть бесплатные смотрятся в последнем. Для платных или ivi у меня есть chrome.

Для генту есть оверлей с яндекс браузером и там имеется скрипт сборки нужной версии кодека (можно скачать собранный ментейнером оверлей). Или опять же скачать ~ нужную версию кодека от убунты. Собирается кодек долго + требует llvm, clang для сборки - так как по сути тянет исходники chromium и использует их.

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

Пользуюсь 28 Silverblue, никакой сырости не заметил, как впрочем и планов про отказу предоставить готовый к 30. Что хотят к 30-ке сделать - это чтобы все можно было через gnome-software ставить и обновлять.

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

Речь идёт про рабочий вариант для широкого круга пользователей. На текущий момент Silverblue рассчитан больше на разработчиков, продвинутых пользователей. Во flatpak, podman/buildah, а это основа основ, достаточно узких мест, которые нуждаются в доработке. Git issues соответствующих инструментов это подтверждают. Насчёт отложить идею сделать Silverblue основным Fedora Workstation 30 высказывался один из разработчиков. К сожалению, источника информации не помню, так как он в памяти не сохранился. Где-то на забугорных ресурсах месяц назад прочитал.

Что хотят к 30-ке сделать - это чтобы все можно было через gnome-software ставить и обновлять.

Весь софт с графической оболочкой (Fedora repo, Flathub repo) спокойно можно установить уже сейчас через Gnome Software Center. Правда кривовато выходит, но можно.

Это касается только GUI, про установку не графических приложений гномовцы забыли, ведь настоящий гномовец никогда не устанавливает (не использует Gnome Software Center для установке) vim, emacs, компонентов для разработки, библиотек и прочего🤣