Appimage, Flatpak, Snap: что лучше/перспективнее?

а у меня krita из snap в меню появилась.

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

а у меня krita из snap в меню появилась.

Странно...вчера ставил в Ubuntu (Unity) и ничего. Запускал из менеджера приложений. Ставил через него же.

Лол, что? Какая слака? Я ей в жизни не пользовался.

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

Такое частенько в убунте встречается.

Кстати, а что там про FatELF было? Или это просто один бинарник на все архитектуры?

поясни, как собрать deb-пакет?

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

а у меня нет никаких исходников, есть набор бинарей и всё

чо делать?

есть ссылка на нормальную инструкцию?

http://askubuntu.com/a/27731/483078

Закопать поглубже все три, протравить заразу дустом.

Я бы лучше вот этот Dependency Hell закопал:

sudo apt install krita
Чтение списков пакетов… Готово
Построение дерева зависимостей       
Чтение информации о состоянии… Готово
...
НОВЫЕ пакеты, которые будут установлены:
  breeze-icon-theme calligra-data calligra-libs docbook-xsl fonts-dejavu fonts-dejavu-extra fonts-lato icoutils kactivities kate-data katepart kde-runtime kde-runtime-data kde-style-breeze
  kde-style-breeze-qt4 kdelibs-bin kdelibs5-data kdelibs5-plugins kdoctools kpackagelauncherqml kpackagetool5 krita krita-data kwayland-data kwayland-integration libakonadi-kde4
  libakonadiprotocolinternals1 libattica0.4 libcauchy0.0v5 libdlrestrictions1 libfam0 libkabc4 libkactivities6 libkatepartinterfaces4 libkcalcore4 libkcmutils4 libkdcraw-data libkdcraw23 libkde3support4
  libkdeclarative5 libkdecore5 libkdesu5 libkdeui5 libkdewebkit5 libkdnssd4 libkemoticons4 libkf5activities5 libkf5archive5 libkf5attica5 libkf5auth-data libkf5auth5 libkf5calendarevents5
  libkf5codecs-data libkf5codecs5 libkf5completion-data libkf5completion5 libkf5config-bin libkf5config-data libkf5configcore5 libkf5configgui5 libkf5configwidgets-data libkf5configwidgets5
  libkf5coreaddons-data libkf5coreaddons5 libkf5crash5 libkf5dbusaddons-bin libkf5dbusaddons-data libkf5dbusaddons5 libkf5declarative-data libkf5declarative5 libkf5globalaccel-bin libkf5globalaccel-data
  libkf5globalaccel5 libkf5globalaccelprivate5 libkf5guiaddons5 libkf5i18n-data libkf5i18n5 libkf5iconthemes-bin libkf5iconthemes-data libkf5iconthemes5 libkf5idletime5 libkf5itemviews-data
  libkf5itemviews5 libkf5jobwidgets-data libkf5jobwidgets5 libkf5kiocore5 libkf5kiowidgets5 libkf5notifications-data libkf5notifications5 libkf5package-data libkf5package5 libkf5plasma5
  libkf5plasmaquick5 libkf5quickaddons5 libkf5service-bin libkf5service-data libkf5service5 libkf5sonnet5-data libkf5sonnetcore5 libkf5sonnetui5 libkf5style5 libkf5textwidgets-data libkf5textwidgets5
  libkf5waylandclient5 libkf5widgetsaddons-data libkf5widgetsaddons5 libkf5windowsystem-data libkf5windowsystem5 libkf5xmlgui-bin libkf5xmlgui-data libkf5xmlgui5 libkfile4 libkhtml5 libkio5 libkjsapi4
  libkjsembed4 libkldap4 libkmediaplayer4 libknewstuff3-4 libknotifyconfig4 libkntlm4 libkparts4 libkpty4 libkresources4 libkrosscore4 libkrossui4 libktexteditor4 libkxmlrpcclient4 libm2mml0.0v5
  libnl-route-3-200 libntrack-qt4-1 libntrack0 libopencolorio1v5 libphonon4 libphonon4qt5-4 libphononexperimental4 libplasma3 libpolkit-qt-1-1 libpolkit-qt5-1-1 libpoppler-qt4-4 libqca2
  libqca2-plugin-ossl libqca2-plugins libqjson0 libqt4-designer libqt4-opengl libqt4-qt3support libqt4-svg libqt5waylandclient5 libqt5x11extras5 libqtwebkit4 libruby2.3 libsolid4 libsoprano4 libspnav0
  libstreamanalyzer0v5 libstreams0v5 libthreadweaver4 libvoikko1 libxcb-composite0 libxcb-damage0 libxml2-utils libyaml-cpp0.3v5 ntrack-module-libnl-0 oxygen-icon-theme oxygen5-icon-theme phonon
  phonon-backend-gstreamer phonon-backend-gstreamer-common plasma-framework plasma-scriptengine-javascript qml-module-org-kde-activities qml-module-org-kde-kquickcontrols
  qml-module-org-kde-kquickcontrolsaddons qml-module-qtquick-dialogs qml-module-qtquick-privatewidgets qtwayland5 rake ruby ruby-did-you-mean ruby-minitest ruby-net-telnet ruby-power-assert
  ruby-test-unit ruby2.3 rubygems-integration sonnet-plugins soprano-daemon
