Jump to...
redirecting...

Log for Ubuntu 台灣社群

Firefox 納入 Vulkan Video 硬體影片解碼支援 (★ 100 分)

Firefox 已合併 Vulkan Video 解碼支援,代表瀏覽器可透過 Vulkan API(跨平台圖形與運算介面)呼叫 GPU(圖形處理器)的硬體影片解碼能力。這項變更對 Linux 使用者尤其重要,因為瀏覽器硬體加速長期受限於驅動程式、顯示協定與不同影片加速介面的整合狀況;若能順利啟用,理論上可降低 CPU 負載、改善播放順暢度與耗電表現。

Vulkan Video 並不是用 shader(著色器程式)在 GPU 上「模擬」解碼器,而是把 GPU 既有的硬體編碼、解碼功能透過 Vulkan 標準介面公開給應用程式使用。因此它不會讓不具備某種解碼能力的硬體突然支援新格式;實際效果仍取決於顯示卡、驅動程式與影片格式。原始 Phoronix 內容摘錄未包含完整技術細節,但主題明確指向 Firefox 已將此功能合併進程式碼庫。

Hacker News 討論多半對 Linux 上的影片硬體解碼前景持正面但審慎的態度。有留言指出,這對 NVIDIA Linux 使用者可能特別有幫助,因為未來或許不再需要依賴 nvidia-vaapi-driver 這類 VA-API(Video Acceleration API,Linux 常見影片加速介面)相容工具;也有人期待開源 NVIDIA 使用者空間驅動 NVK 之後能支援 Vulkan Video。另有評論補充,Firefox 仍使用 FFmpeg(常見影音解碼與轉檔函式庫),這次變更比較像是在建置與硬體加速路徑上啟用新的後端。

討論也提醒,實際受益會受到 codec(編解碼格式)限制。例如 Polaris 世代 AMD Radeon 顯示卡具備 H.264 與 HEVC(H.265)解碼,但 VP9 支援不足或未在常見 Linux 路徑中公開,導致 YouTube 播放仍可能不理想;Raspberry Pi 5 具備 HEVC 硬體解碼,但 YouTube 4K 通常使用 VP9 或 AV1,而 Pi 5 並沒有 VP9 硬體解碼,因此 Vulkan Video 本身也無法解決這類格式落差。

有留言提到相關變更已進入 Firefox 153 Nightly(每日測試版),而 Firefox 153 預計會成為下一個 ESR(Extended Support Release,延長支援版)版本,若沒有新問題,可能在 7 月 21 日隨 ESR 週期推出。部分使用者關心這是否能改善 YouTube 或 Netflix 這類含 DRM(Digital Rights Management,數位版權管理)內容的播放;討論中的共識是,它可能改善符合硬體與驅動支援條件的一般影片播放,但 DRM 串流還涉及額外保護機制與播放管線,不一定單靠 Vulkan Video 就能全面解決。总体來看,這項合併被視為 Firefox 在 Linux 影片加速上的重要進展,但仍需等待實際版本、驅動支援與各平台測試結果。

👥 16 則討論、評論 💬
https://news.ycombinator.com/item?id=48439348
GitHub 掛了 (★ 46 分)

GitHub 狀態頁通報,未登入使用者在存取 Pull Requests(合併請求,用來提出程式碼變更)、Issues(議題追蹤功能)與 Actions(GitHub 的自動化流程與 CI/CD 服務;CI/CD 指持續整合與持續交付)時遭遇可用性或效能問題。事件從 2026 年 6 月 8 日 07:11 UTC(協調世界時)開始調查,隨後 GitHub 陸續確認 Issues 可用性降低、Issues 與 Pull Requests 效能下降,並在 08:13 表示影響範圍主要限於未驗證身分的使用者,08:27 又補充 Actions 也出現效能下降。狀態頁顯示團隊仍在調查與緩解中,尚未提供完整根因或解決時間。

Hacker News 討論中,多名使用者回報實際遇到 GitHub 間歇性無法連線,包括英國倫敦與西歐地區出現 504 Gateway Time-out(閘道逾時,代表上游伺服器未及時回應),有些人重新整理後短暫恢復,接著又再次失效。也有人表示原本以為是 Firefox 或自己網路的問題,後來才發現 GitHub 狀態異常;另有留言指出,雖然官方說影響未登入使用者,但有人連從 IDE(整合開發環境)推送程式碼也遇到問題,因此懷疑實際影響可能比狀態頁描述更廣。

討論焦點很快轉向 GitHub 近期可靠性。部分使用者抱怨這類「GitHub is down」討論幾乎變成每週甚至每日出現,並提到兩天前才有另一次事件;也有人主張應改採自架服務。不過反方認為,多數公司已深度依賴 GitHub Actions、程式碼託管與各種整合流程,遷移到 GitLab 或自架系統成本很高,而且自架未必比 GitHub 更穩定。另有使用者指出,企業近年把內部系統遷到 GitHub 可能是為了節省成本,這也讓 GitHub 成為更多開發流程的單點依賴。

