Understanding through Discussion


Welcome! You are not logged in. [ Login ]
EvC Forum active members: 64 (9045 total)
521 online now:
AZPaul3, DrJones*, Percy (Admin) (3 members, 518 visitors)
Newest Member: maria
Upcoming Birthdays: AdminPhat
Post Volume: Total: 887,200 Year: 4,846/14,102 Month: 444/707 Week: 175/197 Day: 64/55 Hour: 1/3


Thread  Details

Email This Thread
Newer Topic | Older Topic
  
Author Topic:   Trump and Trump supporters keep using the Y2K Fallacy, and it is driving me crazy
dwise1
Member
Posts: 4702
Joined: 05-02-2006
Member Rating: 5.1


(1)
Message 46 of 126 (885689)
04-22-2021 9:26 PM
Reply to: Message 41 by Tanypteryx
04-22-2021 4:55 PM


What about the 22 Aug 1999 bug when GPS faced its first 10K weeknumber rollover? GPS was intended to be a short-lived project, so they only allocated 10 bits to its weeknumber counter -- time, a highly critical component of GPS, is/was maintained with a weeknumber count and a count of seconds into that week along with a highly precise 1 pulse-per-second (1PPS) signal.

Every 19.69 years that 10-bit counter will roll over. It happened first in 1999 and then again this past year. In 1999, it would have caused all GPS devices to suddenly think that it was 1980 again, which would have screwed everything up since part of GPS is a satellite almanac which tells each GPS device where to look for satellites.

GPS receiver manufacturers got onto the problem to find a solution. Our own product line (the final 2 decades of my professional life before I retired) made use of GPS receivers to provide a very precise timebase, so issues such as the weeknumber rollover was very serious for us. We all came in to work at midnight (UTC that is, so around 1700 for us) to observe how all our product line handled that weeknumber rollover. Everything worked fine. Same thing when we all came in to work for the Y2K rollover -- I told my wife I had to be in at work at midnight on New Year's Eve, not letting on that it would be at 1600 instead of at 2400, but she didn't bat an eyelash (should have been my first clue).

 
But none of that addresses the actual big problem coming up: the 2038 Bug.

UNIX time is kept as the count of seconds since 01 Jan 1970 in a 32-bit unsigned integer. At 03:14:07 UTC 2038 Jan 19 that 32-bit counter will roll over and suddenly it will 01 Jan 1970 again on UNIX systems the world over.

Time is declared as time_t which is #defined through your C compiler's global #define. That is now #defined as a 64-bit integer, which solves this 2038 problem, but there are many UNIX programs still in use that were compiled back when time_t was still a 32-bit integer. Also, Windows had adopted UNIX time, so Windows time/calendar objects stop working in 2038 (I know, since I had created one).

Just when you thought it was safe.


This message is a reply to:
 Message 41 by Tanypteryx, posted 04-22-2021 4:55 PM Tanypteryx has responded

Replies to this message:
 Message 47 by Tanypteryx, posted 04-22-2021 9:46 PM dwise1 has responded

  
Tanypteryx
Member
Posts: 2571
From: Oregon, USA
Joined: 08-27-2006
Member Rating: 5.5


Message 47 of 126 (885691)
04-22-2021 9:46 PM
Reply to: Message 46 by dwise1
04-22-2021 9:26 PM


What about the 22 Aug 1999 bug when GPS faced its first 10K weeknumber rollover?

I don't remember what it was that occurred, but my first GPS was a used Magellan, really clunky, I bought it before a dragonfly road trip to New Mexico in 1995. It lost signal all the time. Anyway something changed within the GPS system and it would not receive after that.

Technology has to be managed. Humans have gotten really lazy, and crazy, and it's really starting to show. Denial of the problems will not fix them and will make them worse.

Your grasp of the history of this branch of technology is a pleasure to read!


What if Eleanor Roosevelt had wings? -- Monty Python

One important characteristic of a theory is that is has survived repeated attempts to falsify it. Contrary to your understanding, all available evidence confirms it. --Subbie

If evolution is shown to be false, it will be at the hands of things that are true, not made up. --percy

