heywoods
Joined 13 years ago
Joined 13 years ago
Are things like kv cache eviction policies and memory budgets shipped with recommended configurations based on the hardware and software serving the inference requests? or are they configured dynamically by the cloud provider hosting the model to manage multi-tenant load?
Seems like a dashboard mode toggle to run in a dedicated terminal would be a good candidate to move some of this complexity Anthropic seems to think “most” users can’t handle. When your product is increasing cognitive load the answer isn’t always to remove the complexity entirely. That decision in this case was clearly the wrong one.
I could “feel” the basketball dribble past me. I could hear the squeaky shoes as they rushed past. It was an experience I haven’t had since high school sitting on the bench :p
Did LEGO solve this problem and Apple didn’t? The Apple AirPower is what I’m referring to and it was a matter of physics that was the mighty hurdle Apple had to contend with. But they were also trying to pump out ~15w per device. These bricks will be measured in milliwatts per brick. But I’m curious if there is any additional information about this? How many bricks can be charged at a time? Can they be placed anywhere on the pad? (I hope so.) It would be great if specs were released. I would buy the pad alone just for charging other IoT devices.
https://www.hardwarezone.com.sg/incoming/tech-news-apple-s-a...
Edit: It will not be usable by anything other than Lego Smart Bricks. It will use a proprietary or highly customized inductive standard designed specifically for the new Lego Smart Bricks.
Consider the nomenclature. Even during the Kalanick era, when “move fast and break things” was operational doctrine, you would not have seen internal naming this careless. I was there. We called drivers “supply” and riders “demand.” Clinical, yes, but accurate and apolitical. The language reflected the business model without editorializing about the humans within it.
What’s worth examining is not whether Uber engaged in questionable practices. Of course they did, and of course they still do. The real question is why the practices look different now.
Growth stage vs. profitability stage.
Uber in 2013-2016 was optimizing for growth. Uber in 2025 is optimizing for profitability. These are fundamentally different objective functions, and they produce fundamentally different behaviors. The perverse incentives remain constant; the tactics they generate do not.
Here’s the key distinction: growth-stage illegality and profitability-stage illegality carry asymmetric risk profiles. When Uber was in growth mode, the company had optionality. Infinite capital and public goodwill meant the growth team could deploy aggressive guerrilla tactics to enter new markets, absorb the legal consequences, and move on. The expected value calculation favored action.
Profitability-stage Uber has no such luxury. The levers available to a mature company fighting for margin are few, and they all point in the same direction: the humans. Drivers. The “assets.” When you squeeze there, you’re not circumventing a government. You’re directly degrading the livelihoods of your own platform participants. The reputational and regulatory exposure is immediate and personal.
This brings me to Spain.
When Spain blocked Uber from operating, we did not wait for lawyers to navigate the legal system. We shipped a technical solution. I watched this happen in real time.
Here’s what we actually built:
The goal was simple: keep the Uber app functional for Spanish drivers and riders despite the government blocking our server IPs at the network level. We needed a system that could rapidly distribute new, unblocked IP addresses to every app in the country without requiring an app store update.
The solution was a Lua interpreter embedded in the Uber app paired with a gossip protocol for peer-to-peer distribution. The Lua compiler allowed us to push executable code to the app dynamically. No app store approval needed. It was essentially a remote code execution backdoor into our own app, which was both brilliant and terrifying in hindsight. When a user opened the app, it would fetch and execute Lua scripts that contained the latest routing logic and server whitelist.
The workflow once it was live: when Spain blocked a batch of our IPs, our infrastructure team would publish a new IP whitelist. That list would seed into the gossip network, where each active Uber app became a node, sharing the updated configuration with other nearby apps. The propagation was exponential. Within hours, millions of devices had the new routing information. The Lua script would compile the updated whitelist and redirect all trip service requests to the unblocked servers.
The tech stack was essentially a censorship-circumvention system: Lua for remote code execution, gossip protocol for decentralized distribution, and a dynamically compiled IP whitelist that the app used to route around the blockade. Same playbook Tor uses for bridge distribution or how Telegram distributes proxy servers to users in Iran and Russia.
The Spanish government quickly realized they had exhausted their options. We forced the outcome, Uber was unbanned, and operations resumed legally.
Here’s the part that matters: it was illegal, but the illegality accrued to Uber’s benefit without harming users. Drivers kept driving. Riders kept riding. The Spanish government got cast as the obstruction, and Uber was welcomed back as the protagonist.
That’s the difference between growth-stage rule-breaking and profitability-stage rule-breaking. One makes you the hero. The other makes you a landlord squeezing tenants.
Enjoy the Lyft v Uber era while it lasts!