Log for Ubuntu 台灣社群
我們的 Email 寄不到 500 英里以外（2002） （★ 113 分）
一位負責校園電子郵件系統的系統管理員接到統計系主任來電，對方一本正經地說系上「寄不出超過 500 miles（其實約 520 miles）」的信，還等到「蒐集到足夠資料」才報修，甚至請地理統計學者畫出可寄送半徑地圖。管理員半信半疑地實測：寄到附近城市與 400 多 miles 的目的地都正常，但一到 600 miles 左右就失敗；他也確認問題跟收件人所在地無關，而是取決於對方的郵件伺服器位置，讓這個荒謬現象變得可重現。
他檢查 Sendmail 的設定檔 sendmail.cf，內容看似正常，甚至是自己寫的版本；但用 telnet 連到 SMTP（Simple Mail Transfer Protocol，郵件傳輸協定）埠時，卻看到系統回報的是 SunOS 內建的 Sendmail 5，而非他先前統一部署的 Sendmail 8。原來外部顧問「更新系統」時升級了 SunOS，卻把 Sendmail 降版；更糟的是，升級流程保留了原本的 sendmail.cf，導致 Sendmail 5 讀到 Sendmail 8 才有的長選項名稱時直接略過，許多參數因而變成預設的 0。
關鍵參數之一是連到遠端 SMTP 伺服器的逾時時間被設為 0；在那台機器的負載條件下，等同於連線呼叫在約 3 毫秒就中止。當時校園網路是全交換式（switched）架構，封包在出校前幾乎不會碰到路由器延遲，要到 POP（Point of Presence，對外網路匯聚點）才開始經過路由器，因此「能不能在 3 毫秒內連上」主要受制於訊號以光速傳播的距離上限。作者用 `units` 換算 3 millilightseconds（毫光秒）約等於 559 miles，跟「大概 500 多 miles 就寄不出去」完美吻合，也把整起事件從笑話變成物理學與組態相容性共同導致的故障。
Hacker News 留言把這篇視為經典除錯故事，站方管理員 dang 也說經典文隔一段時間重貼很正常，還整理了多年來多次重貼的討論串與延伸話題（例如 2025 年的「今天 email 還會卡在 500 miles 嗎」）。不少人表示這故事提醒自己別先入為主、要靠驗證與拆解假設；也有人特別喜歡文中「我很確定沒開啟 `FAIL_MAIL_OVER_500_MILES`」這種反差幽默。討論串也補充作者寫過 FAQ（常見問題）回應「到底是不是真的」，並出現相似風格的硬體怪異案例：有人電腦早上不開機、放著一段時間就好，最後發現是老鼠晚上鑽進機殼尿尿造成短路、升溫風乾後才恢復；也有人看完立刻去裝 `units` 指令，親手重現距離換算的梗。
👥 13 則討論、評論 💬
https://news.ycombinator.com/item?id=46805665
一位負責校園電子郵件系統的系統管理員接到統計系主任來電，對方一本正經地說系上「寄不出超過 500 miles（其實約 520 miles）」的信，還等到「蒐集到足夠資料」才報修，甚至請地理統計學者畫出可寄送半徑地圖。管理員半信半疑地實測：寄到附近城市與 400 多 miles 的目的地都正常，但一到 600 miles 左右就失敗；他也確認問題跟收件人所在地無關，而是取決於對方的郵件伺服器位置，讓這個荒謬現象變得可重現。
他檢查 Sendmail 的設定檔 sendmail.cf，內容看似正常，甚至是自己寫的版本；但用 telnet 連到 SMTP（Simple Mail Transfer Protocol，郵件傳輸協定）埠時，卻看到系統回報的是 SunOS 內建的 Sendmail 5，而非他先前統一部署的 Sendmail 8。原來外部顧問「更新系統」時升級了 SunOS，卻把 Sendmail 降版；更糟的是，升級流程保留了原本的 sendmail.cf，導致 Sendmail 5 讀到 Sendmail 8 才有的長選項名稱時直接略過，許多參數因而變成預設的 0。
關鍵參數之一是連到遠端 SMTP 伺服器的逾時時間被設為 0；在那台機器的負載條件下，等同於連線呼叫在約 3 毫秒就中止。當時校園網路是全交換式（switched）架構，封包在出校前幾乎不會碰到路由器延遲，要到 POP（Point of Presence，對外網路匯聚點）才開始經過路由器，因此「能不能在 3 毫秒內連上」主要受制於訊號以光速傳播的距離上限。作者用 `units` 換算 3 millilightseconds（毫光秒）約等於 559 miles，跟「大概 500 多 miles 就寄不出去」完美吻合，也把整起事件從笑話變成物理學與組態相容性共同導致的故障。
Hacker News 留言把這篇視為經典除錯故事，站方管理員 dang 也說經典文隔一段時間重貼很正常，還整理了多年來多次重貼的討論串與延伸話題（例如 2025 年的「今天 email 還會卡在 500 miles 嗎」）。不少人表示這故事提醒自己別先入為主、要靠驗證與拆解假設；也有人特別喜歡文中「我很確定沒開啟 `FAIL_MAIL_OVER_500_MILES`」這種反差幽默。討論串也補充作者寫過 FAQ（常見問題）回應「到底是不是真的」，並出現相似風格的硬體怪異案例：有人電腦早上不開機、放著一段時間就好，最後發現是老鼠晚上鑽進機殼尿尿造成短路、升溫風乾後才恢復；也有人看完立刻去裝 `units` 指令，親手重現距離換算的梗。
👥 13 則討論、評論 💬
https://news.ycombinator.com/item?id=46805665
Linux kernel 社群制定 Linus Torvalds 卸任的計畫
Linux kernel 社群正式制定了一旦 Linus Torvalds 最終卸任，該如何尋找接班人的計畫。該計畫由資深核心（kernel）貢獻者 Dan Williams 起草，並在最近於東京舉行的 Linux 核心維護者高峰會上進行討論。計畫並未指定具體接班人，而是制定一套流程，在最糟或有序交接的情況下，選出一位或多位維護者接手 Linux；其中包含召開一次會議來權衡各種方案，以最大限度確保 Linux 專案的長期健康發展。一位東京的維護者開玩笑建議，像選出新教宗的秘密會議（conclave）一樣，把遴選小組鎖在房間裡，等做出決定時再放出一團白煙。此舉旨在防止「巴士係數」問題。巴士係數是指一個專案在至少失去若干關鍵成員的參與（「被巴士撞到」用來代指職涯與生活型態變動、婚育、意外傷亡等任何導致缺席的原因）就會導致專案陷入混亂、癱瘓而無法延續時，所需失去的關鍵成員數量。Linus Torvalds 目前在 Linux 專案的核心地位，意味著該專案的巴士係數為 1。現階段在 Torvalds 之後，核心社群的順位是穩定版（stable）核心維護者 Greg Kroah-Hartman。針對有人建議指定 Greg KH 為繼任者，Torvalds 回答：「問題是 Greg 並不是一直都是 Greg。在他之前是 Andrew Morton 和 Alan Cox。Greg 之後會是 Shannon 和 Steve。真正的問題在於，你必須找到一個人或一個團隊能贏得社群信任；而信任在於要有夠長的時間，讓大家了解你的工作方式，但夠長的時間並不代表要 30 年。」
https://github.com/torvalds/linux/commit/102606402f4f5943266160e263c450fdfe4dd981#diff-6c81210e8795b03502471e1435cac0763110f72b823038bd0033eb617c15ab8d
https://linux.slashdot.org/story/26/01/28/2253239/kernel-community-drafts-a-plan-for-replacing-linus-torvalds
https://github.com/torvalds/linux/commit/102606402f4f5943266160e263c450fdfe4dd981#diff-6c81210e8795b03502471e1435cac0763110f72b823038bd0033eb617c15ab8d
Linux kernel 社群正式制定了一旦 Linus Torvalds 最終卸任，該如何尋找接班人的計畫。該計畫由資深核心（kernel）貢獻者 Dan Williams 起草，並在最近於東京舉行的 Linux 核心維護者高峰會上進行討論。計畫並未指定具體接班人，而是制定一套流程，在最糟或有序交接的情況下，選出一位或多位維護者接手 Linux；其中包含召開一次會議來權衡各種方案，以最大限度確保 Linux 專案的長期健康發展。一位東京的維護者開玩笑建議，像選出新教宗的秘密會議（conclave）一樣，把遴選小組鎖在房間裡，等做出決定時再放出一團白煙。此舉旨在防止「巴士係數」問題。巴士係數是指一個專案在至少失去若干關鍵成員的參與（「被巴士撞到」用來代指職涯與生活型態變動、婚育、意外傷亡等任何導致缺席的原因）就會導致專案陷入混亂、癱瘓而無法延續時，所需失去的關鍵成員數量。Linus Torvalds 目前在 Linux 專案的核心地位，意味著該專案的巴士係數為 1。現階段在 Torvalds 之後，核心社群的順位是穩定版（stable）核心維護者 Greg Kroah-Hartman。針對有人建議指定 Greg KH 為繼任者，Torvalds 回答：「問題是 Greg 並不是一直都是 Greg。在他之前是 Andrew Morton 和 Alan Cox。Greg 之後會是 Shannon 和 Steve。真正的問題在於，你必須找到一個人或一個團隊能贏得社群信任；而信任在於要有夠長的時間，讓大家了解你的工作方式，但夠長的時間並不代表要 30 年。」
https://github.com/torvalds/linux/commit/102606402f4f5943266160e263c450fdfe4dd981#diff-6c81210e8795b03502471e1435cac0763110f72b823038bd0033eb617c15ab8d
https://linux.slashdot.org/story/26/01/28/2253239/kernel-community-drafts-a-plan-for-replacing-linus-torvalds
https://github.com/torvalds/linux/commit/102606402f4f5943266160e263c450fdfe4dd981#diff-6c81210e8795b03502471e1435cac0763110f72b823038bd0033eb617c15ab8d
GNU C Library 將從 Sourceware 遷移至由 Linux Foundation 託管的 CTI
GNU C Library「glibc」維護者 Carlos O'Donell 宣布，專案核心服務將從 Sourceware 遷移至由 Linux Foundation 託管的 Core Toolchain Infrastructure「CTI」。此舉旨在滿足 glibc 與 GNU Toolchain 目前及未來的需求，具備安全、穩固（robust）且可長期維持的基礎設施，同時兼顧開發者與社群協作創新的需求，確保基礎設施在長期內有可靠的資金支援。
https://sourceware.org/pipermail/libc-alpha/2026-January/174457.html
https://sourceware.org/pipermail/libc-alpha/2026-January/174457.html
GNU C Library「glibc」維護者 Carlos O'Donell 宣布，專案核心服務將從 Sourceware 遷移至由 Linux Foundation 託管的 Core Toolchain Infrastructure「CTI」。此舉旨在滿足 glibc 與 GNU Toolchain 目前及未來的需求，具備安全、穩固（robust）且可長期維持的基礎設施，同時兼顧開發者與社群協作創新的需求，確保基礎設施在長期內有可靠的資金支援。
https://sourceware.org/pipermail/libc-alpha/2026-January/174457.html
https://sourceware.org/pipermail/libc-alpha/2026-January/174457.html