The Changelog: Software Development, Open Source - Oxide builds servers (as they should be) (Interview)

Episode Date: July 8, 2022

Today we have a special treat: Bryan Cantrill, co-founder and CTO of Oxide Computer! You may know Bryan from his work on DTrace. He worked at Sun for many years, then Oracle, and finally Joyent before starting Oxide. We dig deep into their company's mission/principles/values, hear how it it all started with a VC's blank check that turned out to be anything but, and learn how Oxide's integrated approach to hardware & software sets them up to compete with the established players by building servers as they should be.

Welcome, friends. I'm Jared Santo, and this is the ChangeLog, deep conversations with the hackers, leaders, and innovators of theide Computer. You may know Brian from his work on D-Trace, his many years at Sun Microsystems, Oracle, and finally Joyent before starting Oxide. We dig deep into their company's mission, principles, and values, hear how it all started with a VC's blank check that turned out to be anything but, and learn how Oxide's integrated approach to hardware and software sets them up to build servers as they should be. Quick mention of our partners at Fastly. Everything we do here at Changelog is fast because Fastly serves it up super fast everywhere on earth. Check them out at Fastly.com. Okay, Brian Cantrell and Oxide on the Changelog, let's do this.

This episode is brought to you by our friends at Square. Square is the platform that sellers trust. There is a massive opportunity for developers to support Square sellers by building apps for today's business needs. And I'm here with Shannon Skipper, head of developer relations at Square. Shannon, can you share some details about the opportunity for developers on the Square platform? Yeah, absolutely. So we have millions of sellers who have unique needs

and Square has apps like our point of sale app, like our restaurants app, but there are so many different sellers, tuxedo shops, florists, who need specific solutions for their domain. And so we have a node SDK written in TypeScript that allows you to access all of the backend APIs and SDKs that we use to power the billions of transactions

that we do annually. And so there's this massive market of sellers who need help from developers. They either need a bespoke solution built for themselves on their own node stack, where they are working with Square dashboard, working with Square hardware, or with the e-com, you know, what you see is what you get builder. And they need one more thing.

They need an additional build. And then finally, we have that marketplace where you can make a node app and then distribute it so it can get in front of millions of sellers and be an option for them to adopt. Very cool. All right. If you want to learn more, head to developer.squareup.com to dive into the docs, APIs, SDKs, and to create your Square Developer account. Start developing on the show.

Thanks for having me. It's great to be here. We are super excited to have you. We've had a lot of people say, talk about Oxide, get the Oxide people on. So we're happy to fulfill that demand. And joining me also today, it's not Adam. Whose voice is that? It's Gerhard Lezu.

What's up, Gerhard? Hey, I'll try to sound like Adam. I'll try to be the serious one. I'm not sure how well I'm going to pull it off. I will ask at least one Silicon Valley question. There you go. Just to be a bit more like Adam. I'll try to be the serious one. I'm not sure how well I'm going to pull it off. I will ask at least one Silicon Valley question. There you go. Just to be a bit more like Adam. But yeah, this is a nice trio. I like it. Yeah. Adam on vacation this week. When you say Silicon Valley, are we talking HBO's Silicon Valley? Yes, we are. Adam is somewhat obsessed with the show and he brings it up pretty much every episode at some point. And so that's why I got her. Oh, you know, I got an Aviato t-shirt that my 15-year-old gave me.

I feel like I should go put that on. My kids and I like to quote. I think HBO Silicon Valley is really extraordinary. It merits repeated watchings. And I would like to say that I personally reject those in Silicon Valley who say that they can't watch it because it's too real. That's what satire is.

Suck it up and watch the, I think it's extraordinary. So I'm glad. Funny enough, that's what a lot of our guests say when Adam brings it up because he always inevitably asks me, Jared, do you watch it? I'm like, I watched season one and I kind of fell off. I thought it was really

good, but I don't watch it currently. Adam, he turns to the guest and he says, do you, and they say it's too close to home. No, I'm sorry. That is unacceptable. Everybody needs to, needs to grow up and be able to, if you cannot watch satire about yourself, you are taking your life too seriously. And the satire is brilliant. I actually had a boss of mine that I was imploring to watch Silicon Valley. And he retains conversation extraordinarily well. So he inhaled it. And he started dropping stone cold silicon valley references

and so in particular we had some consultants in and if you've not if you've only seen season one jared i'm not talking to you because you are not going to get this and there were uh some consultants were consulting and they were doing a very cringy they started doing a swat diagram and again my boss, the CEO of the company kind of leans back and says, should we let Blaine die? I'm sure that's funny. And the consultant is like, what the, what, what, what's going on? Who's Blaine? And I'm like, holy God. And again, this, this guy's got a very dry sense of humor. So he's totally happy to make a reference that no one else is getting in the room. And just let it sit there for a while.

Oh, I let it absolutely sit there. And I was just like, this is okay. This is impressive. This is really impressive. And he, I mean, more or less ordered his direct reports. Like, I'm sorry. Like I, in order for us to be able to communicate with one another, you're going to have to actually not just watch this, but retain it. So so just like with the news yesterday and Trump throwing his lunch across the room, that is a Gavin Belson scene. That is Gavin Belson destroying his own house in a rage. Anyway. You're talking right past me. I mean, I got the office down.

I can do Seinfeld. I can do New Girl. But Silicon Valley, I'm just going to carry season one and then I'm going to peace out. I'm sorry. It's just what happens. You're making a huge mistake. Okay, enough Silicon Valley for now. Let's get into the meat of this conversation around what you and your team is up to at Oxide. You call it hardware with the software baked in for running infrastructure at scale. It's allegedly shipping 2022. Let's start right in the fields though, as you guys put your principles right up front, your mission, your principles, this is a computer company, kind of like an old school computer company,

but you guys like right on the front of the homepage, here's our mission. Here's our principles. Can you lay out why that's important for you all and what they are and how that actually guides the company and what you guys are doing? Yeah, you bet. And I, yeah, so the origin of this actually is a talk that I, that I was asked to give by the Redmonk folks, by James Governor and Stephen O'Grady at Redmonk. And years ago, I, 2017, I was spun up into a lather over Amazon's 14, quote, unquote, leadership principles. I guess now 16. And I wanted to give my own as a rebuttal. And James responded to that tweet saying, is that your Monctoberfest talk submission?

I'm like, I guess it is. So that, and coupled with kind of striking contrast to Amazon, did force me to think about that. And I was kind of, we were going through an acquisition or it had been acquired and really suffering under a, under values mismatch. And part of the reason, honestly, I wanted to start a company is because I wanted to set the values from the cornerstone. And it's an important differentiation between values and principles. So principles are absolutes. So principles are the things that we can all abide by that transcend culture, transcend company. And those at Oxide, our principles are honesty, integrity, and decency. Those are our principles. That's what we expect everyone at Oxide to abide by at all times. These are irrefutable.

Values, in contrast, are intention. Values are not necessarily unequivocal goods. They are things that can be good, but they need to be not taken to extremes. So as an example of an Oxide value is rigor. Rigor is great, but rigor can also be taken to an extreme, right? Rigor can become paralyzing. You can be too rigorous. That is, if you insist on rigor, we are going to take rigor to an absolute and we are going to formally prove every program at this company. It's like, well, you are also not going to ship a product because you will be formally proving

programs the entire time. That is actually too rigorous. So rigor is intention with other values. Urgency is another oxide value. So the – and when we kind of sat down to figure out the values, I think the important thing for us was the values were not aspirational. They were really trying to capture who we are. And, you know, I'm old enough to know myself pretty well, to know what I wanted to build, what we wanted to build as a company. And perhaps the idiosyncratic step is that we have asked Oxide employees to commit those values to memory.

So there are 15 values. Wow. That's a lot to remember. You know, it's actually not. So let's rip through the values. So courage, candor, curiosity, diversity, empathy, humor, responsibility, resilience, rigor, teamwork, thriftiness, transparency, urgency, and versatility. May have missed optimism. Did I miss optimism? That's actually funny because optimism is the way I feel with that.

That's the Kenan Feltzfar one that I missed. Yeah, so obviously, it was optimism. Thank you. That's hilarious. Yes. Well, I was reading them along as you – I was being impressed by how you hit them in order, even on the end. Then you missed.

I memorized them in alphanetic order. Well, maybe I'm undermining my own point if I actually missed alphanism. See, it is harder than you think, isn't it? But part of the reason that we know that we can commit these kinds of things to memory is that's just like an act of repetition effectively. And, you know, I, uh, I lead the kids scout troops and the kid scout troop. And we asked, you know, 10 and 11 year olds to memorize 12 points of a scout law and they're all able to do it. So, um, I was pretty confident that adults could retain 15, although apparently, except for me, modular optimism. So I'll have

