選型的真正軸線：整合度 vs 組裝自由度

桌面環境的選擇，核心不是「輕或重」，是別人幫你整合好多少、你保留多少自己組裝的自由。這條軸線的一端是 GNOME 這種高整合方案：面板、設定、通知、檔案管理全部設計成一致的整體，你開機就有一台能用的機器，代價是想改動它預設的行為要對抗它的設計哲學。另一端是 Hyprland 這種 compositor：它只負責畫面與視窗，面板、啟動器、鎖屏、通知你全部自己挑自己接，代價是要花時間組裝、每個元件都要自己維護。

「輕/重」只是這條軸線的副產品。高整合方案因為要保證所有元件協同，通常帶較多常駐服務、吃較多記憶體；自己組裝的方案可以只裝你要的，所以輕——但如果你把面板、啟動器、通知、鎖屏一個個補齊，最後的資源佔用未必比一個現成 DE 省多少。所以判選型別問「哪個輕」，要問「我想花多少時間在組裝與維護、換到多少客製自由」。

五個主流選項的定位

下表是常見選項在「整合度」這條軸線上的位置與代價。每個選項底下有延伸說明，因為同樣一句「適合客製」在不同方案裡的實際體驗差很多：

GNOME：把選擇替你做完的現代桌面

GNOME 的定位是「一套有明確設計主張的完整桌面」——它預設一個不同於 Windows/macOS 的工作流（頂欄 + Activities 總覽 + 動態工作區），並且刻意收斂可調選項，讓多數人不用設定就有一致體驗。從 Windows/macOS 轉來、想要「裝好就能用、不想折騰」的人，GNOME 是穩妥選擇：它的整合度最高，通知、設定、線上帳號、檔案管理彼此協調。

代價在客製。GNOME 把很多設定收進 extension 或需要另裝 gnome-tweaks（Arch：pacman -S gnome-tweaks）才改得動的角落，想把它調成傳統工作列風格是在對抗它的設計方向，而 extension 又會隨 GNOME 大版本更新而失效。所以 GNOME 適合「接受它的工作流」的人，不適合「想按自己習慣重排一切」的人。資源上它是這幾個裡偏吃的，老硬體上會感覺得到。

KDE Plasma：整合度高、但幾乎每個角落都能調

KDE Plasma 少見地同時做到高整合與高可調：它像 GNOME 一樣開箱即用、元件協調，但幾乎每個行為都攤在設定介面裡讓你改——面板可以拆解重組、視窗規則、快捷鍵、視覺效果都有深度選項。從 Windows 轉來的人會覺得它的預設隱喻（底部工作列 + 開始選單）親切，又保留了往下鑽的空間。

它的代價不在資源（現代 Plasma 已相當精實，中階機器順暢），在「選項多到需要自己收斂」——設定深意味著你可能花很多時間在調整上。想要「高整合又想保留大量客製、但不想從零組裝」的人，Plasma 通常是比 GNOME 和 Hyprland 都平衡的落點。它的 Wayland session 近年已是預設且成熟。

XFCE：老硬體與「要傳統、要穩、要輕」的預設

XFCE 的定位是輕量而傳統：它給你熟悉的桌面隱喻（工作列、選單、系統匣），資源佔用在這幾個裡最低，且以穩定少變著稱——它不追新，多年來介面與行為變動小。老硬體、低階 VM、或「我只要一個不吵不鬧、能穩定工作的桌面」的場景，XFCE 是可靠預設。

它的取捨是現代感與顯示協定：XFCE 目前仍以 X11 為主，Wayland 化在進行但尚未是預設，所以想要 Wayland 的分數效益（見下節）目前要往別的方案找。客製自由度中等——比 GNOME 開放、但沒有 KDE 那種深度設定，也沒有 Hyprland 那種完全重組的自由。

Cinnamon：給「要 Windows 式熟悉感」的轉移者

