用繪本 (?!!!) 解釋 Apache Kafka

Hacker News 上看到「I wrote a children's book / illustrated guide to Apache Kafka (gentlydownthe.stream)」這篇,用繪本的方式解釋 Apache Kafka 的運作方式:「Gently Down the Stream」,非常值得一看。

以 Hacker News 上 upvote 的數量來看,應該也會上明天的 Hacker News Daily

這繪本還帶有一些動畫效果,而且把需要提到的東西都有帶出來 (像是 Kafka Connector 都有提到),不過雖然作者目標群是小朋友,看起來大人還比較興奮?

又再次看到了 Spectre Mitigation 的效能損失...

Hacker News 首頁上看到的文章,講 Spectre Mitigation 的效能損失:「Spectre Mitigations Murder *Userspace* Performance In The Presence Of Frequent Syscalls」,對應的討論串在「Spectre Mitigations Murder Userspace Performance (ocallahan.org)」。

看起來作者是在調校 rr 時遇到的問題,幾年前有提到過 rr:「Microsoft 的 TTD 與 Mozilla 的 RR」。

對此作者對 rr 上了一個 patch,減少了 mitigation code 會在 syscall 時清掉 cache 與 TLB,這個 patch 讓執行的速度大幅提昇:「Cache access() calls to avoid syscalls」。

另外作者提到了他的硬體是 IntelSkylake,他又再跑一次 pre-patch 與 post-patch 的速度,可以看到在 pre-patch 前,mitigation 會讓系統慢超多 (從 2m5.776s 到 3m19.648s),而 post-patch 後大幅降低 syscall 的使用,就不會影響那麼多 (從 0m33.422s 到 0m36.160s)。

就目前知道的 mitigation 方式來說,這個猜測應該是對的...

Libera.Chat 使用人數超越 freenode

前幾天在「freenode 又在提醒大家搬到 Libera.Chat 了...」這邊猜測這個月月底大概會有交叉,結果發現這幾天 freenode 選擇自爆,直接把上面的註冊使用者與頻道都清空:

這個自爆行為直接讓 Libera.Chat 大幅成長,超越了目前的 freenode:

出自「IRC Networks - Top 10 in the annual comparison

netsplit.de 上的資料看起來是某個比較長時間的平均值,會需要再拉長一些時間才會反應出來。

Google Meet 可以走 443/tcp 了

Work from home 期間開會基本上就是幾個視訊軟體換來換去,Zoom 的話公司有買,自己開免費版的時候是 40mins 限制,另外 Slack 的畫面品質不怎麼樣,而 Google Meet 在疫情期間不限制時間,拿來聊天還蠻好用的。

看到「TLS support for Google Meet」這篇,文章裡面提到先前 Google Meet 是用 443/udp 跑 SRTP,這對很多公司的 firewall 需要另外開 (看到這個 UDP port 想到 QUIC 好像也是走這個 UDP port),在家裡的話應該還好,對於公司的電腦就會麻煩一些。

文章裡提到,這次支援了 TLS (over 443/tcp):

Some network setups do not work with SRTP over 443 which was preventing Meet calls from connecting. Meet now encapsulates SRTP in TLS which increases overall compatibility. This change will initially be available on the web, and will be available for mobile soon. We’ll announce it on the Google Workspace Updates blog when it’s available.

可以 fallback 回 443/tcp 走 TLS 的話穿透力應該就更好了,不過不知道免費版的有沒有也一起上,這邊只題到了 G Suite 系列會上:

Available to all Google Workspace customers, as well as G Suite Basic and Business customers

上次用 Google Meet 是在雲端聚餐聊天...

AWS KMS 推出 Multi-region keys

這應該是 AWS 被許多大客戶敲碗許久的功能之一,AWS KMS 支援 global key:「Encrypt global data client-side with AWS KMS multi-Region keys」。

以前不支援這個功能時,在加密儲存跨區域的資料會有兩種作法,以 us-east-1ap-northeast-1 為例子來說:

第一種是透過 replication 的概念,檔案內容從 us-east-1 解開後,透過 TLS 傳到 ap-northeast-1 再加密,所以不同區的密文內容是不同的。

第二種是自己抽象一層 AES key,檔案內容都用這把 AES key 加解密,而這把 AES key 則透過不同區的 AWS KMS 保護,但這樣做又要自己搞 key rotation,另外還可能會有 auditing 的問題...

現在 AWS KMS 直接支援就省事很多了:

文章裡面是拿 DynamoDB 當範例,不過其他只要能夠用 AWS KMS 應用應該也能用。

cURL 與 Travis CI 的事件

前幾天 Daniel Stenberg (cURL 的發明人與現在的維護者) 發表一篇從 Travis CI 搬出來的文章,換到 Zuul CICircle CI 上:「Bye bye Travis CI」,對應的 Hacker News 的討論可以在「Bye Bye Travis CI (haxx.se)」這邊翻到。

文章裡提到主要的兩個點是,Travis CI 當初有承諾會提供免費服務給 open source project:

今年的時候整個 Travis CI 的商業收費的機制改了,另外也嚴格增加了對 open source project 的限制,包括了你不能收到任何商業公司或是任何組織的贊助:

Project must not be sponsored by a commercial company or organization (monetary or with employees paid to work on the project)

