Turns out, this always happens once a train with radioactive waste on it passes by - causing a few bits to flip in memory and a subsequent crash...
Can't seem to find the story online tho...
Best wishes to everyone who was ok with providing irradiated cows to the plebs.
The first reply to that has a story that seems similar to the one you remember:
(It turned out to be a bug in 'file', not in OOo.)
> "Well, the consultant came in and patched our server and rebooted it.
> Having established that--unbelievably--the problem as reported was true,
As far as problems go, this is an easy one to solve. Accurate description of the problem. Accurate reporting of what changed. Problem is consistently repeatable.
Compared to a problem that doesn’t reliably reproduce and for which the person reporting it claims nothing changed, this one is child’s play.
But it’s still amusing to read every time.
I had something similar occur in the early 2000s on a patch release of Solaris 2.6 (I think) where the sleep call was broken and would always return almost instantly. This caused all sorts of weird behaviors on the running system.
I also recall the first time I ran into an issue with MTU on a dedicated frame relay link we had to admin our web farm in the late nineties. One day a developer reported they could login to our bastion but when they ran “ls -l” in a big enough directory their ssh connection would hang. It turned out the connection would hang whenever a packet was generated near the MTU and we eventually tracked it down to an issue with the frame relay connection. We played with MTUs until we found out what worked. It then took a while to convince our provider what was going on but they eventually replaced a line card on the far end of the connection which allowed us to re-raise the MTU to 1500.
Another fun problem I had was an email to SMS gateway I wrote for myself that worked by posting to a Verizon web form. I developed it on a Mac (probably 2002 or so) where it worked fine but when I deployed it to my Linux box on my same home network, the script couldn’t connect to Verizon’s site. It turned out the Linux box was a setting a flag on the TCP connection (ECN I think) that was tripping up Verizon’s web firewall. The work-around was disabling ECN on the Linux box.
You forgot +inaccurate reporting of the problem.
We had an employee in IT at a client who would tell us "It's broken." This went on, for every report, for three years, with us asking the same follow-up questions every time. For who, in what way, when doing what, what changed, etc.
As far as I know, that individual still works there.
People like that are the best argument for why a basic income and removing some folks from the workforce would increase efficiency.
Which is false, in my experience. Some people absolutely will be, and they won't work.
And I know HN is fairly skewed towards people who want more from life, but there's a lot of people who just don't.
And I feel like they'd be over-represented in an opt-out-of-work cohort, if a basic income allowed for it.
I don't imagine a person like that goes into work saying "I'm going to do a bad job today." I think they just don't value the work they do enough to try to do it well. And they'd rather not, if that were an option.
Easy. Replace mouse. NOPE.
OK, software issue. Reinstall mouse driver. NOPE.
OK, deeper software issue. Replace HDD from working PC. NOPE.
OK, replace RAM? NOPE.
OK, replace motherboard and all add-in cards. NOPE.
At this point we have a different HDD, motherboard, CPU, RAM, video card and mouse. Still left mouse button doesn't work. Mouse moves fine. Right button works.
Only thing left is the case and the PSU.
Replace PSU. Left mouse button works perfectly.
Solving programming problems is sometimes similar.
Edit: rooted / android / HTC phone.
I'll also say, if it's just the signal strength being too high, it seems unlikely that would cause memory corruption. The signal strength is probably just an integer, and there aren't any operations defined on integers that involve using other bytes of memory. (If you have an uint8 and add 1 to 255, you just get 0; it doesn't upgrade the integer to a uint16 and overwrite adjacent memory.)
Also does iPhone use ECC memory for all chips? Another possibility is my phone’s EM shielding is not good, and a strong EM/microwave signal scrambles the memory in one of the chips, probably the signal receiving chip. The freeze only happens occasionally.
So the solution was for all endpoints to trim the very last character - not just if it was a space, but to chop off the last character. Apparently this had been the solution for years.
This worked really well until one day someone (probably a new grad) saw the character issue and figured they'd fix it.
A bank-wide P1 incident occurred because every single XML message was now unparsable due to the malformed closing '</xml ' tag. Every single application in the bank had to do an emergency update on its XML parser.
We can't send email more than 500 miles (2002) - https://news.ycombinator.com/item?id=23775404 - July 2020 (135 comments) (<-- thanks ayewo for finding this!)
The case of the 500-mile email (2002) - https://news.ycombinator.com/item?id=14676835 - July 2017 (56 comments)
Every time we lift a pallet from the shipping room, the server times out (2006) - https://news.ycombinator.com/item?id=13347058 - Jan 2017 (82 comments)
The case of the 500-mile email - https://news.ycombinator.com/item?id=10305377 - Sept 2015 (1 comment)
The 500-mile email (2002) - https://news.ycombinator.com/item?id=9338708 - April 2015 (139 comments)
The case of the 500-mile email - https://news.ycombinator.com/item?id=1293652 - April 2010 (24 comments)
The case of the 500-mile email - https://news.ycombinator.com/item?id=385068 - Dec 2008 (28 comments)
The case of the 500-mile email - https://news.ycombinator.com/item?id=123489 - Feb 2008 (7 comments)
Edit: Here is one: https://bugs.launchpad.net/ubuntu/+source/cupsys/+bug/255161...
I posted a longer explanation in a lower level comment, but the biggest problem is that the author has a fundamental misunderstanding of both the speed of propagation, and how TCP works.
There is no way any of what he wrote actually happened, including "sendmail defaults to a few ms timeout."
That whole FAQ reads very much as "I didn't lie, I just made up all the details". I'm less convinced of the veracity of the story after reading his explanations of all the holes in his story.
We can't send email more than 500 miles (2002) - https://news.ycombinator.com/item?id=23775404 - July 2020 (136 comments)
I really hope there are a few other people here who know what that sentence means or I’m officially ancient :(
Like an ssh setting that only allows incoming connections that can prove (well, suggest) their proximity by a series of latency tests?
Easy enough to whitelist geo-ip matches or large net block ranges for a similar result.
586 units, 56 prefixes
Good news was no spam came that week.
My laptop would freeze for a couple of seconds right before each incoming call. Every single time.
It wasn't all that baffling to me so I decided to test the thing while placing the phone on top of my huge desktop tower. My over clocked computer simply restarted itself instead of freezing. Props to Lenovo, I guess
The C standard says all source files must end in a newline.
Sigh, I miss him so much...
Anyone who is above junior level system or network administration should be able to instantly tell, on point #2 alone. If they don't, they do not understand the basics of TCP.
1)Wave propagation through copper wiring is a bit more than half the speed of light. Strike one.
2)His mail server sends a SYN which is acknowledged by an SYN-ACK back. His mail server does not know instantaneously that the other mail server is accepting the connection; it has to wait for a reply back. A mail server that is '3ms away' even assuming speed of light transmission and no switching/routing/transmission delay would be ~250 miles, not ~500.
3)A mail server does not instantaneously reply to a SYN packet, so there's delay there. Strike three.
4)There are multiple routers involved (at least two) and especially circa 2002 routing and switching probably accounts for a significant amount of delay. Routers and switches tend to be store-and-forward; they receive the entire packet, an interrupt is generated by the NIC, a routing decisions is made, the packet is shoved into the buffer of the outgoing NIC, etc. That doesn't even cover firewalling. 3ms delay through multiple circa-2002 routers, firewalls, and switches is not believable.
5)Transmission delay. Packet take longer than just "distance divited by the speed of light" to arrive somewhere. Given typical LAN/WAN connection speeds of the day, packet transmission delay would be a factor. Ie the time it takes for a complete packet's bits to be transmitted.
6)Jitter. Even the slightest jitter would have wildly affected his testing. Just 2-3ms of jitter (if we follow this guy's calculations) would result in undeliverable mail to almost anywhere, yet he claims mail within the radius was reliably delivered. The campus network (particularly inter-building links), internet uplink, backbones, other network, and other mail server all have jitter that combined would easily exceed 2-3ms.
I also find it extremely difficult to believe that sendmail on SunOS defaults to a 3ms timeout and lacks a sane default when not specified; 3ms isn't remotely sane even today, much less 2002. Anything less than 30 seconds would surprise me. Lot of old software had very long timeout values because of how common slow links and systems were.
This looks like a viral story told by an unemployed sysadmin to get his "I'm looking for a job" message out.
If he truly had the knowledge commensurate with 10+ years as a sysadmin, he knew it was bullshit, and I think he might have been very cleverly looking for places where technical knowledge was lacking and thus he'd either be the smartest guy in the room or have an easy time of things.
It's an entertaining story without changing numbers to bogus ones. So why did he basically lie about everything? Because it never happened and when he concocted the story he wasn't very smart.
Notice he doesn't admit that the sole purpose was to spam "I need a job" to the mailing list?
this acutally hasn been true for high level routers since the late 90's.
On an Juniper M and MX series device for instance, a packet is broken up into a "parcel" (the first 256 bytes of an IP packet) and is saved in shared memory. Further packet processing is done by dividing up parcel lookups to the routing table across different linecard processors. (depending on the linecard, this can differ wildly).
This setup has been in place since the late 90's, although not on "lower end" hardware.
As far as i am aware, cisco has a similair mechanism in their higher end products for atleast a decade or two.