Podcast Summary: The Pragmatic Engineer

Episode: The history of servers, the cloud, and what’s next – with Oxide
Host: Gergely Orosz
Guest: Bryan Cantrill (Co-founder, Oxide; former Sun Microsystems, Joyent)
Date: December 17, 2025

Overview

In this episode, Gergely Orosz is joined by Bryan Cantrill, for an in-depth conversation about the history and evolution of server infrastructure—from the dot-com boom in the 1990s, through the rise of cloud computing, to Oxide’s mission to rethink hardware and software for modern data centers. They discuss lessons learned from industry cycles, innovation in hard times, cloud economics, hardware startup challenges, the open-source stack at Oxide, nuanced uses for AI tools, and advice for engineers in a rapidly changing field.

Audience: Especially valuable for software engineers, hardware engineers, and engineering leaders interested in infrastructure, cloud, and startup culture.

Key Discussion Points & Insights

1. Dot-Com Boom, Bust, and Innovation (00:01–17:44)

• Energy of the 1990s: The early internet (HTTP was brand new, Java just released) was a time of intense optimism and “frothy” growth in Silicon Valley.
  • “The energy was extraordinary. And really knew that I wanted to come out here for my career.” (Bryan, 01:46)
• Sun Microsystems at the Center: Sun’s hardware & Solaris OS were must-haves for anyone building web infrastructure.
  • “If you wanted to build a website as part of that dot-com boom, you were buying Sun servers, you were buying Cisco Switches.” (Bryan, 02:39)
• State of Servers & OS: PCs were insufficient: Linux wasn’t mature, FreeBSD was under legal cloud, and open-source options like GNU Hurd were perpetually not ready.
  • “You couldn’t do it on PCs because of the lack of system software.” (Bryan, 03:25)
• Dot-Com Mania (and its Flaws): The era was full of egos and unfounded confidence, with little room for focus or desperate innovation.
  • “Everyone kind of secretly believes that this is because of me... But that doesn’t really lend itself to real innovation.” (Bryan, 05:48)
• Boom to Bust: When the bubble burst in 2000–2001, money & jobs disappeared almost overnight, but the bust forced necessary focus and led to deeper technical innovations (ZFS, DTrace, service manageability).
  • “We did much more technically interesting work in the bust than we did in the boom... innovation requires some level of desperation.” (Bryan, 00:01 & 05:48)
  • “Layoff after layoff... but those who [cared about technology itself] all stayed.” (Bryan, 14:09)

2. Shifts in Hardware & Software—Rise of Open Source (17:44–25:06)

• Linux Matures; Open Source Wins: By early 2000s, Linux, OpenBSD, open-sourced Solaris, and affordable x86 hardware democratized access to infrastructure, enabling the next wave of big tech.
  • “The companies that became that next boom were all built on open source and indeed needed to be built on open source.” (Bryan, 18:16)
• End of RISC Dominance: SPARC and other RISC processors lost to x86 in terms of price/performance; hardware commoditization accelerated.
  • “If you want a leading edge microprocessor, it’s x86. So that was a big and important shift.” (Bryan, 19:20)
• Birth of Public Cloud: AWS emerges, followed by Google Cloud and Azure, changing industry economics and deployment workflows.
  • “People are like, why would I even screw around on the server at all? It was so great to be able to just spin up infrastructure.” (Bryan, 21:13)

3. Cloud Wars & Emergence of Cloud Neutrality (25:06–34:39)

• AWS Execution: 2010–2014, AWS dominated, making life hard for competitors with relentless price cuts and new service launches.
• GCP and Azure Struggle: Early GCP was “almost a joke” and Azure lagged behind.
• Role of Kubernetes: Containerization and Kubernetes provided a path toward cloud neutrality (multi-cloud adoption), diminishing AWS lock-in.
  • “Multi cloud didn’t really exist, I would say, before Kubernetes.” (Bryan, 28:43)
  • “Part of that initial attraction to Kubernetes is that people wanted to get some optionality around their cloud.” (Bryan, 29:00)
• Quote: “If you want to be in the cloud, you have to implement every AWS API.” (Bryan, 27:22)

4. Hyperscale Hardware: Custom Design as Norm (34:39–42:07)

• Big Tech Building Their Own Hardware: Google and Meta never truly bought servers from Dell/HP; from day one, they custom-built for scale.
  • “They never were [buyers of off-the-shelf servers]... by that point in time, the business was established enough that they built the machines that were fit for scale.” (Bryan, 31:08)
• Internal Tools: These companies also developed world-class internal software (deployment, analytics, feature flags) most companies can’t replicate in-house.

