LINUX Unplugged - 394: Tempted But the Truth is Discovered

Episode Date: February 24, 2021

After all these years, what's made us stick with Linux? Plus the commitment just made by the GNOME team, and some new tools that are changing our game. Special Guest: Drew DeVore.

Isn't this news of NVIDIA nerfing the RTX 3060 for crypto miners just sort of the warning shot that really should be telling us open source drivers matter and open video hardware might even be more important? Because NVIDIA is going to just artificially limit the capabilities of these cards via their driver. And I mean, no love lost here, no tears for the miners, but boy, this just grades on a nerve of mine. Yeah, it's interesting. Clearly a move they're trying to help gamers out. And I

think part of the idea here is right now miners are the ones with the money because they're trying to make a buck off, you know, mining Ethereum or whatever. And so they're just paying all the high prices, grabbing all the stock that exists. So if you create an artificial version that is just for gamers, okay, maybe that leaves a little supply for some gamers. Maybe, but you know what's going to happen. You'll have the miners that will just buy up the gaming cards, and they'll have a hacked driver in under a month. Well, you know, NVIDIA addressed that and wrote that

apparently there's a secure handshake between the driver, the RTX 3060, and the BIOS that prevents removal of the hash rate limiter. So it might be a challenge. Ah, that'll do it. Until somebody just figures out how to put a Raspberry Pi in the middle and pull the whole thing off anyways. Hey there, good looking, and welcome into your weekly Linux talk show.

My name is Chris. My name is Wes. Hello, Wes. Coming up on today's episode of the Unplugged program, we're going to tell you how we have managed to stick it out with Linux over the years. I mean, at least once, maybe sometimes more, you get tempted by the fruit of another. Well, listener John wrote into the show with a problem that's forcing him to consider dropping Linux entirely. So we'll share some hard-learned wisdom

on our part with him and some practical tools to actually pull the whole thing off. So that's coming up in the show. But of course, we also have community news and a lot more to get into. But first, we got to mod load up our virtual lug and say time-appropri appropriate greetings, Mumble

Room. Hello, everyone. Well, hello. You know, you guys, every time you manage to make me giggle, and I don't know how, because you know, I know it's coming, but you still make me smile. Thank you for being here. We've had a little bit of connectivity issues today. We don't know what's going on.

So I appreciate you guys sticking it out with us. It's kind of ironic because this week otherwise has been one of the coolest Linux production achievement weeks for Wes and I in maybe about a year. I mean, we have, we're really flying on high cloud right now with Linux. We are experiencing like a whole new revolution in tools for Linux and audio production. And we're going to talk about some of that today. Some new tech and just stuff that people have been working on for a little bit that's finally being realized. And it's all kind of coming together to make something special. So connectivity issues aside, we've actually had a really, really solid week for Linux. I mean, besides Wes and I and our accomplishments

that we'll share in a little bit, Linux also made it to Mars in the last week since we all got together. And I think a lot of us have been geeking out about Linux landing on Mars. And we covered it a little bit in a recent episode of Linux Action News. But if you've caught stuff since that episode, you may have caught that there was more Linux and open source involved than has been widely reported. During the Monday public unveiling

of the landing footage of the Mars rover, which was legitimately awesome. In there, the NASA officials actually thanked open source and even name dropped FFmpeg directly. I grabbed a few seconds of that stream for you. It's not perfect audio because they were having some packet loss

in their stream at the time, ironically, but I still wanted you to hear it. And I want to add one more thing I wanted to mention about the camera technology and then this data. We haven't mentioned it, but in addition to use commercial cameras, we're using a commercial computer, an Intel-based PC that's running Linux, open source. So it's the first open source, at least that I know of, open source Linux box running on the surface of Mars. It's actually inside the rover.

It's quite compact. And so there's the Linux operating system, and we compress the video using FFmpeg, which is another open source tool. So thank you to the open source community for allowing us to use your amazing software. In fact, there really is quite a bit of Linux in open source software making this mission possible. And if that's the kind of thing that interests you, well, definitely check out episode 177 of Linux Action News, because we've got some exclusive details about the open source software powering multiple aspects of the mission hardware.

Yeah, it's not just Linux on the copter or on the landing system, but there's also a lot of open source that's helping both systems do local processing. And it was the highlight of my week. We got to chat with the operations lead of the Ingenuity helicopter on Mars, and he gave us some of the Linux-y details and hardware details, and that is in Linux Action News 177. If you haven't caught that one, it's pretty historic. It's pretty historic that Linux helped them achieve something. Linux and the open source software that was running on Linux helped them achieve something historic like that, and kind of awesome that it crosses over with our area.

And then that this individual at JPL took the time out of his schedule when they're probably pretty busy right now to answer questions for Linux Action News. Really wonderful. It was pretty great. Wes and I were geeking out pretty good. And now it just gets better as we wait for more and more awesome pictures and videos to come back from Mars.

Yep, that Linux copter will be flying in a few months. And the system we talk about in that episode is what will be powering that flight. And back here on Earth, the Open Build Service from the SUSE folks is announcing that they are introducing Flatpak support into the build service, which is brilliant. And really, you don't have to do much. They have a quick start guide. Even if you've never built a Flatpak app, they say you can quickly get started by branching their template package. For a successful Flatpak build, you're going to need four things.

The project configuration, which you can get in that template. The project meta configuration, oh yeah. A Flatpak manifest file, flatpak.yaml. You knew there was going to be a yaml file here somewhere, right? And then, of course, whatever sources you're using in the form of a bunch of tar archives. But once you've got that, you're on your way to making a Flatpak. I don't think this replaces Flathub necessarily,

but I guess it gets you the Flatpak, then you could turn around and publish on FlatHub. I wonder if this is going to have interesting ramifications for Flatpak's adoption. Neil, do you have any thoughts on this being rolled out for the Open Build service? Yeah, so I've taken a gander at the functionality and looked at it a bit. and looked at it a bit. So what it basically does is provide a way to run Flatpak Builder in the build service environment, depending against the normal runtimes and things like that. But at the moment, they don't have a way of handling OS trees inside of the OpenSUSE build service. So without that piece, it's almost impossible right now to actually correctly publish flat packs and such. It actually takes a different approach from how Fedora has done this.

So for those who may not be aware, Fedora is also capable of building and publishing flat packs. Well, publishing is the important part. We can actually publish flat packs. Fedora's technology works off of constructing its own runtime using the RPMs that make up the Fedora distribution. And then for applications, we use the Fedora modularity building tool chain to construct using the existing spec files for various packages and constructing a flat pack build out of that and shipping that as an OCI container bundle. So they published to the container registry on registry.fedoraproject.org. That registry can be used as a substitute for a OS tree remote to actually fetch Flatpaks and run them. And so that's how we've been shipping Flatpaks and Fedora. And I think this is actually one of those steps for OpenSUSE to get there, to be able to build and release Flatpaks built on their own runtime, using their own trusted inputs and making it so that it becomes more accessible to ship software as Flatpaks. So this is where I was going with it, is do you think long term, I mean, a couple of years down the road,

