LINUX Unplugged - 392: Dad's Deployments

Episode Date: February 10, 2021

Which distro is best for friends and family? We have a unique take on this common question. Plus new insights into the future of CentOS, and Chris falls in love with a 14-inch screamer. Special Guest: Carl George.

Well, I got a kind of a just your experience style question before we start. Do you guys think that the LTSs are actually any more stable than a regular distro for daily use? Are you talking daily use as a desktop or are we talking on the server? Definitely desktop. I don't know. I mean, not really. I've seen this going around our Linux and the author says, from my experience, LTS releases are not more stable to justify the old packages than the regular ones. It's like, is it worth the trade-off?

I think the real trade-off here is that it's the IT team, you know. I get to support this the whole time. I don't have a bunch of different users on a bunch of different desktop versions. But for the individual admin, no. I mean, just keep up with the latest. Yeah, I think, too, it's like, what do you consider stable? Is it that the desktop environment doesn't change very often? Is it an ABI that you can write code against that doesn't change? Or is it a program crashing? Because software has bugs regardless. And an LTS version of software could have a bug.

It's the bugs you know versus the bugs you don't. Right. I think the question is, what kind of stable do you want? Step up. We have a kind for every type. It's the bugs you know for the cloud, Linux, and other modern tech skills. Hundreds of courses, thousands of hands-on labs, get certified, get hired, get learning. ACloudGuru.com. Welcome into 392. We have a lot going on in today's episode.

We're going to get into something kind of personal for me. I'll talk about that in a little bit and kind of try to get into something kind of personal for me. I'll talk about that in a little bit and kind of try to get some advice on a decision that I need to make from Wes and our virtual lug. We'll have some community news and kind of an exciting Jupyter Broadcasting announcement is going to be tucked in here as well. So there's a lot to get into. Quick question, though. That advice, that's going to be binding, right? We get to tell you what to do?

Yes. Perfect. Yes. Let's go with yes, though. That advice, that's going to be binding, right? We get to tell you what to do? Um, yes. Perfect. Yes, let's go with yes, Wes. Let's go with yes. We might need some help if we're making that kind of decision. I just feel like those are like pre-show discussions, Wes, not middle of intro discussion. But for the sake of show, I'm going to go with it. I'm going to do it, Wes. I mean, you've stepped up and done live Arch updates right here on the air, so I'll step up and say yes. But before we can get to any of that, we've got to bring in our virtual lug. Time-appropriate greetings, Mumble Room.

Hello, hello. Hello. Hello, Wes. Hello. I want you to know that I just gave you a personal drumroll on my lap, so you have that visual now. Let's get into the news. And let's start with at least a little bit of something that came out of FOSDEM this week. So FOSDEM is this ginormous open source event that goes on. And this year, like so many others, it had to go virtual. Their videos are trickling out online and will possibly have more coverage in the future. But there was a CentOS Dojo at

Fosdum. I like the name, so it got my attention. And in there, we got some questions answered. And we got some questions that are sort of awkward and left unanswered. This was the CentOS Virtual Dojo that featured several board members from CentOS, and I thought we'd go through a couple of their answers. I'll link to the entire video if you're interested in the show notes at linuxunplugged.com slash 392.

But I got a couple of moments for you here. During this dojo, there was a couple of individuals you're going to be hearing in these clips that answered some questions from people that were watching live. And I want to say right up front, it seems like they answered every kind of question that came at them, even the uncomfortable ones, and answered to the best of their ability right there live. And that's never, that's never really necessarily an easy thing to do. And so in these clips that I'm going to play from you, you're going to hear from a couple of

individuals. You're going to hear from, and Carl, if you know better, please correct me, but you're going to hear from Brian Excelbert. Do you know how to say his last name, Carl? Excelbert. Everyone just calls him Bex, though. B-E-X. Bex. Yep. I was going to say, you may know him as Bex. He is the Red Hat liaison to CentOS, and he is a CentOS board member himself. And he is tossing the question over to Pat Reshecki. Again, Carl, please correct if I'm wrong. That one I'm not sure about. I know him as JCPunk in IRC, so. Yep, he goes by JCPunk online. He has been helping with CentOS officially since

2008 and really unofficially for longer. He works at the Fermi National Accelerator Laboratory. He is part of the scientific Linux team, and he himself has been a CentOS board member since April of 2020. So we have Brian asking the question and Pat answering. And the first question that I want to play for you guys is a simple one. Is CentOS Stream safe for production use? If I can, the next question that I would pull out is here, which is, I'm concerned about the stability of using Stream in production compared to what I used to do now due to the, and I'm going to change the words here, continuously deliberate nature of Stream.

Can you give me a take on why I should or should not be concerned here? The packages that go into Stream have gone through the internal qa before they land in stream so they should be as safe as when they land in actual rel but most importantly is part of what we're trying to aim for with stream is to increase the amount of internal testing and so if you've got something that needs a test, we can try and get that into the RPM so that it is self-tested and get it into the upstream code base that the actual software is based on to get more internal testing that will not only improve the overall quality of stream, it will improve the quality of the upstream software that we're packaging. And so if you're concerned about testing,

I would encourage you to help us build tests to ensure that this software runs beautifully, not just on stream and not just on RHEL, but for everyone in the open source community. The more tests that we can get into upstream codebases, the better the quality will be for everyone worldwide who uses it, no matter who your platform is. And now Brian quickly adds to that.

It's not like they're just YOLOing the packages in the CentOS. The other piece is that Red Hat engineers are not allowed to commit code to CentOS Stream that is work in progress. It is expected to be finished code. So to reiterate what Pat said, we're not putting things like YOLO. It is expected to be finished code. So to reiterate what Pat said, we're not putting, you know, things like YOLO, like it has to actually be ready. It has to go through a level of acceptance testing. The other piece is that Red Hat engineers are not allowed

to commit code to CentOS stream that is work in progress. It is expected to be finished code. So to reiterate what Pat said, we're not putting, you know, things like YOLO, like it has to actually be ready. It has to go through a level of acceptance testing and criteria. So it's a little bit of a mixed answer here. It is, we're going to be testing these packages. We're going to run them through what we currently do in our QA testing. But at the same time, the answer seems to be, well, if you want it to work, write the code. But in this case, the code's tests. I think that might be part of the switch. You know, there's some quote here that, you know, before they kind of just built whatever came out of the Red Hat process, you know, okay, you get the source files, you build them up and ship them in CentOS. I think maybe

some of the part of that is that this is now meant to be more of a collaborative upstream. So like, if you're not sure, if you're worried about this new addition, part of that you can help out by making sure that it is properly tested, that you can say, I need more guarantees on this package and I'm going to help add them, which you didn't really have necessarily an option to do in the old process.

