LINUX Unplugged - 415: Something Sinister Below Deck

Episode Date: July 21, 2021

Could the Steam Deck mean fewer native Linux games? We chat with prolific game developer Ethan Lee and get his perspective on the negative impacts of the Deck. Plus, our thoughts on how Valve might successfully ship Arch to consumers, a batch of feedback, and more. Special Guest: Ethan Lee.

Have you noticed how just about every Linux news outlet is talking about Microsoft's CBL Mariner distro? All at the same time right now. Just going by my feeds, and I'll put a link in the show notes to prove it, I've literally counted a dozen stories written in the past week-ish about CBL Mariner, which is, I don't know, it's funny, I guess, because I thought everybody knew about this. I mean, clearly a few people must have missed Linux Action News Win 86. Because that was back in April we talked about this thing. I think so.

Okay, a quick recap. Microsoft's distro is called CBL Mariner. Kind of a strange name, but CBL stands for Common Base Linux. Clearly they weren't trying to market this thing outside of Microsoft. I guess they use it for all kinds of stuff, but including containers in Azure's Kubernetes service. And now, it's part of that secret sauce making the GUI work on WSL. Yeah, it's got all the bits in there to make a base Linux system work.

Yeah, Pulse Audio, Wayland. Yeah, it does Wayland. Isn't that funny? We kind of broke it down in Linux Action News, so you can check it out in episode 186. And it's really Microsoft's just middle layer Linux. They originally got it started in Azure, and now they're using a custom RDP virtual channel, using the RDP protocol,

and it talks to the Mariner's Western RDP server, and it does the communications for the graphics, for the video stuff, using Wayland, and it uses Pulse Audio to create an audio channel that goes over that RDP connection, which goes back to the Windows client running on the desktop. And this is just something

that the Microsoft Linux engineers created, so that way they had this middle layer here to do this stuff for their Edge devices and their cloud devices, and now for WSLG. It is public, and of course it's up on their GitHub, but there's no official ready-to-go builds. There are some tutorials you can find. But interestingly, Wes, did you know that CBL makes use of RPMs?

It's got tiny DNF for package management. Is that right? Yep. This really is one of those situations with Linux where anyone can make it useful, even Microsoft. Hello, friends, and welcome back to your weekly Linux talk show. My name is Chris. My name is Wes.

Hello, Wes. I see you brought the pops with you. I sure did. We got some show dogs today. This episode is brought to you by the pops with you. I sure did. We got some show dogs today. 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. You know, they got hundreds of courses, thousands of hands-on labs.

So get certified, get hired, get learning at acloudguru.com. Well, you got a big episode in 4.15. You know, of course, probably everybody's wondering if we're going to talk about Valve's Steam Deck. Yes, this week, if you hadn't heard, somehow, Valve announced a Linux-powered handheld device. It's a handheld, high-powered gaming device that lets you take your Steam library with you wherever you are. It's got a beautiful 7-inch display, ergonomic controls that are really built for long play sessions, and a new look for Steam designed for Steam Deck. You can think about Steam Deck like a portable gaming PC with built-in controllers. We have like a million

thoughts around this. There's so much to talk about, and there may be a turd floating in this party punch bowl. A prolific Linuxux game porter ethan lee is going to join us later in the show and he's going to shed light on maybe some of the negative ramifications around valve's effort for the deck the way they're communicating and messaging to developers and what could be a negative for the future native linux. Ironically, the deck may actually be bad news for Linux gaming in some ways. We're going to get to all of that. But first, we really should say time-appropriate greetings to our virtual love. Hello, Mumble Room!

Hello! Hello, everybody. You know, this is kind of special. I realized, I looked at the calendar and I said, holy crap, Wes, we've got. I realized, I looked at the calendar and I said, holy crap, Wes, we've got three episodes left before I hit the road and start heading towards Salt Lake City. How is that happening? Where did the time go? I don't know. We better start making plans.

Should have made those plans a while ago, I think. Yeah, yeah, I know, right? I mean, right now, I've been so focused on getting Lady Joops ready for the road, you know, because she's got to be a home. She's going to have to be a production shop. I'm literally going from the roof down to the axles, getting her ready to go because it's going to be like a 5000 mile journey. And it's mostly over the Cascades and the Rockies. Just a few mountains in the way. Oh, my gosh. So we kind of we kind of have something special something special that is happening on the road trip. Uncle Brent is going to join us, the kids, Hadiyah and I. Brent's going to be on Lady Joops capturing the trip, capturing bits and moments that we're going to shape into content for future exclusive releases after we get back from the road trip. Now, that sounds great. And obviously, Brent's a great fit for that.

I'd like to know, are you going to teach him how to drive the rig? Oh, you know what? I hadn't thought about that. There's very few people I would be willing to let drive Lady Jupes. Rightly so. I mean, it's your home. And Brent is one of them. He is a terrific driver. I have co-piloted with Brent before, and I have seen him in action. It definitely would take some training. But one of them. He is a terrific driver. I have co-piloted with Brent before, and I have seen him in action. It definitely would take some training. But one of the things he'll probably do is, if he wants, is we're going to have a chase vehicle. We thought about towing it.

But with two other adults on board, we think we're going to do the chase thing where we'll have another car with us. And Brent can go and have his private time in that car. You know, he can listen to his audio books and his podcasts and be, you know, on his own playlist for most of the day, if he wants. And the nice thing about co-piloting like our co-driving like that is we both have radios. So even if we don't have cell signal, we can still quickly communicate with each other. And if I see an obstruction on the road up ahead, I can call back to him and I can say, Brent, can you make me a hole?

And Brent will move over and block the oncoming traffic so that way I can get choups over and then get back and going again. So it's really nice to have, or you can go and scout a gas station before I- Right, go find some good landing spots for us. And report back to the mothership. And then when I get in range,

he can radio me and tell me, okay, you're looking good. This is what Hadiyah and I do too. So that's extremely useful. Or he could just write a long board and just chill out. It's a nice view up front. But the fun idea that we had was this seems like a great opportunity to make some really fun content, some exclusive stuff, because along this road trip, not only are we going to be meeting up

with Jupyter Broadcasting audience members, but are we going to be meeting up with Jupiter Broadcasting audience members, but we're going to be meeting up with team members, you know, members of the crew, and capturing those moments. We haven't seen each other for a very long time. It was a whole other world last time. We have some friends that have been on the show before that we're going to

be seeing along the way. And then when we get to Salt Lake City, we're going to do an official meet up there um we have some swag planned we're going to have some swag on board juice yep yep it's the swag tour you know one of the things about since we went independent is uh we don't have a dedicated designer anymore and man is that tricky and linode stepped up in such a huge way they basically just got their design team together for us and they've created stickers they've created uh stuff to go on the shirt

we're gonna have some really cool exclusive swag um very awesome and i if we have enough we'll try to put some on the garage afterwards but they've put together some awesome stickers of lady jupes on the road trip. And, um, they will also be giving away like a couple of raspberry pies and doing, doing, um, a few other like a raffle giveaways at the Denver meetup. So we got some, we got some plans.

We've got a couple locations. I've pinged the meetup group in Salt Lake city, asking them for suggestions. So if you're in the Salt Lake city area and you can give us some suggestions on a venue, you got that local expertise. I was thinking like, I mean, asking them for suggestions. So if you're in the Salt Lake City area and you can give us some suggestions on a venue, you got that local expertise. I was thinking like, I mean, maybe we just do like a park with some shade and we bring some food and some drinks or something.

