Testing rawhide apps using xdg-app

An important aspect of xdg-app is application sandboxing, which will require application changes to use sandbox-specific APIs. However, xdg-app is also a good way to deploy and run non-sandboxed (or partially sandboxed) regular applications.

A very interesting usecase for this is to have an image-based operating system, for instance a Workstation spin of Fedora Atomic. Such a system would have a basic workstation installation with a read-only /usr, and atomic updates/rollback. However, installing an application is painful, and customizing yor install in that way undoes many of the advantages of an image-based OS.

With xdg-app you can install apps into /var (or $HOME) and have them fully integrate with the system, while still being isolated from changes to the host. This makes for a great combination, just like atomic + docker is a good combination for the server space.

I’ve spent some time recently making a prototype runtime based on the Fedora packages, as reported on the desktop list. This is kind of interesting as it lets you test applications from rawhide on fedora 21 or 22. Just install xdg-app from fedora-updates and then install the runtime:

$ xdg-app add-remote --no-gpg-verify --user fedora http://fedorapeople.org/~alexl/repo/
$ xdg-app install-runtime --user fedora org.fedoraproject.Platform 23

And then you can try gedit 3.17.0:

$ xdg-app install-app --user fedora org.gnome.gedit
$ xdg-app run org.gnome.gedit

Or evince 3.17.2:

$ xdg-app install-app --user fedora org.gnome.evince
$ xdg-app run org.gnome.evince

Once installed you can also just start them from the desktop environment as usual.  They should be there like any regular application as the desktop files and icons are exported to the host.

14 thoughts on “Testing rawhide apps using xdg-app”

  1. How can I see a list of all the available applications? I see xdg-app list-apps lists the local ones, I want to see what I can install. Thank you!

  2. Why is Docker or the recently announced Open Containers Project (opencontainers.org) not a suitable starting point for xdg-app? Why reinvent the wheel if there’s already a proven and widely used (and soon to be standardized) way of running sandboxed applications? Its libcontainer underpinnings already uses most of the same technology that xdg-app is utilizing like cgroups, SELinux, namespaces, etc.

    1. Steven S:
      I’m not exactly unaware of Docker, being commiter #8 to it per https://github.com/docker/docker/graphs/contributors

      However, docker is a very poor fit for the desktop case. Any user who is able to run a docker container has instant root rights on the machine, and it relies on a global (i.e. not per user session) daemon which fits very poorly with desktop use.

      And anyway, its not like we’re not sharing code, all of the things you list are used by xdg-app too. The only thing we are not sharing is the scaffolding code to set these up. This is around 2000 lines of dependency-free C code, so its not like its is rocket science.

      1. That’s great news. I figured there was tons of library sharing but didn’t realize it was that much. But my concern was not so much in the implementation of xdg-app but from the end user’s perspective of having to write apps to support another container format. As an app developer for both desktop apps and enterprise apps, it’s already hard to decide which package and container formats to target due to fragmentation with choices like docker, appc, opencontainer, warden, LXC, xdg-app, etc.

        Let’s hope the open container project can address some of the docker issues that you mentioned. Either way, I’m excited about your work and the possibility of sandboxed apps.

  3. It looks very interesting, and it is certainly a big step forward for the modernization of linux distributions. What are the plans for a first “stable” integration? Fedora[23,24,25]?

Comments are closed.

Leave a Reply to Bastian Ilso Cancel reply

Your email address will not be published. Required fields are marked *