Маттиас Класен (Matthias Clasen), лидер Fedora Desktop Team и участник GNOME Release Team, рассказал (http://blogs.gnome.org/mclasen/2015/01/21/sandboxed-applicat.../) о состоянии разработки механизма (https://wiki.gnome.org/Projects/SandboxedApps) поставки программ для GNOME в форме изолированных контейнеров, включающих все необходимые для работы приложения зависимости и не привязанных к конкретному дистрибутиву Linux. Подобные контейнеры позволят упростить распространение сторонних программ, не входящих в штатные репозитории дистрибутивов, за счет подготовки одного универсального контейнера без формирования отдельных сборок для каждого дистрибутива. Конечному пользователю установка подобных контейнеров даст гарантию, что приложение будет надёжно отделено от основной системы, а также позволит не нагромождать систему дополнительными зависимостями и пакетами.Сообщается, что проект достиг состояния, пригодного для проведения экспериментов энтузиастами. Для изоляции приложения используются традиционные для Linux технологии контейнерной изоляции, основанные на использовании cgroups, пространств имён (namespaces) и SELinux. Для взаимодействия со внешней средой используется система обмена сообщениями kdbus (http://www.opennet.ru/opennews/art.shtml?num=41478). Вывод графики и организация ввода осуществляется при помощи протокола Wayland (X11 не поддерживается).
Окружение в котором работает приложение формируется из типового системного runtime-окружения и связанных с приложением дополнительных зависимостей (bundle). В сумме runtime и bundle образуют начинку контейнера. Для использования в одной системе может быть установлено несколько разных runtime (GNOME 3.14, KDE 5.6) или несколько версий одного runtime (GNOME 3.14, GNOME 3.16), в зависимости от требований используемых программ. При этом bundle c программой в качестве зависимости использует только привязку к определённому runtime, без учета отдельных пакетов, из которых состоит runtime. Все недостающие элементы упаковываются непосредственно вместе с приложением в bundle.При формировании контейнера содержимое runtime монтируется как раздел /usr, а bundle монтируется в директорию /self. Для разработчиков приложений предлагается расширенный developer runtime, который выступает в роли аналога SDK и включает помимо файлов, используемых для запуска программы, компоненты, требуемые для сборки приложения. Командой "xdg-app run" осуществляется формирование контейнера и запуск программы, а командой "xdg-app build" выполняется создание контейнера для сборки программы.
Распространение runtime и приложений, а также обновлений, производится с использованием технологии OSTree (http://www.opennet.ru/opennews/art.shtml?num=37750), при которой образ атомарно обновляется из Git-подобного хранилища, позволяющего применять методы версионного контроля к компонентам дистрибутива (например, можно быстро откатить систему к прошлому состоянию). RPM-пакеты транслируются в репозиторий OSTree при помощи специальной прослойки rpm-ostree (http://rpm-ostree.cloud.fedoraproject.org/). Отдельная установка и обновление пакетов внутри рабочего окружения не поддерживается, система обновляется не на уровне отдельных компонентов, а целиком, атомарно меняя своё состояние. Предоставляются средства для инкрементального применения обновлений, избавляющие от необходимости полной замены образа при каждом обновлении. В настоящее время уже запущен репозиторий (https://people.gnome.org/~alexl/gnome-sdk/repo/) с несколькими экспериментальными приложениями и runtime (https://github.com/alexlarsson/gnome-sdk-images) на основе Yocto Linux (https://www.yoctoproject.org/) и GNOME 3.15.
URL: http://blogs.gnome.org/mclasen/2015/01/21/sandboxed-applicat.../
Новость: http://www.opennet.ru/opennews/art.shtml?num=41514
Ах вот что оно зачем kdbus в ядро пихали, оказывается оно не только Поттеру нужно у него своя секта
> оказывается оно не только Поттеру нужноДа и идея объединить все базовые программы системы в один проект - тоже не только ему нужно.
BSDшники так уже много лет жили, а теперь удобство такой схемы начало доходить и до линуксоидов.
> BSDшники так уже много лет жили,BSDшники сделали из этого какой-то полурелигиозный культ, "потому что тут так принятно". А в этой конструкции просматривается какая-то заточенность на практические сценарии использования. Ну там всякие стимы и прочая так отпиливать, напрмер.
Да все нормально, это наши заморочки из джерси
)))))
Ты, похоже, не понимаешь ничего ни в системде, ни в BSD.
> Да и идея объединить все базовые программы системы в один проектFBSD это не один проект, это набор проектов (утилит), равно как и тот-же проект GNU это тоже набор проектов. А systemd это один большой кусок.
> Да и идея объединить все базовые программы системы в один проект -
> тоже не только ему нужно.
> BSDшники так уже много лет жили, а теперь удобство такой схемы начало
> доходить и до линуксоидов.Объединить в одной директории и завязать код на друг друге это разное. systemd с udev сделал именно второе, тем самым подтолкнул разработчиков к переходу на его. Модульность и свалка кода это разные понятия. От тесной интеграции всех программ я пользы не вижу, что нужно одному Васе, второму Васе может никогда не понадобится. Представьте себе ядро Linux в котором все драйвера скомпилированы статично а не динамично. Драйвера же это базовая часть
Есть 80% Вась нужно именно то, что собрано в кучу, то остальные 20% Вась либо терпят наличие чего-то лишнего либо делают свой набор либо берут набор от другого Васи из 20%. Все довольны.
> BSDшники так уже много лет жилиаж так хорошо жили, что сейчас bsd нахер никому в эксплуатации не нужна. И в первую очередь из-за убогости такого подхода.
ага зовется Red Hat
А как же интел?
Кто смеялся над pbi в PC-BSD? Они обогнали время!
> Кто смеялся над pbi в PC-BSD? Они обогнали время!Да такие идеи постоянно всплывают http://www.opennet.ru/opennews/art.shtml?num=40278
Только вот пока не особо взлетают на десктопах.А вот на серваках уже вполне вольготно устроились, будучи важной деталью облачных технологий.
Если еще и дедупликацию файлов между bundle сделают, будет вообще шикарно.
Можно для этого использовать Btrfs.
никогда не думал, что увижу эту фразу для графических приложений - (X11 не поддерживается)
> (X11 не поддерживается)По мнению разработчиков, секурити X11 настолько фиговая что нивелирует весь смысл контейнеров.
> никогда не думал, что увижу эту фразу для графических приложений - (X11
> не поддерживается)Это не для приложений. Это данное дермо под которое предлагают делать приложения. Для любителей ... >:-)
> Это не для приложений. Это данное дермо под которое предлагают делать приложения.
> Для любителей ... >:-)(даже сам задумался. Как у них не поддерживается X11, если оно работает через сеть. И без всяких dbus...)
Прощай GNU/Linux!
Привет SystemD/Linux!
Вот и формат пакетов для новой оси вырисовывается...
Казалось бы, при чем тут systemd/Linux? Это ж GNOME OS!
> Казалось бы, при чем тут systemd/Linux? Это ж GNOME OS!
Да, проблема в среде гноморазработчиков: PBI и Jail не для них — слишком сложно.
Реинкарнация «жирных» бинарников со всеми ихними проблемами. Как в такой блоб впихнуть драйвера? Как проапдейтить зависимости когда там будет найден баг?
> впихнуть драйвера?Никак, разумеется: в кернелмоде никто не ждет код который в юзермоде надо песочницой отгораживать.
>> впихнуть драйвера?
> Никак, разумеется: в кернелмоде никто не ждет код который в юзермоде надо
> песочницой отгораживать.Абажи, ещё не вечер. Будет юзерспейсный код через kdbus ядро патчить.
>позволит не нагромождать систему дополнительными зависимостями и пакетамиТолько вот каждая такая программа будет нести с собой свой отдельный вагон библиотек, которые уже есть в системе, т.е. многократное дублирование получается.
>>позволит не нагромождать систему дополнительными зависимостями и пакетами
> Только вот каждая такая программа будет нести с собой свой отдельный вагон
> библиотек, которые уже есть в системе, т.е. многократное дублирование получается.Там рекурсия: каждая программа тащит только нужные ей библиотеки, а библиотеки тащат только нужные им зависимые библиотеки. В итоге умозрительный "вагон" в классическом представлении превращается по сути в тележку реально востребованного кода.
> в тележку реально востребованного кода.На самом деле нет. Если используются shared object-ы, то тогда не проведено выкидывание неиспользуемого кода (LTO)... Да и вообще все плюсы динамической линковки исчезают (остаются лишь одни минусы [1]) в данной пакетно-контейнерной схеме.
Для систем, в которых браузер жрёт гигабайты, это очень важная проблема.
Большинство нужных программе библиотек будет в среде исполнения runtime, а в контейнере с приложением bundle будут только те библиотеки, которых нет в runtime. Поэтому контейнер не должен содержать большого количества библиотек и уж, тем более, не должно быть избыточного дублирования одинаковых библиотек.
Меня интересует только один админский вопрос применительно к сабжу — предусмотрен ли штатный механизм надёжного запрета всего этого барахла?
> Меня интересует только один админский вопрос применительно к сабжу — предусмотрен
> ли штатный механизм надёжного запрета всего этого барахла?Да — отсутствие места на дисках, отсутствие механизма дедупликации на уровне файлов, отсутствие nullfs в Linux, в конце-концов. Всё нужно изобретать заново для этой замечательной операционной системы — есть чем занять людей в ближайшее десятилетие. :)
Не сцы, г3 в бзде тоже есть (ну или будет).
Как и аналоги системды, дбас и тд, и тп.
Так что ты тоже будешь изобретать "отсутствие свободного места".
> Меня интересует только один админский вопрос применительно к сабжу — предусмотрен ли штатный механизм надёжного запрета всего этого барахла?Эта хрень не для админов предназначениа, а для овоща который будет покупать приложения в магазине который гномеры скоро тоже запилят в свою ос. А овощу не нужно ничего контролировать и запрещать, не овощное это дело.
Не только покупать, но и брать бесплатно. Для проприетарщиков такой подход тоже открывает кучу возможностей, но без этого Линукс не выйдет за пределы 3%. Линукс уже готов для корпоративного использования, но единственное, что его сдерживает -- это отсутствие универсального способа доставки приложений для всех дистрибутивов и слишком сильная привязка софта к конкретным пакетным менеджерам и дистрибутивам, коих вагон и маленькая тележка. Контейнеры Gnome ликвидируют эту проблему. И ведь они решают проблему поставки не только гномовских приложений, но вообще для любых графических тулкитов.
Как valve без гномовских контейнеров и виртуализаций игры распространяет?> и слишком сильная привязка софта к конкретным пакетным менеджерам и дистрибутивам,
> коих вагон и маленькая тележка. Контейнеры Gnome ликвидируют эту проблему. И
> ведь они решают проблему поставки не только гномовских приложений, но вообще
> для любых графических тулкитов.Не такая там проблема, что бы такой огород городить. У меня очень переработанный lfs - нет udev/dbus/pulseaudio/systemd, busybox вместо *nix utils, не придерживаюсь строго FHS, glibc тоже существенно подрезана.
Opera ставилась без проблем. Лень было собирать LO4 - взял сборку для дебиана - ругнулась, что у меня libdbus нет. Взял libdbus с дебиана - и все заработало (без демона dbus!). Pianoteq, Unreal, ET:QW - тоже работали.
> Как valve без гномовских контейнеров и виртуализаций игры распространяет?Клиент Steam и игровой дивжок у них под все дистрибутивы?
> Меня интересует только один админский вопрос применительно к сабжу — предусмотрен ли штатный механизм надёжного запрета всего этого барахла?Запретов не будет -- не хочешь не ставь. Реально независимые от дистрибутива контейнеры приложений будут лежать в магазинах типа Google play, Yandex store, дистрибутивных центрах приложений или на сайтах разработчиков софта, которые предпочтут собрать 1 пакет для всех дистрибутивов и выложить его на FTP.
И чем больше будет таких магазинов софта, как локальных дистрибуивных, так и публичных, тем меньше у дистрибутивов будет желания бесконечно пересобирать этот софт. Пользователи Дебиана, наконец, могут поставить в свой любимый дистрибутив самые последние версии программ, а не тот шлак, который у них есть в репах пятилетней давности.
Только зачем привязывать это все к гному? Запуск программ не должен быть связан с оболочкой.
Маразм крепчал ...
Давайте уж сразу образы под qemu/virtualbox для каждой программы сделаем. Так мы решим проблему не только безопасности и зависимостей, но кроссплатформенности и даже кроссархитектурности!
> но каждый думал а давай
Лучше даже вслух такое не говори. Неровен час...
Слишком большие накладные расходы. Сейчас нет недостатка в технологиях виртуализации, но что-то не слышно, чтобы они были дико популярными для распространения софта.
Да еще лучше зашить гипервизор прямо в биос и все дела.
GNOME таки укатился в ср@ную ж*пу...
Беда в том, что и Gtk и с Gstreamer за собой уволок.И это нихрена не смешно.
> Подобные контейнеры позволят упростить распространение сторонних программ, не входящих в штатные репозитории дистрибутивовНепонятно зачем упрощать то, что нужно запретить.
>поставки программ для GNOME в форме изолированных контейнеров, включающих все необходимые для работы приложения зависимости и не привязанных к конкретному дистрибутиву LinuxА зачем делать из линукса форточку?
Чтобы сделать линукс полноценной корпоративной платформой.
> Чтобы сделать линукс полноценной корпоративной платформой.Скока стоит?
jvm?