LINUX Unplugged - 603: All Your Kernels Belong to Rust

Episode Date: February 24, 2025

There have been major Rust developments in the Linux Kernel; we discuss what's new and how it will impact the future. Plus, we're joined by a special guest.Sponsored By:Tailscale: Tailscale is a programmable networking software that is private and secure by default - get it free on up to 100 devices! 1Password Extended Access Management: 1Password Extended Access Management is a device trust solution for companies with Okta, and they ensure that if a device isn't trusted and secure, it can't log into your cloud apps. River: River is the most trusted place in the U.S. for individuals and businesses to buy, sell, send, and receive Bitcoin. Support LINUX UnpluggedLinks:Get started with River💥 Gets Sats Quick and Easy with Strike📻 LINUX Unplugged on Fountain.FMPlanet Nix - SpeakersSCALE 22xGreg Kroah-Hartman Makes A Compelling Case For New Linux Kernel Drivers To Be Written In Rust — Yes, mixed language codebases are rough, and hard to maintain, but we are kernel developers dammit, we've been maintaining and strengthening Linux for longer than anyone ever thought was going to be possible. We've turned our development model into a well-oiled engineering marvel creating something that no one else has ever been able to accomplish. Adding another language really shouldn't be a problem, we've handled much worse things in the past and we shouldn't give up now on wanting to ensure that our project succeeds for the next 20+ years. We've got to keep pushing forward when confronted with new good ideas, and embrace the people offering to join us in actually doing the work to help make sure that we all succeed together.Kees Cook on Rust in the kernel — In other words, I don't see any reason to focus on replacing existing code -- doing so would actually carry a lot of risk. But writing new stuff in Rust is very effective. Old code is more stable and has fewer bugs already, and yet, we're still going to continue the work of hardening C, because we still need to shake those bugs out. But new code can be written in Rust, and not have any of these classes of bugs at all from day one.Linus Re: Rust kernel policy — You are not forced to take any Rust code, or care about any Rust code in the DMA code. You can ignore it. But "ignore the Rust side" automatically also means that you don't have any say on the Rust side.Texas Linux Fest is back again in 2025!Pick: treetrum/amazon-kindle-bulk-downloader — Allows you to bulk download all your Kindle eBook in a more automated fashion. This tool allows you to create backup copies of the books you've already purchased.Amazon removes your right to download Kindle booksAmazon will stop allowing Kindle book downloads to your PC soonHow to Download Kindle Books to Your Computer Before Amazon Kills the FeatureSimplest Way to Remove DRM from Books – No Kindle Serial Number Needed!Pick: nping — 🏎 Nping mean NB Ping, A Ping Tool in Rust with Real-Time Data and Visualizations

Hello friends and welcome back to your weekly Linux talk show. My name is Chris. My name is Wes. And my name is Brent. Well hey gentlemen, coming up on the show today we're going to really focus on the Linux kernel again. There's been a lot of hoopla about the state of Rust and going on there. So we're going to recap the latest and then dive into what Linus and Greg have said recently. We'll also chat with Hannah from scale, who's going to give us the four on one on what you need to know to go to scale. And then we're going to round out the show with some great boosts,

some picks and a lot more. So before we get to that, I got to do the right thing. And I got to say time appropriate greetings to that do the right thing, and I gotta say time-appropriate greetings to that virtual lug. Hello, Mumble Room. Hello. Hello. Hello, Chris.

Hello, Brian. Hello. Hello. Hello, that's a serious showing. I like it. It's a little echo-y because we had to get a huge room to fit in. Yeah, and a lot of people in there.

Thank you, everybody, for joining us over there. It's nice to have you. And a big good morning to our friends over at Tailscale, tailscale.com slash unplugged. That's where you go to get Tailscale for free. 100 devices, three users, no credit card required. This is a modern networking solution for connecting your devices securely to each other,

your applications, servers, systems, whatever it might be, to each other directly on a mesh network protected by WireGuard. It really is what we've all wanted to see from the moment we heard WireGuard was coming to the Linux kernel. Secure remote access to your systems that just works so intuitively. And it's easy to deploy.

It actually is a zero config, no fuss VPN. I've been running it for years now. You set it up and it just goes. You don't really have to think about it. And with the 100 device plan, you can use it on just about everything you got and support the show. So you go to tailscale.com slash unplugged,

you get it for free on 100 devices, support the show. And then you might do what I did. And I inevitably rolled it out in the company. It's great for your backend infrastructure when you have multiple different data centers and you wanna bring everything together. Thousands of companies do this, like Instacart, Hugging Face, Duolingo, more.

They all use tail scales. So go try it out for yourself or for your business. The free plan is at tailscale.com slash unplugged. Well, as you listen to today's episode, we're going to get into the Linux kernel and we have a question you'd like to answer. Just something put in the back of your mind and when it comes to you as we're talking about this stuff, boost in. If you could be Linus Torvalds for a day, what would you change or get done?

Oh, that's a fun one. Think about that. You know, the pet thing you've always hated in the kernel, the one tweak you'd make, or is it something different? I really, I think we're gonna get some good answers. Whatever it might be though, boost in and let us know. You've been hearing us talk about Planet Nix, and that's coming up really fast, and that runs right along scale.

And so we wanted to get you up to speed on what you need to know if you're going to attend Scale 22x this year. And Hannah from Scale, she is the chair of publicity, joins us to talk about that. Hannah, welcome to the show. It's great to talk to you. Yeah. Thanks so much. I'm so happy to be here to talk about Scale.

We are really close. Scale 22x is coming up on March 6th. That's less than two weeks now. Yeah. And so we wanted to have you on to help everybody kind of know what they need to do in order to attend and what they should do once they get there like on day one. Yeah, of course. So I would be remiss if I didn't give you the quick spiel about what scale is first before how you can attend. Scale stands for the Southern California Linux Expo. We're in our 22nd year and we're hosted in Pasadena, California. And so we're so excited to be back. And if you've never heard of Scale or have not been, it is all things open source.

We're an entirely volunteer run conference. Scale is run on love and passion for open source. And so it is a great time to get together and talk and meet other people who care about all things open source. And the other thing that I absolutely love about Scale is we have been around for a long time. We have great roots in Southern California and beyond. And we also use Scale as a launching pad for other open source communities who might not have the infrastructure or want to plan a conference. So you might see

