That logo design though, 🔥 fire fire fire

So then we shall propose to let them in at our own terms ?

That’s quite reasonable to me, and less radical in my humble opinion.

But I also see how one may arrive at such a conclusion, as all parties may not be as welling to accept such terms and conditions, or even be able to make such terms and conditions enforceable.

One instance may accept favours from meta, and then it spreads out uncontrollably… And then … Its gets more complex.

Perhaps the safest option is to limit their present shares to a maximum of 40% in our servers. That is, they cannot be allowed to have more than a set amount of API exposure to the feeds - and they must allow us to reciprocate, like wise, by being able to have access to theirs by more than 40%. The value of assets can surely be established and estimated par costs of maintenance and OA, etc…

There are teachings I have read/ discovered through YouTube (can’t remember exactly where) about the reasons and the philosophy behind moving to docker, or having it as a state machine.

Have you considered looking into dockers alternatives, also ?

Here is 1 of the sources that may give you insights:

https://www.cloudzero.com/blog/docker-alternatives/

– There has been some concerns over docker’s licensing and, as such, some people have started preferring solutions such as podman and containerd.

Both are good in terms of compatibility and usability, however I have not used them extensively.

Nonetheless, I am currently using docker for my own hyperserver [Edit2: oops, I meant hypervisor ✓, not hyperserver] purposes. And I am also a little concerned about the future of docker, and would consider changing sometime in the future.

[Edit1: I am using docker because it is easy to make custom machines, with all files configurations, and deploy them that way. It is a time saver. But performance wise, I would not recommend it for major machines that contain major machine processes and services. And that’s just the gist of it].