Author: Gea-Suan Lin

Raspberry Pi 5

Raspberry Pi 5 的消息出來了：「Introducing: Raspberry Pi 5!」。

價錢是 $60 (4GB RAM 版本) 與 $80 (8GB RAM 版本)，目前看起來是 pre-order 階段。

Today, we’re delighted to announce the launch of Raspberry Pi 5, coming at the end of October. Priced at $60 for the 4GB variant, and $80 for its 8GB sibling, virtually every aspect of the platform has been upgraded, delivering a no-compromises user experience.

其中一個大賣點應該是效能了，宣稱與 RPi4 相比，CPU/GPU 效能是以前的兩倍到三倍，記憶體與 I/O 的頻寬也加倍了，所以應該是所有應用都會變快不少：

Today, that effort bears fruit, with the launch of Raspberry Pi 5: compared to Raspberry Pi 4, we have between two and three times the CPU and GPU performance; roughly twice the memory and I/O bandwidth; and for the first time we have Raspberry Pi silicon on a flagship Raspberry Pi device.

等到後續出貨應該就會有資料可以看了，不過從時脈就可以看出一些重點，上一代還是 1.5GHz (或是後來更新的 1.8GHz)，這一代拉到 2.4GHz 了：

2.4GHz quad-core 64-bit Arm Cortex-A76 CPU

而後續也提到，在相同的 loading 吃電量比 RPi4 低，但因為 boost 的關係，瞬間最高吃電量從以前 RPi4 的 8W 變到 RPi5 的 12W：

Raspberry Pi 5 consumes significantly less power, and runs significantly cooler, than Raspberry Pi 4 when running an identical workload. However, the much higher performance ceiling means that for the most intensive workloads, and in particular for pathological “power virus” workloads, peak power consumption increases to around 12W, versus 8W for Raspberry Pi 4.

但也因為這樣，如果你拿 15W 的 USB-C 充電器時，他的 USB port 就只能提供 3W 的功率了 (剛好就是他提到的 5V/600mA)：

When using a standard 5V, 3A (15W) USB-C power adapter with Raspberry Pi 5, by default we must limit downstream USB current to 600mA to ensure that we have sufficient margin to support these workloads. This is lower than the 1.2A limit on Raspberry Pi 4, though generally still sufficient to drive mice, keyboards, and other low‑power peripherals.

如果要能夠讓 USB 可以供應足夠的功率 (像是外接的機械硬碟這種會吃比較多電的設備)，需要使用 5V/5A 的充電器。

但這邊提到 RPi5 firmware 在偵測到 5V/5A 的充電器時會提高限制，而不是提到 USB PD，所以可以預期是特規？

For users who wish to drive high-power peripherals like hard drives and SSDs while retaining margin for peak workloads, we are offering a $12 USB-C power adapter which supports a 5V, 5A (25W) operating mode. If the Raspberry Pi 5 firmware detects this supply, it increases the USB current limit to 1.6A, providing 5W of extra power for downstream USB devices and 5W of extra on-board power budget: a boon for those of you who want to experiment with overclocking your Raspberry Pi 5.

供貨的部分反而沒有聊到太多，但 RPi4 最近的供貨還算可以，所以可以預期 RPi5 應該不會太差？

GCP 提供每個區域的 Standard Tier Networking 每個月 200GB 的免費頻寬

GCP 提供每個區域 Standard Tier Networking 每個月有 200GB 的免費頻寬：「Announcing 200 GB free Standard Tier internet data transfer per month」。

這類優惠應該是要給練習或是試用的人用的，吸引他們放一些量上來...

另外雖然是每個區域都有 200GB/mo 的 free bandwidth，但通常也只會用一個或兩個區域，以台灣的 asia-east1 來說，如果有量在上面跑的話，省下來的會是 $0.07/GB 這個部分，大概就是 $14/mo 左右？

ClickHouse 弄了一個 C++ 寫的 ZooKeeper drop-in replacement：ClickHouse Keeper

在 Hacker News 上看到「ClickHouse Keeper: A ZooKeeper alternative written in C++ (clickhouse.com)」，原文是「ClickHouse Keeper: A ZooKeeper alternative written in C++」。

在 distributed coordination 這個領域目前應該是 etcd 比較知名，但 Apache ZooKeeper 畢竟算是元老，還是有不少應用程式會把 ZooKeeper 當作基礎建設在用。

因此 etcd 也包了一個 zetcd，可以用 etcd 當作底層結構，但提供 ZooKeeper API 的介面讓應用程式使用：

Serve the Apache Zookeeper API but back it with an etcd cluster

這次 ClickHouse 的人搞出一個用 C++ 寫的 ClickHouse Keeper，定位是 drop-in replacement，想要解決現有的應用程式遇到的記憶體資源問題。