Carl, I feel like maybe some of this is just confusion around the CentOS project using rolling differently than the rest of us use it. Definitely. That was when CentOS Stream 8 was first announced, it was marketed as a rolling release and kind of tried to co-opt the term, I guess, would be the way to look at it. But it's not really rolling.

It's rolling in the sense of a major rail release. So there's no like 8.1, 8.2, but it's not rolling release like you would think of Arch or Fedora or Rawhide. It's not the same thing. I think when you understand that and you understand that every package that's landing

in CentOS Stream goes through the RHEL QA process and RHEL testing, and that they have this mindset that every package that will land in stream is stable right in a lot of ways that's true because it's kind of getting it's getting field tested in fedora then it gets promoted up to the red hat rel developers and then they submit it up to stream or whoever else is submitting up to stream i mean it has gone through multiple layers before it ever hit stream.

And like Carl so perfectly said, it's rolling within the context of RHEL, right? So you're maybe a point release ahead. And not just RHEL, a major version of RHEL, right? Like there can be major changes between like RHEL 8 and RHEL 9, but any changes that are proposed for CentOS Stream, like they're the changes that you would see within Roll8's lifetime. So things that wouldn't change like the GLibc version or the OpenSSL version, or at least not change often, that's the kind of changes that you wouldn't see in Stream at all. And I think when people start to wrap their heads around this,

they're going to realize CentOS Stream is probably a more stable, more production-ready distro than most things out there. And if you're comfortable with the way Debian operates in terms of their updates, and you consider that to be a stable enterprise distro, well, then Stream is going to be that, plus more QA and more testing, and the entire Fedora distribution doing preliminary deployments in actual public hands. That's a pretty hard thing to match there. And the question really becomes, well, okay, let's say we all wrap our head around Stream, and we're getting comfortable with it. We recognize that now there is a way for just the average citizen to commit something that could land in RHEL. It brings RHEL development out into the open, but still provides system administrators with something that can be used

in production. Okay. All right. I can start to live with this new normal, but there is an elephant in the room. And it's quite simply, if the deal was changed on us once, what means the deal can't be changed again? And my buddyah puts it really well when he says you end up feeling like you're living on borrowed time and this question came up during the q a and to their credit they actually answered it they answered it and it's not an easy question to answer because the deal was changed on them the sent CentOS board members. And you can sense the tension and the uncertainty in the room by how long it actually takes someone to step up and answer the question. A question has come in about the change of the end of the EOL for a community deliverable during a release being very unusual. Is this something that could theoretically happen in the future from your perspective?

I haven't altered this at all. This is the real time that there was just people looking at each other, not sure how to answer this question. I mean, it's hard to predict the future, but fundamentally stream needs to sort of meet the needs of our development process. There needs to be a place where people can push in changes, where people can drive the release towards what they actually are doing in production. There hasn't been a great way for people to actually drive the release in the past.

And so I wouldn't expect that stream of going anywhere as it's going to be fundamental to the actual delivery process of RHEL itself. This is tricky. How do they answer a question like that? Who answers it? So you have this situation where they have to decide, do you want to handle this? No, I'll handle this. That's inherent now with virtual conferences. You've experienced that probably in meetings if you've attended some over video. You have to give them some understanding here.

But it's a hard question to answer for them because what the hell do they know? When the trademark owner decides what they're going to do and when they decide how they will fund development time, the project doesn't really have much choice other than to tuck and roll with it and make the best out of it. Now, I think the other thing to keep in mind here is we're talking about this. CentOS 8, as it is in the traditional style, it's still there. It's not gone. It hasn't gone anywhere.

It's still there until December. So we actually are dealing with this way ahead of time in some senses. It's a short amount of time when you think about migrating thousands of systems, but it's a long amount of time when you think about a company making their strategic plans public. And I appreciate that they think this is good because it sounds like by their answer here, they feel like Stream is in a position now where it's sustainable. It is in a position where it feeds the RHEL beast and also makes it a more open source project.

But I'm going to play just a little bit again. Just feel the awkwardness here. A question has come in about the change of the EOL for a community deliverable during a release being very unusual. Is this something that could theoretically happen in the future from your perspective? I mean, it's hard to predict the future. That's a little rough, Wes. That's like, they don't, you can tell,

like, they think they've got it figured out now, but they're not really in control of this piece of the game. Yeah, right. I sort of appreciate the candor, honestly. Because things change. I mean, things change even at the corporate level, right? And you do your best. I'm sure there was a lot of consternation internally about all of these changes. It's interesting how plain that silence makes it, though. Yeah. And Colonel, in some ways,

they are being more explicit about their plans around Stream than they really were about the long-term support window for 8. Yeah. So one of the things that is not well understood or I haven't heard talked about a lot is that while the EOL was listed on the CentOS page and that is a Red Hat project and therefore falls to Red Hat, that EOL was not actually put there by Red Hat. It was put there by a community user who assumed, based on other past EOLs, that that's what the EOL is going to be. Red Hat itself never actually officially said what the EOL-48 was going to be. And Carl could probably speak to this better than I can, but that's one thing that I haven't heard discussed a lot,

is that Red Hat never actually came out and said, this is the EOL for 8. They passively endorsed that EOL by not changing it and allowing it to go onto the site, but that was done by the community, not RHEL or Red Hat. Yeah, and I think that doesn't get talked about a lot because, I'll be quite frank in my personal opinion, it's a piss poor excuse because I think the internal mentality by not listing,

not putting that EOL date up front was, well, we're not sure how long we're going to keep doing CentOS Linux 8.4, so we just won't put an EOL date. When in reality, in hindsight, it's easy to say you should have absolutely said this isn't going to be supported for the full 10 years, or even better, set an end-of-life date then. Just leaving it blank and then having a community member make a reasonable assumption that based on everything that's happened before with CentOS, that that should have been the end of life date. Yeah, it was just a very unfortunate chain of events. Well, I kind of look at it as a collection of could have done betters. It's like a basket of

could have done's. Number one is clarify ahead of time what the support window was, or at least update that wiki post. Number two, if I were at some position of power in Red Hat, what I would have done is I would have released the REL for Developers program, the expanded REL for Developers program first, or that would have been the headline, and in there I would have said, by the way, CentOS is changing.

That's how I would have managed the message myself. But what do I know? I just talked to an audience of tens of changing. That's how I would have managed the message myself. But, you know, what do I know? I just talked to an audience of tens of thousands. I obviously don't know what I'm talking about. And then the other thing that I would have tweaked is I would have made real damn sure that Stream wasn't sold as a rolling distribution. Because when you say rolling, it conjures Arch. And when you conjure Arch, it's the antithesis of what should be on a server. And so much so that Wes and I as a bit use an Arch server here because you shouldn't be

