LINUX Unplugged - 678: Entropy Ain't Easy

Episode Date: August 2, 2026

Seven Linux kernels landed in one day. We sort out which belong in your homelab, and trace Linux’s long, occasionally disastrous quest for truly random numbers.Sponsored By:Jupiter Party Annual Membership: Put your support on automatic with our annual plan, and get one month of membership for free!Managed Nebula: Meet Managed Nebula from Defined Networking. A decentralized VPN built on the open-source Nebula platform that we love.Support LINUX UnpluggedLinks:Web Boost — Send us a boost via sats or USD💥 Gets Sats Quick and Easy with Strike📻 LINUX Unplugged on Fountain.FMJupiter Garage SWAGAppleTalk 1985-2026 Memorial StickerSorry, I only open regular files StickerClanker Therapy Session 1 - Member's Stream — We’re taking the hype out of agents and showing the workflows that actually help. Join us for a hands-on walk-through of our Hermes multi-agent setup, how we let agents manage systems safely, and how we introduce them to a new Home Assistant instance without letting them run wild.Clanker Therapy Session 1 Highlights - YouTubeLinux 7.2-rc5 announcementLinux 7.2 changelogLinux 7.1 changelog7.2 merge windowBtrfs large folios and DIO fixstrncpy removali486 removalDreamcast fixesCache-aware schedulingFairer GPU schedulerNVIDIA 7.2 driver compatibilityAMD ROCm regressionDreamcast vs i486Btrfs DIO regression reportsTechnical Deep Dive into the Entropy Issue | COINKITE BlogBitcoin losses linked to Coldcard vulnerability grow to $70 million, Galaxy Research saysFlowchart of the Linux RNGdust — A more intuitive version of du in rustPick: TREK — A self-hosted travel/trip planner with real-time collaboration, interactive maps, PWA support, SSO, budgets, packing lists, and more.Pick: cfait — A fast and powerful, offline-first task manager for your terminal, desktop, and phone.Cfait on FlathubCfait on F-Droid

Hello, friends, and welcome back to your weekly Linux talk show. My name is Chris. My name is Wes, and my name is Brent. Hello, gentlemen, coming up on the show this week, Greg K.H. Has been busy. Seven Linux kernels landed on Saturday. Almost all of them were an LTS. We'll break down what changed and what releases just might fit your home lab best. And then, why generating truly random numbers is so dang hard and how it's gone so bad in the past.

We'll talk about that and we'll round it out with some boosts, some picks, and a lot more. So before we get there, let's say time appropriate greetings to our virtual lug. Hello, Mumble Room. Hello, hello, guys. Hello, Bradford. And hello up there, the quiet listening and everybody watching live over at jbblav.tv, making it a Tuesday on a Sunday. And good morning to our friends at Defined networking. Check out Define.net slash unplugged and sign up for managed Nebula, 100 hosts for free, no credit card required.

is one of my favorite technologies. And Managed Nbula makes it so straightforward. And now they give you a lighthouse to get going real quick. Picture a Mesh VPN completely and totally under your control with a design that is intelligent and low resources from the beginning. Something designed to connect

some of the most important and sensitive data around the world is now available to you and through the magic of cryptography is very straightforward to set up. You get strong encryption, direct-to-vite-of-vigion. device-device connections, and you can self-host the lighthouse nodes, giving you complete control over the network that you depend on. That's huge.

So go get started, 100 host for free. No credit card required at defined.net slash unplugged. Go check it out. We love it. Defined.net slash unplugged. You know, we just have a really quick housekeeping this week. We wanted to say thank you. We meant to say thank you last week when we were remote at Brent's place.

but it dawned on us afterwards. Once again, a big thank you to everybody who helped us get those headsets. It's almost been, what, two years now? Yeah. Those things have been just solid. I don't think they've never, ever caused us a technical issue we've had to solve.

Everything else has, but never those headsets. It's crazy, it's crazy what a reduction in complexity and gear that was for us, too. Really? Yeah. I mean, at that point, it's them and a mixer of some kind that can handle enough inputs. Yeah.

And then a computer. And without them, it's my, it's big, microphones and stands and separate headphones and the wires for all of that to work. And it's, it's nuts. It's nuts. So thank you so much. We just want to take a moment. We really, and it's like every time we use them, we're like, oh, so, so freaking grateful the members and the, and the listeners, too, is people contributed from all around to hook us up. I want to thank you two boys and the mumble room for doing a nice little send-off of my beloved studio, too. I mean, that thing has done quite a few episodes. So I want to say thanks for your, like,

Like, I'm in one last hurrah in there. It was really great. Seven kernels on a Saturday. Greg K.H. shipped a bunch of stable kernels in one window. I'm hoping he's taking a summer vacation after this. Six of them were LTS Point Releases and some big numbers in here, boys. Check this out. 6.12.100.

6.1.180. And get ready for this. It's still kicking. Linux 5.10.2.262. Yeah, those are basically point release numbers, right? So those get bumped up as Greg release his new one, so you can kind of tell how long he's been doing those. Yeah.

I'm glad he's keeping track because we're not. Linus also tagged Linux 7.2 RC5 over the weekend. So he called it quite the massive RC5. This really kind of brings it up to a total of seven. So we got these six stable point releases, and then the new 7.2, which kills Apple Talk, is reaching RC5. And it has quite a bit of changes in it

because there's been a lot of AI-assisted patching that's been hitting the kernel recently. It's a lot. What do you say, Wes? You want to break some of it down for us? Yeah, I guess you'll take it to handle on what kernels we're talking about here. Well, sort of before the big push, Greg,

released 7.1.5. The 7-2's not out, right? So we're doing the 7-1 thing. Yes, thank you. And then, of course, as you said, Linus released 7-2 RC5. We're expecting 7-2 to come out. maybe sometimes around August 16th, somewhere in there.

Obviously, depending on how many RCs line of steam is necessary. And then, so that was July 26. And then on July 30, yes, 6 LTS point releases. So we got, we'll go from the newest and then kind of get older. We got 61841. Wow. That's the newest, quote unquote, active LTS, right? 618.

Okay. That has an end of life coming up in December, 28. Then we had, let's see, here, 612-100, Debian 13 Trixie and Rel10 base. That EOL is also December 28. That's, I mean, 2028's not that far away, but pretty good. So these are going to, this will be the kernel that ends up in people's rail 10. So this will be pretty widely used kernel 612, 100. And it's the first time we start seeing the involvement of the civil infrastructure platforms,

super LTS, that's going to try and keep this thing alive until December, 2030. I'm sorry. What did you say? Yeah, 235. Wow, yeah, yeah. That's incredible. So basically there's a, it's a Linux Foundation project, the civil infrastructure platform with a bunch of industry folks, right? Like Siemens, Toshiba, Hitachi, Mucks, people that build like- Google's in there with Android. Right? Long-term embedded industrial systems. And so it kind of exists to extend kernel.org, which often does it for like roughly two years. But they're trying to offer stuff more like 10. 10 plus 20 you know so if you want to run 612 100 you can say that you're running a super lTS kernel yeah that's right okay we also got 6 6147 that has an end of life of 2027 that's getting pretty close december as well yeah 6 1 180 that's a debion 12 bookworm base that aOL is december 27 as well also coming up and would you believe it we are still pushing updates to the five series kernel yes we're on seven now, that's like two giant numbers ago.

