podcast-2.json

{"podcast_details": {"podcast_title": "Software Engineering Daily", "episode_title": "Shipping Oxide with Bryan Cantrill", "episode_image": "http://softwaredaily.wpengine.com/wp-content/uploads/powerpress/SED_square_solid_bg.png", "episode_transcript": " Hyperscalers refer to expansive cloud service providers capable of delivering enterprise-scale computing and storage services. These hyperscalers like Google, Amazon, and Facebook that all have huge data centers are either running their own software or renting out this infrastructure. Realized a long time back that the traditional network storage and compute server racks were not enough to fulfill the requirement of a modern enterprise at scale. So they built custom solutions for their data center requirements. For all of the other companies and organizations that have their own data centers, they're still running legacy old technology. Oxide Computer is a company aiming to democratize access to rack-scale technology and provide a seamless software stack to facilitate its implementation. Brian Cantrell is the co-founder and CTO of Oxide Computer and he joins us in this episode. This episode of Software Engineering Daily is hosted by Jordy Mon Companies. Check the show notes for more information on Jordy's work and where to find him. Hi, Brian. Welcome to Software Engineering Daily. Thanks for having me. Great to be here. For data-driven companies, Starburst offers a full-featured data lake analytics platform. Their data platform includes the capabilities needed to discover, organize, and consume data on a data lake without the need for time-consuming and costly migrations. Trusted by companies like Comcast, Grubhub, and Priceline, Starburst helps companies make better decisions faster. Want to see Starburst in action? Try Starburst Galaxy today. Starburst.io slash S-E Daily. I think this is your, it is not your first appearance on the show. I'm fairly sure about that. Can you correct me if I'm wrong? I think that that's right. I think I may have been on Software Engineering Daily, I mean like years ago, I think like maybe more than five years ago, I think it's been a while. Yes, yes. So you've mostly moved out of or away from Twitter. So you recent talk at the Monctober, and the Monctober Fest hosted by the brilliant guys at you said that it all starts with a tweet. So if you've moved out from or away from Twitter, does that mean there's no more talks coming up? You're not starting anything, right? Yeah, that's right. Yeah, actually, you know, I say that I've moved away from Twitter, but I think like a lot- But it's not true. Oh God, like a lot of people, you know, I'm, so I mean, right now, sadly, right now I'm on Twitter, Blue Sky, and Mastodon. So like, I don't even know, you know, I don't even know what's going on. So- The meme, that meme from the Sopranos that just when you think you're out, the gravitas of Twitter just pulls you back in. It's so true. Well, you know what it is, and actually, and hey, Blue Sky, if you're listening, you need to give people some unlimited invites. I know you're going to have scalability problems, but the, because, and I think like a lot of people have this issue where I have got, you know, ultimately Twitter is not one community. It's a bunch of sub communities. And I've got, you know, we've got our, and it's not just software engineering as community, right? You've got the Rust community. You've got, you've got kind of the FPGA open hardware community. You've got the, and a bunch of these technical communities have actually moved to, and I noticed that like, when I tweet or toot something out, I guess in Mastodon's parlance, something that's technical, that gets a lot more traction on Mastodon than it does on, so a lot of technologists have rightly said that they're fed up with the way the company's being run and so on, and are on Mastodon Blue Sky. The, what has sucked me back in is I am, I'm an Oakland A's fan. We live here in the East Bay. And the, and currently going through a, not that you would follow American baseball, but the Oakland A's are living the plot of a movie, a movie with a diabolical and stupid owner, John Fisher, who is, and so he's trying to move the team and it's this whole saga. Oh, from the city, away from the city. From the city, moving to Las Vegas. Oh, wow. It's a big, big mess. And I mean, it's also like great in that the fans are standing up and protesting, and that's been all, but it's been very, that community has been really important. It's always been important to me, but that community, that Oakland A's community is still very much on Twitter. On Twitter, yeah. So, I, I find like you really need, and like weather Twitter is still on, I've literally, if you go to weather Twitter at all, weather Twitter is amazing. Weather Twitter is. Yeah, I, go back to the, there is something about the tech, slash software community. I guess it has to do with the politics of each one of the community, and something that I don't want to delve into, but that's my only explanation to why the core of, yeah, the software community, tech community has moved out from Twitter almost completely. I live in that space, but I'm not a technologist myself. I'm not a developer myself. And. Well, I think that, and I think in this regard, I think that software engineers in particular are, you know, the kind of the malpractice at Twitter, I think it is particularly upsetting to software engineers rightfully so. I think that the, so yeah, I think that, in this, I think probably is the future. I think that it is probably the future that is gonna be more fragmented. And I think this idea, I, you know, we kind of talk about what's gonna replace Twitter. And I think that, you know, we kind of talk about what's gonna replace Twitter. And I think in the indefinite future, I think lots of different things are probably gonna replace Twitter, even though it's kind of a pain in the butt. So. But wait, you just said that most of the communities apart from that one remain at Twitter. So do you reckon? Well, so I, well, what I've noticed that like, so for example, this Oakland A's community is still very, very much on Twitter. But my, you know, tech is on Macedon, other communities are on Blue Sky. I think that this is probably, and then a bunch have moved to other spots. So the, I mean, so then you get the whole Reddit nonsense that's happening at the same time. So I think it's fair to say that social networking is in the midst of a lot of upheaval at the moment. So it's gonna be very interesting to see how it settles. I, but of course, you've got this, you know, to go back to your essential question, where am I going to have my hot takes that become the foundation of Future Talks? And your spaces, your Twitter spaces, which are highly missed. Yeah, yeah. So the, well, we actually do that. We, that I think Discord has broadly replaced Twitter. We definitely got off Twitter spaces. So anyway, we will find outlets. I will find outlets for my hot takes. I mean, that's extremely important, obviously. So we have to have a place to have our hot takes that become the inspiration for Future Talks. So that's the humanities most dire problem, clearly. Exactly, exactly. So referencing again, the talk that you gave at Mokhtova, which everyone can find on YouTube. It was uploaded a few months ago. The event took place, well, a few months ago, almost a year, I can't really remember. It's in Portland, Maine. Yep, wait till I do. And you talk about many things in that talk. I mean, you've been a long time speaker at that conference, but the last one you mentioned specifically the spirit of Silicon Valley, right? And you actually mentioned it in ways that are for you not... You describe it in ways that are not only inspiring for you, but you actually portray yourself as a son of that. There's affiliation. So talk to me about, please, how would you describe the idea of Silicon Valley? And why do you feel that yourself professionally and personally, you're a son of that idea and generation previous to you? Yeah, and when I say that, unfortunately, I think Silicon Valley has transitioned over the years. And I would say that I view myself as in the spirit, in the original spirit of Silicon Valley. A specific, yeah. Yeah, in particular, I mean, the roots of Silicon Valley were these engineers coming out to Shockley Semiconductor, and realizing that Shockley was a jerk and wanting to go their own way. Shockley, one of the inventors of the transistor, but an extraordinarily difficult human being. And as it turns out, a eugenicist and racist, and much of other things. And I mean, in many regards, that kind of origin story of Silicon Valley, it was very prophetic that you had someone who was a, was potentially a brilliant technologist, but was such an impossible human being that they limited their own efficacy. But he had grown up in Palo Alto, which is the reason he had returned there. And this group of eight engineers, which Shockley called the Traderous Eight, and they wore as a badge of honor, went to form a subsidiary of an East Coast company called Fairchild, Fairchild-Gamberman Instrument. And that group became Fairchild Semiconductor, and Fairchild Semiconductor, and this is to me, like that is the true origin of Silicon Valley, is at Fairchild. And at Fairchild, they very much invented the future. And with Gordon Moore and Andy Grove, and actually our board member, Pierre Lamond, was actually at Fairchild. And wild to hear Pierre's stories of being at Fairchild. And this is at a time when the transistor is brand new, the integrated circuit is being invented. And these are the things that become the foundation for every single thing we do, is ultimately due to the semiconductor advances in Silicon Valley in the 50s and 60s and 70s and 80s. So that sense of innovation and of venturing in boldly into the unknown with a group of fellow engineers, that to me is Silicon Valley. That is the true spirit of Silicon Valley. And it's tragic to me that, but maybe it's also right there in the origins that that spirit is corrupted by this kind of lust for mammon and material wealth, which is like, and I mean, like, listen, nothing, material wealth, like fine, great. It's ultimately like, it's not the meaning of it all. And to me as a technologist, I am much more interested in the kinds of things that the breakthroughs that we can have that can serve us all, right? That can serve all of humanity. And, you know, I read a terrific book years ago in the slow technology series, which is a great series of books, book called Dream Reaper on the invention of the bi-router combines by Craig K-9. And the bi-router combine being a new kind of combine, the combine combines reaping and threshing. And it's as much a history of agricultural technology as it is anything else. And agricultural technology, in the history of agricultural technology, something that we should all like take real appreciation of because that is the reason that you and I are not in the fields today. And ultimately it is innovation that has allowed us to not just survive, but thrive. And the history of humanity is a history of that technological innovation. And so to me, that's what Silicon Valley is. It's more than a place. It is that very much that spirit of innovation and of solving hard problems. But, you know, it is true and unfortunate that it's been, that has been distorted over the years. I would like to see Silicon Valley return to its roots of real deep innovation and solving some of our most pressing problems. Okay. There are two things there that I'd like to pick on. One later, which is the core of the conversation that I want to have with you, which is hardware software co-design. And so I presume, and please don't elaborate now on this, but I presume that the Fairchild era was more about hardware than software. I'm fairly sure there was firmware involved, but I think the importance of software came later for everyone in the world. Yep. But also picking up on what you just said, apart from, we got, regardless of the perverse incentives that now dominate Silicon Valley, like you just mentioned, there's also a sense of a dawn of an era, right? And limited by physics, right? You mentioned in that talk and in other talks in the talk that you recently gave at Open Firmware Convention, that Moore's law is ending, right? I'm not sure if it's dead, but it's ending. So there is a limit, there is a, you know, an end of a cycle, right? Regardless, again, of how perverse incentives have become right. So I guess, how does it feel that you want to embody the spirit of the early age Silicon Valley when the limitations of physics are, you know, starting to surface have become really patterned? Where's the next innovation going to happen? Well, I mean, I think that, you know, Moore's law was an observation made by Gordon Moore originally in 1965. And I mean, Moore's law was not even, I mean, it wasn't even codified really. I mean, it was kind of deposited in Gordon Moore's original 1965 paper. But Moore's law is not a law of physics. And in fact, at any given moment, if you had, you know, took your time machine and traveled into Silicon Valley and asked, what is the state of Moore's law? People would tell you that like Moore's law can't last more than another couple of years. Moore's law will, you know, Moore's law will end in, and now I think that all of that said like, no, no, no, this time we actually are at this time really. But I think it's important to realize that like that transistor density, and again, Moore's law was, but could have been rightfully conflated with transistor speed and density and economics. My kind of thrust has been that Moore's law and I gave a talk a couple years ago, wondering, you know, what was it actually Wright's law all along? So Theodore Wright was an economist at an aircraft company in the 30s and observed that the more we make things, the cheaper they get because we get better at it. And if you look at Wright's law is, it explains what the economics of transistors are arguably better than Moore's law does. And so I actually think that like, it's not that Moore's law, it's just like the end of Gnard scaling 2006. Gnard scaling, you know, for years, the clock rate of your CPU would double every 18 months. And it was, you know, if you came up in that era, as I did, it was remarkable because I mean, they had to actually make new computers go slower to be able to play old video games that had old timing loops in them. And, you know, I don't know who the marketing genius who was, who instead of adding a go slow button, they added a turbo button and the turbo button was always depressed. And if you wanted to slow it down, you would, which was again, an active genius. That was the kind of the halcyon days of Gnard scaling. Gnard scaling ended in 2006 and we, the CPU that we're running on are really no faster from a clock perspective than the CPUs we were running on 15 years ago. What has shifted is that, but the transistor density has continued to climb. So we've gotten more and more cores on that die. We've found ways to take advantage of those cores. And now with transistor density, now it's self slowing, we're forced to innovate again, and we're forced to innovate differently again. So we are, you know, I think that even Moore's law, I think you can kind of see it to do it for another couple of generations, but I do think that we are gonna shift our focus. And I believe we're gonna shift our focus to how do we, how do we make better use of these computational resources? There's a lot of waste, frankly, that has been hidden by the rising tide of Moore's law. And there are a lot of things that we can do to be smarter in software and systems. And we, those are the kinds of things that we've been exploring post the end of the Dynart scaling. There's a bunch, there are a bunch of other things that we can go do. And I think that when you, and I mean, indeed, that you can argue that the end of the Dynart scaling has prompted software to get more efficient. There was an era where like, it just felt like software was getting more and more morbidly obese. And you can view things like Rust and the rise of Rust as a real response to that, where actually getting us back to a leaner artifact and getting us back to artifacts where we do care about memory sizing, we do care about text sizing, program text sizing. And so, I mean, to me, it's exciting because it means that we're, the problem is gonna shift again. And strictly speaking, strictly from an oxide perspective, we believe that one of the ramifications of that is that we need to stop building computers to throw out after a year and a half or two years. And what has historically been true in the server space is that they've got very much have that personal computer zeitgeist where the machine itself is kinda junk, the machine that's surrounding the CPU. Because a better CPU is gonna replace it in a year and a half or two years. It's like, well, if a CPU is actually not something that is gonna last a year and a half or two years, but it's gonna last more like three or five or seven, how would that change the way that you architect the system around it? And we think that there are a bunch of things that you would do differently to reflect a machine that is gonna be more durable. And there are a bunch of things that you putatively can't afford to do if you're gonna throw it out after a year and a half that you can afford to do if it's something that's gonna be really set. With brands like Kelley Blue Book, AutoTrader, Dealer.com and more, Cox Automotive flips the script on how we buy, sell, own, and sell. And we're gonna be doing that in the future. So, we're gonna be doing that in the future. And now, the team at Cox Automotive is looking for software engineers, data scientists, scrum masters, and other tech experts to help create meaningful change in the industry. Want to be part of a collaborative workplace that values your time and work-life balance? Visit coxautotech.com today. And work-life balance? Visit coxautotech.com today. Here's a puzzle. What do products like Dropbox, Slack, Zoom, and Asana all have in common? The answer is that they were all successful because they became enterprise ready. Becoming enterprise ready means adding security and compliance features required by enterprise IT admins. When you add these features, enterprises can buy your product and they'll buy a lot. These features unlock larger deals and faster growth. But enterprise features are super complex to build with lots of weird edge cases and typically they require months or years of precious engineering time. Thankfully, now there's a better solution. WorkOS is a developer platform to make your app enterprise ready. With a few simple APIs, you can immediately add common enterprise features like single sign-on, OAuth, SAML authentication, and SCIM user provisioning. Developers will find beautiful docs and SDKs that make integration a breeze. WorkOS is kind of like Stripe for enterprise features. Today, WorkOS powers apps like Webflow, Vercell, and more than 300 others. The platform is rock solid, fully SOC 2 compliant, and ready for even the largest enterprise environments. So what are you waiting for? Integrate WorkOS today and make your app enterprise ready. To learn more and get started, go to workos.com. So before we move on to, again, this, this, the core of what I, you know, what to pivot the conversation, which is exactly, you mentioned it, OXIDE, there's no better way of embodying, you know, the ideals by which you want to rule your life, that actually taking it to applying them and taking them to practice. And you've founded a company that is about hardware and software code design, or, you know, the idea of a company that's about the idea of a company that's about the idea of a company that's about the idea of a company that's about hardware and software code design or hardware and so forth. But you mentioned Rust. I've got an unpopular opinion about, I have nothing against Rust. It's just that there's always been C and C++. So people effectively caring about optimization and lightweight software, if you wish, and getting the most out of our hardware. That would be an oversimplification of what C++ is about. But in the context of this conversation, I think it would be a good summary of it. And it's around 90% of the code that runs the world. And that arguably almost around half of the code that runs critical infrastructure, if not more, from the latest data that I've got. And it's not going anywhere. I mean, I'm not sure what your opinion is about, but I see a lot of optimism about Rust. And yet, like we were talking about Twitter eventually, the pull, the gravitas for C++ is going to be strong enough for it to hopefully, and this is my opinion of my wishful thinking, it will evolve to something that makes it safer. So I guess what's your opinion on that? Because again, there was always a, the firmware community was always strong on C and C++, right, correct me if I'm wrong. You're probably more of an expert than I am in that. C primarily, but yeah. I mean, I've spent my career doing OS kernel development. So I've been right. And I was implementing, and when I actually started my career in the mid 90s and going into OS kernel development, I was being told that C was dead and that it was all gonna be C++ and then especially Java. And with the rise of Java, we wanted to put Java everywhere. And I was at Sun during the heyday of Java. I mean, we ate at a cafe that was literally called the Java Java. And Sun was, now Facebook, now Meta, I guess, but Sun wanted to do Java microprocessors and Java operating systems. And that didn't make sense to me because what I saw was actually the systems needed to deliver highest performance and C was the way to do that. Not even C++, right, but C. But the problem with C and then especially C++, C++ has to me, C++ was always the worst of all worlds where you end up with all of the unsafety of C, but with the ability to create these abstractions much faster than you could debug them. So you end up with these systems in C++ that are effectively undebuggable. We never use C++ in the operating system kernel. We, I think that is true for most OS kernels that don't have C++. So I never saw, no, I know C++ obviously metastasized at Google and beyond, and there was a lot of important C++ out there, but to me, I had written about 100,000 lines of C++ and decided that I was writing no more because I felt that there were, what C++ gave me was so little and it didn't give me anything with respect to actual safety. It took a lot away in terms of runtime and then especially complexity. And C++, I mean, C++, I mean, it's like Super Size Me for abstractions. You recall the Super Size Me movie where he's, you know, and to me, it's like abstraction junk food, and it creates the ability to kind of, again, create these abstractions very quickly, but then not be able to do it in the real world. But not be able to debug them. So for me, I was at a bit of a quandary because I was struggling to find what is that thing that will replace C, so there are a lot of problems with C. And I say this as someone who, again, I have written a lot of C, I know how to write memory safe C. And memory safety is one of those things where the challenge of memory safety is not at like, you know, freeing what you allocate is not hard. And it's not hard to avoid things like double freeze in general. What becomes much, much trickier is when you have an interface boundary and I wanna call into your code. Well, now we're gonna, the language isn't gonna really help us. So we're gonna have to have a contract and we can, in that contract's gonna be implicit. And the way we would write C, we were pretty disciplined about it. And we had a bunch of patterns where you could reliably know that, when you wanna create one of them, we wrote very effectively object oriented C, where if you wanna create a foo, you're gonna call foo under bar create, it's gonna return a foo T, any operations on foo, we're gonna take a foo T pointer to operate upon and then there's gonna be a foo destroy that is gonna actually implicitly free the foo, which is fine, but very much relies on convention and doesn't actually allow you to do things that are really sophisticated. So in particular, one of the things as I was first experimenting with Rust and realizing that the experience that I had is that my very naive Rust outperformed my hand written C. And I'm like, why is this? And in the particular program that I was writing, the reason for that is that in my C, for this particular data structure, I'd used a balanced binary tree as you do, used a balanced binary tree library that we wrote years ago based on ABL trees, that is extremely robust and I can use very quickly. In Rust, you use a B tree if you wanna, there's no red, black tree, I'm sure there's a red, black tree implementation somewhere and ABL tree implementation somewhere, but the kind of the default standard collection data structure that you use is a B tree. A B tree is a better data structure than a balanced binary tree. It is a more cache efficient data structure. There are lots of reasons, but a B tree is really gnarly to implement. And indeed, it's like, where is the C library to implement a B tree? And it is obviously possible to implement a B tree in C. It is really, really difficult because a B tree fundamentally relies upon moving the location of memory objects. That's the way a B tree works. And when an object is gonna be promoted up into a larger node, it's gonna be the memory for that object is going to be moved. And this is where the contract breaks down because if we've got a foo library, we've got a foo library that takes a foo create, a foo destroy, you rely on the fact that that library is not gonna change the location of that foo underneath you. Because you ultimately are, you've exposed the innards, the implementation, even with careful C, you will expose the implementation. So the problem with that is C by its nature very much inhibits composability. And C++ papers over this, you get marginally better composability, but you haven't actually solved the safety problem at all. So it's very easy to have a C++ system that operates across purposes or sake vaults. And you're like, where the hell am I right now? And it's very, very hard to debug. And... Do you envision a future? So I guess your ideal scenario for the future is every C and C++ code replaced by Rust? Yes. Okay, but could you envision even a medium term scenario in which coding with C and C++ with a AI code companion, guiding best practices, principles, whatever you may wanna call them, enforcing those actually. But you mean like chat GBT to help navigate memory safety? I mean, Jesus Christ. No? No, I mean, that's its own bothers. That's its own bothers. Honestly, I would not try, unfortunately I'm the parent of teenagers. And I know that there are certain ideas that you don't talk a teenager out of, because it's like, no, go ahead. You know what? In fact, I insist that you do that, because you need to learn a life lesson here. And me describing why that's a bad idea, is not gonna be retained. You experimenting with this bad idea. And so you go in as a parent, you kind of constantly have the like, is this bad idea gonna get you killed or injured? Like that one I need to intervene in. But it's not gonna get you killed and injured. You know, if you wanna shave your head or the dye a blue. Yeah, burn a finger with a candle, whatever. And so, chat GBT to navigate memory safety, I very much put in that category of, no, in fact, I insist you go do that. I think that will be, emphatically be its own punishment. No, that is a true, that is not a solution to the memory safety problem. Okay. But again, I would encourage anyone who is feeling that desire in their loins, I would please go act on it. Just don't inflict the rest of the time you create. If anyone is coding C++ with chat, TPT is a code companion or codey or code whisperer or any other copilot, wherever. Let us know and we'd like to know. So let's go back to the, so yes, exactly. So there's no better way to embody those principles that we've described at the beginning that found in a company, which is Oxide. By the way, today has been an important day at Oxide, right? A huge milestone has happened. You just told me before we started recording, can you describe what the company is and what happened today? Yeah, so today it hasn't opened yet. It's this evening, this afternoon. The first Oxide rack will be loaded into a crate and headed out to its first customer. So we've been- Can you tell us where that customer is? Is this in a town like Portland, Maine or something or is it a big city? That exactly, I would want to respect their own privacy, but fortunately, when you solve a hard problem like this and you really broadcast that you intend to solve it, people present themselves and you've got technologists present themselves to help you do it and customers present themselves and say, hey, we've been looking for, I thank God someone is finally solving this problem and those that have been suffering with Dell and HPE and Supermicro are excited that we are taking on. So our earliest customers are in that category of folks that have been suffering. You took investment from capital, but you take investment also for these initial customers that trust your vision, right? Absolutely. So tell us, what are the principles that went into that rack? Like there's a long word, but what are the principles that you envisioned and that are embodied in that rack that is shipping later today? Yeah, in particular, we saw a couple of them. We are at the kind of highest level, we are trying to bring modernity to on-prem infrastructure. So core thesis of the company, Jeff Bezos is not gonna own and operate, or I guess Andy Jassy now, is not gonna own and operate every computer on the planet that there exist reasons to run your own servers and your own data center. And it's not for everybody, certainly, and we are big public cloud proponents, especially when you're small, when you're just getting started, public cloud is great. And in particular, we are huge believers in elastic infrastructure. You should be able to hit an API endpoint and go provision a virtual computer and a virtual NIC and virtual storage and be able to hydrate that by hitting API endpoints and using Terraform and so on. So huge believers in that. What we are also huge believers in is that there are reasons to run that in your own DC. Though those may be security reasons, they may be latency reasons, they may be regulatory reasons, they may be risk management reasons, and they may be economic reasons. So as it turns out, if you're gonna use a lot of compute, just like if you're gonna use a lot of anything, it's generally a better idea to own it, you're gonna use a lot of compute, you actually don't wanna rent it, you wanna own it. And I think increasingly, you know, it used to be true way back in the day, at every AWS re-invent, a price cut would be announced. And they did it for so long that there was kind of this entrenched idea that the cloud is only going to get cheaper. And we knew it's like, because I worked for a public cloud company at the time, it's like, that's going to have its limits. And, you know, re-invent is not about the price cuts anymore. You know, we don't really get those big price cut announcements. And certainly there are some things like bandwidth that have never seen a price cut. And what people are realizing is like, actually this is pretty expensive. And it's like, yeah, this is, you know, kudos to the execution of Amazon for giving people the idea that public cloud was a terrible business that no one wanted to be in when it actually is a very, it's a high market business and it underwrites the rest of the retailer. So we see that economics as increasingly a driver but honestly we see all of those drivers. And there are the security and risk management latency in addition to regulatory compliance and in addition to economics. And, you know, each of those kinds of folks has got kind of a different angle that they are bringing. All of them share a common frustrations though in the state of the art for on-prem computing is important. It is, it looks like the personal computer because it is a personal computer. This is something that basically hasn't the actual machine architecture has not evolved. The CPU is evolved. The CPU is very sophisticated, it has gotten better and better and better but the machine around it is trapped in time. And to say nothing of like the software that you want to run on top of that. If you want to actually, what you want to deliver is elastic infrastructure. You being, I am the platform group in a company and what I'm responsible for is that infrastructure for my developers. And I'm trying to do that on-prem. If you're doing that on-prem or I need to do that on-prem for the other reasons. If you're doing that on-prem, you're stuck in these legacy machine architectures. And then what do you do for software? It's like those things don't come with software. When I go, when you buy a Dell or an HPE system or super micro system, there's actually, I mean, sadly it's actually even worse than that. They do come with software. The software they come with is this atrocious firmware running the baseboard management controller or the ILO or the iDRAC. And the software that actually controls the computer is not great to put it euphemistically. It's got a lot of problems associated with it, but it's actually, so I've got a bunch of software that I actually don't want. It's kind of in my way. Then I don't have the software that I do need. Namely the software that I actually want to be able to run not just an operating system, but an actual true proper elastic infrastructure. There's no, I am responsible to actually go and develop that distributed system on top of that. Whether I'm buying an off the shelf product from the likes of VMware or I'm trying to attack into an open source project, lots of open stack. It's pain and suffering as far as the eye can see because when that system doesn't behave and when my developers say, hey, you know, this provision that I had, you know, I went to go provision this VM and it's taken like 10 minutes of what's going on or the, I can't provision it at all. It's like everybody points fingers at everybody else. VMware is pointing fingers back at Dell, Dell is pointing fingers back at Cisco, Cisco is pointing, and the problem is that the end user of this is the one who has had to do this integration and is suffering with the fact that these things weren't actually designed together. There is no co-design in the computer that's been designed by the Dell HP Supermicro, the elastic infrastructure that's been designed or evolved, the networking infrastructure, all of these things are operating at cross purposes. So I had kind of the big thesis for Oxide was we wanna slice through all of that. We wanted truly co-design hardware and software. We wanna use that to deliver a coherent system and we wanted that out of the box delivers elastic infrastructure. You should power it on, provide it the necessary configuration to speak with your network and you should be provisioning VMs. Doesn't sound like, that shouldn't be as hard a problem as it is, but the reality is these layers have ossified to the point that in order to actually create that system, you've gotta demolish all the boundaries between these layers. And there's a lot of hardware, but then there's a lot of software. And so that's what we've been building. That's been the thesis of Oxide and that's what we've been on the journey to build. And one of the challenges we've had is what is the minimum viable product? Every startup has this challenge. What is the minimum viable product? And one of the challenges that we have that a lot of deep tech or hard tech startups have is the minimum viable product is pretty big. And in particular, part of the problem with the Dell HPE Supermicro is that or the Cisco Arista Juniper is they are delivering this sliver. And when you are only delivering that one U or two U server, you actually, it's very hard to assert control over the rack. And our belief was and remains the minimum viable product is a rack scale computer. So that includes the PowerShell, PowerShell controller, it includes the switch. So we developed in addition to developing our own compute slid, we developed our own networking switch. So we just, we joke that we're nine startups within one startup. There are days when it feels like more like two dozen because we've taken on a lot of very challenging problems. But the upside of having done it that way and of having co-designed the switch with the compute slid with the cable backplane, with the rack is that we can truly integrate this stuff together and solve some of these really thorny problems and deliver to the end user a turnkey experience. So you can view it as, I mean, and our most successful products in computing have done this, right? This is very much an Apple ethos, right? This is where, this is what Apple has historically done. Now, where we diverge is we also believe that when you take this fully integrated approach, there is a lot to be gained and nothing to be lost as far as we're concerned by being completely transparent. So we are, everything we do at Oxide is open source. Everything we do is out there for people to see and understand we've been very transparent by how we're building it, we're not secretive at all because we want people to understand what we've done and the approach we've taken. Where people disagreed with it, we've always wanted to hear about it. I think what technologists have found as they've waded into the details of Oxide is, okay, finally, someone has designed it the way I would design it. And that's because we have pulled in a bunch of folks that for different aspects of the system have a belief in how this should be done. And that's what's reflected at Oxide Rack. Building on this, you've manifested in the past also, not criticisms, but concerns about how fully open source the RISC-V project is, or RISC-V, I never know how to pronounce it, to be honest. I think it's RISC-V, right? RISC-V, yeah. But you build your hardware mostly on AMD architectures? Correct, may I find this? Yeah, AMD Milan for the CPU, Cortex-M7 for the service processor, M33 for the root of trust, and then Intel Tofino for the top of Rack silicon. And then we are using a bunch of other components from other vendors for different, but those are kind of the major computational components, certainly. And how much collaboration have you found from those providers to open source everything that is run on it? Has it been difficult? They've been great. I mean, they've been really, and I think that, you know, fortunately, you know, they see the same thing that we see that this lowest layer of platform enablement software has, it's been a real problem that it's remained proprietary. And I mean, to take the AMD, you know, to their credit, they are, the OpenSIL, something they announced a couple of weeks ago, which is this lowest level silicon initialization library. And they've really committed to, we are not using OpenSIL exactly, but we are extremely supportive of that effort where AMD is pioneering OpenSilicon enablement. And, you know, Intel too has been very receptive to that. So, I mean, I think it's been, which is not a future that one would have envisioned, you know, a decade ago, where, and then there certainly are folks that still view this stuff as ultra, ultra proprietary. When we make decisions, that's something that we factor in. So we really look to what is a company's software and firmware disposition. We use Chelsea for our NICs, in part because Chelsea, we love Chelsea's software disposition. And Chelsea has the NIC, even a NIC that is not a smart NIC, a traditional NIC, there's a lot of sophistication in the NIC. And Chelsea has been exemplary in getting those drivers open source and having a driver model that's got longevity to it and so on. So that's something that we actually really looked at when we're evaluating these different components for the rack. We look at a vendor's disposition with respect to that. Going back to your product, in terms of, I don't know, I'll mention a few areas of the product that you're shipping, memory management, networking, IO pressures or whatever. Tell me the three things that you feel more proud about, what you've achieved in terms of design that might be innovative or optimizations or of previous things, but in those terms, anything? Yeah, boy, there is just, there is so much because we have, when you take a clean sheet of paper, you know, this thing is so ossified that you, that would I say, the kind of the extant server ecosystem and infrastructure is so ossified that you can't just take a little bit of it. You kind of have to take the whole thing, which is what we've done. So, but we take the whole thing. It's not one innovation. It's like, there are so many different ones. And, you know, I mean, so I, well, first of all, I'm, the fact that we have been able to pull off our own server design, the fact that our compute sled has no bias in it. There is no AMI bias in the system. So this is a dimension in which we are regrettably total pioneers because you think that the rest of the industry would do this, but even the hyperscalers have suffered at the hands of these kind of traditional bias vendors that are responsible for those lowest level silicon enablement, platform enablement. We have no bias. We go, we, the first instruction after the AMD PSP executes is our operating system as it pulls up the rest of the system. The watching that come to fruition. I mean, so these things boot like a rocket. They spend most of their time training DIMMs about a minute and 12 seconds to train the terabyte of DIMMs. When we come out of DIMM training, it's 20 seconds to pull the rest of the system up, 30 seconds to pull the rest of the system up. And like servers don't traditionally boot anywhere near that fast. Servers take a long time to boot. Are there any trade-offs from removing the bias that have to be factored in? The trade-off is that we are responsible for getting this thing to work. And when it, you know, that is the danger. The danger is that you, and actually when we took that path, we knew it was gonna be a steeper path and a harder path. What I did not realize was it was ultimately in the limit. It was a faster path because we controlled our own fate. It was very, very hard. And we have an extraordinary team that got very good at inhaling all documentation on the part and then some, but ultimately we were able to deliver a platform faster by having control of our own software. So that's been, that has been a decision that we have been grateful for many, many, many times over. And so I think the ability to do it, the fact that we have eliminated the BMC, replaced it with a proper service processor. It runs an operating system that we developed an all Rust operating system called Hubris, appropriately enough, because the Hubris developed an operating system. Speaking personally, the, I have spent a lot of time on the debugger for Hubris, which we call humility appropriately enough. And watching that become really load bearing for us has been a source of personal pride for me. I mean, part of what I love about the Oxide Rack is that to an employee at Oxide, everyone can look at the rack and point to an aspect of it that is theirs. And the aspect of it is like, I did that. That like the reason it behaves that way, the reason it has that decision is because of something that I did. And a lot of that stuff is like, is subtle. It's something that only an engineer really appreciates. And there are countless examples of that. And it's a lot of fun to watch that all come together. I love the aesthetics of it. The rack is, it's beautiful. And we don't really view racks as, servers are kind of like sooty and loud. And our server is beautifully quiet. We use one of the very first design decisions that we made based on some of the early folks you're talking to, including the technologist named Trammell Hudson, if you don't know Trammell, just electrifying technologist who's really been a pioneer in open systems. And Trammell said, hey, you really wanna look at what the Facebook folks did with 80 millimeter fans. They use these all our enclosures with these we bigger fans, 80 millimeter fans. And it seems like a good idea to me. And as we looked into it, it's like, yeah, that's a really good idea to get up off this one you two you kind of tyranny to get up to this, and we've got a hundred millimeter tall enclosure that fits at 80 millimeter fan. 80 millimeter fans move a lot more air and they do it with a lot less energy. So as a result, and we worked with our fan provider, Sanyu Denki, to allow our fans to operate at 2000 RPM at 0% PWM rather than 5,000 RPM, which say like when the thing is at its lowest setting, how fast is it moving? By default, that was at 5,000 RPM, that was like way more air movement than we needed. So it operates at 2000 RPM at 0% PWM. 2000 RPM is quiet. And so when you like when you're next to the oxide rack, and in fact, when we went into compliance to actually to for radiated emissions, the folks at the compliance lab, they do they see a lot of servers and they're like, are you sure it's on? Because it's so quiet. And you look at the draw and you're like, okay, no, it's definitely like, it's definitely drawing like 15 kilowatts, but it's quiet. And if you go to the back, you can feel the heat pouring off it. You're like, okay, no, it's on. It's definitely cranking. But we've become so accustomed to the violence of these 15,000 RPM fans. And they are so loud. And on the one hand, like we designed this rack to be acoustically pleasing. I mean, it's not designed, like that is not what we set out to do. But on the other hand, the acoustics of the Extant data center, the acoustics are this, it's almost like an odor. It is this visceral reminder that this domain has suffered for lack of real systemic holistic thinking. And it's- If any of it inadvertently, what I'm hearing is that you set out to deliver something that is a pleasure to work with, right? Whether it's from an acoustic level, a visually appealing level, or from the actual value that it provides by enabling elastic infrastructure to run in it fast and sort of like- Yeah, that's exactly it. And it's like, and we wanted to build something that we'd be proud of. And a foundation that we can go build on. And I think that we are- What's exciting about this is it's not, this is not the, and today's a terrific milestone with this first rack being created up. The crate, by the way, it's own engineering marble, because it's like, to ship a rack with the sled, it's been a huge amount of work from a huge number of folks. But it's like, this is not, this is very much the beginning. And we now have a platform upon which we are gonna just, like AWS circa 2006, 2007, 2008, where they really saw the ability to go build all of these additional services. We got the ability to go build a bunch of that, and be able to really deliver modernity to the on-prem operator. This is a perfect segue for the last question, actually. I know you, from other conversations you've had in the podcast and interviews and stuff, that you, for now, at least, you've discarded the HomeLab sort of like market segment. You're not gonna ship anything for that, right? For companies, you're gonna ship. So I guess, what about the new trend on GPUs and I guess, high compute requirements, services and LLMs and stuff like that. Do you see that as an opportunity for you guys to actually intervene there? Yeah, so it's super interesting. We're obviously, like everybody, we've been, the GPGPU has become very important. We needed to go solve the compute storage network problem before we tackled the GPGPU problems. So we have not tackled the GPGPU problem. This has got CPU, it's got computers, it's got networking, it's got storage. We're gonna be pretty careful about how we go into that. So honestly, we struggle to see how we can deliver real oxide value with NVIDIA. I mean, all kudos to NVIDIA, obviously, for really having the vision that's set out there. NVIDIA's a very proprietary company and that's not something that's gonna be a problem. And that's not really consistent with what we wanna go deliver. And our belief is that we at Oxide really need to take responsibility for the experience. And we can't do that when we've got a deeply proprietary partner that has its own ambitions. And ultimately, like NVIDIA, I mean, boy, the ARM acquisition had gone through, God only knows where humanity would have been led because NVIDIA has the idea of actually reproprietarizing all of compute. And it's a problem. And hey, NVIDIA, if you're listening, maybe you could experiment with truly open sourcing things instead of open sourcing a trampoline into your proprietary firmware. How about you actually open source a stack, go to truly open designs. Because I think that it makes it really hard for people to integrate in NVIDIA, NVIDIA GBGBU into a broader system and then take end to end responsibility. So I don't think it's gonna be NVIDIA. It's not impossible, but I don't think it's gonna be NVIDIA. And if it's on video, like, well, okay, who, you know. And there's some interesting folks out there that are taking some interesting swings to this problem that we are really paying very close attention to. But what we need to figure out is how do we go partner with someone to really deliver oxide value? And oxide value is the ability for the end user to have total visibility into how that infrastructure is being used, where the power is going in the system, where the heat is being generated in the system, where the performance is in the system. Because we wanna be able to make rack level decisions about where things are scheduled, where they run and provide visibility into those systems. So the operator can know that my elastic infrastructure is doing what it has set out to do. And in order to be able to deliver that kind of value to the customer, we need to have solutions that are much more open than what we have today. So paying very close attention to a bunch of different companies out there. Had a lot of very interesting conversations with folks, but for the moment that still lies in our future. Brian, I hope that lorry that left your headquarters this morning, that truck with your product was the first of many, many. And I only wish you the best of luck for Oxide. And I thank you for joining us today in this conversation. Yeah, thank you so much for having me. It's really terrific to be with you."}, "podcast_summary": "Thank you for sharing the summary of the podcast. In this episode, Brian Cantrell, the co-founder and CTO of Oxide Computer, discusses their goal of democratizing access to rack-scale technology and providing a seamless software stack for implementation. He talks about the challenges faced by companies with legacy data centers and the need for modern solutions. Oxide Computer has designed a rack-scale computer that integrates hardware and software, eliminating proprietary components and ensuring a turnkey experience for users. They have also focused on aesthetics and acoustics, creating a quiet and visually appealing rack. While they have not yet tackled the GPU market, they are paying close attention to opportunities in that space. Overall, Oxide aims to bring modernity to on-prem infrastructure and deliver a holistic and open solution to customers.", "podcast_guest": {"name": "Brian Cantrell", "org": "Oxide Computer", "title": "", "summary": "Not Available"}, "podcast_highlights": "Thank you for having me. Here are the five highlights from the podcast episode with Brian Cantrell, the co-founder and CTO of Oxide Computer. \n- \"Silicon Valley has transitioned over the years, and unfortunately, it has been corrupted by a lust for material wealth.\" \n- \"We need to shift our focus to making better use of computational resources and finding creative solutions as Moore's law reaches its limits.\" \n- \"Oxide Computer aims to bring modernity to on-prem infrastructure by providing a turnkey system that delivers elastic infrastructure out of the box.\" \n- \"Our server design eliminates biases and includes our own software stack, offering a truly integrated and controlled system.\" \n- \"We are proud of our achievements in terms of eliminating the BMC and replacing it with a service processor, as well as developing our own operating system and switching technology.\""}