LINUX Unplugged - 399: No PRs Please

Episode Date: March 31, 2021

Lutris developer Mathieu Comandon joins us to share his perspective on the uncomfortable issues facing Linux desktop developers. Plus the tech behind Shells.com, community news, feedback, and more. Special Guests: Mathieu Comandon and Zlatan Todorić.

Open your web browser and go to 68k.news. You can thank me later. It's Google News, but in just beautiful text. Easy to read, easy to render, easy to print. Beautiful news in just glorious text. I'm going to be mad if this is more than 68k to download. Hey friends, and welcome into your weekly Linux talk show. My name is Chris.

My name is Wes. Hello, Wes. Don't make Wes angry. He wouldn't like it. No. This episode is brought to you by the all-new A Cloud Guru, the leader in learning for the cloud, Linux, and other modern tech skills. Hundreds of courses, thousands of hands-on labs, get certified, get hired, get learning at acloudguru.com.

Hi there. Welcome into the show. It's 399 and I'm having a bit of a mild panic attack because I can't believe I've committed to anything for this long. It's been great, though. We were just talking on the live stream about some ideas that we have for next week's episode. So I want to say right here off the top, if you'd like to help us celebrate 400, please join us live next week over at jblive.tv at noon Pacific, 3 p.m. Eastern on Tuesday next week, and hang out with us to celebrate 400 episodes of this here little podcast. It's pretty great. But coming up on 399, we have a bit of a problem that has been building

for a long time in the open source community. And so we wanted to use our 399th episode to spotlight the challenge of independent open source software developers, specifically those who are trying to invest in an application for a long period of time, say a decade. Maybe it's an application that's kind of complicated as well. It's not a fun thing to talk about. And I think in a sense, it's meant that we haven't brought this up a lot because we don't have a real positive spin on this. But I think it's led us to give this issue less attention than it deserves. So coming up on the show today, we're going to talk with the developer behind Lutris, which is a phenomenal application for Linux gamers

to manage their GOG library, their Humble library, Steam library, all in one application, and of course, locally installed games, classic retro games. It's one of the best tools for gamers out there, and the developer of it will be joining us to discuss some of those issues a little bit in the show. Hello, hello. Hello, hello. Hello, hello. Hello, everybody. It's good to have you here. As we gather here, it's been a week since we found out that RMS was back on the board at the Free Software Foundation, and a lot

of things have been written and said about this. I haven't seen this wave of both pushback and analysis and clickbait. Like, I haven't seen this kind of thing in a long time. And so I don't think I have a lot more to say today, but I am very happy with our coverage on Linux Action News episode 182. So if you haven't heard that and you want to hear our take and analysis on the situation,

go check out linuxactionnews.com slash 182 for that. I think at a certain point, what I'm worried about is while there's still relevant discussion to be had here, it starts to look like a feeding frenzy. It becomes more of a gang up than analysis. So I want to give a tip of the hat also to the boys over at Late Night Linux, episode 118. I think they did a really good discussion there also to the boys over at Late Night Linux, episode 118. I think they did a really good discussion there. They handled that really well, I thought.

They voiced both sides of the situation. They had a good discussion. And I wanted to compliment them. So go check out Late Night Linux 118 for that as well, if you're looking for a little more analysis. I think we'll leave it at that, really. I don't think I need to say much more. I'm a little disappointed that some of the Linux media just sort of skipped the story because it made them uncomfortable.

Yeah, that's the name of this game. It comes up. And then you saw others who milked it for, like, everything they can. I appreciate it's a hard topic for our community to talk about. I don't think there's much more we can add, Wes, than we have now at this point. We had our initial, like, we just found out about the news last week in this episode. And then in Linux Action News 182, we had an opportunity to kind of reflect on all of the open letters

that had come out of the news coverage and sort of surmised our analysis of the situation. And I'm proud of that work we did there. And I think it stands on its own as a piece of our coverage. Any other thoughts that you have on it? Are you good with that? Do you agree? Yeah, I agree.

I think we should just move right along because also in episode 182 of Linux Action News, we had a good chat with Neil McGovern, the executive director of the GNOME Foundation, discussed the design challenges, GTK4, and of course all the great technical work being done on the shell. And I think that's what we should probably

be more excited about today. Hear, hear. Hear, hear, yeah. There we go All right. Well, then let's talk about something new. Let's talk about, oh, am I going to say this right? Alama Linux. Is that right, Wes? Alama Linux. It's officially stable today. They write, we are happy to announce we are releasing the first Alama Linux OS stable version. And for those of you who don't remember, this is one of the first announced, quote-unquote, replacements for traditional CentOS.

They also announced the formation of a non-profit that's going to take over responsibility for managing the Alma Linux OS project. Also announced some of the board members that are going to steer that effort. So it looks like things are starting to really happen over there. Yeah, I mean, this takes us, what, about four months since we got the news about the traditional release path for CentOS going away and then switching to Stream. And now within that time period,

we have a one-to-one binary compatible, quote-unquote, drop and replacement. I haven't tested that yet. And they say with a very long support timeframe. So if you were wondering how long it would take someone out there to respond to those changes and actually ship something as a version 1.0, four months. There it is. Hats off to them. Yeah, now we just wait and see who uses it and how long it lasts, I guess. I'm not really sure what we qualify as success here, but this is great. It's great to see. And hopefully there's a lot of happy users out there. I think Rocky is getting really close as well. Rocky Linux

is getting nigh, the final release of that one, and we'll have to cover that. I mean, at some point, I'd like to take a look at these. I don't know how you exactly do analysis. CentOS shootout! Yeah, Carl, do you have any insight in how we could compare these various CentOS clones and what benchmarks even go by there. I'm not really clear on how to do this. I mean, if they're doing their mission correctly, you won't really be able to tell a difference. Right. I guess that is the benchmark, isn't it? Is if it feels like it's its own unique distro, they're doing it wrong. Exactly. Because with

their stated goal of bug for bug compatibility, it gets to be even difficult to add any kind of features or fix any other bugs. That's not going to happen in those type of distros. They're made more for building on top of with something equivalent to the CentOS 6, which will be their own challenge to stand up. I'm both happy

and pleased for them to see this. But I wonder if you feel like I do, Carl. I'm also a little like, but we haven't even given Stream a shot yet. I feel kind of like it hasn't gotten its chance to even prove itself. Well, I'm obviously biased there. So I don't know how much I can contribute on that, other than we're definitely working hard on making Stream 8 good, and Stream 9's in the works.

It's coming out pretty soon. I don't know that we've actually set a public-ish date, but definitely very soon you'll see Stream 9, and that'll be what's planned to go into RHEL 9.0. And I'm hoping that, you know, I'm hoping a lot more people give it a shot then because we'll have a lot more modularity. It'll be a lot more mature.