doing it. I mean, it was a ludicrous idea and it completely was tone deaf with the market. It's unbelievable that they, a company that provides an enterprise Linux distribution, didn't get that. Incredible that it takes some stupid podcaster here in Seattle to tell them that. But if I wanted extra credit on how I would have made this a lot better, I would have set out a plan that would have already been in motion that would have demonstrated to people how a lot of what they want to accomplish on a traditional RHEL or CentOS traditional system could be accomplished with the universal base image that is based on RHEL. It's a container that you can run your application inside, kind of like how you can use Alpine as a base for a container.

You could use the universal base image, which is RHEL, supported by these people at Red Hat. And you can deploy your applications on Arch, if you want, inside this universal base image. So you could have CentOS stream. It could have daily updates from GitHub directly, for God's sakes. And you could still have your applications in the universal base image. And somehow, in all of this, they haven't properly communicated that. And I would put that in a basket of obvious

things that they could have done better, could have done before or with the announcement of CentOS Stream to avoid 90% of all of this. But somehow the wrong people were listening and the wrong people are making decisions. And this is what we got. And as a result, all of these alternatives have spun up. And we talked on LAN about some that are actually shipping now. We've talked about Rocky Linux, which is getting really close and has a ton of community momentum around it. So you have to kind of wonder, how does the core CentOS team, and particularly the board members, feel about all of these clones coming along to offer what they used to offer. And Pat says they welcome it. And just to sort of be clear, the folks that are interested in doing RHEL rebuilds to keep 8 alive, we wish them the best. We love our open source friends. I mean, that's really good to hear.

It doesn't sound like, do you think that's true, Carl? There's not really any ill will towards projects like Rocky Linux? Absolutely. We've even been helping here and there, pointing them in the right direction of like, hey, you should use git.sintos.org for the source code. Don't get it from source RPMs from a RHEL subscription because that's actually against the RHEL terms of service. We publish it in this other place specifically for you to use.

Use it the right way. And there's even another blog post. I'll have to find it and link it in the chat. But Bex, the same guy from the Red Hat liaison to the CentOS board, he put together a blog post of do's and don'ts for doing your own REL rebuild, basically, to help give them proper guidance. We want them to succeed, and nobody wants to get any lawyers involved for doing things incorrectly. So the more we can help them to do things right and be successful, the happier everyone will be. You know, the sense I

got by watching this Dojo video, which will be linked in the show notes, the team is kind of, I mean, correct me if I'm wrong, the team seems like they are still committed to CentOS 8 Traditional that we know and love. And this time until December is a bit of a gearing up, and things are not necessarily firm. It seems like there's some malleability here. There's some ideas that are being considered. It kind of feels like, in a way, it's not a reset, but it's a rethink for the project. And that seems like it could not a reset, but it's a rethink for the project. And that seems like it could be a positive thing long term.

What are your thoughts, though, as somebody who's in the middle of the storm right now? I think the biggest takeaway is that CentOS is transitioning, you know, execution and timing aside, it's transitioning from being downstream of RHEL to upstream of RHEL. And at a higher level, it's transitioning from being something that is, quite frankly, a conflict of interest with RHEL to something that's essential to the RHEL development pipeline. And that actually protects CentOS long-term from any kind of future, you know, management decisions around whether or not it deserves to exist. And that's one of the things that, you know, asking now, well, how do we know that CentOS Stream won't go away? That's the same as asking, how do we know Fedora won't go away?

No one's going to make you a guarantee that it won't. But if you understand how the development process actually works, you realize that that's a ridiculous question. Like it can't go away now, not easily. And it would be very difficult to change that. Yeah, that's how I see it too, which is why in a lot of ways, because I don't run a lot of CentOS traditional, I feel like it's just a great win for me because my desktop environment and desktop distro that I like, they're pretty safe and secure. They're kind of an essential part now. And CentOS 3 moves into a serious contender for me because really it's just the right kind of stable

and updates for me. It's funny too, it makes me think about how in terms of the RHEL lifecycle, the LTS lifecycle it really hasn't been that long, right? The Red Hat CentOS acquisition first changed was in 2014 which was the same year that RHEL 7 came out so it's really only been one major release cycle but it's all still been one major release cycle.

It's all still getting figured out. And if this new arrangement means that there's a healthier development community, there's more open source options for people to find the right system, there's rebuilds available for the admin who just wants a stable, free RHEL, and there's now a development community for folks like Facebook who really wanted more input

on CentOS. That's nice. It just leaves me, and I know you, Wes, with one question. All right, so then WireGuard. WireGuard. WireGuard. When do I get WireGuard? That's what I want. I want WireGuard.

Just get WireGuard in there. That's all I'm asking for. Jeez Louise. Linode.com slash unplugged. Go there to get a $100 60-day credit towards a new account. And of course, support the show. It lets them know you heard it here and you're like, hey man, thanks for supporting the show that I listened

to. Those guys have been going for like seven years and really appreciate you supporting them. That's what just visiting linode.com slash unplugged does. It gets you $100 of Linode money, and it's telling them it's a signal that you support the show and that you support them supporting us. That's a lot of support.

It's kind of like a big hug over at linode.com slash unplugged. They're our cloud provider. We've been using them for all of our JB 3.0 infrastructure. I started a couple of years ago using them personally. I wanted a cloud provider that seemed like a good member of the Linux community. And of course, I had known about Linode forever because they've been around since 2003. I've seen them at a ton of events and they've supported things like Linux Fest Northwest. And I thought, okay, it's time.

You know, I wanted something that was separate from the other services we had. And I went to Linode. Separate from the other services we had. And I went to Linode. And one of the things I personally really like, just as somebody just first experiences, is I loved how many freaking distros they have. Remember I mentioned Alpine earlier? Yeah, they got that.

They got Arch. They got the recent CentOS. They got Debian releases up the wazoo. They got, same with Fedora. They got several Fedoras. And OpenSUSE. They got OpenSUSE 2. They got all the versions of Ubuntu you'd want to deploy and more.

It's funny. I even have a couple of Debian boxes from the one-click application deployments for game servers. But what I really, really got about them, what clicked for me, is their love for Linux and open source. You know, they're independently owned. And they're founded on a love of Linux because, and I say that in a way that I'd say this network was founded on a love for Linux. You know, for me, I had to start talking about Linux. That's what I had to do. I was like doing this awesome stuff. I was a Windows refugee who's doing this awesome stuff with Windows. I mean, with Linux, saving myself from Windows. My first real experience was like Squid Proxy because we just cut the bandwidth usage on our T1

