• Hmmm (unregistered)

    april frist?

  • (nodebb)

    I looked at cFS briefly a couple years ago, and pretty much everything Remy said is true. Stuff like the XML message definitions match some of my experience with software written by systems or aerospace engineers instead of by software engineers. It works, and you know that if there are any problems, it's going to fail safe, but the code tends to be a nightmare to maintain.

  • Bob the guest (unregistered)

    This was pretty darn boring. Was that the joke?

  • Naomi (unregistered) in reply to Bob the guest

    This isn't the first time Remy's posted something that's more interesting than entertaining. I, for one, appreciate the peek behind the curtain.

  • (nodebb)

    Messages also have to have a unique "Message ID", but the MID is not just an arbitrary unique number.

    Ha, that reminds me about something similar I encountered in a bank a few decades back (it was more a host related issue). They had a similar idea to encode meta data into their ID to reduce processing work on the host but when I ended up there it already devolved into chaos. For starters the size of the ID was limited, so there was an exhaustion problem. Then there were messages which didn't fit any parameter, which resulted in funny bit masks with special (aka no) meaning. In the end it provided no longer any benefits but the downsides remained. Now it would be easy to blame the original software designers over their decisions of not using generic UUIDs, but their intentions were actually good ones - however a lot of architects underestimate the scope of their solutions, aka when something becomes to popular (voluntary or involuntary, aka management mandated) and starting to get used in cases it was never intended for foreseen to be used, well, concrete architectures in practices tend to slowly fall apart in my experience.

    So interesting to see that no matter the field, no matter the company or org, the issues are always the same :-)

  • Acting up (unregistered)

    Interesting look behind the curtain. But why not just go the whole hog and use Erlang/Elixir? I can't see why one would reinvent it (poorly?) in C. Is there a bit of NIH Syndrome involved here?

  • (nodebb)

    Agree w Naomi - Thank you Remy for an interesting peek at a world I'll never otherwise see.

  • (nodebb) in reply to WTFGuy

    Likewise. Thank you, Remy. It was a fascinating read.

  • (nodebb)

    Very cool story, thank you Remy.

  • (author) in reply to Acting up

    A lot of it is safety concerns and the need for real-time operations, and well… just the entrenched tooling.

    Space is a harsh environment, and NASA has a pretty steep "tech level readiness" ladder that requires tools and tech to be gradually used before they can become mission critical, because things fail in ways you don't expect. How does the BeamVM respond to single event latchups (a cosmic ray fusing a transistor in the CPU or memory)? What scheduling guarantees can it give you? Can you run it on bare metal or an RTOS? Who else is using it? How much does your staff know about it already? What's the training requirements? How does it handle memory?

    One requirement, for example, for mission critical software (like a guidance sensor) is that it needs to be deterministic. Once you start doing heap allocations, you lose that determinism- you don't know where in memory things get allocated (or if they even do- heap allocations can fail!). Similarly, any VM language is going to put a lot of layers of complexity between you and your hardware- does every one of those layers meet all the guarantees that you need to have for safety?

    Like, I'd love to be able to spin up a BeamVM and write some wonderfully high-level code in Elixir but in addition to all the challenges of getting something ready for spaceflight, Beam specifically is bad at operations that we need to do a lot- working on large binary objects, like images. My team is mostly doing computer vision related stuff with cameras and LIDAR, and that's not something the BeamVM is optimized for.

  • Acting up (unregistered) in reply to Remy Porter

    Thanks, Remy. I suspect that Erlang would tick a lot of boxes regarding the tech readiness: it was originally intended to run on failing hardware and still do a pretty good job, there are tiiiiny BEAM implementations (e.g. AtomVM) that run as close to the metal as possible, and it's been keeping things running with ridiculous uptimes for decades. It does soft real-time rather than hard real-time, so that might be a dealbreaker. One can typically drop down to C—CAREFULLY, because if you get your C wrong, then you'll lock up BEAM!—and I've done that once or twice. It's not the greatest experience but it's okay.

    For the specific case of computer vision, I would tend to agree with you… or at least, I haven't seen Erlang commonly put to this use.

    Anyway, I appreciate the extra details and the additional peek behind the curtain 😄. Thanks!

Leave a comment on “Taking Up Space”

Log In or post as a guest

Replying to comment #:

Log Out

« Return to Article