Stanford Seminar - The Soul of a New Machine: Rethinking the Computer

I think its an FPGA with a costume Open-Source Titan chip on it (RISC-V). It is not really a traditional BMC, its more like a service processor that does secure boot and gets you in the OS. It does a few other things but I think they really want it to have minimum functionality. This is a great talk about what they do and why: ▶ this video

To take these in order: for what we're doing, I would recommend the talk I gave at Stanford about a year ago.[0] It's a bit dated (and of course we have much much more detail now), but it remains broadly on point. For the parts of Sun that we want to take after: the good bits, of course! ;) There were things that have influenced us with respect to mission, and then also with respect to hardware/software co-design (we are, contrary to the impression you might have, doing a lot of hardware[1]). Lest I sound too rosy about Sun, it had a lot of problems too[2] -- so we're trying not to recreate those! ;) Thank you for the kind words on the podcast -- very much looking forward to getting back in the garage and recording some new episodes! Finally, on Spring: yes, I need to find it (we just moved) and then find a CD-ROM drive (feels easier) and then I'll get it uploaded! [0] ▶ this video [1] link [2] link

Sorry if that's a bit thin; more detail on what we're doing and why can be found in a (pre-COVID) talk I gave at Stanford[1]. We're definitely not a Deep Stealth company, but we've also been very busy building; expect many more details over the coming year! [1] ▶ this video

For whatever it's worth, the talk I gave at Stanford in February[1] goes into (much) more detail -- and given some of your other comments here, you will find many aspects of the talk educational. [1] ▶ this video

The sibling comment is good. The problem that we're trying to solve is basically laid out on this slide: ▶ this video The business is "we will be selling servers." You can't buy any yet, but in the future, you'll be able to. The talk lays out a history of servers, describes the problems with the servers that you can buy from vendors today, and lays out why we think we can build better ones.

So, I was trying to keep this post short and to the point, but if you want a longer description, straight from the mouth of one of the founders, you may like ▶ this video > Are they trying to offer folks AWS or Azure quality servers for purchase? I think "quality" doesn't really capture 100% of it, but in a sense, yes. The goal is extremely quality, performant, robust servers. I will have to delegate the details to the above talk; I have a bunch of work to get started on, and would just end up re-typing out what it says above, ha!

Oh no! I had honestly never heard of EE380 when they asked me to present[0], but I really appreciated the fact that it was (either implicitly or explicitly?) open to the public. I wish I had heard of it earlier, and sorry to see it go! [0] ▶ this video

This company was created because somebody that actually built a large could with Dell/Supermicro suffered years and years of pain. If you do as you suggest you will have to do a whole lot more, at the minimum you need to set-up (and pay) VMWare. Then you will need to figure out how you do automated firmware upgrades, low level monitoring and if security is a concern you likely want to configure secure booting with attestation and things like that. Consider how much work it is to do what you suggest, vs buying this rack. And then consider how good (and repeatable) the end result is. That is at least the theory, see: ▶ this video

Bryan Cantrill mentions in this talk that they saw no correctable errors, until they suddenly got uncorrectable errors. Turns out that the firmware was hiding the fact that it had been correcting ECC errors the whole time. ▶ this video

Coincidentally I was just watching this talk from Bryan Cantrill: ▶ this video . Around the 58 minute mark he shares an anecdote that is relevant to this thread. It boils down to him doing something where he would have written a simple bespoke balanced binary tree in C, but when writing a reimplementation in Rust used a "naive" library approach and was surprised to see a 35% speedup, which boiled down to the library using a btree instead of a balanced binary tree. This doesn't invalidate your point about there being use cases for binary trees that may necessitate you to write your own, I take you at your word that you've often had strong use cases for this, but I do think it illustrates something I believe to be true, which is that people reach for linked data structures too often, when contiguous ones are a better default.

May be instead of asking target market or audience, who are their competitors? (Edit: Previous Discussions link ) Also thinking if the Website is not finished? All the "Read More" actually hide very little information, if so why hide it? And doesn't seems to explain the company very well. Seems like we need to listen to their PodCast to find out what is going on. ( Edit: Found a Youtube Video about it ▶ this video ) >Get the most efficient power rating and network speeds of 100GBps without the pain of cable 100GBps would be impressive, 100Gbps would be ... not much? A interesting thing is all the terminal like graphics are actually HTML/CSS and not images.

So, believe it or not, we have spent quite a bit of effort trying to make this process lightweight -- and having gone through it a bunch myself (and having a strong aversion to unnecessary process!), it doesn't actually feel unduly arduous. The reason a wiki won't work for us: it's far, far too loose for describing the things we're building and discussing the trade-offs. We're a computer company[1]: we are building a ton of hardware and low-level systems software that needs to be pretty well described and carefully considered (with revisions formally tracked). It's not aerospace or biomedical devices, but... it's also not a SaaS that is amenable to an MVP. So we do need more formalism than might be suitable elsewhere. In terms of newcomers: I actually think that's a tremendous strength of the RFDs: unlike many startups, we have a lot written down -- and newcomers (and indeed, even prospective Oxide employees) are able to read the stuff that often exists in people's heads. All of that said, it's definitely not perfect! If we could get a Google docs (or equivalent) in which the underlying artifact were stored as AsciiDoc and every modification appeared as a git commit (and the comments themselves were also tracked via a git commit), that would almost assuredly be better than the GitHub + custom infrastructure we've built. But already having outrageously broad ambition, we drew the line at not reinventing design document management... ;) [1] ▶ this video