 So, we've got the first talk of the afternoon part of the desktop pack. So let me welcome Mathias Klassen here, the long-time GNOME contributor and desktop engineering manager in AdHat, who's going to talk on Flatpak, the new way of distributing applications on Linux. All right. I hope you can all hear me. Is this loud enough for the back row? Otherwise, there's some seats down here if you want to come closer and heckle. So thanks everybody for coming. Yes. As Jerry said, I'm Mathias, and I'm going to present Flatpak here today, and I hope to explain why we don't think that Flatpak is a threat to distributions, but actually a good thing, and I want to show some of the technical background, and hopefully I'll get to some fun live demo at the end. And before I start that, I want to say that Alex Larson, who works on my team, is really the driving force behind Flatpak, so if you like anything you see here, you should praise Alex for that. If there's any mistakes or anything goes wrong, you can blame me. I'm just cheering him on. And with that, before I get going, I wanted to ask one question, a quick show of hands. Who is actually, who is the Flatpak installed on their system right now? All right. That's quite a few. That's cool. Thank you. And I also wanted to mention that this down here in the corner is the Red Hat West Hot Office. It's not the most exciting place in the world, but it's good for decorating slides. So I want to start by talking a bit about history and how we all came to be here. So why do we have Linux distributions? Not everybody wants to bootstrap their OS from first principles and start by cross-building a tool chain and then compiling their own kernel and then getting to G-Lipsy and moving up user space. People used to do that 20 years ago and it was exciting and an achievement. But nowadays people actually want to use their computers for doing non-computer stuff. Everybody here in the room, of course, excluded. But in general, for instance, an artist may want to use the latest GIMP or Inkscape to do some artwork. And it's not really interested at all in how the computer works underneath. And Linux distributions have emerged as an answer to that need, basically. They make Linux usable by non-computer geeks and normal people. And so that's certainly a good thing. And I work for a company that makes several distributions and so I can certainly see the benefit of that. Nevertheless, there's some downsides to the distribution model. The value of software must come from a single source and that's the only place you trust and you're kind of limited to what that place has to offer. And so Linux distributions have kind of packaged up the whole world of software. I think Debian has well over 20,000 packages and Fedora is not too far behind. And there's some scalability problem there. Every package needs a maintainer or more than one. And also, for instance, non-free applications are pretty much entirely left out of this. And you're pretty much at the mercy of finding a packageer who shares your interests and wants to package that special purpose or fringe application that you might have an interest in and you might just be out of luck and it may not be available. Looking at this from the perspective of an application developer, there's some problems here as well. So you've written your code on your system. You managed to build a binary from it on your system and now you want to get it to your user without further delay and without any holdups. You also want to hear back from your users, maybe even in the form of payment. And for all these things, having a distribution in the middle is mainly just an obstacle. So it's not ideal. And how do application developers work with that? You could either try to find a distro package that is interested in your application and packages it, but that's a bit of a chicken and egg problem because how would the packages know about your application if it's not in any distros that they haven't seen it anywhere? So that's a problem. And if you decide to do the packaging yourself as an application developer, where do you even start? Do a bit in RPM, do a bit at that, do a target for 10, 20, 30, it's really difficult and once you've settled maybe on one choice and you did it, you put your package in the distro then it'll break in short time because some dependency underneath your application was updated without you knowing about it and being able to do anything about it. So that's really hard. And that's why there's not really much of a third party application story for Linux because it is just too hard and people don't bother. Now we don't really need two and a half million desktop applications for Linux, I think, like Android has in their store, but having more than a few dozen might be nice. So switching gears and talking about flatback now. Distributions are valuable, but they don't really have a good answer for you get a lot of applications available, I think. And flatback is the result of us taking, Alex taking a hard look at this situation and trying to come up with better ways of developing, distributing and running desktop applications under Linux. And it's important to stress here that flatback is meant to be an evolutionary approach. We don't want to do a revolutionary thing where we force everybody to rewrite the applications and so away all the desktop infrastructure we've built up over the years. We really want this to be evolutionary and try to preserve what we have and what is good while making some things better. So the main goals that we have with flatback are these. There's, of course, others, but I'll try to explain these in a bit. But what I mean with cross distribution deployment is two things. First of all, ideally we want an application to be built once and to be able to run the same binary everywhere it needs to be run and testing on a user system, using a modern OS or on a user system, using an ancient OS. That's an important aspect of it. We want our users to be able to run new applications on an old OS. Like a prominent example here would be to run the latest web browser on Route 6, which can be a problem. Sandboxing is necessary because we want our users to try applications without necessarily having to trust the source fully. And so if you run an untrusted application, you better have some kind of protection for the rest of your system, that's what sandboxing is about. And the third point, invisible to the user, we want the flatback applications to appear just like applications always have on a Linux desktop. They should be fully integrated in the desktop menus or the shell overview. They should have their icons and be fully integrated in all the ways that you expect a desktop application to be integrated and behave. The last point is about being able to run the latest of what your particular interest is, like some niche application or your special interest, without having to rely on finding a distribution package that shares your interest and makes this application available to you as a distro package. And as an example for that, Telegram 1.0 was released like a few weeks ago, and I used Telegram as a flatback on my system, and I was able to have Telegram 1.0 on my system in less than 24 hours after it was released on GitHub, just by having a flatback available. And it was pretty nice for me. And of course, a distro package I can provide the same kind of turnaround if they are really interested. But with flatback, we hope that the upstream for the application might actually do the work themselves, and just because they have an interest in getting the application out quickly, so if they provide the flatback, you can cut out the middleman. Any idea what's going on here? Didn't really touch it. Just turned off. It's kind of unusual that the accident happens before I get to the demo, but there you are. This was kind of an open. Good idea. Let me see. I guess I could just try to keep talking without my bullet points here, and I'll try to explain what's going on, what would be going on on the screen while I'm talking. Although I had some fun pictures that I would have liked to show, unfortunately. That might not happen. So I wanted to switch gears here a little bit and talk a bit about the technological background, how flatback actually works. And I was going to start by saying that flatback, we try to avoid the word container when we talk about flatback, because Docker containers are really focused on server side applications, and configuring Docker containers is all about network ports, and storage, and those sorts of things. And for desktop application, you really care about connecting to the X server, and presenting dialogues to the user, which is really quite different as a focus. And another important difference is that Docker containers run as root, and your desktop applications, you want to run them in your session with your user ID. It's another important difference. So we try to avoid the word container when talking about flatback, but still under the covers flatback, as we're using all the same technologies, the current technologies that server side containers are using. The first one to mention here is namespaces. The most important one is we use a mountain namespace to hide the actual host file system from the application in the sandbox, and provide a tailored view of just what we want the application to see using a mountain namespace. We also use some other namespaces, like the pit namespace, and the network namespace, and so on. But the mounting is really the most important one. We do use C groups occasionally, optionally, if a system, the dash dash user, is available. It's not required anymore, so we took that hard requirement out because we want to be able to run flatback on older distributions where a system, the dash dash user, might not be around. We also use SecComp, just because it makes sense to reduce the attack surface, and because we can. And another aspect of what we do is bundling. Bundling used to be like a bad word in distribution circles. You couldn't really even say that here. I think we've overcome that by now, and accepted that bundling is a fact of life, to some extent. And it actually does provide concrete advantages for application developers to bundle their dependencies at some level, which is why almost invariably, if you look at third-party applications, they do that. They bundle what they need just because it gives them advantages. The bundling is, in effect, what lets us separate or isolate the application from the US. Of course, there's a cost to it. The cost is that we have a lot of duplication. All those bundled libraries are duplicated in all the applications that you have installed, at least in all the ones that use the library. And then, if there's an important bug fix that needs to go in that library, how do you find all those bundled copies and update them? I want to give several answers to that question. The first one is, hopefully, you tested your application bundle with that library version included, and the application worked fine. So maybe that bug that was found in the library doesn't actually affect your application, and then the fix is maybe not that important for you. But maybe it's a security issue, and the answer to that would be that we hope that the sandboxing helps mitigate that a little bit. If there's a security issue in the library, then hopefully the attacker can maybe attack the application that's running inside the sandbox, but the sandbox is protecting the rest of your system from that threat at some level. And the last answer is that we actually, we do want to limit bundling as far as we can, as far as practical. Because bundling all the world is not necessarily fun. In the Docker world, you start by using a base image, and you hope that works well, and it's well tested, and then you layer on top all the dependencies you need, and you end up with a single image, which has all your dependencies in it. That's not very practical for desktop applications, because our library stacks tend to be quite a bit deeper, so we'd end up bundling quite a few things that way. So we came up with an alternative for that, which is called the runtime application split. Effectively, what we do is we run a flat pack, we put this file system view that I've talked about earlier together from two pieces. We mount the application itself in the slash app, and then we have a separate thing called the runtime, which is essentially a slash user tree, which we mount under slash user. And those pieces together form the file system view for the application inside the sandbox. And yeah, that's that. So in effect, a flat pack application has a single dependency. It needs to declare which runtime you need to use to run it. And the advantage of doing it this way, of course, is that we have this runtime as a separate entity, and we can update it independently. Oh, that's exciting. And in this way, we preserve some of the advantages of the package world, where it's all about having things split out and being able to update them independently. Yes, question? Yeah, I would have shown examples here. I'll try to talk about them. So I'm interested in the radio. Right. So as an example, we do have something we call the GNOME runtime, which essentially contains the entire library stack for GNOME applications. So everything up to GTK and then some other libraries as well. So most of the GNOME applications, you can build against that runtime and don't need anything, any bundling at all, because all they need is in there. Yeah, LibreOffice would need to bundle things they need, like file format libraries or something for Office file formats that would have to be bundled. Yes? Is that the step-by-step application that I, on a common format, would not need that flat-pack? No, not really. I think flat-pack addresses are somewhat different. I mean, even if you had a single package format to rule the world, it would still be like a package that would be in this distribution mindset where you split things up atomically. I think an important aspect of flat-pack is that we do these more granular bundling of bigger pieces, like we have the application and the runtime. And that's the only two pieces here if you don't have this myriad, this whole dependency tree of individual packages. I think that's an important difference between packages and flat-pack. I think you still want to have that. Just not sure if there's a runtime that includes Java currently, actually. We do have a few runtimes built upstream currently. Like we have, as I said, the GNOME runtime. Somebody built a KDE runtime, which has the KDE libraries in it. There's a free desktop runtime, which is more minimal, has less in it. And there were people building various other runtimes for that include more things. I should maybe say that it's not necessarily always the best thing to have your customized runtime. It's perfectly OK to bundle a few things with your application. Java might be a bit bulky for that. But in principle, it's totally fine to have things bundled with the application. OK, yeah, I'll put a URL here if I could. But there's a flat-pack website that has links to basically all the stuff that's available currently, including all the runtimes and all the applications that are packaged as flat-packed. Are we out of luck here? I think that all of the other systems like we think the war is going to be. OK, well then, I guess that would be difficult for my demo later on as well. That's too bad. Well, I'll just soldier on here as far as I can. Yeah, I was going to talk next about the build aspect of this. So how do you actually get built an application so that it uses a particular runtime? Like, the runtime includes libraries. Mainly, that's what, for instance, the GNOME runtime contains all the GNOME libraries. But if you want to build something, you need more than just the libraries. You also need header files. You need debug info. You need tools like compilers and debuggers and profilers and whatnot. So we came up with an answer for that. And that is we introduced the concept of an SDK, which is essentially just like the runtime. Only bigger, it includes all the pieces you need for development. Or looking at it in another way, basically, the runtime that you use to run the application is just a stripped down version where we took out all the development pieces. And there's still this SDK that you can install, which has all that. Yes. So I talked about, like, Flatpak, when you run the Flatpak application, you actually run it in a special way. You run Flatpak, run your application. And Flatpak sets up this sandbox for the application to run and talk about how it mounts together the file system view. But there's other things that it does. It also provides a proxy to the connection to the session bus. Do you find Docker? Do you find Docker? Well, a little bit, yeah. I mean, Docker does similar things for container. But we do a specialized sandbox setup that is necessary for desktop applications. And one thing that it does is it provides a connection to the debus to the session bus. And it's not just a plain connection, but we run a proxy that filters what you're allowed to talk to and what you're allowed to see, just because we want to have sandboxing there as well. All right, I was talking about building. So you have this SDK. And for example, if you were to build a KDE application, that you want to run against the KDE runtime, then what you would do is you would install the KDE SDK and use that and develop your application against it. Flatpak includes a command line tool, which is called Flatpak Builder, which uses a JSON manifest to let you build the application and all its dependencies in a fairly neat way. It's kind of versatile and convenient as a tool. But it's a command line tool, and that's not for everybody. So we also have Flatpak support in GNOME Builder, which is a IDE that is well-suited for building desktop applications, I would say. And with the latest stable version, 3.22, the Flatpak support in GNOME Builder is actually pretty good shape, I would say. So you can use things that way as well. And moving on, talking about more technologies. I'll be waiting for slides to come back. We use OS tree for the local storage and delivery of our content. You may have heard of OS tree in the context of Project Atomic, which is where it's also used. OS tree is a bit like Git, but for file system trees and that contain binary content, that's what it's optimized for. And Project Atomic uses OS tree for the whole OS. And we just use it for smaller trees, like for the individual applications and for runtimes. It gives us a few advantages. It gives us automatic deduplication of the content because it uses content addressing. So if a lot of applications bundle the same library, then we might be able to share that under the covers just because it's the same content. It also gives us atomic updates. So we never see a partial file system tree if you run flat pack update. And the content is only put in place when the whole tree has been updated, which also means that it's safe for us to update a running application. And we can also allow online updates for flat packs in Chrome software, which is something that made a lot of people upset when we stopped doing that for regular application. So it's great that it's coming back. Yeah, I think I'll skip talking about AppStream because there's not much to say there. In terms of security, traditional Unix security is nowadays relatively irrelevant on a single user laptop. There's no other Unix users to protect me from. So that's not really something we need to do. But what is important is to protect my private data from an app that might be untrusted that I'm running on my system. And that's where sandboxing actually helps us. It limits what the application can see. I already talked about this tailored file system view that we put together for the application. And that's done partially at least by we have some static permissions in the metadata for each flat pack application that defines which parts of the file system we need to make visible for the application and which one's not. But sometimes, of course, you do want the application to work with your data because otherwise it would be pretty pointless to run it if it couldn't get access to any data. So there needs to be some way to do that. And for that, we have a more dynamic permission, a way to handle permissions in the form of portals. Portals are services that are running in the user session outside the sandbox and they provide D-Bus APIs for the application in the sandbox via the session bus. And the way they provide, the way they make this interaction safe is by basically always keeping the user in control and expected part of any portal API call is that there will be some user interaction and the user gets to decide whether to go forward with this or not. As an example, if a sandbox application requests to open a file and do something with it, then what it would do is it makes this call to the file chooser portal to open a file and then the portal presents the file chooser dialogue. And since the portal is running outside the sandbox, the portal has a unfakeable way to identify which application that is so it can actually present that as part of the dialogue and say, here application who wants to open file and then the user gets to use this file chooser to select which file it wants to make available to the application. And again, since the portal is running outside the sandbox so this file chooser has the full file system available to it. It's not limited by what we show inside the sandbox. And then the user can make a selection or he can also cancel the dialogue. And after that is done, the portal will make just this one file that we selected available to the sandbox application via a fuse file system. So there's no way for the application inside the sandbox to get access to other stuff. There was a question there. Yeah, I mean, there's no pros and cons to how you do it. I think we ended up doing what we do now because we wanted to have an API that you can even use just as POSIX calls mainly and the application doesn't really need to do much special. It's just a fuse file system. So you can basically use whatever APIs you want on it. And there were various technical reasons why this approach is better. Don't want to go into details there. All right, so that was portals, what next? Right, so I talked earlier about how we are reusing all the kernel technologies for containers. And that's a good thing to reuse things. And we also want to be good citizens and try to reuse things in higher levels in the sec. And there's a lot of effort being put into setting up build systems and registries for containers. And that's, of course, like the main focus of this conference to work on this container stuff. And inside Red Hat, a lot of this effort is centered around what's called OCI, the Open Container Initiative. And that's a vendor neutral specification for Docker containers essentially. And we want to be good citizens and we use as much of that as we can. And so with Flatpak 0.8, which was released around Christmas, I believe, we actually support storing Flatpak applications inside OCI images. And you can install them from registry. And yeah, we will be able to reuse a lot of the good things, the good effort that's put into that stuff this way. And we also, just at this conference, we also talked to the CoG team and the Fedora release engineering guys to figure out how we can integrate Flatpak building into our build system. That's something that we still need to sort out, but that should happen within the next release or two, I think, would make it easier for us to build Flatpaks. Which is something that we want. I was going to show a slide about the roadmap here at this point and what's coming for the future. So there's actually quite a bit of interest in Flatpak from other sites, not just inside Red Hat. There's a company called Endless that you may or may not have heard of. They're building laptops and using, and an OS for like third world countries. And they're using OS3 for the OS itself and they're using Flatpak for their applications. So they are very interested in that. Recently there was an announcement from the Solos project that they also want to use Flatpak for their applications or applications in general. So we want the ecosystem of available Flatpak applications to grow. And we're working on that. Important piece for that is to have a stable runtime that third parties can actually rely on long term. An ideal candidate for that might be CentOS. But we also want to fit our runtime which will be well suited for like just converting applications that currently packages RPMs into Flatpaks almost automatically. So that's something we want to have in the near future. Right, and at this point, I was going to switch gears and actually present a case study of an application I've been working on recently and do a live demo. But I can't really do that, that's unfortunate. So I don't know how we deal with this. Should I just turn my left over on and we try to all huddle around this? I mean, it's a pretty full room to what I really want. Just an explanation that there is a problem in the projector system. And that doesn't seem to be an easy solution to that. So the technicians went for some additional help, but I'm not sure if we can fix this, save this talk. I tried to soldier on a little longer here actually. I was going to talk a little bit about this before I do a live demo, so I can still keep going for a few more minutes. So I started working on a cooking application a while ago and I had a lot of fun doing that. So I wanted to use that as a case study here to talk about how you can actually benefit from having Flatpak available for application development. And the live demo was gonna be the crowning end of this. Sadly, I mean, everybody's welcome, of course, to walk up afterwards and I can do a demo that way, maybe. So a little bit of history I was going to show first. I had this nice timeline on the slide. So I started working on this application end of October when I, after I finally received some mockups for it. And I think October 30 was the first day I committed something to Git. And then I put it on GitHub as a customer nowadays. And amazingly, I looked back in the Git history, my first commit already contained a Flatpak JSON file which used to like give the feet of Flatpak builder to actually build a Flatpak bundle. And right after I put it on GitHub, I also attached a Flatpak bundle as a release there on GitHub. So basically on the very first day that code appeared on GitHub, there was already a Flatpak binary there that people could download and test without building the application themselves. Which I think is a pretty good turnaround for like early testing. Yes, well, I mean, any effort in making builds for producible will help for that. But the question was like, if there's any particular provision for making Flatpak builds for producible, I guess the answer is no. I mean, in general, if builds are reproducible then Flatpak builds will also be reproducible. And anything we do to make builds more reproducible in general will help us for Flatpak. And it would be a good thing because the more reproducible the builds are, the better like the deduplication and sharing of content on the file system will work for us. And I guess it's just a good thing in general. Yeah. So I was talking about my timeline. As I said, end of October is when I first put some code out there and then I got more into this project and did some updates of the Flatpak bundle throughout November and December. So people could actually test the latest. And in early December, Alex figured out how to actually put a Flatpak repository itself on GitHub. So we did that for the recipes up in early December. And then on people could actually update their Flatpak install because if you have a repository you can just run Flatpak update and it'll update. And all this was like well before I had put out the first tableau release that only happened around Christmas and also well before the application is available in distribution. It's not even packaged now. So this is kind of a success story, I think for making things available for early testing without forcing people to build this all themselves. Yes, that was a question. How do you fix something or break your Flatpak stuff? Well, I think, yeah. And the system needs another. Yeah. Yeah. Fixed kind of version and the user can update it. So I guess there's no magic answers here other than that the kernel guys in general are pretty good about preserving compatibility and not breaking user space. And if something breaks then you generally have a pretty good case to make the kernel guys fix it on their side. So I'm not too worried about the kernel stuff breaking. There might be other things that are more very summing user space. You mentioned system B. But I think we're using, we're fairly conservative in what things we're using in Flatpak for setting up things. And so far we haven't had big issues here. But remains to be seen if there will be an issue like this in the future. I don't think there's a magic answer for that. Right, so I was talking about history and. Yes. They run outside of the. Yeah. The flatpak container. Which implies that there's something to try. What? Is that available in any OSes in Fedoro and do you expect it to be on? I believe we have packaged all that stuff for Ubuntu and Debian as well. Yeah. There's a PPA at least. Well, you need a Flatpak itself installed. That's the command line tool that is used to set up the. Well, it's the single command line tool that we have which does everything. Like it's lots of commands for installing Flatpaks, for updating them, for running them, all that stuff is in one binary. And we need that. And then you need like this portal infrastructure, which is a separate package. And that's pretty much it, I mean, yeah. Yes. Most of them are included. So in principle, we don't really care how you get the content inside your application. I mean, it could come from RPMs. It could come from building from tar balls or building from Git. Flatpak builder, this command line tool that I mentioned is focused on building from Git. But as I also mentioned, we are working on getting this into the Fedoro build infrastructure. And that would probably mean that we would look at a way for building from RPMs. Yeah. So we're working on that and that will certainly appear in the future. Yes, I mean, the principle with the Flatpaks is that the runtime contains all the things you need or you bundle it. So if you have the application and the runtime, you should have everything that you need to run it. So if you run it on Ubuntu, you would probably have to download the Fedoro runtime tool because that's what it will depend on. But that's a one-time cost, right? You download it once and then you can use it for all the Fedoro applications that use it. Yes. Yes. Yes. But if you're a dependency that you're finally on top, is this the developer to? Yes, basically, I would say yes. I mean, it depends a little bit on how it's distributed, right? If you are building your own Flatpak as an ISV independent software developer and you publish it yourself, then of course you are responsible for updating it when there's an issue, right? Or you can ignore it and not update it. But if we end up with this Fedoro build system integration where we automatically rebuild application RPMs as Flatpaks, then it would be up to us to figure out a way to make that as automatic and convenient as we can if we discover an issue to make a rebuild happen. Like, we can trigger it automatically, maybe, or we can have whatever support we need for that. Right. So, getting back to my imaginary demo here. What was I going to talk about next? Right, sandboxing, portals. It can be hard to retrofit an existing application inside a sandbox because the application is written in certain ways that expect access to the full file system and things like that and it wants to write its content in a certain place that may not be available in the sandbox. So that can be hard and actually require work. But I started my application from scratch and I could basically make sure from the beginning that I'm a good citizen and write it in a way that works nicely sandbox. So I actually started using the portals right from the beginning and I was going to show a nice list of all the portals that I'm using in my application and it generally works nicely and it's fully sandboxed. So the recipes app Flatpak does not poke any holes because it uses portals whenever it needs to. And an interesting case I was going to mention here is actually one of the portals on that list that I can show is a portal for getting account information about the current user. Basically your avatar photo and your name and what else you want to show for a user. And that's actually a portal that did not exist when I started the application but while I was writing the application I discovered that this would be handy to have so I created a portal for that. And that's useful. It was also very useful to just test all these portals in a real use case. I found quite a few bugs that way and we fixed the portals to actually work. One portal we don't have yet unfortunately is a portal for sharing content out. That's something that applications weekly want to do. You want to like publish a recipe on I don't know where Telegram or send it via email to your friends and we don't have a sharing portal yet so that functionality is not implemented in the application yet. We do have an almost existing portal for access to like the sound. Sound product to pause audio essentially which is like the sound hardware and of course we make the graphics hardware available to you anyway and there's nothing for like more specific other hardware. Would be interesting to explore maybe if you have an application that would need something like that I would recommend to like actually work this out in a concrete example to see what the application actually needs and what form that needs to have. Well the clipboard is part of the display server connection usually so you get that if you can access your X server or your Wayland compositor. Right I was going to talk about bundling a little bit as well. So this recipes app does not have too many dependencies. Basically just use this GTK but then at some point I added export functionality so you can actually export your recipe. It gets wrapped up in a little tar ball and put somewhere in the file system and for that I used a library called Knome AutoR which is fairly new so it's not in the Knome runtime. So that's an example of a library that I actually bundled with the application now just because it's not in the runtime. A little later I then decided to add spell checking as well using Gspell which is also not in the Knome runtime so that's another thing that I added to my growing list of dependencies. And yeah I would have shown how that looks in the JSON file but I can't. And yeah at this point I would have switched to doing a live demo of showing how you actually built this thing with Flatpak builder and then you install it from the repository that you create and then you run it and it's really cool. Yeah. So I will invite everybody here to like find me at some point outside or here later and see this on my screen if you want. No I don't think you do. Actually I'm not 100% sure about it. Do you use a name? Yeah. I can just look at mine. We see that this is just for the site you see here. Yeah you actually see Etsy here. Yeah. But maybe Owen already answered this question. I don't know. Yeah that could be. We do generate some dummy files inside Etsy for like stuff that needs to be right in some blocks. Yes. This actually builds for ARM. I mentioned this company Endless earlier. The laptop at least one model of them was running on ARM. So they have ARM runtimes and working ARM ecosystem using Flatpak. So that's at least there. Yes. That's up to the user to do the snapshots and make sure that they're not great. Well at the end of the day I think it's up to the application author to make sure that they can deal with data that was produced by an earlier version. If they don't do that I mean you can just I guess remove a link. What we do for storing data persistently is we get like if you have a Flatpak that's in a sandbox we make a small part of the home directory like it's .var slash up slash the application ID. That's the part of the file system that the application actually gets to write in. And we set the XTG environment variables to like point into that place. If you use like library APIs and you'll find the right place so that you can actually write content on the file system. And but then it's up to the application to make sure that it understands the content that's there and can deal with updates of that. Yes in the back. The libraries are patched to the water. I didn't catch that. For example. Oh yeah. That's a good point actually. Yes. That's a very good question. So we do try to hide the portal like API interaction like we don't want necessarily we want this to be evolutionary so we don't want you to rewrite your application necessary to talk to the portal directly if you can avoid that. What we've done for GTK is that we actually for instance the file chooser portal is something that GTK can just use transparently for you if you use the high level GTK API for opening a file. We can translate that and do the portal call for you. That also works for a few other things like the printing portal. We can transparently use that if you use the high level GTK printing API. And there's a few other examples like that where we can just hide the portal interaction inside the library which is the ideal case because then the application doesn't really have to be touched at all and it just magically works. And that integration is in the current stable GTK release GTK 322. And we also have somebody working on doing similar things for QT and KDE. Now there's certainly other portals where we don't necessarily have a suitable library API to hide that under. For instance I wrote a portal that lets you just take a screenshot and there's no like give me a screenshot library function so if you want that then you'll probably have to do a debas call. But we're also looking at possibly providing a simple wrapper library that just gives you a C API for each portal because it's just less of a hassle because as I said these portal API calls are all they expect to like do user interactions so you kind of have to do them asynchronously so not block on that. And then you have to do all these async annoyances and hiding that behind the library API is a little nicer. Yes. Well, this is upstream GTK. Like GTKs are just supporters nowadays. If GTK detects that you're running inside a flat pack sandbox, it'll just do the right thing. It's an upstream GTK. Yes, that's an upstream GTK. And it'll also be an upstream QT at some point. Yes. No, no. The expectation for the runtimes is that we keep them stable so you'll be able to update the runtime and the application should not break. If it does, then somebody who updated the runtime did something wrong in the back. I don't know, I certainly haven't talked about that. Maybe that's an interesting idea. It hasn't been brought up before, but it could be possible. I don't know. Yes. You create like a unit without a GUI that just runs as a service or is it just desktop? This is really focused on desktop, yeah. So why distribute with the port like I've heard other talks about system D running Docker containers for services and then this thing running code with the same stuff but for desktop, why use like two systems and not main part that covers everything? Well, at your application, they start from one source, the other has to install from another source and then they're all universal, but you have to use this tool for Apache and this tool for your web browser. It's called universal. Right, it isn't. No, there's no single container. There's no single container definition. Everybody knows as their own definition of what a container is. That's part of the problem here. The kernel doesn't define what a container is. It just gives you a bunch of disparate APIs that you can use to put something together and Docker has done that, we have done that and but there's various points to my talk. I talked about some answers to that. Like one answer is that what Docker does for server containers is actually pretty different from what we do for desktop applications and they are just different things and before Alex worked on Flatpak, he actually worked on Docker support and it is really hard to get things into Docker that are not necessarily 100% aligned with what they are focused on. So it's just not realistic to think that we could like get a few tweaks into Docker to like make it work for desktop applications. We need to have our own thing. But as Dan says, we are trying to like inject some of the things that we care about into like the wider ecosystem. By breaking up Valorab is one example where we're trying to like have this non-route way of setting up containers that's interesting outside of the narrow Flatpak world. Another example is that we're actually using OCI now. I guess we are the first adopter actually of the OCI spec on some level. We can actually run OCI's, nobody else does that. We try to like fit in as where we can but the use cases are just different enough that it's unavoidable that we have to do some of our own things. Right, so let me see what answers I have for that. About the multiple desktop files, I think you can do that. I think we solved that for LibreOffice actually. I think the bigger problem there might be on the GNOME software side where there might be assumptions about having a single application for each app ID, I'm not sure. And for the command line thing, you can actually run the Flatpak, as I said, the Flatpak command line tool is what sets up the sandbox for running the application. So when we install a Flatpak, we install a desktop file and then we rewrite the exec line in desktop file to say Flatpak run your application. And you can use Flatpak run on the command line yourself and you can say, you can actually specify that you give it a, you can give it a command to run instead of the application and then you can get a shell that's running inside the sandbox for this application. Like, you set up the sandbox but then you run just a shell in it and then you can use the command line whichever way you want. There will be one way to use Inkscape as a command line tool even inside the Flatpak. Yeah, that might be in. I think there's some. I think I would, yeah, yeah. All right, I think we have time for one more question, maybe from Dan. Let me see if I can do that. The question was about help apps. Running Firefox. Yes. So the Firefox is running inside a sandbox, I assume. So I would assume Firefox is a good citizen and it calls the portal that we have for that. It's called the OpenUI portal. So you have this doc file, I guess. So you would just make that available to the outside world by putting it in the document portal and then you would call OpenUI and then the OpenUI portal is responsible for finding the right handler for that. The OpenUI portal does the right thing. They're like, basically, what happens is the Firefox makes this doc file, puts it in the document store and then the OpenUI portal lets the user choose which handler it wants. There could be another sandbox application and so then the portal would basically make sure that that sandbox has access to the file it needs to show. So we tried to do the right thing there. Can be a little fiddly at some spot, it works mostly. I think that was the last question I have time for. Thanks all for coming and sorry for the mess up. It really sucks this. Yeah, it's good, it's such a nice demo. But we're trying to work to possibly improve.