Cinnamon 出身 Linux Mint，定位是把傳統桌面隱喻做得順手好上手——底部工作列、開始選單式的應用選單、系統匣，對從 Windows 轉來的人幾乎零學習曲線。它比 XFCE 現代一點、視覺完整度高一些，整合度也高（自帶檔案管理員 Nemo、設定中心、特效）。

代價與 XFCE 類似：以 X11 為主，資源比 XFCE 略高。它適合「要一台立刻上手、像 Windows 但是 Linux」的工作機，不適合追求 Wayland 或極致輕量的場景。附帶一提，Cinnamon 的檔案管理員 Nemo 假設 Cinnamon 桌面服務在旁邊，把它單獨裝進裸 window manager 會拖進整套 Cinnamon 元件——這正是加圖形檔案管理員那篇講的桌面環境耦合。

Hyprland：不是 DE，是你自己組一個桌面

Hyprland 嚴格說不是桌面環境，是一個平鋪式（tiling）Wayland compositor——它只負責畫面合成與視窗排列，面板、啟動器、鎖屏、通知、桌布、音量控制全部不含，要你自己挑元件接上去。選它意味著你接受「從零組裝一個桌面」這件事，換來的是最高的客製自由（每個元件都你選、佈局規則完全你定）和最低的裸資源佔用。

它適合「把配置桌面當成一種投入、想要一套完全長成自己樣子的環境」的人，不適合「只想裝好開始工作」的人。組裝過程本身有相當的學習曲線與維護成本——這也是為什麼本系列用一整個 Rice 設計模組談「選了 Hyprland 之後怎麼把它組起來」。如果你還在「要不要走這條路」的階段，這篇就是那個模組的上游：先確認你要的是組裝自由、而不是開箱即用。

Wayland vs X11：選型時避不開的底層判斷

顯示協定是選型時的一條隱形軸線，因為它決定了一部分未來相容性。Wayland 是較新的顯示協定，設計上更安全、對高 DPI 與多螢幕不同刷新率支援更好，是 Linux 桌面的方向；X11 是沿用數十年的舊協定，相容性最廣但架構老舊、社群維護逐漸收斂到維持模式。GNOME、KDE Plasma、Hyprland 都已預設或原生 Wayland；XFCE、Cinnamon 目前仍以 X11 為主。

實務判讀：如果你用 NVIDIA 專有驅動、或依賴某些只支援 X11 的老工具（部分螢幕錄製、遠端桌面、自動化工具），X11 方案目前可能更少驚喜；如果你要高 DPI 筆電、多螢幕混合刷新率、或想跟上長期方向，優先選 Wayland 方案。這不是非此即彼的道德選擇，是看你的硬體與工具鏈落在哪邊。

依情境選：從你的處境倒推

選型的最後一步是把上面的定位對回你自己的處境，不是背「哪個最好」：

• 剛從 Windows/macOS 轉來、只想要能用：KDE Plasma（熟悉隱喻 + 之後可深調）或 GNOME（接受新工作流、要最省心）。要極致熟悉感就 Cinnamon。
• 老硬體 / 低階 VM / 要穩定不折騰的工作機：XFCE。資源最低、變動最少。
• 想把桌面調成完全自己的樣子、願意投入組裝：Hyprland（或其他 WM）。先讀 Rice 設計模組 確認你要的是這條路。
• 要高整合又要大量客製、不想從零組裝：KDE Plasma，是這兩個需求的平衡點。
• 硬體是 NVIDIA 或依賴 X11 工具：優先 X11 成熟的方案（XFCE / Cinnamon），或確認你的 Wayland 方案在該硬體上的狀況再決定。

判準是把「我願意花多少時間在桌面本身、我對客製的需求有多強、我的硬體與工具落在 Wayland 還是 X11」三個問題答清楚，選項自然收斂。沒有一個 DE 對所有人最好——選錯最常見的原因是拿別人的推薦套自己不同的處境。

桌面環境的擴充生態

