Log for Ubuntu 台灣社群

使用 Snap 版本的 Firefox 預設在 AMD 主板 Framework Laptop 上會因為 Mesa 組件版本原因預設禁用視訊內容的硬體解碼，目前已知可解決問題的 workaround 為安裝 latest/candidate/core24 分支的版本（這個版本因尚有問題未解決尚未正式釋出於 stable 分支，如使用上有遇到問題可考慮回滾 stable 分支的版本）：

sudo snap refresh firefox --channel=latest/candidate/core24

核心：引入多核心（multikernel）架構支援 （★ 169 分）

這個補丁系列在 Linux 核心中引入「多核心」（multikernel）架構支援，透過 kexec（Linux 的重新開機載入機制）基礎架構，允許在同一部實體機器上同時載入並執行多個獨立核心映像，每個核心實例可綁定在特定 CPU 核心上運作，並共用底層硬體資源。作者指出，這種做法能提升不同工作負載之間的故障隔離度、加強核心層級的安全性、相比傳統虛擬機（如 KVM、Xen）更有效率地使用資源，並有機會透過 KHO（Kernel Hand Over，核心接管機制）達成零停機核心更新。

整體架構採用 kexec 的映像追蹤機制，並建立通用的 IPI（inter-processor interrupt，跨處理器中斷）通訊框架來協調多核心實例。x86 平台下加入了 SMP INIT trampoline 用於多核心啟動，以及專用的 MULTIKERNEL_VECTOR 做為核心間通訊通道；此外還新增 arch_cpu_physical_id() 以取得實體 CPU 識別，並將原本的靜態 kimage 結構改為動態鏈結串列，以支援同時載入多個核心映像；最後透過 /proc/multikernel 介面提供核心實例的監控與除錯功能。

此基礎框架主要作為概念驗證（proof of concept），作者在自有開發主機上以硬編碼開機參數與特定硬體進行測試，並強調現階段僅提供基本功能，希望社群能針對不同硬體平台、配置與應用場景進行更廣泛的驗證與優化。潛在應用包括在同一系統中並行運行即時核心與通用核心、隔離關鍵安全應用，以及為特定工作負載提供專屬核心實例等。

在 Hacker News 討論中，許多參與者將此構想與過往的多核心作業系統專案比較，如 Barrelfish OS、OpenVMS Galaxy 以及 IBM 的 LPAR（Logical Partition，邏輯分割）技術，並指出實務上若要共享裝置（例如 DMA、PCI 設備），仍需硬體層面支援如 SR-IOV（單根 I/O 虛擬化）或 IOMMU（I/O 記憶體管理單元）才能達成安全隔離與效能保障。部分評論提出，此方案假設所有載入核心都屬於可信賴範疇，並未提供跨核心的強隔離，對於硬體單一資源的擁有權移轉（如 PCI 列舉、ACPI 管理）也需要進一步設計；更有人建議，或可結合微核心架構（microkernel）或 Genode 平台，以便更靈活且安全地管理驅動程式與裝置資源。總體而言，社群對這項多核心架構抱持興趣，但同時認為在硬體支援與資源管理層面仍有諸多挑戰待克服。

👥 49 則討論、評論 💬
https://news.ycombinator.com/item?id=45302721

你有讀過 Slack 應用程式那份將近二十七萬行的授權文件嗎？ （★ 101 分）

Slack 在 Mac 平台上的應用程式是一個基於 Electron 的桌面軟體，其中包含一個龐大的授權文件。這個檔案大小約 15.2 MB，共計 272,516 行。事實上，它並不是 Slack 自行撰寫的條款，而是因為 Slack 依賴 Chromium 內核，而 Chromium 又含有大量第三方開源程式庫，每個依賴元件都附帶自己的授權條款，因此最終集合成為這份冗長的 `LICENSES.chromium.html`。由於這些程式庫的授權內容會重複出現，例如 Apache、GPL、LGPL、MIT 等大量重疊，檔案才會暴增到近 27 萬行。此外，有開發者指出這份文件的產生方式是 Google 寫的一個 Python 腳本透過 SPDX（Software Package Data Exchange, 軟體套件資料交換制式）資訊自動生成，相當重複繁瑣，並未經過有效最佳化處理。

在 Hacker News 的討論中，有人認為這顯示了「授權地獄」（License Hell）的問題，因為法律部門不願承擔風險，導致工程師只能照本宣科、為每個依賴重複附上完整授權。相對之下，Debian 社群的作法就更有效率：同樣的授權條文只提供一次，並以識別碼（identifier）在各相依元件間交互對應，如此便可避免幾百次重複貼上相同的 Apache 2.0 或 MIT 條款。有開發者指出 Slack 那份文件中光是 Apache 2.0 的授權就出現 800 次，MIT 237 次，這是為了避免任何法律上的爭議，但技術上絕非必要。社群中有人進一步建議改用 SPDX 的標準識別碼來簡寫，或者進一步壓縮授權彙編文檔，這樣既能符合法律要求，也能減少冗餘。

部分討論轉向軟體體積與資源浪費的問題。有工程師對比早年在 10MB 硬碟上仍能編程、打遊戲、收發郵件，如今一個小工具卻動輒附帶上百 MB 不必要的檔案，感嘆現代軟體的肥大相當浪費。另外也有開發者批評 Slack 不僅授權文件臃腫，其應用程式商店政策過於嚴苛，導致開發者投入時間去開發 Slack 外掛完全不值得，因為限制很多且缺乏彈性。有人甚至建議企業考慮其他開源或付費一次的解決方案，例如 Basecamp 旗下的 Once Campfire，或是開源且可自架的 Zulip、Matrix/Element。

整體來看，這次事件凸顯的不僅是 Slack 授權文件本身的荒謬長度，更顯示出當前軟體商業化與法律風險控管帶來的副作用：為了避免最小的潛在風險，公司選擇了最保守的冗餘做法，最終反而導致使用者與硬體儲存的浪費。社群普遍認為這並非 Slack 單獨的問題，而是現今開源授權和商業軟體整合後普遍存在的結構性困境。

👥 49 則討論、評論 💬
https://news.ycombinator.com/item?id=45308503

授權地獄......