 can't talk about it so far because, you know, we have this tested space operating system and as you ship, if you just install the workstation, um, comic workstation, you'll have, um, you know, three or four applications, you'll have your terminal, you'll have, so the question is what, how do you get more software onto there? Um, and there are basically three ways I'm going to talk about adding new software to there. Sort of the way that we're targeting for your parents for a technically non-savvy user, basic idea of Flatpak is it's, um, sort of like containers but for desktop applications, very specialized for desktop applications. Um, an application is sort of independent operating system. It has all its dependencies, great application, without having to break your tested operating system core. We're presenting these in GNOME software. The question is where to get these Flatpaks from. And there are sort of free places where you might get a Flatpak. Um, sort of one of the goals of Flatpak is that you get your Flatpaks from the application creators, from the person who wrote the application, open source project, commercial company and, you know, that, you might just go to the website, they might have a link, you can click on download and install. Well, we're expecting a lot of applications to come from for the comic workstation is from, uh, Fedora itself and we're working on taking door packages and rebuilding them to be, um, that's still a work in progress. It's not something we're going to have many out there for Fedora 27, but hopefully by Fedora 28 we'll have a lot of Flatpaks. And that's probably going to be necessary to take this and make it really suitable for, uh, novice user, is that they have the stable base and they have a good set of applications to install. Stable base without the applications to install is not as interesting. Um, then finally there are people working out on there and taking software and packaging it up into Flatpaks. So if you go to Flatpak.org, you can find Flatpaks for some applications, you know, still sometimes feels like you're hunting around from one place to a different place to find your Flatpaks. So right now you are, it's somewhat of in a hunt and seek for Flatpaks, but we hope to get to the, to the situation where you can ship the comic workstation and out of the box there are, so that's what you do for a desktop application. But what if you want a server application? You need Postgres. Well, generally what we're going to say for that is you want to use containers. Flatpaks is not a solution for server applications. For a lot of the typical server side stuff you would deploy it as a container. Containers are also generally what we say that you should be using, if you do that want that development environment. If you want GCC and kernel headers, and kernel is a bit of a special case, but essentially if you want to develop an environment you do that inside a container, and on the sort of trying it out instructions will, that was on a previous slide, there's a little bit of some hints about how to set up the package. So that's, this is something that's sort of evolving. We really need to figure out how to have good workflows for developers that are sort of there out of the box. And then the third way is package layering. And package layering is essentially that you can say use these packages to extend the core operating system. Now in some sense that breaks the idea that what you're running on your system is exactly the same as what's been tested. And sometimes when you layer on packages, you've added a failure mechanism and upgrading because you could try to upgrade and might say, well, this package is no longer available. So it's not necessarily great for the case of unintended parents using it because we no longer say that we've tested the next version there. But it's really, really, really useful. And it's probably something that we need. It is something we need to make atomic workstation work for everybody. So let me give you an example of package layering. Say if you wanted power line, you could do RPMO history install power line, it go out there, it would look at the Fedora repository, find the power line package, but wouldn't just go ahead and install into your current tree would make a new tree with with all the packages in the core plus power line and then make it available for the next reboot. So that's you see now to do RPMO history status, you see two deployments, the current one and the next one. And the next one has the has listed under layer packages power line. And if that layer packages line has 10 or 15 packages, that's reasonable, that layer packages line has 100 packages you'd probably do. So after reboot, then you see that you have there's work going on. I think it's probably pretty much landed this point to avoid that reboot step for the initial install. I don't think it's in the door 26 but in the tree there, it would sync with the tree you're using. In general, it's not it has a big advantage over a traditional system in that it's very explicit what's been layered on top. In generally an artificial system, you have no real idea what was a part of the base. And it's the same question. So the session was that you could set it up locally on your own system. I think those are both things that would probably work. I mean, it's a bit strange to be doing RPMO history living from a repository in your home directory, but I don't see why it wouldn't work. It is a private