選好 DE 之後，各方案還有自己的擴充路徑，這是「選項之下還有選項」的一層：

• GNOME：透過 GNOME Extensions 加面板、工作流、狀態列元件，但要注意 extension 綁 GNOME 版本、大版本更新可能失效。
• KDE Plasma：內建的 widget（plasmoid）、全域主題、視窗規則系統，多數擴充不需要離開設定介面。
• XFCE / Cinnamon：panel plugin、applet、主題，擴充幅度中等但穩定。
• Hyprland：因為本來就是自己組，擴充等於換元件——換 bar（waybar/其他）、換啟動器、換通知 daemon，自由度最高也最需要自己維護。這一整套怎麼組，是 Rice 設計模組 的主題。

下一步

• 選了 Hyprland、要開始組裝：Dotfile 管理：桌面 Rice 設計 是「選了之後怎麼把它長成自己的樣子」的完整模組。
• 桌面選好、要裝檔案管理員這類 GUI app 時的相依判讀：在 Hyprland 加圖形檔案管理員。
• 純終端機環境不需要桌面環境、但需要對應的 CLI 工具：CLI 環境工具。
• 桌面裝好後遇到顯示、鎖屏、服務層的問題怎麼診斷：除錯與診斷。

流程定位

Desktop client 的風險集中在作業系統信任鏈與更新通道。macOS、Windows、Linux 對簽章、安裝包格式與安全提示的要求不同；同一份 source 通常會產生多個平台 artifact，因此 workflow 要把平台 matrix、簽章 secret 與 Release Channel 拆清楚。

Build 階段負責產生平台專屬 artifact。Flutter Desktop、Electron 與 Tauri 的輸出格式不同，但共同要求是每個 artifact 都能追到 commit、workflow run 與 dependency lock。

Signing 階段負責讓 OS 信任安裝包。Windows code signing certificate、macOS Developer ID、timestamp server 與 Linux package signing key 都是發布能力；secret 應放在受控環境，並限制能觸發 signing job 的分支與 reviewer。

Notarize 階段負責處理 macOS 信任 gate。macOS app 即使完成簽章，也常需要 notarization 與 stapling；CI 要把 notarization log 保存下來，否則使用者看到 Gatekeeper 警告時很難回溯。

Release 階段負責把 artifact 放到正確 Release Channel。Internal、beta、stable 與 enterprise channel 的 gate 不同；CI/CD 要避免未審核的 beta artifact 被 stable feed 取用。

Update 階段負責維持升級路徑。Update Feed、delta package、signature、minimum supported version 與 rollback channel 要一起設計；更新壞掉時，使用者可能卡在需要人工修復的版本。

Recovery 階段負責止血。桌面客戶端常用方式是撤下 update feed、發布 hotfix、切換 rollback channel、停用 remote feature 或要求最低版本；每種方式都依賴 app 內建相容支援。

平台差異判讀

平台差異判讀的責任是讓 CI matrix 對應真實發布風險。桌面發布除了確認「三平台都 build 成功」，還要確認每個平台的安裝、啟動、更新與卸載行為。

這張表的用途是避免平台細節被單一「desktop build」欄位抹平。每個 OS 的失敗代價不同，CI 應保留平台專屬 gate。

Update feed 契約

Update Feed 契約的責任是讓已安裝使用者安全升級。Auto-update 需要簽章、版本比較、channel、最低版本與回退策略共同成立，才能讓新版本 URL 進入 feed。

1. Feed 只指向已簽章且已驗證的 artifact。
2. Stable feed 只接收 stable release，beta feed 只接收 beta release。
3. App 啟動時能處理 feed 暫時不可用。
4. Delta update 失敗時能 fallback 到 full installer。
5. 錯誤版本要能從 feed 撤下，並讓未更新使用者停止取得。
6. 已更新使用者要有 hotfix 或 rollback channel。

