Log for Ubuntu 台灣社群
Tony Hoare, the legendary computer scientist who invented null references, has died at age 92. His work fundamentally shaped modern programming languages and his insights continue to influence developers today. RIP.
現階段的 RISC-V 硬體超級慢 （★ 104 分）
作者分享他近三個月投入 Fedora Linux 的 RISC-V（開放指令集架構）移植工作進度：先把 Fedora RISC-V tracker 上的議題大量分流與釐清，接著用 Fedora 常見的打包流程抓原始碼、在 mock 環境建置、看 log 修問題。成果是已送出 86 個 Fedora 套件的 pull request，從大型的 LLVM 相關套件到小型遊戲都有，且多數已合併並在 Fedora 43 的建置體系（Koji，Fedora 的套件建置與發佈系統）上完成建置，讓整體套件覆蓋率往前推進。
但移植工作很快就碰到最棘手的現實：目前市面上的 RISC-V 硬體太慢，導致套件建置時間非常難看。作者以 binutils（GNU 組譯/連結工具鏈）為例，riscv64 在 8 核心、16 GB 記憶體的 builder 上要 143 分鐘；相較之下 x86_64 約 29 分鐘、aarch64 約 36 分鐘、ppc64le 約 46 分鐘、s390x 約 37 分鐘。為了減少記憶體用量與時間，Fedora 的 RISC-V 建置目前還得停用 LTO（Link Time Optimization，連結時最佳化）。作者指出現有 builder 多是 4 或 8 核心、8/16/32 GB 記憶體，核心等級常被拿來比作 Arm Cortex-A55（偏入門等級的核心），短期內像 Milk-V Titan 搭載的 UltraRISC UR-DP1000 SoC（System on Chip，系統單晶片）或 SpacemiT K3 平台可望改善，但仍不足以把 RISC-V 推到 Fedora 的「主要架構」地位；要做到這一步，需要可上機櫃、可管理、能在 1 小時內完成像 binutils 這類重量級套件且能全域啟用 LTO 的「正規伺服器等級」硬體。
為了跟慢速硬體周旋，作者仍大量依賴 QEMU（開源虛擬化/模擬器）：用 80 個模擬核心，他能在約 4 小時建置完 llvm15；若改在 Banana Pi BPI-F3 的 RISC-V builder 上則要 10.5 小時。作者也提到 LLVM 類套件確實能吃滿核心與記憶體，因此好奇若放到像 Ampere One 這種高核心數 Arm 伺服器（例如 192/384 核心）會快到什麼程度。後續計畫是啟動 Fedora 44 的建置，盡量讓所有 builder 共用同一個核心（kernel）映像檔、LTO 仍先維持停用，同時引進更快的 builder，並把較重的套件優先丟給新硬體處理。
留言區多數人認為「慢」的關鍵不在 RISC-V 指令集本身，而是「現在買得到的晶片實作」還不夠強，因此有人批評標題容易誤導；也有人追問目前哪個 RISC-V 實作稱得上快。較多共識是：現階段市售 RISC-V 單核表現大概頂多到 Arm Cortex-A76（約五、六年前的等級）附近，像 SiFive P870、Tenstorrent Ascalon（Jim Keller 團隊）被視為最受期待的高效能設計，但尚未普及；另有人提到 DC-ROMA 2 大致像 Raspberry Pi 4。也有網友對 s390x（IBM 大型主機架構）在表格中的每核心效率印象深刻，同時提醒用「架構」來比建置時間可能不夠嚴謹，因為不同目標（例如 i686 與 x86_64）測試項目與輸出不同，甚至連 linker 測試數量都可能不同，未必能直接推回 CPU 強弱。
另一條討論線聚焦在「軟體與 ISA 細節」：有人主張編譯器（GCC/LLVM）要吃滿效能仍需針對快取、分支預測、prefetch 等微架構特性調校，否則光靠後端移植不會自然達到同級表現；也有人反駁現代編譯器已很成熟，真正差距多半來自硬體。還有人點名 RISC-V 規格面的爭議：像位元操作（bit manipulation）未納入核心、某些位址運算/溢位（overflow）偵測機制的取捨、以及頁面大小（page size）等設計限制，可能讓可攜程式在未啟用擴充（extensions）時吃虧；對此也有人補充，RISC-V 正在用像 RVA23 這類 profile 把 vector、bitmanip 等常用擴充打包成「可跑 Linux 的實務組合」。此外也有實務派建議走交叉編譯或加上 ccache、firebuild 等建置加速器，但也有人指出 Fedora 套件的 `%install`/`%check`（安裝與測試階段）常需要在目標架構上實跑，讓交叉編譯在大規模發行版流程裡不一定划算。整體氣氛介於「短期仍慢、但新一代硬體與更完整 profile 可能讓情勢在一年內明顯改善」與「RISC-V 常被說再等五、六年」的懷疑之間拉扯。
👥 85 則討論、評論 💬
https://news.ycombinator.com/item?id=47328214
作者分享他近三個月投入 Fedora Linux 的 RISC-V（開放指令集架構）移植工作進度：先把 Fedora RISC-V tracker 上的議題大量分流與釐清，接著用 Fedora 常見的打包流程抓原始碼、在 mock 環境建置、看 log 修問題。成果是已送出 86 個 Fedora 套件的 pull request，從大型的 LLVM 相關套件到小型遊戲都有，且多數已合併並在 Fedora 43 的建置體系（Koji，Fedora 的套件建置與發佈系統）上完成建置，讓整體套件覆蓋率往前推進。
但移植工作很快就碰到最棘手的現實：目前市面上的 RISC-V 硬體太慢，導致套件建置時間非常難看。作者以 binutils（GNU 組譯/連結工具鏈）為例，riscv64 在 8 核心、16 GB 記憶體的 builder 上要 143 分鐘；相較之下 x86_64 約 29 分鐘、aarch64 約 36 分鐘、ppc64le 約 46 分鐘、s390x 約 37 分鐘。為了減少記憶體用量與時間，Fedora 的 RISC-V 建置目前還得停用 LTO（Link Time Optimization，連結時最佳化）。作者指出現有 builder 多是 4 或 8 核心、8/16/32 GB 記憶體，核心等級常被拿來比作 Arm Cortex-A55（偏入門等級的核心），短期內像 Milk-V Titan 搭載的 UltraRISC UR-DP1000 SoC（System on Chip，系統單晶片）或 SpacemiT K3 平台可望改善，但仍不足以把 RISC-V 推到 Fedora 的「主要架構」地位；要做到這一步，需要可上機櫃、可管理、能在 1 小時內完成像 binutils 這類重量級套件且能全域啟用 LTO 的「正規伺服器等級」硬體。
為了跟慢速硬體周旋，作者仍大量依賴 QEMU（開源虛擬化/模擬器）：用 80 個模擬核心，他能在約 4 小時建置完 llvm15；若改在 Banana Pi BPI-F3 的 RISC-V builder 上則要 10.5 小時。作者也提到 LLVM 類套件確實能吃滿核心與記憶體，因此好奇若放到像 Ampere One 這種高核心數 Arm 伺服器（例如 192/384 核心）會快到什麼程度。後續計畫是啟動 Fedora 44 的建置，盡量讓所有 builder 共用同一個核心（kernel）映像檔、LTO 仍先維持停用，同時引進更快的 builder，並把較重的套件優先丟給新硬體處理。
留言區多數人認為「慢」的關鍵不在 RISC-V 指令集本身，而是「現在買得到的晶片實作」還不夠強，因此有人批評標題容易誤導；也有人追問目前哪個 RISC-V 實作稱得上快。較多共識是：現階段市售 RISC-V 單核表現大概頂多到 Arm Cortex-A76（約五、六年前的等級）附近，像 SiFive P870、Tenstorrent Ascalon（Jim Keller 團隊）被視為最受期待的高效能設計，但尚未普及；另有人提到 DC-ROMA 2 大致像 Raspberry Pi 4。也有網友對 s390x（IBM 大型主機架構）在表格中的每核心效率印象深刻，同時提醒用「架構」來比建置時間可能不夠嚴謹，因為不同目標（例如 i686 與 x86_64）測試項目與輸出不同，甚至連 linker 測試數量都可能不同，未必能直接推回 CPU 強弱。
另一條討論線聚焦在「軟體與 ISA 細節」：有人主張編譯器（GCC/LLVM）要吃滿效能仍需針對快取、分支預測、prefetch 等微架構特性調校，否則光靠後端移植不會自然達到同級表現；也有人反駁現代編譯器已很成熟，真正差距多半來自硬體。還有人點名 RISC-V 規格面的爭議：像位元操作（bit manipulation）未納入核心、某些位址運算/溢位（overflow）偵測機制的取捨、以及頁面大小（page size）等設計限制，可能讓可攜程式在未啟用擴充（extensions）時吃虧；對此也有人補充，RISC-V 正在用像 RVA23 這類 profile 把 vector、bitmanip 等常用擴充打包成「可跑 Linux 的實務組合」。此外也有實務派建議走交叉編譯或加上 ccache、firebuild 等建置加速器，但也有人指出 Fedora 套件的 `%install`/`%check`（安裝與測試階段）常需要在目標架構上實跑，讓交叉編譯在大規模發行版流程裡不一定划算。整體氣氛介於「短期仍慢、但新一代硬體與更完整 profile 可能讓情勢在一年內明顯改善」與「RISC-V 常被說再等五、六年」的懷疑之間拉扯。
👥 85 則討論、評論 💬
https://news.ycombinator.com/item?id=47328214
殷拓集團考慮出售 SUSE
瑞典私募股權公司殷拓集團（EQT）考慮出售 SUSE。EQT 已聘請投行 Arma Partners 接洽一批私募股權投資人，商討出售 SUSE 的可能性。相關討論仍處於早期階段，EQT 是否會進行交易尚無定論。SUSE 是最早的 Linux 發行版之一，誕生於 1992 年，最初的名稱 S.u.S.E 是德文 Software und System-Entwicklung 的首字母縮寫，意思是「軟體與系統開發」，之後改為 SuSE，最後又變成 SUSE。SUSE 在 2003 年被 Novell 收購，2010 年 Novell 被 The Attachmate Group 收購，2014 年 SUSE 被 Micro Focus 收購。2018 年 EQT 以 25.35 億美元收購 SUSE。2021 年 SUSE 在法蘭克福證券交易所上市，2023 年 8 月再次被 EQT 私有化。
瑞典私募股權公司殷拓集團（EQT）考慮出售 SUSE。EQT 已聘請投行 Arma Partners 接洽一批私募股權投資人，商討出售 SUSE 的可能性。相關討論仍處於早期階段，EQT 是否會進行交易尚無定論。SUSE 是最早的 Linux 發行版之一，誕生於 1992 年，最初的名稱 S.u.S.E 是德文 Software und System-Entwicklung 的首字母縮寫，意思是「軟體與系統開發」，之後改為 SuSE，最後又變成 SUSE。SUSE 在 2003 年被 Novell 收購，2010 年 Novell 被 The Attachmate Group 收購，2014 年 SUSE 被 Micro Focus 收購。2018 年 EQT 以 25.35 億美元收購 SUSE。2021 年 SUSE 在法蘭克福證券交易所上市，2023 年 8 月再次被 EQT 私有化。