some of your other favorite open source events co-located at Scale. So DevOps Day LA, Kawhi Summit, Planet Nix, Linux training even. So we have a little bit of everything if you are in the open source world, which I imagine everyone listening here is. So now that we've got kind of the details out of the way, if you want to come to scale, we would love to have you in a little under two weeks. You can go to our website, socallininxexpo.org and get registered. We really pride ourselves on the conference being approachable and I think we're probably one of the only conferences that run a four-day event for under a hundred dollars for a ticket. So we think it's really good value but if you want a little extra motivation to get your ticket before the event you can use the promo code Linux for 50% off that ticket. That's great.

Great, okay, promo code Linux. And so also I just wanna say I do love these site events that have been happening over the last few years. It's such a brilliant idea because you folks really are the experts now at the infrastructure and the event and that is such a massive undertaking for smaller projects or groups or communities to undertake. It's a really incredible thing you're doing.

Yeah, we're quite proud of it. Event planning is no joke, and we have hundreds of volunteers that make this conference run year round, and it would not be possible without volunteers. So another shameless plug is if you ever wanna volunteer and help with the conference, you can always, there's an email on the website

where you can volunteer either the week of, or if you want to work on our network or marketing, shameless plug for my team. We're always taking volunteers to do it. But yeah, we love having other events there that would not have the resources otherwise. So there's a place for everyone who cares about open source here and it's in Pasadena in two weeks. That's great. I feel like too, getting involved like that would really build some skills that could

be marketable in the workplace there. I just want to make it clear, when people show up, they do need to proceed to it like there's a proper registration process and all of that that they need to follow when they first get there or at least get their badges and whatnot, right? Yep. We're a pretty standard conference. You can register for your tickets ahead of time at SoCalLinuxExpo.org with that promo code Linux. And you're all registered,

you will go to the building that says, welcome, there's a big Linux penguin that'll give you an idea of what buildings we're in. The Pasadena Convention Center is a little confusing. It is two buildings with a theater in between. So if you're facing the Convention Center, the building on the right is where you check in your first day. And we've got self-serve systems where you enter your name and your registration number, and it'll print your badge. And then you get a swag bag like most conferences full of open source swag.

And then you get to go in and see all the topics for the four days. So make sure you go to the right side building on your first day, get your badge. And once you have your badge, you can go to all the events throughout the four days. Yep. And then it's easy after that. That's the hardest part is just figuring out which building to go in and get your badge. It's not too bad. I would say the hardest part is picking which talks to go to yeah

really so many good ones that happen all at once and The other good thing about our conference is don't get FOMO because if you have two concurrent talks We stream and record all of them So you can go back and listen to the ones you missed as well also no small feat which we really appreciate too Yeah, the tech on that is insane. It takes dozens and dozens of people all year to get those recordings up, but we're quite proud of them. You can always check out our past talks from events on our YouTube channel as well. So if you're still on the fence, you don't know what kind of content, check out the YouTube channel from the years past. We've got a lot of great content there,

and it gives you an idea of what we're putting on for the week as well. For sure. I will say it never quite captures the social element and the hallway track and going out and having lunch and all that stuff, but that's just the bonus that you get to come discover on your own when you visit. So sounds like they need to get registered. They can use promo code Linux to save some money.

Anything else we need to let folks know? Yeah. Just like you said, like the hallway track is really the highest value add. So if it's your first time coming to scale, introduce yourself. I always hang out at RedGestration, so you're always welcome to say hi to me. So you already have one friend,

but get to know other folks. We love the cross population of communities and it comes to really amazing things outside the conference. So I would really encourage you not to be shy and make some new friends there as well. Absolutely. Hannah, thank you for taking some time on your Sunday and joining us. Yeah, thank you so much for having me and I hope to see everyone listening at scale in March. Wonderful. Well, I know the world is full of news these days, but geez, the Colonel has been seeing

some newsworthy notes from day to day. And you guys have been doing a deep dive, my favorite thing. Should we go through what's been happening and dust them off a little bit? Yeah, we started capturing this for the members in the members bootleg, and then it really has developed further. So let's go back, like Brent says, and kind of just briefly just cover what's happened here. Obviously we've talked about Rust and Linux Kernel a bit. Last September we did an episode about it,

and that was sort of the recap on the state of things. Right, an ongoing effort to, you know, add the ability to write new code, to add drivers to the Linux kernel using Rust, which is a secondary language in the kernel, and it's a big change, and that's why it's been a slow and long effort, and why we're continuing to talk about it. Even the idea of adding another language is a big deal, right?

And of course, you know, you have to say, Rust is not new, but it's still moving fairly fast and does things, it's a very different language than C. So you've got that to contend with. So with our current event, we actually need to go back to late January of 2025 and the Rust DMA patch proposal sparks a bit of a conflict

on the Linux kernel mailing list. A patch is proposed to enable Rust written device drivers to call the Linux kernels core direct memory access or what is referred to as DMA. Obvious drivers need this, right? The goal here to expand Rust's usability within the kernel. Christopher Hillwig though had some I would say concerns and probably raised the largest rejection. There's a quote from him that says, no Rust code in kernel slash DMA, please. Yeah, there's a lot to digest here.

For the first part, you know, fairly simple patch, not a huge amount. Three files changed, 273 insertions in the text of the commit or the request reads, add a simple DMA coherent allocator Rust abstraction. And that abstraction has a specific meaning here. There's sort of the automatic bindings that get generated to be able to like talk to the C data structures from the Rust side of things. But then there's the like the higher layer part of really using Rust and Rust type system in what they're calling abstractions,

which is where you do the work to wrap the C-side at a semantic level to sort of encode how to safely use where possible the C-side from Rust so then you have this abstraction layer that kind of sit between. And it's actually, for the most part, for non-exceptional cases, you're not even allowed to go call the C directly in drivers. You're not supposed to. You want to use this abstraction. So that's where this code is trying to sort of

bridge the gap to enable downstream Rust things to be able to use the bus, the DMA bus. And that's the idea is that downstream Rust things could read the DMA bus. And the very events that transpired this week come back to this very patch and this very discussion. So this event that happens in January is pretty noteworthy as time goes on,

the discussion kind of escalates. You'll see this, there's several people in there that are kind of anti-rust, there's folks in there trying to explain stuff, there's other folks that seem to be just kind of in a watch and see mode. Maybe it's worth also touching on, kind of in a watch in C mode. Maybe it's worth also touching on, as you said, Helwig said no rust code in kernel slash

