Log for Ubuntu 台灣社群
我的家用伺服器之死與重生 （★ 68 分）
文章記錄一台 Raspberry Pi 4B 家用伺服器的故障與重建過程。伺服器連續運作多年後，Tremotesf 的 Torrent 清單、SMB（Server Message Block，網路檔案共用協定）掛載與 SSH（Secure Shell，安全殼層）連線同時失效；重新開機時，現行與上一個 NixOS（以宣告式設定管理系統的 Linux 發行版）版本都在載入核心後停滯。作者以 fsck（檔案系統檢查工具）修復大量錯誤，但拔插微型 SD 卡後問題再次出現，判斷記憶卡已損壞，數日前整棟建築停電只是最後一擊。由於重要資料存放在外接硬碟，NixOS 設定檔也幾乎涵蓋整套系統，實際遺失的只有 Torrent 檔案與幾個服務的快取；Immich 的相片資料則有外接硬碟備份，沒有受到影響。
重建時，作者把重點放在減少微型 SD 卡的寫入、讓外接硬碟具備備援能力，以及完整備份。交換空間（swap）改用 zram（在記憶體中建立壓縮區塊裝置的 Linux 功能），暫存目錄則使用 tmpfs（以記憶體作為磁碟的檔案系統），systemd 日誌也改為只寫入記憶體；根檔案系統則停用 atime，避免每次讀取檔案都產生額外寫入。資料方面，他回收兩顆老舊的 500 GB 與 320 GB 硬碟，以 btrfs（支援儲存池與子磁碟區的 Linux 檔案系統）組成 RAID1（鏡像複寫），並為每個服務建立獨立子磁碟區，再透過自製 Nix 模組宣告掛載關係。之後又加入一顆 1 TB 硬碟，計畫再加入另一顆 500 GB 硬碟。
備份採用 restic 備份工具，針對 Immich 保存相片資料，排除可重新產生的影片編碼結果與縮圖；由於暫時缺乏足夠硬碟，作者先以 S3 物件儲存空間及複寫作為替代方案。多個服務共用 Linux ISO 檔案時，則透過 media 群組與 setgid 權限，讓新建立的檔案自動繼承正確群組。硬碟監測目前只做到定期執行 btrfs scrub 檢查錯誤，未來可能加入 S.M.A.R.T.（Self-Monitoring, Analysis and Reporting Technology，自我監測、分析與回報技術）、smartd、Prometheus 與 Grafana。最後，他換上宣稱具高耐用度的 64 GB 微型 SD 卡與 UPS（不斷電系統），利用 NixOS 宣告式設定直接建立可寫入記憶卡的系統映像檔，完成重建後，伺服器及時恢復 Navidrome 音樂服務，讓他能在假期開車途中聽音樂。
Hacker News 的討論大致認同，讓微型 SD 卡長時間承擔 24/7 根檔案系統與大量寫入，是 Raspberry Pi 家用伺服器的主要弱點；有人一年多就把 SD 卡寫到幾乎無法使用，也有人在關閉 swap、控制寫入量後連續使用五年仍無故障，因此實際壽命會受到寫入負載、供電品質、散熱與硬體個體差異影響。留言者普遍建議改用 USB 3 SSD、SATA SSD 或 NVMe，讓系統從外接磁碟開機，或將根檔案系統設為唯讀；Raspberry Pi 5 的 PCIe 插槽、Compute Module 的內建快閃記憶體，以及較新的單板電腦也被視為替代方案。另有不少人推薦二手 Dell OptiPlex、Lenovo ThinkCentre 或 HP EliteDesk 等商用小型電腦。
討論也提醒，硬體監測不一定能預告故障：部分硬碟能在超過十萬小時後仍持續運作，但電源供應器、記憶體與硬碟也可能突然失效，SMART 資訊並非萬無一失。因此，多數留言認為可靠的備份、可快速替換的系統磁碟與備用零件，比精準預測硬體壽命更實際；這也與作者把系統設定、服務資料和備份分開處理的重建方向一致。
👥 38 則討論、評論 💬
https://news.ycombinator.com/item?id=48966769
文章記錄一台 Raspberry Pi 4B 家用伺服器的故障與重建過程。伺服器連續運作多年後，Tremotesf 的 Torrent 清單、SMB（Server Message Block，網路檔案共用協定）掛載與 SSH（Secure Shell，安全殼層）連線同時失效；重新開機時，現行與上一個 NixOS（以宣告式設定管理系統的 Linux 發行版）版本都在載入核心後停滯。作者以 fsck（檔案系統檢查工具）修復大量錯誤，但拔插微型 SD 卡後問題再次出現，判斷記憶卡已損壞，數日前整棟建築停電只是最後一擊。由於重要資料存放在外接硬碟，NixOS 設定檔也幾乎涵蓋整套系統，實際遺失的只有 Torrent 檔案與幾個服務的快取；Immich 的相片資料則有外接硬碟備份，沒有受到影響。
重建時，作者把重點放在減少微型 SD 卡的寫入、讓外接硬碟具備備援能力，以及完整備份。交換空間（swap）改用 zram（在記憶體中建立壓縮區塊裝置的 Linux 功能），暫存目錄則使用 tmpfs（以記憶體作為磁碟的檔案系統），systemd 日誌也改為只寫入記憶體；根檔案系統則停用 atime，避免每次讀取檔案都產生額外寫入。資料方面，他回收兩顆老舊的 500 GB 與 320 GB 硬碟，以 btrfs（支援儲存池與子磁碟區的 Linux 檔案系統）組成 RAID1（鏡像複寫），並為每個服務建立獨立子磁碟區，再透過自製 Nix 模組宣告掛載關係。之後又加入一顆 1 TB 硬碟，計畫再加入另一顆 500 GB 硬碟。
備份採用 restic 備份工具，針對 Immich 保存相片資料，排除可重新產生的影片編碼結果與縮圖；由於暫時缺乏足夠硬碟，作者先以 S3 物件儲存空間及複寫作為替代方案。多個服務共用 Linux ISO 檔案時，則透過 media 群組與 setgid 權限，讓新建立的檔案自動繼承正確群組。硬碟監測目前只做到定期執行 btrfs scrub 檢查錯誤，未來可能加入 S.M.A.R.T.（Self-Monitoring, Analysis and Reporting Technology，自我監測、分析與回報技術）、smartd、Prometheus 與 Grafana。最後，他換上宣稱具高耐用度的 64 GB 微型 SD 卡與 UPS（不斷電系統），利用 NixOS 宣告式設定直接建立可寫入記憶卡的系統映像檔，完成重建後，伺服器及時恢復 Navidrome 音樂服務，讓他能在假期開車途中聽音樂。
Hacker News 的討論大致認同，讓微型 SD 卡長時間承擔 24/7 根檔案系統與大量寫入，是 Raspberry Pi 家用伺服器的主要弱點；有人一年多就把 SD 卡寫到幾乎無法使用，也有人在關閉 swap、控制寫入量後連續使用五年仍無故障，因此實際壽命會受到寫入負載、供電品質、散熱與硬體個體差異影響。留言者普遍建議改用 USB 3 SSD、SATA SSD 或 NVMe，讓系統從外接磁碟開機，或將根檔案系統設為唯讀；Raspberry Pi 5 的 PCIe 插槽、Compute Module 的內建快閃記憶體，以及較新的單板電腦也被視為替代方案。另有不少人推薦二手 Dell OptiPlex、Lenovo ThinkCentre 或 HP EliteDesk 等商用小型電腦。
討論也提醒，硬體監測不一定能預告故障：部分硬碟能在超過十萬小時後仍持續運作，但電源供應器、記憶體與硬碟也可能突然失效，SMART 資訊並非萬無一失。因此，多數留言認為可靠的備份、可快速替換的系統磁碟與備用零件，比精準預測硬體壽命更實際；這也與作者把系統設定、服務資料和備份分開處理的重建方向一致。
👥 38 則討論、評論 💬
https://news.ycombinator.com/item?id=48966769
最後一項 MPEG-4 Visual 專利已到期 （★ 168 分）
MPEG-4 是由動態影像專家小組（Moving Picture Experts Group, MPEG）制定的多媒體標準；其中 MPEG-4 Part 2 的最後一項已知專利，於 2026 年 7 月 19 日在巴西到期。美國與歐盟相關專利早已在近年陸續失效，僅剩巴西專利 BRPI0109962B1「隨時間連續影像的影像資料儲存與處理方法」仍然有效。VIA Licensing Alliance 已確認，這是最後一項 MPEG-4 Visual 專利，意味著這套廣泛使用的視訊技術終於不再受到這項專利限制。
討論中首先有人指出，MPEG-4 Part 2 所對應的主要是 MPEG-4 ASP（Advanced Simple Profile），也就是 Xvid 與 DivX 等早期視訊編碼格式，而不是常被混淆的 H.264／MPEG-4 AVC。這項區分很重要：最後一項 MPEG-4 Part 2 專利到期，並不代表 H.264、H.265 或 H.266 的所有專利也同時失效；有人補充，該巴西專利曾被 VIA Licensing 列為多個 MPEG 視訊標準的必要專利，包括 AVC／H.264、HEVC／H.265、VVC／H.266，以及 SMPTE 制定的 VC-1。
不少讀者期待專利障礙消失後，開放原始碼專案能更放心地加入 MPEG-4 編碼功能，也有人以 Xvid、DivX 在 DVD 播放器與早期網路影音中的普及，回顧這項格式的歷史地位。不過，討論也提醒 H.264 仍會有很長的使用週期：它具備廣泛的硬體與軟體支援，編碼和解碼所需的計算量相對低，畫質對多數用途也已足夠，因此即使 H.265、H.266 與 AV1 能以較高壓縮效率節省頻寬，舊格式仍可能長期作為相容性備援。
讀者同時指出，H.264 的專利不會因這次 MPEG-4 Part 2 到期而立即全部解除，部分專利可能要到 2030 年左右才在全球範圍內失效，且不同設定檔（profile）與更新版本的期限各異。相較之下，AV1 被視為較少受到專利主張影響的新格式，但其編碼與解碼複雜度、硬體加速普及度，以及同時維護多種格式的成本，仍會影響實際採用速度；整體而言，這次到期是開放影音生態的重要進展，卻不會立刻改變現有視訊格式的分布。
👥 43 則討論、評論 💬
https://news.ycombinator.com/item?id=48969635
MPEG-4 是由動態影像專家小組（Moving Picture Experts Group, MPEG）制定的多媒體標準；其中 MPEG-4 Part 2 的最後一項已知專利，於 2026 年 7 月 19 日在巴西到期。美國與歐盟相關專利早已在近年陸續失效，僅剩巴西專利 BRPI0109962B1「隨時間連續影像的影像資料儲存與處理方法」仍然有效。VIA Licensing Alliance 已確認，這是最後一項 MPEG-4 Visual 專利，意味著這套廣泛使用的視訊技術終於不再受到這項專利限制。
討論中首先有人指出，MPEG-4 Part 2 所對應的主要是 MPEG-4 ASP（Advanced Simple Profile），也就是 Xvid 與 DivX 等早期視訊編碼格式，而不是常被混淆的 H.264／MPEG-4 AVC。這項區分很重要：最後一項 MPEG-4 Part 2 專利到期，並不代表 H.264、H.265 或 H.266 的所有專利也同時失效；有人補充，該巴西專利曾被 VIA Licensing 列為多個 MPEG 視訊標準的必要專利，包括 AVC／H.264、HEVC／H.265、VVC／H.266，以及 SMPTE 制定的 VC-1。
不少讀者期待專利障礙消失後，開放原始碼專案能更放心地加入 MPEG-4 編碼功能，也有人以 Xvid、DivX 在 DVD 播放器與早期網路影音中的普及，回顧這項格式的歷史地位。不過，討論也提醒 H.264 仍會有很長的使用週期：它具備廣泛的硬體與軟體支援，編碼和解碼所需的計算量相對低，畫質對多數用途也已足夠，因此即使 H.265、H.266 與 AV1 能以較高壓縮效率節省頻寬，舊格式仍可能長期作為相容性備援。
讀者同時指出，H.264 的專利不會因這次 MPEG-4 Part 2 到期而立即全部解除，部分專利可能要到 2030 年左右才在全球範圍內失效，且不同設定檔（profile）與更新版本的期限各異。相較之下，AV1 被視為較少受到專利主張影響的新格式，但其編碼與解碼複雜度、硬體加速普及度，以及同時維護多種格式的成本，仍會影響實際採用速度；整體而言，這次到期是開放影音生態的重要進展，卻不會立刻改變現有視訊格式的分布。
👥 43 則討論、評論 💬
https://news.ycombinator.com/item?id=48969635
GCC 與 Clang 都不符合 C++ 標準 （★ 45 分）
C++ 標準規定，函式型別帶有「語言連結」（language linkage），例如 `C++` 或 `C`；即使參數與回傳值完全相同，只要語言連結不同，也應視為不同型別。這項規定是為了容納不同的呼叫慣例，避免以錯誤方式呼叫函式。文章指出，GCC 與 Clang 並未把語言連結資訊納入函式型別，因此會把 `extern "C"` 函式與一般 C++ 函式視為相同型別，導致型別判斷結果錯誤，也可能讓原本應能成立的函式多載被誤判為重複定義，觸犯一次定義規則（ODR, One Definition Rule）。
作者認為，問題未必應歸咎於 GCC 或 Clang，而是 C++ 標準本身的規定不切實際，應改成由實作自行決定。現今多數平台上的 C 與 C++ 呼叫慣例大致相同，編譯器若要完全遵循規範，可能必須把 `extern "C"` 的型別差異納入名稱修飾（name mangling），進而造成 ABI（二進位應用程式介面，Application Binary Interface）變更，破壞既有二進位檔的相容性。因此，編譯器實作者沒有太大動機改變已沿用多年的行為。
留言者指出，這類問題早在約 12 年前就曾出現在 C++ 標準委員會的議題中，但至今仍缺乏明確提案或缺陷報告（defect report）推動修正。部分討論認為，函式的呼叫慣例本來就應是型別的一部分；在 32 位元 x86 等平台上，使用錯誤呼叫慣例甚至可能破壞堆疊。也有人質疑作者把影響描述成 ABI 破壞，認為主要是原始碼層級的 API（應用程式介面，Application Programming Interface）變更；另一方則反駁，ABI 變更會迫使大量既有程式與編譯結果同步更新，衝擊更大。
更廣泛的討論集中在 C++ 的複雜性與系統程式設計的取捨。有人主張新專案可考慮 Rust、Zig 或 Odin，以減少記憶體安全與語言細節帶來的負擔；但反方認為，系統程式設計正是由呼叫慣例、硬體特性、配置器、效能與平台差異等細節構成，C++ 的彈性讓開發者能自行掌握這些取捨。Rust 與 Zig 的成熟度、GPU 開發對 C++ 生態系的依賴，以及嵌入式開發常使用不完全符合標準的 C++ 子集，也都被視為採用替代語言時必須面對的現實。整體而言，留言者一方面認同標準應提供跨編譯器的可攜性，另一方面也認為 GCC 與 Clang 的共同慣例已成為實務上不可忽視的最低相容基準。
👥 49 則討論、評論 💬
https://news.ycombinator.com/item?id=48970039
C++ 標準規定，函式型別帶有「語言連結」（language linkage），例如 `C++` 或 `C`；即使參數與回傳值完全相同，只要語言連結不同，也應視為不同型別。這項規定是為了容納不同的呼叫慣例，避免以錯誤方式呼叫函式。文章指出，GCC 與 Clang 並未把語言連結資訊納入函式型別，因此會把 `extern "C"` 函式與一般 C++ 函式視為相同型別，導致型別判斷結果錯誤，也可能讓原本應能成立的函式多載被誤判為重複定義，觸犯一次定義規則（ODR, One Definition Rule）。
作者認為，問題未必應歸咎於 GCC 或 Clang，而是 C++ 標準本身的規定不切實際，應改成由實作自行決定。現今多數平台上的 C 與 C++ 呼叫慣例大致相同，編譯器若要完全遵循規範，可能必須把 `extern "C"` 的型別差異納入名稱修飾（name mangling），進而造成 ABI（二進位應用程式介面，Application Binary Interface）變更，破壞既有二進位檔的相容性。因此，編譯器實作者沒有太大動機改變已沿用多年的行為。
留言者指出，這類問題早在約 12 年前就曾出現在 C++ 標準委員會的議題中，但至今仍缺乏明確提案或缺陷報告（defect report）推動修正。部分討論認為，函式的呼叫慣例本來就應是型別的一部分；在 32 位元 x86 等平台上，使用錯誤呼叫慣例甚至可能破壞堆疊。也有人質疑作者把影響描述成 ABI 破壞，認為主要是原始碼層級的 API（應用程式介面，Application Programming Interface）變更；另一方則反駁，ABI 變更會迫使大量既有程式與編譯結果同步更新，衝擊更大。
更廣泛的討論集中在 C++ 的複雜性與系統程式設計的取捨。有人主張新專案可考慮 Rust、Zig 或 Odin，以減少記憶體安全與語言細節帶來的負擔；但反方認為，系統程式設計正是由呼叫慣例、硬體特性、配置器、效能與平台差異等細節構成，C++ 的彈性讓開發者能自行掌握這些取捨。Rust 與 Zig 的成熟度、GPU 開發對 C++ 生態系的依賴，以及嵌入式開發常使用不完全符合標準的 C++ 子集，也都被視為採用替代語言時必須面對的現實。整體而言，留言者一方面認同標準應提供跨編譯器的可攜性，另一方面也認為 GCC 與 Clang 的共同慣例已成為實務上不可忽視的最低相容基準。
👥 49 則討論、評論 💬
https://news.ycombinator.com/item?id=48970039