 Well, yeah. Hello, everybody. Obviously the title was clickbait, but I'm still glad you showed up and There is some truth to it and I'm gonna Well, I'm it's really a case study of of how software Sometimes die sometimes is buried sometimes is reborn sometimes is resurrected or just has a Come back or shows up in In ways that you didn't expect My name is Christian Glomback. I am a senior software engineer in open shift at red hat I am on the okd streams team and we maintain the okd community releases, which is the community version of open shift Yeah, and I actually started my my journey into software engineering with With almost coro s with with one of the predecessors to coro s which was atomic host and I'll I'll get to that now So really the past of course, and I'm not gonna give you a whole history lesson on on coro s because I wasn't there for the Coro s coro s container Linux Coro s time that was The original Coro s was a gen 2 based System It was then renamed to container Linux At least the the community variant and then red hat bought the company coro s and We created a new operating system that took the name of the predecessor But really it was a new operating system and that operating system was based mostly on the atomic project Some folks may still remember the fedora atomic host Releases I think there was also a red hat product in there somewhere and Really we took the best of these both worlds or at least we try to do that I think we did pretty well in taking the best from you to create the new the new current Coro s so really what what do we have today? What what is? What what's happening in coro s land? The main fedora coro s release, which is the upstream Leverages all kinds of Software it's built with rpm os tree. So it's image-based or hybrid image-based you can Rebase from one image, which is a digest in a repository to another one and that that really Yeah, that changed how we deployed the and provisioned the systems and it really made things much easier for us There's obviously things like potman, which is our main container runtime in fedora coro s We're actually still ship Moby which is Docker and Ignition is our first boot provisioning tool and we took that from the original container Linux coro s so that's a declarative way of Configuring your the machine you want a provision up front you have a config file and that essentially gets written to disk it defines Discard yeah file contents file All kinds of things that you want you want written to disk That gets put in ignition config and then on the first boot the ignition binary writes it While it's still in the inner-dram stage and writes it to disk and then reboots into that newly configured pristine Operating system the way you want it Recently we introduced something that really is a big leap in how you can Work with coro s which is coro as a layering And it's been it's been mentioned a couple of times in other talks today But really what it is it enables the operating system like a container Image because the operating system is a container image. So you can You can import it with a from directive in a Docker file and then rpm-os tree install other things other rpm's on top of the base which could be fedora coro s or rail coro s or the newly String coro s and that really makes it easy to Use the base that the community provides the fedora coro s or center stream coro s and Make your own version very specific to your needs and a great a great example of that how a community Starts to appear around things like this is universal blue you blew it You blew that it and they actually it's a it's a community project and they actually Use coro s layering to build derived images from the standard stock fedora coro s I think they put in Nvidia drivers and things like Yeah, the things that we can't ship in the fedora repose and they configure it for different use cases Gaming and workstation. They have a couple of images there What we end up with or what we currently have three main Versions that we officially release and and distribute of coro s which is the upstream fedora coro s and then the downstream Retta press Linux coro s rail coro s our cause and we recently introduced a mid-stream distro Just sent our stream coro s. So that's essentially For for rail coro s it's about six months ahead of what's I get into rail meaning the way this works is RPM we builds images by consuming our RPMs and It creates an image out of these RPMs. So everything in the image is is part of an RPM and So we for these three composes three different composers we use for the center stream one We use the center stream RPM young those to pull RPMs from for fedora coro s. It's the It's the fedora repose and for rel. It's the rail repose but the manifests that define the RPM lists the RPMs Do you want to include are actually the same or mostly the same or cause and our cause center stream or coro s or stream coro s is s cause Retta and the press Linux coro s is our cause They're actually exactly the same manifests It's just a rebuild with a different set of packages different version different versions of the packages with different sources one come comes from the Santos community the other from the fedora community and We're pretty happy with where we are right now. It's especially the layering and all the the new goodies we've recently introduced it really Feels really nice to work with with the stack, but we're not finished and this is kind of where The next death is around the corner, right? Is it gonna be? Who's it got? What's it gonna be? What's gonna go? What's what's gonna come next and that really is the only the only constant is change and What's next what what do we want to do what do you want to do? there's a lot of interesting projects in in the realm that we Kind of have our finger on the pulse or you know our Following or definitely want to include there's things like can we Make these layered images support actually maybe do something like build one common base and then have different layers That share the same common base, but that do different things so you could imagine one derived image for the for the Kubernetes stack one for work stations and one for iot devices for example All share the same would be very easy to reproduce and to also change if you're unhappy and really want to derive Again, you can derive from a derived image. It doesn't really matter Because in the end it's just shipped as a container image and that container image You can use as a container image, but it's a bit special because it also includes a kernel so when you run it as a container image the kernel doesn't do anything, but when you Use our PMOS tree to rebase to that image Then the image is actually written to disk and the system is rebooted into that image Then it's not in a container anymore. We really use the container as a distribution mechanism for the images because container registry are ubiquitous today So what what are these things here UKI unified kernel images? That is something I'm really excited about. I think it'll it'll make Our operating system safer because with that we'll be able to to do attestation from the From the start to the end essentially it'll be much easier than with the current bootloader stack that we have Obviously there are different interests here different teams different Requirements from customers from community users so really Nothing is set in stone yet, and we don't even know how it's going to look when we when we get there So really this is the time to shape this There's other things like boot C which could replace our PMOS tree sometime and Yeah, really a lot and compose FS which will enable FS variety for our use case In PMOS tree or even boot C based image distributions And really what what's the takeaway? What do I want to say with all of this? And especially with the looking into the future right we can't change the past, but we definitely can do our best to to shape the future so really What I want to say is be the change you want to see in a product in a software project and open it Yeah, right Yeah The quote is not by Mahatma Gandhi and That really closes the circle here Back to this conferences motto, which is define future You can define your own future and be part of it and I'd like to invite you to do that and to join any of these projects Here or any other join the community around it and contribute to open source. Thank you very much So well there is oh, yeah the question question is is it still is our PMOS tree within a container still valuable because you don't need the package manager inside a container And that is essentially where things like boot C comes in that doesn't ship and a package manager in our PMOS tree Our PMOS tree is both the server side that builds that composes an image But it's also the client side package manager that installs more images So it's kind of there isn't the clear split in the code base it's just one binary that does both and With boot C the build part would be separate and boot C would know about RPMs It would just know how to out an OS tree native container to disk and boot into it and maybe upgrade to the next one So yes, there is like maybe doesn't make sense going forward Maybe there are use cases where we want the the layering to happen in in a container build because you can do these Layered builds with any with potman build Docker builds on a cluster anywhere. They don't need to be privileged Which is also different to the the base compose needs to be a privilege because we need virtualization enabled in the in the builder and run some stuff in a in a nested virtualistic nested virt way And maybe that that's going to be solved by boot C some some of that at least so definitely there's There's a lot going on it. Maybe in the future. We won't even have a package manager on these immutable systems Yeah, thank you You