connection just dramatically. And it was like I did it for free and it was just this huge deal and I just kind of became enthralled with it and I had to talk about it. Well the guys at Linode, they came up with a way to do something even more clever. They saw where user mode Linux at the time was going but they saw where the ball was

rolling and they started what was really one of the first cloud computing companies. to do something even more clever. They saw where user mode Linux at the time was going, but they saw where the ball was rolling. And they started what was really one of the first cloud computing companies. And now, Linode is dedicated to offering the best virtualized cloud computing out there. If it runs on Linux, you can run it on Linode. Even weird custom setups, virtual desktops in the cloud. I use it for all kinds of backend infrastructure,

but for personal stuff too. So like a personal website, sure. But you need like a communications hub for your company that's private. Yeah, we'll do that too. But just try it out with that $100 credit. Go to linode.com slash unplugged. Go there, get the $100 credit

and support the show. Linode.com slash unplugged. So Ubuntu has chosen to backport a rather well-known desktop application, but they're not using a snap. They're not using Flatpak. And I find this to be fascinating. So Ubuntu 20.04 LTS shipped with Thunderbird 68, but that version is no longer supported upstream,

which means the Ubuntu developers either have to go figure out how to backport these new fixes for like security stuff, or they have to just buckle down and go with Thunderbird 78. Understandably, the developers decided we're just going to ship Thunderbird 78. But it's not like a simple decision,

and that's why I think the packaging matters in this case, Wes. Oh, yeah, I mean, 68 to 78, that sounds like a big jump, and it is. And therefore, the Ubuntu devs are warning of some possible disruption to come from this rather big stable release upgrade. In particular, say, Enigmail, for instance, is deprecated now that Thunderbird actually has a native PGP solution, finally. And that impacts LTS users relying on that old plugin, not to mention all the other plugins that may no longer work on 78.

Yeah, and... Okay, Wes, come here. I don't want... Let's just have a little side meeting here. Huddle close. The cone of silence. Maybe we should ask, but this seems like the perfect use case for this technology called SNAPS, which is a software packaging methodology that allows LTS users to safely use new software

on older releases, decoupled from the dependencies. So if somebody could tell Canonical that they have snaps, that they could deploy this Thunderbird as a snap and not mess up Thunderbird 68, I feel like that'd probably be a good thing, but I don't want to mention it on the show because that'd be, like, super embarrassing.

Well, you know, they actually, I guess, I'm looking right now, it looks like there already is a Thunderbird Snap available. Yeah, okay, okay, okay. The cone of silence. I think that the problem here is, do you just leave that old unsupported version left to rot in your LTS repo? Actually, what I really like about this story

is that they are actually shipping it as a dev because then the existing users will get that upgrade. And I think it's really awesome that Canonical is investing the time and resources to keep that kind of stuff on the LTS desktop up to date and secure. It makes it a viable option. Yeah, and it's interesting to note, like, this is, it's just sort of insight into where

Canonical is choosing to spend those development resources, right? And I guess Thunderbird is worth it to them. So this is, this is really exciting. I want to take a minute here in the community news to say our community has something special happening this week. This is a local story, you know, like you got your national news and your local news. Well, this is a local news story. Coder Radio 400 lands this week. That's a big milestone for me personally and for Mike and the team here. 400 is no joke when it comes to podcasting. It's over eight years of shows. and that lands later this week.

If you're listening to this on the release day, it lands just a few days after this episode. So I just wanted to encourage you to head over to Coder.show slash subscribe to grab the feed so you can get it. I feel like, you know, it took a break for a little bit, but after we went independent, it came back, and I think it's better than ever. Episode 400 is going to be well worth a listen. We've already recorded it. Wes joined me on 399 and we had a great time there and we talked about some of the backend tech, the open source tech we use here at the studio. And after over two years of like no merch, no swag, just a drought of fun stuff you could get from JB. All my clothing, it's rotting away. I know.

All my old shirts are fading. Well, we're launching our most ambitious merchandise item ever in episode 400 of Coder Radio. There is life before this item, and then there is life after this item. And all of the details, all of them, will be revealed in Coder Radio 400. In fact, there may be more than one item. So check that out later this week. of the details, all of them, will be revealed in Coder Radio 400.

In fact, there may be more than one item. So check that out later this week. Just go to coder.show slash subscribe to grab the feed. And don't miss this week's episode. We're super proud to be to 400 episodes. And this show is not that far away either, Wes. So we got to start thinking, like, what do we want to do for big 400 here on this show? Uh-oh. Yeah, well, we've got eight episodes to go.

Yeah, yeah. So Coder just hit that milestone a little bit before us, and we had a lot of fun. And so keep an eye out. That'll be on the Coder feed, and it'll be in the All Show feeds later this week. And we do have a little bit of cleanup to do around here. I want to mention that our Telegram group is still going strong. We don't talk about it as much these days, but we love it, and we're in there all the time. It's at jupiterbroadcasting.com slash telegram.

Get in there and join the chat, especially if you just recently got Telegram, because I know a lot of you have. Also, the Luplug, going better than ever, every single Sunday. It's noon Pacific, 3 p.m. Eastern, right in our Mumble room, right in the lobby. And we have all the information on how to join Mumble at linuxunplugged.com. And we have the Luplug session in your local time at jupyterbroadcasting.com slash calendar. So I also am going to give a special shout out. If you're looking to reach the audience, we have an opening next month. JB has some sponsor opportunities for members of our audience next month.

So email me chris at jupiterbroadcasting.com. I love to have a situation where somebody who listens to the shows has a product that our community can benefit from. And I'd love to hear from you. Chris at jupiterbroadcasting.com. And Mr. Bain, I think that's all the cleanup we have this week. It sure looks tidy around here. Okay, don't call me crazy for this one.

But I have an honest question that I want to ask you guys. And maybe in a way I kind of want you to talk me out of it, actually. But I'm thinking about Arch for a family member. And this is something I would never ever do in the past. I always go for the LTSs or elementary OS or something that's a multi-year distro. But the situation has changed recently and it's got me considering deploying something much more current for a family member.

It all started because of a laptop. I'm testing a laptop out for my boy Dylan, thinking about giving this to him for his birthday that's coming up soon. And it's a funny thing, this laptop. This time a year ago, by any review I read online, it was an absolute nightmare to get Linux running on this thing. And I can kind of see why. It's a Ryzen 9 8-core CPU. It has an NVIDIA RTX 2060 Max-Q as well as a built-in AMD integrated GPU, 128 hertz display. Not every desktop environment even supports that. I mean, this thing

