jyoung8607

Has there ever been any measurement of this, of any sort? Honest question. I frequently see a plural of anecdotes to that effect, but I've not seen a concrete statement of fact or measurement that could be scrutinized or tested in any way.

If so, please share. This should be measurable, and I'm glad this project is measuring it.

Answers in the form of additional anecdotes, stated with even greater passion but still lacking a statement that could be tested and falsified, would validate my exact concern.

The car always has to be capable of driving safely and avoiding collisions locally. The human operators are being asked occasionally to help with some higher level, longer term decisions. As a random example, if there's foreign objects blocking the road, the car has to be able to stop itself before hitting them, but it might phone-home to a human to decide if a u-turn is appropriate.

To clarify my parent comment, I think it was an interesting experiment and seems like it was done well, and it may well be informative about what various frontier LLMs could do with recorded or world model footage.

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.

This question reads a little ambiguously. The first way I could read it is that you're genuinely concerned about my mental health as a mainly-volunteer open source developer. The second way to read it is a direct accusation. Can you please clarify?

I'm not an expert in the LLM space, but I'm an external contributor to comma.ai's openpilot project and I'm and quite familiar with how its controls work, so I looked from that perspective. There's two questions here:

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.

Seventeen years ago, when we transitioned, the state of available and deployed equipment, codecs, and home receivers would not have permitted it.

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.

That's already widely done in the US.

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.

If the restricted area is large, a carrier is regionally disabling for an imagery provider. If it's smaller (and therefore must move over time to follow the carrier group) as soon as the imagery provider starts refusing sales in an area, any customer can test and learn its perimeter with trial purchases, find a coarse center, and learn its course and speed. You don't care about anything else until there's actual hostilities.

I don't find that an unreasonable interpretation. Absent that paragraph of explained thought process, I could very well read it the agent's way. That's not a defect in the agent, that's linguistic ambiguity.

Persistence allows the scammer free license to attempt password recoveries for every account the victim could possibly have. Other banks, retirement accounts, the victim's email account.

Typo squatting is a thing, and so are Unicode homographs.

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 a function of the website, not the browser.

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?

The controllable shutoff valves are already a thing, on the market. They even measure flow rates and look for slow leaks and notify you in an app.

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.