655: Speeding Up Mistakes

No shade to all the folks up on quiet listening. To be honest with you, if I was listening to the show live, that's how I'd be doing it. I'd be up there in the quiet listening.

You can let them manage it entirely. You can have one system to talk into another system for backups, or you can have a worldwide enterprise system. It's best in class. It's very impressive. It's one of the projects that we have

followed from the very beginning, and we're super excited to have them on the show because we love it. We've been, like, totally dialed into where this thing's going, and we're using it. Nebula was built in 2017. That's how long we have been fanboys. So go check it out because you can get started, 100 hosts for free, no credit card required.

You go to defined.net slash unplugged, and you deserve a better VPN experience, one that you fully control, especially when it's your infrastructure and you're going to use it for a while. Defined.net slash Unplugged. And thank you to Defined for supporting the Unplugged program, our one and only sponsor right now. Well, Planet Nix is just one episode away. We will be in studio, although I was thinking it would be fun to just hit the road early and do one show from- You're right.

Phlox is sending us there. I'm very, very grateful for that because this is something that we would have so much FOMO on if we couldn't make it.

They're in the right position. they're trying to make reproducible dev environments that are actually usable for everyday folks they're kind of you know in the mix here so we're going to have a meetup, it's going to be great meetup.com slash jupiter broadcasting the details aren't necessarily final there but we will get them locked in we do appreciate if you're going to make it if you can sign up because it lets the venue know one more unplugged boys.

And we do appreciate your patience. Really, we do.

Well, we had a chance to sit down with Michael Stonke, the VP of Engineering at Phlox. And i did a little of my internet stalking before we sat down with michael and i discovered that he's been responsible for some projects that we have all used and benefited from in one form or another so he joins us now he'll be at planet nix in just a couple of weeks as well giving a talk yep giving a talk a good talk we'll have that linked in the show notes so let's welcome michael to the program.

Still involved in packaging, turns out. Yeah, I mean, that was kind of how it came full circle was when Flux kind of reached out to me. I was like, wait, that was me to run a whole business based on packaging? Hell yeah, I'm so in. So yeah, I mean, I've loved packaging my entire life. It was just one of the coolest things I have ever gotten to do and work on. And so why would I not want to keep doing it?

And, you know, there's different ways, there's different theories, but I've packaged for basically every Unix and Linux under the sun.

And they all have advantages and disadvantages. advantages and nix was actually something i had looked at first in i'm gonna say 2007 2008 somewhere in there and and i just thought okay a bunch of haskell people decided packaging just wasn't difficult enough um and they made nix and so i kind of dismissed it for a long time and you know obviously kind of sitting on the sidelines i saw things mature and stuff like that but i really

hadn't given it a shot until flox had reached out and i started playing with it again i was like oh there's actually a lot here that i really like so yeah and looking back on it i would have changed my career completely if I'd have known Nix, because some of the work that I was hiring dozens of people to do probably could have been removed. Oh, yeah. So I guess also for a little bit of background, you spent some real interesting time at Puppet during a real key moment in history and CircleCI.

So that really feels like a very interesting background to now bring to Nix, because it's a totally, totally different world and sort of almost a 20-year journey to kind of bring you to this point. It still must have been quite the leap, though. I have to imagine from that background, going to what you're doing today, that must have been a bit of a mental learning process.

The tech wasn't too bad. I mean, there's, there's new words, you know, you hear things like derivation or you hear things, you know, like provenance, you know, spoken about so regularly and things like that. And like, that's, that's fine. And it, but so there was new vocabulary to learn, but most of the principles were basically the same, you know, it was like, why do I chatter the immutable bit of my distribution server?

Well, because it should be read only. So you can't ship the same thing with the same version with a different shah sum. And it's like, well, it just handles that internally. Like, you know, so there's a lot of those principles made total sense once I unpacked them. And there were other things that didn't make sense and frankly still don't to a lot of degrees. You know, there's just choices that are made. I'm like, I have no idea why this decision was made or for whom this was made.

You know, was it made to make one developer's life easier or every user of Nix easier? You know, things like that. And I'm, you know, and again, there's just not, every technology has these moments. So it's like, this is not unique to Nix. Yeah. But, you know, kind of from the puppet world, where we wanted to declare the state, we wanted to have, you know, state enforcement and all of that.

