austin-schick

I'm finding the list of signatories on this letter really interesting and somewhat confusing, looking purely through the lens of economic interest.

It makes sense to see Meta, the startups, and the VC firms on this list. And it makes sense to see OpenAI, Anthropic, and Google all missing. Microsoft is somewhat unexpected to me. I don't think of them as having a focus on open weight models (no more than Google), and they have a large stake in OpenAI. Maybe they're looking at this from the angle of Azure providing compute. But then why is Amazon missing, when it has AWS?

And of course, we don't see DeepSeek, Moonshot, or Z.ai on here. The letter is about American technological leadership after all. But then we _do_ see the French company Mistral! Mistral who released [a playbook](https://europe.mistral.ai/) for Europe becoming a self-reliant AI powerhouse.

I assume all of this is in the context of influencing the Trump administration's thinking on Chinese open weights models. But the letter is really about _American_ open weights models. The call to action is all about keeping the American open weights ecosystem competitive. I didn't even realize that was under threat, so I feel like I'm missing something.

The article says that they did do this:

> Qiu’s team had engineered mice to have a human version of the CHD3 gene with their daughter’s mutation, R1025W, which results in a protein with the amino acid tryptophan where there should be an arginine. The mutant pups developed autismlike traits and didn’t squeak as much as normal mice when separated from their mothers. When the researchers repaired that mutation, the pups developed normally.

I think I'd consider this kind of technology at the intersection of personal freedom and _public_ safety. Drunk or distracted driving puts others at risk, not just you.

Separately from any details of this post, I think you misunderstand what kubernetes is. To me, that's something worth reading and thinking about.

You seem to think it's like a virtual machine, and it lets you run containers anywhere regardless of operating system or host machine. This is not correct. You can't run containers using k8s directly on a Mac, for example, because there is no Linux kernel to run the container. You need a VM first, then you can run k8s inside of that VM. Kubernetes does not let you magically run a container with ARM binaries on an x86 machine either. You would need additional tools to run binaries for another architecture.

You're totally right that in practice, you usually don't need to think about the host OS when you're using k8s. It is nice to not worry about what packages it has installed, etc. But it is not a tool that allows you to run an arbitrary container anywhere.

I get your point. I will disagree that it "doesn't work". It does! You just can't use it for real production workloads since it runs in your browser. If you ported kubernetes to your toaster would it be a port? I think so, but you probably couldn't deploy prod on it. That's just a fun semantics conversation though. Is a taco a sandwich? :-)

Doesn't have to be bad news! An abundance of explainers is only good for the world. Different explanations work for different people. Someday somebody will say "I read all the articles people recommended, and I don't know why but it only clicked for me when I read mcapodici's!"

I bet you just meant to share prior art and not be discouraging, Sam. But just saying :-)

I don't think this analogy holds. Version control and diffing are some core capabilities of git. Sam lists core capabilities of k8s that his port can handle: pod lifecycles, container garbage collection, IP allocation, etc.

My understanding is that the interesting part of k8s is how it orchestrates containers, which this port can do a lot of. Your comments imply that a core component of k8s is actually running containers (rather than orchestrating them), but I don't think that's right. That would be the job of containerd or the operating system, depending at what level you're looking at. Happy to be corrected if I'm wrong about any of this!

I think this blog post has a great description of the "Modern C" niche Zig fills: https://vfoley.xyz/hare/. I tend to think of Zig in this way. If you found yourself reaching for C, you could instead reach for Zig. You'd get optionals instead of null pointers, comptime instead of macros, a real facility for handling errors, etc. It's like C but with some of the sharp edges sanded off.