Log for Ubuntu 台灣社群
HP 復刻推出經典程式設計計算機：HP-16C （★ 103 分）
HP 16c Collector’s Edition 是經典程式設計計算機 HP 16c 的復刻收藏版，主打相隔 35 年後回歸。它延續原版的橫式外觀、按鍵配置與 RPN（Reverse Polish Notation，逆波蘭表示法）輸入邏輯，面向程式設計、電腦科學、邏輯設計與工程使用情境，同時加入現代化改良，官方稱效能最高可達原版 100 倍。
功能上，這款計算機保留 HP 16c 的核心特色：可在 HEX、DEC、OCT、BIN 等進位模式間切換，支援整數運算、位元運算、邏輯測試、進位轉換，以及 1 至 64 bit 可調字長。它也支援浮點運算與按鍵序列程式設計，包含條件分支、副程式、標籤與旗標等功能。硬體規格包括 99 個記憶暫存器、203 B 程式記憶體、1 行 10 字元七段式 LCD、2 顆 CR2032 電池、5 分鐘自動關機，並新增程式儲存與讀取功能。預購優惠到 2026 年 7 月 31 日止，討論中有人提到早鳥價約 117 美元。
Hacker News 討論多半帶有濃厚懷舊色彩。許多人提到舊款 HP 計算機的按鍵手感、耐用度與極長電池壽命，有人表示 1980 年代購入的 HP 15C、16C 或 11C 至今仍能正常使用，甚至二十年才換一次電池。RPN 也引發共鳴與分歧：愛用者認為它能減少按鍵次數、不需括號、很適合手算複雜公式；不習慣者則認為學習成本高，希望能有一般代數輸入版本。也有人指出 HP 16C 對低階程式設計與位元操作特別有用，但原版顯示位數有限，在處理較長二進位值時不如現代計算機直覺。
討論中也有不少人提醒，這次產品是 HP 授權商 Moravia Consulting 推出，並非 HP 自行生產；若沿用 2023 年 HP 15C Collector’s Edition 的製造水準，可能無法完全重現原版在螢幕、按鍵手感、鍵帽印刷與整體做工上的品質。部分使用者推薦 SwissMicros 的 DM16C、DM16L、DM42 或 DM42n 作為替代選擇，也有人提到 HP48 模擬器與手機 App 仍是實用方案。不過由於二手原版 HP 16C 價格常被炒高到數百美元，這款復刻版仍被不少收藏者與工程愛好者視為值得關注的回歸。
👥 63 則討論、評論 💬
https://news.ycombinator.com/item?id=48374685
HP 16c Collector’s Edition 是經典程式設計計算機 HP 16c 的復刻收藏版，主打相隔 35 年後回歸。它延續原版的橫式外觀、按鍵配置與 RPN（Reverse Polish Notation，逆波蘭表示法）輸入邏輯，面向程式設計、電腦科學、邏輯設計與工程使用情境，同時加入現代化改良，官方稱效能最高可達原版 100 倍。
功能上，這款計算機保留 HP 16c 的核心特色：可在 HEX、DEC、OCT、BIN 等進位模式間切換，支援整數運算、位元運算、邏輯測試、進位轉換，以及 1 至 64 bit 可調字長。它也支援浮點運算與按鍵序列程式設計，包含條件分支、副程式、標籤與旗標等功能。硬體規格包括 99 個記憶暫存器、203 B 程式記憶體、1 行 10 字元七段式 LCD、2 顆 CR2032 電池、5 分鐘自動關機，並新增程式儲存與讀取功能。預購優惠到 2026 年 7 月 31 日止，討論中有人提到早鳥價約 117 美元。
Hacker News 討論多半帶有濃厚懷舊色彩。許多人提到舊款 HP 計算機的按鍵手感、耐用度與極長電池壽命，有人表示 1980 年代購入的 HP 15C、16C 或 11C 至今仍能正常使用，甚至二十年才換一次電池。RPN 也引發共鳴與分歧：愛用者認為它能減少按鍵次數、不需括號、很適合手算複雜公式；不習慣者則認為學習成本高，希望能有一般代數輸入版本。也有人指出 HP 16C 對低階程式設計與位元操作特別有用，但原版顯示位數有限，在處理較長二進位值時不如現代計算機直覺。
討論中也有不少人提醒，這次產品是 HP 授權商 Moravia Consulting 推出，並非 HP 自行生產；若沿用 2023 年 HP 15C Collector’s Edition 的製造水準，可能無法完全重現原版在螢幕、按鍵手感、鍵帽印刷與整體做工上的品質。部分使用者推薦 SwissMicros 的 DM16C、DM16L、DM42 或 DM42n 作為替代選擇，也有人提到 HP48 模擬器與手機 App 仍是實用方案。不過由於二手原版 HP 16C 價格常被炒高到數百美元，這款復刻版仍被不少收藏者與工程愛好者視為值得關注的回歸。
👥 63 則討論、評論 💬
https://news.ycombinator.com/item?id=48374685
在 Linux 上把 NVIDIA GPU 的 VRAM（顯示記憶體）當作 swap（交換空間）使用 （★ 109 分）
nbd-vram 是一個 Linux 工具，可把 NVIDIA GPU（圖形處理器）的 VRAM（顯示記憶體）當作 swap（交換空間）使用，特別針對記憶體焊死、無法升級的筆電。作者以 RTX 3070 Laptop 測試，在 16 GB 系統記憶體與 8 GB VRAM 的機器上分配 7 GB 給 swap，搭配 zram（在記憶體中壓縮資料的 Linux swap 機制）與 SSD swap 後，可用的位址空間約達 46 GB；溢位順序設計為 RAM 先滿、接著由 VRAM 承接、再交給 zram 壓縮，最後才動用 SSD，以減少 SSD 寫入並利用閒置 VRAM。
技術上，nbd-vram 以小型常駐程式透過 CUDA（NVIDIA 的平行運算平台與 API）驅動程式 API 配置 VRAM，再用 NBD（Network Block Device，網路區塊裝置）協定經由 Unix socket（Unix 通訊端）提供區塊裝置，Linux 核心內建的 nbd 驅動程式會將其呈現為 /dev/nbdX，之後即可像一般 swap 裝置使用。這個做法不需要撰寫或維護核心模組，也不依賴 NVIDIA 核心符號，因此較不受核心或驅動程式更新影響。作者也說明，直接使用 NVIDIA P2P API（Peer-to-Peer API，讓裝置間直接交換資料的介面）在消費級 GeForce GPU 上會被驅動程式拒絕，而直接映射 BAR1（Base Address Register，PCIe 裝置暴露記憶體區域的機制）也只會看到約 16 MiB 的顯示 framebuffer，因此改用 CUDA 的記憶體複製路徑繞過限制。
專案需求包含支援 CUDA 的 NVIDIA GPU、含 libcuda.so.1 的 NVIDIA 驅動程式、Linux 3.0 以上核心、nbd-client、gcc 與 make。安裝後可透過 systemd（Linux 服務管理工具）自動啟動，也能在服務檔中設定要使用多少 VRAM 與 swap 優先度；若 GPU 記憶體不足，常駐程式會以 512 MiB 為單位往下調整，盡量取得可用容量。它也提供電源管理選項，可在筆電拔除 AC 電源或電量低於門檻時自動停止，重新接電後再啟動。作者量測 RTX 3070 Laptop 上 7 GiB 連續寫入約 1.3 GB/s，主張延遲低於 NVMe SSD（高速 SSD 介面）路徑，但也建議把 VRAM swap 的優先度設高，讓它先於 SSD 承接溢位。
Hacker News 討論多半認為這是相當小眾但有實用情境的點子：例如開發機或遊戲機在未跑 AI 模型、未玩遊戲時，常有大量 VRAM 閒置，拿來減少 SSD swap 寫入有其價值。不少人也指出，swap 不只是「記憶體不夠時的緊急備援」，也可讓 Linux 在檔案快取頁與匿名記憶體頁之間有更公平的回收機制，因此即使記憶體充足，保留少量 swap 仍可能有幫助。
質疑則集中在效能與資源競爭。有人指出 RTX 3070 Laptop 的 PCIe 與 GDDR6 理論頻寬遠高於 1.3 GB/s，若只看連續吞吐量，NVMe SSD 可能更快，且 swap 更需要隨機讀寫與實際工作負載基準測試。也有人擔心 VRAM 被 swap 佔用後，Wayland 桌面、遊戲、AI 推論或其他 GPU 工作負載若突然需要顯示記憶體，是否能安全釋放並產生足夠 backpressure（資源壓力回饋機制）；在低 VRAM 情境下，桌面環境或驅動程式不穩可能會導致當機。整體而言，社群看法是這不是通用解法，但對無法升級記憶體、又有閒置 NVIDIA VRAM 的 Linux 筆電或工作站，確實是一個值得實驗的折衷方案。
👥 33 則討論、評論 💬
https://news.ycombinator.com/item?id=48377404
nbd-vram 是一個 Linux 工具，可把 NVIDIA GPU（圖形處理器）的 VRAM（顯示記憶體）當作 swap（交換空間）使用，特別針對記憶體焊死、無法升級的筆電。作者以 RTX 3070 Laptop 測試，在 16 GB 系統記憶體與 8 GB VRAM 的機器上分配 7 GB 給 swap，搭配 zram（在記憶體中壓縮資料的 Linux swap 機制）與 SSD swap 後，可用的位址空間約達 46 GB；溢位順序設計為 RAM 先滿、接著由 VRAM 承接、再交給 zram 壓縮，最後才動用 SSD，以減少 SSD 寫入並利用閒置 VRAM。
技術上，nbd-vram 以小型常駐程式透過 CUDA（NVIDIA 的平行運算平台與 API）驅動程式 API 配置 VRAM，再用 NBD（Network Block Device，網路區塊裝置）協定經由 Unix socket（Unix 通訊端）提供區塊裝置，Linux 核心內建的 nbd 驅動程式會將其呈現為 /dev/nbdX，之後即可像一般 swap 裝置使用。這個做法不需要撰寫或維護核心模組，也不依賴 NVIDIA 核心符號，因此較不受核心或驅動程式更新影響。作者也說明，直接使用 NVIDIA P2P API（Peer-to-Peer API，讓裝置間直接交換資料的介面）在消費級 GeForce GPU 上會被驅動程式拒絕，而直接映射 BAR1（Base Address Register，PCIe 裝置暴露記憶體區域的機制）也只會看到約 16 MiB 的顯示 framebuffer，因此改用 CUDA 的記憶體複製路徑繞過限制。
專案需求包含支援 CUDA 的 NVIDIA GPU、含 libcuda.so.1 的 NVIDIA 驅動程式、Linux 3.0 以上核心、nbd-client、gcc 與 make。安裝後可透過 systemd（Linux 服務管理工具）自動啟動，也能在服務檔中設定要使用多少 VRAM 與 swap 優先度；若 GPU 記憶體不足，常駐程式會以 512 MiB 為單位往下調整，盡量取得可用容量。它也提供電源管理選項，可在筆電拔除 AC 電源或電量低於門檻時自動停止，重新接電後再啟動。作者量測 RTX 3070 Laptop 上 7 GiB 連續寫入約 1.3 GB/s，主張延遲低於 NVMe SSD（高速 SSD 介面）路徑，但也建議把 VRAM swap 的優先度設高，讓它先於 SSD 承接溢位。
Hacker News 討論多半認為這是相當小眾但有實用情境的點子：例如開發機或遊戲機在未跑 AI 模型、未玩遊戲時，常有大量 VRAM 閒置，拿來減少 SSD swap 寫入有其價值。不少人也指出，swap 不只是「記憶體不夠時的緊急備援」，也可讓 Linux 在檔案快取頁與匿名記憶體頁之間有更公平的回收機制，因此即使記憶體充足，保留少量 swap 仍可能有幫助。
質疑則集中在效能與資源競爭。有人指出 RTX 3070 Laptop 的 PCIe 與 GDDR6 理論頻寬遠高於 1.3 GB/s，若只看連續吞吐量，NVMe SSD 可能更快，且 swap 更需要隨機讀寫與實際工作負載基準測試。也有人擔心 VRAM 被 swap 佔用後，Wayland 桌面、遊戲、AI 推論或其他 GPU 工作負載若突然需要顯示記憶體，是否能安全釋放並產生足夠 backpressure（資源壓力回饋機制）；在低 VRAM 情境下，桌面環境或驅動程式不穩可能會導致當機。整體而言，社群看法是這不是通用解法，但對無法升級記憶體、又有閒置 NVIDIA VRAM 的 Linux 筆電或工作站，確實是一個值得實驗的折衷方案。
👥 33 則討論、評論 💬
https://news.ycombinator.com/item?id=48377404
rsync 與眾怒 （★ 100 分）
rsync（檔案同步工具）維護者 Andrew Tridgell 發文回應近期圍繞 3.4.3 版的爭議。他說，開源軟體套件維護者近來面對大量安全通報，其中不少由人工智慧（AI）工具產生，也有高品質的人工作業分析；為了讓 rsync 能更早發現問題並提升防禦，他開始擴充測試套件、程式碼覆蓋率分析、跨平台 CI（持續整合）測試、安全掃描與縱深防禦（defense-in-depth）加固。Tridgell 表示自己已退休，本想把時間花在航海上，因此使用 Claude、Codex、Gemini 等 AI 工具分擔繁重工作，但否認只是「vibe coding（憑感覺指揮 AI 產出程式碼）」。
他特別說明，將 rsync 測試套件從舊的 shell script 改寫為 Python 是他先完成設計、規劃驗證方式，再讓 AI 工具處理重複性工作；所有部分都由他檢查，並花大量 CI 時間和本機 VM（virtual machine，虛擬機器）測試修正。他也反駁「LLM（大型語言模型，Large Language Model）只是隨機胡說」的批評，認為近幾個月軟體工程與 IT 安全環境已快速改變，LLM 當然需要謹慎使用，但仍是有用工具。至於未使用 pytest（Python 測試框架）的質疑，他表示該框架不適合這次測試套件所需的做法。
Tridgell 承認 3.4.3 確實讓部分有效但少見的使用情境出現回歸問題，主因是該版刻意偏向優先修補安全漏洞，而既有測試與人工測試沒有涵蓋這些情境；他向受影響者致歉，並表示正在處理 GitHub issue（問題回報）和 PR（pull request，程式碼變更請求）。他目前仍在處理多個 CVE（Common Vulnerabilities and Exposures，公開漏洞編號制度），也有具系統開發與安全經驗的新開發者加入。接下來他在評估先推出 3.4.4 緩和回歸問題，或直接推進原本規劃、變動更大的 3.5.0；後者會大幅提高 rsync 的安全門檻，但也需要完整測試套件作為基礎。他也回應有人提議改用 openrsync，稱新版測試套件跑在 openrsync 上目前 98 項中有 85 項失敗，雖然不少是因為 openrsync 沒有對應功能，但仍顯示替代方案並非立刻可補位。
Hacker News 討論的焦點分成兩派：一派認為外界對 AI 輔助開發的憤怒過度放大，尤其已有留言指出，相關回歸問題目前沒有證據可追溯到 AI 參與的 commit（程式碼送交紀錄）；也有人分享資深工程師日常使用 AI 輔助寫程式的經驗，認為把使用 AI 本身視為罪過是意識形態式反應。另一派則認為，問題不只是 AI，而是 rsync 這類基礎工具在小版本更新中引入大規模改動並破壞核心功能，使用者不應因為「正在修安全漏洞」或「用了 AI」而降低品質標準；有人提到 absolute path（絕對路徑）、rrsync（受限 rsync 包裝工具）與 daemon（常駐服務）相關問題，質疑是否應採用較大的版號或 beta 測試來降低風險。
討論也延伸到開源維護的現實壓力。部分留言認為，安全通報暴增、AI 協助帶來的開發速度與社群噪音，可能讓供應鏈攻擊者更容易混入，例如讓人聯想到 Jia Tan（XZ Utils 後門事件中使用的身分）一類風險；也有人指出，測試版本很難真正吸引足夠使用者試用，安全修補又不能無限期等待。整體而言，討論並未形成單一結論：多數人肯定 rsync 維護者承擔壓力與補強安全的必要性，但也提醒關鍵基礎軟體在版號管理、測試覆蓋與發佈節奏上，仍必須對使用者維持高度可預期性與可靠度。
👥 18 則討論、評論 💬
https://news.ycombinator.com/item?id=48379478
rsync（檔案同步工具）維護者 Andrew Tridgell 發文回應近期圍繞 3.4.3 版的爭議。他說，開源軟體套件維護者近來面對大量安全通報，其中不少由人工智慧（AI）工具產生，也有高品質的人工作業分析；為了讓 rsync 能更早發現問題並提升防禦，他開始擴充測試套件、程式碼覆蓋率分析、跨平台 CI（持續整合）測試、安全掃描與縱深防禦（defense-in-depth）加固。Tridgell 表示自己已退休，本想把時間花在航海上，因此使用 Claude、Codex、Gemini 等 AI 工具分擔繁重工作，但否認只是「vibe coding（憑感覺指揮 AI 產出程式碼）」。
他特別說明，將 rsync 測試套件從舊的 shell script 改寫為 Python 是他先完成設計、規劃驗證方式，再讓 AI 工具處理重複性工作；所有部分都由他檢查，並花大量 CI 時間和本機 VM（virtual machine，虛擬機器）測試修正。他也反駁「LLM（大型語言模型，Large Language Model）只是隨機胡說」的批評，認為近幾個月軟體工程與 IT 安全環境已快速改變，LLM 當然需要謹慎使用，但仍是有用工具。至於未使用 pytest（Python 測試框架）的質疑，他表示該框架不適合這次測試套件所需的做法。
Tridgell 承認 3.4.3 確實讓部分有效但少見的使用情境出現回歸問題，主因是該版刻意偏向優先修補安全漏洞，而既有測試與人工測試沒有涵蓋這些情境；他向受影響者致歉，並表示正在處理 GitHub issue（問題回報）和 PR（pull request，程式碼變更請求）。他目前仍在處理多個 CVE（Common Vulnerabilities and Exposures，公開漏洞編號制度），也有具系統開發與安全經驗的新開發者加入。接下來他在評估先推出 3.4.4 緩和回歸問題，或直接推進原本規劃、變動更大的 3.5.0；後者會大幅提高 rsync 的安全門檻，但也需要完整測試套件作為基礎。他也回應有人提議改用 openrsync，稱新版測試套件跑在 openrsync 上目前 98 項中有 85 項失敗，雖然不少是因為 openrsync 沒有對應功能，但仍顯示替代方案並非立刻可補位。
Hacker News 討論的焦點分成兩派：一派認為外界對 AI 輔助開發的憤怒過度放大，尤其已有留言指出，相關回歸問題目前沒有證據可追溯到 AI 參與的 commit（程式碼送交紀錄）；也有人分享資深工程師日常使用 AI 輔助寫程式的經驗，認為把使用 AI 本身視為罪過是意識形態式反應。另一派則認為，問題不只是 AI，而是 rsync 這類基礎工具在小版本更新中引入大規模改動並破壞核心功能，使用者不應因為「正在修安全漏洞」或「用了 AI」而降低品質標準；有人提到 absolute path（絕對路徑）、rrsync（受限 rsync 包裝工具）與 daemon（常駐服務）相關問題，質疑是否應採用較大的版號或 beta 測試來降低風險。
討論也延伸到開源維護的現實壓力。部分留言認為，安全通報暴增、AI 協助帶來的開發速度與社群噪音，可能讓供應鏈攻擊者更容易混入，例如讓人聯想到 Jia Tan（XZ Utils 後門事件中使用的身分）一類風險；也有人指出，測試版本很難真正吸引足夠使用者試用，安全修補又不能無限期等待。整體而言，討論並未形成單一結論：多數人肯定 rsync 維護者承擔壓力與補強安全的必要性，但也提醒關鍵基礎軟體在版號管理、測試覆蓋與發佈節奏上，仍必須對使用者維持高度可預期性與可靠度。
👥 18 則討論、評論 💬
https://news.ycombinator.com/item?id=48379478