to go work on that one. Well, you're optimistic about it. But then we use those values as a lens for everything at Oxide. We use it as a lens for hiring. So our approach to hiring is very different than other folks. We have a process that is very much upfront and written down. My big belief is that, I don't think this is controversial at all, interviews are a terrible way to assess a person. And, you know, we have this longstanding tradition of using oral exams to evaluate software engineers, which is, doesn't work. It's not what they do. And, you know, I think that for me, the kind of a light went on relatively early in my career, you only have to

have, you know, one of these where you have someone who's just super sharp in the interview and is an absolute disaster of an employee, not necessarily out of malice, but just out of what you've selected for in that interview is not what you actually want to select for to succeed in the role that you've got. And we actually, you know, one's ability to be quick on one's feet in a conversation, to be able to dominate a conversation, which is what an interview often selects for, just not a good match for what we actually do in software engineering. And what we do in software engineering is we spend time by ourselves thinking about problems and writing down solutions. That's what we actually do. And there's a degree to which software engineering is a very solitary activity. You are alone with the problem.

Ultimately, it's you staring at your code. Yeah. And how do we kind of capture that? And for us, it is by, I want to see a portfolio of your work. I want you to describe your work. I want you to write it down. What is the work that you're proud of? I want an analysis sample. So walk me through a hard problem that you've solved and the analysis that you applied when doing that. If you've given presentations, I definitely want to see those.

So we kind of ask that kind of portfolio-based questions. And then we go through the values-based questionnaire where we ask people some really basic questions. When have you been happiest in your career and why? When have you been unhappiest and why? Then we ask for, we take those oxide values and we ask you to select one of those values and describe how it's been particularly reflected in your career. Take one of those values and describe how it's been particularly reflected in your career. Take one of those values and describe how it's been violated in your career and how you actually – how you dealt with that. And then we – one that I kind of threw on there at the last second that has been proven to be kind of fascinating is take two of the oxide values and describe how they came in tension for you and how you resolve it. And you won't be too surprised to know that I would say, you know, good, at least a third of the people who apply to Oxide talk about rigor and urgency being intention. And which I think is great. I mean, I never tire of reading that because rigor and urgency is kind of a very fundamental tension in software engineering.

It's a tension that we navigate every day, all day. So I'm always happy when candidates want to describe that. We're not necessarily looking for points for creativity on that one. But then you add all of that up, and those are what we call the materials. And then we hire through that. So as a result, the values become really self-reinforcing. And the values are really deeply held, deeply shared by folks at Oxide. And it has made navigating certain aspects of the company much, much easier. Like any group of people getting together to solve a problem, there is definitely differences of opinion. There's conflict.

But navigating that conflict, navigating those differences is much easier when everyone can be really explicit about their own values. And it's been really interesting to watch people say like, okay, wait a minute, you and I are disagreeing right now, but I realize that actually rigor and urgency are intention for us right now. And that actually we're disagreeing because I am biased right now more towards urgency and you're biased more towards rigor. And that allows for a much more meaningful conversation where you actually need to go resolve a dispute. It's actually providing like a shared lexicon inside the company. Totally shared lexicon. To have discussions. That's cool.

And you have to be careful because like it's very important to me at Oxide that we don't weaponize those values. Right? What you can't say is like we don't want to start, you know, rating one another on values because values are intention. They are, there's ambiguity there and that ambiguity is deliberate. So you've got to kind of balance that. But I think we have found that we've been able to navigate a lot together. extraordinary amount as a very, very small team in part because there are so many problems we don't have when we built the company in this way that is so explicit about values. So did you have all of this right up front or has it grown out of you working together? Because

you started it, what, back in 2019 or so? You've been working on it for a few years. Are these things observed over time or did you have like a list? Here's my list and I'm bringing it to the company to start with. So my big belief was, uh, remains the values have to be set from the first cornerstone. You, you can't retroactively. And so we will never add values. There, there will be, there will be 15 oxide values. Will you remove any? We will not remove any. We will not remove any despite We will not remove any, despite whatever happened to Optimism when I was ratting them off. No, we will not remove any. We will not add any.

Those are our fingerprint. And the reason that you have to do that from the cornerstone is because you do have to use them as a lens for hiring. Because even by the time you have, you know, four, five, six, seven employees, there are going to be differences. And they're going to be, if you haven't used those values as a lens, you're going to have, you know, I guess you could, you know, restructure your company around it, but I think it's, it's, you're really hard pressed to do that. So for us, that is the kind of the foundation upon which the company is built. And I would say also, I mean, this comes out of having done it the wrong way for many, many years, right, where I was too implicit about values or it is an easy mistake to think that someone else shares your values when they in fact don't or when you think you are broadcasting values when you in fact aren't.

And then you end up in conflict with people that you don't understand. Like why are we disagreeing so much about this? I'm very surprised by this conflict. It's like, oh yeah, that's because we actually didn't share those values all along. So it has been a really important way for us to build the company. Well, I understand the importance of values,

how fundamental they are and the principles and everything builds on top of them. Not so good with names, already said that. I'm pretty sure I would stop after three or four, maybe five. Right. On a good day. But the one thing that really resonates with me is stories. And one story that I think you are starting amazingly well

is when you start talking about the soul of the machine. That is such an important construct. The last person that I remember saying that was Steve Jobs. He was all about the soul, about the beauty, the combination of hardware and software and what happens in between. So why is the soul of the machine important to you, Brian? Well, because I mean, to me, it's the entire system, right? I mean, I think that hardware and software should be co-designed. We should be thinking of this holistically. And, you know, there are things,

it's always troubling to me when I hear a Jobs quote or speech that really deeply resonates because there's so much about Jobs that I don't like and don't aspire to. And I think that are kind of the unequivocal praise of Jobs is a huge mistake because the guy was really difficult to deal with. I really recommend, by the way, Isaacson's book is fine, but the actual, the book on Steve Jobs to read is Steve Jobs and the Next Big Thing by Randall Strauss, who's written about Jobs at Next. It's written at the nadir of, when Jobs is basically being left for dead and it's a disaster story about Next. And I think the Isaacson bio does Jobs I think a disservice because there is so little on Next. I mean he was at Next for what, 13 years, 15 years?

I mean he was at Next for well over a decade. It was a spectacular failure that was – that should have been a zero and only wasn't a zero because Jean-Louis Gasset at B felt that B was worth more than Apple was willing to offer. If Jean-Louis Gasset had taken Apple's offer, Next is never purchased by Apple. Jobs does not return to Apple. And we are in an alternate timeline timeline and I've got no idea what happens. I mean, you're in like, you know, you're like a, all of a sudden you're in a Bradbury short story. I've got no idea what happens. Yeah. That might for good fan fiction or something, you know, take that other timeline, make a story about it. But so, but so Jobs gets a bunch of

things. I don't, I don't like the way he treated people. And I think that honestly, the next experience probably we did talk again, hard to know, And I think that, honestly, the next experience, probably, it's hard to get hard to know, but I think it informed his return to Apple. And I would like to believe that he treated people a little bit better. But what I do very strongly resonate with is his aesthetic about the way that these machines are engineered, and that we actually think of the entire system. And that's hard. It's hard to think of the entire system. Computers are really, really complicated. Exceedingly complicated.

I mean, I feel like there's not a day that passes at Oxide that I don't think to myself, God, I wish I knew how computers work. I mean, I've been doing this for, you know, for whatever it is. Coming up on 30 years and I'm still learning how computers work. Because it is so wildly complicated. And it's such a miracle that they work at all. So it can be very hard to co-design hardware and software because we're actually demanding of people this incredible depth of understanding across two disciplines that have a lot in common with one another and have this very important surface area of contact,

but are in fact different. And software is not dictated by physical laws, really. And they are different. Software is not analog. The physical world is analog. Digital is a lie that we tell ourselves. But it's very important, I think, to build those things together. And that means building a team in which you've got software that has reverence for hardware and hardware that has reverence for software. And you want everyone to kind of bring their domain of expertise to the table but also appreciate what the other domains bring.

And that's a trick. That's hard to pull off. Jobs pulled it off. I do think he pulled it off a couple of times. I think it has been pulled off a couple of times in history, certainly. And we believe that in Oxide, because there aren't as many opportunities, I think, to do that today. Ironically, the companies that do believe in that are our most outsized successes. So it's like, you know, what are the companies that believe in hardware software co-design? Like, I don't know, Apple, Tesla, Amazon, really, Google. But other than that, and yet it's still considered to be econoclastic, which is kind of ridiculous to me. I mean, this is so obviously the right way to build a system. But the reason

it's econoclastic is honestly because it's hard. And it's really, really hard. It's much easier to focus on a narrower confine and to dismiss those that are taking on the entire system. It's hard. It's expensive from a, you know, we had to raise a lot of money to go build locks. This episode is brought to you by Sourcegraph.

With the launch of their Code Insights product, teams can now track what really matters in their code base. Code Insights instantly transforms your code base into a queryable database to create visual dashboards in seconds. And I'm here with Joel Kortler, the product manager of Code Insights for Sourcegraph. Joel, the way teams can use Code Insights seems to pretty much be limitless, but a particular problem every engineering team has is tracking versions of languages or packages. How big of a deal is it actually to track versions for teams?

