 Hey, that's your computer, not mine. You could do whatever you want to your computer. It's not mine. It's not my computer. Somebody else's computer. Sure. So hello, all. Yeah, well... So hello everyone. My name's Neil Gampa, and this is David Duncan, and we're here to talk to you about Fedora Cloud KDE. This is a bit about all the stuff we kind of do and things. The most important thing is I do a lot in Fedora. I do a lot in KDE. I do a lot in Santos and other places. David here does a lot in Fedora, and he does stuff for the cloud. And we're here to try to show you what we're trying to do together. I get with Neil a lot, honestly, but that's because he's a great mentor and super helper. I've learned a whole lot in the context of partly some of the things that we're going to talk about today, and then also just generally about Fedora, and it's been a great experience for us to just work together on many things. Exactly. Yeah, so we first want to talk a little bit about desktops in the cloud. The thing about virtual desktop infrastructure is it's been kind of a holy grail of sorts for... Gosh, I don't know, like decades at this point. People have been wanting to eliminate hardware at the edge for as long as it's been possible to have computers connected to each other network, because in the very beginning you didn't have hardware at the edge. You had these thin terminals, dumb clients, whatever you want to call them, and then they would go and speak to some kind of mainframe or supercomputer or whatever. In the current era, now computers do stuff, but the problem with people breaking stuff is also still true, and so they'd like to have a way to do desktop computers without the computer part at the desktop. And part of the reason this came up as something that we thought was super interesting to do is because... You might want to talk closer to the microphone. Oh, yeah, sorry. So one of the things that we thought this was super interesting to do is I was having a conversation, just sort of a casual conversation around use of desktops in graphics intensive workloads, like film and animation. And I was having a conversation with someone, an architect around this, who's responsible for a fairly major Red Hat customer. And it was pretty animated, right? And I got somebody from our media and entertainment group in Amazon to talk to them, and I just listened, right? And I thought, you know, there's a bunch of free stuff out there that we could use to do exactly what's going on in this multi-million dollar solution. And the first opportunity I had to talk about it was to talk about it in the context of the rail workstation. And so rail workstation became one of those things that I was like, we've got to beat down the doors and have this available for anybody who's doing graphics intensive workloads and wants to see how this works. And... And it's a thing now. It is a thing now. Yeah, it's very exciting to me as we have... And obviously crafting something like that was really interesting because we had to craft it in a way that didn't create a cannibalized workload for server. Just generally in the cloud, right? If you run anything anywhere, you just run the cheapest one, right? So we wanted to make sure that people were using this for a specific type of workload, which was single-purpose, right? You want to have one or two users for a rail workstation. You want them to have task-specific workloads that are user-centric. And other than that, you know, the functionality of the bits is kind of the same. And so we wanted to make sure that we had the right kind of business objectives around that. And it led to creating this big screen around what our market model would be and how we would price that. And again, with all of this... Where's the open-source product? Yeah, where's the open-source product to go with it? And how do you create an upstream for that kind of an experience? And Neil and I thought about it and we thought, you know, this is the way we can actually make this happen. Yeah, and then from a community perspective, there were a number of people who had approached me over the years asking about being able to do some of these kinds of things for much more prosaic use cases. You know, thinking about things like, well, in libraries they want to have thin client terminals because the computers need to be cheap because the kids are going to break them. And they'd like to not have to spend thousands of dollars to replace the broken computers. And in schools where they want to do something a little bit more powerful but they don't want to really expose them to the hardware because, you know, in labs and whatever, they're usually using Chromebooks. And Chromebooks are not powerful enough to do certain types of things, but you know, you still want to teach them in real environments. And then we kind of get to environments that are a little bit more interesting and special and that's developing in the cloud for the cloud, right? So in the past 10 years, we've started to see a larger shift towards developer experiences tending away from Windows and macOS surprisingly towards Linux. As of last year, the Stack Overflow Survey shows macOS and Linux basically neck and neck with them trading blows like year over year. And I think this year, Linux actually surpassed macOS in terms of developer preference. And one of the bigger challenges that's around doing a lot of the developer type stuff for cloud applications is that the best developer experience always requires a whole bunch of tools that you run locally in your environment integrated with your IDE and things like that, even the best web IDs. And there's a lot of good ones, like, especially, like, you know, Dev Workspaces and OpenShift and stuff like that and Cloud9 and AWS, right? They provide a lot of capabilities and interesting possibility. But nobody's building, like, in the community space, nobody's really building tools for that. They're building it for your computer because that's the stuff they're interacting with. And we got to bring that kind of experience into the cloud as well, especially if you're maybe in an emergency situation or far away. God forbid you have to work from your phone. Or an intern. Or an intern. Or an intern. Or a contractor. There's a litany of reasons why you'd want to be able to do this and we wanted to be able to do this with Linux because there aren't anybody. There isn't anybody really doing it with Linux. And it seems like a big opportunity, which kind of leads into why are we doing Fedora KDE for the cloud? Well, because Fedora KDE SIG, which is, you know, the SIGI chair, we maintain the KDE stack and we have a great relationship with the upstream KDE community to be able to provide an excellent experience with that stuff. And as part of being able to provide that excellent experience, we provide the fresh KDE software as upstream is releasing it and we collaborate with them to enable features and capabilities that we feel our users for various target audiences would actually benefit from. And that kind of leads to, you know, you want to talk about cloud effect stuff. Yeah, so our excitement today was that we wanted to demo this, but there was a rollback that eliminated the Wayland support. And so we are left without Wayland support and with a requirement for XR Utils, which also doesn't exist in Fedora. And so, but what we did do was to create a series of playbooks and configuration that would provide a lockdown desktop for support, right? So now you can actually create the KDE configuration on top of a Fedora cloud-based image. That Fedora cloud-based image then can be used with a security group. There's a security group that's created and that security group locks you to wherever it is that you started that instance from. So, like, I started one today and created it in my account and I have a single IP address that is associated with the hotel that's, or whatever the hotel network looks like for real, I don't know. But the, and that, you know, prevents you from having something that's just wide open to the rest of the world. That locks us down to a specific client. Now, the client that we use is one that, so it's what I know, right? So, Nice DCV is the client and that's what we were excited about using. Nice DCV happens to be free for use on top of AWS. And the reason we wanted that experience was because it is free, right? And the excitement for us was that that works in the context of the GPU-based instances, which we can support on Fedora. And it also works on just general hardware. So if you have something that's like a smaller workload or you want to do an experiment and, you know, roll something, maybe you want to roll something in KDE, I don't know. Yeah. Like, you could also just, you know, one of those things is like, maybe you're prototyping a new lab environment for some kids in a school that you want to have an instance up to, like, see how that's going to work and make sure everything's good. You could do it in a small GenPop instance, make sure everything's going to be great, then save it. And then, you know, when you're rolling it out for real, you can roll it out in the right kind of configuration that would be needed to support it for the kids. Exactly. And I mean, I know we're all constrained to, like, lots of security requirements. And anybody who's in the security team, in a security team of sorts here, you have my condolences. I know how hard your campaign requirements are and everybody wants you to produce results even when there's not a security bug. Especially when there's not a security. There's not one. So we run into, I run into this a lot in my, you know, in-dollar day job where I have an instance that's running. It's not optimized. Everybody knows it's not optimized. And they know that I'm running it at, you know, whatever, 3% of its actual, you know, optimized use model. And so just very quickly creating a machine image from that and then snapping it, making it possible for me to just start it over again from an S3 snapshot makes it a lot cheaper and decreases the security profile to something that people can live with. Hopefully. Yeah, hopefully. So, those are, if I encrypt the snapshot. Right, right, exactly. So the goal here was to create something that was super simple and we could just get to the next step. So we're doing the install on the nice DCV, but we'll have to rev that once we get the code for the Weyland support. Right. And the idea here is to demonstrate, this was intended to be a prototype to show you can take the Fedora cloud base, you can stack on a desktop, do some minor configuration tweaks and suddenly you have a cloud desktop. Which we... We almost were there. Yeah, and then, well Neil's working on something else though. Right, and so that's part of the future features part of this. So, some of the things I've been having a conversation in the background with KD folks upstream is the idea around headless KD plasma. Now, if you, you may have not seen my talk at Academy so I kind of quickly recap something that I talked about there when I was talking about Fedora KDE, is that for KD6 in Fedora, we are only shipping a Weyland environment. No X11 session, all that stuff's gone. X11 applications will of course work in the plasma Weyland session, but we're not doing X11 for KD plasma 6.0. Upstream KDE will have the ability to be built to support an X11 session, but we're not shipping that in Fedora. On top of that, there's been some efforts upstream in KD to develop a way for Quinn, the compositor, K-Win, to have a headless mode that can then be backed by RDP to use as the ultimate head for running the plasma desktop. So then we can use RDP and have a fully free stack for being able to do a virtual desktop from the cloud to anywhere. And this will give us all kinds of other capabilities but the most important part, because it's fully open and generic, we can have this in any and every cloud, rather than being specific in this case with the prototype with AWS's nice DCV. I mean, you can use it anywhere, but the thing is, it's free on the platform. But more importantly, because it's all open source, you can kind of see how everything works, you can figure it out, you can improve it, you can learn from it, and you can build on top of it. And that's the key aspect that we want to do with the Fedora Cloud KDE. And we're kind of targeting this to be something that we can start really building out when we land Plasma 6 within Fedora and start working on that headless plasma mode. Yeah, and this is like something that kind of dovetails with some of the other things that I think are really amazing, like the Linux system roles, making it possible for you to just find a way to apply this in a way that is kind of generic. Yeah, and so if you're interested in this kind of stuff, in addition to the Fedora Cloud SIG and working group that's working on this, right, the Fedora KDE SIG is actively working with the cloud working group on this front and see our lovely members that are in there and all the avenues in which you can come talk to us. We're on Matrix, we have mailing lists, we have an issue tracker, come in and join in the fun if you're interested in this topic. So any questions? Awesome. And this is why we finish with five minutes to spare. Thank you very much for the presentation. And I'm an avid KDE user in Fedora, but as an avid KDE user, my question really was from the start, why KDE in this case? I love KDE, but it's one of the most resource-heavy desktop environments out there and in the cloud you pay for resources. If it's AWS, that means you pay more, while with this scenario I would be really interesting deploying on a VPS. When you have like four gigabytes of RAM, what KDE can you think of? So my question is how much of this work can be applied to lightweight environment like IWM, like what we used to use ten years ago? And what's the rationale for using a heavyweight environment like KDE in the cloud? So let me pick apart a couple of things here. So the first is the thought that KDE Plasma is the heaviest environment or one of the heaviest. No, it actually isn't anymore, especially when you're running in the Wayland mode. The minimum KDE setup, which is just the desktop, shell, compositor, and you don't have the KDE PIM services, which you don't need in the cloud environment anyway. So if you take all those out, your KDE Plasma desktop runs with 120 megs of RAM. And that is basically comparable to LXQt, XFCE, Mate, with the added advantage of actually being fully actively maintained and having Wayland support and supporting all these kinds of new features, being able to be hardware accelerated optionally through things like cloud-based GPUs and stuff like that. The second aspect of this is most of the stuff that we're trying to do will probably not work on your average X11-based environment because the idea is that we're trying to leverage modern protocols that are network efficient for being able to make it so that it's responsive over the Internet. So like the usage of RDP as an efficient transport and communications mechanism for the desktop has basically not been successfully done in a reasonably performing fashion with anything backed by an X11 server. But with the Wayland server, we're able to cut out a lot of this fat and have a very optimized method of handling this at the compositor level, at the renderer level. And so that's why this is able to be done and you'd be surprised at how much less resources you have when you also don't have to figure out hardware quirks. Yeah. Maybe they're a trade off of network resources which are actually often... Yeah. Yeah, and remember that one of the things that we're taking advantage of is we're taking... Yeah, one of the things that we're taking advantage of is that you're not going to use this all day, right? You're going to use it for task-specific workloads and then you're going to put it away and go do something on another system. So you can start, stop it all day. That means you're paying for the store... Like in this context, you're paying for monthly storage for the volume but then the compute power, which is your actual... your heaviest cost, you're using it opportunistically, right? There is nothing that would stop once we have the final version, which is generic that would stop it from being used in a virtual provider cloud system like say Linode or similar. Those are totally possible to do. The main constraint is making sure that your IO and network performance are high enough in the environment that you're running in that this doesn't choke. Yeah, and I think the thing that... In the context of what we've done here, we have one deployment script for the instance that's created, right? And you can make some modifications in your extra arguments, right? But effectively, there's just a super simple way to do it. We can make many, right? So then the question becomes how do we do that? What's our easiest path forward to doing the provisioning and the provisioning itself is the one thing that we would focus on. Okay, I have a question about the keyboard and I always have a problem with things like key shortcuts, you know, control out F1 or F2 whatever and your session is gone. And how does it do here? So, I mean, I can give you that answer. You want to give it? Yeah, go for it. So there's going to be two parts. One is going to be based on the client and the client itself will allow you to grab the whole keyboard, right? So the client that we're using in this context gives you that whole keyboard. The RDP, the KRDP will also give you access to the whole keyboard. Right, so if you're using the KRDC client, that is the client side of RDP from KD, there's an option in it to make it so that it grabs the whole keyboard and intercepts all actions before passing it on to the host. And so you can use control, special characters, all the fun stuff or, you know, if you are in doing third, fourth, fifth level modifiers, whatever crazy thing you need to do, it'll pass it forward to the remote session. Yeah, you were in my previous talk where I talked about my love of Emacs, but I am a keychord maker. He really is. Okay, and why did you use Ansible instead of Terraform? I know that because Terraform is like, you know the basic, like the most basic tool for changing from one provider to another is quite simple. Well, I think it's super simple, right? But Ansible, you know, just like falls into the family, right? There's also the other part of it, like the only thing Terraform would actually do is make the cloud-based instance. You'd still need to do everything else somewhere else and that would be done in Ansible. So if you're only doing one step in Terraform and all the other steps in Ansible and the one step is trivial, you might as well do the one step in Ansible too. And then on top of that, one of the things that I mentioned was the concept of the Linux system role. So the concept around the Linux system role has been something that's entertained me for a long time. And thinking about how we can have those in the context of Fedora Cloud is something that I think is beneficial, right? I have two questions. I was really looking forward for the demo, so I'm pretty sad. Me too. So, can you later post something on the MasterDent? I would love to watch that because honestly, I will probably not run the playbook. I will have no time for that. I understand. So yeah, I mean, I think, so the answer to that is, I talked to Paolo, I talked to the GM for the product and he was like, hey, we don't see the Wayland support and he was like, oh, I'll have to get you the review code. And so as soon as we can post it out, we'll just make a movie on the GitHub repository on the review. And the second question, so what's the future where I can expect something super easy, like Linux Media Writer or something, which I just click and got it in the cloud or AMEI, which I speak in. So the goal is that once we have the generic version, we actually are going to produce a layered image product or variant or whatever you want to call it. Layered product, layered spin on top of the Fedora cloud-based edition that we can ship and give AMEI launch buttons and give them steps to like, how do you connect to it automatically and all that other fun stuff. So when? Approximately? I would be very hesitant to give dates because I don't actually know what Plasma 6 is going to release. Yeah, my guess is, let's wait until Paolo tells me that the Wayland code is ready for the client. Yes. And then if the KODP is ready, then that's the one we'll choose because we want one that's just functional everywhere. Right, and like, the KDE community has been estimating like we're looking at seeing first Plasma 6 released by the end of the year, early next year. So if everything optimistically works out, I'd like to have a preview build that we start making available in Fedora as a generic image in the summer, maybe, or maybe in the fall, and then kind of go from there. I noticed you didn't specify which summer. Summer of next year, Adam Williamson. We don't make forward-looking statements, I'm sorry. Yeah, quick question. So KODP is an RDP server, right? That's correct. Yeah, KODP is a new library that one of the KDE folks has been making to encapsulate all the functions of creating an RDP server to plug in as part of the backend for Plasma desktop. It's not as lightweight as the... So it's a protocol that we can adhere to. Here's the question. Is an architecture diagram how it plugs into SSSD for authentication, for example? That'd be kind of awesome. Yeah, I think we're going to have to have a conversation with AB about that. There's some other stuff that we have to figure out. Having the ability to render through RDP is only the first step. We have to also figure out authentication, all these other stuff. That's why I'm saying I'm crossing my fingers for being able to do a preview next summer. But I genuinely don't know what it's going to take to get us to a point where this is something that I'd be comfortable with, say, this is a generally useful thing that you can kind of sort of maybe rely on building your own versions of to then roll out for your own thingies, and somebody might want to do something more interesting with it down the road. No, no, yeah, that's right. Wait, but at the moment, so you spawn a VM, it runs key RDP, but how the actual authentication of the user session happens? Well, right now we would be auto-login. Yeah. So we don't have a better way of dealing with this right now. So there is simply no way to protect the VM from unauthorized connections. Okay, so the nice DCV actually contains a client. We can create base logins on the box. And RDP itself also supports handling user password logins, as well as Kerberos logins, but we have to hook all that stuff up. Yeah, yeah. The plumbing for that would be like second generation. Yeah. Yeah. None of this stuff is simple. But I like where you're going. There are other things that are awesome about that, like the SSSE implementation with instance connect models from different public clouds would be really cool. And that would actually be super nice because then we can plug it in through PAM, back into SDDM, and then verify and authenticate the login session automatically through your local credentials. I think I've got like a 700 day old bugzilla with Amy Farley about some of the things that we could do there. Actually, Amy's problem with norms. Yeah, yeah. I don't know who would be doing it now. No, but... That's a way more useful now. Yeah. Yeah. Cool. All right.