5. Rethinking the Server: Oxide’s Approach (38:00–47:46)

• From Joyent to Oxide: Post-Joyent/Samsung, Bryan and team saw a gap: companies should be able to own cloud-like infrastructure, not just rent it.
  • “Cloud computing is the future of all computing... But you shouldn’t be able to only rent that.” (Bryan, 35:47)
• Eliminating Technical Debt: Oxide approaches server/rack design from first principles, not legacy “PC server” constraints (like power, network cabling, board design).
• Notable Innovation: “Blind mating” of both power and networking, factory-cabled—no more manual cabling, greatly improves reliability.
  • “There’s no cabling in the system at all. When you’ve got a sled, you are blind-mating into a cabled backplane.” (Bryan, 40:57)
• Designing a Switch: Building their own programmable switch (Intel Tofino) gave Oxide greater integration, reliability, and made other innovations (like blind-mated networking) achievable.
  • “We did our own de novo operating system in Rust, appropriately called Hubris because we had the hubris to do it. The debugger... is called Humility.” (Bryan, 54:28)
  • “If we didn’t do our own switch, it would be a third party integration nightmare.” (Bryan, 42:28)

6. Building Hardware from Scratch (45:22–51:05)

• Complexity & Talent: Real server design requires deep expertise (e.g., high-speed digital, RF, power sequencing), not just “connecting parts.”
  • On legacy reference designs: “Harder to find folks that were willing to take a clean sheet of paper.” (Bryan, 48:15)
• Team Diversity: Sourcing engineers from medical device backgrounds brought vital fresh approaches compared to traditional PC hardware engineers.

7. Radical Transparency & Company Culture (50:09–53:59)

• Open Salaries and Compensation: Oxide pays all employees the same (including support engineers). This policy attracted talent who resonated with Oxide’s values.
  • “Our compensation is transparent and uniform… it was the compensation that convinced people that we take our values really seriously.” (Bryan, 52:21)
• Support Engineers: High pay for support engineers means “you get people for whom support is a calling... I think we’ve got the best support engineers in the business.” (Bryan, 53:13)

8. The Oxide Software Stack & Shipping (54:28–61:07)

• Open Source Everything: Entire stack from service processor (Rust OS “Hubris”), to host OS (custom hypervisor, control plane), to UX—fully open.
  • “Everything we’ve done is open source... The best way to run this is on the machines that we make.” (Bryan, 54:47)
• Distributed System Challenges: Updating software in a distributed, remote, customer-owned environment (with air gaps/security)—far harder than single-node or SaaS.
  • “One of the very, very thorny problems was how do we ship a distributed system that we can then update?” (Bryan, 58:17)
• Talk Recommendation: Dave Pacheco's presentation on two years of 'update' at Oxide is cited as an extraordinary talk on real-world distributed systems. ([59:14])

9. AI Tools: Pro, Con, and Reality (63:07–77:36)

• How Oxide Uses AI/LLMs:
  • Non-code use cases: Summarizing company docs, generating glossaries, as editorial aid.
  • Small-code use: “Is this idiomatic Rust?”-style help, generating boilerplate, test cases.
  • Low value for deep or novel engineering: “No part of the Oxide stack is vibe coded... It is helpful as a polishing tool, but less at the epicenter of its creation.” (Bryan, 74:20)
  • Hardware design: “Absolutely zero help for hardware engineering. 0.01 if I’m generous.” (Bryan, 75:54)
  • Notable quote: “Building a board is not an IQ test. You need more than intelligence. LLMs are not going to help you debug obscure power-sequencing bugs.” (Bryan, 69:11)
• AI & Teamwork: True breakthroughs often require collective, creative problem-solving — and a roomful of panicked, desperate engineers.
• Prompt ≠ Goal: Real engineering requires goals, teamwork, and resourcefulness—none of which LLMs possess.

10. Remote & Hybrid Team Building (77:53–84:07)

• Team Size & Recruitment: ~85 people, highly diverse, rigorous hiring with a strong culture fit focus.
• Remote Hardware Startup: Much of the engineering (design, simulation, layout, EDA tools) is possible remotely; actual bring-up/fab requires some travel (Minnesota).
• Quote: “We put a beacon out there...People drawn to the company that would be so nuts as to do that [equal pay].” (Bryan, 51:05)

11. Culture, Growth and Sustaining Quality (84:33–87:31)

• Scaling While Staying True: As Oxide grows, discipline in hiring and focus on core values are vital.
  • “Oxide’s culture is important to every single person at Oxide. That’s what it takes to really preserve that.” (Bryan, 84:48)
