來自 Ars Technica 網站的文章《A decade and a half of instability: The history of Google messaging apps》，寫得鉅細靡遺又鞭辟入裡，豐富且詳細地交代了 Google 過去十六年來，所有與即時通訊（包含文字訊息、通話及視訊等）相關的產品及服務。
也是看完這篇文章，才讓 DR 驚覺，原來 Google 在即時通訊這項領域出奇地失敗，完全不像是作為網路巨頭應有的表現。一堆 Google 旗下服務都有自己的通訊功能，且彼此並不互通。另一方面，專注於即時通訊的產品也是一換再換，讓人不知道什麼時候才會安定下來。
由 Colin Watson 所撰寫的文章《Launchpad now runs on Python 3!》，其內容總結了將 Launchpad 軟體協作平台從 Python 2 移植到 Python 3 的歷程，值得參考。由於 Python 2 的最終版本（2.7.x）已於 2020 年 1 月停止維護，因此勢必會有許多原採用 Python 2 作為開發語言的組織，得考慮安排期程，將程式碼轉換至 Python 3 的環境。
來自 GamingOnLinux 網站的訪談文章《An interview with Joshua Ashton, developer on the likes of DXVK, VKD3D-Proton and more》，Joshua Ashton 是 D9VK 的原作者，原為 DXVK 的一個分支，後合併回 DXVK 主線中。
2021 年是 Linux 作業系統問世的三十週年，為此 Tag1 Consulting 的部落格，刊登了兩篇與 Linus Torvalds 的訪談文章，其文章連結如下：
一如既往地，DR 找了個時間，將二號機上的 Fedora 系統從 Fedora 32 升級至 Fedora 34。由於最主要的升級目的，都是為了獲取尚在維護的發行版本。所以 DR 在升級前，通常並不是很在意究竟新版本有哪些變化。此次 Fedora 34 最顯而易見的變化，是使用了最新版本的 GNOME 40 桌面環境，而非過去的 GNOME 3.x。
升級前沒有什麼特別的預期，但在升級後，DR 感受最明顯的差異，是 GNOME Shell 的快捷程式列，從原本的桌面左側移到了底部。作為對照，如下方的桌面擷圖所示，左側是 Fedora 32，右側則是 Fedora 34。
《Food on the table while giving away code》是由 curl 的原作者暨主要維護者 Daniel Stenberg 所撰寫的一篇文章，內容分享了他對於如何維護一項開放原始碼專案、又要兼顧個人生計的挑戰與展望。雖然 curl 工具及其函式庫，為大量的企業及個人所使用，也是許多重要軟體的底層依賴。但它始終是開放且免費的，如同起初的計畫，而 Stenberg 也希望保持如此。
《What Stable Kernel Should I Use?》是由 Linux 穩定版內核的主要管理者 Greg Kroah-Hartman 所撰寫的一篇文章，其內容主要是對 Linux 使用者如何選擇內核版本提供建議。這篇 2018 年的文章其實在 DR 的書籤裡已經存在了一段時間，只是過去未曾在本站提及過。不過由於近期 CentOS 8 的事件鬧得沸沸揚揚，而其中又有部份觀點是有待商榷的，使得 DR 覺得似乎是時候來分享這篇文章。
Linux 內核有自己的維護週期，收納所有更新內容的主線版本（mainline）每二至三個月會釋出一次。新釋出的主線版本接著會產生一個穩定版（stable）分支，持續引入問題修正。穩定版會在下一版的主線釋出後擇期停止維護，除非經選定而成為長期維護版（LTS）。長期維護版會提供 6 年的維護週期，但僅會包含重大的問題修正。
聽聞 CentOS 8 將大幅縮短原先預定的生命週期，不再與 RHEL 8 同步，而是僅維護至 2021 年 12 月；反而是 CentOS 7 仍按照原訂計畫支援至 2024 年。這可能是 DR 今年聽到最令人驚訝的消息，雖然 DR 目前的生產環境剛好都還沒有使用到 CentOS 8，但已有許多測試環境是採用 CentOS 8，並且原本也有規劃要擇期將 CentOS 7 的主機轉移到 CentOS 8。然而在支援週期的轉變下，未來的升級規劃可能就如官方所建議的，是選擇 CentOS Stream 8 作為下一版的作業系統。
讓我們來看看官方消息：
GtkStressTesting 是一款 Linux 上的 CPU 效能暨壓力測試工具，除此之外，它也可以用於便捷地檢視 CPU、記憶體及主機板的細部資訊。雖然說 Linux 使用者多少都知悉，如何在命令行下檢視裝置資訊及進行效能測試，但擁有一個圖形化工具可用仍是方便許多。在 Fedora 32 下的安裝相當單純，只要用 dnf 安裝即可：
如果 3D 遊戲的畫面出現異常，人們通常會去調查與 GPU 相關的層面。然而在《Fixing Mass Effect black blobs on modern AMD CPUs》這篇文章裡，作者則關注了《質量效應》（Mass Effect，2007）這款遊戲的 PC 版，唯獨在 AMD Bulldozer 及其它更新架構的 AMD CPU 上，部份遊戲區域顯示不正常的問題。
作者的研究打破了多數人會有的猜想，發現遊戲程式並沒有出現偵測 CPU 規格、並做出差異行為的跡象。顯示異常是來自於其它層面，並且可以透過將舊版 DirectX 函式呼叫替換為新版的函式來加以避免。在文章中有詳盡的說明，並附有修正程式，值得有興趣的人加以閱讀。