 My name is Felipe Borges, I work for Red Hat here in the desktop team. Can you guys hear me in the back? Cool. So yeah, I've been working on the desktop team for three years already, and for the last couple of years I've been working on GNOME boxes specifically, and that's what the talk is about. It's about my experiences running GNOME boxes in a flatback sandbox. And I guess you're assuming that it's the whole virtualization stack inside of the flatback sandbox, not just running the GTK application and connecting to things broadly. There is no requirement for the host. So these are the basic topics I'm going to approach today. Usually I would go for the motivation and get to the concepts afterwards, but now you're going to understand, after explaining the concepts, that the motivation is pretty much the other way around, right? There was a technology trend forming around the desktop technologies, flatback, RPMOS3, silver-blue, and containers technologies getting closer to the desktop, and this was something we were trying to catch up to still be available in the Utopia future, where there is no packages anymore and everything runs on containers. So first of all, do any of you have ever run GNOME boxes or know what it is about? I usually don't have this feedback from the user, so it's really exciting to see people using it. So for those who don't know it, it's like an alternative to virtual box or VMware for desktop users focused on the desktop use case. So for somebody who is experimenting with a new distro, just trying something out on a Windows VM, it's not something focused on scale deployment, neither for somebody who has a very deep understanding of virtualization. So if you are looking to that, Vid Manager is your friend. Both of them are actually based on the same stack, so there is no competition here. They usually have two different use cases, and one is focused on users and the other is focused on advanced users and developers. So that's why we call it virtualization made simple. Boxes, parts like from the point where it assumes that the user doesn't need to understand what's necessary to be set up to get a virtual machine running. So for them, it needs to be like a couple clicks and a lot of things need to be abstract from the users. And other than virtual machines, Boxes supports remote machines. So you can connect to remote machines, either running locally or remotely, over VNC, RDP, and SPICE. So it also replaces your client. You also can use it as a SSH client, so you can have a terminal embedded there and use it for SSH. So the main focus is this test drive experiment. So it's based on LibVirt, so it's just a front-end for LibVirt, and it has this LibOS Info at the core. LibOS Info is a library that has data on operating systems in terms of which devices each operating system supports, which requirements it supports in terms of memory allocation and things as such. But it can vary to all kinds of features that certain operating system supports. And Boxes uses the US Info tools, which are able to detect that an image, an ISO, or a disk match a certain criteria that qualifies it as a specific operating system and already configures this operating system to use these certain devices. So you don't actually need to know whether CentOS 7 supports SCSI adapters for disk buzzer, things like that, because we have a database with this, and this database is designed as such that there's some hierarchy, so we know which operating systems derive from other operating systems, so somehow we can cover a lot of ground to support things out of the box. We also have this great feature that is like a great sales feature for us, which is the Express installs. When Boxes detects that you want to install a specific operating system, which is like a known operating system, for some of them we have these install scripts, which are able to start up the machine based on data from your host and replicate them on the guest. So if I'm installing a Fedora virtual machine in my Fedora host, you'd be able to create a user for me with my same user, my password, my profile picture, and you would do the all install by yourself, so we don't need to do the Anaconda process in your VM, you can just let it install and just go for a coffee and when you're back hopefully things are going to work just fine. So Boxes is like the application I've been working on and Flatpak. A couple years ago applications in the desktop started to be text as a Flatpak and Boxes was kind of left behind because you can imagine that the complexity of a virtualization tool is not comparable to other common desktop applications. As Owen has described, the complexity is also based on the amount of dependencies it has, so it's very easy when you depend on things that are usually part of SDK or a normal installation. And it is hard when you have a lot of dependencies and Boxes uses libvirt, which uses camel, and then you have the spice display, we also support RDP, which means you have free RDP. So a lot of big projects are dependencies of Boxes. And Flatpak has brought us, like you have heard a lot of Flatpak today, so I'm not getting to the details of Flatpak and I'm going to save you both time and patience on this. But the build orchestration actually is a great feature for us in Boxes because I would say that half of the bug reports we receive from users are not our fault. And you know that this is something that I maintain, I usually say, but it's kind of true that in the traditional packaging management the people packaging libvirt and the people packaging spice or camel, they are not the same, sometimes they're not even talking to each other, sometimes they are volunteers, they are just copying some things from other districts. So when you have dependencies which are very well connected to each other and camel has been built with a certain flag and then spice needs to have this certain flag, it can become a nightmare. And the truth is that most of the bug reports were pretty much saying something like Boxes doesn't support a certain feature and then I would dig a little bit and find out that Arch Linux has built camel with some smart car support but it hasn't built a spice with this flag, so it's looking for the flag but it's not built with this support so this type of things that it's like a consequence of the Linux fragmentation that Jan has spoken before and I don't need to get into it. Another great feature that FlightPad has brought for Boxes is the distribution that some distributions just thought that it was too hard to ship Boxes because of the whole dependency tree so they're just not shipping it. And now with the distribution we have it on FlatHub and it's as easy as it gets to install, it's like a couple clicks. And the FlightPad Sandbox enables us to perform non-destructive actions so since FlightPad also enables us to run multiple instances at the same time the user can hack on it and don't cause any damage on their existing virtual machines neither on their host installation or things. So another concept that was around on the desktop before I decided to start working on getting Boxes to work just fine on a FlatPad was Fedora Superblue. Fedora Superblue was designed to be the next Fedora desktop and it's an image-based operating system which means that the basic core OS of it is going to be a static read-only image and everything on top of it is going to be containers. Of course there's this technology which is RPMOS3 that allows you to layer packages on top of it but you are defeating the purpose of having a read-only image-based system if you are just layering stuff on top because you lose the robustness of upgrades and you are just messing up with your install and not decoupling things. And by having an operating system which is focused on containers first we are actually enabling our users to have a very core solid operating system that does these robust updates and have their apps independent of dependencies that usually would expect them to come in the core image of the OS. So Fedora Superblue enables us to have a very reliable operating system and at the same time run on stable applications on top multiple versions of applications on top and that's great for Boxes because one of the biggest challenges is to get people to hack big applications because they just need to build the newest stuff of everything and build the whole world, it's a pain. So you should definitely try Fedora Superblue there is a stand outside, they have demos there and they might help you out with everything you need for Fedora Superblue and so now we are finally at the motivation. So with the reproducible builds I solved the problem with the cross distro support distribution is not having Boxes set with the right things I can just literally go to the GitLab issues and say have you tried the Flatpak and they just try the Flatpak and we find out that most of the issues are on the distro side so then I can tell them to file these reports downstream or just get the users to use Flatpak and most of them are just turning they are just like I'm gonna use Flatpak for now on and not interested on using the packaged one from my distribution The development process has also improved a lot because before we were using GH build so you are just building a different prefix but you still need to build everything locally and the dependencies, the runtime dependencies were things that you just need to catch up and discover when the build is failing and compensate for that So now we have CI bundles so whenever you push something on GitLab we use Flatpak builder to build a bundle which contains the whole build with SysLivirt and Kemu and all and you can just download it, double click it and test it and this enables us to get designers to test the new stuff translators to actually try their translations because how many translators are actually building Kemu just to see whether their Boxes translation is fine is just painful and the simultaneous installs you can have a Boxes development version installed and you still have your stable version which you have your VMs that you don't want to screw up with So right, so the build orchestration this is one of the hardest challenges for packaging Boxes getting all the dependencies to build with the right flags and stuff so this is the moment where I felt a little empathetic with the packages because it's really hard to build so much stuff I don't know if I can actually get my my code to show in that display yeah, there we go so now I don't see it here right, so this is the manifest of the Boxes Flatpak this is the nightly version so you see that the application ID here in the top has the develop prefix applications oh, I don't know how GNOME builder does it so maybe I could just open up in a terminal because I know how to make terminals big yeah, but I don't know this keyboard yeah, but somehow it's eating my shortcuts oh, sorry alright, so I'll describe it, I'm really sorry oh, here I can see it better so the application ID is unique so if this build would have the same org.gnome.boxes then you'll be seeing the same VMs you have on your stable version but by appending this develop thing you can have simultaneous install that doesn't see those VMs so when I run this develop version I don't see the VMs that I installed on the stable Flatpak so they have an isolated container where the VMs are running the libvirt demon is running inside the VM and it spawns it when Boxes is launched and then it just leaps down because there's deburse activation for that so we also save a lot of memory about not running libvirt demon all the time in your Fedora civil bloat because you just need it on demand what else? so here we have the finish arguments which are pretty much the permissions and so far Boxes has device all which means it has access to all the dash dev devices and that's not ideal and that's something that I have in the section of further work of my project which is to use portals to be able to access devices but we still don't have a working devices portal for Flatpak but it's gonna get there at some point we need to just get in motion also file system access here this is mostly because we have this folder sharing feature that allows you to share some folders from the host and see them on the guest and there's a file chooser portal but it's for files not for folders so this is also something that Flatpak needs to change to accumulate these changes we need to have maybe a sharing folder portal or something up to discussion so let's get to dependencies and so here we describe how to build the dependencies you see here that we are doing some patching on this one here to correct some multi-tools build things yeah so a lot of them different build systems so I imagine that for a packageer and understanding that these are the flags that are necessary for you to run Boxes but at the same time we want to build these things and get them working elsewhere for other apps which depend on other builds so delegating to the application developer all these responsibilities actually enables us to do just what we need to do and nothing else more so here we have tracker, disabling a lot of things so another topic of this see Verge Rendering we recently have enabled Verge Rendering for operating systems that support it so you have OpenGL acceleration in your VM so you can run high-performance apps such as Photoshop and things like this and here finally Boxes another aspect here you can see some these apps are sub-projects which I have created for Boxes to introduce new features on it this one is a RDP widget and this one is to support the OpenVirtualization format so the Fatpack also enables me to create sub-projects which can be used elsewhere and ship them together here and I don't need to convince packages or to update a library and things like this these things are quite unstable yet so I don't need to go back and forth with them because we just are in charge of everything from now on okay so let me check where I was there we go so there are certain things that still don't work you used to be able to detect that you connected a physical device and because you are using your dev to detect plug-in stuff so if you connect a USB stick or something the Fatpack Boxes wouldn't be able to see it yet that's also something we need to handle with a portal we now have a FlatHub build which means that you can go to FlatHub.org and download the last stable Boxes and we also have the Nightly Builds which are automatically built every night from GNOME so you can have the latest master comments so if something doesn't work you can try the Nightly Builds and see if it's still broken so for the work this is what is remaining to acknowledge those if-deaf conditions the network bridge so far we don't have the network bridge between the VMs which means that they don't see each other they can connect to the outside world but they don't talk to each other neither to the host which means that you cannot SSH into your virtual machine inside your FlatPacks sandbox with the network bridge you're required to set up a bridge and also forward this file descriptor into LiveVirt so LiveVirt can do its shenanigans and that requires escalating privileges and in FlatPack that is something we don't want which is to escalate privileges inside the sandbox so ideally with the devices portal we would be able to let's say get network manager to create the bridge and then create a little helper which the devices portal is going to use PolishKit so you'll be able to type your password there and forward the file descriptor from the DevNetToon or TAP device into the FlatPacks sandbox and from there on we know what to do with it so we will be able to recreate the network bridge with that but so far we are not able to perform network settings on the host system from inside the sandbox I have some hackish ways to do it but it requires you to set the SUI-ED bit on your binary and run it and you don't want to tell users to install FlatPack and also run a privileged binary at the same time just to set it up we don't expect boxes users to know what they're doing with the bridge network so we want to use also portals for file system access as I mentioned before we can already drag and drop files into it because files are supported through the portal but directors are more complicated because you imagine that you might have some scene links you might have recursive directories and things like this but we expect that we've virtio file system which is a recent work we are going to be able to tackle this very easily by creating a specific FlatPack portal and device access imagine that you want GPU pass through or USB redirection you would be very interested to have a portal that you would be able to decide which devices you want to expose to your specific virtio machines and in the other way around if you want to create some virtio machines which are air-gapped for testing some malicious code whether you're working on security and you want to hack that would be ideal as well so this is future work so yeah here I described so we will pretty much just forward the file descriptor and create a socket pair with it and I kind of ran through this already so pretty much we just need portals and these portals need to be like having boxes in mind that we will be able to forward something not just into the sandbox but from the sandbox expose these two virtio machines so yeah that's a good timing I was planning to go oh you got it I was planning to go deeper on flatback but I guess you already saw a lot of flatback stuff so just a little bit before I was planning to maybe run boxes so I can just press play here you can see the build here in the footer and it's going to run this unstable version of boxes yeah and that's how it looks like it has this nice develop style this nice black team that we like it but it can also change if you don't like black but that's how it looks like we have this nice setup here where you can download the grating systems you can install free rel so you just need to create an account for redhead to know how many people are using it but it's a free rel server you just click here you're going to go to some desktop portal and you're going to create an account for yourself and it's going to download and install rel for you and it's going to use the express install so no one account and here you can connect to your remote machines so I guess that's I guess some time for questions I guess yes it is OCI container oh he is asking whether Flapex is a container yeah well it's an OCI container I would say right so it's compatible with a Docker container in this sense and it just has the niceties for desktop apps so it handles desktop icons and putting the desktop files in the right places and making it easy to show in software stores and things passing into the yeah right the way it is now it does not because we're just poking this hole in the sandbox so the way it is now is just having direct access but we always have this portal in the feature that would allow you to authorize or not to forward the access into the so this is ongoing work you already do for files so if you want to move a file on and off and the GNOME settings panel is going to have in the feature like this application panel where you can decide which application is going to have access to each devices each element you want to introduce in there so it's an ongoing work yeah any more questions? thank you