GripNewsDec 14
🌘 軟體的表面張力：透過約束維持系統的完整性
➤ 從水滴的表面張力看軟體的內在穩定性與彈性
✤ https://iamstelios.com/blog/surface-tension-of-software/
本文探討軟體系統如何透過內建的約束機制，維持其結構的穩定性和完整性，如同水滴的表面張力一般。作者以生動的比喻闡述，良好的軟體設計應能抵禦變更帶來的衝擊，避免任意狀態的產生。透過類型系統、不變性、介面約束等方法，明確定義系統的邊界與規則，確保邏輯的清晰，進而使系統在面對修改時能「彎而不斷」。文章也提及過度約束可能導致系統僵化，強調在結構與變動之間尋求微妙平衡的重要性，這也是軟體開發的真正藝術。
+ 這篇文章的比喻非常貼切，讓我對軟體系統的「完整性」有了更深的理解。原來很多設計原則背後的邏輯是這麼有道理。
+ 很有啟發性！特別是關於 enum 設計如何消弭無效狀態，還有約束與彈性之間的平衡，都讓我重新思考現有的程式碼。
#軟體工程 #系統設計 #軟體架構 #程式設計哲學
Surface Tension of Software

How systems hold their shape through constraint, and why integrity emerges from what you make impossible

~/iam
GripNewsNov 27
🌘 數位訊號處理入門：DSP 系統設計導論（第一部）
➤ 揭開數位訊號處理的奧祕：從類比到數位，設計你的第一個 DSP 系統
✤ https://www.analog.com/en/resources/analog-dialogue/articles/dsp-101-part-1.html
本文為數位訊號處理（DSP）系列文章的第一部，旨在為類比系統設計師介紹 DSP 的概念、優勢及應用。文章闡述了 DSP 處理器如何透過專為高速數值運算優化的軟硬體，即時處理類比訊號的數位樣本。與傳統類比濾波器相比，DSP 濾波器因其軟體基礎而更具彈性、可重複性且易於修改，尤其在高階濾波器設計上，DSP 展現出顯著的成本效益與穩定性。文中也介紹了兩種主要的 DSP 濾波器設計方法：有限脈衝響應（FIR）與無限脈衝響應（IIR），並探討了數位訊號處理的基礎，即即時訊號採樣，強調了採樣頻率對訊號還原精確度的關鍵影響。
+ 這篇文章真是 DSP 的最佳入門！終於瞭解為什麼現在的電子產品都離不開 DSP 了，原來軟體控制比硬體調整方便這麼多。
+ 對於類比背景的工程師
#數位訊號處理 #DSP #系統設計
GripNewsNov 19
🌗 Cloudflare 故障事件後，系統思辨與操作員界面質疑
➤ 探究 Cloudflare 事故報告背後被忽略的系統性問題與操作員界面設計
✤ https://entropicthoughts.com/questions-for-cloudflare
作者針對 Cloudflare 近期發生的重大網路中斷事件，質疑該公司在事故報告中過於強調控制路徑，卻忽略了關鍵的迴路回饋機制。透過簡化的系統模型，作者提出一系列關於操作員界面設計、系統可觀察性以及內部協定遵循性的關鍵問題，旨在釐清 Cloudflare 是否真正關注操作員如何理解和應對系統行為，以及在事故發生時，操作員是否擁有足夠的資訊來有效決策。文章呼籲技術組織應更深入地進行事故調查，並建議潛在使用者在採用 Cloudflare 服務前，應審慎考量這些操作和設計上的潛在風險。
+ 這篇文章點出了 Cloudflare 報告中的盲點，尤其是在回饋機制這塊。操作員需要的不僅是控制權，更重要的是理解系統狀態的能力。
+ 對於 Cloudflare 的使用者來說，這些問題非常重要。在我們
#系統設計 #網路安全 #事故分析 #雲端服務
Questions for Cloudflare