Yeah, it's a big deal for a couple of reasons. The first is, of course, just compatibility. You don't want things to break when you're testing locally or to break on your CI systems or test systems. You need to have some sort of level of like version unification and minimum version supported and all of that needs to be compatible forward. But the other thing we learned was that for a lot of customers, especially, you know, engineering organizations that are pretty established, they have older versions of things or even older versions of like SaaS tools they don't use anymore that they haven't fully removed because they're like not sure if it's

still in use or they lost focus on that. And they're spinning up old virtual machines that they're still paying for. They're using old SaaS subscriptions they're afraid to cancel because they're not sure if anyone's actually using it. And so getting off of those versions not just like saves you the headaches and the risks and the vulnerabilities of being on old versions, but also literally the money of older systems running more slowly, or the build times, or virtual machines and SaaS tools that you're no longer using.

Before you had this ability, we talked to teams. There are basically three ways you could do this. You could Slack a million people and ask for just an update point in time. You could have one human and one spreadsheet, where it's somebody's job every Friday or every two weeks to just search all the code and find all the versions and write it down in a Google Sheet. Or there were a couple of companies that I came across with in-house systems that were sort of complicated. You had to know maybe Kotlin,

but you didn't know Kotlin. But if you want to use this system, you had to learn Kotlin, and you'd have to sort of build the whole world from scratch and run basically a tool like this with a pretty steep learning curve. And now for all three of those, you can replace it with a single line source graph search, which is basically just the name of the thing you're trying to track and the version string in the right format. And then we have templates that will help you get started if you're not sure what that format is. And then it'll automatically track all the different versions for you, both historically. So even if you start using it today, you can see your historical patterns. And then, of course, going forward.

Very cool. Thank you, Joel. So right now there is a treasure trove of insights just waiting for you. Living inside your code base right now, teams are tracking migrations, adoption, deprecations. They're detecting and tracking versions of languages and packages. They're removing or ensuring the removal of security vulnerabilities. They understand their code by team. They can track their code smells and health, And they can visualize configurations and services and so much more with Code Insights. A good next step is to go to about.sourcegraph.com slash code dash insights. See how other teams are using this awesome feature. Again, about.sourcegraph.com slash code dash insights. This link is in the show notes. So why did you decide to do it? I mean, you say you kind of ask yourself that question repetitively, but the very first time that you asked yourself the question and said, yeah, actually, I'm going to do it.

It's like, what was in the way? What was missing? Or what was in the way of you doing what you want to do where you currently were working or currently building? Yeah. Why decide to go ahead and raise the money, get the co-founders, and take that huge leap that you took? Well, so we were – so I was at a cloud computing company. So I spent 14 years at Sun Microsystems, which I have to clarify was a computer company because my now 10-year-old daughter thought it was a brewery in a very strange exchange we had at some point.

It might be a brewery. There very strange exchange at some point it might be a brewery there's lots of breweries out there what what kid is thinking about breweries what's going on anyway so i now defund computer company but um i um so i spent 14 years at sun um sun definitely did believe in that hardware software co-design, for sure. Certainly saw elements of it there. After Sun was invaded by the Nazis, I fled. So Sun was purchased by Oracle in 2010. I went to a cloud computing company, Joyent, and spent another nine years there. And it was at, so it was kind of interesting to be on both sides of this. And Joyent was acquired by Samsung in 2016. And I and a colleague of mine that I had come to know at Joyent, Steve Tuck, Steve and I had decided like we knew we wanted to start a company together. And we were kicking around some very bad ideas for things that we could go do.

And as we were kind of kicking around bad ideas, you know, maybe it's time to like start talking, start lighting up some venture capitalists. And, you know, I wanted to go back to my, I'd known VCs over the years, but needed to go kind of remind myself of them and maybe get some lunches or whatever. And I went back to the mail from a VC, actually a pretty famous VC, and he and I would get lunch together with some regularity. And the last email that he had sent me was, hey, really enjoyed lunch. Just wanted to remind you that I will fund literally anything you put in front of me. Nice. Wow. Okay. So Steve, you know, I got this mail and, you know, he's going to fund anything. They're going to fund anything we put in front of them.

Maybe we should solve the problem that we actually want to solve. And the ideas that we had been taking around were frankly small ball. They were small problems that felt like startup size problems. But if we have got an opportunity to raise money for anything we wanted to go do, the problem that we actually wanted to go solve together was the one that we were suffering with every day inside of the walls of Joyent and then Samsung, which is the infrastructure that we were building a cloud on out of commodity gear, Dell, HPE, Supermicro, had no end of problems, plagued by problems that we simply could not solve because we did not control that layer of the stack. And if you look at what Google and Facebook, now Meta, Microsoft, Amazon have done for themselves, the machines that they were building

for themselves looked nothing like the machines that we were trying to build a cloud on. And I'm like, Steve, if we want to like, if we can actually get anything funded, we should go start a computer company. And I just remember, you know, vividly in Steve's office being like, do you think we could get like, wow, do you think we could? Like, it was almost like, do we have like permission to go do that? Because yeah, I mean, obviously we should go do that. Steve had spent, you know, a decade at, prior to his decade at Joyent, had spent a decade at Dell. And so, you know, he and I, and coming up on the go-to-market side. So I mean, we felt like, boy, if we can go do this, like, let's go do it. The thing that's really funny is that we, so we kind of started to formulate this and started to reach out to VCs and talk

about it. And what we learned pretty early is that this is wildly contrarian, but intriguing to VCs. In some ways, this is like the worst possible thing for VCs because VCs always want to know more, but it requires a boldness that can be hard for venture capital to summon. So it's easy to have like long conversations that lead to ultimately not getting across the finish line. But folks were intrigued and great. So the irony is that talking to a bunch of venture capitalists, getting a bunch of enthusiasm for it, and then finally went back to that VC that had sent the email that honestly sent us down the path for Oxide. And I call him up and I get like maybe a minute into kind of describing the problem that we were going to

solve. He's like, wait a minute, Brian, I'm going to stop you. I see where this is going. Please tell me you're not going to start a computer company. I'm like, no, that's exactly what we're going to do. He's like, no, absolutely not. No, no, no, no. I want nothing to do with this. And I'm like, you know, you sent me this email saying you'd fund, quote, literally anything

I put in front of you. He's like, no, no, I'm not doing that. Like, no, definitely not. Oh, wow. you'd fund quote literally anything i put in front of you he's like no oh i'm not doing that like no definitely not oh wow so uh there was a you know the birth of oxide is a kind of a lie from a vc albeit a pretty harmless one but you know wow it got us to to dream a lot bigger uh this vc did he didn't radically pass on us so passed on is he in now in now? Did he eventually get in? Is he out? No, no, no, no, no, no, no, no. He's out, which is fine. You think he's going to want back in later? You think he's going to be kicking himself

five years from now? You know, that's the fantasy of every entrepreneur is that- That's why I'm asking. Yeah. I mean, that'd be obviously, that'd be great. That'd be terrific. All right. You know, you try not to live your life to, to spite others. You know what I mean? No, no, no. But you could say, I mean, is there room for them on your cap table eventually? I'm sure there's other rounds. Are you done raising money for good?

We're not, we're definitely not done, but there is, once you get beyond a certain stage, the early stage folks are, it's, it's like the money's off the table. Their thesis is they need to be in earlier and get the larger multiples. So that larger multiple will be off. No, actually, we've got, honestly, it worked out great, honestly, from an investor perspective. We got, I guess when you're doing something bold, you will self-select for VCs that themselves are bold. And we got the boldest and the best. So we got a Clipse Ventures funded the company and in particular, a venture capitalist named Pierre

Lamond. Do you know Pierre? No. Okay. So Pierre hired Andy Grove at Fairchild. Fairchild Semiconductor. Okay. Going back. So Fairchild Semiconductor, this is the true birth of Silicon Valley, right? The birth of Silicon Valley is Shockley Semiconductor and then the traders leaving Shockley, going to Fairchild. And Fairchild was where you had this just incredible confluence of unbelievable talent. You've got Noyce. You've got Moore. You've got Andy Grove, incredible folks. And this is, this is Moore's law, right? This is where you have this incredible growth of the integrated circuit and Fairchild just explodes. And they end up all

leaving. Fairchild is actually a subsidiary of a Fairchild instrument and camera. And all those folks end up leaving Fairchild and going to National Semiconductor, where Pierre went, Intel, all the birth of Silicon Valley very much comes out of Fairchild. So Pierre was at Fairchild. And he was at Sequoia for many years with Don Valentine, funded YouTube. And as you can imagine, you're like, wait a minute, how old is Pierre? Yeah, I'm just wondering, because this seems like this goes back. Yep, it goes back. Pierre is certainly the oldest venture capitalist in Silicon Valley. And he is absolutely the boldest. Wow. I mean, it's kind of amazing to me that you got someone who is I mean, I think it's honestly, it's a little bit embarrassing for younger venture capitalists when you've got Pierre is so