DMA. And what that's referring to is sort of the various trees inside the kernel source tree itself. So that's, we'll see coming back to this already, if you just look at the diff, you know, how you view whether it's a part of the subsystem or not versus like where it lives in the source tree could be a whole separate question, but this was all under Rust slash at the top layer. So it's all kind of in the rust tree in its own.

It is, of course, wrapping code that lives in the DMA side, but yes. And so it's in its own contained area. That is important to understand later. So this kind of brews for a bit. You know, there's there's FOSDEM. There's a talk about Rust for Linux there held by Miguel Odesia. Is that? Oyeada?

Oyeada. And he's the lead maintainer of Rust for Linux. He presented at FOSDEM. He highlighted there some of the progress and some of the things that landed in Linux 6.13. Also tried to go and get, I believe, a bunch of quotes from various maintainers, both neutral for and against.

I think it did seem to have, he's able to get more responses from people interested in the project, but it was an interesting survey. As you can imagine, though, after that talk, the debate kind of heats up again until later on, Linus and Hector Martin kind of start to get into it. And Hector Martin takes to social media

to call out the process as being, you know, just really hard on the contributors who were trying to get Rust in the Linux kernel. That very act sparks a debate on the Linux mailing list about social brigading and trying to influence the kernel process through social media posts. Linus steps in, says this is essentially social brigading, says it pushes him away from supporting the patch, says to Hector, maybe the problem is you.

And that got quite a bit of attention just a couple of weeks ago. To kind of try to take us from the dust up over that to actual like tangible policy Miguel introduced what he's calling on February 11th the Rust kernel policy which is meant to clarify how rush should integrate with the kernel hoping to reduce tensions yeah he wrote given the discussions in the last days I decided to publish this page with what our understanding is. Hope it helps to clarify things. Did it clarify things, Wes?

Well, that probably depends on who you ask. There was obviously some pushback. But maybe it's worth looking at kind of like what it was. Yeah. You know, it had some points about like, who's pushing this? It's not the Rust project or the foundation or even necessarily there are companies interested,

but it's like its own, there are kernel contributors who want to add Rust. Then it mentions some key folks, maintainers, other people that are involved. Here's some quotes. Some subsystems may decide they do not want to have Rust code for the time being, typically for bandwidth reasons. This is fine and expected.

Now, in the kernel maintainer summit 2022, we asked for flexibility when the time comes that a major user of Rust in the kernel requires key APIs for which the maintainer may not be able to maintain Rust abstractions for it. This flexibility is the needed counterpart to the ability of maintainers to decide whether they want to allow rust or not. It also says some stuff about what happens if things break.

So on their FAQ, who's responsible if a C change breaks a build with rust enabled? That has been a big contentious question, right? Well, this site's position, their understanding is, the usual kernel policy applies. So by default, changes should not be introduced if they are known to break the build, including Rust. However, exceptionally for Rust, a subsystem may allow to temporarily break Rust code.

The intention is to facilitate friendly adoption of Rust in a subsystem without introducing a burden to existing maintainers who may be working on urgent fixes for the seaside. That feels like a big compromise from the rust side where they're essentially saying we're willing to let rust code break for a while and we'll try to sort it out if it just means the seaside will roll with us here. That's a big give. And you've seen various versions too, right?

Like that's where there's, you know, some subsystem maintainers are interested in figuring out some of the Rust stuff for themselves. Other ones appoint like a co-maintainer or like a you're maintaining the Rust side of this subsystem while I'm gonna do the C side or all kinds of other mixes. And some of this flexibility on both sides, at least as some people felt was kind of an agreement before

was to accommodate all of that. And the idea would be if the rust code does break, you actually fix it before it gets to Linus's tree, and it actually ships. It's not like you ship broken rust code. There's an idea that gets caught, but that is still a pretty big compromise. Now, there are concerns with some of this in practice,

particularly around like, okay, you say it's fine to break it, but am I gonna get yelled at still? And like- Who knows it's even broken? You have to make sure that you've set up, and I don't think they're not doing this, but just, you know, you have to make sure you've set up like who do you then, if we've all agreed you're not gonna fix it, but it being broken is a problem,

then like who is actually in practice fixing it? Yeah. Helwig also said, I don't think having a webpage in any form is useful. If you want it to be valid, it has to be in the kernel tree and widely agreed on. It also states factually incorrect information. E.g. some subsystems may decide they do not want to have Rust code for the time being. We read that.

Halloween continues, while Linus in private said that he absolutely is going to merge Rust code over a maintainer subjection. Yeah. And this has been sort of the one of the complaints has been mixed messaging here, like, oh, it's a maintainer's choice, but also I am going to be publishing Rust code. Helwig's been kind of emerging as maybe the most vocal critic of Rust getting in and I think has probably raised

the most points in the most recent rounds of going back and forth. And he's kind of calling out Linus here. He says, quote, yeah, like you said, while Linus in private said that he absolutely is going to merge Rust code over a maintainer's objection, he says this is a very dishonest way of communication. Yeah, and that was pointed at Miguel over including that quote about you don't have

to take it. Right. And that's where there's a bunch of nuance and we'll eventually see, spoilers, that Linus sort of does eventually chime in. But I think there has been a question in many folks' minds of like, where, you know, has there been enough communication? We've seen Greg Cage chime in a few times in various small ways, especially to clarify stuff about, oh, what was broken in this previous case that people were pointing to at one time.

You know, while this is going on, right, so we start in January, we're mid-February right now, maintainers are hitting a wall. Hector Martin resigns, right, burns out, disappointed with leadership in the kernel. Frustrated with their approach to Rust integration. Ceases maintaining upstream Linux kernel code for the ARM stuff. You know, the Solly project has to rework that now. We've seen others that burned out. Like that is, so you understand the context and the background while all of this is sort

of playing out. While also at the same time, publicly, Greg and Linus kind of would from time to time save fairly pro-Rust stuff. Even though this is super heated debates happening in the background during all of this, you know, you'd see comments from both of them saying, Oh yeah, no, Rust is coming. Yeah. And I think there has been maybe some lack of clarity in general, or at least

there's been some confusion around the like, okay, so it's clear that Rust has been kind of an experiment in the kernel. But to some people's mind, experiment means it's not been like, like we're not doing it. Whereas I think maybe in some of the higher up maintainers minds, experiment means, well, we don't know how we're doing it and we're figuring out the right way to do it. And it may be painful and break things, but like in general, we're doing it. We may decide we ultimately don't want to do it and stop doing it, but for the moment, we're doing it and we're figuring out the right way to do it and it may be painful and break things but like in general We're doing it. We may decide we ultimately don't want to do it and stop doing it. But for the moment we're doing it I gotta say one of the debates and it's just like a hard line is we just should not have a Multilanguage project like this