Some of the other drawbacks we've had with 8 are going to be taken care of. Like, we're trying to make the entire build route available. There were some devil packages that were missing in Stream 8 that made a lot of things like Apple harder to do. So we're hoping to enable a lot more contributions and a lot more of the ecosystem with 9. It's the first stream of the new era. Right. This will be the first time where we're actually delivering on the mission. Stream 8 is kind of a retrofit. Like, okay, well, it's going to be upstream. It's just still in progress to get upstream.

We're still technically – Stream 8, we're still rebuilding it. I'm still doing a lot of those rebuilds myself, and they're still happening inside RHEL internally first. It's just they're getting delivered to the public as soon as we rebuild them rather than batching them all up into one big like CentOS 8.4 release. With Stream 9, that's when we're actually going to be moving, finishing that process and having, I don't want to say finished. It'll still be, there'll still be things that can be improved,

but it'll be a lot closer to the final vision of role maintainers doing their builds in Stream 9 first, and then we can compose and deliver those. We're doing weekly right now delivery of the updates. I don't know if we're going to keep that same cadence, but that's probably what people could expect initially. Okay. Neil, I'm curious if you feel like this means that CentOS Stream

has to compete even more aggressively with these other clones out there now. So I think that the CentOS Stream effort that's going on now is going to be an interesting differentiator on itself because when you look at what CentOS stream nine is going to be, and if you do the right kind of digging and a little bit of the poking, you can kind of see that we're probably going to start seeing early builds and releases coming out in about two months. We'll fact check me in two months time and see if we've got that going. But I think what you're going to see is that people who are really into the enterprise space, who have been kind of frustrated with how difficult it is to leverage RHEL or CentOS and be able to

get things going and get things fixed, we'll find that CentOS stream will be a way for them to deal with those problems. Because one of the things that I have been conveyed as part of some of the work I do professionally that involves Red Hat Enterprise Linux is I'm being told I need to, I should just go push them into CentOS Stream, and they'll cherry pick them back if they need to be early, but then they'll be shipped right along with everything else into the next point release. So it gives an avenue in which people who are equipped

to be able to do stuff to make it better for everyone actually have the ability to do it, engaging with Red Hat and engaging with the community and making a better enterprise Linux. I think that's awesome. I mean, I've already been doing the same in OpenSUSE Leap for three years now. And so it's nice to see this

on the Red Hat side of things too. It's gotten to the point now where I can actually visualize the flow of it from Fedora onward. And the fundamental change now is that Stream is going to make RHEL a more openly developed operating system. And I think because of the scale of importance that RHEL has in the industry, that is a bigger win than we can appreciate right now while we are in the midst of the very beginning of the transition. But long term, like when we are in episode 500 territory, we'll look back and be grateful, I think, that RHEL's development is so much more open now. And people have insights what's actually going to land in RHEL and can plan and develop for it. I think it's going to make a huge difference.

But I guess time will tell. We have a PSA for Ubuntu folks out there. Ubuntu 21.04 is testing soon, and they'd love to get your help. Now, they have specific things they're going to focus on. So I recommend you check the link in the show notes if you'd like to help them out. But it's coming up pretty soon, April 1st to April 7th. On April 1st, they'll release Ubuntu 21.04 and they'll halt changes, do some testing, and then hopefully incorporate what everybody finds during testing week. They have information and all that good stuff in a post that Popey made on the Ubuntu

discourse site. So I'll have a link to that in the show notes. If you'd like to help them make the next release a little bit better, because this has the opportunity to kind of be a great desktop environment for folks who are not ready to take the plunge to 40 and want something really, really solid and just the latest and greatest of the GNOME 3 series. So go check that out. We'll have a link in the show notes and you can help them. Go help them, you know, go make it better.

Go make it even better. And then next up in the show, this is an interesting one. So I had an opportunity to sit down with some of the folks behind shells.com about a week ago, just like an off-air conversation that we had, because they are, well, they're introducing something that seems like a pretty solid idea to me. Streaming is all the rage these days. I signed up for a GeForce Now streaming membership, and every now and then I stream video games. And it kind of makes sense that Linux would be in on that game.

So they're new. They're just kind of getting rolling. They're not a sponsor or anything like that. There's no relationship between them and JB. But I'm always curious how companies are using Linux. And then because I used to be an IT guy who built up systems, I always like to know as much as I can about the tech behind the scenes. And so the idea behind Shells.com, if you haven't heard of it,

probably haven't because it's pretty new, it lets you stream a Linux desktop that you have root on via your browser. And they got lots of different distros, some distros they're working directly with who will basically answer their calls. So all of them that will. There's like, I played,

did you get a chance to play with it, Wes? I played with an Ubuntu box, a Fedora box. I messed around with it and thought it was pretty neat. Yeah, I mean, I didn't play with it a ton, but everything I tried, I was pretty impressed. Snappy, worked right up. I mean, it felt like a real Linux box. Yeah, and it's interesting because they're not, like,

running off of any other cloud infrastructure. They, in the modern day, they're actually, they have their own data center, their own servers. It really seems like they have this infrastructure pretty far along. And I was curious why, and I suspect it's because they have ties to the people who found private internet access, and even Mt. Gox. So I chatted with their man behind the scenes who is building all this up on the tech side. So I'm Zlatan Todorovic. If that name sounds familiar to you, that's because you might recall he was the CTO at Purism in a past life.

So we started things off by asking why he left Purism and how he ended up at Shells.com. I think our audience might recall your name. It might sound familiar because it was October 20th, 2019 that Michael Arbel posted an interview with you at Pharonix where you expressed some concerns around Purism. So how do we go, just short version, how do we go from leaving Purism

to working at Shells.com and building their tech infrastructure? Well, it was, again, more select part of the community. So I left Purism because I disagreed with the direction it chose to go forward of. And I ended up in Shells because they basically contacted kd community and

people from kd community contacted me and they needed a systems engineer and from there on i became a systems engineer project manager product manager and probably some few more titles in there. It's startup, so everybody is having like five jobs. Yeah, I know that one. It just seems super ambitious. So the elevator pitch for the audience that's listening, and feel free to jump in, is it's a way to get a full Linux desktop shell

in your web browser or on mobile using the app. And if you're a student or a worker or a developer or creator and you need access to a Linux desktop and one that will persist as well so you can disconnect and reconnect and that environment still exists and you can install software and you get admin access. That's what shells.com is trying to do. But functionally, that means you're spinning up VMs and creating VMs and allocating IPs and all kinds of stuff on the back end. And it's not like a package, as far as I know,

