Cloudflare Workers 支援 Python (是 open beta)

Cloudflare 宣佈 Cloudflare Workers 支援 Python:「Bringing Python to Workers using Pyodide and WebAssembly」。

不過比較特別的是,並不是原生支援 Python 環境,而是透過轉譯成 WebAssembly 丟進 V8 engine 執行,就如同文章標題提到的。

另外是套件的部分,照這個文字的說明,應該不是所有的套件都可以丟進去用 (can import a subnet of popular Python packages),支援的套件看起來是預先 compile 好:

All bindings, including bindings to Vectorize, Workers AI, R2, Durable Objects, and more are supported on day one. Python Workers can import a subset of popular Python packages including FastAPI, Langchain, Numpy and more. There are no extra build steps or external toolchains.

看起來是打算全部都用 javascript 當作基礎?

UI Event 的順序

othree 寫了一篇「UI Event Order」在講滑鼠 (或是更廣廣義的 pointer 類) 以及鍵盤 (包括輸入法) 在瀏覽器上會產生的 event。

裡面有些是歷史 (提到 IE 上的實作方式),現在都不太會碰到了,可以直接看目前的幾份標準就好,然後蠻多標準都還是在 draft 階段,各家瀏覽器更新的速度不一樣,所以會有不同的行為冒出來。

我決定先把文章保留起來,等遇到的時候再回來看 XD

Redis 的眾多 fork

從「Redis 改變授權,變成非開源軟體」差不多過去一個禮拜了,瞬間冒出一卡車 Redis fork:「The race to replace Redis」。

文章裡提到的第一個是 Valkey,在 Redis 宣佈改變授權後幾天 fork 出來的。

第二個則是 KeyDB,是很久前就 fork 出來實作 multi-threading 的公司,後來公司被 Snap 買走後 open source,但因為 fork 的很早,後續 Redis 增加的功能就沒有跟上了...

第三個則是 Redict,這是 SourceHut 這邊的 fork 版本。

第四個不算是 fork,是微軟前幾天公開的 Garnet,用 C# 寫的,也因為不是 fork,相容性當然比不上前面幾個。

另外一個文章帶出來的重要資訊,是目前 Redis 的 contributor 分佈,可以看到其實 Redis 本家不算多,這樣 Redis 決定硬幹 BSL + SSPL 的決定就頗值得玩味了:

可以看看 Redis 接下來會不會有什麼重量級的功能要推出?

Proxmox 的 VMware 轉移方案

Hacker News 上看到「Proxmox VE: Import Wizard for Migrating VMware ESXi VMs (proxmox.com)」這篇,原文在「New Import Wizard Available for Migrating VMware ESXi Based Virtual Machines」這邊。

算是有比較簡單的方式 (在這邊是提供 wizard) 可以把現有跑在 VMware 上面的 VM 轉出來,就不用自己在 command line 下 export (dump) & convert & import (restore),光是把 storage 轉過去就弄半天,這對於不熟悉 CLI & script 的人方便不少。

話說二月時傳出 Broadcom 打算把買來的 VMware 的 C 端產品拆開來賣:「VMware's end-user compute unit reportedly headed to private equity firm KKR」,後續好像沒有看到新消息?不過 C 端目前的領頭者應該還是 VirtualBox?這樣看起來賣掉也不算太意外就是了...

當年 Facebook 透過 VPN 記錄使用者活動細節的目的

2019 年年初的時候 TechCrunch 爆出 Facebook 透過付錢給使用者,透過 VPN (以及安裝 Root CA) 記錄使用者的行為:「Facebook 花錢向使用者購買他們的行為記錄」,最近揭露的文件透漏了當年的目的:「Facebook snooped on users’ Snapchat traffic in secret project, documents reveal」。

TC 這邊的文章裡面沒看到信件,另外找了其他報導:「Project Ghostbusters: Facebook Accused of Using Your Phone to Wiretap Snapchat」,裡面有兩份資料是信件往來的部分:「Document 735」、「Document 736」。

裡面可以看到想要取得 SnapchatYouTubeAmazon 這些使用行為:

