I was also surprised the first time I heard you can safely burn explosives: I was reading some comments on the Vietnam war from veterans talking about how they used to heat their meals by burning pieces of C4.
I mean, the fumes are super not good since there will be a significant amount of N20, but most explosives are very hard to set off. Sure, it's relatively easy to create chemicals that explode, but the real trick is finding ones that don't explode from the slightest bump. For example, Alfred Nobel didn't invent nitroglycerin, he invented a safe(er) way to store and transport it. TNT is actually relatively difficult to set off, even something like shooting it with a rifle won't necessarily set it off. That being said, explosives definitely can sensitize with age, which is why unexploded ordinance is so hazardous.
For reference, my father was an explosives engineer and was the point of contact for local law enforcement when they found old explosives. (this was the 90s,so they didn't have funding for a bomb disposal team and this was an area that had mining history). There were multiple buildings where he advised the safest way to deal with the old explosives (mostly dynamite, but some TNT) was to set an explosive charge near and set them off since handling them would have been too high risk. New dynamite is safe enough you could toss it onto a campfire and it won't do anything more dramatic than burn rapidly (EDIT: not a guarantee, it is potentially possible that a fire could set dynamite off so I wouldn't recommend this, but anyone who can purchase it has an explosives license and hopefully knows better), but once it has aged enough it could potentially be set off by poking it with a stick. More modern explosives like TNT don't break down quite as dramatically, and in certain conditions TNT can even be rendered inert, but given unknown environmental factors any improperly stored explosives should be treated as potentially ready to go off if they are poked gently. That said, dad definitely did dispose of the majority of the old explosives simply by burning them, sometimes in place with the fire department on site if they couldn't be safely moved. The only buildings he had to set off the old explosives in were outbuildings in remote areas, where they had been left alone for a very long time. One of the structures, he was able to see a date stamp of 1918 on the wooden crate of dynamite leaking raw nitroglycerin.
> It is funny people can't envision things breaking...
This is what enraged me about the Therac-25 design which ended up killing people. There's a whole report to read on the design, failure and follow up but to paraphrase the designers eliminated the physical locking mechanism and had this attitude that "oh it's electronic so it won't wear out and fail".
It's a bit sad to see it coming up to regularly. On the one hand it's a very classic example of programming bugs leading to injury and death. On the other hand it's so long ago that bringing it up so often makes it seem like it's the only good example of dangerous software. Software must be pretty amazing and safe that we have to keep bringing up an example from the late 80s.
Uh, no. We have plenty of examples, they just don't kill people that often, because some industries learned their lessons.
If you want recent one, 737 MAX, killed way more than Therac-25. Although it was as much fault of software as suits around it wanting to save a penny on training, because if pilots knew about how it exactly worked they could've circumvented it
The software on the MAX worked as designed/specified; unlike Therac-25 there was no bug in the critical path, it was a series of design and oversight failures pushed by business and cost cutting interests, and the actual accidents were triggered (though I wouldn't consider it causal) by hardware failure in one of the AoA sensors. There was a bug regarding displaying an AoA disagree warning to the pilots, which despite being known wasn't fixed by Boeing, but this wouldn't have actually changed anything about the plane's behaviour.
To the credit of systems engineers, I can't think of a recent high profile fatal accident that could be reasonably blamed primarily on software, but that's not so much because software is infallible, but because systems are designed to fail safe.
I don't think so? Maybe a bug of this form was found, but I'm sure nothing like that was involved in the crashes. The flight control software performed as it was designed to, it wasn't software that sent the trim wheels spinning, but a bad AOA sensor and a lack of proper safety analysis, training and procedures.
There was a bug that caused the AOA DISAGREE alert on the EICAS not to be displayed, because at some point someone misunderstood the requirement that the AOA indicator should be hidden if they didn't pay for the upgrade, but this was just an indication and wouldn't have affected control at all (though likely would have hinted the pilots to a more appropriate cause of action).
One could also consider the lack of cross-checking between the two flight computers and associated AOA sensors to be a bug, but that was how the system was intentionally designed, because AOA wasn't considered a flight-critical measurement in the system's safety assessment, so they didn't consider this required. A holistic safety analysis was never really done inclusive of MCAS though, and this requirement probably just followed on from 737NG and wasn't really considered (at least thoughtfully...) in MCAS' design.
* each flight computer used its own angle of attack sensor with no way to detect failure. Craft had 2 sensors, but they were not used together (apparently that was extra paid option...)
* pilots didn't know how the system worked or when it is active, so they were fighting against it
> Software must be pretty amazing and safe that we have to keep bringing up an example from the late 80s.
Or perhaps this failure settle the argument about whether or not physical lockouts were necessary and due to regulations you can no longer rely solely on software?
More that software that is critical is written with some level of care, and then never touched again out of fear of breaking it. See all the stories of hospital machines running windows xp.
> but to paraphrase the designers eliminated the physical locking mechanism and had this attitude that "oh it's electronic so it won't wear out and fail".
And it would have been entirely fine if there was electronic safeguards put between code and rest of the device, just like some stop lights have it (if control board sends green signal to both directions it fails out and doesn't allow that). Defense in depth and all that
Each episode focuses on a root cause analysis of a major engineering disaster. Presented in a dry but engaging way - he's a good presenter, but none of the "Radio Lab" style nonsense.
Incidentally most of them _are_ focusable by the keyboard but just aren't tabbable.
I'm using a Chrome plugin Vimium - one of the shortcuts 'f' (documented as opening links) actually highlights all focusable elements. Using this feature shows most of the checkboxes are interactive.
Edit: I guess the reason for me pointing this out is hopefully there's an easy way to make these more accessible for keyboard users.
I don't have a startup but I did make a useful little Python library while at my previous job to help ease the pain with using argparse to make CLIs.
It's called bargeparse [1]. The idea is to define an entry point function and use its signature as a means to declare the CLI arguments & options. I was surprised at how well Python's syntax for function arguments works for this... especially the use of pos-only & keyword-only arguments to force a particular style.
Wow, that looks extremely useful. I typically use docopt for all my CLI needs, but it looks like this could be really nice as well. I will have to try it the next time I'm building a CLI.
I love that! Argparse is such an old and boring solution to such a simple problem that we need more like this. And I have hope that one of the solutions will make it into the standard library at some point.
There are some others like yours:
Google's python-fire (1)
Docopt (2), which creates the cli from the documentation instead of the other way around
Typer looks neat. I don't think it was well-established when I started on this, there were quite a few offerings but the only one I managed to find was python-fire. It didn't quite do what my team wanted and there were a few behaviours that we didn't quite like so we decided to make this.
Having said that bargeparse was meant to rely solely on stdlib as the environment we were operating in was tightly controlled and any 3rd party packages had to go through a lengthy review process to be whitelisted.
Additionally, since our team (and others in our organisation) were mostly using argparse, the goal was to provide a way to declaratively interact with it using existing features in the language itself.
I used typer as an example because it has a modern twist, yet is based on click which has been the leader for 7 years.
If you want something older and with a similar api (wrapping argparse), using only the stdlib, I can ask the same question with argh, which already worked in python 2.6.
I can make a guess: GP does not know, he started working on the software and pointlessly duplicated existing projects, but with worse quality, because he neglected to survey the landscape.
I have noticed that happening regularly and out of curiousity interviewed those fellow programmers. I found out it's not because of lack of diligence, or because they attribute no value to a survey, but because of a risk-loving psychology trait that expresses itself in staking out ground and claiming it as one's own. (Armchair psychology warning, I am not qualified to make that conclusion; leave the real work confirming this hypothesis to the scientists in the field.)
IMO, this behaviour is harmful and we should work together to socially shun it like we already do for compulsive hoarding of physical objects. We have trouble finding a piece of software that works well because we spend so much effort to repeatedly sift through the mountains of published software that is mostly garbage.
Mainstream news outlets have been caught doing this. Australian ABC News (government funded) deceptively edited a Navy ceremony that showed the Governor-General & Navy Chief ogling over young women twerking [1]
Edit: I might've been mistaken here in thinking the above migration operation was automatically applied as the docs seem to suggest you need to add it yourself [2] but at least it's as easy as adding an operation ;)
