Podcasting 2.0 - Episode 269: Verbal Pollution

Shownotes

-------------------------------------------------------------------------------------------------------------------------------------

00 - DATABASE SURGERY WEEK — AND THE THIRD EMERGENCY OF THE MONTH

The lead, and it's Dave's: Saturday 22 Aug — "#api I'm in the middle of a big refactor with the Podcast Index database schema. If I do my job right, nobody will notice it. But, the side effect will be an overall huge increase in the consistency of the data (duplicates, url change lag, etc)."

@dave — the big schema refactor (22 Aug)

Wednesday night: "Podcast Index database surgery will begin in the morning." Thursday: "Step 1. Expect a brief api outage. It should last just a few minutes." — then "Done" — then "#api Adding a very large table index..." — and finally, Thursday evening: "Finished. Butt is intact." (6 favourites. The board's favourite status update of the month.)

What Adam should ask: what actually changed under the hood, what does "consistency" buy an app developer in practice, and is there anything a host or an app should do differently now that duplicates and url-change lag are being cleaned up?

The other half of the week — the third emergency. Tuesday 25 Aug: "#api Linode emergency maintenance on our db host. API is down." Then: "No update as of yet. Just hard down." Then the line that is really the story: "This is the third 'emergency maintenance' event that has affected us this month. Getting kind of old." And, dryly: "I guess a reboot every few years isn't too much to ask."

@dave — Linode emergency maintenance, API is down (25 Aug)

Board question: three unplanned outages in one month on the host that carries the Index. Is it time to talk publicly about where the database lives, and what the fallback is? The Index is infrastructure now — other people's products go down when it does.

Podping shipped twice. v0.13.0 across gossip writer, watcher and monitor — "a dynamic memory cap to address the Iroh bug" (that is last week's memory leak, now capped). Then v0.14.0 the same day — "cpu architecture in the mesh announcement messages to make determining what hardware a node is running on easier." Monitor updated too: ppmonitor.podcastindex.org.

@dave — podping v0.13.0, dynamic memory cap for the Iroh bug

Podping monitor