rakyll

> Disclaimer: I'm one of the co-creators of this project and working on Kubernetes so my opinions may be biased.

We met quite a large number of customers in the last few months, and several teams inside Google, who are asking for a stack that runs on any cluster.

There are several reasons for a layer like this.

(a) Today, it's extremely hard to deliver large agentic applications to someone else's compute, and it kills adoption for products that need to run closer on customer data plane, e.g. large scale code scanning product.

(b) It's tedious to build systems that set up the environment, deal with networking policies, provide integrations for session storage, memory curation, skills retrieval and mounting, etc while all you want to do is to focus on building applications.

(c) People want a truly transparent stack for compliance/auditing, and all other non functional capabilities most people don't usually think about until they have to.

We are mentioning Agent Substrate. Agent Substrate is working on Kubernetes but isn't exclusive to Kubernetes.

Disclaimer: I'm one of the co-creators of this project.

AX is a layer that is closer to job orchestration, Agent Substrate. It's NOT an agentic framework. We use Antigravity for a few generative features but are abstracting away some of these components so anyone can bring their own. AX is trying to solve some tedious things everyone has to deal with. Layering execution with the underlying stateful worker, wiring up the network correctly, providing sub "task" identity, provisioning the right environment, proving stateful branching, auto discovery.

We want to keep Agent Substrate free of generative features and still need a layer above for some integrations that require agentic concepts and identity.

Google compute services are under GCP and I work on Kubernetes. So the comparison with Gemini CLI is not relevant here.

OpenCensus is not a vendor specific project. The data OpenCensus collects can be exportable to any tracing backend. We already have a Jaeger exporter for Go: https://godoc.org/go.opencensus.io/exporter/jaeger.

Code instrumented with OpenCensus can export to any backend by changing the registered backend.

LLVM is a future consideration for Go. One of the main reasons I don't want to tackle (1) right now if the possibility of benefiting from XRay even though it doesn't sort the case out for the vast majority: the gc users.

Whoops, fixed the typo. Thanks!

Avoiding error checking against a properly formatted constant is not avoiding error checking. I cannot follow your argument.

Two. The URL is a constant that is guaranteed not to return an error. It is not brevity.

Anyways, the point is I don't understand the point of err != nil bashing here, given there are two programs in the article that only contain one error check each.

There are only two err != nils in the article. What's your point?

I had a big group of coworkers from EPFL when I was working for Google Switzerland. At some point, I actually questioned whether we have a bias for these schools.

EPFL or ETH are definitely not something I'd consider as just "Swiss education system". These schools are what Stanford or Berkeley are in their region, and are highly international.

There is not a single mention of Java at the Brillo announcement.

Irrelevant but flush your biases and assumptions down to the toilet. Java can statically compile to microcontroller architectures with minimal runtime footprint. Stop blaming the languages, blame the runtime implementations.

Google is building their own hardware, an embedded Linux distro is primarily a need at Google to support our hardware projects for a long time. But, for the first time, the industry is capable of building hw projects at scale. It's not surprising we reinforce our interest to get involved by opening what we're already doing.

Brillo contains a very minimal part of Android for HAL and the network stack. 64MB is our medium-end target. The ART is not in the scope of Brillo.

You must interpret low-power devices as low-end Linux boards. No one is aiming to target the microcontroller market with a Linux/arm board.