幹壞事是進步最大的原動力
前幾天不知道在哪邊看到「Five years of GPT progress」這篇，裡面整理了這五年 GPT/LLM 的進程，算是回顧性質的文章，裡面當然有提到技術改善的地方 (像是參數大小，類神經網路層的架構差異)，另外裡面都有原始論文或是資料的連結，然後作者也有描述一些當時的背景，對於要釐清歷史脈絡也蠻有幫助的。
從 GPT、GPT-2、GPT-3 這三個 OpenAI 的作品開始講，然後提到 GPT-3 帶出來的新紀元。
接著提到的是各家都開始進來參與的年代，Jurassic-1 (AI21 Labs)、Megatron-Turing NLG (Nvidia)、Gopher (DeepMind)、Chinchilla (DeepMind)、PaLM (Google AI)。
然後是 LLaMa (Facebook)，第一個有參數夠大，而且效能夠好的 model，被放出來讓大家玩的 LLM。
最後又回到 OpenAI 的 GPT-4。
這樣整理讀起來清晰不少，但要注意裡面的發展不是線性關係，彼此之間互相影響交錯在跑 (因為中間還是有很多其他的論文互相影響)。
一樣是在 Hacker News 上看到「Who invented vector clocks? (decomposition.al)」這篇文章，在找出誰發明了 vector clock，原文在「Who invented vector clocks?」。
主要有兩個不同的時間點，一個是 vector clock 概念的提出，另外一個是第一次用到 vector 這個詞。
這篇讓我覺得有趣的地方是，vector clock 本來就是在處理分散式系統裡面事件順序的問題，而這篇文章則是在找出真實世界裡面這些發明的先後順序，而且也牽扯到了各種 citation (類比到分散式系統裡事件的 dependency)。
前幾天在 Hacker News 上看到「Clocks and Causality – Ordering Events in Distributed Systems (2022) (exhypothesi.com)」這篇，講分散式系統上 clock 的設計，作者也有跑出來在 Hacker News 上面跟大家聊一下 (帳號是 thoughtlede)，原文在「Clocks and Causality - Ordering Events in Distributed Systems」這邊。
文章裡面主要講空間是 
作者會整理這些資料的原因是因為在研究 CRDT 的時候看到演算法中常常會需要處理分散式系統裡面事件的順序，所以花了一些時間整理常見的方式：
Author here. Pleasantly surprised to see the article here.
Some context behind the article. I studied CRDTs for a few months, and noticed that different CRDT designs use logical clocks in different and clever ways. And I haven't seen anyone narrate all those ways of use in one article. My attempt with this article was to dredge up those flavors of logical clocks into one article and give them names for future reference.
(To respond to a couple of other comments, I ignored atomic (and gps-based) clocks in this discussion, as indicated in my footnote 3).
我記得還有一個 Interval Tree Clocks 可以參考 (在「Interval Tree Clocks」這邊講的比較清楚)，是針對節點的動態增刪而改善的演算法，但不確定有什麼比較有名的系統有用。
大多數應該都是用 Vector clock，畢竟是在 2007 年的「Dynamo: Amazon’s Highly Available Key-value Store」被發揚光大，而且也算是還不錯的演算法？
前幾天在 Hacker News 上看到「What happens when you leak AWS credentials and how AWS minimizes the damage (xebia.com)」這篇，原文連結在「What happens when you leak AWS credentials and how AWS minimizes the damage」這邊。原文跟 Hacker News 上的寫到東西都頗有趣的，可以分開來講。
先是原文的部份，他抓了一些時間軸：
12:33:12 – Pushed the credentials to GitHub
12:34:19 – The AWSCompromisedKeyQuarantineV2 policy is attached to the IAM user test-user by AWS
12:34:32 – Various List and Describe calls are made using the leaked credentials
12:35:08 – Received an email from AWS with the subject ‘ACTION REQUIRED: Your AWS Access Key is Exposed for AWS Account 12345678’
可以看到推上 GitHub 後，AWS 在一分七秒後就自動加上 AWSCompromisedKeyQuarantineV2 以減少災害擴大，然後再發信件通知。
這個功能可以參考 GitHub 的文件說明：「About secret scanning - GitHub Docs」。
另外在 Hacker News 上面看到有人直接把 secret scanning 當作 API 串來用 (噗)，把在 PyPI 上面掃到的 AWS secret 丟上 GitHub 觸發後續的機制：
I set up a project[1] to automatically leak AWS secrets published to the Python package index, which then triggers the secret scanning process and quarantines the keys[2]
1. https://github.com/pypi-data/pypi-aws-secrets
2. https://github.com/pypi-data/pypi-aws-secrets/blob/main/keys...
查了一下這兩個 server 端的軟體支援 Ed25519 的時間點。
OpenSSH 是在 2014/01/30 的 6.5 就支援了：
* ssh(1), sshd(8): Add support for Ed25519 as a public key type. Ed25519 is a elliptic curve signature scheme that offers better security than ECDSA and DSA and good performance. It may be used for both user and host keys.
算是相當久以前就支援了。對應到第一個支援的 Debian 版本是 Jessie 使用的 OpenSSH 6.7：「sshd(8) — openssh-server — Debian jessie — Debian Manpages」；第一個支援的 Ubuntu (LTS) 版本是 Trusty (14.04) 用的 OpenSSH 6.6：「openssh source package in Trusty」。
Dropbear 這邊就晚不少，在 2020/06/15 的 2020.79 版本才支援：
- Support ed25519 hostkeys and authorized_keys, many thanks to Vladislav Grishenko. This also replaces curve25519 with a TweetNaCl implementation that reduces code size.
所以對應到第一個支援的 Debian 版本是 Bullseye 的 2020.81：「Debian -- Details of package dropbear in bullseye」；第一個支援 Ubuntu (LTS) 的版本是 Jammy (22.04) 的 2020.81：「Ubuntu – Details of package dropbear in jammy」。
這樣看起來如果就是想要用 Ed25519 的話，變成 server 端的軟體得配合：預設裝的 sshd 應該都是 OpenSSH，如果想要換 Dropbear 的話要看 distribution 內給的版本夠不夠新，或是透過 PPA 之類的方法裝新版。
但大多數採用 BusyBox 的機器應該沒有採用新版 Dropbear (像是 AP 刷機)，這邊還是得使用其他 key format，如果要避開 NIST 有介入的格式，就還是得用 ssh-rsa 了。
因為想在 Raspberry Pi 上面把一些 log 丟上 Slack，本來看到「Stream Any Log File to Slack Using curl」這篇，但發現裡面在把字串包進 JSON object 的方法太髒 (直接把 " 換成 ')，另外一方面是 Slack 已經在宣導不要用舊版的 Incoming Webhooks，所以決定用其他方式來處理。
選擇 Perl 主要是因為有一陣子沒有用 Perl 寫東西了，倒不是什麼特別的原因 (如果考慮到 Raspberry Pi 上資源有限的話，應該用 C 或是 Rust 或是 Go，但我的 Raspberry Pi 還沒忙到這種程度...)，所以決定用 Perl 來實做這個程式，把 log 檔案丟上 Slack：
這邊有些比較不太常見的選擇：
tail -F 的輸出，是因為 File::Tail 非常舊了 (2015)，實做上沒有用到 inotify 類的界面監控檔案的變化，反而是系統的 tail 有做。use v5.14 的原因。然後查了一下 // 的用法在 Perl 5.10+ 就支援了，好早...
Hacker News 上看到 VPN 廠商 Mullvad 也推出了自家的瀏覽器，Mullvad Browser：「The Mullvad Browser (mullvad.net)」。
改自 Tor Browser，最底層是 Firefox，然後開起來看，內建了三個套件：
然後因為是基於 Tor Browser，所以許多的預設值會更偏向強化隱私性的設定，這點可以從 fingerprint.com 這邊測發現，每次重開瀏覽器會是不一樣的值，這代表用 canvas 的網站有一定機會會掛掉... 另外會有一些不方便的地方，像是時間相關的設定因為要隱藏 timezone，所以 server 端無法取得 client 的正確時間資訊。
而在 FAQ 裡面有提到，Mullvad Browser 不允許你透過 cookie 記錄登入資訊：
How do I stay logged into specific websites between sessions?
It’s not possible. It’s an action to combat tracking.
所以這個瀏覽器的定位不會是給你當作一般用的... 但這樣的話我更偏好用 Tor Browser？
把一台本來跑在 Vultr 上的機器搬到 AWS 的 us-east-1 上面，除了剛好把 Ubuntu 18.04 換成 Ubuntu 22.04 外，也把本來用 x86-64 架構的機器換成用 ARM 的 t4g.micro (都是 1GB RAM)。
就效能上來說，t4g 機器的效能很不錯，這兩年 blog 跑的也都還算順，先前公司用起來感覺也很好，然後價錢更便宜，另外加上 AWS 的三年 RI 折扣大約是 4 折的價錢，算是會想要換的主因。
在確認應用跑得起來後，買三年 RI 是 $87.15/3y，所以機器本身的費用大約是 $29.05/y，就算加上 8GB 的 EBS (gp3) 空間費用，整體比本來在 Vultr 的 $6/mo 低不少。
上面跑的是我自己的 Trac，想搬到 AWS 上一陣子了，但有幾個不確定的因素，所以連假期間才有空多花一些時間確認。
第一個是 MySQL 的部份，我自己習慣用 Percona Server 的版本，但目前還沒有 arm64 的套件可以直接裝，要用的話就得自己編以及升級。
在 2021 年的時候 blog 搬到 AWS 的時候就遇過了，本來以為這次有機會，但看了一下還是沒支援，所以還是得用 MariaDB。
第二個是 Trac 1.4 只能跑在 Python 2.7 上 (mailing list 上有在討論轉到 Python 3 的事情，但看起來官方的動力也不大...)，這在 18.04 的時代是沒什麼問題，但 22.04 下面不知道會爛掉多少東西。
所以只能繼續用 pyenv 扛著，但已經有預期會遇到問題，加上這次又從 MySQL 轉到 MariaDB，應該也會有些地雷...
所以跳下去後遇到的問題就跟上面提到的類似，分成兩塊。
在 MariaDB 這邊第一個遇到問題是，雖然官方有提供 APT server，但沒有在 HTTPS server 上放新的 public key，所以一定得從 key server 撈。
但 GnuPG 就是沒有直接從 key server 下載變成檔案的功能，一定要先塞到 keystore 裡面再 export 出來，就覺得很...
所以就冒出利用 mktemp -d 在 /tmp 下產生暫存目錄這樣的寫法，讓 GnuPG 把 keystore 放進去，這樣至少在重開機後就會消失：
export GNUPGHOME=$(mktemp -d); gpg --recv-keys --keyserver hkp://keyserver.ubuntu.com:80 0x177F4010FE56CA3336300305F1656F24C74CD1D8; gpg --export 0x177F4010FE56CA3336300305F1656F24C74CD1D8 | sudo tee /etc/apt/trusted.gpg.d/mariadb.gpg > /dev/null; unset GNUPGHOME
這邊為了安全性，還得把官方提供的 0xF1656F24C74CD1D8 換成 0x177F4010FE56CA3336300305F1656F24C74CD1D8。
另外就是整理 MariaDB 需要的 my.cnf 內容，我是拿 Percona Server 5.7 的設定檔來改，只刪掉了跟 GTID 相關的設定就會動了。
而其他 MariaDB 遇到的問題主要是設計改變的問題，在 wiki 上有提到。
接下來是 Trac 1.4 的問題，本來的安裝是用 libmysqlclient-dev，然後再安裝 mysql-python：
sudo apt install -y libmysqlclient-dev pip install mysql-python PyMySQL Pygments Trac
但單純把 libmysqlclient-dev 換成 libmariadb-dev 後，mysql-python 還是編不動，照著錯誤訊息試著 workaround (像是試著把 /usr/bin/mysql_config 指到 /usr/bin/mariadb_config) 半天還是不過，最後找資料發現要改用 mysqlclient：
sudo apt install -y libmariadb-dev pip install mysqlclient PyMySQL Pygments Trac
搞定後後續就一路看錯誤訊息解就可以了...
在 Hacker News 上看到「Llama.cpp 30B runs with only 6GB of RAM now (github.com/ggerganov)」這個消息，原 pull request 在「Make loading weights 10-100x faster #613」這邊。
這個 PR 的作者 Justine Tunney 在 PR 上有提到他改變 model 檔案格式，以便改用 mmap()，大幅降低了需要預先讀取的時間 (因為變成 lazy-loading style)，而且這也讓系統可以利用 cache page，避免了 double buffering 的問題：
This was accomplished by changing the file format so we can mmap() weights directly into memory without having to read() or copy them thereby ensuring the kernel can make its file cache pages directly accessible to our inference processes; and secondly, that the file cache pages are much less likely to get evicted (which would force loads to hit disk) because they're no longer competing with memory pages that were needlessly created by gigabytes of standard i/o.
這讓我想到在資料庫領域中，PostgreSQL 也會用 mmap() 操作，有點類似的概念。
另外 Justine Tunney 在這邊的 comment 有提到一個意外觀察到的現象，他發現實際在計算的時候用到的 model 內容意外的少：他用一個簡單的 prompt 測試，發現 20GB 的 30B model 檔案在他的 Intel 機器上實際只用到了 1.6GB 左右：
If I run 30B on my Intel machine:
[...]
As we can see, 400k page faults happen, which means only 1.6 gigabytes ((411522 * 4096) / (1024 * 1024)) of the 20 gigabyte weights file actually needed to be used.
這點他還在懷疑是不是他的修改有 bug，但目前他覺得不太像，也看不太出來：
Now, since my change is so new, it's possible my theory is wrong and this is just a bug. I don't actually understand the inner workings of LLaMA 30B well enough to know why it's sparse. Maybe we made some kind of rare mistake where llama.cpp is somehow evaluating 30B as though it were the 7B model. Anything's possible, however I don't think it's likely. I was pretty careful in writing this change, to compare the deterministic output of the LLaMA model, before and after the Git commit occurred. I haven't however actually found the time to reconcile the output of LLaMA C++ with something like PyTorch. It'd be great if someone could help with that, and possibly help us know why, from more a data science (rather than systems engineering perspective) why 30B is sparse.
如果不是 bug 的話，這其實冒出了一個很有趣的訊號，表示這些 model 是有可能再瘦身的？