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-ons 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 any of that, I've got to do the right thing, and I've got to say time-appropriate greetings to that virtual lug. Hello, Mumble Room.
Hello. Hello, Chris. Hello. Hello, Brent. Hello.
Hello. That's a serious showing. I like it.
It's a little echoey because we had to get a huge room to fit everyone.
Yeah, 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. Well, 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 back-end infrastructure when you have multiple different data centers and you want to bring everything together. Thousands of companies do this, like Instacart, Hugging Face, Duolingo, more. They all use TailScale, 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?
Bigger, broader. I think we're going to get some good answers. Whatever it might be, though, boost in and let us know. You've been hearing us talk about Planet Nyx, 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, Kauai 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, socalinuxexpo.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 $100 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 want to say, I do love these side 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 want to 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.
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 kind of want to make it clear, when people show up, they do need to proceed to it. 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. So 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, you know, 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 registration. 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 in 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 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 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 kernel's core direct memory access, or what is referred to as DMA. Obvious drivers need this, right? The goal here is 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, and 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-Russ 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 um as you said uh helwig said no rust code in kernel slash dma and what that's referring to is sort of the various trees inside this kernel source tree itself uh 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 subtree.
In its own it is of course wrapping code that lives in the dma side but.
Yes and so it's in its own container that is important to understand later so this kind of brews for a bit you know there's a there's fosdem there's a talk about rust for linux there held by miguel odeja is that oyeda oyeda and he's the lead maintainer of rust for linux he presented at fostum uh he liked so he highlighted there some of the progress and some of the things that landed in linux 6 6 13 also.
Tried to go and get i believe a bunch of quotes from various uh maintainers both you know 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 are 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 Rust 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, you know, they're kernel contributors who want to add Rust. Then I mentioned 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's 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 going to 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 going to get yelled at still?
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 going to fix it, but it being broken is a problem, then, like, who is actually in practice fixing it?
Yeah.
Helbig also said, I don't think having a web page 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. Helwig continues, while Linus in private said that he absolutely is going to merge Rust code over a maintainer's objection.
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. But 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 uh burned out disappointed with leadership in the kernel frustrated with their post approach to rust integration ceases maintaining upstream linux kernel code for the arm stuff you know the solid project has to rework that now, um we've seen others that burned out like that that is so you understand the context in 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 say fairly pro rust stuff even though this superheated 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 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 bright 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 multi-language project like this. We should not just introduce for us this is going to make it hard to maintain this is going to make it more of a bear. We should just improve the sea stuff if we want. If we 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 going to write a Rust version and essentially this is going to become a Rust kernel? They don't want that. That's ridiculous. We should just fix the problems and see 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.
Sure 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 uh 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 going to 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 right like 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.
1password.com slash unplugged. That's the number 1password.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 1Password has an answer. It's extended access management. 1Password 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.
1Password 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. 1Password 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 1password.com slash unplugged, all overcase. That's 1password.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 rough, like Wes was saying. He says, quote, yes, mixed language code bases are rough and hard to maintain, but, We're kernel developers, damn it. 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 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, you know, 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, you know, whether you agree with the mission or not, you have to agree that the Rust for Linux folks are trying hard.
You know, I noticed, I think it was a week or two ago, they're working on the Phobus, 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 C-side and a Rust-side, and it's good. Try out the Phobus.
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, are... 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 overwrites 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 Hillwig, 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 C side. They weren't touching anything on the C side for the DMA bus that we originally talked about.
As we touched on it, 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 a 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.
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 BcacheFS or how, you know, how to maybe reframe things from time to time.
Yeah. And, you know, there's just there's 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 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 uh miguel has just sort of been seemingly tirelessly and for the most part quite you know politely uh 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 uh, I know that it's cliche to say the process is messy, but sometimes when 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.
Not because he hasn't stepped in and doesn't have good thoughts about this but like, the downward spiral that 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 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 multi-language is terrible. Ignoring the fact that the Linux kernel actually been a multi-language project since almost the beginning.
It's been C in Assembler, and then C, Perl, Python, and Assembler, and Makefiles, and Shell, 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-languageness and complexity I think kind of is missing the forest for the trees there.
There's a lot more complexity in the Linux kernel today than there ever has been. So 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's that it can't 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 last year. And this is not going to be a new thing. This is going to keep happening. And so we have to start, I mean, we, 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 been a long time leading the kernel 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 of like, well, where does this end? And are we trying to rewrite the whole kernel? And what is the goal of this experiment, really?
So Keyes wrote, Speaking to the what is the goal question, I see the goal as 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 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.
Jupiterbroadcasting.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 boosts on the show, Bitcoin was around $30-something thousand dollars, and now it's around $100,000-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. There 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 don't really want an ETF because that's essentially an IOU. you.
You want to own the real thing. The challenge is finding a legit, secure, trusted space that isn't a scam or isn't something that is going to 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 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.
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. Not bad at all. It says, I am, of course, advocating for a K-8s challenge. Yes, I know. And after that gets shot down, maybe some kind of exciting network challenge?
Ooh.
They know us so well.
Yeah, they do. Also, I randomly saw hybrid sarcasm in the Gavio contribution release logs as I was getting it set up. Really? That's cool. Condesas, 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, because as he knows, the K8s challenge. That was an obvious skip, right? That's obvious. I mean, unless you want to do, I do have plenty of Raspberry Pis. We could do like a pie thing, but 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, Vey. 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 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 live stream while we're doing the show.
Right, right, right.
The Doodamide comes in with 42,000 sats. 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 use something like PFSense or OpenSense or TrueNAS Core as a base for the challenge? Technically, they all use free BSD, so would that still count?
No.
Oh.
I'd say no, but I think it would count as one of the, you know, because one of the points is like a re-spin of 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.
Oh, yeah.
If you learn something about how the BSD works.
Oh, yeah, sure.
Okay.
Everybody gets a trophy. And what do you think, Brent? You get a tiebreaker here.
Oh, if 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. I think it was. All right. 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 sats.
Adversaries, of course, obviously.
I try to get it right to 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!
Lucky 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. 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 ifconfig on his next box.
Hey, 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.
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.
Does it 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 on to something here.
You know, you get the pre-built stage 2 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. 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 gonna say nyx and i don't know if this is technically a topping more of a sauce but uh i'm gonna say nyx 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 uh 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. 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 Beanboosin with 4,444 sats. Oh, 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.
Yes, X-Hive.
But it's neat to see. I mean, you know, 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 VertIO 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 macOS, so it kind of supersedes XHive in that respect. But, you know, I'd like to see the virtio 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 facts 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.e. putting it off.
We'll let you know, Gene. We'll let you know.
Neil. Well, Neural P sent in 5,000 sats. No message on this one, just a kind little send.
Well, Monty came in with a row of adorable ducks, 2,222 sats. I got my AlbiHub 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. AlbiHub, though, I had it up in 10 minutes. Any suggestions on the simplest way to boost from AlbiHub? For this, I installed the Albi browser extension and opened up Linux Unplugged on the podcast index.
That probably is the simplest way, actually, really, if you have Albi 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 lightning node in the app. You put some sats 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 AlbiHub setup.
But if you just want to send some sats to the show, something like Fountain or Breeze, B-R-E-E-Z, make it really easy. And then you can go chat-o-matic 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 ended up on Albie Hub and love it. It's great to hear.
Distress 2 boosts in with 10,000 sats. Short and sweet. Planet Nix, y'all.
I agree. Planet Nix, indeed.
Yeah. Looking forward to hopefully seeing you there.
Yeah.
Well, Kongaroo Paradox sends one, two, three, four, five Satoshis. They're sending in a late update on their free BSD challenge. I tried out OpenBSD on a 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 when 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 NixBSD for me. P.S. I'll let you guys decide if this suffices or if I'll have to go server 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. Autobrain comes in with 5,000 sats. That's a Jar Jar boost.
My dual monitor. Oh, good. I've been hoping to get more dual monitor setups. By the way, I want more dual monitor setups out there.
Boost them in.
Multi monitor setups. Autobrain 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 much, 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 an opportunity. Thank you, everybody who boosted the show. That's all the boosts above the 2,000-set cutoff for time. But I want to give a special shout-out to our sat streamers. 35 of you streamed 70,762 sats to the show.
Dang.
Just as you sat back and listened, 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 Drew gets a set. It's just the way the whole system works is 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? Mm, or 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 e-book that you've bought from them in the past.
Yeah, I think this takes effect on the 26th, February 26th, 2025.
Yeah, 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. And, you know, then you could use open source tooling to strip DRM and then have like a proper backup file or something you could use with a different e-reader if you wanted. Or, you know, like any of the things that you might think that you want to be able to do with the thing that you purchased. Yeah.
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 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, you know, maybe you have a big library. So, I don't 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 fire 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 like a little Ubuntu container and that worked totally fine. and then you just give it some nvars 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 auth into Amazon.
Okay.
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.
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.
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 like settle out by the afternoon and it never happens but like it sucks because i get here early in the morning like 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 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 you know 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 zelige session exactly in the background could be a nice way to do it i just need for a.
Couple of hours you know run it there so n ping we'll put a link to that and it is mit licensed.
I like it so by default you get like 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.
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 Jupyter Broadcasting calendar, and of course we'll try to mark it 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 p.m. Pacific, 3 p.m. Eastern. 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 Phlox 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.
And 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, and we'll see you right back here next Tuesday, as in Sunday!