GitHub 之前：Trac、Subversion 與 SourceForge 時代的開源協作
Armin Ronacher's Blog · 2026-04-28
Flask 的創作者 Armin Ronacher 在 Ghostty 離開 GitHub 的討論風潮中，回顧了 GitHub 出現前的開源基礎設施生態。
前 GitHub 時代的技術棧
Ronacher 和同事透過 Pocoo 集體（一個分擔伺服器費用的開發者社群）自行維護 Subversion 版本庫、Trac 問題追蹤器、郵件列表與文件/發布版本的靜態檔案服務。依賴某個函式庫意味著必須先理解它從哪裡來、如何維護、授權是否相容——成本夠高，使開發者傾向把外部程式碼直接納入（vendor）自己的儲存庫。早期的大型集中平台是 SourceForge；Bitbucket 稍後出現，吸引了不急著轉到 Git 的開發者。
GitHub 帶來的根本改變
GitHub 降低了三個門檻：創建新專案的成本、發現他人專案的難度，以及對 pull request 和議題追蹤不熟悉的開發者的上手門檻。更重要的是，GitHub 成為歸檔媒介——即使已廢棄的專案也保持可被搜尋，這是前 GitHub 時代自建基礎設施最終走向失憶的主要原因。
去中心化的弔詭
Git 和 Mercurial 哲學上是分散式版本控制系統，設計上任何節點都是平等的。然而「世界最終標準化在一個巨大的中央化服務上」，這正是當前平台遷移討論的根本矛盾——Radicle、Forgejo 等方案試圖在不失去可發現性的前提下恢復分散化。
原始來源：lucumr.pocoo.org
電子郵件有多瘋狂：從 1982 年 RFC 到 DMARC 的協定考古
samkhawase.com · 2026-04-28
電子郵件是網際網路上最古老的應用層協定之一，同時也是最複雜的。這篇文章以考古的角度拆解其歷史包袱。
協定層疊的結構
現代電子郵件系統層疊了多個互不連貫的時代標準：SMTP（RFC 5321）負責傳輸，MIME（RFC 2045–2049）處理多媒體附件，POP3/IMAP 處理收取，再加上 DKIM（RFC 6376，以私鑰簽署郵件標頭）、SPF（RFC 7208，宣告允許發送的 IP 範圍）與 DMARC（RFC 7489，整合前兩者並定義受害回報機制）。每一層都在前一層的缺陷補丁上再加補丁。
身份驗證的失敗模式
SMTP 原始設計不含任何身份驗證——MAIL FROM 中的寄件者地址完全可以偽造。SPF 只能驗證傳送 IP，無法驗證 Header From。DKIM 只驗證特定標頭，不驗證整封郵件。DMARC 需要 SPF 或 DKIM 其中一個對齊（align）Header From 才能生效，但「對齊」的定義本身也有嚴格和寬鬆兩種模式。即使三者全部通過，郵件顯示名稱（display name）仍可任意偽造，導致大量社交工程攻擊。
傳遞複雜性
決定一封郵件能否送達取決於：IP 信譽、域名信譽、垃圾郵件評分、退信率歷史、郵件列表清潔度、接收端過濾規則，以及接收端 MTA 的實作細節——這些因素跨越數十個獨立運作的系統，任何一個黑箱都無法完全掌控。
原始來源：samkhawase.com
在 2026 年使用 1978 年的 DEC VT-100 終端：RS-232、PTY 與差分渲染
nikhiljha.com · 2026-04-28
一位工程師紀錄了將 1978 年出廠的 DEC VT-100 終端機連接到現代 Linux 系統並作為日常開發工具的完整過程。
硬體規格與連接
VT-100 配備 Intel 8080 處理器、3KB RAM、CRT 顯示器與鍵盤。連接方式是透過 RS-232 標準線纜加 USB 轉換器，在 Linux 系統上顯示為 /dev/ttyUSB0。初始佈線因 RX/TX 線序接反需用示波器診斷並修正。
終端通訊協定
互動式應用依賴 ANSI 轉義序列（escape sequences）——特殊位元組序列控制游標移動與文字格式化，例如 ^[D 向左移動游標。Linux 核心以 PTY（pseudoterminal）和 TTY 抽象層管理這些設備，在 cooked mode 下負責字元回顯（echo）與訊號生成。
技術挑戰
硬體流量控制：macOS 不支援硬體流量控制，需切換至 Linux VM 才能正常運作。頻寬限制：9600 baud 的速率在處理大量轉義序列內容時吃力，需實作差分渲染器（differential renderer）追蹤螢幕狀態，最小化每次更新的資料量。字符集相容性：VT-100 只支援 ASCII，現代 OSC 序列（如終端機標題設定）在設備上顯示為可見亂碼，需要特殊的「傳統模式」迴避不支援的格式。
原始來源：nikhiljha.com
LocalSend：不需帳號的區域網路跨平台檔案傳輸——AirDrop 的開源替代
GitHub: localsend/localsend · 2026-04-28（HN 熱議）
LocalSend 是一款以 Flutter 開發的跨平台應用（iOS、Android、macOS、Windows、Linux），在本地網路上實現類 AirDrop 的裝置間直接傳輸，不依賴雲端服務，2026-04-28 在 Hacker News 獲得 718 分。
技術實作
LocalSend 使用 mDNS 進行裝置發現（服務類型 _localsend._tcp），連線後使用 HTTPS（自簽憑證）加密傳輸。每個裝置在首次啟動時生成 RSA 金鑰對，公鑰在握手時交換並顯示給使用者確認，防止中間人攻擊。傳輸協定以 HTTP REST API 為基礎，JSON 交換元資料，二進位資料以 multipart/form-data 傳輸。
設計特點
整個傳輸過程無需帳號、伺服器或網際網路連線，資料不離開本地網路。接收方需要明確接受每個傳入請求（可切換至自動接受模式）。開源授權為 MIT，程式碼庫在 GitHub 完全公開。相較 AirDrop 的 Apple 生態系封閉性，LocalSend 支援跨平台（包括 Android 到 macOS 的傳輸）成為主要吸引力。
2026 年的 GitHub 出走潮：Codeberg、Forgejo 與 Radicle 的生態現狀
jonashietala.se / Lobsters · 2026-04-28
在 Ghostty 宣布離開 GitHub 的同一天，Lobsters 上多篇文章記錄了各種從 GitHub 遷移到替代平台的實際體驗，反映出一個持續積累的社群趨勢。
主要替代平台
Codeberg：由德國非營利組織 Codeberg e.V. 運營的 Forgejo 實例，以非商業、社群治理為核心定位，提供免費的公開與私有儲存庫。HardenedBSD 也在同週宣布遷移至 Radicle——一個基於點對點協定的去中心化 Git 平台，儲存庫透過 Ed25519 公鑰標識，不依賴任何中央服務，但可發現性是當前主要限制。Forgejo（Gitea 的社群 fork）提供自託管選項，API 層面與 GitHub 相容度較高，遷移成本較低。
遷移的實際障礙
GitHub 的 CI/CD（Actions）生態是最大的遷移成本——Forgejo Actions 與 GitHub Actions 語法相容，但大量第三方 action 需要評估是否有替代。Issue 追蹤器的歷史資料可透過 API 匯出，但格式轉換需要工程投入。對多數專案而言，可發現性降低是最難量化也最難補償的代價。