Re-usable pools of hashtables don't get enough love. Part of the issue is that most general purpose implementations can't be cheaply reset; it's cheaper to create a new one. But in some cases, a more specialized version can be used which has a relatively cheap reset cost.

Wrote a long series, Learning Zig. It isn't "The Little Zig Book". I don't think Zig fits in "The Little" container.

I thought it'd take ~4 days. Took a couple weeks. Trying to write a coherent series is a challenge. But I have delusions that the pointer/memory talk will resonate with people.

Been working on an SMTP client for Zig. It's been more painful than I thought.

RFC 5321 feels like the most poorly written RFC I've read. Hard to pinpoint exactly why. I would strongly recommend that implementers look at the original, RFC 821, first. It's leaner and more straightforward.

Also, the state of TLS in Zig is pretty rough right now. And what's up with Amazon's SES crap support for TLS 1.3?

Much better hardware, but overall, I regret moving back to a Macbook. Linux developer experience and, for me, general usability is unparalleled. I'm keeping an eye on Asahi's Feature Support, still a few deal breakers for my CPU.

I honestly think a lot of people don't understand what an SLA is. An SLA is not a guarantee of availability. An SLA is a guarantee of financial compensation. That's it. A provider can have an SLA of 99% and be down for 1 hour every day of the month. Great, you'll get reimbursed, but your users will abandon you.

The only SLA that may be meaningful is a reimbursement of well over 100%. Now the provider has a real financial incentive.

Started going through Crafting Interpreters (available for free online). So far, very impressed and into it.

Downfall is brutal. You cannot use shared tenancy hardware (e.g. virtually any cloud hosting) if you're serious about privacy and security.

Always disappointed that there isn't something like the Autobahn Websocket Test Suite for other protocols. Like, given how many DBs are using the PostgreSQL protocol these days, I'd think a client/server testsuite would be useful.

I found a few paid options for HTTP, but they're all "contact sales" type stuff.

If you set synchronous_commit = off in postgresql.conf, you open yourself up to a small window of data loss (but not data corruption) and gain faster writes. It can even be set on a per-transaction basis. Unless you really can't afford data loss, I'd set it to off even in production.

Setting fsync = false can result in data loss AND data corruption. It should absolute not be set to false in production, but in development? Unless a corruption is a big concern, I always disable fsync.

The official Firefox Multi-Account containers is a huge reason to prefer Firefox. It's a really shitty UX, especially since it should be one of their key features. But being able to have youtube.com run in its own "container" logged into Google, while having all other tabs not logged into Google is pretty big privacy win.

Feels like EPYC has changed the game a little. Last year I got 2 cores, 4GB RAM and 60GB SSD for ~100USD/year.

This year it was 4 cores, 8GB and 60SSD for ~$70USD/year. Feels like it's largely driven by high EPYC core count.

Prices in Asia are pretty bad, you could do better in Europe. This is for my own blog and a few small things. 2 cores was plenty, but why not double it for less money?

I never really understood Herbert's description of Dune as "beware of heroes." Yes, Muad'Dib's jihad caused the death of billions and sterilisation of planets, but the alternative seemed to be outright [eventual] extinction. Herbert created a universe in which humanity was doomed, created actual gods (Paul and Leto), and then criticised people (e.g. us) for following them.