Nothing has changed with regards to our anti-blob and pro-open source stances. I am not sure what you're referring to here.
> with unnecessary lock-in.
What lock-in are you referring to here? The way that things run on the rack is via virtual machines, you can run virtual machines on many providers. We even have a terraform provider so that you can use familiar tools instead of the API directly, if you believe that is lock-in (and that stuff is all also fully open source).
To be clearer regarding my questions:
- What happened to Project X (supposedly coreboot++ for latest AMD CPUs)? It seems dead, despite being more reported on than Oxide's attempts in working with AMD (to achieve the same outcomes, presumably - what's the difference?). Loads of well meaning people have approached this with virtue, innocence and skills; perhaps another approach is needed that fully respects the dynamic between the user, the chip manufacturers and the governments and banks they're in debt to.
- Does Oxide attempt to sandbox, completely remove or 'verify as benign' aspects like the PSP? For example, if someone could verify that the PSP cannot possibly be affected over the network, then peace of mind could be more affordable regarding things like supply chain attacks and bad actors with AMD/Intel/Apple management engine secrets.
Not referring to software lock-in, just hardware. And it isn't very nefarious like other hardware lock-in (serialization, see Rossmann Group). Just hardware on the rack-level: replacing oxide gear & upgrading oxide gear (not sure about repair, that could be easy). And if the offering were of a less blobby architecture, then many of us would be happy to pay a bit more for the hardware as a system. However, if the hardware platform is FOSS, then it won't be unnecessarily difficult to mix and match and integrate the Oxide gear with other DC-class gear.
> What happened to Project X (supposedly coreboot++ for latest AMD CPUs)?
I don't recall what you're referring to specifically, maybe this was a thing before I started at Oxide. I do know that we deliberately decided to not go with coreboot. I believe the equivalent component would be phbl[1]. It boots illumos directly. Bryan gave a talk about how we boot[1][2] with more reasoning and context.
> Does Oxide attempt to sandbox, completely remove or 'verify as benign' aspects like the PSP?
The general attitude is still "remove or work around every binary blob possible," but the PSP is unfortunately not able to be worked around.
> However, if the hardware platform is FOSS
We fully intend to do this, by the way. Just haven't yet. It'll come.
1: https://github.com/oxidecomputer/phbl
2: https://www.osfc.io/2022/talks/i-have-come-to-bury-the-bios-...
This seems to make no mention of Oxide at all. Perhaps you're connecting two different unrelated organizations together as Oxide appears to have never had any relation to it. I think you're just perhaps confused about what the situation is.