 Hi, my name is Simon, I'm here to talk about flatback and why Debian should be using it. I work at Collabora, which is an open source consultancy, mostly doing stuff with the known library stack and building Debian derivatives. At moment, I'm working with Valve exploring how we can use flatback to improve steam and steam-offs. Hopefully Debian. So, I've touched on this in this talk a few minutes ago. Flatback is a sandboxed app framework for Linux. It was previously called XDG app, but that's kind of unwieldy. The lead developer is from Sweden, so it got renamed in honour of IKEA. It is an app framework, so it's very much focused on desktop apps, the sort of thing you would find in your app menu, user share applications or whatever. Or alternative, if you like, the sort of app you would find in an app store, so like Android or iOS or that kind of thing. Very much leaf packages, not anything that stuff depends on. They are sandboxed. Obviously, if you've installed one of these apps, you trust it enough to use it. But you don't necessarily trust it completely, and you don't want it to get into PGP keys. And it is for Linux, or if I'm being more pedantic, GNU slash Linux. It makes no attempt to be portable away from that. It makes full use of GNU features, Linux features, things like namespaces. It can use SystemD to put each app in its own scope, but it doesn't have to. Although it's a vnit fan, it's going to be happy about that. And it's not specific to a particular distribution, like Debian, Fedora, Ubuntu, SteamOS, whatever. So, one of the things it provides is stable platforms to run your app. Distributing an app for generic Linux is a bit of a pain. There's this horrible term, ISVs, independent software vendors. And they might think, well, we can target generic Linux, like we can target Windows, or MacOS, or whatever. But it's kind of problematic for them to do that, because all the distributions have different packaging systems. They have different library versions. They have different sets of libraries installed. A traditional answer to this is you pick some ancient version, traditionally old version of Red Hat. These days, an old version of Ubuntu. You assume the system is going to have the most common libraries from that baseline. And you bundle in the rest, so you statically link your binary, or you play games with our paths to get the libraries you want linked. The LSB was, an after a while ago, to define a standard baseline that LSB app vendors could choose to depend on the LSB instead of on a particular distribution. And that's all very well up to a point, but it doesn't have a particularly complete library stack available. And I spoke to Deirdre Boot about this the other day, and he said there's like four or five LSB apps in the world that anyone actually shipped depending on this. So it's kind of a waste of time, and you should maybe go to us to talk about getting rid of it. And if LSBs can't use new features we add, then you can kind of ask, well what benefit are they actually getting from open source? We have new features, fixed bugs, whatever, and maybe five or ten years later they can feel safe actually depending on this new stuff. So this concept of platform problem where you treat what you're depending on as something immutable that you could never fix it. You just have to work around it, and if LSBs are using this old baseline it makes sure they have the platform problem forever. And even when they do the right thing and help us fix our bugs, add new features that they want, that kind of thing, they still have to wait maybe five, ten years before they can rely on it, which is a pretty big disadvantage for them to actually help us. And of course they have to be responsible if they bundle libraries for keeping them up to date with security. And some LSBs do this well, others bundle a library and forget about it forever. This is not what we want. But it's not just LSBs who could benefit from having an app framework. There is some software in Debian that we treat it like the rest of Debian. We run it on a two-ish year release cycle. We have a wonderfully stable platform, and that's kind of useless because this software gets to six months or a year old and nobody wants it anymore. And at the moment we're not amazingly good at solving that problem. We have backboards, and they solve it partially, but they're not really a particularly complete solution. We have a policy that we have to come from testing. But testing is by definition what we are preparing for our next stable release. And if the app is sufficiently fast moving, like has to change every six months to deal with new web APIs or something like that, then maybe it will never be suitable for a stable Debian release with a two, three year lifetime. So we can't put it in backboards because policies have to. It has to be able to cope with its dependencies coming from the version of stable that we're targeting backboarding onto. So, for instance, if it's using new features from GTK or something like that, it needs to be able to cope with that old version for the entire lifetime of that stable cycle. Or we can backboard the dependencies, but then that's kind of a problem because if we try and backboard something like GTK to make our backboard, you'd have to be able to use it. Yeah, well done. We've just desabilised two-thirds of our supported desktop environments because they were not expecting that new GTK version. And if you're sufficiently willing to take that risk, then okay, maybe that's fine. But in that case, what are you doing running stable? Wouldn't you be better off with a rolling release, which, for better or worse, is no more stable drive? So, flatpack runtimes are flatpack's answer to this. Instead of using the slash user from the operating system, the flatpack runtime is basically another small copy of slash user. And this is with the user merge, so it includes the equivalent of slashlib slash bin slash asbin. So you get your runtime linker and all that from your runtime, not from the real system. There is nothing kind of magic about runtimes that means only, like, some approved flatpack vent that can ship one. Anyone can make their own runtimes. When you build one, you choose what libraries you'll put in it. You choose what version numbers you want those to be at. And your flatpack app sees only the runtime. It does not see your real slash user path system. So whatever set of libraries your app has declared depends on, that's what it gets. The runtime does not need to contain development tools. You don't use it as your real operating system. So you don't have to have your debugger and things like that, your compiler. It doesn't have to have a package manager. You ship new runtime versions and kind of forget about them. So you don't need to be able to install new packages into your runtime to update it. You just install a new version of the same runtime instead. It doesn't need to be able to boot, so you don't need in it. You don't need anything assessment related. It is essentially just libraries and a few executables. So the maintainers of flatpack produce a couple of reference runtimes. These are initially built using some horrible Yokto thing. And then stack of libraries are built onto that using flatpack built tools. So there is what they call a free desktop platform, which has all the sorts of libraries that a vendor might have traditionally assumed you had. Like libjpeg, zlib, BZ2, that kind of thing. It also has the lower level parts of what you might call the known stack. So you get Gstreamer, you get Glib. I think you might get GTK. But nothing higher level than that, and you also get Python. So it's enough for a reasonable number of portable apps to run it. If you want more than that, you can have bigger runtime. There is the known platform also from the flatpack maintainers, which adds in the rest of the known library stack like libsoop and extra widgets, things like that. KDE have been experimenting with producing their own runtimes, which are a lot like the known runtime with less known and more KDE. And Fedora produce a runtime, which has all the libraries you would get in a standard installation of Fedora. Because unlike Debian, a standard installation of Fedora is a thing that it makes sense to talk about. We could soon have flatpack runtimes built from Debian with packages dependencies in. And there is interest from Valve in potentially producing a runtime that, for example, the Steve runtime that they have now, which is a library stack, called using AldiLibraryPath, which is what Steve games are expected to assume. So this talk is a kind of tedious, let's have a demo. So I am installing some stuff from FlatHub, which is like the... Can you increase the font size? I can try. No, it's too big. Shut up. So this is coming from a standard to be from FlatHub. If Flatpack is like the Android app framework, then FlatHub is like Google Play Store or something. It's like a central distribution point that you don't have to add, you don't have to enable, but a lot of people probably will. And it's meant to be like the obvious place where you distribute your app or where you get your app. And also where you get your runtime. I'm actually using a local mirror of it on my laptop because I don't trust conference Wi-Fi. And because I'm using this local mirror, I've turned off the GPG verification that it would normally have. I've only got a subset, so I don't want to go signing my subset separately. So I'm installing my test, which is a knockoff of a popular game involving cubes. And it is automatically picking up the free desktop platform. Also coming from my local mirror of a FlatHub subset. So here we go. As you can see, the free desktop runtime is not small. It comes out at something like 160MB for 64MB at the top. Having installed this and thought about it for a while, I should eventually get a game. I don't know why my SSD is a bit excessive today. It's the font size. It's the font size. Repeat it over. It's not worth repeating. There we go, finally. So now that I've installed this app, obviously an ordinary user of Debian might well be using no software or something like that to install this rather than arcade command lines. But arcade command lines are easy to demo. Having installed it, I can run it. I already have a world generated. And apparently DevCon 2017 is a rather nice beach with no trees. So there we go. That's a flatback app. Ask your app, really. It's not work of its font size. So if I rerun this, here I've overwritten the command line used inside the app container. So instead of actually running my test, this is run bash. And this gives me a shell inside the app environment. You can see that I have a slash user, which contains a whole bunch of libraries. It is based on this Yocto thing that has a pile of packages available. And then the free desktop platform builds on that to add, for example, well, there's built tools which are actually present in this copy. But there are also things like drivers and Zenit to pop up dollar boxes, that kind of thing. A particularly small runtime. And over here in slash app, I have the parts that are actually my test. And there's an executable. There are some bundle libraries. So the free desktop platform does not include this game library, LibIrLict, for some reason. It also doesn't include a lower interpreter. So my test has had to bundle those two. And my home directory, as far as the app sees it, it looks pretty empty. And you can see that my real home directory here is not visible. There is just the bits used by my test itself. That's part of the sandboxing, which I will come back to. So I want with each runtime, you need a way to compile stuff. And to do that, we have the SDK, which is another runtime, but a rather larger one. This one does have the development tools. It's got a compiler, it's got your header files, all that kind of thing. The conventional naming is you give your platform runtime a reversed domain name ending with .platform. And the corresponding SDK is .sdk, so like org-node-sdk or whatever. This would not be a whole lot of use if your game was running on, if your game or your app was running on, how unspecified we should have known. So you're back to, well, what am I running on? I just don't know. So we have branches. So, for instance, the current stable version of the known text editor to G-Edit might depend on this week on version 3.24 of the known platform. And then when its author or app vendor rebuilds it in a couple of months' time when known 3.26 is released, they can decide at their own pace to switch branch to known 3.26. So, for instance, known has these versions this by which known version it is. Fedora aligns theirs with Fedora release. And coming soon, Debian-based platforms, which are based on branch of Debian. And I don't think it makes sense to have, like, of the Debian runtime, because what would you put in it? Does it have particular libraries? You can have anything in Debian with the universal operating system. So I think it makes more sense to have a smallish number of runtime, of runtimes of particular purposes. So the prototype I've done is the games runtime, which has some of the libraries you would need to play a game. As you've seen, with LiberoLift for my test, not everything gets included in the runtime. In principle, we could build a separate runtime for every app containing exactly the libraries it needs. This would be a lot of runtimes, but if we script it, maybe no big deal. They get de-duplicated, so it could be fine. But I think we probably don't want that. So instead, the app ends up bundling some extra libraries. Partly this is used for uncommon libraries, so my test bundles LiberoLift, because there are not many other games that use that library. But also some apps that develop very much in lockstack, with a particular library that make heavy use of, like, events that no PDF viewer is pretty much developed in lockstack with its PDF renderer, I believe, LibPoplar. And if the maintainer wants the very latest version of that, they can drop it in Outlet and know that they have it. The app appears in Slash App. Economically, you do this by rebuilding it from source and giving it a different prefix. You do the same with your bunch of libraries, Slash App, like Override Slash User. Unlike some app frameworks, like, for instance, Appanage and, I think, Snap, you do not have to make sure your app is relocatable. Lots of people have designed their apps so that paths are hardcoded at built-time. And flatbacks, like, pragmatic approach to this is, well, that's fine. You can hardcode it if you want. We're never going to relocate the app to some random path. It will always believe it's in Slash App. You'll notice Slash App is the same length as Slash User. I don't think this is coincidence. So if you really need to, you can take your hex editor to your app and replace the references to Slash User with Slash App, and you're good until you need to do this again for the next push. How do these get deployed? As Cosmo said in his previous talk, Libository is, like, get a lot for libraries and operating system files. And it looks quite a lot like Git, so you have your configuration, you have some branches, you have some hash storage. Actually, I lied, that's just Git. Here isository. It looks very similar. The branch names are kind of weird because they include the app name and which branch you're on and things. You can add remotes. So FlatHub or whatever is a remote from which you pull branches. And the objects are hashed with, I think, Shot 256 instead of Shot 1, but it's basically the same. The way this is made to work is the sandboxing layer of Flatpak sets a new app name space. So as far as your host system is concerned, there is no Slash App, there is no view of this runtime in a specific place. But the new map name space for the app creates a tempFS, creates the bound points and mounts the runtime and the app in the right places for it to be able to see them. This is also how it gets its special view of your home directory with only the files that's meant to get that, which is part of the sandboxing layer. It uses a tool called bubble wrap to make sure your valuable stuff is nicely protected. There are several reasons you might want to sandbox your app. You trust the app's author enough to run it, so it's got some, like, attack surface there from it can make system calls, although they are restricted. But you don't want it to have complete control of your system, which is what you have right now for a typical app installed from source or from a devied package or whatever. The app's author, even if they're not malicious, might have made a mistake that someone malicious can get in through, or they might have bundled an insecure library, which we don't want. The way Flatpak does this mostly is with namespaces, so creating a, like, virtualised view of users, processes, the mount table, networks, you can deny networking to your app, that kind of thing. And on some Linux platforms we can just use these, it's fine. The feature in question is up-privileged user namespaces. But unfortunately, user namespaces are kind of scary, because we have an up-privileged user, and suddenly it gets all the capabilities in the new namespaces created. And in principle, the Linux kernel is meant to not let users with capabilities in a non-init namespace do scary things. But people miss stuff, and this CV here mentioned here was one where if you create a new network namespace, you've got network admin access in it. With your network admin access, you can install netfilter rules for firewalling. And there was a buffer overflow in netfilter. So you could add crafted rules that would let you overwrite a buffer overwrite stuff in the kernel, which we don't want. In upstream Linux, there is one config option for this. You can have it all or you can have it off. So in for instance Ubuntu, and I think Arch Linux is just on. And if there is a vulnerability that this exposes, they will just have to deal with it. In Debian, I received a kernel maintainer and looked at this and went ha ha ha no. So we have a kernel patch. If you want to use a namespace, creation is not allowed by default. There is a system that you can twiddle at runtime if you want to enable it at the cost of a war attack service. And in for instance, Red Hat Enterprise Linux, they have a similar kernel patch, but in their patch, it's the boot parameter. So if you want to change this, you have to reboot. So the result of all this is you can't portably rely on being able to create these namespaces. It's a flatpack which wants to be portable and wants to use them. So we have Gullwrap. It's a small set here at executable. Designed to have minimal attack surface. It doesn't use fancy libraries, for instance. It was originally back when flatpack was SDG app. This was a part of flatpack. But it was spun off into a separate project because other things what this feature it turns out. So it gives you a subset of full power of user namespaces. It is enough for flatpack. It is enough for some of the other things that Red Hat's project topic does. And hopefully a lot of the projects that want to use namespaces in practice will be happy with Gullwrap. But it is not as powerful as the full attack service that the kernel gives you. In particular, it will not execute user code until it sets this no new privacy flag, which means it defangs to set you at executable basically. So you can't craft an environment in which a set you at executable will do something unsafe because as far as your confined app is concerned the set you at executable is not set you at anymore. The design principle is it doesn't make too much it doesn't have too much reliance on the set you at. So it doesn't have anything that its maintainers wouldn't like to see in the upstream kernel. So the intention is this can hopefully go away one day. Flatpack builds on this by having a sandboxing model. There is a list of capabilities for each app for what it's allowed to do. It's the same principle as Android permissions where you have your list of this can send SMSs, this can cost you money. So for instance here are the permissions for a fairly difficult 3D game. It shares the network and IPC namespaces so you can play multiplayer and you can talk to POTS Audio. It has the sockets necessary to output video via x11 or Wayland and it has the DRA devices so it can do fast rendering. If we want to escape from the sandbox a bit more there is this POTS app called POTL's named POTL, thank you. So these are a way of getting out of the sandbox with user consent without having to declare this access in advance and then have it available for abuse whenever. So we've all seen the browser security warnings. Do you want to blah blah blah blah blah I don't understand blah blah blah yes. But when these things are done in a less complicated way it's really clear what's going on in your hangouts.google.com wants to use your microphone. Well yes I hope it does, I'm making a call. I think I may have to skip this demo because I'm running out of time but one of the core portals that's actually available with Flatpak is the document portal which presents a normal no more KDE style file open dialogue or save as dialogue but the dialogue box is actually outside the app sandbox and whatever you select in it that's automatically made available to the app via refuse file system. So as far as the user is concerned they're just choosing a file but they don't know they're necessarily making a trusted decision but they are giving the app access to that file, they've said so it's fine. And so the right thing happens and to do sandboxing and have it work well without modifying your apps but one of the key insights in developing Flatpak is that it's enough to mend to modify your libraries so if your app is using a recent version of Glib and GTK it will just automatically use this document portal if it detects that it's inside a sandbox so that's quite convenient. These very briefly work by contacting the host system they have filtered access to the session bus. At the moment Flatpak has this slightly nasty proxy which looks at all the messages and decides whether to allow them I have an ongoing project to integrate this filtering and sandboxing into D-Bus Demon so that we don't have to have a proxy. But one of the things that's automatically allowed is talking to these portal bus names and the implementation of most of these is thinking of the XG desktop portal which I also maintain in Debian there is meant to be only one implementation of this but it delegates the actual work to a per desktop implementation so if you're in known you'll get your known file open dialogue but if you're in KDE you'll get a KDE looking one and so on. So how can we improve Debian with this? First thing to say is this does not replace the majority of what we do in Debian not everything we ship in Debian is something you can call out the entire system layer your network management turn your logins and your in-is system is way outside the scope of the flat pack and in particular flat pack and the portal implementations have to be outside flat pack because you can space also the platform layer per user is not something that can be considered an app like this so like known shell is not an app it's part of the trusted computing base people who use known are the little services that things like known use are also not something that can be presented as an app they are outside these sandboxes distros have to provide these also most of my command line interfaces, development tools servers that kind of thing these aren't really in scope of flat pack it doesn't make any attempt to be suitable for that you can use similar techniques for them the namespace thing is exactly how docker works so if you want your server in docker that's fine but it's not flat packs job one of the things we can do for flat pack is at their best distribution like Debian have a series of well maintained apps where the Debian maintainer of the app is worthy of the name and is really maintaining is an expert on the package and knows what's going on with it even if the upstream is not as responsible as we might hope about for its fixing their security bugs another thing we can do that really helps flat pack is we can build the runtimes we're very good at libraries in Debian we have a lot of policy around them they're stable, they're secure we don't break stuff this is exactly what you want when you're building a runtime you want your library to keep working but distributions are not perfect and some of the time when we're packaging apps making them available to our users it's kind of a little bit pointless so no mines for instance no minesweeper game sorry to pick up the note here particularly since I'm a member of it but most of the uploads of that package are just the upstream release so you can kind of ask what value are we adding to this by packaging it in our distro we're making it available to our users but that's kind of a thing of our own making we're not actually fixing any bugs we're not actually adding any new features we're just turning the handle on packaging and another pretty good or depending on how you look at it pretty bad example is Zalotek a multiplier first person shooter it's not clear what value we have to this because it has been stuck in intent package state for over five years and ok in an ideal world maybe we'd have a package of this and it would be very well maintained but in the world we actually live in a flat pack of this coming from upstream is going to be better for our users than a random binary coming from upstream and a random binary coming from upstream is better than nothing at all so we can get access to potentially quite a long tail of applications by enabling flat pack and using flat pack versions of them where that's the best answer this does not need to be either or some of Cosmos thoughts of flat pack at the end of this talk kind of made it sound as though we had to choose one we don't we can have some of our apps come from upstream directly and be in a flat pack for apps where we are generally helping, adding value, fixing bugs fixing security flaws we can have those come from deviant either in a flat pack or just as a package and these two could coexist and we get some of the same advantages which ever of these we do so for instance if our app is coming from deviant in flat pack 4 we still got this unboxing and that's quite a big win so the thing that is new here that we haven't historically done but now we do is as small as we can is I've put together a prototype of using deviant for runtimes so much like before I'm installing flat pack from a web server but this time the package I'm installing is deviant's version of open arena and this is pulling in the deviant games runtime which as of a fortnight ago didn't exist you can see this runtime is significantly smaller at the moment it just includes enough for open arena I haven't included for instance python or GTK or anything like that it will probably get bigger over time to sport more games but hopefully it will still be smaller than the free desktop runtime while I'm waiting for that to install go back to here so I've recently done this tool I'm calling FlatDev which is a prototype of piecing together a runtime or an app from out of the package packages open arena is kind of big so the idea is for the runtime we can do a debut strap get a minimal copy of deviant and then install a bunch of packages into that if I open up a new tab here so here is a description of what goes in so this is a description of what goes into the new games runtime in addition to what's in a minimal debut strap so we've got exactly the library's open arena needs right now as I said it will eventually grow similarly there is a declarative description of where we get this stuff so in the the base runtime includes an app sources list which pulls in debut and security updates and then I also have a description of the game itself this is quite similar to the jason files that the plug pack builder uses except in y artwork because that has nice things like comments and all of this stuff with the arguments enabling the missions and things is actually what you'd get normally with flat pack the only difference is I'm building some packages here from source I've had to modify them slightly to be real ok at all and also pulling in some packages using act installed yes good so here we go the quake 3 arena engine and if you can see the version number down at the bottom there this is deviant's open arena with fixes and stuff and you really can't see that on the screen but take my word for it that version number is the one from deviant with all the security fixes and not upstream it was released from ten years ago or whatever it is and similarly if I go if I go to chat in there you can see that I've got a rather different set of libraries and here in the app I have just what we need for that one game so the simple case is your app is already relocated some apps don't hardcode paths and then you could just install the dev, move files around job done as it turns out open arena and airframe 3 are not like this they need some small changes, we need to build it with a different prefix so my current prototype is using built profiles there is now a package.flatpack.app built profile which requests to put it in slash app and the dev help and maintainer seems to be interested in standardising this bit so that for like auto tools it will automatically do the right thing there are various alternatives to flatpack for situations where flatpack is just not the right thing which I don't think I have time to go through but if people want to ask about a particular one please let me know and slides and such will be going up shortly on flatpack.devion.net any questions? Questions, first one is probably easiest wouldn't tour browser be a good candidate for handling in this way? Funny you should say that, I was talking about that on the internet, it developed quite recently tour browser would be an excellent candidate for packaging like this it seems to kind of already work that way it gives you synchronous notification of update availability outside of the other notification system so the tour browser launch package is kind of a hack it's forcing the tour browser into our packaging model when it doesn't really fit in that round hull and I think it would be much better if the tour browser people publish a flatpack repository with their browser binaries and either a run time or use a standard run time like the free desktop ones from flathub or maybe a devion published one if they prefer devion and then we could just install flatpack run it, there's your tour browser and secured by PGP keys just the same as apt and it would be nicely orthogonal to how you do apt updates for your platform My other question real quick probably has a short answer do you not think of what ends up on a devion system either with just all packages of a priority standard or higher or alternatively that which you get from task cell if you don't select any tasks install time wouldn't those be candidates for a standard devion release because you said we don't really have that well defined of a contra fedora for instance What you get from a task when you install your tasks in di is a fully working bootable devion system and for a run time we don't actually really want that we don't need the boot process because that's in my form layer that's not our problem if you have a look at the source code of flatbed it actually strips out the init system and the very last thing it does is to call dpackage-purge-dpackage because we don't need it right but you're right that devion standard is something we could have as a run time or the libraries from devion standard but it's not clear to me that that's very interesting because that is only enough to host quant line applications you don't even have things like libjpack but at the same time you do have things like e2fs which who wants that really you know you have to have a fairly specialised app to want to be able to poke at a x2 file system so yeah I do have a base run time which is essentially standard I think but I don't think it's a particularly interesting target I think something like games or the known desktop or that sort of a package set is a more interesting one or the same run time Can you speak a little about the implications for resource requirements I'm thinking disk and virtual memory and other things Yeah okay so yes if you have multiple flatback run times installed you will consume a bit more disk space because they won't have perfectly aligned versions of libraries and you will have the version of like gtk in your run time duplicating the version of gtk in your base system which is not necessarily the same so yes there is some discos you saw that the free desktop platform run time is about 160 meg the better we get a reproducible built the less of a problem that will be because if your binaries are identical OS tree will de-duplicate them I believe endless who layer flatback over OS tree actually share one repository for both of them Yes we do so if by coincidence they have exactly the same version of gtk in their run time and in their base platform that will be the same file hard linked and presumably they try reasonably hard to make sure that in fact you have the same version a lot of the time so a lot of the time in practice they don't pay that cost Do you happen to know if caching of shared libraries is de-duplicated across flatback instances? What do you mean by flatback instances? You're running a bunch of different flatpacks on one system is that going to consume additional virtual memory for all the sets of libraries or is the kernel smart... I don't know how it works at the kernel level because it's the same i node it should be able to know that it only has to cache that file once but I haven't checked that If an application is already relocatable because it follows 6dg datadir could we then build flatpacks directly from devs and not from source packages? Just the information added about what sandboxing that we've asked? Yes First we look at my open arena here One of my built steps is to build IOQ3 One of my built steps is to build the open arena game code and the last build step here is to install the data files which are just in a data so they are already relocatable and flatdown just passes this list and install all the packages If my entire game was relocatable I wouldn't need the source steps I would just include the game engine of the game code in this list of packages and they would just be pulled in moved to app, job done I have another one like this in the flatdown repository which is ganoo hello which is relocatable because what does it even load and that one does literally just unpack the package and move the file so there we go that is all it does not compile it from source Thank you I just had a question about versioning so when you make a flatpack of runtime you can specify all the versions of all the things in that runtime is that correct? To a point yes don't think of it as specifying a version more of specifying a branch so for instance the GNOME 3.24 runtime that is not 3.24.0 which is like GNOME release day versions it's 3.24.something so when they later do a point release to like fix bugs or pull in security updates or that kind of thing the 3.24 GNOME runtime wouldn't track those I include like small changes that are assumed to be not of major risk progressions and then if you have a version that then downloads things from out then those are going to be whatever version is in out as an insult rate Yes, in my flatpack prototype it pulls in whatever was available in out at the time the base title was deboostrupt just as it happens If you have an application which relies on a version of dependency then it can break if out changes If it relies on a very very specific version flatdev does not currently handle that it could it could have a lockstep dependency but I haven't implemented that yet but I would expect that the normal thing is that you would specify a debian suite like stretch or buster and leave it at that and then it would pull in whatever security or bugfix updates have happened in that suite at the time the app was rebuilt and you just periodically rebuilt your app to pick up the latest I'll talk to you later about questions Sure It sounds like we're going to end up with your average deviant stable's desktop running flatpacks using maybe three or four different runtimes like the deviant one, the learn one just because that's what they need to make their apps work Potentially If there's a security flaw discovered in one of the main libraries does our security team now have to patch it in four places because that's going to be a big burden increase So the runtimes that we produce we are responsible for re-spinning those If we're building them from packages like I am in FlatDev then the security team would have to issue a new dev and then press the button to rebuild the runtimes and it would pull in that security update or to rebuild the app of the app bundles it that should hopefully really automate it If no have their runtime that's not our problem no more responsible for updating that How this works in terms of deviant policy I don't know We might want a policy that by default we only enable deviant maintained runtimes I don't know But if the user or the assessment has chosen to trust no or FlatHub as their source of packages then they are trusting FlatHub's process for updating not ours So if you want to use a non-deviant you're definitely going to have to pull it you're going to have to download it as you just did in this demo it's not going to come from one of our repos I would assume that yes I'm providing mechanism here not policy Sort of related to what you just said Can you imagine Do you have a position on whether deviant could ever get to a place where it's enabling non-deviant runtimes by default So for example it's not very interesting for distros to be in the space of packaging that kind of apps but it's also kind of annoying if every deviant user has to go and find out how to enable an external source to find these things So do you think I don't know I feel like there's an argument for putting this nothing by default There are very many, as we just heard very many interesting arguments Yes, I could see both sides of this The people setting up FlatHub are very much setting it up trying their hardest to make it something that distributions can feel comfortable about enabling by default It does contain some non-free software It's free software and non-free software but they've made sure that the packages are tagged according to their freeness I can't remember which one it is that has the tag but it is possible to tell in a machine-readable way and the idea is that if we were to enable FlatHub by default known software for instance would by default hide all the non-free stuff and then have some preference to show it probably the same preference that controls whether we enable contrary but non-free for app sources that would seem the simplest way Barring console applications from being flatback and the other question is there any use case for having console applications flatback? In principle there is nothing to stop you having a flatback app that is console based I mean, here is going to do hello it doesn't have a whole lot of gooey the question is do you want to? I kind of think that there is not a whole lot of use case for it because the attention for these things is primarily the sort of things that would show up in your app store the sort of things that would show up in known software and I'm not sure how much sense it makes having most console applications be directly visible to non-technical users in that way if you if you are happy enough about the terminal and you are very much not Cosmo's user base if you are happy enough about the terminal to run your console app like Earthsea or whatever you are probably also happy about the terminal enough to find out how to install it I don't know whether this means should be flat packs just not visible by default in the gooey or whether this means they should just be continue to be hacked or whatever so over time right