[HN Gopher] NASA Ogma: generate hard-realtime C runtime monitori...
___________________________________________________________________
NASA Ogma: generate hard-realtime C runtime monitoring applications
Author : runeks
Score : 104 points
Date : 2021-12-12 09:44 UTC (13 hours ago)
(HTM) web link (github.com)
(TXT) w3m dump (github.com)
| martini333 wrote:
| I hate Material Design with a passion. It's so off putting and
| ugly.
| black_13 wrote:
| What is ,,Material Design"?
| rad_gruchalski wrote:
| I'm looking at the list of NASA repos and thinking to myself: why
| am I still not able to follow an organization on github? It's
| almost 2022 and it's still not possible.
| [deleted]
| [deleted]
| b20000 wrote:
| rust enthousiasts arriving in 3...2...1...
| WJW wrote:
| For those without a NASA-level drone at home that still want to
| play around with generating hard-realtime C code, there is the
| excellent arduino-copilot package
| (https://hackage.haskell.org/package/arduino-copilot) that does
| exactly what the name implies. I wrote a blog post about it at
| https://wjwh.eu/posts/2020-01-30-arduino-copilot.html.
| ivanperez-keera wrote:
| +1. For those wondering what the connection is: Ogma generates
| Copilot code, which you can compile to Arduino. But you can
| also of course write Copilot code directly.
| sitkack wrote:
| Thank you for such a wonderful readme!
| i_don_t_know wrote:
| I find this space fascinating. Can you recommend books or
| other resources to learn more about hard real-time systems,
| modeling and model-checking, and hardware-in-the-loop
| testing?
| pizza wrote:
| If I recall correctly, Galois also got involved in a DARPA
| initiative a few years back (HACMS [0]) to create un-hackable
| UAVs (drones) - use the Haskell type system to produce non-
| vulnerable C code
|
| [0] https://galois.com/project/hacms-high-assurance-cyber-
| milita...
| hydroxideOH- wrote:
| Pretty cool. I didn't know there were groups using Haskell at
| NASA.
| ivanperez-keera wrote:
| AFAIK, there is only ours.
| ivanperez-keera wrote:
| I hope now that the world is coming back from the pandemic,
| we get to do conferences again. I've been missing giving
| talks. I'd love to present Ogma, and also explain what the
| challenges of using Haskell at NASA have been.
| makira wrote:
| What's the status of Rust usage inside NASA? I am currently
| writing software that, hopefully, will be sent to the Moon
| one day, and I am considering options as to software
| technologies.
| ivanperez-keera wrote:
| I do not really know. I heard that it's generally
| perceived as a good option, but I don't know if any teams
| are actively using it for any missions.
|
| My suspicion is that once it's generally accepted as part
| of the kernel, things may change.
|
| If the rust community wants rust to be used in safety-
| critical, my personal view is that they need to
| prioritize robustness and stability _of the rust
| ecosystem as a whole_ over frequent changes to the
| language or libraries to save 1-2 lines of code.
|
| Breaking changes to APIs and tool changes are a big issue
| in general, so they are best avoided (almost every time
| some introduces a breaking change that we are forced to
| adopt, we have to spend thousands of dollars (in time) to
| adapt). It's best to take longer to release a tool, but
| when you do it, make sure it'll work for a long time.
|
| We recently had this case with a tool and our project was
| delayed by several weeks because someone replaced a
| version of a tool in homebrew that introduced a breaking
| change. We hit multiple bugs during the upgrade.
|
| A mission that flies won't depend on homebrew, but it
| would be very plausible for a bug to be fixed in a
| version that pulls a dependency with a higher version
| number, and for it to be impossible or impractical to
| upgrade only one or two packages. In particular (and I
| don't "speak" rust), if your compiler comes with core
| libraries that necessarily need a version of the compiler
| to work, you want those to be de-coupled and the core API
| not to change.
|
| Please be aware that this is just my personal opinion. I
| don't speak on behalf of any agencies.
| vlovich123 wrote:
| Not sure if you're aware but in Rust there's no
| dependency hell. Component A can depend on version X of a
| library and component B can depend on incompatible
| version Y and you can still link in components A & B into
| your program without any hassle/correctness/safety
| issues. That doesn't solve the "but I want to upgrade to
| the latest version & for it to be compatible" but that's
| typically an untenable position in any environment when
| relying on OSS - perhaps try to work out arrangements
| with those projects if possible to backport fixes instead
| if it's that mission critical or live with developing
| processes to stay on top of updates like the rest of us?
| ivanperez-keera wrote:
| One day I'll learn rust and maybe then I'll understand.
|
| > live with developing processes to stay on top of
| updates like the rest of us?
|
| NASA follows very robust software engineering processes
| (even for research projects like e.g., Copilot and, to a
| lesser extend, Ogma). It would not be able to do what it
| does if it didn't.
|
| This is a topic for a longer discussion and definitely
| not to be had here, but I will say that it's not
| conductive to a constructive discussion to see it as a
| problem with our processes, or us ("developing processes
| to stay on top of updates", "like the rest of us").
|
| The people who work on these things are smart. This is a
| topic we've had long discussions on. If it was obvious or
| viable to fix internally, we would have done it already.
|
| I have been programming in particular in Haskell for 20y.
| I've worked for all kinds of companies and organizations,
| big and small, for the last 18y. I am like the rest of
| us. The problem is not exclusive to NASA, and NASA's
| processes are not to blame here.
|
| It's a problem with how to build languages and
| ecosystems.
| [deleted]
| ComputerGuru wrote:
| Specifically regarding this point:
|
| > Breaking changes to APIs and tool changes are a big
| issue in general, so they are best avoided
|
| There seem to be two different camps in the rust world.
| Any crates that have to do with web (orthogonal to but
| not distinct from async) or _some_ GUI-related aspects
| seem to be constantly breaking in major ways between
| releases, way too often to actually keep up with.
| Anything else in the rust world, such that someone coming
| from a traditional C /C++ background would be interacting
| with, has a much more mature ecosystem around it w/ saner
| breakage (i.e. only when/where necessary and typically
| only changing a name or restructuring a type, but not
| "let's wholly rearchitecture both our own code and the
| code of anyone using this in the wild" kind of thing).
| makira wrote:
| Thanks Ivan, makes sense. With the ongoing work of
| integrating Rust into Linux, I hope we'll see some of
| that sought-after stability in its tooling. I appreciate
| the insight - I also wish more code was written with long
| term in mind, and by long term, I mean decades, not
| years.
| ivanperez-keera wrote:
| This has been my issue too, and for a long time.
|
| I've been betting on creating good software that survives
| for decades, but most people just want quick fixes and
| new features, and few are willing to put in the time to
| "do the homework" (that is, clean up the code, debug it,
| benchmark it, reduce it, modularize it, etc.). Over time,
| with more and more fixes and features, code rots and the
| maintenance burden increases.
|
| People seem to be creating open source like it's free,
| with no regards for the time and effort put before. Every
| solution we create adds to the global maintenance burden
| of the community. We need to set processes in place that
| make open source code better over time, not bigger.
| [deleted]
___________________________________________________________________
(page generated 2021-12-12 23:01 UTC)