 Hello. Hopefully many of you saw my other Flatpak talk yesterday. If not, the introduction to Flatpak in this one will be even more introductory and in a bit of a rush. So this is the like two-minute version of my 20-minute talk yesterday. Sandbox is our framework for desktop Linux. It's for the sort of thing you might get in an app store. It's also for the sort of thing that might have a desktop file. Your app runs in a sandbox because you don't want it reading your PGP key. There are portals, which are a clever mechanism to escape from the sandbox to do things like access a file that the user has chosen without having access to all the other files that the user didn't choose. And they use essentially the same Linux syscalls and so on as more conventional server-containing technologies like Docker, Alexa, that kind of thing. And the thing that is important for how these relate to distributions is that an app runs on a runtime. So the idea of a runtime is a Linux distribution is fine as a stable platform. But if you want your app to run on Debian and Fedora and Debian from this year and also Debian from five years ago, you don't really know what you're going to get. So a runtime is like the API compatibility levels you have in Android where you can say, this app is going to run on Debian 9 and the infrastructure gives you an appropriate runtime to run your app on. So the app author gets to choose when they update. They can update at their own pace once they've done whatever QA they feel is appropriate. The runtime comes from what Flatpak calls a branch where the idea is the major version and depending on your policy maybe the minor version is fixed at a constant. But you do pick up like micro releases for bug fixes, security, that kind of thing. You definitely don't update it across incompatible changes because that defeats the object. And you have some kind of lifetime for which this runtime is supported. So you might have, will support this runtime as long as the underlying version of Debian, so two years or five years or whatever. And this also seems kind of familiar to people in the distro's dev room, I'm sure. Because this is basically a tiny Linux distribution. It's a weird Linux distribution because it can't boot. You don't have a kernel because you have a host system for that. You don't have init because you have a host system for that. There is no sysadmin things because you're running as one user, you're running an app, you don't need demons. In the version that users see of the runtime, you don't have development tools because if you just want to run events or Firefox or Steam or whatever, you don't need GDP. And there is also no package manager because version management and uninstalling and upgrading and all that kind of thing is done from outside. So instead of running apt inside your container like you might with Docker, you essentially throw away your container and put another one in. And obviously it's de-givlicated. You don't actually download everything again. But conceptually it's as though you did. So the first thing I want to talk about is why you might want your distribution to have flatback and not just go, well, we've never needed this. We never will need it. One thing that's often really annoying on long-term stable distributions is when you want a stable platform to do your work on that will not change under you and give you arbitrarily different UX, except that there are these three apps that you absolutely need the latest version because they're important to you in your job or whatever. So you might be running on one of these very enterprise distributions that's supported for five years and it's not allowed to upgrade anything because you want that predictability. But you absolutely need the latest version of maybe Inkscape or something because that's the thing you're specifically interested in. And as an upstream developer of an app, you kind of have this nasty duality that if you depend on new libraries, it's going to be really annoying for your users to install them on Debian from two years ago or Red Hat Enterprise Linux from five years ago or whatever. But if you choose to artificially restrict your dependencies and say, well, I'm only going to use the version of GLib that was in Debian two years ago, you don't get the benefit of all the work that's been done since then. And as we know, two years is an eternity in software, so you probably don't want that. So distros have generally dealt with this by backports. So like in Debian, we have the stable backports branch and lots of other distros have similar things. So you choose your selected software, mostly like leaf packages like an app or a game or maybe a server. And you take the version from the next development release, you rebuild it for the previous stable release, and you cross your fingers and you hope it works. And if it hasn't actually got new dependencies like a lot of games, you can just backport by five years and they'll be fine because they don't require much from libraries anyway. But if you do depend on newer libraries, because you only have one copy of like LibGTK3 on your system, you have to make this unpalatable choice of do I want the predictable one or do I want the latest for my backport. So for instance, if you have a backport of Abbey Word, which depends on GTK, it might pull in a newer version of GTK, okay, fine. But now all of Nome is using that newer version of GTK and maybe you've just destabilized your entire desktop environment, which is probably not what you want. Or even if you're like happy with backporting the entirety of Nome, like I believe Red Hat Enterprise Linux does sometimes. If you've decided that's something you're willing to do, you upgrade your GLIB to be able to do that, but you can only have one copy of GLIB on your system and thermal D that stops your CPU overheating also uses GLIB. So if there's a regression there, then your laptop cooked itself and you're sad. So the reason I was like originally interested in Flatpak is to be a better backports because backports as currently done in distros have this problem with you have to make a choice. But if you can build each app, each game, each leaf package against a stack that its maintainer is happy with, not necessarily the same one even, then you don't have to make this choice. You can have one choice of runtime that you run on for, Nome Builder if it needs the latest shiny Nome things. If Inkscape doesn't need really recent stuff, you can run it on a different runtime. You don't have to choose a single answer. And each upstream app author can choose the pace they upgrade at and not be forced into, well, we have to use this new version because this other app wants it. And obviously the immediate worry from distro people is but we don't like duplication. And yes, your libraries will be duplicated a bit. That will happen. But there's less than you might think actually because Flatpak uses OS tree which is essentially Git for binaries. So it's content address storage. And if two of your runtimes happen to contain the same thing like you have a Nome runtime and a KDE runtime that both include Gillip C, you only actually have one Gillip C if it's the same one because they're just hard links to the same file in the hashed storage. Another thing that's quite interesting for Flatpak and on distro is the diametric opposite of that. If you have software that depends on libraries from the distant past that we would all rather had died like the Nome 2 stack which we're finally removing from Debian at the moment, you don't really want to carry those in your distribution forever because your users might have an app that wants like Nome VFS or LibUnique or whatever. And a lot of the time the distros don't really have the resources to maintain them forever. And to be honest they were deprecated for a reason, right? No one just says this library is obsolete for fun. It's because they've found a design floor and they can't fix it without breaking compatibility. In particular, Colabora has been doing some work recently with Valve on Steam and they have this problem in a big way because they distribute binary games which ideally the publisher doesn't want to touch them once they've got them to like an acceptable quality. They want to go, right, this game has gone gold, throw it out the door, we're done with this one, move on. And like maybe patch it a few times later but they don't want to keep going, oh well this doesn't work on this year's Ubuntu, we'll have to fix it to work with this GTK. And now it doesn't work on the next year's Ubuntu, let's fix it up for that. If someone's complaining it doesn't work on OpenSuser it's not really viable. So their solution to this has been the Steam Runtime which is Ubuntu from 2012 with Selected Backports which is two words, a cover of multitude of sins I'm sure. And it's a giant LD library path to pull in libraries of selected versions and all the games running this, the Steam client runs in this as well because it has stuff that would potentially break with a newer GTK or a newer, I don't know, LibJPEG or something. But it has gaps, it specifically doesn't use, doesn't have its own graphics stack because if you have an NVIDIA binary driver or a Mesa open source driver that works for your hardware and that corresponds to your kernel which is that one, they don't want to use some other version that may or may not work on your machine. So it's like this incomplete runtime. And what we think might be a good way forward here which we're still experimenting with is put each Steam game in a container. So I have this tool called FlatDev which is a proof of concept for building a Flatpack runtime out of Debian or Ubuntu packages. So the Steam runtime, we have a pile of .debs that are perfectly reasonable. We just need to unpack them, put them in a container, use those. My colleague Vivek is working on this terrifying thing called LibCapsule, which if you're interested in that he did a talk on this which was recorded at last year's MiniDebConf in Cambridge. That lets you load libraries of the same name with the same symbols into the same address space without colliding. It's GNPC Blackmagic. And the idea is that you can have your game's dependencies which probably include the standard C++ library because game developers love C++ and you have Mesa which uses LibLVM which uses C++ and a different standard C++ library. And somehow you need to get both these in your process space without them fighting. And this is the idea of LibCapsule and it almost works which amazes me. As I said, work in progress. And in future, at the moment the entire Steam environment runs in one copy of the Steam runtime essentially. The UI where you buy your games and the library browser and the launcher and the games themselves. What we would like to do is have old games that have never been QA'd against a newer distribution. Keep running them in the old runtime. New games that the developer has tried them against newer stuff. Maybe they even need newer stuff. We can run them in a less old Steam runtime like maybe based on a more recent Ubuntu or on the latest Debian stable or something. And pick one or the other whichever works for the library browser and that kind of thing. There are a few unsolved problems with forward ports. I have to say and I can see why distributions might not like the idea. I mean if you have some un-maintained libraries and you put them in runtime, that doesn't magically make them maintained. Someone still has to either do the work or acknowledge that it's not going to be done. And in particular Ubuntu 1204 was EOL last summer. I mean it's a long term support distribution but there's a long term and there's a long term, right? But if you're going to use this anyway and Steam is in production using a pile of libraries anyway, we can at least sandbox it and that's got to count for something. It's better than not sandboxing it. And it's way better than a static binary where you can't update it even if you wanted to and it's infinitely better than what people tend to do in practice which is go to archive.buntu.com wget ancient library, don't use secure app, just install it, cross your fingers, yeah, don't do that. Another good thing to do is software that isn't yet in your distribution but you would like to use it anyway. So some distributions are more complete than others. Debian tries to have everything. Even we don't package everything. And the idea is ideally we want everything to help to our quality standards but maybe that's just not feasible and maybe we should let the perfect not be the enemy of the good here because in an ideal world we have enough maintainers for doing all these things better than upstreams can, keeping everything up to date, QA to make it not regress, making sure the licensing is actually reasonable and that kind of thing at our best we can protect our users from bad software but sometimes we don't actually add value. I'm sure there's plenty of packages in everyone's distribution where the entire change log is like new upstream version, new upstream version, new upstream version. You're not actually adding a whole lot to that package and sometimes having a gatekeeper is just stopping people doing what they want to do which is not great. So I said a couple of slides ago that Debian tries to package everything apart from that whole free software thing. So some distributions very much want to steer clear of proprietary software but we kind of have to acknowledge that our users want it and ideally we should be like mitigating that and protecting the rest of the system from deficiencies in the software that we can't fix. Hey, wait, we have sandboxing. Good idea, right? And I was talking about free software there but sometimes it's not even about freedom, it's just about quality which, you know, you might think of the same thing. Some software is really niche and maybe it doesn't make sense to package it for even Debian but you want it anyway. Some software is, to put it bluntly, really awful but maybe you need to run it anyway because it does something critical for your job or whatever and surely someone packaging it is better than you can't have it. Particularly if you can sandbox it to mitigate if they've done it wrong. So one thing that you get with Flatpak if you choose to enable this is FlatHub which is the idea is it's like the App Store or the Google Play Store equivalent for Flatpak. You don't have to enable it but the expectation is you probably will and it's a good place to get a lot of stuff. So there are some reference runtimes targeting common library stacks. There's upstream software packaged by the upstream developer themselves which is like the ideal case. We want upstreams to maintain their own because they know it best, hopefully. And also software that is not packaged by its upstream, maybe even proprietary maybe even non-distributable packaged by the community. This is all tagged with license information so if you're worried about like Debian free software guidelines or whatever you don't have to display all the proprietary stuff but you can if you want to if your user opts in and in some cases FlatHub isn't actually allowed to redistribute things but what they distribute is a script that knows how to download it. So for instance this is how the NVIDIA drivers work I believe that you install a sort of stub Flatpak which then goes and gets the right driver for you. So hopefully distributions would quite like to have Flatpak. Distributions can also help Flatpak out. The most obvious thing is make it easy for your users to get it. If your distro doesn't ship it then you're kind of stuck. Also the portal mechanism which I spoke more about yesterday you really need the portals to be available on the host system otherwise apps will just not work because it's like okay I will go and browse for a file and wait the file browser is not there no that's not going to happen. So for distributions where their policy allows following the stable branches provided by Flatpak upstream is an excellent plan. I'm doing that where I can in Debian. Backporting the latest versions can be a good move too. I know I said backports were terrible but in this case kind of a necessary evil. And some other components are picking up support to be used kind of like portals as a way to get like controlled access outside the sandbox without giving like blanket access to everything. So I'm currently working on some stuff for Debus Demon which will come in in the next year or so hopefully. There are some plans for improving how deconf works so it can behave a bit like a portal that kind of thing and if your distribution makes those available great. Runtimes Runtimes seem quite familiar but because they are essentially a distribution. So and this is the distro's dev room we know this right? We know how to put together libraries that are compatible, apply security updates not regress we hope. So maybe having distros be like a curator of this is a good runtime with compatible versions of GNOME is a good move. Another thing distributions are often very good at because they've kind of had to be is making sure you're complying with all the relevant licenses. So Flatback Builder helps you with this because when you build your app or your runtime it makes another distributable module alongside it in the same Austria repository which is the corresponding source code. So whatever it compiled it commits that as well so that if you just blindly async the result to your mirror you're distributing binaries and you're distributing source for those binaries. But obviously not all our upstreams are amazingly good at complying with their licenses and sometimes there's licensing oversights and missing copyright notices and whatever and some distros are more strict than others. So ideally if you're fixing this sort of stuff in your distribution please tell your upstream about it if you can get that fixed once there we all win and less time rummaging through licenses and hitting our lives. So as well as runtimes distributions might be a good source of high quality apps and in particular not all upstreams get their apps right like some upstreams naming no names are not very good at releasing security fixes. They'll commit them to get master and then never do a release and distros pick up the slack there. So hopefully we can do the same for Flatpak provide good apps so Fedora I believe are planning to essentially take all their leaf packages mechanically turn them into Flatpaks publish them. So yeah ready made source of good apps hopefully and other distros I'm sure can help with this sort of thing. Fixing apps yeah I talked about security fixes but just any serious bugs really same kind of thing send stuff upstream so that it gets into all the other distros and it gets into the Flatpaks that will help a great deal and if your upstream developer is not helping you out with this maybe rooting around them is kind of necessary and talk to the other redistributors of your app and try and get stuff fixed that way. I was going to talk a bit about places where you can't use Flatpak but I don't think I have time for any detail on this but basically if it's not an app it's not Flatpak use a different tool and I can talk about this more afterwards if people are interested. Thank you.