curl 的 command line 工具也要支援 JSON 格式了

Daniel Stenberg 在 curl 的 mailing list 上宣佈要支援 JSON 格式：「JSON support」，用法在「JSON awareness in the curl tool」在這邊可以看到，另外在 Hacker News 上的討論「The time might come when we add some JSON specific command line options (curl.se)」也可以翻翻。

討論裡面馬上有提到 HTTPie，這個套件基本上也算是標配了 (而且在各大 distribution 的 package 都有內建，直接裝就可以了)，可以看到主要是處理 POST 輸入時的 JSON 部份 (在 Content-Type: application/json 的情境下)，HTTP response 輸出的部份一般都還是用 jq 處理。

不過 curl 自己又定義了一套指定 JSON 內容的方式...

Mac 上的小麥輸入法大改版 (2.0，不過目前已經又出 2.0.1 了)

在 Twitter 上看到 zonble 的推文：

整串可以看「Thread by @zonble on Thread Reader App」這邊，在 GitHub 上面的 release note 也可以參考：「Release 2.0 · openvanilla/McBopomofo」，不過要注意如果要下載的話，記得抓 bugfix 後的版本：「Release 2.0.1 · openvanilla/McBopomofo」。

對我來說最大的進步就是詞庫這塊了，可以直接加進去學習方便不少...

Igor Sysoev (nginx 的作者) 離開 F5

在 Hacker News Daily 上看到的消息，nginx 的發明人 Igor Sysoev 離開 F5：「Do Svidaniya, Igor, and Thank You for NGINX」。

官方的理由是家庭與朋友，另外有其他的個人計畫：

With profound appreciation and gratitude, we announce today that Igor Sysoev – author of NGINX and co‑founder of NGINX, Inc. – has chosen to step back from NGINX and F5 in order to spend more time with his friends and family and to pursue personal projects.

在 Hacker News 上的討論「Do svidaniya, Igor, and thank you for Nginx (nginx.com)」也可以翻一下，不過看起來都是在歌功頌德...

2019 年三月 NGINX, Inc. 賣給了 F5，到現在快三年了。以官方的文章看起來應該是和平分手，翻了 Twitter 帳號發現也很久都沒更新了，比較好奇的是後續的計畫會是什麼...

QTE 小遊戲 Looptap

在 Hacker News 首頁上看到這個小遊戲：「Show HN: Looptap – A minimal game to waste your time (vasanthv.com)」，如同他的標題寫的，浪費時間的小遊戲 XDDD

標題講的 QTE 是「快速反應事件」這個東西，在現在的遊戲裡面算是蠻常見的機制，是一種需要在事件有效區間反應的設計 (太早反應或是太晚反應都不行)。

SSH 的 StrictHostKeyChecking=accept-new

OpenSSH 在連到新的 host 時會跳出 key fingerprint 的資訊讓使用者確認，有時候為了自動化會用 StrictHostKeyChecking=no 避開，在 Lobsters Daily 上則看到了新的選項可以用，StrictHostKeyChecking=accept-new：

就如同選項的名字所描述的，查了一下 OpenSSH Release Notes 可以看到這是在 OpenSSH 7.5 導入的參數，是在 March 20, 2017 引入的：

* ssh(1): expand the StrictHostKeyChecking option with two new settings. The first "accept-new" will automatically accept hitherto-unseen keys but will refuse connections for changed or invalid hostkeys. This is a safer subset of the current behaviour of StrictHostKeyChecking=no. The second setting "off", is a synonym for the current behaviour of StrictHostKeyChecking=no: accept new host keys, and continue connection for hosts with incorrect hostkeys. A future release will change the meaning of StrictHostKeyChecking=no to the behaviour of "accept-new". bz#2400

對於一些自動化的流程應該夠用了，不需要到用 no 完全關掉。

翻了「Ubuntu – Package Search Results -- openssh-client」可以看到 18.04 之後都是 7.5 之後的版本了，支援度應該是沒什麼太大問題...

搜尋影片的串流平台

在 Hacker News Daily 上看到「Show HN: API to query catalogs of 20 streaming services across 60 countries (movieofthenight.com)」這個，但這個服務反而不是重點，有許多人發現裡面錯誤率頗高，而且也沒有台灣的資料，反倒是裡面有人提到 JustWatch 這個服務看起來比較好用...

像是「Friends」(這邊用的是中國的翻譯片名) 可以看到在台灣是在 Netflix 上，美國的話則是在 HBO Max (串流) 與 Apple TV (購買) 上可以看到。不過查 MythBusters 在兩個平台上都沒看到資料...

但整體上來說 JustWatch 搜出來的品質還是好不少...

Uber 對 Golang GC 的調整

Hacker News 上看到「How We Saved 70K Cores Across 30 Mission-Critical Services (Large-Scale, Semi-Automated Go GC Tuning @Uber)」這篇，講 Uber 的人怎麼調整 Golang 的 GC，在 Hacker News 上的討論「Large-scale, semi-automated Go GC tuning (uber.com)」也有些東西再講。

