>And you'll be down for weeks or months while they do it.

Off by a few orders of magnitude. Dell on-site SLA with pre-purchased spares was about 6 hours.

With Oxide, you'd be lucky to get same day service.

> Off by a few orders of magnitude. Dell on-site SLA with pre-purchased spares was about 6 hours.

You're talking about replacement parts. Yes Dell is good about that.

The discussion above is asking them to diagnose and fix a problem with the interaction of various hardware components (all of which come from third parties).

Oxide also has various hardware components from AMD, Intel, Samsung, etc. They are not manufacturing every component.

But they _are_ writing the firmware that runs most of them and need to understand those devices at a deep level in order to do that, unlike Dell. Dell slaps together hardware and firmware from other vendors with some high level software of their own on top. They don't do the low level firmware and thus don't understand the low level intricacies of their own systems.

No they're not unless I'm mistaken. They're not writing the firmware that runs on the NVMe drives, nor the NICs (they're not even writing the drivers for some of the NICs), etc.

There's a line in the sand that you must cross when it comes to understanding the true nature of the componentry that you're using. At the end of the day, your AMD CPUs may be lying to you, to all of us, but we just don't know it yet.

I'm not speaking hypothetically. If you hit a "zero-day" bug that Dell has never seen it's going to take time. And somehow every large customer finds bugs that Dell certification didn't.

>I'm not speaking hypothetically.

Neither am I.

>If you hit a "zero-day" bug that Dell has never seen it's going to take time.

If you hit a "zero-day" bug that Oxide has never seen it's going to take time.

>And somehow every large customer finds bugs that Dell certification didn't.

Yes, happens. And I'm sure the exact same will happen with Oxide, so it's not a differentiator.

> And somehow every large customer finds bugs that Dell certification didn't.

It's a law of computer engineering.

In the Apollo 11 decent sequence the Rendezvous Radar experienced a hardware bug[0] not uncovered during simulation. They found it later, but until then, the solution was adding a "turn off Rendezvous Radar" checklist item.

[0] The Rendezvous Radar would stop the CPU, shuttle some data into areas it could be read, and woke the CPU back up to process it. The bug caused it to supuriously do this dance just to tell it "no new data", which then caused other systems to overload.