 And welcome everyone. This is the president and future of Fedora Flat Packs talk. Jan, Beran and me work for Red Hat in the desktop team. But we are mostly speaking here as Fedora contributors. We have had some additions of this talk in the past where we were speaking a bit about the foundations of Flat Packs or how Fedora Flat Packs were built. And today we want to a little bit cover what's the current state of the things and maybe move a bit on the future plans we have for Fedora and for Red Hat Enterprise Linux. For getting Fedora Flat Packs popular in Red Hat Enterprise Linux. So let me mute myself. Hello. I'm Jan Beran and I would like to tell you something about first introduction to Flat Packs and then something about the current state of Fedora Flat Packs. So first of all, what is a Flat Packs? Generally speaking, it's a new way how to distribute your application. You as a user don't seem much difference in comparison to, for example, RPM. But under the hood there are quite a big changes. I will get to that later. But first of all, how Flat Packs are distributed. You can download Flat Packs from FlatHub, which is the biggest app store with FlatPacks. Or you can download them with GNOME software. As a user, you may be noticed that there are some sandboxing things. That generally speaking means that the application itself is isolated from your host operating system. And everything that the application needs has to be explicitly permitted in a manifest file. That's obviously good because you know what is going on and what resources your application needs. And the second difference is that application in FlatPacks don't target specific distribution, but they target specific runtime. And that means that if you can install the runtime, you can install the application and run it, no matter what operating system are you using. There is something called SDK that's generally speaking for developers. It's a bunch of header files and it allows you to build FlatPacks targeting specific runtime. To this slide, you can see the runtime, which is basically a bunch of commonly used libraries. It is bundled together and it creates the runtime itself. And if you are building some application, this application looks for its dependencies in the runtime. But of course, it can happen that in the runtime there are no dependencies, no such libraries that you need as the application. But that's not a problem because you can just grab the library and bundle it together with the application itself and send it in the FlatPack. To the advantages of FlatPack, as I said before, it's cross-distribution because FlatPacks does not target distributions but run times. So it's a quite easy way how to do cross-distribution application. You can build the FlatPack on your own machine because you can download the manifest file in case of FlatPack. Or you can download application.yml and container.yml in case of Fedora FlatPacks and you can build your own FlatPack on your own machine. As a developer, you are also developing against a specific stack version. So it's good because there is some probability that things will not change. And the last three points are about isolation and security, as I was talking about before. Very simply put, application is isolated and you as a developer need to specifically say what resources your application needs. By resources, I mean network connection permission to play audio or for example accessing parts of the host file system. And that's it. Next slide, please. When we are talking about Fedora FlatPacks, we need to discuss two things. First, they are based on RPMs in comparison to FlatHub FlatPacks, which are based on the source code itself. So this approach with RPMs means some additional layer of security and transparency because RPMs are maintained and there are spec files, which allows you to check what files are installed and where and even how. The second big difference is that Fedora FlatPacks use OCI containers in comparison to FlatHub FlatPacks that use OST. And if you are talking about the process of FlatPacking application in Fedora infrastructure, it consists of three steps. The first step is to build a module because we need to rebuild the application itself and its private dependencies with slash app prefix. These private dependencies are listed in application.tml file. And once we have the module, we can build the container or the FlatPack itself. So we need to think in Fedora infrastructure the way how to handle containers and FlatPacks is very similar. And in that container.tml file, there are the permissions itself. That means like network permission, host file system permissions, etc. For FlatPacks, Fedora FlatPacks live in registry.fedoraproject.org. So if you want to look at the application that are already FlatPacked, you can check this website. And once we have the FlatPack, we just distribute it through body. And that's it. So you can, speaking about the current state of FlatPacks, we have more or less 85 applications currently converted. We have delta updates, which is good because when you are updating Fedora FlatPacks, you download only the difference between the old and new version. We are working on langpacks, debug info for developers to better debug the FlatPacks. And the last point that is not Fedora specific, that's FlatPack wide. And we adopted the new Tracker 3 portals. Very simply put, it means that you can specify what parts of Tracker information will be showed to your application. Like in case of, for example, some document oriented application, you need information only about documents and that's it. You don't need information about videos or music. With these portals, you can do that. And that's pretty much it. Hi, so when it comes to Red Hat Enterprise Linux, here first, a disclaimer. A lot of you might know that the way we're working in Red Hat is that a lot of us are upstream first, we work very close to the upstream communities. And the things I'm going to say here are not necessarily plans or things that Red Hat has decided or I'm not speaking on behalf of Red Hat, but speaking on behalf of Fedora who wants to see it, so see it in Red Hat Enterprise Linux. Also because we know that when we see something that we develop upstream, so see it in Red Hat Enterprise Linux. We know that Red Hat helps the project more and gives us more and more support to push for these ideas. So a lot of things like FlatPack itself, right, are projects that started in upstream communities and they were pushed by Red Hat developers upstream and then later they got into Red Hat Enterprise Linux. So that's my disclaimer. And the thing I wanted to mention about Red Hat Enterprise Linux in this whole FlatPack story is that when we sell Red Hat Enterprise Linux or when we promote Red Hat Enterprise Linux, we promote it as this stable foundation for people to build their architectures on top. Somebody's going to write an application on top of RHEL. RHEL is the basis solid for everything. So this is something I want to see for the RHEL runtimes, right? When we are going to have a popular RHEL runtime for FlatPack, we are going to have like a stable and supported and with all the Red Hat experienced is a runtime where developers can target their application. So this is ideal for ensuring that security issues are going to be fixed in the runtime, that developers can reliably target that version of the runtime, knowing that the runtime has been built with trust, has been built from RPM packages that are maintained by Red Hat folks and Red Hat has a lot of credibility over there. So we are very excited about pushing for upstream things in RHEL, including FlatPack. Currently, the approach we are doing is that we are building runtimes for specific RHEL versions. So RHEL 8, RHEL 9 would have specific RHEL versions. So one would have the lifecycle of that one RHEL version as the lifecycle of that runtime, including the support. And as far as I know, we are now going to be shipping some applications as tech preview in RHEL 8. They are probably already there actually. And they are LibreOffice, GIMP, I think Inkscape, and it's the very same idea as Fedora FlatPack said we want to be building them the very same way and make them available in the Red Hat registry. So FlatPack would learn how to deal with the subscription part and all that. So this is just one more possibility to our users, right? Because one of the historical problems we hear from users of Red Hat Enterprise Linux is that the system is rock solid and very stable, but somehow users want to be able to use new applications and at the same time benefit from the best of both worlds, right? Receive a lot of updates, but at the same time stick to the rock solid system that they love. So I feel that FlatPack really helps us in that story because FlatPack would allow us to have a stream of updates for specific apps. And at the same time the user can keep their basic system of rock solid with the things that have been heavily tried and passed by Red Hat for that specific major version. Another advantage I see from this is the bundling dependencies. A lot of times we are bringing on dependencies in RHEL because they are dependencies of applications we are shipping, but we don't necessarily want users to be consuming those dependencies and at the same time once some user starts to consume that dependency, we are supporting that dependency. So it just scales and becomes like exponential combination of dependencies to support. And with this approach, I believe we would be able to bundle some application specific dependencies within a FlatPack. And this would bring lots of benefits for us to focus on developing these applications instead of maintaining more and more things. Another aspect that I like about this is that you would allow you to run RHEL 8 applications as FlatPacks in RHEL 9 and vice versa. If some regression would appear in an application, you'll be able to mask that commit on FlatPack so you'll be able to stick to that version so you can really have a lot of control of your updates. And I think that that's a great improvement. And this last bit I mentioned about the RHEL RPMs is the very same thing as Fedora. The Fedora community has trust, has been building over the years that a lot of people rely on Fedora, build things on Fedora and RHEL is the very same thing. There's a red hat employee taking care of every single RPM you see in RHEL and creating FlatPack runtimes and FlatPack applications from those RPMs mean that you are inheriting these benefits as well. And as I said before, everything we do is very upstream first. So here I kind of mixed it up a bunch of points but there are so many more ideas going around in the team about how we can improve our FlatPack story. The portal support story is really one that a lot of people are interested on improving upstream and they'll bring benefits for all distrusts. That is the idea that applications need to talk to each other. So we have this XDG desktop portal, which is a service that provides this communication and moderates the permission for accessing to certain things out of the sandbox. Unfortunately, lots of new applications which are available as FlatPacks are still not consuming those portals. So recently we had an economic conference at HackFest and one of the things that was discussed there was exactly this problem. The idea that we should be pushing for more applications to consume information and data through portals instead of exposing filesystem, exposing devices, exposing other things, poking holes in the sandbox as we often refer. So we definitely want to put a lot of work into improving our portal story. There's now only portal which is a library that provides programmatically access to the portal so you don't necessarily need to be very skillful with the whole debuzz sending messages and g-variance. So that's something nice but I'd like to really see some effort into improving our portal story. More applications consuming data over portals instead of exposing user data. I think that this should be really a major goal for us to really make a point about security. We are selling a lot of FlatPacks as a secure thing but it's not just secure by default if we are really not trying to protect the user data proactively. So I think that that's a good thing. And we also want to get much more engagement. Most of these Fedora FlatPacks you mentioned those 85 applications, they have been built by a handful of people. So it would be very nice if application developers or people who maintain applications as RPMs would be also interested on the effort to create Fedora FlatPacks. So we could have more eyes on it, more collaboration on it and be able to really support those applications specific needs. Lots of the FlatPacks applications, they might need some sort of adaption, some certain changes that need to be made for them to work well on the FlatPacks sandbox. So it would be really nice to have the people with that specific know-how. People who are really maintaining those apps or even developing them upstream. Another front that we would like to see some work on is CBE tracking that we would have a lot of automation in that regard. We would even have redhead insights or things like this, but the ability to be able to automatically create FlatPacks builds based on events, based on other assessments. So the idea that release monitoring could be somehow integrated to these or at the CBE comes out and then suddenly there's a bug report and automatic build is done, things like this. And definitely our debug story, we also want to improve it because debugging FlatPacks applications, it's very doable if you are very familiar with the technology, but it's still not something that we have integrated with ABRT or something that you'd be easily able to ask users. Could you please provide me that back trace? It's not that simple yet. So this is our major work and it cannot be possibly done just by us. So it would be very nice if people interested on this would approach us and you would also check our FlatPacks docs in the Fedora documentation so we can continue improving this story. So are there any questions? Let me just get back to the chat because I've been completely blind about what's going on over there. Hi there, so. Also there are Q&A. Well, lots of them. So let's start from the oldest ones. You want to take one first year or should I? The answer was in the chat, but very simply, there is a process with RPMs that are checked. There is a process how to bring new people to maintain RPMs and the process itself puts some control over the source code. Yeah, there's Fedora QE as well. So Fedora apps are reliable. I see here, Matthew, what about shipping the runtime on the Fedora, on the Fedora Workstation media? Yeah, that's an interesting question. I think it might be a question for the Fedora Workstation working group, but I think that that's definitely some path that we are going to because it's something that we definitely want for Silverblue. And it's necessary in Silverblue. Applications are already pre-installed as FlatPacks in Silverblue. And I think as we transition this, I'm speaking here as a non-contributor and a Fedora contributor. I see Silverblue becoming one of the main workstations to be more pro-eminent. So I feel that this is really related. Let's go one question each. Okay, Matthew Miller, what do you think about adding this gate to FlatPack option without going through RPMs and modules first? If I understand correctly, you're meaning more about getting the Fedora sources and then building classic FlatPacks with it, like using FlatPack builder, but from the Fedora sources. Is that it? I'm quite not sure about the question. Yes. Yeah, this could be a possibility. I am not sure if everybody's on board with this, but it sounds to me very reasonable, right, because it's what we're doing on FlatHub. Yeah, definitely. And modularity being problematic. I was just responding to Matthew on chat saying that there are many moving parts on this process. And yeah, this is something that we definitely want to improve. Our colleague, Owen Taylor, has done some very decent work on improving the whole FlatPack build processes. I used to build some big applications in the past and they used to take like an hour, two hours. And now everything is much faster, so big shout out to Owen. More questions. Should I read and you will answer? Oh, or maybe if you feel like answering that there's this one about the difference between OCI or OS trees for FlatPacks. Am I supposed to answer? Oh, if you want to. Generally speaking, the main reason why we are using OCI is that it was already for server containers and we just keep to using that. So it was nothing like we want to use something different, but we had something that was working and we just adapted our solution to FlatPacks. And to the question, does it affect the duplication and install size? I think there are some significant differences. I don't think it affects in some huge way. Yeah. The OCI, the choice for OCI also allows us to publish FlatPack applications in regular registries, right? The registry is running an application for managing the registry and they are used to OCI containers. So this allows us for not having to worry about the whole publishing hosting part of the story. The next question is about the future of FlatPacks and we have the future of FlatPacks on the end of the presentation. And this question was put before. So I think we can skip it. The next question, is there any plan to preserve the runtimes to allow running old FlatPacks that are created for those old runtimes? I'm not sure we have a plan for this. I think so, but one advantage of FlatPacks is that you can, for instance, do a FlatPack run minus run time and pass another run time. So the idea that you actually could be testing the new run time without actually having to have a new route installed or a new Fedora installed is a great advantage. For instance, in the norm of stream, we have a nightly builds of our runtime and we are able to test all the applications against the nightly build and we know as soon as it breaks that it broke. So I see that there might be a desire to preserve old applications for the sense of not touching what is broken. I'm sure that also the advantages of FlatPack allow us to actually be constantly testing the changes in the runtime to make sure that once the runtime reaches its end of life, the applications are pretty ready to switch to when you want to the next run time. The question is, when is REL anticipated to get FlatPacks? The answer was in chat. So, very simply, REL has FlatPacks, but only in tech preview. That means it's something that is not entirely official. It's something that the support is not as good as it will be once it will be released. And nothing stops you from adding new FlatPack repository to your REL system and just installing Fedora FlatPacks or installing from FlatPack. Okay, the next question is, would the REL FlatPack runtime be available outside of REL, say on Fedora? I don't see why not. I'm not sure about it, but I don't see why not. Maybe you should still go through the subscription manager part of it. So if you would be able to authenticate that, I don't see why not, right? But I haven't heard conversations about it. I wouldn't be able to give a complete answer. The next question, why does Fedora not ship the FlatHub repo by default? I think it's because of legal reasons. We just can't do that. There are no free applications on FlatHub, right? So ideally, if we could either filter those or have separate repositories, that would be a solution. But this is a very long end with standing discussion on the Fedora Workstation Working Group. And if you follow Fedora, the VEL, this has been discussed. But yeah, it's something that has been being discussed around. We really want to make it happen. But yeah, we need to go around these constraints. So the next question. I run a FlatHub FlatPack for a JavaScript electron application in virtual machine because the FlatPack gives access to user data. Is it feasible to repackage that more securely for Fedora? Generally speaking, it could be possible, but it depends what is the reason why it access to user data. Maybe it's intended to do that. So we need to know the exact application to know that. And of course, it needs to be packaged as RPM. Next question. What is runtime when installing FlatPack? Can you do an LI-15? Also, why are they so big? Are they duplicating the operating system? So why are runtimes so big? It's because in runtime, there are plenty of libraries that are commonly used across many applications. It's something like a common base for all the applications that target that specific runtime. That's the reason why they are so big. So imagine in the future where we don't have so many things on the host operating system, right? I'd like to see a future where the runtime is big and the operating system is very light. Then there's a question for Neil. From Neil, that is, can the RPMs that make up the real FlatPack runtime get added to the real UBI? It repulsed. So the downstreams that use the RPM base flat-back view process can use it. That's a very good idea. I haven't thought about it. I don't have an answer for that, but I think it would be a very good idea for CI. New question. I would like to be able to start FlatPack-based Firefox slash Chrome slash whatever using CNI network configuration to share the same network with Podman containers. I think it's really about whether you are poking or hosing your Podman container to use a certain network interface, right? I am not that very familiar with container internals, but I suppose that if you would just latch your Podman container access to the same network interface that your standard system is using, you would achieve that. But yeah, I'm sorry. This is really not the scope. I wouldn't be able to answer. We are reaching the six, well, we are reaching the end of the hour, depending on your time. And I don't see any more questions. So I hope you folks enjoyed. It was quite short, but we just wanted to give a little bit of a report of what's happening and a little bit of a call for action. So more folks get engaged and interested on consuming and also collaborating with building those FlatPacks. Thank you very much for watching. It was a pleasure.