think long term, I mean, a couple of years down the road, we could see some of the desktop applications on a SUSE desktop or the OpenSUSE desktop packaged as flat packs instead of RPMs? I think so. Yeah, I'm sure you've kind of seen this. But for those who, you know, may be a little less familiar, there's an OpenSUSE micro OS, which is a minimal platform that you can use for single purpose workloads or specialized workloads and things like that. That's a rolling but stable platform built on Tumbleweed. There's also now a micro OS desktop, which lets you do this by your single purpose being a desktop computer.

And then applications would generally be shipped in the form of flat packs and layered on top of it that way. Right, right. So, yeah, we could totally see a future where, like Fedora with Silver, Blue, and Kinoite, you will see microOS desktop GNOME and KDE doing the same thing. Yeah. Colonel, I see you joking in the chat room, but I think there's some seriousness. You're like, you're okay with this, but not if it's Snap.

So we're okay with Flatpaks, Colonel, but not if it's Snap. So we're okay with Flatpaks kernel, but not Snap doing this. I'm fine if distros want to start shipping applications via Flatpak, because the Flatpaks, especially on Fedora, and I haven't used them on OpenSUSE, but at least in Fedora, they integrate in well. There's no real performance hit, and there are certain applications that I actually prefer to be in a Flatpak because it's proprietary software, and I like that sandboxing around that. My issue with Snaps is that, A, they don't work well on distros that don't have AppArmor by default. They don't work well with SELinux. And the other issue I have with Sn snaps is that regardless of the distro,

you're always talking back to Canonical. Well, okay. But aren't all of those concerns and complaints irrelevant if you're on Ubuntu? Because Ubuntu is already checking back with Canonical to check for updates. Ubuntu isn't going to have some of those integration issues because it will have AppArmor and all the components necessary to run snaps. Isn't it sort of validating the idea that there is actually some utility in moving away from the distribution's core package manager, which by the way, not actually sure I agree with. But anyways, isn't other distributions attempting to do this with Flatpak sort of validating what Canonical tried to do early with snaps? I think it really depends on that particular piece of software. If it's a piece of software

that is either proprietary, or it's a piece of software that pulls in proprietary components, or it's a piece of software that's difficult to build and maintain for the distro, I think a containerized solution in that case makes sense. Yeah. If it's something like Firefox or it's, you know, the desktop environment or it's something else that's either heavily integrated in with your user experience and the distro or it's very easily built and it's open source, I personally would prefer to have those maintained and in the repos. Yeah. I think that's how I fall down on it too, pretty much.

Well, it's an interesting development and I could see the utility of it for certain applications. Some that in the past, maybe you had to add specific repos for and then install a bunch of dependencies. It remains a problem that needs a little bit of solving. As somebody who's been trying to make Fedora work kind of to some futility because I just can't get my hands on some software still, I appreciate this is not a problem that is fully solved by repositories alone, and there needs to be some other solution in here.

But while we're talking about flat packs, for you parents or maybe anybody out there who's a Minecraft fan, there's this Bedrock edition that Microsoft created that is basically a utopia of Microsoft components, ties in nicely with their store and Windows 10. And it's really one of those kind of transitions that, for my kids, has been extremely tempting. They traditionally use what is the standard version of Minecraft, the Java Edition, which has a huge community, tons of mods, years of history. But Microsoft, you know, they couldn't have that.

Something about embracing and extending? I'm not sure. Yeah. So the Bedrock edition of Minecraft came along, and that's sort of a rewrite of Minecraft with more integration with Microsoft technologies. And surprise, surprise, there's no Linux version. with more integration with Microsoft technologies. And surprise, surprise, there's no Linux version. And this has been a bit of a point of contention with my kids because they'd like to have access to it

because a lot of their friends on their Windows 10 machines or whatever are playing it. And there isn't really any gaming stream service that offers it because it's a Microsoft game and there's no Microsoft gaming streaming service that offers this via the web browser right now. So I hadn't had a great, did not have a great answer until today when I was browsing Flathub and I saw that there is a Minecraft Bedrock launcher that you can download and play on

Linux. And it's clever because it appears to be using the Android version of this game, but running it on your Linux desktop. Clever indeed. Yeah, and it's early. It's a work in progress, big time. There's still several ways to make it crash and all of that. But the author is continuing to update it,

and it's becoming the unofficial launcher for the Minecraft Bedrock code base. And, you know, they're not affiliated with Microsoft or anything like that, but it shows real potential. And it could be another one of those things that helps me keep the kiddos on Linux, which I'm a big fan of because I hate for these silly App Store games and stuff to be what draws my kids off of a free operating system. And it just sucks to have to also be on the other side and be like, well, I'm sorry, you know, it just doesn't exist on Linux.

Yeah. You can't have access to it. That must feel bad. Yeah, they see it as a deficiency in Linux because their friends, it's just their computer that has Windows on it and it just has this Microsoft Store on it. So I will put a link to that in the show notes or you can just go on Flathub and search for Minecraft Bedrock Launcher

and you'll find it over there. And I'm going to give it a go probably this week. So I'll find out how good it works, I suppose, and maybe I'll report back on it and see if I solve the problem for the kiddos. I think this whole topic was just an excuse so you could play more Minecraft. Linode.com slash unplugged.

Go there to receive a $100 60-day credit towards your new account, and of course, support the show. It lets them know you heard about it here. And it's kind of a way of saying, hey, thanks for supporting my weekly Linux talk show. Linode is the largest independent cloud right there. How awesome is that? Independent still after all these years.

They started in 2003, which is basically before time, before the cloud. I mean, it's just forever ago because they're huge fans of Linux and they saw where things were going in the kernel and in the user space. And they were able to build a company around that. Over the years, they've managed to refine it into a lean, mean cloud hosting machine with native SSDs, 40 gigabit connections to the machines, revamped and easy to use cloud manager that's extremely competitive, fast and very reliable. an easy-to-use cloud manager that's extremely competitive, fast, and very reliable. They have an API that has a command line you can use, which you get really awesome when you're doing like the drop-down terminal thing and you run the Linode command line tool in there. It's a way for interaction with their object storage or for managing your servers. I mean, it's really great. And Linode costs 30 to 50% less than the major cloud providers like AWS or Google or Azure,

which is great because they're an independent Linux company that's been around forever. You get a real good balance of technology and price. They have machines you can pick from that start at $5 a month. And, of course, they have systems with lots of dedicated CPU and memory or GPU. It kind of depends on what you need. They make it really easy to go through and pick. And that's why that $100 credit is freaking great, because you can really play around, see what works best for you.

So go to linode.com slash unplugged, get that $100 60-day credit, and try something out. And if you dig around on their site, you'll find some extremely useful utilities, guides, how-tos, you know, all that kind of stuff. And one I'll throw a link to in the show notes because it was just updated a couple of days ago is the Linux system monitoring fundamentals. This is a great way to wrap your head around what might need to be monitored on a Linux system, what might be the best tool to collect that,

depending on what your needs are, and get a good rundown of the entire thing. It's an example of an area that Linode is always investing in, and we'll have a link to that in the show notes for the Linux system monitoring fundamentals that you can run through and get an idea of maybe what you could be looking at to properly monitor your Linux box. And, of course, they build a lot of those analytics into the dashboard to give you a quick snapshot of that, too, and that's extremely useful as well. So go check them out. Linode.com slash unplug.