So this is 515-213. That's the Ubuntu 2204 LTS base. That's coming up soon, though. End of life, December 2026. As far as, obviously, Ubuntu does their own work, but in terms of kernel.org. Right, right. Then they're on their own after that.

And then the last. The least, I don't know, that's up to you. 510-262. That's the Debian 11 era. Kernel.org, end of life, December, 2026, coming right up. But this one is also under that super long-term support to January 2031. When you see that, when you see they get the super long-term support, I think the obvious giveaway here is like these have ended up in some sort of widely deployed corporate system,

some image that's on a bunch of consumer devices or control devices, something like that. Yeah, and things shipped that aren't easy to update or maybe are certified. And so if you change the kernel, you've got to do a whole new certification. You might not be able to do updates in place. but a lot of these drop off in 2027, a couple of drop off in December of this year, two of them drop off. So like Greg's list,

I don't know, because I don't know if he's responsible for the super long term, but like Greg's list does shorten a little bit in a year or two. And that's part of the sort of the two-year thing, right? It's like the colonel of the org team has to maintain stable kernels

that like, you know, actual people pull from and they work on whatever the latest kernel is all the time. It's just, you know, you have to handle who's going to actually support this, which is where it is nice to see the, the companies involved in wanting to run ancient colonels, stepping up to sort of take on some of that ownership. So, Brent, I think last time we were looking at some of the patch sets that were hitting 7-2,

there was a lot of stuff in video, a lot of video drivers. What are we seeing that got your attention in 7-2 RC5, the new freshness? There is new freshness. There's AMD GPU compute stuff in there. That's 42x regressions, though, on some of the 7.0.0. releases. So stable diffusion Excel via comfy UI went from a 9 second

to 388 seconds. That's a pretty significant regression. Okay, so, all right, so maybe 7.2 don't use it on AMG compute systems just yet. I mean, some of those are fixed upstream in 7.0.13, but not every single distro has picked them up yet. So take your chances,

or do some research, I would say. I also saw a fair amount of pent-up networking work. West had a staten here over a third of the patching of the patches that landed were networking alone. And again, I think, Brent,

that's more of like the AI-assisted code stuff only sitting in the networking branch. It just to me seems like we're going to need like a spring cleaning next year or something. How much you're hoping to clear out as much as we cleared out? Well, if we're willing to get rid of Apple Talk,

then where is the line, poise? I think you're right. We're probably going to see more of that as basically every subsystem in the kernel gets more and more pressure. the stuff that is no longer load bearing is just the desire to cut it is kind of increase.

But to your point about that massive 42X regression compared to Linux 70, that stuff stings, but most people that are using that stuff in a production workload where they're using the actual AMD compute infrastructure, I doubt they're going to install 7-2,

and AMD does seem to be actively contributing upstream, so I imagine they're going to be working on that. I think part of the story here is is kind of like, what and why do you choose a particular kernel? How do you go about doing that? Right? So it's like some of these things are, yeah, you hit it if you are upgrading, but do you need

to upgrade for hardware enablement? Do you need some sort of new feature? Are you really looking for a potential performance improvement? There's another wrinkle to it as well, as sometimes the drivers or system support do get backported to these older releases. So you might see that they started contributing drivers at the 70s series, but sometimes, like the NVIDIA stuff, IOMMU stuff, that stuff gets backported.

And so the older kernels can sometimes end up with that. So I think that you could think about it in tiers here, right? If you're looking through an LTS lens and you're just looking at long-term stable kernels, you want to set up a box and forget about it for as long as possible, I mean, you still need to update, but you won't have to redo your kernel. Then that's, I think, right off the bad,

that's Linux 618. It is the current, quote-unquote, bleeding edge LTS. It has some of the newer AMD, the Nvidia stuff backported. And it will last until 2028. That gets you a pretty long runway. Yeah, I suppose that comes down to like what

are you supporting and how long, how many updates are you willing to do? How long can you go without changing kernels and... Yeah. Well, or if it's, or like what you said, is it is it just doing stupid file serving and maybe DNS? And it's like something you run on a Raspberry Pi or it's a low end networking box, then

you don't need 618. Something like 612 will be around. until possibly 2035. So talk about a box for networking infrastructure you could just set and forget and just do quarterly updates on

and you're not going to have to worry about a new kernel. So 612 could potentially be around until 2035. That's the one for those machines. It's funny. It feels old, right? 612 kind of sounds a little old.

But, I mean, it was a kernel we really talked about a lot on the show. It was a big one, preempt RT stuff. I mean, there's just like a bunch of stuff and I think it was pretty widely deployed, which is why it's getting that long-term support.

Right, preempt. RT. Right. Also the note in here that it's considered one of the most battles tested kernels of all of them. And that's their opinion. So, okay, let's go with that. So 612 seems like a real winner if you don't need super modern hardware and you're cool with a set up and forget it kernel. Then after that, like, I think it sort of just drops off and it's okay, well, you're just going to go with whatever distro you want. This is really, if you're even making an active decision, right? Because Debion's going to manage their kernel release, Ubuntu will manage theirs. There's going to be stuff that they're just going to take care of for you and you may end up on a on a different kernel at some point when you just upgrade the distro but if you are actively making a choice and I'd like to know how many of you really are actively making a choice which kernel do you actually

pick like I'd like to know how many of you are actually doing that I mean we do yeah we do definitely do I mean we're running this end kernel so yeah and then back in the day when this was a KDE neon box here in the studio you were doing the mainline tool to just kind of get the freshest kernels and on fake nes we're doing the LTS kernel we're doing one of the LTS kernels just because we hardly ever

update that box and we don't want it to break when we do ZFS updates. And so we did go to the LTS gear for the rolling arch base server. And so I wonder how many people out there are A, actively choosing their kernel. I bet it's a minority. And I wonder B, which colonel's they're choosing. So boostin, boost. dot jubitabridoribratcasting.com and let us know. Yeah, I like that.

It turns out you can have a rolling distro with a stable kernel or a stable distro with a rolling kernel. I like it. I mean, on our desktop boxes, we just go full rolling with everything. But on the server, it's not that crazy, I think, to have an LTS kernel and a rolling user land. I mean, we've been proven it for how many years on that fake NAS box, abusing it, doing random updates. Yeah. Isn't it just lots of luck, though? Maybe it's strategy.

I think the cottonwood is structural. It helps at this point. It's really about, well, for us, right, it was down to we wanted rock-solid ZFS support. And sometimes ZFS doesn't keep up with the current kernel. And if you load the current kernel, you can sometimes not have a lot. loadable ZFS. And so for us, it just made a lot of sense. I think if we were doing B-Cash-FS or ButterFS on that machine, probably wouldn't be a big deal. It probably wouldn't matter. But then if we were trying to use an invidia driver or an AMD driver, then it could be.

It could be. So again, I'd like to know how you pick and what you pick. Let us know. But let's talk about 7-2 because I feel like we've been building to this for weeks, especially since we learned about the death of Apple dot coming at 7-2. So what stands out to you, Wes? Yeah, there's a lot of exciting stuff. A few highlights for today, though. The Cash Aware Task Scheduler. Yeah, buddy. The scheduler now knows which cores share a cache. It groups tasks that share data onto the same cash domain,

so you stop paying cash miss penalties across cores. Now, we should be clear. This really only counts if you are on a system like Epic or Zeon that has multiple cash domains. You're not going to see it on a single cash domain device. But if you have that, this is basically like a free performance when you don't do anything except upgrade your kernel and things get faster. See all those Xion CPU?

