Yes (perhaps not etcd, but the combination of kube-apiserver and etcd)

Substrate does not use CRDs for anything on the hot path of actor scheduling or resumption.

This is going to be decomposed. I believe the plan is to offer resumption with disk state only as well (and the RAM snapshots will need to be discarded from time to time, if you update the underlying code of the agent, or switch CPU types).

By the way, the RAM snapshots are not kept in RAM, they are serialized to disk, or uploaded to object storage.

* More efficient usage of compute by timeslicing agents (Substrate Actors), which requires fast suspend and resume (using gVisor or cloud-hypervisor snapshots), as well as keeping the K8s control plane out of the critical path (so agents can't be stored as resources in the K8s database).

* Deep inspection of outgoing requests using an egress gateway

* Minimizing the exposure of credentials to unpredictable agent control (so they can't upload access tokens to pastebin).

Achieving those goals ultimately required a significantly different design from Agent Sandbox.

(This is work in flight, but it will land within a few weeks)

Comments URL: https://news.ycombinator.com/item?id=49516713

Points: 3

# Comments: 0

Comments URL: https://news.ycombinator.com/item?id=48244426

Points: 2

# Comments: 0

If you sell them immediately, then you don't pay any additional capital gains tax, because there were no capital gains from the moment you got them to the moment you sold them.

If you hold on to them, you will eventually pay capital gains on any increase in value from the moment they vested until the moment you sell them.

Perhaps, once they are vested, you could take loans against them, to get some cash while avoiding selling them.

But no matter what, they are taxed at the moment you receive them, and again at the moment they leave your possession.

In practice, it is easy to pick out the situations in which there is "practical" universal jurisdiction, vs "theoretical" universal jurisdiction.

A Colorado company selling locally in Colorado falls in the "theoretical" bucket.

(This is basically how Let's Encrypt / ACME accounts work)

Kubernetes is such a huge project that there are few reviewers who would feel comfortable signing off an an arbitrary PR in a part of the codebase they are not very familiar with.

It's more like Linux, where you need to find the working group (Kubernetes SIG) who would be a good sponsor for a patch, and they can then assign a good reviewer.

(This is true even if you work for Google or Red Hat)

* https://github.com/grpc/grpc-java/blob/master/documentation/...

* https://grpc.io/docs/guides/reflection/

You can then use generic tools like grpc_cli or grpcurl to list available services and methods, and call them.

Take a look at https://github.com/kubernetes/enhancements/tree/master/keps/..., which is hopefully landing as alpha in Kubernetes 1.34. It lets you run a controller that issues certificates, and the certificates get automatically plumbed down into pod filesystems, and refresh is handled automatically.

Together with ClusterTrustBundles (KEP 3257), these are all the pieces that are needed for someone to put together a controller that distributes certificates and trust anchors to every pod in the cluster.

> If the Pool holds the only reference when this happens, the item might be deallocated.

Conceptually, the pool is holding a weak pointer to the items inside it. The GC is free to clean them up if it wants to, when it gets triggered.

I think you need to flip a flag on the cluster object to enable the Gateway controller.