We should not just introduce for us. This is gonna make it hard to maintain. This is gonna make it more of a bear We should just improve the C stuff if we want if want, we should go back and retrofit that. And I think what they're ultimately pushing back on is, well, where do you draw the line? Do you completely rewrite the Linux kernel one day in Rust? Is that where this leads to? Every time we find a bug now, are we just gonna write a Rust version

and essentially this is gonna become a Rust kernel? They don't want that, that's ridiculous. We should just fix the problems in C is what they're, I'm sure you've seen that opinion in the mailing list. Yeah, well, and I think it's also like, it means you have to have double the infrastructure. You're now at some point maybe become dependent on the right version of cargo.

And you can just imagine, right, if you are a maintainer who spent years knowing the ins and outs of, you know, how to maintain a complicated and important C project, even if you can, you know, even if you're willing to take like a co-maintainer path, it's a lot of trust, it's a lot of change, and you are gonna have code that's either making, you know, has expectations of you or is directly interfacing with code that you're using that you don't maybe have a full understanding of and that's Imagine a situation where you're trying to push a feature and it does break something in Rust and now you're kind of trying to

Be polite so you're trying to wait for the rust stuff to get fixed But now maybe you've missed the merge window like you can understand there There is a little bit of concern there that does seem legitimate and that's where this is You know a complicated question because it is ultimately one, like most things in the real world, of trade-offs. There are real costs to having multiple languages, regardless of the language. And there's real costs for the Rust in particulars,

and it's a big change. But what the Rust for Linux folks, and as we'll see some others, are advocating is that especially maybe if we focus this on net new code and new drivers in particular, there's a lot of upside and a lot of wins that can help the kernel overall. One password dot com slash unplugged. That's the number one password dot com slash unplugged all lowercase.

And you're going to want to go there because this is something that if I had when I still worked in IT, I think it would have sustained me for many, many more years. The reality is your end users don't, and I mean without exception, work on only company-owned devices, applications, and services. Maybe you get lucky and they mostly do, but I don't find that to be the reality today. And so the next question becomes, how do you actually keep your company's data safe when it's sitting on all of these unmanaged apps and devices? Well, that's where OnePassword has an answer. It's extended access management.

OnePassword extended access management helps you secure every sign-on for every app on every device because it solves the problems that your traditional IAMs and MDMs just can't touch. And it's the first security solution that brings unmanaged devices and applications and identities under your control. It ensures that every credential is strong and protected.

Every device is known and healthy, and every app is visible. This is some powerful stuff, and it's available for companies that use Okta or Microsoft Entra, and it's in beta for Google Workspace customers too. OnePassword changed the game for password management, and now they're taking everything they've learned there and expanding it to the login level and the application level.

You know what a difference it makes when people have proper password management. Now let's have proper login management and authorization. OnePassword also has regular third party audits and the industry's largest bug bounty. They exceed the standards set by others. They really do. So go secure every app, every device, and every identity.

Even the unmanaged ones. You just go to onepassword.com slash unplugged. All over case. That's onepassword.com slash unplugged. All over case, that's onepassword.com slash unplugged. Now with all this happening, Greg and also Linus did chime in just a few days ago. Greg came in with a rather compelling case actually for new drivers at least to be written in roughs

like Wes was saying. He says quote, yes, for new drivers, at least, to be written in rough, like Wes was saying. He says, quote, Yes, mixed language codebases are rough and hard to maintain. But we're kernel developers, dammit. We have been maintaining and strengthening Linux for longer than anyone ever thought was going to be possible. We have turned our development model into a well oiled engineering marvel, creating something that no one else has ever been able to accomplish. Adding another language really shouldn't be a problem. We've handled much worse things in the past and we shouldn't give up now on wanting to ensure that our project succeeds for the next 20 plus years. We've got to keep

pushing forward when confronted with a new good ideas and embrace the people offering to join us actually doing the work to help make sure that we all succeed together. Yeah, I like that. I really think Greg's done some good, just sort of on the edges and a little stronger here, but just with a very nice tone. It's so positive.

It makes you want to go help make Linux better yourself. And I think it's right to call out that, whether you agree with the mission or not, you have to agree that the rest of Linux folks are trying hard. You know, I noticed, I think it was a week or two ago, uh, and they're working on the FO bus and Greg posted on Masto about it. And he made sure to call out, you know, from the get go, this has rust API bindings. It's ready to go for the rust crew.

We're introducing a seaside and a rough side and it's good. Try out the FOBUS. Well, I think that's been influenced, not some small amount, by, you know, he's been super involved with, you know, maintaining the stable side of things and dealing now with the kernel CVE process. So he started that post by saying, as someone who's seen almost every kernel bug fix and security issue for the past 15 plus years, well, hopefully all of them, and who sees every kernel CVE issued, I think I can speak on this topic. The majority of bugs and here he's trying to be clear, quantity, not quality or severity. The majority of bugs we have are due to the stupid little corner cases in C that are totally gone in Rust. Things like simple overrides of memory,

error path cleanups, forgetting to check error values, and use after free mistakes. That's why I'm wanting to see Rust get into the kernel. These types of issues just go away, allowing developers and maintainers more time to focus on the real bugs that happen, i.e. logic issues, race conditions, etc. Yeah, the memory problems developers create themselves.

And then, so, a moment that really impressed me was Linus. And you know, I've been critical of him recently on some of his decisions, but I really felt like Linus showed he still really got his hands around this entire thing. He popped in on the mailing list a couple of days ago. And remember, this went all the way back to January, the beginning of the nuance of all of this. And none of it missed Linus's catch. And I was impressed by that. And he was responding to Hillwick, I believe, when he writes,

you're not forced to take any rust code at all or care about rust code in the DMA code. You can just ignore it. But the quote, ignore the Rust side, end quote, automatically also means that you don't have any say on the Rust side. You can't have it both ways. You can't say quote, I want to have nothing to do with Rust. And then in the very next sentence say quote, and that means that the Rust code that I want to ignore cannot use the C interfaces I maintain. Maintainers who want to be involved in the rust side can be involved in it, and by being involved with it, they will have some say in what the rust bindings will look like. They basically become the maintainers of the rust interfaces.

