How does this compare to Google's in-house source control?
Most companies don't use mono-repos like this. While there are some really compelling advantages, the downsides tend to stack up as a company's codevbase grows.
It's mainly just startups and huge companies. For small companies git works fine for mono-repos and large companies can build their own complex code management pipelines for mono-repos.
I have been questioning whether agentic development changes the mono-repo vs multi-repo question.
It really makes me appreciate how important good game design is. Claude is doing a fine job coding everything I describe, but it doesn't really understand fun, so I need to.
This is my experience too. I think people with no gamedev experience widely underestimate the challenge of good game design and the need for iteration with real people testing the game. In a similar way that an inexperienced game developer overestimates their skill to assess the fun and all the small details that matter, and will get demolished when it's first playtested by other people.
I am confused by this. The UX of the CLI is almost identical to kubectl, but it doesn't seem to actually be built on K8s CRDs. There's a backend that runs on k8s, but doesn't seem natively integrated.
Because it's using `ax apple` instead of `kubectl apply` you can't use tools like argocd for managing resources.
It's built on agent substrate which is built on top of k8s CRDs, so I'm surprised.
Is the throughput of these objects too high for etcd?
There’s overlap in spirit, but we’re not trying to replace the precision of Fusion/SolidWorks. the idea is that an agent writes an editable 3D program from your prompt/reference, including geometry, parts and eventually behavior. Blender/GLB is our current target, so it looks game-oriented rn, but games aren’t the whole idea. for a mechanical CAD use case we’d want the same experience backed by a real CAD tool/kernel rather than pretending mesh geometry is engineering-grade. I think of CAD, Blender and game engines as different possible build targets for the same broader idea.
The only thing that is "better" in space is the efficiency of solar energy. Everything else is harder and more expensive
* Rockets costs more than trucks for moving things around
* No water in space for cooling/heat transfer
* Heat dissipation is difficult because vacuum is the best insulator
* How do you repair one?
* network bandwidth is probably lower
From a rationalist perspective, provided SpaceX can launch at a low cost AND the problem of radiation shielding, cooling, maintenance can be solved, it will be almost a no-brainer to launch data centers into space.
Either the next administration declares data-centers to be unimportant (which is unlikely, China etc.), or they would want to offload them as far as possible. If space is an option, it will be taken provided it's cost efficient.
From another rationalist perspective, it will always be cheaper to run a data center somewhere on earth under any conceivable scenario. It would be easier and cheaper to put a data center in the ocean. Just a few of the significant issues:
1. Selling an old compute unit is a significant cost savings when they are replaced every five years. In space you basically have to write them off.
2. Cooling in space is limited. Not impossible but limited. And these things throw off massive amounts of heat. You are talking about huge heat sinks which take valuable space and add massive weight that limits space on the rocket.
3. The size per data center will be relatively minuscule OR they somehow have to assemble in space adding additional complexity.
4. Any launch, deployment, connectivity, or hardware failure is a total loss. So you have to account for that.
"You can play around with the cost sliders to estimate the economics, but even being quite optimistic, space data centers cost ~2-3x of their terrestrial counterparts."
The idea is marketing for the stock price and enterprise value. If SpaceX does do it, it'll be analogous to Tesla's "Supervised Full Self Driving." "We run a Kubernetes cluster with some models on the satellites."
> space data centers cost ~2-3x of their terrestrial counterparts
Which is very cheap if it means they can launch it quickly instead of being in permit hell for a year. You can also avoid sabotage (including via lawfare) and dishonest TV reporting à la "I'm standing here in front Big Bad Evil Datacenter that the local community says causes cancer and bad hair".
They also get lower latency to pretty much everybody except the neighbours of such a terrestrial data center.
The latter is an honest advantage. The former is a way of routing around damage. Both can be very valuable.
Its always CI. Whenever I've worked with good pen testers they always start with Jenkins, know that people stored creds and there and didn't treat as seriously as they treated production.
Most companies don't use mono-repos like this. While there are some really compelling advantages, the downsides tend to stack up as a company's codevbase grows.
It's mainly just startups and huge companies. For small companies git works fine for mono-repos and large companies can build their own complex code management pipelines for mono-repos.
I have been questioning whether agentic development changes the mono-repo vs multi-repo question.