I agree with you that it is the very obvious conclusion, but it isn't obvious to everyone. But it could still be relevant to you if you find yourself discussing with someone saying "why do we even spend money making an API, the AI can just control my computer?"
I'm on the side of "clever, fun, but feels useless". But to defend the project, all sensors require a powered central system. It's pretty common for Zigbee to have one repeater per room [1], which is just what is needed for this system.
[1] Because any AC-powered Zigbee device is a repeater, so just a bulb or a plug is enough
TFA says "After 1,000 fast charges, the battery should retain more than 90 percent of its original state of charge, the company said."
I can't really judge whether 1000 charges is a reasonable target for a car, though i think that 1000 fast charges is reasonable. It should probably be able to push to 5000 slow charges and 500 fast charges, which should fit a lot of use-cases.
If you get 400km per charge using 88% of the battery (98% -> 10%), that's 400,000km (258,000 miles) before you're down to 90%, at which point you have likely worn out an awful lot of other things with the car.
Admitting that I have the luxury of an urban, low-driving lifestyle: I'm 50. That battery would literally last the rest of my driving life and have room to spare.
Understanding battery degredation takes a lot of nuance. If you do nothing but charge and discharge quickly at some given temperature, you degrade to 90% in 1,000 cycles.
But the battery also degrades over time, the hotter it is the more, the higher the SOC the more. So you have to add on that calendar degradation, to that 10% loss from just charging.
Total degradation in practice will vary a lot, based on users charging and storage practices. Most of the time in practice it seems some fault will brick a battery before it degrades too much in total capacity.
The battery in my PHEV (Chrysler Pacifica) showed no appreciable degradation in eight years (and >100k miles) before being replaced under recall for a manufacturing fault last year.
>I can't really judge whether 1000 charges is a reasonable target for a car
I mean, if "charges" is "full charge" and the battery pack does even 200 miles of range then that'd be 200,000 miles right? And more like 250-300+ miles seems like a spreading target as energy density ticks upwards.
Honestly that's more than I've ever put on any single individual car or truck I've owned, and well into the point where I'd be expecting to put real money into engine and other work for an ICE. Sure more is better but if a battery pack can go 200k-300k miles keeping 90% range that doesn't feel unreasonable at all for non-commercial usage. Taxis and so on with much higher utilization may find value in alternative options of course.
1000 charges 10-80% for a passenger car at 300-400 km per charge is 300 000 - 400 000 km of fast charge driving. I'd say it's perfectly fine for most people?
The point is that most charges do not have to be fast charges. The usual case is to charge slowly when parked at a "Destination Charger" or overnight at home. Electricity supply is almost everywhere.
You have to change the mentality of "I only get gas when I travel out of my way to the gas station, so the gas refill has to be fast". EVs just do not work like that, and overnight charging is far more convenient that having to go get gas.
Well, you stopped hearing about it, not because it stopped being used, but because its support became mainstream for a very long time. Google strongly recommends using zram on all devices, even on devices with a lot of RAM since like Android 10?
I'll add to your comment that it isn't a bug of MCP itself. MCP doesn't specify what the LLM sees. It's a bug of the MCP client.
In my toy chatbot, I implement MCP as pseudo-python for the LLM, dropping typing info, and giving the tool infos as abruptly as possible, just a line - function_name(mandatory arg1 name, mandatory arg2 name): Description
(I don't recommend doing that, it's largely obsolete, my point is simply that you feed the LLM whatever you want, MCP doesn't mandate anything. tbh it doesn't even mandate that it feeds into a LLM, hence the MCP CLIs)
Since GCC is lacking such an essential optimization, you should consider have one of your junior interviewee contribute this basic optimization mainline.
You can make frequency inertia with solar (even without batteries if you accept running with a constant reserve so with reduced efficiency). Spain showed that there is a learning curve, that's for sure, but their issue was a "simple" oscillation problem that can be fixed by adjusting frequency-follow rate and grid-disconnect rules. It wasn't like a peak of energy consumption or loss of energy production that only a rotating mass could compensate.
reply