The goal of Facebook’s SSL bump technology was the company’s acquisition, decryption, transfer, and use in competitive decisionmaking of private, encrypted in-app analytics from the Snapchat, YouTube, and Amazon apps, which were supposed to be transmitted over a secure connection between those respective apps and secure servers (sc-analytics.appspot.com for Snapchat, s.youtube.com and youtubei.googleapis.com for YouTube, and *.amazon.com for Amazon). Id.

然後信裡還有提到是用 Squid 實作的:

Today we are using the Onavo vpn-proxy stack to deploy squid with ssl bump the stack runs in edge on our own hosts (onavopp and onavolb) with a really old version of squid (3.1).

這次的訴訟裡提到了 18 U.S. Code § 2511 - Interception and disclosure of wire, oral, or electronic communications prohibited,看起來會是聯邦層級的刑事案件...

那是個還不流行 certificate pinning 的年代...?

Brendan Gregg 推薦平常在 Linux 上先裝好的工具

Brendan Gregg 推薦了一整包內建的工具 (透過系統的 apt repository 就能裝),平常先準備好,出問題的時候可以直接拿出來用:「Linux Crisis Tools」。

作者有提到表上列出來的工具算是基本盤,有特殊硬體的情況 (像是 GPU) 需要再加裝其他的套件:

This list is a minimum. Some servers have accelerators and you'll want their analysis tools installed as well: e.g., on Intel GPU servers, the intel-gpu-tools package; on NVIDIA, nvidia-smi. Debugging tools, like gdb(1), can also be pre-installed for immediate use in a crisis.

這邊是把表格有提到的都放進去,另外包括了上面提到的 GDB

sudo apt install -y bpfcc-tools bpftrace cpuid ethtool gdb iproute2 linux-tools-common msr-tools nicstat numactl procps sysstat tcpdump tiptop trace-cmd util-linux; sudo apt clean

裝了以後可以順便拿這張表格練練手,把不熟悉的工具開 backlog 找機會練手,熟悉一下這些工具的常用用法,這樣遇到狀況的時候可以直接用...

Redis 改變授權,變成非開源軟體

