 My talk, when I submitted it, it was called Life and Death on Fedora Atomic Workstation. And since then, things have changed and got renamed. And now it's called Life and Death on Fedora Silver Blue. So I decided that I'd spend the first few minutes of this talk talking a little bit about the changes that led to that and why it's Silver Blue now. And then I'll switch over to give some impressions of how daily life on such a system actually is. So let's dive right in here. This works in a different direction. So the first section is going to be about the renaming and rebranding. And these are the highlights for that section. If you take away just these three points, then you can sit back and wait for the entertaining part to second off. But I want to talk a little bit about the fact that Silver Blue really is just Fedora. And I'm stressing that because when we first started talking about Silver Blue, there was some concerns that, oh, we're trying to do a new distro outside Fedora. It's going to be a competitor. And why are we doing that? So that is not the case. Silver Blue really is just Fedora. It's the continuation of something that used to be called Fedora Atomic Workstation, which has existed since roughly Fedora 25. And it's built from Fedora RPMs, just like any other Fedora edition is. It's just that we compose those RPMs on the server side and deliver the content as an OSTree image, an OSTree repository, similar to what Atomic host does. And we install applications via Flatpak. Yes. But why did we decide that we need to rename it? So I don't know about you, but to me, Workstation sounds a little old fashioned. But when I hear the name Workstation, like a computer comes to mind that looks maybe like this, like a spark station from the 90s. So that's not necessarily the impression we want to give people. So we want to have a name that sounds fresh and interesting. And the other half of the name Atomic Workstation also is not so cool for marketing purposes. I mean, we in the know, we text save users maybe nowhere else comes from and find it okay. But for the rest of the population, the closest thing that comes to mind is probably nuclear waste. And since we want to reach out beyond this audience here in this room, we decided that it would be better to avoid that. So, yes, we decided we need not just a new name, but also a new logo, a new website, and new communication channels. The logo that we came up is the thing you can see here. If you squint a little, you can maybe see that this could be like a leaf. The original name that we were going for was going to be silver leaf. It didn't work out for some reason. So, we had to go with silver-blue in the end, but the logo still kind of has this leaky feeling to it, which I think is nice. You can maybe think of it as a new leaf on the Fedora tree or something like that. And down here you can see the link to the website that we set up, and we have a Twitter handle by that same name. And as I said, we also wanted to try something new for communication instead of a mailing list that may be the most comfortable for us, or thoughts. We decided to set up a web forum using this course. The link to that is down there. Yeah, what I should also say is that when we started setting this up, we did things pretty quickly, so we got our own domain there, teamsyverblue.org, and we're now in the process of moving this over to Fedora domains, so some of the URLs that you see here might change over time. For instance, the discourse server has already moved over to the Fedora side because we want to use this course a little more widely in the Fedora context in the future. Right, so Fedora Atomic Workstation, as I said, has existed for a while since Fedora 25, and it was kind of undercover. Not many people knew about it. A few of us were trying it on and off, and it lived off to the side under the umbrella of Project Atomic next to Atomic Host, and a bunch of the other new container tools that we are hosting there. And yeah, so when we decided this year at DevCon from February that we were going to try and push Atomic Workstation and make it something that's more public and more visible and ready for primetime for a wider audience, we did not know yet that Red Hat was going to acquire CoreOS. That was the surprise that we all learned of an on-the-flight home from DevCon. So it has taken a while, but by now it's become clear that Atomic Host is going to be merged with container Linux that we acquired that way and it's going to become Fedora CoreOS. And the Atomic Workstation is becoming silver-blue, as I already said, and the other projects that are currently hosted under Project Atomic are going to find a new home and a new place for container tools. And Project Atomic is basically going away in the medium future. In a way, it was very lucky for us that we already had embarked on this rebranding effort just in time to be surprised by this. Right, so much for names and brands and now I'll switch to the actual topic of my talk and I want to give a little bit of an impression of how daily life is on an Atomic Workstation, or silver-blue system. I started, I reinstalled my system after DevCon and forced myself at plate with Atomic Workstation before like in the VM, installed it off to the side. You play around with it for 10 minutes and then you go back to your actual system and do your work, which kind of doesn't really force you to like figure out how things work on this kind of system. So I decided that I'd have to actually reinstall my system and force myself to use it day in, day out. And what I'm showing you next is basically the experience I had doing that. So the first impressions are, I just show a few commands that you could run on your system to see how it feels. So if you run DNF installed, and I can install some extra package, which seems like the most normal thing to do in a fedora system, you get total DNF and I'm not found, that's pretty shocking. So you're gonna get anything done on a system that you cannot install a package. Now maybe you might look around a little further and you look for slash user, how it's mounted and you'll see, oh, it's read-only. Then that means that DNF wouldn't have done you much good anyway. But if you never sign that, this is really a system that's not like the other fedora systems. The third command I put down here is like calling RPM. RPM at least is installed. You can run RPM-Q-Connel and it'll tell you well, this is the kernel that you have. So that's at least a little bit of a good sign. There's still an RPM database somewhere on the system and it can actually tell you what's installed there. So there's still some familiarity left. Yeah, moving on, basically DNF is not there so you have to learn to work again and figure out how you can get things done on a system like this. The important command to know here is RPMOS tree, which is the tool that we are using inherited from Atomichost to update the system and install from an OS tree repository. There's a bunch of useful commands. The one that I show here up top is RPMOS tree status which basically gives you a bunch of output that tells you which image is installed in your system currently, which version it is, what the exact commit is. I abbreviated this a little bit if you run it, you'll see there's more coming. It'll tell you about the other images that are also in your system because RPMOS tree actually keeps more than one system at a time and lets you switch between them. As I said, RPMOS tree, the second command down here, RPMOS tree upgrade is what you run to pull down the latest, basically the equivalent of DNF update. Yes, what did I want to say about that? Yeah, I didn't have an upgrade available here. Otherwise it would tell me a lot more about what's actually getting installed. And I should say I'm running these commands and not as root because RPMOS tree has a system demon that runs in the background and if it needs privileges to do things, the command line tool will just talk to the demon and get things done that way so you don't need to run it as root. Yeah, at this point I'll have a brief intermission about talking about why we may want to use RPMOS tree in this way. The basic idea is that this is an image based system so I'm installing an image which is identified as a unit not individual packages that get combined on my system and then a bunch of postscripts get run in undefined order and the outcome is not really clear so this is an image based system where I pull an image that is still identified by this commit checksum and everybody who does the same will get exactly the same bits on his system which is kind of very nice for reproducibility and QA so QA can actually be sure that they test the same bits that users have on their system and reporting bugs becomes a lot easier and the way this works in practice is that RPMOS tree when I run the command RPMOS tree upgrade will start pulling down the new bits and put them somewhere on my disk until the full new image is assembled but it's not gonna modify my running system underneath me like the slash user that I have was read only and it's not going to get modified and I actually have to reboot into my newly downloaded new image which means that the updates are actually atomic so I'm running the old system until I'm ready to switch into the new system with a reboot and there's no weird mix states and if I lose power in the middle then I just the next boot will bring me back to my old system rather than to something that is half updated or broken. Yeah, I already mentioned the third point here RPMOS tree downloads the new image but the old image is still around after I rebooted into the new image. If I find a problem I can easily reboot back into the old system so that means that roll back so I kind of easy. The last point I put down here is that the downloads are at least somewhat efficient because Austria uses content addressing so it'll only download files that have actually changed if it finds that one of the files it needs is already on my system maybe because it didn't change from the old image to the new image then it's just going to keep reusing the file that it already has but moving on to learning to do more things on the system. The first line here shows the dirty secret of RPMOS tree or if you want to put it in a positive way the charming compromise. You can still install packages even on this image based system it's what I'm doing here RPMOS tree install GDB it's going to like go out to a younger repository find the GDB RPM downloaded and then do some magic and the magic that it does is RPMOS tree will compose a new image on my system by combining the existing image that I have currently running with the layered RPMs and create a new image. I still have to reboot to get the new image so in that sense it's still image based but I do lose some advantages that I've just had on the previous slide. I said that everybody's getting the same bits now I've composed an image on my own system that has whatever RPMs I needed at the time so it's no longer going to be the same bits. I lose that advantage but at least it's still atomic I have to reboot to get into the new image and in that sense it's still safe. This is called package layering and it makes the system a lot easier for somebody who comes from a traditional for their own system because at least you don't have you don't have both sides behind your back but just one. But maybe this is not the ideal way to go because this layering, as I said, brings back some of the problems of package based systems so maybe the right way to go is actually to look at containers and when I started this journey in February I didn't know much about containers at all. Hadn't really used stock at all before so I found builder and everybody thinks it's cool so I thought I should try it and build myself a container and this is how you do it you say builder from Fedora which downloads the Fedora base image and then I can run it like this and inside that container I'm using a different color here to indicate that these last two commands you are running inside the container. I actually have DNF there because this is like a Fedora system so a lot more traditional I can just DNF install something and it'll work and then I can try to run it and when I did that back in February I discovered oops, I didn't have a display here because the container is isolated from my system and I tried for quite a while to figure out how to fix this but I don't know Docker and I don't know a lot of the technologies involved there and despite me trying to leak the display socket into the container I could never really make it work. A little frustrating. Thankfully things can get better. The bushy on my team is working on making this something that you don't have to figure out for yourself you're working on a toolbox container which will basically be like a ready-made Fedora container that has a bunch of useful things in it and will be set up in a way that makes it very easy so actually yesterday evening I finally got around to try out what the bushy has so far and I found that if I use this toolbox I can again install my little test application here and I can just run it and it works. So this is hopefully coming in Fedora 29 and should make things a little less hard to get going. Yeah, another quick interlude here. The workstation target audience developers are obviously a very important segment of that so the atomic workstation is supposed to basically replace it over time so we kind of still need to target developers and that means in this case in particular we need to make sure that container tools are installed so all of these will be installed on a silver-blue system. Portman, Builder, Scorpio, and maybe even Docker, I don't know. And this toolbox that I just mentioned, I hope we can bring it in for Fedora 29. And longer term we also want to look at making, yeah making the terminal that you run on the desktop a little more aware of the context in which you are like if you're jumping in and out of containers a lot it becomes important to know where you are so we're looking at making the terminal a little bit aware of that and maybe telling you about that. There's some other alternatives that I tried out back when I started in February just to get my work done. Flatpak Builder is a build tool that comes with Flatpak which uses containers and avoids host tools for like doing builds so that works well on silver-blue and GNOME Builder is an IDE that does things in a similar way also using sandboxes for builds and not using host tools and you can install both of these actually from FlatHub with a command like this down here. Yeah, and now that I've started talking about Flatpak I'll talk a little bit more about that. I said earlier on that we're using our PMOS tree for the OS image itself and we're installing applications via Flatpak and Flatpak is essentially just desktop containers you could say using all the container technologies that Dan Walsh talked about this morning just wrapped up in the right way to make desktop applications work nicely and so they are going to be isolated from the OS and we can update them independently and safely. Currently the best place to get Flatpak is the website called FlatHub. I put the wrong URL there but if you go to www.flaphub.org you'll find 350 or so applications that are packaged in this format and well that's pretty good. It's not something that we're comfortable enabling by default for Fedora because there's a mix of proprietary and free applications there so kind of the API infusion problem all over and thankfully very soon we'll start building Flatpaks directly inside Fedora. Owen is somewhere here who worked on this so as soon as this week actually or next week we'll start seeing Flatpaks come out of that and those will be available from the Fedora registry in the form of OCI containers and we'll look at making those available by default. Yeah going back to my experience from back in February after I learned how to do some basic things in containers I got somewhat comfortable with the system but I'm using the raw height stream and raw height is still raw height so you hit all the usual problems in this broken composites. That's not so bad. I mean if you don't get an update for a day you just keep using what you have. Unfortunately the most recent phase of broken composites has now been lasting for well over a month. I'm a little disappointed by that. I hope we can get a compost going very soon again. Yeah and Owen sometimes you also hit a working compost and it just turns out that the updated image afterwards fails to boot or doesn't work in some other way which on a traditional system would be the time where you look at maybe a few hours of lost work because you have to struggle to get your system back into a working state and that's always very annoying which is why a few people lose raw height if they have any sense. Thankfully on silver blue raw height this is a lot easier because as I said earlier there's easy rollbacks so you can just reboot and switch back to the old image and you lost maybe a minute or two, not an hour or two but that's very nice and that actually gave atomic the slogan fearless updates. That's an important characteristic of this kind of system. You can just update and if it doesn't work as you thought it should then you can easily get back to a working system but it's still just software so it's sufficiently stupid or determined human can still break it and I thought I'd tell you about the one time where I almost painted myself in the corner on the system. So this was a snow day and it was morning and I had just installed an update and I needed obviously a web browser because it was snow day I was stuck at home needed to be in a meeting in an hour and so I rebooted into my new image and I didn't get a login screen because Norm Shell was giving me this error message there I didn't find the GBM renderer, blah blah blah. So far so good. I didn't fear the update because these are fearless updates so I went on ISE and asked some of my graphics team peers what to do and they recommended I should get them the output of a little tool called EGL info so I booted back into the broken image run level three this time tried to run EGL info and all the surprises wasn't installed so I have package layering available so I just ran APMOS to install EGL utils which contains that tool and rebooted to get into this image with EGL utils installed now and well now at the boot prompt I realized my mistake now I was faced with the choice between the broken image and the broken image plus EGL utils which I mean the second one is kind of what I was going for but I had hoped that my working image was still available so it turns out that APMOS 3 keeps exactly two images around at our times and it always assumes that it can never replace the one you're currently booted in because that's supposedly the good one in my situation I was booted into the broken one and still needed to create another one so this was a bit of a bummer I had 50 minutes left of the meeting so what to do I remembered another slogan that Atomic has which is like OS 3 is like get for operating systems so if it's like get there should be a history somewhere I thought a little bit of grabbing around I found a command called OS 3 lock which lists existing commits or images and I kind of abbreviated the output here but the important line is the last one here history beyond this commit not fetched basically what OS 3 was telling me is that I only had like two commits available like the current one and the previous one and the rest of the history is not kept because it's kind of bulky and my disk is not infinite so I had to figure out that I can actually pull more commits from the remote repository using OS 3 pull, giving it a depth so I was going to like go five versions back not infinitely far because you have so much disk space and then I could use another command called OS 3 admin deploy to actually switch to one particular commit that I knew was working and this all was a little stressful but I managed to make it just in time and got into my meeting so that was good but I guess this was the closest I've come to death on Silverblue and that's basically the story I have to tell I hope you're interested in trying this out for yourself now and if you want to, you can actually you don't have to wait for this you can try it out, there's a kind of pre-release that we did with Fedora 28 this spring or not sure when I've had it was released and for Fedora 29 we'll have a first I guess proper release of Silverblue and some of the things I've talked about here today are going to land for Fedora 30 when it's hopefully going to be ready for prime time the ultimate goal of this initiative is that we'll make Silverblue basically ready to take the role of the traditional workstation edition and be useful for everybody but you can try it today Oops, wrong direction Yeah and that's all I had for you today there's a bunch of links you can follow to learn more the docs website has a list of references so the blog post I wrote since February that I have a bunch more stories of life and death on Silverblue thank you for listening and if you have any questions I think I have some time for that Yes, there's a microphone So two questions so the Silverblue like image itself is basically the same set of packages as Fedora workstation has plus a few more, correct? Pretty close, yeah So I'm managing a fleet of REL7 workstations and we frequently have to provide additional packages that aren't applications but add on to the base like you know GNOME desktop environment like say additional GTK themes because users want them or additional fonts because users want them will those be installed as layered RPMs? So that's certainly one option you can just use layering but that kind of goes system by system so if you have a whole fleet that might not be the most practical approach you can also compose your own image if you want I mean the tools are like the RPM Osprey tool is also used on the server side to compose the image that may not be the most well documented aspect of the whole system but it's certainly possible people have done that before if you have a whole system and you want to like put up your own Osprey repository that has a image that is a bit larger has other packages in it that's certainly possible yes for instance there's a few people who created a KDE variant of Silverblue I believe I forgot the name but so it's possible gotcha so I also maintain a fleet of workstations mine for Dora but what does configuration management look like in a world like this? so this is a workstation so most people use it on the laptop so it's kind of individual systems I guess most of the time and if you're looking at Etsy that's not managed by RPM Osprey or rather it's managed in a somewhat smart way Osprey will merge your own edits in slash Etsy with whatever comes in from the updated image like from packages and tries to do a 3-way merge there just for reference we have workstations that are old term I suppose but are actually managed through Ansible and such yeah in theory Etsy is open you can edit Etsy and whatever tools you use to manage that configuration and your systems should work on atomic systems as well I think so I think it was clear at the start but I just want to make sure that the RPM OS tree that approach versus like the Fedora core OS or the core OS merger all that kind of stuff Silverblue is staying with the OS tree stuff is that correct? I can maybe say a little bit more about that but you can also go to Colin Wartler's talk tomorrow to hear like what the plans for the Fedora core OS are but I believe that Fedora core OS is also going to continue using RPM OS tree they kind of try to pick the best technology on both sides and I think for the kind of atomic update system image-based system I think they decided to use RPM OS tree so do you have to reboot for any update or? well as long as you do the things that I showed here yes like if you install like using RPM OS tree upgrade that will require reboot to like get into the new image if you use RPM OS tree installed to like lay a package on top that will also create a new image that you need to boot into there's some experimental things RPM OS tree is full of these charming compromises there's also like an experimental thing where you can like unlock the system and install a package live which basically gets you all the way back to traditional package installs you install into the existing image and things you do take immediate effect but they're usually gone with the next reboot so there's different compromises there it sounded like there were three options for tools that are not in the base image you could use a flat pack you could use a pet container and you could use a layered package install how do you make choices between those? so I'm not the expert on containers but in my life experience since February using the system it seems that package layering brings back a bunch of the problems that you have on the traditional system that like nerves get out of sync and then there's a conflict between the layered package and the base image and like things tend to like fall apart a lot more if you have a lot of packages layered so I found that it's much nicer for me to stay away from package layering and lose either like a container or like a flat pack builder style approach for doing things that's the amount of recommendation I have I guess so you said you had a you're working on something called the toolbox that's a container that enables you to run graphical apps on and other containers so I've tried, you know, three years ago I tried to run graphical apps in Docker and it was annoying because I had to use Tiger, VNC or X2Go or try to figure out some better way to do X alone forwarding I can't find any reason about this toolbox is it a is that the name of it or is that just your nickname or currently that's the nickname I mean it comes from a the CoreOS actually had a thing like that called Truebox I believe or has a thing like that which works very much the same way you basically have this Truebox command which gives you a Fedora and a container and so we kind of stole that name from CoreOS but we haven't really published Debashy has not published what he has yet because he's still like not quite happy with the current state of affairs but I'll push for having getting that out there very soon so you can try it out Thank you My question's about so you at the very end you quickly went past the future of Silverblue how it could become maybe part of workstation in general OS trees initially have to be released as images themselves so how will that work if if OS trees part of a normal workstation release is it going to be released as an image is it going to be a feature within the installer to make it this immutable platform that's updated through OS tree what does that look like so I think we're basically going to like steal whatever atomic host does with Anaconda like this and atomic host has an installer that basically does this already when it gets a OS tree image onto your system initially and I believe it does that by having an OS tree repository on the ISO and installing from there and we're just going to use the same so one thing we haven't worked out in this area is how to pre-install flat packs quite yet because currently the Silverblue image I didn't say that but it still contains a bunch of like graphical apps that are just expected to be there like a terminal and a file manager and like a simple editor or things like that ideally we want all of those to be installed as flat packs so we want to take them out of the OS tree image but we don't want to give you like an empty system when you like install for the first time so we kind of need to figure out how to pre-install flat packs with Anaconda and that's one part that we haven't solved yet and I assume that in the end look similar to what Anaconda currently does for the OS tree image itself Okay, we have time for one more So in many IT organizations you want to mirror the repositories that use for YUM and there's multiple ways of mirroring YUM repositories and I see that OS tree has a way of mirroring repositories but is there a way of mirroring like flat packs? I didn't say that explicitly but flat pack actually uses OS tree itself like underneath for repositories and for local storage flat pack is very similar to APM OS tree in that respect so it's also using OS tree as the repository format whatever's gonna work for APM OS tree will work for flat pack most likely Great I recommend that you go to Colin's talk tomorrow maybe he's going to talk about some ideas he has for making mirroring of OS trees easier and better Who's talk? Colin, Colin Waters Alright, thank you Thanks, my dears Thanks everybody for coming