Email or username:

Password:

Forgot your password?
Daniel Keys Moran's posts Post Back to profile
Top-level
Toadofsky

@fatsam Which planes and reactors were at risk? I understand that software which involves calendars and dates and financial records could be at risk, but I didn't think navigation systems or safety systems scheduled their meltdowns.

3 June at 11:47 | Wall-to-wall | Open on mastodon.social
7 comments
Daniel Keys Moran

@toadofsky most commercial flights were cancelled on New Year's Eve 1999. They were more worried about flight control than the individual planes, but there was patching done to quite a lot of individual subsystems in planes, as I recall.

Give me a minute on the nuclear power plants. I know there was at least one problem due just to testing.

3 June at 12:05 | Open on mstdn.social
Daniel Keys Moran
Leeloo

@fatsam @toadofsky
That reads like the problem was someone messed up Y2k testing, rather than an actual Y2k bug.

3 June at 16:24 | Open on techhub.social
Professor Emeritus Blake Y Rat

@leeloo @fatsam @toadofsky Other than the journalist's weird use of the word "antiquated" to describe analog indicators, it doesn't at any point demonstrate that the analog indicators are inferior to the computerized. (And why would they be? Nuclear reactors existed, safely, before computers were available for them, like in 1950s submarines)

I get the urge to push back on "Y2K was no problem!" but there's some over-correction going on here. This is just as wrong, but in the other direction.

3 June at 18:27 | Open on mastodon.social
cholling

@leeloo @fatsam @toadofsky True, but if the problem could be caused by an improperly set clock, it's not a stretch to think it could have been caused by a date overflow, too.

3 June at 21:14 | Open on social.sdf.org
Adora (She/Her) :flag_transgender:

@toadofsky @fatsam systems use dates/times to monitor changes.

like "too much radiation leak" might be "X rads in Y time"

date/time failures could bring down key monitoring systems easily (I didn't work on Y2K, but I do make monitoring systems)

3 June at 12:48 | Open on tech.lgbt
Zimmie

@toadofsky @fatsam The Boeing 787 has had quite a few time-related problems.

In mid-2015, the FAA reported the generator control units (GCUs) would all simultaneously hang after about 248 days of uptime, causing a total outage of AC power to the aircraft. The workaround was to reboot all of the GCUs after no more than 120 days up. arstechnica.com/information-te

Then in late 2016, they reported all three flight control computers could hang after 22 days up, leading to loss of flight control until they were rebooted. The workaround was to reboot them every week. seattletimes.com/business/boei

In early 2020, there was another problem which could result in the control network crashing or in weeks-stale data from a wide variety of plane systems being shown to the pilots as if it were current. Again, the workaround was to reboot the whole plane every three weeks. theregister.com/2020/04/02/boe

While these are all likely to be accumulators which overflowed, they all mean Boeing software is not developed particularly rigorously. I could definitely see a timestamp which the plane thinks is invalid causing flight control or engine control to go unresponsive. Particularly things tracked by rate—when the timestamp overflows, the rate will be wildly nonsensical until the full rate window is past the overflow.

@toadofsky @fatsam The Boeing 787 has had quite a few time-related problems.

In mid-2015, the FAA reported the generator control units (GCUs) would all simultaneously hang after about 248 days of uptime, causing a total outage of AC power to the aircraft. The workaround was to reboot all of the GCUs after no more than 120 days up. arstechnica.com/information-te

3 June at 13:23 | Open on infosec.exchange
Go Up