Представлен (https://blogs.gnome.org/alexl/2016/03/17/xdg-app-0-5-0-released/) выпуск инструментария xdg-app (https://github.com/alexlarsson/xdg-app), предназначенного для организации распространения графических приложений в самодостаточных контейнерах, не привязанных к конкретному дистрибутиву Linux и надёжно изолирующих приложение от остальной системы. Контейнеры позволяют упростить распространение сторонних программ, не входящих в штатные репозитории дистрибутивов, за счет подготовки одного универсального контейнера без формирования отдельных сборок для каждого дистрибутива.При создании проекта были поставлены две ключевые цели: предоставление разработчикам сторонних программ возможности создавать и распространять приложения, работающие в разных дистрибутивах, и обеспечение работы с минимальным доступом к системе (доступ только к сетевым функциям и связанным с приложением файлам пользователя). Отмечается, что в выпуске xdg-app 0.5.0 полностью реализована вся функциональность, необходимая для достижения первой цели. В том числе доступны средства для сборки контейнеров приложений, поддержки различных графических фронтэндов, использования в различных дистрибутивах. В будущем внимание планируется сосредоточить на развитии средств для sandbox-изоляции и проброса данных в контейнер.
Особенности (https://lists.freedesktop.org/archives/xdg-app/2016-March/00...) xdg-app 0.5.0:
- Новая библиотека libxdg-app, предоставляющая API для создания графических интерфейсов, работающих поверх xdg-app. Например, библиотека задействована для поддержки контейнеров-приложений в gnome-software и Papyros software center.
- Поддержка обработки метаданных AppData, определяющих такую видимую пользователю информацию о пакете, как имя программы, описание, пиктограммы, скриншоты и списки изменений. Интеграция AppData позволила обеспечить в gnome-software удобную навигацию по репозиториям xdg-app;- Упрощён интерфейс командной строки, доступный через утилиту xdg-app;
- Добавлена новая утилита xdg-app-helper, упрощающая процесс сборки приложений в форме окружений xdg-app;
- Реализована возможность формирования однофайловых образов приложений, которые можно использовать для поставки приложения на физическом носителе;
- Готовые пакеты сформированы (https://wiki.gnome.org/Projects/SandboxedApps/Packages) для дистрибутивов Fedora, Ubuntu, Debian, Arch Linux и Mageia.Изолированное окружение формируется из двух компонентов: типового системного окружения (runtime), устанавливаемого через специальный репозиторий (http://sdk.gnome.org/repo/), и дополнительных зависимостей (bundle), связанных с приложением. В сумме runtime и bundle образуют начинку контейнера, при том, что runtime устанавливается отдельно и привязывается сразу к нескольким контейнерам, что позволяет обойтись без дублирования общих для контейнеров системных файлов. В одной системе может быть установлено несколько разных runtime (GNOME, KDE) или несколько версий одного runtime (GNOME 3.16, GNOME 3.18), в зависимости от требований используемых программ. Контейнер с приложением в качестве зависимости использует привязку только к определённому runtime, без учета отдельных пакетов, из которых состоит runtime. Все недостающие элементы упаковываются непосредственно вместе с приложением. При формировании контейнера содержимое runtime монтируется как раздел /usr, а bundle монтируется в директорию /self.
Начинка runtime и контейнеров приложений формируется с использованием технологии OSTree (https://www.opennet.ru/opennews/art.shtml?num=37750), при которой образ атомарно обновляется из Git-подобного хранилища, позволяющего применять методы версионного контроля к компонентам дистрибутива (например, можно быстро откатить систему к прошлому состоянию). RPM-пакеты транслируются в репозиторий OSTree при помощи специальной прослойки rpm-ostree (http://rpm-ostree.cloud.fedoraproject.org/). Отдельная установка и обновление пакетов внутри рабочего окружения не поддерживается, система обновляется не на уровне отдельных компонентов, а целиком, атомарно меняя своё состояние. Предоставляются средства для инкрементального применения обновлений, избавляющие от необходимости полной замены образа при каждом обновлении.
Формируемое изолированное окружение полностью независимо от используемого дистрибутива, не имеет доступа к файлам и процессам пользователя или основной системы, не может напрямую обращаться к оборудованию, за исключением вывода через DRI, и сетевой подсистеме.
Вывод графики и организация ввода реализована при помощи протокола Wayland (X11 не поддерживается). Взаимодействия со внешней средой построено на основе системы обмена сообщениями kdbus. Для изоляции используются традиционные для Linux технологии контейнерной виртуализации, основанные на использовании cgroups, пространств имён (namespaces) и SELinux. Для вывода звука применяется PulseAudio.
URL: https://blogs.gnome.org/alexl/2016/03/17/xdg-app-0-5-0-released/
Новость: https://www.opennet.ru/opennews/art.shtml?num=44075
> не может напрямую обращаться к оборудованию, за исключением вывода через DRI, и сетевой подсистеме
> (X11 не поддерживается).Типа сеть у приложения есть, а X11 пользоваться нельзя. А как они этого добились?
Очередной дурачёк который думает что сетевое взаимодействие программ (сервер<=>клиент) это якобы TCP_socket по 127.0.0.1 ?Обломись! У нас есть unix-сокеты и dbus (т.е. опять-таки unix-сокеты)
> дурачок
Элементарно: X-сервер запускется без поддрежки TCP (это и так по умолчанию в большинстве дистров) и в контейнер не просовывается сокет /tmp/.X11-unix/X0.
Over 9000 способов. Например, в контейнере может быть свой localhost и отдельный IP, которые могут вообще не иметь доступа к сети host.
> возможности создавать и распространять приложения, работающие в разных дистрибутивахЕсли бы это возможность изначально присутствовала в Linux, то давно бы уже на половине десктопов стоял, т.к. у производителей софта пропала бы преграда, мешающая один раз скомпилированному приложению работать везде и всегда
Какой-то кукарек подобный гетзефакс.
Прикинь, эта возможность давным давно присутсвует в линукс в той же мере что и в винде. То есть чем более специфические вещи ты используешь, тем ниже переносимость. Ну и само собой нет переносимости вниз и на другие архитектуры. В винде ровно такая же ситуация.
> Если бы это возможность изначально присутствовала в Linux,Все системные компоненты давно присутствуют. Вопрос в запускалке и программах.
> мешающая один раз скомпилированному приложениюв этом месте впердоливатели проприетари испытывают попаболь и учащённое сердцебиение. граждане, чей опенсорсный продукт собирают в репах дистростроители дышат ровно и глубоко.
Виндовый скайп запихали бы в контейнер пусть даже весил бы 2 гб, но что бы в репе была всегда актуальная версия.
А так да вещь полезная, можно с убунты несколько программ в федору перетащить.
вот поэтому я не использую федору и дебиан....;) не проще юзать убунту и ничего никуда не таскать?
Не проще юзать source-based дистрибутивы и ставить то что душе угодно?
Не проще. Когда начнёшь канпелять сам, поймёшь.
Компиляю на протяжении 5 лет трудностей не наблюдаю
Через distcc на это делается без напряга
Ну конечно школьникам не потянуть отдельную машинку предназначенную для компеляции, за то плакаться на форумах как все плохо в вашей убунточке намного проще
Скомпиляй ка мне это:
http://ccwu.me/vsfm/Только всё, с зависимостями. Как скомпиляешь, можешь Praat со товарищи собрать. Только не из ебилдов, ручками.
Если ебилд написан ручками -- это считается за компиляцию ручками? А если компилятор компилирует сам, не требуя от меня ручками переводить программыный код в машинные коды -- это не является нарушением идеи "ручками"? А использование make не портит картины? А вот ещё, я когда-то давно сидя на слаквари решил собрать gnome из сорцов, узрел там путаницу в кросс-депендансах, и написал скрипт, который собирая вывод ./configure из разных пакетов, выяснял граф зависимостей, вычислял порядок сборки этих пакетов, и таким образом компилировал: такой подход считается "ручками" или нет?Но я отвлёкся. Мне очень любопытно оценить, сложность того, что вы считаете невыносимо сложным, но пока я вижу лишь одну сложность: где сорцы той программы, на которую вы дали ссылку? Я вижу там ссылки на бинари, а ссылки на сорцы -- нет. Сложность в том, что это программа без сорцов, и поэтому непосвящённым невозможно её скомпилять? Мне почему-то кажется, что это настолько банальная сложность, что вы скорее имели в виду что-то иное. Но что именно?
Ребёнок (уж не знаю, кто ты, мальчик или девочка)! Ты не в состоянии найти сорцы на той странице, о чём ты говоришь вообще? Если твоё представление о сборке софта закключается в знании нескольких команд емержа, могу тебя расстроить. Ебилды кто-то должен написать, понимаешь? Но! ты же даже сырцов не нашёл, а их зависимости... Напиши проще - "ждём ебилдов!"
Я тоже не вижу сорцов на той странице. Архивы с готовыми бинарниками или бинарными либами, из которых можно собрать бинарь, вижу, а вот сорцов - нет. Если у тебя фантастический скилл поиска по вебу, то я рад за тебя, только какое отношение это имеет к сборке из исходников?
Из ответа Ordu явно следует, что его знания отнюдь не ограничиваются командами emerge. Если ты этого не понял, то приходится усомниться в твоем умении читать и понимать прочитанное.
типичный ТЛД:FAQ-7. Is VisualSFM open sourced? Programmable control of VisualSFM?
The GUI (including SfM) part of the software package is close-sourced, which I developed from scratch. If you are interested in the algorithm detail of the SfM system, you can read my 3D paper here.
Правильно, это проект института, который частично открыл код для некоммерческого использования. Закрыт там только гуй, но там целый ворох библиотек, которые тянут за собой ещё ворох библиотек оно всё состоит из такого вот нагромождения (нет, оно не так сложно, когда въедешь). Это и есть проблема - собрать всё в кучу.И первое что должен был понять и написать "спицалист по гентушкам", который не знает проблем с компилянием. А не отмазки типа "да я не нашёл, да там сложно всё!"
However, I have already open-sourced SiftGPU (feature detection & matching) and PBA (multicore bundle adjustment), which can be easily integrated into any other SfM system. You can also make changes to them, and reintegrate with VisualSFM.то есть, в готовом виде канпелять нечего, надо самому писать, что далеко не одно и то же
Их можно сомпилить со своими опциями, например просто sift, не на gpu и пр. использовать с тем гуем. Так идёт?
> Не проще юзать source-based дистрибутивы и ставить то что душе угодно?Нет желания и времени разбираться в ошибках компиляции.
Проще. Только кто же тебе сорцы даст проприетарного дерьма? Эти контейнеры делают для дистрибуции проприетарщины.
> вот поэтому я не использую федору и дебиан....;) не проще юзать убунту
> и ничего никуда не таскать?1. В Убунте нет DNF.
2. В Убунте нет нового Gnome 3
3. В Убунте нет простого и стабильного обновления системы.
> 1. В Убунте нет DNF.В Федоре уже можно, без плясок с контейнерами, сhroot-ами или самосборкой поставить несколько версий шланга и гцц?
> 3. В Убунте нет простого и стабильного обновления системы.
В котором просто и стабильно то кеды сломают
https://lists.fedoraproject.org/archives/list/kde@lists.../
http://linuxbsdos.com/2015/11/06/how-to-upgrade-fedora-22-to.../
то плагины для gstreamer
https://fedoramagazine.org/upgrading-from-fedora-22-to-fedor.../
> 1. В Убунте нет DNF.Там apt. Он лучше.
> 2. В Убунте нет нового Gnome 3
В 16.04 вроде 3.18 будет.
> 3. В Убунте нет простого и стабильного обновления системы.
По сравнению с федорой? Да ты жирный тролль.
Во-первых в Fedora вот вот Gnome 3.20 завезут, во-вторых в целях производительности DNF полностью переписывают на C, в-третих Fedora давно превратилась из тестовой площадки RHEL в самодостаточный надежный стабильный дистрибутив у которого есть собственные ветки полировки rawhide/tested те Fedora по стабильности не хуже, чаще лучше Ubuntu, внутри Fedora гораздо слаженней и симпатичней той же Ubuntu. В Fedora всегда самые передовые разработки которые иногда кочуют в другие дистры годами, Red Hat очень много комитят в ядро, в репах Fedora уйма софта, ну а весь проприетарный мусор можно найти в репе RPM Fusion. Да и почитайте что завезут в Fedora 24, заглядение ведь :) особенно вынос языков в мягкие зависимости. Лично я ничего не имею против Ubuntu и других дистрибутивов, людям нравятся пусть пользуются, для каждого свой дистрибутив по своему удобен, выше я написал часть того чем меня переманила Fedora чем она мне нравится, написал бы больше да честно говоря лень...
> 3. В Убунте нет простого и стабильного обновления системы.Наглая ложь, всегда прекрасно обновлялась Убунта. Вот например скринкаст записал: http://videobin.org/+88w/b20.ogg (14.04 → 14.10)
И ещё вот: https://www.linux.org.ru/gallery/screenshots/6124095 (чел ради эксперимента последовательно обновил Убунту от 4.10 до 11.04).
Ждём поддержки в KDE Discover (Muon)
> Для изоляции используются традиционные для Linux технологии контейнерной виртуализации, основанные на использовании cgroups, пространств имён (namespaces) и SELinux.У меня почти ничего этого нет. Я нормален?
Либо это нужно чтобы клепать GUI для админов, либо я чего-то не понимаю... За исключением network namespaces не вижу пользы на десктопе ни от одной из перечисленных технологий.
>> основанные на использовании cgroups, пространств имён (namespaces) и SELinux.
> Либо это нужно чтобы клепать GUI для админов, либо я чего-то не понимаю...никто не заставляет использовать, но уж представлять юскейс SELinux уж как-то можно...
На десктопе у него один юзкейс - защищать безгололового идиота, который не ведает, что творит, от самого себя. Во всяком случае, вменяемый пользователь даже на винде при аккуратности мог сидеть за файрволлом (не встроенным в винду, конечно) без антивируса и не иметь проблем. В линуксе - и подавно.