is a quintessential gaming laptop. It's the Asus Zephyrus G14. It's a 14-inch screamer, and it's a slick-looking rig. I've seen a lot of people asking online if it's compatible with Linux, and back in April of

2020, when Jim Salter over at Ars Technica tried it out, our buddy Jim from the show here, he's been on before, he had all kinds of problems. And Jim's not new to Linux. He declared it, and I quote, a bust under Linux. He had trackpad issues. He had no working GPU acceleration. And for the hardware that did work, he had like strange driver errors that would be in the logs even though things were working. It just was a complete no recommendation from him.

And it seemed like such a shame, you know, something with a with a great Ryzen CPU and dedicated graphics and 128 hertz screen. That's a special combination. Well, is it isn't it funny how it works in Linux land? Well, isn't it funny how it works in Linux land? If you fast forward to the end of 2020, early 2021, and you have a distro that rocks a modern kernel, the thing's nearly problem-free now. Wow.

Everything basically works. And I mean, you've seen it, Wes. It's a nice-looking rig, too. Yeah, yeah, it is. It's got 24 gigs of RAM. It's got a really fast NVMe disk in it. That Ryzen CPU has 16 threads, eight physical cores. And with that 128-hertz screen

and that NVIDIA GPU, this has literally become one of the best experiences of desktop Linux that I have ever had. And I've fallen in love with my son's computer. And I don't know what I'm going to do about this. I mean, this is going to be really hard to give up. and I've fallen in love with my son's computer. And I don't know what I'm going to do about this.

I mean, this is going to be really hard to give up. But the kid loves to game on Linux. And this week, he asked me for Arch. He asked. And I think, you know, for him, it's obvious. He's seen how quickly I can get things up and going on my computer versus his, which is based on an 1804 base, and things are just a little bit harder to get up and running when you're trying out different launchers or the latest NVIDIA driver.

And he gets that. He doesn't understand all the details of it, but he understands that his Linux is based on something that was released in 2018, and my Linux is based on stuff that was released now. And he finds that more compelling, because he wants to get like launchers from the AUR and stuff, drivers and stuff like that. And so my idea was, let's see if this machine works. And I was pretty skeptical, because Jim had had such a hard time with and others as well. You can find threads all over the internet of people having this drugs. And so I thought, well, you know, maybe, you know, because I'm, you know, I'm Mr. Linux

Unplugged over here. Maybe I can get it working. Chris, LAS, the LAS stands for Linux Action Show. Hello, ladies. So I thought maybe I'll get it going. And but in reality, all I did was download Endeavor OS, which ships with a very modern kernel, especially their latest release, and use that to boot this laptop.

And everything just worked. And so then I started to think, well, hang on here. Should I do this? I mean, my personal reasons for giving my son Arch on this machine would be over and over again with gaming, it seems like it's always been beneficial

to have the latest graphics stack and kernel stack. There are a few kernel patches that allow you to control the thermals and the fans and other things more with the G14. Of course, that stuff's right there in the AUR. Super easy. Just a kernel build away. Yeah, and that's nice

because it just solves a couple of things and it's just done. Like I mentioned, there's tons of game launchers that'd be easy for me to set up for him via the AUR. And rolling means fresh GNOME shell. And fresh GNOME means the latest performance improvements that multiple upstream companies are working on. And then at the end of the day, of course, my kid has dad-grade tech support. So it's not like I can't help him. I mean, that's a real factor here.

So I'm wondering, can somebody give me a reason not to do it? Carl, I know your kids are on Fedora, and it looks like it's working really well for them. Your daughter seems to love it. I guess, is it, am I crazy here? Should I just be happy with something like Fedora? Because I have thought, like, either the most recent Fedora or the most recent Ubuntu and just stick with that. I would say go with whatever you're most comfortable with. I mean, whenever you're the escalation point,

whenever you're the support, have them use whatever is the easiest thing for you to support. Computer kid thinks I should go Fedora. Yeah, it's going to give you all the rolling, nice updated software you would get in Arch. But here's the thing. Your son won't have pain from his operating system.

Yeah. I mean, is Arch that bad? I feel like Endeavor OS makes a lot of, it takes a lot, it's very, it gets you installed, it gets you set up with a desktop environment, and then it's basically like, okay, have at it, and it's out of your way, and it just runs. I would say it depends on his update hygiene.

Yeah. And how willing is Dylan to be, you know, involved in that sort of maintenance? Are you the one doing the updates, or is he going to be doing that on some kind of basis? My thought there was maybe go with the LTS kernel and the LTS video drivers, and then just do updates, you know, a couple times a month. If you do the LTS, you will probably miss out on some kernel niceties that might help with his newer components. True. Although the LTS kernel, I think in Arch now it's 5.10.

I mean, I'm pretty good at that point. Maybe that's coming. It looks like the current is 5.4. Oh. Oh. Oh. Oh. Oh. I. Oh. Oh.

I don't know. I'm running an AMD system and it's very nice to have latest kernel and Mesa stuff. It helps out a lot. Oh, boy. Yeah, boy.

If it's 5.4, that's kind of a deal breaker because I think some of the stuff I need is in later versions. Hmm. Okay, so LTS is out, but PyCrash points out

there could be a few other steps I could take to make Arch a little bit safer to use. Yeah, I mean, it will be a great opportunity for Dylan to play with his system and learn a little more about Linux. And you can just install Snapper

like you have on your Arch server. So he breaks it, just tell me how to roll back with Snapper and he's done. He rolls back, he fixes problems and it's done. True. I feel like what would make Snapper even more perfect with

its, with Arch would be if it made a boot entry. So you could actually boot into a previous snapshot and just go right back. So you could just, all you had to do was reboot and go to previous state in Grub. And then I feel like that would be deployment ready for him. But Minimac, I feel like part of the thing here is he's asking for Arch, and this is kind of an opportunity to take him further down the Linux path.

Yeah, I was just listening to that story, and I just felt as a proud father, you just want to do that. You know, in German, we have that saying that says the apple just falls next to the tree. And you want your son being in the sky. And I mean, there is probably a learning curve. But I mean, with a possibility of SSH connection, you can probably fix some stuff. True. That maybe, and let's be honest, you want that.

And it's cool. That is a good point. I could probably just do a reverse SSH connection and fix it for him. And I'm always just a call or a text message or sitting right next to him. So that's true. Although I don't want it to end up being a problem like when I'm super busy and I can't address it right away, which could happen.

So I don't know, Colonel, maybe there's a bit of a safety in between with Manjaro. Yeah, I know that for a lot of gamers, they really like Manjaro because it walks that line of having the newest stuff, but Manjaro will hold it for a lot of gamers they really like manjaro because it walks that line of having the newest stuff but manjaro will hold it for a week or two do a little extra testing and kind of takes the pain out of arch so it might be a nice happy in between where he's still getting newest stuff it's still rolling it's still technically sort of arch but he doesn't have some of the pain points that Arch would present

