I have not been able to find a clear objective---beyond slowing the progress on various AI fronts---and how that achieves an end-goal towards safer AI.

They mention things like "limits through compute thresholds (FLOP caps)" which seems extremely hand-wavy to me. What does that achieve and how do you enforce only "negative" use-cases of AI being a target of such policies? The same compute is used for non-AI workloads, along with plenty of useful advancements as a result of AI. The lines between general scientific work in numerous tangential fields (e.g., computer architecture) and how it impacts AI is blurring fast, but that does not mean (at least to me) that those fields should also be subject to an outright blockade.

I completely understand and support the need for researchers and practitioners to come together, ensure net-positive outcomes from AI progress and minimize the steep cost (e.g., environmental). I want to understand how this movement in particular (i.e., their demands, vision, plan) brings us closer to that end-goal?

Good luck preventing distillation and limiting the supply of accelerators to China when Jensen himself is a strong opponent of any such barriers [1].

[1] https://youtu.be/Hrbq66XqtCo?si=VJh2QjOzkqT3iMjl&t=3456

There are a few cases where `dlmopen` has issues, for example, some libraries are written with the assumption that there will only be one of them in the process (their use of globals/thread local variables etc.) which may result in conflicts across namespaces.

Specifically, `libpthread` has one such issue [1] where `pthread_key_create` will create duplicate keys in separate namespaces. But these keys are later used to index into `THREAD_SELF->specific_1stblock` which is shared between all namespaces, which can cause all sorts of weird issues.

There is a (relatively old, unmerged) patch to glibc where you can specify some libraries to be shared across namespaces [2].

[1]: https://sourceware.org/bugzilla/show_bug.cgi?id=24776#c13

[2]: https://patchwork.ozlabs.org/project/glibc/patch/20211010163...

I believe you can do that with `dlmopen` in separate link maps. I have worked with multiple completely isolated Python interpreters in the same process that do not share a GIL using that approach.

I have also been working on running multiple Python interpreters in the same process by isolating them in different namespaces using `dlmopen` [1]. The objective on a high level is to receive requests for some compute intensive operations from a TCP/HTTP server and dispatch them on to different workers. In this case, a thin C++ shim receives the requests and dispatches them on to one of the Python interpreters in a namespace. This eliminates contention for the GIL amongst the interpreters and can exploit parallelism by running each interpreter on a different set of cores. The data obtained from the request does not need to be copied into the interpreter because everything is in the same address space; similarly the output produced by the Python interpreter is also just passed back without any copies to the server.

[1] https://www.man7.org/linux/man-pages/man3/dlmopen.3.html