Remember when the world held its breath for the arrival of the year 2000 and the infamous Y2K bug? Turned out to be a big fuss over nothing. But how would we deal with something like this today? Panic or calm? thisdayintechhistory.com/12/31…
@robertatcara As someone who personally discovered and fixed Y2K bugs that would have had significant real world impact, it is disturbing to hear someone propagate this myth [that it was a "big fuss about nothing"]. And it is a myth.
The testing methodology insured that these impacts were not hypothetical. At my company, the testing was performed by actually rolling the clock forward to test systems to see what would happen. For example, I discovered that every ATM in the state of Alaska operated by my company would have locked up until a PROM chip was swapped. Someone had to fly all over the state to proactively swap the chip beforehand, to avoid significant customer impact.
And that was just one story. I personally oversaw investigation and fixes for other hardware and software a
... mehr anzeigen
@robertatcara As someone who personally discovered and fixed Y2K bugs that would have had significant real world impact, it is disturbing to hear someone propagate this myth [that it was a "big fuss about nothing"]. And it is a myth.
The testing methodology insured that these impacts were not hypothetical. At my company, the testing was performed by actually rolling the clock forward to test systems to see what would happen. For example, I discovered that every ATM in the state of Alaska operated by my company would have locked up until a PROM chip was swapped. Someone had to fly all over the state to proactively swap the chip beforehand, to avoid significant customer impact.
And that was just one story. I personally oversaw investigation and fixes for other hardware and software at that company that would have failed.
And that was just my company. I spoke with others in IT at that time with similar stories. And that was just the people I knew.
So no, it wasn't "a big fuss about nothing" - and saying so is both dangerously revisionist, and disrespectful of the work it took to prevent real impacts.
Can confirm! My company checked the PLCs and production control systems at a large automotive plant. Several systems were vulnerable and had to be fixed. Otherwise the whole plant would have stand still. They have 14000 people, producing 1000+ cars per day.
We also had a development project running that had a hard start date on 2000-01-03. Hard as in „if it doesn’t work right away, the penalty would ruin our customer in days“. We also rolled the clock forward, passed 1999-12-23 23:23:59 several times, produced virtually into the future, including reports and stuff. It worked from the start.
Funny though: At our new years eve party, we had a Braun radio controlled alarm clock, working on a public broadcast signal (DCF77 in Braunschweig, DE). We watched the seconds hand ticking to midnight - and then it stopped. For seconds! Several IT people held their breath. Then it moved
Can confirm! My company checked the PLCs and production control systems at a large automotive plant. Several systems were vulnerable and had to be fixed. Otherwise the whole plant would have stand still. They have 14000 people, producing 1000+ cars per day.
We also had a development project running that had a hard start date on 2000-01-03. Hard as in „if it doesn’t work right away, the penalty would ruin our customer in days“. We also rolled the clock forward, passed 1999-12-23 23:23:59 several times, produced virtually into the future, including reports and stuff. It worked from the start.
Funny though: At our new years eve party, we had a Braun radio controlled alarm clock, working on a public broadcast signal (DCF77 in Braunschweig, DE). We watched the seconds hand ticking to midnight - and then it stopped. For seconds! Several IT people held their breath. Then it moved again. Pew. Solution: The sender had transmitted the whole time string. New millenium, etc. That took that clock a while to receive and process.
@tychotithonus @robertatcara it was just a year setting. Four digit instead of two. The machines that couldn’t be reset to a four digit year were obsolete. It really wasn’t a big deal! Mind you, many charlatans made a bloody fortune!
i take it you didn't work anywhere in NYC in the 1990s? nyc spent the whole decade migrating universities, city gov, banks, telecomms, so that it would be nothing by the turn of the century.
and it wasn't just coders involved: architects, interior designers, screenwriters, illustrators, whole swaths of people were being hired by places like Goldman Sachs to update floor plans, manage cabling, write training manuals
@robertatcara It was a big fuss over nothing because many of us worked around them clock to make it nothing.
I did y2k remediation to help pay for undergrad. 1997.ev right up to December of 1999.ev, reversing DEC ALPHA binaries compiled for OpenVMS for a power company. I was part of a team of 20 but the only one who'd ever done reverse engineering. We had some source code in COBOL and a little in C but mostly were were hex editing executables, with a little tool writing in Perl for more difficulty fixes.
Our first rollover test in summer of 1997.ev resulted in a nine hour power outage. Substations put themselves into fail-safe mode and shut down, requiring teams to drive around Allegheny County and bring them back online.
We finally finished in summer of 1999.ev, alongside a few of Pittsburgh's bigger banks. Final test was a scheduled clock rollover at 1200 hours UTC-5. We wound up testing three times in a row (once after a cold boot) that afternoon before we called it good.
Royce Williams
Als Antwort auf Robert Gibbons • • •@robertatcara As someone who personally discovered and fixed Y2K bugs that would have had significant real world impact, it is disturbing to hear someone propagate this myth [that it was a "big fuss about nothing"]. And it is a myth.
This is what really happened:
time.com/5752129/y2k-bug-histo…
The testing methodology insured that these impacts were not hypothetical. At my company, the testing was performed by actually rolling the clock forward to test systems to see what would happen. For example, I discovered that every ATM in the state of Alaska operated by my company would have locked up until a PROM chip was swapped. Someone had to fly all over the state to proactively swap the chip beforehand, to avoid significant customer impact.
And that was just one story. I personally oversaw investigation and fixes for other hardware and software a
... mehr anzeigen@robertatcara As someone who personally discovered and fixed Y2K bugs that would have had significant real world impact, it is disturbing to hear someone propagate this myth [that it was a "big fuss about nothing"]. And it is a myth.
This is what really happened:
time.com/5752129/y2k-bug-histo…
The testing methodology insured that these impacts were not hypothetical. At my company, the testing was performed by actually rolling the clock forward to test systems to see what would happen. For example, I discovered that every ATM in the state of Alaska operated by my company would have locked up until a PROM chip was swapped. Someone had to fly all over the state to proactively swap the chip beforehand, to avoid significant customer impact.
And that was just one story. I personally oversaw investigation and fixes for other hardware and software at that company that would have failed.
And that was just my company. I spoke with others in IT at that time with similar stories. And that was just the people I knew.
So no, it wasn't "a big fuss about nothing" - and saying so is both dangerously revisionist, and disrespectful of the work it took to prevent real impacts.
#Y2K
20 Years Later, the Y2K Bug Seems Like a Joke—Because Those Behind the Scenes Took It Seriously
Francine Uenuma (Time)Jaddy mag das.
teilten dies erneut
Martin Marheinecke, Lars Marowsky-Brée 😷, Martin Schröder, imdat celeste :v_tg: :v_nb: :v_genderfluid: [witchzard] und Jan Walzer haben dies geteilt.
Kee Hinckley
Als Antwort auf Royce Williams • • •@tychotithonus @Shanmonster @robertatcara Absolutely. I fixed a few for my clients (and missed one, but not a big deal).
I’m not sure the Unix time one is going to go as well.
Paul_IPv6
Als Antwort auf Kee Hinckley • • •@nazgul @tychotithonus @Shanmonster @robertatcara
the unix epoch one will be 2038. by then, anyone who was at least 30 for y2k will be near or at retirement. :)
i sure hope the next generations of linux/unix hackers listen to a few old farts...
Jaddy
Als Antwort auf Royce Williams • •@Royce Williams @robertatcara@infosec.exchange 👍
Can confirm! My company checked the PLCs and production control systems at a large automotive plant. Several systems were vulnerable and had to be fixed. Otherwise the whole plant would have stand still. They have 14000 people, producing 1000+ cars per day.
We also had a development project running that had a hard start date on 2000-01-03. Hard as in „if it doesn’t work right away, the penalty would ruin our customer in days“. We also rolled the clock forward, passed 1999-12-23 23:23:59 several times, produced virtually into the future, including reports and stuff. It worked from the start.
Funny though: At our new years eve party, we had a Braun radio controlled alarm clock, working on a public broadcast signal (DCF77 in Braunschweig, DE). We watched the seconds hand ticking to midnight - and then it stopped. For seconds! Several IT people held their breath. Then it moved
... mehr anzeigen@Royce Williams @robertatcara@infosec.exchange 👍
Can confirm! My company checked the PLCs and production control systems at a large automotive plant. Several systems were vulnerable and had to be fixed. Otherwise the whole plant would have stand still. They have 14000 people, producing 1000+ cars per day.
We also had a development project running that had a hard start date on 2000-01-03. Hard as in „if it doesn’t work right away, the penalty would ruin our customer in days“. We also rolled the clock forward, passed 1999-12-23 23:23:59 several times, produced virtually into the future, including reports and stuff. It worked from the start.
Funny though: At our new years eve party, we had a Braun radio controlled alarm clock, working on a public broadcast signal (DCF77 in Braunschweig, DE). We watched the seconds hand ticking to midnight - and then it stopped. For seconds! Several IT people held their breath. Then it moved again. Pew. Solution: The sender had transmitted the whole time string. New millenium, etc. That took that clock a while to receive and process.
John Caveney woke is me🛠️
Als Antwort auf Royce Williams • • •your auntifa liza 🇵🇷 🦛 🦦
Als Antwort auf John Caveney woke is me🛠️ • • •i take it you didn't work anywhere in NYC in the 1990s? nyc spent the whole decade migrating universities, city gov, banks, telecomms, so that it would be nothing by the turn of the century.
and it wasn't just coders involved: architects, interior designers, screenwriters, illustrators, whole swaths of people were being hired by places like Goldman Sachs to update floor plans, manage cabling, write training manuals
nothing happened because shit gone done
@jaycee @tychotithonus @robertatcara
The Doctor
Als Antwort auf Robert Gibbons • • •@robertatcara It was a big fuss over nothing because many of us worked around them clock to make it nothing.
I did y2k remediation to help pay for undergrad. 1997.ev right up to December of 1999.ev, reversing DEC ALPHA binaries compiled for OpenVMS for a power company. I was part of a team of 20 but the only one who'd ever done reverse engineering. We had some source code in COBOL and a little in C but mostly were were hex editing executables, with a little tool writing in Perl for more difficulty fixes.
Our first rollover test in summer of 1997.ev resulted in a nine hour power outage. Substations put themselves into fail-safe mode and shut down, requiring teams to drive around Allegheny County and bring them back online.
We finally finished in summer of 1999.ev, alongside a few of Pittsburgh's bigger banks. Final test was a scheduled clock rollover at 1200 hours UTC-5. We wound up testing three times in a row (once after a cold boot) that afternoon before we called it good.