 Let's go. Welcome everybody to Fedora 39 Release Party and this session here. And we're gonna give you an update on all the Fedora desktops that are using Alpiumistry in Fedora. So we're here for several blue, kinoites, Celsera, and Onyx. And with us today, we have a special guest, his Oshua, that is with us. And that is going to talk about Fedora Onyx. All right, so let's dive in right away with what's new if I click on this, right? That's better. And the stage is yours. Yeah, well, thanks for inviting me on to talk about Onyx. I'm glad that we're having a shared session here because the principle of Fedora Onyx is quite simple in that you take budgie and you add all the awesomeness that is Fedora Atomic Desktops to it and you merge it. And if you love budgie, this is a perfect experience for you. So yeah, it uses the budgie desktop with a nearly stock experience. So basically the only changes are like pinned applications for the default apps. And it's a follow-up to Fedora Budgie Spin, which was introduced in Fedora 38. And of course, similar to other Fedora Atomic Desktops we ship with Toolbox and we have access to flatbacks. So that's basically it. Hopefully we'll be rebranding from Onyx, at least in terms of the public-facing name to Fedora Budgie Atomic. It will get into that in a moment. And then there's sort of a big brain idea and aspirational to eventually have this Atomic desktop variant actually be the flagship Fedora Budgie Spin and actually have the immutable version be rebranded. So this, I don't have a timeframe for this. I think there's obviously some discussions that have to be had in terms of usability for everybody and from end users to developers, the entire spectrum. But I'm quite confident in the resiliency and viability of it. So I would be very excited to have it be the flagship experience. But I will hand it off to Timothy to actually talk about this whole, what is this Fedora Atomic's desktop thing that I just mentioned? What? Yes, exactly. Thank you, Joshua. And so the idea with here is that we're trying to regroup all of those variants that we have in Fedora. And so we're creating a new SIG, a new special interest group, which is called the Fedora Atomic Desktops. And we'll have it focused on all of them. So instead of having us be split into subgroups, silver, blue, canoites, or sournicks, we're trying to regroup everybody under the atomic branding. So you might know the atomic branding from the ways, the project atomic days, a little bit about a few years in the past now. And so here we're trying to like reuse this brand, but just for the Fedora Atomic Desktops. And this is what we're trying to do that here. So now we have a SIG, we have a change proposal for Fedora 40 that is going to be submitted to the Fedora console. So this is right now still in flux. Hopefully it will get approved, but we're not fully there yet. The logo is very like, this is all Fedora Atomic, this is all project atomic logo. It's likely to be something else. So don't get to attach to logo yet. Yeah, hopefully once this is approved and the decision has been made, we'll get somebody from Fedora Design to make a lovely new logo that really reflects the current atomic desktop. Yeah, definitely. And yeah, along all of that centralization, we're trying to have us hang out in, out of the SIG hang out in GitLab, in a GitLab namespace. Right now it's named OSG, but maybe we could rename that to Atomic, that's the possibility. And yeah, we're trying to centralize stuff here so that we share as much as possible between all of those variants. All right, so that's kind of the big news. Now let's see what we have for all of the spins that we have in all of the variants that we've been talking about here. So first let's go with silver blue. With silver blue comes everything that goes with all the changes that come in Fedora Workstation. So we have the latest GNOME release. We have a new viewer for images. So loop, the new loop application replaces iognome. So if you have flat packs on silver blue, obviously you use flat packs. The iognome flat pack won't be replaced automatically yet by the loop one. So you will have to do it manually, remove the iognome one and install the loop one to get it. But it's just in the repo. We also now have flat packs on the poor PC architecture thanks to the very good work of the flat pack SIG. And they are included in the installer if you want to install that directly on this architecture. And that's not all of the changes. A lot of the changes here are very shared or very similar to what Fedora Workstation has been doing, just kind of like the idea of silver blue. And so if you go and see the Fedora Workstation, what's new page on the Fedora magazine, you will get the full picture. Alrighty, then what's new in Kenoite? Well, not so much because in a way, we're still waiting, we're still waiting for the next version of Plasma 6 which is going to be released in February and mid-end of February. I don't remember the exact dates. So we're still on the latest version of Plasma 5 which is 5.27 and checking it out. What's definitely new is that now we have a good set of key applications that are available as flat packs in Fedora. So they are built in Fedora infrastructure from the same RPM sources that you know and love and the same build options. And so you get the same thing but as a flat back from Fedora. Due to the advantage of flat packs, those flat packs are also available immediately for all Fedora release. It's not just for the this one, you get it for all the release. So for this, we have to go and give a big shout out and big thanks to Yakov and the flat back seat that made this happen because it's a lot of work and they're working really hard on this. So with the flat packs now being there, we've decided to remove some application from the base image. So you will longer after them. So we remove the color when you're in K-Colk and you can now get them as flat packs. So either from Fedora or if you prefer from Flat Hub, it's kind of the same. The one trick here is that the migration won't happen directly, so you will kind of have to do it manually and your settings won't be migrated as well, unfortunately. So if you have a lot of settings in those apps, then well, you'll have to either copy them or re-set them. Okay, then let's take a look at SirSera. And SirSera, well, there hasn't been much happening in SirSera for this release, which is fine. Sometimes software doesn't have to change all the time. And so I asked them and say, hey, we did some stuff, but it's in the background. So nobody should notice. So I guess it's cool as well if nobody notices any changes or any problems. So that's it for SirSera. And yeah, and the last one is Oleg's and we'll just talk about it. All right, the last bit of change for Fedora 39 is our industry unified call. So this one as well, you won't notice at all because it should be completely transparent to users. And it's just something for us on the server side. And it's kind of something that helps us prepare for the next thing that are coming up. So what is the society is that we've now started to build all of those images, these versions of Fedora, using a special mode using our industry, we call that unified call. I won't go into all the technical details because it's a bit long to explain. But the main idea is that it's a strict to build mode for those images. And so it helps us catch up issues in RPMs, make sure that the image are better for proof, they don't have issues and things like that. And so it's really useful for us. It's how we build Fedora Chorus, it's how we build a lot of other things. The main bit that is interesting is that this is, right now this is a prerequisite for bootable support which we'll go into right away in the interview slides. And also it's also set towards the OSG container image which is also something we'll go over in the next few slides. All righty, and that's it for the changes for Fedora 39. So now we have some time still. So let's look at what's coming up next. We have ambitions for the future of the atomic desktops. Now we can call them this way. And we're looking at what we're gonna do in the next few years. You might recall that there has been Fedora strategy initiative that is looking at, hey, let's try and make those Fedora atomic desktops be a really good or even potentially the default option in Fedora. And so we're looking at things that will help us make that happen. So one of the things here is bootable support. So the main thing right now is that if you're running on those variants, Fedora variants, well, your bootloader isn't really getting any updates. So you can do that manually, but it's a little bit painful. So we've had it support for, we're working on added support for bootable D. But if you right now, it's available in Fedora, of course, for example, the server version, but it's not in the atomic desktops. So we're working on adding that. It will let you finally, let you update your bootloader in a much more easier fashion. So a prerequisite for that work was Optimus 3.5 call. And we did that for Fedora 39. So now this is out of the way and we can focus on fixing the Anaconda stutter to support that. And hopefully this lands in Fedora 40 and we're good with that. Next is one of the biggest items is what we call OS3 native containers. So we're working on moving the ecosystem from OS3 as OS3 repos, OS3 commits, is to having them be packaged as OCI containers. So OCI containers, you may know them under the name of Docker containers or simply containers. And the idea is that it's going to make managing all of those versions, the systems much, much easier for you users and for developers for administrators. So that's like one of the big benefits. Easier to manage, easier to deploy, easier to mirror as well. Mirroring an OS3 repo right now, it's fairly doable, but it's still something special. Mirroring a container image is something that a lot of people know really to do. How to do. So the Big Plus and Podman, yeah, they're not just Docker, Podman works out well. The Big Plus is that you can do with OS3 native containers, you can do derived images. So when you want to have changes, when you have changes to image, you can use container file, Docker file to do those changes and push new images and use that for your desktop. As it's just a container images, you can also inspect the content just like any other container images, run a scanner on top of it, if you want to scan for vulnerabilities or something like that, or just run it. Why not? It's a container. You can just run it and see things inside of it. Another nice thing is that you can do all of the cool stuff using cosine and seek store to actually sign those images with keys that are stored in a ledger and all those things, which will make it much easier for people to actually set up all of this and finally get rid of new GP gene. And yeah, so here are at the end of bottom, I've written and I've pasted two examples of all of these books. So the first one is like a little bit oriented around the raw course, but it's the same technologies, the same ID, and you can see a lot of examples here. And the second one here below, I've just made it's fresh out of the printing of the printer. And it's a, I have a small example that maybe we can get to if I have enough time at the end to run how to build a custom image. All right, so where are we with this work? Well, the idea is we're trying to lend that for about 40 years as well. We have working progress in Pungi to get those images being built by the compose in Fedora and Fram. Initially, they will be like different images, but like they will be the same content as the OS3 ones, the classic OS3 ones, but they will be built differently in parallel. And so, yeah, so we'll have duplication and hopefully at some point, we'll transition everybody to the container images and leave the OS3 repo as legacy. So I have a link here to the change page where you can take a look at the, there's like a lot of things, this is the change page, it covers a lot of grounds, a lot of different things. Like don't take it all the way in, like we'll try to be updating this page and probably rewrite it to focus on some points. It's kind of generic, but yeah, it's kind of the IT easier. All right, and now here, I wanna give a big shout out to the three projects, well, it's three but one project that are outside kind of like the federal committee, but just like, well, no outside is not the right word, it's more like alongside the federal committee and they are building incredible things. They are using our images. So yeah, they're using Fedora as a base to do all of this stuff and it's awesome. So they're using this very container native from what I've just presented to derive their own images and had tons of changes on top of it, tons of fixes, tons of stuff that sometimes Fedora should do, let's be honest, like some things we should just do, but like for time reasons or whatever we haven't done yet. And there are some things that, well, we can't really do for legal reasons and they can't do. So it's awesome that it can do it and make it easier for users. Yeah, so for example, like if you have a brand spanking new framework and you want an image that you know is gonna work right out of the box, they actually have a framework image that you could go and grab. It's all the same lovely goodness that you know and love from Fedora, just catered towards the framework configurations. Exactly, and it's pretty cool. So they have like three main burners here. The first one is like kind of the umbrella project, universal blue projects where they have a lot of images, a lot of options, which is kind of a generic one. Then they made what they call the project blue film which is a GNOME silver blue based image focused on super developer use case with cool stuff, really interesting opinions, ideas. And finally, there's Pesite, which is kind of like SteamOS but made from Fedora with additions on top and fixes on top, like stuff that's not in SteamOS that they fixed in Pesite, and which is really cool. So do check them out if you want. All right, and I see a question that I'm gonna answer, but we, those images are, so the base images that we build here in Fedora, we build them via Alpeger Street, and what they do is that they make those images via derived images. So they make this via container builds, just like you would do a container build for an application and they do it in GitHub. All right, and the last item, the one last thing is support for Azure Linux. So we don't have support right now for Azure Linux, but we would really like to have that and we kind of need help. So this is kind of like a call for help to make this happen. One of those items is like having Alpeger Street support in Kiwi that is kind of needed because right now Fedora has a remix images that are built using Kiwi. And yeah, hopefully it's not that much work, but yeah, if you're interested in working on that, feel free to reach out to us and we'll try and make that happen. All right, so I just say we got good mental stuff. If you wanna help us to make that happen and help us move us forward, and help us move those variants as the default options for Fedora, then yeah, we need folks to help us here. So you can reach us on several places. We are mostly hanging out in the metric channels. So if you wanna talk about things that are like kind of meta which impacts everybody, you can go into the admin desktops metric channel. Otherwise we have channels for all the desktops. So if you are having a specific issue related to GNOME, then go ahead and jump into the civil view one because there's like eight more people that will be able to help you there. For example, and it's around. And that's it for me. Thanks for listening and I can do a demo. We have five minutes I guess that's nine or we can answer questions as well. Yeah, there's a couple of questions actually. There's one from Joseph and he says, I heard talk about removing Firefox from atomic spins in the future. So that's not stuck as part of the immutable image. Any comments or correction on that idea? Yeah, that's still planned but it needs help from folks to happen because it's a lot of work. And so, yeah, it's in the car in the box but we need help to make it happen. And the next question comes from, again, you might have heard of this guy, Matthew Miller, he says, how does six-door integration work here and why get rid of GPG signing? I mean, GPG is a failure, is a general failure for encrypted communications but we've got the signing and verification infrastructure in place. Yeah, it's a good point. So it's likely that we won't get rid of GPG signing for federal imaging images soon but the main advantage is that cosign six-door make it much easier for you to set up the signing for your custom images and this is kind of the goal here. So maybe we start signing using both in Fedora or we switch to six-door, I don't know. Well, we'll see. We're not like the main difference here is that we're not bound to GPG because we don't have to use the RPM format in all those things. So we can use different tech that is using better things. And Dommer says, sorry if I missed your talking about it but any plans for a system debut support in the future? And this is also in the box waiting for help for us to work on system debut support in OS 3 especially. And so yeah, we would really love to have that support but yeah, again, we need help to make this happen. All right, so we don't have any more questions and we have got like two minutes. So I'll give you a quick look about how does building a derived container image for your desktop looks like. So I've just made that and just test it out. And this is kind of like the idea of what you need. So this looks like, this is like the custom set of packages that I have on my system. So right now I have those packages over late because I need them, especially like Libbird. You cannot really, it's super hard to run Libbird in different ways or in a container having been really successful with that yet. So right now I have Libbird directly installed my system and another bunch of tools. And so you think the container file format, the OS 3 native container format, you can go ahead and write a container file and say, hey, okay, I'm gonna pick up a base image. So here I'm starting from Kinoite. It's just a label for query to see that, hey, don't keep images forever. And then I'm going to install a few packages. So here are list of packages that I wanna install from my system. Let's say I enable the Libbird daemon. I just remove some files that shouldn't be there. This is an opn packaging bug. We'll fix that later. And then finally I commit the stuff. And if I go ahead and on GitHub, use GitHub action and build that using stored up build container tools. So here I'm using builder. And I'm building this image and pushing it to Quay. And I just used that earlier. And here I've got an image here that is being pushed. So it's a little bit, but it's okay. And if I click the federal Kinoite system here that I have, and so I've just installed this first system here. It was on federal 39. And I've used the rebase command there to rebase to this image. I've rebooted. So right now I'm running on this image here. And if I go and look at, for example, do we have Libbird install? Oh yeah, if I could, that's better. And here we go. We've got Libbird install on my system and zero package layered, which is like the main thing. Like this GitHub action will like turn out images every day and with updates from federal packages from the federal repos. And then I can just up here with three updates and I get all the benefits of using image-based system. And at the same time, I don't lose time layering packages. I don't have issues with packages layered when I do the update. It's always working essentially. The updates happen on the GitHub action side. The failures after the GitHub action side, they don't happen on my system. Yeah, I was gonna ask, like why wouldn't you? Cause like I'm sure some people that aren't used to immutable variants would just run, you know, pseudo DNF install in a package. You know, why wouldn't they just do that with RPMOS tree? But you kind of touched on that by the fact that it will cause transactions to take longer as you're layering so much on top of that base image. Yeah, that's the main benefit here is that essentially you're donning the thing prepared, you're donning the loading the things like directly prepared directly installed. And so you don't have to wait for the system to reinstall the packages as overlay every time you update essentially. The updates are so much faster with this method. Just really, really practical, really great. And what's also a nice side effect of this if you are lucky to have multiple systems and you all want them to be shared and have the same configuration is you could just point your fresh system to your OS tree and have everything that you have installed on one system already installed on the other. Exactly. All right. And I guess that's it. We are about our time. Thanks a lot Joshua for joining us today. And thanks everybody for joining.