News, boys. Sweet. I'm going to go dust off that old Mac Pro upstairs. It's like 15 years old that's got zions in it. And I'm going to actually, I do have an active zion system in production that I think about it. Oh, I love it. Well, time to update. Mm-hmm.

Or it will be in August. Yeah. Okay. Not the only work on the scheduler, though. Okay. And scheduler stuff. I mean, not only isn't one of the trickiest areas, I think, of the whole kernel, but it can tend to really, you know, it can have regressions pretty easily.

It can be very noticeable. It can be. It can have a lot of performance impact. So another change is a fairer GPU scheduler. The Kernel's DRM scheduler used to defaults a high priority for GPU jobs. Now it defaults to fair. So GPU time gets distributed more evenly when you've got multiple things competing for it. And if you're running GPU pass-through to a VM or something like that,

well also, you know, running all your fancy desktop compositing as you do, this should help. If you've just got like one GPU, you know, turning away at like an ML task or just rendering one thing specifically, you probably won't notice. Again, these are hardware-specific, but that even makes them a little more challenging to do. Yeah. So it's impressive where you've seen the changes. Okay, you got anything for a guy that's just got a regular old computer that doesn't have like zions or, you know, multiple goopoos?

Well, we do have memory reclaiming. How about that? All right. I like that. The Colonel's page reclaim got a lot smarter in 7-2. M-G-L-R-U improvements are showing 30 to 100% higher throughput on things like. like MongoDB, which is kind of just a test workload. All right.

And your page allocator isn't stuck and always handing out to MB anymore. I can hand out 16K, 32K, 64K pages, smaller bits. It means less overhead on every memory lookup. And that means, like, instead of having to allocate more stuff than you actually need, programs can request and get more reasonable amounts. I can't believe that wasn't a thing already. Yeah. There's definitely some of that in here.

You're telling me the huge page allocator in Linux has been stuck at two megabytes forever? Yeah. Wow. Okay. That's a big one. That's a big one. All right. You got me.

And it should mean container startup and tear down in particular should be noticeably faster. All right. All right. You got me on board, West. And maybe you don't want to be using it. But if you do, your pal swap also got faster. Oh, you know, you never know. Sometimes you got a swap.

Yeah. Back in the old days, the bad old days swap used to route different memory types through different. different code paths, that's gone, cleaned up, unified, less bookkeeping, less bloat. And at the end of the day, that just makes it faster. I like to put my swap on a RAM disk, so I'm glad to see that performance has been improved. Now, it's not all good news necessarily. There are some regressions here that, you know, that's being worked on, though. Butterfess in particular is in a bit of active surgery. Large folio supports on by default now. Okay. And they've improved things. There was a previous direct

i.O regression. That got a fix, a 59% throughput fix, no less. Jeez, okay. But as a result of that, you know, so you had to do that to get the new fix. You had to get the performance improvement. We got large folio support that speeds things up. But

it did also introduce regression itself. In particular, if you're running KVM guests with RAM backed by a Butter of S file, so it's like a particular setup, it can cause a deadlock. Hmm. But they're working on the patch. I don't know. yet if that's going to land in

7-2 ultimately, I hope so, but we haven't gotten there yet. And then they will backport it to Linux 612. And perhaps in a way where you, if this is only in the RC, then perhaps then it's a way that you just never have a possibility of getting into it all. I'm like

working through all my VMs and like, is this going to hit me? And I think actually one of them does. Yeah, I could see that getting me. What you need is a super fast external storage in a different file system. Maybe some new stack for the universal serial bus could enable this, Wes?

Maybe a new iteration? Oh, maybe. Yeah, we are seeing USB for streaming support coming. There's not hardware, really, I think, out there a ton of it yet that you could actually use. So this is the case where the kernel sort of leads the way with people doing upstream development right, where, like, before the hardware exists, it's in the kernel. So then when the hardware does exist, you just plug it in, and the kernel supports it.

That's so great. Also, stuff that isn't super used yet and isn't a little more. experimental, but fun to watch because we've been paying attention, is sub-schedular support in the Skeg-X system that enables you to write your own scheduler. What's the difference between a scheduled task and a sub-scheduled task, Wes? Well, like, you have a finer grain on, you know, because, and you can change, you can basically have tasks that have their own schedulers, right? So you can have, instead of one scheduler that has to know about how to schedule everything for every type of task, it can then have its own

sub-scheduler that can schedule just that type of task. That's awesome. And then you can optimize it more like maybe specifically you're trying to run a database server, right? And like the database does all kinds of stuff that like other kinds of applications don't do. And so you might need a schedule that's aware, like, oh, give the database priority on this kind of thing. Dang it.

You're going to make me run 7-2. Well, that was the idea. Dang it. I don't know why. I just like the number 7-2. It's got a good round shape in my brains. Yeah, it does. Kind of nice color.

So we should all be running it. There has been, I mean, I was teasing earlier, but there has been a bit of, cleanup in the 7-2 current release as well. Quite a bit of cleanup. You mentioned the networking stack. Mm-hmm. And you mentioned a third of the patch

of RC5 is networking alone. So mostly driver-side stuff. And Linus himself said, nothing in there strikes me as particularly a strange or scary. So don't worry, guys. Oh, man. Also, there's, hey, you remember the Sega Dreamcast? Yeah.

Yeah. That was like peak late 90s, really. Oh, I play the heck out of that. Yeah, that was 1998. Wow. Well, the Dreamcast is still getting driver fixes. So there's a mouse driver null-pointed DREference. It had drivers at all?

I had a mouse? Okay. I mean, we should investigate maybe. So there was a null-pointer de-reference since 2017, and that's been fixed. That's got to be an LLM fix. For sure. That's got to be. I mean, it's kind of interesting almost that this happened.

and are people on the list being like, why do we still support the Dreamcast? I like to think it's a long list. But the Dreamcast is totally fine. I like to think there's a couple of load-bearing Dreamcasts out there running the Lamp stack. That's what I like. Look, it's been hosting my personal website since 1998. Or it's like some Colonel Developers email server from like, yeah, 99 or something like that.

Like in 2000, you gave up on it and just turned into a Linux mail server. They're still maintaining it. Well, they might be running off disks. So GD ROMs, those discs, are mount properly now in the gamecast. Just in case, you know, you're having that problem. So don't forget, like, I-486 is also gone from that. Wow, right. Yeah.

Hey, 14,000 lines removed, though. It's true. That's quite a few. That's 80 whole files. And Linus says here, Zero real reason for anybody to waste one second of development effort on this. It launched in 1989, supported for 37 years in total, which is 18 years after Intel stopped making them. 6.12 LTS still supports it, though, till 236. So don't worry, Chris.

That 612 is the MVP kernel, guys. Yeah, you want your Apple Talk, you want your 486. Honestly, and I hope we are right now. If we're still going in 2035, 2036, hand this guy, I hope. We got a challenge. We should load up 612 and get a 486 box that we can still get booting going. Yeah. That would be pretty great. Okay.

All right. I mean, this is pretty solid, right? We got a lot of kernel releases here. I mean, a lot of times you're not even going to think about this. We like to think about it. We like to pick. But I think a lot of us don't actually have to think about it that much. We hope that maybe you're the kind of person that does give it some thought.