這些條件讓更新通道具備操作性。若 app 只知道「看到新版就下載」，錯誤 feed 會把事故放大到所有啟動中的使用者。

下一步路由

• Desktop 部署總覽：回 Desktop Client 部署 CI/CD。
• App 發布通用觀念：讀 App 簽章、商店審核與分批發布流程。
• 簽章術語：讀 App Signing。

這個系列講的不只是「有哪些桌面工具」，而是選它們時該看什麼：相依足跡、桌面環境耦合、功能相依（掛載 / 縮圖 / 網路這些側欄功能背後各是一個額外套件）。

文章

相關

• 純終端機下的檔案管理器（yazi / broot / ranger）是另一條路，見 CLI 環境工具 的檔案管理器段。
• 桌面環境本身（GNOME / KDE / Hyprland）怎麼選、各自的擴充生態，見 桌面環境選型；選了 Hyprland 之後怎麼組裝，見 Dotfile 管理：桌面 Rice 設計。
• 在圖形桌面上安裝這些工具前的環境與相依判讀，跟 除錯與診斷 的權威狀態紀律同源。

場域定位

Desktop client 常見於 Flutter Desktop、Electron、Tauri。部署流程通常要分平台建置（macOS、Windows、Linux），並處理安裝體驗、Release Channel 更新節奏與版本共存。

常見注意事項

• 不同 OS 的簽章與公證流程需分開治理。
• Auto-update 要有版本相容策略與 fallback feed。
• 崩潰回報與更新成功率應列為發布後 gate。
• 若與 Flutter App 共用程式碼，要明確區分 mobile 與 desktop 的發布管線。

學習路線

下一步路由

• Desktop 發布主流程：讀 Desktop client 簽章、公證與自動更新流程。
• 行動與客戶端通用觀念：讀 App 部署 CI/CD。
• 簽章治理：讀 App Signing 與 Secret Management。
• 失敗處理：讀 CI 失敗到修復發布流程。

概念位置

Update Feed 位在 signed artifact、release channel 與已安裝 app 之間，常包含版本號、下載 URL、signature、checksum、release notes 與最低支援版本。

可觀察訊號

• 客戶端需要自動偵測新版本。
• beta 與 stable 使用者需要看到不同版本。
• 錯誤版本需要從更新來源撤下。

接近真實服務的例子

Electron app 啟動時讀取 stable feed，取得最新 signed installer 與 signature。若新版本 crash rate 升高，團隊先撤下 feed 指向，讓未更新使用者停止取得錯誤版本。

設計責任

Update Feed 要定義簽章驗證、channel 分流、版本比較、fallback installer、撤版策略與 telemetry，讓已安裝客戶端安全升級。

拆包生態：裝了本體不等於裝了功能

發行版為了控制依賴體積，會把一個應用的核心跟功能模組拆成多個套件，預設只裝核心。這個設計讓「安裝成功」跟「功能可用」變成兩件事，而缺件的症狀往往是靜默的：

• VLC 的解碼器是獨立 plugin：Arch 的 vlc 本體開得起來、UI 完整，播 H.264 影片卻回報 Codec 'h264' is not supported——解碼能力在 vlc-plugin-ffmpeg（或整組 vlc-plugins-all）。judgment 訊號是「應用正常啟動、特定格式失敗」，權威來源是應用自己的 log（vlc --verbose=2）。
• pipewire 的 session manager 是獨立套件：pipewire 常被依賴鏈拉進來，但沒有 wireplumber 就沒有人建立音訊 graph——daemon 在跑、wpctl status 的 Sinks 段是空的、所有應用無聲且不報錯。補 wireplumber + pipewire-pulse（多數 GUI 應用走 PulseAudio API）後輸出裝置立即出現。
• optional dependency 不會自動安裝：套件宣告的 optdepends 是「裝了會多什麼功能」的提示、不是安裝動作。影片縮圖、壓縮格式支援、硬體加速常落在這層，pacman -Qi <pkg> 的 Optional Deps 段列出哪些沒裝。