Get that $100 60-day credit and a big thank you to everybody who does that and supports the show. It's what makes it possible for us to do this and for us to remain independent. Linode.com slash unplugged. There is some big GNOME developments or GNOME developments this week. GNOME Shell and Mutter have hit a bit of a 40 version milestone with the beta being released and things really kind of coming together. If you can get your hands on the freshest builds of GNOME, you're going to see essentially the almost near final design for the new shell. It's getting real close.

Oh, yeah. In GNOME Shell 40 beta, you'll see the redesign to the overview area. Out-of-date extensions are now disabled by default. Hey, that's nice to see because you don't want a busted and old extension. Plus a wide variety of fixes, just general bug fixes, but also some crash fixes. That's nice. Yeah, really, right? As for Mutter, well, it's now defaulting to starting X-Wayland on demand.

It gained support for atomic mode setting, improved touch mode heuristics, which that's nice too, and, of course, defaulting to the horizontal workspace layout. Burp, burp, burp, burp. Yeah, we're going to talk more about that. Alan Day over at the Gnome, Shell, and Mutter blog did a post just before the show started about the horizontal layout and the

multi-monitor stuff and stick with us here guys because we got to chew on this a little bit because as you know these things tend to have lasting ramifications and so i think it's it's important to note here that the development team for gnome seems to be listening to what people are saying alan Alan writes, MultiMonitor has come up a fair bit in conversations about the GNOME Shell UI changes that are coming in GNOME 40. There has been uncertainty and anxiety in this area. And I just don't think that's an overstatement. I think if you go back a few weeks and you hear my conversation with Carl,

there is some anxiety in how multi-monitor users are going to use these new updates. So he goes on to say, so we wanted to provide more detail on what the multi-monitor experience will be exactly like so people know what to expect. Now, in many key respects, multi-monitor handling in GNOME 40 will be basically identical to how it is in 3.3.8. GNOME 40 still defaults to workspaces only on the primary display, as we've had since 3.0. The top bar in overview will only be shown on the primary display,

and the number of workspaces will still be dynamic. So in many respects, GNOME 40 should feel very similar to previous GNOME versions. But there are still some changes and some unanswered questions about what exactly is changing. Yeah, and that's fair. And there are some good visuals that we'll have linked in this GNOME post. They tried to specifically illustrate

what he's talking about. But the key here is, like Wes said, GNOME 40 will continue to default to only showing one workspace on the primary display. And when you have a dual display setup, the overview on the other screen will be just that workspace. It'll zoom back like the primary display does, and it'll overview all of the screens.

But that workspace on that second screen, that won't change. But they're making some tweaks in how it's displayed, and the team feels like that presentation, the tweaking they're doing, will help people understand with multiple displays how this works more clearly. Now, while workspaces only being on the primary display, as we mentioned, it's the default behavior. Gnome also supports having workspaces on all displays

using the workspaces only on primary settings key. This is pretty similar to how workspaces work with just only on primary configuration, but the main difference is you can see the additional workspaces extending to the right on the secondary display. It's also possible to see that the workspace navigator, that small little set of thumbnails up at the top,

that's now visible on both displays. That's a new change in GNOME 40, and it's intended to hopefully improve the experience for users to actually have workspaces on all displays. I think a few people have pointed out that horizontal workspaces aren't going to work for them. But if you think about it, it is how a lot of the desktop environments do it today already. It's sort of been kind of standard. And what I think needs to now be appreciated, and why we wanted to go through some of these details with you is when Gnome 40 launches, it's going to be kind of controversial.

There'll be different headlines about it. There'll be different hot takes on incumbent threads. And I think it should be reflected in that future conversation that the team listened and made some tweaks and even has some further adjustments they want to make long term. They say, in case there's any doubt, multi-monitor is absolutely a priority for us in the Shell design team. We know that the multi-monitor experience is important to many GNOME users, including many of us who work on GNOME, and it's something that we're committed to improving.

That's a commitment, right, from the top there. I think it's notable and should be considered in the future conversation. Yes, I think the other part here, too, as they mentioned, as Alan mentions, is that we actually have a few plans for multi-monitor improvements in the future, and some of these predate the GNOME 40 work that's currently happening. So there's more in the pipeline. They're hoping to get back to that after all these GNOME 40 changes, but this isn't something new that they just started considering after the feedback.

It's been there the whole time. And then just also in the new stuff department, something that we're going to be telling you more about soon. We have an update on that. And then my plan too, by the way, is to switch to GNOME, win 40 launches, and give it an honest go for a bit. See how things go on the GNOME side for a while. Because I've been living plasma for a long time. I like it a lot. But I want to give this a fair shot. So when GNOME 40 lands, I'm going to make the switch for a bit. Not in protest, but because I want to. But something that I'm

playing with right now, I don't have to wait around for, is Pipewire. Pipewire is getting really exciting, and Wes and I have had an opportunity to use it in a couple of scenarios now in production. And there's a new version that's just been released this week with a lot of stuff landing, I think, Wes,

to get it ready for Fedora 34. Yeah, Pipewire 0.3.22 was released this week. A whole lot of work, yeah, and a lot of that focused around making sure that Fedora 34 can hopefully ship it as default this coming spring. Some of the highlights of this release are per-client configuration files. That's some nice customizability. Support for pro audio cards. Bluetooth audio improvements, better sync. Support for HFP, HF, that profile. And most notably for us, improvements in their jack support.

So I think this is one of the funny things about Pipewire is I think it gets talked a lot about as a jack replacement. But ironically, one of the things that Wes and I are finding best about Pipewire is how it plugs into existing jack tools and makes it even simpler and more reliable and easier in a lot of ways to use. It really unifies the desktop Linux audio scene. Suddenly you can use these jack tools with regular Pulse audio apps. You don't have to convert everything over. Pipewire brings them all together. It's been pretty exciting.

And I'll save it because we have more to talk about on that front. We should probably wait and do our due diligence and do a little cleaning up around here. We do have some housekeeping, just a few things to let you know about to keep the show on the road. And that, first and foremost, is we love hearing from you. We love it when you can participate in the conversation outside just when the show is live or just when the show is released. That conversation, it's always rolling in our Telegram group at jupiterbroadcasting.com slash Telegram.

And then additionally, check out the Luplug on Sunday. It goes down at noon Pacific, 3 p.m. Eastern. On Sundays, we have the details at linuxunplugged.com slash mumble if you want to get connected. And I wanted to mention something about this. I'm not really a big social person. I don't generally go out and hang out at a bar and socialize. Generally, when I'm off air, I kind of keep to myself.

You're hiding away in the woods. Right. But I still get a lot of enjoyment and fulfillment out of attending the Leplug. It's nice to hang out with people who know what you're talking about and are excited about the same stuff you're excited about. And they always either have just a conversation that it's open and everybody can jump in or sometimes they have presentations happening too. Things are always in the works. So I encourage you to join on Sundays, and we have that up on the calendar to get it in your local time at jupiterbroadcasting.com slash calendar.