where you have to read the blog post before you do your updates and stuff like that. I have considered that because you're right for gaming too. It really does kind of hit that. The other thing too is that Manjaro has taken a lot of work to actually make gaming a good experience on Manjaro. So there's that too yep yeah that's a fair point i have really liked endeavor os but i'm liking it from i forget that it's not just vanilla arch i i think their iso sort of hits that perfect balance it has some of the latest

packages you might need and they just did an update for 2021 and And so in there, they've got like just some nice sensible defaults. And you boot that and you get Linux 5.10. And you get a lot of nice new stuff, just right out of the box. And then you're off to the races with Arch. And some of the other things they do by default that I think all Arch distros should do is they package reflectors. So you get the fastest mirrors possible. I mean, it's just a solid, solid version of Arch. But you're right. If I'm going just for gaming, I could see that. I could. Talk me out of it, Carl.

Well, I guess the way I would look at it is that you were talking about when things do go wrong, Fedora would give you a good boundary there where they still get very fresh software, still get the latest kernel and graphics drivers all the time. But for other major, major changes in the operating system, those are going to be batched up with the major version upgrades like going from Fedora 32 to 33. And you could wait until you're around to do those upgrades, but not doing the system upgrades, you know, just the regular routine ones he can apply on his own all the time. he can apply on his own all the time. Yeah. Huh, man, this is tricky. I feel like I had all this momentum and now you guys have basically taken me to the distro disco. Distro.

So what I got to do is I got to just try it all out. So right now I have Arch on there. So I think before I take Arch off, PyCrash linked SnapPack Grub, which is a Pac-Man hook to update Grub entries if you're running ButterFS, which I don't know if I am or not on that machine. So this is cool. Did you see this, Wes? It does that bit I was talking about by taking those snapshots and making them grub entries.

Ooh, yeah, isn't that handy? I wonder if we should put that on the server. I'll put a link to it in the show notes. Let me think about that. Kick that one around. See, that seems perfect. We'll test it out on the server, see if we like it, and if it proves itself reliable, give it to Dylan.

True. I could try it on the laptop for a bit, and then I think I think I need to give Fedora a spin. I need to try it. I need to try it soon, so that way I can get this figured out before it's birthday. And then I gotta figure out what the heck I'm gonna do

for myself. I'm kinda thinking maybe I might sell my X1. It's a fine laptop. You just got that. I know, I know, I know. But I have to recommend this G14. If you're comfortable running cutting edge Linux and you want like an Asus laptop that you can order off Amazon. I mean, the thing's ridiculous. It plays every single video game I throw at it, but my desktop experience has been super smooth. I've gone with Gnome Shell on it because I'm just using it as a single monitor,

and it feels really, really nice and really fast on there. And I'm using Plasma on my workstation class machines that have multiple monitors and multiple screens, or even a single screen, but we're using it for work. That's Plasma these days. But for my one-off play machines that are single monitor, I'm finding GNOME Shell really does the trick. I really like it. And I've been using that on there and it seems that it has solid support for the 120 hertz screen. So everything is just so smooth you want to lick it.

I feel like maybe I've been broken by it. I don't know if I can go back now. I'm like that guy now. Looks like you'll be buying a second one pretty soon. I would love for Next Gen Ryzen to be easy to get access to. That would be perfect. But I'd love to know your thoughts. Let me know, linuxunplugged.com slash contact. Have you deployed something like Arch for a family member?

Is that just too crazy? And is Fedora or maybe the latest Ubuntu a safer kind of bet? Ironically, he would be happier with GNOME 40 because he's actually used to horizontal workspace layouts with the very little interaction he does with them because he's currently using elementary OS. And it's worked fantastic for a long, long time since it came out. But now it seems like it's getting trickier and trickier for him to do things like run multiple versions of Java and update the NVIDIA driver. And his frustration translates to,

maybe I should try Windows 10. And so when there was this window of opportunity, and we went, well, wait a minute. If I can keep using Linux, but Arch makes it easier, maybe I should use Arch. Dad, will you put Arch on my computer? What would you do? Let me know. LinuxUnplugged.com slash contact.

Thank you to Datadog for sponsoring this episode of the Unplugged program. First time here on the Unplugged program, so go to datadog.com slash unplugged. They're the unified monitoring analytics platform for comprehensive visibility into cloud hybrid and multi-cloud environments. If you have on-premises and in cloud, they can do that. Before on the show, we've talked about site monitoring, keeping a real good eye on your site. Well, of course, Datadog can do that, but this is the entire stack. This is monitoring your whole stack, your OS, your applications, your website, all of it from top to bottom. This is make important business decisions kind of monitoring.

Get data to make decisions. It's data about your entire stack, and you can quickly analyze the performance of your Linux servers in real time with customizable dashboards, and you can troubleshoot those issues in seconds. You can get a unified view of your metrics, your traces, your logs, all in one place. Datadog started as an effort for the developers to communicate with sysadmins and sysadmins to communicate with developers. Seriously, that was the original premise. And they've built in this incredible stack with turnkey integrations for over 400 technologies. You can even use Datadog to monitor key Linux metrics

and watch it right alongside with application data and even inside your containers. Get insights into container performance. I mean, I'm talking full stack visibility here. You get an idea of the health, the performance, all of it. So start a Datadog trial right now by going to datadog.com slash unplugged. If you start a free trial and you create just one dashboard, you'll get a free

t-shirt from Datadog and you support the show. It's that easy. It's that simple. Datadog.com slash unplugged. Get an eye on everything and go too, just to see how beautiful they make it. They really help you visualize all of this in a way that your brain can process and take action on. Datadog.com slash unplugged. We got a couple of emails in and some follow-up about BrowserSync. Do you want to take Dan's email there, Mr. Payne? Hmm, sure do. Yes, Dan wrote in about BrowserSync

and writes that when Chris mentioned the story about Google cutting off sync support for Chromium, I thought for sure he'd mention Eversync or XBrowserSync. Both have cross-browser sync nailed down, and the latter, being XBrowserSync, is FOSS and self-hostable. I like that. So I went and took a little look-a-roo

over at XBrowserSync.org and they pitched themselves as a solution that respects your privacy and gives you complete anonymity. Anonymity. Thank you. I'm not even going to try. And no signups are required.

There's no personal data that they ever collect, they say. They say to start syncing, you just simply download their X browser sync tool or plugin and an encryption password, and then you create a new sync. And then that's how you do it