seven kernels, two of them are finally aging out at the end of this year, and one that does kind of break your GPU performance, so be careful. But the clear MVPs for Home Labs, if you need modern graphics hardware, is 618, and if you just want to set it and forget it forever, is 612. I mean, 612 is getting the fixes that we talked about for the performance regressions. It's getting support until 2035, and it's going to support 486. Probably also has Apple Talk in there. I mean, probably has Apple Talk, right? It does. Oh, my goodness.

What an MVP of a kernel. Are we calling it the legacy kernel? I think we should call it the MVP super kernel. I mean, that's what they call it. It's the MVP Super. Let's do it. We got all kinds of links in the show notes if you would like to nerd out and read more. And there is some good reading in there.

And you know where to find those show notes over at LinuxUMPLug.com. Well, we got a really nice email into the show this week, or more accurately, into my personal email. And here's the title. serious security advisory for your cold card. And I thought this was a scam at first because I've been getting a lot of really quite sophisticated spam into my email. And it's been very entertaining to watch, but nope, this one's real. And it got me a little nervous about what the heck is happening out there. Do you guys have any idea why I got this email?

This is a tragic story. As of this weekend, almost 2,000 addresses. have been drained of nearly $90 million worth of Bitcoin, affecting cold card wallets, initially the cold card mark three devices, and then later expanded to include certain Mark 4, mark five, and Cold Card Q firmware versions, basically everything but the most current emergency firmware that was released over the weekend. And it comes down to a issue in how the cold card generated random numbers. You know, we're going to get into this. Randomness has been a real challenge, and a challenge for Linux, too, that has gone wrong in catastrophe kind of ways.

So in this case, the cold card had a firmware bug that sent the seed generation down the wrong path. Instead of using the hardware that was built in to derive a seed phrase that, or a key that had low entropy, it was falling back to like a Python script, in fact, a micro Python script that roughly generated an entropy of 40 bits on the Mark 3 and 72 bits on the later device. Yeah, it's essentially the micropython runtime provides sort of like a random, a basic random generate. It'd be fine if you were using it for like, you know, an offset in a cron job or something like that, but it is not meant to be cryptographically secure. Yeah, it doesn't generate complex enough cryptography that it can't be figured out. So the hardware was designed to generate strong randomness.

The hardware was present. It was working, but it just wasn't being used, which is really a tragedy. And so because people can now mathematically derive the seeds, they are able to essentially restore wallets on remote systems and drain the cold cards without ever having your cold card connected to the internet or your computer active. Yeah. So essentially without the hardware part that was supposed to be like the secure random entropy, the fallback random number generator was seeded from the chip's UID, which is like a unique ID on the chip that has a limited possible amount of numbers and a boot time. timer state. And that, neither of those are truly secret. And a lot of them, it turns out to be kind of closer to a predictable range than something random. And then so if you can kind of constrain the space of things that the initial secrets generated from, then you can explore that space and the rest of it's all just deterministic. And then you can generate a whole bunch of private

keys at once and then just go check them. Yeah. And before the computing machine became easily accessible to us, analysis confirmed in the past that the hardware worked. That's what people really focused on in their audits is that the hardware did, but the hardware said it did. They didn't test if the actual path to activate it was working until LLM assisted security reviews came along and discovered it. Yeah, because the code to use the hardware is in the binary. Like it's built in, it's available. It's just never called.

Yeah, yeah. So the code exists. It works, but they failed to verify it was actually being used. And so as a result, attackers have been able to access. people's funds. And that's a tragedy because people thought they were doing the best thing they could for themselves, they were keeping them offline and all of that. And it got us thinking about some of the previous times in Linux where random number

generation has gone horribly wrong. It's not necessarily a hardware story itself. It's really about the difficulty of generating true randomness on deterministic systems, right? Because if you give a computer the same input, you're going to get the same output every single time. So the limitation then is how do you generate something? something that is truly uniquely random on a deterministic system.

And it has to be something that's sound and secure and hopefully as future proof is possible. So when something like this happens, well, you don't get rugged. And that is more difficult than it seems. And it's something that Linux has been working on since the very early days, like since 1994. Yeah. It's essentially cryptographic security is essentially a bet, right? It's like not a law of physics. It's not a guarantee.

You are just trying to do everything you can to have a giant pool. of randomness to pull from, and then keep that hidden and secret and intact across the entire chain. And there really is a chain, like it's not just, you know, give me number and done. It takes a lot of setup. Yeah.

So kind of how it works today, the very first step is some of the most important, and that's getting quote unquote, unpredictable inputs. And this is stuff that comes from a large space that's really hard to guess. So Linux, the kernel, is continuously collecting small little timing variations and environmental noise,

and pieces of the system that are sensitive to things like that. So when does a hardware interrupt fire, which one fired? It can even be like noise from the disk, user input, just things that the system generates that are unique. Totally. CPU timing, bootloader provided seeds you can use. If you want to bootstrap randomness in a VM, you can also use hardware things, either included by your CPU manufacturer or an add-on device or something like that.

And part of the idea here is that no, you're not trying to make sure, every single source needing to be perfect on its own, you can try to mix them together so that even if some don't have as much randomness in there as you think, you're still getting a good final randomness on the other side. So after you're able to find a bunch of different sources, you mix that into your entropy pool, and you need to be careful because the most dangerous time is when you boot something up fresh, because there hasn't been a lot of time for environmental noise to get into the system.

There hasn't been, you haven't really done anything yet. It's all kind of starting code cold from the very non-random initial firmware and like, you know, first code that runs on the system. And so a lot of work over the years has been around like, do we need to block if there's not enough randomness or not? What does it mean to have enough randomness or not? And Intel's tried to solve it with their R-R-R-R-R-R-and kind of built-in stuff that's trying to generate some noise. But of course, that thing's a black box. You can't use it as the one source of truth. Yes.

And that's where like the colonel folks have said, like, it's okay to use, we think, but we're not going to rely on it in terms of being the only option. we're going to make sure we mix it into a bunch of other stuff. So even if it is compromised, that limits the damage. Yeah, I would say in a way, random generator in Linux is a story of learning that we need multiple sources and we need to make sure that we don't trust any one particular source. We have a clip from Jason Donfeld, and he took over the Linux random generation system from Theodore Soe, who originally created it in 94. And this was some of Jason's observations when he started working on it.

And, you know, he's a developer and he tells it like it is. But I think if you look through that, it's a fair assessment. It's in Random.C, which is really old code. It dates back as far as I could find to version 1.3.30. I mean, it's really ancient code. There's a copyright date on it from 1994. So I think that even the code was living someplace else before there. But actually, considering when it was written, it's not so bad.

It's held up remarkably well, despite the knowledge. that was around in that time. And I think for all intensive purposes, it's okay. It's held up. It's been done with some reasonable intelligence. But still over time, there's been a lot of complexity added to it. But that complexity is kind of necessary in order to generate randomness that doesn't have one single point of failure as well.

Yeah. I think it has point two is sort of identifying like what's the essential complexity and what's sort of the complexity that's just crept in over years of maintenance? And how do we keep what we need, but also keep it simple enough to understand? And so on Linux as an end user, you know, you perceive this as there's dev random and there's devU random. And when I was reading about this, one of the things that I thought was really fascinating is early on dev random or maybe it was devU random. I can't remember. But one of them would essentially let an application ask for a random number, but wouldn't force the application to wait for the correct answer.