The reason that we have the scientific method is because common sense isn't reliable. -- Taq


This message is a reply to:
 Message 46 by dwise1, posted 04-22-2021 9:26 PM dwise1 has responded

Replies to this message:
 Message 48 by dwise1, posted 04-22-2021 10:02 PM Tanypteryx has not yet responded
 Message 49 by dwise1, posted 04-23-2021 12:59 PM Tanypteryx has not yet responded

  
dwise1
Member
Posts: 4702
Joined: 05-02-2006
Member Rating: 5.1


(3)
Message 48 of 126 (885692)
04-22-2021 10:02 PM
Reply to: Message 47 by Tanypteryx
04-22-2021 9:46 PM


Part of the very slow (very low bandwidth) signal download from the satellites was the almanac to tell the receiver where to look for the satellites. Our early lab experiments with the receivers (we did use Magellan receivers at first) found that it could take a receiver manufactured on the East Coast about 20 minutes to figure out it was on the West Coast. I seem to recall that a complete download of data from the satellites would take about 12 minutes. Very low power, low bandwidth.

We would have fun at times watching a new receiver find its way to California.

An added bonus is that when I immediately understood the moment I encountered it that ubiquitous creationist claim about how the earth's spin is slowing down so it used be ridiculously fast in the past (not actually! -- DWISE1'S CREATION / EVOLUTION PAGE: Earth's Rotation is Slowing. The originators' mistake (most likely Walter Brown) in 1979 (soundly refuted in 1982, but the claim is still with us) was that he didn't understand what leap seconds are. But, having worked very intimately with them for about two decades, I did know and understand what leap seconds are.


This message is a reply to:
 Message 47 by Tanypteryx, posted 04-22-2021 9:46 PM Tanypteryx has not yet responded

  
dwise1
Member
Posts: 4702
Joined: 05-02-2006
Member Rating: 5.1


(2)
Message 49 of 126 (885708)
04-23-2021 12:59 PM
Reply to: Message 47 by Tanypteryx
04-22-2021 9:46 PM


Technology has to be managed. Humans have gotten really lazy, and crazy, and it's really starting to show. Denial of the problems will not fix them and will make them worse.

A large part of the problem is lack of foresight. In so many cases, the creators of new technologies just could not imagine it ever growing or even lasting, so they fail to design in room for growth.

The common story about electronic computers was that about 30 computers would be enough to satisfy all the needs of the whole world. The number kind of changes with every reference.

IPv4 addresses were supposed to satisfy all the world's networking needs. After all, only a small number of people would ever use the Internet. With 32 bits (four octets) and two special use addresses (232-2), that provided 4,294,967,294 possible IP addresses. The practical number of IP addresses was smaller because of how they were allocated:

  • Class A Network -- 126 networks in the world, each with 16,777,214 hosts
  • Class B Network -- 4,096 networks in the world, each with 65,534 hosts
  • Class C Network -- 2,097,152 networks in the world, each with 254 hosts
