RHEL 9 作為桌面系統之嘗試與感想
雖然標題是這樣寫，但其實本文很大程度應該算是偏綜合性的雜談，只是 RHEL 9 在當中佔了蠻重要的份量。故事的起頭，是在物盡其用的訴求下，前陣子開始在規劃，如何將還堪用的舊筆電（十年以上），重新打造成在硬體規格尚可負荷的前提下，能夠迎合日常各式電腦使用需求的狀態。進行試驗的兩款筆電型號，分別是一部 Lenovo ThinkPad X230 Tablet（CPU i7-3520M），以及一部 Toshiba Portege R830（CPU i3-2350M），儲存媒體皆更換至 1TB SATA SSD，以及記憶體皆更換至 8GB（DDR3 4GB * 2）。
由於 Linux 是 DR 個人最習慣的操作環境，並且也最適合用於應對一些具技術性的需求；但與此同時也需要考量到其他使用者，以及某些應用程式對於 Windows 系統的依賴情形。所以如果目標是要實現最具廣泛可用性的狀態，那麼採用 Windows + Linux 雙系統共存的作法應該就是必然的選擇。於是接著需要做出決定的，則是選擇要安裝哪一款 Linux 發行版。其中雖然 Fedora 是 DR 平常最主要使用的桌面系統，然而 Fedora 的使用者總是需要在每隔一年半載左右，透過升級或者重新安裝的方式，來更換至較新版的 Fedora，以應對 Fedora 生命週期較短的特性。
儘管 DR 已經很習慣在自己的個人桌機上，每隔一段時間進行這樣的更換動作。以便將系統及軟體環境維持在可獲取套件更新的狀態，並且也已經有一套既定的備份及復原流程來重建工作環境。然而若要將這樣的作法，擴大到更多機器上，心裡說實在話還是會覺得有些掙扎。反之如果發行版的生命週期可以至少有三年以上，即便系統環境可能不怎麼新，但只要夠用就好，認為會是比較理想的部署情形。
事實上 DR 先前也曾經因著某些需求，在 CentOS 7 及 CentOS Stream 8 上建置過常態性使用的桌面系統。所以其實一個自然而然可以想見的選項，就是延續這樣的世代更替，採用基於 RHEL 9 的解決方案。那麼何不就是直接採用 RHEL 9，而非其它的複製品呢？畢竟 Red Hat 所提供的開發者訂閱（Red Hat Developer Subscription for Individuals），其授權上限（16 部主機）以 DR 自己的使用情形來說，根本很難用得完。
安裝作業系統
於是在作業系統的選擇上有了方向後，接著就是具體實作的部份。首先是使用 Rufus 來製作隨身碟安裝媒體，說實在話，Rufus 真的是少數在 Linux 上找不到好用替代品的工具程式之一，也是 DR 偶然需要依賴 Windows 環境的其中一項原因。透過 Rufus 將 RHEL 9.3 的 DVD ISO 安裝映像解開到隨身碟中，而之所以是選擇體積大得多的 DVD 映像，則是因為 DR 先前曾經在安裝 RHEL 8 時，並沒有成功實現線上安裝的方式，所以後來索性都是一律下載完整的安裝映像。
05/24/2024 更新：
再次安裝新的 RHEL 9 主機，發現線上安裝可行，不過跟起初未成功的安裝經驗相比，究竟步驟上有哪些差異，則已經沒有確切的印象了。倘若是採線上安裝，則主機註冊及授權啟用程序得在安裝程式裡先完成，後續進入系統後就無須再做此設定。
雙系統的建置方式，一般來說最簡單可行的處理流程是先安裝 Windows、然後再安裝 Linux。於是先安裝 Windows 10，並直接按照 Windows 的預設方式完成磁碟分割表的分配。完成 Windows 安裝後，再運用例如 GParted 這類工具，縮減 Windows 分割區的大小，藉此重劃出未建立分割區的剩餘磁碟空間，留給 Linux 系統安裝用。
或許可以視之為是老筆電的一項優勢，讓雙系統的建置相對更加簡單：磁碟配置有蠻充分的理由不需要考量到 UEFI，因此兩部筆電的磁碟是統一採用 MBR 分割表，而非 GPT，也不用建立 EFI 分割區。在極簡的分割表規劃下，除了 Windows 10 預設建立的三個分割區外，在 RHEL 9 的安裝過程裡，只需要再建立一個分割區用於安裝整個系統。連 Swap 分割區都可以省略，之後再以檔案形式於系統中建立 Swap 即可。然後由安裝程式自動覆寫 MBR 開機啟動磁區，如此就完成了雙系統的建置，可透過開機時顯示的 GRUB 選單來選擇要進入的作業系統。
由於顯而易見的原因，Linux 使用者往往需要更加留意所使用的硬體設備，在 Linux 上的支援情形。一項最基本的判斷概念，就是 Linux 的內核（kernel）版本越新，通常就代表著支援越多的硬體，因為多數的 Linux 硬體驅動程式皆是內建在內核中；以及也可能要避免使用太過新穎的硬體設備，以防出現 Linux 尚未妥善支援的情形。不過雖然 RHEL 的產品特性並非是標榜擁有最新的 Linux 內核，然而因為安裝的對象是十年以上的舊筆電，所以反而是不錯的搭配。並沒有在這兩部筆電中，感受到有任何硬體支援上的問題，包含起初的系統安裝、顯示、音效、輸入設備、網路介面及視訊鏡頭等，看起來都是正常運作。
兩部筆電都是使用 Intel 內顯，這其實也讓顯示驅動的支援相對單純了一些。雖然 DR 自己的個人桌機已經是蠻根深蒂固地、習慣使用 NVIDIA 的顯卡。但平心而論，如果是需要建置多個 Linux 系統，那麼 DR 可能會更傾向選擇 Intel 或 AMD 的顯卡方案。因為這兩間公司都有直接投注開源碼的驅動程式在 Linux 內核中，無須像 NVIDIA 那樣需要再另外安裝封閉的驅動程式版本。儘管安裝 NVIDIA 的 Linux 驅動程式並不算麻煩，在 RHEL 上也是如此，但畢竟多一事不如省一事。
初始設定
在一般的使用情形中，雙系統其實需要稍加留意的，是作業系統同步校時的設定差異。Windows 預設是將 BIOS 時間視為本地時間，所以系統時間與 BIOS 時間之數值應會保持一致；Linux 則是將 BIOS 時間視為是 UTC 時間，然後在系統中根據時區來管理系統時間，所以倘若系統時區非 UTC+0/-0，則 BIOS 時間應會跟系統時間保持一個固定的間距。然而如果是按照前文所描述的，先安裝 Windows、再安裝 RHEL 的流程。則 RHEL 所使用的 Anaconda 安裝程式會在識別出存在 Windows 系統的情況下，將時間設定變更為與 Windows 一致的情形（BIOS 時間即為本地時間）。
所以使用者並不必然需要干涉這樣的設定結果，但需要留意這並非 Linux 的原生設定。若是在純 Linux 的機器上，應該就會看到不同的設定狀態。不過倘若是希望 Windows 配合 Linux 的原生設定，那麼首先就是在 Linux 系統上復原為預設值：
- sudo timedatectl set-local-rtc 0
然後在 Windows 系統上，透過登錄機碼的修改，將 Windows 變更為與 Linux 一致的機制（BIOS 時間為 UTC 時間）。
另一方面，如同前面曾提及過的，Swap 分割區並不是一個必要的存在。也是可以使用替代方式，在 Linux 檔案系統中建立一個 Swap 檔來用：
- sudo dd if=/dev/zero of=/swapfile count=8192 bs=1MiB
- sudo chmod 600 /swapfile
- sudo mkswap /swapfile
- sudo swapon /swapfile
完成檔案建立後，再編輯 /etc/fstab，使其在一開始開機時便掛載起來：
/swapfile swap swap sw 0 0
接著就是關於套件安裝的功能，以 RHEL 來說，首先需要做的，便是對主機進行註冊動作：
- sudo subscription-manager register
在這個步驟中，輸入有效的 Red Hat 帳號及密碼。完成主機註冊後，倘若是新建立的 Red Hat 帳號，則應在 Red Hat 用戶後台裡，確認是否已停用可能是預設啟用的簡單內容存取（Simple Content Access）功能，否則後面的步驟會無法操作。然後執行以下指令：
- sudo subscription-manager list --available
在前述指令的輸出清單中，找尋「Red Hat Developer Subscription for Individuals」這一項目之 ID，接著便執行下列指令，以開發者訂閱啟用授權：
- sudo subscription-manager attach --pool=<ID>
完成前述操作後，用於管理系統及軟體套件的 dnf 工具應已可用。除此之外，GNOME 桌面環境還有內建一個名為【軟體】（Software）的圖形化管理程式。但其實 DR 從來沒有使用過它，甚至覺得它的自動更新檢查功能反而是個干擾……所以會先進入到該程式的偏好設定內，將更新檢查的相關設定皆停用，一律由使用者手動檢查及安裝更新。
sshd 服務預設是啟用的，以桌面系統來說，使用者應該會傾向將其停用，視需要再開啟。此外，在 Red Hat 生態裡相當常見的 SELinux 安全性增強模組， 在 RHEL 9 裡自然也是預設啟用的。SELinux 或許可以說是 Linux 內核中，最接近防毒軟體概念的內建機制（指的是行為限制這一層面，而非掃描引擎）。不過就桌面使用的領域而言，應該是不太會遇到跟 SELinux 有關的障礙。倘若真的遇到了，就參照彈出警示內的 SELinux 疑難排解工具（sealert 的 GUI），從中獲取細節並檢視若要給予許可的操作流程。
軟體安裝
除了 RHEL 內建的套件庫來源以及 EPEL 外，以桌面系統的需求來說，RPM Fusion 和 negativo17.org 都是可以考慮加入的第三方套件庫。然而即便有其它額外套件庫的輔助，就軟體套件的豐富性及完整性來說，RHEL 跟 Fedora 相比依然還是有不小的落差。在桌面使用的情境下，可能蠻容易就會發覺到，某些軟體套件在 RHEL 上是不存在的；也有些軟體套件雖然存在，但實際上有點問題，好像套件的志願維護者在組建完畢後，並沒有認真測試究竟在 RHEL 上能否正常使用。而前述的情形，也會一致反映在 RHEL 的開發預覽版本或複製品上，如 CentOS Stream、AlmaLinux 或 Rocky Linux 等發行版，按理講並不會有什麼差異。
總歸來說，其實這應該歸因於，並沒有太多人認真關注 RHEL（及其複製品） 的桌面應用性。一套系統、軟體或者是產品的生命力，某方面來說就像是希臘眾神的觀念，一個神祇的信眾越多，祂的力量就越強大，反之則是減弱甚至是消亡。同樣的觀念也可套用在軟體或功能的發展上，當越多的使用者給予更多的反饋，無論是功能建議，或者是問題修正，都會促使軟體變得更加強大。那麼以 RHEL 的情形來說，關鍵就在於，並沒有很多使用者將其作為日常的桌面系統來使用。使得它在這一領域，對照其它的發行版，無論是 Red Hat 自家的 Fedora，或者是 Ubuntu 等等這些，恐怕就不容易有很一致的體驗。
不過除了設法從套件庫取得需要的軟體外，一種可行的替代方案，就是使用 Flatpak 作為軟體的安裝來源。然而若要將 Flatpak 視為是一種萬靈丹，或許也不盡然。Flatpak 嘗試與系統環境脫鉤的封裝方式，在某些情況下，也有可能會讓使用者遇到新的問題。且另一方面，其實傳統使用 yum/dnf 套件管理工具的作法，經常也可以視為是一種提昇系統函式庫完整性的便捷手段。因為軟體若是透過此方式安裝，就能夠連帶把許多相依的函式庫也一併安裝到系統上。讓其它有著類似依賴、但非以 RPM 套件或 Flatpak 方式安裝的應用程式也可以順利運作，從而減少需要詳查其依賴函式庫的情形。
此外在開放原始碼的軟體生態中，自然而然可以想到的終極解決方案，則是自行從軟體原始碼編譯及安裝。例如在本站的另一篇文章裡，可以看到 DR 是索性採取自行編譯的方式，來安裝 Wine 這款 Windows 應用程式的相容工具。然而若要在 RHEL 上自行編譯軟體，這又是一個與 Fedora 有些許差異的地方。在 RHEL 9 上，需要再特別啟用一個名為 CodeReady Linux Builder 的套件庫，才能夠從中獲取許多在編譯時依賴的開發套件（*-devel），啟用指令如下：
- sudo subscription-manager repos --enable codeready-builder-for-rhel-9-$(arch)-rpms
那麼在這些各種的解決方案下，究竟 RHEL 9 能否順利構築出具有廣泛可用性的桌面操作環境？其實是可以的。首先在現今這個世代裡，桌面系統中最重要的應用程式無非就是網頁瀏覽器了。RHEL 本身即有提供長期支援版的 Firefox ESR，並不需要再另外安裝。以及如果有需要使用 Google Chrome（畢竟偶然還是有一些非它不可的時候），則 Google 也有提供相容於 RHEL 的 RPM 套件庫，安裝及使用並無問題。
LibreOffice 是跨平台的開源辦公軟體解決方案，同樣可見於 RHEL 上。倘若有需要使用多媒體播放程式，則 VLC 應該是可以滿足幾乎所有的影音播放需求，且在 RHEL 上也有不只一種來源可以獲取此播放軟體。繪圖軟體方面，RHEL 的套件庫即有提供 GIMP 和 Inkscape，以及 Krita 也可以透過 Flatpak 安裝起來。至於在程式設計的領域，如果是需要好一點的程式碼編輯器，那麼例如 Visual Studio Code 也是有相容於 RHEL 的 RPM 套件庫可使用。
除此之外，雖然 RHEL 相較於一般的 Linux 桌面發行版，很顯然並不是以遊戲休閒為預期可能的使用領域；但與此同時，它也並沒有存在任何技術上的限制，讓使用者無法將其打造成可執行電玩遊戲的環境。只要借助第三方的安裝來源，最起碼 Steam 的 Linux 客戶端是可以成功安裝及執行的，如此一來基本上就已經滿足了現今在 Linux 上玩遊戲的最主要條件。不過當然在雙系統的配置下，在 Windows 上玩遊戲顯然是一種選項。然而在 Linux 上能夠做到的事情，DR 總還是會傾向優先在 Linux 上實現。
遊戲應用
之所以再針對遊戲應用做進一步的描述，是因為 DR 總是認為，若要實現一個具真正泛用性的電腦使用環境，則能不能拿來玩遊戲，是一項非常重要的指標……不過也必須要考量到這兩部老筆電的硬體規格，再加上都是純 Intel 內顯，估計純粹 2D 的遊戲是較能夠負荷的範疇；需要仰賴 GPU 的 3D 遊戲則得是比較久遠的舊作，才或許是可行的選項。而這年頭若想要快速地測試電腦的 3D 效能，其實可能也不太需要額外安裝應用程式。單純地利用像是《Slow Roads》這樣的網頁 3D 遊戲，自動駕駛開起來讓它跑。倘若在預設畫面效果下都執行得有些吃力，那麼就表示電腦的 3D 效能恐怕不能夠太過期待。
仍是有一些經過實際驗證、確定可以順暢執行的 3D 遊戲。就如前面所描述的，直接尋覓較老的遊戲是比較可行的對策。比方說《浴血戰場》（Unreal Tournament，1999），使用由社群接手維護的跨平台版本（OldUnreal）；以及《夢幻遙控車》（Re-Volt，1999），同樣安裝社群版本（RVGL），就可以無痛地在現代的系統環境中執行，包含 RHEL 9 在內。至於若是要建立區域網路下的多人遊戲連線，則需要留意 RHEL 的防火牆規則，或者是索性將 firewalld 服務先行關閉。
RHEL 9 也是一套預設使用 Wayland 而非 X11 的 Linux 發行版。雖然 DR 也是期望自己能夠與時俱進、適應新的技術，而不是死守在舊技術上。但是在嘗試了一陣後，目前還是決定切換回 X11（編輯 /etc/gdm/custom.conf，#WaylandEnable=false 取消註解 ）。原因是在遊戲應用的情境下，DR 還是覺得在 X11 環境中遇到的狀況比較少，也比較容易解決問題，比方說可以利用 xrandr 來調整桌面解析度。尤其是在使用模擬器、或者是使用 Wine 相容工具來執行遊戲的情況下，則 X11 上的運作情形覺得是比 Wayland 要好一些 。
結語
無論是在 Red Hat 生態體系、或者是整個 Linux 發行版生態中，或許都沒有足夠決定性的理由，優先選擇 RHEL 作為日常泛用的桌面系統環境。尤其是 RHEL 本身的市場定位也不在此，是以企業用戶、伺服器及專業工作站為主。而且良好的桌面體驗，與追求減少變動的系統環境之間，兩者也經常是存在著衝突的概念。
然而這是否是一個可行的選項？結論則是肯定的。某些環節或許相形之下比較麻煩，但最終來說，RHEL 能夠實現的使用者體驗，與其它的 Linux 發行版並沒有根本的差異。而可見的一項優勢，即是它本身是一個平穩、不太變動的系統載台。並且有著較長的維護週期，同時也有途徑可以容許較具變動性的應用程式在當中運行。
如果說是因為必須要擁有授權的緣故（姑且不論開發者訂閱這一選項），讓 RHEL 較難成為使用者建置 Linux 桌面系統的選擇之一。那麼最至少本文的經驗，估計也能夠適用在諸如 CentOS Stream、AlmaLinux 及 Rocky Linux 等等這些與 RHEL 基本雷同、且無須授權的發行版上。
