dennis-tra

Content-addressing decouples the hoster from the data itself. Anyone can serve content-addressed data and you can locally verify that you’ve got served the correct bytes. IPFS implements building blocks for such an alternative web.

What irony that this article is about crawling content-addressed data.

> There are no written documents, it’s only that a boat landed there hundreds of years ago

Talking about Kiel, the non existent document was signed there: https://en.wikipedia.org/wiki/Treaty_of_Kiel

Had the same issue that the blue dot won’t disappear. I was able to clear the dot with:

gh api notifications -X PUT -F last_read_at=2025-10-06T00:00:00Z

Just change the date to today. I also got that line from a gh issue somewhere - maybe it was the same issue that you’re referring to.

Can someone explain to me why the compiler can’t do struct-field-alignment? This feels like something that can easily be automated.

This is an excellent article!

The tribal knowledge seems to be that you shouldn't do TCP-based hole punching because it's harder than UDP. The author acknowledges this:

> You can do NAT traversal with TCP, but it adds another layer of complexity to an already quite complex problem, and may even require kernel customizations depending on how deep you want to go.

However, I only see marginally added complexity (given the already complex UDP flows). IMO this complexity doesn't justify discarding TCP hole punching altogether. In the article you could replace raw UDP packets to initiate a connection with TCP SYN packets plus support for "simultaneous open" [0].

This is especially true if networks block UDP traffic which is also acknowledged:

> For example, we’ve observed that the UC Berkeley guest Wi-Fi blocks all outbound UDP except for DNS traffic.

My point is that many articles gloss over TCP hole punching with the excuse of being harder than UDP while I would argue that it's almost equally feasible with marginal added complexity.

[0] https://ttcplinux.sourceforge.net/documents/one/tcpstate/tcp...

I had the exact same thought for years but never came around experimenting with it. I also hoped that one could eventually hear that something is off.

I think this can happen by either recognising the "rhythm" in which sounds appear and/or recognising different tones.

As a first step, my idea was to write a logger that plays different beep sounds for different log levels. That way you could mostly identify the “rhythm” because I guess most log messages would have the same severity. However, to a tiny degree also by the pitch of the sound.

Then as a second step I thought of mapping the log message to a scale of sounds by e.g., hashing the message. This obviously would only work if there’s no dynamic content in the message.

I’d like to add

  please = push —-force-with-lease

for rebase-heavy workflows