Looking at Nix, you actually end up in a very similar kind of CSE, you know, graph theory, I'm going to walk my dependencies kind of mode. It's almost the same stuff. It's just applied through a, you know, different language lens, different client server models and, you know, things like that. So, yeah, maybe you flip it a bit, right, where you can the system's working with you instead of sort of having to impose item potency from afar after the fact.

Right, right. It does make me, it does kind of stand out to me that, you know, between Apple and Puppet and Circle, like, you've been involved clearly with a lot of the different lifecycle in software, not just, you know, building a backend service that runs a SaaS. It's like actually having to do good builds and get them out there on infrastructure and get them configured and running properly on end machines, which I think probably connects a bit to Fox's mission, too.

Yeah, I mean, you know, at Puppet, it was built basically a whole distribution of this thing called Puppet Enterprise. that had to run on all these different platforms. We're testing on 100 different targets or whatever. And so through that testing, we had to build custom CI systems because there was nothing off the shelf that did anything that we needed it to do.

And eventually that's where CircleCI comes in. They see me give presentations on the way we build and test Puppet and they're like, we'd love to have you. And so I get to go do that, which is super fun because the cost of being wrong at Puppet was you had to ship a new version. You had to wait for your customer to take it up. And that might be a change window that's nine months from now before they even get it installed and all that.

You go to CircleCI and it's like, Like we can ship literally 85 times. And it was just awesome. You know, like that is so cool. And then at Flux, there's a little bit of both because it's like a client piece and a server piece. And the servers, we can be moving all around and we can be updating and, you know, adding new observability capabilities or, you know, whatever all the time.

And then on the client, we ship it every two weeks and roughly, I mean, almost always every two weeks, but every now and then we take a week break if it's like a holiday week or we're all at an offsite or something. But, you know, and that gives you that client on your computers, whether it's, you know, client, server, laptop, whatever, but, and, and so it has a little bit of both of those like backgrounds that I really, you know, got to, got to work in.

And so it, I would say, generally, it leverages a lot of my background pretty well. So then, okay, where is the gap now for regular enterprise adoption? Because you kind of just made a great case, but it still seems a little slow. I mean, it's picking up. Yeah, I think that a lot of the friction is, it's like socio-technical, it's not just technical. And so you have, you know, I think Nix is, it's cool.

It's, it's, well, the documentation and the getting started guides are still a little bit esoteric, or maybe you're like, this one's weird if you're doing it in this way versus that way.

But a lot of companies end up evaluating nicks for using it and what we find is there's kind of one person who's the champion of the nicks you know experience and if that champion is no longer available for whatever reason you know they win the lottery they leave they get hit by a bus they are on pto they have a baby whatever it is the nicks effort kind of stagnates and then basically gets a bad rap because people like oh this nicks stuff no one understands it

but like we rely on it this sucks it's always broken no one knows how to fix it why do i have to learn all this that That doesn't get totally different. Yeah, right, right. And so, you know, when Michael, our founder. You know, was at D.E. Shaw, which is a giant hedge fund, you know, big financial services. Cost being rung there, very high, by the way. You know, you're talking millions of dollars a minute at times. So, and so for them, they needed a lot of precision, which meant they need to

know where software came from and everything. And so they found Nix as this build system. And he was, this is awesome. My developers can't use this. And so, he started working on what are the abstraction layers, what are the patterns, what are the workflows that people need, and that was eventually spun out to become Phlox.

And as we've been developing Phlox, it's been, well, how do we work on team collaboration and team usage and team understanding versus kind of that superhuman individual that maybe eats, sleeps, and breathes this stuff and sees it more religiously than probably pragmatically. And I think for us, if you're religious and love Nix about it, cool, that's fine.

I think a lot of people just want to get their work done and move on and that's cool too and so we want to help you do that with these principles that are awesome from nix yeah kind of it kind of reminds me of of editors you know you could do something where you have a custom neovim setup and it really fits you and you've like made it bespoke and it's great and it works really well but you can't really onboard someone to that and it's kind of nix is the

same way right it's a it's a private superpower it's incredible but yeah trying to make sure everyone else is on the same page with your particular way of injecting the right uh modules different story. For us, like, one of the more interesting things I would say about, like, Flox right now is we're not just trying to be, like, Nix++ or Nix with a veneer.

You know, like, there are other capabilities within Flox that are more about portability of usage and about acceleration of environments and, like, all these kind of environmental things that are, I would say, more Flox primitives than, like, Nix primitives at this point. And that's really important to us as well because we don't just want to be, like, Nix++ because if all you're going to do is make Nix better, just go work upstream and make Nix better. Like, that's the right thing to do.