不少留言質疑 GitHub 狀態頁的呈現方式,認為官方 90 天可用率看起來過於樂觀;有人比較第三方追蹤頁,指出 Pull Requests 的可用率估算與官方數字差距很大,也有人觀察到過去多天明明有「效能下降」紀錄,日曆仍顯示綠色。另有技術性推測認為,未登入使用者受影響可能與快取頁面或未驗證請求路徑有關;也有人把近期不穩歸因於大型語言模型(LLM, Large Language Model)帶來的流量成長、AI 功能優先,以及工程速度提高後可能增加的變更風險,但這些說法多屬使用者推測,官方通報尚未確認根因。

👥 35 則討論、評論 💬
https://news.ycombinator.com/item?id=48442470
盟開放原始碼策略 (★ 95 分)

歐盟 (EU) 的開放原始碼策略 (Open Source Strategy) 將開放原始碼置於科技主權核心,目標是在關鍵領域推動歐洲可掌握的開放替代方案,降低對非歐盟專有技術的仰賴。這項策略屬於歐盟數位主權套案的一環,並與 Cloud and AI Development Act(雲端與 AI 發展法草案)、Chips Act 2.0(晶片法 2.0 草案)、能源數位化與人工智慧 (AI) 戰略路線圖等政策並行,試圖建立更具韌性、競爭力與戰略自主性的歐洲數位基礎設施。

文件強調,開放原始碼可讓公部門有更多選擇、降低供應商鎖定、提升互通性,也能讓中小企業 (SMEs) 降低進入門檻、參與共享創新;對公民而言,則代表更透明、安全且符合歐盟價值的數位服務。不過歐洲開放原始碼生態系仍面臨長期資金不足、專案維護與擴大應用困難、公共採購不易、歐洲方案能見度分散,以及價值被歐洲以外企業捕捉等問題。歐盟提出的作法是採取全生命週期策略,從研發、市場採用、部署到長期維運與治理,並在作業系統、雲端與邊緣運算、AI、資安、半導體、未來網際網路架構等關鍵技術投入資源。

具體措施包括建立開放網際網路堆疊 (Open Internet Stack) 目錄,推動符合歐盟規範與優先政策的開放原始碼方案;在 EUDI Wallet(European Digital Identity Wallet,歐洲數位身分錢包)、EBW(European Business Wallet,歐洲企業錢包)與年齡驗證等數位身分場景採用開放原始碼;透過 Digital Commons EDIC(歐洲數位基礎設施聯盟,用於數位公共財合作)與會員國合作,發展公部門可用的安全替代方案。策略也提到強化 OSPO(Open Source Programme Office,開放原始碼計畫辦公室)、制定開放標準採購指引、建立關鍵相依元件盤點與 Open Source Maintenance Instrument(開放原始碼維護工具),並透過 Erasmus+ 2027 等計畫提升開放技術能力。

Hacker News 討論主要聚焦在「是否真的有資金與落地機制」。不少開發者認為歐盟常以「支援」之名提出模糊補助或稅務誘因,真正能直接投入維護者與個人貢獻者的資源有限,最後可能仍由大型承包商、研究機構或財團取得經費。也有人指出,政府若要求業者把既有產品開放原始碼,可能導致原本付費採購的公部門停止付費,反而削弱維運誘因。另一個常見觀點是,歐盟與各國政府應先實際採用現有 FOSS(Free and Open Source Software,自由及開放原始碼軟體),不要再用「除非有理由」的但書回到 Microsoft 等美國大型科技公司,尤其雲端服務還牽涉美國 CLOUD Act(Clarifying Lawful Overseas Use of Data Act,允許美國執法機關要求美企提供境外資料的法律)帶來的主權疑慮。

討論也提出多個現實挑戰:法規面上,CRA(Cyber Resilience Act,資安韌性法)與 PLD(Product Liability Directive,產品責任指令)雖通常豁免非商業開放原始碼,但企業若把開放原始碼元件整合進商業產品,就可能承擔漏洞與缺陷責任;支持者則反駁,販售產品獲利的公司本來就應對所有元件負責。技術面上,部分人質疑 GNU/Linux 桌面是否足以滿足公部門安全與管理需求,也有人認為真正該先替換的是 Outlook、OneDrive、Google Workspace 等辦公協作工具。法國 La Suite Numérique 與荷蘭公部門協作套件被視為正向案例,但 Nextcloud、Matrix 等工具在使用者體驗 (UX) 與成熟度上仍被認為有落差。整體來看,這項策略被視為方向正確但仍需更明確的直接資金、採購承諾、資安研究安全港,以及對長期維運者更實際的制度設計。

👥 50 則討論、評論 💬
https://news.ycombinator.com/item?id=48442503
結果改用開源軟體的貢獻者是美國人,基金會來源是美國公司,哈!
歐洲人一直都很廢啊!七十幾年前要不是美國人,他們能打敗希特勒嗎?
歪樓提醒
"距離上一次重新編譯Linux核心有 0 天"
其實我不會編譯kernel, 我只會modprobe
希特勒:我不是歐洲人?