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
I was quite happy and entlohntes when I dropped an HTML table Formates with Emojies into my prompt and told to turn it into a terraform module.
But how do you quality check this part? I am proofreading all these transformations and I am not sure if this is really faster than actually recording a VIM macro, which will do the steps I need.
Love it. Also using UTM with Amazon Linux 2023 x64 on an M1 works, so you can create a local HashiCorp Packer Pipeline using the Packer UTM plugin (similar to the QEMU Packer plugin)
From the Enterprise Perspektive at least for my use cases(fine grained permissions using extra id) , elasticsearch with kibana always had a solution available.
For grafana cloud and Loki you can close to a good usability with LBAC (label based access control) but you still need have many data sources to map onto each “team view” to make it user friendly.
What is missing for me is like in elastic a single datasource for all logs which every team member across all teams can see and you scope out the visibility level with LBAC
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"