is that key you are essentially creating. And I had not seen X browser sync. And I guess kind of because I got kind of burned with X marks. That's what I use to sync across all my browsers. It was so nice. Guys, if you use bookmarks and you use multiple browsers, the strugs is real. Like I have bookmarks in Firefox. I got bookmarks in Chrome. It's just, it's mismatched. And Xmarks used to keep it all in sync until one day they just kind of went away because everybody started building this in. Well, there's a couple of projects out there to solve it.

But I wanted to say, Wes, we got an email into the old show skis here about using Gnome Web or Epiphany with Firefox Sync. Oh, you've been using it, huh? Super good. Super duper good. Really nice, really fast, peppy, modern browser. If you haven't used GNOME Web in a while or Epiphany, whatever you want to call it, you got to give it a go again.

It's not going to be my primary, but it is definitely a good secondary browser. It handles the Google Apps fine, as far as I can tell. Low resource usage, Wes. I'm telling you, it's beautiful, Wes. If you're on a GNOME desktop, it's beautiful. Just try it out. Just saying.

And it syncs with Firefox Sync. All right, our next one comes in from Halvers, and he writes in about gaming on Wayland. I recently tried using Wayland to play games on my dual monitor setup using my AMD GPU and the latest Mesa. I'm not entirely sure that this is the case,

but it felt wrong. Like I had massive input lag or something, even though my frame rates were just fine. Is this something that could be relevant to talk about here on the show? Because I'm wondering if it's just me or if I need to stay on X11 for some reason. With all of the work that's gone into gaming on Linux in recent years,

I was sort of sad to discover this. Best regards. Have you done much gaming on Wayland, Wes? You know, honestly, most of my gaming these days is on Wayland. Really? Kind of just switched over. Now, I'm not a huge gamer. I don't play a lot of crazy difficult or intensive games necessarily,

but a lot of stuff through Proton, and just casually on the weekends or whatever. It's been fine for me. I don't have a crazy monitor setup, especially like you with triple, multi-orientations or anything. I've just got two monitors side by side, but I've not noticed this, at least.

Gambus, or Gabmus, in the mumble there, you said you're playing Gnome Weyland in games all the time. Yeah, I actually since I got my 5700 XT I've been playing exclusively on Gnome Weyland and so far it's been great to the point that

when I sporadically need to go back to X.org and I just forget that I'm there, I immediately notice when I launch a game and because of tearing and stuff that doesn't work like I'm used to, I guess it just works better if you have a recent AMD GPU. Also, I'm on Arch, by the way, so that may be a thing. Very nicely done.

So, Halvers, you didn't say what desktop environment you're using, because I have had two very different experiences with gaming on Wayland. Gaming on Wayland with Gnome Shell has been remarkably flawless. I think I've even mentioned on the show at one point, I was blown away because I was gaming on Wayland with an AMD GPU that is an eGPU. So I'm using an eGPU while X Wayland is running in Wayland, and I'm controlling it with a Bluetooth mouse and a wireless headset. And everything was in sync, and everything worked. I mean, like, amazing, right? Bluetooth mouse, wireless headset, eGPU, laptop, and it just was great with Wayland, right?

And so I've had that experience, and I've also had this strange experience that you've had where I've had this weird delay in lag, and I really have problems when I have two monitors on Plasma. It seems to be that if I'm on Plasma with a single monitor and on Wayland, I don't have as many problems. But if I'm on Plasma with multiple monitors and Wayland and I try a game, because I'm a maniac apparently, then I also experience what you're seeing. So you didn't say what desktop environment is, but I'm wondering if that plays a role. It's GNOME. So this is probably to do with, I mean, Wayland, it's weird.

We're used to Xorg where Xorg does most of the window management and not the compositing necessarily, but the compositor for Xorg is typically very close to what Xorg does. In Wayland, on the other hand, as far as I understand, the desktop environment acts as a compositor that in turn acts as also a window manager. So everything has to do with the compositor. So it makes sense that you will have different experiences depending on the desktop environment

because it's practically a different way of implementation. Right, well said. And then one last bit of follow-up before we get out of the feedback section. I talked before about MailSpring. It's a mail client that I use and it has pretty good invite support. It doesn't have integrated calendar,

but it has some nice features. Overall, it's got kind of this cool slash creepy, like has somebody opened up the email tracking system? And I kind of like it. It also has integration with LinkedIn. So when you're reading, you can email from somebody if they are on a popular social network, it'll pull in some of their details. It is an Electron app, but it's probably one of Linux's most feature-complete mail clients. It kind of had a slowdown in development app, but it's probably one of Linux's most feature-complete mail clients. It kind of had a slowdown in development recently, but the developer seems to have popped back up, and now we have another update. A component of what makes MailSpring work really well is the server-side sync.

And the server-side sync is really staying in touch with the Google Apps account that you have. It's what helps do the really kind of cool-slash- slash creepy tracking. It's a major component of MailSpring. MailSpring itself, open source. MailSync, the server component, wasn't until this week. A day ago, the developer of MailSpring took MailSync GPL. And now the server component of what is one of the better desktop Linux mail apps, right up there with Thunderbird, now has a GPL3 server component that you can self-host. It's early days still, but this has been a project that this developer spent five years of his sweat, tears, and blood building. And now it's open source. Wow. Good to see, huh? Yeah. I mean, it's a nice little bolster for continued development.

I think they write in that update, you know, trying to find the right balance between product and project, and that's definitely not easy in open source. Makes me wonder, maybe I should give it a shot again, because I've sort of just given up on desktop clients, and I'm a webmail guy now. Yeah, I tell you, like today I was, before we got on air, I was emailing back and forth to somebody for something we were talking about today.

And it sure was nice having that on a desktop app. Because while I wanted it, I could turn on desktop notifications. It integrates in great with that. And I could, as soon as that person got back to me, the pop-up came up on my desktop, and I just moved over to that virtual desktop that had the app full screen and got right back to them. And I was like, man, I'm really glad this is a desktop app. I could do this with a web app, but it's just not quite as nice. So MailSpring, it's great.

Now to have both ends of it open source, now I feel a little bit more comfortable kind of giving it a full-throated endorsement, whereas before I was sort of like, oh, yeah, but, you know, there's Thunderbird. But now I'm kind of like, yeah, Thunderbird's great, but Malespring, pretty awesome. And then last but not least in the show today, we have a few picks to enthrall you with. And I don't know, Wes, is there a theme to these picks?

There certainly is, and it wasn't even of our own devising. We just got a whole bunch of picks via email and they were all built on Rust. Yeah, we have a whole batch of Rust picks. And like Wes said, we didn't even do this. So you did this to yourselves. The first one, and I looked at the other ones pretty closely, but I didn't actually look at this first