Also, over there on our website, we have the all-shows feed, so you can subscribe and get all of those shows. We have some really great stuff in the works for Coda Radio and self-hosted. And, of course, we just mentioned a killer Linux action news that went out this week. So why not make it easy on yourself? Get the all-shows feed, and then you just get everything in one solid feed. Mr. Payne, is there anything else we need to clean up around here? No, it looks pretty tidy to me.

Thank you. Just set that bag over there, okay? Appreciate it. Let's take a moment and thank a cloud guru for sponsoring this episode of Linux Unplugged. And there is a special opportunity right now. You can save 20% on ACG's annual plans. 20% when you use the promo code SPRINGINTOCLOUD21. All one word. You know the cloud's growing. I mean, we see it around us all the time. And of course, that means there's demand for skilled cloud professionals, and that's increasing all the time. 82% of hiring managers say that cloud certificates make a candidate more attractive for hiring.

So maybe it's time to go keep modern, keep up to date, and grow your skills and your career. Get 20% off the most effective and hands-on cloud learning. Keep up with change and develop the new effective and hands-on cloud learning. Keep up with change and develop the new skills you need at A Cloud Guru. So get 25% off, go to acloudguru.com and use the annual promo code SPRINGINTOCLOUD21. 95% of their learners say that their tools and content directly helped advance their career. 95%! And you can get an annual plan for 20% off. Spring into cloud, 21.

We got an email into the show that we thought we should hold and maybe make into a wider conversation. Because it's a bigger question, and the longer you use Linux, the more opportunities you have to be tempted by the fruit of another. And so we thought, let's have a conversation about how we stick with it. How do we manage to stick it out? Sometimes it's hard. Yeah. Takes work. Right, right. And so this email from John, listener John, came into the show and we realized it was really about two things. How do we stick with Linux on the long haul when we get tempted? And what's the current snapshot of media production on Linux and some of those tools that seem so tempting by the other platforms?

How are we doing on the Linux side? And there, of course, have been some big boosts recently that have landed for Linux content creators that we haven't really talked about much on air in one cohesive piece. So we thought, you know, our buddy Drew, perfect guy to tackle this, right? I mean, this is his sweet spot right here. He's gone above and beyond in the past to stick with Linux. He's documented that before on Joe's Late Night Linux Extra. And he's also mastered audio editing and mixing on Linux. So he's really kind of in this area. So we called him up last night to chat about this. And Virtual Lug, I want

you to listen along and then flag me in the chat with your thoughts. And then we're going to follow up after this chat with Drew and expand on it a little bit. So we'll go back in time to last night when we called up Drew. Hey, guys. How you doing? It's been a minute, and this really felt like it was in your wheelhouse. Are you ready to help us solve a couple of particular problems? I will certainly try. I'll do my best here.

No promises, of course. No, it's just all resting on your shoulders. And it goes like this. John writes into the show, Greeting, lepers. Do you sometimes wonder if it's time to give up on Linux as your daily driver? I'm no stranger to Linux, having built a PC with bespoke components in 1995 so that I could run Slackware 1.0 on a 15-inch CRT monitor.

But I've used the Mac exclusively since 2000. After starting a new job in a window shop in 2008, I just didn't feel like spending the money to go upgrade to a new MacBook Pro. So I found myself exploring desktop environments. But about a year ago, I bought a System76 Lemur Pro running Pop! OS. And here's my dilemma. I love my Lemur Pro. I love it. But since getting it, I've decided maybe I'd return to podcasting.

And that's where things have become a problem. I find that I need to run a VM for certain audio applications frequently. It started with Descript, then the Rodecaster Pro utilities, the Hindenburg Journalist Pro, and I just find myself in Windows more often than I would like. And I hate Windows. Sure, there are plenty of digital audio workstations out there available for Linux, but Descript? Descript will probably never be available. And it's just amazing how much faster Descript is than a traditional editor. And at what point do I just give up? What point do I just give up and return to a mainstream desktop? Is it when I have two apps in a VM? Is it three

apps in a VM? Where's the line? And what do you guys think? Thanks in advance, and I'm interested to hear your thoughts. Now, I thought, Drew, this is really two questions. This is, how do you stick with Linux when things get a little tough? And how do you produce content on Linux? And I was curious to get your take on both of these, because obviously they're right in your wheelhouse. Okay, so first things first. Honestly, use the tool that is the most comfortable and the best for you. Yes, you can do all of this on Linux.

But if you absolutely have to have Descript or whatever other tool that only runs on Windows, and that's the only way you want to do it, just do it on Windows. Nothing's stopping you. I mean, yeah, if you hate Windows and you don't want to be going back and forth into a VM or dual booting or whatever, you can certainly do it on Linux. The way I do it is with Reaper. I also use Yabridge for some Windows VSTs that I quite like, and they run great on Linux. And I have set up my Reaper with so many keyboard shortcuts and macros, I don't even remember what the defaults are anymore. And those make me considerably faster than I would be in something like Ardor or what have you. So I don't know. I mean, I want to say,

yeah, do it all on Linux. But at the same time, it's like, well, if Descript is really that important to your workflow, if this other tool is that important to your workflow, use the best tool that you have available to you. It also seems like there's maybe a trade-off of how invested do you want to be in playing with that tooling? As you said, you've spent a lot of time customizing Reaper to work well for you, and you've also definitely learned the ins and outs of working with Wine, making things like Yawbridge work nicely, but that might not be interesting enough or worthwhile enough if folks just want to concentrate on whatever that

application is. Oh, for sure. I mean, I had the privilege of working in a job where I could work on this stuff all day and get paid to figure out how to do this stuff on Linux. So that certainly helped. But if that's not your jam, then it's not your jam. There's no shame in that. Here's where I think the struggle comes in. Because if you and I were having this conversation, you'd tell me just suck it up and use Reaper on Linux is what you'd actually, that's what you'd really say to me. But here's where the problem is. So let's focus in on Descript because it's a really good example.

Let's focus in on Descript because it's a really good example. Descript is a new kind of audio editor that uses a cloud component to analyze audio and create and generate a transcript. And then it allows you to edit the audio like you would edit a text document. So you edit the transcript, and on the back end, the application does audio editing. and on the back end, the application does audio editing. But what's even more incredible is, of course, this is going to have, just full disclaimer, probably very, very poor results compared to someone who knows how to edit. But something else it offers is you can actually copy and paste text, and it will generate the audio of you saying those things based on what its machine learning has figured out from how you spoke the other words, and it can actually generate you saying the or adding a word into an audio track.

Yeah, it's pretty remarkable. The use case that even for this podcast right here would be you download a two-hour talk from, say, Fostalk or from LinuxFest or from whatever event that might be. Maybe somebody you love is up there doing something or has some topic that you want to know more about. You could download it into this Descript editor. It would generate a transcript of the entire thing for you, which is fairly accurate and getting better all the time. This is a tool that is being used at some scale right now. So it's not like it's vaporware. And you could just search the document for the section of the talk that we wanted, like somebody maybe talking specifically about a component for three minutes in a two-hour talk, and I could grab that audio for the show that way. I mean, it's a very compelling tool.

