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

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]

It seems that video has been posted to HN twice, but didn't attract any comments either time, sadly. I don't have the energy to watch a 90 minute talk, but some skipping around finds a bit more detail about what is in the plan: [this video] The theme seems to be giving the operator of the computer a lot more control - eliminating opaque binary blobs, exposing the hardware more directly, etc. I can't tell if this is a particular bee in the founders' bonnets, or a real market demand, or if they know about some scary threat they can't talk about. Whilst this is definitely cool, and something that will get a lot of people on HN super pumped, it doesn't sound like something any company i have worked at would really care about. Unless these machines also deliver significantly better performance. But then, those companies were not hyperscalers.

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]

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.

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.

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]