that you can just install and we'll do that for you. So no, we basically use open source tech and leverage that. So we use QEMU and we use PyProtocol to basically show in browsers. And we have our own things going on in the backend to make all that smooth process. And as you say, currently we have a couple of Linux distros. We work with more. We also plan to offer Windows, Android, and who knows what future brings for REST. It seems like you must have done something

to make the Spice experience feel a little quicker. It feels faster than VNC to me. Yeah, I mean, Spice has already integrated its own protocols, and we use the service, a strong service back, so it's a lot of hardware power behind, but we also have fast networks, and we do require a bit that you have on your side as well, faster networks, so it doesn't have that huge latency.

And we have our own data centers, and we try to actually move data quite fast and use Ceph as object storage behind to make sure everything is kept in place. It doesn't break every day and loses user data. Can we talk just for a second before you go too much further? Can we talk about the centralized storage? I'm curious how you've built that here.

So I got a little bit of insight there. It sounds like you're using CIFS to manage some of this. Can you break some of that down for us? Well, there's nothing special. We use, again, basically what CIFS is giving us, and we just deploy it on all our servers, and we make it sure that we have backups, and CIFS is good for basically keeping, you know, data

uncorrupted and moving a lot of data around because, again, serving a desktop is quite a bit of data that needs to be moved around and especially the query plan. How are the data centers connected? Is it like a VPN over the public internet? Have you guys wired the data centers directly together? Because it seems like a ton of data to move around. Yeah, so we wired them. And it's our own data centers with our own servers. And basically try to have everything in one place and to maintain by ourselves. So we don't rent anything from Amazon or DigitalOcean or what's the usual aspect for that.

We really try to keep everything in-house because, again, Shell was founded by founders of PIA and they really care for the privacy and security. So instead of relying on others, we're actually working hard to have everything in-house and make it as private, as secure as possible on our side. It sounds like there's been some lessons, perhaps maybe from running PIA, that were learned, lessons you learned. Just going into this, you're kind of building it the way you would want to build it after building something that's just quick and cheap

and then having to tear it down and rebuild. It sounds like you just went right to the rebuild, this is what you'd want to build if you could stage. Yeah, so we are really trying in our decision to make a decision that's going to be long-term because we have the resources to pull that out. And we are still, of course, learning along our way, but there is no slacking or there's no quick road to anything.

We are trying to make a stable product from day one so we spend a lot of times during the day most actual of our time during the day debugging things making them work together having the transitions go smooth so users don't see anything happen in their shells and which is a really good achievement because we daily send things to the production and we try to avoid as much breakage as we can. But sometimes we break things, but we're quick to fix. What are we using underneath the user experience? What Linux distro and kind of technology

are you using to push things around? The kernel that's powering all shells is a gentle one, so it's pretty upstream. Agnostic, it's very close to upstream, and we use the latest one, but we actually do offer to distros, and we collaborate

with some of them, like OpenSUSE and Fedora, they expressed desire to have their own kernel to actually run the entire experience, and we do offer that as well. But again, in that case, the distros themselves need to provide the kernel,

they need to provide the bootloader, they need to provide the disk resize tools, obviously. Or you have the other way, going with our kernel, and we already have automated the disk size in it. It's pretty nice, though, that the distros are giving you that feedback. It sounds like you guys have talked to a lot of them,

and some of them have said it could be even better if you tweaked a few things. So you've got to build a system that can accommodate hosting servers in your data center running, say, a Fedora kernel and a Gen2 kernel for a different system. It sounds like there must be some glue that helps you manage all of this. We have most of the scripts for the systems. We actually open source them, and we invite digital stores to collaborate

on our GitHub repo, basically giving their own scripts how to build them. But we have a couple of scripts for managing all that data centers, including everything we have then currently internally. So they are not currently open source, but we do plan to open source

them in the future. It's just that we are working at high pace and currently we don't have like a super usable finished product for people, you know, to just build a top on it. But it's going to be there. Like we're going to open source more and more things eventually. I set myself up a couple of, I set up a Fedora workstation shell and I also tried out the Ubuntu 2004 experience. And it's pretty cool. It seems like it really is becoming the era of streaming desktops

and streaming games. And I wonder, since you've been under the hood for a little bit, is there any tweaks? Like if you could wave a magic wand and all of a sudden have development effort in Linux directed at something, is there any new code or tweaks that you would wish for to make this even better for what shells.com was trying to do there's like some latency i guess like issues that we that we see from time to time and that we're probably going to try to improve the spice protocol and upstream those things and of course there's the input uh we need to make it sure that once you plug your usb that it's going to be right inside the shells and some people expressed you know they want to do that and have printing capabilities because that's like an enterprise solution.

So we need to tweak and work on those, like, I would say minor, maybe not medium hard things. But there's nothing too much special now that I would really change about it. Just refinements and improving things to make it work even better. It seems like, especially with Spice. Yeah, we are doing, Spice is going to have some changes, but mostly it's basically default tweaking, the same with QEMU. And for example, now we don't have GPUs in our data centers, but we do plan in the future to have that, and that's going to

bring us another option, the VRGL option to basically pass through directly to GPU, which is going to increase the performance a lot. It can be literally hundreds and even thousands of times the performance can rise, because most of the desktop nowadays, they have

the graphical acceleration, compositing, and same goes for the browsers. YouTube needs hardware acceleration to properly push that through. And so some things are hardware-specific and some are software-specific that we're going to tune through the time. But on the bright side, Linux distributions work really well through Spice and through QEMNU and entire work done by

community on that side is absolutely stunning and incredible and we're just building on top of it it's again the power of the open source is coming to its own height linode.com slash unplugged go there to get a $100 60-day credit and support the show.

I just love it. You know, here we are, an independent podcast, almost to 400 episodes. And one of the things that makes it possible is the audience trusting that we work with great sponsors and trying them. And Linode, it can solve some problems. If you're prototyping, if you're learning, or if you just want to host something for yourself or for the public. Linode has different machines at different price points that you're going to be impressed by. They're 30% to 50% less than AWS or Azure. And personally, one of the things I love about Linode is they have all the distros.

And the reason why I love that is it's a great opportunity to learn and test or just host on the distro that you prefer, I suppose. I mean, that seems like the obvious one. I even found a how-to online on how to, using Linux actually, load Windows. People want Windows on Linodes, too. I mean, that's because the Linode hardware is really good. You can go get Windows VPSs somewhere, right? But Linode does more than just the average bear. They have fast disks and network and a great interface

