10 ms·

I'd like to add that their open source code is also EXTREMELY high quality. If you're an embedded developer go take a look at Hubris and Humility. I ended up us

I'd like to add that their open source code is also EXTREMELY high quality. If you're an embedded developer go take a look at Hubris and Humility. I ended up using those to GREAT effect for this custom one-off aerospace device and it was a fantastic experience to integrate with. Definitely a change from what I was used to that took a bit of getting used to.

throw0101c 3y ago
> I'd like to add that their open source code is also EXTREMELY high quality. * https://github.com/oxidecomputer https://github.com/oxidecomputer
- doublepg23 3y ago
  MPL even, that should satisfy about anyone who'd want to contribute.
csomar 3y ago
I agree. I stole some of their stuff from here https://github.com/oxidecomputer/third-party-api-clients/tree/main https://github.com/oxidecomputer/third-party-api-clients/tre... when I needed a SendGrid integration. High quality code and proper use of Rust types.
- jeffrallen 3y ago
  Their ring logger was really enlightening to me about the value of Rust enums. Heterogeneous log events are dropped into the ring with some holding only the fact that something happened, and others holding additional data about what happened. Then Humility is able to print out the contents of the ring either online or in crash dumps. This is how you get logging in nostdlib Rust without ending up without half of a badly implemented printf. Instead, Humility, which has the full stdlib available, formats the enums for the firmware.
  - vlovich123 3y ago
    Link?
    - mkeeter 3y ago
      The embedded side is here: https://github.com/oxidecomputer/hubris/blob/master/lib/ringbuf/src/lib.rs https://github.com/oxidecomputer/hubris/blob/master/lib/ring... And the debugger is here: https://github.com/oxidecomputer/humility/blob/master/cmd/ringbuf/src/lib.rs 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-and-post-mortem-debugging-in-a-remote-system/ https://www.osfc.io/2023/talks/unplugging-the-debugger-live-... (conference videos aren't online yet, but should be posted early next week)