判讀原則：GUI 應用「開得起來但某個功能不動」時，先查發行版有沒有把那個功能拆成獨立套件，再懷疑設定或相容性。

首跑同意對話框：程式在等使用者決策

不少 GUI 應用第一次啟動會彈出需要使用者決策的對話框，最典型的是 VLC 的「Privacy and Network Access Policy」：

VLC 聲明自己不蒐集、不傳輸任何個人資料，但它能自動向第三方網路服務抓取播放清單裡媒體的中繼資料（封面圖、曲名、演出者）——這個行為等於把「你在播哪些檔案」暴露給第三方服務，所以 VLC 開發者要求使用者明示同意（Allow metadata network access 勾選框、預設勾選）後才允許自動連網。

這個對話框的判讀是用途導向：拿 VLC 播本機影片、看下載的影片檔，中繼資料抓取沒有用處、取消勾選讓播放器完全離線工作；拿它管理音樂庫、想要自動補封面跟曲目資訊，才需要同意。同意與否都能在偏好設定（Privacy / Network Interaction）事後改。

首跑對話框對自動化流程有一層額外影響：無人值守安裝驗證時，應用會停在對話框等輸入、腳本側只看到「程式起了但沒繼續」。VLC 把這兩個決策記在 ~/.config/vlc/vlcrc 的 qt-privacy-ask 與 metadata-network-access 兩個鍵——首跑後檔案才生成，而且 VLC 退出時會整檔重寫（幾千行的完整設定 dump），把它納入 dotfile 版控會持續產生無意義的 diff，比較合理的處理是讓首跑對話框留給人、或在自動化腳本裡預先寫入只含這兩鍵的最小 vlcrc。

同型的首跑決策也出現在瀏覽器（預設瀏覽器詢問、錯誤回報同意）跟大型 GUI 應用（遙測同意）。它們的共通判讀：對話框問的是「要不要讓程式自動連外 / 回傳資料」，答案取決於這台機器的用途與隱私要求，安裝驗證流程要把「首跑會有互動」納入預期、不是當成故障。

播放驗證鏈：三個權威位置

「有沒有真的在播」的驗證不靠肉眼跟喇叭，三個權威位置各管一段：

把「管線通不通」跟「應用會不會播」拆開驗證能大幅縮短歸因：先用本機音檔 pw-play <file> 打通音訊路徑（stream 出現 [active] 代表 guest 側無誤），再測應用層；應用層失敗就跟管線無關，往解碼器、DRM、應用 log 查。串流再多拆一層：先用無 DRM 的串流（一般影音網站）確立網路串流基線，DRM 內容（Spotify、Netflix 類）的失敗才能歸因到 DRM 層——DRM 在非 x86_64 架構的可用性判讀見 平台與發行版差異的判讀地圖 的套件存在性段。

VM 特有：硬體解碼回退

在 VM 裡播放影片，第一次開檔常會閃一個錯誤對話框（failed to create video output）然後正常播放——這是硬體解碼回退的痕跡：播放器預設先嘗試硬體加速解碼（VDPAU / VAAPI），虛擬 GPU（如 virtio-gpu）沒有視訊解碼能力，嘗試失敗後回退軟體解碼重建輸出。log 上的特徵是一次性的 decoder error 加上之後穩定的 avcodec decoder 軟體解碼行；實體機器有 GPU 解碼時不會出現。VM 裡想要乾淨啟動，在播放器偏好設定停用 hardware-accelerated decoding 即可——這是機器特性設定，適合留在該機器本機、不進共用 dotfile。

下一步路由

• 套件在這個平台 / 架構存不存在、名字叫什麼：平台與發行版差異的判讀地圖
• 音訊、行程、服務狀態的權威判讀：Linux 除錯與診斷
• GUI 應用清單怎麼進 bootstrap：模組八：Bootstrap script 設計