and 11 data centers to choose from. They've really dialed this thing in because they've been around since 2003. And now they're dedicated to the best virtualized cloud computing. They're independently owned and founded on a love for Linux and open source technologies. They support This Here Show and others in the Linux media space. And of course, projects that we love Thank you. support the show, and see what I've been talking about. Try them out. Linode.com slash unplugged.

Well, Mr. Payne, why don't we talk about something that is a bit ox, you know what I mean? It's time to broach this subject, I think. I think what gets me about it is it's easy to feel guilty, like we're part of the problem. So what we're going to try to talk about today, through the lens of the Lutris project, is an overwhelming problem that seems to be facing independent open-source developers who have to balance life and time and community and bug fixes.

Matthew's dedicated the last 10 years to building Lutris. He's adjusted his work schedule to go part-time so he has time for the project and also time for himself. I mean, also, just trying to take care of yourself is a hard thing to balance. It's not really even a hobby anymore at that point. I mean, gosh. Yeah.

And we've talked to developers off-air, but not a lot of developers have wanted to say what he's going to say on-air. We do see this discussion not a lot of developers have wanted to say what he's going to say on air. We do see this discussion happening a lot, and I know it's uncomfortable for us end users. So we just kind of have to listen, and maybe we can come up as a community, just maybe some ideas or solutions to address some of these concerns that he'll raise. It seems like there is some kind of change that is in the winds. And our chat with Matthew gives us insights into

some of the longer term challenges, specifically around these complex applications. Well, Matthew, thank you for joining me on the show today. You did a blog post on the 20th of March titled Not on the Same Page. And it's sort of a reflection of your 15 year journey in Linux. and it's sort of a reflection of your 15-year journey in Linux. You are the founder of Lutris, which is one of my absolute favorite desktop Linux apps. Do you have an elevator pitch to the audience who might not be familiar with who or what Lutris is? Well, I call it a video game preservation platform now.

I used to call it an open platform for Linux and recently I've decided to change the main focus of the project and to make it clear that it's a project that is here to preserve video games, to make them run locally on your machine. So the goal is really to make run any type of video games, regardless of their platform. It can be old consoles, old computers, or like really modern games as well. And one place to just manage all of that

and try to make it as approachable as possible, which is obvious why I love the project. You must have known trying to build something like this, especially targeting the Linux desktop before you even started, was going to be an uphill battle. I knew that in some ways because the way I wanted to approach Lutris

was not the traditional way of running things. But also, I had some ideas. I wanted to gather some, let's say, some development team or just a team to work with. And I thought that I would start an open source project and some people would jump into the project and I was just getting started at the time and I wasn't the best programmer or anything.

You thought if you built it, though, they would come. Yeah, I thought that I just have to start something and someone will say, oh, this looks great, so I'll come and help you. Well, the users arrived. Yeah, the users, yes, but not really. And also some people who helped with the code, really. I don't want to say that I haven't had any contributors,

because that wouldn't be true. But some team members who worked on the project would be on the same page, like I said. But as the project goes on, it sounds like the disconnect that you felt between what you have in mind, what the goals are for the project, and what Linux users are asking for. And it sounds like kind of a core tenet of Linux users is this desire to tweak their system and make it their own, customize it the way they like it. It's something the community, I think you say, and I agree with, takes pride in doing. But that is ultimately kind of creating an always moving target for you, I think you say, and I agree with, takes pride in doing. But that is ultimately kind of creating an always

moving target for you, I would imagine. That's something that's on top of the open source aspect of the project. That's just working on Linux, and that would also happen if the program was proprietary, like Steam. Steam faces the same issues. When they want to run games on Linux, they have to run games on Linux, they have to work on this platform, which is so broad and what you can do with it, that you have to target something to ship on.

And that thing is like moving all the time, like you said. You could describe it as a volatile environment to develop for. You write on here, if your goal is to have a system that is about choice, then you've made the choice to not give me or other developers a stable foundation to build upon. I might not 100% agree with that, but I have absolutely heard that sentiment 100 times over from other developers I've talked to.

Yeah, I don't want to say that Linux is not stable because I have software that is closed source and that will run on Linux pretty easily. That is closed source, and that will run on Linux pretty easily. So compatibility is good if you are doing the right thing, if you're choosing the right libraries and you're compiling just rights, then your program might keep working in the long run. And Lutris interacts a lot with a lot of the other components of the system. It's just like a video game is just its own program,

just shows up a 3D window and it's done. But Lutris is all interacting with all these other components on the system. So it has to play friendly. It has to have a good idea on what's going on. And that's not always easy to achieve, to have this situation where you have control of what you're running.

And it's not like you're trying to support some open-source command-line application inside Lutris. You're trying to support a complex game that's using God knows what 3D and audio libraries from God knows when. I mean, actually, the development I'm doing right now in Lutris

is to support command line applications. Oh, really? That's hilarious. Good for you. That might be nice for a while. It's also in order to build a feature that will be used for Steam and other things. So it's not only for command line, but it's something that's a starting

point for some other things. But yeah, it has to be in this ecosystem that works great locally on my setup, and then someone tries it, and they have those weirdest issues. If I knew how to reproduce issues, it usually doesn't take long to solve. What weird thing did they do that I would have to replicate to reproduce the problem? I mean, what it sounds like you're describing is why containers have become so popular in the server space, because it sort of smooths this problem out. There are some efforts regarding containers, including one that I've made that's using the Docker, and I've made it so it would run like

old Loki games like Soldier of Fortune or SimCity. But the problem is that it doesn't play nice with what's installed locally, like the graphics drivers or the sound card or all those things. So there's something I have an idea for that. I'm not sure it's technically feasible because it's really just an idea at this point. It's on paper.

It's no code, no prototype, nothing. But something that would more or less do like what Wine is doing, but for Linux and that would say, okay, you want to run this game, but you run this game

in this section of this window because this is also some of the problems with Wayland rights because Wayland gets rid of all the screen coordinates. So you run a game and the game doesn't know where to put itself. And same with sound cards.

Sometimes you have a sound coming out of a TV and you would like it from your headphones and it gets mixed up and everything. And you have games with ALSA and a game with Pulse Video. It gets messy. So if you had some way of sending the game where you want it to, and that can be a portion of the screen

that could be a full screen, that could be two screens, a big window that spans two screens, or three, I don't know, any number of screens. If you give it the game only the sound card you want to use, or if you want to give it the game, only the sound card you want to use or if you want to give it only the

joysticks you want it to use, then that would solve a lot of problems. And that's something I would like to give it a go. That's not something I can do technically because I'm not good enough. It's a fantastic idea. And it kind of is, kind of going back to a point you were making earlier, is it kind of comes

