標籤彙整: news

嘗試整理 FreshRSS 的資訊，整理一份推薦閱讀摘要

發佈留言

嘗試透過資料來源、整理一些重要的資訊，整理範圍 2026-03-03 ~ 2026-03-10。這是第一篇整理的內容，流程是把平時訂閱的 RSS 內容（FreshRSS）挑選幾個分類產生一個列表，再丟到自行架設的 OpenWebUI 做文字編輯輸出。

看起來好像真的有這麼一回事，我就先來試試這樣的流程幾週看看！

本週必讀

  • 甲骨文正以未來的債務，建造昨天的資料中心 [產業]
    重點：OpenAI 終止與甲骨文擴建德州 Stargate 資料中心計畫，凸顯 AI 晶片迭代速度已超越傳統資料中心建設週期。
    推薦理由：這不只是單一合作案告吹，而是揭示「算力軍備競賽」的核心風險——當硬體世代更替快於基建折舊周期，資本支出與債務結構將成為科技巨頭的潛在壓力點，對整個 AI 基礎設施投資邏輯具指標意義。
  • ShinyHunters claims more high-profile victims in latest Salesforce customers data heist [安全]
    重點：駭客組織 ShinyHunters 宣稱入侵約 100 家知名企業並竊取 Salesforce 客戶資料，甚至濫用 Mandiant 開源工具發動攻擊。
    推薦理由：攻擊不僅波及供應鏈核心 SaaS 平台，還涉及開源安全工具被反向利用，對企業雲端依賴與開源治理帶來雙重警訊，是本週最具實質衝擊的資安事件。
  • 解鎖 Python 核心：移除全域直譯器鎖（GIL）後的硬體利用率與能耗影響 [技術]
    重點：研究比較標準版與無 GIL Python 在多種工作負載下的效能與能耗，指出移除 GIL 並非全面提升，需視場景權衡。
    推薦理由：無 GIL 是 Python 近年最重大的變革之一，這篇提供實證數據而非口號式討論，對後端服務、科學運算與基礎設施選型都有實際參考價值。
  • 根據自身憲章，OpenAI 應退出這場競賽 [產業]
    重點：作者指出 OpenAI 的商業化與競逐 AGI 的行為，可能已偏離其原始憲章中對安全與公共利益的承諾。
    推薦理由：在 AI 競賽白熱化之際，這篇文章從組織治理與價值承諾切入，提出尖銳質疑，有助理解 AI 巨頭在理想與資本壓力間的張力。
  • Bluesky 的新篇章 [市場]
    重點：Bluesky 用戶突破 4,000 萬後，CEO 交棒並引入具規模化經驗的高管接手營運。
    推薦理由：去中心化社交平台進入「規模化治理」階段，創辦人轉型與專業經理人進場，象徵產品理想走向商業現實，值得觀察其是否能避免傳統社群平台的路徑依賴。

選讀

本週關鍵字

算力基建風險、無 GIL Python、AI 治理張力、雲端供應鏈安全、即時生成模型

本週的共同主題是：當 AI 從模型競賽走向基建、治理與長期維運，真正的挑戰才正要開始。

Stalwart 開源郵件伺服器即將發佈 1.0 版本，成為第一個實作 JMAP 協議的郵件伺服器

發佈留言

雖然現在已經很少人自架郵件伺服器了，但是一款開源的郵件伺服器軟體 Stalwart 完成了 JMAP 的實作！這篇文章介紹了 Stalwart Labs 一個重大里程碑：完成 JMAP 用於行事曆、聯絡人、地址簿、檔案儲存及分享的完整實作，使 Stalwart 成為首個支援完整 JMAP 協作協議的郵件伺服器。

