>> Это где вы 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" -- это не сильно смахивает на синонимы.