 Okay, everyone please take a seat. Next up is Senator talking about containerizing the next desktop. Okay, hi everyone. That's way more people than I expected. Usually I have a friend who says when there's a headline asking a question, like in this case, usually the answer is no. Let's just say you're all interested in clean desktops. Who is just here for asking questions about the CORO as acquisition? Okay, so you're all actually interested in clean desktops. You can still ask questions about the CORO as acquisition later. There's gonna be enough time. Okay, so you want a clean desk to voice containerize it. It's not gonna be just to talk about using Docker and that's it. So we're gonna talk about what actually is the problem. Well, my problem is that, so when I started studying about 14, 15 years ago, there was, we had to have two operating systems because Matlab was only working on Windows with the license we got and then we had some stuff that was only working on Linux. So I was constantly reinstalling stuff or dual boating and I ended up having two computers at the end, which was pretty annoying. And then I got really obsessed with reinstalling stuff because every time I used something, I had application data that I had. It was just really annoying. So I got really obsessed with clean desktops and ended up using Gentoo a lot, which took a week to configure. I had my make, comp, and use flex all figured out but the rest just took ages. So the actual problem in the past is there's packages upon packages. You have tons of dependencies and really little control of how to use them. If you have something like Arch or Gentoo, you can maybe use another version of something but if the normal traditional distros you had, what you had, and that's it. You had to really hack into the OS to have something different. Dev environments were really annoying to set up because at some company you needed this, at the other company you needed that, or if you worked freelance or at your own time, it was, it's all really, yeah, if something breaks, you're basically fiddling around with it until you fix it or reinstall it. That was the past, right? The present right now is people who like to paint, they tweak their systems. Who has seen Jesse Frozel's post on the coroise using it on your desktop? That's actually not so many. Okay, so Jesse Frozel wrote a whole blog post about, and given talks actually about how she uses coroise on her desktop, it's not for normal humans. Even humans who use and love Gentoo, but it's still a pain, right? And people who don't like to paint, they usually run some flavor of Linux and just deal with it. People who don't care just have Windows or macOS, but yeah. The future is containers everywhere. We know it, we have to deal with it. So it's containers. They're distribution agnostic and the dependencies are included. The rest you know, and for a clean desktop, that's all we have to know. So it's basically what we want. I don't like containers at all. Two years ago, I think it was two years ago, was the first job where I was confronted with containers with Docker. I was working as a DBA or DBE actually, and we used a lot of containers. So all I had to do was basically docker run and some other stuff. I didn't really get into it, and I was like, oh, it's just gonna pass. It's really annoying. I don't have to learn it. Turns out I didn't have to because it's just everywhere now. So basically if you want a clean desktop OS, you know you have to use containers because then it's contained. What else do you need from an operating system that you want to be clean, but you wanna be able to set up stuff and if it fails, you don't want to deal with everything. You don't have the time to fix it for a week. So you want rollbacks, which is really important, and you want it to work seamlessly so you don't have to spend the week on fixing things. Ideally, it works on the server and the desktop so you don't have to take care of remembering two things. So I ended up using Gen2 on my server for a very long time, which is not recommended. It breaks often and when it breaks, yeah, you have to spend a lot of time on it. And ideally, it's also an OS that has support. I work for Red Hat, by the way. So ideally, it's an OS that has support so that you can actually tell your boss, hey, let's use this thing that I know how to use. So basically, from an operating system, we want it to be widely accepted, sort of, if you really wanna use it day to day. So let's talk about CoreOS. It's pretty cool. That's why Red Hat bought it. And we also have Atomic OS, which is basically your Red Hat's version of a container-based operating system. It's very different to CoreOS. Who has used Project Atomic like Atomic host? Okay, and who has used CoreOS? That's kind of, sort of, it looks like a 50-50. That's unexpected. So of those of you who use Project Atomic, do you use it on the cloud? One, okay, interesting. Yeah, because it's not widely available on the cloud. So for Atomic host, there are free flavors. There's a Fedora Atomic host, there's a Rail Atomic host, and a CentOS Atomic host. They all are obviously based on their distribution. Atomic host runs on RPM OS tree. So the RPM OS tree uses, who knows RPM OS tree? Sorry, just like, okay. Okay, so RPM OS tree provides atomic updates and rollbacks, which means basically, if your power goes out, you will be able, if your power goes out while you're updating, you're gonna have the old version. If you're updating, it's an atomic update. It's the one thing, the one file tree snapshot. It updates, and you can roll it back. So you'll see if you do the status. In the terminal, you'll see commits from all the updates you did. And you can always revert to another commit, because basically, if something went wrong, you will be able to roll back, which is really important. CoreOS has the same, obviously. Let's talk a little bit about CoreOS and Atomic host as a comparison. So CoreOS uses update engine, and Atomic host uses RPM OS tree as their underlying mechanism. CoreOS is one nice thing which Atomic host doesn't have. I mean, there's obviously other differences. But one really, really striking feature is auto rollback, which Atomic host doesn't have. So when you have, for example, if something breaks, CoreOS will notice it that the machine didn't boot up, and it will auto roll back, and boot up with the rollback version. That's pretty nice. RPM OS tree, for example. On the other hand, Atomic host provides you with an easy way to a workstation, which is what we're actually talking about today, the Atomic workstation. Specifically, Fedora Atomic workstation. I also have a colleague with me, Patrick, whose last name I can't pronounce. Do you want to say it? Okay. Basically, he's the second user for Fedora Atomic workstation ever. How long have you been using it? A few years. So that's pretty good. We have a few Atomic workstation users outside of Red Hat, and quite a few of us use it. So we're basically testing it extensively. If you want to test it, you can talk to me afterwards. Docs for Atomic workstation are coming by mid-February. So, yeah. So CoreOS and Atomic host, there's a lot of differences, but this is not a talk about it. Current admins don't know either that well. And there's a lot of learning and adapting to do, which is going to be more interesting now with the news of the acquisition. So we're going to see what happens with that. A little bit about RPM OS tree. Why not containerize all the things? Why is there a layer, like why can you use RPM still? Package installation is critical for drivers. It's hard to containerize all the things. And basically, RPM OS tree provides you with a way to hack a little bit into the West, which CoreOS doesn't give you CoreOS as one piece. And then you put containers on it, right? They're not really meant for desktop. Whereas with RPM OS tree, you can use RPMs. You can basically pack, we call it package layering. So you can RPM install, RPM OS tree install a package that is packed in an RPM. So about atomic workstation. If you download the ISO and just like install it like you would, for example, Fedora, it looks exactly like Fedora. You won't see the difference. But underlying, it uses RPM OS tree. It works and it provides automatic updates. The issue for actually closing the issue for actually enabling the automatic updates, I think it's not quite done yet. They haven't decided yet if they're gonna enable it. Is it true? Yeah, but it's there. So it's working. So probably in the next few weeks they're gonna enable it. It provides immutability and isolation, which you exactly have with a container-based OS. It's important to not have the file system writable. You can, it's the var slash var is writable. The rest isn't. But you can hack into it. There's a command with which you can still write to the system if you want to. It's basically like a git for workstation, which is, as I said, you have the commits and you can roll back. That's really important for if something goes wrong. And you can, of course, for someone like me who is a little obsessed about it, you can always delete the commits. So if your system works, you delete the rest and it's all gone. Because it's just a snapshot, no extra data. So what's with flatpacks? Who knows flatpacks? Yay. Okay, so flatpacks, they're nice. I love them. They're awesome. But if you really want a clean system, they're not quite the way to go. I mean, flatpacks are great if you just wanna quickly install stuff. But the problem if you want a really clean system is that they still save a bunch of data in your home and in your other folders. You can see it in the FAQ for flatpacks where stuff is saved. You can always delete it when you uninstall a flatpack. But what really bothers me is that I am always worried that something is gonna be installed somewhere else. So I don't quite like that. That means containers it is, even if you don't like them. Personally, I don't like Docker very much because it has this daemon and I like to not have to run an extra, which is also why I don't use Java anymore. I just would like to have the Java VM on. But we have Builder in Project Atomic. And with Builder, you can use Docker files to build OCI compliant containers. But you don't have to use Docker files. You can also build it from scratch. It's great. It's not Docker and it has no daemon requirement. So if you make a container, you can run it and there's no daemon in the background. But it's Linux only. So if you wanna use it on macOS and Windows, you can't do that. But yet, unless you make a pull request, it's always welcome to contribute. So if you wanna have Builder available on the other systems, you're welcome to contribute. I just wanna show you quickly. So basically, if you use Fedora Atomic Workstation, you can install Builder. And then you have all the tools needed. You can install flatpacks. You can install RPMs if you want to. And you can create containers with Builder. That's basically all you need for a clean desktop OS. I'm just gonna quickly show you how Builder would work. So I mean, there's a Getting Started blog post on the Project Atomic website with clear steps. I left out a few like installing it, for example, which is just like an RPM. But there's also a description of how to install it from source. So you will, for example, say I want a new container and I tell Builder to build it from scratch, not from a Docker file. Then it builds it from scratch. It creates a meta data file. Then you mount it, which you see in the second line. And if you echo the scratch mount, you will see where it's actually located. It's in var. This is not really visible. It says Builder run. And then you run the new container before that you have to install Bash Core Utils. So I installed Bash and Core Utils, like it's in the tutorial. And then you can run the container and inside the container you have the Bash. So you can just do all the stuff that you can with Bash and Core Utils. And that's your first container, basically. But, so for example, if you wanna then run something inside the container, you could, for example, as described in the tutorial, you make a script file, which is just this, as it's mentioned in the tutorial. So you make it executable and with Builder copy, you copy it over to the container. Then you tell the container to run when the container, you tell the script to run when the container runs. And that's what happens. So you do Builder run new container and then it just runs the script that you did. So you built your first container in just a few easy steps and no daemon required. And now we're gonna come to the takeaway. So Fedora Atomic Workstation exists. It's pretty cool. And you can keep your desktop very clean with it. It uses RPMOS tree. Atomic host is for server and Atomic Workstation for desktop. You can also be crazy and use Atomic host. I actually tried it, Atomic host as a workstation, but it doesn't even have the wireless modules installed because it's obviously not needed. It's lightweight as much as it gets and on a server you don't need wireless modules. So none of that's installed. So if you don't have an ethernet, for example, you will need to get your wireless modules on a USB stick there and then you can use the rest. So it's a little bit more complicated than just installing Fedora Atomic Workstation. So Fedora Atomic Workstation is a mix and match of RPMs, flat packs, and containers. And that's basically it from me about this talk. If you wanna contribute or if you wanna join the working group for Atomic, we're in the IRC Free Note pound Atomic. Website and Twitter handle are also here and we're really happy about contributions. And I think we can go to the questions now. 10 minutes for questions. Who's first? Oh, there's one all over there. Does it have X or Wayland or Mir? So it contains both. Do you wanna come out? As the second user of Atomic Workstation. Cause I've just been using it for like two months, so. What's the performance difference compared with the bare metal? Pretty much none because the bits you run are pretty much the same as you would have with a normal for a workstation. The main difference is the actual deployment mechanism which doesn't add too much of red and is in a lot of case actually faster. So how do we get started using it? Okay, so the docs that are, for now you can search engine, Fedora Atomic Workstation, but it's really hard to find the ISO. For now, because you have to go through several links, by 15th of February there's gonna be proper documentation on it on the Project Atomic website. And for now you can still download the ISO. It's just a little harder to find if you search for it. But you can come to me later. I actually have a USB stick with it on me. So if someone wants to try it right away, I have it. Put a USB stick. First come, first serve. Okay, there was a question about that thing, right? Okay, you get the mic after. Well, for gaming I still use Windows. I have an extra machine. I want the performance, you know? But yeah, no, I just, I read just when I spin up at that environment and I have that and then it's gone. So basically it's all in one container. Atomic is literally the only thing I've ran for a number of years, but I don't really game all that much myself. So how do you deal with the display manager or like how do you expose the X-Window system or Wayland to the containers and where does the X-Window or Wayland run? Is it running on host or? For applications, for desktop applications, I tend to use Flatpak, which takes care of that part. I've played around with getting Xorg and not Wayland. For, I literally used two graphical applications of like terminal and browser, which are both built into the main atomic workstation. So. And for me, I just have Gimp and Inkscape and like most of that stuff is, you have almost everything I use is in Flatpaks. And even if it's not, there's a good at Defconn last week, there was a really good introduction on how to create Flatpaks. So if you just check out the uploads for Defconn, there's three or four good talks about Flatpaks and how to actually create them and even upload them to Flatpap. So two quick questions, number one, how does the rollback work technically? But the FS or something like that? No, technically, when you update, it deploys a full new deploy a second deployment with links back to the actual repository. So it doesn't take up too much space, but basically you have the entire file system of pre and post upgrade available. And it just switches which one it mounts into your slash. And second question, let's assume there's a security update for a base library. How long does it take to update all the containers and how much work is it? Sorry, say again. So let's say there's a security update for a base library that exists in each and every container. How much work is it to get it fixed everywhere and how long does it take? That is something up to the distribution point of your container. And I don't know about others. I do know that in Fedora containers, we are currently like the average for between landing like a security fix in packages and containers going out is two hours at this point. How long it will then take for you to update is up is depending on your bandwidth. Any other question? Probably not. Thank you.