資訊技術

好像還未曾在其它地方見過，有像《FFmpeg - Ultimate Guide》這樣長篇幅又深入淺出的 FFmpeg 教學指南。雖然有關於 FFmpeg 的筆記，本站大概已經寫過蠻多次了。不過 DR 自己依然不是 FFmpeg 專家，通常就是把指令兜到可以用，就寫成腳本固定放在那邊跑了，對於其運作細節也稱不上熟練。所以每次若是有什麼新的需求，都很需要再查找筆記或線上文件。

儘管 FFmpeg 採命令行介面的操作方式，乍看之下可能並不是很平易近人。然而其功能非常強大，正如指南中所揭示的，除了基本的影音格式轉換外，能夠實現的多媒體處理任務也相當多樣。如今在 DR 日常的工作需求裡，其實 FFmpeg 也已經是變得不可或缺，已常態性的運用在諸如設備直播及錄影等項目中。

最近找了個空檔將二號機上的 Fedora Linux 發行版，以重新安裝的方式，從 36 升級到 38。而處理過程中讓 DR 想起，其實去年 Fedora 社群有一項變更提案，曾讓 DR 頓時感到有些愁煩。所幸最後的投票結果是一面倒的駁回，而沒有付諸執行。這項提案的內容，是希望自 Fedora 37 起，安裝程式便不再支援傳統的 BIOS 韌體，而一律只能在 UEFI 韌體下進行安裝（見 Changes/DeprecateLegacyBIOS）。

似乎很少看到有文章認真地探討，該如何適當地撰寫軟體系統中的錯誤訊息。來自 Wix UX 團隊的文章《When life gives you lemons, write better error messages》，描述了 Wix 網站平台如何對錯誤訊息的表達做出檢討，擬定新的原則，並投注心力加以改善。

這是一篇很值得一讀的文章，雖然當中的概念，主要是針對一般用戶，可能不一定都適用在不同的情境中。比方說在微軟產品裡，經常是僅僅丟出一長串的錯誤代碼，讓使用者自己按代碼去搜尋解答。儘管這確實應該是有改善空間，不過採用錯誤代碼的方式，背後應該也是有其工程考量。而非蓄意的怠惰，然後把麻煩轉嫁在使用者身上。

在 DR 的觀念裡，倘若不知道錯誤訊息該怎麼寫，那麼最至少就是單純地把事實陳述出來。說明發生了什麼事，以及根據程式的設計邏輯，盡可能準確表達出問題的來源。

在 DR 開始接觸電腦的年代裡，除了 Apple 的 Macintosh/Mac 還有一點能見度外，整個個人電腦市場其實已經差不多都被 x86 架構的 IBM 相容 PC 給攻佔了。不過在這樣的態勢出現以前，市場上也曾經有過更加多樣化的年代。BBC Micro（暱稱為 Beeb）是由 BBC 最早於 1981 年推出的電腦產品，以教育用途為目的，主要是針對英國當地的學校及家庭用戶。

RGBeeb 是一個蠻神奇的改造計畫，背後的製作者並不滿足於單純將古董般的 BBC Micro，以維持原狀的方式啟動起來。而是將其魔改、塞入到現代 PC 的 ATX 機殼裡，用的是 ATX 電源供應器，並且接上 USB 的鍵盤及遊戲手把，甚至背板還有 RGB 燈光效果，不過骨子裡仍是不折不扣的 BBC Micro。相關技術資訊都是以開源授權分享在網路上，不僅是嘆為觀止，也很有教育意義。

《Linux command line for you and me》是一份簡潔但又頗為完善的 Linux 指令大全，很適合作為新手學習、或者是老手的速查來源。畢竟現今 IT 領域的知識量已今非昔比，人有限的腦容量經常需要做記憶輪替，已無法將每項知識都牢牢記在腦海裡，懂得在需要時查詢到正確的資料才是正途。

學習透過命令行介面（若以桌面環境來說，指的就是終端機視窗程式）來完成需求，是踏入 Linux 作業系統的重要基礎。因為有別於在 Windows 或者 macOS 上的情形，Linux 相對來說有更多實用的工具程式是以文字指令的形式存在；以及在 Linux 生態百家爭鳴的多樣性下，在不同的環境裡，文字指令通常比圖形介面的解決方案有更好的共通性。

一系列蠻有趣的文章《How I Hacked my Car》，內容描述作者在買了一部現代（Hyundai）房車後，便著手想要破解裡面的 Linux 車載系統（Display Audio Gen2V），藉此實現出自訂的功能。文章連結如下：

一篇蠻有意思的文章《The very weird Hewlett Packard FreeDOS option》，文章的作者 Hein-Pieter van Braam 購買了一部 HP 的筆電，然後在客製化的選項中，選擇 FreeDOS 作為預先安裝的作業系統。一般來說，品牌電腦若有提供這樣的選項，背後的意義其實是要讓用戶自行安裝所需的系統版本。預載 FreeDOS 的目的，並不是真的預期用戶會想在筆電上使用這麼古典的作業系統版本。而是僅僅作為最基本的設備檢驗，以確認筆電能夠正常完成開機動作。

從 1995 年問世至今的 Java，儘管知名度高，發展也算活躍，並且有著跨平台的優勢，卻似乎未曾在 PC 應用程式的開發上佔據很重要的份額。 直到 Android 以 Java 作為首選的程式語言，才終於找到另外一片天地。然而 Java 起初既為桌面系統而生，何以在桌面系統上走得不是那麼順遂？關於此議題，jDeploy 工具的開發者 Steve Hannah，撰寫了多篇幅的專題文章《The Decline and Fall of Java on the Desktop》，分別為 Part 1 及 Part 2。

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

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

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

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