No you are definitely not saying the same thing. You say there are thrusters on top of the vehicle, whereas in stead they are sucking vacuum below the vehicle. And the exhaust ports for those fans are not at the top.
Tesla seems to disagree with you as well, they call it a "multi-mode suction system" [1] suggesting that the evacuation under the car is what does the job. And that's far more likely than that the ejection of that little bit of air at the top is what keeps the vehicle planted upside down. But with vacuum that is almost a trivial accomplishment.
I'll just note that again, my hypothesis and the actual way it works are very similar to each other, and both are very dissimilar to the suction cap analogy. Suction cap works by passively utilizing atmospheric pressure, this utilizes moving a large amount of air in the direction opposite to the road. The only difference is that it's taking the air from below instead of pushing from above. I imagine that is the case to utilize the same outlets that are used for lifting the car.
> this utilizes moving a large amount of air in the direction opposite to the road.
False.
The air from the fans is ejected out of rear of the vehicle, not the top. The kinetic energy of that air is neglible at best. The vehicle uses retractible fairings to create a partial seal and the fans create a low pressure zone inside the zone that holds the vehicle to road.
The cold gas thrusters are a completely different system that expels high pressurized air from canisters in the vehicle.
The difference is approximately mass counteracting the force of gravity ejected on a continuous basis versus a modest expense in power to run fans. The two are not even remotely similar.
Agree, except the probabilities for outcomes in the structured output. I don't think you can get those for most frontier LLMs (logprobas). You can get it for open source models but not frontier LLMs.
I've seen them talk about it a bit on Twitter -- it seems to be fairly well-calibrated in general, but obviously you need to test it on your use case and dial it in comparison with known data for best results.
Kessler is much less of a problem at their altitude (480km). Debris has too much drag and would get pulled down too quick to have a sustained Kessler situation. It's possible, but very very unlikely at that altitude.
You could still generate a mess for 5-10 years at that altitude. Even if it self-clears you still destroy the constellation and deny access to LEO for years.
Even if everyone used it, the security scanners would still have time to do their static analysis of new packages. Basically, all the clients implementing a delay would create a de facto quarantine status for new packages so they can be examined before everyone starts installing them. (Why npm doesn't just implement that themselves, I do not know.)
I think if they did it, then attackers would be able to iterate their attack against their own project, and once it passes the filters they could deploy for real.
I guess it could work better if it was enabled for only actual attack vectors projects.
That’s my point. For whatever reason, npm isn’t doing it. All npm users adding a minimum package age is kind of like doing it as a collective, without npm’s help.
