 We have been using a Chakral Linux for nearly a decade now, and we believe that it can be recorded in the section for desktop users. A few words about Chakra. Chakra is a distribution that is focused on KDE and Qt software, and it's an independent distro. However, it heavily relies on Arch Linux technologies, and the Half-Rolling Impositing model that we implement is one of our unique selling points. My name is Neapolitan Skogadronis, I'm a long-time Chakra team member, I'm involved in community and project management, and I'm also involved in various quiz-of-guide open-data projects. You probably know these two popular release models, one is the fully-rolling model, and that is the non-rolling fixed release model. With the Half-Rolling model, we try to balance the advantages of both of these models and find a frigid app between them, and hopefully find another easier case. The main advantages of the fully-rolling model are, of course, that you get all the related software that is shipped by AXT, and with that, you get the latest functionalities, all the security updates, any practices that are available. And with the rolling models, you can continuously upgrade to your system, your package manager, without having to do much else. The main disadvantage here is, of course, because we have many updates all the time that are continuous, there are possibilities for the regression to show up, and AXT back coming up, and in more severe cases, we could adapt with the broken system. Some examples of these rolling distributions are actually in Oxygen2, and this makes them ideal for a webinar, so I'm looking to get all the links in the application, the links in the software, and some more experienced advanced users. Regarding the fixed release model, the main advantage is, of course, stability, and that comes from the less frequent updates that come to these distributions, and that makes it easier also to maintain. The major disadvantage is that these releases, the fixed releases, usually come in the form of series, so when a new series is out, you have to upgrade from the old series to the new ones, so things get complicated there, and it could end up with stability issues, and the software that draws into the distribution, it's much slower, so you don't get all the links in the application usually. Some popular examples are Debian, Ubuntu, and Fedora, and they tend to be ideal for workstations, servers, and more casual users. Now, with the hard rolling model, we try to distinguish between two different layers of software. The first is the stable color software, where we update this code less often, periodically through the year, and on top of that, we have the fully rolling desktop environment and applications. This might help you understand it a bit better hopefully. You can see the yellow box, we have all the libraries, the applications, and the desktop environment, in the case of Chakra, when we have Palma from PD, which fully rolls, so this could get continuously updated, and all the new versions are available immediately to our users. And on the bottom half, in the orange box, you can see the core components of the system, which are usually libraries of sub-core packages, which are only hard rolling, so they are periodically updated. In our implementation in the core layer, we include software that we consider that is critical for an operational system. So, we update this software more periodically and on scheduling terms throughout the year. We try to categorize our packages in the core layer in groups, so you get the kernel and driver group, the shock server group, the multimedia group, and other important core packages with their dependencies, Karmacy Group. We don't see those package groups the same though. Some package groups are updated more often than others. This is usually due to point-billard demands, so users tend to require the latest package drivers, so we try to upgrade this those more often through the year, whereas we upgrade sort or the multimedia packages maybe less times. The second layer is what we think users tend to interact with, and that is exactly the desktop environment and the applications. In Chakra specifically, that includes frameworks and Plasma by PD, all the applications that are available to users, and any related dependency that has to do with their packages. Now, all our packages that are fully running, they go to stable directory. You don't have to pass them through a testing repository because we don't consider those to be any way critical in our application banks. It's okay. The packages in the core layer, however, have to pass through our testing repository, which is a unified repository. We keep packages there usually for a week, but it might be from several days to weeks, depending on the significance of these packages. And after we get the green light from our testers and our own testing, we then move them to the stable repositories accordingly. So, here we are aiming with the hardware model to balance between stability and getting the latest software. So, in regards to stability, we make the updates available periodically through the year, so the updates are also foreseeable so the users know what's the next package route that's going to be updated and when that is going to land in stable. At the same time, we try to fully roll the applications, so we continuously push all the latest versions. And because we are rolling, that means that you only have to install your system once, and then you just get the updates to your package manager. The disadvantages have to do with your standpoint. If you are comparing to the fully rolling model, then of course you get slower upgrades of the core components. And if you are comparing to the fixed release model, you have higher risk because even though it's slower, these things have to upgrade more often than the fixed release distributions. Some challenges we face. This is the most often. When a new application requires a new library version, we then need to decide what to do about that and we need to check, does that library break Bacchus compatibility? If yes, then you have other issues because you cannot get the application and then break all the other applications that depend on that library. So you would have to find a solution for that. And then there is the issue of it as a library in the core layer, is it part of a larger group of packages? So all those packages will also be affected. Another challenge is security vulnerabilities. You always want those to be out and available to use it as soon as possible. So if you are hard rolling, you need to make a decision whether you are going to keep that package frozen or shipped by a fix. So we need to always check if an update is always required and not what can we do about that. Another challenge is always sticking to your schedule. So we might lack packaging resources which might complicate things and we often have unscheduled upgrades or issues that come up from upstream that we can't predict. And there's always a pressure since we are rolling to keep those packages coming. Now what do we do about that? What we push out is updating applications and libraries together. So you always get the latest regarding your application as a user. When a new library version is out and you can't update because of compatibility issues, then we try to patch it, either the application or the package itself, the library itself. So we can ship it without an update and without leading to redo the whole group of packages that come with that. When that is not possible, what we do is we compile the whole group. So the library and all the other applications of libraries that might be ahead of that. And in more extreme scenarios, we freeze the application and libraries for a certain amount of time until we have a workaround or we can update the application together with other applications. And finally, we might postpone or skip a group of packages and go to the next one until we have a solution. Is it for you? Well, we consider the idea for casual desktop users and that includes also a lot of gamers that are nowadays using Linux. And we also have examples in our community from small offices and businesses and also from school laboratories. That's probably it. Thank you very much for your time and if you have any questions, I would be happy to take it. Maybe too. So if there are one. So the common issue with the incompatibility breaking how often would you say that, Karen? It does happen a lot, yeah. It depends on the app. So if something like GCC comes up and you need to compile like a whole bunch of packages, probably all of the packages in the reports, it's different, just a simple library then it depends on the severity. Sometimes since we upgrade the applications together, we might need to compile like a second application and then an application after updating the library. Is it like a monthly occurring? Yeah, it depends. It varies a lot. But yeah, it happens often. So we have to either patch or do the whole group together. Not as often as you might think, but yeah, it happens. Because many after applications provide their own libraries so they just roll together. Thank you very much.