在本年度由東寶所舉辦的哥吉拉慶祝活動（Godzilla Fest 2022）裡，是以《哥吉拉對蓋剛》（Godzilla vs. Gigan，1972）的 50 週年紀念為主軸，發表了兩部新製作的短片。首先是《哥吉拉 VS 霸王蓋剛》（Godzilla vs. Gigan Rex），可以直接在官方的 YouTube 頻道上觀看。

前陣子先後讀到兩篇關於自架郵件服務的感想文章，看完後感觸蠻多的。當年 DR 在開始接觸 Linux 時，一個令人印象深刻之處，就是 Linux 可以用來架設許多服務。然而其中關於郵件服務這一塊，在瞭解其組成與各樣條件後，DR 很早就覺得這是個沒事不要自己架的東西。個人就用免費郵件服務，中小企業或機構需求則購買郵件代管，會省事很多。

Chris Siebenmann 是任職於多倫多大學的 Unix 系統工程師，在他所寫的文章《Running your own email is increasingly an artisanal choice, not a practical one》裡，Siebenmann 客觀地描述，儘管他至今依然在維運著自行架設的校園郵件服務，而這樣的作法雖然擁有高自訂性，以及獨立自主的優勢；但對比大型廠商所能夠輕而易舉達到的服務品質，已經不是一個很務實的選擇。

繼續趁著 Amazon Prime 的試用期間看下一部片，《明日戰爭》（The Tomorrow War）是一部 2021 年的科幻動作電影。由於科幻題材向來都是 DR 偏好的類型，所以對於科幻片的接受度通常都蠻高的，不會那麼挑剔。然而看完後 DR 卻覺得這部電影沒上院線應該是有考量的，如果上院線則票房很可能會炸掉……

本片故事的主架構，是未來世界受外星生物襲擊，出現嚴重的兵力不足而瀕臨人類滅絕危機。於是透過蟲洞回到過去，從過去徵召士兵傳送到未來參戰。倘若論原創程度，那麼本片的原創性並不是很高。故事的主軸雖然還算有特色，但其餘的許多元素都很容易讓人聯想到其它作品。然而其實有原創性與否也不是一個很大的問題，而是在於故事本身是否說得好。

話說原本只是要在 Amazon 上買個東西的，結果一時沒注意，點選到 Prime 試用，就這樣啟用了 Prime 會員。但也是這樣才知道，原來 Prime 會員就包含了 Prime Video 服務，實在是孤陋寡聞。儘管是非預期地得到一個未曾使用過的影音平台服務，但 DR 幾乎是立即地就想起《十三條命》（Thirteen Lives）這部在 Prime Video 獨家上架的電影。雖然實際上它的播映權限是有地區限制的，不過這就是自架 WireGuard 派上用場的時候了。

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

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

對普遍的台灣觀眾來說，在觀賞各種戲劇時，搭配字幕應該算是件非常習以為常的事。然而對於許多美國人來說就不是這樣了，所以一旦無法清楚地聽到電影中的對白，勢必會產生許多困擾。因此，來自 Slashfilm 網站的文章《Here's Why Movie Dialogue Has Gotten More Difficult To Understand》，特別探討何以近年來似乎有越來越多的電影對白難以聽得清楚。

文章中詳盡地涉及到許多面向及案例，倘若姑且在此粗略地加以歸結，則大略可分成幾個環節。首先就某些案例來說，這是刻意為之的創作考量，可能是為了增加場景或人物的真實感，或者是為了更加符合當下劇情的氛圍。以及演員的演出，也可能是以更加自然而非劇場性的方式表現，那麼其口條就未必會這麼地清晰。

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

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

故事的起頭是這樣的，話說 DR 手邊有一項任務需要處理大量的表格資料，為此便寫了一支 Python 程式。然而這支程式的資料迭代過程有一項設計缺失，會導致已經處理完並存檔的資料，仍持續累積在記憶體裡，造成程式的記憶體佔用量持續升高。當 DR 隨意地用 htop 查看系統資源時，才赫然發現若按照這個累積速度，恐怕二號機上的 16GB 記憶體會被整個吃光。但當下又不太想讓它重跑，於是就硬著頭皮看著它跑完。果不其然，在整個執行過程中，系統記憶體一度接近耗盡，連 swap 都用上了。

程式沒寫好雖然尷尬，然而轉念一想，若寫一支能夠刻意把記憶體吃光的程式，似乎對於某些情境是有意義的，像是用於測試系統高負載情形及設備可靠性等等。於是順手另外再寫了一支腳本程式（mem_consume_test.py），來專門實現記憶體的消耗。這支腳本係針對 Linux 平台設計，對於記憶體使用量的監控是從 /proc/meminfo 中的數值計算而成。

由於 Red Hat 提早結束了 CentOS 8 的生命週期，並且讓 CentOS 這個品牌從 RHEL 的免費版本，轉型成為 RHEL 的上游開發版本，也就是 CentOS Stream。使得原本許多 CentOS 的使用者，必然會需要思考合適的替代方案。雖然人們似乎會自然地關注諸如 AlmaLinux 及 Rocky Linux 這些比照原本 CentOS 模式，從 RHEL 原始碼重新編譯而成的發行版本。然而說實在話，DR 並不認為需要就此將 CentOS Stream 從可行的選擇清單中剔除。因此在過去一年多的時間裡，DR 在工作環境裡建置了幾部 CentOS Stream 8 主機，而本文即是維運至今的一些感想。