Many fireworks are designed to explode at altitude. The biggest risk is probably if the firework is ingested into an engine (also a major risk for bird strikes).
I'm not aware of any organization that has the same requirements to fund its future pension obligations that the USPS has. That requirement was created by Congress as part of a sustained campaign to damage the USPS.
It seems like your argument is actually that Congress should rescind that requirement, so that USPS can afford to better service urban customers while continuing to be a critical lifeline to rural areas.
Curly braces are a very uncommon piece of punctuation outside of math and programming. If you picked a person at random, they will find "curly brace" (and indeed, "square bracket") much clearer and less ambiguous. Doubly so when accounting for variations between British and American English.
That's not what the post you're replying to said, at all.
I'm not in a position to evaluate whether they were right, but you've presented this as if it proves them wrong when it's barely related to what they said.
I'm not sure I understand your comment; OpenSCAD has functions like sphere(), cylinder(), etc. Most OpenSCAD models I have seen are built up primarily from solid primitives combined using boolean operations, just as you describe for the other tools.
> The actual ingredients are literally on the safety data sheet
This is an oversimplification, in a way that is likely not obvious to a lot of people on this (software-focused) forum. An SDS does not have to list exact amounts, does not have to disclose some details of how an ingredient or mix of ingredients was processed, and (depending on jurisdiction) may not have to identify some "safe" ingredients at all. Some ingredients may be identified in relatively vague ways, that are sufficient for safety purposes but do not reveal the exact product. As the SDS you linked to says "The specific chemical identity and exact percentages are a trade secret". An SDS is certainly very helpful to reverse-engineering a product, but it doesn't tell you everything.
All that said, yes, the main strength of WD-40 is its marketing and ubiquity, and claims about its secrecy have more to do with marketing than anything practical.
You can correlate microarchitecture to product SKUs using the Intel site that the article links. AMD has a similar site with similar functionality (except that AFAIK it won't let you easily get a list of products with a given uarch). These both have their faults, but I'd certainly pick them over an LLM.
But you're correct that for anything buried in the guts of CPUID, your life is pain. And Intel's product branding has been a disaster for years.
Intel doesn't like to officially use codenames for products once they have shipped, but those codenames are used widely to delineate different families (even by them!), so they compromise with the awkward "products formerly x" wording. Have done for a long time.
It has pretty much always been the case that you need to make sure the motherboard supports the specific chip you want to use, and that you can't rely on just the physical socket as an indicator of compatibility (true for AMD as well). For motherboards sold at retail the manufacturer's site will normally have a list, and they may provide some BIOS updates over time that extend compatibility to newer chips. OEM stuff like this can be more of a crapshoot.
All things considered I actually kind of respect the relatively straightforward naming of this and several of Intel's other sockets. LGA to indicate it's land grid array (CPU has flat "lands" on it, pins are on the motherboard), 2011 because it has 2011 pins. FC because it's flip chip packaging.