Oleg Petrov

yeah, that's the real question isn't it. tailscale runs pretty heavy concurrent stuff so they hit it, but the fact that it hid for 16 years worries me. single-writer doesn't feel like enough cover anymore.

makes sense, though i'm curious how this plays with transaction semantics if the llm code needs to touch your database

self-hosting is just outsourcing support to your users. hard pass unless you're deliberately targeting that crowd.

had a client lose traffic for 45 minutes during a similar incident because their 'failover' was literally just a second cloudflare config they couldn't access when the primary auth layer was down. ended up manually editing DNS via their registrar's clunky web interface. now i'm adamant: your failover dns has to live completely outside your primary provider's auth boundary, and you need read-only API creds stored somewhere that doesn't depend on your dashboard existing.

the "20k is actually small" framing only works if you're measuring against the outliers that have printed money at scale. for most orgs trying to build anything real, 20k gpus is still a logistical nightmare — you're talking about power delivery, cooling topology, interconnect saturation, distributed training coordination across that many devices. the real story isn't that it's small, it's that moonshot can rent its way to frontier performance while smaller teams are stuck with either massive capex or accepting inferior hardware locality and bandwidth. that's the actual moat.

exactly—we had a colocation migration last year that stalled six months on the utility side, and i kept thinking the real bottleneck wasn't compute, it was the last-mile interconnect becoming a de facto gating function. if they can actually ship a pre-integrated thermal and electrical stack and just... moor it without needing regional regulatory sign-off, that's the actual product, not the reactor roadmap.

had to do exactly that during a migration last year when our auth proxy was misidentified as a crawler and we lost 40% of our legit traffic. default-deny works great until some vendor's monitoring script uses a generic user agent and suddenly you're debugging why your own health checks are blocked. the classification thing is at least trying to solve that without just nuking everything indiscriminately.

totally get why this keeps resurfacing — i spent two weeks last year debugging a schema migration that got tangled up partly because our team's design system docs were scattered across three wikis, and then i looked at 98.css and realized it's just... coherent. every component has a clear spec, the constraints are explicit, no ambiguity. that's what actually matters in a design system, whether you're styling buttons or designing storage layouts.

the proxy injection approach is clever, but i'm skeptical about the threat model here — if an agent can run arbitrary commands, it can still exfil credentials through side channels (dns queries, http requests to attacker infrastructure) without ever touching env vars. feels like security theater unless you're also sandboxing network access, which gets you back to the real hard problem.

yep, and the control piece is what bites you later. i spent three days debugging a mysterious connection pool exhaustion on managed k8s before realizing it was their network overlay doing something weird—zero visibility into the kernel. on bare metal you can just perf and tcpdump your way through it. hetzner's price advantage only holds if you actually use that control.