Live data from Hacker News

The code worked differently when the moon was full

hanselman.com

11–20 of 175 posts

Re: The code worked differently when the moon was full

#11
post #10

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... )

A bit unrelated, but another fun one, "We can't send mail more than 500 miles": https://web.mit.edu/jemorris/humor/500-miles

Re: The code worked differently when the moon was full

#12
The 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 problem was at low tide the reflected path off the water interfered with the line-of-sight path causing signal fading, whereas at high tide it interfered much less. In particular, see figure 2 of their paper for the correlation between tide height and SNR: https://homepages.inf.ed.ac.uk/mmarina/papers/EDI-INF-RR-136... As tide height really does depend on the phase of the moon, presumably their loss did too, if they measured for long enough.

Re: The code worked differently when the moon was full

#13
post #4

> 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…

Dates are a pain.

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

#14
post #6

Earlier 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.

I love the GNU units program so much. I think I use it at least 4 times/week. It's useful for kitchen conversions and also quick nuclear fuel burnup calcs. For example I used it on this blog post covering the long-term sustainability of nuclear fuel resources on earth.

https://whatisnuclear.com/blog/2020-10-28-nuclear-energy-is-...

Re: The code worked differently when the moon was full

#15
I thought that this was going to be different story.

There 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

#16

The 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…

[deleted]

Re: The code worked differently when the moon was full

#17

The 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…

Cool result. That figure 2 is begging for a scatter plot of SNR and tide level to see how well correlated they are.

Re: The code worked differently when the moon was full

#18

The 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…

I remember reading that paper when I was trying to figure out why we were having issues with a wireless link down in the Patagonia fjords.

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

#20

As long as you don't traumatize the hard drives by yelling at them, feat. brendangregg & bcantrill: https://youtu.be/tDacjrSCeq4

Tangentially, my last company made sophisticated routers, dissipating ~3kW of heat. We had hard drives in them for persistent logs.

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))

Post reply on HN