Biocomputing on human neurons (Interview)

What's up, friends? Welcome back. This is the change log. We feature the hackers, the leaders, and those building biocomputing. Yes. Today, we're joined by doctor Evelyn Kurtz. She's leading the scientific research for final spark on the next evolutionary leap for AI, the leap for biocomputing. This is neurons. This is serotonin. This is dopamine. This is all the things and a live thing, computing. We learn about digital processes versus bioprocessors, the role of rewarding these things with dopamine and serotonin, how they measure input and output, reading data, exotic use cases, general purpose, who's using it and why, and why it takes ten years to get to a useful product. Of course, a massive thank you to our friends and our partners at fly.io. That is the home of changelaw.com. Learn more at fly.io. Okay. Let's talk about biocomputing. What's up, friends? I'm here with Kyle Galbraith, cofounder and CEO of Deepo. Deepo is the only build platform looking to make your builds as fast as possible. But, Kyle, this is an issue because GitHub Actions is the number one CI provider out there, but not everyone's a fan. Explain that. I think when you're thinking about GitHub Actions, it's really quite jarring how you can have such a wildly popular CI provider, and yet it's lacking some of the basic functionality or tools that you need to actually be able to debug your builds or deployments. And so back in June, we essentially took a stab at that problem in particular with Depots GitHub Action Runners. What we've observed over time is effectively GitHub Actions, when it comes to, like, actually debugging a build, is pretty much useless. The job logs in GitHub Actions UI is pretty much where your dreams go to die. Like, they're collapsed by default. They have no resource metrics. When jobs fail, you're essentially left playing detective, like, clicking each little drop down on each step in your job to figure out, like, okay, where did this actually go wrong? And so what we set out to do with our own GitHub Actions observability is essentially we built a real observability solution around GitHub Actions. Okay. So how does it work? All of the logs by default for a job that runs on a depot GitHub Action runner, they're uncollapsed. You can search them. You can detect if there's been out of memory errors. You can see all of the resource contention that was happening on the runner. So you can see your CPU metrics, your memory metrics, not just at the top level runner level, but all the way down to the individual processes running on the machine. And so for us, this is our take on the first step forward of actually building a real observability solution around GitHub actions so that developers have real debugging tools to figure out what's going on in their builds. Okay, Fran. You can learn more at depot.dev. Get a free trial, test …