Even after reading the 2025 updated version, reading the original made me absolutely giddy at the end.
I can only imagine the euphoria of reconciling the inputs of “the things I know to be true of computers and email” and “my emails won’t send further than 500 miles”. What a great story - thanks for posting the original.
I’ve seen some weird technical glitches in my career. One that i will always remember is that a customer was very happy with his new big computer, but could not work for multiple hours on it, because his office would get colder and colder when he kept using it. After some mailing and talking over the phone i suggested a visit to his office where i quickly found the cause of the problem: The big computer fan was aimed directly at the thermostat knob of the radiator, so it assumed the entire office was well heated and closed.
It's not quite in the same league as any of this, but when I was a child, we sent our Commodore 64 in for repairs several times because it started "writing" by itself. Gibberish would slowly appear as if someone was randomly hitting the keyboard.
Each time it took several days before they repair centre got to it, and they then contacted us to tell us there was nothing wrong with the computer at all.
After we picked it up, eventually, when it started happening again for the third or fourth time, we realised the problem:
The "large" (a whopping 26") CRT TV we'd recently started placing it under when not in use caused it... A few days away from the TV to dishcharge it, and it was fine - hence why the repair technician didn't find anything.
I know this story is a bit unrelated, but your story brought it to mind (probably the keywords child, repaired several times, etc): When I was a kid my father had a Nokia 3310. Any early Nokia owner would remember how you could configure your own 'welcome message', which would flash up on the phone's monochrome screen for a second while it boots. My Dad was an engineer, and would get totally hung up on the minutiae of anything technical. Picture him spending a totally inappropriate amount of time adjusting the TV's audio settings, for instance. One day I thought I'd play a prank on him, and changed the welcome message on his phone to say 'SIM CARD ERROR'. It sent him completely bananas, and triggered this huge quest to remedy the problem. He ended up taking it back to the local Vodafone store where he bought it multiple times, and they couldn't figure out what was wrong either. Maybe they got the joke and thought it was too funny, who knows. The store ended up escalating the case to Nokia and authorised an RMA. At which point I figured the joke had gone too far, and I reset the welcome message to 'Dad's Phone'. For some reason, he was happy just to leave it at that. I never confessed what I'd done! It caused way too much fuss, and I'd have been absolutely in for it if anyone figured it out!
I once had a desktop computer that had great uptime, but started to consistently crash when I got up and left the room to get a drink of water.
Turns out it was old building with loose floorboards. The vibrational force of standing up was enough to short out a failing power supply. As long as I sat my desk, it was fine.
But I had a co-worker who had a worse problem with getting up to get a drink of water. Once while she was kitchen, an eight foot steel lighting ballast came loose from the ceiling and felt right onto her chair.That what-if memory still haunts me.
(not disclaiming that it wasn't, but that "chair piston causes EM surge" had me driven crazy for the longest time til I was able to pinpoint the cause)
That reminds me of one. I had a PC that would fail to boot the first time every day. Second and subsequent times were fine, until the next day.
When it stopped happening in the spring, and started again in the fall, it became obvious -- my apartment was too cold. The heat from the first failed boot sufficiently heated up the system to boot the second time.
“WiFi doesn’t work in the summer” is one of the first anecdotes I learned about WiFi when it was still brand new. You set up WiFi between two buildings in the winter, spring comes and the water in the leaves blocks the signal.
I wonder if the feeling is excitement or horror when you encounter one of these weird problems that seems like it has to be the user.
Not computer related really, but I'm reminded of when my Mom was helping set up macs in the lab at my middle school. I, a 4th grader, tagged along and hung out in the other lab across the hall. I got very incredulous looks when i claimed that there was a lizard in there. It was the Midwest over summer break! I was obviously a kid seeing things. There's no lizards here.
Then I produced it, caught under a bin. It was a brown anole that had come back in a plant sent from Florida. I wasn't crazy that day.
Since you mentioned your mom, mine is not as tech savvy. At one point she needed a computer to type something and print it, a simple use case so I came up with this idea of setting up a computer that would give me no tech support trouble, since I was living in another state. I installed CentOS, libre office and made sure the printer was supported.
I told my mom to keep the system up to date and set up an ssh connection for remote access just in case.
A few months go by and one day I receive a phone call that she cannot find the system updater shortcut anymore. I started to think how I could get Gnome to load over ssh, I was sure she moved the icon accidentally or something but decided to google it just in case.
Lo and behold and there is a bug report that due to some bug in package management dependency resolution the graphic software updater GUI could remove… itself… if the user performed a routine system update. It seemed to even affect RHEL at the time if I’m not mistaken.
A yum install command away over ssh and it was solved but that was the day I realized that no matter how stable a distro is famed to be or how much support it has from a company, there was still lots of work to be done until Linux could be seen as friendly enough for the end user.
Most of these are good, but "can't log in while standing up" is just too implausible. I can't possibly be led to believe that every single one of a whole group of technically-literate touch typers failed to notice that keys were swapped.
There also is the (somewhat) famous caps lock gamble in XCOM 2 [1].
Quote: "Hitting the key, through a rube-goldberg-esque series of events, forces all outstanding load requests to be filled immediately in a single frame. This causes a massive hitch, and potentially could crash the game. If you don't care about those adverse effects the synchronous load is faster."
I had one of these myself. WiFi wouldn’t work when my wife was using her laptop in bed. As soon as she gave it to me, it started working again. She thought it was the magic touch of the engineer, but it turned out that when she was in bed, she pulled her knees up and set the computer on her lap, while I would lay down completely and let the computer rest on my chest. Her knees blocked the WiFi signal enough to be quite noticeable.
It's one of my most used utilities, as someone who can't help but nerd-snipe myself on the regular. Example questions that I've used it for, just in the last week:
If I work 42 hours/week, how many minutes is that per year?
I've downloaded 4.91GB in the last minute, what's that in Mbps? How long will it take to download a 76GB game?
This AWS feature costs $0.045/hour, how much is that per month?
This guy I read about traveled 58,000km in 27 years, what's his average speed in m/s?
How much would a 10cm sphere of gold be worth in GBP?
If a 36 inch pipeline can deliver 25580 acre-feet of water in a year, how fast is the water flowing in m/s?
units has (I assume room temp/pressure) densities for all elements, as well as some precious metal prices and currency exchange rates (you need to run the units_cur program regularly to update the database for these). It also has tab completion to make discovering these a bit easier.
The invocation is
You have: goldprice * golddensity * spherevol(10cm/2)
If you find the output a bit hard to parse at times (as I do), you might want to try qalc instead, I use it all the time from the terminal to do conversions:
$ qalc
> 3 millilightseconds to miles
3 milliLightSeconds ≈ 558 mi + 1491 yd + 0.1692913386 ft
I'm not sure if it has all the same units as `units` does, but it replaced my use of it entirely as it can do other useful operations as well
And if you're one of today's lucky 10,000 and haven't heard of the concept of "lucky 10,000", you can read the relevant XKCD here: https://xkcd.com/1053/
Thank you for linking this - I need to save this locally because I reference this all the time. This is one of my favorite internet stories - it's just a great arc!
I got curious what Trey Harris (the original 500 mile story teller) was up to these days, but Google mostly finds me a football player born around that time (2002).
I think this is enough of a classic to be widely known even among younger people. I'm 23 (doing math msc) and I think all the CS people that I know would instantly recognize the 500 miles title.
Though I do somewhat envy the possibility of having read the article close to publication and feel in some sense part of the history when it crops up again like this.
> There’s a lot to the story that’s obviously made up...
Obviously? I think I've had this phone call myself a few times, although in my experience it was never from a statistician and they didn't give me as much data, but I'm pretty sure the story is mostly accurate.
> I think this is nonsense... why would an invalid or incomplete sendmail configuration default to three milliseconds?
This is a wonderful question, and perhaps much more interesting than anything else in the page, but first, let's reproduce the timing;
My desktop, a 2017 Xeon E7-8880 (144 cores of 2.3ghz; 1tb ram) with a load of 2.26 at this moment:
$ time sleep 0.001
real 0m0.004s
user 0m0.001s
sys 0m0.003s
On my i9-10900k (3.7ghz) current load of 3,31:
$ time sleep 0.001
real 0m0,002s
user 0m0,000s
sys 0m0,001s
(In case you think I'm measuring exec; time /bin/echo returns 0's on both machine)
Now as to why this is? Well in order to understand that, you need to understand how connect() actually works, and how to create a timeout for connect(). Those skilled in the art know you've got a number of choices on how to do it, but they all involve multiple steps because connect() does not take a timeout as an argument. Here's one way (not too different than what sendmail does/did):
If you read this carefully, you only need to ask yourself how much time can pass between the top of connect() and the bottom of select(), and if you think it is zero like tedu does, you might probably have the same surprise: Computers are not abstract machines, but made out of matter and powered by energy and thus subject to the laws of physics, and so everything takes time.
For others, the surprise might be that it's still 3msec over twenty years later, and I think that is a much more interesting subject to explore than whether the speed of light exists.
I thought the 3ms was more or less what a low-granularity clock would give you. So, not the clock that gives you nanos, but the big standard one that is useful if you just somewhat care that some timer has run out. Perhaps you use it to count frames (120fps ~ 8.3ms) or check whether some calendar event has happened.
A 333 Hz clock seems like something you might have on computers going back to those days, even if not for the CPU.
Well, first light does 500 miles in 3ms, but the connect signal needs to come back, right? So it should be 250 miles, at most? But this is just a detail.
More importantly, because it seems to assume that all other operations besides the signal actually reaching the destination are instantaneous. As you point out yourself, computers are not abstract machines, so the actual response time between the signal being received by the destination (even assuming it's just one straight line with zero electronics in between) and the destination replying is not zero. I imagine there can be a large variation between physical installations and different types of hardware, so much as to make it very hard to detect a clear 500 miles boundary.
Yes I think I had read those FAQ at some point, they're terribly handwavy though.
"Should have been 6ms instead of 3 for the ACK to come back? Yes, sorry, it was too boring to add"; "Should it be much more and variable because of the routers in between? Yes sure, I probably pinged them and added up the delays"; "Shouldn't plenty of deliveries have failed for destinations much closer than 500 miles? Yes sure, but that must have been the limit..." Etc.
The "destinations much closer than 500 miles" was explicitly handled in the story, I don't know why that was even in the FAQ except that the asker failed reading comprehension.
> "There are a number of destinations within that radius that we can't reach, either, or reach sporadically, but we can never email farther than this radius."
> Obviously? I think I've had this phone call myself a few times, although in my experience it was never from a statistician and they didn't give me as much data, but I'm pretty sure the story is mostly accurate.
Yeah, the original retelling even states up-front:
> The story is slightly altered in order to protect
the guilty, elide over irrelevant and boring details, and generally make
the whole thing more entertaining.
It's pretty common to alter minor details of stories in order to make them easier to follow, not to mention that the entire account is also written several years after it happened, when details are presumably less likely to be completely accurate. Obviously the dialogue is reconstructive for narrative ease; no reader would look at that and assume it's intended to be a verbatim transcript.
Unless the author here can cite specific things that make it truly impossible for anything of that shape to have occurred, I'm not seeing anything that justifies the conclusion "there's a lot to the story that's obviously made up".
> there was a university president who couldn’t send an email more than 500 miles, and the wise sysadmin said that’s not possible, so the president said come to my office, and lo and behold, the emails stopped before going 500 miles.
NO. NO NO NO.
How can you get SO MANY facts wrong when the freaking story is googlable?
This annoys me because I know the original author and I remember when this happened (he told the story a few times).
Let's recap:
> there was a university president
NO! It was the chairman of the statistics department.
> who couldn’t send an email more than 500 miles,
True. Being in the statistics department he had the tools to make actual maps.
> and the wise sysadmin said that’s not possible, so the president said come to my office
Kind of true. There was an office involved.
> and lo and behold, the emails stopped before going 500 miles.
True.
> There’s a lot to the story that’s obviously made up,
NO! Zero of this story was made up.
ALL the people that were involved in the story are still alive. You can literally get them on the phone and talk to them. We're not debating whether or not Han Solo ever used a light saber. THIS SHIT REALLY HAPPENED.
The whole tone of TFA is super frustrating. The original story is funny, well written, and, well, a story meant to be told "over drinks at a conference". TFA misses all the humor and generally seems to be written by a very bitter person.
I think the entire story was made up, but certainly the author admits much of it was made up.
> 4. If you are not 100% sure of the details, then why are there so many details in the story?
> Because with the details, the story looks much better. Do you really think that if I started each sentence with the words “I don’t remember exactly, but it seems to be ...”, then something would have changed? In the end, at the very beginning, I warned that some minor details were changed, and some were intentionally omitted - just to make the story better.
> The second important point is the site where the story was first published. I sent this story to the SAGE (System Administrators Guild) mailing list in the "incredible challenges" section. These were just stories about the most incredible tasks that management sometimes puts to system administrators.
And let's not forget the the post ends with:
> I'm looking for work. If you need a SAGE Level IV with 10 years Perl,
tool development, training, and architecture experience, please email me
at trey@sage.org. I'm willing to relocate for the right opportunity.
Which I think was the true purpose of the (to me) made up story.
I really wouldn't have predicted the extreme amount of centralization, and arguably unnecessary centralization, that we have today for things like university email and web servers. Even 20 years ago when I was in college, the servers I interacted with including email, were all in our school's /16. They did have software packages for LMS and stuff, but those were mostly deployed on-prem.
Today the websites are hosted on third party cloud servers (my school's main website is some company that hosts your Wordpress or Drupal site so you don't have to) and the email by Microsoft or Google. Same for every school it seems. I guess the IT department that used to run all the infra is now probably just a few people in charge of ordering new laptops for faculty/staff when they break, and replacing Wi-Fi access points every 5 years.
Spam is another reason most places don't bother with selfhosting email now. Big providers like GMail aggressively filter unknown servers so if you attempt to host your own and don't setup everything perfectly (or even if you do and you trigger their filter ban threshold) all your email will silently fail to deliver or be blackholed to the Spam folder for the largest email providers and you might never find out or have a way to get them to reconsider.
Something I faced at multiple companies before Google and MS took over was that malware would get on your mail server and start blasting out spam. And then you'd find yourself on a bunch of blacklists thinking they made a mistake but it's because your server was actually spamming.
Meh. Decades ago most universities realised it made sense to separate "run the IT infrastructure that the university runs on" from the CS department, and after that the university IT department followed the same trajectory as the IT department of every other large institution. It doesn't really make sense to run your own email servers any more if your core business is a paper merchant or steel mill or whatever, and it's the same for universities.
I'm sure the same thing happened with e.g. electricity - at first people in the physics department ran their own generators, then at some point the university was using enough electricity for day-to-day stuff like lights that the main generators moved to being operated by the facilities department, and nowadays the university just gets their electricity from the local wholesaler like every other big organisation and probably doesn't have a whole lot of transformer expertise in their maintenance department.
You totally could make that prediction just by thinking about a number of schools in the world, a number of /16s in ipv4 and a rate of ipv6 adoption.
Typically that "IT department" was just a few CS teachers, who assigned some slacking students creating a webpage as a homework, and replacing a bad memory in a server computer as a lab work, and then gave up when that become impossible.
> The poll timeout is 3ms, as specified by the lore. I think this is nonsense, why would an invalid or incomplete sendmail configuration default to three milliseconds?
The answer is that per the original story, it was not defaulting to three milliseconds. It was defaulting to 0, and the 3ms was just how long it took the system to check for a response with a 0 timeout:
> Some experimentation established that on this particular machine with its typical load, a zero timeout would abort a connect call in slightly over three milliseconds.
This is a very different scenario, as it's not clear there should be a poll() there at all (or more likely select() given the age of the story) to match the original, but if there was, the select would have a timeout of 0, not 3ms, and would just happen to be unable to distinguish between 0 and up to 3ms.
There's no competition that's running on copper -- even competitors without latency sensitivity with still be running over fibre because that's just the baseline infrastructure in datacentres, transatlantic etc.
Of course, yes, the HFT firms will be using also the standard tricks of microwave towers, shortwave radio, weather balloon etc, to beat the fibre route.
We have a program which the company who developed lost the ability to rebuild the app for some reason.
It has a 500ms timeout to load some settings from a server in the UK via TLS. If it goes more than that 500ms (or something, it's unclear the exact timeout cause) the app just vapourises.
This is fine in the UK, TLS needs about* 3 times RTT to complete though, so an RTT above about 160ms and it's screwed.
Almost all our users are in the UK, europe, mid-east or east coast USA, and in that 160ms RTT range.
We ran into issues when a dozen people tried to use it in Australia, so the principal still happens with some badly written code.
Is there a library to re-introduce relevant delays into a CDN so that all users experience their own geographically-appropriate response times?
I mean, I want reliability. But I also want Europeans to be able to taste that authentic latency they'd expect from a fledgling startup running out of a garage in San Jose.
It’s a nerd story about short timeouts. Effectively a what is the speed of light or electricity in copper and over infrastructure. It’s a joke that doesn’t make any sense because 3ms was clearly bullshit devised for example. Don’t think about it too hard, it doesn’t suddenly snap into anything meaningful.
connect() will take time. Either you then fail on reiceiving EINPROGRESS, or you attempt a select() with 0 for the timeout, which will also take time. That that time could add up to 3ms on a mid-90's system also used for other things seems entirely plausible to me.
If you’re one of today’s lucky 10,000 and haven’t heard the original 500-mile email story, you can read it at https://web.mit.edu/jemorris/humor/500-miles.
(discussed previously on HN 5 years ago – https://news.ycombinator.com/item?id=23775404 – and 10 years ago – https://news.ycombinator.com/item?id=9338708)
Even after reading the 2025 updated version, reading the original made me absolutely giddy at the end.
I can only imagine the euphoria of reconciling the inputs of “the things I know to be true of computers and email” and “my emails won’t send further than 500 miles”. What a great story - thanks for posting the original.
I collected a list of fun stories of this form a while ago!
- Car allergic to vanilla ice cream: https://www.cs.cmu.edu/~wkw/humour/carproblems.txt
- Can't log in when standing up: https://www.reddit.com/r/talesfromtechsupport/comments/3v52p...
- OpenOffice won't print on Tuesdays: https://bugs.launchpad.net/ubuntu/+source/cupsys/+bug/255161...
- The Wi-Fi only works when it's raining: https://predr.ag/blog/wifi-only-works-when-its-raining/
I’ve seen some weird technical glitches in my career. One that i will always remember is that a customer was very happy with his new big computer, but could not work for multiple hours on it, because his office would get colder and colder when he kept using it. After some mailing and talking over the phone i suggested a visit to his office where i quickly found the cause of the problem: The big computer fan was aimed directly at the thermostat knob of the radiator, so it assumed the entire office was well heated and closed.
It's not quite in the same league as any of this, but when I was a child, we sent our Commodore 64 in for repairs several times because it started "writing" by itself. Gibberish would slowly appear as if someone was randomly hitting the keyboard.
Each time it took several days before they repair centre got to it, and they then contacted us to tell us there was nothing wrong with the computer at all.
After we picked it up, eventually, when it started happening again for the third or fourth time, we realised the problem:
The "large" (a whopping 26") CRT TV we'd recently started placing it under when not in use caused it... A few days away from the TV to dishcharge it, and it was fine - hence why the repair technician didn't find anything.
I know this story is a bit unrelated, but your story brought it to mind (probably the keywords child, repaired several times, etc): When I was a kid my father had a Nokia 3310. Any early Nokia owner would remember how you could configure your own 'welcome message', which would flash up on the phone's monochrome screen for a second while it boots. My Dad was an engineer, and would get totally hung up on the minutiae of anything technical. Picture him spending a totally inappropriate amount of time adjusting the TV's audio settings, for instance. One day I thought I'd play a prank on him, and changed the welcome message on his phone to say 'SIM CARD ERROR'. It sent him completely bananas, and triggered this huge quest to remedy the problem. He ended up taking it back to the local Vodafone store where he bought it multiple times, and they couldn't figure out what was wrong either. Maybe they got the joke and thought it was too funny, who knows. The store ended up escalating the case to Nokia and authorised an RMA. At which point I figured the joke had gone too far, and I reset the welcome message to 'Dad's Phone'. For some reason, he was happy just to leave it at that. I never confessed what I'd done! It caused way too much fuss, and I'd have been absolutely in for it if anyone figured it out!
I once had a desktop computer that had great uptime, but started to consistently crash when I got up and left the room to get a drink of water.
Turns out it was old building with loose floorboards. The vibrational force of standing up was enough to short out a failing power supply. As long as I sat my desk, it was fine.
But I had a co-worker who had a worse problem with getting up to get a drink of water. Once while she was kitchen, an eight foot steel lighting ballast came loose from the ceiling and felt right onto her chair.That what-if memory still haunts me.
> The vibrational force of standing up was enough to short out a failing power supply
Or, was it?
https://superuser.com/questions/1406140/monitor-screen-that-...
(not disclaiming that it wasn't, but that "chair piston causes EM surge" had me driven crazy for the longest time til I was able to pinpoint the cause)
I saw this in an office while working on an embedded project where our dev boards had no EM shielding.
Standing up from the chair was enough to cause it to crash.
That reminds me of one. I had a PC that would fail to boot the first time every day. Second and subsequent times were fine, until the next day.
When it stopped happening in the spring, and started again in the fall, it became obvious -- my apartment was too cold. The heat from the first failed boot sufficiently heated up the system to boot the second time.
Canadian winter for you, I guess.
“WiFi doesn’t work in the summer” is one of the first anecdotes I learned about WiFi when it was still brand new. You set up WiFi between two buildings in the winter, spring comes and the water in the leaves blocks the signal.
This also happens with satellite TV.
This site has a collection of them: https://500mile.email/
Monitor switches off when I sit down deserves to be on that list (even if it's hardware, not software): https://old.reddit.com/r/techsupport/comments/2rsivw/monitor...
- A Story About ‘Magic' http://www.catb.org/jargon/html/magic-story.html
I wonder if the feeling is excitement or horror when you encounter one of these weird problems that seems like it has to be the user.
Not computer related really, but I'm reminded of when my Mom was helping set up macs in the lab at my middle school. I, a 4th grader, tagged along and hung out in the other lab across the hall. I got very incredulous looks when i claimed that there was a lizard in there. It was the Midwest over summer break! I was obviously a kid seeing things. There's no lizards here.
Then I produced it, caught under a bin. It was a brown anole that had come back in a plant sent from Florida. I wasn't crazy that day.
Since you mentioned your mom, mine is not as tech savvy. At one point she needed a computer to type something and print it, a simple use case so I came up with this idea of setting up a computer that would give me no tech support trouble, since I was living in another state. I installed CentOS, libre office and made sure the printer was supported.
I told my mom to keep the system up to date and set up an ssh connection for remote access just in case.
A few months go by and one day I receive a phone call that she cannot find the system updater shortcut anymore. I started to think how I could get Gnome to load over ssh, I was sure she moved the icon accidentally or something but decided to google it just in case.
Lo and behold and there is a bug report that due to some bug in package management dependency resolution the graphic software updater GUI could remove… itself… if the user performed a routine system update. It seemed to even affect RHEL at the time if I’m not mistaken.
A yum install command away over ssh and it was solved but that was the day I realized that no matter how stable a distro is famed to be or how much support it has from a company, there was still lots of work to be done until Linux could be seen as friendly enough for the end user.
I don't know about that conclusion. Windows will occasionally break itself worse than that.
Most of these are good, but "can't log in while standing up" is just too implausible. I can't possibly be led to believe that every single one of a whole group of technically-literate touch typers failed to notice that keys were swapped.
It seems pretty easy to overlook. Especially because the correct position is alphabetically backwards.
As seen on HN:
Car allergic to vanilla ice cream: https://news.ycombinator.com/item?id=37584399 and https://news.ycombinator.com/item?id=13347852
The Wi-Fi only works when it's raining: https://news.ycombinator.com/item?id=39896371
there's also the story that wiggling the mouse in Win95 when installing something really does make it go faster. https://retrocomputing.stackexchange.com/questions/11533/why...
There also is the (somewhat) famous caps lock gamble in XCOM 2 [1].
Quote: "Hitting the key, through a rube-goldberg-esque series of events, forces all outstanding load requests to be filled immediately in a single frame. This causes a massive hitch, and potentially could crash the game. If you don't care about those adverse effects the synchronous load is faster."
[1] https://www.eurogamer.net/a-single-button-press-skips-loadin...
At one point, my scanner only worked when my daughter was awake - never when she was asleep (nighttime or napping).
I had one of these myself. WiFi wouldn’t work when my wife was using her laptop in bed. As soon as she gave it to me, it started working again. She thought it was the magic touch of the engineer, but it turned out that when she was in bed, she pulled her knees up and set the computer on her lap, while I would lay down completely and let the computer rest on my chest. Her knees blocked the WiFi signal enough to be quite noticeable.
I have a tough time deciding a favorite between this story and “the ultimate in garbage collection”: https://devblogs.microsoft.com/oldnewthing/20180228-00/?p=98...
Does this system release all the memory it allocates?
Yes, it releases it at about 200 meters per second.
"...even of a relatively impoverished department like statistics."
Perfection.
It's one of my most used utilities, as someone who can't help but nerd-snipe myself on the regular. Example questions that I've used it for, just in the last week:
If I work 42 hours/week, how many minutes is that per year?
I've downloaded 4.91GB in the last minute, what's that in Mbps? How long will it take to download a 76GB game?
This AWS feature costs $0.045/hour, how much is that per month?
This guy I read about traveled 58,000km in 27 years, what's his average speed in m/s?
How much would a 10cm sphere of gold be worth in GBP?
If a 36 inch pipeline can deliver 25580 acre-feet of water in a year, how fast is the water flowing in m/s?
Also check out Kragen's examples from a thread a couple of years ago!
https://news.ycombinator.com/item?id=36988917
Wow, that’s an awesome resource actually. Thanks!
> How much would a 10cm sphere of gold be worth in GBP?
Is there some trick to this? Or do you have to input it like:
You have: 4/3pi(10 cm)^319320 kg/m^345000 GBP/kg
(What ChatGPT gave me)
units has (I assume room temp/pressure) densities for all elements, as well as some precious metal prices and currency exchange rates (you need to run the units_cur program regularly to update the database for these). It also has tab completion to make discovering these a bit easier.
The invocation is
You have: goldprice * golddensity * spherevol(10cm/2)
You want: GBP
Neat! Thank you!
TIL -- thank you, brother!
You can just save a step and ask ChatGPT the answer. It can google the current spot price of gold.
You can just save a step of double-checking everything by using WolframAlpha
https://www.wolframalpha.com/input?i=%2810cm+sphere+of+gold+...
Sure, but then I need to do all the math to verify the answer it gives me isn’t gibberish anyway.
What if its wrong
>25580 acre-feet of water
This is why we can't have nice things.
I always want to reach for `units`, but I'm perennially baffled by the output! What's up with the * and /?
The * value is the result of converting 10 miles to meters, as requested.
The / value is the inverse of that in case you wanted that, ie 0.1 meters in miles.
It's explained in `man 1 units`
Oh, I know it's explained in the man page. I read it every time and promptly forget because I can't internalize the choice of notation.
If you find the output a bit hard to parse at times (as I do), you might want to try qalc instead, I use it all the time from the terminal to do conversions:
I'm not sure if it has all the same units as `units` does, but it replaced my use of it entirely as it can do other useful operations as well* multiply
/ divide
I am familiar.
I usually call it non-interactively:
in which case it's always the first line I want.(The second line is telling me 1USD is 0.00422357 of 1500DKK.)
Note if you use the currency conversions,
is needed to keep them up-to-date.the * is denoting the conversion from your first unit to your second, the / denotes the other way.
You have: 1 miles You want: feet * 5280 / 0.00018939394
In the above example, 1 mile is 5280 feet, and 1 foot is 0.00018939394 miles
If I do 2 miles to feet, the values are doubled (or halved for the reverse conversion)
You have: 2 miles You want: feet * 10560 / 9.469697e-05
And if you're one of today's lucky 10,000 and haven't heard of the concept of "lucky 10,000", you can read the relevant XKCD here: https://xkcd.com/1053/
9,999 remaining.
And if you're one of today's lucky 10,000 who haven't heard of XKCD: https://www.explainxkcd.com/wiki/index.php/xkcd
Thank you for linking this - I need to save this locally because I reference this all the time. This is one of my favorite internet stories - it's just a great arc!
I got curious what Trey Harris (the original 500 mile story teller) was up to these days, but Google mostly finds me a football player born around that time (2002).
Presumably this is the author given their UNC and SysAdmin background: https://www.linkedin.com/in/treyharris
I found it via a "trey harris sage.org" search on Google.
This was the highest-voted submission, posted two years ago: https://news.ycombinator.com/item?id=37576633
First time I'm hearing about this actually, thank you.
reminds me of the magic/more magic switch story
Easily my favorite story on the internet
Thanks for letting me be one of the lucky ones.
Obligatory xkcd 10,000 lucky people explainer: https://xkcd.com/1053/
Reading the title and knowing exactly what this is about kind of makes me feel old to be honest.
If it makes you feel better, I'm so old I read the title and 3/4 of the original story before I realised I'd read it before.
I think this is enough of a classic to be widely known even among younger people. I'm 23 (doing math msc) and I think all the CS people that I know would instantly recognize the 500 miles title.
Though I do somewhat envy the possibility of having read the article close to publication and feel in some sense part of the history when it crops up again like this.
You could have discovered that story yesterday :-)
> Reading the title and knowing exactly what this is about kind of makes me feel old to be honest.
Let's go for experienced and ready to educate the young'uns.
I thought this was about consolidation of email providers so your email never leaves a single datacenter:
"10 years ago we couldn't send an email 500 miles, but these days we can't send it 500 miles because it just routes internally."
Too bad, I think that would have been more interesting to read.
This is the first roadblock the author runs into - lots of universities ping at <2ms, likely because everyone's on the same datacenter.
> There’s a lot to the story that’s obviously made up...
Obviously? I think I've had this phone call myself a few times, although in my experience it was never from a statistician and they didn't give me as much data, but I'm pretty sure the story is mostly accurate.
> I think this is nonsense... why would an invalid or incomplete sendmail configuration default to three milliseconds?
This is a wonderful question, and perhaps much more interesting than anything else in the page, but first, let's reproduce the timing;
My desktop, a 2017 Xeon E7-8880 (144 cores of 2.3ghz; 1tb ram) with a load of 2.26 at this moment:
On my i9-10900k (3.7ghz) current load of 3,31: (In case you think I'm measuring exec; time /bin/echo returns 0's on both machine)Now as to why this is? Well in order to understand that, you need to understand how connect() actually works, and how to create a timeout for connect(). Those skilled in the art know you've got a number of choices on how to do it, but they all involve multiple steps because connect() does not take a timeout as an argument. Here's one way (not too different than what sendmail does/did):
If you read this carefully, you only need to ask yourself how much time can pass between the top of connect() and the bottom of select(), and if you think it is zero like tedu does, you might probably have the same surprise: Computers are not abstract machines, but made out of matter and powered by energy and thus subject to the laws of physics, and so everything takes time.For others, the surprise might be that it's still 3msec over twenty years later, and I think that is a much more interesting subject to explore than whether the speed of light exists.
I thought the 3ms was more or less what a low-granularity clock would give you. So, not the clock that gives you nanos, but the big standard one that is useful if you just somewhat care that some timer has run out. Perhaps you use it to count frames (120fps ~ 8.3ms) or check whether some calendar event has happened.
A 333 Hz clock seems like something you might have on computers going back to those days, even if not for the CPU.
> 144 cores of 2.3ghz; 1tb ram
I can't help but feel that's somewhat excessive for a desktop. Have you considered closing a few browser tabs?
> I can't help but feel that's somewhat excessive for a desktop.
I got it on ebay for €2k. You can't not expect me to use it as a desktop.
> Have you considered closing a few browser tabs?
No? I mean actually no: I made a brotab+wofi script that allows me to search tabs, and I find it a lot more convenient than bookmarks.
Here's the relevant bits:
Works fine on 19,294 tabs at the moment...I think I love you.
Jesus christ
Never got this, honestly.
Well, first light does 500 miles in 3ms, but the connect signal needs to come back, right? So it should be 250 miles, at most? But this is just a detail.
More importantly, because it seems to assume that all other operations besides the signal actually reaching the destination are instantaneous. As you point out yourself, computers are not abstract machines, so the actual response time between the signal being received by the destination (even assuming it's just one straight line with zero electronics in between) and the destination replying is not zero. I imagine there can be a large variation between physical installations and different types of hardware, so much as to make it very hard to detect a clear 500 miles boundary.
Or am I missing something?
The author wrote an FAQ several years after the original story that answers most of your questions. https://www.ibiblio.org/harris/500milemail-faq.html
Yes I think I had read those FAQ at some point, they're terribly handwavy though.
"Should have been 6ms instead of 3 for the ACK to come back? Yes, sorry, it was too boring to add"; "Should it be much more and variable because of the routers in between? Yes sure, I probably pinged them and added up the delays"; "Shouldn't plenty of deliveries have failed for destinations much closer than 500 miles? Yes sure, but that must have been the limit..." Etc.
And there's also this nuance from the article text,
"The secret here is the kernel will always round 3ms up to at least one whole tick, 10ms."
Interestingly, not covered in the FAQ.
If you account for signal propagation speed through copper and the unaccounted ACK, I think the timing actually works out about the same.
The "destinations much closer than 500 miles" was explicitly handled in the story, I don't know why that was even in the FAQ except that the asker failed reading comprehension.
> "There are a number of destinations within that radius that we can't reach, either, or reach sporadically, but we can never email farther than this radius."
> Obviously? I think I've had this phone call myself a few times, although in my experience it was never from a statistician and they didn't give me as much data, but I'm pretty sure the story is mostly accurate.
Yeah, the original retelling even states up-front:
> The story is slightly altered in order to protect the guilty, elide over irrelevant and boring details, and generally make the whole thing more entertaining.
It's pretty common to alter minor details of stories in order to make them easier to follow, not to mention that the entire account is also written several years after it happened, when details are presumably less likely to be completely accurate. Obviously the dialogue is reconstructive for narrative ease; no reader would look at that and assume it's intended to be a verbatim transcript.
Unless the author here can cite specific things that make it truly impossible for anything of that shape to have occurred, I'm not seeing anything that justifies the conclusion "there's a lot to the story that's obviously made up".
> there was a university president who couldn’t send an email more than 500 miles, and the wise sysadmin said that’s not possible, so the president said come to my office, and lo and behold, the emails stopped before going 500 miles.
NO. NO NO NO.
How can you get SO MANY facts wrong when the freaking story is googlable?
Here's the original email: https://web.mit.edu/jemorris/humor/500-miles
Here's the FAQ that covers the ambiguous parts: https://www.ibiblio.org/harris/500milemail-faq.html
This annoys me because I know the original author and I remember when this happened (he told the story a few times).
Let's recap:
> there was a university president
NO! It was the chairman of the statistics department.
> who couldn’t send an email more than 500 miles,
True. Being in the statistics department he had the tools to make actual maps.
> and the wise sysadmin said that’s not possible, so the president said come to my office
Kind of true. There was an office involved.
> and lo and behold, the emails stopped before going 500 miles.
True.
> There’s a lot to the story that’s obviously made up,
NO! Zero of this story was made up.
ALL the people that were involved in the story are still alive. You can literally get them on the phone and talk to them. We're not debating whether or not Han Solo ever used a light saber. THIS SHIT REALLY HAPPENED.
Sheesh.
The whole tone of TFA is super frustrating. The original story is funny, well written, and, well, a story meant to be told "over drinks at a conference". TFA misses all the humor and generally seems to be written by a very bitter person.
I think the entire story was made up, but certainly the author admits much of it was made up.
> 4. If you are not 100% sure of the details, then why are there so many details in the story?
> Because with the details, the story looks much better. Do you really think that if I started each sentence with the words “I don’t remember exactly, but it seems to be ...”, then something would have changed? In the end, at the very beginning, I warned that some minor details were changed, and some were intentionally omitted - just to make the story better.
> The second important point is the site where the story was first published. I sent this story to the SAGE (System Administrators Guild) mailing list in the "incredible challenges" section. These were just stories about the most incredible tasks that management sometimes puts to system administrators.
And let's not forget the the post ends with:
> I'm looking for work. If you need a SAGE Level IV with 10 years Perl, tool development, training, and architecture experience, please email me at trey@sage.org. I'm willing to relocate for the right opportunity.
Which I think was the true purpose of the (to me) made up story.
I really wouldn't have predicted the extreme amount of centralization, and arguably unnecessary centralization, that we have today for things like university email and web servers. Even 20 years ago when I was in college, the servers I interacted with including email, were all in our school's /16. They did have software packages for LMS and stuff, but those were mostly deployed on-prem.
Today the websites are hosted on third party cloud servers (my school's main website is some company that hosts your Wordpress or Drupal site so you don't have to) and the email by Microsoft or Google. Same for every school it seems. I guess the IT department that used to run all the infra is now probably just a few people in charge of ordering new laptops for faculty/staff when they break, and replacing Wi-Fi access points every 5 years.
Spam is another reason most places don't bother with selfhosting email now. Big providers like GMail aggressively filter unknown servers so if you attempt to host your own and don't setup everything perfectly (or even if you do and you trigger their filter ban threshold) all your email will silently fail to deliver or be blackholed to the Spam folder for the largest email providers and you might never find out or have a way to get them to reconsider.
Something I faced at multiple companies before Google and MS took over was that malware would get on your mail server and start blasting out spam. And then you'd find yourself on a bunch of blacklists thinking they made a mistake but it's because your server was actually spamming.
You answered your own question. IT staff is expensive, a SaaS subscription less-so.
You, sir, obviously have not dealt with enterprise SaaS subscriptions
Meh. Decades ago most universities realised it made sense to separate "run the IT infrastructure that the university runs on" from the CS department, and after that the university IT department followed the same trajectory as the IT department of every other large institution. It doesn't really make sense to run your own email servers any more if your core business is a paper merchant or steel mill or whatever, and it's the same for universities.
I'm sure the same thing happened with e.g. electricity - at first people in the physics department ran their own generators, then at some point the university was using enough electricity for day-to-day stuff like lights that the main generators moved to being operated by the facilities department, and nowadays the university just gets their electricity from the local wholesaler like every other big organisation and probably doesn't have a whole lot of transformer expertise in their maintenance department.
You totally could make that prediction just by thinking about a number of schools in the world, a number of /16s in ipv4 and a rate of ipv6 adoption.
Typically that "IT department" was just a few CS teachers, who assigned some slacking students creating a webpage as a homework, and replacing a bad memory in a server computer as a lab work, and then gave up when that become impossible.
> The poll timeout is 3ms, as specified by the lore. I think this is nonsense, why would an invalid or incomplete sendmail configuration default to three milliseconds?
The answer is that per the original story, it was not defaulting to three milliseconds. It was defaulting to 0, and the 3ms was just how long it took the system to check for a response with a 0 timeout:
> Some experimentation established that on this particular machine with its typical load, a zero timeout would abort a connect call in slightly over three milliseconds.
This is a very different scenario, as it's not clear there should be a poll() there at all (or more likely select() given the age of the story) to match the original, but if there was, the select would have a timeout of 0, not 3ms, and would just happen to be unable to distinguish between 0 and up to 3ms.
Yeah, the article is a good one overall, but the truthering is obnoxious, especially since it hinges on a basic misreading of the original story.
The original story is also about the statistics department, not the university president. It would be nice to get such details right.
I clicked the story wondering if the speed of light has changed since the late 90s.
Apparently not.
It’s still speed of light in a medium, which is not speed of light. Electricity over copper it is 2/3 iirc.
speed of packets over copper I think is actually faster than fibre
It seems to depend on the cable type: https://en.wikipedia.org/wiki/Velocity_factor#Typical_veloci...
HFT firms have entire infrastructure that runs very close to the speed of light, beating the competition that runs on antiquated copper.
There's no competition that's running on copper -- even competitors without latency sensitivity with still be running over fibre because that's just the baseline infrastructure in datacentres, transatlantic etc.
Of course, yes, the HFT firms will be using also the standard tricks of microwave towers, shortwave radio, weather balloon etc, to beat the fibre route.
There’s always competition running on copper, shitty little traders that think they can beat the big firms.
I don't think the switches connecting to any real exchanges support this
~200,000km/s is the speed of light in fiber optics. Electromagnetic propagation in copper is more like 99% c.
The insulating material significantly decreases the propagation speed: https://en.wikipedia.org/wiki/Velocity_factor#Typical_veloci...
We have a program which the company who developed lost the ability to rebuild the app for some reason.
It has a 500ms timeout to load some settings from a server in the UK via TLS. If it goes more than that 500ms (or something, it's unclear the exact timeout cause) the app just vapourises.
This is fine in the UK, TLS needs about* 3 times RTT to complete though, so an RTT above about 160ms and it's screwed.
Almost all our users are in the UK, europe, mid-east or east coast USA, and in that 160ms RTT range.
We ran into issues when a dozen people tried to use it in Australia, so the principal still happens with some badly written code.
Patching the binary is an option, though it’s tricky I would attempt it anyway.
Is there a library to re-introduce relevant delays into a CDN so that all users experience their own geographically-appropriate response times?
I mean, I want reliability. But I also want Europeans to be able to taste that authentic latency they'd expect from a fledgling startup running out of a garage in San Jose.
[dead]
Don't get it
Data can only go about 500 miles in 3ms, and in the original story, that's how long the system took to time out, and would fail to send the email
It’s a test of an old probably apocryphal story about a university that couldn’t send an email more than 500 miles: https://web.mit.edu/jemorris/humor/500-miles
Both the person who supposedly configured Sendmail, and the person who wrote the story, have defended the truthfulness of it on HN in the past.
Good to know! I do love the story.
Commenting late on this but I seriously didn't know about the story beforehand.
It’s a nerd story about short timeouts. Effectively a what is the speed of light or electricity in copper and over infrastructure. It’s a joke that doesn’t make any sense because 3ms was clearly bullshit devised for example. Don’t think about it too hard, it doesn’t suddenly snap into anything meaningful.
Why do you think it's "clearly bullshit"?
connect() will take time. Either you then fail on reiceiving EINPROGRESS, or you attempt a select() with 0 for the timeout, which will also take time. That that time could add up to 3ms on a mid-90's system also used for other things seems entirely plausible to me.
[dead]