 and I do a lot of different things but recently I've been working on figuring out how do we take flat packs and build them within the store infrastructure and out of our content. My talk is titled as a tutorial how to make application into a flat pack but it's going to be a couple of different things. I first want to just provide a general introduction to flat pack to those who are less familiar with that. We'll discuss a little bit about how we are looking at putting flat packs in Fedora and then go ahead and walk through one example of actually what a Fedora flat pack looks like. I'm not going to spend a lot of time talking about the back-end infrastructure details, how we build flat packs in Fedora because I think if you care about back-end infrastructure you're probably at the factory2o.o talk rather than this talk. So just sort of talking a bit about the basic idea behind flat pack. This picture represents the traditional view of a Linux operating system. It's a unified whole. There are lots and lots and lots of components within it. A lot of them are very key like the init system or your display server, the kernel of course. There are libraries that all these components pair depend upon in a shared fashion and then you have applications and generally we package applications the exact same way as we package all these system components. There is no real distinction between how we package the GIMP and how we package system D. So that causes a number of different problems. One is that when we look at these very core system components we think they should actually be integrated very deeply with the operating system. We expect that there will be a lot of dependencies and we wouldn't expect that you could take the Fedora 26 version of system D and swap it out for the Fedora 27 or system D and things would just work. There are also a lot of dependencies on the actual distribution that Fedora package is going to look a lot like Debian package. Those things to gather make it very, very, very, very difficult for somebody who is external from the distribution world to make a package for distribution. They actually have to know exactly how the details of that system work and you know there are, you know, because packages are tied to particular versions of picker distributions in order to reach a significant fraction of the lense community you have to make a very large number of packages and update them continually. That's not just not really feasible. But beyond that their security model here is not really what we want. If you have creating the GIMP at the same level system D then we certainly don't have security installation time. The GIMP package can replace any files in the system. It can change your your system configuration. It can drop new files into ads. It runs in fact scripts as root. But also at runtime we don't have any barriers there. We can't, if you have the GIMP running there it has access to all the system, the files in the user's session. It can sniff your bank passwords, access your webcam. Everything is bad there and that's because we simply are trusting the application author we have to say I think this application is perfectly good. But that's not usually a real world situation. We usually want to say well I somewhat trust that this is application. I trust the GIMP to edit my image files but I'm not gonna trust it entirely. I don't think it needs to also have access to my bank passwords. So we like to be able to create security boundaries around applications. And that's simply not possible in this traditional model. So the evolution of that is we're gonna say okay we're gonna make the operating system integrated whole and we're making applications separate integrated holes. So they won't use the same libraries as the system. They will use their own set of libraries. And that then allows us to upgrade applications independently to create security boundaries. But then we have copies of libraries in every application separately. And that's something that's less than ideal. It causes duplication of disk space. It causes extra memory usage. And it means that if there's a security problem in our library then you have to update every application independently. So the idea that Flatpak takes is to have a runtime which is essentially a set of libraries that we pack up independently from the operating system. And instead of having application depend upon the operating system libraries depends upon our runtime. Now if we had only one runtime in the system we still have a problem. Because then when I switched from the Fedora 26 runtime to the Fedora 27 runtime I'd have to update every single application. So it's even better if we can have multiple runtimes in the system. We can say we'll have a Fedora 26 runtime, we'll have a Fedora 27 runtime, and maybe if I want to run an application that was built against Debian on the Debian runtime. So this is sort of, this is the picture of the Flatpak application model. Mobile applications separate from the operating system depending upon mobile runtimes. When I say applications I want to be clear that I mean desktop applications. Flatpak has a limited target space. I mean something like Libre Obviously again or TuxtCard or even a proprietary application like Google Chrome. But I don't mean a server like MariaDB. I don't mean WordPress. I mean WordPress is an application but it's not a desktop application. I don't mean a command line tool like VI. And I mean the reason for this is that if we say we're handling desktop applications then there's a lot of specific problems at those address. Like how do we open a file securely. And there's a set of interactions with the user that involve a user interface, a GUI, and those are really distinct problems from the problems that I want when I'm just playing a server somewhere. Okay so that's a model. Where are we going to get Flatpaks from? Well one of the goals of the Flatpak projects is that Flatpaks can come from application creators. If the GIMP project wants to release a binary of the GIMP, Flatpak provides a way of writing that across distributions and makes it feasible for them to do that. If a proprietary software company wants to release a binary for Linux, they can reasonably do that without creating 20 or 30 or 50 binaries. But that's not the only place we expect to have Flatpaks because there's actually some real benefits from taking distribution packages and putting them into the Flatpak. We still have these upgrade and advantages. We still have this flexibility where we're taking application and split it away from the operating system and we still have the security there. So that's what I'm going to concentrate on talking about today is how we build Flatpaks out of distribution packages and less about how somebody upstream could build a Flatpak right directly from source. And the same displays for runtimes. There are upstream runtimes that have been created to get Flatpak going that are built on a Yachto base and there's a generic free desktop runtime, there's a GNOME runtime, a KDE runtime. But once we start looking at making Flatpaks out of distribution packages, they will need a Fedora runtime that's built out of Fedora packages. So we're going to talk about how we build the create the Fedora runtime and use that to build Fedora Flatpaks. And as I said, with those we still have the advantages that we can... So I guess the question then is why do we want to build Flatpaks out of distribution packages? Why don't you just want to build everything from source upstream? And I'd say that there are sort of three major reasons for that. Why the idea of building Flatpaks out of Fedora packages makes sense. First, there's not always an active upstream. There are say roughly a thousand graph applications package in Fedora. You know, a good number of those have active upstreams. Other ones haven't been touched in three years, five years. But we'd still like to have somebody to build them into Flatpaks and that the Fedora packages are a very natural community to do that. There's also we actually have a distinct build recipes. We have the definition of what goes into the application, what packages are required, how you build it from source. We'd like to reuse that information as well. And then finally and very importantly, Fedora has a security update mechanism. When there is an upstream CVE, we track it into a package, we listen to the package, and we build updates from it. If we're just building Flatpaks out of source, that mechanism isn't there. And so we would like to take the Fedora updates mechanism and say, when there's a openness to sell security vulnerability, let's find all the Flatpaks that include a package, that openness to sell package, and automatically rebuild them, automatically release them so that the person doesn't have, people containing the Flatpaks don't have to individually worry about all these individual security holes. So I wanted to talk a little bit more about how Flatpaks work on a security point of view because I think that's an important thing to understand if you're, you know, learning how to package a Flatpak. So my default, a Flatpak, if you don't give any extra permissions, has no permissions. The default state of a Flatpak is you can't talk to the outside world. You can't talk to the network. You can't access any files. You can't open a window. But default is basically entirely useless. But then, so you have to start giving it some permissions. And there's a set of permissions which are sort of considered safe permissions. The ability to go out and talk over the network to external servers is a pretty safe permission. The ability to talk to the Weyland display server, which is a secure protocol, is a safe permission. That, just those two permissions by itself would allow you to do some set of applications. But you often want more deep integration with the operating system. Like you want to be able to read the user's files or use the webcam. Well, we can define other questions which are unsafe permissions, talking to the external evidence play server or reading any app out in the user home directory. Now, so if we give an application those permissions, then it's only broken the sandbox. At that point, the application is not sandboxed anymore. That still actually is not useless. If we want to take an old application, we basically have to do that to package as a flat pack. We can't require an application to be rewritten to use entirely new models. So we can still get the sort of packaging images of flat packs by running out on sandbox as a flat bottom pack. But we also want to find a secure modern way of doing that. And this is something called portals. So what you can think of permissions is being punching big holes in sandbox. Portal is a very, very targeted hole in sandbox that has a specific design for the purpose deepest interface that was designed to have security in mind. And usually the way that security is added is by involving the user into the flow. If we think about opening a file, we don't want to say does this application have the permission to access any file in your home directory. That's a very big hole. Instead, when the user wants to open a file, present a file dialogue, and when the user selects a file, by selecting that file themselves, they implicitly giving that permission there for that one file. So if we can involve the user into the flow, then we've made a much more natural and a much more limited way of giving permission for that to do something. There aren't, you'll need a whole lot of portals. The ones that sit there, the file brand, show a web page, get the network status. Those are, there's a few more existing currently, but those are the ones, those are almost a complete set. You know, we expect there to be roughly 10 portals in the, even as a backpack of balls, not 100 or 200 portals. Portals, the portal system that the backpack implements has mobile backends. So if we open a file dialogue, and you're running within the KDE desktop, you can get the KDE file chooser instead of the GNOME file chooser. This could be extended with other backends, but currently we have GNOME KDE ones. And it says user interaction, which makes it safe. So I mean, the only thing I'm going to do here is quick demo of how portals work. I'm going to start the GNOME recipes application. So this is an application that was largely written to be demo of how flat packs. It has recipes that are contributed by GNOME contributors. And, you know, it will present that interface to when you say start cooking to walk you step by step through this interactions, hopefully with minimal touching your screen. So, but it also has, here you can see there's like print and share buttons. And these go through and go through a portal. So I'm going to print this recipe. I print here. And it pops up a normal print dialogue. Now, certainly the old way of doing it, to have an application be able to print, it will talk to the cop server, the effort to see every single printer that was on your network, find out all capabilities of all those printers. And by that point, you actually created a fairly specific security a whole there. You know, maybe that printer also has a scanner to be able to see your, you know, we would suppose a lot of detail about your system there to the application. But on the other hand, in the fact that world, basically the fact the application asks the outside the runtime to put up a print dialogue, then once the user selects a printer, the application gets back, very, you know, here are the margins, it's double sided, you know, this color is black and white, it creates a PDF file, it's then sends it back out. And it goes to whatever printer the user has selected without having to give the applications very broad permissions there. And if the user pop up the print dialogue and said, I want to print 10,000 copies of this document, you know, the user wouldn't would just say, well, no, that wasn't what I wanted to do and close it. So once we didn't have to trust the application with any sort of upfront permission, you know, file logs works the same way. If you want to something by email, the way that the sharing dialogue does it pop up, print pop ups are pre populated email with the recipe in it, and they either choose to send it or you can choose to not send it. So that's sort of the case of portals. When portals are working properly, you don't know they're there. It just looks completely transparent to you. In a few cases, there might have to be explicit requests for permissions. An example would be a location portal. If you want application wants to know where you are, then you probably have to ask the user, can I share your location data with the application? Because there's no natural place for use interaction there. But that's something we tried to minimize instead of having this sort of old Android style of front permission lists. So, kind of a little bit more talking about generic flat packs. The way that flat packs work is that every application gets its own files with some namespace. So it's own sort of mini view of the operating system that's separate from the algorithm operating system. The runtime is mounted on slash user. That's all the share of libraries and shared binaries are there. The application on their hand is it's all that slash app. And that's sort of important from the view of how we make things from Fedora, because since the application has a different prefix, you can't take an existing Fedora package and just without rebuilding it turning into a flat pack. Building a flat pack never involves rebuilding the application. So, Dan? Where does it get its Etsy? It's Etsy? It's Etsy also comes from the runtime. So, it gets a password on most flat packs will simply be a default. That's a password similar to what you might have if you... So, every flat pack will have its own... Actually uses a UID namespace. So, there's no need to, you know, no need to have an expression to pull in a lot of outside stuff. Actually, I don't really know the question about this. I mean, absolutely, if you do look up the user's details, you should get the right name for the user. So, we may do something to put out a stop Etsy password into the flat pack. So, that would happen sort of at the runtime level. So, if some things happen at the build time level, we freight file systems, then sometimes things happen at runtime where when we assemble these namespaces, we do a few tricks there. And then maybe a trick from Etsy password. But we do need to rebuild applications. So, we'll talk about how that goes about. There are other current security features are used in the sort of same way they would be used for a container. There are, as I said, the UID namespace. There's a pin namespaces. So, you don't see all the other processes. You just see the processes running within that flat pack. There's a set comp filter so that the application does have access to a lot of system calls that doesn't have any business accessing. You're generally, a lot of times when a security vulnerability is discovered in the kernel, it involves some very, very obscure system call that most applications would need to use anyways. So, a set comp filter is used to forbid access to all those obscure system calls that really applications shouldn't need to use. So, to store our flat pack on disk, the technology is OS Tree, which is also what we use for atomic host. You can sort of be seen as being Git for binaries. It's ways of storing binary trees the same way Git is a way of storing Frieza source code. And one of the big things that gets you is duplication. So, I have two flat packs and they have exactly the same file in them. Maybe for whatever reason, this happens more than you'd think. It will actually be saved only once a disk and if both applications load up that same file by a shared memory map, it will be shared in memory as well. And then, sort of the standard model for distributing flat packs is to use OS Tree as your distribution mechanism. In that case, you also have this duplication on the network. If you need to download a file twice, you'll say, well, it's already half out of this check sum. I don't need to download it from the origin again. Then finally, OS Tree is designed to, I'm sorry, atomic updates so that if I want to take an application, I want to apply some updates to it and then I want to start the new version, I don't have to mutate the version of the application which is currently running. I instead create a whole new tree which is the new updated version application. And then once I've gotten the update done, I start the application with that new tree. So it's a safe way of doing updates. But in terms of, there's actually also a second way of distributing a flat pack which is called an OCI image. OCI images are from the Open Container Initiative and they're essentially a standardized evolution of the Docker format. And you can take a flat pack and you can also build it into an OCI image. And I mean, there are a couple of advantages of that. One is that compared to OS Tree, there's not a ton of small image, a ton of small files. So one of the problems with OS Tree distribution is that a large OS Tree repository might have millions of files in it. And if you start like mirroring that by our sync, that really just does not work. It also, it's a lot of individual HTTP requests. But it also, by getting conversions with server containers, makes things easy on the infrastructure side. We don't have to have two ways of building applications in Fedora. We can have just one way. And it makes things easier for our system administrator. They don't have to have one way of serving application for the servers and then maybe an entirely different way to do it for their desktops. Yes. Is that transparent to the user whether it's a package as an OCI image or we can go to OS Tree? Yeah, it is. I think I have a picture here that essentially you have a set of what are called remotes that are configured for your system. These are places you can get packages from. And some of them can be OS Tree remotes and some of them can be OCI remotes. And the user, if everything's working properly, won't notice the difference. They just see a set of available packages. And I should emphasize that. I should say that once you download an OS Tree image, it's locally exploded into an OS Tree. So you still get the undisk duplication. So how do we go about creating a package from Fedora packages? Well, first of all, why do it? Why don't we just use the upstream ones from the sources? We want the sandboxing. We want upgrades without rebooting. We wanted to be able to try out some packages for raw hide without upgrading my entire system to raw hide. And finally, another reason is that when Fedora removed its model of the atomic host and atomic workstation where the core operating system is distributed as a tested unified whole. And if I want to, I don't want to insert packages into that test unified whole, I want to have my package leave my operating system as it is as a single OS Tree, then have my applications independently there. It's a flatback to the very natural way to layer application on top of a atomic workstation tested sort of tree. So at the level of, you know, Fedora disk yet and infrastructure, the model that we really are promoting for flatbacks is that flatbacks are Fedora modules packaged into containers. Well, let me modify that a little bit and say that they're a very particular sort of module packaged into a very particular sort of container. But in general, we're trying to completely converge the view of a flatback so that we're not creating some entirely new set of objects within the Fedora infrastructure within the minds of our package. But if you learn how to create a flatback, it's very much, you learn how to create a module and you learn how to create a container. So we're saying hard to say that these are the same things and we're not trying to create a lot of extra buster around this. So there's one module in Fedora, the flatback one time module. Then you have a separate module for every application. So, you know, the Gimper Inkscape would have their own module within Fedora. They are the Fedora-layered image build service, which is sometimes also called the OpenShift build service, is chargeable in containers within Fedora. It's also chargeable in flatbacks. And registry.fdora.project.org, which distributes current service containers, is also what's going to be distributing flatbacks as well. So, within sort of that world, flatbacks are very much equivalent to containers. So I wanted to talk a little bit more about modules here because as opposed to containers, they may be a little bit less of an obvious fit. You know, you could take flatbacks and build them directly out of Fedora 26 content without introducing modules there. But modules, one thing that they give us is this ability to rebuild a package of different prefix. Like, if a package within Fedora 26 would build exactly one way, but modules have sort of one of the basic ideas is that I can take the same source from diskit and build it different ways in a different environment. And one of the different environments I can build it in is a environment with different RPM macros that set the prefix to be slash app rather than slash user. Like, any other uses of modules using a flatback gives the application to retain a lot of flexibility. You no longer have to be in agreement with every other door package you're about what version of each library you're using. If one application needs a one version of a library, and one application uses a different version of a library, then they can do that. And you can deal with your application at your own tempo. You can say that I'm only going to contain one version of my application and I expect people at Fedora 25 and 27 all to be able to install it very via a flatback. It's generally giving more power to the package or though also more responsibility. And furthermore, we're using modules there because that's the way Fedora is moving. I don't want to spend a lot of time building infrastructure that is related to Fedora as it was. I want to make sure that we're building something that's really lined with the way that Fedora is going in the future. And finally, because I'm being aligned there, it's a lot easier to get changes into Fedora infrastructure. I'm saying, telling everybody of Fedora infrastructure, we need to add yet another component, another service. There's going to be a lot of resistance to that. And I said I'm not going to talk a lot about what's internally going on within the Fedora infrastructure because I don't think people who care about that are at this talk. There's sort of some key things being used as the module build services, is what actually goes and builds your module, makes the definition of the module and coordinates all the building of packages that make up that module. Once modules are built, they go into the product definition center which just says here are the packages that make up this module. These are something called the on-demand post service which takes modules and puts them together into the Yammer pod story. As I mentioned before, there's the Fedora-layered image build service. And then finally, there's registry.fedora-project.org which is the public-facing registry for containers and as we add flatbacks for flatbacks as well. So, we'll move on now to an example. An example I'm going to use is the IAM Pinole which is a very simple image viewer which has been sometimes been the standard image viewer for Pinole and sometimes it's been one of the standard image viewers for Pinole. And to make a flatback out of it, you essentially have to create two files that describe how your flatback is going to be built. One describes the module and one describes the container. So, the first one is the module-md file. Traditionally called the name of the module plus .yml. It describes what packages make up that module and what the module depends upon. So, if you look at this, this is the first half of the module-md file. It has some sort of generic metadata like a summary description. And generally in the flatback world, those can be automatically propagated from the summary description out of the package. It gives some build dependencies. For doors 26, the set of build dependencies are pretty complicated because the module structure is still evolving. I don't necessarily expect that people in the future will have to say that I want Perl so that my automakes scripts run correctly. Probably some of this will simplify in the future. But there's also the hires section that says what you need at runtime. And for an arbitrary module, this could be complicated. For a flatback, it's very simple. You need to say, I require the flatback runtime and the version of the flatback runtime you need. So that's gonna be the same for every module-md file for a flatback. There's also a profile section which says, here are what packages from this module I want to install. And again, it's really simple for flatback applications because usually the only package you wanna install directly is the application itself. Then it'll pull in by dependencies and the libraries it needs. So this half of the module-md file is pretty simple. It's much of this could, can be auto-generated. Sort of the second half is the more complicated part which is the list of performance that you need in your, even within the module there. And essentially you need every package that you depend upon which is not part of the runtime. And that could be a pretty big, so you also want some tooling to automatically generate this as well. You don't want to be sitting there saying, comparing two big list of packages. Here's everything my package requires. Here's everything in the runtime. Let me figure out which ones are different. So we have some tooling there or and they're working on some tooling. There's something called flatback module tools which is some Python scripts I wrote that do sort of development tasks for flatbacks. So there's one called create module-md. And if you run that with, you can say create module-md from package EOG, it gets the EOG package, looks at the summary of the description, look at what's required, pairs that to what's in the sort of Fedora 26 to figure out the complete set of dependencies and writes out sort of a template EOG.yaml, a met module-md file. So this is flatback specific, it's still pretty rough. There's generally an effort to do the same thing for modules in general and respect the long-term, there'll be some standard Fedora tool for doing this process of taking an application, RPM and turning it into a module. Something, there's a start, something called depthchase which does the dependency part of it but doesn't actually write out a skeleton module-md for you but I'm not sure exactly where we're gonna end the long-term but there'll be something there for modules. So that's half of it, that was what describes your module but then we also need to describe a bit about how that module is turned into a flatback in particular about the runtime and environment, what permissions that flatback needs. So for that something called a flatback.json this is a JSON file with some keys in it. This is very based upon something called a flatback builder manifest. Flatback builder is a tool for building flatbacks from source and a lot of what that has is going to be how to build the source code but if you remove take that, remove all of the instructions for building source code then that's basically what's left is what's in the flatback.json. And some of this is just sort of simple metadata. Flatback identified applications by in sort of reverse domain names. So there's like org.gov.ubg is the ID of the application. The complicated part here is something called finishogs which is a really awful name but it basically defines the permissions and it's called that because it's all arguments you pass to flatback build finish which is also in relation to detail but I wanted to be consistent with the flatback builder. Jason's which I left the name. So you can look at the man page for flatback build finish to figure out what you need in your finishogs but generally this is, this is an old application isn't sandboxed so I say that it has access to the host file system to the user's files that is to X11 it then has access to deconf which is the user's settings. So this is like sort of what it looks like for a sandbox application. A sandbox application would generally have a smaller finish arch section because it would need less permissions. So how do you take those two files and then build them into a flatback? Well if you're doing a local build which works currently you first need to build a module and the module ROG team has a tool called MBS build you can do MBS build local it will download all the necessary bits and then build your module MD file locally and create a sense of local packages sort of like a mock build. And then you can use another tool from flatback module tools called flatback module create flatback which takes those local little packages and turns them into a flatback bundle. And then if you wanna try it out you can flatback and solve the bundle and then you can try running it just like any flatback. You could run it from the command line with flatback run or you could go to your application launch room and launch it from there. Now, but that's not the long-term goal long-term goal is to build an infotour infrastructure on infotour build servers. So it's actually not that different I show the first that you should be in this again if you're gonna build in a flatback infrastructure there's modules namespace which contains all the modules. So you're, and then you'd say MBS build instead of build local you'd say MBS build submit that fired off to the Fedora module build server you would take your file and turn it through code to you and generate all the packages and then we need to sort of build the Fedora layer image build system and the tool for that is code container build and then I've added an extra command to that flatback build which builds a flatback instead of a container and then you sort of say what you want to build and what module you have to build against. So I mean, I think eventually we'll have some fed package integration so that becomes a bit simpler so you don't have that very long command line but that's enough to get it built and theoretically once everything's in place they'll get it put into the door registry. And then the basic idea of how you install it is that you would add a remote that points to the well either the door registry or the candidate door registry which is where things are before they've been released. Then you can just install using a flatback install from that candidate registry where you can do the same thing through GNOME software and you again run it as normal flatback. So that's basically what the sort of process does and will look like for creating a flatback out of through our packages and the key being these two metadata files that you need to create. So I'll quickly go over for the status and then take some questions if we'll have them. So the whole module being in part works fine in through our currently. You can build against a flatback one time module and get your application models built with the right prefix. The code to take that and assemble it into an OCI image and upload that to the door registry. It's all working really well but it still has to be merged upstream. And then finally the part that needs to be there so that you can actually go to GNOME software and view all the packages in registry.doorproject.org and install them through GNOME software is still needs to be written and that's gonna be a door 28 feature. That's either some work arounds you can do currently or we'll be able to do once the rest of it's landed to install them for more clumsily. But I don't want to describe that in detail now because that's still in flux. But that's sort of what we'll envision and I'd say that we're like 80% done with it now. Okay, so questions. Yeah. Let's say we're gonna take the normal standard RPM and DNN, I don't know, install that. And then I were gonna install the flathead. Is there a way that you would, would my system like take one over the other or would they show it differently? So if you went to like the GNOME application overview or the KDF application launcher we would show either one or the other and if you wanna really show one of them what's gonna show is the flat pack. If you, from the command line, if you either want UOG from the command line or you do flat pack one or GNOME.UOG and run either one of them. So sometimes when you're building a flat pack you actually wanna change the application ID. Like if I have a building a light and let this snap up to the GIMP I may not want to just replace the system GIMP with it. I may want to appear differently as GIMP parentheses light. In that case you can give your flat pack different application ID and then it will show up as a different entry. So it might be possible that you would have two different streams of your Flora module. One which is, just looks like the application standard and one which is distinguishing from it and has a different application ID and those two could be installed at the same time and user will be able to pick one or the other. Okay. But if you don't change the application ID then only one can be launched. You can just overwrite the original. Yeah. Yeah. I have three questions. Yes? The first is kinda similar but it's about platforms. If you install some, like a platform is a bundle of libraries, right? Yeah. So if you install one from your distribution and one from upstream, one from, you can have what, which one gets chosen. So the priority? So you always, application is always tied to a particular run time. So it's not like, so different run times are thought of as providing different user, different API or different API. So the application is either built against org-nome free desktop or it's built against org Fedora project or whatever other run time. I guess the org project doesn't provide anything that is in GNOME? Yeah, so they might have many of the same libraries but there's no assumption that you could replace one with the other one. Okay. I mean that's, I mean I think that's because one of the things with Flatpak is the strongest inference that if I didn't create a Flatpak and somebody else wants it, it's running exactly as I created it. And so I've tried the, somebody has made a Flatpak for Spotify. Yeah. I've used it and it failed on Wayland. Is it like a missing permission or something? It worked only on X11? So I mean, I'm not trying, I mean I don't, I don't know the exact answer to that. It's possible that it simply doesn't support Wayland. Like so. Oh, there it is. I mean, well I was thinking in the... Actually the option that they built before works on Wayland. Yeah, well it should work on Wayland. I mean, it should, if it's built to work on X11, it should just follow who's X-Wayland and work on Wayland too. So I actually have no idea. There's nothing Flatpak involved in that. No, I mean, if you want, we can take a look at it later if you want to figure out what's going on. So you found this technology, the only thing that you need to change in your application if you want to support Flatpak is if you want to have portals. And there is, you can have a modified application running Flatpak if you're not using portals. So, yeah, so there are two cases where you can not use portals. One is if your application doesn't need a portal. Yeah. I mean, so a game might not need any portals at all. The game just wants to display, take it from the user and display things to the screen. Or the second case where you don't need portals is if you want them on Sandboxed. And currently we don't, currently we don't make a big deal on Sandbox applications. We don't say, this is on Sandbox, it's entirely unsafe. We're sort of, eventually the public will get the case while we're saying, we're really trying to scour if you're just using on Sandbox applications. We're not yet at the point where we can do that. We hopefully, over time, application authors will be using portals more and more. And sometimes portal application usage is transparent to the application author. It's under the toolkit. Like if you're using GDK, and you're going through the right, so if you use sort of the simple print interface that doesn't provide you a lot of details about the printer, then you automatically use the print portal. Some cases you automatically use the file to use your portal. So in many cases, you don't actually have, as an application author, you may not need to know anything to use a portal. Your toolkit may do it for you. Okay. So because I was thinking of those sorts of applications that maybe don't want to rewrite parts of the, yeah. Well, I mean, you know, some of them might just need to run on Sandbox for a long time. Yeah. And that depends on, you know, what pressures would apply to them. And if they don't, some of the closer people are like middle of the next thing, we don't want to touch it for the next 20 years, you know, but sometimes they're more responsive than some people are. So I'm, some of those sort of options are definitely engaging with Flatpak. Okay. Yeah. Okay. Any questions? There? Okay. There you go. Okay. Okay. So I'm working into the quality engineering aspects of the language. I have a question that if I want to test a platform for say, the forms input method for locates, so where should I start testing that thing? So is it better or 26 is right or? So 326, I mean, in terms of like to general flatback infrastructure, 326 is quite up to date and has everything you need there. It doesn't have the Fedora, Flatpak's bill of Fedora packages, but that should be pretty much the same either way. So like things that internationalization should work the same, whether no matter how flatback is built. So you can definitely start looking at 326. So do we need to build a Flatpak or is it or can we download it from somewhere and test it? There are flatpaks you can download and test. So like if you go to Flatpak.org, you can still be linked to the Flatpaks there that you can run with. Excellent. Thank you. Okay. In the back. I will show a Flatpak. So it can be worked either way. The default in Fedora is that Flatpaks install are installed system-wide and it works a bit similarly to packages in that if you have the main privileges, you can install Flatpak system-wide without having to authenticate its route. But you know, it's a default system-wide but for testing purposes, where we don't have a main privileges, we can also install it just as one user. I think probably not because that's not really what people would expect most of the time. I mean, it's something that I think I don't, we could do that, I don't think we do. I think instead of what we do is we ask you to get, we ask you for a main, like prompt you for a main user privileges. What is the future for this? This created a pretty big broadcast when we came up on Fedora develop. But I think the answer is we're going to see how it goes. And that's going to eventually be a decision for the packagers. Like if a packager, once this is mature, a packager says, you know, Flatpaks are a better way of destroying a package when I put it into a Flatpak, it has sandboxing, I can release one version and have it work across all different Fedora releases, then I don't think we're always going to say, well, no, you need to build it as an RPM too. But that's certainly, that's several releases out, probably not Fedora 27, clearly, because we're just going to have to get into the Fedora 27, not Fedora 28, I don't know. For Fedora 29, maybe packagers will be able to do that. It's a really policy question that we're not going to establish until we, until we actually get some experience, we're not going to set that policy. Yeah? You know, I don't know the, I'm, you know, obviously, you're better off talking to them, Alex, too. Well, you know, they all use input. So, you're saying if, I mean, the ones I play, this is so far approachable. So, you're saying, oh, so mandatory, so, I guess it's not, I'm sorry. And the big thing about the primary mandatory act, so, I mean, do, we basically can be a little more specific on your question there, I'm not sure what the question is exactly. I'm saying are people using it now? Oh, are people actually using the portals? I think it's a mixed bag currently. Generally, very recent, you know, applications are going to be built sandbox using the final portals, but a lot of applications that are more complex will not yet have imported to using the portal system. Something like OpenOffice would be a pretty big job, there's just probably a lot of, some should sort of straddle through the code there about being able to access random files. I think it's going to be sort of an evolution and then eventually we'll start putting the clamps down to tell people that they really need to sandbox the applications. Yeah, so, I mean, that's some extent, you know, we don't want to put too many barriers there at the start, because we don't want to say, well, you need to do secondary writing before you can get it back at all, but, you know, I think you're totally right, and I think it's a little bit chicken and egg, we have to build up the ecosystem from all directions and then get, but I think there are a lot of, I hope that there are enough compelling advantages that we'll get there eventually. Not, I'm not the right person to answer that, I haven't looked at the run-season or space feature, well, in the back first. Now that you're moving to the module thing, we're not the module or the stuff, is it still going to be compatible with other operating systems such as Sousa, or open Sousa, open Sousa as flat pack, and I think I see a flat pack with a built-in fedora. Yeah, no, the module component is also on the built side. Once you've actually built a flat pack, it's just a flat pack and you can still take a flat pack, build up your RPMs and run it on Sousa, or take a Sousa flat pack and run it on fedora. So the module, the involvement of modularity is all on the sort of package or side and not at all on the user side. The, eventually what you might see, a user might see eventually, is that fedora flat packs are no longer versions, fedora 26, fedora 27, you might just have a GIMP 2.8 flat pack and a GIMP 3 flat pack instead of fedora 26 when fedora 27. You mentioned games are something that don't need portals. It's kind of an example of things that don't access user files. I could put up a file dialogue, but might need some file system access for like storing saved data or whatever. So is there a persistent like runtime directory? Yeah, so I mean, the default for a flat pack is that it has that the, what's the XDG data there? We're on an application that's sort of semi-modern with source files is presently stored for the application there. So if you store files in there, you can still access your XDG data there without, it was going through a portal and anything you save there will be there next time the application runs. So, you know, if you obviously, if the file expects, if the application looks for a dot filing around the place, then it wouldn't be able to do it without, I think, we could theoretically mount something on dollar home as well. I don't think we should do so currently, but I'm not, I'm not 100% sure about that. Yeah. Did the run times pair to a particular kernel or minimum kernel? So, in general, you know, I mean, in general, there's probably a pretty weak dependency between the kernel is pretty good at containing API and involving compatible ways. So it's not usually the case that something that's running unprivileged cares too much about which kernel it uses. There are, the sort of exception to this is often graphics drivers because new features, graphic drivers might require new kernel features at the sort of kernel level. And for that, we've actually, there's a system called extensions. So you can have a runtime extension, which is basically a way of saying, I'm gonna take this runtime and I'm gonna drop in a new graphics driver. But, you know, you can certainly see a situation where the runtime could be updated to work with the new kernel version in some way. In that case, you can be able to take advantage of the new kernel version because it has the new runtime. But I wouldn't generally say that there's any strict preparing between the runtime and the kernel version. I don't feel like I can answer your question. Oh, I'm just wondering, are the run times supplied with like Fedora 26? Does Fedora 26 have its set of those run times that may be different than something you get out of Seuss? So there might be, generally, when we like the situation where a runtime can be used in the host operating system, clearly the runtime does talk to the host operating system in different ways. They need to communicate. So the interface that they communicate over have to be stable. Like, if the runtime talks the Wailin protocol to say, I wanna put a window on the screen, then the host operating system has to understand that protocol. So I can't just say that any runtime will work with any host operating system. But the expectation is that a runtime is not tied to a host operating system. It talks via standard protocols interfaces. So you can use the SUSE runtime with Fedora, Fedora runtime with SUSE. Can you compare Flux Pack to similar technologies in other operating systems? I mean OS X applications and Android applications. Are there similar or not? I would say that they're in some ways similar, in some ways different. I mean, that's obviously not. So I mean, I think the idea of using a sort of the file system namespaces is fairly specific to Flux Pack. And also it's something that shares with like Docker containers, but not so much with other operating systems because generally other operating systems have had sort of more leeway to require application rewriting. So we're trying to do it in a way that's more compatible with existing applications. And file system namespaces provide a way of doing that. Key abilities wise, I think what Flux Pack's provide are pretty similar to what other operating systems provide in the newer sandbox applications. I mean, both Windows and Mac have been moving towards the sandbox model. I think when you, a sandbox Flux Pack or a sandbox Mac or Android application would have similar capabilities. Android's inter-application model is much more complex. And I think that offers some real security problems. So because essentially an Android, their intents which are their equivalent of portals are not a fixed set provided by the operating system. It's that any application can offer any intent sort of any other application. Well, that sounds really poor, really powerful. It's a huge vector for leaking permissions from one application to another and from another application and also makes it very hard to establish a good user interface for it. Because something that somebody is thinking about an internal part of the application suddenly gets used in the application. And so I don't think, I think that the Flux Pack model is a more secure way of doing permissions than the Android intent model, though it's sort of less flexible as a consequence of that. But yeah, I mean, I think we're, you know, we're some sense of trying to shoot a little bit smaller, not redesign everything and provide more of the existing set of APIs instead of saying we're going to create a whole new different way of doing APIs. Okay, well, thanks everybody. This has been recorded, right? It hasn't been recorded, yes. I probably shouldn't have been repeating questions, but hopefully it's a small enough room so that the recording will still be. I was looking at the laptop and I couldn't tell if it was actually doing well. I don't know. I pressed the button. Okay, you pressed the button. I didn't check. I pressed the button. Yeah. Do you know what would be the adoption of Flux Packs and all the Linux distributions? I didn't say that in terms of major distributions, I mean, certainly, I'd say, I think