 I'm Timothée Arvier and I work at Red Hat in the chorus team, mostly on federal chorus, but I do a lot of work also on other RPM voice tree-based system such as Federa 7 Blue, and today we're here to talk about, of course, Federa Kinoite, which is another RPM tree-based system based on Federa as well. Let's get started. This works. We have a fairly packed agenda and we'll see all that very shortly. First, quick basic things. What's Federa Kinoite? Well, Federa Kinoite is Federa, so that's the main important thing to remember. We're attached to the key DEC. We built from 100% Federa RPM packages, so there's basically no changes. It's like, you get Federa packages like they are in the regular distribution. What's the difference? We're calling Federa Kinoite an immutable desktop operating system, so it's not immutable in the sense that you cannot change it, but in that you can control how it gets changed and how things change in it. It's featuring the key DEC Blastmap desktop, and the first release will be, of course, for Federa 35, which is coming up in the couple of months. Well, I pre-wonder that you mentioned why we chose Federa for that because we're here for Federa, so it's not really news here, but there's a lot of great stuff around. We have to date, we're upstream first, we follow all the data to release, and we do also set for key D packaging in Federa, so this makes things great to use Federa as a base for this project. All right, so what makes Federa Kinoite actually different? Well, we based on RBM or Street to manage the system. That's like the basics. You get your system working as a consistent mage and not a collection of packages that may or may not work together. The second one, the good point is that we're using flatbacks to manage applications, so you get most of all of your applications using flatbacks. You can bait them on their own and uninstall them as you go. And finally, we just put them to manage containers of different tools and things you might need on top of the system. So, you might have noticed that we're a really close sibling of Federa Silver Blue, which is also an RBM Street-based desktop with the GNOME desktop environment. All right, so what does it look like? Well, essentially, it just looks like Federa because Federa Kinoite is just Federa. It's just not a brand with a little twist on it, but essentially the look is basically the same instead. We just have Kinoite instead of of being named Federa Linux. So, there's not much difference. We'll see that use discovery to install applications using flatback and you get the classic KD desktop. All right, so the status of this project right now is we're in full development program in progress. We plan for, we've been accepted as change for Federa 35, so we'll be there when Federa 35 gets released. And right now, it's in progress. You can get official development boots that are now available in Rohide. We can fill the links over there to install them. Or if you don't feel like using development boots for Rohide for your day-to-day use cases, you can use an official boot that I'm currently maintaining for Federa. They are based on Federa 34 packages. So, it's an official, but it's still 100% Federa RPMs. Essentially, the main difference is that they're not signed by Federa Infra. It's just signed by my personal GPG key, but that's mostly the only difference. Well, you still have to trust me and put them only from Federa RPMs, but essentially it's what I do. All right, so what's the goal of this? Like, why do we even bother creating a new edition, new variant Federa? We are just not doing that for the sake of doing it. Why are we doing that? So, the main idea here is we want to make sure that the desktop experience is great for users. So, we get this by using RPMs. So, RPMs gives us a really nice update experience for the base system because the whole system is shipped as a single consistent image. So, when you do an update, you either update the whole system or not at all, and you do that offline in a sense. So, you get the new version and you reboot to a new version. The update is atomic. You get rollbacks. You can go back. Finishing happens. And so, this makes like the day-to-day experience of updating your system really great. The second thing that is great with that is using flatbacks makes installing and updating application really easy. So, this decouples the updates of the applications from the system. So, when you get the date for file files or something else, you can get that directly. You don't have to wait for the system date or anything. You can update each application independently. You can even rollback them if you want. And you even have to update them if you want to keep a specific version. And it doesn't matter which version of the system you're running. Each application is independent. And it also opens up a really great opportunity to access a lot of applications. So, you'll see Flathead has a lot of applications available as flatbacks for Linux. And, of course, you'll still have the flatbacks which are provided by Fedora, which is full open source applications. Finally, the latest piece for the greatest of experience for users is the Toolbox, which is a common line tool which basically brings all classic Fedora packages directly to your desktop, just like you would have. So, even if an app is not available as a flatback, you can just like install it in the Toolbox and you get it. And it's just working almost as if it was already installed on the system. All right. So, that's for user. And then you get, all right, we'll use this first. And then you try and do things more. So, usually, you find a better thing or you want to test a new version of the applications or you want to try a new version of GD Plasma, because you think, hey, this feature is kind of cool. So, maybe I want to try it. So, the idea is, yeah, we want to be there for testers, early adopters of technologies, but I want to be like on the very front of the development thing. Before it's happening. And this has made it much easier, thanks to RPA industry, because you're not giving up stability for early version testing, because you can always go back to a non-void version if you know, for example, if you find a bug. So, yeah, it is that you try the version, try the new version. And once you're done, you just go back to the original version. And it's just easier. You don't have to reinstall everything. It's the same thing with flatbacks. Flatbacks, you can install several versions of flatback at once. So, you can have a testing version of the flatback installed as well, at the same time as the stable version, which makes it really easy to test a new version of an application without, like, certifying your stability, your day-to-day work on the stable flatback. Yeah, you can try nightly different flatbacks. You can try nightly versions of the system. And you will have the stable version as fullback. And all of that is installed at the same time of system. And the last piece, which I love is using PRs, building flatbacks from PRs. So, if you get like specific bugs or something, you can use, for example, this key of action which builds an application to the flatback for your application from PR and give that as an option to your user. So, they can go ahead and, like, try if this new version of the flatback, the application actually fixes the bug that they're having. And if it does, then you're confident that, like, merging the code will actually fix the bug. And this is, like, really nice user experience because for testers, they don't have to build the code. They don't have to understand everything. They just, like, install the new version of the app, test it directly. And when they report the feedback, you will have really good confidence that the bug is actually fixed. So, that's great. And finally, we want to make sure that it's also a great experience for developers. So, this is all enabled, again, by RBMistry in flatback because RBMistry enables you control change, well, code control change. So, that's, like, the thing about the immutable desktop. It's not immutable that you cannot change it. You control or you change it. So, essentially, the idea is that you can basically override any package on the system using RBMistry and it will tell you. So, it will tell you what has changed on the system. And you can go back to the previous version, to the stable version of what you had. So, that's, like, the nice thing about it. This is, like, by default, you will just go back to the stable version to the version that worked. But you can always try and change things to see if you want. Yeah, this version is just with, to the back is always to the reverse. So, you are installing some developing packages, things broke, okay, you just need to go back to the version to the stable. For flatbacks, the benefit comes with the way of flatbacks work in the sense that you've got everything included into flatbacks and build environments and frameworks, everything. The libraries, you can have anything you want and you don't really have any restriction or compatibility issues with what's already included on the system. So, essentially, you can use whatever you want, whatever you need for your applications without strong constraints. Oops. Yeah. So, all right, so that's what we want to do. But we're in there with Fedora, right? But for all that work, well, you also need applications to live on the system. And so, let's take a look at where are actually right now, where we can find key applications to install on Fedora. Well, the first thing is right now, the flatbacks in Fedora are still in progress. So, there's a good collection, good selection of key application already, but most of the key apps are available as RPMs that they are not yet available as flatbacks. We're working on that. If you want to get key applications, you can get them from FlatHub. We're a progressive packaging. A lot of them are in FlatHub. And hopefully, at some point before the Fedora certified release will have Fedora official Fedora flatback packages for key apps. They are also in good selection of neon key apps already available as flatbacks from Fedora. And of course, there are a lot of them on FlatHub too. So, the main difference between the apps that you would get from FlatHub and perhaps from Fedora is that maybe they're not necessarily the same version. But the main difference is that if you get them from Fedora, you will have the full guarantee that it's fully included on the open source software. Whereas from FlatHub, you won't really have that guarantee because you can have external proprietary software added in certain cases, or some restricted software, such as media codecs and things like that. So, yeah, if you look at the flatback from FlatHub, we've got a quickly expanding list of key applications. We're working closely with Substreaming every time to make sure that when we fix something, it gets Substreamed, so it gets there for everybody, and that key application works well by default in Flatback. So, it's a work in progress. We're doing that progressively, fixing applications as we go, as we try. There's a lot of easy and small tasks for beginners to get involved if you're interested. So, if you're interested in packaging or helping us with fixing some little small bugs in key applications, adding some features, it's a really great way to get started because packaging, once you've got the basics about FlatHub packaging, it's really easy to get started and re-package key applications, much easier than classic development outside of Flatback. Yeah, so, if you take a look at Hubs and FlatHub, you'll get a ton of them, or the classic ones, some proprietary ones, a lot of popular applications out there. And, if you want to focus on only the KDE application, which are there, you can search for all of the KDE, and you will get only the KDE apps that are already available on FlatHub. So, yeah, the next part of this presentation is about what we're going to do next. So, we're very welcome to ask what we want to go in the future, in the coming months. Well, once we've released it to our certified, what we will be doing on top of that. Well, the idea is that we want to be the best platform to try the next version. So, the next version of what? The next version of the Plasma desktop. So, of course, on Fedora, you will usually push the next, the current release of the Plasma desktop, but it's not always easy to try the next version. So, let's say we, the Plasma, KDE Plasma release the new beta version, unless you're running a low-high, it's not always easy. We can try and make available some other ways to try and run latest data beta Plasma releases on top of stable, the stable base of Fedora, to be able to try a new version of the desktop without compressing all the stability of the system. And at the same time, we also want to make sure that the nightly version of the KDE applications are easily available for you to consume at the same time as you can get the classic version of the flatback. So, yeah, being able to test both the desktop and the new applications at their release as beta before they get really fully released. So, the idea here is that we probably make some different data release streams. So, right now we'll have, when Fedora certified gets released, we'll have the stable version, of course, so the Fedora certified branch and the low-high stream, which is already there for Fedora Kinoite, and which we still a bit there always. But the idea is that maybe at some point we'll have this sort of stream, or another option where you get the Plasma, beta Plasma desktop and the stable Fedora content underneath. Yeah, and the last thing that we really want to try and focus on is trying to do the testing before we do releases. So, this, we're putting in Fedora right now is that usually when the images are composed, they're built and then the testing goes onto it and trying to make sure that the images work. And we might want to try and do that through the testing and then actually make sure before release that everything is fully tested. But this is like a much bigger piece of work and we'll see how this goes. All right, and finally, taking a look here is that we don't have any logos. So, we still don't have a logo for Kinoite. We're still looking for ideas. If you've got any ideas, if you've got any talent in this space, feel free to join us. There's an in progress issue about that and any help that here is appreciated. And yeah, you can join us for the ASU. So, we hang out in the, in the, in the kitty with the kitty SIG. So, everything is connected attached to the kitty SIG. And we have the issue you can report issues into the kitty SIGs. We meet fairly regularly on Mondays at 1800 UTC. And yeah, you can easily try. I have the official booths which are right now Rohaid until Fedora certified gets released or the official booths which are based on the stable version of Fedora right now. And all the links are there. Of course, I'll post the slides, link to the slides, just right for that. Okay, so let's have a little quick demo and some time for questions if you don't have any questions first. So right now I have one question. Thank you for that. Well, Kenoite had the same issues as Silverblue, like missing support for easy way of extending copper packages or missing ABRT reporting. Yes, probably. So we share a lot of the code between Silverblue and Kenoite. So a lot of common issues are, a lot of those issues are and I'm looking into that. The installing copper packages is, yeah, it's a little bit different, but you essentially have to pull out the repo file manually and add that to your system. But apart from that, you can directly install packages. So yeah, it's not great UX, but it's still fairly easy. For ABRT reporting, that's something I'm definitely looking into and try and figure out some points. But yeah, right now we're not great on this front. We have to work on that. All right, second question I have is, do daily drive Kenoite? And yes, I do. So I'll just show that to you. The idea is that right now I'm not daily driving the official release version because it's a little bit too soon. Still, we haven't even branched or satisfied. So it's like reasonably working, but it's not fully there yet. But I'm driving the official version. So I'll just show that to you right now. So let's just see if you can change up if you see my screen correctly, hopefully. I'll just have to switch. Yeah, seems like it's working. Yeah, great. Thank you. All right. So here's like the current version that I'm running, which is still an official boost, but it is still Kenoite in a sense, because it's still Fedora packages. It's Fedora 34 packages. It's an official boost from which are hosted by Fedora. Yeah. And you can see here, so Kenoite version is this boost I made this Monday, this week. And I have some packages of OLA here on top of it. So I use Opium Fusion, Veeam, and etc. Yeah, and I have a bunch of flatbacks too. So yeah, you can see from this lid here, but I don't really have the KDE application over there on top, because essentially all the KDE applications I use, I use them on flatbacks. So if you go and list here all the applications that I've installed with system, you can see this for a bunch of them. So I've got Spotify, Steam and everything. And you also have like a lot of KDE applications there, which are the classic ones, which are all, unfortunately right now, so they all come from FlatHub, because that's where they are packaged, I'll say. Yeah. What should I show next? I'm on the other side. I'll just like give a quick try and see if there's no question. Yeah, there's another question. If someone wanted to create a federal Opium industry spin with a different desktop environment, like MixQ made something, would they build it on QR2? Well, neither. That's a good question. So essentially the idea is that you don't create, so there wasn't supposed to be another session just after this one about specific uses of to create desktop environments based on Opium Street, but we had to rescue them. So this would be for another time. But the base idea is that you don't, you base that on a common sort of packages and that's mostly done. Let's just like link to the config here, which shows you how it's done. So essentially the config is here. And yeah, and you essentially is a common base, which makes an Opium Street desktop based on Fedora. And then you add on top the desktop environment that you want. So essentially silver blue is adding on top of that. Key white is adding all the kitty plasma desktop of that. And if you want to make an XFC variant, which is something I've already done and officially is not an official variant, you can create, you can have this, you take the same base and you add the XFC packages on top of that and you get a full Opium Street based XFC desktop. And yeah, it looks very well. So you can, you used to have the official bits about XFC for that in my in the same links that I'm making here first. Yeah, so thanks Micah, but thanks for the knowledge in the sense, because I don't like to say that we remove gnome and had key, because since that's not really what we're doing, we're not removing gnome form to make it's all right. We're not removing them to make you know, because essentially just using the same base technologies and we share the same packages, it's just that instead of adding gnome to create silver bill, you had to create you know, so yeah, we're not taking away something from silver bill, we're just using the same common set of packages and creating something new. So yeah, it's not that it's it's kind of true, but like I don't like it feels bad. This is not like we're taking anything from from from them or silver bill here. It's just another option. Yeah, we need to base another yeah, I've created a base image for that. And but it's not there's not really an option. Another option is about like rebasing on top of federal chorus, which is all the bigger topic. But we're not there yet and we still have to to try and make that available. So yeah, there's no official XFC. So let's like go through the question that has it on which key comes from flatbacks and holy toe, is it in the history base? So essentially, what we have in the history base comments is like only is the core application that you cannot go and live with that. So we have had all the key deep blocks my desktop shell in a sense, and all widgets. And then you get Firefox, the terminal, Dolphin and discover and Arc, the Archive Manager, because that's like the basics. If you don't have that, it's painful in a sense on desktop. So that's like included in the image by default. Everything else you install their flatback. The main goal with the federal certified release is that I have just enough flatbacks built in federal so that we can pre install them, just like what it's done in Silverville where a lot of the GNOME application are pre installed in the image by default. And that's the goal here. So I mean, you just enough key application so that we can pre install them. So you have to get the calculator, the, I don't know, the music player thing like that available by default on on your desktop. So yeah, that's the sense in since the idea. No silver, blue, I have choices for more to stop them and key. So yeah, this, this is like the and will there be a nice observation silver. This is like where things gets tricky. So silver blue is GNOME. So essentially, the silver blue version of it's an up and sweet based desktop with GNOME. So it's only one thing. There's no XFC silver blue or anything like that, just like Kenoi. There's no GNOME version of Kenoi. It doesn't really make sense in a sense. It's a whole. So you cannot like speed it up. But you can create an XFC based off the industry desktop. It's still possible. It's just, it will just be something different. It's like, yeah, it's, it's really weird. So if you take a look at the config here, just to share the screen again. Yes, you can install classic RPMs on top of or should I, should I share my whole screen? So if you go, if you use RPMs 3, if you go there, so when you say RPMs 3 status, you've got a list of layer packages. What this means is that essentially what I've done is I've called RPMs 3 and I've said install and I've given hit some packages. So here I can, for example, set a stress. And if I go ahead and start a stress, we will just create a new deployment and install a stress on the system. So this won't be available right now, but you can reboot into the new version and you get package install. And there's even new option right now. If I just come to that, you can go ahead and say, okay, let's do that directly. You can go ahead and apply live and you will get a stress installed directly on the system. So it takes a while and but you know, it's going to maybe we can give it a try. If it's going to be the top of the 30 minutes, I'll have to start here. All right. Thank you everyone for coming to the session. Hopefully you get a bit of view of the work that we're doing right here is right now. And yeah, if you got any questions, please feel free to reach out to me either on metrics, the RC channels in the QDC, if you feel you want to take us and anything like that, if you want to contribute, you're welcome, of course. All right. Thanks, everyone.