obi1kenobi

It's not self-cancellation in the way you're interpreting the title :)

Author here. This! The point isn't to name and shame, but to illustrate a complex failure mode. I too could see myself writing this bug!

Hi! Author here. You're right — but two things to consider here.

First, that quote is referring to human-made systems, not natural ones (as is the rest of the essay!) and I think our views align on whether human systems regularly work.

Second, natural systems (and all complex-enough systems) are always running in some degraded fashion. So what "working" means is ambiguous: they are broken, yet accomplishing the goal. The quote from the essay refers to "working" in the "free of faults" sense, in which I again think our views align.

The site's description says: "I was feeling nostalgic for the Windows Bubbles Screensaver, so I made my own, much more relaxing version."

Click the bubbles and they pop! Very satisfying :)

I'm sure of it. And yet based on this rapidly getting to the front page, it seems like many of us are part of today's lucky ten thousand: https://xkcd.com/1053/

Might be more than ten thousand, even, based on the reactions :)

The shell script starts with the following comment:

    # All the code is wrapped in a main function that gets called at the
    # bottom of the file, so that a truncated partial download doesn't end
    # up executing half a script.

Seems like another user with way more experience than me did an excellent job explaining the situation -- I enjoyed reading their answer!

Oh wow, what a read! Great story, thanks for sharing :)

(Author here) The image is AI generated. I did not use any AI to write the post itself.

That's just my style of writing, you can check my pre-GPT posts and compare if you'd like.

Haha sadly from reading many of the rest of the comments, the typical HN reader seems unconvinced that trees or rain could impede Wi-Fi signals, because their Wi-Fi at home goes through walls just fine. A few even suggested I shouldn't have bothered with Wi-Fi and instead just laid cable across a few city blocks instead :)

But I do appreciate precise language and the desire to help people learn new things, so thanks for helping make the distinction between MIMO and beamforming clear! I hope at least a few more people know about it now thanks to your comments.

Wow! Are you maybe able to find a demo video of this? I'd love to see it!