一開始的方法是動態一直調整 GOGC 的值：

Our initial approach was to have a ticker to run every second to monitor the heap metrics, and then adjust GOGC value accordingly.

但這個方法的 overhead 太重：

The disadvantage of this approach is that the overhead starts to become considerable, because in order to read heap metrics Go needs to do a STW (ReadMemStats) and it is somewhat inaccurate, because we can have more than one garbage collection per second.

後來的方法是利用 SetFinalizer 來做 (然後這段 code 不知道為什麼是用圖片...)：

Luckily we were able to find a good alternative. Go has finalizers (SetFinalizer), which are functions that run when the object is going to be garbage collected. They are mainly useful for cleaning memory in C code or some other resources. We were able to employ a self-referencing finalizer that resets itself on every GC invocation. This allows us to reduce any CPU overhead.

不過 Hacker News 上有些人也很驚訝於 30 個 service 用掉 70K cores 這件事情，以 Uber 的服務來說算是比預想多不少數字，而且這只是跑 Golang，而且這次省下來的部份...

另外在 Hacker News 上也有人提到 Golang 有在思考 soft memory limit 的設計，也值得看一看：「runtime/debug: soft memory limit #48409」、「Proposal: Soft memory limit」。

qBittorrent 支援 BitTorrent v2

在「Thursday January 06th 2022 - qBittorrent v4.4.0 release」這邊可以看到 qBittorrent v4.4.0 支援 BitTorrent v2 (BEP 52) 了：

FEATURE: Support for v2 torrents along with libtorrent 2.0.x support (glassez, Chocobo1)

先前在「libtorrent 宣佈支援 BitTorrent v2」這邊有提到過 libtorrent 要支援 BitTorrent v2 的消息，而 qBittorrent 算是 libtorrent 的使用大戶，支援 BitTorrent v2 後會讓 BitTorrent v2 的使用率增加不少。

用了一年多才出現一個比較大的 client 跳進去支援，看起來大家的動力的確不高...

用 Akamai 提供的 akahelp 分析 DNS Resolver 的資訊

整理資料的時候看到以前就看到的資訊，Akamai 有提供工具，可以看 DNS resolver 的資訊：「Introducing a New whoami Tool for DNS Resolver Information」。

這拿來分析 168.95.1.1 或是 8.8.8.8 這些服務還蠻好用的，這些對外雖然有一個 IP address 在服務，但後面是一整個 cluster，所以可以利用 Akamai 的這個工具來看分析。

像是 8.8.8.8 會給接近的 EDNS Client Subnet (ECS) 資訊 (ip 的部份看起來是隨便給一個)：

$ dig whoami.ds.akahelp.net txt @8.8.8.8

[...]

;; ANSWER SECTION:
whoami.ds.akahelp.net.  20      IN      TXT     "ns" "172.217.43.194"
whoami.ds.akahelp.net.  20      IN      TXT     "ecs" "111.250.35.0/24/24"
whoami.ds.akahelp.net.  20      IN      TXT     "ip" "111.250.35.149"

而 1.1.1.1 會給假的 ECS 資訊：

$ dig whoami.ds.akahelp.net txt @1.1.1.1

[...]

;; ANSWER SECTION:
whoami.ds.akahelp.net.  20      IN      TXT     "ns" "2400:cb00:80:1024::a29e:f134"
whoami.ds.akahelp.net.  20      IN      TXT     "ip" "2400:cb00:80:1024::a29e:f134"
whoami.ds.akahelp.net.  20      IN      TXT     "ecs" "111.250.0.0/24/24"

然後 168.95.1.1 則是連 ECS 都不給 XDDD

$ dig whoami.ds.akahelp.net txt @168.95.1.1

[...]

;; ANSWER SECTION:
whoami.ds.akahelp.net.  20      IN      TXT     "ns" "2001:b000:180:8002:0:2:9:114"

之前在找 DNS 類問題的時候還算可以用的工具...

把 Blog 丟到 CloudFront 上

先前在「AWS 流量相關的 Free Tier 增加不少...」這邊有提到一般性的流量從 1GB/month per region 升到 100GB/month，另外 CloudFront 則是大幅增加，從 50GB/month (只有註冊完的前 12 個月) 提升到 1TB/month (不限制 12 個月)，另外 CloudFront 到 EC2 中間的流量是不計費的。

剛剛花了點功夫把 blog 從 Cloudflare 搬到 CloudFront 上，另外先對預設的 /* 調整成 no cache，然後針對 /wp-content/* 另外加上 cache 處理，跑一陣子看看有沒有問題再說...

目前比較明顯的改善就是 latency，從 HiNet 連到免費版的 Cloudflare 會導去美國，用 CloudFront 的話就會是台灣了：

另外一方面，這樣國際頻寬的部份就會走進 AWS 的骨幹，比起透過 HiNet 自己連到美國的 PoP 上，理論上應該是會快一些...