And what Linus did here in my kind of short horrible read there is he recognized that what Hillwig was originally complaining about wasn't really applicable here. The Rust folks weren't asking to change anything on the seaside. They weren't touching anything on the seaside for the DMA bus that we originally talked about as we touched on it was in a separate subtree. It's in its own separate subtree. And all they would be doing is reading the DMA bus like anything else might in the Linux kernel.

And that is a line too far for Linus. You can't be not involved and also say what these programs can and cannot use in the Linux kernel. As he puts it, it just simply does not work that way. Like he says, but that wall of protection goes both ways. If you don't want to deal with the Rust code, you get no say on the Rust code. Put another way, the nobody is forced to deal with Rust does not imply everybody is allowed to veto any Rust code.

I think I just want to reiterate, you know, people have been saying Linus needs to say more, Linus needs to chime in. Linus, if you look at this mailing list thread, he's chiming in pretty frequently, not all the time, but pretty frequently throughout. It does seem like, I mean, it seems maybe it failed, but he did clearly also have some private communiques with Miguel and...

But I was impressed that the original nuance, all the way back in January, did not miss his grasp. And that was a fundamental nuance to kind of saying to Hillwig, hey I respect your arguments you're often right you call and Linus even says you call me on my BS I'm calling you on your BS here. That's the other thing if you just hear the parts we read the most intense parts of the you know the debate and Linus putting down his policy right but he

also says things like you know you're saying like I respect what you're saying he also says I respect you technically and I like working with you. Yeah. I'm not looking for yes men. And I like it when you call me on my BS. I say some stupid things at times. There needs to be people who can stand up to me and tell me I'm full of s. But now I'm calling you out on yours. It's pretty good. It's a very different Linus than we've seen previously. I love it. I think one of the MVPs in this thread is Miguel. Don't you think?

Yeah. I will say there's been, you know, we focused on a lot of the, you know, the more intense parts as I was just saying. But there was a lot of good interactions in there as well. You know, I saw James Bottomley asking a lot of like, legit and good natured questions, a lot of developers trying to learn more. Kent Overstreet chiming in how this could be beneficial for BcashFS,

or how to maybe reframe things from time to time. Yeah, and there's a lot of different levels of knowledge, right? Some folks have used Rust, but like for user land stuff and never thought about the kernel side of it, some people have never touched Rust at all. So you get levels of like, do you, is your understanding of Rust accurate? Are you asking about a nuance of like,

where the type system isn't complete? Are you asking sort of like, you don't understand, you know, how the compiler side of it works? There's a lot of areas and yeah, Miguel has just sort of been seemingly tirelessly and for the most part quite, you know, politely answering, trying to clarify. This has not been an easy process for the community and it has not been without its costs of some really good contributors, you know, and I know that it's cliche to say the process is

messy but sometimes you actually see the mess unfold. It's hard to watch. Neil, did you have any thoughts from sort of the Asahi side, you know, watching that project as closely as you do now being tied in over there at Fedora? Did you have any thoughts on this? I think part of the, my personal feeling on this is that I think Linus should have stepped in two weeks ago about this. Because not because, you know, he hasn't stepped in and doesn't have good thoughts about this, but like the downward spiral with this whole

the whole conversation has had could have been completely avoided. If he had said this earlier, I get why he didn't. I understand the the desire to have the community sort itself out. I just think that this is one of those things that is going to require more tough love type stuff as we keep going. Because there's this contention with groups of people saying, oh, this can't ever be enterprise ready, and so it's a toy. There are people saying, I don't want to deal with this because multilanguage is terrible. Ignoring the fact that the Linux kernel actually been a multilanguage project since almost the beginning. It's been C and assembler and then C, Perl,

Python and assembler and make files and shell and and like, there is code in there that generates code that generates code that is then used to compile code. Like, it is a morass of complexity all the way through it. Not acknowledging that and then kind of complaining about Rust bringing in a new thing of multi-language-ness and complexity, I think, kind of is missing the force for the trees there. There's a lot more complexity in the Linux kernel today than there ever has been. Basically, I think a lot of people are going to need reality checks fairly frequently as this keeps going on. Now, I'm not going to say that I'm like the most amazing fan of Rust. I think that there are things about Rust that I'm not the biggest fan of, but it is pretty clear at this point that there are significant drivers towards,

pun intended, towards Rust in the Linux kernel and people who are interested and enthusiastic about it. And I think the job of a good community leader is to encourage and support the people that are doing these sorts of things to enable the next generation to be successful. Like the Linux kernel has a very very big problem that it hasn't really started looking at addressing, which is the churn rate of maintainers in the Linux kernel is unbelievably low. Most of the people that are maintaining subsystems in Linux kernel have been doing it since almost the beginning of that subsystem. And you look at the progress of bringing in new people to stay in for the long haul, and it's not terribly high. And that can be concerning as everyone's getting older. And what's going to happen when a critical subsystem

loses a maintainer for reasons? Like we lost wireless subsystem Larry Finger like last year. And this is not going to be a new thing. This is going to keep happening. And so like we have to start, I mean, we, I, the people in the Linux kernel community, the subsystem leaders and whatnot

have to start acknowledging that there has to be some give and take, there has to be some give to be where the people are, or where the people want to be. And some people want C++, some people want Rust, some people want to be on forges rather than using mailing lists. This is all going to be things that have to be dealt with because you need the next generation or the project dies. So this is something where I think Linus is going to have to take some tougher leadership on because otherwise I don't know what's going to happen. I thought maybe we could end.

I saw a nice post during part of this discussion from Keys Cook, who's for been a long time leading the Colonel Self-Protection project and doing a lot of good security vulnerability focused work on the C code in the kernel and Chris you mentioned kind of the contention like well, where does this end and are we trying to rewrite the whole kernel? What is the goal of this experiment really? so Keys wrote speaking to the what is the goal question I See the goal is eliminating memory safety issues

in new drivers and subsystems. The pattern we've seen in Linux with security flaws is that the majority appear in new code. Focusing on getting new code written in Rust puts a stop to these kinds of flaws. And it has an exponential impact as Android and Usenix have found, and then he included a bunch of citations. In other words, I don't see any reason to focus impact, as Android and Usenix have found.

In other words, I don't see any reason to focus on replacing existing code. Doing so would actually carry a lot of risk. But writing new stuff in Rust is very effective. Old code is more stable, and it already has fewer bugs. And yet, we're still going to continue the work of hardening C, because we still need to shake those bugs out. But new code can be written in Rust and not have any of these classes of bugs at all

