 Hey everybody, my name is Micah Abbott, I work at Red Hat on the Red Hat Core OS project. I'm going to talk about Fedora Silver Glue. This is going to be a very general overview for folks who have never seen it before, never heard about it before. You should come away with a better idea of what it is, what kind of technologies go into it, and why it's better than Fedora Workstation in my opinion. So who's actually heard of Fedora Silver Glue for it? Who's actually using it? Okay, good, a couple of users. Some of the technology behind it are like OS tree and RPM ministry. Anybody use that? Heard of that? Containers, flat packs? Alright, great. So let's start with just the basics. What's Silver Glue? It's part of Fedora. It's officially recognized, officially supported by the Fedora community and the Fedora Project Council. It uses the same RPMs that Fedora produces for all their other distributions. Workstation and server and whatnot. It utilizes containers very heavily for sandboxing your applications off the host. Flat packs as well is a way to distribute your GUI applications in a container format. It's also an immutable host, and I'll get into a little more details about that. And it could be the future. I'm living the future right now just like Doc Emmet Brown is. So immutable host, I made up this quote by myself. It's where the OS is delivered in such a way where OS modification is not expected with an asterisk, because there are ways you can modify the OS, but generally it's treated as a mutable object. So in the server world, the immutable host has may have been referred to as, sort of, Cattles or the new Paradibus Elephants. They're disposable hosts. We can recreate them easily because it's a fixed image, delivered as an image or image-like format. Previously we've seen things like CentOS, Fedora, and Red Hat to Homocost, Container Linux from the CoreOS guys, and then Endless OS. Now why would we want this on the desktop? Well, having an immutable host, we gain things like better security because we can't easily touch the actual OS bits on the host. In the case of Silverblue and other OS-tree-based systems, the way the OS is delivered is transactional, so you have safer upgrades. And I'll get into all these details in a little further along. So let's talk about how Silverblue is similar to Workstation. As I said earlier, they will share the same RPMs from Fedora Ecosystem, so you don't need any new special package format or anything. RPMs work just fine. You can install RPMs on Fedora Silverblue, slightly differently than you would on Workstation, and both can run containers and flatpacks. Differences start to show up in the file system immutability. So on Silverblue, only VAR and ETC are writable. Why is this important? Well, here's an example of why a mutable slash user partition or part of the file system would be bad. This is a screenshot I grabbed from an installer for an NVIDIA driver, as I believe. There is a one character error, the space between slash user and slash lib. So it nukes your entire user partition, which is very bad. If you ran this script, again, Silverblue, it would just fail to run because slash user is immutable. Silverblue has a different upgrade mechanism than Workstation of support for atomic transactional updates via OS tree and RPM OS tree. And during this upgrade process, your running system is not touched. So if something goes wrong, your existing deployment is still functional and you don't have to reboot to try to bail out of the error. It's really so rugged that you can actually pull the power on a Silverblue host and you can recover just by rebooting. The trade-off being that to get into your upgraded version of the OS, you do need to reboot the host. Why is this good? Well, here's another screenshot I grabbed off Adam Williamson. He's his blog. He's a Fedora QE engineer. And he talks about how in, I think it was, yeah, Fedora 24 release, there was an upgrade DNF problem where if you had a certain hybrid GPU on your system and you upgraded from the desktop, it would crash X and then you wouldn't be able to get back into your X session. That kind of shows how when upgrades are touching your running system, bad things can happen. The upgrades are also delivered differently. So Workstation uses RPMs. If you've ever done a DNF upgrade, you know that it's just pulling down RPMs from your DNF repo. Silverblue delivers the upgrades and the OS itself via OS tree commits. And like I said earlier, both can install packages as RPMs. So Silverblue sort of threads a needle between both of those in terms of it can support RPMs, but mostly OS is delivered through an OS tree commit. So what is OS tree? An RPM OS tree. So OS tree can be simplified as get for an operating system or get for a file system. You can basically, you can write out a file system, check it into an OS tree repo, and then check out that commit in a new file system tree somewhere. The files are checked, some are tracked in a content addressable object store, deduplicate it through hard links. It also handles the bootlet configuration and management of slash ETC when you're doing upgrades. So if you have one version of a config file at ETC and there's a new version coming in, as well as modifications you made, there's a three-way merge process that happens, so everything is happy. So RPM OS tree from the documentation is hybrid image package system. It uses lib OS tree under the covers to track the RPMs that are going into the compose. The RPMs are consumed on the server side when you're making the OS tree commit, the OS tree compose, and then on the client side as well when you want to install packages. RPM OS tree is also a CLI binary, so that is the primary entry point for how you would manage your OS. I'll show you some live demos in a little bit. We'll start with this one. So RPM OS tree status, that will give you the status of the RPM OS tree daemon, whether or not you have automatic upgrades configured, information about the deployment like versions, commit checksums, GPG signatures, and I can also report security advisories that have been fixed in a new version. So, here we go, let's do it live. So, everybody see that? So there's, I have, this is a VM. I've got booted up on my system. Everybody see that okay? Big air please? Say when. Thanks, thanks Dan. Put on your glasses. So this is a, like I said, a VM that I booted. It has a single deployment. It's got an old version of silver blue. It's from August 2nd. You can see there's a commit sum attached to it. It's been signed. The commit itself has been signed by the Fedora release key. If I upgrade, hopefully this works, we'll see that it's pulling down the new file objects from the commit, writing them into the new deployment. My running system is still perfectly functional. If I want to, I could hard reset the VM right now, but I'm not, I don't want to live dangerously right now. And afterwards, it prints out a big summary of all the packages that changed, what have been upgraded. Any packages that have been added or removed are even downgraded. If we do rp-missory-status-a, we should see, oh right, I don't have package layers. That's why I wanted it. Well, if I had prepped this demo correctly, you would have seen all the CVs that got fixed in this new version. So, dang, that's it. But as you can see, the dot here on the bottom one, let me bring it up a little bit, indicates this is the version I'm still booted into. The new version is staged at the top. That's the next one I'll reboot into. So if I just do boot process, VM is doing, looks like a normal Fedora install. There's nothing special about it, like I said. It still uses, I mean, we still install via Anaconda. We have ISOs that install, just fine. It uses the same GNOME interface. I'm just using the CLI, since it's easier to demonstrate right now. Now you can see I booted into the new version, and everything works fine. So, back to the slides. So I showed you upgrade. During the upgrade process, you can actually combine package layering operations. Package layering is what we refer to, is when you're installing a package on top of the base OS, or removing packages from the base OS, or overriding packages, and I'll show you those commands as well. I showed you how the system is left unchanged. You remain in the old boot, the old deployment until you reboot. What if the upgrade is bad? So if I want to go back to the previous version, for some reason, I can just use RPMO Street Rollback, reorder the boot entries, and when I reboot, I get into the previous version. It'll actually print out the differences as well. If for some reason you can't get to RPMO Street Rollback, but you can access the grub menu, you can just pick the old version in the grub menu, and try to recover from that point. So, since I promised you a demo, we're just going to do a rollback. It shows that we're moving back to the previous commit. On the system, prints out the changes, so you can see the packages that were added have been removed, packages that were previously upgraded have been downgraded. I'm just going to move along, so I don't run out of time. One of the cool things about RPMO Street is that you can actually switch major versions. So if you're in the workstation scenario, when you want to go from Fedora 30 to Fedora 31, or 28 to 29, et cetera, it's like a DNF system upgrade, whatever the command is. I haven't used it in such a long time. Here we use a rebase operation. It has similar mechanics. It's checking out the new deployment, doesn't touch your running system, it's completely safe, allows you to test and reproduce issues on older versions. So if I'm running Fedora 30, but someone's, for some reason, is using Fedora 29, I could actually boot into Fedora 29, maybe test out that package, test out that bug. I could also change out the entire OS. So if you want to really live dangerously and switch from Fedora Fedora solar blue and run, say, CentOS atomic host, because they're both OS rebase systems, we can support this. This one's going to take, this one could take some time. So I have an OS remote configured on my host. I'm trying to, I want to show you how I'm going to use CentOS's deployment. So I've queried the OS remote. You can see I have the silver blue ref spec and an atomic host ref spec. So I can do pseudo, European OS tree. That commit signed by the CentOS GBG key. So I missed that part of the demo as well. This is not really going the way I want it to. Okay. Well, deal with it. Package layering. So in my opinion, package layering is sort of like the last resort. You want to try to package your applications in containers or flat packs. However, there are cases where you can't do that. Like, for example, libvert you want to have on the host because it's in the host extension. PSC might, I think is a card reading program for key cards, but I haven't used it. So when you do this, the package, package layering operations actually creates an OS tree commit that has the changes based on the base OS commit that you have that you're running currently. You can override base packages as well with RPEMOS tree override, remove or replace, and any changes you make to that base OS through package laying operations are also tracked and can be upgraded during the upgrade process. So install and uninstall, extendings the OS, replace and remove to modify the base OS. Let's try another demo and see how it goes. I'm going to use something simple. Just install a JQ. So what it's doing is it's actually creating a new tree. It's going to get the same metadata we get from DNF Repos on Fedora Workstation, and then download that RPEM and install it as part of this package layering operation. Of course, the slowest part is getting metadata because there's a ton of it to be forever, so I'm just going to try and move forward. We can come back to that in a little bit. So containers, container tools, another big part of Silverblue, if you haven't heard, containers are Linux. This is something that Red Hat's been drumming, making noise with their drum boat except for jails and zones. They have T-shirts, exactly. You might have seen some T-shirts around here. So they use C groups. If you're familiar with containers, should I run through the basics of containers? You don't know anything? Oh, Antonia, I feel so bad for you. The new tools that we have, because we're moving away from Docker thanks to Dan's hard work and his team. If you've been at Dan Walsh's talks, as you can see here, it's probably old news because he's covered it all. We've got buildup, podman, scopio. We used build to build our container images, podman to run and manage our containers, as well as pods. Scopio we can use to inspect our remote registries, copy container ranges between different storage formats. And the new thing is Toolbox, which is a small shell program that is included with Silverblue, which allows you to create a compact container where you can install your tools that you use on day to day. So think of it as a place where you can install your development libraries, your development tools, GCC, all that kind of stuff. And it sticks around with the host unless you want to create a new one. So this presents a new option for container developers where podman's a little more attractive than Docker. So if you've been at Dan's talks, or any of the container teams talks recently, build a you can build images using Docker files, you can shell script it to install packages into a mounted container that supports the different OCI formats. I'm going to go right back to this VM to see if it actually worked. Yeah, it did. So going back to the package layering operation you can see the output, the result. It downloaded the packages and installed it, ran the scripts safely in the background and we have the two packages added. When we inspect the output of our PNL3 status, you can see that running system is still unchanged. If I try to do JQ right now it's not there. We have a layered package entry now showing that JQ is installed in the new deployment. So in order to get access to that, I have to reboot. It's part of the trade-off. Then stick with Fedora Workstation. More container tools. If you were to do one of these upgrades, would you have to then re-add the JQ back in it? No. So the question was if we did an upgrade after I did the install of JQ, would I have to re-add JQ? No. That's tracked as part of the deployment. So when you upgrade the JQ package would follow along the upgrade and also be upgraded as well as upgrades available. Is that true or not? I'm sorry. You can install JQ and then after that if you upgrade, the next upgrade includes JQ. Does that include even if you don't reboot into the new image with JQ? Yes. So the question was would the layered package be upgraded even if you didn't reboot? If you did an RPM L3 upgrade that process brings in all the updates for the OS including any layered packages. Does that apply to the KBSP image you haven't yet rebooted? Right. So it would apply to let's go back into this for a second. Whoops. So now that I'm in this new deployment with JQ if I were to do another upgrade actually back this up. Actually we can do it. All right. So we're going to do an upgrade because I actually rolled back, I forgot. This will actually be able to show the CVs I think. So there's probably not an upgrade to JQ because it doesn't get upgraded very often. It's a pretty simple program, right? So in this case I still have the bits from the previous the upgraded deployment on the host so it didn't have to fetch the data from the network. This is what I wanted to show earlier. So you can see now the new deployment I have pending it lists out all the security advisories that were fixed in this deployment and the packages that were assigned to the CV numbers the package versions. So it's very helpful if you're security minded and you want to delay rebooting for what a reason maybe you don't want to you don't feel you need to take that upgrade update right away. Very cool trick that RPM's most has learned I think. So pardon me again it's basically a drop-in replacement for the Docker CLI to do an alias Docker equals podman 99% Dan 98% Is it paying attention? No. A lot of the Docker CLI commands are replicated in podman so you probably wouldn't know the difference. It doesn't have a daemon so hashtag no big fat daemons for Dan. You can also do rootless or unprivileged containers. As a regular user you can run containers using podman. Scopio I use it mostly for inspecting registries like I have a if I want to look at which tag is what the SHA256 digest for a tag is I can go and inspect the registry and get that kind of information. Or if I could actually copy if you saw Sally in the Rashi's demo earlier this morning they showed copying from the Docker daemon on your host to the podman container storage so it's helpful to copy existing images between the two container storages. The toolbox I mentioned earlier creates a mutable container for installing death tools or any package on your host that runs rootless so you don't have to use sudo and automatically mounts in your home directory so let's try to do that. So the way I do that I do toolbox create and place along so it's going to it defaults to Fedora toolbox container but you can specify any base image for your containers you could have one for Node.js you could have one for NPM whatever the case may be or you can just have one big fat container that has all your tools included which is kind of the model I use rather than having multiple different containers to track Could you have toolbox with a different container? Yeah, you could do in theory I don't know if this I don't believe the toolbox supports the different distros right now it's very Fedora specific but in theory it could be done pull requests are welcome. Flaphacks are the other side of the container story for Silverblue it provides a way to containerize your GUI applications because the LCI containers I just talked about with all those tools are good for command line tools like JQ for example S3 is GCC that kind of stuff but if you want to containerize a GUI it gets a little gnarly unless you're Jesse Frizzle and have a bunch of daughter files that does all that for you so it Flaphacks actually uses LIBO history as well to store the data for the run times required to run the GUIs and the apps themselves on the disk uses bubble wrap for unprivileged users can talk to D-Bus and SystemD apps are distributed via the OCI image format or through OS tree repos as well and this kind of opens up the distribution model a little bit more where you can just distribute a single Flaphack with all the different dependencies to a different to a Flaphack repo and then the Ubuntu guys can run it the Arch guys can run it the Fedora guys can run it for ladies or guys I want to be inclusive but it takes the container story to the next level for GUI apps so going back to Toolbox for a second I've got the Fedora Toolbox container created to go into it simple as that and this is just doing normal enough stuff inside a container this is no big deal let's go to the actual GUI part of it and we're going to see if I'm going to try to install Flaphack and hopefully the network cooperates so some of those ships Firefox as part of the host we could we're waiting for the Firefox Flaphack to mature before we take Firefox completely out of the host because we've had instances where we've removed certain applications from the host that had Flaphacks and people complain because they expect them to be there by default the most popular Flaphack Flaphack repo is called Flathub has anybody used Flaphacks or Flathub before? a couple of people so similar to the way we have our PMOS tree has an OS tree repo for getting its data we need to install a Flaphack OS tree repo on our host probably could have done this ahead of time but now you get to the pain I feel so one thing I didn't mention is that if you use GNOME we have the GNOME software capability and GNOME software understands Flaphacks and understands RPM OS tree the support for RPM OS tree isn't the greatest as well as Flaphack there are some rough edges you may hit errors if you go through the GNOME software route but each release gets better and we hope it to be completely seamless before we turn it over as like the potential default replacement for Fedora Workstation so in the background you saw the DNF install of S-Trace completed in the toolbox exit the toolbox and then go back in S-Trace is there if I look at my home directory it's the same thing as in the home directory in the host I'll exit out the same stuff pretty handy way to move away from installing your development tools and libraries on your host and keep them containerized so we've got a Flaphack installed to on this VM if I can make this bigger for you so flat so we use Flaphack search let's say Spotify for example I know that's or I can just go to the Flaphack so Flaphack install I've got this Spotify client oops too many so it's going to ask for necessary commissions to install it do you want the run times yeah of course I do do I want to do all this of course yes I want to listen to music on Spotify so now it's going to pull down the different run times you've got the platform which is basically the core of it the core of the library is required to run these GUI applications from free desktop some codecs localization files we're going to let that run while I keep going forward before I run out of time that's a whirlwind tour through all the technology if you haven't been paying attention to SolarBlue lately we've had some nice improvements to the experience before we had a limitation where you couldn't install software that was installing to slash opt namely Google Chrome is one of the big requests that we had like why can't I install Google Chrome I don't want to use Chromium thankfully Alex Larson stepped in via RPM OS 3 and now we can install Google Chrome to slash opt not all the software is going to work but Google Chrome is at least unblocked we also have support for NVIDIA drivers so if you have those hyper-forms GPUs for running games and whatnot or machine learning tasks whatever the case may be we have support for installing those as well which kind of unlocks another use case of the workstation from the GNOME team at Red Hat who was responsible for both those changes so thank goodness for him going forward we want to enable automatic OS upgrades by default I forgot to show you that but it's an easy one line fix to a config file when automatic upgrades are enabled on these RPM OS 3 systems the upgrades are downloaded in the background and staged and then you can choose to reboot into them whenever you want it happens just without even you knowing it's a little system deservice it's great we want to install more flat packs out of the box we weren't able to do that up till now because Fedora didn't have a flat pack registry we're starting to see more flat packs be produced by Fedora so we'll be able to enable the Fedora flat pack registry on new installs users will be able to install flat packs we can't distribute flathug because of probably legal reasons and there's been talk of making silver blue default workstation choice it's very contentious if one fan back there thank you very contentious because some people are really want to hold on to the DNF workflow because they love it so much but the I mean if you've ever done a DNF upgrade and it's gone south in the middle of it and you're left with a system that's broken our PM ministry is the thing you are looking for so maybe I don't know 31 is not going to be the default for workstation but maybe in a couple years we'll be at a place where we can do that the other development we're starting to talk about is building silver blue through a new tool that has been developed for building Fedora CoreOS and Red Hat CoreOS called CoreOS Assembler it's essentially a wrapper around our PM ministry a number of tools basically to produce a OS using the OS reformat Colin Walther is one of the key contributors the architect of OS tree and our PM ministry he's been hacking on this trying to get us to a point where we can use CoreOS similar to build any our PM OS tree based OS so that'll be pretty cool if that happens then of course like improving the documentation and growing the community our documentation is a little lacking right now we could use more help in that area for sure and then just growing the community getting more users on board trying it out reporting problems you can do that through here we have a great discourse forum that's up and running we have docs that are like I said need updating we have an issue tracker on github for reporting issues and we have a twitter handle for tweeting problems to us or suggestions whatever thanks for coming to my diffcom talk you can get in touch with me at twitter or an email via those things there so questions you serve in the back running it on my laptop at home on my kids laptop, fantastic brilliant everyone should use it a couple of things I think there's still room to improve the availability of flat packs things like there's no tool browser and that's an important thing for lots of people who are an open source and things like numtweak tool doesn't run which means you can't restore sessions or you can't have start up it's things like that it's not fully usable yet and I encourage people to use it but it's a fantastic piece of work and keep doing it thank you thank you for the feedback I agree the flat pack there are those rough edges that we need to polish off and make it a little more usable we need to be able to give it to not a developer basically not someone who's willing to dig into the journal and figure out problems and say oh do you want to install Spotify well just go through numtweak search Spotify and install it and you're good to go so we have usability improvements for sure anything else Neil so this looks quite interesting and it seems to have advanced a fair bit in my attempt to use it and it kind of stalled out on installation so that's good but I know it's not my bag are you looking to like collaborate with some of the other desktop groups within Fedora to see if we can get some interesting flavors made like for example KDE using Wayland with this because with this new model it's a lot easier to experiment with that kind of thing or trying out Mate with their new experimental Mirko which is also Wayland and things like that giving people an opportunity to try the new tech with the kind of desktops they like in the brave new world of maybe secure so Neil's question was I'm not a known user how do I use additional or different desktop environments basically so there's two ways you can actually just pack an RPM OS to reinstall KDE or whatever on top of the existing Silverblue installation and then at boot choose which desktop environment you want to go clearly that's not the optimized path there's a community member who maintains his own OS to repose of a KDE version XFCE deep in a number of different desktop environments I3 I think so it's possible to rip out all the GNOME stuff and put in a new desktop environment and have it work I also would love to see a different spin of Silverblue for the users who want a different desktop environment I don't know of any official talks that have happened in that regard but it's certainly possible we have the community to support behind it maybe we just need to have the right people to make it happen but yeah so the answer is kind of someone else I've not used Silverblue yet but I've been using flatpacks on regular fedora and one thing I've noticed when like installing some of the audio recording and music notation software many of them depend on KDE dependencies and some of the things I noticed were it was using up a lot of disk space because different programs were downloading different versions of the different KDE dependencies so is that just like good distro version hygiene that just hasn't happened because it's not a concerted distro wide effort yet or would that be an ongoing problem where maybe developers are not updating to the latest version of libraries and so we end up with a lot of extra different versions of everything so the question was basically like what do we do about flat pack flat pack bloat where different flat packs are installing different versions of the same supporting libraries I would say that it's probably best solved by right now it's probably best solved by the individual flat pack owners so whatever sound recording software you were talking about they need to stay as up to date as possible as long as well as all the other flat packs like I really don't have a good answer for that but it's a I understand the problem I understand the problem there there's somebody on the forums who's just complaining about how this is like no flat packs are no different than if you're installed a game from the steam store then on windows they install all these different DLLs versions for the same libraries but because it's they've been versioned differently you have to install them so it's a similar problem I'm not sure we have a good solution for that right now Dan? So Toolbox is really cool from a developer point of view but a lot of times I might be setting up a service to run out of the system D as system D become aware of what's going on with Toolbox yet but I set up a container image that at boot time would start a service inside of my container So Dan asked can I set up a system D service to start a Toolbox container is that a good summary? Yeah, more complex than that though I want to install Apache inside of my Toolbox as root as you were showing and I want at boot time I'm going to enable that system service and then have Apache come in and have that service So Dan wants a system D service to start a Toolbox which also has Apache inside of it and that service is started as well when the container starts Wouldn't you just use a regular OCI container for that? Well no because I wouldn't have Apache installed in my system so I have to install Apache inside of a container and then I need to I just I mean my normal workflow would be to bottom line is is system D starting to look how they can interact better with sort of this new silver blue type environment where people are installing software inside of containers So what Dan really wants to know is has system D become aware of how we're doing how silver blue is handling user containers like Toolbox and to the best of my knowledge I don't know of any new developments in that case Any other questions? This is probably more of a flat pack interoperability but I was running flat pack with open source graphical applications and one of the things they couldn't do they would try unsuccessfully like you were working on an object and you could open it you know there's like a right click and open it in another open source image editor and on a normal DNF system that works great but in a flat pack system because they're launched differently however they were launching it it fails. The question is basically let's see if I can summarize this when you're using flat packs it's hard for the flat packs to communicate with each other essentially right so trying to launch trying to trigger an event from one flat pack to another it just is not not easily done right now flat pack does have support for what they call portals and that gives you access to basically opens up the flat pack with different permissions to talk to debuts for example or even different flat packs I believe or access you can even have a portal to access the file system itself so it seems technically feasible and I think as the flat packs are becoming more widely adopted and more understood in terms of how to package them we'll see more we'll see better integration in that regard right now it's more along the lines of taking whatever flat pack you have figuring out the right changes you need to make to that flat pack to open it up for access to other flat packs from the system and then running it that way this is one of those in terms of usability improvements like one that we have to keep surviving towards any other questions? this red hat is going to replace their CSB corporate desktops with Silverblow it's a tall order Dan I don't know that's above my I agree so Dan's pointing out this is a perfect corporate desktop because you don't need root you can install packages in your user space containers you have flat packs you can deliver updates at the cadence you want through your own custom there is a lot of benefit to using it using this method for question in the back you can yell and I can try to repeat it I have a question in this regards to the red hat I understand the red hat they have their own cloud system I don't know if I'm permitted to ask a question but if you understand about Amazon AWX everything is on cloud base but during my research I'm just trying to find out how is red hat trying to work with other cloud system so you can access other cloud systems like Microsoft, AWS true red hat because I think that's a big challenge right now so I'm just really thinking I'm just kind of imagining what is red hat really doing about it since I'm really trying to take the certification the question is how is red hat working with other cloud providers besides AWS man that's way above my pre grade I don't know I know for example on the open shift side we have support for AWS we're working to support other cloud providers such as Azure and GCP Terry sounds like he's going to answer this question for you I might be able to help a little in terms of like something like this like silver blue desktop experience or general so at the risk of stealing their thunder for this topic we could talk outside but we have tons of teams working with all of the cloud partners we have a certified cloud partnership and we have a ton of management tooling and certification efforts to support all of the clouds so we can talk more later any other questions? the server side? so the question is where is the server side for this well this was actually birthed out of atomic host so red hat and fedora and centOS had a server version of it called atomic host used the same infrastructure technology industry and rpm industry it never really took off as well as much as we wanted to now what we're doing is we're using that same technology to provide a mutable host in a server format for open shift so open shift 4 uses rel core os as the default os the only os actually supported for all the masters and the control plane other than that red hat does not have a rel 8 based offering using rpm os there is a rel 7 version of atomic host which uses rpm os but given that rel 8 has been released rel 7 is not long for this world anything else? up till now i have been using my desktop as partly server running live word and other things how do you see that happening once we go here do you suggest that we have a dedicated desktop which runs silver blue and a federal server version somewhere else doing the desktop server things or the intention is to run live word and other things also so how do you run live word on silver blue essentially all you have to do is package layer it install the live word packages and you can still interact on the host level use vert install to install images this laptop right now is running silver blue and i'm running so i've got vert manager right here got a couple of vms in verse right now so it just works going once thanks for coming guys and ladies