My only point is to say this sort of experiment is where it ends. Neither Anthropic nor OpenAI will be coming out with a "drive your car from the cloud" subscription until we have FTL communication, meaning never.

1) Could a cloud-delivered LLM figure out how to drive this route, based on those input data and given access to those output actuators? Looks like yes. Sure.

2) Could this work in the real world? Absolutely not. Three reasons: latency, latency, and latency.

openpilot's driving model updates the target curvature and acceleration at 20Hz. Every millisecond of the round trip time through every piece of its entirely-local driving stack is well-understood, extremely consistent, and tightly optimized. It has to be, otherwise you can't react to even minor bumps or wind gusts, much less rapidly-developing traffic situations.

Adding even a single speed of light RTT to a cloud service is meaningfully bad, and you'll need a whole lot more to encode and upload camera imagery to even start the time-to-LLM-response clock, and then send the response back down. By then the world around the car has moved on.

There's a reason Tesla and every other self-driving manufacturer need the compute hardware in the car.

If you got into a time machine and tried your plan two decades ago, the conversations would have gone something like this:

-----

Government: "Hey broadcaster, we need you to throw out and upgrade all your broadcast equipment that's working just fine today."

Broadcaster: "Why?"

Government: "So we can auction off some of the broadcast channel bandwidth."

Broadcaster: "Why else?"

Government: "That's really it."

Broadcaster: "How about instead, I take a little bit of that money you're asking me to spend, and give it to your political opponent's campaign?"

-----

Government: "Hey citizens, we need you to buy a new TV or buy an adapter for your current TV that's currently working just fine."

Citizen: "Why?"

Government: "So we can auction off some of the broadcast channel bandwidth."

Citizen: "Why else?"

Government: "That's really it."

Citizen: "How about instead, I vote for the opposition candidate who says he'll let me keep my TV and my money?"

-----

We're able to juggle broadcast frequencies more easily after the transition. Not only did we shrink the broadcast frequency range at the time of transition, we did it again about ten years ago with far less pain.

https://en.wikipedia.org/wiki/2008_United_States_wireless_sp...

https://en.wikipedia.org/wiki/2016_United_States_wireless_sp...

TL;DR: 480i would have been an absolute non-starter.

I mean sure, you could pack four streams into one 6MHz channel. They could even be "HD" insofar as the transmitted stream is 720p or 1080i.

The result would have been MPEG-2 program streams of about 4.5Mbit each instead of about 18-19Mbit (assuming no other subchannels). That would make live sports or anything with significant motion look like absolute dogshit.

You might say that you don't care about that, and that is fine for you. However, in that case, I would respectfully submit that opinion to be far from the center of the bell curve of television-viewing American public of that era.

We could do a lot better with ATSC 3.0. So, there might someday be a second round of broadcast frequency reclamation, just as there was with ATSC 1.0.

If you plug in an antenna and scan for local channels, what used to be one analog TV channel on colloquially-named "channel 7" in the defined channel 7 frequency range will now be seen as "channel 7-1" which is often (but not always!) actually broadcast on the old frequency. During the ATSC transition, it was important to retain the branding and consumer memory of "channel 7" even when the RF transport frequency changed.

The transition opened the ability to have an arbitrary number of digital subchannels, 7-2, 7-3, etc etc. The total bitrate available on a given ATSC broadcast is fixed, but it can be partitioned among multiple MPEG streams. The typical setup is one (occasional two) HD channels and several SD channels. Obviously there's a balancing act between bitrate and visual quality for each subchannel. It's often used as a way to broadcast older (read: cheaper) syndicated SD content on which they can run more ads while keeping the main HD channel quality reasonably acceptable.

The permissions approach isn't bad. I may trust Thunderbird for some things, but permission to read SMS and notifications is permission to bypass SMS 2FA for every other account using that phone number. It deserves a special gate that's very hard for a scammer to pass. The exact nature of the gate can be reasonably debated.

That's hand-waving away quite a lot. The task changes from serving a copy of a file on disk, as every other image format in common use, to needing a transcoding pipeline more akin to sites like YouTube. Technically possible, but lots of extra complexity in return for what gain?

Draining the pipes isn't that simple, and even if you did, you still have things like a water heater, toilets, softeners, filters, and expansion tanks. You also wouldn't get the water sitting in drain traps; winterizing a house or RV involves pouring a little RV antifreeze down each drain.

AI has processing delay even if run locally. In telephony the delays are more speed-of-light dictated. But the impact on human interactive conversation is the same.