(I'm the author of the post btw)

Related, sure!

But it could be rain helping close a circuit on a rusty antenna connector port. Or rain improving the grounding of some neighboring circuit that otherwise drains through the metal scaffolding the antenna is attached to. Or rain attenuating a neighbor's own Wi-Fi that otherwise might have been aggressively transmitting on the same channel as our units.

The rain and the Wi-Fi devices were clearly related. How they were related, was not clear. Aging hardware rusts, breaks, gets yanked around or unseated or pulled out of the ground, or has water enter in places where it shouldn't be.

I was already running diagnostics on everything to figure out which devices might be faulty (local AP, local bridge unit, local antenna, remote antenna, remote bridge unit, remote switch, remote modem/router, upstream connection to ISP) so checking for "update gone wrong" was a 3 second job: I was already in the admin UI, so check logs, nope, no recent updates, done. I'd rather spend 3 seconds checking something that probably isn't the problem but I can know for sure in 3 seconds than risk climbing precariously up a scaffold 30ft in the air only to realize it was just something I could have solved at a keyboard instead.

Risk/reward. Low risk, low reward is okay too if it's super fast and already on the way.

(Author here) For our Wi-Fi bridge, the devices on both ends were set to max power.

I don't recall them being able to change data rates very much (if at all) because the ones at the beginning of the story were 802.11g devices, and 802.11g didn't have channel bonding capability or similar tricks up its sleeve. Newer equipment definitely has more options like this.

Right. This is a multiple timelines problem.

This story happened a bit over 10 years ago at this point. At the time of the story, the Wi-Fi bridge was already almost 10 years old -- we'd had the same equipment since I first remember getting internet at home.

That means the antennas at the start of the story were mid-2000s mid-tier consumer level equipment. I don't think a 16-17dB antenna would have been $35 at the time, in either mid-2000s dollars or in today's dollars. I also grew up in a country much poorer than the US, where $35 could feed a family for a week.

At the end of the post, we upgraded to 802.11n antennas (but still tech from 10+ years ago) which solved the problem by being newer, nicer, and having beamforming + MIMO capability which let them be more tolerant of obstacles (effectively, get more dB at the same emitted power level).

(Author here) Across several city blocks, in fact, and longer than the max range of Ethernet on normal (Cat 5/5e/6) cables.

Past ~300ft/100m, you need a repeater even for Ethernet. We would have needed at least one repeater somewhere along the line, which adds even more cost and complexity on top of needing to get permits from the city and approvals from all the neighbors in between. Anyone that says "just go get a permit from the city" has never tried doing it.

(Author here) Worse: to the balcony of our apartment building. Imagine asking your HOA how they'd feel about you mounting your antenna "higher" AKA on someone else's balcony or on the roof above someone else's apartment.

"Just" move it higher vs replace ~10yr old (at the time) equipment with newer, faster equipment that doesn't have the problem? Easy answer if you ask me, and I'd make the same choice again with ~10yrs of retrospect -- the same 802.11n antennas are still there today!

(Author here) Yeah, my dad's company does this stuff for a living, so I learned to distinguish all the terminology very early on :)

Even if you are looking at the turbines "edge-on," there's probably going to be a noticeable Doppler return as well.

Plastic drones with plastic propellers are still visible on radar because the tiny propellers spin super fast, so they light up like a Christmas tree on Doppler radar because the approaching vs receding velocities of the blades are so different.

(Author here) I'm worried they might combine in a way that leaves them not working neither rain nor shine!

(Author here) I didn't forget, it just didn't seem like the most likely problem.

Like I said in a reply to a sibling to your comment, the gear was ~10yrs old at the time and had been working fine until then. It was perched in a very inconvenient spot because it had to "look around the corner" of the building, so checking the line of sight wasn't just a case of looking out the window.

I went in order of "most likely to be the problem, weighted by how easy they were to check." This is a debugging strategy that has served me well, and I don't regret using it that time either.

(Author here)

I didn't think to check the line of sight because I was primed by the fact the bridge had been running fine for 10 years. With networking gear that old, it seemed more likely that a device/cable/power brick had just gone bad with age.

Also, the antenna is on some metal scaffolding propped out 6ft past the edge of our balcony, because it needs to "look around the corner" of the building. It's 30ft in the air, and checking the line of sight involved climbing up there. It certainly wasn't the easiest nor the likeliest thing to check, so I didn't check it first.

Multiple people in the comments just here on HN have mentioned having weird situations caused by routers that had gone bad. I imagine most of their routers weren't 10 years old when they started acting up. How old is your router?

(Author here.) Yeah, I get where you're coming from. Ultimately, this was an editing decision first and foremost.

Beamforming is cool and magical, and MIMO even more so. The post wasn't intended as a primer on wireless technology, just as a fun read for folks to enjoy. I tried to sprinkle in some nerd-snipe-quality technical detail and offer links for folks who might want to dig in, and MIMO is explicitly discussed in both the 802.11n and in the several links on beamforming I provided.

I barely managed to explain beamforming without that sidenote turning into a paragraph of its own. I don't think I could have done MIMO justice in a sidenote.

(Author here) I'm not a tree expert, so ... a tall deciduous one? Sorry!

(I'm the author.) I really like trees! So I wouldn't have wanted to cut it down or even prune it.

Also, I hate operational (ongoing) solutions to problems. Pruning it would have been exactly that kind of solution -- we'd have had to prune it regularly or else it would have kept being a problem every so often.

The hardware fix was easier: our equipment was already a bit old and slow, the upgrade fixed the rain problem while also making it faster, and it's not something we've had to tweak since. I've long since moved out, but my parents still use that same 802.11n bridge today!

No antenna is directional enough to overcome n^2 scaling. Especially not the mid-tier consumer-grade hardware I would have had access to at the time.

Rough rule of thumb, a consumer-grade directional antenna (at least at the time, maybe they've improved in the last 10yrs) will give your signal strength a one-digit multiplier (say ~8x), meaning ~7-10dB. But that n^2 means that improvement only takes you 2-3x farther, not 8x.

Here we're talking about ~100x the distance, which would need a 10000x = 40dB improvement in signal strength. AFAIK an antenna like that would cost more than the entire city block where I grew up

I'm the author. Among other things, it's a distance problem -- WiFi can go through walls when the router is right there. But distance attenuates the signal as distance squared, and in this case we're talking about hundred+ yards/meters instead of just a couple.

The work you cited is very impressive and very welcome.

But you seem to be implying that `std::unordered_map` is the default choice one would use, which in my experience is not accurate -- it is well-known to have serious perf shortcomings, and everyone I know uses some other implementation by default. Even so, the delta from `std::unordered_map` to the improved hashtable in the blog post is impressive, and just shy of 10x.

Graph algorithms frequently have 10x improvements from one state-of-the-art approach to the next -- for example, here's one from my own research[1]. The delta between state-of-the-art and "good default" in graph algorithms would often be around 100-1000x. And comparing state-of-the-art to the equivalent of an `std::unordered_map` would be another 10-100x on top of that, so 1000-100000x total.

[1]: https://dl.acm.org/doi/10.1145/3210377.3210395

Two problems I see here, based on the research I've done in high-performance graph algorithms:

- It's hard to find a "good-enough" graph implementation. The best hashtable is only a handful of percent better than the built-in ones. The best graph impl is 1000x or more better than any generic built-in one could be, so there's much more incentive to specialize (and people already specialize hashtables for just a handful of percent speedup!)

- The baseline complexity level of implementing a reasonable hashtable is fairly high, even if for a small dataset. The baseline complexity of implementing a graph algorithm for a small dataset is pretty low, and the real problems come in later / at larger scale. So in graphs there's less incentive to learn a complex library's API when "I could just hack it myself," unlike for hashtables where the API is simple and doing it myself is much harder.

As someone who did a lot of work with graphs, "why don't programming languages have a built-in graph data type?" is a question I’ve been asked a million times.

I'm thrilled I'll be able to point folks to a much more in-depth analysis like the one here, instead of saying some variation of "it's really hard to do it well" and having them just take my word for it.

Trustfall queries are also how the Rust semver linter `cargo-semver-checks` works. It's cool to see more projects putting it the engine to good use!

I'm the Trustfall maintainer, happy to answer questions about the query engine or how oxlint or cargo-semver-checks use it.

I also recently gave a talk at P99 CONF on how cargo-semver-checks used Trustfall's optimizations API to get a 2000x speedup: https://www.youtube.com/watch?v=Fqo8r4bInsk