GripNewsNov 11
🌗 「最後寫入、優先讀取」規則：在無交易的世界中保持系統一致性
➤ 在分散式系統中，如何像銀行金庫一樣，確保資料的準確與安全
✤ https://tigerbeetle.com/blog/2025-11-06-the-write-last-read-first-rule/
本文探討如何在缺乏傳統交易機制的情況下，確保分散式金融系統中的資料一致性。作者以 TigerBeetle 資料庫為例，提出「最後寫入、優先讀取」的規則，將系統區分為「記錄系統」（System of Record）與「參考系統」（System of Reference）。透過將 TigerBeetle 設定為記錄系統，並採用具備回復能力的非同步佇列（Distributed Async Await）來協調跨系統的操作，即便在部分失敗的狀況下，也能確保資料的追蹤性與一致性，從而為開發者提供更可靠的開發體驗。
+ 這個「最後寫入、優先讀取」的概念很有趣，對於需要高一致性的金融應用來說，這提供了一個實際的解決方案，特別是當我們不能依賴傳統的 ACID 交易時。
+ 將 Tige
#系統設計 #資料庫 #一致性 #分散式系統
The Write Last, Read First Rule

Insights, updates, and technical deep dives on building a high-performance financial transactions database.

GripNewsNov 10
🌗 TigerFans：運用 TigerBeetle 建構高效能票務系統
➤ 從好奇心到每秒 977 張票券的優化之旅
✤ https://renerocks.ai/blog/2025-11-02--tigerfans/
作者透過親身實踐，將 TigerBeetle 這個專為金融交易設計的資料庫，應用於建構一個高流量的票務系統。文章詳細闡述瞭如何將票務模型轉換為雙帳本會計概念，利用 TigerBeetle 的帳戶與轉帳機制，確保交易的絕對正確性與不可超賣性。從一個學習專案出發，作者逐步優化系統，從最初的 115 個請求/秒，最終將效能推升至 977 個請求/秒，展現了 TigerBeetle 在極端負載下的強大處理能力，並探討了從 SQLite 遷移到 PostgreSQL、優化 SQL 查詢及調整基礎設施等效能提升的關鍵步驟。
+ 這個案例太棒了！將金融級的資料庫用於票務系統，確保了交易的嚴謹性，解決了超賣的痛點。Python 實現也讓它更易於理解。
+ 效能優化曲線令人印象深刻，從 115 到 977
#系統設計 #資料庫 #Python #TigerBeetle #效能優化
TigerFans: Building a High-Performance Ticketing System with TigerBeetle | @renerocksai

@renerocksai - personal website

GripNewsOct 29
🌘 分散式系統中的背壓機制
➤ 在訊息洪流中保持系統穩定與高效的關鍵技術
✤ https://blog.pranshu-raj.me/posts/backpressure/
本文深入探討分散式系統中至關重要的「背壓」概念。作者首先釐清了背壓的兩種定義，並偏好「生產者過載消費者的能力」此一定義。接著，文章闡述了未妥善處理背壓可能引發的一系列問題，如記憶體溢位、訊息遺失、吞吐量下降等。隨後，作者描繪了背壓發生的典型情境：生產者速率超越消費者處理速率。為了應對此問題，文章提出了四種主要策略：減緩生產者、捨棄現有訊息、捨棄新進訊息，以及增加消費者數量。作者以自身開發即時排行榜的經驗為例，詳細說明瞭如何應用「捨棄現有訊息」策略來優化效能。此外，文章還觸及了 TCP 如何透過流量控制與壅塞控制來處理背壓，並列舉了 Kafka、gRPC 等其他採用背壓機制的系統。
+ 這篇文章對背壓的解釋非常到位，特別是將其比喻為俄羅斯方塊遊戲，讓人更容易理解。作者提供的幾種解決方案也相當實用。
+ 作者在處理即時排行榜時的實務經驗分享非常有價值，讓我對如何在特定情
#系統設計 #分散式系統 #背壓 #效能優化
Backpressure in Distributed Systems | Systems & Sidequests

Understanding what it is, how to deal with it, where it's used and how I handled it in the real time leaderboard.

GripNewsOct 23
🌘 關於 Arena 與非平凡解構函式
➤ 在 C++ Arena 配置器中安全管理資源
✤ https://nullprogram.com/blog/2025/10/16/
本文探討如何在 C++ 的 Arena 配置器中安全地處理具有非平凡解構函式（non-trivial destructors）的物件。作者介紹了一種新的機制，透過維護一個解構函式指標列表（LIFO stack），確保這些物件在 Arena 毀損時能夠被正確清理，同時維持了與舊版 Arena 配置器相同的介面，並且完全例外安全。作者還討論了相關的 C++ 語法和內建函式，並分享了將此技術實際應用於軟體中的一些考量。
+ 這個關於 Arena 的概念很有趣，特別是它能處理有複雜解構過程的物件，而且不增加太多額外開銷。我喜歡作者的寫作風格，清晰且逐步解釋。
+ 對我來說，C++ 的 RAII 和記憶體管理一直是個挑戰，這篇文章提供了一個相當聰明的解決方案。將解構函式鏈結起來以實現自動清理，這想法很棒。
#C++ #記憶體管理 #系統設計
Speculations on arenas and non-trivial destructors