terrifically bold and they are so afraid of things. So it's been singular. It's been so great to have. And I think it's highlighted for us the importance of having, when you're starting a new bold endeavor, having an investor who is, who's fit for that endeavor, having an investor who is as bold as the company itself has been really, really important for us. If Wikipedia is right, it looks like he's in his nineties at this point. Yes. Wow. He turned 92 in September And this guy is razor sharp. He's great. And not just sharp. I mean, sharp is great.

But like lots of people are sharp. It is the courage that he's got, the boldness. Because what we're doing is very bold. And it requires someone who shares that vision, but also understands what it means to actually solve a hard problem. And what it means to solve a hard problem is things are not always going to go well. And if you're solving a hard problem, if things are going well, you need to push harder so that you are prepared when things aren't going well. And then you need to stand by the technologists who are solving a hard problem. And that is a balance that is increasingly rare to strike. Jobs is very good at it, actually.

I disagree with some of his people management methods. But the reality is that Jobs had teams that were able to birth very bold ideas into the universe because he understood that he understood how to hit that balance of being both pushing people towards those mountains on the horizon and supporting them when they when when things aren't going well which is which is a challenge speaking of big things just to put this into perspective we had the internet we had the distributed version control system git from boast we had open source there's something else coming next revolution i think that's how big we're talking here like a really big moment how do you see that brian because i know that you've been talking about this i forget which talk exactly but this is the scale that you're thinking at and aiming for and that's why you need people that see the challenge that

lies ahead for what it is, because it's really big and it's going to take a long time and a lot of effort and a lot of people to see through. Yeah, I mean, for sure. And so what we are doing is, I would say, bringing those revolutions to the computer itself. I mean, it's kind of embarrassing that if you look at the server-side computer that is commercially available, it hasn't really evolved since the 90s.

It is basically a personal computer. It is a racked personal computer. Right. And that's embarrassing. I mean come on. Yeah. And the approach that we're taking is true rack scale design. So, and I think that the revolution you maybe were referring to, I do think that the firmware, which is to say the proprietary software that sits between the hardware and the system software that runs upon it, that proprietary firmware has been a real problem. And what we, I don't necessarily view it as a, no, it's a revolution in its own right as so much as it is bringing the open source

revolution to firmware. We know that open source, open source is really, really, really, really important. And the older I get, the more I appreciate how deeply important it is. And it has changed everything that we do. I think that the, I think that when I was coming up in the 90s, it's kind of the era of the death march, right? And there are all of these tales of showstoppers, a terrific one about the development of Windows NT. And if you read the development of proprietary software in the 90s, it feels otherworldly. And the reason it feels otherworldly is because there was no sharing of software, really. Everything was proprietary. Everything had to be either built from scratch or bought. And that really, it served as an incredible impediment to innovation. And people are, I mean, software projects being

canceled because they ended up being so large, the scope would expand, they would have to be canceled. I mean, there are all these kind of knock-on effects. And we know that software has this incredible property that it endures, right? It's not a physical machine. It doesn't wear out. And when you get software right, if the software works for me, I can share it with you for free. There's no cost of goods sold. It's information. I'm giving you like the answer to the homework. It doesn't cost me anything. And that is remarkable because then you can build upon it and you can go solve a new problem that you couldn't solve previously. And I think that, you know, when it's all writ, I think that the development of open source is going to be viewed as a Gutenberg-esque moment. That software alone was actually, software alone is like the written word, extraordinarily powerful. But you actually need the printing press to have that kind of broad impact, broad societal impact you need to the printing press. And for software, open source

is the printing press for software. the printing press the software's efficacy software's benefits were limited and it's not it's not an accident every single one of these companies that we that one might talk about is built on open source components up down and all around our programming languages are all open source our databases are open source our systems are open source and yes obviously people are doing their own proprietary software in there, but those open source components have proved essential. That revolution has not yet come to firmware. And that's what we are doing as a, now I would say that's a side effect of what we're doing. What we are doing, what we actually are doing is building a unified hardware software system, a rack scale machine that represents the kind of

machines the hyperscalers build for themselves for those folks who wish to run on-prem. And I think the other big belief is that Jeff Bezos is not going to own and operate every computer on the planet. So that's our other renegade belief, that we're not all going to be running a computer in perpetuity. There you go. That sets you up in a nice David and Goliath type scenario. So you can have that mission to beat Goliath.

So I'm wondering when you talk about open source revolution, bringing that to firmware, bringing that to the metal, does RISC-V fit into this conversation at all? Yeah, that's a great question. I would like it to. I think we would like it to. RISC-V, so there are a couple, some great elements of RISC-V. I do love the instruction set.

The instruction set is very thoughtfully designed. And the fact that we can have open cores for RISC-V is great. So the fact that you can have your own blue spec core, what have you, RISC-V core, that's great. The challenge with RISC-V five is that and we've seen this happen again and again where you have something that has good intentions and then the the kind of the tentacles of the existing way of doing things spread into it and risk five has developed pretty proprietary firmware for all of its openness, the instruction set is open,

the actual systems based on RISC-V have got a lot of proprietary elements. And indeed, they have recreated some of the most gallingly proprietary elements of x86. So things like SMM. SMM is the system management mode. It is a mode that the processor enters when it wants to and does whatever it wants. And if you are accustomed to writing the operating system, I do OS kernel development, like the idea that there is some hidden mode that you can't see that gets to do whatever it wants in the machine, well, that operates across purposes.

I mean, that's a source of security vulnerabilities. That's a source of performance problems. And those kinds of management modes should not exist. Those are antithetical to hardware software co-design because those modes, what those modes are saying is that there is some software beneath the system software that is unseen that is actually controlling the computer. And it makes it very hard to build a unified system. We actually, of all the things we're doing at Oxide, and we're doing our own compute sled based on AMD Milan. We're doing our own switch based on Intel Tofino. We're doing our own cable backplane. We're doing our own operating system on the service processor. We're doing our own hypervisor. So we're doing all these very big, bold bets. Maybe the boldest is there is no AMI

bias in our system. So AMI, American Megatrends Incorporated, which even the name drips from the 80s. This is a bias manufacturer from the 1980s that has somehow remained at the brainstem of server-side computing. And right now, x86 parts, be it Intel or AMD, have got AMI-authored code, proprietary AMI code, that you can't see change or operate, that is part of that machine bring-up, that platform enablement. And it's a huge problem. It's a huge problem because it's, I mean, first of all, it's just bad.

I mean, it's just poorly written. It is at the very lowest layer of the stack. It has got no idea what's running above it. And so it will kind of hijack the machine to its own purposes. The bias will, in cooperation with SMM, with other aspects of the computer, will kind of do what it wants when it wants to.

And that's not the way you build a reliable system. That is not the way you, that again, antithetical to this idea of unifying, of taking this hardware software co-design approach. So we have no UEFI in the system. So UEFI is a, that was what my colleague says, it's like MS-DOS circa 2099. UEFI was designed as a mechanism, actually originally the boot Itanium, but it is designed as, it's kind of like the worst of all worlds in that it requires these kind of interdependencies across layers of the stack, but it doesn't actually empower anything. So it ends up being kind of the worst of all worlds. We have no UEFI in our system. We have no ACPI in our system. We do not need to have these layers that allow arbitrary other layers of software to run on top of them. We can actually design the whole system together.

And then because our revenue model is based on hardware, because we're selling the whole system, we can make the entire thing open. And I think this is where we do diverge from a company like Apple. I love so much of what Apple does. But the secrecy with which Apple engages itself, I don't think is necessary. I think Apple would be an even more relevant company if they were a proponent of open source software. And they're really not. I mean, they kind of, they have been, they've kind of, you know, they've flirted with it at various times. Yeah.

But they are not really an open company. It's like there's little bubbles inside of Apple that are. They're absolutely bubbles. And then the bubbles will kind of persist for a while and then they'll be hit with a hammer. And then they, I mean, Apple is a company that routinely goes backwards at open source,

where things were open and are no longer open. And that's always a bad sign. Well, they're still working on that FaceTime open standard. You know, they're still getting that thing rolling. Right. Just like Steve Jobs said they would. And, you know, that's, I think to me, that's frustrating because it's like, look, Apple, like you are, you sell devices, like pretty expensive devices.

You don't, you should be incentivized to get your software out. People should be able to see how these systems work, but it's just not the way. They believe their secrecy is at the core of their success, and I think that their secrecy, I think that the core of their success is so deep, namely hardware software co-design, and so successful that even their ridiculous secrecy

has been unable to kill it right there are aspects of which i mean we're too far afield here but there are aspects of apple strategy that i think have paid off with regards not necessarily to secrecy but to propriety if that's how you say it which is specifically i'm thinking of messages i message i think keeping that apple device only has been a brilliant form of lock-in which is not pro consumer but it's pro apple that has worked out quite well and i don't think they would be as relevant as they are today if you could get apple messages i message format across any device because that's a lot of people that say that the only reason why they still use apple is because of those stick and blue bubbles

