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 7CentOS 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 Fusionnegativo17.org 都是可以考慮加入的第三方套件庫。然而即便有其它額外套件庫的輔助,就軟體套件的豐富性及完整性來說,RHEL 跟 Fedora 相比依然還是有不小的落差。在桌面使用的情境下,可能蠻容易就會發覺到,某些軟體套件在 RHEL 上是不存在的;也有些軟體套件雖然存在,但實際上有點問題,好像套件的志願維護者在組建完畢後,並沒有認真測試究竟在 RHEL 上能否正常使用。而前述的情形,也會一致反映在 RHEL 的開發預覽版本或複製品上,如 CentOS Stream、AlmaLinuxRocky 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 的套件庫即有提供 GIMPInkscape,以及 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 基本雷同、且無須授權的發行版上。

 

 

分類: