In a parallel universe , what would have to be different with computers and critical systems for the Y2k that people feared would cause chaos to be possible and actually happen?
$\begingroup$
$\endgroup$
2
asked Jan 3, 2017 at 1:10
-
$\begingroup$ Recommended to read: Y2K -- It's Already Too Late by Jason Kelly. I did read the book in first months of 2000 and it gave me shivers. (Book was published in 1998) $\endgroup$– Pavel JanicekJan 4, 2017 at 7:55
-
$\begingroup$ I believe there was a 'work around' for certain applications and systems in which the year was put back to a time which matched the calendar. So if it caused issues it would be a simple fix until a proper solution was actioned. $\endgroup$– TerryJan 4, 2017 at 12:31
Add a comment
|
4 Answers
$\begingroup$
$\endgroup$
1
Y2K WAS possible. I worked on many systems to keep your phone systems working. Between my company and others in USA, we collectively spent $3 billion dollars to fix the bug. And we did fix it. The alternate history would be when fleets of programmers just didn't do their jobs and let it happen.
-
1$\begingroup$ Yup, my boss a couple jobs ago was also a part of that group that fixed this bug on server systems. I, like many others, was misinformed when in reality it did actually happen, but the damage was relatively minimal due to hardworking sys admins. $\endgroup$ Jan 3, 2017 at 14:35
$\begingroup$
$\endgroup$
3
You fear Y2K? Wait for the end of UNIX epoch (well, on 32 bit machines)!
When adding 2 digits to a year can be sorta trivial in software, telling a computer to count to numbers more than it can is a little more difficult unless you change physically that limit.
UNIX epoch is just counting the number of seconds elapsed since January 1st 1970 at 00:00 UTC (don't talk about additionnal seconds please). Not much? Well 1 billion seconds is roughly 31 years and signed 32 bit integers go to 2 billion.
So OK, we just have to change all the CPUs to 64 bit (and use unisgned integers), simple eh? We just have to cope with critical servers running for 16 years in a row. And as others already said, if the head officer doesn't see/understand the problem without economical consequences, he won't do nothing...
-
$\begingroup$ I agree: the epoch bug is a real problem. Luckily, work on the epoch bug started at the same time we started work on Y2K, so a lot of systems have already moved to U64. We are more ready for 2035 today than we were for Y2K in 1998. I'm pretty confident we'll collectively have the epoch bug fixed in time. (I say collectively... I don't work on that sort of code any more. Though maybe in 2034 we'll all be pulled in!) $\endgroup$– SRMJan 5, 2017 at 17:27
-
$\begingroup$ See also What is ultimately a time_t typedef to? on Stack Overflow. $\endgroup$– userSep 22, 2017 at 14:48
-
$\begingroup$ "telling a computer to count to numbers more than it can is a little more difficult unless you change physically that limit." Pretty much every processor out there has an "add with carry" instruction. Doing 64-bit calculations on a 32-bit processor is easy. The hard part is pushing the representation change through the whole software stack. $\endgroup$ Feb 4, 2019 at 19:42
$\begingroup$
$\endgroup$
1
People would have to ignore the problem. Managers and decision makers would be ignorant of embedded systems. A culture of denialism would spring up instead, spreading misinformation on how embedded systems work and claiming the issue is a hoax or fraud to keep old COBOL programmers employed. Make sure the politicos hear the denialists and make sure that no funding is given to infrastructure auditing and preparation on this issue. Include deep suspicion and predjudice against “old COBOL programmers” or more generally touching existing systems that “work fine”.
-
2$\begingroup$ Wow. You could weave an awesome allegory between the Y2K bug and climate change! I never considered the parallels of the denialism before! $\endgroup$– SRMJan 3, 2017 at 15:21
$\begingroup$
$\endgroup$
It feels like you're asking what would have made the bug un fixable. The problem with this is that nearly every kind of bug is fixable once it is found and replicated (assuming the hardware can run it, hence the Unix 32 bit issue described elsewhere). Since the y2k bug was simply computer logic saying dates were a certain number of bits, it's straightforward to simply say there's more bits (obviously there's a lot more to it, but nothing remotely "impossible").
What you can maybe have is a deployed system that's incapable of receiving software patches (say, an automated satellite weapons system with no write permissions due to the threat of hacking, or an isolated network in a country like North Korea, without the CS skills to fix it). But for everyday computers, fixing a bug is straightforward once it's found.
If you wanna go fully different history, you could mess around with "free mason"-y programmers plotting to let the bug proceed for nefarious reasons (maybe messing with Bank accounts would equalize the world, or give them more power or something). But that would involve a lot of divergent history going much further back.