資訊技術

近期一個比較重大的產業消息，是 Red Hat 停止在公開站點（git.centos.org）上發佈 RHEL 的 SRPM 原始碼套件。直接公開的原始碼下載途徑僅存 CentOS Stream，也就是 RHEL 的上游開發版本。並且由於 CentOS Stream 更動較 RHEL 快速，所以其原始碼也不是完全與當前 RHEL 一致的狀態。至於 Red Hat 的訂閱用戶，則依然能夠從用戶後台系統、或者是使用 dnf/yum 工具來下載 RHEL 的 SRPM。

好段時間前，來自 Ars Technica 網站的一則消息：Microsoft is scanning the inside of password-protected zip files for malware，其內容描述一名安全研究員，發現他在 SharePoint 上保存的 ZIP 壓縮檔，即便有加上密碼保護，似乎仍會被雲端服務嘗試解開，並對裡頭的檔案進行防毒掃描，若是偵測到有惡意程式便會遭到封鎖。雖然微軟官方並未公開表述其解開壓縮檔密碼保護的方式，然而估計其中一種可能性，仍是透過某種經過蒐集的密碼清單來進行嘗試。

恐怕沒有多少人真的對 Windows 檔案路徑的運作方式，有很透徹的瞭解。在 Fileside 應用程式的部落格文章《The weird world of Windows file paths》裡，作者 Erik Jälevik 彙整了關於 Windows 檔案路徑的各項機制與特性。其中包含了各種不同的路徑表示方式，以及特殊的檔名限制等等。只能說一言難盡，有興趣的人可以自行參閱。

倘若僅僅是作為 Windows 系統的終端使用者，那麼或許還不會覺得 Windows 檔案路徑的運作，有什麼特別稀奇古怪的地方。但如果是要編寫工具程式或批次腳本，就有可能會踩到地雷，而需要在設計上有所留意與調適。相形之下，真的會覺得還是 Linux 的世界單純許多。

來自 LWN.net 的文章《The early days of Linux》，作者 Lars Wirzenius 是 Linus Torvalds 在赫爾辛基大學的同學，曾一同參與 Linux 最起初的發展歷程。雖然已經存在許多介紹 Linux 發展歷史的文章或資料，不過像這樣的第一手見證就不是這麼常出現了。文章篇幅並不冗長，很容易就能夠讀完。

最早的 Linux 程式碼，是在一部 386 PC 上開發出來的。發生在 Torvalds 玩完了《波斯王子》（Prince of Persia，1989）之後，他開始學習 x86 組合語言，並製作出 Linux 內核的最初雛型。後來再進一步用 C 語言加以擴充，Wirzenius 也協助貢獻了一些函式實作，其程式碼至今仍可在當前的 Linux 內核裡找到。

來自 Chips and Cheese 網站的兩篇文章：

• Bulldozer, AMD’s Crash Modernization: Frontend and Execution Engine
• Bulldozer, AMD’s Crash Modernization: Caching and Conclusion

雖然 Google Stadia 已正式終結其營運，不過有一項與之相關的內部專案 CDC File Transfer，卻默默地以開放原始碼授權出現在 GitHub 上。正如其名稱所揭示的，這項專案設法在檔案傳輸的過程裡，實作出以內容為依據的分塊方式（Content Defined Chunking，CDC），藉此準確地擷取出兩端之間的內容差異，以減少實際需要傳輸的資料量，進而提昇遠端檔案同步的效率。

好像還未曾在其它地方見過，有像《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。相關技術資訊都是以開源授權分享在網路上，不僅是嘆為觀止，也很有教育意義。