that's right i uh they believe that. I'm not sure that's true or not, honestly. I'm not sure that's true or not, but they certainly believe that. So I actually think that their products are pretty good. And I think that they actually don't need to lock people in. I think they can actually allow people to make a, and people do, like they make, they choose to use their products because they're good. Yeah, they do. And they're good because they have taken on the whole system. So I think there's a lot of reasons to believe that delivers a better artifact. But so we have no AMI bias. We believe that these layers of system software that are serving to make the machine look like a personal computer are dated, but they require doing things that really

have not been done before in terms of system enablement. I mean a long way of getting back to kind of the RISC-V. So with RISC-V, I'm optimistic about elements of RISC-V. But it needs to not go down some of these same paths because there's this idea. And we certainly saw this happen in ARM, in the ARM ecosystem where it's like we need to have UEFI to be successful. And you're like, no, no, stop. The x86 is successful despite UEFI, not because of it. And you want to actually allow people to use RISC-V, ARM, what have you, as a building block for a larger system, which means it needs

to be truly open, it needs to be well documented, and allow it to be used as a real building block. And that's what RISC-V needs to do. And some days they're doing it and some days they aren't, but we don't have any RISC-V in our system yet. We definitely evaluated it for certain aspects for the hardware we were entrusted in particular. I think we probably will in the fullness of time, but right now it's all ARM for the embedded use cases and x86 for the for the cpu for the cpu i really like my hardware i like my imac pro the one that i'm using to record this on it's been many years love it the new m1 max great machine but also appreciate very much my fanless amd system completely fanless not even the psu has a fan so i'm wondering if i wanted to add an oxide rack

to my hardware like first of all would i do it and how would i go even about it yeah so i and i really i want to let people down easy because we've got such a demographic that is following companies like i can't wait to buy an oxide rack i I'm like, I don't know that you're going to be – I mean, do you have 15kW in your house? If so, why? You know, this is really destined – this is destined really for a data center. Now, I don't think there's any reason architecturally we couldn't make a much smaller rack, but that's not what we're focused on. What we're focused on is building a rack for a data center. Actually,

it's funny. It's like 15 KW is our power budget for the rack, which is arguably the worst of all worlds because for the hyperscalers, they're like, Oh, 15 KW feels very tight. They're accustomed to being at, you know,

20, 25, 30, 35, 40 KW per rack. And you talk to the enterprise folks and they're like uh 50 okay maybe you're like we're mainly more like 10 12 kw per rack but our belief is that by actually designing the whole rack together we can optimize power across that rack all that said it's

not gonna be destined for a home lab so i don't think the i and we actually in terms of the fans we we are certainly not not fanless we very much have fans we went through a great deal of effort to make the fans uh it drives me nuts when you plug in a dollar super micro server and the first thing it does is those fans go full tilt have you ever been around like a fan going i mean these are i have one a one u right so you've got those little one u screamers right and those are like 25 000 rpm drives 20 000 20 000 rpm fans and these are super super loud so i always view that as it's so and maybe this is my inner steve jobs it's just so inartful to have so we have so the geometry of our sleds are a little bit different. So they're higher. So they're 100 millimeters high, roughly 2OU, which is a little more than a 2RU.

So it's like 2RU and change high and then half width. And that sled has got – that's a single AMD socket on there, 16 DIMMs, and we've got 10 NME drives. So the fans, part of the reason that the geometry is different, and this is what Facebook had initially done with OCP, but we wanted to have larger fans. So we wanted to have 80 millimeter fans. We did not want to have, because when you have a larger fan, then you can go at lower RPMs. You can actually, they're just much more efficient and much more power efficient as well.

But the fans that we wanted at 0% PWM, which is to say at its like offsetting, it's at 5,000 RPM and 5,000 RPM is loud. So we worked with our partner. One of the things that we do at Oxide that is actually a little bit different than certainly than I'd done in previous lives. I don't really believe in dual sourcing everything.

I really believe – I want to put rings on fingers. So I want to find like the right partner and I want to go deep with that partner. And actually, ironically, I mean this is a belief that we had. It was somewhat iconoclastic. Jobs did not have a dissimilar belief. Jobs believed the same thing. So for us, San Yudanki is our fan partner. We worked with San Yudanki to have a 0% PWM fan that's at 2,000 RPM.

And that is great. Like whisper quiet. So we've done – we've got all of these things to get – so when the rack powers on, it's just going to whisper. So we get the first rack together to do our compliance testing. And I'm like, what the hell is this like our firmware is wrong I you know we we get this like blast of fans but it's super short and I'm like what the hell was that and when I realized like oh it's the the rectifiers so we've got our a power shelf so we've got a dc bus part on the back we've got a single power shelf that has rectifiers the rectifiers have their own fans it's like the only firmware in this system we did not

write is the firmware that sits on the rectifier and that thing turns the fans on full tilt it's like oh man unfortunately it's for it's it's very very brief It's nowhere near as bad as the Dell Supermicro kind of experience. But it's just an example of how, like, you do want to – and maybe it's a bit of an aesthetic example. But actually, I believe that we are going to be – it's going to be very interesting to watch how this thing does at full speed because we're going to be able to run these fans. We do not need to run these fans of, I think, even 5,000 RPM to move the air that we need to move to actually keep the system adequately cool. I have a very important question. What happens when you shout at an oxide rack? Right. So that's a reference to a video that I shot of Brendan Gregg many years ago when he and I worked together at Sun. And Brendan was, we were trying to debug an outlier, a latency outlier that we thought might be due to, well, actually, to back up a little bit.

We were trying to figure out with another colleague of mine, Eric Schrock, why we had a JBOD, just a bunch of disks, with a single latency outlier that we could not figure out. And we're trying to debug it. And it's like this thing is only this drive is behaving badly. And we were about to go to lunch, and we had this lab space that was next to the office. And Eric was like, well, let's go look at the machine before we go to lunch. And I remember thinking, like, that is the dumbest idea. Like, what are you going to look at the machine?

It's like, is your hypothesis that there's like like, a raccoon in the data center, like, gnawing? It's like, yeah, right. Old school bug. Look at the machine. Sure. Why not? Actual bug. Right.

Yeah. So we go in there, and he pulls out the drive that is the problematic drive. And I just remember, like, my breath feeling like it was taken away because what we saw is that all four of the mounting screws in the bracket had worked their way out and the screws were gone. And it was sitting there vibing just on the connector. And this should have been one of those moments. I remember it was one of those moments where you're just like, oh, the system's a lot more complicated than I realized. And oh, the system's a lot more complicated than I realized. And, oh, wow, yeah. All of, like, this is where, you know, in terms of the education of why software hardware code design matters, it's like, oh, yeah, right, vibe really matters.

And in trying to reproduce those vibe issues, Brendan and I were alone in the office, I think it did during Christmas and New Year's, if I recall correctly. It was years ago. And Brendan was trying various things to reproduce this. So we wanted to talk about how we debugged it. And Brendan comes running in and says, you've got to see this and runs out. And Brendan is just like not a person that ran all that frequently. So Brendan is the kind of person like if this person's running, I'm running in the same direction. Like,

I don't even know what we're running about, but like, I'm not, I'm not going to take my chance. It's worth checking out. Right. Yeah. And then he,

what he showed me was, uh, that he had figured out that he could scream at the drives and induce the latency outliers. And I remember thinking like, wow, we should video this. So he had a camera there.

I videoed it. Hi, I'm Brendan. We're here in the Fishworks lab. Sorry for screaming. It's very loud in here with the air conditioners and servers all around me. We just made an interesting discovery and we thought we'd show you straight away. What I'm going to do is not recommended. This is not supported.

Do not try this at home so me videoing him screaming at the drives is the second take that's the second time i've ever seen it you can kind of hear me laughing because i'm still like delighted by this i put it up on what is then the very young youtube again i think this is in like christmas 2008 if memory serves so this is youtube's only a couple years old yep and i'm thinking like this would be good like it'll get like you know i don't know a couple hundred views or whatever i haven't checked recently it's definitely over a million 1.8 yeah 1.8 right so that's yeah that's that's had quite a few views my kids view me as my career as a failure because you know i i could have been a YouTuber. I actually had the, um, I tried to explain to them that like, I'm a one trick pony. And by the way, it was like, Brendan, anyway,

Brendan was the talent. I just like, I just held the button down through the cameraman. I was the cameraman. Really? I did nothing more or less. Uh, and the, what was funny is that that video became more viewed than any content son had ever generated and i definitely remember talking to some of the marketing folks being like yeah we didn't really ask permission on that one we just kind of did it and they're like yeah um you know it's all right uh we just wish you had said sun microsystems in there at all i'm like did we forget to mention the name of the company? Oh, sorry about that. Sorry, that's awkward. Backfire. But yeah, screaming in an oxide rack is going to be less interesting for a couple of reasons.

