Как устроен Flatpak?

Вот эти проблемы я и имею в виду, когда говорю что «переусложнен». С точки зрения админа и программиста все очень круто. Но как это адаптировать для пользователя?

Существующие ПМ позволяют это сделать, потратив на это досадное количество времени. Не работает способ «Тыц-тыц и в дымках», на который ты намекаешь противопоставляя флатпакосвалку и графические «аппсторы» супротив никса. Я тоже за удобные графические устанавливалки, но Синаптик и Памак -это лучшее, что случалось с миром линукса и, похоже, он прошёл мимо. Всем прдавай свалку из флатпаков, снапов, докеров, а устанавливать это надо с «аппстора». Бред сивой кобылы этот ваш мир. А подать мне другую реальность!

Когда же уже гугл запомнить, что я не робот?

Это ты, ChekPuk, или мне показалось?

Тебе слишком много кажется.

Каштан.

которым не нравится флатпак Которые считают, что подобному подходу не место в линуксе

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

Первое, это проблемы с зависимостями. В целом, при корректном использовании symver и soname разработчиками библиотек, и неиспользовании глобальных состояний, в ОС можно держать сколь угодно много разных версий одного и того же и в одном каталоге и в одном адресном пространстве. Если посмотреть на опыт того-же vmware, как одного из самых старых примеров дистрибуции сложной проприетарщины с большой завязкой на рантайм на линакс, проблема не столько в symver/soname, сколько в отсутствии необходимых версий библиотек в конкретно взятом дистрибутиве. В этом плане системы десктпной контейнеризации не решают никаких принципиальных проблем - с тем же успехом можно вести дополнительные deb/rpm/whatever репозитории с теми же самыми библиотеками. Системы десктопной контейнеризации в этом плане решают проблему методом упрощения (в плохом смысле этого слова) - вводят дополнительную сущность управления пакетами. Больше не нужно быть завязанными на конкретного вендора или конкретный формат пакетов, ведь у нас появился более другой, свой, общий формат. Такое положение вещей в значительной степени обуславливает негативное отношения к системам десктопной контейнеризации. По сути, у нас получается очередной дистрибутив поверх существующего. Т.е. если бы я хотел /этого/, я бы собрал какой-нибудь ostree дистрибутив, а не использовал debian/RH/whatever. И вместо прессинга на говноделов, мы фиксируем печальное состояние с качеством ПО костылями в виде контейнеризации.

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

1. Уязвимости в самом приложении
2. Скрытая злонамеренная функциональность самого приложения
3. Злонамеренная дистрибуция приложения.

Основная драма в том, что в десктопных ОС вообще, и в линаксе в частности, отсутствует концепция недоверия приложению. Вся система безопасности заточена на изоляцию пользователей, а все приложения коммуницируют примерно с одниковыми привелегиями с одним множеством объектов IPC. Самые простые примеры - доступ к конфигурации других приложений (через API или файловый доступ), доступ к буферу обмена, к клавиатурному вводу, десктопу (скриншоты, запись), звуковому менеджеру, парольному менеджеру итп. До определенной степени системы десктопной контейнеризации действительно могут решать эти проблемы. Например firejail мог запускать xpra для изоляции доступа к десктопу, во flatpak изобрели dbus proxy, который режет обращения к сервисам, которые не разрешены, во всех системах контейнеризации можно порезать доступ к FS. С другой стороны, т.к. приложения разрабатывались без учета изоляции, необходимы костыли разного рода, типа выборочного проброса ряда файлов из системы (например настройки шрифтов итп), IPC зачастую не обрезается (доступ к сервисам торчащим по TCP на localhost, доступ к приложениям с абстрактными unix сокетами), доступ к не-системным файлам находится в серой зоне (примонтированные устройства, доступ к хомяку итд). Особняком стоит вопрос временного предоставления привелегий. Например, если я использую Skype, мне нужно что бы он имел доступ к камере и микрофону. Но не всегда, а во вполне определенный момент. Аналогично запись экрана итд. В определенной степени движение в верном направлении присутствует - стараются родить desktop portals, возможно когда-то это заработает. На данный момент же первые попавшиеся приложения из репозитория flatpak по дефолту получают доступ к хомяку (финита ля комедия с этой вашей изоляцией), к secrets (аналогично) итп. В моем понимании правильно было бы поднять вопрос о разработке общего API для работы изолированных приложений, (тем более так или иначе к этому вопросу придут) и решать проблему с изоляцией ближе к естественному способу Linux - через изоляцию на уровне пользователей (т.е. примерно как в Android). Как и в случае с контейнеризацией, мы фиксируем текущее печальное положение дел костылями, вместо потуг решать проблемы (конечно нужно отметить что какое-то движение есть, но слишком неторопливое).

Ну и самое отвратительное, что так как фокус решения проблем смещён с причин на костыли (контейнеризация, изоляция на уровне контейнеров), мы имеем зоопарк этих самых систем контейнеризации.

А кто же ещё? :)

Я молчал-молчал, да не выдержал.

Как я рад тебя тут видеть. Ты куда пропал? Если здесь неудобно, напиши мне на мыло пожалуйста.

какой-то иной тип контейнера

Самодостаточный (ну относительно) пакет, который контейнезируется через bubblewrap (а там уже cgroups, namespaces и пр)

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

Согласен. Концепция кроссдистрибутивных пакетов себя практически не оправдала.

В моем понимании правильно было бы поднять вопрос о разработке общего API для работы изолированных приложений

Ну, порталы разрабатываются как стандарт freedesktop.

к естественному способу Linux - через изоляцию на уровне пользователей

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

фокус решения проблем смещён с причин

Причина - это «говноделы», на которых нужен прессинг?

А чё сам не писал? :) Ладно, напишу. Но толку с меня со всех сторон - ноль без палочки

Это хорошо а Android где все через сильные обертки работает

Там как бы нет «сильных обёрток». Просто у них не было легаси проблем, вот и запиливали API с нуля.

Причина - это «говноделы», на которых нужен прессинг?

Именно так

Смотреть что? Я не говорил, что рантайм вмещает вообще все библиотеки.

Размер того, что с Flatpak, и какой получится без него. С тем же софтом.

Каштан.

Там как бы нет «сильных обёрток». Просто у них не было легаси проблем, вот и запиливали API с нуля.

Ну здрасьте.

В Android целая эпопея с 6.0 по запиливанию разрешений по запросу.

Кажись она ещё не закончилась.

Каштан.

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

Так, а поподробнее?

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

Изи мод: выбираешь что ставить, а что нет + кнопка «update».

Intermediate mode: вместо кнопки update слайдер во времени + выбирашка релизов.

Advanced mode: можно добавлять приложения много раз из разных моментов развития nixpkgs и с разными input’ами. Там, вим с плагинами.

Expert mode: configuration.nix