The most important and obvious difference between TTD and rr is that TTD is for Windows and rr is for Linux (though a few crazy people have had success debugging Windows applications in Wine under rr).
TTD supports recording of multiple threads in parallel, while rr is limited to a single core.
On the other hand, per-thread recording overhead seems to be much higher in TTD than in rr. It's hard to make a direct comparison, but a simple "start Firefox, display mozilla.org, shut down" test run on similar hardware takes about 250 seconds under TTD and 26 seconds under rr.
You should probably avoid TP-Link products if you’re on a tight bandwidth budget. By design, TP-Link firmware sends six DNS requests and one NTP query every 5 seconds, for a total of 715,4 MB per month.
如果拿 24 小時都開機的 Windows 相比的話，會發現這數字天差地別：
To put this number in context: an always-on Windows device will use around 1,6 KB per month on NTP.
作者抓出韌體上面的設定，發現裡面寫死了不少伺服器... 那個 au 與 nz 的選擇讓人頗好奇，另外直接把幾個大學的 NTP server 放進去不知道是什麼樣的想法：
TP-Link has hardcoded the following non-configurable NTP servers and server pools in their firmware:
The first sets of servers are operated by the US National Institute of Standards and Technology (NIST). The second is the Australian and New Zealand public NTP project time server pools. The IP addresses are owned by universities in Japan, Colorado; US, and Sweden respectively.
而從行為可以看到沒有遵守這些 NTP service 的規範：
The NTP Pool project asks device manufacturers and vendors to register (and optionally sponsor) their own pools through the service (e.g. tplink.pool.ntp.org), and emphasize that they “must absolutely not use the default pool.ntp.org zone names”. They also request that vendors don’t check more often than every 5 minutes at the most.
而且因為沒有地方可以修改這些設定，唯一的解法是不要買 TP-Link 的產品：
You can avoid buying TP-Link products to avoid this problem.
You can’t turn this behavior off in TP-Link’s web administration interface nor in their management app for mobile. You can’t change the NTP server addresses it targets either.
You can use the CloudWatch console to graph metric data generated by AWS services and your applications. Now, you can zoom into a shorter time period such as one minute or five minutes while viewing the metric graph at a longer interval.
Once zoomed, you can also pan the metric graph across your selected interval, but at a zoomed detail level.
You can access the service via the link local 169.254.169.123 IP address. This means you don’t need to configure external internet access and the service can be securely accessed from within your private subnets.
然後也有提到 leap second 的解法，用的解法是 leap smearing：
Leap seconds are known to cause application errors and this can be a concern for many savvy developers and systems administrators. The 169.254.169.123 clock smooths out leap seconds some period of time (commonly called leap smearing) which makes it easy for your applications to deal with leap seconds.
先前 AWS 也有 leap time，但不包括 Amazon EC2 這些系統 (EC2 裡的時間是獨立的)，不過還是可以看一下 AWS 處理 leap time 的方式，因為這次 NTP Service 就會拿去用了。
Which gets us to the point that it is no different than storing INT (hello 2038?) or UNSIGNED INT (a bit later) or BIGINT (till the end of time) and possibly passing binary values in efficient protocols eventually.
If you got that far of this post, your likes in Facebook graph are stored with 'INT UNSIGNED' time field.
順道一提，INT 是 2038 年問題，INT UNSIGNED 是 2106 年問題。
而 Facebook 在 MySQL 上會選擇不使用 DATETIME 與 TIMESTAMP 的原因其實跟技術搭不上太多關係，主因是因為 MySQL 根本沒打算修 XDDD
It is my favorite MySQL bug, simply because it forces any reasonable mind not to use TIMESTAMP, and MySQL is never going to fix it (nor will ever understand time). I lost my temper a bit on that bug: https://bugs.mysql.com/bug.php?id=38455
我的猜測是已經爛成一團了，而且大家都有 workaround (呃，其實就是 Facebook 推薦用 INT UNSIGNED 的方法)，再考慮到有一票現有程式，在上面狂用 side effect 讓執行結果正確，不如就不要修這種吃力不討好的東西了 XDDD
另外一方面 timezone 資訊其實常常變化，常常需要更新 MySQL 的 timezone database (而這對於維運來說不是什麼開心的事情)：
There're few ways around that. One of them is side-load and maintain timezone data inside MySQL itself - it has support for internal timezone database and tracks obscure time shifts like ones for "Pacific War Time" and "Pacific Peace Time". That is operationally feasible (you have to remind yourself to update the database whenever time rules change, and they do change a lot, if you consider every timezone in the world), but has limited value.
However, most browsers have implemented their own caching layer that can override the TTL specified by the server. In fact, some browsers cache for 5-10 minutes, which is an eternity when a region or data center fails and you need to route end users to a different location.
Previously, you could start and stop Amazon ECS tasks manually, but running tasks on a schedule required writing and integrating an external scheduler with the Amazon ECS API.
Now you can schedule tasks through the Amazon ECS console on fixed time intervals (e.g.: number of minutes, hours, or days). Additionally, you can now set Amazon ECS as a CloudWatch Events target, allowing you to launch tasks by using CloudWatch Events.