So if you were a class A network and you only used 1,000 of your allocated addresses, then that left 16,776,214 addresses wasted; nobody outside your network could use them. With the explosion of Internet users (they hadn't anticipated personal computers either) and now the explosion of the "Internet of Things".

That is why they had to create IPv6 addresses, but that also required upgrading the Internet to support those new addresses. In the meantime, Network Address Translation (NAT) kept things working. Your gateway router has a public IP address facing outwards and a private address facing your private network (eg, 192.168.0.1) in which all the devices on the network have their own private IP address. When one of those devices sends a message out onto the Internet, the router's NAT changes the address to match your public address and does the reverse for incoming responses.

The NAVSTAR GPS project was meant to be a military experiment that would last only about a decade. I've seen the formatting of the data transmitted by the satellites and it is shoehorned in pretty tightly, plus because of the low bandwidth (it takes about 12 minutes for a complete download to your receiver) you have to keep everything down to a minimum. Time is given in week number from the Start of Time (06 Jan 1980) and how much time into the week. So they allocated ten (10) bits to the week number giving them 1024 weeks (19.69 years) to play with which was twice what they figured they needed. At the end of Week 1023, the week number would roll over back to Week 0.

Of course, GPS lasted a lot longer than they had planned for, plus it expanded to commercial use. With the first week number rollover approaching, receiver manufacturers worked out a fix to keep us from reliving 1980. It worked for the first rollover and also for the second rollover which was last year. Last I heard, the satellite data messages were going to be (or have been) changed to assign 13 bits to the week number, which would push the next rollover out 157.5 years to the year 2137.

When that first week number rollover hit, we set up our entire product line in the lab and came in to work on Saturday to verify that they all kept the right time. They did. We were just lucky that midnight UTC was 1700 PDT, so we were still able to be home in time for dinner.


This message is a reply to:
 Message 47 by Tanypteryx, posted 04-22-2021 9:46 PM Tanypteryx has not yet responded

  
ringo
Member
Posts: 19226
From: frozen wasteland
Joined: 03-23-2005
Member Rating: 3.7


Message 50 of 126 (885711)
04-23-2021 2:25 PM
Reply to: Message 40 by Sarah Bellum
04-22-2021 4:52 PM


Where I live, the year 2000 started in January and January can be very cold. So the local power company spent a lot of time and money to make sure that when the time came there would be no frozen customers. They even set their clocks forward so that the rollover happened in October when they could fix any remaining problems without loss of life.

"I've been to Moose Jaw, now I can die." -- John Wing

This message is a reply to:
 Message 40 by Sarah Bellum, posted 04-22-2021 4:52 PM Sarah Bellum has responded

Replies to this message:
 Message 51 by ramoss, posted 04-23-2021 3:59 PM ringo has acknowledged this reply
 Message 57 by Sarah Bellum, posted 05-01-2021 9:38 AM ringo has responded

  
ramoss
Member
Posts: 3209
Joined: 08-11-2004


Message 51 of 126 (885715)
04-23-2021 3:59 PM
Reply to: Message 50 by ringo
04-23-2021 2:25 PM


that also probably did not include the many hours of testing of their software before hand

This message is a reply to:
 Message 50 by ringo, posted 04-23-2021 2:25 PM ringo has acknowledged this reply

Replies to this message:
 Message 52 by AZPaul3, posted 04-23-2021 6:40 PM ramoss has not yet responded

  
AZPaul3
Member
Posts: 5988
From: Phoenix
Joined: 11-06-2006
Member Rating: 3.6


(2)
Message 52 of 126 (885716)
04-23-2021 6:40 PM
Reply to: Message 51 by ramoss
04-23-2021 3:59 PM


Many, many hours.

Way back in 1995 I was on a team that was contracted to help BofA test their ACH and wire transfer programs.

We copied all their production stuff to an isolated test partition and put up a database of live transactions from Dec-Jan 1994-95. We went through each record to update time/date stamps and coded security fields to Dec-Jan 99-00.

The biggest headache setting up the test was the base system, IMS. IMS did not react well to having the sysclock set forward. The IBM guys on our team spent two days getting it right. Yes, two 24 hour days straight. We were under contract and you don't argue with the biggest gorilla in the financial world.

The entire setup took 3 months. The tests did not go well. BofA spent the next year becoming Y2k compliant for ACH, FedWire, SWIFT and all.

Many hours indeed.

Edited by AZPaul3, : No reason given.


Eschew obfuscation. Habituate elucidation.

This message is a reply to:
 Message 51 by ramoss, posted 04-23-2021 3:59 PM ramoss has not yet responded

  
Sarah Bellum
Member
Posts: 748
Joined: 05-04-2019


Message 53 of 126 (885988)
05-01-2021 9:33 AM
Reply to: Message 42 by Tanypteryx
04-22-2021 5:37 PM


Airliners didn't fall from the sky, power grids didn't go dark, ATMs didn't dump bags of cash into the arms of hackers. And they never were going to, at least not because of Y2K.

There are bugs everywhere. We've seen them many many times, from the Ariane 5 disaster in 1996 to the Yahoo data breach in 2017. When the next big crisis comes, say when an all-out war starts (for example between China and Taiwan or between China and India or between China and . . . . etc.), all those bugs will be displayed in massive casualty lists.

The Y2K bug is just the one that got a lot of publicity because people could understand it from a thirty second sound bite. And because of the eschatological connection with the "coming of the millennium." Not because it was comparable to the more serious problems that are in the news every week. Surely if all those non-Y2K bugs have not been fixed, some of the Y2K bugs would also have been overlooked and caused some catastrophes?

Wait a minute! Some of the Y2K bugs were indeed overlooked! And what happened? A 105 year old grandmother got a notice to report to kindergarten, an employee saw a readout that the ingredients to a manufacturing process had expired 98 years ago and dumped a whole batch, wasting it, . . .

Airliners didn't fall from the sky, power grids didn't go dark, ATMs didn't dump bags of cash into the arms of hackers. And they never were going to, at least not because of Y2K.


This message is a reply to:
 Message 42 by Tanypteryx, posted 04-22-2021 5:37 PM Tanypteryx has responded

Replies to this message:
 Message 59 by Tanypteryx, posted 05-01-2021 10:48 AM Sarah Bellum has acknowledged this reply

  
Sarah Bellum
Member
Posts: 748
Joined: 05-04-2019


Message 54 of 126 (885989)
05-01-2021 9:34 AM
Reply to: Message 43 by jar
04-22-2021 6:13 PM


Airliners didn't fall from the sky, power grids didn't go dark, ATMs didn't dump bags of cash into the arms of hackers. And they never were going to, at least not because of Y2K.

There are bugs everywhere. We've seen them many many times, from the Ariane 5 disaster in 1996 to the Yahoo data breach in 2017. When the next big crisis comes, say when an all-out war starts (for example between China and Taiwan or between China and India or between China and . . . . etc.), all those bugs will be displayed in massive casualty lists.

The Y2K bug is just the one that got a lot of publicity because people could understand it from a thirty second sound bite. And because of the eschatological connection with the "coming of the millennium." Not because it was comparable to the more serious problems that are in the news every week. Surely if all those non-Y2K bugs have not been fixed, some of the Y2K bugs would also have been overlooked and caused some catastrophes?

Wait a minute! Some of the Y2K bugs were indeed overlooked! And what happened? A 105 year old grandmother got a notice to report to kindergarten, an employee saw a readout that the ingredients to a manufacturing process had expired 98 years ago and dumped a whole batch, wasting it, . . .

Airliners didn't fall from the sky, power grids didn't go dark, ATMs didn't dump bags of cash into the arms of hackers. And they never were going to, at least not because of Y2K.


This message is a reply to:
 Message 43 by jar, posted 04-22-2021 6:13 PM jar has not yet responded

  
Sarah Bellum
Member
Posts: 748
Joined: 05-04-2019


Message 55 of 126 (885990)
05-01-2021 9:34 AM
Reply to: Message 44 by AZPaul3
04-22-2021 6:42 PM


Airliners didn't fall from the sky, power grids didn't go dark, ATMs didn't dump bags of cash into the arms of hackers. And they never were going to, at least not because of Y2K.

There are bugs everywhere. We've seen them many many times, from the Ariane 5 disaster in 1996 to the Yahoo data breach in 2017. When the next big crisis comes, say when an all-out war starts (for example between China and Taiwan or between China and India or between China and . . . . etc.), all those bugs will be displayed in massive casualty lists.

The Y2K bug is just the one that got a lot of publicity because people could understand it from a thirty second sound bite. And because of the eschatological connection with the "coming of the millennium." Not because it was comparable to the more serious problems that are in the news every week. Surely if all those non-Y2K bugs have not been fixed, some of the Y2K bugs would also have been overlooked and caused some catastrophes?

Wait a minute! Some of the Y2K bugs were indeed overlooked! And what happened? A 105 year old grandmother got a notice to report to kindergarten, an employee saw a readout that the ingredients to a manufacturing process had expired 98 years ago and dumped a whole batch, wasting it, . . .

Airliners didn't fall from the sky, power grids didn't go dark, ATMs didn't dump bags of cash into the arms of hackers. And they never were going to, at least not because of Y2K.


This message is a reply to:
 Message 44 by AZPaul3, posted 04-22-2021 6:42 PM AZPaul3 has not yet responded

Replies to this message:
 Message 94 by ramoss, posted 07-12-2021 6:55 PM Sarah Bellum has acknowledged this reply

  
Sarah Bellum
Member
Posts: 748
Joined: 05-04-2019


Message 56 of 126 (885991)
05-01-2021 9:35 AM
Reply to: Message 45 by nwr
04-22-2021 8:34 PM


Airliners didn't fall from the sky, power grids didn't go dark, ATMs didn't dump bags of cash into the arms of hackers. And they never were going to, at least not because of Y2K.

There are bugs everywhere. We've seen them many many times, from the Ariane 5 disaster in 1996 to the Yahoo data breach in 2017. When the next big crisis comes, say when an all-out war starts (for example between China and Taiwan or between China and India or between China and . . . . etc.), all those bugs will be displayed in massive casualty lists.

The Y2K bug is just the one that got a lot of publicity because people could understand it from a thirty second sound bite. And because of the eschatological connection with the "coming of the millennium." Not because it was comparable to the more serious problems that are in the news every week. Surely if all those non-Y2K bugs have not been fixed, some of the Y2K bugs would also have been overlooked and caused some catastrophes?

Wait a minute! Some of the Y2K bugs were indeed overlooked! And what happened? A 105 year old grandmother got a notice to report to kindergarten, an employee saw a readout that the ingredients to a manufacturing process had expired 98 years ago and dumped a whole batch, wasting it, . . .

Airliners didn't fall from the sky, power grids didn't go dark, ATMs didn't dump bags of cash into the arms of hackers. And they never were going to, at least not because of Y2K.


This message is a reply to:
 Message 45 by nwr, posted 04-22-2021 8:34 PM nwr has acknowledged this reply

Replies to this message:
 Message 60 by Percy, posted 05-02-2021 4:41 PM Sarah Bellum has acknowledged this reply

  
Sarah Bellum
Member
Posts: 748
Joined: 05-04-2019


Message 57 of 126 (885992)
05-01-2021 9:38 AM
Reply to: Message 50 by ringo
04-23-2021 2:25 PM


I'm curious. How would changing the time on a clock result in "frozen customers"? Surely any problem an incorrect clock could cause could be fixed long before anyone got chilly. I mean, clocks do break, even when it's not 31 December 1999.

This message is a reply to:
 Message 50 by ringo, posted 04-23-2021 2:25 PM ringo has responded

Replies to this message:
 Message 58 by ringo, posted 05-01-2021 10:29 AM Sarah Bellum has responded

  
ringo
Member
Posts: 19226
From: frozen wasteland
Joined: 03-23-2005
Member Rating: 3.7


(1)
Message 58 of 126 (885993)
05-01-2021 10:29 AM
Reply to: Message 57 by Sarah Bellum
05-01-2021 9:38 AM


Sarah Bellum writes:

How would changing the time on a clock result in "frozen customers"?


They changed the time to test their fixes of the Y2K bug. If they hadn't fixed it, the grid certainly might have gone dark on Jan 1, 2000. And with temperatures colder than -20 Celsius, customers would have literally frozen.

When they had fixed all the bugs they could find, on Oct something, they ran the system as if it was Dec 31, 1999 to see if they had missed any. I don't know what their clocks read on the actual Dec 31, 1999.


"I've been to Moose Jaw, now I can die." -- John Wing

This message is a reply to:
 Message 57 by Sarah Bellum, posted 05-01-2021 9:38 AM Sarah Bellum has responded

Replies to this message:
 Message 61 by Sarah Bellum, posted 05-03-2021 12:37 PM ringo has responded

  
Tanypteryx
Member
Posts: 2571
From: Oregon, USA
Joined: 08-27-2006
Member Rating: 5.5


(1)
Message 59 of 126 (885995)
05-01-2021 10:48 AM
Reply to: Message 53 by Sarah Bellum
05-01-2021 9:33 AM


Thanks so much for fixing our error
Wow! Well done!

What if Eleanor Roosevelt had wings? -- Monty Python

One important characteristic of a theory is that is has survived repeated attempts to falsify it. Contrary to your understanding, all available evidence confirms it. --Subbie

If evolution is shown to be false, it will be at the hands of things that are true, not made up. --percy

The reason that we have the scientific method is because common sense isn't reliable. -- Taq


This message is a reply to:
 Message 53 by Sarah Bellum, posted 05-01-2021 9:33 AM Sarah Bellum has acknowledged this reply

  
Percy
Member
Posts: 20237
From: New Hampshire
Joined: 12-23-2000
Member Rating: 4.5


(3)
Message 60 of 126 (886022)
05-02-2021 4:41 PM
Reply to: Message 56 by Sarah Bellum
05-01-2021 9:35 AM


This reply is mostly just reminiscences, but my impression is that you've been far too quick and far too anecdotal in being dismissive.

Five years before Y2K there was a similar circumstance known as the Pentium FDIV bug - Wikipedia (it wasn't called that at the time - I forget what we called it then). It affected the FPU. Depending upon the required precision and how you did your math (some approaches are more prone to accumulating error than others) the bug either was or wasn't serious. If you were flying spacecraft or designing bridges it was serious. Very serious.

Ten years before in the mid-80's I worked for one of the two major workstation companies, and we suffered our own version of the Y2K problem because we used the Motorola 68000 family of microprocessors which in 1987 (or thereabouts) released a faulty new generation (I no longer recall any details). This hardware bug got very little attention, as did my own suggestions to upper management that we take it very seriously in case, God forbid, someone used our workstations to design spacecraft. Nothing bad ever happened and the problem was fixed after about six months. I can find no mention online today of this bug.

To err is human, and mistakes are inevitable in any human endeavor. Some mistakes end up having no severe consequences, but that doesn't mean the dangers and risks were not very, very real. Most of the time the care and precautions we take are sufficient and things work out, but sometimes they don't, and then astronauts die and bridges collapse and buildings topple and oil platforms sink and so forth.

My group had software in the field the night of Y2K. My company knew how exposed all our software was and we had done our best to fix it, but across the entire company we had millions of lines of code, and the possibility that we hadn't fixed it in some crucial place was gut-wrenchingly clear. It was a great relief when morning came and the phone had not rung.

When you roll the dice and don't throw craps that doesn't mean the risk that you could have thrown craps wasn't very, very real. Roll the dice often enough and they will eventually come up craps.

Back around 1986 there was a book that received a great deal of attention in software quality circles whose author and title I no longer remember. The book argued that software companies were paying far too little attention to quality and that it would eventually have dire consequences. The book anticipated that in the future some programs would have extremely high numbers of installations and described disastrous scenarios of companies releasing buggy software and then receiving millions of bug reports, refund demands, and lawsuits.

What the book didn't anticipate but that became clear within a decade was that extremely high quality software often isn't needed because in most circumstances "good enough" software will do. And that's what we mostly have today, as any user of cell phones and websites can attest. Most people not in the industry blame themselves when they can't get a cell phone or website to work, which works in the industry's favor.

Companies today with large software distributions often protect themselves from dealing with run-of-the-mill bugs by making bug reporting extremely difficult or even impossible. I probably file bug reports on some piece of software about once every couple months or so, and I never hear back from anyone, other than a "thank you" type message, and maybe a reference number. For many companies I can't even figure out how to file a bug report. An insurance company I use provides no way to file bug reports or give feedback about their website, just one of the bugs I wish I could tell them about. Of course, they probably consider it a feature.

--Percy


This message is a reply to:
 Message 56 by Sarah Bellum, posted 05-01-2021 9:35 AM Sarah Bellum has acknowledged this reply

  
Newer Topic | Older Topic
Jump to:


Copyright 2001-2018 by EvC Forum, All Rights Reserved

™ Version 4.0 Beta
Innovative software from Qwixotic © 2021