обновлено 0, установлено 188 новых пакетов, для удаления отмечено 0 пакетов, и 0 пакетов не обновлено.
Необходимо скачать 127 MБ архивов.
После данной операции, объём занятого дискового пространства возрастёт на 480 MB.
Хотите продолжить? [Д/н]

Развели, блджд, эпидемию.

76M krita-3.0-x86_64.appimage — Вот. Красивенько. Запустил, поработал, выключил. И система девственная, не изнасилованная KDE3, KDE4, KDE5 хламом.

Так что AppImage и прочее — несомненный +. Жирный плюс.

Лол, а вес самого appimage вы не хотите посчитать? И, да, дебианопроблемы. В моём арче без кед Krita с зависимостями - это 41 пакет весом чуть больше 200 Mb в установленном виде.

Я бы лучше вот этот Dependency Hell закопал:

Теперь я понимаю, что значит «латентный макофил».

Кто что думает?

[x] Против всех

Чел, я собрал Krita в PPA, и он при установке тянет за собой только Opencolorio https://launchpad.net/~samoilov-lex/ archive/ubuntu/krita-ppa так что твой высер ни о чём. У Appimage Криты есть пара минусов - не создаёт ярлык и порой игнорит локализацию. И если тебя пугает большое число зависимостей - купи винт побольше......40 гигабайт :)

P.S. при установке в KDE естественно. Для других DE не вижу проблемы качнуть KF5 и держать его в системе. Тут вон Flatpak предлагает целые рантаймы тянуть, весом от 100 мегабайт.

И кстати - это в каком дистре у тебя Krita 3? В Debian 2.8, в Ubuntu 2.9 и 3.0.1 в SNAP

купи винт побольше......40 гигабайт :)

Для других DE не вижу проблемы качнуть KF5 и держать его в системе.

Проблема не в том, что KDE-зависимости занимают место. Проблема в том, что KDE-зависимости изгаживают систему:

http://imgur.com/VqlGohX

Snap победит потому что Ubuntu.

Зависимости не нужны.

Захламление системы не нужно.

Люди хотят использовать софт любой версии на любой операционке просто перетащив директорию с файлами или подключив внешний диск.

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

необходимость регистрации в Ubuntu One для установки даже просто скаченного snap-пакета

Был баг, его закрыли. Регистрация не нужна, аккаунт не нужен.

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

Лол, а вес самого appimage вы не хотите посчитать?

Appimage, в отличие от snap и flatpak — самостоятельный ELF-файл. Для запуска Appimage-приложений не требуется установка какой-либо программы, а можно сразу запускать. Такое портабельное приложение, которое не предназначено для установки привычным образом. А Snap и Flatpak предназначены для установки.

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

А это можно сделать как-то без демона?

Appimage, конечно. Остальное — overcomplicated bloatware, требующее каких-то демонов, установок и прочее-прочее. AppImage запустится где угодно (достаточно FUSE и поддержки SquashFS в ядре). Остальные два уродца требуют установленного рантайма, да ещё и демонов запущенных. К тому же код Flatpak и Snap очень сложен, а AppImage понятен даже одному человеку. К тому же для безопасности Snap и Flatpak являют свои велосипеды, прибитые гвоздями, а с AppImage можно юзать firejail, или не юзать firejail вообще, или юзать любой другой инструмент для сэндбоксинга, который делает только это, но делает хорошо.

Это по поводу «лучше».

А «перспективнее», конечно же, Snap. Самое говно всегда побеждает.

41 пакет весом чуть больше 200 Mb против одного файла весом 76 Mb

Не качай левые сборки. Левый deb (вспомни шум с PPA на ланчпаде) тоже может интересного натворить. Такой же левый deb от васяна на сайте вована - аналогично. AppImage = Runner + Squash-образ, распаковывай, просматривай при помощи strace/gdb/дизассемблера - как любую бинарную дистрибуцию. Или запускай в песочнице.

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