另外 Daniel Stenberg 在文章裡也表明目前不打算付錢,要找市場上便宜可用的方案 (而目前看起來還有,至少 Zuul CI 與 Circle CI 都在選項內),所以就從 Travis CI 搬離了:

Lots of people have commented and think I’m “whining” about Travis CI charging for something that is useful and that I should rather just pay up. I could probably have gone with that but I dislike their broken promise and that they don’t consider us Open source anymore and I feel I have a responsibility to use the funds we get from gracious donors as wisely and economically as possible, and that includes using no-cost or cheap services rather than services charging thousands of dollars per year.

If there really were no other available and viable options, then paying could’ve been an alternative. Now, moving on to something else was the right choice for us.

然後 Travis CI 過了兩天丟出「Open Source Terms at Travis CI – An Update and Clarification」,雖然沒有表明是在講 cURL,但放在一起看其實也都大概知道發生什麼事情。

看了一下自己的小專案 (更新頻率不高,test case 也不多),丟 Circle CI 還算是夠用,另外自己也有弄個 GitLab,需要的時候也可以在上面跑 CI。

這邊另外看到 cURL 這種大型專案,因為 test case 數量很多,丟到不同的 CI vendor 上跑,看起來是個還不錯的架構...

用圖片表示 SHA-256 的值

Hacker News 上看到的用法,把 SHA-256 的值表示成 avatar:「Representing SHA-256 Hashes As Avatars」,Hacker News 上的討論在「Representing SHA-256 Hashes as Avatars (francoisbest.com)」這邊可以看到。

做出來大概是這樣,這邊的 e3b0c44298fc1c149afbf4c8996fb92427ae41e4649b934ca495991b7852b855 是空字串的 SHA-256 值:

裡面有提到一些演算法,讓圖片看起來不要那麼「奇怪」,還蠻有趣的...

在文章最後面還有一些其他的圖片類型,如果要自己搞 avatar service 的人可以參考演算法的部份,自己搞一套出來玩。

freenode 又在提醒大家搬到 Libera.Chat 了...

看到「Last remaining >1000 user community channel seized by freenode staff」這篇,freenode 把 ##linux 頻道給綁走了:

Late in the evening of June 12, 2021, freenode staff seized the largest community channel left on freenode.

新家在 Libera.Chat 上面:

Similar hostile takeovers happened to the Python community, GNU and the FSF. More than 700 FLOSS projects have abandoned freenode and now the Linux.Chat community has left as well; find our new home at #linux on Libera and our multi-platform community website here.

翻了一下「IRC Networks - Top 10 in the annual comparison」這邊的資料,看起來這個月月底有機會交叉?

另外文章裡有提到 OFTC (The Open and Free Technology Community),看起來也是個對 open source community 開放的資源...

SSH 對傳入參數的 quoting

昨天在 Hacker News 首頁上看到「SSH quoting」這個,看得出來作者被 OpenSSH 玩弄到不要不要的樣子...

先簡單的整理一下:

$ ssh example.com 'cd /tmp; pwd'
/tmp
$ ssh example.com 'bash -l -c "cd /tmp; pwd"'
/tmp
$ ssh example.com bash -l -c "cd /tmp; pwd"  
/home/gslin

第三個指令發生的「預期外的行為」,但寫習慣的人會把指令全部包成一個字串,就很自然的避開這個問題了。當然 OpenSSH 的設計 (讓你不用加 quote 也會動) 的確也是容易中獎的點啦...

PostgreSQL 的 Job Queue、Application Lock 以及 Pub/Sub

Hacker News Daily 上看到一篇講 PostgreSQL 做 Job Queue、Application Lock 以及 Pub/Sub 的方法:「Do You Really Need Redis? How to Get Away with Just PostgreSQL」,對應的討論在「Do you really need Redis? How to get away with just PostgreSQL (atomicobject.com)」這邊可以翻到。

拿 PostgreSQL 跑這些東西的確有點浪費,不過如果是自己的專案,不想要把 infrastructure 搞的太複雜的話,倒是還不錯。

首先是 Job Queue 的部份,從他的範例看起來他是在做 async job queue (不用等回傳值的),這讓我想到很久前寫的 queue service (應該是 2007 年與 2012 年都寫過一次),不過我是用 MySQL 當作後端,要想辦法降低 InnoDB 的 lock 特性。

async job queue 設計起來其實很多奇怪的眉角,主要就是在怎麼處理失敗的狀態。大多數的需求可以放到兩個種類,最常見用的是 at-least-once,保證最少跑一次,大多數從設計上有設計成 idempotence 的都可以往這類丟,像是報表類的 (重複再跑一次昨天的報表是 OK 的),另外每天更新會員狀態也可以放在這邊。

另外少見一點的是 at-most-once 與 exactly-once,最多只跑一次與只跑一次,通常用在不是 idempotence 的操作上,像是扣款之類的,這邊的機制通常都會跟商業邏輯有關,反正不太好處理...

第二個是 Application Lock,跨機器時的 lock 機制,量沒有很大時拿 PostgreSQL 跑還行,再大就要另外想辦法了,馬上想到的是 ZooKeeper,但近年設計的系統應該更偏向用 etcdConsul 了...

最後提到的 Pub/Sub,一樣是在量大的時候拿 PostgreSQL 跑還行,更大的時候就要拿 Kafka 這種專門為了效能而設計出來的軟體出來用...