One, it's all NVMe drives. We don't have any spindles in there, so it's all flash. I also would say that we have spent quite, again, we are big believers in learning from the failures that came in front of us. There have been lots of mechanical failures actually in server design the the mechanicals of of server design require some care and uh we've got an a just absolutely aces mechanical team um at a partner of ours benchmark electronics and they have done a terrific job on the mechanicals and uh screaming at this thing i don't think it's going to do very much i think this is gonna i i think we're mechanically pretty good shape one test that's definitely green the tick is green if there is such a thing it passed it there you go yeah absolutely This episode is brought to you by our friends at Fire Hydrant.

Fire Hydrant is the reliability platform for every developer. Incidents, they impact everyone, not just SREs. They give teams the tools to maintain service catalogs, respond to incidents, communicate through status pages, and learn with retrospectives. What would normally be manual, error-prone tasks across the entire spectrum of responding to an incident, they can all be automated in every way with FireHydrant. They have incident tooling to manage incidents of any type with any severity with consistency, declare and mitigate incidents all from inside Slack. Service catalogs allow service owners to improve operational maturity

and document all your deploys in your service catalog. Incident analytics allow you to extract meaningful insights about your reliability over any facet of your incident or the people who respond to them. And at the heart of it all, incident Runbooks, they let you create custom automation rules

to convert manual tasks into automated, reliable, repeatable sequences that run when you want. You can create Slack channels, Jira tickets, Zoom bridges instantly after declaring an incident. Now your processes can be consistent and automatic. The next step is to try it free. Small teams up to 10 people can get started for free with all Fire Hydrant features included. No credit card is required.

Get started at firehydrant.io. Again, firehydrant.io. And by our friends at MongoDB, the makers of MongoDB Atlas, the multi-cloud application data platform. Atlas provides an integrated suite of data services centered around a cloud database designed for scale, speed, and simplicity.

You can ditch the columns and the rows once and for all and switch to a database loved by millions for its flexible schema and query API. When you're ready to launch, Atlas layers on production-grade resilience, performance, and security so you can confidently scale your project from zero to one. Atlas is a truly multi-cloud database. Deploy your data across multiple regions simultaneously on AWS, Azure, and Google Cloud. Yes, you heard that right. Distribute your

data across multiple cloud providers at the same time. The next step is to try Atlas free today. They have a free forever tier. Prove yourself and your team that the platform has everything you need head to mongodb.com slash changelog again mongodb.com slash changelog So despite Gerhard having secured his spot in line, we think that probably an Oxide computer is not destined for his home lab. I mean, you'll probably sell him one just because why not? It's a sale, right? But not target audience is not the enthusiast,

hobbyist home lab guy like Gerhard who then is your ideal customer and to that ideal customer can you tell them why I mean I'm looking at it it looks cool right like you guys got the aesthetic down the black and the green and the oh and like it's it's sexy but I'm also not a guy who's gonna be acquiring racks upon racks right some sort of server farm. So can you, to that person, can you sell them on Oxide versus just going back to their Dell rep and saying, hey, give us a reorder of what we did last time? Yeah. So you should talk to some of those folks because those folks are in excruciating pain

for a bunch of reasons. One, they are in, first of all, they are all generally cloud aware. So, you know, some people say, oh, I love that Oxide is like, you're a contrarian cloud play. It's like, no, no, no, we are not anti-cloud. Like we are very, very pro-cloud. Elastic infrastructure is an incredibly important development. And we are very, very pro-elastic infrastructure, to be clear. Very pro-cloud computing. We just believe that you shouldn't have to rent all of it. We believe that you should be able to buy some of it.

Because when you're renting compute, the Moore's Law dividend is going to your service provider, not to you. And we believe that there are folks who've got compute at a scale where it makes sense to own a computer and own a rack of computers. So the folks that we are targeting are folks that are already on-prem. They are on-prem for good reasons. Those reasons are they may be security, maybe they're latency. They're very often economic. AWS is expensive.

The public cloud is expensive, especially when you're at a certain scale. And there's a certain scale you get to where it's like, actually, the public cloud is debilitatingly expensive. I can't even contemplate the cloud for this workload. So those folks, they are cloud aware. They're running their own hardware. And they are stuck on this personal computer that hasn't meaningfully moved in 20 years. And when they buy something from Dell or from HP or from Micro, they then are responsible for putting the software on top of it. It's like you're not running Dell on its bytes. You're running Dell plus VMware.

You're running Dell plus VMware plus Cisco plus software to manage the network. And you are going plus your distributed storage system, whatever that is. And whenever anything goes wrong, well, you assembled this thing, so this is on you. And every vendor points at everyone else. And boy, I mean, you know, I live this. We were Dell customers. And I just remember, I mean, I've told Dell a lot of things over the years. One of them is never tell me you've never heard of this problem before. I'm not interested. It's not, all that is

telling me is that your most technical customers are leaving Dell, which is actually what's happening. And so when you are having a problem, it's like, yeah, Dell is telling me like, I'm the only one seeing this. It's like, no, Dell is trying to gaslight you into believing that you're the only one seeing this because Dell itself does not have the depth of competence to actually understand what's going on on their systems. Because Dell, Dell in super micro, it's taking it to an even greater extreme of there's this self-fulfilling prophecy that this is commoditized garbage. So we're going to treat it as commoditized garbage. But it's actually really expensive. I mean, if you look at a racked out Dell 2U server, it's expensive.

And we haven't even gotten the software on there yet. We haven't gotten VMware. We haven't gotten the software or OpenStack or whatever you end up putting on this thing to manage it. For Oxide, not only are we taking the fresh approach to hardware, but obviously it's software co-designed. We are actually developing the hypervisor, the control plane. What you get is an actual cloud in that rack. You hit API endpoints, you provision. You don't buy VMware to put it on this rack. So for our target demographic, they have been grossly underserved. In fact, the existing infrastructure providers have denied

they even exist. They're like, well, every on-prem use case is going to the public cloud. It's like, I mean, these are like, no, I know about the public cloud. I understand the public cloud. I, this workload needs to run on-prem for economic reasons. This is not a legacy workload. This is not going anywhere. And to be told that you don't effectively don't exist and then be more or less treated that way, it's pretty aggravating. So, you know, our target demographic has kind of worked up there. They've kind of had enough. Actually, it was when we were doing due diligence for the initial VC investment and having VCs talk to our some of our first perspective customers, they're angry. So one of the feedback, we got some of the feedback from some of the VCs, like, well,

your early customers, they're agitated. I'm like, yeah, they're pissed. They're pissed. And they're definitely pissed. Like, don't try to tell them that they don't exist. That's a mistake. Because what they have seen is all of this innovation happening in all of these dimensions around them, and all of the innovation around Elastic Compute happening on

the public cloud, and where they need to run it, they have been entirely deprived. And so what they see in Oxide is oxygen. Someone who understands that, like, understands what I'm trying, and yes, I mean, the aesthetics are extraordinary, and the rack really is beautiful, I got to say. The rack is, it is so good looking. It is a really good looking rack, but what we're doing is much deeper than that. It's much deeper than the aesthetics. It is a true first principles approach that allows them to actually appreciate some of those advantages that folks have in the public cloud. And then they can go focus their energies on their business and on building the software and supporting the software, supporting the developers that they need to go build a better product, build a better service. And what we see is that our target

demographic is where we started on those excellent enterprises, excellent Dell customers. The customers that we see on the horizon are those folks that are born in the cloud and then wake up to a business that is actually not sustainable because their margin is actually going to Amazon. And over the years, there have been many of these folks who have come up to the edge and like, we're going to go on, we're going to build our own data centers. And then they go, you know, they're naive about how bad the market is. And so they go in like, I don't know, I'm going to buy some Dell or whatever. It's like, oh, God, yeah, you're going to learn just how awful it is.

And they end up vacillating, you know, going on-prem a little bit, but then staying on the cloud. And we believe that if you give those folks a real off-ramp where they can have the power of cloud computing, but with the economics of an on-prem data center, there's real demand for that on these cloud-borne SaaS companies. So that's the future that we see. I would really like open source developers to one day be end users of an oxide rack, of an oxide system, because I think there's a lot of power in the little person that has seen it all that is so pissed at their internet connection, that is so annoyed why the Unify doesn't work with Microtech. I'm talking about myself. that has tried Supermicros and it's like, they're okay, but seriously, after 20 years, it's still the same. If I buy a new one, it's exactly like the old one which I had. I think there's a lot to be said about where computers are

going these days, especially the latest Apple ones. Everything's system on a chip, you just replace the computer. There's no way you can replace a component i mean modularity seems to have gone out the window and i think it's the wrong direction so i'm not removing my my place from um when i registered interest i'm somewhere in your list 2020 i think it was february or march yeah i'm very curious about the pricing like ballpark like how many years do i have to save for one because i'm really really determined to get it even if it has to live in the garage that's okay we will we will find a solution you know but uh it's going to be a lot of allowance i gotta tell you i mean it's going to be you're going to be i mean it's going to be price competitive but not price competitive with the things that you're