Redis 宣佈拿掉開源授權:「Redis Adopts Dual Source-Available Licensing」,對應的 git commit 在「Change license from BSD-3 to dual RSALv2+SSPLv1 (#13157)」這邊可以看到。

Starting with Redis 7.4, Redis will be dual-licensed under the Redis Source Available License (RSALv2) and Server Side Public License (SSPLv1).

算是今天蠻熱的新聞之一,不過算是在預期之內的變化,因為 Redis 在 2018 年就把很多他們自己開發的 proprietary component 變成 SSPL,現在主體也變其實不算太意外,後續就是看社群的 fork 凝聚的力量會比較大,還是 Redis 公司方的力量比較大... 尤其在 Redis 已經實作了許多 data structure 後,Redis 公司想要套現這件事情是否還有機會?

不過比較特別的反倒是微軟... 微軟早了一兩天發佈了 Redis 相容的實作 Garnet

Garnet is a remote cache-store from Microsoft Research that offers strong performance (throughput and latency), scalability, storage, recovery, cluster sharding, key migration, and replication features. Garnet can work with existing Redis clients.

會是巧合嗎?這時間點其實真的很微妙...

Redis 對 HyperLogLog 省空間的實作

HyperLogLog (HLL) 是用統計方式解決 Count-distinct problem 的資料結構以及演算法,不要求完全正確,而是大概的數量。

演算法其實沒有很難懂,在 2007 年的原始論文「HyperLogLog: the analysis of a near-optimal cardinality estimation algorithm」裡面可以讀到演算法是長這樣:

可以看到一開始要決定好 b 的值 (於是就會有 2b 個 register),以及單個 register M[j] 的大小,所以是一開始就會決定好固定大小,無論有多少元素都會先吃掉這麼多空間。

但在 Redis 的文件「HyperLogLog」裡面則是提到很少元素的時候會低於 12KB:

The magic of this algorithm is that you no longer need to use an amount of memory proportional to the number of items counted, and instead can use a constant amount of memory; 12k bytes in the worst case, or a lot less if your HyperLogLog (We'll just call them HLL from now) has seen very few elements.

網路上搜了一下沒看到怎麼做到的,不過直接翻 Redis 的程式碼 hyperloglog.c 可以看到答案。

在檔案開頭的註解可以看到有 16384 個 register (對應到論文裡面的 b = 14,因為 214 = 16384),單個 register 的大小則是 6 bit (對應到論文裡面的 M[j]),相乘後是 12K bytes,剛好符合文件上的說明:

The use of 16384 6-bit registers for a great level of accuracy, using a total of 12k per key.

在「Dense representation」這邊也說明了每個 register 都是 6 bit 的存放方式,到這邊都與 HLL 論文提到的實作一樣。

省空間的方式是在「Sparse representation」這邊做到的,在大多數的 register 都沒有被設定的情況下,用這種方式可以省下大量的空間,而缺點是當元素「有點多」的時候會有比較高的 CPU time:

In the example the sparse representation used just 7 bytes instead of 12k in order to represent the HLL registers. In general for low cardinality there is a big win in terms of space efficiency, traded with CPU time since the sparse representation is slower to access.

依照註解上面的數字,看起來在 10000 個元素以下有機會低於 12KB,然後夠大的時候從 sparse 轉到 dense 上。

本來以為是什麼其他論文可以調整 b 參數 (enlarge),結果是個比較像是 hack 的方式搞定,但的確是蠻有效的...

拔掉 Android 上面無意義的軟體:Universal Android Debloater GUI

HN 上看到「Debloat non-rooted Android devices (github.com/universal-debloater-alliance)」這個討論,原網頁是 GitHub 專案 Universal Android Debloater GUI 這個。

說明的地方還蠻清楚的,透過 ADB 在不需要 root 的情況下試著把垃圾軟體清掉:

Cross-platform GUI written in Rust using ADB to debloat non-rooted android devices. Improve your privacy, the security and battery life of your device.

專案看起來跑一段時間了,從 releases 頁這邊可以直接下載 binary 執行。

FAQ 頁裡面的「What are the ADB commands used by UAD?」也有列出用到的指令,如果不想用這套軟體的話也可以自己下指令移除。

首頁上有列出支援的廠牌,看起來還不少,拿找個時間清一下手上的 Android 手機...

Java 21 的 ZGC 在 Netflix 的效果

Hacker News 上看到連結「Bending pause times to your will with Generational ZGC (netflixtechblog.com)」,發現這篇還沒整理:「Bending pause times to your will with Generational ZGC」,裡面講的東西都有圖有數字 (i.e. Y 軸),作者是 Danny Thomas

在這之前他們就已經知道 GC pause 是延遲的重要來源,會導致 timeout & retry:

In both our GRPC and DGS Framework services, GC pauses are a significant source of tail latencies.

That’s particularly true of our GRPC clients and servers, where request cancellations due to timeouts interact with reliability features such as retries, hedging and fallbacks.

第一張圖拉出來的資料是 error rate,白色是上個禮拜的資料,紫色是這個禮拜的資料,而從 G1GC 切到 ZGC 是在 2023/11/16 發生的:

可以看到很明顯的 error rate 改變:尖峰從 2k 下降到大約 0.3k,大約是原來的 1/6 到 1/7 的下降。

第二張圖是 GC 的時間:

可以看到 G1GC 還是偶而會撞到 2 秒,發生時平均值也都還是會 >100ms,切到 ZGC 後直接降到個位數 ms 等級了。

第三張圖是 memory overhead 的部分:

從圖上可以看到上週與本週的對比,導入 ZGC 後記憶體的使用量下降了,不過文裡面倒是沒解釋這點,反而提到 ZGC 比起 G1GC 有個固定的 3% overhead:

ZGC has a fixed overhead 3% of the heap size, requiring more native memory than G1. Except in a couple of cases, there’s been no need to lower the maximum heap size to allow for more headroom, and those were services with greater than average native memory needs.

第四張則是 Huge Pages 的差異,這邊要注意這張圖的 Y 軸不是從 0 計算:

可以看到在開 Huge Pages 後,在 RPS (request per second) 不變的情況下 CPU 使用率是有下降的,大約從 50% 降到 45% 左右,不過這張圖的時間跨度有點少,應該是要拉長一點的圖... 不過既然被提出來了,就假設 Netflix 內看起來應該是有這個趨勢,只是抓圖的時候懶了點?

整體算是大成功?