That is exactly how the USB IF has been branding it for consumer use. They explicitly tell[0] implementers to not call it "USB 3.2 Gen2x2", but "USB 20Gbps".
The problem is just that the manufacturers and the tech press keep ignoring it...
Which is why I honestly believe they should have fixed this in the design stage itself. Post-facto reframing/renaming never seems to go well.
Especially once the mass produced cheap stuff starts being churned out, and there's no cost incentive to go back and fix wrong messaging. USB-IF constantly drops the ball around this ngl, feels like they're a pure scientific community that doesn't think about consumer adoption and UX.
You're looking for a technological solution for a human problem.
Automatically running arbitrary code from random repositories is a Really Bad Idea, so Git will almost certainly never auto-install pre-commit hooks. Just mention it in the README and run a checker in CI to confirm they are using it, it really isn't that difficult.
People wasting 2 minutes of their own time once during their first contribution because they didn't read the README is not that big of a deal. What's next, you want a script to automatically sign a project's legally-binding CLA on checkout?
You're talking out of both sides of your face here. It's dangerous and also it's super easy and you should do it first thing without having to think because it's so easy. You shouldn't run this code but also the build machine automatically runs it.
We already know we're definitely going to run some of these. We know we want to maintain changes to these hooks. Can we stop pretending like we're not doing that? We get it. Some of these will be untrusted so let's design a system to handle that instead of not designing a system and deciding to be just short of as unsafe as possible.
Automation an uniformity increases safety. Human intervention increases human error. Its just a matter of actually finding a good solution to know what is trusted but instead we get "just set it up manually because its safer."
Why do I have to create a weird "workflow" to receive webhooks in a chat channel? Why does it have such complicated ownership permissions? Why is it automatically deleted if it doesn't see "enough" use? Why do I need to send the message in some weird "adaptive card" format - for which there are barely any ready-made libraries? Heck, why can't I create a new chat channel on my own, but need to invite three other people into it? Why does chat have a completely separate "channels" functionality which act more like a forum?
Please, stop trying to reinvent the wheel! Just do exactly what all your competitors are doing and I'd be so much better. My company is already stuck with Teams due to M365 licensing, there is no need to make it "unique".
Imagine when you receive millions of events per day -- the ones that arrive out of order, the days when delivery time goes up and up again, the days when oauth fails renewing keys... it's meant to be a lot of fun.
Compare to a sad websocket that just stays connected, you receive everything in order and you don't need an harness with tunnels every time you want to test something in dev.
> in an hour, these stations have to charge 7 cars now whereas in the past, they only had to charge 1
Why? Where do those extra cars come from? In reality the change you're going to see is from spending 30 minutes to charge 1 car followed by 30 minutes of sitting idle to spending 5 minutes to charge 1 car followed by 55 minutes of sitting idle.
Or, alternatively, go from 6 stations each spending 30 minutes / car to charge 12 cars per hour to 1 station spending 5 minutes / car to charge 12 cars per hour.
The electricity demand only depends on the number of miles driven. Same with ICE cars: the speed through which fuel comes out of the gas station's nozzle doesn't impact how much fuel you consume during your commute, or how often the gas station needs to be resupplied.
They didn't share third party tests. They shared tests done by a party they contracted, and whose test reports don't back up the claims to the extent that they claimed.
Do they have something interesting? Maybe! But it could also be yet another Theranos. Extraordinary claims require extraordinary evidence, and they haven't exactly been forthcoming with it.
The charging station's batteries don't have to use the same chemistry though, as they aren't space- and weight-constrained like EV batteries are. You can optimize for durability and cost instead.
Having station-based storage also allows the station to participate on the energy market and purchase only when electricity is cheap. It could even do double duty by selling back electricity from storage during periods of high grid demand! Heck, pair it with a local grid storage battery which is going to be built anyways and you basically get it for free.
Station batteries are an additional toxic inextinguishable fire hazard and expense to consider. I wonder what is the efficiency loss in charging one battery to turn around and charge another too. But you are generally right: stationary batteries do not need to be lightweight like the ones in cars.
> there might still be a point in battery swap, especially for public transport systems
There isn't. Buses aren't really size- or weight-constricted and don't drive at highway speeds, so building one with enough battery capacity to last most of the day isn't a big deal. Plenty of cities have already transitioned to a 100% electric bus fleet, after all.
A big thing to remember is that people don't travel at the same volume at every moment of the day, so you don't need to run buses at the same frequency the entire day either. You can run buses at 10-minute intervals during commute hours, 15-minute intervals in the middle of the day, and 30-minute intervals in the early mornings and late evenings. This means that there is plenty of time between the morning rush and the evening rush for some buses to go off-duty and charge for a few hour. They are going to sit idle anyways, so why not make use of it?
There are many cases where the EV busses have been abandoned. Busses typically do not do their route and stop, so getting a significant amount of charging for any busses requires extra busses that can be rotated on/off duty. If you design the system to depend on that charging then you need extra busses and you're effectively stuck with a sparse schedule. That is not a constraint to consider with petrol-powered busses. They can run nonstop as much as needed.
There is another thing cities should consider in all this: EV busses are totally unsuitable in emergencies. They cannot be charged fast enough, especially in extreme weather. You should consider this before buying an EV as well. At least, have a plan to arrange alternate transport with a reliable petrol vehicle.
The vast majority of charging is done at home, though. Five-minute-charging/swapping is basically a gimmick to show off to your friends, and only really sees (questionable) use during that once-a-year road trip.
The main value in these technologies is to shut up the "But sometimes I want to drive for 20 hours without being forced to take even a single 30-minute break!" pseudo-argument as to why an EV is "impossible" for their lifestyle. Same with the Lucid Air and its 1000km range: basically zero people truly need it, but it needs to exists in order to drag the last few holdouts into the future.
When my road trip is in negative temperatures, I appreciate not having to be in the cold for too long. I think the bigger adoption issue is thoughts of scaling the charging stations. If there’s a line of cars at a liquid fuel pump, one can still get fuel in twenty or thirty minutes. If there’s a line of four cars at every charger and every car takes 15 minutes to charge on average, that’s an hour before you can start.
reply