從開頭的說明就可以看到著重在這塊：

up to 46 times less memory than ZooKeeper ​​for the same volume of data while maintaining performance close to ZooKeeper.

而對於新的應用程式，在開發時應該就不太會選 ZooKeeper 了，畢竟連 distributed lock 都得自己操作 znode 把功能疊出來 (像是官網很貼心的還提供了「ZooKeeper Recipes and Solutions」，裡面提供了 lock 的方法)，而這種事情太累，用 etcd 方便太多...

號稱目前最強的 Mistral 7B

Hacker News 上看到「Mistral 7B (mistral.ai)」，Mistral 7B 是目前號稱最強的 7B model。

宣稱在所有項目超越 Llama 2 13B，以及在許多項目超越 Llama 1 34B：

Outperforms Llama 2 13B on all benchmarks
Outperforms Llama 1 34B on many benchmarks

很重要的是以 open source license 放出來的，選的是 Apache License, Version 2.0：

We’re releasing Mistral 7B under the Apache 2.0 license, it can be used without restrictions.

這個 model 大小是可以用 CPU 跑的，馬上就有人推 patch 進 llama.cpp 了：「Added the fact that llama.cpp supports Mistral AI release 0.1 #3362」。

我記得 Llama 2 13B 的輸出結果還有點微妙，但如果說是全部都超過的話，也許可以期待看看品質...

Percona XtraDB Cluster (PXC) 的感想

看到「Percona XtraDB Cluster 是 MySQL 的叢集與分散式解決方案」這篇，裡面提到了 Percona 包的 Galera Cluster，叫 Percona XtraDB Cluster。

Percona 算是把 Galera Cluster 包的比較好的 distribution，是還蠻建議直接用他們家的版本。另外我記得 MariaDB 也有包一個版本，叫做 MariaDB Galera Cluster。

這篇算是很早期使用 PXC 的人的一些感想：(大概是 2012 年導入，當年雲端也還沒流行，在地端上面自己建，對應的 MySQL 底層還是 5.5 的年代)

Percona XtraDB Cluster 建議至少三台

Galera Cluster 的三台可以是兩台有資料的，加上一台沒有資料，這台沒資料的只負責投票組成 quorum，不需要到三台都是大機器，而且這樣的配置也比較單純一點。

另外兩台雖然都可以當 writer 寫入，但實務上會建議都集中在一台寫，這樣可以大幅降低跨機器時產生的 lock contention。

基於上面這個因素，將兩台有資料的機器，一台做 writer，另外一台做 reader 算是常見的架構，然後把可以接受些許 replication lag 的應用 (像是什麼 BI 專用 DB server) 用傳統的 MySQL logical replication 掛出去 (標準的 master-slave 架構，或是後來政治改名為 source-replica 架構)，不要直接參與 Galera Cluster 協定。

(MySQL 5.5 的時候還得自己處理當 master/source 切換時 replication binlog position 的問題，現在有 GUID 後會好一些)

除了 Galera Cluster 外，另外一種方式 (也是比較傳統的方式) 是 active-standby 的方式跑 DRBD：因為 DRBD 可以在兩台機器的 block 層做 mirror，所以切換的時候另外一台機器只要跑 journaling filesystem recovery (像是當年比較流行的 XFS 或是後來主力的 ext4) + InnoDB recovery 就可以跑起來。

DRBD 的老方法架構很單純，維護成本也很低，但缺點就是 recovery 的時間會高一些：在 crash 的 case 下可以做到十分鐘的 downtime 切換 (在傳統磁頭硬碟組成的 RAID)，而 Galera Cluster 因為等於是 hot-standby，蠻容易就可以做到小於 30 秒。

另外在切換後 warmup 的時間上，Galera Cluster 也是因為 hot-standby 大勝：DRBD 這邊的情境等於是 cold start，資料庫內還有很多東西還沒進到 InnoDB buffer，對應的 SQL query 還不會快。

相比起來 Galera Cluster 看起來是個好東西，但後面運作的機制複雜不少 (而且需要有人維護)，公司如果有專門的 DBOps 會比較好...

不過現在 SSD 變成主流的情況，讀取速度與 random access 的效率都快很多，這使得 DRBD 切換的成本低很多了，很有機會整個 downtime (切換 + warmup) 是五分鐘內搞定，如果這個時間是可以接受的，用 Galera Cluster 的優點可能就沒那麼高了...

scp -3：直接對兩個 remote host 複製檔案

剛剛找資料才發現的，scp 指令早就可以針對兩個遠端複製檔案了：「scp from one remote server to another remote server」。

可以加上 -3，像是這樣：

scp -3 src:/foo/bar/a.zip dst:/tmp/

不過依照說明可以不用加，因為這是 default 值：