The problem is it only works on the Mac, and I don't want to run on the Mac. And the Mac is a pain in the ass to virtualize. The Macs are extremely expensive. Mac OS really locks you in. I want to use Linux for everything else, but from time to time, there's tools like this that have come along,

and you've got to acknowledge this must have hit you at some point too, Drew, where at some point in the last decade, a tool's come along that's only available on another platform, and it's tugged at your, oh, maybe I should consider getting a Mac, or maybe I should consider installing Windows, or it's tugged on that thing that tempts you to leave the Linux platform. And I'm curious what you've done in those situations.

Like, did you explore it and then come back? Or did you find a way to stick with Linux? That's a tricky question for me, because remember, I'm coming from doing rock and roll and live shows for years and years and years, right? So I was used to real hardware mixers and outboard compression gear and stuff like that. So for me, it's less about, oh, this tool is really cool and more, I need it to sound this way. How do I get there? So I'm a little less of like, oh, it's got to be this one specific tool and more, I just need it to do what I need it to do.

And it turns out there's a wide variety of plugins that work really well on Linux. And sure, I use some Windows stuff because it works really well and I like the way it's designed and it sounds great and all of that, but I can still do it on Linux through Winebridge. So no, I haven't really gone out and said, oh, well, you know, I need to be using this tool that's only on Mac or that's only on Windows because it's just not that interesting to me. I'd rather use what I'm more comfortable with and find a tool that will do what I want it to do in the platform I'm on. But I'm also, you know, weird that way. What about you, Wes?

Have you ever wandered away from Linux for a bit and then found your way back? I mean, I definitely have had more VMs in the past. I think partly, and this is definitely a position of privilege, but I tend to try to avoid things like that if I can. And I'll be the first to admit, sometimes that means I'm using a worse solution. This is in a different space entirely, but Plex is kind of one of those things. I mean, I have a Plex account. I watch stuff on Plex from people's shares, but I've kind of purposefully avoided really investing all in because I knew that there were open source solutions and I was

willing to make that work. Doesn't mean I don't appreciate some of the nicer aspects that some of these more proprietary products might have, but maybe to Drew's point, if I can focus on the goal that I have and then evaluate the tools, and if it meets that goal enough, and it makes me comfortable, and it's on the system that it already works, I kind of just try to focus on that.

Yeah. I feel like what John is hitting up against when he writes in is he switched back to Linux, he got the Lemur, and then he's like, man, this thing's powerful. I could produce an entire podcast on this thing. And when you haven't been on Linux for a while, or you're new to it, you don't really have a lot of knowledge to pull from. And so the first solutions that start coming to you are going to be from the platforms you're most familiar with. So if you spent the most time

on Mac and Windows, well, you're going to kind of almost already know what direction to go in for those platforms and not really know where to even start with Linux. Right.

You framed it in the terms of how the problem would be on Mac and Windows even. Yeah, yeah. And I totally get that too when you're just trying to get something done. And I think that's where

Drew's overall point is really a sound one, is don't feel guilty about it. Use the right tool for the job. I mean, maybe it means you end up using Linux for 80% of your desktop use, but you have a laptop that runs another operating system that you use for another tool. Yes, that's definitely something we've both explored, too, I think, is, you know, you don't look down on someone who has a piece of hardware audio gear. And yes, a Mac is more of a general purpose computer. And of course, in the Linux and open source world, we have issues with those being locked down. But if you just set it aside as a purpose built, this is how I edit my podcasts, or maybe this is how I do my like outlook for work, and I keep my communications on this, and then I have desktop Linux and all the joys on everything else,

sometimes the compartmentalization can be nice, especially, I would say, invest in making sure that you're not paying a really large tax in switching systems because the second you're like, oh, I've got to unplug cables just to get my Linux desktop back set up to my monitors, that's where it's tempting to stop doing that.

But if you've got it all set up nicely, you've got a KVM switch or whatever, makes it simple to switch to the system you need for the task you want, and then get back to desktop Linux, I find that much easier. Totally, well put. And I'm going to, I'll add this

before we get into some tools here, because that's the second part of this question. But, and I think this is a good spot to transition, but I will just add this, that long-term, if you invest the time to do the production under Linux, that is where the puck is skating to. What we can do now in Linux with Pipewire and Jack and Reaper

and applications like Sonobus are so far beyond what was capable when I started about 15 years ago. That just yesterday, Wes and I were working on something that I was thinking to myself, if I could have told 15-year version of me that there would have been a go, that there would have been something like this, I wouldn't have even understood

how it could have been possible, what Linux can do today. It is advanced so far in media production. And so if you take the time to learn it and you're willing to invest it, and you have that time to invest, eventually it pays off this entire conversation that we're having right now. We're all on Linux, we're all doing it with tools that are integrated into our audio subsystem at a very awesome level that I didn't think would even be possible. And we're

just using it to have this chat right now. It's, It's so cool. So let's talk a little bit about the tools because Drew in there, you mentioned Reaper. He's really liking this Hindenburg journalist audio editor, which kind of is like GarageBand, but for podcasts. And it really blocks things up really nicely. It's a really easy to lay it out kind of podcast. I don't know how it would work if you had, like, eight tracks and it was two hours long, but it seems like it's very approachable. But there are a lot of tools available for Linux today that were only available, that have only been around for a couple of years. So I thought maybe we could hit on a couple of the highlights.

Reaper is obviously one of them, but I think beyond that, it's kind of how you have learned to use the tool. And we should disclaim that Reaper is a digital audio workstation-style editor. It's what we use to use the tool. And we should disclaim that Reaper is a digital audio workstation style editor. It's what we use to record the shows. And it's one of Drew's go-to tools. And we should probably also note that it is proprietary, although very reasonably priced. Yep. So what do you think, Drew, besides just Reaper itself? It's how you use it. There's other tools as well. Give us a snapshot of what you consider to be the state of Linux podcasting tools right now. There are a lot of plugins that are available for Linux,

like directly natively for Linux that you don't even have to put through a bridge. And I know we're going to harp on Reaper a lot, but because it's amazing, they have a bunch of tools in the box that are available for free for Linux, like studio quality compressors, studio quality reverb units, really, really cool stuff that you can use for free. Not even just in Reaper, they release them as VSTs that you can load on your system. They're not the prettiest, but they definitely get the job done. So definitely check out the Reaper plugins, even if you're not using Reaper itself, but you have something that is VST capable. They're great.

Ardor also has a lot of great built-in plugins. There's the CAF plugins, which I don't really like that much, but they've been around forever. They're kind of a staple. I don't really like that much, but they've been around forever. They're kind of a staple. There's the LSP plugins collection, which is fantastic and really good to use. Although I do find they're a little heavy on the CPU. Air Windows is available for Linux.

There's all kinds of stuff out there that can help you with your mixes. As far as editing for podcast production, I don't find Ardor to be very good. Personally, I the editor is not geared towards this kind of production. And it's a lot harder to make it be that way. I edited on that for a long time before Reaper came to Linux. And it's a great editor. In my opinion, it's probably the best multi-track recorder out there. But for editing podcast, it's really hard. It's really slow. It's fair. I completely agree with your take. It's probably better for music production. Yeah. It's great for music production. Seems like it works nice too sometimes, maybe just like setting up for mixing or routing or applying effects live.

