在今年初執行本站 CMS 從 Drupal 7 升級至 Drupal 10 的作業後，目前剩下的待處理問題，主要多是與管理後台有關的疑難雜症，反之訪客可見的網站前台問題則多數均已消弭。於是覺得好像是時候可以回頭敘述一下，除了大幅度的 Drupal 版本升級外，其實還曾經考量過哪些可能的作法。
在剛開始用 Drupal 7 架設本站的頭幾年，其實並沒有立即預估，網站系統的下一次改版，就是將 Drupal 版本再往上升級。相反地，曾經有一度期盼可能下一次改版會改用基於 Python、比方說 Django 框架的技術來架設網站。這是因為 DR 對於 Python 的使用量還蠻大的，覺得如果能夠在各種需求上採用更加統一的程式語言，那麼會是個頗具吸引力的構想。然而這個思緒隨著時間逐漸淡化，部份原因可能是因為自己始終沒有生發出足夠認真的工作計畫，來投入到用 Python 架設網站的技術領域中；與此同時，對於 PHP 網站架設的概念則是越加熟悉，轉換作法的動力與企圖也就跟著降低不少。
某方面是延續著前一篇文章的議題，在當時的工作經歷裡，VPS（virtual private server）主機也是公司的產品之一。而其具體的組成方式，是導入某個商務套件程式，藉此將 Linux KVM Hypervisor 伺服器打造成可對外販售 Windows 或 Linux 虛擬機（virtual machine，VM）、並且進行租戶管理的形式。
當作為一名新人工程師進入到一間經營許久的資訊公司，菜鳥屬性勢必是存在的，或多或少的差異而已。然而卻頗為驚訝地發現，至少就 QEMU/KVM 虛擬化這項領域而言，似乎是大家都一致地有些生疏，或者是沒有什麼人認真地關注它的細節。儘管公司的 VPS 產品服務也已經營運了數年，但實際上並沒有建立多少完善的知識體系。除了必須得自己從頭自學以前還未碰過的東西外，還必須試著解決一些累積的問題及懸案。
雖然 DR 自己的個人網站是使用 Drupal 架設，並且在近期因著版本升級的緣故，又陸續找時間做了許多調整措施。然而回想起來，其實在自己過去的工作經驗裡，接觸過最多的 CMS 是 WordPress，其次則是 Joomla。而這些經驗多數是來自於 DR 幾年前在雲端主機商做工程師的期間，因為虛擬主機（shared hosting）服務是公司的主力產品之一，並且有許多租戶是在虛擬主機上使用 CMS 來架設網站。
或許有人會有所預估，儘管虛擬主機是多租戶共用同一個網頁、資料庫及郵件伺服器，不過在給定的帳號權限區隔及資源配額下，如果租戶的網站配置有所缺失，那麼最多影響的是租戶自己的網站，而不會損害到整個基礎設施。然而實情並非如此，在各種可能發生的損害狀況裡，以下會列舉幾個還算相對單純的案例。
印象中好幾年前 DR 曾經有做過一次以電話啟用 Windows 授權的程序，所以這是一個有自身經歷證實可行的作法。後來就未曾再執行過，直到近期，公司有一部電腦的主機板故障，因此將核心零組件整個更換。更換後原先所配附的 Windows 10 Home 產品金鑰便無法直接生效。並且該金鑰也並未綁定在帳戶下，無法透過帳戶登入的方式轉移。於是便嘗試使用電話啟用的方式處理。
在 Windows 的電話啟用表單裡，選擇台灣地區後，所顯示的多組電話號碼，大致分成免付費電話的自動語音服務，以及付費電話的真人客服支援。由於 DR 許多年前的那次經驗，記得是與中文客服通話，應對過程蠻流暢的，所以還是傾向於優先採真人客服的方式。然而似乎總機設定有問題，實際上是撥不進去的（即便是在平日上班時間），所以只能改撥打提供自動語音的電話（00800-2468-1668）。
前一陣子試著對 ScummVM 回報一項問題，雖然 DR 僅是回報問題而已，並非是最終找出問題肇因、並且修正問題的貢獻者。然而在過程中則發掘到一些似乎是前所未聞之事，相當罕見，好像是應該稍微記錄下來。
首先是不知何故，除了首頁以外，DR 始終沒有辦法檢視 ScummVM Issue Tracker 網站上任何進一步的功能頁面，也就無法查看問題清單，以及提交 Bug 報告。因為一律都會出現以下的純文字輸出訊息（時間日期則會異動）：
HTTP/1.1 NoneServer: gunicorn
Date: Sun, 29 Dec 2024 13:47:20 GMT
Connection: close
自從 2011 年的 Fedora 15 發行版採用了 GNOME 3 桌面環境後，DR 自己就頗為認份地接受了它的多項變化。而其中最主要的變革核心，就是 GNOME Shell，也就是 GNOME 桌面環境從第 3 版起引入的主介面，取代了傳統的工作列及選單列，用於控制視窗的編排與切換，以及應用程式的啟動與關閉。
話說上週某日發現二號機開機開不起來，有啟動但無嗶聲，鍵盤及螢幕皆無訊號。將顯卡及記憶體拔除測試，也都未有相應的嗶聲，用別顆電源供應器測試也是如此。按此情形，認為主機板故障的可能性較高。然而這顆 CPU（AMD FX-8350）已經用了超過十年，主機板也曾經在 2020 年做過更換。讓 DR 覺得如今已經到了應該要大幅升級的階段，而不是再去找二手主機板來換。
於是隨即開始上網挑需要的組件，來實現這個睽違了十年以上的重度翻新。任務目標是以最快速度、以及可控的成本（畢竟這是一筆非預期的開支），讓二號機回復成可運作的狀態，並一定程度考量未來的升級彈性。採買的組件如下：
雖然標題是這樣寫，但其實本文很大程度應該算是偏綜合性的雜談，只是 RHEL 9 在當中佔了蠻重要的份量。故事的起頭，是在物盡其用的訴求下，前陣子開始在規劃，如何將還堪用的舊筆電（十年以上），重新打造成在硬體規格尚可負荷的前提下，能夠迎合日常各式電腦使用需求的狀態。進行試驗的兩款筆電型號，分別是一部 Lenovo ThinkPad X230 Tablet（CPU i7-3520M），以及一部 Toshiba Portege R830（CPU i3-2350M），儲存媒體皆更換至 1TB SATA SSD，以及記憶體皆更換至 8GB（DDR3 4GB * 2）。
在《The beauty of finished software》這篇文章裡，作者以《冰與火之歌》（A Song of Ice and Fire）系列的小說原作者 George R. R. Martin 為例，GRRM 長年以來，一直都僅僅使用古老的 DOS 文書軟體 WordStar 4.0 來進行寫作。這表示在某些情境下，當軟體滿足了實用性的需求，一經設計完成，其實就不太需要什麼改變，使用者可以長久地使用下去。其它類似的案例，還包含了知名編劇 Eric Roth，也是長年使用一款古老的 DOS 軟體 Movie Master 來編寫劇本，同樣沒有隨著科技的日新月異而有所轉變。
最近讀到 Ars Technica 網站的一篇文章《I abandoned OpenLiteSpeed and went back to good ol’ Nginx》，其內容勾起了 DR 幾年前在虛擬主機商做工程師的一些回憶。呃，所以本文並不是要對該文章所涉及的技術議題做出回應；而是想借題發揮，在分享該文章的同時，順便陳述自己當年曾經遇到的一個網站效能異常問題。