I mean, we could do that too. It doesn't have to be anything super fancy or it could be. So meetup.com slash Jupiter Broadcasting for the two official meetups that are on the books. But then the plan is I'll have the live tracker with me and I'm going to have a website at colonytracker.live with a little link on there. If you want to do a micro meetup, that's what I'm calling the live micro meetups. You hit that little button. I've created a specific form that asks you a couple of questions so we can arrange a meetup. And that's going to be all at colonytracker.live. Your direct link to Lady Jibs. It's getting real close. I don't know if

we're going to get everything done in the three weeks. It's pretty nuts when I think about it. And then like, I realized Brent's going to be on board, then he could join me for some of the shows. Oh, yeah.

I need to have like a two host setup in Jupes, which has traditionally been a single host setup, which means immediately I'm going to a mixer, right? That's so that had a complication right there.

And last time I looked, you didn't have a separate sound booth installed in the RV. Okay. No. I'm thinking like he'll be in the dinette and I'll be in the upfront work area or something. We'll just do a little bit of distance and then rely on the sound isolation of our mics, I suppose.

But trying to just coordinate all of it together, we're creating a new sleeping space in Lady Joops too. So he, you know, has his own spot. A bread box. Yep. And all that stuff. Very excited. He'd join us, but he's a, he's box yep and all that stuff very excited he'd join us but he's uh he's mid-project right now so he can't really join us but it's all getting really close

and then we'll be producing some shows on the road of course as well and then uh wes is going to meet up with with everyone and all of us in denver and we're going to do a linux unplugged in denver from denver i don't know where yet. We don't actually have a place figured out to record yet. Day two. So we've got to figure that out. I don't know how we're going to live stream it,

but we're going to try to do that. I don't know how we're going to accommodate a mumble room too, but we're going to try to do that. I've got to figure it all out. Just a few small details. And it should be fine because you're going to get

in the night before and I'm going to get in the day before that. It's plenty of time to figure this out. Plenty of time. Plenty of time. There should be no interruptions.

However, if the show's a little weird that week, you know, mid-August, the week of the 20th, you know, so the episode like on the 17th or 18th, you know, maybe give us a little latitude on that one. You know, because we're going to try our best. But you never know what's going to happen when you're kind of throwing it all together. And if you are in that area and you know of a space we could use to record for two of us. Let us know. Or maybe three. I don't know.

Or maybe, I mean, imagine if a few of our friends should. Maybe more. That would be something. What's going to happen? Who knows? Stay tuned and find out. But we do have a lot to get to today, including our chat with Ethan, which is, I think it's extremely, extremely important. It brings attention to a subject that is completely

getting lost in the announcement of the deck, which has otherwise been very positive. So before we jump in all that and to give room for Ethan, I want to say thanks to Linode. Linode.com slash unplugged. Go there to get $100 in credit on a new account for 60 days. $100. And of course, you're supporting the show. Linode is our hosting provider for everything we've built in the last couple of years. Their infrastructure is solid.

It's fast. It's flexible. You can focus on your project and not on all the details of hosting a server. But you can get down as deep as you like. And they got 11 data centers to choose from and every service level,

every single box you get is backed by the best customer support in the business. And when that matters, it makes all the difference and of course linode is making our jupiter colony reunion possible they have been so supportive not only financially but by contributing their the time of their of their designers contributing the time of some of their web developers and of course they're going to be making the meetups even more awesome with swag and giveaways.

Like when I brought the idea up, it was like, it was like a co-idea. They like, you know, we'd love to do something. And you know, we'd love the idea of a road trip.

And I was like, well, we want to do a road trip and here's what we're talking about. And it was just, it clicked immediately. And they have been so supportive through all of this because they really care about this. Like what they have been focused on throughout the entire thing is like,

when we get to that meetup, we just, we want to talk to people. We want to ask them what they think about Linode. We want everybody to have a great time. And it has been so easy to work with them because that is their end goal in this. And that,

that, that has shined through when I've seen them support other projects in the communities, distributions, and of course events. And now to see them help other projects in the community, distributions and, of course, events. And now to see them help us make this reunion possible, it's just been like, I don't know, man. It just took my appreciation up for Linode to a whole other level because, of course, I've appreciated them for an extremely good technical service that they've executed on extremely well since 2003. I'm like, okay, I recognize that indie game and I support that.

and like, okay, I recognize that indie game and I support that. But then to just kind of see them step up in this way, you know, the way they've contributed to the design team and the web team time and really been there to like check in and see what I think about what they're doing and all that stuff, like just way above and beyond. And it really shows the passion.

And that's the thing, the passion for the Linux community and the passion for Linux itself. And I could tell you so much about the service and why we choose to use it, but I think that $100 will do the speaking for itself. So what I want you to do is go to linode.com slash unplugged, get that $100 for a new account, try this stuff out, build something, learn something. And of course, you support the show. There's a lot of ways to host something. And there's a lot of

different companies with weird, crazy funding schemes that are trying to dump on the market. There's only one that's like Linode that checks all the boxes, remains independent, and focuses on the things that make running services on Linux excellent. So go try it out at linode.com slash unplugged. So the Steam Deck has been announced, and it's extremely impressive. From a hardware perspective, what they've managed to get in there with the AMD chip in there, the screen, the USB-C connectivity with an external dock, and then the storage expansion via SD, and then the form factor with the trackpads, a lot of things to check in my boxes. Yeah, no kidding. I think it's checking a lot of boxes around the community.

Seems like most of the people I know are thinking about buying one if they haven't already reserved one. I decided to reserve one. I decided to reserve the big boy because it's also got the anti-reflective screen. And I thought that just seemed like the way to go for me. Long term, I'm probably going to use it. And I also, you know, I admittedly, there's a dad factor in here for me. This is sort of solving a problem. My kids are getting to an

age where they want to game and they see their big brother doing it and now they want to do it. You know, the younger, the younger girls. But Dylan's got a pretty sweet gaming laptop, if I recall. Yeah. And I just can't afford to buy them all gaming laptops, right? That's crazy. Let alone laptops for yourself at some point. But as a dad, like the idea that we could all be multiplayers, some gaming together, like that sounds like some like good memories right there. Yeah, that's the new dinner table.

And then that they can dock this, right, that they can dock this and have a desktop PC. With Linux just right there. Yeah, yeah. Big. That's a big deal for me at a price point that I can swallow

because I was willing to get them switches, right? So it's not too different. Yeah, this is so from like the dad mode. This is such a this is such a big deal for me. And the reality is that Valve's clearly been working on this for a very, very long time. And they've also wrapped this up with a new pretty UI,

and they are promising 100% Windows game compatibility in the near future. We definitely have some thoughts on how that might work out, as well as their new Arch base. Yeah. Oh boy. Yeah, we'll do that in a little bit. But first, we wanted to shine a light on an area not getting very much coverage right

now. Some potential fallout from Valve's new focus and that big drive for Proton compatibility. Prolific Linux game porter and developer Ethan Lee sounded the alarm bells about this from Valve's new focus and that big drive for proton compatibility. Prolific Linux game porter and developer Ethan Lee sounded the alarm bells about this on Twitter recently, and he's been involved with some of our favorite games. Late last night, we called him up to discuss how the launch of the deck might actually mean fewer native Linux games. Ethan, thank you for joining me, especially on the short notice.

I know, and please fill in the gaps here, from my recollection, were native Linux games. Ethan, thank you for joining me, especially on the short notice. I know, and please fill in the gaps here, from my recollection, I know that you've been involved with some of my favorite Linux game ports, Streets of Rage 4. I believe there's a couple of others in there, including V that I never know how to pronounce, and more. It's funny, because I've worked on too much stuff, so I have to remember what I did recently. Streets of Rage 4 is probably the most recent one that people remember, but there's also Fez, Celeste, Dream Daddy, Rogue Legacy.

And some libraries that Valve uses themselves as well. Yeah, so mostly what I do is I make an X and A re-implementation called F and A, and then alongside that, an X Audio 2 implementation called F Audio. And both of those, while they're actually designed for native games, they actually are now integrated into the official version of Wine as the XNA re-implementation and as the XAudio 2 re-implementation, because I designed them, in addition to making it easy to port stuff, to just be very accurate. And so they were able to kind of integrate that into their software in a way that

helps with preservation, which is the main goal of both of those libraries. Sure. And it sounds like just from that overview that Linux native games and porting games to be native on the Linux platform was a big part of what you've done and what your career has been. And that might be changing now with the announcement of the Steam Deck. Yeah. So basically since April 2012, so it's almost been 10 years, it's getting close. I've just been doing Linux game development as my full-time thing. It's always been my primary thing, first and foremost, to do Linux games. I did Mac versions alongside that because just culturally, those two happen to be very similar

and was an easy way to pitch a port. That actually stopped this year. So it was kind of strange to go from like in January, I said, okay, no more Mac versions. It's the ecosystem there is just too crazy. And I like working on platforms where, you know, I have a good relationship with the vendor and they are not too invasive, which in hindsight, well, we'll get into that. Yeah, so it's it seems like you're looking at it, you know, even just a few months ago and the situation's clear.

Apple has an agenda. They have the M1 platform now. They're really not focused on wide game compatibility. It seemed likeux would be the open platform but i noticed a couple of red flags with the announcement of the steam deck and then i saw your twitter feed but the first red flags i i noticed the developer documentation so not just the promotional literature but the developer documentation really only talks about proton there's a couple of slides that say native games are also compatible but all of the docs just say focus on proton and then i saw i saw your tweet

that it seems that some people have maybe even been contacted suggesting that they should instead of focusing on a native version just go ahead and just focus on the proton version and i'm getting mixed signals on on on if that's something that Valve is pushing or not. And it seems like you've gotten wind of the same issue and it seems alarming to you. The deck is the thing that's, I mean, we'll get to that. But just for like historical context,

because I think the context particularly matters. Sure. Both in the sense of like where my role is in it and where Valve might've been coming from originally. So I think it was August 2018 that Proton ended up being announced as a part of the Linux client, which was exciting to me.

When I was always pitching the idea of Steam for Linux, it was always interesting to think about, even if you assume from 2012 on when they started doing Linux games for the Steam client natively, you still have a decade and even more longer, depending on what you consider

older releases to be, Windows-only games that are this giant back catalog problem that they have to fight. And so for me, when I saw Proton the first time, it was like, oh, this is a great answer to the back catalog problem. And I think I ran a MacF when I saw Proton the first time, it was like, oh, this is a great answer to the back catalog problem.

And I think I ran a MacFest panel about Proton specifically and how it did a really fantastic job of kind of filling in a gap. Right, games that were never going to get ported to Linux. They were, the developers have long moved on. Or don't even exist. Like you couldn't even go back and say,

hey, do you want to kind of do like a remaster or something like that to make it? Right. And it was to the point where I was kind of interested in working with it because it was something that I had, even as a native there are XNA games made by these one-man development teams from like 10 years ago that kind of threw an XNA version out there and nobody knows where they are. Like we have no idea

what their identities are. We just have this binary blob and we don't know what to do with it. So I actually from, I want to say like October 2018 to like November 2019, I was technically on, like, October 2018 to, like, November 2019, I was technically on the Proton team. My job basically was to implement the new xAudio 2 implementation

that was causing a lot of problems for games, because xAudio 2 is very, very low level, and trying to do a high-level emulation of it is basically impossible. And then kind of alongside that, we decided to do, you know, X and A integration as well, because it's not as big as like the no AAA games made with X and A. So it's kind of, it's kind of one of those things that I don't know if they had that pictured or anything, it was just something that we could at least justify as making like 100% completion a viable thing. But after that, like once the integration was done, it kind of became an interesting

conversation of like, well, is there anything else you think you'd like to do with us? And I tried working on performance with them because obviously, you know, historically Wine has kind of lagged in terms of performance, but particularly compared to Windows, which is kind of a hard thing to compare. But the point is like there was this emphasis to make it more performant and as performant as Windows, which actually is surprisingly viable in some cases. So I tried doing that. And then once that kind of was explored,

it was like, it started to lean like, do you want to be a wine developer? And I said, no, because I mean, there's an obvious conflict of interest there. Like I would prefer that my time be spent making native games and the technology that makes native games work, work well. So after that, I kind of went back to native where I made an emphasis on trying to focus on native. And it went okay at first, but within the last few years, it became very noticeable that the line between native and Proton was blurring,

which, okay, sure, Windows developers like to not do work, so being able to have that work done for them for free is fine. But within the last year in particular, I started noticing that developers weren't talking to me anymore. And if they were, they either were coming back to me from their old games saying, is this Proton something we need to worry about? Or in some cases, it was just flat out,

okay, we have Proton now, we don't need your services anymore, it's done. Some cases I was able to kind of get against that. I know Streets of Rage 4 was kind of an awkward situation where it's one of those difficult parts where I don't know the full story, but you can tell it was definitely a case where Valve actively got involved

with the Windows version and made it with Proton. And when it came time to actually start the work on the Linux version, there was this awkward conversation where it was like, well, do we need to? Or is this enough to make it work?

And then luckily they went through with it. It took a long time because the pandemic kind of made it difficult for QA to kind of check everything. But, you know, having that awkward conversation combined with the delays, it's a situation that's like the best case scenario for what I've been experiencing. Most of the time, it's just developers who I've previously worked with before just kind of shooing you away, or just ghosting me.

And you get the sense it's, they've realized that we don't really need to bother with this native port. We can just make a few adjustments. Even Val's engineers will give us the tips we need to make adjustments for Proton compatibility, and that's good enough. So that's sort of the thing,

is that there's this line that, and keep in mind we haven't even gotten to the deck yet this is like 2020 like this is like a year before and so there's like this line that's not being drawn here where it's like okay the back the whole point of the back catalog problem was to kind of get a broad solution for a problem that is very, very large in scale. And while, of course, you're going to run into scenarios where you have a single game and you want to explore it, there's a very distinct line between trying to come up with a solution that works for a broad portion of the catalog

and starting to act as a specialist, including developer outreach, where it's like, hey, that's what I'm supposed to be doing. Like, it's my job to be the one who specializes the work and does the outreach and uses my expertise. And so there's this line that's blurred

where it's like, well, the only real difference is that you and Valve, as far as we're concerned, and as far as we're being told, are, the only real difference is that you and Valve, as far as we're concerned, and as far as we're being told, are basically the same thing. But you cost money. Yeah, it's hard to compete with free. They're also promising less work, too, and less time investment. Yeah.

And that's the thing that kind of becomes a struggle because I would have, if there was a distinction, both in the internal process and in the way they present the product in a way that makes the distinction of what it takes to make a really good native game and what it takes to make it work in Proton, both on the back end and what developers have to do, and you really kind of make it clear that there's a one-size-fits-all versus a specialized and who controls the product at its core it's like it feels like a loss leader product rather than a preservation product at this point it feels like we had this giant thing that obviously i can't speak to how much it costs to develop proton but you can probably take a guess given the gigantic size of the catalog combined

with the expertise that it takes to actually get it to work with so many different things reliably. And so when it just feels like it's become this thing where it's better for their image to not point any of that out. And unfortunately, as a result, it puts us in the native world in an extremely uncomfortable position where we have to like prove before we've even started the pitch that what we're doing makes sense which is not uncommon like hey it's hard to justify a linux version if you just go and say let

me do it like obviously i have to be able to say like it's a small audience but we can make it work you'll make your money it's not going to be a sunk cost like we can make it work versus look i know what valve told you that everything i'm about to tell you is completely unnecessary, but trust me, it's hard to undo the words of a multi-billion dollar corporation. Especially when it's offering to save them money. Yeah. That is very tricky. And it seems also, it sort of like gives Valve this ability

to ensure that there's going to be certain games on their platform if they go this route. Like I can see there's an incentive structure for valve to pursue this avenue sure it gives them a bit of a guarantee to be able to say that these games work without having to consult somebody else because i think for them it's nice to be able to say that have confidence in their own stuff internally without having to depend on someone else. I mean, any company is like that. We like to have everything in-house. I can kind of see that making even more,

or at least becoming even more of a priority when something like the deck is being worked on, because that must have been in the works for a while. Yes. If you look at things like GameScope and other similar types of investments that Valve have made outside of the Steam client itself, you can see that this is something that they've been thinking about for a very long time.

Yeah. And if they want others to sell hardware like this, they're going to need some sort of compatibility guarantee, some sort of middle layer that they control that makes sure that the games run on all the different on the Dell version of the deck and the HP version of the deck. Me and some other people were talking about this earlier today. When we try to compare the Steam Deck to the Steam Machines, we try to figure out what they wanted to correct and what they haven't corrected

or how they're presenting the information. It does seem like we're not entirely sure what the difference is other than the catalog. Because if the idea is that you're going to have other vendors do this, what's different from this compared to Steam Machines other than the form factor? I have a Steam Machine here, actually. It's basically just a Dell device they put Linux on.

And that's kind of it? It's cool that we have other people making the hardware, but the hardware wasn't the problem. Like, I know everybody talks about, like, the fact that Linux would probably be more widely used if it was pre-installed. The Steam machines in particular made me reconsider that argument

because the first thing that most people would do is they just put Windows on it because it turns out SteamOS versions just happen to be cheaper and they can find Windows at a pretty steep discount where they can just reuse product keys. There's a million reasons that people would just buy a Steam machine and then throw Windows on it. So I think the software catalog for them was a bigger concern here, which is why I think they're being so aggressive about it and not really being all that concerned

about the consequences of what happens to native developers at this point. And do you think that would motivate them to the point of discouraging native ports? It's up in the air. When I was talking about Valve reaching out to developers about focusing on Proton despite having native versions, there was a bit of context lost in that where it was a mixture of developers who historically have always released native and may have always been doing native anyway and then getting this weird email

about like, you know, by the way you don't have to do this anymore and then there was the other half which is what I was talking about earlier which is developers who have historically released native but may not have done it for their latest thing. And suddenly there's this whole argument like, oh, we don't need to worry about that anymore. And here's the thing that shows us that you don't have to worry about it anymore. Yeah. And look at all this buzz, look at all this press, and now look at these

developer documents that just say target Proton. Right. And that was the thing that was really frustrating is that is knowing that because again, this is something that's been in development for a very long time. So it's just a little is a little frustrating that there was

all this time. And obviously, there are lots of people working on this product. You know, from every angle, we had people who including people who focus

on Linux development. Nobody looked at these docs and stopped to say, should we maybe have like a line about it? Like one? And the wording of it just seems so careless. Just so unconcerned

with the consequences of what it would mean for an entire industry of developers, for Valve of all people to say, Linux native is unnecessary. Like, you don't think that's going to have some consequences to that? And after that post came up, someone at Valve did reach out and were kind of surprised about it.

Are you saying that someone at Valve that contacted you was surprised by your tweet? Yeah. I mean, hey, when something like that gets that much attention, particularly if you weren't expecting it, I'll give them that. And the fact that they did reach out is great. But even after that conversation, it just seems like the risk of atrophy is not something they're thinking about. Because let's say hypothetically that, okay, sure, everybody gets on Proton. The product does well.

And let's say hypothetically there is like that performance delta that developers care about. Okay, but once you get to that point and then you start to talk about native after the fact, you have to consider what have native developers

been doing in that time? Because I can tell you what I'm doing, which is nothing. Because there's nothing I can do. I don't have clients anymore. So is the characterization of the response sort of, well, this is a stopgap measure. This is a temporary thing just to get games on the device.

Was that the nature of the response? I think that might be the nature of the whole strategy. I mean, I don't think this is uniquely something that they told me and just uniquely in private. It seems to just be what they're thinking in general. Because they talk about things like, oh, you can use Vulkan, you can use something that's not a patented codec, like use VP9 or whatever instead. But that's with the expectation that this is going to take years to develop.

And that's assuming it happens. So you're basically telling me that I, as a one-man development team who does Linux games, which already works on a very low budget, you're expecting me to just accept that I'm going to have this tank in revenue and just activity in general. And I'm just supposed to expect that at some indeterminate period of time in the future that suddenly it's going to turn back around

based on just a hypothetical idea that it's going to come back. Like I have no material proof that's what's going to happen. Right. People may just stick with Proton. They're happy with it. They're moving on to the next game. They don't even care. Right. Or it's just like

or maybe that won't happen. Like I'm just going to lose all my customers and then the platform's going to fail and then it's just going to be yet another thing that's like well it didn't even work this way so I should be care period. So like there's all these risks that I'm just expected as some random jerk in Georgia

supposed to just accept and I'm just going to weather it jerk in Georgia supposed to just accept, and I'm just going to weather it out somehow. While Valve is doing the math, and you have to figure they looked at the Steam machines and they went, all right, this didn't work for multiple reasons, and one of them was game compatibility. One of them might have been that they chose Debian as their base. The choice of Arch seems to be almost like a reactionary choice

to their Debian choice. And now with Proton is this compatibility strategy, and they've been investing quite a bit in other aspects of the stack to improve performance. And you look at it and you go, they're really betting the farm on this because this is like, this is for a corporation. How many meetings must they have had? How many people, how many staffers must be working on this project for it to extend over five years or something like that now? I mean, it's remarkable. And so you have to

figure they are on such a course with so much momentum that they're not really even giving how it impacts independent developers like yourself who are in that ecosystem. They're not even really thinking about it. Well, when you're that big, it's hard to measure. system. They're not even really thinking about it. Well, when you're that big, it's hard to measure. Even factoring out Linux, for example, like Steam has kind of frustrated small developers for quite a long time.

So this is just really my example of it, where when you have a billion dollars to spend, like, what's another million? But like, hey, I wish I had a million to look at, you know? Yeah, yeah. Do you plan to go back into like Windows gaming?

What's your thoughts there? Is this sort of ending your Linux gaming career? It certainly is kind of putting a knife into my Linux development career. It would take a substantial turnaround because like the thing is, even if they were to undo a ton of the stuff that they've done, it's out in the wild and the impact on it just as proton has been even buying closed doors

has been pretty tremendous like when i was having this conversation i was like like i went and i looked at the numbers one more time and it's you can you can see like to the year like it just comes crumbling down like real quick so the fact that it's only getting worse is definitely kind of sticking a knife into it. But I mean, as a player, it's hard to say. I mean, I still technically made a lot of games, and it'd be fun to kind of be able to keep playing or maybe even keep supporting them,

depending on how aggressive the strategy is. Maybe they just decide, oh, we're just going to try and make all games proton-based. I don't know if that's kind of outlandish of a claim to make, but I don't know how desperate they're going to be to get to the end of this compatibility problem. And I've been using this stuff for over a decade. It'd be a shame to throw it all away.

Indeed, indeed. It kind of seems like the best hope would be if game shops appreciated the value of a native port and they wanted that. And I suppose the only way we're going to get that is if the customers are asking for it. Yeah, and that's the thing that's been really discouraging is kind of seeing the response to just the idea

that that might be what they're doing. I mean, obviously, a couple comments on the internet doesn't represent a whole community, but it really was just kind of seeing that even after 10 years of making games, like the attitude, even with my name on it, was still basically good riddance, was a little disheartening.

And it's difficult being as negative as this, but being told that the last 10 years of your life were unnecessary, I don't know how I told that the last 10 years of your life were unnecessary is a, I don't know how I'm supposed to spend that in a positive way without putting in a lot of mental gymnastics into it.

I understand. I enjoy the games that you have been involved in. And of course, I know a lot of our audience very much does appreciate a native port of the game. So you have supporters

in our audience. Well, keep in touch. Just kind of let me know if any way which direction it does go i suppose it's such a game changer now to kind of use a horrible pun uh and we just don't really know but i do appreciate you informing us and enlightening us of this side of it because i think this is an aspect that just hasn't gotten a lot of coverage in what has otherwise been a lot of excitement around the deck. Yeah, and it sucks to be the bad guy for something that is actually kind of cool in terms of hardware.

But, like, I kind of have, like, bills and stuff. Developers got to eat. Linux.entropy.works. Use promo code LUB13 and save 15%. Entropy is an industry-leading mobile and web development studio based in the UK. They have global clients, including Mars Wrigley, Walmart, Mediacom, the Financial Times. I mean, they're trusted by some of the biggest names in media content, but Entropy isn't necessarily all about those big global corporations. They love working with

smaller businesses and startups. They just, they love to realize really outstanding apps. That's, that's it. And web applications too. I'm talking mobile, desktop, the web. Entropy runs on Linux and they're a bunch of Linux nerds. They have distro hoppers in their office. They love to geek out on Linux hardware. It's why they reached out to me because they're listeners of the show. They're part of our community.

And they use Ruby and they use Ruby on Rails for web applications and more and more that Flutter. Flutter for mobile desktop and for web apps. And that also, by the way, includes the Linux desktop. They have pioneered some of the most complex Flutter apps out there. The new Flutter reality is here. They've baked in image recognition and machine learning into some apps they're launching globally for Mars. You know, with Flutter, Entropy can just rapidly build an iOS app, an Android app,

and a Windows app, a macOS app, and yes, of course, a Linux app. And they can really do it in no time. You know, they're already really one of the global leaders in Flutter development. They have dozens of deployments in the last year alone. So if you're thinking about taking the plunge into Flutter for a Linux desktop app, and you want to hit other platforms as well, maybe you're a small business, a large business, a startup, just kind of getting going. But you just want to get an outstanding app on a number of platforms. Entropy is ready to chat. They love to discuss ideas and, of course, love to share their opinions. And regardless if you want to move forward with a project or maybe you just kind of want to get your head wrapped around some of this stuff,

get an idea of what this looks like. Maybe you just want to discuss your favorite distro. Entropy would love to chat. So to get started, they're offering listeners of Linux Unplugged 15% off their first project. This is a great way to take the plunge. What an opportunity. And you're supporting a member of our community.

You're shopping locally within the Linux community. So just head to linux.entropy.works and fill out one of their contact forms, but cite the promo code LUP13, and then they'll get in touch and they'll get started. And there's never any pressure. They're always just happy to discuss your project and help in any way they can. That's linux.entropy.works, promo code LUP13. That's linux.entropy.works. Promo code LUP13. Since our chat with Ethan, we've thought a lot about some of the points he brought up,

and we're very glad he raised them. I think this is a discussion that it's good for the community to have. We're in a sort of weird point in Linux gaming, and frankly, it's pretty tough to hear the troubles he's facing. I mean, he's made a lot of great games. He's doing really good and important and just neat work. It does kind of make sense. I can understand how Proton getting as good as it is has eaten up a lot of the air that used to exist here. Ethan mentioned not wanting to become a wine developer. And I get that, right? That's not why he got into this space. It's not what is exciting. Right. But at the same time, I don't know, it sort of seems, and I don't like saying it, but

sort of seems that if you want to be involved in the future of Linux gaming, at least as it stands right now, maybe you have to embrace Pivot to Proton. Okay, I think we could talk more about that, but I see where you're going. In some ways, it's sort of like Electron or Flutter at the high level where we're getting what we want, whether that's, you know, the app you need for work on the desktop or it's the game you wanted to play without having to install Windows. We're getting all that on Linux, but we're not getting it with our tools and our philosophy baked in. And I think that's a little bit of a tough pill to swallow sometimes. Yeah, and the Proton games don't necessarily have all of the functionality you want. Like sometimes they're lacking in multiplayer functionality

or currently anti-cheat functionality. But, you know, after talking with Ethan, I kind of thought I could see Valve. Valve looked at that first attempt with Steam Machines and they said, okay, what went wrong? And they went down a list and they said, well, it was pretty hard actually basing on Debian because we're doing all this work upstream, but then it takes forever to get to debian

well you know what uh it was it was pretty rough getting the games to run because we didn't have proton at that time right so compatibility was a joke and people weren't really that keen to port their games um and of course there was a a weird third-party ecosystem in there and i could see them looking at this going that was a failure and what i could see them doing now when they take more of a console look at it a handheld console look is i could see the focus on proton being a way to prevent failure like it's this it's this insurance layer it's this middle layer that they can guarantee that's going to work and that it'll work across any third-party maker of a deck as well.

And they could just say, you know, we looked at going native, but guys like Ethan, they only scale so far, there's only so many developers in the world, and we want all game compatibility. We don't want just the native games. And you can see how from a business case, too, right, this sort of keeps it under their own control, where it's like, well, this

is our layer, we can guarantee that you'll have these API endpoints and not, yeah, you know, we'd really like you to target native Linux, here's a list of some people you could try and work with to get there. I mean, that would be great to see, and I think that could still be part of the option, but you can see how that wouldn't maybe be enough for Valve's big push here.

And I think the other thing too, since they launched the Steam machines, is Vulkan didn't become like this universal across all platforms standard that we hoped. It definitely is great. But DirectX has really continued to thrive in the Microsoft ecosystem. And that is a massive reality of the marketplace. And I think this isn't the same thing as Steam machines. These are not Steam machines 2.0.

And I think there's probably a few key reasons for that. These are not Steam Machines 2.0, and I think there's probably a few key reasons for that. Number one, Steam Machines were really just entirely a third-party hardware thing, that the makers really just didn't make much money. There was like a bad incentive structure there. Additionally, Steam Input, it was a baby compared to where it's at now. Third-party controllers were nowhere where they're at now, and it didn't really kind of work for the demo because just about everybody who had a big Steam library that would find value in a Steam machine already had a gaming PC.

And then Valve very quickly cut their legs out underneath the Steam machine by coming up with the Steam Link, which just took your already existing expensive PC and made it work on your TV. And gamers already had Xboxes. Proton wasn't a thing, so there wasn't really this Linux compatibility story. And they just failed. It just was a flop.

And I think that flop was a harder pill to swallow. And now they look at the market in probably a much more practical, we're just going to fix base OS problems. And you can hear this in their interviews, like with IGN. The way they talk about it is, well, we to fix base OS problems. And you can hear this in their interviews, like with IGN. The way they talk about it is, well, we solved some core OS problems, and then we built up

this Proton layer as a middle layer, and now we're shipping the deck. And they don't think about it in terms of native games. They just think about it as a game runtime environment that includes all of the Steam bits, including their super old Ubuntu base.

Right, yeah. Really, it's a hodgepodge of magic stuff to make games play at the end of the day. All right, so let's get into our first email of the day. Gabe writes in, hey Chris and Wes, Valve called you up and asked you for some top tips on how to successfully ship Arch on the new Steam Deck, what might you advise them to do? Ah, based on all of our pro experience of course with our server, I assume. Head up time, baby. Yeah, well, number one, Gabe, is don't wait about

six months between updates. Don't do that. But in all seriousness, how would you ship Arch on a mass consumer device? Yeah, I mean, you're gonna need to introduce some kind of control, whether that's image-based or something more like Manjaro, where you have your own repos that you're maintaining, and you can sort of keep packages at a stable place. That's my bet. I don't think that's the solution I'd prefer, but I think that's the solution they're going to go with. Well, because

you need some level of curation, right? Just for QA purposes, at least. Yeah, and you don't want weird libraries coming down, breaking things and whatnot. So I think that would be one of them. I think you've got to also do a minimum viable Linux install. That's one of the things we did on our server. Minimum viable Linux install, and I'm going to say it, I think they should use ButterFS on the root file system.

Oh, going bold with this one. You need something that has low resource impact. You need something that works well on a single SSD. And it'd be great to have something that supports snapshots. Right. So that even if you might have some sort of arch breakage, you can be somewhat guaranteed you can just reboot back into a snapshot. What about the kernel? Because if you go LTS kernel,

you're not necessarily going to have all the hardware support you need, possibly. You know, that might be one spot where they're just going to compile it themselves, I wonder. You know, maybe you're trying to tweak things for performance or otherwise, or they just want the latest and greatest. Does anyone in the Mumble room have a hot tip for Valve on how to ship this thing in a way that's usable by consumers? I guess I'll have the hot tip.

And I'm going to say the most probably traumatic slash controversial statement. Fork the entire package set, because when you're working with delivering a product, you need to be able to have testable checkpoints. And the easiest way to do that when you're building a full scale product, soup to nuts, where you have both you're controlling the kernel, full-scale products, soup to nuts, where you have both your controlling the kernel, as well as going all the way up to things like the user space, the desktop, and fiddly bits here and there, is branch the entire distribution, filter out what you don't need, build it, integrate it, and release it on your own schedule. Because that way you can ensure consistent quality, and you can work around the underlying faults in the software management stack to make sure that upgrades are not going to be painful.

Because in a traditional Arch setup, it is fairly common for people to have to manually work through upgrades, especially with more invasive things or stuff where like library switching happens and things like that. So those are things that are not acceptable for a product. And in order to mitigate that, you need to take the whole thing into your hands and deal with it. Dan, you have a lot of experience about shipping Arch on mobile devices for Manjaro. Do you have any thoughts? Not other than it's hard to get a kernel just right. So you need to compile that yourself if you want to actually get it working for the device you're shipping it on. Sure, so you agree with Wes,

we're probably going to see a custom kernel on this thing? Yeah, yeah, I do. Yeah, that wouldn't be too surprising. They were already doing that for the Debian Steam OS for what it's worth. Ah, fair point. Yeah, fair point. Additionally, they already have an Arch repo with their own custom kernel, a patch kernel, with its Linux F-Sync, fair point. Additionally, they already have an Arch repo with their own custom kernel,

a patch kernel with its Linux F-Sync, I think. Right. They originally created it for shipping the Mesa ACO stuff that they were working on. I think it was, what, a year ago, two years ago, three years ago. I forget exactly when, but when they were first working with Red Hat on the ACO Vulcan stuff for AMD on Mesa, they created this AUR repository to ship it. I shouldn't call it an AUR repository. That's not what it is. It's an Arch Pac-Man repository. And they created it so that they could ship it to people to test it and use it. It's being reused for everything else, but hey, that's where it started from.

And as far as the reliance on Proton, it definitely seems like a concern, especially if GameShop see it as just like a super easy button to get stack support. Or if that's all they're willing to do as well, you know?

That's all we care about. It doesn't matter that it doesn't run on your other Linux over here. We weren't going for Linux support. We were going to click the box to go on the deck. But doesn't that long term undermine Valve because they essentially become reliant on DirectX and Microsoft's gaming platform, which is in direct competition with them? So doesn't long term Proton kind of undermine Valve's? Because they could become wholly reliant on their competitor. Yeah, do they develop, you know, push their own sort of alternatives? Or does Proton evolve as it needs to and at some point maybe split off from some of its space?

It seemed like the way Ethan characterized some of the responses from Valve, that potentially Valve is just pitching this as a transition technology. But I think Ethan's response to that was, yeah, but it'll become permanent. Like, that temporary solution will become the permanent solution. It just works, you know, good enough. Yeah, but Valve could be creating themselves a new cage by becoming so

dependent on DirectX. I'll leave it, you know, I want to say a note about this. Like, when we're talking about Proton versus native Linux, I want to just a note about this. When we're talking about Proton versus native Linux, I want to just say something, a particular quote. A better Windows than Windows and a better DOS than DOS. The operating system that used that slogan is no longer with us because emphasizing that point made it so difficult to convince people to build for that platform

that it couldn't survive when more investment was required to make it successful. And that platform was IBM's Operating System 2, or OS2. Yep, yep, good point. All right, well, we've got some more feedback. Mark has a distro that Chris and Young Wesley

might like to kick the tires of. That one made me chuckle, Young Wesley. Love it, and thank you. Yes. So this is MoFo Linux. Linux designed to defeat state censorship and surveillance. Yeah, I meant to give this a go this morning, but then I got distracted with all of the tech stuff.

But MoFo Linux is like fight the man with Linux, and it's at mofolinux.com, and it is, well, it's a unique website. I'll give it that. It pitches itself as having a few things out of the box that make it more secure, like encrypted DNS over TLS that has OpenVPN and Tor set up ready to go, and a bunch of software tools that are meant to anonymize

your use of the internet. They want to be pretty clear about this. This is not simply an Ubuntu ISO with crypto and VPN applications added. The system has been stripped, de-bloated and optimized to help you break out and access the global internet.

I love it when somebody uses a base distro and then craps on it by saying like we've de-bloated it. Well, why'd you pick a bloated distro to begin with there, Hotshot? And like, why you got to crap on the people that made your distro possible as you're building your distro? But either way, it definitely is a distribution with attitude.

And so I wanted to kick the tires before the show, but then that chance to chat with Ethan came up. But, you know, they pitch it as something you could boot on a live environment, so it'd be pretty easy to try it out. So I might give it a go after. Yeah, something to thrill for a future episode, perhaps. And I love the name, right? I mean, MoFo Linux, that's pretty great.

Matt writes in, I was wondering if y'all could recommend a VPN device that had a Linux client or service. We use Checkpoint Firewalls, and it doesn't have a Linux client. We have to use Windows. So any recommendations would be great. I've recently just started listening to the podcast and enjoy learning about Linux and various distros. Thanks, Matt.

Wes, I know we both are in a long-term committed relationship to WireGuard. Yeah, true. And we shall never stray. But do you have any VPNs on the side? Well, I have some VPNs I use just for connecting out when I want to not be geo-blocked by things or if I'm traveling and the hotel has sort of sketchy Wi-Fi, things like that. So, yeah, I do rely on some third-party VPN services from time to time,

some of which now have WireGuard, which is very nice to see. But, of course, they all have OpenVPN, too. Do you have one you recommend? I've been using TorGuard, but really that's just because I paid for some discounted multi-year account ages ago. And, you know, they've, I know some folks are really picky and rightfully so about like, how good is their policy around their logging? And, you know, are there, is there evidence around, has that come up in court before? And those are all good things. I just, I don't use it for that kind of stuff. It's not my, it's

casual security layer that I just layer on top to get around whatever local network I'm on. But they have a Linux client. They publish just OVPN config files. They've added WireGuard support to just about all their servers. So I've had no reason to switch. That's the two things. If they have WireGuard support, great.

If they don't, if they have OpenVPN, if they can just provide you a config file, you can just use Network Manager. Provado VPN, they've been a sponsor on SSH before, on self-hosted, so disclaimer. But I really like Provado because they have a free tier that pretty much lets you do everything you want. And then if you want to get into like peer-to-peer software and that kind of stuff, they have a paid tier that works for that. So that's Provado VPN. And then I also have a NordVPN account that I use for content bypassing because they have an Android TV app. But I was just on this week's Destination Linux podcast, episode 235. And VPNs that work with Linux was one of the topics we kicked around,

as well as we all chimed in on the Steam Deck, of course. So I got a chance to hang out with my buddies. It's been a while. And that's episode 235, which we will have linked in the show notes for that. All right. So we just have a couple of emails about Rocky Linux, and then we're going to wrap up the feedback. Wes, do you want to take the first one? Yeah, Morgan writes in. Hey, all.

Linux HPC sysadmin here. That's high-performance computing, if you're not familiar. Just wanted to tip you off as to where I see academic HPC systems going. I know of two Ivy League schools that have effectively decided on Rocky Linux as their CentOS replacement for some or maybe all of their research computing clusters. These can be some pretty big clusters. Can't share details, but we, the academic HPC industry, kind of all been waiting to see where CERN went

after the CentOS announcement. They've been very slow, likely waiting on the Rocky release before deciding between Alma and Rocky. Unfortunately for the discussions I've been in, Rocky always has a leg up. Though I think this might just have been some name recognition. Think CentOS co-founder. I don't make the rules. I simply live comfortably beneath them.

It's amazing the mileage that story gets, isn't it? It really is. Anyway, I just figured it was worth mentioning that thousands of our servers will most likely move to whatever CERN ends up switching to. Something to watch. Yeah, so this is a really fascinating moment we are in because we have a clock. There's a countdown. We have until the end of December for the people that are just diehard traditional CentOS release model. They have to make a choice. And that's hard, right, where we've talked so much that really what's going to help you

make a choice is going to be way down the road at this point. Right. It's like these distributions, this enterprise thing, it's a long-term thing. Like we won't know for a few years which is really the best contender. And right now they're technically very similar. So what you end up having to kind of go by is all of the stuff that surrounds the distribution, like the engineers or the foundation behind it or the structure of the company or whatever. And that is sort of all we have right now. Crystal writes in, she says, I was struck

by the chat with Jack from Alma Linux. It seemed like a lot was covered that Rocky Linux would want to respond to. I know you mentioned you invited them on the show, but what happened with that? Keep up the great work and thanks for helping those of us trying to choose between Rocky and Alma Linux. So we did. We did invite Greg and the community manager from Rocky Linux on the show via email. In fact, we even held our chat with Jack for a week. So that way we had we gave them a week to answer the email. Instead of answering the email, though, they did show up in the IRC chat during the live show a couple of weeks ago.

It started pretty good. We linked the log in the last week's episode, if you're interested. And then it kind of slid downhill. It kind of got a little rough. I think it's a real shame that Rocky Linux chose not to come on the show. I'll read you the email they sent me. I think it's a little disingenuous and I'll link the full email in the show notes. But in here, Stack writes, the Rocky team talked afterwards. This is after the little IRC incident that happened during our live show. He says,

the Rocky team talked afterwards. We're going to attempt to further disassociate comparisons between Rocky and others, like all Malinics, which right there, that's such crap. I mean, I hate to say this, but like that's what everybody's doing right now. People want to know which one to go with. That's the very focus right now is comparing the two. Stack goes on to say,

because Greg couldn't be bothered to write the email the two. Stack goes on to say, because Greg couldn't be bothered to write the email himself, but Stack goes on to say, we just don't feel like it's helpful to contrast and compare when the goal for most of these projects is to be one-to-one with Upstream and provide awesome community support. We would rather be in a position to lift Rocky and the community and others, like Alma, lift them up, and then try to make ourselves out to be something better than

we are. And so because that is their goal, they just couldn't make it to come on the show and respond to us. And unfortunately, all I really have is my personal experience and interactions with Greg and the team, which is I went out of my way to contact them and try to get them involved. a team, which is I went out of my way to contact them and try to get them involved. It felt like for a brief moment, we had an opportunity for an impartial body to be a bridge that creates a community of enterprise distros. And that really seemed like that seemed like something new and special. I was really excited about that. But the conversations that we had and the way that things went down in the IRC, I made

it clear that wasn't going to happen. And instead of extending that bridge, in my opinion, Greg proactively went to the register and got a softball interview where he claims to have seen the light and seen the way on how all of this works now. He now understands the genius behind CentOS Stream. And the last bit to help connect all the dots was neil it was neil in our chat room he shook sense into greg and now he's seen the light of course it wasn't the entire

conversation that we had with jack because you'd never want to give all my any credit it wasn't the points brought up in the chat room i mean neil deserves all the credit in the world he works his ass off but let's be frank these are all things that Greg already knew. And then instead of coming on the show, he went and got a softball interview at the register a few days before our episode came out. And he knew it was coming out because I had the courtesy of giving him a heads up over email. And that's just my personal experience with the guy. And what I saw was a lot of show and not an actual lot of delivery there. And what I see, and just in my personal experience, what I see is I see Jack from Amalynx in our Mumble room right now.

You know, he doesn't have access to our show notes. He doesn't know what we're talking about. But I see somebody from Amalynx showing up to be part of the conversation. And I can tell you this, having been creating Linux content for 13 years now, I can tell you that the projects that show up and participate at this level

that have this kind of passion always sort of have the morality and the compass that agrees with my personal tastes and my moralities. They tend to be people that are truly in it for the greater good. They want to be communicative with the community so that way they can convey their ideas

and try to get acceptance at every level and try to reach at the grassroots level of the community, which is how you have to get a conversation like this started. The people that get that, they get the way free software works. They get the way that working within the free software, the dynamics of that. And those are the projects that tend to be in it for the right reasons for the long term. tend to be in it for the right reasons for the long term. And in my estimation right now, without much more to go on, I've had a pretty gross interaction with the Rocky Linux folks. And then the actions I saw them take afterwards and the words that they used to try to convince me

why they're not coming on the show felt very manipulative. All in my opinion, of course. And what I've seen from AmoLinux is a track record that already exists for 10 years. Engineers on staff that seem like they could very likely actually contribute upstream to CentOS stream, which means they could actually make an impact on RHEL, which is an opportunity we have never seen before.

And they've already delivered on their promises so far. And we have their community manager in our room right now here to interact with the community, which, in my my opinion is just crushing it because it's an open room. Anybody can say anything and he's right there, right? There's no buffer and that takes guts and that takes commitment. And I was willing to roll out the red carpet for Greg and have a nice civil chat. You guys know me, you know how my interview style is, you know how I roll, But that's not where it ended up.

So you make your own decisions out there. You all have to do that. But I don't think we'll be deploying any rocky Linux servers. I find it very disappointing. Coming on the show would have just been a great opportunity. You know, it could have been a great opportunity to say, yeah, some heads were budding early on, but you know, we're moving on now. But it didn't happen. It is what it is. I agree with Johnny Hughes. He's a CentOS project developer and a board member. He says go with Alma Linux. I agree with Johnny. Well, with that out of the way, we better clean up in here. So I heard there was quite the virtual lug this Sunday. Yeah, of course, there's always a great virtual lug on Sunday. It's just that we don't always make it. But you did. Of course I did.

Well, we got lean done early. So I had a little spot of free time on Sunday. After working out some issues, you know, I was using a different system where I'd compiled Pipewire from source, and I also had Mumble installed from a flat pack, and it took a little bit

to get going. That doesn't have to be your experience, though. If you just get Mumble set up and don't mess around with your own custom audio setup, you'll be fine. It's easy. And there's a lot of folks there, like MiniMac, who are ready to help you out, which is amazing. That's true. And then your Mumble's all good to go in case you can make it on a Tuesday. Right.

You know, playing hooky, you want to come hang out with your Linux buddies on a Tuesday. We do this show every Tuesday that we can until we're on the road, and then maybe it gets weird. I don't know. But we'd love to get your feedback. We're going to try to integrate that more while we're on the road and just get some conversations going. So linuxunplugged.com slash contact. It's open feedback season for the rest of the summer.

Go fill our inbox. Also, our Telegram group has had some really great conversations going recently. Like I've been popping in there and having some great chats. So check that out. The conversation is going all the time at jupiterbroadcasting.com slash telegram. And then last but not least, got to plug that meetup page because those meetups are getting close and I want you to remember it. So I say it multiple times now, meetup.com slash jupiterbroadcasting.

All right, we have a pick that's kind of special. It's like Wireshark, but not. Yeah, it's called Hotwire, and it's a GTK application. Yeah, that's right, no electron here. Now, it does leverage a lot of the Wireshark and T-Shark infrastructure to capture traffic and explore the contents, but it's really aimed at displaying a subset of that data and a subset of all the crazy protocols that Wireshark supports in a focused way.

It looks really, really good. But there's one thing missing, Wes. Can you spice it up a little bit for me? It's written in Rust. And there's one aspect of this that is super cool. Hotwire can open TCP dump files and record traffic through a FIFO file, which basically means you don't need escalated or special root privileges to monitor traffic. It's just smart to think about this because the way I got it installed was through Flatpak. And, you know, in modern sort of more secure Linux apps,

you might not want to give some random app pseudo access to capture from your wireless card or something. And so this is sort of set up in a way where you can go run that dump on your own and pipe it in. Wow, a network capture tool via Flatpak. That is the new era right there. It's early days, currently only supports Postgres, HTTP, and HTTP2. But if you're working with one of those, it could be pretty handy. Well, I'm out. I'm out. Instead, I'm going to recommend Rust Scan.

Yes, another Rust port scanner. It's too much. The whole world is getting rusty. And this one is modern, it's fast, and this one has the exciting tagline that it can scan all 65,000 ports in three seconds, which is really what got my attention. I was all in when I saw that. And, of course, it's in the AUR.

It's also in Homebrew. And as Wes will tell you, it's also available via Docker. That's right. A little secret tip here. If you try it out, you'll see it throws a little shade at nmap2 once it runs. So that's fun. Oh, man. Well, I mean, 65,000 ports

in three seconds is actually legitimately impressive. I can't even really conceive how it's technically possible. All the CPU cores, I suppose. It's the power of Rust. Yeah, I guess. Rust can do anything. If you're into the Twitter thing, you can follow this here show.

We are at Linux Unplugged. The network is at JupiterSignal. It's a great way to get show announcements or news or send us some feedback. You can do it that way. Of course, we have that contact page. That's the canonical way. No, not that canonical,

but like the official way. LinuxUnplugged.com slash contact. Now, there's only two more episodes left in studio. So do try to join us live. Make it a only two more episodes left in studio. So do try to join us live. Make it a Linux Tuesday. See you next week. Same bad time.

Same bad station. That's right. That's noon Pacific, 3 p.m. Eastern over at JBLive.tv. JupiterBroadcasting.com slash calendar for your local time. If you want a full breakdown of the Steam Deck announcement and our analysis, check out Linux Action News.

There's a lot packed in there, including some very interesting news that we just don't have time in the Unplugged program. But I wish we did. Wish we did. Maybe one day. Maybe we'll do three Unplugs a week one day. Mwahaha! Only you can make it possible by becoming a member.

UnpluggedCore.com Three episodes a week. Trust meuggedCore.com. Three episodes a week. Trust me, you don't want that. I don't want that. No. Thanks for joining us. We'll see you right back here next Tuesday! I think something that doesn't get talked about with the whole AmoLinux and RockyLinux and CentOS Stream is this market that these distributions serve is fundamental to how Linux makes money.

Like, the desktop isn't what gets a lot of contributions to Linux. I mean, it absolutely does, but when you look at, like, big money contributions and percentages, it's of contributions to Linux. I mean, it absolutely does. But when you look at like big money contributions and percentages, it's companies contributing to Linux to get their hardware enablement support or to get something working for their device stack that's in the enterprise.

It's so server focused. It's like the desktop market doesn't even exist, right? When you look at how Linux makes money. And so when you take these distributions like Rocky and Alma, they are serving a market that screws with how Linux makes money. And so when you take these distributions like Rocky and Alma, they are serving a market that screws with how Linux can survive. And so if one of them goes sideways, and I just think, you know, I look at cloud Linux was around for 10 years, right? But if one of these go sideways, the damage to Linux's reputation, these free distros, these quote unquote

free distros, you just can't trust them. You could see how a narrative like that could take off like wildfire. So the actual like what's at stake here is fairly significant when you consider this is what makes Linux relevant in the marketplace is this category that these distributions are serving. And people have just a few months left to start making their decisions. Right. So that's why when you say, oh, we don't want to make a comparison. It's just ludicrous. People are making the, yeah, you may not want to, but people are and sort of have to. It's vital right now. And the stakes couldn't be higher. So like, we really got to figure this out because we could tank Linux's reputation in this category. I wonder how many folks are testing out multiple, you know, sort of,

I'd hope that at least at first especially that the delta would be not too large. So even if you did sort of go with one, try it all out, you know, if you needed

to, if there was some strange bug or something, you could pivot. But what are the differences going to be? Yeah, hopefully it's

hard to screw up in a meaningful way. You spin them up and you can hardly even tell really once you're past the login screen. I mean, you can hardly even tell.

And I think that's a burden load that a lot of people are going to look at and go, well, let's just go with stream. I mean, I think a lot of people are going to consider that. I would. That's what I would want to do. Yeah, I mean, it's coming, you know. Before we get out of here,

I didn't want to talk about it in the main show, but I do want to bring awareness to this problem. The head of strategy for the Muse group seems to be threatening a developer of one of the Audacity forks with thinly veiled threats about contacting the government and getting his citizenship revoked and things like that. Not Audacity, the fork of what's the other program? Oh, MuseScore. Yes, it was downloading some assets from there. It's a fork of MuseScore, thank you. Yeah, so that was LibraScore, I think is what it's called.

I forget the name of it, but yeah, I was horrified when I saw that. When I saw that, it's like he tried to cover it up by editing the message, but he clearly forgot that GitHub actually archives all versions of comments in threads. So the original one was still there and it was absolutely horrific because he's basically blackmailing the dude like without actually going out right and saying it it basically was it was bad that was some serious mafia shit man to go after someone like that and basically threaten him with like deportation back to China. That was not nice.

A public forum, no less. Yeah. On GitHub. One thing is a threatening email or something, but like, geez, but also like implied that,

you know, we know that if this happens, you won't be long for this world. It's like, what kind of crap is going on here?