Мне, как дистрибутору, просто нет времени и желания создавать пакеты для каждой версии дистрибутива. Бизнес не готов тратить деньги на то, что можно не делать и сделать малой кровью. Поэтому: Docker + образ на основе CentOS6 + нужный дополнительный свежий софт и свежий компилятор, в полученном образе (создаётся один раз и на долго, хорошая воспроизводимость) собирается целевой софт, при помощи скрипта, ldd и patchelf формируется бандл с нужными либами и после чего генерируется AppImage, который практически гарантированно запустится на всех glibc-совместимых системах (а может даже на каком-нить AlpineLinux тоже).

Ну... вообще для AppImage можно тоже запустить демон, как миниумум по дефолту он смотрит в ~/bin и ~/Downloads и сканирует на предмет появления новых AppImage пакетов, после чего регистрирует их у пользователя: так что через меню можно достучаться к нему (XDG).

От себя: его ещё и создавать проще. Была бы ещё серебряная пуля для создания AppDir...

Appimage, конечно.

Согласен полностью. Уже заагитировал OpenOrienteering Mapper добавить билды в формате AppImage (попутно отговорив от планов на Snap/Flatpak)

Позвал @probonopd... — https://github.com/OpenOrienteering/mapper/issues/894#issuecomment-311632026

... и он пришел — https://github.com/OpenOrienteering/mapper/pull/898

вообще для AppImage можно тоже запустить демон

Я в курсе. Но он опционален (чисто для любителей «рабочего стола» и «меню приложений»), AppImage спокойно можно использовать без него (что я успешно и делаю), в отличие от Snap и Flatpak, где без него нельзя.

От себя: его ещё и создавать проще. Была бы ещё серебряная пуля для создания AppDir...

https://github.com/OpenOrienteering/superbuild

Спасибо, скоро второе приложение пакетировать, погляжу.

Стоп, а при чём тут список зависимостей? Я про то, что бы сканировать бинарь и собирать необходимые библиотеки в локальный бандл. Пока мне хватает linuxdeployqt + немного рукоприкладства.

А само воспроизводимое окружение сделал при помощи докера и правил для сборки. Я не обмазывался cmake, поэтому шаги по отстройке - простые шелл-скрипты (по скрипту на шаг, что бы использовать кеширование докера на этапе первоначального создания образа - продолжать с зафейлившегося шага). Почему докер - что бы поднять, по сути, chroot со старой системой, со старыми системными библиотеками, но что бы не было возможности случайно его загаживать и пользоваться от обычного пользователя

Я даже не хочу говорить, до какой степени это всё не нужно. У меня не установлено ни одного snap пакета, при этом snapd – крупнейший потребитель памяти и процессора в свежеустановленной системе.

при этом snapd – крупнейший потребитель памяти и процессора в свежеустановленной системе.

У AppImage подобных проблем нет.

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

Имхо, будущее за flatpak'ом.

AppImage здесь не конкурент, т.к. не даёт никакой изоляции. М.б. appimage + firejail, но у последнего проблемы.

Snap - дырявое говно, приложение в котором может прописаться в автозагрузку. Да и завязан на apparmor, т.е. в половине дистров не даёт никакой изоляции.

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

В общем с нетерпением ждём новостей от космонавта о выпиливании ещё одной своей поделки.

Мне больше Appimage понравился за его простоту. Просто берёт и работает без необходимости что-то ещё ставить, удобно. Это перевешивает все его недостатки. С остальными форматами даже не приходилось связываться к счастью.

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

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

Если автор создает один AppImage, то этот AppImage будет работать почти на всех Linux-based 'зверях'.

AppImage идеальный для прикладного ПО, потому как исчезает зависимость от пакетного менеджера

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

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

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

Мейнтейнеры должны работать над самим дистром, а не над 'подгонкой' прикладного ПО.

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

Мейнтейнеры должны работать над самим дистром, а не над 'подгонкой' прикладного ПО.

Не согласен. Прикладное ПО должно быть правильно подогнано под конкретный дистрибутив, как минимум для обновления. Если всё перевести в Appimage - винда какая-то получится. Система зависимостей - крайне годная штука, но разрабов ПО лучше реально освободить от заботы о сборке под разные дистры. А так все довольны получается

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

Скачал новый AppImage - вот и все что нужно для обновления прикладного ПО

Если всё перевести в Appimage - винда какая-то получится.

Для десктопа и прикладного ПО как раз и нужен подход винды. AppImage делает легким для обычного пользователя использование Linux-based ОС на своем десктопе, а обновление путем скачивания нового AppImage дает возможность даже домохозяйкам легко работать с прикладными программами.