Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

The code worked differently when the moon was full

hanselman.com

Post reply on HN
Print view View original

161–170 of 175 posts

Re: The code worked differently when the moon was full

#161

Post by tabtab »

zikduruqe wrote: post #62
tabtab wrote: post #57

Earlier quoted context omitted.

Our garage door opener has this problem. At very specific times of the year the sun confuses the infrared blockage sensor. The cause occurred to me when I lined up my eye to see what the sensor was seeing when it was failing, and I noticed the morning sun right next to the other end of the sensor stream. I moved a trash can to shade the sensor and it worked fine.

Just switch the sensors. Move the light source to the other side of the door, and the receiver to the shade. :tapstemplegif: (That's how I fixed mine.)

Then the evening sun could potentially cause the same thing. There's a gap in houses across the street that may allow sun in at the right time of year.

Re: The code worked differently when the moon was full

#162

Post by kergonath »

LargoLasskhyfv wrote: post #107
acidburnNSA wrote: post #14

Earlier quoted context omitted.

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

Interesting kitchen you have. Calculating nuclear fuel burnup. I wonder what's cooking? Does it glow in the dark? ;>

> I wonder what's cooking?

Yellow cake.

Re: The code worked differently when the moon was full

#163

Post by vidanay »

vincnetas wrote: post #112
vidanay wrote: post #26

We once had a customer who would call us in a panic a couple of times a year saying our inspection equipment was experiencing unusually high false rejects and they were generating very high scrap rate. By the time we got a technician on site the next day, everything was working flawlessly and the customer couldn't reproduce the problem either. This went on for almost three years with various levels of escalation to t…

preemptivly storing images from camera of rejected samples would have saved everyone more time, as it would be enough to review images of failed samples and notice a flare. of course if that was an option.

If I remember rightly, this incident was the motivating factor for adding "save failing images" capability to our software.

Re: The code worked differently when the moon was full

#164

Post by mixmastamyk »

vidarh wrote: post #118
xsmasher wrote: post #40

Earlier quoted context omitted.

This is like a real-world equivalent of the "cleaning lady unplugged the machine" urban legend.

I know someone who had that happen to a server he was directly responsible for (well, someone unplugged it anyway, might well have been someone else in the office - it wasn't exactly a proper server room) It was not just that the server crashed, but the ventilation proved to be bad enough that one of the SCSI drives (which should have been in a RAID, but wasn't...) wouldn't start. They ended up opening it to try to k…

I do have a memory of having to bump an old heavy drive to get it to start spinning. :-)

Re: The code worked differently when the moon was full

#165

Post by jareklupinski »

xsmasher wrote: post #40
vidanay wrote: post #26

We once had a customer who would call us in a panic a couple of times a year saying our inspection equipment was experiencing unusually high false rejects and they were generating very high scrap rate. By the time we got a technician on site the next day, everything was working flawlessly and the customer couldn't reproduce the problem either. This went on for almost three years with various levels of escalation to t…

This is like a real-world equivalent of the "cleaning lady unplugged the machine" urban legend.

I had a root cause once that was a cable draped across the corner of a ventilation duct.

The duct would vibrate when the air was on, and the corner was pretty sharp, which caused the duct corner to 'saw' its way through the cable's insulation over time.

Took a while to isolate the problem to 'its between this box and this box' but was a pretty quick find after that :)

Re: The code worked differently when the moon was full

#166

Post by crtasm »

huhtenberg wrote: post #130
johnfn wrote: post #44

Earlier quoted context omitted.

I was going to say it was the real world equivalent of, like, Redwall, or one of those other fantasy books where an event happens once a year when the sun shines in exactly the right spot to illuminate some secret writing.

There is the Anthem Veterans Memorial that projects an image on the ground on November 11th at 11:11 and at no time else. https://en.wikipedia.org/wiki/Anthem_Veterans_Memorial

Except for when it is visible at other times, as that link explains?

Re: The code worked differently when the moon was full

#167

Post by m4rtink »

walrus01 wrote: post #58
m4rtink wrote: post #31

Earlier quoted context omitted.