But we were trying to build it more with a commercial eye toward adoption from, you know, businesses that actually want to want to get work done and have a build system that's consistent. Any of those primitives stand out? I'm just kind of curious. I've dabbled with Phlox, but I haven't used it in part of a shipping team yet or anything. Yeah, I mean, I think the Phlox environment is kind of the thing that we would say is different.

You know, in a lot of ways, it resembles a Nix profile, but it's like a Nix profile that is a big superset of what a Nix profile can do. You know, we have service management within there. So you can have developer services kind of into, you know, you could say flock services start or flock services status and kind of get, you know, I have my Postgres running, I have my Redis running. So the second I can clone the thing I'm going to go work on, I can just clone, activate, start services.

And now I've basically got a working developer setup, you know, within moments. And then more on the runtime side or, you know, builder side, you can build custom packages. You can add them in there. you can activate things where you have libraries enabled to compile against or you only have binaries in the bin path. It works with ZSH and not just Bash.

So there's all sorts of enhancements that we've done there but some of them are also just not things that a Nix shell sets out to do and that's totally fine. For us, we want the Flux environment to be the unit of change. It's got history, it's got generations, you can roll back to previous versions of it, everything like that so that it's more of an enterprise capability. Yeah, that makes a lot a sense of kind of taking some of the ideas in the broader

ecosystem in ways Nix gets right and maybe applying them to a broader scope of ideas. That's neat. Yeah, if you kind of think about like a thing that was a unit of work and all the CNCF workflows and, you know, we built all sorts of tooling around it and everything. And it's kind of similar like that. And we just we use the Phlox environment. It's not to say we can't work with containers, by the way. We totally work with containers, but you don't have to. It's optional. Yeah.

OK, so I want to shift gears and talk a little bit about another gap that I think maybe you're bringing up in a talk on Friday. So I kind of wanted to get a sense of, oh, I don't have a picture. I kind of want to get a sense of what you'll be talking about, Nix and AI, are we there yet? And then you have a line in here, why aren't more ML teams using Nix? Yeah, well, so there's like so many threads to pull on in that topic.

And I mean, I think part of it is model distribution is, it's expensive and it's bespoke to a large degree. It's like your home directory has a dot, you know, olama directory or whatever. And it's just got gigabytes and gigabytes of stuff in there. And if you have another user on the same system, they have this same thing. They also have gigabytes and gigabytes of stuff in there. It's just like, I mean, just from an efficiency standpoint, it makes me angry.

But like also is it versioned is it packaged like how do you know what's in it where did it come from was it from hugging face was it you know did you get it straight from somewhere else did you just go download it off github like there's all sorts of needs there for those ai and ml teams and i think you can just look at it as well what if they were just packaged and like you know they should be read only like those models shouldn't be being written to so

like a lot of the things that nix does by default you kind of want those those those defaults and And so packaging some of that, but also, you know, just being able to pass it around and be like, you know, we, a lot of those models also don't care what architecture they run on. So you don't need like a package specific, like this is on AR64 and this is on, you know, PowerPC or whatever. It's like, it's, it's just inputs.

So not all of them depends on the model exactly, but like, you know, there's just different ways of doing that stuff. And so I think that's part of it, but also one of my favorite things I've been doing since I've worked at Phlox is I have a program that I like to throw and say, generating expression to build this program. And I'll throw it at an LLM. It's a really, really simple Go program, I'll be honest. Like it's maybe got, I don't know, maybe 15 dependencies and like most of those

are really well-known Go stuff, like nothing esoteric. And when I first did it, i'd iterate with chat tpt 30 35 times to get a build that worked yeah and it was like crappy and like now you know if you pull up like anti-gravity or claude or whatever and just be like hey yeah give me a nix expression that it one shots it yeah and like that is a huge difference and so now when it one shots it's like is this the best nix expression i've ever seen no that's right um you know does it

do everything the way that i would prefer it to be done no but does it give me the package it does i'm like that's huge and so some of this is you want of look at like evals over time and the way that most models are are kind of scored is they have these things called formal evaluations and we've never built one of those for nicks i just had this program that i've been using for three years and like that's what i've been doing that's been my eval and so i'll probably end up

