apenwarr
apenwarr.ca · Personal blog · on HN since 2009
Avery Pennarun writes on networking, software engineering, tech debt, and how tech companies and executives work.
What HN saysHN commenters recommend his code and writing, and often point to his IPv6 essay, noting it has been submitted many times. His BeamLab diagram also gets cited.
253HN people shared it
124linked it in comments
281stories submitted
13Kstory points
4 months agolast shared
2009people per year2026
Most-shared posts
- 1The world in which IPv6 was a good design (2017)29 people · 725 points · first shared 2019 · 238 comments on HN
- 2A log/event processing pipeline you can't have (2019)20 people · 211 points · first shared 2019 · 40 comments on HN
- 3What do executives do, anyway?17 people · 708 points · first shared 2019 · 203 comments on HN
- 4An epic treatise on scheduling, bug tracking, and triage (2017)15 people · 79 points · first shared 2019 · 15 comments on HN
- 5Forget privacy: you're terrible at targeting anyway13 people · 454 points · first shared 2019 · 114 comments on HN
- 6Mtime comparison considered harmful11 people · 281 points · first shared 2018 · 62 comments on HN
- 7The strange story of etherpad9 people · 429 points · first shared 2011 · 74 comments on HN
- 8Everything you never wanted to know about file locking8 people · 174 points · first shared 2010 · 14 comments on HN
- 9Tech Debt Metaphor Maximalism8 people · 12 points · first shared 2023 · discussion on HN
- 10The Gift of It's Your Problem Now(2021-12-29)8 people · 1 points · first shared 2017 · discussion on HN
- 11The gift of it's your problem now7 people · 760 points · first shared 2021 · 293 comments on HN
- 12Systems design explains the world: volume 17 people · 348 points · first shared 2020 · 152 comments on HN
- 13An epic treatise on scheduling, bug tracking, and triage7 people · 243 points · first shared 2017 · 65 comments on HN
- 14IPv4, IPv6, and a sudden change in attitude7 people · 118 points · first shared 2020 · 182 comments on HN
- 15Absolute Scale Corrupts Absolutely6 people · 231 points · first shared 2019 · 51 comments on HN
What HN people wrote when they linked it
beagle3 · 2011-01-12
for C code: Anything by djb. http://cr.yp.to Unconventional, but top quality.
for C or Python code: Anything by Avery Pennarun (http://apenwarr.ca - his stuff is on GitHub)
for C or Lua code: Anything by Mike Pall (http://luajit.org)
The Python interpreter is mostly a joy to read.
FLTK is a great example of C++ code from the days before template worms ate everyone's brains.
NobodyNada · 2025-09-17
> Probably somewhere on the internet is a fantastic interactive diagram that would clearly demonstrate this for you, but I couldn't google one up. Links solicited.
Here's one: https://apenwarr.ca/beamlab -- as well as the author's writeup: https://apenwarr.ca/log/20140801
The author is focused on beamforming WiFi signals, but the principle is exactly the same whether it's a radio wave or a sound wave.
ignoramous · 2025-06-04
> Building a profitable business reduces both the problem and the solution space by a huge margin, and if you can find a way to get rid of that, the space opens up.
That's one way to look at it. Usually though, for upstarts, what's paramount is not the profits part, but the risks inherent in working on a solution for a perceived problem (or worse, for customers one is ill-placed to sell to [0]). I like what Seibel recommends: the v1 must solve an acute problem for the customer to pay up [1]. From there, building out a holistic product may put our upstart on path to growth & profitability while simultaneously expanding the scope of the problem space building such a product brings [2].
[0] https://www.michaelseibel.com/blog/users-you-don-t-want
[1] https://news.ycombinator.com/item?id=13109480
[2] https://apenwarr.ca/log/20211024
oftenwrong · 2025-03-21
I recommend reading The world in which IPv6 was a good design by apenwarr:
https://apenwarr.ca/log/20170810
It has been submitted many times here:
https://hn.algolia.com/?dateRange=all&page=0&prefix=true&q…
You will find at the end that it has received an update of sorts here:
https://tailscale.com/blog/two-internets-both-flakey
omoikane · 2024-08-16
I am saying that old school projects aren't paying the developers' bills because they aren't profitable. The developers realize this too, there is only so much altruism to go around but you got mouths to feed and rents to pay.
As an alternative to working on a second job to fund their passion, we are seeing developers trying various things to make their one passion job pay, such as licensing tweaks or VC funding. These don't seem to work out very well, I think it's best explained here:
https://apenwarr.ca/log/20211229
"So it is with free software. You literally cannot pay for it. If you do, it becomes something else."
ZephyrBlu · 2024-06-05
This is a tech-focused selection from my personal list, with a few more business-y sources thrown in:
- https://erikbern.com
- https://lethain.com
- https://commoncog.com
- https://scattered-thoughts.net
- https://danluu.com
- https://ideolalia.com
- https://staysaasy.com
- https://collabfund.com
- https://blog.nelhage.com
- https://jacobian.org
- https://equalventures.substack.com
- https://defmacro.org
- https://spakhm.com
- https://apenwarr.ca
- https://scarletink.com
- https://benkuhn.net
- https://cpojer.net
- https://brandur.org
- https://zeptonaut.com
Let me know if you want some reading recommendations for any of these!
kqr · 2024-03-08
> Bugs approximately follow a heavy-tailed distribution
What's your data on this? In my experience, bug fixing time has been surprisingly thin-tailed. (High variation, yes, but not subexponential.)
My experience here is also mirrored by Avery Pennarun, who observes that "every bug is the same size": https://apenwarr.ca/log/20171213
a_c · 2023-06-16
This is illustrated in The Innovator's Dilemma and happens all the time. Established companies want to focus resources, increase profit margin, and improve operational efficiency. They improve their best product and sell to big customers. Not-so-successful product with not so wealthy clients got de-prioritized. They don't mind letting competitors take the market share. Why would they? It is lower margin business with low quality customers anyway. They may even sell the money losing product to competitor to milk out the last pennies.
The section "Q: Won't Big Company X just clone your product and steal all your customers?" in https://apenwarr.ca/log/20180724 also described this phenomenon
jrockway · 2023-05-08
Is Scrum supposed to increase velocity? I always view these processes as a consistency enhancer. "What can we accurately promise 6 months out" vs. "how can we get the most done possible?" This is important because the big risk is that you do 80% of 10 projects, rather than 100% of 1 project, especially if you have a team and not just a couple of individuals.
Lots of stuff pushes organizations in the direction of doing 80% of 10 separate projects, and it's a killer. This is good reading in this domain: https://apenwarr.ca/log/20171213
sshb · 2023-05-03
Great article on this topic: https://apenwarr.ca/log/20171213
NateEag · 2023-02-03
I tried a few of my favorites and the results were... predictable, I guess.
It kind of matches genre, but has no grasp of musicianship or why I might like a track.
And this is a fundamental problem. See Avery Pennarun's brilliant explanation of tracking users, data analysis, and recommendation systems to understand why:
https://apenwarr.ca/log/?m=201902
pr337h4m · 2022-12-03
If Puter/FriendOS can support legacy Windows enterprise apps not updated in over a decade and adds collaboration, SSO, 2FA, access controls, VPN/intranet, etc. - basically what FrontEgg (https://techcrunch.com/2022/07/28/with-40m-in-new-funding-frontegg-loo… offers - on top on them, it could be a pretty great business.
This is a great illustration of this type of business: https://apenwarr.ca/log/20120326. A lot of customers totally need, not just want, this type of thing.
Puter/FriendOS type systems can graft upon some modern features on top of all legacy apps, which is far far better than having to build it out for every single one. Especially as the market lies more in the long tail of the custom software tailed to specific companies, that has been chugging along for 15 years in maintenance mode.
cpach · 2022-02-04
If anyone wants to know more more about Deming, I can warmly recommend this blog post by Avery Pennarun: https://apenwarr.ca/log/20161226
Bluecobra · 2022-01-30
Funnily enough there’s another excellent article by apenwarr that touches on this a bit. Ethernet is designed to go as fast as possible/line rate and assumes that everything is the same speed. When you disabled pause frames, it likely prevented the switch from interfering and punting the issue to the TCP stack of the server/client.
https://apenwarr.ca/log/20170810
eaplmx · 2022-01-21
A problem with open and free projects (to oversimplify the ideological differences) is the source of time and purpose.
The production cost is subsidized as a Hobbie not as a profession, so it's hard to expect a 'consumer product'. When you put external money and corporate interest in your hobbies, something breaks.
Not saying open products don't have to exist, we all love them. They cover different creative needs, and usually are a gift for the community.
https://apenwarr.ca/log/20211229 - The Gift of It's your problem now
keithnz · 2021-12-31
actually, reading through his various different articles is quite interesting.
This one probably is the best
"The world in which IPv6 was a good design" https://apenwarr.ca/log/20170810
mindslight · 2021-12-07
Yeah I was going to touch upon that. I understand where they were coming from design wise (apenwarr's post is fantastic for that - https://apenwarr.ca/log/20170810). Privacy extensions mainly seems like doubling down on an unworkable idea. I can see the hypothetical benefit on a shared network, where say a coffee shop has a /64 and you can have every single app looking like a separate device on that network to an outside observer. I just foresee the inevitable future where IP surveillance databases contain information like "this /48 hands out /64 to each end user, so treat it as one entity", rendering those extra bits as a mere liability to be mitigated.
rapnie · 2021-12-03
Ha yes, reminds me of this quote from "100 years of whatever this will be" (recommended read) that trended on HN [1] yesterday:
> Software intercompatibility is trending toward zero. Text chat apps are literally the easiest thing in the world to imagine making compatible - they just send very short strings, very rarely, to very small networks of people! But I use at least 7 separate ones because every vendor wants their own stupid castle and won't share. Don't even get me started about books or video.
[0] https://apenwarr.ca/log/20211201
[1] https://news.ycombinator.com/item?id=29416606
shaicoleman · 2021-10-03
My favorite post on the subject is by apenwarr:
https://apenwarr.ca/log/20201227
Search for the "Chicken-egg problems" heading
advisedwang · 2021-09-16
bit per second is a pretty standard way to measure network traffic. Just be glad they aren't listing baud!
The networking community historically follows a tradition coming from telecoms, which is why there is a bit of a cultural split between networking folks and other computing folks (software and hardware folks have more cultural connection to each other than to networking!)
Apenwarr actually traces this cultural and historical split forward [1] even to the difference between lower levels of the stack defined by IEEE standards (e.g. 802.11) and higher levels of the stack defined by IETF (e.g. IP).
[1] https://apenwarr.ca/log/20170810
nikisweeting · 2021-06-28
Was about to post this as well.
I think these two articles are also a great launch point before diving into the whole stack:
- https://apenwarr.ca/log/20170810 The World in Which IPv6 was a good design (which is actually a mini CS history course on networking in disguise)
- https://tailscale.com/blog/how-nat-traversal-works/
MorganGallant · 2021-05-27
Surprised no one mentioned https://apenwarr.ca/log/ yet - such a great read!
aahortwwy · 2020-09-13
> People still complain about Netflix recommendations and they've spent tens of millions of dollars, possibly over a hundred million dollars, on it and are one of the most valuable companies on the planet with one of the best engineering teams on the planet.
This blog post talks about this exact subject: https://apenwarr.ca/log/20190201
> Why do people think algorithmic recommendations are easy? Or even desirable?
They're easier than you think, it's just most of them on major platforms are optimized to maximize your engagement with the platform, rather than your enjoyment of the content.
jwatzman · 2020-09-10
Along with the above fantastic comment, I found https://apenwarr.ca/log/20170810 an interesting (if inflammatory/divisive) essay on the subject and its history.
Ar-Curunir · 2020-02-27
The followup article (https://apenwarr.ca/log/20100721) talks about a potential C/C++ replacement, and seems like a lot of points match up with Rust
cpeterso · 2019-10-20
For more practical information on software estimation, I recommend apenwarr's "An epic treatise on scheduling, bug tracking, and triage" (2017):
https://apenwarr.ca/log/20171213
rocqua · 2019-09-27
P.s. this rant/idea was taken from this excellent blog post: https://apenwarr.ca/log/20170810
nambit · 2019-09-25
It's not as easy as "improving" existing protocols. Look at the ipv4 -> ipv6 mess. And even then ipv6 suffers from issues that are tied to how networks were built, etc. See this great article: https://apenwarr.ca/log/20170810
If I'm building something to give connectivity to dog tags, why not do something simpler?
tonyg · 2019-05-26
Relevant: https://apenwarr.ca/log/20101214. Code: https://github.com/apenwarr/redo. It's excellent!
twic · 2019-02-21
You may enjoy this:
The best way to not lose messages is to minimize the work done by your log receiver. So we did. It receives the uploaded log file chunk and appends it to a file, and that's it. The "file" is actually in a cloud storage system that's more-or-less like S3. When I explained this to someone, they asked why we didn't put it in a Bigtable-like thing or some other database, because isn't a filesystem kinda cheesy? No, it's not cheesy, it's simple. Simple things don't break.
https://apenwarr.ca/log/20190216