Speaker 1: Welcome to tech Stuff, a production of I Heart Radios
Speaker 1: How Stuff Works. Hey there, and welcome to tech Stuff.
Speaker 1: I'm your host, Jonathan Strickland. I'm an executive producer with
Speaker 1: iHeart Radio and I love all things tech and I'm
Speaker 1: probably still running all over the United States right now
Speaker 1: on special projects. And for that reason, we are going
Speaker 1: to enjoy another classic episode of tech Stuff. This episode
Speaker 1: is called bad Computer Bugs, and it's all about software
Speaker 1: bugs that were some of the worst to ever go
Speaker 1: out with shipped projects. So let's go back and listen
Speaker 1: to this classic episode. I have to address a bit
Speaker 1: of apocryphal history, and regrettably it's a story that we've
Speaker 1: repeated on tech Stuff. So I'm sad to admit that
Speaker 1: I was complicit, although unknowingly, in the spread of misinformation
Speaker 1: and that all has to do with the origin of
Speaker 1: the term bug to describe a flaw in programming. So
Speaker 1: here's the popular story, the one that we have accidentally,
Speaker 1: uh promoted on tech Stuff without knowing that we were
Speaker 1: in the wrong. It goes that Grace Hopper, who was
Speaker 1: an early computer scientist who rose to the rank of
Speaker 1: rear admiral in the U. S. Navy coined the phrase
Speaker 1: bug after discovering a moth coming up Harvard's Market two calculator,
Speaker 1: a literal bug. Generally speaking, the story tends to be
Speaker 1: set in nineteen, and there is even a note in
Speaker 1: the log book that reads first actual case of bug
Speaker 1: being found that's attributed to Grace Hopper. But there are
Speaker 1: several points that are wrong in this story. First, the
Speaker 1: year it didn't happen in nineteen. It happened on September.
Speaker 1: We know because there's a log book. The log book
Speaker 1: that marks the incident not only has the notes, it
Speaker 1: actually has the moth taped into the book itself. It's
Speaker 1: taped onto the page. Second, Grace Hopper wasn't the person
Speaker 1: to discover the moth or make that log entry. She
Speaker 1: did tell the story about the moth several times, but
Speaker 1: it wasn't in the context of finding it or logging it.
Speaker 1: She just told the story that, yeah, we really did
Speaker 1: have a bug in the system. And most importantly, the
Speaker 1: word bug had already been used to describe design flaws
Speaker 1: for decades before the Mark two was even designed. In fact,
Speaker 1: if you look at the log book, this makes sense.
Speaker 1: It says first actual case of bug being found that
Speaker 1: sentence doesn't make sense unless you've already used the word
Speaker 1: bug to describe a flaw, because you wouldn't say, first
Speaker 1: actual case of bug being found that the wording doesn't
Speaker 1: make a sense, the context makes no sense. Sadly, there
Speaker 1: are documented quotes dating back to the nineteenth century using
Speaker 1: the word bug to mean a design fault, and it
Speaker 1: could go back even further than that. So is with
Speaker 1: much regret that I admit I have unwillingly contributed to
Speaker 1: a bit of misleading folklore making the rounds. But I'm
Speaker 1: glad I can take this opportunity to address it. All Right,
Speaker 1: so let's talk about design bugs, and I'll be covering
Speaker 1: several goofs mistakes, flubs, flaws, and outright catastrophes in this episode.
Speaker 1: But one thing I'm not necessarily going to cover our
Speaker 1: software vulnerabilities that were later exploited, either by opportunistic hackers
Speaker 1: or white hats who are just trying to improve system security.
Speaker 1: Those vulnerabilities are common in many types of software and
Speaker 1: arise not just through mistakes but sometimes simple oversights, and
Speaker 1: I think it might be more fun to look at
Speaker 1: some real bugs, like stuff that made things go wrong,
Speaker 1: stuff that may have rendered a program defunct or otherwise
Speaker 1: cau headaches. Now I'm gonna make an exception to this.
Speaker 1: I'm going to start off with the Ping of death,
Speaker 1: and I only mention it because it has an awesome name. Now,
Speaker 1: this flaw caused headaches back in ninety six. It was
Speaker 1: a flawed i P fragmentation reassembly code, and it became
Speaker 1: possible to crash lots of different types of computers using
Speaker 1: different operating systems, although Windows machines were particularly vulnerable, and
Speaker 1: this particular flaw would make a Windows machine revert to
Speaker 1: the dreaded blue screen of death. And it all happened
Speaker 1: by sending a special ping packet over the Internet. So,
Speaker 1: for those of you who aren't familiar with what that is,
Speaker 1: a ping is essentially a simple message that checks for
Speaker 1: a connection between two computers. You send one ping from
Speaker 1: a computer to another one and look for a response,
Speaker 1: so that way you verify there is in fact a connection.
Speaker 1: You can also tell other things like how fast is
Speaker 1: that connection between those two computers. Now, in this case,
Speaker 1: you would have to actually design a malformed ping request
Speaker 1: and send that to a target and it would bring
Speaker 1: that target down. That's the only security vulnerability story I
Speaker 1: really wanted to focus on. The others are all just
Speaker 1: design flaws. And let's begin with the bug that inspired
Speaker 1: me to do this episode in the first place. That
Speaker 1: Spotify bug I mentioned earlier. Ours Technica wrote a piece
Speaker 1: on it in November two thousand and sixteen, but the
Speaker 1: problem seems to date back at least as far as
Speaker 1: June two thousand sixteen, and that's when a few savvy
Speaker 1: Spotify users noticed some unusual activities on their computers. And
Speaker 1: it took a little bit of detective work, but they
Speaker 1: discovered that Spotify was apparently generating a huge amount of
Speaker 1: data on a daily basis, like gigabytes of data per day.
Speaker 1: And the culprit turned out to be a vacuum process
Speaker 1: for a database file containing the string mercury dot d b. Now,
Speaker 1: the vacuum process is the digital equivalent of vacuum ceiling.
Speaker 1: It's meant to repack data so that it takes up
Speaker 1: a space on a drive. Now, this involves building a
Speaker 1: new file to maximize efficiency, which is a good thing
Speaker 1: generally speaking. The problem was that Spotify's version was making
Speaker 1: it happen way too frequently, like on the order of
Speaker 1: once every few minutes, so that's not generally necessary. You
Speaker 1: don't need to rebuild a database file every few minutes
Speaker 1: to make sure it's the most efficient size it can be.
Speaker 1: So each rebuild represented a relatively small amount of data,
Speaker 1: but over time it added up, which meant that if
Speaker 1: you had Spotify on on your computer, even if it
Speaker 1: was just running in the background, it would be generating
Speaker 1: gigabytes worth of information rewriting this file over and over.
Speaker 1: Now it wasn't filling up a hard drive. It was
Speaker 1: just overriding the same file. Now, if it had been
Speaker 1: filling up a hard drive, people would have noticed much earlier,
Speaker 1: and it wouldn't have just been savvy Spotify users, because
Speaker 1: you would suddenly notice, hey, I don't I can't save
Speaker 1: anything to my hard drive because things filling up. Instead, Again,
Speaker 1: it was just sort of writing and deleting and writing
Speaker 1: and deleting the same file over and over again. And
Speaker 1: that probably doesn't sound like a big deal, but it
Speaker 1: is a problem if you're using a solid state drive
Speaker 1: or s s D. So one of the drawbacks of
Speaker 1: an ss D is that over time it loses storage capacity.
Speaker 1: Like you can store less data on an ss D
Speaker 1: over time. Now by overtime, I generally mean over a
Speaker 1: great deal of time and a lot of different data
Speaker 1: being written to it and overwritten. Uh. Generally speaking, most
Speaker 1: of us end up replacing our drives before we get
Speaker 1: to a point where the loss of capacity is a
Speaker 1: real issue. But similar in a way to how a
Speaker 1: battery can lose its ability to hold a full charge
Speaker 1: after you've gone through lots of charging and discharging cycles,
Speaker 1: you know how a battery won't be able to to
Speaker 1: hold as much even if it says it's up to
Speaker 1: a percent, but a hundred percent doesn't last you as
Speaker 1: long as it used to. That's because it's capacity need
Speaker 1: to hold a full charge has decreased over time. But
Speaker 1: let's say you've got a program that's just constantly overwriting
Speaker 1: data to your drive, you might discover that your ss
Speaker 1: D S useful lifespan has been drastically reduced. So as
Speaker 1: I record this episode, Spotify has already rolled out an
Speaker 1: updated version of its desktop application, and that, by the way,
Speaker 1: is the only version of Spotify that was affected. If
Speaker 1: you use web based Spotify or mobile Spotify, you're in
Speaker 1: the clear already. If you use a desktop version, as
Speaker 1: long as you have version one point zero point four
Speaker 1: two or later, you are fine. But if you did
Speaker 1: have that earlier version and you just had Spotify running
Speaker 1: on in the background, chances are it was writing to
Speaker 1: your hard drive like crazy. So what about some of
Speaker 1: the other big bugs in computer history? Well, some of
Speaker 1: the real doozies involve our attempts to explore the final frontier.
Speaker 1: So we'll be talking about space a few times in
Speaker 1: this episode, and we'll start with an early US satellite.
Speaker 1: So first up is a nineteen sixty two blunder involving
Speaker 1: the Mariner one. So some backstory on this one. Uh,
Speaker 1: We're gonna talk a lot about the Soviet Union in
Speaker 1: this episode too. It takes a couple of roles as
Speaker 1: we go on. But in this case, the then USSR
Speaker 1: had launched Sputnik into orbit in nineteen fifty seven, which
Speaker 1: really kicked off the space race and also was a
Speaker 1: big shot in the Cold War because of so Union
Speaker 1: was essentially saying, hey, we can launch this into space,
Speaker 1: we could also launch something at you in response to
Speaker 1: the US and done sort of the same thing. They
Speaker 1: had launched some satellites into space, and the Mariner one
Speaker 1: was going to be a big, big, feather in the
Speaker 1: cap of the US. The whole idea was to launch
Speaker 1: a probe that would be a fly by probe and
Speaker 1: it would go by Venus. So uh NASA, which was
Speaker 1: newly formed in nineteen sixty two, was taking control of
Speaker 1: this and the budget for this particular project was eighteen
Speaker 1: point five million dollars, which if you were to adjust
Speaker 1: for inflation, would be almost a hundred fifty million dollars today,
Speaker 1: So a hundred fifty million dollar project to launch the
Speaker 1: Mariner one and have it fly by Venus. But as
Speaker 1: I'm sure you guys have figured out by now based
Speaker 1: upon the topic of this podcast, not all went according
Speaker 1: to plan. Not long at all. After the rocket launched
Speaker 1: from the launchpad, it began to veer off course, and
Speaker 1: neither the computer controls on the rocket or manual controls
Speaker 1: back at HQ could correct for the problem. The rockets
Speaker 1: course was such that it was going to take it
Speaker 1: over shipping lanes, which meant there could be a potential catastrophe,
Speaker 1: and so Arrange safety officer made the difficult call and
Speaker 1: issued the command to blow the whole thing up just
Speaker 1: shy of three hundred seconds after it launched. So what happened.
Speaker 1: What why did it go off course in the first place, Well,
Speaker 1: there was a flaw in the spacecraft's guidance software which
Speaker 1: diverted the rocket, and no amount of commands from ground
Speaker 1: control could correct for it. After a lengthy investigation, NASA
Speaker 1: discovered the era error was the result of a mistake
Speaker 1: transcribing handwritten notes into computer code. So someone just took
Speaker 1: some handwritten notes and misinterpreted one of them, and that
Speaker 1: one mistake was enough to crash the rocket or to
Speaker 1: to necessitate it being destroyed. The great science fiction author
Speaker 1: Arthur C. Clark wrote that the Mariner one was wrecked
Speaker 1: by the most expensive hyphen in history, which isn't quite right,
Speaker 1: but it's pretty funny. I mean, come on, it's humorous phrase.
Speaker 1: So the actual punctuation mark that caused the problem was
Speaker 1: not technically a hyphen. It was a superscript bar. Superscript
Speaker 1: of bars, by the way, not a place where playwrights
Speaker 1: hang out to get tore up. A superscript barge means
Speaker 1: it's a horizontal bar that is above some other symbol.
Speaker 1: In this case, it was a radius symbol, and that
Speaker 1: was a symbol along with the superscript bar to describe
Speaker 1: a smoothing function, which means the formula was meant to
Speaker 1: calculate smoothed values over the time derivative of a radius. Now,
Speaker 1: without the smoothing function, tiny deviations in course sent commands
Speaker 1: to the rockets thrusters to kick in big time to
Speaker 1: overcorrect for that problem. As an analogy, imagine you're driving
Speaker 1: a vehicle and you see a pothole in the road
Speaker 1: and you're approaching it, and instead of gently steering out
Speaker 1: of the way, you wrenched the wheel really hard to
Speaker 1: the left or to the right in order to try
Speaker 1: and get around this pothole. That's kind of what was
Speaker 1: happening with the rocket. It didn't have the smoothing function,
Speaker 1: and so as a result, it was having these wild
Speaker 1: deviations and course. So it wasn't a hyphen that caused
Speaker 1: the problem, but is close enough. Our next space story
Speaker 1: takes place in nine with the European Space Agencies ARIANE
Speaker 1: five Flight five O one rocket. Now, this rocket was
Speaker 1: to launch into space on June four nine and instead
Speaker 1: the rocket disintegrated forty seconds after taking off. So what
Speaker 1: the heck happened? Well, it largely had to do with
Speaker 1: the E s A reusing old work. This actually becomes
Speaker 1: a theme in this episode. One of the morals of
Speaker 1: of this entire podcast is if you're designing something a
Speaker 1: successor to an earlier product, and you'd want to reuse
Speaker 1: some of the features that you created in your previous product,
Speaker 1: test the heck out of it in its new form factor,
Speaker 1: because it could be that things that worked perfectly fine
Speaker 1: in the earlier model will go awry in the new one.
Speaker 1: That's what happened here, So as you might guess from
Speaker 1: the name, the ARIANE five marked the fifth generation of
Speaker 1: launch vehicles under that name. The Arian four's inertial reference
Speaker 1: system would convert sixty four bit floating point numbers into
Speaker 1: a sixteen bits signed integer, and it worked just fine.
Speaker 1: But the Arian five stats were beefier than its predecessor
Speaker 1: with faster engines, and that was where the problem really started.
Speaker 1: The engine output meant those sixty four bit floating point
Speaker 1: numbers were significantly larger than the ones generated by the
Speaker 1: engines on the Arian four. They didn't anticipate this, so
Speaker 1: during the conversion process there was actually data overflow, and
Speaker 1: that overflow caused both the backup computer and the primary
Speaker 1: computer aboard the are N five to crash, and they
Speaker 1: crashed in that order. The backup computer crashed first, followed
Speaker 1: by the primary computer a couple of seconds later. The
Speaker 1: whole thing took less than a minute to go from
Speaker 1: launch to disintegration. Oops, now we're gonna stick with space.
Speaker 1: But jumped forward to and the Mars Climate Orbiter. This
Speaker 1: was an unfortunate problem. So this particular spacecraft was meant
Speaker 1: to study Mars's climate, atmosphere and surface changes, and it
Speaker 1: was also supposed to be a kind of relay station
Speaker 1: for landers that would explore Mars's surface, but none of
Speaker 1: that would last because of some pretty significant goofs. So
Speaker 1: on September, the orbiter passed into the upper atmosphere of
Speaker 1: Mars and did so at a pretty low altitude. And
Speaker 1: this is what folks in the space industry called a
Speaker 1: bad thing. The drag on the spacecraft was significant. It
Speaker 1: began to fall apart and it was destroyed upon entering
Speaker 1: Mars's atmosphere. That's what happened. So the software guiding the
Speaker 1: orbiter was to blame, and it's a dumb, dumb mistake.
Speaker 1: It was supposed to make adjustments to the orbiter's flight
Speaker 1: in SI units specifically in Newton seconds. That's what the
Speaker 1: contract with Lockheed and NASA said, Newton seconds use SI
Speaker 1: units for all of your all of your calculations, but
Speaker 1: the software instead made calculations in non SI units, namely
Speaker 1: pounds seconds. So Lockheeds software gave information to NASA's systems
Speaker 1: using the wrong units of measure. NASA systems then took
Speaker 1: the information, assuming it was with the right units of measure,
Speaker 1: and executed commands based upon that. Uh So, this is
Speaker 1: why if you're ever in a math course and the
Speaker 1: teacher makes you stop in the middle of writing a
Speaker 1: problem on the board and says, where are your units?
Speaker 1: This is why you have to make sure you're using
Speaker 1: the right units, because if you're saying a number and
Speaker 1: you don't associate a unit with it, someone could make
Speaker 1: an incorrect decision based on that and it could be disastrous,
Speaker 1: as it was with the case of this orbiter. The
Speaker 1: thrusters fired at four point four or five times the
Speaker 1: power they were supposed to, and the orbiter didn't stand
Speaker 1: a chance. And this was a pretty expensive mistake. That
Speaker 1: mission's cost came in at three seven point six million dollars.
Speaker 1: But on the bright side, with all of these stories,
Speaker 1: at least no human lives were ever in real danger
Speaker 1: as a result of the mistake. Now I've got a
Speaker 1: lot more to say about bugs, but before I get
Speaker 1: into that, let's take a quick break to thank our sponsor.
Speaker 1: All right, Now, let's make a switch to A T
Speaker 1: and T, which is a company that had a pretty
Speaker 1: big problem with switches once upon a time. I'm talking
Speaker 1: about an issue that popped up on January. That's when
Speaker 1: A T and T long distance customers discovered they were
Speaker 1: unable to make any long distance calls. Why why could
Speaker 1: they no longer reach anybody? Well, A T and T
Speaker 1: s long distance switches, which control that and allow for
Speaker 1: the actual connections to be made, were on the fritz.
Speaker 1: They were trying to reboot over and over again. They
Speaker 1: were just stuck in a reboot cycle. Now, initially the
Speaker 1: company thought it was being hacked, But like I said
Speaker 1: at the top of the show, I'm not covering stories
Speaker 1: about hackers here. I'm talking about big design flaws that
Speaker 1: caused problems. So they weren't getting hacked. That's not what
Speaker 1: was going on with those D fourteen long distance switches. No,
Speaker 1: there was a design problem at fault, so What had
Speaker 1: happened was a T and D had rolled out an
Speaker 1: update to the code that managed the switches, and it
Speaker 1: was meant to increase the efficiency. It was meant to
Speaker 1: speed things up. But the problem was it sped things
Speaker 1: up so much that the system got caught up in itself.
Speaker 1: It gets pretty technical, but I can give you kind
Speaker 1: of a overview of what the problem was. Alright, so
Speaker 1: each switch had a function that allowed it to alert
Speaker 1: the next switch down the line if things were starting
Speaker 1: to get harry. So imagine the switch number one is
Speaker 1: handling traffic, but it's getting really close to capacity. So
Speaker 1: it sends a message over to switch number two and says,
Speaker 1: I can't take on any more work because if I do,
Speaker 1: I'll be overloaded. Switch to then says, no problem, I'll
Speaker 1: take on the any oncoming work for you and we'll
Speaker 1: handle it from there. And if switched number two order
Speaker 1: to get into the same source situation, it would say
Speaker 1: the same thing to switch number three, and so on
Speaker 1: and so forth. Now, eventually each switch will contact the
Speaker 1: one below it and say, hey, how are you doing there?
Speaker 1: And if the answer is okay, then everything switches back
Speaker 1: and you go back to normal operation. That's how it's
Speaker 1: supposed to work up. But A T and He's updated
Speaker 1: code sped things up so much it caused some real issues,
Speaker 1: and there was some poor timing, just coincidental timing that
Speaker 1: made things worse. So switch number one starts to get
Speaker 1: overwhelmed and sends a message over to switch number two,
Speaker 1: But switched number two was just in the middle of
Speaker 1: resetting itself. So switch number two goes into reset mode,
Speaker 1: which says do not disturb. Sends a message over to
Speaker 1: switch number three. That prompted switched number three to overload
Speaker 1: and put up a do not disturb sign. Move that
Speaker 1: down to switch number four. This whole thing goes down
Speaker 1: the entire line of on switches. They all end up
Speaker 1: getting overloaded as a result of this, and I'll go
Speaker 1: into reset mode and they get stuck there. That problem
Speaker 1: lasted for nine hours before A T and T was
Speaker 1: finally able to address the message load on the entire
Speaker 1: system and get the switches back to normal. The estimated
Speaker 1: cost of lost revenue for that time was about sixty
Speaker 1: million dollars in long distance calls, and there were a
Speaker 1: lot of angry customers to boot, so to placate them,
Speaker 1: A T and T offered reduced long distance rates on
Speaker 1: Valentine's Day pretty ugly by the A, T and T
Speaker 1: tried to handle it, at least in a way that
Speaker 1: didn't turn it into a pr nightmare. Not so with Intel.
Speaker 1: That's what it brings us to the Pendium problem. I
Speaker 1: don't know if you guys remember when Penium processors first
Speaker 1: came out, but they were a big deal. It was
Speaker 1: a redesign of the architecture of the microprocessor and it
Speaker 1: was meant to really speed things up. Well, Intel had
Speaker 1: a massive nightmare in n thanks to a flaw in
Speaker 1: the entire first generation of Pentium processors. Now, when you
Speaker 1: break it all down, a CPU is all about performing
Speaker 1: mathematical operations on data, so it's kind of important that
Speaker 1: does this correctly. Unfortunately, the flaw and the Pentium processors
Speaker 1: kind of messed that up. And the issue has to
Speaker 1: do with floating point operations. So the predecessor to the Pentium,
Speaker 1: the four six, used a shift and subtract algorithm for
Speaker 1: floating point operations, which was effective but relatively slow compared
Speaker 1: to what Intel thought they could do by totally redesigning
Speaker 1: that structure and using a look up table approach. Now,
Speaker 1: the table was supposed to have one thousand sixty six
Speaker 1: entries programmed directly onto the logic array of the Pentium processor,
Speaker 1: but for some reason only one thousand sixty one entries
Speaker 1: made it. Five entries went missing and essentially returned an
Speaker 1: answer of zero instead of what they were supposed to say,
Speaker 1: so if a calculation accessed one of those missing cells,
Speaker 1: it got zero, even though that's not the correct answer.
Speaker 1: All the first generation pentiums went out with this error
Speaker 1: because it was so minor that it wasn't even picked
Speaker 1: up by Intel's quality control at the time. Now, processes
Speaker 1: worked just fine up to the eighth decimal point. Beyond
Speaker 1: that things got messy, But for most folks that wasn't
Speaker 1: a problem because they weren't doing mathematical calculations that needed
Speaker 1: that level of precision. It just wasn't a thing. In fact,
Speaker 1: there was only a one in three sixty billion chance
Speaker 1: that this error would cause a big enough problem to
Speaker 1: reach up to the fourth decimal place. So most calculations
Speaker 1: that were simple were bulletproof. You you were fine. But
Speaker 1: if you needed that precision, if you needed that really
Speaker 1: fine degree, that's when you would encounter the flaw, and
Speaker 1: that happened because there are math professors in this world,
Speaker 1: and one of those, Thomas Nicely, discovered in October that
Speaker 1: he was getting errors because of this issue. He needed
Speaker 1: the processor to work correctly, and so he contacted Intel
Speaker 1: about the problem. And this is where we take a
Speaker 1: moment to acknowledge there's a right way and a wrong
Speaker 1: way to handle an issue. That's your fault until decided
Speaker 1: to go the wrong way. My opinion is, if you
Speaker 1: make a mistake, it's usually a good idea to just
Speaker 1: own up to it and try to make it better.
Speaker 1: But Intel's response was more along the lines of, yeah,
Speaker 1: we didn't think it was a big deal. And then
Speaker 1: Intel made other pr blenders. But because people began to hear, hey,
Speaker 1: that pentium processor in your computer that you just bought,
Speaker 1: it doesn't work properly. So people wanted to get replacements.
Speaker 1: But Intel said, oh, we're only going to replace the
Speaker 1: ones if you can prove that the mistakes that it
Speaker 1: makes affect you in some meaningful way. So they weren't
Speaker 1: They weren't denying that there was a problem. They were
Speaker 1: just saying, hey, unless you can prove the problem affects you,
Speaker 1: where we don't care that didn't go well. If you
Speaker 1: create a product and you market it as the future
Speaker 1: of computing, and then it's discovered there's a flaw on
Speaker 1: the design, and then you say we'll replace it, but
Speaker 1: only if you prove you deserve it, it doesn't end
Speaker 1: to make your customer base very happy. So ultimately, until
Speaker 1: reverse that decision and offered to replace the processor for
Speaker 1: anyone who wanted it who had a first generation Pentium,
Speaker 1: and that mistake ended up costing the company four seventy
Speaker 1: five million dollars. Yikes. All right, now we're gonna switch
Speaker 1: Gears over to Microsoft. First, I think you could claim
Speaker 1: that all of Microsoft Bob product that was supposed to
Speaker 1: be an easy, accessible computer interface was really just a
Speaker 1: massive software bug. I mean, it introduced comic sands for
Speaker 1: goodness sakes, The cluttered organization system, the lack of meaningful security,
Speaker 1: and other numerous issues plagued that software. But we did
Speaker 1: an entire episode of Tech Stuff about Microsoft Bob a
Speaker 1: couple of years ago, so I'm not gonna dwell on
Speaker 1: it anymore, but if you want to hear more about it,
Speaker 1: go find that episode. It was a fun one. Now
Speaker 1: into the seven Microsoft experienced a massive headache when a
Speaker 1: bug on their servers notified thousands of Windows customers that
Speaker 1: they were filthy, dirty software pirates and they should be punished.
Speaker 1: These include people who actually had legitimate, legal purchase copies
Speaker 1: of Windows XP or Vista. So the problem here was
Speaker 1: Microsoft had an initiative called Windows Genuine Advantage, and it
Speaker 1: was a nice name for a strategy meant to curtail
Speaker 1: operating system piracy. Essentially, it was a component in Windows
Speaker 1: that would allow Microsoft to figure out if the copy
Speaker 1: of Windows on any given computer was legit. In other words,
Speaker 1: it was a d r M strategy. But in two
Speaker 1: thousand seven, a buggy install of software on a server
Speaker 1: misidentified thousands of legitimate, law abiding customers as pirates for
Speaker 1: nineteen hours. The software just laid down the law, and
Speaker 1: so people began to receive sternly written warnings about their
Speaker 1: choice to indulge in bad behavior. And if you were
Speaker 1: a Windows Vista customer, you had it the worst, not
Speaker 1: just because you were using Windows Vista, which I think
Speaker 1: we all agree was not one of the bright points
Speaker 1: and Microsoft's operating system history, but also because Microsoft had
Speaker 1: built in the ability for Windows Genuine Advantage to switch
Speaker 1: off certain operating system features in Windows Vista if it
Speaker 1: determined that the copy someone was using was a pirated version,
Speaker 1: so it was misidentifying real versions as pirated ones, turning
Speaker 1: off features, and these are for people who have bought
Speaker 1: legitimate copies. This, by the way, is one of the
Speaker 1: big arguments people have against DRM. It has the tendency
Speaker 1: to punish legitimate customers. And you feel like you're stupid
Speaker 1: for buying a copy of a piece of software rather
Speaker 1: than just stealing one that has had those features or
Speaker 1: those defenses removed. Like why you're you're creating more incentives
Speaker 1: for people to go outside and get a pirated copy. Alright,
Speaker 1: so imagine you've purchased this legitimate copy of Windows Vista.
Speaker 1: First of all, you you already feel bad. Then you're
Speaker 1: told you're a thief, so you feel worse. Then someone
Speaker 1: remotely switches off several features of your operating system. That
Speaker 1: was not a great pr message, So that was a
Speaker 1: real issue. They did eventually fix it after that nineteen hours,
Speaker 1: but by then people were already very upset. Also, I
Speaker 1: don't wanna just, you know, pile lots of abuse onto Microsoft.
Speaker 1: I gotta talk about Apple here too. So the company
Speaker 1: prides itself on a high standard of quality, and in
Speaker 1: general it's pretty good about living up to that standard
Speaker 1: of quality, depending upon your point of view of their
Speaker 1: various products. But that hasn't stopped a few clunkers getting
Speaker 1: through and into the public hands. And that was the
Speaker 1: case in two thousand twelve with Apple Maps. If you
Speaker 1: owned an iPhone back in two thousand twelve when Apple
Speaker 1: Maps came out, you may remember this problem. It's pretty
Speaker 1: well publicized. Maps were inaccurate, sometimes leaving out important details
Speaker 1: like you know, a river or a lake between you
Speaker 1: and your destination, things that might be important if I
Speaker 1: don't know you don't drive an amphibious vehicle, might not
Speaker 1: have a road on there that's important. Might misidentify the
Speaker 1: location of a historical landmark. For instance, that thought the
Speaker 1: Washington Monument was across the street from where it is,
Speaker 1: But nope, it's just where we left it. Despite all
Speaker 1: of roland emericks best attempts to move it or destroy it,
Speaker 1: it's still there. The real problem here was that the
Speaker 1: Apple software just wasn't ready for public unveiling. It was.
Speaker 1: It needed a lot more testing. It was trying to
Speaker 1: play catch up to Google Maps, but Google had the
Speaker 1: advantage of working with companies that have been doing mapping
Speaker 1: software for years. Google acquired those companies and acquired the
Speaker 1: expertise of people who have been working that software, and
Speaker 1: Apple was really just trying to create their own version
Speaker 1: and get it out as fast as it could. But
Speaker 1: it got out a little too early, and the company
Speaker 1: spent the next several months tweaking maps and trying to
Speaker 1: keep control of the situation. But by that time, many
Speaker 1: of Apple's fans, even the most devoted ones, had kind
Speaker 1: of given up and switched over to Google Maps instead. Well,
Speaker 1: that's most of the fun stuff. I've got some really
Speaker 1: serious bugs to cover. But before I do that, let's
Speaker 1: take another quick break and thank our sponsor. Now I'm
Speaker 1: going to transition into some serious bugs. These are ones
Speaker 1: that either threatened the lives of people or they contributed
Speaker 1: to people dying. The ones I've talked about now up
Speaker 1: to now rather have cost companies millions of dollars, but
Speaker 1: no one's life was truly threatened on Fortunately, that's not
Speaker 1: the case with all software bugs. Now, a couple of
Speaker 1: bugs had the potential to kill millions of people. One
Speaker 1: of those happened in nineteen eighty a famous famous bug,
Speaker 1: or at least a faulty circuit, and that was a
Speaker 1: faulty circuit in nora ADS computer system which caused it
Speaker 1: to mistakenly conclude the US was under nuclear attack from
Speaker 1: the Soviet Union. So displays on nora AD systems showed
Speaker 1: seemingly random attacks, and they didn't correspond with each other.
Speaker 1: So the display might show, Hey, there two missiles heading
Speaker 1: over from the Soviet Union. No, they're two hundred. No
Speaker 1: they're fifty. No there's three, And it wasn't consistent, and
Speaker 1: command posts around the US all had conflicting information, which
Speaker 1: led leaders to conclude the whole thing was a regrettable
Speaker 1: computer error, and they were right to do so. To
Speaker 1: be fair, they were kind of prepared for this because
Speaker 1: there was another incident that it actually happened in nineteen
Speaker 1: seventy nine that was a scarier and in that case,
Speaker 1: someone mistakenly inserted a training scenario into the computer system
Speaker 1: that made it seem like the Soviet Union had launched
Speaker 1: an all out nuclear attack on the US. But that
Speaker 1: wasn't a bug. That was a mistake on the part
Speaker 1: of a human who had accidentally uploaded the wrong or
Speaker 1: rather executed the wrong command. It didn't have something to
Speaker 1: do with a flaw in the computer system itself. However,
Speaker 1: because that thing happened and everybody was freaked out and
Speaker 1: then was able to determine that, in fact it was
Speaker 1: a false alarm, it meant that calmer heads could prevail.
Speaker 1: In the nineteen eighty incident, so the Soviets also had
Speaker 1: a close call just a few years later. It was
Speaker 1: a bug in the early warning detection software that the
Speaker 1: USSR was using in the early eighties, and on September
Speaker 1: twenty three, Night three and so Union received an alert
Speaker 1: that the US had launched a nuclear attack in the
Speaker 1: form of five nuclear warheads UH technically two different attacks.
Speaker 1: The first would have been a single nuclear warhead and
Speaker 1: the second was four nuclear warheads, and this was during
Speaker 1: a particularly stressful period in the history of both countries
Speaker 1: and their relationship with each other, at the height of
Speaker 1: the Cold War nine three now fortunately UH Soviet Air
Speaker 1: Defense Forces Lieutenant Colonel Stanislav Petrov suspected that this report
Speaker 1: was an error and that there was some sort of
Speaker 1: bug in the software or a mistake in the reporting
Speaker 1: system that caused this. He gave a command to hold
Speaker 1: off on any sort of retaliatory strike, which would have
Speaker 1: initiated a full scale nuclear war had it happened. Petrov
Speaker 1: was the officer in charge of a a bunker that served
Speaker 1: as the command center for this early warning system, and
Speaker 1: he he had said afterward that his reckoning was any
Speaker 1: real attack would consist of hundreds of warheads, not five.
Speaker 1: No one would start an attack with just five warheads,
Speaker 1: so it was more likely to be an error than
Speaker 1: a genuine attack. So he gave the command to wait
Speaker 1: until the reported missiles would pass into the range of radar,
Speaker 1: which only extended as far as the horizon, so if
Speaker 1: it had in fact been a real attack, it would
Speaker 1: have potentially limited the Soviet Union's ability to respond. But
Speaker 1: no missile showed up, and he was vindicated in his decision. Now,
Speaker 1: the cause of the false alarm in this case was
Speaker 1: a combination of factors that the designers didn't anticipate, uh
Speaker 1: which largely consisted of sunlight hitting high altitude clouds at
Speaker 1: a particular angle from a particular perspective of the satellites,
Speaker 1: So the satellites misidentified that reflection as a warhead. Now
Speaker 1: they were the subviys were able to address this error
Speaker 1: in the future by adding another step in which these
Speaker 1: satellites would cross reference data from other geostationary satellites to
Speaker 1: make certain and that they are identifying actual rockets as
Speaker 1: opposed to high altitude clouds. Now, there are several cases
Speaker 1: of software bugs leading to actual deaths. For example, the
Speaker 1: the RACK was such a case. Now that was a
Speaker 1: radiation therapy machine that could deliver two different modes of
Speaker 1: radiation treatments. The first was a low powered direct electron
Speaker 1: beam and the second was a mega volt X ray beam. Now,
Speaker 1: the x ray beam was far more intense and it
Speaker 1: required physicians to provide shielding to patients to limit exposure
Speaker 1: to the beam. But the therac had inherited its code
Speaker 1: from its predecessor, which had different hardware constraints. Now the
Speaker 1: new machine meant that these constraints weren't there, and it
Speaker 1: created a deadly problem if operators changed the machines mode
Speaker 1: too quickly from one to the other, it would actually
Speaker 1: send two sets of instructions to the processor, one for
Speaker 1: each mode of operation, and whichever set of instructions reached
Speaker 1: the processor first, that's what the machine would switch to.
Speaker 1: So let's say you've been operating the THERAC in the
Speaker 1: mega volt X ray mode, but now you're going to
Speaker 1: have a patient come in. You need to administer radiation therapy,
Speaker 1: so you want to switch it to low electron. Being
Speaker 1: you switch it too quickly, it sends two sets of
Speaker 1: instructions to the processor, and the one that arises the
Speaker 1: mega volt x ray instruction, so instead of switching it,
Speaker 1: you confirm to stay on the more intense, deadlier radiation.
Speaker 1: The tragic news is this did happen several times. Six
Speaker 1: patients were documented as dying from complications due to radiation
Speaker 1: poisoning from THERAC twenty machines between night five and nineteen
Speaker 1: eight six, and while the machine would send error messages
Speaker 1: when these conditions were present, the documentation for the machine
Speaker 1: didn't explain what the errors meant. It didn't say, hey,
Speaker 1: if you get this error, it means that you've switched
Speaker 1: modes too quickly and you need to address this. So,
Speaker 1: since operators weren't told that this was necessarily a hazardous condition,
Speaker 1: they would just clear the error and proceed, and there
Speaker 1: were deadly results. In a similar vein in Panama City, Panama,
Speaker 1: there was an incident involving a Cobalt sixty system, actually
Speaker 1: several incidents involving this Cobalt sixty system that was running
Speaker 1: therapy planning software made by a company called Multi Data
Speaker 1: Systems International. Now, the software's purpose was to calculate the
Speaker 1: amount of radiation that cancer patients should receive in a
Speaker 1: radiation therapy sessions. During these radiation therapy sessions, the therapists
Speaker 1: were meant to place metal shields on the patient to
Speaker 1: protect healthy tissue from radiation damage. And the software would
Speaker 1: allow therapists to use a methodology to show where those
Speaker 1: shields were on the patient, to indicate where the shields
Speaker 1: are present. But they could only draw up to four shields,
Speaker 1: and the doctors in Panama wanted to use five shields
Speaker 1: for particular therapy sessions. They were overloaded, they had a
Speaker 1: long waiting list of patients, and they were trying to
Speaker 1: make things more efficient, and they discovered that they could
Speaker 1: kind of work around this limitation of four shields by
Speaker 1: drawing a design on the computer screen as if they
Speaker 1: were using just one large shield that has a hole
Speaker 1: in the middle of it. And so what they would
Speaker 1: do is they would arrange the five shields to essentially
Speaker 1: be in the same sort of shape with the middle
Speaker 1: of it being open so that they can have the
Speaker 1: radiation therapy passed through it. Uh, But they didn't realize
Speaker 1: that the software had a bug in it, and that
Speaker 1: bug was if you drew the hole in one direction,
Speaker 1: you get the correct dose of radiation, but if you
Speaker 1: drew it in the other direction, so like clockwise versus counterclockwise,
Speaker 1: the software would recommend a dosage twice as strong as
Speaker 1: what was needed, and the result was devastating. Eight patients
Speaker 1: died as a result of this, and another twenty received
Speaker 1: doses high enough to potentially cause health problems. Later on,
Speaker 1: the physicians were actually arrested and brought up on murder
Speaker 1: charges because they were supposed to double check all calculations
Speaker 1: by hand to ensure that they were going to give
Speaker 1: the proper dose of radiation treatment. So while the software
Speaker 1: was calculating the incorrect dose, the physicians were responsible for
Speaker 1: making sure that any dose that was calculated was in
Speaker 1: fact the correct one, and they failed to do so,
Speaker 1: or at least that was the charge. There are also
Speaker 1: bugs that involved military applications that have resulted in the
Speaker 1: loss of life. During the Persian Gulf War in Iraqi
Speaker 1: fired scud missile hit a US base in Saudi Arabia
Speaker 1: and it killed twenty eight soldiers. Now the base had
Speaker 1: detected the missile and had launched and fired a Patriot
Speaker 1: missile in return. The purpose of the Patriot missile was
Speaker 1: to intercept and destroy incoming missiles, and the way a
Speaker 1: Patriot missile did this was to use radar pulses to
Speaker 1: guide trajectory calculations so that it would end up getting
Speaker 1: close to the incoming missile. This is harder than it sounds,
Speaker 1: because both missiles are moving very very quickly, so we
Speaker 1: need a very precise information in order to adjust its
Speaker 1: trajectory properly and make sure it was on target. Now,
Speaker 1: once it gets within range, which is between five and
Speaker 1: ten meters I think uh, it would then fire out
Speaker 1: thousand pellets from the Patriot missile at high velocity with
Speaker 1: the goal of causing the incoming warhead to explode prematurely.
Speaker 1: In this case, the Patriot missile missed, and the military
Speaker 1: investigated the issue in the wake of the loss of
Speaker 1: life and found a problem with the software guiding the
Speaker 1: Patriot missile. And it was a problem that actually the
Speaker 1: military kind of knew about already. So one of the
Speaker 1: processes in the Patriots programming was to avert time into
Speaker 1: floating point operations for increased accuracy. But not all subroutines
Speaker 1: that depended on tracking time did this. Some of them
Speaker 1: remained UH clock units rather than floating point operations, which
Speaker 1: meant that they would get out of sync after a while.
Speaker 1: There'd be a disagreement in various subroutines as to what
Speaker 1: how much time had actually passed. And like I said,
Speaker 1: the military was aware of this issue and they had
Speaker 1: a work around, which was not ideal. The workaround was
Speaker 1: you would occasionally reboot the system, which would reset the
Speaker 1: clocks and synchronize them, but over time they would fall
Speaker 1: out of sync because they're not tracking time the same way.
Speaker 1: And since there was no hard and fast rule as
Speaker 1: to how frequently you'd reset the system, problems like this
Speaker 1: one where possible, and in fact, in this case it
Speaker 1: did happen. So prior to this particular incident, that specific
Speaker 1: Patriot system had been running for one hours without a reboot,
Speaker 1: and the clock disagreement amounted to about one third of
Speaker 1: a second. Now that seems like it's no time at all.
Speaker 1: One third of a second is so so short, But
Speaker 1: a scutt missile's top speed is about one point one
Speaker 1: miles per second or one point seven kilometers per second,
Speaker 1: which means if you take a third of a second,
Speaker 1: the missile could travel more than five And since the
Speaker 1: patriot needs to be within ten meters of a target
Speaker 1: to destroy it, that resulted in a catastrophic failure. So
Speaker 1: software bugs can be a matter of life or death.
Speaker 1: It's not all just Hey, this irritating thing meant people
Speaker 1: couldn't make long distance phone calls or uh, this issue
Speaker 1: caused my computer to start writing massive amounts of data
Speaker 1: to its hard drive. And this is why it's so
Speaker 1: important to have really qualified QA personnel go through code
Speaker 1: and make sure it's doing what it's supposed to do,
Speaker 1: because the problems that can arise can be non trivial
Speaker 1: and in fact life or death situations depending upon the
Speaker 1: application of technology. So technology is a fascinating thing. It's
Speaker 1: a wonderful thing. It has benefited us in ways that
Speaker 1: I can't even begin to describe. It's just too broad
Speaker 1: a topic, and it's something I've been tackling for, you know,
Speaker 1: eight years, and I haven't haven't even gotten close to
Speaker 1: getting toward the finishing point. So I don't want to
Speaker 1: suggest that technology is bad, but we definitely have the
Speaker 1: need to check, double check, and triple check all this
Speaker 1: work to make certain things are working properly before we
Speaker 1: release them out into the wild. That particularly applies if again,
Speaker 1: you are reusing old code or old components in a
Speaker 1: new way, because you have to make absolutely certain that
Speaker 1: there's not going to be some unintended problem that results
Speaker 1: when a new form factor is using old code. And
Speaker 1: that wraps up that classic episode of tech Stuff. Hope
Speaker 1: you guys enjoyed it. If you have any requests, questions, comments,
Speaker 1: you can email me the addresses tech stuff at how
Speaker 1: stuff Works dot com, or you can reach out on
Speaker 1: Facebook or Twitter. The handle for both of those is
Speaker 1: tech Stuff h s W. Don't forget to go to
Speaker 1: our website that's tech Stuff podcast dot com. You'll find
Speaker 1: a link to every episode we've ever recorded, plus a
Speaker 1: link to our online store, where every purchase you make
Speaker 1: goes to help the show. And we greatly appreciate it,
Speaker 1: and I'll talk to you again really soon. Text Stuff
Speaker 1: is a production of I Heart Radio's How Stuff Works.
Speaker 1: For more podcasts from my heart Radio, visit the i
Speaker 1: heart Radio app, Apple podcasts, or wherever you listen to
Speaker 1: your favorite shows.