Yep. That works nice too sometimes, maybe just like setting up for mixing or routing or applying effects live. Yep. I think we have to also mention what Wes and I are extremely, Drew too, very excited about is Sonobus, which we mentioned last week on the show as an app pick, but we've been using it this week as the method that we communicate. And it is a Linux desktop app, also available for the other desktops and mobile devices. a Linux desktop app, also available for the other desktops and mobile devices, and it's open source and it uses Opus to create a peer-to-peer audio session that is incredible audio quality that integrates in with Jack Audio so we can route it around with everything else that

we route with Jack Audio in our system and bring it directly into our audio editor. This is radio quality grade software. I mean, it sounds incredible. The latency is the best you're going to get. It gives you data that the other tools don't give you. You combine that with Pipewire, which Wes and I have just begun messing with for remote production setups,

and Pipewire brings some functionality. It's like not all of it, but some core functionality that you get from a software on the Mac called Audio Hijack Pro, which is one of those third-party Mac software tools that in the past I've looked at and gone, oh God, I'd love to have that on Linux. I would love to have that. But Pipewire gets a lot of it. What I would need, there's a lot more Audio Hijack can do, but Pipewire is also new. But we were just playing around with it last night where I was able to take the audio output of applications like Firefox and VLC and then route them all into Sonobus using Pipewire and the jack tools that you can use to manipulate some of those settings.

And it means that I could host, I could host like a remote streaming session all on one laptop, recording with separate audio tracks, all routed through Pipewire, going through Sonobus back to the studio. And it just is seamless. It's really awesome stuff. The other part, too, is, you know, some of this stuff was definitely already possible, especially with Jack. But it was a little more complicated than I think you especially were really interested in investing in. You know, you had to manipulate a whole bunch of pulse audio bridges and run some command line stuff. But this was just, you pulled up one tool and you could move audio wherever you wanted. I think I've heard just about every Linux podcaster make a joke about Jack audio being too complicated at some point. You know, it's like, it's a cliche about how complicated Jack is.

Well, and they're not wrong. I mean, Jack is really designed to function like you would route cables in a studio to real hardware. That's the way it's set up. And if you don't have that background and don't want to learn that stuff, you just want it to work. It's not the tool for you. Right.

But yeah, Pipewire is amazing. I've been using it for a few months now and it's only gotten better. You bring things like Pipewire landing in Fedora 34. It's available in just about every distro right now. It's super simple to get up and running in just about any modern distro. You bring Pipewire together with something like Sonobus and a tool like Reaper, and you have everything I needed to build a studio for years ago in a laptop or a desktop, all on Linux, most of it free software with the exception of Reaper. It's just, it's really awesome. So John, it is worth learning because when you do get all the pieces together, what you get is vendor independence. So now your content

production is independent of what Apple does with their processors or their operating system. It's totally separated from Microsoft and the hell of Windows. And it's your desktop environment, your operating system of choice. And then you get all the other great features. So we'll stack WireGuard in on this. So now we're connecting our studio systems via a WireGuard network. And maybe while we're at it, we'll go to a low latency kernel and we'll use a specially tuned ButterFS partition for our recordings. You can start leveraging all of the other technologies in Linux that make Linux great for servers and other desktop workstation use cases that make it also great for audio and video production. And you only get to take advantage of that stuff when you've learned the tools.

And you just, you have to start the journey one step at a time. So hopefully some of this stuff will be useful to you. We will pick Drew's brain and Wes and I will get a collection of our links together for some of these, for some of these different tools and applications we've talked about. And you can take a look at those. We'll have them all linked up at linuxunplugged.com slash 394. you can take a look at those. We'll have them all linked up at linuxunplugged.com slash 394. Thank you to Drew for coming on and helping us sort through that. So I thought we'd have a little confession time with our virtual lug. I know ByteBit and you said that you've had some steps

along the path to sticking with Linux that you wanted to share with the class? Yeah, so what I usually do is check, can I, so the most obvious step is, is there a tool in Linux that can handle the tasks that I want to do? But sadly, that is not always the thing. And usually some specific software is known for that specific function. So you usually need that piece of software.

And then I start to look in, can I run it in Wine? Can I go just a step higher with the crossover from CodeWeavers or stuff like that? Because the issue with going into a virtual machine is, yes, you can do a virtual machine but windows does updates windows does drivers yeah and it's slower it is slower yep but the thing is that once you do need that tool to run on windows and yeah you can do something within the virtual machine but there are also some modes like seamless mode. So where you start

the application within the Windows system, but it has its application window in your Linux box. So that makes the transition a bit easier to work with. And there are also some Windows versions that are more dressed down from functions and other things to run lighter. Well, I know we have more to get to in the post-show, so we will cover some more of those. And, of course, a big thank you to Drew for coming on. He came on late after working, and that was after he spent the weekend patching servers.

And we told him to use a brand new audio tool to join us, which he'd never tried before. But, of course, he's always down to clown because it is pretty fun to play with that stuff. So thanks to Drew as well. Datadog.com slash unplugged. So Datadog is how you see it all. If you have an on-premises setup, if you use

cloud infrastructure, or you use everything in between, you want to visualize it all in one place. So why not something that gives you drag-and-drop dashboards to visualize all of the metrics from the bare Linux stuff up all the way to the application stack in your website.

Datadog is about visualizing the entire stack. Quickly analyze the performance of your Linux servers in real time. These customizable dashboards are beautiful. You got to go to datadog.com slash unplugged

just to check those out. But if you're there, you sign up and you create one dashboard, you can get a free t-shirt as well by going to datadog.com slash unplugged. And of course, you support this show. So when you're there, take a look around and see how Datadog can be used as a tool for you to communicate with your team. And you can set up, of course, alerts and different events that can be pushed into your Slack communications or be sent to different messaging systems that you use. You can integrate

it with whatever tool your team uses. Additionally, Datadog itself has integrations for over 400 technologies. Like just turnkey, now you're getting metrics into Datadog and you're visualizing the entire thing. This is data to make decisions with. This is data to communicate with your team. Datadog.com slash unplugged. Go there, start a free trial, create one dashboard, and get a free Datadog t-shirt. Datadog.com slash unplugged.

And a big thank you to Datadog for building tools to help teams communicate and, of course, for sponsoring this here podcast. We have a really cool pick this week. There's been several ways to go about this problem. And that is, wouldn't it be great if you could take all of the coolness of Proton, which has seen a lot of advancements in running Windows applications, and just use Proton to run everyday Windows apps?

And it turns out you can. Proton Caller. Run any turns out you can. Proton Color. Run any Windows program through Valve's Proton. And Chris, you'll love this. Not only is it already in the AUR, it's powered by Rust. What was that? Hold on, I'm sorry.

Did you say it was powered by Rust? I sure did. I don't know why, but I misunderstood our conversation earlier, and I actually thought you told me, ah, it's too bad it's not using Rust. I just totally misunderstood you. And so I'm actually legitimately surprised this is a Rust app. Yeah, and there have been a couple of weird ways to do this,

