In some states, like NH, the default is that you can even hunt on other people's (privately-owned) land, unless it is posted. As a landowner, you are encouraged to allow free, recreational use of your land by others.
France also has very strong gun controls. It is of course, more complicated than that. And, by the way, a man shot and killed 12 people in the UK in 2010 with legally held rifles: https://en.wikipedia.org/wiki/Cumbria_shootings
"Cops are trained to push peoples buttons and make them lose control"
They are? I could see why, say, detectives interviewing a suspect might use that approach to try to get them to say something incriminating, but for regular cops I would think their job is made much easier if the people they interact with are calm.
Yes, you can list (and listen to) your Echo voice command history, and delete them. Frustratingly, there is no bulk delete that I have found - you have to go through them individually.
A cautionary tale: Echo starts recording when it hears the "wake" word ('Alexa' or 'Amazon'), but it can mistake other words or parts of speech for a wake word (for example, consider how close the phrase "he likes her" is to "Alexa"). Browsing through the history I have found snippets of conversations that Echo had no business listening to, and which the recorded subjects certainly did not wish to send to Amazon.
A stall warning occurs when the angle of attack (angle between the wing and the airflow) is too high to maintain lift. There is a separate instrument for detecting this (which can also be disabled by ice build up, but appeared to be working here). Low airspeed is not the only condition for a stall - it can happen even at high speed!
That will integrate other people's changes into your branch. But until you also merge your branch into master (and/or all other branches), you are not integrating your changes.
That's really a function of your QA process, not anything specific to branching strategies. If you can automate everything such that continuous delivery (or even deployment) is possible - great. If not, deliver at whatever pace your QA allows (and strive to increase that pace). Trunk based development does not imply a diminished QA process.
Yes, there is always going to be a feedback delay between you making a change and the full impact of that change being known (even if your feature is bug free, will the customer want to use it?), but we should be bringing that feedback forward by moving changes through the pipeline as early as possible. Feature branching delays feedback, which is why I reject it.
"Sure you can invest hours of your life setting up CI, then writing code, not testing it locally[...]"
Maybe I've misunderstood, but why aren't you testing it locally? With trunk based development you make your changes, run a local build and push if it passes. Everyone (including any CI servers) runs the same build process.
The trick is that you have to be able to push to master without breaking it, which is scary to many developers and usually requires a shift in thinking. How do I do large refactorings? (you don't - do many small refactorings instead). How do I add a half-finished feature? (break the feature into many smaller features, use feature toggles, etc.)
I don't consider not-branching to be a radical approach. If you are using branches you really aren't doing CI, because you aren't integrating continuously.