looking at right it is again we are you're looking at what is more or less a personal computer and what we are really focusing at is an enterprise rack scale machine. So the pricing of our, certainly of our initial product, I think is probably going to be prohibitive, fortunately for you. So where could I get one from, for example, is there, will there be a place where I can go and get a slice of this rack or what would that look like? Yeah. Well, I think it's interesting. So I think because i first of all i totally agree with what you're saying i about the there's a a tremendous power in individuals right and their ability to contribute i mean the thing honestly the thing

that i would do and do i have one i guess i got that one here so what i would do is if one wants to start playing around with oxide start playing around with these little single board computers right this is uh i think this is an f411 so this is an STM micro. This thing will run Hubris, which is our service. So this is running our service processor. This is not something you're going to run your arbitrary cloud workloads on, but it is actually really fun to, Hubris is our operating system that is our, I mean, appropriately named because we did our own operating system. Rust-based operating system, DeNovo Rust-based system. And these single board computers are incredibly cheap.

For $20, you can get a computer that's more powerful than the desktop that I had when I came into the industry. And much more powerful. 400 megahertz part. My first desktop as a professional was 143 megahertz ultra spark. And the fact that we are able to have these incredibly powerful single board computers, relatively powerful, we view them as underpowered. Then there are these kind of embedded use cases. But I think it's a great way to start exploring oxide and start exploring something. And we love the fact that it's all open source. It's all out there and there's going to be some terrific mutations that are going to

be fun and allow people to explore and contribute, um, not in the customer sense, but more in a community sense. So that I would say is probably going to be going to be the vector unless you, uh, unless you inherit a data center data center and truly more money than you know what to do with. I like my options. Thank you. There you go. Well, let's open up the hubris and humility conversation a little bit.

I'll have you go a little bit deeper. You say hubris is the operating system, well-named, as you said, and easy to say, Gerhard, really easy to say, hubris. There you go. I've been practicing. Humility is the debugger which is just also

brilliantly named as a pair I love that kind of that goes back to your I guess humor value

do you want to tell the folks exactly why you build your own OS and maybe like give hooks into you know a lot of our listeners

our developers tinkers hobbyists operating system folks programming language enthusiasts. What could they potentially clone Hubris, the repo, and what could they do with it? Or what could they learn?

Or what could they help, et cetera? Yes, there's a bunch of great resources out there, actually. First of all, I would steer anyone to my colleague Cliff Biffle, who coined the term, coined Hubris for the operating system. He gave a great talk at the Open Source Firmware Conference that is really just superlative, must listen, must watch talk where he walks through why hubris? Why did we do our own operating system? Why did we not? And there are a bunch of reasons. And actually, it was fun to bring together some really different perspectives because Cliff had done a ton of embedded work and a ton of Rust work and had a real belief of what an embedded operating system should be. And it's funny because coming from really the more host CPU side, kind of industrial operating system kernel side, some of Cliff's beliefs that are the most

iconoclastic are ones that feel like they shouldn't be iconoclastic at all. So in particular, Hubris and most embedded operating systems do not use the memory protection unit that is present on most embedded microcontrollers. So they are effectively single address space applications. And that to me is crazy because as I mentioned, like these CPUs are more powerful than the desktop computer that I had when I came into the industry in 1996. And the idea that you would take a computer that's that powerful, that can do many different things, that can have true multitasking, and that you would run without memory protection. I mean, this is like, I mean, talk about something that the children don't appreciate. When we were coming up, if you're running DOS and you're running a game or editing a file, it was not unusual for the machine to just reset.

Yeah. And that is something that humanity has rightfully left behind because we actually have memory protection. Now, when your web browser does something that it shouldn't, it's an aw snap, right? And you've maybe lost that session or that program has crashed, but the rest of the computer is intact. And of course it should be. That hasn't been true on the embedded side.

And when we, part of the real design center around Hubris was we want a system that is microkernel-based, that uses memory protection, that is an all-RUST-based system, that really has RUST as a first-class citizen. And my first job in the industry was working for a microkernel company, QNX. QNX software systems out of Canada that later bought and sold a bunch of different times, was digested by BlackBerry at one point. I think at Harman, they've been in a bunch of places.

But QNX is an amazing operating system, microkernel-based operating system. I always felt that that was the right abstraction for a large cross-section of problems. So it was really exciting to me when we, and we did our own system because we were evaluating others and realizing that nothing was doing what we wanted it to do. And that's where the hubris comes from. My contribution, such as it was, was, you know, we talked about hardware software co-design. I'm also a big believer in system debugger co-design, where you are debugging, you are developing the debugger as you're developing the system. And I have always found that that yields a much more robust system and gives you a much better platform to develop that system quickly. So as Cliff was starting in on Hubris, I was starting in on Humility, the debugger for Hubris. And that's been really fun. I think we've taken the, because amazingly,

this doesn't really happen in the embedded world. The kind of debugger system co-design does not really happen. To the best of my knowledge, we're the only ones doing it. Most people are stuck using GDB and OpenOCD when they go to debug these things. And that is just galling. I mean, I was like, that is not only do you have a system that has these wild aspects of exposure because you've got a single system that's got no memory protection. Then you're going to debug it with these terrible, terrible tools. And it's like, are you really expecting your firmware not to have the results that it has? I mean, are you really wondering why your Bluetooth stack is rebooting and why all your devices are fighting with one another? It's because they are all on these systems that are these terribly antiquated software systems being debugged with terribly antiquated software

tools, and we're trying to get them to do something modern. So I think there is, I think Ubers is really important. I think that we're going to see a lot of use cases what our use case is this embedded use case rather the embedded use case in kind of a single board computer but i think that there's going to be many other use cases i should also say that the other beauty of hubris is that the hubris is not a general purpose system in that it is designed for that deeply embedded use case. It's not designed to load a new application that it has never seen before. So most operating, a general purpose operating system, I've got the ability to add a program that that operating system has never seen before and it will run it. And that's great on your desktop. That's great on a server. You don't

want that on an embedded system. So when at build time, Hubris knows all of the tasks. That's statically known. And there are lots of things you can go do when you know all of the tasks that are ever going to run on the system. You don't need to dynamically allocate tasks and processes. So there's a lot that comes out of that. I think it's really – it's been a lot of fun. It's also been super valuable for us. It's been unquestionably the right decision.

And I think it's a good opportunity for folks to mess around because that is – we open sourced it when Cliff gave his talk at OSFC. It's already been used as a great blog entry by Artemis Everfree on running Hubris on our watch on a pine time, which is fun. And there's a bunch of interesting stuff that's out there where people are starting to mess around and take it to different applications. We see a really broad use case for Hubris out in that embedded world. I read a lot of blog posts.

The one on Hubris and humility, the one that you wrote, Brian, is really, really good. I'm sure that good writing goes very well with a good software company and there's so many things to that but it's a good one to go especially for enthusiasts that want to try this out you mentioned the st nucleo yep device that's you know people can buy and try this thing out and that's just like to your point that you were saying earlier you can try it out you know you don't have to wait for a rack to be shipped from oxide even if you do have a multi-million allowance uh the point being it's it's a great one to learn more about hubris humility and just start exploring a bit more

of the oxide blog post because there's many good ones there's many good ones and then we've got our entire control plane is also open source so it also also vector people into our... We've done a DeNovo Rust hypervisor that we call Propolis. We've got our own control plane, which we felt we had a great name for, a Futurama reference, actually. Omicron. It's like, we were Omicron before Omicron was Omicron.

Oh, that's hilarious. Now, I'm a Futurama fan. And yet, when Gerhard said, this project's named Omicron, I thought to myself, that's a terrible name. They must have done it before the pandemic. Right. It's like, God, we're going to get a name of Project Polio next? I mean, that is strange and morbid. I went straight to COVID.

It did not go to Futurama in my head. No, this is Lur from the Omicron Per Se 7, right? Right. Yeah, totally. Now I know what you're talking about. Right, so we're big lure fans. So yeah, Omicron was a Futurama reference and now it's just like a big mess, I guess.

Hopefully, I'm optimistic that the Omicron as a Futurama reference will outlive Omicron as a COVID reference in the cultural zeitgeist, but we'll see. We may have to be patient on that one. We'll see. It depends on how far that thing continues to spread, I guess, or how many variants are called Omicron, you know, because there's just the one variant, right? Or just the

one that I heard about. Well, Brian, we've taken up so much of your time. I'm sure, Gerhard, you have many more questions, but you're not going to be able to ask them today because this show is just about over. Brian, I will give you one chance to say whatever you'd like here. And then for Gerhard's follow-up, we might have... First of all, I have to re-watch all of Silicon Valley. So that's the first thing. So it could be a while.

I have to do that. And only then am I allowed to invite Brian. Take notes, all right? Like, you know... I will. Trust me. The show will be all about Silicon Valley, okay? I will.