And so applications would query, but this thing would take a minute to generate. And then they would be like, okay, got it, when they didn't actually have like a truly random number generated. And so later on, they had to create an API that would force the application. It's just called get random. It's the get random API in the Linux kernel. They had to create this API that would essentially manage all of that for the application so they could, in a sense, force the application to wait for true randomness to be generated.

But then for compatibility reasons, they had to like allow the API to also keep that working in the background and just allow the application to move on and think it had everything it needed. Like it's this funny kind of line they have to walk every time they try to make a change to the system. So I imagine complexity does seep in. Yeah. And I think part of it was just being confused around like the intentions. Like U-R-R-R-V-R-Bus like never super clear. But what the new interface is able to do and get random is it has, um, underneath there's CRNG ready. And so the kernel now tracks whether it's random number generator has been seated with enough, quote-unquote, real entropy to be trusted.

And that's the gate you want to wait for. It doesn't really matter if you've generated a bunch after that, which is sort of where the U-Randum versus random didn't ultimately make sense. But what does matter is, especially at early boot, has the pool itself had enough mixed-in entropy yet? And that you probably do want to wait for. And that's where it becomes important to, like,

you know, not roll your own stuff, to rely on standard APIs, to rely on trusted, audited libraries that are using the correct code paths because that can and does change over the years. There's been improvements. Is there anything else you want to touch on before we talk about when it went horribly wrong?

No, I guess just the rough idea is you grab random bits, you mix them into a pool, you wait until that pool has sufficient entropy, then you use deterministic pseudo-random number generator stuff like Chachot 20 in the current kernel, and that sort of stretches that value. It can't add more stuff, but it can turn like initial secret seeds into big, long streams of random numbers.

And that's what you actually pull from. And they sort of generate ephemeral keys and then generate stuff and then throw them away. And there's a whole process around that. But it's not adding new entropy. It's just using the entropy you have to get as many random bits as you actually need for user space. Okay. So when you don't get enough random bits, you have situations like the cold card or a situation that lasted multiple years, CVE 2008-0-160. also known as Debian's open SSL bug.

I remember this one. And it started very innocently. A Debian package maintainer was trying to silence a memory analysis tool, a Valgrin warning about open SSL utilizing uninitialized memory. And it seemed like, okay, well, this is an easy two-line fix. Clean that up. And normally that's good, right? Because why are you reading from memory that hasn't been initialized? They can't possibly have a value you want.

Right. So they remove those lines of code. they ship it, everything seems to be fine. The issue was, is that they had basically really cut down the entropy of the keys that were getting generated for things like OpenSSL, which you can imagine what that impacts. In fact, it didn't just impact OpenSSL. It was like everything that needed a cert. So SSH, all your X-509 keys, like everything got affected by this. And the worst part was it was out in the wild for two years before researchers discovered it.

So, this bag which affected OpenSSEL, the random number generator, was introduced two years ago due to a Tebian specific patch. So it's a Tebian specific bag and remained undiscovered for two years. It's almost exactly two years until Luciano discovered this. And it was published on May 2008. Think about the scope of this for a moment, right? You've got to reissue and revoke every key that was created from 2006 to 2008. There were, I mean, just maybe millions could have been in the millions that were affected by that. It was a massive, massive issue.

Yeah, it also affected a chunk of live Tor relay nodes at the time, which isn't great. Under the hood, what was happening is that OpenSSL was actually intentionally using uninitialized memory as an unpredictability source, right? The idea is on different systems, other processes, whatever's been in that system,

how it came up in the hardware, all of that will be different. And so it's one of the very few times you might actually legitimately read from uninitialized memory. Valgrind doesn't know that. And there hadn't been any infrastructure or communication or clearly comments around it

or whatever to make it clear. And so when you remove that, it wasn't like there was no other sources, but it was essentially only the process IT that was left in the pool of entropy. And so that's like a number between one and like 32K at the time. And that's not enough.

Right? You'll start having... And so how they found it is that they found real world collisions out there. Right. And that's the only way you can because if you just look at output from this random number generator,

you can do statistical tests on it. You can look at. Just sampling that one value won't, tell you. It doesn't tell you how big of a space it came from. You, the only way to do it is by looking at huge samples of the outputs in the real world, effectively. And so it's really hard to do, especially for a developer making a change, and it's kind of the thing that tends to favor the attacker. It strikes me, too, that if an automation tool led to a mistake like this today, we would probably spend 90% of the discussion having an existential panic about automation

tools and 10% of the discussion about the actual bug. But back then, it wasn't, that wasn't the conversation at all. And it was so, it was so massive. And there was a lot of downstream issues as well. And it's reminiscent of the cold card issue. When you dig through it, you know, it looks like this person that was, that made this commitment, I don't know for sure, but it looks like maybe they were a Python person and they didn't understand the C code and they didn't really know

what they were looking at. They thought they applied a fix that, that solved an error that was happening when they were compiling the firmware. They would get this compiler error over and over again, and the guy went in or the gal, I don't know who it was, went in and made the change that ultimately bypassed the hardware and used the micropython. And they resolved the build air and considered it fixed.

And all the tests were making sure that the build flag was there to say enable the hardware RNG, and it was there. It was just, it's supposed to be a one and it was a zero. And there was no check on the value. there was only ever a check that the VAR existed. So I just sat there for 20 months, just waiting for somebody to come along with a tool to find it. And it is the case, right, if you did add your own passphrase thing on top,

if you had brought in your own sources of randomness. Yeah, which you can with the cold card. You can provide your own entropy. But then you have to do that, right? And if you're buying a device like that, you assume it's... Part of the value was like, well, this has a hardware source. That's part of why I'm buying it. It's so sad that the exact thing they were promising is the thing they didn't do.

Well, yes. Unintentionally. And it was for people that had all the best intentions. But it makes me realize, you said at the beginning, or towards the middle of the West, you said, you know, don't reinvent the wheel, try to use things that exist. In a crazy twist of fate, people that rolled on a Linux box and used the Linux random number generator were, are better off. And I think there's a lesson in that. And it's why Linux is so important to us as a society is that it is a general technology platform where there are people with mutual incentives that are improving the system and making it and testing it. And every time we go outside of that and we recreate something, you take on risk.

And this time it's a type of risk that was at the firmware provider level when a lot of people were thinking about physical security and air gaping and, you know, 9-volt batteries and all this kind of stuff. and we're not really focused on the actual threat. And it also speaks to, you know, open source is not enough. Maybe that will help in our new era of automated reviews, but, like, the code was out there, right? It wasn't that it was, obviously, the hardware is somewhat hidden, but the code was there. You know, it wasn't like a truly open source license.

And I think if it had been like a GPL license, maybe more people would have built off of it and discovered this, but because they didn't want people doing that, they did like some sort of like read-only, you-can-view license kind of crap. And this is also one of the side effects. of that. And it just goes back to like that's why Linux is so important is we have solved some of these problems

and they continue to be monitored and maintained and it's done right. And it really comes back to like we invented it once and we've continued to iterate on it. And what started back in 1994 as kind of a simple system has developed into this truly robust multi-source of

