Desktop Containers – The Way Forward

One feature we are spending quite a bit of effort in around the Workstation is container technologies for the desktop. This has been on the wishlist for quite some time and luckily the pieces for it are now coming together. Thanks to strong collaboration between Red Hat and Docker we have a great baseline to start from. One of the core members of the desktop engineering team, Alex Larsson, has been leading the Docker integration effort inside Red Hat and we are now preparing to build onwards on that work, using the desktop container roadmap created by Lennart Poettering.

So while Lennarts LinuxApps ideas predates Docker they do provide a great set of steps we need to turn Docker into a container solution not just for server and web applications, but also for desktop applications. And luckily a lot of the features we need for the desktop are also useful for the other usecases, for instance one of the main things Red Hat has been working with our friends at Docker on is integrating systemd with Docker.

There are a set of other components as part of this plan too. One of the big ones is Wayland, and I assume that if you are reading this you
have already seen my Wayland in Fedora updates.

Two other core technologies we identified are kdbus and overlayfs. Alex Larsson has already written an overlayfs backend for Docker, and Fedora Workstation Steering committee member, Josh Bowyer, just announced the availability of a Copr which includes experimental kernels for Fedora with overlayfs and kdbus enabled.

In parallel with this, David King has been prototyping a version of Cheese that can be run inside a container and that uses this concept that in the LinuxApps proposal is called ‘Portals’, which is basically dbus APIs for accessing resources outside the container, like the webcam and microphone in the case of Cheese. For those interested he will be presenting on his work at GUADEC at the end of the Month, on Monday the 28th of July. The talk is called ‘Cheese: TNG (less libcheese, more D-Bus)’

So all in all the pieces are really starting to come together now and we expect to have some sessions during both GUADEC and Flock this year to try hammer out the remaining details. If you are interested in learning more or join the effort be sure to check the two conferences notice boards for time and place for the container sessions.

There is still a lot of work to do, but I am confident we have the right team assembled to do it. In addition to the people already mentioned we for instance have Allan Day who is kicking off an effort to look at the user experience we want to provide around the container hosted application bundles in terms of upgrades and installation for instance. And we will also work with the wider Docker community to make sure we have great composition tools for creating these container images available for developers on Fedora.

6 thoughts on “Desktop Containers – The Way Forward

  1. I like this idea, so much that I wrote about a similar thing a few years ago when people were talking about Gnome OS.

    A well defined application model could make desktop Linux a much easier dev target, and make things safer for users as a bonus.

    • Crucially, we need to get support for these sandboxed apps (whatever that support entails) into Debian, and therefore eventually into Ubuntu and SteamOS.

  2. I hope the UX part of Linux desktop containers will be like on OS X. Just can’t think of a better way. Drop file into “Applications” folder. Done. Click file. Application launches. Right click file to view contents.

    • What? I have never seen OS/X do that. Here is how every application I have installed on OS/X works:

      1. Download dmg file.
      2. If it doesn’t open, find it in the downloads folder and open it
      3. Click the icon marked “double click this” in the opened window.
      4. Hit “I agree” and “OK” a few times. Then it is installed.
      5. Search around on the desktop for the disk image and eject it (or just leave it until I notice it).

  3. How do these desktop contrainers differ from what’s already being developed as part of the Capsicum framework?

    Is it right to target a more generalised solution like Docker instead of a more specialised one like Capsicum?

Comments are closed.