Copies between two remote hosts are transferred through the local host. Without this option the data is copied directly between the two remote hosts. Note that, when using the legacy SCP protocol (via the -O flag), this option selects batch mode for the second host as scp cannot ask for passwords or passphrases for both hosts. This mode is the default.

看了 Stack Exchange 上的回答日期，是 2014 年十月回的，所以至少 Ubuntu 16.04 就有這個功能了？(沒有去查這個功能多早...)

之前一直都是查怎麼用 rsync 搬，然後發現做不到所以都還是傻傻的透過 jump server 轉運檔案，沒想到隔壁棚早就給了解法...

這樣有些情境搬檔案就簡單多了...

目前最老的 BitTorrent 種子 20 年了：The Fanimatrix

The Fanimatrix 的 BitTorrent 種子是目前還活著的 BitTorrent 種子最老的，從 2003 年九月建立的種子，至今要 20 年了：「The World’s Oldest Active Torrent Turns 20 Years Old」。

在 2022 的報告裡面 BitTorrent 的流量大約是 2.91% (雖然這份報告本身有些地方很詭異，但就還是可以當個參考)：「2022 Global Internet Phenomena Report」，在「BitTorrent is Still the King of Upstream Internet Traffic, But for How Long?」這邊也在討論 BitTorrent 的占比逐漸下降。

但這就是 open protocol 的特性，你沒辦法殺掉他，而且他在對應的領域還是活的很好...

cURL 放入 ipfs:// 支援

在 Hacker News 上看到 cURL 支援 ipfs:// 的消息：「IPFS support got merged into curl (twitter.com/bmann)」。

Hacker News 上有人提到這包支援的特性與問題：

This patch makes curl utilize a gateway for ipfs:// addresses. It prefers a local one but can also use public gateways. It makes no effort to verify that the final product's cryptographic hash corresponds to the one in the address.

依照說明是透過 gateway 處理，如果本地端有的話就用本地端的 gateway，不然就用 public gateway。另外就是沒有驗證 hash...

不算是原生支援，但還行...？

Kagi 又恢復 $10/mo 的 Unlimited Search Plan 了

Kagi 公告 $10/mo 的 Unlimited Search Plan：「Unlimited Kagi searches for $10 per month」。

今天公告以後可以看到有個比較抖一點的成長，但要再觀察看看是不是持續的：

翻了一下文章，還是沒看到為什麼要這樣做，尤其是財務上的理由... 最早從 $10/mo 漲到 $25/mo 就是成本問題，我的猜測是現在有量了所以 discount 比較好談 (從 9/6 的「Kagi Search Stats」的 8034 與現在的相比，的確可以看到一直在成長)，然後談完 discount 後重算成本結構，發現有機會衝一波？

也有可能是 VC 那邊有進展？像是找到比較願意放手讓 Kagi 執行這樣的理念的 VC？

Anyway，$10/mo 又回來了...

Golang 將改變常見的 closure 地雷

在「Fixing for loops in Go 1.22 (go.dev)」看到的，原文在「Fixing For Loops in Go 1.22」這邊。

算是各種有 closure 的程式語言會遇到的經典問題，下面的 Golang 程式在撰寫時會預期輸出 a、b、c (不保證順序)，但實際上會輸出 c、c、c，因為變數的 scope 設計原因：

func main() {
    done := make(chan bool)

    values := []string{"a", "b", "c"}
    for _, v := range values {
        go func() {
            fmt.Println(v)
            done <- true
        }()
    }

    // wait for all goroutines to complete before exiting
    for _ = range values {
        <-done
    }
}

這在 JavaScript 也是個經典的問題，搜「javascript closure loop」就可以看到「JavaScript closure inside loops – simple practical example」這個例子，對應的答案則是有提到 ES6 的 let 因為改變了變數的 scope，可以用來解決這個問題。

剛好 let 也是 best practice 了，所以現在 JavaScript 這邊遇到這個問題的情況會少一些。

回到 Golang 這邊，Golang 是打算改變在 for loop 時，對應變數的 scope 來解決：

For Go 1.22, we plan to change for loops to make these variables have per-iteration scope instead of per-loop scope. This change will fix the examples above, so that they are no longer buggy Go programs; it will end the production problems caused by such mistakes; and it will remove the need for imprecise tools that prompt users to make unnecessary changes to their code.

另外因為這是 breaking compatibility 的改變 (畢竟有些程式碼是清楚知道這個特性而刻意這樣寫的)，所以會有對應的措施，只有在有指定 Golang 1.22 或是更新的版本才會用新的 scope 編譯：

To ensure backwards compatibility with existing code, the new semantics will only apply in packages contained in modules that declare go 1.22 or later in their go.mod files. This per-module decision provides developer control of a gradual update to the new semantics throughout a codebase. It is also possible to use //go:build lines to control the decision on a per-file basis.