It may be a EU wide tale.
Edit. Didn’t realize it might just be an English version where the boy is killed and eaten. Aesop’s original didn’t have that. Just the sheep killed.
(For the curious, a subscription means free delivery. The subscription costs 10 euro a month, and if you don't have a subscription, the delivery fee is around 4 euro)
It sounds like a subscription means ad-funded delivery to me though
Personally I would absolutely refuse to pay for services that still continue to serve me ads even though I'm paying
I loathe advertising. I don't understand why most people seem so apathetic about it
I do this for different reasons. I just don't want every site knowing when I'm logged in and using my computer, which computer that is, and whatever else information they're grabbing all day.
This is called "normalization of deviance" and generally should be avoided, because it often precedes a serious accident.
You don't even need to get to the point of breaking the rules for it to be a problem. This is stupid human factors type stuff.
The filthy capitalists don't want their oil rigs going kaboom and their expensively trained workers having injury downtime. There is a natural incentive alignment to some extent here.
And then the useful idiots show up, and rather than fostering that alignment they put their thumb on the scale and they change the calculations. The filthy capitalists crunch the numbers and they realize that over the life of the oil rig and a fleet of some number of them they'll make more money spewing alarms at the guys running the place until their eyes glaze over. Sure he'll miss something important blowing up the works with loss of life and limb 2/<big number> amount of the time instead of 1/<big number> if you'd have tuned it right buuuuut, you'll lose less money that way because if you do it the "right" way you'll get dinged by the OSHA people every time some petty accident type happens because you turned the alarm for that one off so as not to fatigue people. A typical example is some industrial facility where policy defines "hot" as anything lukewarm and up and so they implicitly train people to ignore it. People are opening "hot" equipment all the time, getting approvals to do it, ignoring warning lights, etc, etc, so basically no net improvement in actual safety over having nothing at all. And this is fine until one day someone gets killed because they let loose something that was 300deg not 110. You see this goddamn fact pattern all the time. Machinery beepers, hazard signage and barriers, machinery interlocks, etc, etc, it never fucking ends.
Great job guys, Mission Accomplished (TM). When everything is a hazard nothing is.
checks notes
workplace safety, then for-profit companies could be free to act for the good of all, like they always do!
(If by "dangers of creating too many errors" you just meant "don't create too many bugs" then that's not really relevant to this conversation, and also totally the wrong lesson to learn from that incident. The lesson is, software will inevitably have bugs, so make sure you have redundant checks to minimise their impact.)
Edit: see replies, originally I wrote fuses, but hardware interlocks is more correct.
They mention that previous Therac machines had "hardware interlocks" to prevent this sort of issue - maybe those are the safety fuses you're both talking about? - but it says they were never included in Therac-25 in the first place, because the software was assumed to be so reliable, not that they were removed because they blew.
Are you sure this is the same incident? Do you have a link to a source about it?
Edit: This article cited in Wikipedia is much more comprehensive and mentions that Therac-20 did have these fuses, in addition to hardware interlocks. But they weren't disabled because the real alarms were drowned out by false alarms - instead they all represented real instances of the issue.
https://web.archive.org/web/20041128024227/http://www.cs.umd...
(Middle column of the 12th page of PDF, numbered page 29 of the publication.)
> The Therac-20 at the University of Chicago is used to teach students in a radiation therapy school conducted by the center. The center’s physicist, Frank Borger, noticed that whenever a new class of students started using the Therac-20, fuses and breakers on the machine tripped, shutting down the unit. These failures, which had been occurring ever since the center had acquired the machine, might appear three times a week while new students operated the machine and then disappear for months. Borger determined that new students make lots of different types of mistakes and use “creative methods of editing” parameters on the console. Through experimentation, he found that certain editing sequences correlated with blown fuses and determined that the same computer bug (as in the Therac-25 soft- ware) was responsible. The physicist notified the FDA, which notified Therac-20 users.*
> The software error is just a nuisance on the Therac-20 because this machine has independent hardware protective circuits for monitoring the electron-beam scanning. The protective circuits do not allow the beam to turn on, so there is no danger of radiation exposure to a patient. While the Therac-20 relies on mechanical interlocks for monitoring the machine, the Therac-25 relies largely on software.
I remember talking about it several times over my college career, and for good reason.
To this day when people start talking about software in the loop in a safety context I get extremely twitchy. I don't let that shit happen on my watch.
Today, I’d ask about more ways to push the responsibility away from the firmware to stop catastrophic failures. If the debugger pauses the CPU you can’t use the CPU to regulate things. I’ve worked on things where the failure mode can be explosive and it makes dev really harrowing if you can’t rely on hardware interlocks.
They often don't have to know how the nitty-gritty of the HW works. HALs are used everywhere, and some of them abstract a lot away. I've interviewed embedded SWEs that couldn't explain how the tri-state buffers work within GPIO.
I've seen it during my career as a software developer, too. Heaps of alert spam that remained unread because 99% of them were useless and not indicative of a problem on our end. It's important to be careful about alerts so you know when real problems occur.