talking about that i love that yeah that is really okay i'll be there um yeah all right so i have i have a question unrelated but i have to ask you before we let you go because you know i was doing my due diligence and uh i always like to check out a guy's GitHub before he comes on the show. And I noticed that you have a project called Mandatory Fun, a repository called Mandatory Fun. What's this about?

So it's basically this idea that I had with a buddy of mine, or maybe a couple buddies of mine, that was, we love to make different collaboration software. And basically, you can think of it as like shitposting at scale. I don't know if I can say that, but I will. You can beep it out, I guess. So, but, Like some of it was, we wanted a pipeline where you could shoot your AI generated images as fast as you can and it would drop it into a channel in Slack.

And like, it's just fun that way. Or like we had, you know, like I think a lot of my Hubot extensions are in there. We have a lot, you know, a lot of like bot related activities in there. And then some of the stuff I was also playing with how does a monorepo work? Because that is a giant monorepo with several subprojects. And honestly, the more that I played with it, the less I like monorepos again. I go back and forth every time.

Just like the industry. Yeah, the grass is always greener where I'm not standing. But, I mean, generally, I also have a thing where, like, if you have, like, a permanent Zoom meeting and somebody joins, they can throw a webhook and, like, notify you through Slack so that you can say, hey, somebody's joined the Zoom.

And so, like, my buddies and I have, like, a standing Zoom. And if somebody's there, you get a notification, and you can be like, I have time to join right now and say hi or whatever. And so it's just stuff like that where it's a bunch of how do you collaborate with your friends? And, I mean, not to say that it wouldn't work in a work setting, but it certainly wasn't designed that way. And that's why we pulled the name Mandatory Fun as just an idea.

So I think just it's a great it's a great just a great title. Mandatory Fun. That's that's always that's always how it works. And a nice mix of, you know, right. These sort of collaboration, corporate workflows. But yeah, like real people want to do it in a more casual way to get fun stuff done. Yeah. Yeah. Well, and there's no rule that says you can't have fun while you're working. So I encourage people to do that. Well, I think we're going to have a lot of fun at Planet Nix.

I'm really looking forward to it. Yeah, I certainly hope so. you know I think we have we have several hundred people registered right now and we usually get about several hundred more during the last week so you know it should be should be four or five hundred people which is, And there's so much going on this year. It's going to be just like the energy there, I think is going to be crazy. People are going to be laptops, open building stuff.

Yeah. We, I mean, we have work areas. We have, you know, kind of workshop tables. We have talks. We're going to have stickers. We're going to have giveaways, trivias, all sorts of stuff. Gosh, we got to get ourselves to California. Mike, thank you for coming on and chatting with us. And I look forward to seeing you in California in just a few days. All right. Well, thank you so much. Thank you, sir.

support the whole network and help us get down to scale. And, of course, you can send us a boost to get us down there as well. Appreciate that. Well, Kelsey Hightower is back. He joined us about a year ago. He's a software engineer who calls himself retired, although for somebody who's retired, he still works quite a bit. He hits the speaker scene a lot. He is known renownedly for his Kubernetes work, open source advocacy, really an insightful speaker.

And he's going to be joining us at Planet Nix, but we had a chance to sit down and talk with him before Planet Nix. Kelsey welcome back to the unplugged program and happy pre-planet nix to you.

made a really i think keen observation in an interview you had with jet brains back in december and you said that you spent your whole career trying to make these systems as determinate as possible, right? To know exactly what they're going to produce every single time. And this is, in this last year or two, it's kind of flipping that on its head a little bit.

And I wanted to know if you could expand on that comment you made in that JetBrains interview, because I thought that was pretty insightful.

So these are machines first and foremost. And when we build machines, we kind of want them to do exactly what they're designed to do. Light switch on, light switch off. And so when you turn that into the software world, anytime we get behavior that we ourselves didn't intentionally design, we call those bugs or defects or security vulnerabilities if they're ever exploited.

And so we've been spending the last, I don't know, couple of decades trying to build reproducible software, deterministic software, right? We want these things to be predictable. So then we can make promises. Like we have SLA as a whole discipline around observability is saying that if this thing doesn't do what it's supposed to do, then we have a problem. And so what you get with an LLM, so let's say you take away some of the deterministic

work. So to me, the value of an LLM is just somewhat of a human persona that we can lay on top of these systems. So instead of just telling people what the temperature is today, maybe this thing can say it in a very polite way or maybe in a kind way. It's like, oh, that was a fun interaction. But it also does another thing that I remember for the first time when I wrote a regular expression. I want to write a regular expression to filter out all the email addresses.

