筆記

最近因故覺得有必要釐清主機板 BIOS 內，Above 4G Decoding 及 Re-Size BAR Support 這兩項設定，對於 Linux 遊戲執行狀況的影響。特別是 NVIDIA 獨顯視訊記憶體（VRAM）的消耗、以及與之相關的錯誤情形。雖然最終是未能得出清楚的結論，可能要看日後是否有更合適的環境條件再做研究。但由於 BIOS 操作過程中有發覺到一些其它的事情，所以在此筆記下來。

即如標題所示，DR 最近開始體會到這會是個問題……因著各種不一的因素，有些時候可能會遇到主機設備上存在著非常陳舊的 SSH 服務。它所支援及啟用的加密演算法，在較新的 Linux 系統上，若嘗試以 OpenSSH 的 ssh 客戶端指令連線過去，會出現例如以下錯誤：「no matching host key type found. Their offer: ssh-rsa,ssh-dss」。而這些陳舊設備裡，有些是 Linux、也有些是某種封閉系統。其中後者即代表它的軟體環境是無法被更動的，連線障礙無論如何都只能從客戶端解決。

由於這項需求的發生頻率相當低，很難維持記憶力。所以曾寫了一份內部工作筆記，讓自己在一旦有需要的時候，可以看著筆記來操作。不過最近則意識到若改放置在自己的個人網站上，檢視起來是會更加方便。所以也請留意，以下其實是非常個人化的文字筆記（寫給自己看的）。它可能不是最佳實踐方法，也非圖文並茂、或者擁有鉅細靡遺的知識內容。倘若有進一步想要瞭解之處，則會建議找尋網路上的其它教程或說明。

製作流程如下：

本站部份的文章內容可能多少都曾提及過：Mozilla Firefox 是 DR 個人在 PC 上最主要使用的網頁瀏覽器，而且是自 2004 年的 1.0 版就開始在用了。Google Chrome 雖然也會用到，但就不是當成主要的瀏覽器來用。然而這並不因此表示，DR 對於 Firefox 歷代版本以來的所有變革都是照單全收。相反地，有一些改版變化，自己都還是傾向再手動回復成舊版的面貌。也幸好這些復原途徑始終存在，所以依然可以按照自己以往的習慣來操作瀏覽器。

於是本文接下來便是一份簡短的清單，算是呈現出 Firefox 有哪些變化項目，其實恐怕並不是很迎合自己的使用習慣，同時也一併說明相應的復原方式：

每到報稅季就要在電腦上插健保卡來驗證身份及報稅，這已經是每年固定會做的事。然而由於 DR 在家裡最主要使用的桌機系統，大概也是每年都會換裝一個 Fedora 發行版。所以 Linux 版本的健保卡驗證程式（mLNHIICC）及其依賴套件都得再重裝一次（相關文章見此）。於是在今年安裝了 Fedora 42 後，其實又是再一次面臨了 mLNHIICC 程式相依性無法直接滿足的情形。因為即便是 mLNHIICC 的 20240710.1 版本，也仍然依賴於已經停止維護的 OpenSSL 函式庫 1.x 版。在 mLNHIICC 安裝完畢後，可使用以下指令的輸出結果來確認此情形，若缺少該函式庫也就實際上無法執行起來：

• ldd /usr/local/share/NHIICC/mLNHIICC

手上有一台塵封好些日子的老筆電 Aspire ES1-331-C2DE，CPU 為 Celeron N3160。之所以塵封起來，是因為起初回收到它時，經過排查便發現它是自身的螢幕故障，有訊號但已無法正常呈像，不過外接 HDMI 介面則是可用。由於筆電若螢幕無法使用，就失去了可攜式的用處。除非找得到料件來更換螢幕，否則 DR 就覺得它沒有什麼使用的意義，也否決了把它當桌機來使用的提議。然而最近重新評估手邊的可用物資，轉念接受了自己曾經否決的想法。於是就將這台筆電的螢幕拆除，用分離的外接螢幕與它搭配，就當成某種特殊的桌機來使用。

這個起因是赫然發覺在 Linux 系統上，倘若存在不只一個 Wi-Fi 無線網卡，則 NetworkManager 似乎截至目前為止，並沒有提供任何操作方式，能夠很便利的暫時性停用（及回復啟用）其中一個無線網路介面。要就是整個無線網路關閉，而沒有關閉特定裝置的選項（至少 DR 在 Fedora 40 發行版上研究了一陣的結論是這樣）。所以倘若有此需求，基本上還是得回歸最基本的網路控制指令，例如：

• sudo ip link set down <無線網卡介面>
• sudo ip link set up <無線網卡介面>

於是就設想了一種將其腳本化的方式：networking_control.py。此腳本設計並不要求帶入參數，會以選項清單的互動方式呈現。在給予可執行權限後，便以 root 權限執行即可：

無論是出於什麼樣的原因而使用了 RHEL（或者其複製品），這款發行版在使用上的一項挑戰，就是它字面上的 Linux 內核版本，無法準確地反映出它實際的內核狀況。比方說 RHEL 9 的內核版本乍看之下為 5.14，但它實際上還包含了許多由 Red Hat 從其它較新的內核版本裡所移植的異動。這使得第三方的內核模組，比方說特定硬體裝置的驅動程式，倘若要妥善地支援及應對 RHEL 的內核變化，基本上很難不透過一連串的試錯（排除編譯錯誤），以及加入許多額外的條件判斷來實現。

過去這一陣子終於將手邊最後的 CentOS 7 及 CentOS Stream 8 系統皆全數替換掉，其中多數是採取服務遷移或者原機重灌，以 RHEL 9 取而代之，至於測試或者非正式用途的機器則是使用 CentOS Stream 9。不過也有兩部 CentOS Stream 8 主機，是使用 Red Hat 所提供的 Convert2RHEL 工具程式，以沒有做任何重灌或遷移的方式，原地轉換至 RHEL 8。由於這似乎不是很常見的需求，網路上並沒有許多可見的使用案例，但還是可以找得到一些文件說明可加以參考。

許多一般家用型、採 Wi-Fi 無線網路連接的網路監控攝影機（IP camera）都具備 RTSP 串流輸出的功能。所以除了預設的本機儲存能力外，其實也可以考慮啟用此功能。然後在區域網路中的其它電腦主機上，常態性的從攝影機接收 RTSP 串流，並儲存成檔案，來實現某種即時的遠端錄影備份。雖然這並不是一項很認真的需求，只是根據手上有的設備做試驗，但還是想看看這樣的作法是否容易實現。

結果並沒有如預期般的單純，在 Linux 主機上若是以腳本程式搭配工作排程的方式執行 FFmpeg，例如在腳本中執行以下指令：

• ffmpeg -loglevel error -i <RTSP 來源位址> -y -vcodec copy -an -t <錄製長度> <輸出的 MKV 檔案> > <輸出的日誌檔> 2>&1