Log for Ubuntu 台灣社群
錯誤更正碼（ECC）與 DDR5 記憶體 （★ 69 分）
ECC（Error-Correcting Code，錯誤更正碼）記憶體可在資料送達 CPU（中央處理器）前修正記憶體錯誤。文章以漢明碼（Hamming code）為例：加入 6 個同位元可保護 32 位元資料，加入 7 個則可保護 64 位元資料；一般 DDR4（第四代雙倍資料傳輸率記憶體）ECC 模組採用 72 位元匯流排，可更正單一位元錯誤並偵測雙位元錯誤。RDIMM（Registered DIMM，具暫存緩衝的記憶體模組）能讓系統安裝更大容量、更多記憶體模組，但延遲略高；UDIMM（Unbuffered DIMM，無緩衝記憶體模組）則較常見於一般電腦。作者認為二手 ECC RDIMM 因伺服器汰換而價格低廉，反而比昂貴的 ECC UDIMM 更適合組建家用伺服器。
當同一顆 DRAM（Dynamic Random-Access Memory，動態隨機存取記憶體）晶片的多個位元同時出錯，或整顆晶片失效時，基本漢明碼可能不足以處理；IBM 將能因應單顆 DRAM 晶片故障的技術稱為 ChipKill，Dell 與 HP 則常稱為 Advanced ECC，部分系統也提供記憶體備援等功能。DDR5（第五代雙倍資料傳輸率記憶體）因記憶體單元更小、速度更快，內建了晶片內 ECC（on-die ECC），以降低晶片內部錯誤，但它不是系統層級 ECC 的替代品，無法處理記憶體模組與記憶體控制器之間的傳輸錯誤；文章作者也擔心兩層 ECC 的錯誤處理方式可能互相影響。
DDR5 將 64 位元通道拆成兩個 32 位元子通道，ECC 模組又分為 EC4 與 EC8。EC8 每個子通道有足夠的額外位元，可獨立執行完整漢明碼檢查；EC4 的實際運作方式則缺乏清楚公開資料。市場上普遍流傳 DDR5 ECC RDIMM 都是 EC8、ECC UDIMM 都是 EC4，但作者找到 EC4 RDIMM、EC8 UDIMM，以及 Dell R760 可支援兩種規格卻不能混用的案例，因此認為 EC4 是不必要的次級規格，只會增加升級時的相容性困難。現有公開研究主要仍是 Google 在 2009 年針對 DDR 與 DDR2 的研究，雲端業者可能持續進行相關測試，但成果多半受到保密協議限制，導致 DDR5 的實際可靠度缺乏公開資料。
文章引用 Mozilla 工程師根據 47 萬份自動回傳的當機報告所做的估計，指出最多 15% 的 Firefox 當機可能與記憶體硬體錯誤有關，但這項估計偏向可重現的錯誤，可能漏掉偶爾才發生的位元翻轉。作者也分享自身經驗：記憶體錯誤曾造成 Btrfs（B-tree File System，一種檔案系統）損毀與資料遺失，另一台測試虛擬機則因主機板故障而反覆產生難以追查的程式錯誤。基於這些案例，他主張 ECC 應更普及，政府甚至可透過課稅或產品規範降低非 ECC 與 DDR5 EC4 記憶體的市場優勢，並提醒重要資料不應長期放在無法使用 ECC 的筆電或手機上。
Hacker News 留言大致認同 ECC 能降低難以察覺的資料損毀，但對政府強制普及的主張分歧明顯。反對者認為遊戲電腦、一般瀏覽用途不一定值得支付 ECC 的成本，非 ECC 記憶體並非不良品，而是符合其設計用途；ECC 也不能提供絕對保護。支持者則指出，檔案系統、文件、程式碼與壓縮檔可能在多年後才暴露損毀，使用者既不容易察覺，也未必真的能以合理價格取得 ECC 選項，因此這不只是個人承擔的成本。留言也提到 ECC 模組常比一般記憶體更慢、更貴，超頻記憶體雖可能正常運作，卻缺乏 CPU 與記憶體廠商對穩定性的保證。
社群中較具共識的技術觀點是，光有晶片內 ECC 並不足夠，還需要涵蓋 CPU 記憶體控制器、模組與 DRAM 的端對端 ECC，以及能讓作業系統（OS）取得錯誤紀錄的回報機制；目前 DDR5 晶片內 ECC 的錯誤次數通常不會回報給 OS，有人因此提出 IBECC（In-Band ECC，利用記憶體區域攜帶校驗資訊的機制）作為替代方案。留言也指出，宇宙射線、插槽接觸不良、電氣雜訊、接點氧化、長期老化與電源供應器故障都可能造成錯誤，ECC 的實際價值之一正是協助辨識正在劣化的記憶體模組。另有留言推測，DDR5 晶片內 ECC 即使把雙位元錯誤誤更正成三位元錯誤，系統層級 ECC 的設計可能仍會將其判定為不可更正，但目前缺乏權威公開資料確認這種保護確實成立。
👥 46 則討論、評論 💬
https://news.ycombinator.com/item?id=48969530
ECC（Error-Correcting Code，錯誤更正碼）記憶體可在資料送達 CPU（中央處理器）前修正記憶體錯誤。文章以漢明碼（Hamming code）為例：加入 6 個同位元可保護 32 位元資料，加入 7 個則可保護 64 位元資料；一般 DDR4（第四代雙倍資料傳輸率記憶體）ECC 模組採用 72 位元匯流排，可更正單一位元錯誤並偵測雙位元錯誤。RDIMM（Registered DIMM，具暫存緩衝的記憶體模組）能讓系統安裝更大容量、更多記憶體模組，但延遲略高；UDIMM（Unbuffered DIMM，無緩衝記憶體模組）則較常見於一般電腦。作者認為二手 ECC RDIMM 因伺服器汰換而價格低廉，反而比昂貴的 ECC UDIMM 更適合組建家用伺服器。
當同一顆 DRAM（Dynamic Random-Access Memory，動態隨機存取記憶體）晶片的多個位元同時出錯，或整顆晶片失效時，基本漢明碼可能不足以處理；IBM 將能因應單顆 DRAM 晶片故障的技術稱為 ChipKill，Dell 與 HP 則常稱為 Advanced ECC，部分系統也提供記憶體備援等功能。DDR5（第五代雙倍資料傳輸率記憶體）因記憶體單元更小、速度更快，內建了晶片內 ECC（on-die ECC），以降低晶片內部錯誤，但它不是系統層級 ECC 的替代品，無法處理記憶體模組與記憶體控制器之間的傳輸錯誤；文章作者也擔心兩層 ECC 的錯誤處理方式可能互相影響。
DDR5 將 64 位元通道拆成兩個 32 位元子通道，ECC 模組又分為 EC4 與 EC8。EC8 每個子通道有足夠的額外位元，可獨立執行完整漢明碼檢查；EC4 的實際運作方式則缺乏清楚公開資料。市場上普遍流傳 DDR5 ECC RDIMM 都是 EC8、ECC UDIMM 都是 EC4，但作者找到 EC4 RDIMM、EC8 UDIMM，以及 Dell R760 可支援兩種規格卻不能混用的案例，因此認為 EC4 是不必要的次級規格，只會增加升級時的相容性困難。現有公開研究主要仍是 Google 在 2009 年針對 DDR 與 DDR2 的研究，雲端業者可能持續進行相關測試，但成果多半受到保密協議限制，導致 DDR5 的實際可靠度缺乏公開資料。
文章引用 Mozilla 工程師根據 47 萬份自動回傳的當機報告所做的估計，指出最多 15% 的 Firefox 當機可能與記憶體硬體錯誤有關，但這項估計偏向可重現的錯誤，可能漏掉偶爾才發生的位元翻轉。作者也分享自身經驗：記憶體錯誤曾造成 Btrfs（B-tree File System，一種檔案系統）損毀與資料遺失，另一台測試虛擬機則因主機板故障而反覆產生難以追查的程式錯誤。基於這些案例，他主張 ECC 應更普及，政府甚至可透過課稅或產品規範降低非 ECC 與 DDR5 EC4 記憶體的市場優勢，並提醒重要資料不應長期放在無法使用 ECC 的筆電或手機上。
Hacker News 留言大致認同 ECC 能降低難以察覺的資料損毀，但對政府強制普及的主張分歧明顯。反對者認為遊戲電腦、一般瀏覽用途不一定值得支付 ECC 的成本，非 ECC 記憶體並非不良品，而是符合其設計用途；ECC 也不能提供絕對保護。支持者則指出，檔案系統、文件、程式碼與壓縮檔可能在多年後才暴露損毀，使用者既不容易察覺，也未必真的能以合理價格取得 ECC 選項，因此這不只是個人承擔的成本。留言也提到 ECC 模組常比一般記憶體更慢、更貴，超頻記憶體雖可能正常運作，卻缺乏 CPU 與記憶體廠商對穩定性的保證。
社群中較具共識的技術觀點是，光有晶片內 ECC 並不足夠，還需要涵蓋 CPU 記憶體控制器、模組與 DRAM 的端對端 ECC，以及能讓作業系統（OS）取得錯誤紀錄的回報機制；目前 DDR5 晶片內 ECC 的錯誤次數通常不會回報給 OS，有人因此提出 IBECC（In-Band ECC，利用記憶體區域攜帶校驗資訊的機制）作為替代方案。留言也指出，宇宙射線、插槽接觸不良、電氣雜訊、接點氧化、長期老化與電源供應器故障都可能造成錯誤，ECC 的實際價值之一正是協助辨識正在劣化的記憶體模組。另有留言推測，DDR5 晶片內 ECC 即使把雙位元錯誤誤更正成三位元錯誤，系統層級 ECC 的設計可能仍會將其判定為不可更正，但目前缺乏權威公開資料確認這種保護確實成立。
👥 46 則討論、評論 💬
https://news.ycombinator.com/item?id=48969530
Jellyfin 創辦人 Andrew 離開團隊 （★ 102 分）
Jellyfin 團隊宣布，Anthony 與 Joshua 已決定離開專案，前者卸下核心團隊成員職務，後者則辭去專案負責人一職；創辦人 Andrew 也已於前一週五辭任。團隊表示，專案將交由多年來持續推動 Jellyfin 的其餘成員接手。Joshua 說，長期投入已造成嚴重倦怠，他無法再提供職務所需的時間與心力，為了心理健康而選擇退下。
Joshua 回顧，Jellyfin 創立之初只預期服務數百到數千名使用者，如今經過約 7 年半，已成為自由／開放原始碼軟體（FLOSS）領域的重要媒體伺服器，被視為 Plex 的替代方案，服務數百萬名伺服器管理者及更多一般使用者。他認為，Jellyfin 證明了 FLOSS 產品確實有需求，也希望團隊能延續專案的理念與程式碼。Anthony 則表示，自己近年主要處理後端及 App Store 等事務，但生活重心已改變，難以持續投入大量空閒時間；他承諾協助平順交接，即使過程需要一年也願意配合。
Hacker News 上的整體反應正面，多數留言感謝三位長期維護者，並樂見交接過程和平。不過，Jellyfin 的實際使用體驗評價不一：有人在 Synology 網路附加儲存裝置（NAS）上以 Docker 容器執行時，遇到啟動緩慢、媒體資料快取時間過長、用戶端不穩定、伺服器意外當機或登入問題；也有人在 N100 迷你電腦、舊電競電腦或較新的 NAS 上長期穩定使用，認為近年版本已有改善。部分使用者特別指出，Jellyfin 的伺服器本身表現不錯，但不同平台的用戶端品質仍有落差。
討論也集中比較 Jellyfin 與 Plex 的取捨。Plex 的優勢包括跨平台用戶端、媒體索引、觀看紀錄、字幕收集、直播錄影、較簡單的介面，以及透過 HTTPS 和中介轉接功能在外部網路存取家中媒體；Jellyfin 則受到偏好自架媒體庫、沒有廣告或自動播放預告片的使用者喜愛。有人批評 Plex 日益把重心轉向串流服務，且新推出的終身 Plex Pass 售價提高到 750 美元，與自架媒體的理念相悖；也有留言指出，Plex 並非開放原始碼軟體，部分使用者可能因其與 Kodi 的關係而產生混淆。最後，Jellyfin 自稱是最主要的 FLOSS 媒體伺服器，也有人要求提出與 Kodi 等專案比較的安裝量依據；另有一則較具爭議的匿名留言，指控官方空間對第三方用戶端、外掛程式與主題過於排斥，顯示專案治理氣氛仍存在不同看法。
👥 46 則討論、評論 💬
https://news.ycombinator.com/item?id=48986091
Jellyfin 團隊宣布，Anthony 與 Joshua 已決定離開專案，前者卸下核心團隊成員職務，後者則辭去專案負責人一職；創辦人 Andrew 也已於前一週五辭任。團隊表示，專案將交由多年來持續推動 Jellyfin 的其餘成員接手。Joshua 說，長期投入已造成嚴重倦怠，他無法再提供職務所需的時間與心力，為了心理健康而選擇退下。
Joshua 回顧，Jellyfin 創立之初只預期服務數百到數千名使用者，如今經過約 7 年半，已成為自由／開放原始碼軟體（FLOSS）領域的重要媒體伺服器，被視為 Plex 的替代方案，服務數百萬名伺服器管理者及更多一般使用者。他認為，Jellyfin 證明了 FLOSS 產品確實有需求，也希望團隊能延續專案的理念與程式碼。Anthony 則表示，自己近年主要處理後端及 App Store 等事務，但生活重心已改變，難以持續投入大量空閒時間；他承諾協助平順交接，即使過程需要一年也願意配合。
Hacker News 上的整體反應正面，多數留言感謝三位長期維護者，並樂見交接過程和平。不過，Jellyfin 的實際使用體驗評價不一：有人在 Synology 網路附加儲存裝置（NAS）上以 Docker 容器執行時，遇到啟動緩慢、媒體資料快取時間過長、用戶端不穩定、伺服器意外當機或登入問題；也有人在 N100 迷你電腦、舊電競電腦或較新的 NAS 上長期穩定使用，認為近年版本已有改善。部分使用者特別指出，Jellyfin 的伺服器本身表現不錯，但不同平台的用戶端品質仍有落差。
討論也集中比較 Jellyfin 與 Plex 的取捨。Plex 的優勢包括跨平台用戶端、媒體索引、觀看紀錄、字幕收集、直播錄影、較簡單的介面，以及透過 HTTPS 和中介轉接功能在外部網路存取家中媒體；Jellyfin 則受到偏好自架媒體庫、沒有廣告或自動播放預告片的使用者喜愛。有人批評 Plex 日益把重心轉向串流服務，且新推出的終身 Plex Pass 售價提高到 750 美元，與自架媒體的理念相悖；也有留言指出，Plex 並非開放原始碼軟體，部分使用者可能因其與 Kodi 的關係而產生混淆。最後，Jellyfin 自稱是最主要的 FLOSS 媒體伺服器，也有人要求提出與 Kodi 等專案比較的安裝量依據；另有一則較具爭議的匿名留言，指控官方空間對第三方用戶端、外掛程式與主題過於排斥，顯示專案治理氣氛仍存在不同看法。
👥 46 則討論、評論 💬
https://news.ycombinator.com/item?id=48986091