from day one. Jupiter broadcasting.com slash river. You know I'm all about decentralized systems like Linux, podcasting and Bitcoin. Self hosted, user controlled, no vendors pulling the strings. And Bitcoin really is the Linux of money. When we first started talking about boost on the show, Bitcoin was around thirty something thousand dollars.

And now it's around a hundred thousand something dollars. Now, why did that happen? It's because of a couple of things and scarcity and network effect come to mind. There's only 21 million Bitcoin that will ever exist and there is unlimited printed fiat chasing it. This is why the Bitcoin ETFs were the most successful ETF launches in history. That was just a little story that went by in the last year, but they were the most successful ETFs in history.

So if you're like me, you know, you don't really want an ETF because that's essentially an IOU. You wanna own the real thing. The challenge is finding a legit, secure, trusted space that isn't a scam or isn't something that is gonna go away in a few years. You want a place you can buy, DCA or sell your Bitcoin. And my answer to that is River.

Go to jupiterbroadcasting.com slash River. That'll take you to our partner page. River is where I buy my Bitcoin, my family's Bitcoin. What I like about them is they have proof of reserves and anyone can audit their supply at any time. They also are a Bitcoin only focused company. So that means top tier services for Bitcoiners, slick mobile and web apps, lightning support, the works.

And one of my favorite features is actually their cash savings account with a 3.8% interest paid in Bitcoin. Now your galaxy brain move here is you stash some cash in there, you earn the 3.8% and then you smash buy Bitcoin when the price dips a little bit. And trust me, it adds up fast. River is the most trusted spot in the United States for individuals and businesses to buy, sell, send or receive Bitcoin.

That's why I use them and that's why I am pumped to recommend them to you. So if you just want some sats to boost the show or you're looking for a long term store of value, River makes it easy to get started with Bitcoin in three simple steps. Get started by going to jupiterbroadcasting.com slash River. It's real easy. That'll take you to our partner page for businesses or individuals jupiterbroadcasting.com slash River. Well, it is certainly conference season coming up and we have one who's planning way ahead. Texas Linux Fest is of course back again this year, but with a new season, October 3rd to 4th this year, that's in Austin, Texas.

And there's a call for paper open. You have until August 3rd, so no excuses for getting a talk in, but we would love to see what you can throw at Texas Linux Fest. Make it good, that way we feel like we have to go. Yeah, yeah, it's a great little fest. They're looking for sponsors too. 2025.texaslinuxfest.org for more details.

And I think Austin in October is going to be wonderful. October 3rd through the 4th at the JJ Pickle Research Campus. Is that real? Is that real? Is that not right? I believe so. I think I named that one maybe. JJ Pickle?

Yeah, it is a different location from last year. That's a good old Texas boy name right there, JJ Pickle. Get some culture in too while you're at it. Is it close to barbecue? That's what we need to figure out. I mean, Carl is, I believe, involved, so... You would hope, right? Right.

And now, it is time for Le Booth. Yes, it is, and Vamax is our baller booster for episode 603, the only 603 there will be, and he came in with 100,000 sats. Hey Rich Lobster! Not bad at all. I am of course advocating for a K8 challenge. Yes, I know. And after that gets shot down, maybe some kind of exciting network challenge?

They know us so well. Yeah, they do. Also, I randomly saw hybrid sarcasm in the Gathio contribution release logs as I was getting it set up. Really? That's cool. He says, cheers to hybrid. That's really neat. Okay, so a networking challenge. You skipped right over the first idea. What was the first idea? Oh, well, because as he knows, so a networking challenge. We skipped right over the first idea. What was the first idea? Oh, because as he knows, the K-8 challenge, that was an obvious skip, right? That's obvious. I mean, unless you want to do, I do have plenty of raspberry pies.

We could do like a pie, a pie thing, but, uh, I don't know if we have enough pies for all of us. The idea of networking quote unquote as something we should do has come up about a bajillion times though. So we do need to hone in on networking and figure out what we can do there. Because it's come up a lot. Thank you very, very much.

They, we really appreciate that you are the max. Thanks for the boost. And if anybody has any networking challenge ideas that we could realistically pull off, because I remember one of the things we do like is if the audience can participate too. Please do send those in. We just have to not take down the livestream

while we're doing the show. Right, right, right. The Dude Amid comes in with 42,000 sets. The answer to the ultimate question. I didn't have time to get on with the BSD challenge, but it was fun listening to your adventures. I'm wondering, how would it be if you used something like PFSense or OpenSense or TrueNAS Core as a base for the challenge? Technically they all use FreeBSD, so would that still count? Um, no. Oh, I say no, but I think it would count as one of the, you know, cause one of the points is like a re-spend a free BSD.

Because otherwise we'd have to say ghost BSD counts and ghost BSD didn't count. Right. Well, I was just going to be nice and say, you know, make it your own challenge. And if you learn something about how the BSD was. Oh yeah, sure. Okay. Everybody yeah, sure. Okay. But yeah, everybody gets a trophy. And what do you think Brent?

You get the tiebreaker here. Oh, you put me in that hard position. I think we gained a lot of background and knowledge and context running FreeBSD. And that meant that when we went into running a non-FreeBSD, you know, one of the derivatives, we had all of that context and it gave us a bigger appreciation. So you're siding with me, I think, is what I'm hearing there. I was trying not to choose a side, but yeah, I guess I did. But I still, like Wes said, I think it's very valuable.

And also, worth checking in on OpenSense. They've been doing a lot of good stuff over there. Well, I think it also says something that all these projects are based on FreeBSD, so there's certainly value to diving into any of them. Yeah, they don't like the GPO. Well, adversaries sent us in 32,768 sets. The traders love the ball. Adversaries, of course, obviously.

I try to get it right the way you get it wrong and then I get it wrong. So my trick is just do both. What? Yeah, adversaries, adversaries, you just, you know, use both. Okay. Or, you know, we get a little more colloquial in 17.

Yeah, it's big 17. Okay, 17 came in and says, I loved all the BSD coverage. What a wild ride that must have been. Oh, thank you. I'm glad to hear it was positive. It, I know this sounds silly, but we did have the discussion. Like, should we be talking about BSD in our Linux podcast?

So I'm glad that people liked it. Thank you for that. It's always good to hear from you. Big 17. I heard Chris had to go and reinstall if config on his next box And I still got one machine with ghost BSD it lingers. Oh it lingers Turd Ferguson's here with 24,500 sats