完整的文章內容： https://stalw.art/blog/jmap-collaboration

  • 新一代協議：JMAP 包括用於行事曆、聯絡人、檔案儲存及分享的新協議，目標取代傳統的 WebDAV 技術如 CalDAV 和 CardDAV，並引入 JSCalendar 和 JSContact 作為 iCalendar 和 vCard 的繼承者。這些新標準提供一致且優雅的生態系統。
  • 舊技術的限制：傳統的 WebDAV 及其延伸技術因 XML 設計的複雜性，導致實施困難且互通性差。iCalendar 和 vCard 的技術負擔也使這些格式難以維護。
  • JMAP 的現代解決方案：JMAP 協議以 JSON 為基礎，透過 HTTPS 提供高效且清晰的 API，用於郵件、行事曆、聯絡人及檔案分享，簡化協作技術實作，提升可讀性與解析效率。這次發佈不僅帶來新功能，更改變了群件協議的設計和實作方式，對開發者和組織而言意味著更簡單、更少的互通性問題，並加速創新。
  • 客戶端支援與生態系統：目前已有幾個專案（如 Mailtemi、Parula 和 OpenCloud）在開發 JMAP 的客戶端實作，預期 JMAP 會快速被採用。
  • 感謝及未來展望：感謝 NLNet 對 JMAP 開發的支持。Stalwart 開發團隊將致力於性能優化和增強功能，目標在未來幾個月內推出正式的 1.0.0 版本，樹立開放且現代化的郵件通信伺服器新標準。

前幾個月有把 Stalwart 架起來，很難想像在此刻架一台郵件伺服器能有多難，但再往前跨一步出去後發現，很多雲端服務如 AWS、DigitalOcean 將 25, 465, 587 連線埠給關閉或不提供 IP 反向解析1（PTR/RDNS），即使架好了也無法與其他郵件伺服器溝通，或許當越來越多人使用 Stalwart 後這個問題有可能會被克服，我很期待可以自己架設郵件伺服器！

  1. 設定 IP 反向解析（PTR/RDNS）有助於驗證發信伺服器的真實身份，提高郵件的可信度並減少被標記為垃圾郵件的風險，確保郵件順利地送達收件者的主要信箱，提升整體郵件的可交付性。 ↩︎

開源自架服務 immich 被 Google 安全瀏覽誤判為「危險」網站

發佈留言

Google 提供一項名為「安全瀏覽（Google Safe Browsing）」的服務，用來檢測網站是否存在惡意軟體、不受歡迎的軟體或從事某種社交工程行為。不過，對於如何判斷網站是否「危險」的細節仍然不太清楚。這導致使用 Google 安全瀏覽服務的瀏覽器（如 Chrome 和 Firefox）會自動警告使用者，除非少數人忽視這樣的警告，否則這些網站幾乎無法被訪問。

而近期一款開源自架的照片、影片管理軟體 immich，因為自家的 Demo 網站被標記為危險，影響到整個網域的使用。immich 解釋如何透過 Google 的申訴管道提出恢復，但恢復之後所產生的頁面也再次被標記危險。結論提到目前像是可自架服務的 NextCloud、n8n、Jellyfin …… 等，都會有這樣發生的可能，對於開源、自架環境是一個潛在的阻礙。

有興趣可以閱讀完整內容：https://immich.app/blog/google-flags-immich-as-dangerous

查了一下 Google Safe Browsing 沒有公開名單讓人查閱哪些網站被放入，只有一個查詢的網站可以使用，雖然我自己不是用 Chrome，但其他使用者以目前 Chrome 的市占率，其影響不容小覷。

這樣的審查模式與臺灣之前討論 RPZ 類似，一樣也是不公佈名單，但 Google 比較麻煩的部分是評判標準不明，然後又常常誤判，申訴後也不知道何時可以恢復，如果真的遇到誤判，還真的不知道該如何面對。

之前作過一個內部系統，也是遇到這樣的問題，想說臨時換一個網域應該可以解決，但又馬上被判定「危險」，最後只能請使用者關閉「安全瀏覽」檢查的功能，還好不是面對外部的使用者，可以這樣一一通知暫時解法使用。