Доступен (https://github.com/flatpak/flatpak/releases/tag/0.10.1) релиз инструментария Flatpak 0.10.1 (http://flatpak.org/), в рамках которого развивается система для сборки самодостаточных пакетов, которые не привязаны к конкретным дистрибутивам Linux и выполняются в специальном контейнере, изолирующем приложение от остальной системы. Поддержка выполнения Flatpak-пакетов обеспечена для Arch Linux, CentOS (https://copr.fedorainfracloud.org/coprs/amigadave/flatpak-epel7/), Debian, Fedora, Gentoo, Mageia и Ubuntu. Пакеты с Flatpak включены в репозиторий Fedora и поддерживаются в штатной программе управления приложениями GNOME.
Ключевое отличие Flatpak от Snap заключается в том, что Snap использует компоненты окружения основной системы и изоляцию на основе фильтрации системных вызовов, в то время как Flatpak создаёт отдельный от системы контейнер и оперирует крупными runtime-наборами, предоставляя в качестве зависимостей не пакеты, а типовые системные окружения (например, все библиотеки, необходимые для работы программ GNOME или KDE). С особенностями Flatpak можно познакомиться в тексте анонса (https://www.opennet.ru/opennews/art.shtml?num=44640) первого выпуска.
В новом выпуске:
- Новая команда "flatpak remote-info (https://github.com/flatpak/flatpak/blob/b3cb71222bbd371175f2...)", отображающая информацию о приложениях или runtime-наборах во внешнем репозитории. Указанная вместе с командой опция "--log" позволяет просмотреть историю изменений, а также в комбинации с "flatpak upate --commit=XYZ" может применяться для отката на прошлую версию;- Новая команда "flatpak search", предназначенная для поиска в метаданных Appstream, собранных со всех подключенных репозиториев;
- Команда "flatpak update" теперь обновляет метаданные Appstream для всех внешних репозиториев;- Разрешена автоматическая установка GTK-тем, соответствующих активной теме оформления;
- Добавлена поддержка систем, в которых /etc/resolv.conf является символической ссылкой на файл внутри /usr;
- Обеспечена работа команды "flatpak remote-add" под непривилегированным пользователем при пустом каталоге /var/lib/flatpak , что позволяет использовать flatpak в окружениях не сохраняющих своё состояния между перезапусками;
- Добавлена опция "flatpak build --log-session/system-bus", аналогичная похожей операции во "flatpak run";- Добавлена опция "flatpak build --readonly", позволяющая использовать целевой каталог (/app) в режиме только для чтения;
- Добавлена, но пока не включена по умолчанию, поддержка репозиториев OCI (Open Container Initiative (https://www.opencontainers.org/)).
URL: https://github.com/flatpak/flatpak/releases/tag/0.10.1
Новость: https://www.opennet.ru/opennews/art.shtml?num=47624
Пробовал на gentoo стим в из него поднять -- не поднялось. Наверное ему systemг или пшшшадиа нужны.
Я бы сказал OpenRC и отсутствие JACK/PA/PW ему мешает.Я ничего против OpenRC не имею, по части иногда его даже поддерживаю.
> Я бы сказал OpenRC и отсутствие JACK/PA/PW ему мешает.Отсутствие пульсы и джека стиму не помеха: он прекрасно работает через обычную альсу.
OpenRC ему помешать не может даже в теории.
> Отсутствие пульсы и джека стиму не помеха: он прекрасно работает через обычную альсу.
> OpenRC ему помешать не может даже в теории.Я имел ввиду пользователю мешает работа этих приложений. Либо у него руки кривые.
Offtopic: Пока сообщение отправить не могу, занят к сожалению. Но отправлю сразу же по возможности.
>> Отсутствие пульсы и джека стиму не помеха: он прекрасно работает через обычную альсу.
>> OpenRC ему помешать не может даже в теории.
> Я имел ввиду пользователю мешает работа этих приложений.Антон, ну вряд ли работа OpenRC мешает запуску Steam. :)
Между прочим, судя по описанию, это должна быть не такая уж плохая вещь.
# Depends on: docbook-xsl gnupg json-glib libseccomp ostree xorg-libxau
./configure --prefix=/usr --libexecdir=/usr/lib/flatpak --sysconfdir=/etc --localstatedir=/var --disable-gtk-doc --disable-nls --disable-system-helper --with-priv-mode=setuid
Ой, новые зависимости добавились.
# Depends on: appstream-glib docbook-xsl gnupg libseccomp ostree
Wine поставить возможно? Не нашел.
Appimage уже захватил это поприще. И это хорошо. Добро победило.
Appimage не умеет в монтирование окромя /tmp, а оно обычно в tmpfs.
https://github.com/AppImage/AppImageKit/wiki/Similar-projects
добром эти кривые портянки на баше может назвать только человек ни разу этим не пользовавшийся
AppImage сделан для другого. AppImage — просто портативная программа, которую не нужно и нельзя установить. В AppImage не предусмотрен механизм обновления в виде репозиториев (но программа может содержать команды сборки внутри файла).Flatpak же предоставляет собственный базовый образ, на основе которого можно делать контейнеры с нужной программой, которые нужно устанавливать в систему. Обновляется через собственные репозитории.
Недавно запустили AppImageHub (наподобие Repology, но для AppImage) - https://appimage.github.io/
Не понимаю и не одобряю. Память жрёт, место на диске жрёт, обновления из системы не подхватывает, ад зависимостей порождает. Пусть идут на %¥№ со своими контейнерами, а я продолжу пользоваться пакетным менеджером.
Сравни цену 1 Гб жёсткого диска и стоимость человеко-часов работы 100+ мантейнеров на опакечивание одной и той же программы в 100+ дистрибутивах. А кол-во программ растёт и будет расти по мере популяризации линукса. Ограниченность человеческого ресурса и толкает тех.прогресс в сторону универсальных для всех дистрибутивов приложений-контейнеров независимо от твоего одобрямс.
> Сравни цену 1 Гб жёсткого диска и стоимость человеко-часов работы 100+ мантейнеров на опакечивание одной и той же программы в 100+ дистрибутивахФу, какой вы лживый. Вы наверное хотели сказать 1 Гб жёсткого диска на _каждое_ приложение у _каждого_ пользователя + драгоценное время авторов софта которым придётся разбираться с этими недопакетами + миллионы убытков из-за уязвимостей в забандленных зависимостях которые авторы не в силах мониторить и своевременно обновлять. А нативные пакеты будут вне зависимости от flatpak и вашей к ним рьяной любви, просто потому что большинство людей всё-таки думает головой, а не ведётся на рекламку форматика пригодного исключительно для распространения дырявой проприетарщины. И 100+ разных форматов пакетов вы не насчитаете, тут вы тоже мерзко и бессовестно соврали, Вова.
Автор сделает 1 флатпак для всех дистрибутивов, а потом будет его обновлять через OSTree, в результате чего флатпаки во всех дистрибутивах будут обновляться. Таким образом, контейнер-приложение Flatpak сопровождается автором программы, а не мантейнерами дистрибутивов. Такая модель разработки позволяет экономить человеческие ресурсы в дистрибутивах, а мантейнеры сосредоточатся на качестве базовой системы.Об уязвимостях не понял, т.к. контейнеры с приложениями обновляются. Обновляются и контейнеры с рантаймами в пределах минорной версии. Или вы считаете, что авторы программ меньше заинтересованы в обновлениях безопасности и исправлении багов в своих приложениях, чем многочисленные мантейнеры дистрибутивов? Или, может быть, вы имеете ввиду уязвимости в приложениях? Но они же, в конце концов, находятся в контейнерах, которые изолируют их от системы!
> Автор сделает 1 флатпак для всех дистрибутивов, а потом будет его обновлять
> через OSTree, в результате чего флатпаки во всех дистрибутивах будут обновляться.
> Таким образом, контейнер-приложение Flatpak сопровождается автором программы, а не мантейнерами
> дистрибутивов. Такая модель разработки позволяет экономить человеческие ресурсы в дистрибутивах,
> а мантейнеры сосредоточатся на качестве базовой системы.Необязательно что приложение будет сопровождаться именно автором программы. Оно вполне может лежать на каком-нибудь Flathub, и сопровождаться тамошними.
Но разница всё равно будет ощутимой. Ибо собирать надо один раз, а подойдёт под все дистрибутивы.
> И 100+ разных форматов пакетов вы не насчитаете, тут вы тоже мерзко и бессовестно соврали, Вова.Вы имеете ввиду форматы пакетов контейнеров? Я говорю только про формат Flatpak, который, с моей точки зрения, наиболее перспективный и имеет преимущества перед другими для установки в десктоп-ОС. Хотя, если взять, к примеру, контейнеры Docker или AppImage, то у них своя ниша. Их предпочитают в серверных системах, т.к. у них выше степень изоляции, но туда пихают и больше системных библиотек и библиотек раб.окружения.
Кстати говоря, модификаций форматов rpm тоже не мало, если ни сказать, что большинство дистрибутивов имеют свою версию rpm со своими особенностями, в результате чего чаще всего не возможно rpm-пакеты от одного дистрибутива установить в другой.
И самое главное, у каждого дистрибутива имеется в наличии ограниченное количество мантейнеров, которые и так перегружены работой. Наращивать кол-во программ в репозитории при ограниченном кол-ве людей возможно только за счёт автоматизации и усложнения сборочной среды. Спроси, чем занимались много лет разработчики из Альта и Росы. Они совершенствовали и усложняли инфраструктуру сборки, наращивали автоматизацию только ради того, чтобы временно преодолеть разрыв между экспоненциальным ростом приложений в репо и ограниченным кол-вом мантейнеров.
> в 100+ дистрибутивахХм… Arch, Debian, Fedora, Gentoo, openSUSE, Slackware — добей список дистрибутивов, под которые действительно есть смысл что-то опакечивать, хотя бы до десятка.
https://distrowatch.com/
Читать умеешь? *Те, для которых есть смысл что-то опакечивать.* То есть исключая клоны перечисленных мной, для которых трудозатраты нулевые, и те, у которых пользователей меньше, чем разработчиков. Из первой двадцадки DW под первый критерий подходят два дистрибутива — Solux и PCLinuxOS, вот только живых их пользователей я что-то не видел.
Для справки: положение в рейтинге крайне слабо коррелирует с числом реальных пользователей.
Вот именно -- ты из своего окна живых пользователей не видел. Это не значит, что у этих дистрибутивов нет пользователей, хотя бы за рубежом. И уж, конечно, там есть мантейнеры, которые опакечивают всё те же самые программы, которые имеются в репах десятков других дистрибутивах.Технология Flatpak появилась, чтобы из цепочки "автор - мантейнер дистрибутива - пользователь", убрать мантейнера, чтобы быстро доставлять до пользователя свежие версии софта прямо от автора. Чтобы оперативно обновлять софт и закрывать в нём баги. Чтобы исключить сизифов труд мантейнеров по встраиванию программ в дистрибутивы. Чтобы обеспечить безопасность выполнения программ в ОС за счёт контейнеров и атомарных обновлений файлов в них.
Пользователи Дебиана, например, сидят на протухшем софте из-за консервативной политики дистрибутива. А флатпаки дают им возможность устанавливать в свою систему самый свежий софт.
> Вот именно -- ты из своего окна живых пользователей не видел. Это не значит, что у этих дистрибутивов нет пользователей, хотя бы за рубежом. И уж, конечно, там есть мантейнеры, которые опакечивают всё те же самые программы, которые имеются в репах десятков других дистрибутивах.Хотят — пускай опакечивают. Для себя и того парня. Разработчику же всех потенциальных пользователей в любом случае не охватить, а 0,001% от них потерять ваще не жалко.
> Технология Flatpak появилась, чтобы из цепочки "автор - мантейнер дистрибутива - пользователь", убрать мантейнера, чтобы быстро доставлять до пользователя свежие версии софта прямо от автора.
И полностью лишить этот процесс какого бы то ни было контроля. Наличие в цепочке квалифицированного майнтейнера, руководствующегося политиками дистрибутива, даёт хотя бы минимальные гарантии, что Васян не пропихнёт свой гoвнoкод в репы.
> Пользователи Дебиана, например, сидят на протухшем софте из-за консервативной политики дистрибутива.
Заметь, с обновлениями безопасности, и не ломающемся из-за очередного внезапного мегаапдейта.
> А флатпаки дают им возможность устанавливать в свою систему самый свежий софт.
На то есть бекпорты. Но откуда тебе о них знать, ты же про дебиан только cpaчики на форумах читал.
Если хочешь, сиди на опакеченном софте. Думаю, дистрибутивы ещё долго будут собирать популярные программы. А контейнеры-приложения будут существовать параллельно.Думаю, что со временем разработчики софта возьмут эту технологию на вооружение. Потому что выгодно поддерживать 1 пакет для всех линуксов, нежели делать N сборок под несколько популярных линуксов.
Лично для меня лучше использовать флатпаки, если они есть. Они стоят в стороне от системы и не загаживают систему своими библиотеками, система остаётся чистой и быстро обновляется. Пока я не вижу существенных недостатков, чтобы не использовать эту технологию.
> Думаю, что со временем разработчики софта возьмут эту технологию на вооружение. Потому что выгодно поддерживать 1 пакет для всех линуксов, нежели делать N сборок под несколько популярных линуксов.Я бы, может, и поверил, да вот только проходили мы это неоднократно. 0install, listaller, autopackage и прочие — все они обещали ровно то же самое, но оказались выкинуты на помойку.
Это инсталяторы, которые в той или иной мере пытались повторить принцип инсталяторов Windows. Они устанавливают приложение в Linux (и возможно в др. ОС) также, как это делается в Windows. То есть, просто создают каталог приложения и засовывают туда бинарники и файлы библиотек программы.Их применение, скорее всего, ограничено проприетарным софтом. Типа установить статически слинкованную прогу в каталог /opt.
Эти инсталяторы не решают следующие проблемы:
-- проблему изоляции приложения от системы, а следовательно, безопасности ОС;
-- проблему периодического обновления приложения;
-- проблему совместимости устанавливаемого приложения с текущей системой (проприетарщики просто оговаривают, в какие версии ОС можно устанавливать их прлгу);
-- проблему работоспособности приложения после обновления системы;
-- эти инсталяторы даже не отслеживают зависимости и соответствия приложения используемым в системе библиотекам.В итоге эти инсталлеры плодят файл-помойки в системе, а при обновлении системы на новую версию нет никаких гарантий, что установленная таким образом программа будет работать.
Не удивительно, что эти инсталлеры в экосистеме Linux не взлетели.
>-- проблему изоляции приложения от системы, а следовательно, безопасности ОС;Купи себе отдельный комп под каждую программку. Ну или виртуальный комп. Потому что под линукс нет ни одной песочницы, решающей проблемы безопасности. Проблемы безопасности под линуксом решаются запуском виртуалки, в которой своя система.
>проблему периодического обновления приложения;
решает пакетный менеджер.
>-- проблему совместимости устанавливаемого приложения с текущей системой (проприетарщики просто оговаривают, в какие версии ОС можно устанавливать их прлгу);
контейнеры не решают. Я не могу поставить новые проги на старое ядро даже в контейнерке. Тут только виртуалка.
> -- проблему работоспособности приложения после обновления системы;
пакетный менеджер.
>-- эти инсталяторы даже не отслеживают зависимости и соответствия приложения используемым в системе библиотекам.
пакетный менеджер.
Зачем ему рут права при установке приложений? По мне так appimage лучше. Там не нужно ничего дополнительно устанавливать.
Самодостаточная директория /opt смотрит на это всё свысока...
> Самодостаточная директория /opt смотрит на это всё свысока...Одна помойка смотрит на другую помойку свысока.
Лучше вообще без помойки, но если уж нет возможности утилизировать весь мусор, есть смысл держать его в контейнере, чтоб не вонял.
Там программы статически слинкованы с библиотеками. Старые версии библиотек, которые не обновляются. Потенциальные уязвимости. Отсутствие изоляции от системы. Программа в /opt может не запуститься после обновления на новую версию дистрибутива (например, с новой версией KDE).
Ему все еще нужен root для установки приложений, если да, то нафиг оно нужно?
Ему все еще нужно скармливать репозитории приложений(для каждого софт свой?), тогда нафиг оно нужно?
Выглядит как не нужно. Все эти рантаймы - изобрели очередной пакетник. АппИмаге действительно удобней, но, технически, АппИмаге странный... Переменными окружения ссылаться на монтируемый директорию... Патч, лд_либрари_патч, выглядит как костыли, если приложение не учитывает переменные окружения(например длопен со статическим путем - то его никак не заставить красиво жрать нужную библиотеку) Вот если был бы некий оверлей на основной корень, в котором конфигом указывается, какие директории доступны физически, а какие накрывать - было бы интересней, ИМХО
Ну и сколько весит флатпак КДЕ5?
Купи весы.
В Федоре 27 у меня 2 каталога:
/var/lib/flatpak/runtime/org.kde.Platform/x86_64/5.9
1.0 G
/var/lib/flatpak/runtime/org.kde.Platform.Locale/x86_64/5.9
757.5 M
Меня забавляют местные, топящие за AppImage. AppImage и Flatpak это разные инструменты для разных задач.AppImage - это как статически слинкованный .exe с приложением. Пихай куда хочешь, копируй куда хочешь, запускай откуда хочешь. Требуется только базовая система. Однако никакой тебе интеграции в систему, только костылюшки.
Flatpak же подразумевает поставку дистрибутивами по умолчанию вместе с системой. Установка подразумевается из репозитория в интернетах. OSTree решает проблему дедубликации файлов. Контейнерная изоляция лишает привязанности к дистрибутиву. Тем самым можно поставлять только базовую систему (Atomic Core, если хотите), а приложения уже ставить в виде Flatpak, заменяя пакетную систему. (см. Endless OS)
> Меня забавляют местные, топящие за AppImage. AppImage и Flatpak это разные инструменты
> для разных задач.
> AppImage - это как статически слинкованный .exe с приложением. Пихай куда хочешь,
> копируй куда хочешь, запускай откуда хочешь. Требуется только базовая система. Однако
> никакой тебе интеграции в систему, только костылюшки.
> Flatpak же подразумевает поставку дистрибутивами по умолчанию вместе с системой. Установка
> подразумевается из репозитория в интернетах. OSTree решает проблему дедубликации файлов.
> Контейнерная изоляция лишает привязанности к дистрибутиву. Тем самым можно поставлять
> только базовую систему (Atomic Core, если хотите), а приложения уже ставить
> в виде Flatpak, заменяя пакетную систему. (см. Endless OS)тогда накой нужон тот флатпак, если есть аппимаге, который самодостаточен, и людские пакеты, которые интегрированы в систему?
> тогда накой нужон тот флатпак, если есть аппимаге, который самодостаточен, и людские
> пакеты, которые интегрированы в систему?Потому что он создавался чтобы стать чем-то посередине. Универсальной пакетной системой для установки
десктопных приложений.А не метаться между статическими образами бандлами всего чего только можно, без дедубликации и намёка на хоть какое-то обновление компонентов в случае Security Issues.
Или зоопарком пакетных менеджеров и дистрибутивов, каждый из которых имеет свой персональный Dependency Hell и принципиально свои, родные спеки (или чего там у вас в этом dpkg или арчепакетах) не совместимые нисчем.
Собрал один раз, выложил в OSTree, и готово. Доступно сразу для всех зоопарков. Обновления дельтами (качаются только изменённые файлы). И не надо думать об обновлениях тех компонентов, что поставляются в Runtime, ибо они параллельно обновляются.
> зоопарком пакетных менеджеров и дистрибутивов, каждый из которых имеет свой персональный Dependency HellЭто где вы Dependency Hell в дистрибутивах нашли?
> Собрал один раз, выложил в OSTree, и готово.
То есть, если я правильно вас понял, у вас для каждого приложения есть контейнер с базовой системой, и контейнер с файлами приложения, и в рантайме оно объединяется в один большой контейнер?
"Не хотим портировать нашу программу под другую систему, давайте лучше заставим человека иметь нашу систему в chroot-окружении (пардон, в контейнере)".
Вы же таким образом сохраняете зависимость от базовой системы, и по факту паразитируете на уже сложившейся инфраструктуре дистрибутивов. Если базовый образ обновится как-то неудачно, какие-то контейнеры с приложениями могут запросто полететь к чёрту на куличики. А какой толк в этих ваих контейнерах, если приложение в них может не запуститься? Чем вы тогда отличаетесь от обычных дистрибутивов, и нафига вообще нужны?
> А не метаться между статическими образами бандлами всего чего только можно, без
> дедубликации и намёка на хоть какое-то обновление компонентов в случае Security
> Issues.AppImage, коли он действительно "omnia mea mecum porto", выглядит куда более разумным: приложение в его контейнере гарантированно всегда запустится.
> Потому что он создавался чтобы стать чем-то посередине. Универсальной пакетной системой
> для установки десктопных приложений.И предлагаете нам потенциально нестабильную систему? Ну спасибо.
Проблема контейнеров в том, что взаимодействие между ними -- штука чертовски сложная, и никто не может окинуть её взглядом. Мы и взаимодействие программ безо вяских контейнеров зачастую окинуть взглядом не можем, а вы ещё и контейнеры сверху нацепили. Нет, упростить жизнь вы так не сможете.
На самом деле, всё это хайп. Контейнеры сейчас -- слово популярное. Мы и раньше загружали другие системы в chroot-окружения (и до сих пор это делаем), но никому не приходило в голову поставить это дело на поток: потому что это жизнь проще не делает. Все эти популистские сказки про Dependency Hell оставьте, право слово. Где и когда вы его видели, а? Контейнеры -- это не решение. Вот NixOS -- это, возможно, решение. А контейнеры добавляют точно такой же "аля пакетный" слой абстракции, только ещё чуточку повыше.
> Это где вы Dependency Hell в дистрибутивах нашли?В каждом отдельном дистрибутиве разные версии библиотек, разные версии оболочек рабочих столов, разные версии иксов в конце концов, Mesa, systemd, ядра, драйверов видеокарт.
Полезешь в CentOS, Debian stable - там всё ожидаемо стабильно, как экскременты мамонта. Устаревшие фичи. Старые баги.
Полезешь в Fedora, ArchLinux - там наоборот всё новое. Новый GNOME. Новые фичи. Новые баги.А вот предположим, есть среднестатистический Васян. Он макака на C++, и пишет всякую Freeware для Шиндовсов. И вот захотелось ему попробовать поразрабатывать под Linux. Подробности по изучению и инструментам опустим.
И у него рано или поздно встанет вопрос: А на какой базе это собирать? В свежей бубунте/Fedora?
С другой же стороны есть ещё целый лагерь любителей обмазываться несвежим LTS и играть в самолётики, которые презирают свежий софт, ибо вечно видят в нём мифические критические баги, из-за которых "невозможно пользоваться". + корпоративные пользователи, где админы руководствуются немного другими соображениями, но похожими.
Кого ему выбрать? Упускать возможность адаптировать свой софт под новые тулкиты или получать в лицо кучу помидоров/экскрементов за то, что LTS не поддерживаются?
> То есть, если я правильно вас понял, у вас для каждого приложения
> есть контейнер с базовой системой, и контейнер с файлами приложения, и
> в рантайме оно объединяется в один большой контейнер?Нет. Необходимые файлы скачиваются в OSTree репозиторий, и затем из хардлинков по метаданным ставятся на место нужные файлы, и нужные директории. За счёт чего получается и дедубликация. За подробностями в Google.
Ну или сюда: https://blogs.gnome.org/alexl/2017/10/02/on-application-size.../
> "Не хотим портировать нашу программу под другую систему, давайте лучше заставим человека
> иметь нашу систему в chroot-окружении (пардон, в контейнере)".Вот кто действительно тащит целую тучу говена, так это AppImage. Они могут с собой даже целый KDE 5 Frameworks тащить, в единственном экземпляре для единственного же приложения в образе, которое его использует. (привет, Krita)
Тем временем, во Flatpak для этого существуют runtime'ы. Причём есть даже особенность. Если скачать сразу и freedesktop, и GNOME runtime - одинаковые файлы скачиваться не будут.
> Вы же таким образом сохраняете зависимость от базовой системы, и по факту
> паразитируете на уже сложившейся инфраструктуре дистрибутивов.Зависимость сохраняется только от runtime. А его даже не обязательно заново собирать целиком каждый раз. В Fedora уже есть сборка flatpak контейнеров из уже готовых rpm.
> Если базовый образ обновится
> как-то неудачно, какие-то контейнеры с приложениями могут запросто полететь к чёрту
> на куличики. А какой толк в этих ваих контейнерах, если приложение
> в них может не запуститься? Чем вы тогда отличаетесь от обычных
> дистрибутивов, и нафига вообще нужны?Если GNOME runtime сломают, или любой другой, можно просто откатиться на предыдущий коммит в OSTree.
> AppImage, коли он действительно "omnia mea mecum porto", выглядит куда более разумным:
> приложение в его контейнере гарантированно всегда запустится.Но цена этому высока.
Я потому и говорю, что это разные инструменты под разные задачи.
Если говорить аналогами, то AppImage - это тот же статический .exe в Windows, который тащит всё с собой. Можно таскать хоть на флешке, хоть по сети запускать, ибо файл же единЪ, абсолютно portable. В светлом будущем, когда все компьютеры будут на Linux, можно будет использовать вместо portable программ для Windows.
Тем временем Flatpak перерос в аналог UWP, только с поддержкой множества репозиториев и анально не ограниченный в плане установки из файла.
Похожие, но в тоже время разные вещи.
> А вот предположим, есть среднестатистический Васян. Он макака на C++, и пишет всякую Freeware для Шиндовсов. И вот захотелось ему попробовать поразрабатывать под Linux.А, так вот для кого это придумали? Ну пускай себе собирает, нам только удобнее обходить стороной его пoделия будет.
>> А вот предположим, есть среднестатистический Васян. Он макака на C++, и пишет всякую Freeware для Шиндовсов. И вот захотелось ему попробовать поразрабатывать под Linux.
> А, так вот для кого это придумали? Ну пускай себе собирает, нам
> только удобнее обходить стороной его пoделия будет.С Flatpak будет не важно, собирает ли Васян под 3.26 GNOME, или под 3.22. Ибо можно без проблем тупо установить 2 рантайма.
А ещё стоит вспомнить, что как-бэ, каждый разрабочик, который сейчас вкладывается в OpenSource, мог когда-то быть этим Васяном. Просто он познал дзен и проникся. Так что зря ты так с ним.
> тупо установить
> тупоДа, это для тебя.
> А ещё стоит вспомнить, что как-бэ, каждый разрабочик, который сейчас вкладывается в
> OpenSource, мог когда-то быть этим Васяном. Просто он познал дзен и
> проникся. Так что зря ты так с ним.Если правда познал, зачем бы ему сабж?
> Тем временем Flatpak перерос в аналог UWP, только с поддержкой множества репозиториев и анально не ограниченный в плане установки из файла.У UWP другая задача по сравнению с Flatpak.
Flatpak объединяет зоопарк дистрибутивов.
А UWP объединяет зоопарк устройств.Суть UWP в том что у вас есть приложение и оно будет работать на Xbox One, PC, W10M, Surface, Hololens, Surface Hub. На которых стоит Windows 10.
>> Тем временем Flatpak перерос в аналог UWP, только с поддержкой множества репозиториев и анально не ограниченный в плане установки из файла.
> У UWP другая задача по сравнению с Flatpak.
> Flatpak объединяет зоопарк дистрибутивов.
> А UWP объединяет зоопарк устройств.
> Суть UWP в том что у вас есть приложение и оно будет
> работать на Xbox One, PC, W10M, Surface, Hololens, Surface Hub. На
> которых стоит Windows 10.Замечание справедливое. Просто более близкого примера в голову не пришло.
>> Это где вы Dependency Hell в дистрибутивах нашли?
> В каждом отдельном дистрибутиве разные версии библиотек, разные версии оболочек рабочих
> столов, разные версии иксов в конце концов, Mesa, systemd, ядра, драйверов
> видеокарт.Разница в версиях библиотек между разными дистрибутивами -- это не dependency hell.
> Полезешь в CentOS, Debian stable - там всё ожидаемо стабильно, как экскременты
> мамонта. Устаревшие фичи. Старые баги.
> Полезешь в Fedora, ArchLinux - там наоборот всё новое. Новый GNOME. Новые
> фичи. Новые баги.
> А вот предположим, есть среднестатистический Васян. Он макака на C++, и пишет
> всякую Freeware для Шиндовсов. И вот захотелось ему попробовать поразрабатывать под
> Linux. Подробности по изучению и инструментам опустим.
> И у него рано или поздно встанет вопрос: А на какой базе это собирать? В свежей бубунте/Fedora?Для этого в принципе и был создан LSB. Но как показала практика, программы среднестатистических Васянов оказались настолько невостребованными, что LSB из Debian, например, недавно выпилили за ненадобностью. Серьёзным разработчикам легче всё своё таскать с собой. Если производитель хочет, чтобы его программа запустилась везде, то он просто доукомплектовывает архив своей программы соответствующими библиотеками. Steam наиболее явственно демонстрирует обывателю работоспособность данного подхода. Да и прочие поставщики серьёзных коробочных решений уже несколько десятилетий не брезгуют ставиться в /opt вместе со всем необходимым.
>> То есть, если я правильно вас понял, у вас для каждого приложения
>> есть контейнер с базовой системой, и контейнер с файлами приложения, и
>> в рантайме оно объединяется в один большой контейнер?
> Нет. Необходимые файлы скачиваются в OSTree репозиторий, и затем из хардлинков по
> метаданным ставятся на место нужные файлы, и нужные директории. За счёт
> чего получается и дедубликация. За подробностями в Google.Что значит нет? Я ведь то же самое сказал.
>> Если базовый образ обновится как-то неудачно, какие-то контейнеры с
>> приложениями могут запросто полететь к чёрту на куличики. А какой
>> толк в этих ваих контейнерах, если приложение в них может не
>> запуститься? Чем вы тогда отличаетесь от обычных дистрибутивов, и
>> нафига вообще нужны?
> Если GNOME runtime сломают, или любой другой, можно просто откатиться на предыдущий
> коммит в OSTree.Вы не всегда можете откатиться, потому что обновление базовой системы может содержать критичные исправления безопасности.
>> AppImage, коли он действительно "omnia mea mecum porto", выглядит куда более разумным:
>> приложение в его контейнере гарантированно всегда запустится.
> Но цена этому высока.Суть в том, что для бизнеса, равно как и для пользователя в подавляющем большинстве случаев первостепенную важность имеет стабильность работы, а стоимость никогда не была проблемой хотя бы по закону Мура. (Да и вообще, если бы стоимость играла какую-то роль, было бы у нас столь дикое засилье JVM-based приложений?). AppImage в этом плане удобнее тем, что является по факту калькой того решения, которое бизнес использовал на протяжении десятилетий. Использовал, использует и будет использовать.
AppImage говорит "просто запакуйте приложение и всё будет стопудово ок". Flatpak говорит "запакуйте приложение к базовой системе, следите за обновлениями базовой системы". Если базовую систему поставляете не вы, вы не можете быть уверены, что этот кто-то со стороны не сломает ваше приложение. Так что программы среднестатистического Васяна со временем с большой вероятностью подохнут, а бизнес либо будет поставлять свою базовую систему, что нивелирует плюсы Flatpak, либо воспользуется AppImage, как более простым и более надёжным инструментом.
> Я потому и говорю, что это разные инструменты под разные задачи.
> Если говорить аналогами, то AppImage - это тот же статический .exe в Windows, который тащит всё с собой."Статический" и "как в Windows" -- это не сильно смахивает на синонимы.
>зоопарком пакетных менеджеров и дистрибутивов, каждый из которых имеет свой персональный Dependency Hell и принципиально свои, родные спеки (или чего там у вас в этом dpkg или арчепакетах) не совместимые нисчем.выдумка поналезшей изо всех дыр вантузошвали, у которой отродясь пакетного менеджера не было, а тут оказалось, что пакетов и окружений из одних и тех же пакетов много разных, а билдсервиса они из своего вантузомирка вынести не могут.
>Собрал один раз, выложил в OSTree, и готово. Доступно сразу для всех зоопарков. Обновления дельтами (качаются только изменённые файлы). И не надо думать об обновлениях тех компонентов, что поставляются в Runtime, ибо они параллельно обновляются.
опять вантузомрii о щястьи сетуп ехе, далее, далее, и воображаемых обновлениях свежекраденного фотошопа и автокада, с ручным качанием очередного визуалстудия рунтайма 2018.
Очевидно что в дистрибутивах очень хорошие и развитые пакетные менеджеры. До них любым поделкам еще раком ползти и ползти. Но есть современные направления развития: унификация, контейнеры, дедубликация. Вот эти поделки и пытаются взлететь на том, что мамонты еще долго будут отдуплятся.
> Очевидно что в дистрибутивах очень хорошие и развитые пакетные менеджеры. До них
> любым поделкам еще раком ползти и ползти. Но есть современные направления
> развития: унификация, контейнеры, дедубликация. Вот эти поделки и пытаются взлететь на
> том, что мамонты еще долго будут отдуплятся.Я сам, бывало, фанател по пакетным менеджерам. И искренне поливал какащками винду за их отсуствие.
Затем я увидел презентацию по концепции Fedora Atomic Workstation. Заинтересовался, обчитался, обмазался, а затем познал истину. Что это и есть будущее.
В пакетных менеджерах нет ничего плохого. Просто они этим современным направлениям не соответствуют. Собирать систему по кирпичикам, где нет ничего лишнего, только необходимое - в этом нет сейчас необходимости. Сейчас даже телефоны минимум с 32-мя гигабайтами встроенной флеш памяти. А в среднем это 64 гигабайта. Если какой-то софт притащит с собой 2-3 лишних библиотеки, которых не было в runtime, и будет использовать их вместо общесистемных из /usr, это не беда. Главное чтобы 2 одинаковых файла не скачивались 2 раза.
Проблема в том, что каждую прогу в каждом дистрибутиве опакечивают мантейнеры под особенности данного дистрибутива. Это сизифов труд. Кол-во программ под линукс растёт и будет расти в геометрической прогрессии. Зачем в 100+ дистрибутивах делать одну и ту же рутинную работу, чтобы бесконечно пакетить одну и ту же программу и её новые версии? Где взять столько мантейнеров / человеко-часов / людских ресурсов, которые ограничены?
OSTree - это красношапочные инженеры увидели NixOS, ничего не поняли и решили сделать по-своему, по-крестьянски.
Родина дала им NixOS со воспроизводимыми билдами и дедупликацией - не хотим, хотим как в венде.
В винде поставляется инсталятор, который раскладывает файлики по папкам и прописывает нужные ключики программы в реестре.А Flatpak поставляет готовый контейнер с предустановленной программой с одной-двумя зависимостями на рантайм(ы) (например, на библиотеки Gnome 3.24 и GTK, которые пакуются в отдельный контейнер). Несколько флатпаков с приложениями могут требовать один и тот же рантайм, что избавляет от дублирования библиотек.
Например, в моей системе сейчас установлены 11 флатпаков, которые зависят от 7 рантаймов:
# flatpak list
Ref Options
com.skype.Client/x86_64/alpha system,current
com.transmissionbt.Transmission/x86_64/stable system,current
nl.openoffice.bluefish/x86_64/stable system,current
org.audacityteam.Audacity/x86_64/stable system,current
org.gimp.GIMP/x86_64/stable system,current
org.gnome.Builder/x86_64/stable system,current
org.inkscape.Inkscape/x86_64/stable system,current
org.libreoffice.LibreOffice/x86_64/stable system,current
org.mypaint.MyPaint/x86_64/stable system,current
org.pitivi.Pitivi/x86_64/stable system,current
org.videolan.VLC/x86_64/stable system,current
org.freedesktop.Platform.Icontheme.Adwaita/x86_64/1.0 system,runtime
org.freedesktop.Platform.VAAPI.Intel/x86_64/1.6 system,runtime
org.freedesktop.Platform/x86_64/1.6 system,runtime
org.gnome.Platform/x86_64/3.24 system,runtime
org.gnome.Platform/x86_64/3.26 system,runtime
org.gnome.Sdk/x86_64/3.26 system,runtime
org.kde.Platform/x86_64/5.9 system,runtime
> 11 флатпаков, которые зависят от 7
> рантаймовА я-то наивно полагал, что это сделано, чтобы экономить место за счёт рантаймов, то есть на кучу флатпаков один-два рантайма. Ну ок, только теперь окончательно перестал понимать смысл всего этого.
Некоторые флатпаки требуют, например, библиотек Gnome 3.24. Другие -- Gnome 3.26. Третьи -- Gnome 3.26 и Gnome SDK 3.26.Но почему они не запаковали Gnome.Platform 3.26 и Gnome.SDK 3.26 в один рантайм -- не знаю.
Экономия места на рантаймах заключается в том, что несколько флатпаков могут требовать один и тот же рантайм, например, Gnome 3.24. Поэтому Gnome.Platform 3.24 запаковали в отдельный контейнер, чтобы не паковать с каждым приложением.
В AppImage, к примеру, и приложение, и платформу, и SDK, и тему с иконками запаковали бы в один контейнер.
ребзя, я правильно разумею, что эти флатпаки огроменных размеров, если они все зависимости удовлетворяют?
Если упрощённо, флатпак -- это предустановленное приложение. Что-то типа статически скомпилированного LibreOffice, установленного в /opt/libreoffice.В отдельном контейнере поставляется рантайм (например, библиотеки Gnome 3.24), с которыми этот либреофис компилировался, чтобы не зависеть от текущей системы (а это может быть любой линукс с KDE или с другой версией Gnome)
С одной стороны вроде понятно зачем, и бяку всякую при необходимости, аля Скайп, не хочется ставить в систему, с другой - склоняюсь к тому, что всякий вредоносный зоопарк лучше запрятать в вирт машину.
> ребзя, я правильно разумею, что эти флатпаки огроменных размеров, если они все
> зависимости удовлетворяют?https://blogs.gnome.org/alexl/2017/10/02/on-application-size.../