How's about a video game challenge three of you get a co-op game working on Linux extra points if the audience can join oh Oh, that sounds super fun. I'm in. It does sound fun. Okay. Also, Turd says, what about a no build Gen 2 challenge? Same rules as the BSD challenge, but no building software. Wow. How does that work? I mean, they have a binary cache right now. Could you get Nix working on Gen 2?

That'd be hilarious. Just strap a small little alpine on there. If we could somehow do the Gen 2 challenge without doing the Gen 2 challenge, I think turns onto something here. You know, you get the pre-built stage two or whatever. Okay, and then here's a philosophical question for you, Brent. If your favorite Linux distribution was a pizza topping, what would it be and why? Oh, man. Um, well, I think I have to say pineapple because it's so divisive.

There's a Linux for everyone. Pineapple? What? I'm challenging the question just a bit. Because instead of distro specific, I'm just going to say Nix. And I don't know if this is technically a topping more of a sauce, but I'm gonna say Nick's is like pesto because it goes with everything. Oh All right

Not the cheese or the dough. No pesto. Okay. All right. I was gonna say it's the sauce but all right Okay. All right. Okay. Well, so I do kind of like that We have never done a video we have not done a video game thing for a while on the show, but we've never done a video game challenge. Like, wouldn't that be fun if we did a stream, like sometime in like an evening during the week where everybody got in, we could do like a big co-op session. Why don't they make Race the Sun co-op edition?

Right, that's all I'm saying. That's all I'm saying. Thank you, Turd, appreciate the boost. Our buddy, our pal, Gene Bean boosts in with 4,444 cents. Ah, fuck! First question, did y'all play any with Beehive? Yeah, I did a bit. Not as much as I would have liked to.

I got a Linux VM going. I started down the path of trying Windows on it. I'd like to come back to that and get that working a little better. I did not this go around. Beehive is the one thing I've played around with before, where I've loaded FreeBSD just to try Beehive. And I think I've also, at some point, tried some sort of version that's on macOS.

I mean, I haven't done anything in anger with it. You mean Xhive. Yes, Xhive. But it's neat to see. I mean, KVM has worked so well for us on Linux, and FreeBSD deserves a great virtualizer, and now it has one. At least they're starting to integrate Vert.io support.

So we may actually see things like USB redirection, GPU, para virtualization, that sort of stuff show up in Beehive in the future. I mean, like Apple integrated it with their hypervisor framework for Mac OS. So it kind of supersedes Xhive in that respect, but you know, I'd like to see the Vert.io stuff be usable in more hypervisors. Agreed.

You know, Wes, I'm looking here. Do you see this here? It seems like maybe the message got degraded. I'm trying to connect and pull it again. I think the fax got cut off for the report, but I think he had something about skipping the Gentoo challenge in there. Did you see that? Yeah, Gene's trolling us here, rightly so. Oh, you say you're in need of another challenge, huh? How about that Gentoo challenge you've been putting off forever?

I'm not from Gentoo. Never heard of it. No. That was Brent's challenge. Yeah, right. I take offense to that. I don't think we've been putting this off. I think we've just been focused elsewhere. Oh, okay

All right, I putting it off. We'll let you know Jean. We'll let you know Neil Well Nural P sent in 5,000 sats you supposed No message on this one. Just a kind little send hmm well Monty came in with a row of adorable ducks 2,222 sats I got my Albie hub set up he says congratulations that's a nice little journey tried several times to get Nick's Bitcoin up and running but just couldn't get it to build Albie hub though I had it up in 10 minutes any suggestions on the simplest way to boost from Albie hub for this I installed the Albie browser extension I opened up Linux unplugged on the simplest way to boost from Albie hub. For this, I installed the Albie browser extension and opened up Linux unplugged on the podcast index.

That probably is the simplest way, actually, really, if you have Albie hub. So here's the order. If you're curious about boosting fountain makes it the easiest because it's all hosted by them. Okay. That's the easiest breeze is the next easiest because it's all hosted inside the app, you get a, you get a lightning note in the app. You put some stats in there, you can go find the podcast,

you can boost, you don't really have to change podcast apps. That's Breeze, B-R-E-E-Z. And then the next tier, which you're hearing people talk about is AlbiHub, and AlbiHub is where you self host the entire thing. I mean, it is, after all, an open source peer to peer network, and anybody can participate. And AlbiHub is a stack of basically a lightning demon and a bunch of great software and a nice UI on top of that to manage all of this.

But you don't really need it to boost. But if you want to go to like, you know, Chad level tier tech guy, then you go the Albie Hub setup, but if you just want to send some stats to the show, something like fountain or breeze, B R E E Z make it really easy. And then you can go Chad, a Matic if you want later on.-E-Z, make it really easy. And then you can go Chattomatic if you want later on. And congratulations, Monty. I'm really impressed. And I'm also really impressed you tried the next Bitcoin route too

and still still ended up on Albie Hub and love it. That's great to hear. Distress 2 boosts in with 10,000 cents. Boy, they are doing a lot with Mayo these days. Short and sweet. Planet Nix, yo. I agree. Planet Nix indeed. Yeah. Looking forward to hopefully seeing you there. Yeah.

Well, Congaroo Paradox sends a 1-2-3-4-5 Satoshis. So the culmination is 1-2-3-4-5! They're sending in a late update on their free BSD challenge. I tried out OpenBSD on Raspberry Pi 4 as a server, but busy life with two young children didn't let me do much else apart from the manual install and installing NeoVim. Hey, you got the important work done. I will say that I very much liked the vibe of OpenBSD.

The installer is very guided and clear, and once rebooted, you have a message that states that you have mail. I do like that. I love the old Unix mail system. You got messages in there. Said mail has very interesting information for newcomers. I think I'll keep playing with this in my free time.

And once I get a feel for BSD, on to next BSD for me. PS, I'll let you guys decide if this suffices or if I'll have to go hover with Windows 11 I'm feeling like it does because we didn't get Very many open or if all open BSD reports And I think it's extremely valuable to get an open BSD report and he got it on a Raspberry Pi 4 So I'm saying even though it's not free BSD. I think he wins. I think he wins right there So no Windows 11 for you. You've at least avoided that enough points to avoid that.

Auto brain comes in with 5000 stats. That's a charge boost. You suppose my do them. Oh, good. I've been hoping to get more to a monitor setups. By the way, I want more to a monitor setups up there. Most of the multi monitor setups. Auto brain says my dual monitor setup for work is a 2K fast refresh display on an X-Pen display drawing tablet. Whoa!