GripNewsOct 20
🌘 無需 Kafka：僅用兩個 UNIX 訊號建構訊息佇列
➤ 用兩個訊號玩轉行程間通訊，打造你的簡易訊息佇列
✤ https://leandronsp.com/articles/you-dont-need-kafka-building-a-message-queue-with-only-two-unix-signals
作者 Leandro Proença 分享瞭如何運用兩個 UNIX 使用者自訂訊號 (SIGUSR1 和 SIGUSR2) 來模擬建立一個簡易的訊息佇列，藉此說明不必依賴 Kafka 等複雜的訊息代理，也能實現行程間通訊 (IPC)。文章深入探討了 UNIX 訊號的機制、二進位資料的編碼與解碼，以及如何在 Ruby 中捕捉訊號，最終成功將二進位資料透過訊號傳遞，實現了訊息的傳送與接收。
+ 這篇文章的點子太有創意了！原本以為訊號只能用來終止或重新載入設定，沒想到竟然能用來傳遞資料，太驚人了！
+ 雖然實務上大概不會真的這樣用，但這個實驗對理解底層原理非常有幫助，特別是二進位編碼的部分。
#系統設計 #程式設計 #UNIX #訊息佇列
You don't need Kafka: Building a message queue with only two UNIX signals

Have you ever asked yourself what if we could replace any message broker with a very simple one using only two UNIX signals? Well, I'm not surprised if you didn'

Leandro Proença
GripNewsOct 11
🌗 硬體版「貨幣化」症候羣：C 語言的勝利如何塑造了我們的計算機架構
➤ 從 C 語言主宰到硬體優化：為何我們被鎖定在函數呼叫的鎖鏈中？
✤ https://programmingsimplicity.substack.com/p/hardware-stockholm-syndrome
本文探討了為何現代中央處理器（CPU）的硬體設計，特別是針對 C 語言和「萬物皆函數」的編程範式進行了優化，這種現象被作者比喻為「硬體版「貨幣化」症候羣」。作者指出，早期 CPU 提供的基礎功能，因 C 語言的普及和其固有的函數呼叫約定，促使硬體不斷演進以支援這種模式，例如加入堆疊管理硬體和暫存器。然而，這種對同步序列函數的依賴，在多工處理的作業系統中引入了昂貴的上下文切換成本。作者透過回顧 1972 年的經濟背景，解釋了這種模式為何在當時是合理的，並以 Pong 遊戲的硬體邏輯設計為反例，說明瞭其他可能的發展路徑。最後，作者呼籲在今日 CPU 成本極低的時代，應重新審視並擺脫這種受限於過去經濟考量的硬體設計思維，探索更符合現狀的計算模型。
#計算機架構 #程式語言 #C 語言 #演算法 #系統設計
Hardware Stockholm Syndrome

2025-10-05

Paul’s Substack
GripNewsSep 12
🌘 stal/IX：重新思考 UNIX 核心概念的新作業系統
➤ 一個追求簡潔、透明與現代化設計的 Linux 變體
✤ https://stal-ix.github.io/STALIX.html
stal/IX 是一項旨在重新構思 UNIX 核心概念的作業系統專案，同時維持與 Linux API 和 ABI 的相容性。它追求簡潔易懂的系統架構，而非僅僅易於使用。stal/IX 捨棄了傳統的檔案系統階層標準 (FHS) 和 systemd，採用了類似 Nix/Guix 的原子更新及多版本管理方式。系統預設使用 musl C 函式庫，並支援使用者自選 C 函式庫。為了提升安全性與簡化管理，所有套件管理均以非 root 使用者身分進行，系統中不存在 setuid 檔案，sudo 僅是本地 SSH 守護程式的權限提升層。stal/IX 強調完全監督的程序樹，任何非 init 的程序都必須有 init 以外的父程序。該系統僅支援 Wayland，並移除 X11 以降低維護成本。此外，它還實現了獨有的檔案關聯機制，並預設支援跨平臺編
#作業系統 #UNIX #Linux #系統設計 #最小化
stal/IX

landing page