carnet VS moveit

These kinds of problems affect all software in all programming languages. At the end of the day, you have to have your build process and testing sandboxed if you can't afford to review every dependency update. Companies who have strict policies about this can host their own internal Crates.io mirror so internal projects can only rely on audited crates. For Rust, Carnet is a wrapper for Cargo which sandboxes builds with bubblewrap on Linux.

(Shameless plug) I wrote carnet exactly for this reason. It's a small bash script that isolates cargo using namespaces/cgroups. It can't normalize system time (yet?) but I always use it when I work with Rust.

You can also see https://github.com/google/moveit as a crate for solving problems like this right now, with this conference talk from the author.

There's actually a direct mention of that in my post already, but it's all the way near the bottom in the "Weakening non-moveability" section. It probably goes a bit too far to link in the intro, so I inlined a quick definition as relative clause there instead.

The `moveit` library is interesting also because it would allow pinning containers to expose a wider mutable API, though there's currently no trait to update instances post-move, which would allow `realloc` use. I filed an issue for it about a week ago: https://github.com/google/moveit/issues/26

That still leaves the issue of callback targets though, which would have to be notified before a possible move to support one-step reallocation.