Voices of Oxide (Interview)

Well, friends, it is your favorite podcast, the change log. Yes. Jared and I have a special episode for you. Jared and I and team went to Emeryville, California at the invitation of Oxide. We went to Oxide's HQ. They have an annual conference every year. It's an internal conference called Oxcon, and they invited us out to celebrate and to peel back the layers to have a good look at the inside of Oxide. So they recently raised a series b round of a $100,000,000, and they also just signed a purchase order, a massive purchase order that is truly helping them cross the chasm. Now we also have three awesome conversations conversations for you. First up is Cliff Biffle. He's in charge of all things Hubris. Hubris is Oxide's operating system, and Cliff is also in charge of pretty much everything that happens before the CPU empowers on. Next up is Dave Pacheco. He's in charge of all things update, and update is the system for which they update the system. It's really important. And last up is Ben Leonard. Ben is in charge of all things design and brain for oxide. And if you like how oxide looks, I do. Well, that's Ben. A massive thank you to our friends and our partners over at Fly. Check them out at fly.io. Alright. Let's do this. 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 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 Depo's 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 …