down to developer resources. The theme we see here is that Lutris has gotten really popular. It is, I think, a critical part of a Linux gamer's set of tools. And it has a very loyal user base, but it hasn't really scaled up development-wise. And in part, that means that you are inundated with tons of issues, you and many other developers. And I wonder if this isn't a tooling problem, Matthew, because I talk to other developers who have just turned off notifications of new issues and requests because they just simply don't have the email bandwidth to manage it.

And they're just going to be working on what they have time to work on anyways. And it kind of makes the whole bug submission process moot and it leaves end users expecting that something's going to get fixed and it creates this weird tension between developer and user. And I'm curious if you have thoughts on how we could fix this problem because from your blog, I grok that this is an issue for you and everybody else I talk to in this space. Is it a tooling problem? Is it a people problem? It's a problem with expectations, I think.

This is very common. Not only with issues, issues is something that's raised quite a lot, but also pull request is also very time-consuming and it can be worse in some ways than issues because issues, you just respond and you get on with it. And if you don't have the time to work on it, then I mean, that's too bad, but you can go on. With pull request, I mean, either it's something

you're not, you don't want, and then you have to say, well, no, that's not something we want for the project or something you want, but it's not, it doesn't fit well, or I mean, it doesn't fit well, or it doesn't fit the code standards, or all the stuff that's around the project. Or it uses some code variation that will break the project on various platforms. Right, so you can't just go with it.

And if you were going to import it, it would take hours of refactoring. Yeah, and I was doing that at some points earlier, like a few years ago, where I would just welcome everything and say, yeah, you helped the project, that's great. And it would just hit merge. And then weeks would pass, and sometimes a bug would sneak in and would not see it.

And then I would ship the program with some broken stuff because I didn't test the PR enough or I didn't review it enough. And some PR contained some really broken stuff. And that has happened a few times. And it happens enough that you have to always be vigilant for it. I talked to a developer last week who said, even though he has an open source project,

he just sort of has an unofficial policy that he's not going to accept any future merge requests. He'll look at the code, and then if he likes it, he'll rewrite it himself and do it that way. Yeah, I've done that a lot. Either just saying, no, I don't want this proof of request, but then writing my own version of it, or merging it and then rewriting on top of it.

Yeah, that's something that's frequent. And I think that's mostly, because this doesn't happen in companies. When you work in a company, on a project, this doesn't happen. This is an open source problem. And I think in a way, GitHub and its UI have kind of encouraged this issue.

They've made it worse. Yeah, but this is open source, but also open source on a one-man team project because you have like Mozilla, you have like big projects that have like a real team on it. Staff.

Yeah, and you don't have those problems. You have like a real workflow that you would see in an enterprise. And because like everyone is on the same team, they share the same coding standards. They have like the same goals and key results we have to hit. Yeah.

And this is something. So I went back and, and ran some of the, the things that were in the cathedral and the bazaar. Yeah. And some of it's rebusial mostly like not, not the article itself of the cat B, but more of the articles that followed it.

Interesting. Good idea. And one of them is in the Wikipedia page for Cat B. And it was written more than 20 years ago. It was written in 1999, just after Cat B was released. And it raises a lot of important issues that are really valid today. And, you know, about this like tribalism or cult of personality and all this stuff,

and also not having the bandwidth to work on issues and the fact that open source can slow down a developer instead of speed up and all those things. And I was like, oh, wow, this is really old, but also really accurate in how things work even today. And yeah, I shouldn't have had some expectations that open source would bring some help into the development and help me really speed up the development.

But it's really clear now that you work on something on your own. It's kind of a clothesline, but it doesn't have to be. At some point, it exists just on your computer because you're the only one who's aware of it. If you release something and you make it open, then that's not

going to speed up anything. That's just going to make it visible to people so people will be able to... Yeah, it speeds up adoption, essentially. It gets it included in distribution repositories. Yeah, and if it's good and if it's stable enough to be used, then adoption will grow. But it doesn't necessarily guarantee a development team will form or that the tooling around the support process will be comprehensive. It's like a land of promise, but then you get there and it turns out there's a lot of negatives and positives.

And I'm wondering what your thoughts are on that. It doesn't put you in a place where you can build and design great things. So you can support your software, you can debug it. And it's true because I've found that it was the case that it's good to have this open source environment when I'm in QA stage, when I've done a bunch of work and I've say, okay, I've done this, please test it.

And sometimes, I mean, there's not even enough testing because I release those betas or release candidates and I say, okay, test it. And there is some testing. There are a lot of bug reports and it goes well. It's fast and there's a lot of feedback in that. And that sort of situation, open source were really great. And then we have this situation where we are now where we're just after

release and I want to have a lot of new stuff. That's like either like rewriting some previous code or just like brand new code. That's never been done before. That's that's creates like value added for the project. That's right. The kind of features you get excited to work on. Yeah.

The fun stuff, like this is like fun stuff. This is stuff that will bring like value to the program that doesn't exist yet. This is stuff that has been promised on Patreon or to donors. All those new features, that's where it blocks. That's where I want to get the project working, and then it's no because of those PRs. People also come and complain about the because of those PRs. And people also come and complain

about the state of the current projects. They say, oh, this doesn't work right. Oh, the UI doesn't work right. And they say, yeah, okay, but this is not really finished. It's like I've shipped what I could do with it. It's in a working form while you focus on other features.

Yeah. And I want to change it. I don't want to keep it that way. But also, I don't want to bring back the older, like the old stuff. I don't want to regress. So I want to keep moving forward. But some people, they just say, oh, this is bad. I just want the old stuff.

I just want the old stuff back. And say, no, this is not great, but I want to make it better, not move backwards. Yeah, I can totally understand, especially when you've been working on something for so long. It's got to be a huge driver to want to build these new things. And is the unspoken thing here is simply revenue? If this was a $50 piece of software that somebody had to buy from you before they downloaded it, you could just hire developers. Yeah, sadly, I'm not under the same impression.

So what I see is that 10 years ago, when the Lutris project started, there was a big push from, I would say mostly from Ubuntu, from Canonical, to create those developers. And this effort is just not here today. And this is something that's been noted by other developers. I've heard this from other developers, that there was a huge group effort and everybody was developing software. Even people that never called themselves software developers, they would just fire up some code editor,

write some Python and GTK, and everyone was doing Python and GTK. And there was this quickly framework that would let you create those apps really fast. And now I think there's not this group effort going on, and there's this sort group efforts going on. And there's this sort of confusion of what should we do? What should I code in?

Should it be in Electron? Should I code in Rust? Should I code in Python? There's no, like, I don't know, like, Python developers who work in GTK anymore. I mean, I know one, the developer of Lollipop. I mean, I don't know him personally. I know his code. I know other small projects.