behnamoh 3y ago
On a side note, I really liked their website. The ASCII animations are interesting -- wish there was a video game that had those.
- ranger207 3y ago
  Cogmind (https://www.gridsagegames.com/cogmind/ https://www.gridsagegames.com/cogmind/) has those sorts of animations
  - jefurii 3y ago
    The developer also released the ASCII art editor he used to make all those nifty designs: https://www.gridsagegames.com/rexpaint/ https://www.gridsagegames.com/rexpaint/
  - LoganDark 3y ago
    Woah , definitely going on my wishlist
  - mlindner 3y ago
    I've been interested in Cogmind for a while, unfortunately it only works on Windows (which seems an odd choice for a text-based game) so I have no ability to play it.
    - rileyphone 3y ago
      It appears to work under Proton in Linux. https://www.protondb.com/app/722730 https://www.protondb.com/app/722730
- benjaminleonard 3y ago
  They are very fun to make as well! I've built my own mini-lib on top of this ASCII rendering library (https://github.com/ertdfgcvb/play.core https://github.com/ertdfgcvb/play.core). I design them in Monodraw, pass it through a janky converter I wrote that converts text into a json grid of characters. I then render a number of layers that get combined, which is a mix of the static art layer, and others generated from functions that spit out a similar cell based frame. If you're interested: https://gist.github.com/benjaminleonard/c913ddbf23fe7a70f9c25aef0ae13496#file-projectlevelanimation-ts https://gist.github.com/benjaminleonard/c913ddbf23fe7a70f9c2... And for what it's worth there's this ASCII game: https://twitter.com/StoneStoryRPG https://twitter.com/StoneStoryRPG
throw-DO-178C 3y ago
> ... code is also EXTREMELY high quality. If you're an embedded developer go take a look at Hubris and Humility. So, Humility is like MC/DC? https://en.wikipedia.org/wiki/Modified_condition/decision_coverage https://en.wikipedia.org/wiki/Modified_condition/decision_co...
- steveklabnik 3y ago
  Humility is a debugger, not a code coverage tool.
  - acct-litter-zed 3y ago
    I think 'throw-DO-178C' was being less literal than you are assuming here. Note that they quoted the comment about extremely high quality. What gives Hubris/Humility that level of quality? When I see the concept of "extremely high quality" applied to software in the aerospace domain, I tend to think of methods like formal proofs and "semi-formal" methodologies like DO-178C (including MC/DC, not as a tool, but as a critical sub-process). It does appear that Humility adheres to some traditional ideas used in even "safety conscious", real-time embedded work: > However, Hubris may be more interesting for what it doesn't have. There are no operations for creating or destroying tasks at runtime, no dynamic resource allocation, no driver code running in privileged mode, and no C code in the system. This removes, by construction, a lot of the attack surface normally present in similar systems. [1] Oxide surely didn't invent all these concepts, we were applying some of this in the early '90s on human-safety-critical embedded projects, and they were most likely used before that. The attack surface eliminated is more than just security, e.g. even self-induced "attacks" from task priority inversion. Maybe the concept of applying them to rack mount servers is novel, but I have no experience there. Techniques like DO-178C go farther and do things like trace requirements to object code and strict coverage criteria. When you are considering where Hubris/Humility might be applied in aerospace, also note that it would most likely be denied at the proposal stage of talking to a regulatory body like the FAA if you said, "The methodology for our brake controller is cloning a Github repo written by 100X S/W engineers in the Rust language, then modding that to fit." It's a process you have to follow in a documented fashion, from the start. Who knows--I certainly don't know everything--if you do have a identify reproducible process that improves S/W quality, the FAA might be interested. And as far as eliminating debuggers goes, Boeing did actually do a joint academic/industry project on a zero-bug reduced (subset) Ada compiler (Zbra), which itself would be qualified as a tool instead of the more laborious process of mapping requirements to object code directly. [2] In the spirit of humor shown on this topic, I would suggest considering a reduced subset of Rust called Iron. :) Regards, and best of luck! [1] https://oxidecomputer.github.io/hubris/ https://oxidecomputer.github.io/hubris/ [2] http://www.sigada.org/conf/sigada2002/SIGAda2002-CDROM/SIGAda2002-Proceedings/p40-santhanam.pdf http://www.sigada.org/conf/sigada2002/SIGAda2002-CDROM/SIGAd...
danbruc 3y ago
Tangent. In my admittedly limited experience, embedded code seems to have a tendency to be some of the worst code you can come across. The stuff is already low level and not the most easy to follow, but then embedded developers seem to despise names with more than two letters and a number. Without the datasheet at hand it is impossible to figure out what any of the code does because everything is just an abbreviation or acronym from some block or pin-out diagram.
- otteromkram 3y ago
  What's the point of your comment?
teraflop 3y ago
Yeah, I just skimmed through the reference docs for Hubris and was very impressed with what I saw. No "rocket science", just (apparently) solid technical decisions that are extremely well justified and documented. https://oxidecomputer.github.io/hubris/reference/ https://oxidecomputer.github.io/hubris/reference/
- o11c 3y ago
  Some interesting rare choices there (some of which would be applicable to normal userlands or even to language VMs): * Memory access is protected, but addresses are not virtually mapped. The lack of paging of course ties strongly to the inability to dynamically add tasks. * They wish they could have read-only shared libraries (viable since there's only one address space) so they could truly be shared, but the current ecosystem assumes mutability is possible (even though in Rust mutable globals are rare).
taink 3y ago
The only big thing missing for now is their OS (or rather, their Illumos distribution), Helios[1]. Can't wait to read its source code, I was curious since reading this thread[2]. [1] https://github.com/oxidecomputer/helios https://github.com/oxidecomputer/helios (if this is not found for you, we're in the same boat) [2] https://news.ycombinator.com/item?id=33337086 https://news.ycombinator.com/item?id=33337086
cryptonector 3y ago
> their open source code is also EXTREMELY high quality I would expect nothing less from that crew. They did amazing things at Sun Microsystems, Inc. (RIP), and they continue to do even greater things now.
throwawaaarrgh 3y ago
Thought I had heard the cringiest random names for an oss project, and then...
otteromkram 3y ago
Is that the same extremely high-quality open-source code that currently has a failing build? https://github.com/oxidecomputer/hubris 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 https://github.com/oxidecomputer/humility
- bcantrill 3y ago
  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/651a9546b20ce19ce96d22446feba7c3bc41e963 https://github.com/oxidecomputer/hubris/commit/651a9546b20ce...
- mbStavola 3y ago
  If those are your complaints, I think they're probably doing okay.

throw0101c 3y ago

> I'd like to add that their open source code is also EXTREMELY high quality. * https://github.com/oxidecomputer https://github.com/oxidecomputer

doublepg23 3y ago
MPL even, that should satisfy about anyone who'd want to contribute.

csomar 3y ago

I agree. I stole some of their stuff from here https://github.com/oxidecomputer/third-party-api-clients/tree/main https://github.com/oxidecomputer/third-party-api-clients/tre... when I needed a SendGrid integration. High quality code and proper use of Rust types.

jeffrallen 3y ago
Their ring logger was really enlightening to me about the value of Rust enums. Heterogeneous log events are dropped into the ring with some holding only the fact that something happened, and others holding additional data about what happened. Then Humility is able to print out the contents of the ring either online or in crash dumps. This is how you get logging in nostdlib Rust without ending up without half of a badly implemented printf. Instead, Humility, which has the full stdlib available, formats the enums for the firmware.
- vlovich123 3y ago
  Link?
  - mkeeter 3y ago
    The embedded side is here: https://github.com/oxidecomputer/hubris/blob/master/lib/ringbuf/src/lib.rs https://github.com/oxidecomputer/hubris/blob/master/lib/ring... And the debugger is here: https://github.com/oxidecomputer/humility/blob/master/cmd/ringbuf/src/lib.rs 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-and-post-mortem-debugging-in-a-remote-system/ https://www.osfc.io/2023/talks/unplugging-the-debugger-live-... (conference videos aren't online yet, but should be posted early next week)

behnamoh 3y ago

On a side note, I really liked their website. The ASCII animations are interesting -- wish there was a video game that had those.

ranger207 3y ago
Cogmind (https://www.gridsagegames.com/cogmind/ https://www.gridsagegames.com/cogmind/) has those sorts of animations
- jefurii 3y ago
  The developer also released the ASCII art editor he used to make all those nifty designs: https://www.gridsagegames.com/rexpaint/ https://www.gridsagegames.com/rexpaint/
- LoganDark 3y ago
  Woah , definitely going on my wishlist
- mlindner 3y ago
  I've been interested in Cogmind for a while, unfortunately it only works on Windows (which seems an odd choice for a text-based game) so I have no ability to play it.
  - rileyphone 3y ago
    It appears to work under Proton in Linux. https://www.protondb.com/app/722730 https://www.protondb.com/app/722730
benjaminleonard 3y ago
They are very fun to make as well! I've built my own mini-lib on top of this ASCII rendering library (https://github.com/ertdfgcvb/play.core https://github.com/ertdfgcvb/play.core). I design them in Monodraw, pass it through a janky converter I wrote that converts text into a json grid of characters. I then render a number of layers that get combined, which is a mix of the static art layer, and others generated from functions that spit out a similar cell based frame. If you're interested: https://gist.github.com/benjaminleonard/c913ddbf23fe7a70f9c25aef0ae13496#file-projectlevelanimation-ts https://gist.github.com/benjaminleonard/c913ddbf23fe7a70f9c2... And for what it's worth there's this ASCII game: https://twitter.com/StoneStoryRPG https://twitter.com/StoneStoryRPG

throw-DO-178C 3y ago

> ... code is also EXTREMELY high quality. If you're an embedded developer go take a look at Hubris and Humility. So, Humility is like MC/DC? https://en.wikipedia.org/wiki/Modified_condition/decision_coverage https://en.wikipedia.org/wiki/Modified_condition/decision_co...

steveklabnik 3y ago
Humility is a debugger, not a code coverage tool.
- acct-litter-zed 3y ago
  I think 'throw-DO-178C' was being less literal than you are assuming here. Note that they quoted the comment about extremely high quality. What gives Hubris/Humility that level of quality? When I see the concept of "extremely high quality" applied to software in the aerospace domain, I tend to think of methods like formal proofs and "semi-formal" methodologies like DO-178C (including MC/DC, not as a tool, but as a critical sub-process). It does appear that Humility adheres to some traditional ideas used in even "safety conscious", real-time embedded work: > However, Hubris may be more interesting for what it doesn't have. There are no operations for creating or destroying tasks at runtime, no dynamic resource allocation, no driver code running in privileged mode, and no C code in the system. This removes, by construction, a lot of the attack surface normally present in similar systems. [1] Oxide surely didn't invent all these concepts, we were applying some of this in the early '90s on human-safety-critical embedded projects, and they were most likely used before that. The attack surface eliminated is more than just security, e.g. even self-induced "attacks" from task priority inversion. Maybe the concept of applying them to rack mount servers is novel, but I have no experience there. Techniques like DO-178C go farther and do things like trace requirements to object code and strict coverage criteria. When you are considering where Hubris/Humility might be applied in aerospace, also note that it would most likely be denied at the proposal stage of talking to a regulatory body like the FAA if you said, "The methodology for our brake controller is cloning a Github repo written by 100X S/W engineers in the Rust language, then modding that to fit." It's a process you have to follow in a documented fashion, from the start. Who knows--I certainly don't know everything--if you do have a identify reproducible process that improves S/W quality, the FAA might be interested. And as far as eliminating debuggers goes, Boeing did actually do a joint academic/industry project on a zero-bug reduced (subset) Ada compiler (Zbra), which itself would be qualified as a tool instead of the more laborious process of mapping requirements to object code directly. [2] In the spirit of humor shown on this topic, I would suggest considering a reduced subset of Rust called Iron. :) Regards, and best of luck! [1] https://oxidecomputer.github.io/hubris/ https://oxidecomputer.github.io/hubris/ [2] http://www.sigada.org/conf/sigada2002/SIGAda2002-CDROM/SIGAda2002-Proceedings/p40-santhanam.pdf http://www.sigada.org/conf/sigada2002/SIGAda2002-CDROM/SIGAd...

danbruc 3y ago

Tangent. In my admittedly limited experience, embedded code seems to have a tendency to be some of the worst code you can come across. The stuff is already low level and not the most easy to follow, but then embedded developers seem to despise names with more than two letters and a number. Without the datasheet at hand it is impossible to figure out what any of the code does because everything is just an abbreviation or acronym from some block or pin-out diagram.

otteromkram 3y ago
What's the point of your comment?

teraflop 3y ago

Yeah, I just skimmed through the reference docs for Hubris and was very impressed with what I saw. No "rocket science", just (apparently) solid technical decisions that are extremely well justified and documented. https://oxidecomputer.github.io/hubris/reference/ https://oxidecomputer.github.io/hubris/reference/

o11c 3y ago
Some interesting rare choices there (some of which would be applicable to normal userlands or even to language VMs): * Memory access is protected, but addresses are not virtually mapped. The lack of paging of course ties strongly to the inability to dynamically add tasks. * They wish they could have read-only shared libraries (viable since there's only one address space) so they could truly be shared, but the current ecosystem assumes mutability is possible (even though in Rust mutable globals are rare).

taink 3y ago

The only big thing missing for now is their OS (or rather, their Illumos distribution), Helios[1]. Can't wait to read its source code, I was curious since reading this thread[2]. [1] https://github.com/oxidecomputer/helios https://github.com/oxidecomputer/helios (if this is not found for you, we're in the same boat) [2] https://news.ycombinator.com/item?id=33337086 https://news.ycombinator.com/item?id=33337086

cryptonector 3y ago

> their open source code is also EXTREMELY high quality I would expect nothing less from that crew. They did amazing things at Sun Microsystems, Inc. (RIP), and they continue to do even greater things now.

throwawaaarrgh 3y ago

Thought I had heard the cringiest random names for an oss project, and then...

otteromkram 3y ago

Is that the same extremely high-quality open-source code that currently has a failing build? https://github.com/oxidecomputer/hubris 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 https://github.com/oxidecomputer/humility

bcantrill 3y ago
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/651a9546b20ce19ce96d22446feba7c3bc41e963 https://github.com/oxidecomputer/hubris/commit/651a9546b20ce...
mbStavola 3y ago
If those are your complaints, I think they're probably doing okay.