one super closely, but I think it's kind of like a curl or wget clone, but in Rust, is that right? Yeah. So it's a HTTPi clone, and if you're not familiar with that, HTTPi is a Python application that, yeah, it's sort of just like a friendly or easy curl to use. You know,

curl's great, Wget's great, they're easy to use, they're scriptable. This is a version of that same thing you're making requests, HTTP requests, but you just want it for a human. It's for human workflows, you're experimenting with it. I use it just about every day because I'm writing a lot of APIs and I want to test them out,

write tests for them, and give a nice easy human breakdown of what are the headers, pass on JSON files no problem, all that kind of stuff. The biggest pain point for some people, though, is, well, it's a Python app. You can't just go download a package necessarily. Maybe you have to install from pip or hope it's packaged in your OS or something like that. Well, HT is a Rust app, so just head to the GitHub releases page.

And while you're there, swing over to the FDDF page, the Fast Dupe Finder. This is a small Rust command line program to find duplicate files in a directory, but recursively it uses a thread pool to calculate the file hashes in parallel, so it's super quick, and then it uses a thread pool to make its decisions. Duplicates are found by checking the size, and then the hashes of parts of files of the same size. I mean, it looks at them

and then takes a byte-by-byte comparison and then tells you which ones are duplicates and it does it all in the blink of an eye. It's very impressive. That's what I like, right? I mean, maybe you don't need this. It's kind of a niche use case. It's just a small little app.

But if you have a file, maybe you're trying to clean up some data, you have a lot of duplicates in there. And I just think this is a perfect application of Rust because you get those, you know, those nice reasonings about concurrency and parallelism, about data safety. So you can do some complicated algorithms, implement them well, and still end up with a tight little binary to run. Yeah, word to your mother. And also, it could be just a simple tool to just go through and find like duplicate files or for photos. Like say you took a bunch of photos, and then brought, you imported them and you got some duplicates. I know I've done that.

Could be useful for that. But clear the decks because the best we saved for last, we talked about bash top. We've talked about py top. We've talked about bpy top. We've talked about gotop. We've talked about a lot of top replacements and they always seem to be trying to top each other. But when somebody came and wrote one for Rust, they took the other route. They took the bottom. And that's why this application is called Bottom, yet another cross-platform graphical process

and system monitor for your terminal. And it's awesome. It supports Linux, macOS, and even Windows. It seems like it's primarily inspired by Gtop and Gotop. And I, of course, put it on my system, and I love it. It's so fast, and it's got pretty nice mouse support. I didn't even realize that, but here I was playing with it while you were talking and started just scrolling on my, you know, just on the trackpad here,

and it scrolls all, you can scroll in the graph and change how long of a period you're looking. You can scroll through the list of processes or temperatures of the sensors. Awesome. Wow, that's cool. I totally didn't, that is really useful to be able to scroll

through the processors there. That is really nice. They've also got a really rich readme, lots of documentations in there, which clearly I haven't read yet. But if you're looking for a new top,

this is a good contender. Before we go, I just want to say thank you to our Unplugged Core contributors, unpluggedcore.com. You keep in the show independent, you get that limited ad feed or the full uncut feed. All the pre, post show, like additional show stuff, super, super content show. Both feeds are available to our members, unpluggedcore.com.

Thank you, everybody. Also, I want to mention that a cloud guru has a course to help you get networking figured out on Linux. You ever have that where you've had to troubleshoot a networking issue or something like that? Well, they have a course. Only every day. Yeah, they have a course. Only every day. Yeah, they have a course that'll help you feel comfortable in working with a large variety of different networking tools

and configurations and help you manage complex Linux network implementations. We'll have a link in the show notes for that or you can go to cloudguru.com. Good way to learn tools like TCP dump, Wireshark, and a lot more. So check the link in the show notes if you

want to learn deep. If you want to go all in on Linux networking. And then a pro tip before we get out of here. Join us online. The conversation keeps going at jupiterbroadcasting.com slash telegram. We have our matrix server info, our mumble server. Everything

is at linuxunplugged.com. And there's an entire network of fantastic podcasts that can be found at linuxunplugged.com. And there's an entire network of fantastic podcasts that can be found at jupyterbroadcasting.com. And just a reminder, Coder 400 is just around the corner. It's a big one. Wes was there live, so he already knows how exciting it is. Secrets, but this is not a coder to miss. I don't think so.

I don't think so. I don't think so. And why miss a live production of this show? We make this here podcast every Tuesday. Join us live at 12pm Pacific, 3pm Eastern. See you next week. Same bat time, same bat station. Contact page, subscriptions,

all of that info at linuxunplugged.com. Go there to get all of that. Even if you can't make it live we still appreciate you downloading this podcast and we always appreciate it if you can share it it's a great way to contribute to the show even if you can't do it monetarily you can still share the show with somebody

that's absolutely free and it turns out to be the number one way podcasts get marketed I mean you think about it it's a big ass to listen to like an hour plus show so if somebody you trust tells you to listen to it, it makes a big difference. And that's a great way to support the show as we're nearly to 400 ourself. Thanks so much for joining us on this week's episode of the Unplugged program. And we'll see you right back here next Tuesday. Bye. All right, initiate intense jealousy mode.

Dalton already has a pre-order for a Starlink kitten. What the hell? Didn't those just come out? Yeah, six hours ago. They opened pre-orders, so it's like, well, I got nothing to lose. I want one. Where do I go? The Starlink website. You can do an order now. I'm going to do it.

I really think this would be a game changer for me. I feel like this would be a significant game changer. Yeah, I'm paying like 200 bucks a month for maybe 40 megabits per second down. So, yep, yep, yep. Starlink is going to be life changing for me. See, when I go to their web page, though, it's just the same old, same old, same old that I've already filled out before. I think it says order. The button has changed to order now, hasn't it?

Oh, you're right. Oh, my God. Oh, this is very exciting. I'm going to go fill it out. When you go through the order now process, do they mention anything about the ongoing play cost after you've ordered the kit? Yes. $100 a month. Well, $99. Whatever. Which is so much cheaper than what I pay for LTE connections and whatnot. Six LTE connections.

I was going to say, Chris, you're probably paying what? $300 or $400? Yeah, I actually just spent about 95 hours in the woods off grid and it was fantastic. Oh, it was wonderful. The only thing that really kind of went sideways is that there's like a polar vortex, as they call it, coming into the Pacific Northwest. And so the temperatures are going down to like negative eight in the area that we were at. And so it started to snow Sunday night. And Monday morning we woke up and we looked around and we thought, we better get out of here.