There's a GOG tool that's written with Python and GTK. I mean, if I wanted to hire someone, I don't know who I would hire at this point. I see. The finishery aspect is not the problem because I've made the decision to just work part-time because I wanted to keep Lutris going. So I have a contracted job

that is only 20 hours because I want to keep... I mean, it's not just for Lutris, okay? It's also for having some more time for myself, but also mostly to be able to work on Lootris. So that is myself putting some resources into the projects. But even, I've noticed that even being, having all this time devoted to the project doesn't necessarily help when all I see around it is no one being...

Like I said, I was working on this monitoring stuff for command line applications. And there's no one who is aware of this. Yes, there's an issue on GitHub. There's a few comments that have been... If I wanted to work on this with someone, I wouldn't know who to reach

out to. I wonder if it isn't the point you make in your blog. We don't have a common goal. In a silly way, hating Windows and hating Microsoft and how everybody had been burned by Windows, it was a unifying mission. We all wanted to beat Windows,

and then Microsoft went and rolled over on its own. And I think in a way, with Microsoft not really being the big bad guy anymore, we've sort of lost a bit of unity. And we've sort of lost a common goal. Yeah, sure. I mean, that's something I feel, but also I don't feel that being against Microsoft brought anything of value.

I mean, it brought people to Linux, sure, but I don't think it brought technical expertise and I don't think it brought code, like actual code. So that was something to rally, like to group together, but that's... It wasn't necessarily a healthy thing. Yeah, it wasn't healthy. There's echoes and ramifications and ripples from it

that I think are not positive today. I agree. And I was fully participant in it back in the day. I completely acknowledge that. Oh, I mean, I was participant in the anti-Microsoft stuff before I was using Amiga. Yeah, I mean, I didn't have a computer and I was already on Microsoft.

So what do you think this leaves you as a long-time Linux user? Do you think it's kind of a new, I don't want to call it a maturing of how you are going to interact with Linux in the community, but a shift kind of like from lessons learned. Is it kind of a, have you come to a new realization or a new normal, as it were? Yeah, totally. Not only because of that aspect, but also because of some more positive aspects. The more positive aspect being that I have this Linux console that can play pretty much

any game I want. So from some point of view, the project is pretty much done because I have this machine and I don't have a game that I cannot play. That's great. And that's something I want to

say, okay, this is from now on, this is the reality of Linux. This is that I have this machine that can play pretty much any game I want, regardless of its age, regardless of its platform. So I want to build based on that,

and that's going to be the reality. And sure, there will be some feedback from people who send them some bug reports and they want to bring some features. But from now on, I built the software based on that console that can run those games.

And that's something that I have in my living room that I can work on that is rooted in the physical world. So I don't have to ask questions. I can just make progress on that. It's going to be more of an intentional development style. There's also another positive thing about Rootries is that it's also now everywhere.

It's in Ubuntu, it's in Debian. So I don't want to ship something that's broken and I want to have a lot more testing going on. And I hope that your new focus ends up making you more pleased with the process, enjoy the have a lot more testing going on. And I hope that your new focus ends up making you more pleased with the process, enjoy the process a bit more, and means that we get years more of Lutris. Yeah, that's kind of the goal, is to be enjoying more of the development process. I care about the project a lot.

I would rather change some of the aspects of the open sourceness of the projects rather than just walk away from the projects. It's almost worth listening to that again if you care about this issue because what he touches on, you can kind of extract what the bigger picture issues are. Because what I heard in there is that he feels like he's been left behind by the GTK and Python stack, and he's not really sure where to go next. He hasn't really had a lot of development support. The users definitely showed up,

but he hasn't really had people show up helping him. And I mean, he has had support, but not like core development features, you know, the big stuff. And I think there's also a disconnect right now because he wants to work on finishing core features and users are submitting requests that are more like quality-of-life requests, not necessarily core feature fixes.

And I think he's kind of getting a bit demotivated by it all. No, you're right. I mean, this is something that started as a solo project, a hobby project maybe, and has really grown. And in open source, it can be hard, especially, I think, once you're packaged in distributions, you're widely known. There are a lot of expectations spoken and unspoken.

It's also really hard to find good development support. I mean, this is true even in private corporate development, but when it's a baby, when it's your project, you can't just turn control over to anyone. Delegating is hard, finding good help is hard. And then if you don't totally trust them to make a fully formed PR that just needs a little light review, some checking, then you're going to either have to do a whole bunch of hand-holding and help,

which can be good and can be one way to eventually get more help on the project, but that's a huge investment. Or, as Matthew mentioned, the other option is just sort of taking that idea and just doing it yourself, But that doesn't scale. And this is something he mentioned that I never thought of because, of course, I'm not a developer. But it's not easy to figure out who's the designer to go to to develop GTK applications and have them design a beautiful GTK app. Or who do I go to that has this Python expertise? Like, we don't have a way to really sort that out.

The downside of the flexibility, right? I mean, I think it favors folks with strong opinions and who do just want to make their own project and I'm going to make it work my way. But if you don't have those strong opinions or you want to try to find some help, it's not clear where are those communities, where are other people doing?

If everyone assembles it their own way on the development stack, well, they might not be ready to just jump in and use your version of that. Yeah, that is an interesting challenge as well. So yeah, you're right. That's also in there is sometimes you get a patch that comes along, but it just is written in a way that just not really fit with the rest of the project's code base.

And so that's particularly tricky. And then, of course, in there, you can hear that he's had struggle with motivation as well. And our podcast, I know you had some thoughts on staying motivated when you're getting that kind of skewed feedback from users who want things and not the users that are just sitting back there loving the software, using it every day. Yeah, I mean, I encountered this even in my day job sometimes with developing complex and sophisticated products, but then you only hear about what's wrong with it. You don't hear a lot of praise from it. And I think in open source, that happens all too much, whether it's creating software like Luchas or even content

creators like some of us. Sometimes you just hear about wrongs and not so much how to help people. And I know that can be a big problem that can be motivated. Yeah, really, you know, because like I told him, you know, it's packaged with the distros. So it's not like I download it from the website. I installed from the repo and I've just used it for like eight years and I've never sent him a note saying, thank you. That's why I actually wanted to reach out to him recently. And then he made a blog post and I was like, dude, we got to talk. And I just, I really connected with that struggle of this passion project. It's a, it's a different transition for everybody. And if he could get out of the trenches and build a community

of support around him that could deal with some of that lower hanging fruit, that would definitely be beneficial. But I think part of the problem is just he doesn't have the tactical time to accomplish that. And Neil, I know you've experienced this. You might have some suggestions. Yeah. So it's been something that I've had to experience for years. Like I don't actually write as much code as I used to five or six years ago. I actually do. I spent a lot more time doing coordination and community building and all that kind of stuff because it's actually harder than writing line of code. It's so much harder. And I still do technical work.

