Log for Ubuntu 台灣社群
GitHub Actions 發生事故 （★ 100 分）
GitHub 於 2026 年 10 月 5 日發生影響 Actions 與 Pages 的事故。GitHub Actions（GitHub 的持續整合與持續交付 CI/CD 自動化服務）最初出現效能下降，隨後確認 GitHub 託管執行器（hosted runners）派發工作與啟動工作流程發生延遲及失敗，使不同執行器組態的自動化流程無法及時開始。事故期間，部分帳號的儲存庫清單、授權與帳務頁面也無法存取。
GitHub 在當日 21:32 UTC 表示已套用緩解措施，排隊中的工作逐步清除，新工作不再延遲，並預期執行器將完全恢復；Actions 於 21:54 UTC 恢復正常，Pages 於 22:40 UTC 恢復，事故在 22:49 UTC 宣告結束。GitHub 表示將在完成後公布詳細的根本原因分析，但事件公告本身尚未交代故障成因。
Hacker News 討論普遍認為 GitHub Actions 的故障已過於頻繁，許多人甚至認為「長時間沒有事故」才值得成為新聞。有留言指出，美國、歐洲、澳洲與日本等標榜資料落地與隔離的 GitHub Enterprise Cloud 執行個體似乎同受影響，質疑這些區域部署是否仍共用關鍵單點故障。也有人注意到，事故公告提及的儲存庫清單、授權及帳務異常，未在狀態頁其他元件中清楚呈現。
不少使用者正評估替代方案，例如 GitLab、Gitea、Forgejo，或改用其他 CI 服務與自行代管執行器。有公司即使已將執行器移往外部供應商，仍因 GitHub 的派工作業未恢復而無法啟動工作；討論者因此指出，自行代管硬體只能避開 GitHub 託管執行器不足，無法避開 GitHub Actions 控制平面（control plane，負責接收工作流程並派發工作的中樞）故障。另有使用者分享，以舊硬體、Mac mini 或低價雲端主機搭配 Kubernetes（容器編排平台）與 ARC（Actions Runner Controller，管理 Actions 執行器的工具）自行建置 CI，可降低費用並縮短流程時間，但仍需設計脫離 GitHub 派工機制的備援路徑。討論也將近年 AI 輔助開發帶來的大量提交、平行開發與 CI 測試需求，視為平台負載持續攀升的可能因素之一。
👥 63 則討論、評論 💬
https://news.ycombinator.com/item?id=49969961
GitHub 於 2026 年 10 月 5 日發生影響 Actions 與 Pages 的事故。GitHub Actions（GitHub 的持續整合與持續交付 CI/CD 自動化服務）最初出現效能下降，隨後確認 GitHub 託管執行器（hosted runners）派發工作與啟動工作流程發生延遲及失敗，使不同執行器組態的自動化流程無法及時開始。事故期間，部分帳號的儲存庫清單、授權與帳務頁面也無法存取。
GitHub 在當日 21:32 UTC 表示已套用緩解措施，排隊中的工作逐步清除，新工作不再延遲，並預期執行器將完全恢復；Actions 於 21:54 UTC 恢復正常，Pages 於 22:40 UTC 恢復，事故在 22:49 UTC 宣告結束。GitHub 表示將在完成後公布詳細的根本原因分析，但事件公告本身尚未交代故障成因。
Hacker News 討論普遍認為 GitHub Actions 的故障已過於頻繁，許多人甚至認為「長時間沒有事故」才值得成為新聞。有留言指出，美國、歐洲、澳洲與日本等標榜資料落地與隔離的 GitHub Enterprise Cloud 執行個體似乎同受影響，質疑這些區域部署是否仍共用關鍵單點故障。也有人注意到，事故公告提及的儲存庫清單、授權及帳務異常，未在狀態頁其他元件中清楚呈現。
不少使用者正評估替代方案，例如 GitLab、Gitea、Forgejo，或改用其他 CI 服務與自行代管執行器。有公司即使已將執行器移往外部供應商，仍因 GitHub 的派工作業未恢復而無法啟動工作；討論者因此指出，自行代管硬體只能避開 GitHub 託管執行器不足，無法避開 GitHub Actions 控制平面（control plane，負責接收工作流程並派發工作的中樞）故障。另有使用者分享，以舊硬體、Mac mini 或低價雲端主機搭配 Kubernetes（容器編排平台）與 ARC（Actions Runner Controller，管理 Actions 執行器的工具）自行建置 CI，可降低費用並縮短流程時間，但仍需設計脫離 GitHub 派工機制的備援路徑。討論也將近年 AI 輔助開發帶來的大量提交、平行開發與 CI 測試需求，視為平台負載持續攀升的可能因素之一。
👥 63 則討論、評論 💬
https://news.ycombinator.com/item?id=49969961
Penguin Mail：適用於 Linux、以 Rust 開發並內建 AI 的開放原始碼電子郵件用戶端 （★ 100 分）
Penguin Mail 是面向 Linux 的開放原始碼電子郵件與行事曆程式，採 GPL-3.0-or-later（自由軟體授權）釋出，目前提供 x86_64 Linux 版本。它可集中管理 Gmail、Microsoft、Fastmail、iCloud、Yahoo 與其他 IMAP／POP3（收取電子郵件的通訊協定）帳號，並以 SMTP（寄信協定）寄送郵件；程式可依電子郵件地址尋找伺服器設定。主要特色包括整合收件匣、常駐系統列的背景同步與通知，以及 Google、Microsoft 與 CalDAV（日曆同步協定）行事曆的日、週、月與議程檢視，亦可整合 CardDAV（聯絡人同步協定）聯絡人。
安全與隱私是其主打重點：它可透過使用者自己的 GnuPG（金鑰管理工具）處理 OpenPGP 與 S/MIME（電子郵件簽章與加密標準），不會保管私密金鑰或要求輸入密碼片語。程式本身不設中介伺服器、不追蹤也不刊登廣告；Gmail 與 Google Calendar 直接連至 Google，Microsoft 帳號則直接連至 Microsoft Graph（微軟雲端服務 API）。其他功能還包括 Gmail 分類收件匣、延後寄送與短暫取消寄信、依網站建立 Gmail 加號別名的 Hide My Email，以及將 Gmail、Microsoft 與 Sieve（郵件過濾規則語言）規則以較易讀的方式呈現。
內建的人工智慧（AI）助理預設關閉，使用者可自行選擇透過 LM Studio 或 Ollama 在本機執行模型。助理可回答例如哪些已寄郵件尚未收到回覆、促銷郵件有哪些等問題，並列出它實際呼叫過的信箱工具；但它寄信或更改設定前會先徵求同意。這項設計讓 AI 不必將信件交由 Penguin Mail 的自有雲端處理，但延後寄送仍要求程式持續執行，包括在系統列背景執行時。
Hacker News 的回應肯定其介面外觀接近 Apple Mail，並認為 Linux 需要更多原生郵件程式選項；不過，許多人質疑剛公開約一個月便標示為 1.0 是否過早，因為電子郵件、行事曆與多帳號同步的錯誤範圍很大，往往需長時間才會浮現。反方則指出 GitHub 公開時間不等於開發時間，也不應在缺乏實證時預設程式不穩定；已有試用者認為它目前運作穩定，只是仍缺少部分攸關日常使用的功能。有人也提到，若要處理數十萬封郵件，設計與實作不可能短時間完成，並質疑既然宣稱支援 Fastmail，為何尚未採用 JMAP（新式電子郵件 API）。
實測意見指出，目前 Fastmail 帳號無法選擇寄件別名或自訂網域地址，對擁有多個別名的人是嚴重缺陷；資料夾排序、資料夾顏色與整體介面細節也仍待修整。AI 功能尤其兩極：有人認可可選用且採本機模型的作法，也期待本機大型語言模型（LLM）能依專案與往來情境自動分類郵件；另一些人則對嵌入式聊天視窗反感，偏好由命令列介面讓自己選擇的代理程式查詢郵件。討論也延伸至 GTK4／libadwaita 的選單設計，有人擔心漢堡選單不適合功能繁多的郵件程式，認為傳統多層選單列仍較有效率。
👥 45 則討論、評論 💬
https://news.ycombinator.com/item?id=49984716
Penguin Mail 是面向 Linux 的開放原始碼電子郵件與行事曆程式，採 GPL-3.0-or-later（自由軟體授權）釋出，目前提供 x86_64 Linux 版本。它可集中管理 Gmail、Microsoft、Fastmail、iCloud、Yahoo 與其他 IMAP／POP3（收取電子郵件的通訊協定）帳號，並以 SMTP（寄信協定）寄送郵件；程式可依電子郵件地址尋找伺服器設定。主要特色包括整合收件匣、常駐系統列的背景同步與通知，以及 Google、Microsoft 與 CalDAV（日曆同步協定）行事曆的日、週、月與議程檢視，亦可整合 CardDAV（聯絡人同步協定）聯絡人。
安全與隱私是其主打重點：它可透過使用者自己的 GnuPG（金鑰管理工具）處理 OpenPGP 與 S/MIME（電子郵件簽章與加密標準），不會保管私密金鑰或要求輸入密碼片語。程式本身不設中介伺服器、不追蹤也不刊登廣告；Gmail 與 Google Calendar 直接連至 Google，Microsoft 帳號則直接連至 Microsoft Graph（微軟雲端服務 API）。其他功能還包括 Gmail 分類收件匣、延後寄送與短暫取消寄信、依網站建立 Gmail 加號別名的 Hide My Email，以及將 Gmail、Microsoft 與 Sieve（郵件過濾規則語言）規則以較易讀的方式呈現。
內建的人工智慧（AI）助理預設關閉，使用者可自行選擇透過 LM Studio 或 Ollama 在本機執行模型。助理可回答例如哪些已寄郵件尚未收到回覆、促銷郵件有哪些等問題，並列出它實際呼叫過的信箱工具；但它寄信或更改設定前會先徵求同意。這項設計讓 AI 不必將信件交由 Penguin Mail 的自有雲端處理，但延後寄送仍要求程式持續執行，包括在系統列背景執行時。
Hacker News 的回應肯定其介面外觀接近 Apple Mail，並認為 Linux 需要更多原生郵件程式選項；不過，許多人質疑剛公開約一個月便標示為 1.0 是否過早，因為電子郵件、行事曆與多帳號同步的錯誤範圍很大，往往需長時間才會浮現。反方則指出 GitHub 公開時間不等於開發時間，也不應在缺乏實證時預設程式不穩定；已有試用者認為它目前運作穩定，只是仍缺少部分攸關日常使用的功能。有人也提到，若要處理數十萬封郵件，設計與實作不可能短時間完成，並質疑既然宣稱支援 Fastmail，為何尚未採用 JMAP（新式電子郵件 API）。
實測意見指出，目前 Fastmail 帳號無法選擇寄件別名或自訂網域地址，對擁有多個別名的人是嚴重缺陷；資料夾排序、資料夾顏色與整體介面細節也仍待修整。AI 功能尤其兩極：有人認可可選用且採本機模型的作法，也期待本機大型語言模型（LLM）能依專案與往來情境自動分類郵件；另一些人則對嵌入式聊天視窗反感，偏好由命令列介面讓自己選擇的代理程式查詢郵件。討論也延伸至 GTK4／libadwaita 的選單設計，有人擔心漢堡選單不適合功能繁多的郵件程式，認為傳統多層選單列仍較有效率。
👥 45 則討論、評論 💬
https://news.ycombinator.com/item?id=49984716