Ooh, interesting. Whoa! Really? A drawing tablet and it works great on Nix with GNOME. A drawing tablet on the desktop for Linux. AutoBrain, I'd love to know what you're doing there. That's interesting. That's really interesting.

See, Chris, I think I have a problem with these requests for multi-monitor setups because it just makes me really jealous. Yeah, how come it doesn't come with a budget? You know, that would be a great, oh man, you know how, if JB had like, you know, like some of these YouTubers that just get these stupid ad deals and they just go spend money like crazy, ours would be, we do tech makeovers, like we go to Brent's cabin, we do a total tech makeover.

Bring it on. Oh, I would love it, that'd be so great. One day, one day when Linux is the most popular thing ever and everybody out there cares about it real hard, I'm sure we'll get to do that That'll be our opportunity. Thank you everybody who boosted the show That's all the boosts above the 2000 set cutoff for time But I want to give a special shout out to our SAT streamers 35 of you streamed

70,000 762 stats to the show just as you sat back and listen Thank you very much when you combine that with our boosters that means we stacked a grand total of 309,141 Sats. Thank you very much. That system is nice and easy. Once you get set up with Fountain or Breeze or something like that, you can boost and also check out the splits.

You never know, we're sometimes sending some Sats to a project, editor Druke, it's just the way the whole system works, it's so freaking cool. And you just need a podcasting app like Fountain or something like that to try it. You can find them at podcastapps.com and then you can also listen to the live stream in your podcast app and all that kind of stuff too. And you're using a decentralized index

instead of like apples or Spotify's, you know, hmm, Spotify. We have a couple of picks and this one's kind of a time appropriate pick, if you will. That is because Amazon is about to remove your ability to download any ebook that you've bought from them in the past. Yeah, I think this takes effect on the 26th, February 26th, 2025. It's just a few days after the show comes out. So we wanted to get this in here.

And the app pick that we have for you is Amazon Kindle Bulk Downloader. Yeah, right. The backstory here is since time forgot, you could go and download like an actual file and then transfer it over USB or even email things to your Kindle. Oh, yeah. Then you could use open source tooling to strip DRM and then have a proper backup file or something you could use with a different e-reader if you wanted.

Or any of the things that you might think that you want to be able to do with the thing that you purchased. Well, now Amazon's doubling down on the whole, you didn't buy this, it's just a license. No, you can't download it. Oh yeah? But, so you can't download it. Oh yeah? But, so you can still do that. I think you have to have a compatible device, because maybe they've already stopped this for newer devices or something.

I have not tested that. Okay. You can go onto their site and download them one by one. If you have a few books, that's fine, but if you have, maybe you have a big library. So, I don't have a crazy library, but I had 100 or so, didn't want to do that. So I was able have a crazy library, but I had, you know, 100 or so, didn't want to do that. So I was able to find a little open source app, actually, no, an unlicensed

app. I think they intended to be open source. So buy beware on that one. There's not yet a license file. I'm thinking I'll open an issue on that. Licensed TBD. But you know, you're archiving Kindle books in a rush anyway. So maybe that's not your biggest concern. You can get the code and run it on yourself, on your computer, all you like. It's a TypeScript app set up with Bun, so I just did it in a little Ubuntu container

and that worked totally fine. And then you just give it some envars with your Amazon login info. And it's not very big, so you can go check out the source. And then it'll do, it spins up a Chrome instance to control via Puppeteer to then go like off into Amazon. If you do it locally too, I didn't have a problem, but they do have support for actually not doing it headless

and popping the browser up if you need to do like a manual login, if the auto login doesn't work. So. That's nice. Yeah, it worked quite well, just downloaded real fast, had progress bars and everything. Get your books, people. Hopefully that helps.

Get your books, get your books that helps. Get your books. Get your books. And go find somewhere else to download them. We have a bonus pick. This came in from Bear, listener Bear. And I love it. I double checked. I cannot believe we have not picked this before

because it is 100% up our alley. It is called N-Ping. It is a ping tool and it is developed in Rust. It supports concurrent ping for multiple addresses and then it, on the command line, gives you a visual chart display with real-time data updates and other features. Look at this, boys. Look how beautiful this is.

Yeah, okay, I like it. I am experiencing a very strange problem with my one workstation up in my office at the studio, particularly in the mornings, it's dropping packets. I can't even ping my router, so it's on my LAN. And then it kind of seems to settle out by the afternoon and it never happens. But it sucks, because I get here early in the morning.

I was in at the studio at 4.30 a.m. today to do the show, and that's when it's absolutely the worst. Oh, no. And so it's like, come on, I'm here early to get this done. And it doesn't... And it wasn't until about, oh, I don't know, nine, eight a.m., somewhere in that hour, it starts to smooth out.

So being able to throw this on there, I could actually visualize the issues, which was really cool. I was gonna say, you know, this seems like something you maybe traditionally would use a tool like smoke ping for, but having this in a zeledge session in the background could be a nice way to do it. I just need it for a couple of hours, run it there.

So nping, we'll put a link to that, and it is MIT licensed. I like it, so by default you get a graph per thing that you're pinging. You can ping multiple things, has a slick little graph going, and it shows you the recent records that Target resolved to and the latency to each of them.

So there's a lot of handy info right there. You know, I think next week might be our last live episode before we take off to scale in Planet Nix. Whoa. So, and we may or may not do a live episode from there. We probably will have a pre-record. All of this, we'll try to get this on the Jupiter broadcasting calendar and of course we'll try to market pending in podcasting 2.0 apps. But I do know we have one more regular live show next Sunday coming

up. So join us for 12 PM Pacific, 3 PM Eastern. See you next week. Same bad time, same bad station. Now don't forget, links to what we talked about today are at LinuxUnplugged.com slash 603. You can use that promo code Linux to take 50% off your scale tickets and of course we're really excited about Planet Nix. We want to see you there and the team at FLOX is making it possible for us to attend Planet Nix and we'll have so much great coverage for you coming soon. And last but not least, I'd really encourage you to consider setting up our Mumble Room. We have it going now for the launch on Tuesdays and for LUP on Sundays.

It's a great way to just listen and get high quality opus right from the mixer. But if you just listen, that's all that really matters. Thanks so much for joining us on this week's episode of the Unplugged program. We'll see you right back here next Tuesday, as in Sunday! Yeah! Thanks for watching! you