noise and entropy truly great as we can get on these determined systems random number generator. And And I've just, like, that's just one of the many gifts of Linux is that these things like networking and disk I.O. and random number generation and cryptographic signals, all this stuff is handled by Linux for us. And we get, such a gift. We get a world class product for free. You don't have to go buy a proprietary, you know, cryptographic enhanced, you know, private OS from Microsoft or from Qualcomm or for whatever. And just trust that they got that aspect right. Right. No, you just use the standard kernel that is open source and anyone can download. Oh, my goodness, gents, there are some boosts here. We're going to start with our baller, Greg, the lawyer.

Hey, rich lobster! Greg came in with 133,33,000, 333 sets. Whoa! Thank you, Greg. Appreciate that. Greg is also adhering by the rules of the show. One of the boosts is a roll of sticks. Was that a rule?

And it says, yeah, well, the other one is actually. It is now. We've said that, I think, twice. He wants to reward early movers on Buzz. Not for me, but as a Mac user since 1984, I appreciate those early adopters. Aw, sweet. Yeah. Greg came coming in with a live boost here

because we got low support for last week's episode, and we realized we probably should have waited a year to cover Buzz. And so thank you, Craig. We appreciate that. And thanks for hanging with us, audience. Also, a few Satoshi's in there to feed those chickens. I do have, I wonder how I'm, how I could get those public in a way that wouldn't drain my internet.

But I do have a few camera set up on those chickens. But do I want to dedicate one to two megabits of my precious Starlink upload link? I don't know. But if I can think of a way. Isn't that why you got the backup? The backup? Yeah. Well, I do the backup.

Oh. The connecting backup. We've been planning this for months, really. And then, like, if I have to switch to it for production, maybe I pause the streams or something. What about a system where people, you know, it's like you boost and then the stream is opened for a certain amount of time? opens the Engrock Tunnel to your ID.

Yeah, so you get like 10, you know, send in a couple sets, and you get like a 10 minutes of chicken game. That's great. They are the best chickens. You would not believe. Like Labradors. Like, they get on our lap and they just snuggle. It's ridiculous.

And Boss, the rooster, he's got a routine now in the evening around sunset. He comes in and watches TV on the couch with us. What's his favorite show? I mean, mostly it's Magnum, but last night he was watching YouTube. Oh. He doesn't mind. He just likes the colors.

Uh-huh. Nice. Tird Ferguson comes, and thank you very much, Greg. You basically brought up the whole trend for the episode. Tird Ferguson comes in with a row of Mick Ducks. Turd Ferguson! That's 22,222 Satochees. Things out looking up for old McDuck.

Oh, it's a live boost. The cold card mess has me tired. We trusted the hardware because it was offline, but the bug was already baked in and waiting fun times ahead. Yeah, pretty brutal. And then it can just sort of disappear out from, under you. You don't have to do anything. It's just moved in a transaction and the next time you check it's gone.

You're like, Brenton, you take a few days. You go check and it's gone. I did check this morning because I thought that was a responsible thing to do. Not gone yet. Don't try anything on me. But I got some homework to do after the show. Can you describe your cold card more to me? You know, it makes me think like, yeah, what else? That is a good point.

Oh, that's a good question. We're just getting this thing rolling, right? Because what do you think the coincidence is that it happened a few days after Kimmy K3 with open weights came out publicly. And it's one of the only really current top tier models that doesn't restrict you from doing cybersecurity stuff. And then three days later, this exploits found. I think it depends on how long it took to do some of the prework. Could have been going.

They could have been, we may find they were cooking for months. Or we may find that they slammed it in 10 minutes with K3. Because the reason why I bring that up is now people have tried it and it finds it in 5, 10 minutes. It's just immediate. Yeah, I think the main question is from finding it, how long does it take to generate all of the private keys? It's a massive sweep and all of it. Yeah, yeah, for sure. And I assume there was like some staging before you actually submit all the transactions. But who know? That's a great question.

I'm sure we'll be. I mean, that's the thing about the blockchain. People are already putting it all together. Well, E Scott Boosin with 2,371 sats. What, what? What happened with Next Cloud? I have two separate instances running. I even moved Sl. data off my Windows 7 NTFS share to a proper ZFS mirror with backups. Also, this is a Star Trek boost. But that's not possible.

Nothing can do that. So a quick version is I had like a cold stop, will not be using X cloud ever again moment, just because the data it wiped out was some of the most valuable data possible. And so what happened is I went to view a text file, just using the viewer like it's in the web interface, and you click on a dot txt file

and it opened and the instant it opened it wiped the document it put some escape characters in the top left corner and then it immediately wrote that to the file system and it should have just been a document viewer

it shouldn't have been writing and it did it instantly and Wes you looked it up and it turned out to be like some sort of like in browser issue that is very rare but happened on the client side rendering

and I realized for what I need there was just too much going on there and the fact that by just viewing my most important document, which is what I use NextCloud for, was for its privacy, totally offline, off the internet. By just viewing that document, I wiped it out.

And that was when I was like, I don't need any of this. And I decided at that moment I was going to stop using it, which has been a real pain in my butt. But when something fails that catastrophically on you, sometimes it just leaves a bad taste email. And that's after it worked for me for a long, long time. And doesn't mean it still couldn't be a great Caldev suite,

There's lots of roles that still make sense for, especially if you have robust backups and it's just one place to look at them. It was just sort of the last straw, honestly, because it's been a lot to upgrade and manage over the years, and I sort of have rolled back what I use it for to some degree. And so that was sort of the last thing I was really, really relying on it for, and it bit me.

And major reconsidered, do I even need it? Yeah. I did look it up. 2371 is a well-known year in Star Trek. So we got a few things. Well, third season, DS9 begins then. It's also the year USS Voyager launched on its hill. faded mission.

And it's Star Trek Generations is set in that year when Captain Kirk meets Captain Picard. That was such a great time for Star Trek. That was such a great time. Thank you, sir. Appreciate the boost. Thank you, Scott. Unicorn 1999 came in with 6,000 sets.

At some points in open source and with some projects who had to sign off that you were the author of the code and had not. used any source that was also not clean. But now with AI that doesn't really matter. It seems the who owns AI code question is not completely solved. Wait, well, why is that? Why is that? Well, it is, there's still active legislation or legal debates around it is one. So like, for instance, some courts have said that pure, like if all you did was one shot code, it can't be copyrighted at all. So I think the question of, you know, exactly the, the, law has not cut up with the current tool set is sort of one aspect of it. Like we have some cases that

mostly dealt with code in the era of browser tabs and nothing that's really dealt with the case of you're doing project management on an agentic harness and then you edited some parts of it or you reviewed it or so I think that's where some camps uh concerns are coming from just in that it's still an open legal question. So but it seems like if my self-driving car runs into brent and smashes his van up I'm legally responsible for that. It doesn't matter if the AI design degenerated that. Yeah, but that's a legal sort of, it's a separate set of law, essentially, right? Like, this was a judge making a case about if you could copyright pure AI generating content.

Oh, copyright, copyright. Yes. So, like, when you make something, not everything is copyrightable, but if it is a copyrightable expression, not just the idea, but the expression, you get to sign copyright to it. That's how you add a license to your code files. But they're saying if all you did was prompt a single AI to generate code, that cannot currently be copyrighted. Yeah, I just think in the context of most, most, not all, but most free software project, this is really ant-humping, because who's responsible is the person who submits it.

