Thank you for your response. So time as you mentioned can be made explicit.
I am probably looking for something like the request context with timers and cancellation signals propagating through the call chain like in gRPC but more fine granular.
So you could implement arbitrary response times of functions. So you could say like:
This whole request must finish in 5 seconds, otherwise abort.
And these 5 seconds can be made very low so that you reach latency of NUMA vs Single CPU.
I don't know how you call this, maybe "latency budget"
Side question as I am following zig only losely and do Go Programming:
Zig has the feature that you can drop in your allocator from the caller. Now with 0.16 you also "bring your own IO" implementation with you.
And for my understanding this looks like the pattern Go uses with its Context package, where you pass in transitive data, cancellation signals and timers to for example stop an SQL query in server B, since a user canceled a web request in their browser before hitting server A, whilst all elements delegate the Context.
Then yesterday was total unrelated article about NUMA architecture, and I remember somewhere that the creator of Erlang mentioned (Joe Armstrong) that you cannot get around physics and it takes time to call a function between servers, therefore so not try to hide the latency between the calls.
And now to my question:
Would that in any way make sense for zig to go even more in this direction, where you pass in your allocator, IO, but now with something similar to Google Go context, but have it even more fine grained?
So that your functions could actually in their interface expose somehow the time in between CPU cores (NUMA) up to the request cancellation as Google go context is used for timeout signals, cancellation signals.
Also probably making time an external dependency as well.
So in essence , every function would be treated as a remote procedure calls, whereas remote would mean: "other cpu", other server/service
regarding …“One was the realization that a purely mechanical computer can, in principle simulate the laws …“
As far as I unterstood,there is no theory of quantum gravity and therefore this is not being simulated on a computer.
I think he makes other arguments.
So you cannot say for sure that you can simulate a human brain on a computer
I was thinking of people were to use an image…:$my_tag on the host cluster and some roughe pod on the child cluster (but same underlying physical nodes) somehow overwriting the local cached :my_tag, you could do something on the parent cluster.
But I don’t fully understand what you meant with content adressed :)
Maybe one has to ensure in the host cluster that the image pull policy is set to Always or all references to images have to be based on the shasum rather than Tags.
I understood from the host cluster perspective you won’t see the child cluster pods.
And what is the perspective on nodes?
Can you have like a host cluster spawning on host nodes and the host cluster has control over spawning separate physical nodes which contain the child cluster (api server) + workload pods ?
I don’t understand how they are separating security in the virtual mode as they only mention pods. It seems every workload still shares the underlying node, even when in virtual mode.
Take for example the OCI cache on the nodes. What about cache poisoning?
Maybe for your personal workstation this might be the experience you have.
But from my experience for enterprise there is RHEL, Suse and maybe Ubuntu Pro.
If you are an AWS Enterprise customer you might justify Amazon Linux
Love what they are doing. At least you get the chance to introduce Nix in the enterprise with the MacOS installer, having figured out private CAs and the MacOS keychain for example. Then MDM.
There is a bit of a pattern emerging, where you add a „tools“ packages and this tools package just contains blank _ imports to external Go tools you use (e.g. gometalinter)
This way when you run god mod vendor, you will also be able to vendor your tools and build them locally from your repo.
This works quite well with a Makefile for now. There is an open issue tracking this vendor-tools approach
I am probably looking for something like the request context with timers and cancellation signals propagating through the call chain like in gRPC but more fine granular.
So you could implement arbitrary response times of functions. So you could say like:
This whole request must finish in 5 seconds, otherwise abort.
And these 5 seconds can be made very low so that you reach latency of NUMA vs Single CPU.
I don't know how you call this, maybe "latency budget"