kfnic

William Osman on YouTube made a bike fully out of wood: https://www.youtube.com/watch?v=0yJdz-kjfLk

[haven't finished the video yet, not sure if this or something similar was mentioned]

Another annoyance about the sync is that it is only recent episodes that are synced. When you get a new device you lose the status of most of your episodes.

Most people in the US are stuck with only one choice of broadband Internet providers, and those who are lucky might have two options[1].

The difference between Comcast and Amazon/Costco is that when Amazon provides sub par customer service you have the option to shop elsewhere. The reason Comcast can be so well known for providing terrible support is because there is no alternative, your only other option is to choose a dial-up provider and sacrifice a consistent Internet connection.

1. https://arstechnica.com/information-technology/2016/08/us-br...

There is already a LOC Resource Record type defined by RFC 1876[1] that can be used to represent location data.

[1] https://tools.ietf.org/html/rfc1876

As an Alfred replacement check out Kupfer[1], it's got a number of plugins to interact with different applications I use. It's actually the reason I went searching for and found Alfred to replace the functionality on my Mac.

I haven't used iTerm on OS X, but Terminator[2] might be worth checking out as a Linux replacement.

1. http://engla.github.io/kupfer/

2. http://gnometerminator.blogspot.com/

What kind of TTL value would they use for these records? Should something happen to one of the collectors, couldn't that value still be cached by an endpoint or an intermediary?

Even with a short TTL, are there still servers out there that don't respect all TTLs, or has that been eliminated by now?

Shouldn't the TCP handshake look like this:

---- SYN ---->

<-- SYN/ACK --

---- ACK ---->

rather than having the client send two SYNs to the server?