hubris

With respect to Hubris, the build badge was, in turns out, pointing to a stale workflow. (That is, the build was succeeding, but the build badge was busted.) This comment has been immortalized in the fix.[0] With respect to Humility, I am going to resist the temptation of pointing out why one of those directories has a different nomenclature with respect to its delimiter -- and just leave it at this: if you really want to find some filthy code in Humility, you can do much, much better than that! [0] https://github.com/oxidecomputer/hubris/commit/651a9546b20ce...

Is that the same extremely high-quality open-source code that currently has a failing build? https://github.com/oxidecomputer/hubris And, that one underscore-delimited folder name in this repo just catches the eye, huh? https://github.com/oxidecomputer/humility

The embedded side is here: https://github.com/oxidecomputer/hubris/blob/master/lib/ring... And the debugger is here: https://github.com/oxidecomputer/humility/blob/master/cmd/ri... I also gave a talk at this year's Open Source Firmware Conference that covers a bunch of debug strategies: https://www.osfc.io/2023/talks/unplugging-the-debugger-live-... (conference videos aren't online yet, but should be posted early next week)

A lot of questions in there! Taking these in order: 1. We aren't making standalone servers: the Oxide compute sled comes in the Oxide rack. So are not (and do not intend to be) a drop in replacement for extant rack mounted servers. 2. We have taken a fundamentally different approach to firmware, with a true root of trust that can attest to the service processor -- which can turn attest to the system software. This prompts a lot of questions (e.g., who attests to the root of trust?), and there is a LOT to say about this; look for us to talk a lot more about this 3. In stark contrast (sadly) to nearly everyone else in the server space, the firmware we are developing is entirely open source. More details on that can be found in Cliff Biffle's 2021 OSFC talk and the Hubris and Humility repos.[0][1][2] 4. Definitely not vaporware! We are in

The day I started (time ago) to learn Rust I had trouble learning to map Error(s) and dynamic dispatching. My first thought was: "if I cannot escape dynamic dispatching (for example with crates that use it), I will never understand how to use Rust in embedded, because of Box<T>". And as an embedded C developer, this is something I never understood. For example: "Values can be boxed (allocated on the heap) by creating a Box<T>" (https://doc.rust-lang.org/rust-by-example/std/box.html) But then I see Box<dyn std::error::Error> everywhere, for example in https://github.com/oxidecomputer/hubris/search?q=dyn Is Box really allocating here? Is the "Rust By Example" text incomplete? Then I had to stop learning Rust for other reasons, but this doubt really hit me at the time.

Way out of my depth! However, the stuff I saw the folks from Oxide [1] talk about comes to mind. Hardware stuff with Rust. If you want to look at a specific project, Hubris [2] is a kernel for "deeply-embedded" systems. [1] https://oxide.computer/blog/building-big-systems-with-remote... [2] https://github.com/oxidecomputer/hubris

For someone doing related work in the open (and least remarkably in the open), Oxide Computer told some storied about the difficulty of bring up of a new motherboard, and mentioned a lot of gotcha details and hack solutions for managing their AMD chip. They talked about their bring up sequence, boot chain verification on their motherboard, and designing / creating / verifying their hardware root of trust. I heard mention of this on a podcast recently, trying to find the reference. I'm pretty sure it was [S3] - "Tales from the Bringup Lab" https://lnns.co/FBf5oLpyHK3 - or "More Tales from the Bringup Lab" https://lnns.co/LQur_ToJX9m But I found again these interesting things worth sharing on that search. - https://oxide.computer/blog/hubris-and-humility, see https://github.com/oxidecomputer/hubris as some of their key enabling software/fir

> New C/C++/asm based hobby kernels are started (and abandoned) everyday on /r/osdev. Nowhere near as many in Rust by a wide margin. Instead the Rust community seems to have placed all their bets on an "outside in" rewrite of the Linux kernel in Rust. While I think this may well be great for Linux in the long term, its a little dissapointing that there is not more momentum for "from scratch" projects yet. Even Linux started as "as hobby, not big and professional like GNU". Which leads to my next point ... I think you may just be not looking where the rust people are posting. All you're really saying is that they aren't on /r/osdev, and frankly I don't find that surprising. Here are some of the more flagship projects The biggest rust kernel/os project I'm aware of is https://www.redox-os.org/ It's a bit out of date by now, but this is an e

When we started the company, we knew it would be a three year build -- and indeed, our first product is in the final stages of development (i.e. EMC/safety certification). We have been very transparent about our progress along the way[0][1][2][3][4][5][6][7] -- and our software is essentially all open source, so you can follow along there as well.[8][9][10] If you are asking "does anyone want a rack-scale computer?" the (short) answer is: yes, they do. The on-prem market has been woefully underserved -- and there are plenty of folks who are sick of Dell/HPE/VMware/Cisco, to say nothing of those who are public cloud borne and wondering if they should perhaps own some of their own compute rather than rent it all. [0] https://oxide-and-friends.transistor.fm/episodes/holistic-bo... [1] https://oxide-and-friends.transistor.fm/episodes/the-oxid