 Hi everybody. I am Matthew Miller, the Fedora project leader, and this is our monthly video meeting. We've been doing these for a long time. Like, this isn't a coronavirus thing. This is just how we work in Fedora. Normally, most of our business is done on mailing lists and IRC-based text chat meetings and tickets. But we also want to have some high bandwidth conversations. And so once a month, we do these things where we get somebody doing something interesting and important in the project and bring them into chat with the council about what that part of the project is doing, what they'd like to share with the rest of Fedora, and what they could use from the council in support. As I hope you have heard me hear me say before, that's what hearing works. Fedora is a project that's made up of people. When you say Fedora, don't think of an operating system. Think of this group of awesome, friendly people who work together to make an operating system. And as part of our project, we make the Fedora workstation edition, which is our flagship desktop in a lot of ways. But we also have a bunch of other desktop environments that different groups in Fedora put together. And by far the most popular of those is the KDE Plasma Spin. And so Rex is here today to talk to us about that spin and how things are going in it and what's cool about it and where the future is going and all those kind of things. Hi Rex, welcome. Hi friends and Matthew, I guess you're a friend too. Thank you. So I just put together a few bullet points to kind of highlight some of the things that I like about Fedora and what helped make the KDE spin great. And then some challenges and then I figured we could just chat after that. My quick bullet points of things that made Fedora a great place to make a spin for KDE. Years ago I've been involved in the Fedora project since, well, almost the beginning. And then I think it was Fedora 7 was the first one where we made a KDE spin. So that was a long time ago. And that's where I formally joined the KDE project in their, they call it the KDE EV. So anyway, some of the things that made KDE a good fit for Fedora for me. And that helped bring people in is community. The stuff that I enjoyed about Fedora and that brought people around the work that I was doing was that I, well, what's the movie? Drawing the blank. Field of Dreams. If you build it, they will come. If you build something great, people will come. And that's basically what happened. And then it helps that when you see invigorated contributors wanting to help, you jump in and basically mentor them and bring them along. And then they can do the same thing for others as well. The other thing that has worked great than item number two on my bullet point was kind of upstream downstream collaboration. Helps really well in, especially in about the last few years in that we can bring in upstream developers to work in Fedora and vice versa. So it helps get our changes and improvements pushed upstream and it helps to get their work into Fedora downstream really fast. And then working out any conflicts that arises from that on occasion. What was the other point here? Oh, it's kind of a nice thing, but it's been nice that being in Fedora every once in a while, we can get someone from Red Hat that's especially directly involved with REL and KDE there to work with us in Fedora. So we can get some of the things that they want improved, worked into Fedora first. So that's kind of been a nice side benefit. And then I was going to highlight some challenges. Yes, please do. Something in the past couple of years I went through kind of an employment change and that made my involvement in Fedora taper off a little bit. So that meant that my care and feeding of the KDE SIG and the KDE SPIN was kind of an autopilot for I'd say for maybe a year, year and a half. That's gotten better. I've been on my current job for a while now. I'm very happy and getting to the point where I can like start ramping up my Fedora involvement again and start kind of again this care and feeding business goes a long way. Right? If you don't water your garden, you get some weeds, you know. So a couple of things that I wanted to at least highlight to the board that's been, or sorry, council. You're old school, you can be forgiven on that. So that's been kind of a challenge recently. One unfortunate setback to upstream collaboration was that a couple of years ago we had some upstream contributors that got KDE upstream to use Fedora containers a lot for their continuous integration project. And they had a snag a while back and long story short, they don't use Fedora anymore because of a bad interaction there. And for those of you that aren't familiar with it, you can look up FESCO issue 1784. At least be aware of that issue and I'd really love to be able to avoid cases like that again because that was one case where we had made really good inroads upstream with KDE and then that soured their take on using Fedora for anything. Oh yeah, and then there was a recent Fedora develop thread about the Fedora Jam spin switching away from using KDE, which is kind of a challenge. And it's probably best if we take the details of that offline. I don't want to like air dirty laundry and a meeting like this, but it basically there's some negative negativity and a couple individuals that we need to figure out. How to deal with better, I hope. I'm trying not to get distracted by the FESCO ticket here. Fascinating. Yeah, we don't necessarily need to dig into that in the meeting. I just wanted to make sure that at least those of you who weren't aware of that because it happened a couple of years ago that and I don't we don't need to revisit how that happened. I just want to have that in people's minds that if something like that happens again, I'd really like to avoid that kind of resolution again. That's all. Yeah. And I think that's that's the end of my specific bullet points that I had. I suppose a general one, too, is that we've had some. Yeah, the good news is that I said that I'd be able to be involved more and then there's been a recent influx of contributors recently. So that has been exciting for me. Yay. And a lot of them are really gung-ho on trying to improve the Wayland situation for plasma. That's kind of exciting, too. Yeah, that's going to be one of my questions. What's going on with Wayland? But also in general, what's new in KDE and new in Fedora's KDE spin specifically? What can users look forward to in the next year? Excellent question. I don't have a really good answer that. Like I said, kind of the KDE spin has kind of been flying by an autopilot for a really long time. It's been fairly robust and solid and stable, but that means not much has changed either. Like you said, and I said, one of the big changes we're looking at, tentatively targeting 34 is to finally see if we can get the Wayland situation good enough to use it by default. Yeah, Neil's happy about that. I think Neil's actually one of the main people pulling behind that, aren't you? Yeah. We can blame him on my laptop for a while. So now I'm hoping to get the last bit of bugs working with KDE upstream. I've been filing some bug reports and my hope, I thought we'd do it for 33, but like it's still just slightly too buggy. I'm confident that we could probably do it for 34. And so that's something that I'm personally very excited for. Cool. Yeah. So even on autopilot, KDE continues to be very popular within Fedora. I have some preliminary numbers from my DNF counting project where KDE spin is about 5% of Fedora systems out there, which is much higher than any of the other non-workstation desktop spins. And it is my anecdotal impression that that percentage is probably higher amongst some of the active Fedora contributors. I think it's probably more like 10-15%. That's just kind of my feeling in talking to people. It's pretty popular. And one of the things Marie and I have talked about, we kind of talked about a little bit in general, is we're due for a refresh of Get Fedora and the Fedora website setup. And one of the things we'd like to do, we've always wanted that to have the spins page to be a way to showcase these different desktop technologies. And marketing is always hard. And I think we did the right approach with our targeted marketing thing for the additions. I don't regret it, but I would also like to see a way that we could showcase all this work that is happening in the project and that people are doing cool things on so that people who are looking for it can find it. And so that you can show off to people, hey, there's this other desktop option. If that's something you'd be interested in, here it is for you. So we're looking at that as we look at doing web redesign. Hopefully that will... I would like to see the KDE website be a little more than just a cookie cutter template thing that kind of shows it off and gets people excited about it. They're going to be a hub for KDE users. So for the point of that, actually, upstream KDE and I have been talking about maybe having them contribute to making a more fleshed out, markety kind of website for Fedora KDE blending the Fedora branding with upstream KDE branding. Like maybe give like a more standout approach to promoting the KDE spin. I don't know exactly how that'll work out right now. Everyone's fighting with our bad old tools that are not working on people's computers, but that's a whole different fun set of problems. But yeah, this is something that KDE upstream, some of the developers are actually Fedora KDE users and they kind of want this improved as well. So there's some interest on both sides here. Cool. Community care and feeding and things. Rex, I'm really glad to hear you say that you're going to have some more time for this because basically any group that's successful in Fedora has... You've got to have basically tent pole people holding up either the gardening metaphor is good too. If there's not someone there holding up the tent, when people come to it, you just have a bunch of collapsed fabric on the ground and it doesn't look like anything's going on. This happened a while ago to the docs team where there just basically was nobody there and then people show up like, I want to contribute and then nobody's there. So having the core group that meets regularly and does these things really, really helps. Right. So speaking on that, for example, the low hanging fruit for me was I fell off the bandwagon of leading regular meetings. Even if they're short, you still have to have meetings and transparency and more of letting people know what you're working on. That helps too. Yeah, exactly. Without getting into specifics, there is a perception that Fedora in general, not just KDE, but it's sometimes hard to get along with and that we have strong personalities and that... I think there are... It is scary to interact on some of the Fedora mailing lists. I actually see channels because someone who disagrees with you and has been in the project for a long time may yell at you, be difficult. How do we change that perception? How do we make Fedora KDE more friendly to people? That's hard. You basically have to make sure that most people's, either their initial reaction or a majority of their interactions are positive. If the first thing they see is negative, someone's first impressions are really going to turn them off. Yes, we have to make sure that people's first impressions are good. If anything, try to drown out the negativity with positivity and then make things clear of what is good interactions, what is acceptable, what's good, and then highlight what is not acceptable and what's bad that we're not going to stand for stuff like that. Yeah, that sounds good to me and is important basic steps going forward. Hi Rex, I have a question. Plasma 5.19 was just released in early June. When is it planned to land on Fedora? Plasma 5.19 you said? Yes, that it was released on early June. So when you say in Fedora, you mean like a released Fedora versus Rawhide because it's been in Rawhide for a while. Yes, in a stable release. For a real user because I use Rawhide, I know it's in Rawhide. Yeah, that's another thing that I want to get involved with and help push forward. In the past, we were pretty aggressive on pushing minor version updates into at least the latest Fedora release. And that didn't happen yet with 5.19. So my initial goal, if we're talking about Plasma releases and Fedora releases, my first goal is to try to get 5.18 available for Fedora 31. My primary interest in that is because 5.18 is one of the upstream Plasma's long term support releases. So that's always good. That actually raises questions for me. You finish what you're saying then I'll ask. Sure. Tentatively, I mean nothing's set in stone. And then we can consider working on the 5.19 for Fedora 32. So my questions are, what is the, I have no idea actually. I know Kanom releases basically like clockwork twice a year in a way that works out pretty well for the Fedora six month release schedule. What is KDE's release cadence like? Is there a fixed schedule and are there LTS releases picked arbitrarily or is it like every four releases or something like that? So KDE releases are pretty close to how Noam does it. I think they aim for about every six months as well. And that fits for initial releases, of course. And then as far as, oh, thank Luigi. As far as LTS goes, I think they just periodically pick one every and then for every four to six releases that ends up being every two to three years they ended up picking something. So actually, I can kind of answer what the schedule, the cadence is. So the plasma desktop DAC, which includes KDE frameworks and the plasma applications is usually released just a shy over quarterly basically every four months, three to four months. And then they cut new LTS releases, I believe, every two years. Mostly that's lined up with Ubuntu's LTS cycle. If I remember correctly, Pino can try to, it can correct me if I'm wrong. Oh, and Susan, right. So we're, so the LTS releases are lined up with SLEZ, with SLEZ point release service pack rebase releases, as well as Ubuntu LTS releases. So that's essentially every two years. So what, one of the comments there is that there is no single KDE or there's, so the plasma is released on its own cadence and then applications are released, are applications released in bundles or those just basically as they're updated. So there's like rings or tiers of applications. This is a concept very familiar to you, Matt. So the core set of applications as well as the premier extra set of applications tend to be released along with the plasma desktop. Then there's this whole like wide universe of KDE applications that follow their own release cadence. So like things like Krita and DigiCom and whatnot, follow their own cadence. But a lot of the core applications that you tend to see like showcased with the plasma desktop tend to be released along the same time as the core desktop application. The libraries are released at the same time, usually as the desktop, they follow a quarterly cadence. So every three months, which is I think why plasma desktop itself is every four months, because there's that one month integration window. Although I don't know that for certain, don't, don't like super quote me on that, but I believe that that's the reason that it works that way. So the goal is that at least from a fedora perspective, by about month five in the development. We would have all the rings of stable, the latest stable releases for an upcoming fedora release. So. Okay, um, is there a like. How, how big in the flat pack or those kind of technologies is KDE as a project going. That's my couple of things on it at that level. It's a good question. So, so KDE upstream is. I'm going to put aside KD neon because they're a little weird because KD neon is whatever. So in general, the KD project doesn't specifically gear towards what a particular tech that say that they're going towards particular technology. However, they've been generally emphasizing app, app images and flat packs, and they've been working with the known guys a little bit to collaborate on the base runtime that's in the free desktop one and stacking their KDE runtime on top of that. And there's been work in the last I think year or so about making it so that they can do flat pack builds. A lot of this has been kind of blocked on their infrastructure churn that's been going on. They just transitioned to a new CI system powered by Git lab. And so that'll allow them to reuse a lot of the same work that gnome did to be able to do flat pack builds with releases and stuff. They're still working on setting up their own flat pack remote stuff. And I think they're going to be working on integrating pushing to flat hub. And so there's there's a great deal of like work that's been largely slowed down by Katie's weaker infrastructure with regards to in comparison to gnomes. And that's they've shored that up recently and and that's going to I think help them push forward with this a lot more. But if we do fedora kino like this is something that we can also probably start helping with and yes I know I just randomly throughout a word the back when silver blue was being introduced. He's a contributor in the door Katie who's actually no longer part of the kid or Katie project, but he built a derivative of silver blue using Katie technologies and called it fedora kino it. We have that stuff sitting in the repo. We haven't really used it yet. That's probably something that we want to start exploring and maybe start collaborating with the fedora desktop or workstation working group desktop team whatever, but we can start seeing if we can pump out flat packs of Katie applications and provide those through our tooling because I think I think we can we can provide some significant value here by seriously bootstrapping the availability of flat packs for Katie applications. Yeah, so we have right now in fedora technology which uses a modularity group Goldberg machine in a possibly over clever way, but it takes existing RPM packages and makes flat packs from them in a hopefully almost automated fashion once you've got it set up. So that's something we can do and in the future I would love for us to be able to go straight from a source repository fedora source repository to a fedora flat pack without having an RPM intermediary. Let's not talk crazy. That's maybe a little far out but I think that's something we can do we shouldn't just limit ourselves to RPM, but we can still bring the benefits of having a centralized build system fedora build flags fedora tooling to build those things so people you know users have a consistent experience. And we're going to bring something to it. I mean, speaking personally from looking at flat pack stuff like the, the hardest part is that the flat pack upstream flat pack developer experience is awful. Like I maintain a game, you know, for Linux, like I develop it and it's a project of mine. And like I have been horribly put off by the experience of building a flat pack from source. It's not very good. And I don't know who thought that it was a great developer experience. So I'm hoping that one of the things that we can bring to the table is some way to provide a better experience for producing flat packs as an end artifact because the upstream experience is actually frankly fairly bad. Yeah, I know. There's definitely some interest in that in in GNOME and in the Red Hat desktop team, although it is not a thing that Red Hat is funding their team to work on. So that's a labor of love rather than a day job thing. So the other thing about all of this in life cycle is one of the things we've been wanting to do for many years and are slowly working towards is the ability to release end user facing artifacts, basically spins and media that are not tied to the six month general Fedora OS release cycle. So if it would be more convenient or better to release a new Fedora, a KDE Fedora plasma spin every four months, I would like us to get to the point where we could do that. And then the, you know, which base Fedora OS underneath it is kind of an implementation detail. Or conversely, to do it every two years with the LTS releases and say this is a new, you know, and then hold to that. You know, I'd hope modularity would be our showcase technology for doing this and then hold to it bit, but using whatever technology we have available to hold to that same, that same KDE LTS release over whatever number of versions of Fedora happened, you know, the Fedora OS happened to be underneath it and keep the end user experience the same on top of it. Is that interesting to the KDE sig at all. So I think it'd be interesting with the key know I think I was talking about earlier. So one of the complexities of like deviating from the Fedora standard release cycle for the traditional variants is that now we're completely out of sync in terms of content availability. There's a lot less of a problem. If you are using an immutable base platform like either using RPM OS tree, or building some other technology to do a base OS that is stabilized and you can stack on top of it relatively safely. I think it might actually be interesting within the Fedora KD sig banner to build a a an LTS based derivative using sent us maybe I am. I'm kind of like crossing my fingers here because there's a there's a whole bunch of wibbly stuff. And I that's my technical term for this wibbly stuff related to how we can stack in on top of sent us with all of the modular content things because Apple's not ready for dealing with that yet, like to the level that I would hope it to be. And there's some other interesting issues related to like, how do we handle branding. And I these are all kinds of problems that I haven't yet thought through how to solve. But I think that from from the perspective of being able to provide that that LTS stack, I think that would be interesting with with if we can figure out like how how that kind of branding stack stuff would work with a sent us base because I don't want to provide this disjoint experience where where things are out of sync in such a way where like people people's expectations are are essentially broken when it comes to Fedora people expect that a something offering the freshest KD stack also as the freshest foundational stack. And like that is what people test against that's what people build against is what people want to run against. I don't want to break that expectation because I think that would actually make things considerably worse. But this is, but these are all ideas that I've kind of had in regards to like, how do we build upon like this solid foundation that we have with the Fedora infrastructure Fedora tooling and and our our upstream friendly ethos, because I want to be a premier outlet for the KD project. Yeah, and this is one of the this kind of thing is one of the reasons Jim Perrin and I have been talking about putting KDE branches next to Fedora branches and get in that that got held up but it is still it is still a goal of mine because I think it will help enable a lot of things like this if we get to that. So for what it's worth, even so like, I know some people may be familiar with Debian doing, they actually do this sort of thing of they fork all the source trees into their into their get server if their team uses get VCS is are optional with Debian. But like, if they fork it, if they decide to choose that workflow they can choose to fork or choose to just ship only packaging in their get trees, the KDE team typically just does the packaging in the because it makes it much more straightforward to maintain to do rebasing and maintain the separation and like keep updating things. I think from from the perspective of being helpful to KDE and minimizing a patch delta and accidental patch deltas. I don't want to personally go down the road of forking source repos into Fedora for this purpose. This was separate from the source repo thing this was just putting the CentOS. Okay, I was confused. But yeah, yeah, sorry. This this plan is, you know how we've got an F 27 branch also have a CentOS stream branch right next to it there and whatever CentOS module branches there as well, because that makes sense. I want that that I that I'm good with. I mean, if I were to postulate about my dreams here, you know, if I were to go on about what I would dream to happen. CentOS shouldn't have its own Koji. It should be building in the Fedora Koji, and it all those artifacts and resources would be available there, and then we can leverage the same pipeline and integration and such to to consume things because, especially with modularity things are very complicated. If you don't have all the stuff in your in the source Koji that you want to use it from. So, in my dreams of the future. We would build everything in one big Koji and have a lot more builder resources, so that we can do stuff like this without feeling like we're starving everyone else. Yes, that would be my thing. That sounds good to me as well. I just talked about a long time ago, and it was mostly ignored because of political reasons. It could be. I mean, I think these days it's possible, but it would be a lot of work to merge it in. You can still keep. One of the things I talked about in the past was keeping. Have a CentOS front end and a Fedora front end. They share the database. They share the back end. You can put multiple different front ends on a Koji instance. There's nothing that would stop Rex from running a KDE themed Koji front end and then had access to the Fedora back end. Part of the branding thing is not merely politics, but with how Red Hat would like to use the CentOS brand for what they're doing in CentOS stream, for example, where they would like it. CentOS traditionally has been a, outside of CentOS Plus and CentOS Extras, been a we don't do any development. There's no choices to be made. We're trying to make it exactly like the thing we're replicating. And with CentOS stream, it's getting away from that to some degree, but it is still very explicitly Red Hat is making the development decisions for what happens in the CentOS stream and community can provide input. Patch is welcome, but patch acceptance is a Red Hat thing. And obviously that is very different from Fedora and I don't want really a Fedora branded thing to work that way because that's not the expectation. For example, ButterFS, the ultimate decision for ButterFS in CentOS stream is not with the CentOS community that is with Red Hat. And that's just how it is. That's what that is for. And that's not the case as we see with Fedora. We as a community take Red Hat's input, but we make our own decision on these things. And so I want to make sure that stays true to the Fedora brand and I don't want to have Fedora things that are Red Hat only, unless we can label them in a very clear way. And make that not just be a Red Hat privilege, but that whoever wants to and comes to us with the resources to do it can have the space to do things. That's fine. But it still should be community led. That's what Fedora is about. The answer is it's very complicated and someday we will figure it out. Yeah. Anyways, let's go deep dive on packaging and things. Do people have some questions more about the desktop experience and desktop environment? Or application experience, does the chat? How does nobody care about KB? Perfect timing. So I just wanted to say that I'm using i3 myself. I use Arch, BTW. But no, the question is, I'm one of the editors in Fedora magazine and I just did a search for KDE or Plasma and the last article is from 2016. And I was wondering if we, and I would be able, I would love to help with that if there is an interest in writing something for the magazine so we can spread to people that Fedora has KDE and these are the cool things that you can have. And maybe that would attract new users, maybe they will be able to help out. I don't know. Yeah, this is a call to the KDE community in Fedora. Write for Fedora magazine. It's a great way to get publicity. And I guess related to that, for I traditionally, when I went to write, you know, the release announcement for Fedora would go and ask KDE, hey, what's going on? What should I write about? And I, for a couple of years was not getting any answers. So I stopped doing that. I will try and do that again, because that's really helpful to me. I like to always have something to point out when we have a new base OS release about what's, what's going on. Question for Rex. Historically, you know, the KDE SIG was pretty aggressive in pushing the new versions of KDE back into the old stable releases. And I take from, you know, your comments earlier that, you know, we haven't been doing that. Has there been much user concern or feedback or complaints about not pushing that back or, you know, going forward? You're going to just focus on like the most recent stable release and leave the older, you know, like 32 is the most stable, but 31 is still supported. You're going to leave like 31 alone and leave it on the older KDE releases going forward. So, yeah, I always get, folks are asking about that all the time. We kind of had people get spoiled for a long time that they'd always have the latest and greatest stuff. And then when they don't get all the new shinies, then they're like, where's, where's my stuff? So, so basically, as time allows where it makes sense, we do it. One thing that's kind of slowed some progress down is a lot of the, there have been a couple new plasma releases that bump the QT dependencies. And it's turned out that the upgrading the QT stack in Fedora is a huge job now. Well, it's big. And the biggest reason, unfortunately, is that we have way, I would argue we'd have probably have way too many packages in Fedora that are using QT private APIs. That basically means every single time we do a QT update, we have to rebuild like 30 other packages just because of this private API usage. So that's slowed things down. But, and like I said, my time commitment to Fedora had been limited for a while. So some of that had tapered off. So we do have a couple of contributors that have picked up the slack a little bit, especially plasma wise. So that part has been nice. That it didn't all fall on my own shoulders. So yeah, definitely did get feedback about the lack of shininess. And, and historically, we've always been try to limit our aggressive updates to the latest Fedora release. And the one release older has been, we usually try to leave that alone and focus primarily on, you know, critical bug fixes only. But I think that answer your question. I think that's what users generally prefer from my, my, my guess is about patterns about upgrade usage. Like there's a good solid third of the Fedora user community that upgrades with every release. And then another another chunk likes to either hang a release back or skip a release, which is and then I'm interested in finding the differences between those two groups of users. But the people who are hanging back, like they would prefer to not have quite as rapid change. And so when things get pushed back to those older releases, when core stuff gets pushed back to the older releases, it's disruptive. Yeah, I have another question. There isn't. Sorry. There is any interest in in the in do a silver blue flavor with KDE. So I mentioned this earlier, this is so we have, we have tentatively this Fedora Kino, I think that we've kind of often on looked at. I mean, Rex and I have talked about a little bit about maybe making it our showcase for doing the Wayland stuff first are, but I think now with how mature it is we might do them both at the same time, but like definitely Kino might be Wayland only. You may not just have you just may not have an accession there. And we're interested in the idea and I see that another person asked in the chat about the door KDE for IoT and embedded boards. I don't know how it would make sense for IoT, but I assume you mean like single board computers like the Raspberry Pi. So the only reason we don't really do that is honestly because I don't know how we would validate it and make sure it's good. I mean, we don't even really do this for workstation or or anything else and like I'm kind of like personally, I'm kind of uncomfortable about how we release desktops to arm with basically no, no validation that they that they're any good. There is validation that goes on. And we did. We used to produce all the desktops we used to produce KDE, XFT, LXT. Okay. When we, quite a while back when I was doing release engineering and we were adding a bunch of the, you know, setting everything up, we added all the, you know, armed versions of all the, all the desktops spins. And three or four releases ago now. We narrowed that down. And I think at this point, we only release. I think it's just workstation. No, the XFT is the main supported. One, but there's only a couple now and they do get, you know, Paul Wayland does a great job of making sure that they work across. He's got three or four boards that he tests them on and make sure that they work. So I'm just going to check what we had for the door 32. Well, if that's the case, like, if we have a way of testing them and making sure that they're not like that, when we, when we release arm, arm builds of stuff, I don't, I don't think Rex and I would have a problem with an arm port of KDE. No, I just like, okay. I thought that they had removed them. They have not. They're in Fedora 32, at least in the compose is KDE, LXD, LXQT. Sugar on a stick and XSE. Okay, so we have them all. We just have never really tried it. Go ahead and give it a shot. Maybe help us make sure it works better. If it doesn't work very well. There's a workstation as well. The Spence directory is a whole bunch of them and apparently we, I believe we were removing them and apparently we never did. Okay, cool. So we have them and give it a shot because we have let us know. Yeah, I mean, a lot of the difficulty is, you know, those little single board computers are not very well standardized. And the reason they work in Fedora at all is because Peter Robinson is a crazy person in a, in a good way. And basically stays, you know, up all night and works all weekends with little devices making them work. So everybody should thank Peter. Yes, but Peter has the job I don't want to have anymore. But even better would be if there would be some kind of industry standardization around these things. So they would use a normal booting process and hardware that you could just expect to have. Well, so here. So there it exists. Nobody's using it. EVPR is the standard for it. And as far as I know, no boards have adopted it. So there is a standard boot process in U-boot. There is some standards to like how to send with the SPSA that requires hardware to have SPI, etc. But most of the vendors is not supporting it. And the biggest issue today is where do you put U-boot? More and more boards are putting SPI flashes on. And if they provided a U-boot that had the distro instead of support, let's not go too deep on this. Right. Are we championed? Things would just work. But it's, you know, the biggest issue now is just where do you put U-boot? Or how do you, you know, how do you set up different boards to boot? That's enough of that. David, do you have a question? Yeah. And I don't know that it was covered earlier. If it was, I apologize. I've had a lot of pings this morning. But Rex, a couple of months ago, I remember seeing some news about licensing changes again around QT. Also, is it QT or is it QT? I remember meeting someone from South America who insisted it was called QT. And I was like, oh, I've never heard that. But that's just a side question. I was concerned more about the licensing issue because I know that's always been a thorn. And in fact, was kind of a primary reason for known starting up was since KDE predates that. And how is that impacting KDE and Fedora and KDE in general? That's a super awesome question. So I think there is an issue there. And one of it revolves around, well, I'll back up on the naming thing. So I call it both, but yeah, I think I ended up calling it QT mostly. And I think Luigi chimed in on the chat that QT's the way to go. So QT. Officially, the QT company says it's QT. So that's that's pretty much how that's cute. Yeah, it is. So licensing. So licensing is okay. But they're the upstream project is trying to kind of. They're negotiating with KDE because there's a, I think they call it the KDE QT foundation or something like that. That's kind of a curator of keeping QT free. They're still in negotiations. Thanks. Pino, you're awesome. The chat has some good references and links. I don't think the chat will make it to the recording, however. Oh darn. So it's the KDE free QT foundation and that foundation is an arm of KDE EV that that actually jointly owns the total copyright for QT, along with troll tech and its successes, which is currently the QT company. And in the event that there are certain like provisions in the contract that kick in if they, if the QT company screws up long enough. The QT library stack, the whole thing reverts to a three clause BSD license. And basically they don't want that. So they're incentivized to, to make sure that that doesn't happen by following the terms of the thing and changing the terms of how QT is distributed requires both KDE and the QT company to agree. So anytime they want to change something, it technically can't take effect without changing the terms of the agreement. Right. So given all that, they are in negotiations for some, some changes. But at least in the near term, we don't really have any concerns about that. So we're protected and we can be rest assured that things will remain free and open source licensed and all that good, all that good stuff. And we'll see how those negotiations go. But like I said, they're, they're still working kind of behind the scenes. Yeah, I, okay, I guess that makes me less concerned. I do remember when I saw that in the news, sort of the licensing changes and discussions. I was also around being able to download the source from like download dot. Cute. Yeah. And that I didn't even know about that a friend of mine at another company who uses that library for their commercial project. They, he was like, I can't get this without creating an account, but I can't create an account without buying it. So what the, what the hell's going on and I got to me, I was like, wait, how are we getting it now? How do we download the source? So it sounds like that's been sorted out mostly so that projects like Fedora and such can, can get to it. So, so the way it's currently working is that sources for the latest releases are available to download without an account. All binaries are now behind an account wall. Binaries for non free platforms are behind a paywall. So for Linux, this is not a concern. Now, one of the things that the, that the cute company wants to change about the agreement is that even bug fix releases, especially for long term releases of cute, they want to put it even the sources behind the paywall. Right now, they technically can't do that, but they're trying to, they're going as far in the boundary as possible to make it so that they don't release it for people to use long term. The only thing I think might suffer is our ability to do are, you know, maybe having KDE in, in, in, in Apple, that might actually be the only bad outcome. But if cute is in supported by rail, then I don't, I don't see that as an issue either. And most likely what would happen is the commercial company shipping cute in their distributions, red hat, SUSE and, and canonical and others will probably band together to have a stabilized bug fixed tree that all of us would actually that we could rely on and KDE upstream would start using that for long term releases as the base. I'm speculating at this point. I have literally no idea what the hell's going to happen. But like, I am not terribly concerned right now. That said, I'm keeping a close eye on the situation with my perspective as like somebody who interacts with KDE upstream quite frequently. And if the situation changes, there's there's definitely some adjustments we will have to make about our strategy. I think the light most likely thing that worst case scenarios that we have to stop providing KDE for Apple, like just straight up. That's probably the only bad, bad ending that we would have because the door tends to take the latest cute anyway. And so it's usually not a problem from that perspective. Right. Well, we're getting to the hour here. Is anybody have any last questions. And say along the lines of that, even though once we've got the source would we then potentially become a distributor of it since we put it all in the look of site cash. And those old versions are available. People can can access to them via, you know, like if the upstream gate kit is only making most current version. And then and with that potentially put us in some kind of. Maybe it's worth looking at to make sure that, you know, us continuing to have available and distribute old sources doesn't violate some, you know, terms of. You know, code availability. It shouldn't because we're fetching the sources under the terms of the open source licenses. So basically what happened what they're thinking of doing is that they branch acute release for LTS. They make the first release available as a free open source download but then every subsequent bug fix release on that release would just not be available. That that's the that's the way that they want to go. So the door is perspective we would never download anything we can't fetch freely. So I don't personally I'm not concerned about that. I also don't think that they're going to do this because it's inviting a lot of pain for not a lot of gain, but we'll see. The company has made questionable decisions before we'll see whether they wait, they, they do it again. Yeah, Pino says like they want to delay the releases for LTS bug fix releases by 12 months, which is the limit of the agreement in which they can hold back a release if they wanted to for public consumption. I, again, I think this is one of those questionable decisions that will bite them in the rear later, but we'll see. Katie community and the Katie foundations are are are negotiating with the cute company to make sure that we have a situation that's equitable for everybody because because the all of the plasma LTS stuff is stacked on cute LTS. Like that's that's sort of the point. And so if it's not then then there's a whole whole set of knock on effects that have to be dealt with. Thank you everybody. Thank you chat commentators. We appreciate the color as we went by very useful. Thank you, Neil. And of course, thank you Rex. Thank you everyone. Thank you for all this and I'm looking forward to seeing more from the kidney. Ending record.