歡迎來到 DAVID888 Daily 每日放送！今天我們將帶你從一位更生人工程師的開源救贖之路出發，探討用化學原理解析的完美鬆餅、Linear 零延遲的技術奧秘、資料庫隔離級別的迷思、Linux 經典的 /lost+found 機制、1948 年 IBM 604 的硬體逆向工程，以及如何與未竟之夢和解，最後再看看離線生存電腦與會成長的 AI Agent 等前沿開源專案。
Building from zero after addiction, prison, and a felony
從深淵到開源：一位重罪犯的技術救贖
資深工程師 Gavin Ray 分享了他如何從少年重刑犯監獄與毒癮深淵中，透過 Open Source（開源）貢獻與社群信任，重新建立軟體開發生涯並加入知名 GraphQL 公司 Hasura 的傳奇歷程。
Gavin 在 14 至 16 歲期間於最高安全級別的少年監獄服刑，19 歲時更因 17 項二級受管制物質持有與販售指控成為聯邦重罪犯（Felon）。重獲自由後，他面臨了極其殘酷的求職困境：他曾憑藉實力通過 8 家公司的最終輪面試並拿到 Offer，但每次都在最後關頭因企業 HR 的「No Felons（不錄用重罪犯）」背景審查政策而被無情撤回。
轉折點發生在他於邁阿密一家年薪僅 5 萬美元的新創公司工作時。當時他接觸到了 Hasura（一個能自動生成 Postgres CRUD API 的工具），並深深為之著迷。他開始深入 Hasura 的 Discord 社群協助解答其他用戶的問題，並積極提交 Pull Request（PR）。他的技術實力與熱情打動了 Hasura 團隊，最終繞過傳統 HR 篩選直接獲得錄用，薪資也瞬間翻倍至 10 萬美元以上。
社群熱議：非典型路徑在 AI 時代還走得通嗎？
這篇真誠的分享在 Hacker News 引發了極大迴響。許多人指出，Gavin 當年能直接走進辦公室獲得實習機會、或透過社群直接對接開發團隊的「非典型路徑」，在如今 AI 履歷自動篩選器（ATS）橫行的時代已幾乎不可行。
此外，評論區也出現了兩極化的聲音。有用戶質疑 Gavin 當年將研究性化學物質（Methylone）當成 MDMA 轉售的道德問題，認為他不配得到第二次機會；但絕大多數社群成員則強烈反對這種「終身貼標籤」的想法，認為更生人若展現出真正的改變，理應獲得重生的機會。有趣的是，討論甚至歪樓到了「更生人的冒險性格」與「騎摩托車安全性」的激烈辯論。
編輯觀點：對於有背景瑕疵或非科班出身的開發者來說，Open Source 是唯一的「無偏見競技場」。在這裡，代碼質量與社群貢獻是唯一的通行證，能直接繞過 HR 的背景審查與學歷過濾器。這也提醒技術主管在招聘時，應多關注候選人在開源社群的實際足跡，而非單純依賴自動化的背景調查。
Show HN: I Derived a Pancake
用第一原理「推導」出一塊完美鬆餅
你以為煎鬆餅只是把麵粉、蛋和牛奶攪一攪嗎？軟體工程師 Ben 從化學第一原理（酸鹼化學計量、二氧化碳動力學、麵筋抑制與梅納反應）出發，硬是推導出了「最優化鬆餅配方」，並開發出一個能根據冰箱現有食材自動計算化學計量的互動式計算機！
這項研究的硬核程度令人咋舌：
- 酸鹼緩衝與 $pK_a$：檸檬酸是三元酸（Triprotic），但其第三步解離常數（$pK_{a3} = 6.40$）與碳酸（$pK_a = 6.35$）極為接近。在麵糊 pH 值約 6.4 的環境下，僅有 50% 的檸檬酸分子能釋放第三個質子，因此有效質子釋放比率為 2.5 而非 3。
- 乳酸感知閾值：麵糊中乳酸當量濃度在 0.05% 以下時人類無感，超過 0.2% 會有明顯酸味，而天然酵母（Sourdough）的範圍則在 0.45% - 0.73%。
- 熱力學與熱容量：30cm 的鑄鐵鍋（2.8kg）在 200°C 下能儲存約 258 kJ 的熱能，而同尺寸的碳鋼鍋（1.4kg）僅能儲存 127 kJ。鑄鐵的高熱容能防止冷麵糊倒入時溫度驟降，從而維持梅納反應所需的 140°C 以上高溫。
- 聲學脆度測試：Ben 甚至引用了 1976 年的聲學破裂力學研究，指出脆度（Crispness）本質上是高頻聲學現象，破裂產生的聲波能量集中在 5 kHz 以上；而嚼勁（Crunchiness）則集中在 1.25 - 2 kHz。
實用主義 vs. 極致工程的對決
這個項目讓網友們又愛又恨。有網友幽默地吐槽：「當早上 7:30 面對四個尖叫的孩子和一隻飢餓的狗時，誰有空去等 10 小時的低溫發酵？這時候超市買的預拌粉才是唯一救星！」
另外，關於「烘焙是否必須用秤」也引發了論戰。有人認為環境濕度對麵粉重量的影響（吸水率變化）遠大於杯子計量的誤差，且人類味覺具有魯棒性；但專業烘焙派則強烈反駁，指出麵粉因緊實度不同，體積誤差可達 20% 以上，這也是為什麼專業烘焙一律使用重量（Weight）而非體積（Volume）的原因。
編輯觀點：這個項目展示了將嚴謹的軟體工程思維（參數化設計、邊界條件限制、雙分法求解器）應用於傳統烹飪的魅力。它告訴我們：任何看似「憑感覺」的混沌系統，只要拆解到物理與化學底層，都能轉化為可預測、可編程的演算法。
Making peace with your unlived dreams (2023)
與那些未竟之夢握手言和
我們每個人心中，或許都埋藏著一些永遠無法實現的夢想。作者 Niklas Göke 在文中探討了如何面對因生理限制（如膝蓋受損無法滑雪）或時間有限而無法實現的「未竟之夢」，並透過斯多葛學派（Stoicism）與禪宗思維與這些遺憾達成和解。
作者因為遺傳與後天因素，膝蓋無法承受高強度運動，15 年前就被骨科醫生警告必須遠離滑雪、網球等運動。他引用了 Sylvia Plath 在經典小說《鐘形罩》（The Bell Jar）中的「無花果樹」隱喻：你看著無數代表美好未來的無花果在眼前枯萎落地，只因為你無法決定到底要摘下哪一顆，最後只能眼睜睜看著它們全部流逝。
命運的重擊與醫學的局限
這篇文章觸動了無數讀者的心。一位網友分享了他極具毀滅性的真實經歷：他的兒子在 3 歲時確診癌症，好不容易熬過化療，卻又確診重度自閉症，這迫使他不得不放棄退伍後的所有夢想，終身擔任全職看護。這讓社群深切體會到，有些夢想的破滅並非個人選擇，而是命運強加的悲劇。
不過，也有讀者從實用角度提出建議，認為普通醫生的診斷通常過於保守（只會叫你「不要做」），如果透過專業的運動醫學（Sports Medicine）與物理治療（DPT），例如進行單腿下蹲與倒退拉雪橇等針對性訓練，許多被判定「報廢」的關節其實是有機會重建功能的。
編輯觀點：開發者常患有「技術焦慮症」，總想學完所有語言、框架、寫出獨角獸專案。這篇文章提醒我們，人生與系統設計一樣，都受限於有限的資源（時間與精力）。學會對非核心的「夢想分支」進行 Pruning（剪枝），並非妥協，而是為了讓核心系統（當下的生活與關係）能獲得最大頻寬的優化。
How's Linear so fast? A technical breakdown
為什麼 Linear 這麼快？深度技術拆解
專案管理工具 Linear 一直以極致的速度著稱。這篇技術拆解深入剖析了 Linear 如何透過「瀏覽器即資料庫（Local-first）」、MobX 細粒度響應式更新，以及極致的打包優化，將傳統 CRUD 應用的 300ms 延遲降低至近乎 0ms 的原生級體驗。
其核心技術細節包括：
- Local-first 架構：將完整資料庫（IndexedDB，使用
idb包裝）直接移至瀏覽器。UI 讀取記憶體中的 MobX Observable 狀態，任何修改（Mutation）優先寫入本地，再由同步引擎（Sync Engine）在背景非同步推送到伺服器。 - 打包演進：Linear 經歷了 Parcel -> Rollup -> Vite -> Rolldown 的四次重構。他們果斷捨棄了對舊版瀏覽器的支援（無 Polyfills、無 ES5 轉譯），使代碼量減少 50%，壓縮後體積減少 30%，Safari 上的首次渲染時間（Time-to-first-paint）提升了 59%，記憶體佔用減少 70-80%。
- 極致加載：雖然其 minified JS 高達 21MB，但透過
<link rel=modulepreload>進行並行預加載，並利用 Service Worker 在背景預快取 1,200 個雜湊資產。 - 渲染優化：避免使用會觸發瀏覽器重排（Layout-triggering）的屬性（如
width,height,margin）來做動畫，僅對 GPU 加速的 Composited 屬性（transform,opacity）進行動畫處理。
「樂觀更新」是在對用戶撒謊嗎？
儘管技術令人驚嘆，社群中也出現了不少質疑。批評者指出，Local-first 的「樂觀更新（Optimistic Updates）」本質上是在「對用戶撒謊」——在伺服器確認前就假裝操作已成功。一旦網路在背景默默斷線或發生寫入衝突，會導致嚴重的數據丟失或狀態回滾（Rollback），這在多人協同工作時會引發混亂。
此外，也有 Firefox 用戶抱怨 Linear 佔用極大記憶體，且在非 Chrome 瀏覽器上首次加載極慢。部分用戶也批評 Linear 為了追求極簡視覺，過度隱藏基礎功能（例如必須按 Ctrl+F 才能看到搜尋框），導致易用性大打折扣。
編輯觀點：Linear 的速度不是單一技術的銀彈，而是「系統級協調」的結果。它證明了在 Web 效能瓶頸已從 CPU 轉移到網路延遲（Network Latency）的今天，將伺服器視為「同步終端」而非「UI 唯一真理來源」的 Local-first 架構，才是實現極致效能的終極解法。
Do we fear the serializable isolation level more than we fear subtle bugs (2024)
我們對 Serializable 的恐懼，是否超過了對 Bug 的擔憂？
在資料庫設計中，開發者是否因為過度擔憂效能損耗，而盲目避開 SERIALIZABLE（可序列化）隔離級別，進而導致系統中隱藏著難以偵測的並行（Concurrency）漏洞？
一項學術論文分析指出，在 22 個常見的並行漏洞中，僅有 5 個是「級別相關」（因預設的弱隔離級別導致）；其餘 17 個皆為「範圍相關」（Scope-based），也就是說，開發者根本沒有將資料庫操作正確封裝在 Transaction（事務）中，導致並行 API 請求直接繞過了隔離機制。
著名的 Flexcoin 比特幣銀行劫案就是一個經典案例。其漏洞本質上就是 Race Condition（競爭條件）：讀取餘額 -> 扣除金額 -> 寫入新餘額。在沒有 SELECT FOR UPDATE 或 SERIALIZABLE 保護下，並行請求導致餘額被重複扣減，最終導致銀行破產。
隔離級別的抉擇：該交給開發者還是資料庫？
Postgres 的 Repeatable Read 採用快照隔離（Snapshot Isolation），僅能防止「寫-寫」衝突；而真正的 Serializable（如 Postgres 的 SSI）則能偵測「讀-寫」衝突，但代價是衝突時會拋出 Serialization Failure，需要應用端實現重試（Retry）機制。
有網友悲觀地表示，既然絕大多數漏洞是因為開發者連 Transaction 都寫不對，那資料庫預設提供再強的隔離級別也是白費效能。但也有人認為，SERIALIZABLE 必須成為預設值，就像現代雲端資料庫（CosmosDB, Firestore）預設自動索引一樣，因為實踐證明，絕大多數開發者根本沒有能力在開發初期正確預估並行衝突。
編輯觀點：不使用 SERIALIZABLE 的代價，是將並行控制的複雜度完全轉嫁給應用層開發者。在分散式系統與高並行場景下，手動編寫無 Bug 的鎖機制極其困難。現代資料庫（如 Google Spanner）已證明，透過 TrueTime 等技術，強一致性的 SERIALIZABLE 可以在保持高吞吐量的同時，徹底消除並行 Bug。
What is the purpose of the lost+found folder in Linux and Unix? (2014)
Linux 中的 /lost+found 資料夾到底是幹嘛用的？
如果你用過 Linux 或 Unix 系統，一定在根目錄看過 /lost+found 這個資料夾。這篇經典問答深入解釋了它在檔案系統（特別是 ext 家族）底層的運作機制。
簡單來說，當系統異常崩潰或斷電後，重啟時會執行 fsck（檔案系統檢查）。如果 fsck 發現某個 Inode 的引用計數大於 0，但在目錄樹中找不到任何目錄項（Directory Entry）指向它（這被稱為孤立檔案 Orphaned File），fsck 就會將該 Inode 重新連結到 /lost+found 下，並以 Inode 號碼命名（如 #12345），以便管理員挽救數據。
這裡有一個精妙的設計：/lost+found 的空間是由 mklost+found 預先分配（Pre-allocated）磁碟區塊（Blocks）的。這是為了確保當 fsck 在修復一個已經 100% 滿載且損壞的檔案系統時，不需要再分配新的 Data Blocks 就能直接寫入恢復的檔案。
早期 ext2 時代的噩夢與設計智慧
這篇討論勾起了許多老玩家的回憶。在早期 ext2 時代，系統未正常關機導致開機強制執行 fsck 是家常便飯，大容量硬碟動輒需要數小時甚至整晚才能完成掃描。
有人質疑，為什麼不等到需要時再動態創建該資料夾？專家解釋了關鍵的「引導程序悖論（Bootstrap Paradox）」：在檔案系統損壞且硬碟已滿的極端情況下，動態創建目錄（需要分配 Inode 和 Block）是極度危險且可能失敗的，因此必須在格式化時就「預先佔用」空間。
編輯觀點：/lost+found 的設計是防禦性系統工程（Defensive Systems Engineering）的經典範例。它告訴我們：在設計容災與恢復系統時，絕不能依賴系統正常運作時的 API，而必須在系統最健康的時候，為最壞的崩潰場景預留好專用的、物理隔離的資源。
Powering up a module from the IBM 604: an electronic calculator from 1948
點亮 1948 年的記憶：逆向工程 IBM 604 真空管模組
硬體歷史學家 Ken Shirriff 最近成功復原並逆向工程了 1948 年 IBM 604 電子計算打孔機中的「可插拔真空管模組」，並使用其中的閘流管（Thyratron）實際驅動了現代燈泡！
這台 1948 年的龐然大物包含約 1250 支真空管，主機重達 1310 磅，功耗高達 5.5 kW（光是單個模組的燈絲加熱器就需要 3.75W）。其中使用的閘流管（Thyratron 2D21）內部充有萬分之一大氣壓力的氙氣（Xenon），運作原理類似於現代的矽控整流器（SCR），一旦觸發就會持續導通，直到物理切斷電源。
IBM 604 的偉大之處在於其開創性的「三維立體封裝」專利設計。它將真空管插座、電阻、電容整合在一個 9-pin 的可插拔單元中，這正是現代模組化維護的先河。
商業維護的本質：降低平均修復時間
有網友指出，早期真空管計算機（如 ENIAC）的商業化瓶頸在於極高的維護成本。IBM 透過設計標準化的單管可插拔模組，讓穿著白襯衫、打領帶的客服工程師（CE）能在幾分鐘內定位並更換故障模組，大幅降低了企業客戶的停機時間。此外，IBM 604 能減少真空管數量的關鍵，在於其布林邏輯大部分是由便宜的鍺二極體（Germanium Diodes）完成，真空管僅用於信號放大與驅動。
編輯觀點：1948 年的 IBM 604 模組化設計，本質上就是現代「熱插拔伺服器刀鋒（Hot-swappable Blades）」與「微服務（Microservices）」的物理前身。它證明了：當底層組件的平均故障間隔時間（MTBF）極短時，系統架構的設計核心必須從「避免故障」轉向「極速容錯與更換」。
Crosstalk-Solutions / project-nomad
Project N.O.M.A.D：打造你的離線末日生存電腦
在無網路、無電力的極端環境下，你該如何獲取資訊與工具？開源專案 Project N.O.M.A.D（離線生存電腦）正是為此而生。
這是一個自包含（Self-contained）、完全離線的生存運算平台。它旨在低功耗的邊緣設備（如 Raspberry Pi 或加固型軍規筆電）上運行，整合了離線地圖、應急通信協議、醫療/農業/機械知識庫，甚至還打包了能在本地運行的輕量化 AI 模型（Local LLM）。
這個專案在 GitHub 上獲得關注，反映了開發者社群中「末日準備狂技術（Prepper Tech）」與去中心化思維的抬頭。社群討論多集中於如何在不依賴 AWS 或 Cloudflare 等雲端巨頭的情況下，將人類文明的關鍵知識庫（如 Wikipedia 離線版 Kiwix）進行極致壓縮與本地檢索。
編輯觀點：Project N.O.M.A.D 代表了從「Cloud-First」向「Zero-Connectivity-First」的極端架構轉移。當我們習慣了無限制的 API 與雲端算力時，如何設計一個在完全斷網、頻寬為零、電力受限的環境下依然具有高可用性的系統，將是未來災備設計的重要課題。
NousResearch / hermes-agent
Hermes Agent：與你共同成長的「有狀態」AI 智能體
由知名開源 AI 團隊 NousResearch 推出的 hermes-agent，主打「能與用戶共同成長」的適應性、狀態保存型 AI Agent 架構。
與傳統單次對話、無狀態（Stateless）的 AI 不同，hermes-agent 專注於智能體工作流（Agentic Workflows），具備動態記憶體管理、工具調用（Tool Calling）以及基於反饋的自我進化機制（Self-improvement loop）。
目前 LangChain、AutoGPT 等第一代 Agent 框架因過度抽象和臃腫而飽受開發者批評。社群對 NousResearch 的加入感到非常興奮，期待 hermes-agent 能提供更輕量、更貼近開源模型（如 Llama 3, Mistral）底層特性的原生 Agent 實現。
編輯觀點：「會成長的 Agent」意味著 AI 伴侶將擁有持續性的狀態與個性化記憶。這將改變未來的軟體開發範式：未來的應用程式可能不再是由開發者編寫死邏輯，而是由一個不斷適應使用者行為的 Agent 網絡動態生成與執行。