Log for Ubuntu 台灣社群
有點 IE，不過剛剛更新系統時發現 apt-key 要被棄用了（24.04 已經被棄用了，我是基於 22.04 的系統，所以只是警告）
現在的政策是針對套件做 "signed-by" 的 keyring，以前的 trusted.gpg 不再使用了。
雖然受衆應該不多，不過這裡如果最近有人要把系統升到 24.04 的話，記得先把 apt update 看一下，把警告都清乾淨再升
現在的政策是針對套件做 "signed-by" 的 keyring，以前的 trusted.gpg 不再使用了。
雖然受衆應該不多，不過這裡如果最近有人要把系統升到 24.04 的話，記得先把 apt update 看一下，把警告都清乾淨再升
徵求白老鼠測試我打包的現在支援 Vulkan GPU 加速的 Whisper.cpp 語音轉文字軟體：
主要需要 Intel 跟 NVIDIA 支援 Vulkan API 的系統的執行結果資料
sudo snap install --channel=edge whisper-cpp whisper-cpp.download-ggml-model medium whisper-cpp.cli -m ggml-medium.bin --threads $(nproc) --language auto --print-progress --flash-attn --suppress-nst --output-srt 輸入音訊檔路徑
主要需要 Intel 跟 NVIDIA 支援 Vulkan API 的系統的執行結果資料
我在 2026 年可以開始改用 Wayland 了嗎？ （★ 111 分）
Wayland 是 Linux 圖形顯示架構中用來取代 X server（X11/Xorg）的協定與生態系。作者 Michael Stapelberg 從 2008 年 Wayland 啟動以來幾乎每年都嘗試遷移，但長期被驅動與應用程式支援卡住；2026 年這次實測聚焦在他要用的「極端」桌面情境：nVidia 顯示卡加上 Dell 32 吋 8K 螢幕（7680x4320@60，需雙 DisplayPort 1.4、MST 與 `TILE` 拼接）。近年多個發行版與桌面環境逐步把 Wayland 當預設、甚至弱化 X11，也讓他更想確認「現在到底能不能日用」。
他指出 nVidia 在 2021 年驅動 495 才加入 GBM（Generic Buffer Manager）後，Wayland 才比較能啟動，但仍曾因同步機制不同而出現嚴重畫面瑕疵；直到 explicit sync（顯式同步）落地，Sway 1.11（2025/06）與 wlroots 0.19.0 才讓 nVidia 在 wlroots/Sway 上「基本可用」。然而真正的關卡是 8K 拼接顯示：wlroots 多年缺乏 `TILE` 屬性支援，補丁雖能讓螢幕以單一輸出顯示，卻在 nVidia 上出現右半邊黑屏。作者在 Claude Code（AI 程式助理）協助下做出最小重現程式，鎖定是 nVidia 對 DRM 的 `SRC_X` 屬性行為異常，並提出以額外 buffer 複製右半畫面迴避的修補，終於首次在 8K 螢幕上把 Sway 跑起來；同時也提到 GNOME 雖能正確拼接，但 tile 更新不同步導致撕裂更嚴重，需等 Mutter（GNOME 視窗管理器/合成器）後續修正。
進入「實際工作一整天」後，問題轉向日用體驗：Sway 雖大致相容 i3 設定，但作者遇到滑鼠游標延遲、libinput 參數難以對應、偶發快捷鍵像是被觸發兩次，以及最致命的 Xwayland 縮放支援不足導致舊程式模糊或被雙重縮放（讓「先用 Xwayland 撐著」這條退路失效）。他也記錄 GTK 設定（字體縮放、GDK_BACKEND）與字型渲染差異，甚至發現 GTK3 在 Wayland 下偏向只吃 dconf 設定而忽略傳統 `settings.ini`。螢幕鎖定從 i3lock 換到 swaylock，因 Wayland 的 ext-session-lock-v1 協定要求合成器遮蔽輸出，造成 swaylock 若被殺掉會出現「紅畫面」必須重新解鎖；i3 的 IPC（interprocess communication）相關自動化工具也因 Sway 功能缺口（例如不做 layout save/restore、部分比對條件未支援）而需要改寫。終端機方面他偏好 foot，但遇到快捷鍵、URL 選取、screen(1) 顏色（terminfo）等相容性瑕疵；Emacs 則是另一個大痛點：原版多半走 Xwayland（在 Sway 下變模糊），原生 Wayland 需用 Emacs 的 pgtk 版本，卻出現字距/行高不同與明顯輸入延遲，且遠端使用從 X11 forwarding 轉到 waypipe（Wayland 遠端轉送）仍待評估。Chrome 在 Wayland 下初看硬體加速正常，但頻繁移動縮放後 GPU 行程會崩掉，WebGL 等加速失效；此外 Chrome 視窗無法像在 i3/X11 時依 `_NET_WM_DESKTOP` 回到原工作區，對多工作區工作流非常惱人，預期要靠新協定 `xdg-session-management` 改善。螢幕分享則必須靠 xdg-desktop-portal 與 xdg-desktop-portal-wlr（wlroots 的 portal），舊版無法分享「單一視窗」，新版雖可但流程需要額外挑選器、解析度還可能套錯縮放係數導致畫面糊。再加上啟用輸出縮放後切換視窗會短暫「跳動/模糊」的縮放瑕疵，作者結論是：距離「可當日常主力」第一次真的接近了，但以他目前 X11/i3 幾乎零瑕疵、超低延遲的基準來看，改用 Wayland/Sway 仍是純負擔，短期內會繼續留在 X11/i3，並列出需達成的條件（快捷鍵重複、縮放跳動、Chrome 長時間硬體加速穩定、視窗回工作區、以及 Emacs 的縮放/延遲問題）。
討論區的共識大致分裂成兩派：一派認為 Wayland 最大的結構性問題是「它只是協定，不是單一實作」，導致 GNOME（Mutter）、KDE（KWin）、wlroots/Sway/Hyprland 等各自重做大量過去 Xorg 集中提供的功能，還外掛出 xdg-desktop-portal-gnome/kde/wlr/hyprland 等多套 portal，複雜度從「只有一份」搬到「很多份」，除錯與相容性成本被放大；也有人直指這種缺乏共同基礎層的狀態違背了某些人心目中的 UNIX 傳統。針對螢幕分享，留言補充目前「多數螢幕分享都在瀏覽器」卻得依賴 portal/Flatpak 這條路徑，涉及多層 IPC（行程間通訊）與元件，體驗特別容易踩雷；也有人分享 wlroots 系合成器（Sway、niri）日用仍常遇到 Wine、多螢幕、10-bit 等零碎問題，甚至得偶爾切回 GNOME 才能做特定工作。
另一派則強調「其實很多人早就順用」，尤其是 AMD/Intel 顯示卡、或直接用 GNOME/KDE 的使用者，回饋 Wayland 的平滑度、多螢幕不同縮放（fractional scaling，非整數縮放）與切換顯示器的體驗更好；也有人指出 X11 長期維護人力萎縮是現實，桌面環境想甩掉同時維護 X11 與 Wayland 的負擔，才會逐步把 Wayland 變預設，XWayland 則會作為相容層長存。不過討論也提醒：Wayland 的安全模型讓 xdotool、xev、x2x 這類「全域操控/讀取輸入」的自動化工作流變得困難，等於逼部分使用者留在 Xorg；也有人糾正文章中常見的歷史敘事，認為當年 nVidia 與 GBM/EGLStreams 的衝突不完全是「nVidia 不配合」，而是早期 GBM 偏向 Mesa 生態的介面設計導致封閉驅動難以直接採用。整體而言，留言普遍肯定作者把問題具體化、做出可重現案例並回報上游，因為在「預設遷移潮」下，真正能推進相容性的往往就是這種細節扎實的 bug 追查與修補。
👥 68 則討論、評論 💬
https://news.ycombinator.com/item?id=46485989
Wayland 是 Linux 圖形顯示架構中用來取代 X server（X11/Xorg）的協定與生態系。作者 Michael Stapelberg 從 2008 年 Wayland 啟動以來幾乎每年都嘗試遷移，但長期被驅動與應用程式支援卡住；2026 年這次實測聚焦在他要用的「極端」桌面情境：nVidia 顯示卡加上 Dell 32 吋 8K 螢幕（7680x4320@60，需雙 DisplayPort 1.4、MST 與 `TILE` 拼接）。近年多個發行版與桌面環境逐步把 Wayland 當預設、甚至弱化 X11，也讓他更想確認「現在到底能不能日用」。
他指出 nVidia 在 2021 年驅動 495 才加入 GBM（Generic Buffer Manager）後，Wayland 才比較能啟動，但仍曾因同步機制不同而出現嚴重畫面瑕疵；直到 explicit sync（顯式同步）落地，Sway 1.11（2025/06）與 wlroots 0.19.0 才讓 nVidia 在 wlroots/Sway 上「基本可用」。然而真正的關卡是 8K 拼接顯示：wlroots 多年缺乏 `TILE` 屬性支援，補丁雖能讓螢幕以單一輸出顯示，卻在 nVidia 上出現右半邊黑屏。作者在 Claude Code（AI 程式助理）協助下做出最小重現程式，鎖定是 nVidia 對 DRM 的 `SRC_X` 屬性行為異常，並提出以額外 buffer 複製右半畫面迴避的修補，終於首次在 8K 螢幕上把 Sway 跑起來；同時也提到 GNOME 雖能正確拼接，但 tile 更新不同步導致撕裂更嚴重，需等 Mutter（GNOME 視窗管理器/合成器）後續修正。
進入「實際工作一整天」後，問題轉向日用體驗：Sway 雖大致相容 i3 設定，但作者遇到滑鼠游標延遲、libinput 參數難以對應、偶發快捷鍵像是被觸發兩次，以及最致命的 Xwayland 縮放支援不足導致舊程式模糊或被雙重縮放（讓「先用 Xwayland 撐著」這條退路失效）。他也記錄 GTK 設定（字體縮放、GDK_BACKEND）與字型渲染差異，甚至發現 GTK3 在 Wayland 下偏向只吃 dconf 設定而忽略傳統 `settings.ini`。螢幕鎖定從 i3lock 換到 swaylock，因 Wayland 的 ext-session-lock-v1 協定要求合成器遮蔽輸出，造成 swaylock 若被殺掉會出現「紅畫面」必須重新解鎖；i3 的 IPC（interprocess communication）相關自動化工具也因 Sway 功能缺口（例如不做 layout save/restore、部分比對條件未支援）而需要改寫。終端機方面他偏好 foot，但遇到快捷鍵、URL 選取、screen(1) 顏色（terminfo）等相容性瑕疵；Emacs 則是另一個大痛點：原版多半走 Xwayland（在 Sway 下變模糊），原生 Wayland 需用 Emacs 的 pgtk 版本，卻出現字距/行高不同與明顯輸入延遲，且遠端使用從 X11 forwarding 轉到 waypipe（Wayland 遠端轉送）仍待評估。Chrome 在 Wayland 下初看硬體加速正常，但頻繁移動縮放後 GPU 行程會崩掉，WebGL 等加速失效；此外 Chrome 視窗無法像在 i3/X11 時依 `_NET_WM_DESKTOP` 回到原工作區，對多工作區工作流非常惱人，預期要靠新協定 `xdg-session-management` 改善。螢幕分享則必須靠 xdg-desktop-portal 與 xdg-desktop-portal-wlr（wlroots 的 portal），舊版無法分享「單一視窗」，新版雖可但流程需要額外挑選器、解析度還可能套錯縮放係數導致畫面糊。再加上啟用輸出縮放後切換視窗會短暫「跳動/模糊」的縮放瑕疵，作者結論是：距離「可當日常主力」第一次真的接近了，但以他目前 X11/i3 幾乎零瑕疵、超低延遲的基準來看，改用 Wayland/Sway 仍是純負擔，短期內會繼續留在 X11/i3，並列出需達成的條件（快捷鍵重複、縮放跳動、Chrome 長時間硬體加速穩定、視窗回工作區、以及 Emacs 的縮放/延遲問題）。
討論區的共識大致分裂成兩派：一派認為 Wayland 最大的結構性問題是「它只是協定，不是單一實作」，導致 GNOME（Mutter）、KDE（KWin）、wlroots/Sway/Hyprland 等各自重做大量過去 Xorg 集中提供的功能，還外掛出 xdg-desktop-portal-gnome/kde/wlr/hyprland 等多套 portal，複雜度從「只有一份」搬到「很多份」，除錯與相容性成本被放大；也有人直指這種缺乏共同基礎層的狀態違背了某些人心目中的 UNIX 傳統。針對螢幕分享，留言補充目前「多數螢幕分享都在瀏覽器」卻得依賴 portal/Flatpak 這條路徑，涉及多層 IPC（行程間通訊）與元件，體驗特別容易踩雷；也有人分享 wlroots 系合成器（Sway、niri）日用仍常遇到 Wine、多螢幕、10-bit 等零碎問題，甚至得偶爾切回 GNOME 才能做特定工作。
另一派則強調「其實很多人早就順用」，尤其是 AMD/Intel 顯示卡、或直接用 GNOME/KDE 的使用者，回饋 Wayland 的平滑度、多螢幕不同縮放（fractional scaling，非整數縮放）與切換顯示器的體驗更好；也有人指出 X11 長期維護人力萎縮是現實，桌面環境想甩掉同時維護 X11 與 Wayland 的負擔，才會逐步把 Wayland 變預設，XWayland 則會作為相容層長存。不過討論也提醒：Wayland 的安全模型讓 xdotool、xev、x2x 這類「全域操控/讀取輸入」的自動化工作流變得困難，等於逼部分使用者留在 Xorg；也有人糾正文章中常見的歷史敘事，認為當年 nVidia 與 GBM/EGLStreams 的衝突不完全是「nVidia 不配合」，而是早期 GBM 偏向 Mesa 生態的介面設計導致封閉驅動難以直接採用。整體而言，留言普遍肯定作者把問題具體化、做出可重現案例並回報上游，因為在「預設遷移潮」下，真正能推進相容性的往往就是這種細節扎實的 bug 追查與修補。
👥 68 則討論、評論 💬
https://news.ycombinator.com/item?id=46485989
只為了預設啟用h264，但書有一大堆
Only the "Graphics Pipeline" extension of the RDP protocol is implemented for video streaming. This extension allows using H.264 for video streaming, but it means only clients supporting that extension are supported.
H.264 encoding is done using hardware encoding if possible, but currently we only support using VAAPI for this. Most notably this means hardware encoding on NVidia hardware can not be used and software encoding will be used instead. Additionally, on certain hardware there are limits to what size of frame can be encoded by the hardware. In both cases, encoding will fall back to software encoding.
Only the "Graphics Pipeline" extension of the RDP protocol is implemented for video streaming. This extension allows using H.264 for video streaming, but it means only clients supporting that extension are supported.
H.264 encoding is done using hardware encoding if possible, but currently we only support using VAAPI for this. Most notably this means hardware encoding on NVidia hardware can not be used and software encoding will be used instead. Additionally, on certain hardware there are limits to what size of frame can be encoded by the hardware. In both cases, encoding will fall back to software encoding.
Wayland究竟什麼時候才能single source of interface/implementation呢.png