You know that, Chris. I've, you know, the Butterfest things and stuff in Fedora with Plasma and Wayland and Pipewire and all that stuff. Yeah, I'm still doing that stuff. But like, I spend a lot of my time doing that because if you don't have someone actually doing that work specifically, you burn out. And so, you know, my suggestion on that front, at least, is instead of looking for another developer, look for someone that is geared towards doing the community building because you can't do both. It's just you'll burn yourself out doing it. I think he's starting to feel that in the first place. And another bit that he was talking about feeling abandoned by the PyGTK mess is the nicest way to put it. I've seen a lot of projects move from GTK to Qt mostly because of this. And the other added advantage of using Qt is that the other market

that a lot of Linux software tends to be more successful on is macOS. And Qt works a lot better there than GTK. And if that's something that eventually somebody wants to do, like Lutris on macOS, I don't see any reason anyone would. That's a thing. But I think PyQt, which is officially supported by the Qt project and is maintained as part of it, is pretty much the go-to for a lot of the Pythonistas

doing graphical applications these days. It's fairly straightforward to use. And with things like QML, it's super easy to do the styling and stuff like that. That's probably, like, if you want to take a hard look about, like, switching ecosystems while remaining Python, that's probably the best choice to go. Otherwise, I mean, another option is, and this is me doing a little plug for myself here, a project that I work on called the Monotools project. We use a library called libue from the SUSE folks.

That's the UI toolkit library that powers the YAST installer. We have Python bindings for it, and it works fairly well. And that library toolkit gives you both Qt5 and GTK3 UIs basically for free by using the abstract interface provided by LibUI. I think the next thing that Lutris as a project needs to consider is not hiring a developer, but hiring a community manager type. A community manager is a really good point. And it could be somebody who could help kind of bubble the people that could help the most to the top to Matthew.

It's a good idea because I think a support community, beyond just a community of users who need, right, but a community of contributors. Well, I think you know, Chris, right, it can be hard to balance time involved directly in the community and then time doing the work, whether that's creating a show or actually heads down in the trenches trying to add a complicated technical new feature. There's just no doubt about it. I sit now as kind of a you know, reward, I guess, maybe in a way for having been around for so long. We have a lot of really good people

in our community that can help organize it as well, including a lot of people who are here in our virtual lug right now. And it means that I get to be more of a participant and that's really great. But that's like, you know, that's what you, to get to that point, you've got to build something for a really long time. But he does have a very beloved application. So I think he's got everything that it would take to build a good community around him. And, you know, he and I talked a little bit off air afterwards, and he felt like there's probably some sort of shift.

Something is going to happen. You know, we talked a little bit about what Elementary OS is doing, and he felt like there's probably some sort of shift. Something is going to happen. You know, we talked a little bit about what Elementary OS is doing, and he thinks that's an intriguing idea, just having kind of some established design languages. And he wouldn't necessarily have to use Vala either, you know, but just kind of following their GTK design language and stuff is an idea just in its sense, because he likes that kind of structure.

I mentioned it in the chat, but he authored this blog post where he goes into a lot more detail. And so if you are curious, we'll have a link in the notes if you want to check that out. Go give that a read. And he wrote it more in the moment of passion.

You know, by the time he and I got on the horn, I think he had some time to reflect on a little bit. But that blog post, I think, was written kind of at the heat of the moment. So that'll be at linuxonplug.com slash 399. Just a couple of last minute housekeeping items, because we're getting long. It's a big show. 399 is a lot. But there was a pretty cool up lug this Sunday. So I wanted to give Minimac a chance to give us an update on how things went at the up lug. Thank you, Chris. So we had a good meeting. I think there were about 20 listeners to the talk. So the topic was very specific. I mean, creating and managing data streams is not

an everyday task for a normal Linux user. But we had some well-informed people in the room. And also for the first time, we had some audio and video recording. So we recorded our mumble room and Bennett shared his screen via OBS Ninja and also recorded his screen at the same time. So I think it was a pretty good success. But we have Bennett here in the room. So Bennett, what do you think?

Hey, MiniMac. I do have to say, Loveblog was a huge success. I was Bennett here in the room so Bennett what do you think? Hey Minimek I do have to say Leplug was a huge success I was blown away with the turnout and I met some really interesting engineers as Minimek mentioned we recorded the Leplug so in case you missed you missed the Leplug and want to watch the recording you can watch the edited down condensed version so you can catch Leplug in a third of the time. How about that? That's great, guys. Man, you know, as we're getting close to 400, I look, oh, you know what?

For the 400 time capsule, I'm going to put down how the Leplug's doing. That's going to be number six in the time capsule. going to be number six in the time capsule. So I just, it's so cool to see, you know, that's a, that's a self, self-started organic component to this show's community. And I think it's so great. So if you want to participate in the love blog, it's every Sunday, noon Pacific in our mumble room right there in the lobby. And we have information about our mumble room on the website at linuxunplugged.com. You can probably find that I would imagine. And then also while we're in the housekeeping, just one more reminder, next week is 400.

We will be live and would love to have you join us. If you haven't had an opportunity to join us in a while, it would be a great chance to come by and say hi and celebrate 400 episodes of your Unplugged program. Then we have 401 pre-recorded, so we will not be live on April 13th. So 401 is going to be a pre-record. But then we'll be back to our regular bat time.

So come hang out with us next week for 400 and then I give you permission to take the week off on 401. You just listen to it on your own time. I'm going to let you do that just this once though. So I don't want to see you doing that too much, but it's a special occasion. And that's really all we have in the housekeeping.

Thank you to our members who support the show, help us stay independent. And that means a lot to us. And especially as we get to, well, I'm just feeling really, I don't know, I'm feeling really something now that we're getting close to 400. I'm really grateful for those members. Unpluggedcore.com. Thank you very much. We've got a couple of perks for you. You get a limited ad version of the show as one feed option. Same full production, all the Joe Lovin'. Just a few less ads. And then there is Feed 2, which is the full live stream. Right as we get going, I hit the record button.

Our mumble room is our virtual lug. You know, imagine being at a lug as people trickle in through the door and you say, oh, you know, it's been a week since you've seen. You say, oh, hi, how's it going? That's a little bit of what we do in there. And we talk about a few topics and kind of just warm up. And then we usually have to wind down and that's all in there as well. It's like a full additional show that gets packed into that second feed. Plus extra mistakes.