I heard a story about an astronomer loosing the chance to be the first to report a commet one cold winter night - just as he wanted to send the email to report it, the Internet connection was dead! He ran from the observatory to the nearest place with Internet connectivity, but by the time he sent the email from there, there was already a report from another astronomer elsewhere, a few minutes ago. Reason for the mys…

one of the reasons why free space optics gigabit and 10GbE ethernet laser based links are a tiny niche product in the ISP space, millimeter wave (71-86 GHz) fills the purpose much better. also they don't do as well in rain as something that can adapt modulation.

Yeah, that is likely why terrestrial FSO seems to be mostly dead these days as far as I can tell. Even back then there used to be a backup RF link in case of fog - why not have a proper RF link instead, especially if its going to be much better due to all the money dumped into RF technology in comparison to free space optics.

Re: The code worked differently when the moon was full

#168

Post by randomswede »

zadwang wrote: post #131
dhosek wrote: post #113

Earlier quoted context omitted.

To clarify, I was thinking a quick command line thing. Right now, I do it in a browser (both DuckDuckGo and Google produce the answer easily enough).

The unix date command does this.

Well, GNU date does, BSD date may or may not.

Linux box:

  $ date -d 'now + 4711 days ago'
  Thu Nov  6 06:57:20 UTC 2008
  $ date --version
  date (GNU coreutils) 8.30
  Copyright (C) 2018 Free Software Foundation, Inc.
  License GPLv3+: GNU GPL version 3 or later 
  .
  This is free software: you are free to change and redistribute it.
  There is NO WARRANTY, to the extent permitted by law.

  Written by David MacKenzie.
Mac:

  % date -d 'now + 4711 days ago'
  usage: date [-jnRu] [-d dst] [-r seconds] [-t west] [-v[+|-]val[ymwdHMS]] ... 
            [-f fmt date | [[[mm]dd]HH]MM[[cc]yy][.ss]] [+format]
I also seem to be unable to pull a version out of the Mac's date command.

Re: The code worked differently when the moon was full

#169

Post by vidarh »

mixmastamyk wrote: post #164
vidarh wrote: post #118

Earlier quoted context omitted.

I know someone who had that happen to a server he was directly responsible for (well, someone unplugged it anyway, might well have been someone else in the office - it wasn't exactly a proper server room) It was not just that the server crashed, but the ventilation proved to be bad enough that one of the SCSI drives (which should have been in a RAID, but wasn't...) wouldn't start. They ended up opening it to try to k…

I do have a memory of having to bump an old heavy drive to get it to start spinning. :-)

I opened mine up, so I'd start rotating the platter by using my finger to start spinning the centre.

Of course this was with a 20MB hard drive - the sensitivity to everything from dust to alignment changes was magnitudes different from the internals of modern drives...

Re: The code worked differently when the moon was full

#170

Post by randomswede »

a-dub wrote: post #30
drdeadringer wrote: post #23

Reminds me of a story where a company's internet would regularly drop at the same time every day -- let's say 3pm. Nobody could figure it out so they called in an expert. After lots of attempts and figuring, one day the person in question happens to look out the window at the time in question ... and sees a service truck park exactly in line-of-sight between the business and their internet-signal pickup broadcast poi…

i once lived in an apartment in an old building where if you turned on the light in the bathroom the dsl would lose sync. why this would occur i'll never know. (probably old telephone wiring wrapped around old 110v wiring? maybe? or who knows what kind of weird leakage/ground loops may have existed)

At a very former workplace, we suddenly lost the ability to ARP between two buildings. Once the ARP entry was in the machines, it worked fine (FSVO "fine"), but getting to the point where ARP worked simply was not reliable.

Much troubleshooting later, it turns out that when they'd been doing some maintenance in the lift shaft (which was also used to drop the inter-building 10Base-5 yellow snake), they'd managed to shoot a nail through the Ethernet cable and we now had a nice 50Hz hum on the cable.

Retries in TCP made that work, but ARP doesn't have retries, so if that managed to get faded out, you'd hope to get lucky next time...

Post reply on HN