Yeah, if I... You know know one thing to say you know i think that one thing that has been neat is that that we've been doing for the last year and change or so um we've been doing a weekly twitter space which has been a lot of fun okay and i would encourage folks we do it oxide and friends is a weekly twitter space um and that's been uh i've always wanted to be in a book club and I think we've kind of created it. It ends up being kind of an accident, but club to a degree we talk about, we've got wide variety of topics there. Um, and that's been really interesting. I mean, I love podcasting as I love these kinds of conversations, um, are great. It's also really

fun when it gets hard to share or point about like opening it up to like individuals. And it's been, you know, when you open yourself up to the internet, you're like, oh my God, like how much, how much of 4chan is going to show up versus the kind of the delightful aspects of the internet. Right. But you know what? NetNet, it has been really delightful. And NetNet, it's been so much fun to hear from people that we, new voices, folks we

haven't heard from from hear their perspective, their ideas. And I love it. Actually, it's kind of like this. This podcasting meets the AM radio dial the old school AM radio dial. It's a really interesting kind of mashup that I really enjoyed. So you all had a podcast or have a podcast? Yeah, as well. Now, has this Twitter space kind of usurped the podcast? It has kind of usurped it. Yeah. I mean, I love the podcast. I love On the Metal. It's been great. But as you know, it's a lot of work. It's a lot of editing. There's a lot of pre-work. You end up with these things. You have these great conversations that you then have to kind of wait months to get out. And I think we really liked the Twitter spaces for that kind of that, that immediacy it's been able to, we've been able to get a lot of the bang, um, for much less of the buck. And then I think we've also been able to get these kinds of new aspects to it. Although I, but I still, I love on the metal people want

to check out on the metal. I love those conversations. Um, it was so much fun. So how do people people follow the Twitter? Is it just follow you on Twitter? Or is there a link to a Twitter space that we could put in the show notes? Yeah. I mean, if they follow me on Twitter, we link it out. It's every Monday at 5 p.m. Pacific. You can follow me.

You can follow Oxide Computer on Twitter. And you can also follow my co-host, Adam Leventhal. He's AHL, which is not the American Hockey League. So that, you know, we were, Twitter was a customer of Suns early and Adam realized he wanted to get in with his OG initials. So AHL to follow him. And then we would love to have, again, we really enjoy having new voices on there. I think it's a great medium. As with many Twitter properties, you know, I am filled with both hope and disappointment. There's so much that could be done with it that I hope that they do go through with it.

Yeah, it might just disappear. Who knows? I mean, they cloned, what was it, stories? They cloned stories as a feature and then they just said, meh, we're done with stories. But at least they're actually changing the product at this point. There were years where Twitter was stagnant. There were zero changes to the product

for probably like darn near a decade. So at least things are changing now. But yeah, you never know when spaces just might fall out of the cool kids club and be gone. I really hope not, because I think social audio is a really interesting milieu. I think it's a different kind of, you know, it doesn't replace anything. I think it adds to what we're already doing.

Like, I love podcasts and will always listen to that. But I really love this aspect of getting people together for social audio. I think it's a lot of fun. Well, we appreciate you getting together with us for this conversation. Listener, all the links to all the things are in your show notes. There's lots of cool references on this one. So definitely check those out. Of course, you can find all of Oxide's things in there as well.

Join the wait list if you have a small fortune and are ready to spend it on loud but sexy looking computers. Not loud, not loud. Only the power shelves. Just for a moment. Then it's all whisper quiet. Okay, for a moment of, it's going to blow you away for a moment and then just disappear into nothingness,

which is also nice. And Gerhard, thanks for sitting in for Adam. Thanks for, you know, faking like you had Silicon Valley. It didn't work very well. That's okay. I've learned my lesson. I need to be myself.

And that's my takeaway from this. Just be myself, seriously. That's a great takeaway. That's my takeaway from this. Just be myself, seriously. That's a great takeaway. Well, you definitely brought the humor, which is one of Oxide's values, so you might fit in there as well. Alright, that's our show for this week. Thanks for listening. We'll talk to you all next time.

That's the changelog for this week. We hope you enjoyed it. Stick around for a brief after show bonus. Gerhard asked Brian which character he identifies with the most from HBO's Silicon Valley and Insanity Ensued. We are including this bonus for everyone, but our changelog plus plus listeners get these kinds of goodies all the time. If you're not a member, check it out today at changelog.com slash plus plus. You can directly support our work, get closer to the metal with behind the

scenes extras, save a bit of time by ditching the ads, and get a changelog sticker pack while you're at it. Speaking of Gerhard, he's been killing it with Shibboleth lately. Episode 59 featured Ben Johnson from Lightstream talking Postgres versus SQLite. I think people have a frustration with having so many dependencies out there where just everything always requires like just way too much. This is just way too much like headspace that everything takes

up and you're not actually like building your application. You're like reading docs for Redis or for some like some caching system or some load balancer or whatever. And like the idea of just like actually writing your app and like the database is there and it just works and it's super solid but you know it's not you know i think i looked up i think in that blog post i wrote you know postgres has like i think their documentation is like three or four thousand pages in a pdf

like it's crazy which is great i mean it's you know it does everything but at the same time it's a lot to keep in your head so i think that that's really the reason people love it. If they have an application that works for it, then, you know, it's, it feels great to use. Continue listening in our Ship It feed or on the web at shipit.show slash 59. Oh, and Gerhard has a great guest lined up for episode 62. Can you guess who? What? Thanks again to our partners at Fastly for having our CDN covered, to the mysterious Breakmaster Cylinder for keeping our beat supply on swole, and to you for listening. We appreciate you. That is all for now, but we'll be back again on Monday for Changelog News. We'll talk to you then. I'm going to ask something that Adam would ask if he was here. Brian, who do you identify with from Silicon Valley?

Is there a character that you identify with? Oh. Don't tell me too many. It has to be one. Just one. Okay, so how do you want me to take it? So in terms of like the because if i'm gonna be critical of myself i'm gonna be my own critic yes please do uh this i'm this is really i'm

gonna expose myself here metaphorically keenan felt spar so you watch the show i did all of them but it was too long ago and i forgot you don't remember listen if we're gonna if we're gonna roll we gotta roll no so keen feldspar is a now he's a bit of a composite character and he's got some palmer lucky in him i definitely don't identify with at all but the thing about keen feldspar is that i actually do i mean identify with maybe putting a bit too strong but super enthusiastic optimistic guy who puts together these teams that do these kind of extraordinary things and to the the crew at pied piper it feels like he's constantly like lucking

into things and um everything is going to work out in the kind of the keenan feldspar and i i have often imagined that if i were to criticize myself i I would criticize myself as being Keenan Feldspar. Great with faces. Terrible with names. I don't think he was in season one. What's his face? I've Googled him. I've looked him up.

I don't think he's in season one. I think I'm off the hook here. No, he's no, no. He's Joel Osment playing Keenan Feldspar. Oh, yeah. And what it's the Keenan Vortex. Is that what they call it? Dinesh and Guilfoyle call it the Keenan Vortex.

Yes. Adam, where are you? Adam, we need you. Adam, yeah. I need to find this. Save us. Honestly, I wasn't going to go here. I feel like you took me here.

And then I'm like, I'm by myself. I'm the only one that's in the homework. You guys have to do the homework. No, no, no, no, no. I forget. So he's not Dinesh. He's not like the main characters. Who is he? I'm terrible with names.

I really am great with faces. Look, if you wanted to open this one up, I mean, this was your question, Gerhard. You're asking me the question. It's on me. It's on me. It's on me. Like, what am I supposed to say? Like Dinesh or Guilfoyle?

I'm supposed to give you like, am I supposed to be like Richard Hendr or guilfoyle i'm supposed to give you like am i supposed to be like richard hendrix now no no no whoever you want okay all right let's go uh main characters no you know i i have considered uh because these the folks that are in there are a lot of great character actors that are in hbs gulf and valley and i wanted to have like so you can get the actor who plays ron laflum who's the lawyer you could have him like join in all hands for like 3 000 bucks you know you're like and now our new general counsel and have ron laflum in there that's kind of nice uh side gig for them you think you have the royalties but now it's like a kind of irl royalty where people will just hire you to come to their party and basically be that character for you. Yeah, that is, that is the way that once you reach, there's a certain critical mass of celebrity that once you have attained,

you can effectively live off your own fat for the rest of your life by doing these kinds of things by, you know, even if you're a, you know, a C-list celebrity, you can go like open a car wash for a couple hundred bucks or whatever it is. Yeah, totally. Well, that Cameo has made it even easier now. They can actually just sit in their house and just hold up their phone and just say hi to people or like, you know, whatever it is and charge 400, 500 bucks a pop. You can do those 30 seconds, a couple bucks you know why leave bed just live off the fat and i'd pay for it i'd pay for it and i would get these obscure silicon valley character actors but neither of you two would appreciate it honestly i don't know no i would totally lost totally i would faces please what you wanted to do hold of a picture of who he identifies with

care heart hubris i mean that that was like know, a word which I haven't used. It just shows you. Great with faces? Well, maybe. We will see. Not very good with names. We already know that.