but Proton is so neat, and it's seen so much development. So wouldn't it be great if you could use it to run, you know, an application, perhaps a Windows application that needs some 3D support? Yeah, and I'll admit, Proton's a little bit of a black box. You know, I click the button, maybe I have to change the version sometimes, and then I just cross my fingers and hope the game runs. It's cool that

this sort of exposes things for you. You can specify what Proton version to use on the command line, or even point it to your Steam apps folder where there's all the juicy details. And it's all open source online. Of course, right now there are no releases, binary releases available. Easiest way to get it is the AUR,

but they've got build instructions. You just need cargo. Yeah, I mean, that way you get to feel accomplished for the day. What did you say that name was again, Wes? Proton Collar. Proton Collar. There you go. It needs an echo effect as well.

That's pretty neat. We'll have a link to that. Everything is linked at linuxunplugged.com slash 394. Thank you to our Unplugged Core contributors. You are our core. That's why we call you that. You are the core of this show, and you keep us going. Unpluggedcore.com.

Help us stay independent. Reduce the ad load needed for this year's show. And, of course, you get two feeds, limited ad version of the show, same full production, just limited ads, or get the full thing, the live stream. You know, that one's fun because you hear all of our friends show up. They show up and we say, oh, hi, hey, Bray, good to see you.

You know, everybody kind of, you hear everybody kind of shuffling in for the day and us, you know, grousing about stuff. It's a whole additional show. It's just really relaxed and chill, plus a bunch of the post-show stuff. So you get access to either one of those. And also that second feed,

we try to get that out pronto after the show. So it's another way to get it right away. If that works better for your afternoon commute. Also, we'd love to hear from you. So head over to our website, linuxunplugged.com. There you'll find links to Matrix. You'll find links to, I don't know, the contact form, you know, good old traditional email. It's like new again. You should try it. And also, of course, our Mumble is over there as well. And our LiveTime, that's, well, that's actually a, well, that's a different website now that I think about it. But it always stays the same unless it doesn't because something. You better check.

Yeah, you better check. JupiterBroadcasting.com slash calendar. But we try to do it on a Tuesday. See you next week. Same bad time, same bad station. And, of course, you can find the show on Twitter at Linux Unplugged. The network is at Jupiter Signal and all of our fantastic shows, whole family of shows, all having a big hug over at jupiterbroadcasting.com. Do make it live if

you can, because then you can participate and you can get your word into the show. We'd love to have you do that. You can find information at our website. Thanks so much for joining us in this week's episode of this here unplugged program. I'm going to get out of here and go play with Sonobos and Pipewire. I am like totally jazzed. You guys got to watch out because I'm not going to stop talking about it. It's that exciting. I think you might mean you're totally jacked. I see what you did there. See you next Tuesday. might mean you're totally jacked. Ah, I see what you did there. See you next Tuesday! All right, let's go boat. I know what I want to call it. I know what I want to call it.

I know what I want to call it. Thank you, everybody, for being here. Colonel, did you want to get your Linux story in before we wrap up today? Yeah, so one of my classes in college, the professor said, no, you can't write things in LibreOffice. You have to do it in Word. Because I would save things out in the 1003 Word format. And he's like, no, you can't do that. And I go, okay, here's the requirements for the class.

Because all of my college, all of the classes, they have a list of here's your required textbook and your required software and et cetera, for a class. And I was like, where is it on this list? And he goes, well, I didn't put it on there because I thought everybody would just use Office. And I was like, where is it on this list? And he goes, well, I didn't put it on there because I thought everybody would just use Office. And I go, well, when you want to put it on that list which you can't change during the class, then okay, fine. And I basically said, screw him.

And then the other one I've had is the way that I actually use Windows because I do have some classes that I actually have to take screenshots of Windows applications and stuff. And I have a VM of Windows that I install it, I activate it, I run the updates, and that's it. And then I will clone it, take away its internet connection, do whatever configurations I need, use that for that semester, and blow it away at the end of the semester. I have found that with Windows 10, if you take away its internet connection, it runs way better. All of a sudden, it runs fine. But if you give it an internet connection, it hangs. That's classic, isn't it? All right, I have something I have to get off my chest.

The Fedora experiment has come to an end on the ThinkPad, and it's running Arch again, and it's glorious. I thought I'd make it to 34, but it simply just came down to software availability for Fedora is just not quite there for the kind of things that I need because I need these weird esoteric thing that maybe only a couple of hundred people have. Chris, you could have used the Snap. No, I can't because the Snap supports an older version of Jack,

Jack 1, and I need Jack 2 support. But you see, it's not one piece of software. So Sonobus is what Neil's referring to, but it's actually several pieces of software. And what I will do is next time I take a go at Fedora, what I will do is I will, I will first learn how to make a copper repository for the software that I need. Oh my gosh, you're going to finally do it? Well, because that's clearly the missing piece. I think you have to at this point. Yeah. Either you engage with the packaging system.

We were chatting with Drew last night, and there was no Sonobus package at all for Fedora. It's kind of sad too, because it's this incredible new piece of production software, and Fedora's totally left out. And Drew just coppered it up, and has it ready to go, and he's able to do that with the tools that he needs for

all of his production stuff, to make Fedora work for him. And he's had to do a considerable amount of the lifting on his own, but it seems like it's doable. My only concern is that I feel like it's likely to be one of those tasks where there is a variable amount of effort, i.e. some things are going to be a real pain in the butt to copper up and other things are going to be really straightforward and simple. And fundamentally, what it comes down to is justifying how I spend my time

because I could spend my time figuring out how complicated this weird esoteric audio recorder for pulse is, or I could just yay-s audio-recorder, and I have it and I can record the stream that I already have up on my computer paused waiting to get recorded. And that's where at the end of the day, it just doesn't end up working out for me because I do that math. And I think I need to learn how to do these things so that way I can bring software over. But even if I learn, I'm not going to stop mid-flow of a task that is to accomplish something else for a production just so that way I can then package an application so that way I can use it on the esoteric distribution that I've chosen to use when I can either just run Ubuntu or I could run Arch

or any of the Ubuntu derivatives, obviously. And the problem is preemptively solved for me. And it saves me time at multiple iterations because every time a package comes up, like this thing we just talked about today, already available in the AUR, I can install it right now and I can have an opinion about it on the show. I can actually have hands-on experience with something, or I can spend my time packaging, and it just doesn't really seem to make sense to me. It's not that I don't want to learn how to do it. It's just that's the math of the situation right now. Sure. But Chris, you could also, when you're making those copper things, you could also just reference the AUR package build files to be able to speed through actually making them. So how does that work? Tell me about that, because that might be like the hack to make it work. Because if it's in the AUR, then I have a shortcut, it sounds like.

You can't necessarily, at least right now, take a package build file and just run it and it produces you an RPM. However, a package build file and an RPM spec file look very similar in structure. And in many cases, what you can do is that you can, you know, you do vim, you know, foo.spec, and it'll generate you the template because vim has a built-in template for RPM spec files. And you can literally just copy and paste a lot of the commands that are run to actually just go ahead and build it. And then it and push it into Copper, it'll build it, produce you an RPM and have a repo that you can actually, you know, you can show off to others or have other people reference or whatever, and they can run it. Moreover, you can actually build