And this is sort of full stop. I mean, anything else is just sort of ant-humping. Now, when you're working on a giant international project, maybe that's really where things matter like that, I think. But that's my opinion. There were some explorations of laws in Europe, though, that recently suggested that open-source software might be responsible if people use it in certain contexts. So that's an interesting angle. Unicorn 99 here wants to clarify, though. I'm not anti-A-I.

I'm anti-corporate exploitation. Boy, sure, the corporate AI aspect is so obnoxious. It's so tiring. I agree with you there. It's the worst about it. It's the worst thing about it. And yet, we need their precious GPUs, at least for now. Hey, Mr. Mayhem's back with 16,000, Satoshies.

Boy, they are doing a lot with Mayo these days. Look at that. Boost the Roost. boost the roost, boost the roost. Something broke. It's a fill-in boost. Well, boost the roost indeed. Thank you.

Appreciate that. And that is all of the paid boost, but we do have some member boost. Would you like to kick that off, Wes? Oh, you know how I love a good member boost. A unicorns back. Oh, Unicorn 1999 comes in with a member boost. Hey. Coming in hot with the boost.

I think tech people bringing up the copyright issue is not only crap, but partially how copyright is always used by corporations against us, users. Like it was okay back in the day for ISPs to host Usenet servers full of TV shows, but not okay for people to download and share. We don't talk about Usenet. We don't talk about Usenet. Yeah, no, I think it's like we're talking about two different things here, Unicorn. Because everything you just said, I completely agree with. I just

think there's hypocrisy in folks that, you know, have their RAR stack set up or whatever or rip DVDs, then now concerned that LLMs are ripping content, right? There's just hypocrisy in that. But yeah, using copyright as a cludge is never good. There's also sort of like we're seeing projects now, which is perhaps reasonable in that they are much more established products, but projects. But we see projects now that are having concerns over copyright questions

that maybe were different than how like Linux was treated and being actively developed in the SCO era. Yeah. We're similar sort of copyright questions. Mm-hmm. Mm-hmm. Mm-hmm. Yeah. Mm-hmm. Yeah. All right, well, Greg, the lawyer's here with a member boost. All systems are functional. Welcome back to the States.

I hope the trip was flock-free. You know, I'm not sure. I doubt it, though. I doubt it. He says, I got fed up with Dario's nonsense and switch back to codex. I figure their model is better because they broke out first. Weird feeling when switching VC-funded... The weird feeling when switching VC-funded frontier models is how I fight in part for open-source.

Yeah, although if it makes you feel better, the codex is open source. The back end isn't, but the codex client is open source. Amadeus member boosts in I hate building PCs My workful of cleaning up my own drives Is using a great rust tool called dust Dust Find out what takes up space

Old Hugging Face models Old proton versions from Steam Podman containers etc Works great and I'm using it on every machine I control or manage The Podman containers makes me chuckle Thank you for concluding the very realistic selection of actual disc usage

Yeah really yeah And dust is Apache 2 license. Good to see. Nice little extra pick there. We've got Joshua here with a free members boost. You're doing very well. I'm a software engineer and always have ideas for side projects but no time to actually make the most of them.

Cloud code has really changed that though, but I worry about making my new projects open source because of public backlash since they're all written with AI. Do you have any advice? I would bet Joshua that you would actually find the reverse problem is going to be your issue, is that if you open source it and it's popular, you're going to have a lot of people that are contributing back with AI assistant code development. You're going to have a lot more of that than you are people that drive by your repo and get upset at you.

Yeah, like I think it would be different. Like if you vibe something up and go share it on three subreddits at once. Yeah, yeah. Like there are versions of that where you can get yourself in trouble. But if all you're doing is sort of putting it out there, I don't think you'll receive too much backclash. Anonymous comes in with a member Boost. Boy, they are doing a lot with Mayo these days.

It never occurred to me that a nutcase might not only have a thousand tabs open, that that nutcase might also have them scattered across dozen of windows. Absolute madness. Friendly won't open 10 new windows like some kind of entropy enthusiast. I know, I know. Are we, it says Anonymous, but I don't know. I kind of smell a PJ booth. I don't think I've been called a nutcase before, and certainly not for my tab habits.

Well, it came from the whole squirrel thing. Yeah, as a squirrel father, I think you would put yourself in the nutcase category. Yeah, that's fair. That's actually kind of a compliment. Thank you, Anonymous. Well, a sensor smile comes in with our last member boost. I'm finally ready to start playing with AI. However, I'm not sure where.

to start. I have a local Quinn model up with Lama CPP. The built-in chat interface is boring. How do I code with this? Hermes? How do you do long-running agent? A beginner's guide for the tech experienced. This is senior smile. You're like, you're starting with Bitcoin by installing a node before you've acquired stats. I mean, not necessarily a bad way to go to truly learn from the ground up, but you might you might just spend a month with open code and open code go subscription and learn that because what they're going to have for you is agents that are, A, optimized for coding, B, work right out of the box with tool calls. And when you're going to do your own Quinn and your Lama CPP, I love it, but you're going to need to use a front-end interface. You're going to have to pick one that understands all that stuff, that knows how to work with that stuff.

And that, when you're just getting into all of this, feels like a little extra complexity before you've even really figured out what they can even do for you. And they could also help. Like, if you do get open code going or whatever, then you can have it set it up for you. Exactly. It can have open code talk to Lama CPP, no problem. But that's just more stuff you kind of get in that isn't actually playing with AI. But you could have the AI sort of bridge the gap and then try out both local and cloud hosted. Not too bad there, Westpane.

All right. Thank you everybody who supported this episode with a boast. We had 18 of you stream sets as you listened along. And collectively, you all stacked 17,625 Satoches for the show. Thank you for helping us. Help you. Help us all. And you bring it all together with everybody.

who boosted. You're doing very well. We stacked a humble but very grateful 198,570 Satoshi's. Not the best hourly rate when you split it four ways, as we do, or five ways, really. I think it's like climbing there, but we still appreciate the support. It is a lean season. When you hear the dynamic ads, you know we're hurting.

But we really appreciate the members and the boost. It's also one of our favorite segments on the show. It's stuff we never really plan to talk about, but often is great conversation. And you can send a boost by going to bring. boost.jupiterbricasting.com or jupiterbroadcasting.com slash membership or Linuxunplug.com slash membership to be a member. That's it from us for the boost. Thank you, everybody who supported us. And we got a couple of picks before we get out of here. This is one I've been sitting on for a while because I thought maybe we would use it for our Texas trip.

But I think I'd like to put it out there and get a sense if the audience likes it and if anybody deploys it before we use it. But I could see this being very useful for us in the future. It's called Trek. I already like the name. It's a self-hostable travel trip planner with real-time collab features, interactive maps, progressive web support, single sign-on, planning budgets, packing lists, and more. I mean, this thing, and it looks good. It looks like a top-grade commercial application that you can self-host. And then you can work with your friends, your family, whatever it might be, together to plan a trip. And like, you know, make your big plans, put your budgets in there,

get it all on a calendar, you can subscribe to the calendars, like, you know what I'm saying? Like, this is a real tool with interactive maps and stuff like that. So you get a journal for every trip, you get real-time, collaborative planning, you see it all on a map,

it has lists and categories, it has, you can put in, like, we're going to go on a vacation, and you can have it pre-visualized that. You can track costs per person. You can drag things around and drop them on the calendar. And Wes, it's got an API.

