Tangentially related, here's another fun bug that inexplicably cares what time it is: Open Office cannot print on Tuesdays ( https://bugs.launchpad.net/ubuntu/+source/cupsys/+bug/255161... )
The code worked differently when the moon was full
11–20 of 175 posts
Re: The code worked differently when the moon was full
#12Re: The code worked differently when the moon was full
#13> Bugs based on a time calculations can often show themselves later when view through a longer lens and scope of time...sometimes WAY longer than you'd expect. When I worked for BBN in '97-'98, someone from outside the company as I recall came to talk to a room of engineers about the wide variety of calendar-related behaviors in various UNIX systems that were expected to cause problems for Y2K. It was a very, very lo…
The date bug I committed with the longest tail was daylight time. It was all good until we got to a day with 25 hours when we "fell back."
Re: The code worked differently when the moon was full
#14Earlier quoted context omitted.
I was also hoping the title was more accurate. In the lines of the famous story of not being able to send an email 500 miles. https://web.mit.edu/jemorris/humor/500-miles
The end of that article is a good reminder of the units command, I've been using Google for units conversion for so long that I forgot about the standalone units . It even comes standard with OSX.
https://whatisnuclear.com/blog/2020-10-28-nuclear-energy-is-...
Re: The code worked differently when the moon was full
#15There was a program I heard about back in the 90s which would literally crash depending on the phase of the moon!
The story is that it wanted to print a date. The programmer happened to have an astronomy library available that gave a string containing the date. So the programmer called that, and then parsed out the date.
Unfortunately the astronomy library wrote its result as a string to a point. The result included the phase of the Moon. The pointer was not declared to be long enough. And therefore, would crash if the name of the phase of the moon was too long!
Re: The code worked differently when the moon was full
#16The phase of the moon really can affect performance. A friend of mine worked on wireless links in Scotland and was struggling with loss at certain times of day, but not exactly the same time every day. When they graphed loss against time, the pattern was really periodic over many days. The periodicity turned out to be 12 hours 25 minutes, which they eventually realized is exactly the time between low tides. The probl…
Re: The code worked differently when the moon was full
#17The phase of the moon really can affect performance. A friend of mine worked on wireless links in Scotland and was struggling with loss at certain times of day, but not exactly the same time every day. When they graphed loss against time, the pattern was really periodic over many days. The periodicity turned out to be 12 hours 25 minutes, which they eventually realized is exactly the time between low tides. The probl…
Re: The code worked differently when the moon was full
#18The phase of the moon really can affect performance. A friend of mine worked on wireless links in Scotland and was struggling with loss at certain times of day, but not exactly the same time every day. When they graphed loss against time, the pattern was really periodic over many days. The periodicity turned out to be 12 hours 25 minutes, which they eventually realized is exactly the time between low tides. The probl…
Unfortunately we didn't have the hardware or enough control over the link (it took negotiating access with armed forces to work on either end) to try to implement any of their ideas.
Re: The code worked differently when the moon was full
#19Re: The code worked differently when the moon was full
#20As long as you don't traumatize the hard drives by yelling at them, feat. brendangregg & bcantrill: https://youtu.be/tDacjrSCeq4
There was a big problem where we needed to upgrade the fans to deal with the heat dissipation, but it was destroying the performance of the spinning disk HDDs due to the vibration of the fans.
(these were 2U devices with 5 boards: 2 control-plane boards (1 active, 1 on stand-by for redundancy) & 3 data-plane boards (2 active, 1 stand-by))