筆記

最近在二號機上使用 Wine 或 Proton 執行 Windows 遊戲時，無論是 2D 還是 3D 遊戲，都發現容易在連續玩了數小時後出現當機情形（畫面凍住，整個主機沒有反應）。於是經過觀察並且做了一些比對後，認為可能是 CPU 熱當。因為觀察到 CPU 在前述的使用情境下，單一執行緒的使用率會持續滿載，而 CPU 溫度也會隨之上升，然後在一段時間後就有可能會發生當機情形。然而其它的使用情境，例如原生的 Linux 遊戲，則負載看似相對平穩，未重現出相同的狀況。

看到電腦鍵盤就想要亂按一通，好像是許多小朋友都會做的事。話說某日家裡的小朋友，不知怎麼辦到的，在鍵盤上按著按著，就觸發了 GNOME 桌面環境的放大鏡功能。由於 DR 平常並未使用這項功能，所以一時之間也不曉得要怎麼按，才能夠切換回正常的畫面。於是當下便想說直接登出再登入試試看，結果狀況反而更糟……變成登入時會出現不明的錯誤而無法進入桌面。即便重啟系統（Fedora 38）後再嘗試登入也是一樣，似乎是遇到了某種未知的 Bug。

原本認為可能得要找到某個使用者設定檔，然後直接砍掉試試看。不過上網查了一下，發現 GNOME 有提供一支名為 GSettings 的命令行工具，可用於變更 GNOME 的設定值。舉例來說，以下指令能夠列出 GSettings 的所有可設定項目：

• gsettings list-recursively

接著，下列指令能夠列出放大鏡功能的啟用狀態：

話說 DR 已經有好一陣子，沒有嘗試用 Steam Linux 客戶端的 Proton 相容層來執行 Windows 遊戲了。雖然近期多少還是有在 Steam 上，簡單地玩了幾款遊戲。不過多數都是有提供原生的 Linux 版本，所以就無須透過 Proton 相容層來執行。然而最近也入手了《GigaBash》這款遊戲（至於入手的原因則顯而易見，因為有哥吉拉 DLC 啊……），儘管它並無原生的 Linux 版本，不過就網路上可見的資訊來看，應該是能夠透過 Proton 來執行的。

採開放原始碼（open source）授權條款的字型，就如同於開源碼的軟體程式，對一般使用者來說，基本上就是代表著能夠自由地使用這些字型。雖然 DR 過去主要都是憑印象，記得有哪些開源字型可用，然後在有需要時就會找來用。然而久而久之，覺得記憶力也是有衰敗的風險。所以本文的目的，便是將印象彙整成簡單的清單以便日後查詢，不過並未追求要把清單做到很完整或者是鉅細靡遺。

中日韓（CJK）字型：

由於已事隔快要一年，看起來狀態並沒有什麼變化，所以或許是時候說明一下狀況，以及可行的應對方式。在目前 Red Hat 生態體系的各個 Linux 發行版裡，倘若要實現 WireGuard 支援，則 CentOS Stream 8（以下簡稱 CS8）可能是當中最不簡便的一款發行版。而背後的因素，其實也連帶影響了下游的 RHEL 8 及其複製品（AlmaLinux 8、Rocky Linux 8 等等），只是就時序而言，下游的處境可能會稍微好一點。

有別於先前的 RHEL/CentOS 7/8，這回 RHEL 9 因為 Linux 內核版本較新（5.14）的緣故，已內建對於 WireGuard 的支援。而無須再找尋第三方套件庫，或者是得動手自行編譯模組。所以同樣的支援狀態也適用於 RHEL 的複製品，如 AlmaLinux 及 Rocky Linux 等。

最近讀到一則來自 AdGuard 部落格的消息《EasyList is in trouble and so are many ad blockers》，其內容描述 EasyList 這個由社群維護的廣告過濾清單，近期曾一度因為過多的連線請求，形成就像被 DDoS 的情形而變得難以存取。而問題的來源，似乎是印度地區的某款 Android 網頁瀏覽器存在設計缺失，會以不正常的頻率反覆下載該清單，而造成嚴重的流量負載。

像這樣的案例，倘若技術條件可行，也許在必要時得先暫時封禁特定的地區，讓其它地區的用戶不致受到影響，直到問題的來源消弭為止。而這也讓 DR 想起自己幾年前在虛擬主機商做值班工程師的一個故事。不過在此之前，DR 得先描述一下背景，以便讓人瞭解為什麼當下似乎只能採取這種作法。

很難預想到，即便在 2022 年的現代作業系統中，仍然會遇到與古老 Big5 編碼有關的問題。然而就 Windows 來說確實是如此，時至今日為止，至少在隨處可見的 Windows 10 繁中環境裡，其預設的環境編碼依然是 CP950（微軟自行維護的 Big5 實作）。因此根據壓縮軟體的具體實作而異，所生產出來的 ZIP 壓縮檔，寫入的檔名清單不盡然都會是 Unicode，也有可能依然是 CP950。

延伸閱讀：libarchive 函式庫關於檔名處理的說明文件。

倘若因某些緣故，發生 Linux 系統的 UEFI 開機失效，使得無法順利進入作業系統。那麼可參考以下流程，來進行 UEFI 開機程式重新安裝的動作。本文範例是以 CentOS Stream 8 為操作環境，使用此發行版的安裝映像檔做開機，然後進入救援模式。接著設法讓安裝在磁碟中的相同發行版，回復至可順利啟動的狀態。

若是使用同為 Red Hat 生態體系下的 Linux 發行版，操作流程應會相當一致。至於其它的 Linux 發行版本，則至少在概念上也是相同的。

1. 進入救援模式

按理講 USB 隨身碟應該被視為是一種消耗品，是僅供臨時性的資料移動，而非講究保障的資料儲存方案。但……如果裡頭真的有資料想要救援呢？話說前陣子 DR 拿到一顆 128GB 的隨身碟，是處於無法開啟的狀態。雖然裝置本身偵測得到，但在 Windows 或 Linux 系統上，分割區實際上都無法順利掛載。其中以 Linux 來說，就是即便手動做 mount 也會直接卡住不動，也就無法讀取裡頭的檔案。

嘗試使用 ddrescue 做區塊複製，例如以下指令是將 /dev/sdb 複製到名為 rescued.img 的映像檔：

• ddrescue -f -r 1 -n -v -d -b 512 /dev/sdb rescued.img recovery.log