No kidding. No kidding. And if you'd like to know how we messed up, that's, that's how you're going to, that's good. Maybe we should, what are we doing, Wes? Why are we doing that? We should rethink that. It can't be good for our reputations. No, no.

But too late, we've committed. Yeah, I know some people like the full thing. So thank you everybody who supports the show over at unpluggedcore.com. Just a couple of feedback items

before we get out of here. Number one, it was just an excuse to mention a great tool that we haven't talked about for a little bit. Jack writes in. He says, hey, guys, I'm not aware if you've seen this before. I think I found a great tool for system administration and for local management or even remote server management. It's called SSH. No, I'm kidding. It's called Cockpit.

And it's, of course, in Arch, but it's also in Fedora and a lot of other distributions as well. And once you install it, you'll find it at localhost on port 9090. You can manage VMs, updates, network, and a bunch of other stuff. Hope you enjoy it, and thanks for the show, Jack. Well, Jack, we love Cockpit here at the show. We've talked about it a few times, but Wes and I were thinking it'd been a little bit. Did you recently just install it too? Is it just totally unrelated to this email?

Yeah, well, I was doing updates to JBot over the weekend. Well, updates now. Basic maintenance, let's call it that. Life support restoration, hospice care. Yeah, yeah. I was moving it to a Fedora 33 box and, you know, there was Cockpit for me already. I was like, oh, yeah, I've kind of forgotten about Cockpit, but it sure is handy to have because it's come a long way

and it really is quite full-featured and handy. Yeah, it is. No disrespect to the Webmin team, but it makes Webmin just look like a real tool of the past and Cockpit has a much better security history and story, much more modern. I think that's it. I kind of forget that GUI server management

can be a thing on Linux, because I'm just used to using the command line anyway, and that's kind of my preference, or at least default. But you're right, Cockpit kind of resets that. It's good. Also, a lot of times people will write in and say, how come you don't talk about XYZ Web GUI to manage containers on the show? And a lot of times my response back is, oh, how come you don't talk about XYZ web GUI to manage containers on

the show? And a lot of times my response back is, oh, because Cockpit does it. Cockpit does it well. Five wrote in. You want to take his email? Five wrote in with a interesting little tip he developed with more people becoming eligible for the COVID-19 vaccine. One of the most difficult things now is getting an appointment. I resorted to writing a simple Python script to output availability using the VaccineSpotter.org API. The script is noisy, but attempts to output only new availability. I also wrote a matrix shell command to send me various notifications. I've used this script and Cron to notify me when new appointments open up. Just thought I'd share with the Linux Unplugged

and Jupyter Broadcasting community since I think everyone in it rocks. And boy, you are right about that one, Five. And thanks, this looks pretty handy. It can be pretty tricky to find those appointments. And this is exactly the sort of, you know, open source sharing and just like, you've learned some fun tools on the Linux command line

and now you can make them useful for problems in your own real life. What a great example of learning to build something by having a problem to solve. And this was a clever one. I like this. And it got me thinking, if you have little small projects like this, they don't have to be significant, although those are cool too. Let me know. But more importantly, let the Coder Radio Show know, because I'd love to maybe talk about them from time to time in our feedback, just like Five just did. You can go to coder.show slash contact for those. And little code projects you've built to solve problems like this that maybe others might be interested in but nobody knows about it, I'd love to share what our community is building.

And the Coder Radio program would be such a perfect outlet for that. So coder.show slash contact for that stuff. Coder code swap. Yeah, actually check out the Coder Radio coming out later this week because Wes joined to give Mike a hard time. So I really enjoyed that episode. Hey, that wasn't my intention, but that is what happened. Anyways, this here show, if you want to find anything that we talked about today, links for all of that stuff, of course, all at linuxunplugged.com slash 399.

links for all of that stuff, of course, all at linuxunplugged.com slash 399. If you do that Twitter thing, that Twitter thing, you can follow the podcast at Linux Unplugged. I'm over there at Chris LAS at Wes Payne over there. That's right. You on Twitter, Wes? I sure am. I don't see you tweet much. You know, you're not a big tweeter. I should probably tweet more or maybe I shouldn't tweet at all. I just don't know anymore. You tweet when you need to, right? I mean, you're not spamming people. You're not spamming people. That's right. Low volume, just some weird, interesting things from time to time.

Yeah, and, you know, same on the Grams. He's got some local pics that are pretty good. So go check that out. But the whole network also has Twitter, you know. It's a thing. So what can I say? The network's there at Jupiter Signal. But really, you know what's great? Websites So what can I say? The network's there at Jupyter Signal. But really, you know what's great? Websites. Websites are good. And we have one of those,

JupyterBroadcasting.com. So go over there. Yeah, just good, clean, pure HTML for you. Well, yeah. I mean, I don't know about pure, but definitely HTML. Don't look too close. And be sure you check out Linux Action News every Monday morning. Wes and I break down everything that matters in the world of Linux. So join us. We'll be back for episode 400 next Tuesday. That's at 12 p.m. Pacific, 3 p.m. Eastern. And we'd love to have you join us to celebrate 400 ridiculous episodes of the show I launched to read emails.

Yep. And now look at us go. But I'm looking forward to it. Wes and I have been doing something special for the last few weeks in preparation, and we will unveil it in episode 400. Thanks so much for joining us on this week's episode of the Unplugged program. And we will see you right back here next Tuesday. All right, let's name it. JBtitles.com, let's go pick our title. Mumble Room, you were great today, everybody. Thank you very much.

Lots of great discussion. I really enjoyed that. Really great that you contacted the developer for Lutris, actually, and you got to talk with him. Oh, yeah, yeah, it was great, yeah. Yeah, and I wasn't sure if at the time it would work out, but it totally did, and that was pretty cool. It was nice.

And I think he's found a new comfortable place with it. I think the project's safe. But I think it's good to touch in with those issues because, like, we don't want to talk about it all the time on the show because it's kind of a bummer. That a lot of things aren't great for people who are putting software out there for free. Surprise, surprise. And we don't want to talk about it, but it's the reality. software out there for free. Surprise, surprise. And we don't want to talk about it, but it's the reality. And I get the sense that most people in the community are down for a solution that's equitable for everybody. And we just haven't really stumbled on the right one. And when we

get there, I think it's going to be great for developers. We're just not there right now. And in the meantime, it makes me even more grateful for everyone out there who's sticking it out. Even if, you know, they're never going to make a dime, they're somehow finding that balance and they keep going. And it just makes me just incredibly grateful for them. Yeah, I mean, it really makes the Linux desktop, the open source world and landscape, I mean, it makes it what it is, right? And it makes the arse kicking that we're giving to the commercial desktops even more impressive.