• Company Parties Analogy: Mixing disciplines and unexpected crossovers creates vibrancy and creativity.

12. Advice for Engineers: Tools and Mindsets (87:31–94:02)

• AI as a Tool, Not a Threat: LLMs will accelerate productivity, but won’t “replace all jobs.”
  • “We actually need to get back to putting the tools in the toolbox of the human that’s building it.” (Bryan, 87:59)
• Younger Engineers: Focus on Learning by Doing
  • “You need to have a mindset towards getting better everyday... There’s so much to learn out there.” (Bryan, 91:32)
  • View LLMs as “private coaches or tutors”—but always verify their output.

Notable Quotes & Moments

• [00:01] “We did much more technically interesting work in the bust than we did in the boom. I think that innovation requires some level of desperation.”
• [05:48] “If I work on the microprocessor, it’s because the microprocessor is perfect. If I work on the operating system, it’s because people are buying the machine for the operating system. That doesn’t really lend itself to real innovation.”
• [14:09] “The people that had moved to Silicon Valley for the technology all stayed—and we did better technical work in the bust than in the boom.”
• [18:16] “Google was always built on Linux. You had to be built on open source.”
• [29:00] “Part of that early momentum behind Kubernetes was this idea: I want to get some optionality in here.”
• [31:08] “Google and Meta never were [off-the-shelf server buyers]—they built the machines that were fit for scale.”
• [40:57] “There’s no cabling in the system at all... You are blind-mating into a cabled backplane.”
• [52:21] “Our compensation is transparent and uniform. It was the compensation that convinced people that we take our values really seriously.”
• [54:28] “We did our own de novo operating system in Rust, appropriately called Hubris because we had the hubris to do it. The debugger is called Humility.”
• [58:17] “One of the very thorny problems: how do we ship a distributed system that we can then update?”
• [69:11] “Building a board is not an IQ test. Intelligence is not enough. You need these other kinds of characteristics.”
• [75:54] “No, [LLMs are] zero help for hardware engineering. 0.01 if I’m being generous.”
• [87:59] “This is going to allow us all to do more... AI tools have become much more powerful—it’s a tool, not the only tool.”
• [91:32] “You want to play major league baseball? You need to get better every day... You need to really focus on self-improvement.”

Timestamps for Important Segments

• 00:01 – Dot-com boom/bust: innovation under pressure
• 05:48 – Lack of focus/real innovation during "frothy" times
• 13:21 – Impact of the bust; technical team’s resilience
• 17:44 – Linux & open source disrupt the status quo
• 19:20 – x86 overtakes proprietary microprocessors
• 21:13 – Rise of AWS and cloud model
• 29:00 – Kubernetes and the promise of cloud neutrality
• 34:39 – Why hyperscalers design their own hardware
• 40:57 – Oxide’s “blind mating” hardware innovation
• 51:05 – Radical transparency and recruiting at Oxide
• 54:28 – The fully open-source Oxide stack; OS “Hubris”
• 58:17 – Distributed system update challenges; Dave Pacheco’s “update” talk
• 63:07 – Realistic (and limited) role of AI/LLMs in engineering
• 75:54 – LLMs: basically no use in hardware engineering
• 84:48 – How Oxide maintains culture while scaling
• 87:59 – The future: AI as tool; opportunity outweighs doomerism
• 91:32 – Advice to junior engineers: focus on getting better

Book Recommendations (Bryan Cantrill, [94:02])

1. Soul of a New Machine by Tracy Kidder
   • Pulitzer-winning story of a hardware engineering team under pressure.
   • “Every engineer will see something of themselves in that book.”
2. Skunk Works by Ben Rich
   • The real story of engineering the near-impossible at Lockheed’s famed Skunk Works.
3. Steve Jobs and the Next Big Thing by Randall Stross
   • Focuses on Jobs’s wilderness years at NeXT—failure essential to his success at Apple.

Conclusion & Overall Tone

Bryan Cantrill is candid, technically deep, and animated—offering both practical details and industry meta-lessons. The conversation moves fluidly from war stories of the '90s, to the nuts-and-bolts (and philosophy) of modern hardware, to the realities of AI engineering and what’s left to human creativity. Oxide’s radical openness, hardware-first principles, and unconventional approach to company culture make it a beacon for ambitious engineers.

Summary Verdict:
For engineers hungry to understand both history and future of infrastructure (and the human factors that shape both), this rich episode provides not just a window into technical evolution, but a strong dose of inspiration for building and learning in a changing era.

For further resources & Oxide deep-dive:
Check the show notes and pragmaticengineer.com.