hermit VS Vale

That's been my experience as well. It lacks support for certain clone(2) flags like CLONE_VFORK[1], which limits the set of non-trivial programs it can run, and since running non-trivial programs is most of the point, I haven't revisited it since it was first announced.

[1] https://github.com/facebookexperimental/hermit/blob/bd3153b4...

A Meta developer responded to an issue of mine on Hermit, and said:

"Just to let you know we're not actively working on Hermit in the team..."

https://github.com/facebookexperimental/hermit/issues/34#iss...

I really like antithesis' approach: it's non-intrusive as all the changes are on a VM so one can run deterministic simulation without changing their code. It's also technically challenging, as making a VM suitable for deterministic simulation is not an easy feat.

On a side, I was wondering how this approach compares to Meta's Hermit(https://github.com/facebookexperimental/hermit), which is a deterministic Linux instead of a VM.

> AMA!

Eager to try it but encountering the build error here - https://github.com/facebookexperimental/hermit/issues/11

Do you have a reference build log / environment you can share? Last known good commit sha and/or output from "rustup show"?

Here is the GitHub repository: https://github.com/facebookexperimental/hermit

Not to be confused with Vale[0].

[0] https://vale.dev/

The article says they created a deterministic hypervisor that runs all pseudorandom behavior from a starting seed to enable perfect re-playability.

But that's all we know so far. I'm assuming there'll be some sort of fuzz testing, and static analysis or some defining actions that your software can perform.

Honestly it sounds a lot like it has a lot of crossover with what the Vale language is trying to solve: https://vale.dev/, but focused on trying to get existing software to that state instead of creating a new language to make new software already be at that state by default.

Why go through all the trouble when you can do this: https://www.hylo-lang.org/ and not spend a second thinking of lifetimes? No, copies will not be issued unless necessary.

Or why not keep exploring this idea as well? More research-oriented than the first one right now, though, so take it with a grain of salt: https://vale.dev/

Another relevant language might be Vale (https://vale.dev), which is aiming for "perfect replayability": https://verdagon.dev/blog/perfect-replayability-prototyped

Interesting. Very low level though and C(++) centric. She there any thoughts on combining the hardware and OS features with rust or https://vale.dev ?

Use a runtime memory management solution that's cheaper than garbage collection (see Vale)

This seems like a tool I'll be using, and this is an almost meaningless criticism, but why the name?

There's already the Vale programming language (https://vale.dev/), but moreover, I don't get the meaning of "vale". You could call it something like Englint which actually hints its purpose.