Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

O(x)Caml in Space

gazagnaire.org

Post reply on HN
Print view View original

51–57 of 57 posts

Re: O(x)Caml in Space

#51

Post by rho_soul_kg_m3 »

ffaser5gxlsll wrote: post #35
rho_soul_kg_m3 wrote: post #12

Well, I might have been the first to put OCaml in space, specifically on low-Earth orbit aboard GHGSat-D in 2016. I designed the payload software as a collection of SystemD services talking over DBus, and it included a CCSDS-to-DBus bridge to talk to the platform (the thing that hosts the payload, controls and steers the satellite). The payload also did perform symmetric-key encryption of the resulting data, as per r…

> Today there is little reason not to use Rust and it can cover both the processing side and the payload software. But people still insist on using C/C++. I'm OK with that as long as I can invoice them. Any reason _not_ to continue using ocaml besides being less popular? If popularity/mindshare wasn't an issue, I find the development cycle with ocaml to be nicer in several ways compared to rust on a platform where st…

In general, if it works, leave it alone; but I can think of two reasons to stop using OCaml:

1) You have been ordered to directly interface with some external library that has a complicated C ABI, and you can't isolate it in a separate process and do IPC, and the FFI would be too clunky or slow.

2) You really need to manipulate lots of bits or bytes or floats very fast, or there are lots of them, and speed or memory footprint is becoming an issue. You need to multicore and/or SIMD, you need efficient abstractions, and you do that kind of thing all over the place, not just in a few functions that you separately implement in C or whatever.

As a bonus here's a good reason for NOT leaving OCaml: You can quickly bootstrap the compiler and run it on small embedded machines. I remember using OCaml on a Cyrix 686 with 64 megs I think, it was perfectly fine. Today, the lights dim a bit when I start cargo build.

Re: O(x)Caml in Space

#52

Post by rho_soul_kg_m3 »

eriangazag wrote: post #30
rho_soul_kg_m3 wrote: post #12

Well, I might have been the first to put OCaml in space, specifically on low-Earth orbit aboard GHGSat-D in 2016. I designed the payload software as a collection of SystemD services talking over DBus, and it included a CCSDS-to-DBus bridge to talk to the platform (the thing that hosts the payload, controls and steers the satellite). The payload also did perform symmetric-key encryption of the resulting data, as per r…

(author of the post here) Hey Berké! I remember your talk very well (I was in the room), super interesting and it really got me thinking about this area! Since then, the more I look into it, the more I see a fit with our MirageOS unikernel work. On the ground, you can paper over security and specialisation by throwing more machines (or money) at the problem. In orbit you cannot, so both the compile-time and the runti…

Hello :) Glad to hear the talk was useful.

You say you're using Linux as the underlying OS, but you must have looked at bare-metal embedded usage as well.

How feasible would you say it is, today, to use OCaml with MirageOS (or something similar) on a bare-metal target, say a small softcore RISCV32 with 256kB of RAM?

Re: O(x)Caml in Space

#53

Post by sheepybloke »

dsab wrote: post #6

CCSDS guides you to reinvent everything from scratch, I doubt memory safety is the biggest attack surface when you implement this stack. I dont know how big players implement networking for their satellites, but personally I would choose to fit something existing and battle-tested like TLS instead of reinventing data encryption, just look at those documents: https://www.google.com/search?client=firefox-b-lm&q=ccsds+e…

> battle-tested like TLS instead of reinventing data encryption

Working in the industry, CCSDS SDLS is quite battle tested, albeit in a different way than TLS. It's not reinventing everything from scratch; in most cases, companies have common libraries and services that they've been using since the 90's that implement the standards. I found it interesting that a lot of the CCSDS standards sound a lot like internet standards because many were developed alongside the internet standards, just targeting constrained space systems rather than ground systems.

TLS is difficult because it doesn't work well when you get to large latencies (e.g. 700ms in LEO to ~1.5s in GEO). CCSDS standards target general space systems, so they have to account for that latency.

Re: O(x)Caml in Space

#54

Post by poulpy123 »

cmrdporcupine wrote: post #39
javcasas wrote: post #29

Earlier quoted context omitted.

> the main challenge has been training developers to Ocaml and I doubt they would write new code in it now Why do I never hear about these kinds of opportunities? I have done some Ocaml, quite a bit of embedded systems, and these days I have to waste the years doing web development. Where do I have to call to be considered for doing OCaml embedded systems?

Right, I always find these kinds of statements about "we can't find talent in " a bit confusing because I personally know all kinds of people always desperate to find work in neat-lang be it Haskell, OCaml, whatever... But the opportunities never seem to be there. And it was only 3-4 years ago (maybe less) that Rust was considered by hiring managers to be in that category, too. Ask me how I know. I'm going to assume…

Probably because the requirement is not knowing ocaml but knowing how to do X, preferably in ocaml.

Re: O(x)Caml in Space

#55

Post by pjmlp »

rho_soul_kg_m3 wrote: post #51
ffaser5gxlsll wrote: post #35

Earlier quoted context omitted.

> Today there is little reason not to use Rust and it can cover both the processing side and the payload software. But people still insist on using C/C++. I'm OK with that as long as I can invoice them. Any reason _not_ to continue using ocaml besides being less popular? If popularity/mindshare wasn't an issue, I find the development cycle with ocaml to be nicer in several ways compared to rust on a platform where st…

In general, if it works, leave it alone; but I can think of two reasons to stop using OCaml: 1) You have been ordered to directly interface with some external library that has a complicated C ABI, and you can't isolate it in a separate process and do IPC, and the FFI would be too clunky or slow. 2) You really need to manipulate lots of bits or bytes or floats very fast, or there are lots of them, and speed or memory…

Given the kind of computer I had in 1996, you can even run in less, because I did so when the official name was still Objective Caml, and Caml Light was heavily used in education.

Re: O(x)Caml in Space

#56

Post by pjmlp »

noelwelsh wrote: post #33
legobmw99 wrote: post #28

Earlier quoted context omitted.

I think that’s not true; vanilla OCaml is already a competitor to Go, etc. OxCaml is explicitly an effort to compete more with Rust (the “Ox” in the name is to evoke “oxidizing” = rusting)

Agreed with this. OxCaml still requires a runtime, so it's not suitable for some applications, like embedded systems, where e.g. Rust can be used. But it certainly can be used for many of the same applications. E.g. Bun, which has been on the home page recently, could easily be written in OxCaml.

Many embedded systems use languages with runtimes, the runtime is the OS, there is nothing else underneath.

Examples, real time Java, Oberon, Pascal, BASIC Stamp, Propeller,..

Re: O(x)Caml in Space

#57

Post by pjmlp »

Maksadbek wrote: post #27

I'm not deeply familiar with reliability-focused languages, but as far as I know, Ada, Rust, and Haskell are the most prominent ones. What made OCaml a better choice here over those alternatives?

Java real time is also quite used see PTC (they are also a Ada vendor) and Aicas.
Post reply on HN