it for multiple releases of Fedora. You can even technically use Copper to build for OpenSUSE if you'd like. And it's not exactly the same. It's not exactly completely zero effort, but it can get you through it fairly quickly. So here's kind of another element of this. It's like, what speed are you operating at, I feel like. For another example is something I've kind of been talking about on Coder Radio and the live stream for this show is performance and getting my machine faster and maybe getting a faster refresh rate on my monitor and experimenting with the profile sync demon to get my browser cache into RAM, messing around with maybe different types of schedulers or things like that.

And it all seems like it's infinitely easier on Arch than it is on Fedora or other desktops. And I know I heard your recent tirade about how dangerous Arch is. And I frankly, I can't have it. I can't accept that because I'm sitting here, somebody who has enough knowledge to put together a box, but ultimately I just want the tool that saves me time. And I swear right now to you on the mixer sitting in front of me that if Fedora could save me time and make it possible for me to get my job done faster than Arch, I 100% unequivocally with no doubt would use it on every single machine I

have. And it started with my workstation. I tried it there and on my laptop. And over time, even though I struggled not to do it because I didn't want to make the concession, I eventually had to replace it simply because what I want to spend my time on is experimenting with this software and trying things or recording that clip or getting that editing software or quickly installing this esoteric branch of the kernel

to try it for a week so I can talk about it on the show. And I don't want to spend my time figuring out how to go set up a Copper account and how to go wire this hard work that somebody's already done to get it in. I just, none of that sounds appealing to me right now. And I cannot be the only one who has this opinion. And so, you know, you can denigrate Arch for being rolling and for maybe being unsafe for new users.

But for people like me who have been using Linux since the 90s, and I just want a damn workstation that I don't have to fuss with just to get some piece of software going, it's very appealing. And I feel like it doesn't get the credit. Instead, we laugh at, oh, I run Arch, by the way. And we actually have now kind of ganged up on Arch users for being so crazy to run a distribution that they don't have to go through an upgrade cycle every six months. And I feel like it's kind of unfair because it turns out to make an incredibly powerful workstation if you're remotely comfortable with using Linux. And then on top of that, they have really good documentation. Linux. And then on top of that, they have really good documentation. And then if you just go to the AUR and you sort by the most popular applications, you just see it's people trying to solve problems to get their work done. And that's who's installing software from the AUR. It's things like Slack and Zoom. It's not this weird, crazy stuff. It's just people trying to get their jobs done during the day. And I kind of feel like we have cast Arch users as if they're these dangerous influencers who are going to derail new user adoption and prevent Linux from taking off.

And the only way to save them is because package managers will come in and protect them from the dangerous rolling releases. And it's just a shame because I struggled with this and I didn't, because of this opinion, I didn't know how to tackle this on air. And I feel like it produces like this boogeyman out there and it creates a parody of Linux users. And it's just unfortunate. End of rant. Okay. First of all, Chris, I don't have a problem with you running Arch. I am disappointed when you run Arch because it feels like I failed in trying to make things work out well in Fedora for you. But I don't particularly care to make you feel bad or whatever for it. That's not my point. Arch in a lot of sense. The nuance here is there are a lot of people who don't know anything about anything about Linux who try to use Arch because everyone else talks about it as if Arch is easy. I guess I reject that premise. And I think that premise, which I don't think can be proved,

leads to denigrating Arch users and making it actually almost embarrassing to admit that you run Arch. I grant you that in a theoretical world where new people were coming to Linux and they were somehow discovering Arch on their brand new journey, thanks to the magic of Google, that would be a problem. But I just don't really accept that based just solely on the user base numbers of Ubuntu and Mint alone. I'm not saying it's happening universally. I'm saying it happens in places like our Linux. It even happens in places like R, Linux. It even happens in my workplace Slack where people say, you know, Arch is easy, so just go do it.

And then I have people telling me that Arch, because of their experience with Arch, that they hate Linux and they just go back to Windows or macOS. Like, I don't care that you find Arch more comfortable. That's fine if that's the case. I would like to make Fedora better for your use case because I feel you are actually one of those people. But I also want to tackle this other thing where you said, well, you know, these people working in AUR, they're all people trying to solve problems.

You know what? That's pretty much everybody working in every Linux distribution, doing everything that they're doing. That's why Copper exists. That's why Launchpad exists. That's why, you know, PPAs. That's why Copper exists. That's why Launchpad exists. That's why PPAs. That's why OBS. That's why AUR.

All of these systems are for that stuff. Not everything is going to have the required effort to put it into the main distribution. Would it be nice if they're all in there? Sure. Is it going to happen? No. And that's the reason that stuff is all there.

If you take what you're doing and you take the equivalent of just slap together a package build and call it good and everything's available, you can do the same thing and say, I'll slap together a spec file and push it up and call it good. The only difference between AOR and Copper in that respect is one of them you're building locally on your computer and the other one you're not. And my thing about Arch versus everything else is that Arch is very developer centric and the Arch user community themselves have been historically very inhospitable to folks who are very new to the Linux ecosystem. Whether or not that actually winds up being true in your circle, that's a different story. Whether it turns out to be true in the macrocosm, that's a different story.

So I think that would be good. If the experience for new users when they come to Arch is somewhat of a hostile response, that's probably the signal to the new user that that's not the community for them. So that probably kind of reinforces what I say, where it's not really the new user distribution where they land. And here's where I'm kind of getting at, because I actually do, I agree with everything you just said. But where I think it kind of goes off the rails, and this is what gets me kind of fired up about it, because this is where then I struggle with how to talk about this on air, is fundamentally, I think we have created this like shame dome for Arch users. And it's kind of become like this joke, but in reality, we're shaming people. We're shaming people for

choosing to use a distribution. And that's the bit I don't like. I mean, you can make a solid argument for why somebody would want to land on a distribution that is managed versus a distribution that's kind of like a Wild West. That I don't disagree with. But what I disagree with is the characterization that A, it's hostile to new users. It's not for new users. And I don't want to get into a situation where we're advocating to dumb down tools to appease a theoretical user base. I feel like tools should be as powerful as they can be, and then it's up to the distros to create something that's palatable to new users. And there is a market for each kind of user.

And so we shouldn't shame people if they choose to run Gen 2, like we laugh at them now if they run Gen 2 or Arch, because it's solving a problem for them. And just like Fedora and Ubuntu and Mandrake and Mandriva and OpenSUSE, you know, et cetera, et cetera, et cetera, et cetera. And so that's where I feel like we kind of got to right the ship a little bit, is this anti-rhetoric against Arch users is kind of becoming more and more hostile. And to the point where I realized

I didn't even want to admit that I was using it more and more and that I would maybe talk up more about this distro than I would admit that I'm using Arch simply because of this community shaming that's happening. And I feel like that's what has to stop because there's completely valid work problems that it's solving for me. It seems confused too when, like Neil, you spoke about being upset when people make Arch seem easy. There's certainly problems there,

but it seems like in a lot of Linux media, that becomes the focus. And it's when we're often a community of folks that are not new users and are experienced, and we're trying to have one conversation, but it gets dominated by this idea that some folks out there are leading people astray with Arch. And we can be upset at that without having to be upset about the happy community of Arch users who are talking amongst themselves.