幹壞事是進步最大的原動力
在「ps aux written in bash without forking (github.com/izabera)」這邊看到的有趣東西，原連結是 GitHub 上面的專案「ps aux written entirely in bash without ever forking」。
以前偶而會碰到 process 已經爆掉，只剩下一個 shell 的情況，這時候只能自己利用 shell 內建的指令觀察系統的狀態，像是用 echo * 取代 ls 這種方法。
不過只用內建功能就把 ps aux 做出來算是很厲害了，從 /proc 挖了許多資料出來...
PS：真的遇到需要用的話，可以貼上 psaux.bash 裡面的內容。
在 Hacker News 上看到「Database Design for Google Calendar: A Tutorial (databasedesignbook.com)」這個，原文在「Database Design fo Google Calendar: a tutorial」這，這邊的資料庫指的是關聯式資料庫 (RDBMS)，像是常見的 MySQL 或是 PostgreSQL。
而有趣的點是在 Hacker News 的討論，不過還是先帶一下原文的內容。
原文主要就是怎麼設計以及怎麼下 SQL query 會比較好，另外有些「作者經驗」說明為什麼這樣設計，不過這部份很吃場景，所以當作故事聽過去比較好，自己遇到的時候需要通盤考慮；另外有些地方提到的是 trade off，沒有最佳解。
然後回到 Hacker News 上面，在 id=41044011 這邊算給你看，幹嘛用 RDBMS 設計一堆架構：
A random event from my calendar serializes to 740 bytes of iCalendar. An extremely busy calendar containing one event every 15 minutes 9am-5pm 7 days per week only contains 11680 entries for a full year, which works out to around 8MB.
Would suggest instead of designing a schema at all, a calendar is a good example of a problem that might be far better implemented as a scan. Optimizing an iCalendar parser to traverse a range of dumped events at GB/sec-like throughputs would mean the above worst-case calendar could be scanned in single-digit milliseconds.
Since optimizing a parser is a much simpler problem to solve once than changing or adding to a bad data model after it has many users, and that the very first task involving your new data model is probably to write an iCalendar importer/exporter anyway, I think this would be a really great trade off.
因為每個 entry 也不到 1KB (740 bytes)，就算是超級忙的 calendar，每週七天的 9am～5pm 都是每 15mins 一個會議的情況下，全滿也才 8MB... XDDDDDDDD
另外幫他補充說明，他這邊省略掉的是 calendar 接近於 share-nothing 架構，所以每個人直接拆開來獨立存放很容易 scale，你可以用個 scalable key-value solution 存 JSON 就好。
不過文章的原作者主要的目的是找一個大家熟悉但又有點複雜性的東西，示範 database schema 設計的考慮，我不會直接說文章原作者錯啦...
但的確一開始看到文章不會想到暴力解還蠻... 暴力的？XDDD
Hacker News 上看到在討論 Intel N100 小主機：「Intel N100 Radxa X4 First Thoughts (bret.dk)」，原文在「Intel N100 Radxa X4 First Thoughts」，剛好我自己的 N100 主機也滿一年了 (2023/07/15 拿到的)，來整理一下這一年用下來的感想？
我當時買的主機價錢是 $5,147 含稅，記憶體與硬碟的規格是 16GB RAM + 512GB SSD，掛著 HiNet 的非固固 IP 在用 (非固定制網路的固定 IP，就是固一動七的設定)。
當初買他的原因是這算是 Intel 小主機 CPU 的大進步，在 2022 年如果想要找個二十四小時都開機，但大多時間都在 idle 的小主機，會選到 2013Q4 出的 J1900，主要是看到這顆 CPU 的 TDP 掛 10W。
但 2023 年就突然有了變化，在 2023Q1 出的 N100 差不多是五倍的效能 (拿 CPU Benchmark 上面的資料)，然後 TDP 標示是 6W...
拿到以後裝了 Ubuntu 22.04，新版的 kernel 跑起來沒什麼問題，在服務都丟上去跑，實際接 power meter 看整機功耗，上面的程式 idle 時差不多在 10W 多一些，算是還蠻好用的機器。
Hacker News 上有人討論與 Raspberry Pi 5 的比較，不過兩邊的定位不太一樣，Raspberry Pi 到目前還是偏學習面向，可以看到不少人會用上面的 GPIO 接 sensor 或是其他裝置做很多事情。
而 N100 畢竟是 x86-64 架構，可以跑 Windows 加上效能頗不錯，對於辦公室文書機來說頗好用的，同樣道理，拿來跑會議室的公用電腦應該也不錯。
兩邊各自有已經發展起來的生態系...
上禮拜看到「My Favorite Algorithm: Linear Time Median Finding (2018) (rcoh.me)」這篇，原文是 2018 的文章「My Favorite Algorithm: Linear Time Median Finding」。
找中位數最直覺的想法是排序後直接拉出來，這樣的演算法在最差情況下可以做到 
不過這個問題有 Quickselect + Median of medians 的組合技，可以達到最差情況下仍然有線性時間解 
記得是演算法的經典教科書 Introduction to Algorithms (封面是個楓葉 + tree 的意象圖) 很前面的部分，好像還在 Master theorem 前面？(手上沒這本書，一時間不確定...)
其實整個演算法不難懂，用的數學證明線性時間也很簡單，用中文講理解其實蠻快的，差不多是高中生就可以理解的程度。
但記得大一時翹課 + 英文閱讀還不夠好，自己讀原文書的專注度大多放在英文閱讀上，理解演算法能分到的腦力有限，花了不少時間才理解... 現在回頭來看覺得頗有趣的。
在 Hacker News 上看到「Node.js adds experimental support for TypeScript (github.com/nodejs)」這個，標題有點誤導就是了，GitHub 上面的標題比較正確：「module: add --experimental-strip-types」。
從說明可以看到 --experimental-strip-types 參數只是接受 type 語法，但不會檢查：
It is possible to execute TypeScript files by setting the experimental flag --experimental-strip-types.
Node.js will transpile TypeScript source code into JavaScript source code.
During the transpilation process, no type checking is performed, and types are discarded.
目前的版本離跑 TypeScript 還有段距離，不過算是個有趣的開頭：
At least initially in this PR no trasformation is performed, meaning that using Enum, namespaces etc... will not be possible.
不確定官方打算要支援 TypeScript，還是只是個人作個實驗看看？
Apple 發表了網頁版的地圖服務：「Apple Maps on the web launches in beta」，網址在 https://beta.maps.apple.com/。
我用 Brave 會出現「Your current browser isn't supported」的訊息，但依照 Hacker News 上面的討論「Apple Maps on the web launches in beta (apple.com)」，看起來檢查只放在 root path 上，url 後面隨便加個字串就可以了，像是 https://beta.maps.apple.com/a 這樣。
測了一下土城這邊的情況，看起來資料還算 OK，除了連鎖商店外，一些本地的商家資料也有進去，相比 OpenStreetMap 的資料豐富不少...
Meta 發佈了 Llama 3.1：「Introducing Llama 3.1: Our most capable models to date」，這本來就只是個發佈而已，但讓我注意到的是 AWS 與 GCP 都同時宣佈在雲端上支援 Llama 3.1 了：
這代表 Meta 在 Llama 3.1 發表前就先跟 AWS & GCP 合作了，這看起來是一個包圍 OpenAI (以及微軟) 的姿態，之前好像沒看到這樣？(單純印象...)
看到 Let's Encrypt 貼出來的文章，想要停掉 OCSP 服務：「Intent to End OCSP Service」，而打算以 CRLs 為主。
OCSP 是拿來驗證 certificate 是否有效的機制，由 CA 提供服務讓瀏覽器查詢，但這會有效能與 privacy issue。
前者比較容易理解，因為熱門網站所使用的 HTTPS certificate 會導致很多瀏覽器跑去 OCSP 服務查詢；後者則是因為 OCSP 服務就會知道哪個 IP 存取哪個網站。
不過這兩個應該都可以用 OCSP stapling 解決才對，也就是 web server 去 OCSP 服務拿有效的簽名 (證明你手上的是有效的)，然後在瀏覽器連上來的時候一起送出去，這樣瀏覽器就不用跑去煩 OCSP 服務，而且 OCSP 服務也不知道誰看了什麼網站。
不過跟 CRLs 相比還是不小的負擔就是了，尤其像是 Let's Encrypt 這種等級的量，光是 web server 固定時間去要 OCSP stapling 的簽名 (這又是個數位簽章的動作) 不容易 cache；反過來 CRLs 容易 cache 多了？
另外一方面，CA/Browser 在 2023 年的時候已經投票通過，將 OCSP 列為選擇性項目，而 CRLs 則變成必要項目：「Ballot SC-063 v4: Make OCSP Optional, Require CRLs, and Incentivize Automation」
看文章的語氣，應該是先放個風向？尤其故意不提到 OCSP stapling 這點...
看到「Amazon DocumentDB announces improvements to document compression」這則公告提到 Amazon DocumentDB 5.0 支援壓縮了：
These compression benefits are now supported in Amazon DocumentDB 5.0 instance-based clusters in all regions where Amazon DocumentDB is available.
官方宣稱可以壓七倍：
Compressed documents in Amazon DocumentDB can be up to 7 times smaller than uncompressed documents, leading to lower storage costs, I/O costs, and improved query performance.
在「Managing collection-level document compression」這份文件裡面則是提到演算法是 LZ4：
Amazon DocumentDB uses the LZ4 compression algorithm to compress documents.
因為大家都猜 DocumentDB 後面是 PostgreSQL，所以我就查了一下 PostgreSQL 這邊的資料，可以從 PostgreSQL 14.0 (2021/09/30) 的 Release Notes 看到支援 LZ4：
Add ability to use LZ4 compression on TOAST data (Dilip Kumar)
This can be set at the column level, or set as a default via server parameter default_toast_compression. The server must be compiled with --with-lz4 to support this feature. The default setting is still pglz.
而 DocumentDB 則是 2019 年一月的時候出的，大概是 DocumentDB 5.0 用到的 PostgreSQL 比較新所以可以支援了...
KataGo v1.15.0 的「New Human-like Play and Analysis」推出了用人類棋譜訓練出來的 model：
This release adds a new human supervised learning ("Human SL") model trained on a large number of human games to predict human moves across players of different ranks and time periods! Not much experimentation with it has been done yet and there is probably low-hanging fruit on ways to use and visualize it, open for interested devs and enthusiasts to try.
lightvector 列出的一些 screenshot 看起來像是試著去猜測人類的棋力可能會選擇的點，列出了同樣的棋局在 20 級、1 段與 9 段會考慮的點的差異，算是一種幫助人類理解的方式？