And so you craft this like you think is the best regular expression in the world. And then you find out that it's not actually capturing all the email addresses. Because either A, you didn't understand what's a valid email address, or it's a really hard problem to solve. And so now, what was the saying back then? If you use regular expressions to solve a problem, now you have two problems.

If you just code the data structure, you now have this universal tool that can convert between these different formats, making a JPEG or an MPEG or a PDF out of an invoice, that is an amazing capability that is in some ways subjective on how to format a PDF from an HTML doc. And so the LLM allows you to do all of that. So I understand why people are super excited.

But at the same time, though, then we see ourselves now with the flexibility, building a bunch of guardrails to make sure that it doesn't generate something that's out of bounds from our expectations. So that's kind of what I meant by we spent our whole careers making these deterministic, predictable systems, and now we're letting them a little bit more loose. And then we're all like crossing our fingers that they don't turn off the Internet.

Well, the LLM is producing syntax in the way that you would have produced syntax. So that means it sits at the surface, Meaning what it outputs is still targeting the same output you would have done, which is also at the surface. Now, what would a below-the-surface technology look like? It would look like, let's just bypass Golang and the JVM. Let's go straight to assembly, right? Let's just go and program the logic gates directly.

And that's not really what most people are doing. Most people are literally just providing themselves with a better user experience. And I'll give you another example, which is, I think, more applicable to the average person. If you ask an LLM to give me a summary of this particular document or in my database, the customer that spent the most money in June of last year. Now, you could have done that with SQL, but SQL is very cumbersome. It's very strict. You have to know the dialect.

And sometimes the SQL is very far away from your intent. And so the ability just to make that one statement and then have the LLM at the surface translate that into the correct SQL query and then return a response, that is the perfect level of abstraction for what most people want to do, which makes it highly effective on being able to interface to lots of existing systems.

And I think this is why LLMs in some ways are deserving of some of the hype and the attention that they're getting because they can be very useful in many domains.

So we take that diamond problem and we just try to give it an honest solution. These are the things you depend on. Here's the things that make it work. And just give you a way to articulate that, express that, discover that. And so if you think about it from the AI perspective, then what you have is guardrails.

So if you want to express a build, if you want to express output, what you have now is at least a framework where you're not starting from scratch and say, hey, at the surface, I would like you to build my application. Well, if you were to target maybe the next ecosystem, you get something super reproducible. And I always like to think about the quality of these tools as if I were to remove the LLM, what am I left with?

And I think you're left with something that's still usable, even if you chose not to use an LLM again, maybe downstream, your build system, your deployment systems, generating S-bombs. Those things can be done without the magic of AI and all of its complexities, because you've kind of targeted something that's going to be a little bit more strict and domain driven. So that's where I see tools like Nextill having a ton of value.

And this is why I think the explosion of things like skills and MCP, where you can just say, hey, let's not invent package management or build systems. Let's just teach these tools how to leverage them.

And you've been also making the point, which I really like that, you know, okay, I can do this stuff at the surface, but if we haven't necessarily mastered 20-year-old tech, from Nix to just a lot of other things, like maybe we need to be looking at that too.

And the part where you say, hey, now AI lets us move 10 times faster. Sometimes I hear 10 times more tech debt, 10 times more bugs, 10 times more things you shouldn't have shipped in the first place. And so when I think about our ability to understand what's available in our tool, I'm looking at, I'm staring at a collection of tools. And a lot of times, I think people never really understood the core decision that happened with Docker.

Docker comes after decades of decisions around trying to reinvent package managers, RPM, Debian files. It's just so many of them, Jim, and they're all kind of solving the same problem. There is nothing you can do with one programming language on its own. At some point, you're going to have a form function interface to some C library, SQLite, LibC. It's just something's going to happen. And we all try to pretend that that wasn't real or that Debian and RPM could get us there.

And so we just kept rebuilding these package managers trying to solve problems we've created. Docker is born from that world. Docker just says, well, if that's what it's going to be, let us just let you keep doing that. And look, it was fun. It did speed things up. But in many ways, it sped up the mistakes. There are now far more things to scan than before. So before we were scanning servers and VMs. Now we're scanning apps. We're literally scanning apps for OS vulnerabilities.

We're scanning apps for all of these things that now are getting packaged because we're still doing the same mentality as before. I think if you rewind the clock back 20 years and say, hey, what's the real problem? The real problem is we don't really even know what our dependencies are. The real problem, we don't even know what we're linking out to these days. And the vendoring approach, it just kind of created a mess. So that original Borg paper was like, you know what?

The best way to think about software is in a holistic way. You can't think about the Ruby ecosystem independently of the C ecosystem. And so what you do is you just say at some point, this is just how computers work. Apps will start, and then they will reach out across the file system loading things that they need in order to run.

So that NPM package is much closer to the NICS philosophy around intentionality around what's on your machines, intentionality around what we link to, and then you manage the system from that regard. And then I think it's a little easier to think about secure software supply chains, but you need to know what the software supply is before you can secure it. And so I think it's just thinking of what we're dealing with.

And again, and I said this at the Nix event, there's nothing stopping someone from saying, hey, Docker is a really awesome way to package and distribute things. What if I was using Nix inside of a Docker image? So I still get the portability. I still get access to things like Heroku and, you know, Lambda and all of these container only platforms. But that container image, when combined with intentionality, I do think gets us there much faster than starting over from scratch.

But a friend pointed out malware and security vulnerabilities and suggested a VPS instead. What would you suggest? And can you recommend a good VPS service suitable for this particular task?

you're putting into it. on the LAN side, it might depend on like what access do you want it to have. It can be really useful if maybe you want it to be able to run scripts to make reports or control your audio bookshelf or your jellyfin or something, or maybe you want to do some network segmentation. So all it can do is reach the outside network, except for some blessed paths that you allow with tightly controlled API keys.

So there's a lot of different ways you could, but you need to kind of understand what you want it to do and what you're willing to accept the risk for.

If a lot of its work is going to be executing local APIs, it will have to still do reasoning and instructions with the LLM. But then a lot of that execution can actually take place via scripts that it creates and those run persistently local. And a lot of us actually have systems that are capable of running models that can at least be used for memory systems and things like that. So it's something that I think we're both debating.

It really, like Wes said, comes down to a big depends. But there are a couple of yes-no paths. And the number one yes path is if you can run a local model. If you don't intend to integrate with local self-hosted services on your LAN a lot, I think that's another vote for going with a VPS.

But I thought your basics in LUP 654, isolated setup, dedicated accounts, etc., were a helpful starting point. It'd be nice to see open-claw variants that defaulted to local models and an open chat platform.

I'm relatively new to the show and only started listening last year. Well, welcome. Thanks for listening. A few weeks back, I got talking to Abe, and he showed me a concept video from 1967 called 1999 AD, where the home computer would talk to other computers to do things. He's also been helping me run my own Abe's. I have two, and I just let them be, I don't call them Pete's because Petiverse doesn't have the same zing to it.

I am more sure than ever that this separation of duty is the way to go. Separate AIs that have, oh, no, the boost got cut off.

We got 80,388 sats this week. It's all right. It's okay. It's all right. It's all right. Don't cry. It's okay. Are you all right?

Well, we got too many picks this week. Most of it's my fault, but you boys also found some really good ones. And let's talk about WebSocket Cam. It's an app for Android that exposes your camera.

So I have built one, an OpenClaw plugin that bridges any MCP HTTP server as a native tool to OpenClaw. They don't have one yet, but MCPs are big. The model context protocols out there, they're big. And OpenClaw is kind of not really built to solve it directly. They recommend you use MCP Importer, which uses a CLI interface. So I created a plugin that lets you use MCPs directly in OpenClaw.

It just requires a password that you set up on the Fresh RSS server. And then you plug it into your gateway once you have my other thing working. And there's even a guide on there for your agent if you're too lazy to do it for yourself. And you should see significant token savings when you do this because it uses a lot less reasoning, pulling down the whole XML feed and going through it and just sorting out the few things that you want.

Because the MCP server exposes in particular options and tools and makes it a lot more efficient. So it's a great way to get like a daily briefing. Without burning a bunch of tokens.

Also, all the like .config files you might have for project specific settings, maybe for IDEs or tools or whatever, those all get sandboxed too.

With that, links over at linuxunplugged.com slash 655, if you can believe it. You got any pro tips for people before we get here? Like maybe fancy JSON chapters or transcripts, things like that?

So you probably want to join next week, just so you can try it out, because you know if we're in studio, there will be a mumble room. So you probably ought to join us. Next week. Make it a Tuesday on a Sunday. All right. Thank you so much for joining us on this week's episode of the Unplugged program. And we'll see you right back here next Sunday.