Does it also tell the kernel to drop the socket? Or is a TCP FIN packet still sent?

Be better if the scraper is left waiting for a packet that'll never arrive (till it times out obviously)

In the grand scheme of things supporting a rocket turnaround, sending somebody out with a wrench (to detach the harpoons from the leg) and a grinder (to smooth out the deck surface) probably isn't that big of a deal.

However, for an alternative that would be wild to see from a rocket: https://en.wikipedia.org/wiki/Beartrap_(hauldown_device)

A tank doesn't do much without a significant amount of combat support and logistics backing it up.

It wouldn't be clear of the fallout before it ran out of fuel.

In the war plan under discussion IIRC all the nuclear bursts were air bursts, so minimal fallout, not enough to kill anybody even right after the strike.

Or all the bursts in the territory earmarked for invasion were air bursts while some of NATO's air bases outside the invasion area get hit with ground bursts (to maximize destruction of the runways).

There's a difference.

I've noticed that people seem to believe as long as they bought something it should be safe. If you're smart enough to build something, I have to hope you're at least smart enough to realize that there might be consequences.

Take your beer back, I'm going for a rip next.

So that you can flip over in an uncontrolled wheelie at an even lower fraction of the throttle? Even if there was infinite energy throughput (aka power) at zero mass, the main limiter for power per total system mass would still be the battery. In any practical setup, even in super short runtime designs, getting, say, twice the power would not all that dramatic a runtime hit if it was achieved by scaling the same motor technology and paying for the extra mass with a little battery capacity. Unless of course you want to actually use that power increase for any meaningful fraction of the runtime, then you'll obviously drain the battery fast. But a zero-mass power increase would not change that a lot either.

Increasing power density (of the motor) just isn't worth much when it does not happen to coincide with an increase in efficiency (and then the battery mass saved for achieving the same range will quite literally outweigh the mass saved by a smaller engine for achieving the same power)

The good news is that those striving for power density aren't really at liberty to completely ignore efficiency in the process because cooling is a key issue for them.

Honestly he’d probably just pretzel the frame underneath him, assuming he gunned it.

That’s enough power to potentially do that to a full size car frame.

That would be a AI agent which isn't the problem (for the author). The problem is the scrapers gathering data to train the models. Scrapers need to be very cheap to run and are thus very stupid and certainly dont have "prompts".

No need to wonder, proximity fuzes are still used today. And yes, they are much smaller, cheaper, more reliable, and precise.

I was wondering how much easier it would have been, specifically in dollar terms. Order of magnitude?

Well according to this person* by the end of WW2 a proximity fuze cost $18 or $314 today.

I figure I could probably put together a resilient fuze using off-the-shelf parts that's at least as good as a WW2 era one for <$100 (potted solid state parts are really frickin resilient to G forces). With some optimisations for mass production I think <$30 is doable. So I'm going to say an order of magnitude easier.

Of course factoring in today's markup on military parts and the failings of military procurement, that fuze will actually cost the tax payer $3000-$30000 + R&D.

* https://history.stackexchange.com/questions/75940/what-has-h...

I would suspect that the patents and other IP dont protect against a software implementation of x86-*. Similar to the way copyright doesnt protect against somebody else making a clean room implementation of an API.

No idea what happens around firmware implementations or an FPGA.

Indeed that is the definition of a "aviation incident" where there was a risk of injury or damage. If there is actual injury or damage it becomes an "accident".

The investigations into incidents aren't usually particularly long or noteworthy and often the corrective action will be to brief X on dangers of Y, or some manner of bulletin distributed to operators.

Second guessing a pilot saying they have a problem is a really bad idea. ATC second guessing an emergency is a really bad idea. Making a pilot explain why they're actually low on fuel, despite whatever some computer is saying, instead of focusing on flying the plane is a really, really bad idea.

Also, that sort of telemetry does exist for most major airlines, however it goes via satellite to the airline not the ATC.

I am not saying you are wrong, but both Type I and Type II errors are problematic. What if the pilot is wrong?

Korean Air Flight 801 could have used someone 2nd guessing a pilot. They didn't until they were almost dead and then it was too late. Not 2nd guessing the pilot was a really really bad idea.

If the pilot is wrong you hope the copilot or someone else on the crew picks up on the error and corrects it. If they’re both wrong, or if they don’t feel empowered to challenge the pilot like in Korean Air 801, everyone is usually fucked.

ATC doesn’t have the kind of situational awareness or manpower to fix these kinds of problems the vast majority of the time. It only seems like they could have done something after the fact when the disaster has already happened and hindsight activates.

Like the GP said, ATC second guessing pilots is a really, really bad idea. A few incidents doesn’t change that.

That specific incident resulted in a lot of changes to the rulebook and some very specific notes about training in terms of cultural differences.

> Korean Air Flight 801 could have used someone 2nd guessing a pilot.

...yeah, the second pilot. And in this case, also flight engineer.

IIRC The problem was pretty much aside from errors the cultural issues with pilots, the "lower ranks" wouldn't dare to be assertive to seniority and just voiced the issues they saw without doing anything.

As somebody who regularly tinkers, debugs, and programs microcontrollers at my desk. I just realized how handy having UART/SPI/I2C headers right there would be. Obviously I already have them like right there but to have them right there there would be great.

After a few dumb accidents involving header pins, I've come to the conclusion that exposed male header pins on my desk are a hazard.

I've learned to be wary, too. Most desktop motherboard these days have several fan headers just above the memory slots. They also frequently use DIMM slots that only have one latching lever, usually at the top of the slot near the fan headers. So when you're trying to remove a memory module, if you use slightly too much force and your finger keeps moving after the latch opens up all the way, you get a deep puncture wound.

The headers on the keyboard look like they'd be easier to hit accidentally, but probably not with enough force to cause a serious injury. I'd still prefer having some covers over them.

I would perhaps put pin receptacles / sockets there instead.

Shrouded headers are also available.

How about the risk of frying the MCU?

You can always put some extra protection on the external interfaces. Won't make it impossible to fry if you really do something stupid but would reduce the risk significantly.

Risk? Ain't no risk to it, it's an established fact! What's a good electronics hobby without an assortment of dead MCUs, melted wires, and exploded probe tips?