Why it isn't likely to have happened before: trying is only easy for a developer who is not only very familiar with the API for reading those motion sensors but also with the API for system wide overlay. This a strict no for your run of the mill to-do list app. Combine that with the requirement of being affected themselves (or someone close), having the idea, having the time to try and no competing side quests that take up all attention. And the requirement of when the experiment was successful, having the kind of access that actually serves as a conduit for ideas not only on paper to someone in the position to make it a product. That's a lot of stars that need to align. Personally I wouldn't even be surprised if there was an LLM angle: would still need someone in the know to try it, but chances are that knowledge combined with a bit of prompting could be a path to PoC implementation that could clear effort thresholds that would stand in the way of conventional coding.

"13000 * 9.81 * 1000 = 127.5 MJ, to reach your altitude"

Presumably quite a bit of that would be harvested back during the descent that follows. The conventional engine would still need some excess power (relative to cruise load) to fill the gap left by drag and imperfect circle efficiency of the electric motor/generator, but mass x altitude is stored energy, not lost. (I'm still talking about the "what if we need a second abort" of the root post)

Easy: you don't try the second landing approach before the battery is sufficiently recharged to contain enough energy for the second abort. Chances are this does not take any longer than going through the pattern anyways.

The saving is not just the dead weight of the bigger engine you'd need to do take-off, climb and abort without electric assist, it's also the fuel saved during cruise from running an engine that is completely designed for efficiency at cruise load instead of for some compromise between cruise efficiency and sufficient peak power for start and abort.

This is still quite debatable, but so much less so than the implied accusation that they would somehow sell out their privileges as subcontractors for the data centers themselves.

In the old days, when it was all about squeezing maximum performance from a given chip area budget you'd prefer using those transistors for some improvement of the general purpose parts, no matter how marginal. But now it's the thermal envelope, or power consumption of you prefer looking at it from that angle, and even slightly esoteric special purpose units can start making sense.

But it turns out even in the container, there are footguns that have occasionally made the news by being fired: few projects don't have any external resources and when credentials with any form of write access happen to make it into the container (even if it's just a session cookie) agents might jump at the opportunity.

The latter can seem to be as good as the former for any amount of time. No outside observation can really prove reliability, only the negative result ("it does occasionally break the rules we expect") would be proof. So it's difficult to trust any claims that it's the former.

And even if it does have some of the former, chances are that the protection you experience is only partially provided on code level, while an unknown amount is still just bootstrap prompting that just works until does not.

But it really depends not only on the presentation theme but also on the data set itself and that varies by region. I'm sure that there are still places where the sources Google is buying are better than whatever is on OSM, just like there are regions where OSM is just so much more detailed than everybody else. And yet others, where OSM is generously fed by an entity that also supplies Google and all the others because they are not doing it for the map, they are doing it for the place.

If you do do much admire economic success through suffering, can I assume that you have relocated to China? (mainland) Because they sure know a thing or two about that...