Ooh, ho, okay. This looks really nice. Yeah, I'm pretty excited about it. Like I said, I haven't had a chance to try it myself, but I think somebody out there in the audience might be willing to give it a go and let us know. It is A-GPL3.0, and it is primarily typescript. It's got a Docker Compose setup, Kubernetes, if that's your style.

Yeah. Yeah. Okay. Yeah. Yeah. The real-time collab part sounds quite interesting. Like, we could just be on a call, workshop and a trip, trying things out. Tees and Brent about how long he has to drive.

because you put it right there on the map in front of them. Right. It probably helped me with that part. One of the big questions I have is, will it Nix? Well, of course. It does also have a Docker if you just want to go that way. But from that, you could get to a declarative Podman configuration in about two Licks and two shakes of a Lampstale.

Oh, it includes built-in MCP as well as an API. Great. I mean, you could see how maybe our agents use this to have a plan and they just tell us when they're done. All right, Brentley, you got a little sneaky pick. I believe that you wanted to pull forward, as they said. I'm representing this sneaky pick as producer Jeff actually brought this up to me, and he said, Brent, this is perfect for me and therefore probably perfect for you.

It's a to-do app that is called C-Fair, which is French, but I'm going to declare that everybody else can probably just say C-fit. Oh, yeah, I would have told me what you should call it. Can we get the French one more time? I would have said C-FET. I would say fat. I know because it's got a cat. So I would have gone with cat. You know,

because it has a cat logo. Yeah, yeah. Yeah, that works too. A silent F, right? In French,

that really means it's done, which I think it's kind of clever. Ah, I got you. Okay. But it's built for people who, quote, want keyboard-centric efficiency,

which I have been looking for forever. Jeff, you know me so well. It looks like you can use it comfortably from the command line via Tui. You can use a desktop GUI if you want. Or on the, the goat with a native Android app.

Ain't no electron in here. It's got a toey and a graphical app and an Android app. This is impressive. Uh-huh. I don't know how. None of us found this. It's also, it's apparently available

on Flat Hubbardi, FreeBSD. There's obviously it's in Froid and Google Play. There's Windows releases maybe. There's Mac OS stuff. The only thing I'm not seeing is Knicks, really, but we can get that thing. As a long time and slightly ashamed to-doist user, this,

this cooks. This, like, I think this is blown to doist away, even at the UI layer. To find shortcuts on the fly, wow. Yeah, yeah, it's nice. There's a little detail here. It's 69.5% rust. All right, you know what?

Does it count? We'll give it to it. It's over 50%. It's over 50%. Everyday usage, press the question mark and navigate to the help tab. Configurations in the CLI-2E under the hood. All right, so PJ, you've been trying this? Like, what's the deal?

What do you think? It really did catch my eye. in Eftroid, just going to do some updates and it was right there on the front. Smart. Yeah, I really do like it. I like that the Linux desktop app and the phone app, they look very similar. They're not these giant, just no giant changes between the two. Right.

So you don't need to necessarily learn all the key bindings because I never real remember them anyways. And I really like the subtasks. You can tree out things. I dream of an idea of having dependency tasks. This ain't quite that, but the subtask kind of gets you. there. So I've been using it. So it's like a, it's like sub-task isn't quite a project, but you can have a task with a bunch of things you got to do to complete it. Yeah, exactly. So I have, I've kind of

using it for goals. Like I have, you know, truck repairs, right? And then a bunch of subtask under that of the different things I want to do for my truck, you know, house repairs or home things I want to do. And I can have a bunch of subtas for that. And it's been working out pretty well for that. I like that a lot. Just a dedicated place. I can put the things I want to get done or, oh, I've got 15 minutes to kill. What kind of thing can I do? Well, here's a whole list of things I want to try. I want to do. Right. And I'll forget about them otherwise. How is the self-hosting side set up, the server side? Um, using NextCloud to sync everything up. So, so you don't have to run, like a back end in particular. You could just have it. Whatever Cal Dev server you want to use. Yeah.

Oh, okay. Okay. I see. I see. So they include Radical, a self-hosted, lightweight, feature complete thing you can use. Or, yeah, Next Cloud. Huh. This is great, Jeff. Nice, fine. I'm glad Brent. I'm glad he pulled it forward.

I may give this a try afterwards. Especially if I could store it. Of course, I don't know. If I could store it in something, we'll see. Yeah, especially if we can compose it with a few other things. The fact that it's got the Android layer solved. There's a lot of promise. There's a lot I like about it.

And the client's in FlatHub, which is nice. And the Android version is an F-Droid, which is nice. Okay, so PJ's now game correspondent, right? And I guess, like, he's also like a... Productivity. Yeah, productivity expert. Productivity, John. That's what PJ still works for that.

Sort of like a lifestyle expert. Yeah. Yeah. And a few other things, solar, long hair, floor showers. Oh, floor showers. He's got that down. He does have the floor showers down. Also our on-site California expert.

It's true. If you want to know anything about California, you just ask PJ. All right. Well, we'll have links to everything we talked about at Linuxunplug.com slash 678. We're slowly working our way to 700, so we hope you stick with us and join us live. You can make it a Tuesday on a Sunday, 10 a.m. Pacific, 1 p.m. Eastern over at J.B.Live. I say before we go, we tell people some pro tips. We should always, maybe we should start the show with these.

Instead of burying it all the way at the absolute end of the show. Right. We should like do a reverse show sometime. We just start from the bottom. Flip the dock. surely a bot could flip the dog we should flip the show all right next week

we should think about that that could be a lot of fun don't you think probably oh yeah at least tell us what we like and don't like how do you handle the intro and the outro do you do the outro at the beginning because that would really screw with new folks like you'll lose them immediately oh go for it come on what's one episode I don't know how

I think if we can I just the intro is the only thing we need some input on that but I would totally be down for a reversal episode that could be one no it's it works perfectly. You start and you say, about the same bad time, same bad channel, you know, make it a Linux on a Tuesday on a Sunday and join a Sunday. But then we play the outro music and what? No, it starts with the outro music. We'll figure it out. I don't think we will. And then you intro the show at the end. I think we need out. That's what I think. Drew will save us. Oh yeah, sure. Yeah. All right. Okay, very good.

But in the meantime, JSON, it's in the cloud and in the feed. We put JSON in our XML, but then we also put like text in there in in the form of a VTT. That's true. So you can have it either way. And we put in a link. It's not the whole MP4, but there's a link to an MP4 embedded within it. Yeah.

So you could watch it in Vigivision, and you may be surprised there's visuals, but because we're such effing pros, you can just listen to the audio version, and it never detracts from that to such a degree you wouldn't even know there's a video version. How about that? So, yeah, you can find that MP4 in the feed as well.

And our mumble room is always going every single Sunday. So do join us live. It's fun. It's unique. And not a lot of podcasts do it. See you next week. Same bat time, same bat station. And, of course, links to everything we talked about at our website, Linuxonplug.com. And the bat catalog and all the other great shows over at jupiterbredcasting.com,

as long as you want to check it out, you might as well go to the calendar. It's over there and a contact page as well. Would you believe it? And the last but not least, you can get a message and support the show at boost. At jupiterbredcasting.com. And you members, don't you forget, you get a free boost every single episode because we appreciate you so much. In fact, we appreciate you just for listening.

Thank you so much for listening to this week's episode of your Unplugged program. And you know what we're going to do? We're going to work on a show right after this, get cooking on another one, and we're going to see you right back here next Tuesday, as in Sunday.