🌘 我（仍然）為何熱愛 Linux
➤ 一位資深使用者對 GNU/Linux 的情感與反思
✤ https://it-notes.dragas.net/2025/11/24/why-i-still-love-linux/
作者回顧了他對 GNU/Linux 長達近三十年的熱愛歷程，從早期接觸 Unix 系統的自由感，到 Linux 在桌面、手機、汽車及各種嵌入式裝置的普及。儘管作者最初更傾向 BSD 系統，但他肯定 Linux 在開源領域的巨大貢獻，特別是其推動了開源軟體的廣泛接受度。文章也探討了 Linux 發展中的一些變化，作者認為部分發行版為了追求創新而犧牲了穩定性，例如 systemd 的引入，並舉例說明其在資源受限設備上的不適用性。
+ 身為一個 Linux 愛好者，看到這篇文章真是感同身受！Linux 的確帶給我們無與倫比的自由和彈性。
+ 對於 systemd 的批評我無法完全同意，但作者對 Linux 早期發展和普及的描述非常到位，值得一看。
#Linux #伺服器 #系統管理 #自我數據

🌗 關於系統故障與數值限制的更多軼事
➤ 從 16 位元 ID 到 32 位元檔案大小上限：系統故障的真實寫照
✤ https://rachelbythebay.com/w/2025/11/18/down/
本文分享了作者在系統管理與軟體開發領域中，遇到的幾起因數值限制或設定不當而導致的系統故障案例。從員工 ID 超出 16 位元有號整數範圍，到日誌儲存系統硬體限制，再到 Apache 伺服器日誌檔案大小達到 32 位元有號整數上限，以及因核心更新後應用程式無法載入新版設定檔而導致的「崩潰迴圈」問題，作者藉由這些真實經歷，強調了理解技術限制、謹慎處理設定、以及分批次更新的重要性，並藉此諷刺了所謂「卓越基礎設施」背後也可能存在的種種混亂。
+ 這些案例太真實了！常常覺得系統很穩定，一出問題才發現是這些基本限制惹的禍。
+ 感謝分享這些寶貴的經驗，特別是關於設定檔更新和分批次部署的提醒，對我們這些仍在學習的人非常有幫助。
#系統管理 #軟體開發 #經驗分享

🌘 歷史考量
➤ 為紀念先驅，將人本歷史融入系統運作
✤ https://exple.tive.org/blarg/2025/11/11/historical-reasons-2/
作者在Dennis Ritchie逝世後，構思在Unix系統上退役使用者名稱作為一種榮譽致敬，如同體育界退役球員背號。儘管當時提出的程式碼修補提案未被採納，作者仍在個人系統上運行修改後的版本，體會這種將文化歷史融入共享程式碼基礎的意義。作者反思，這種做法或許能讓歷史感在系統中無形沉澱，而非僅體現在錯誤或臨時性的變更中，如同體育明星的背號成為一種文化印記，使用者名稱亦可承載人本歷史的厚重。
+ 這個想法很有詩意，但實際執行上是否可行？退役使用者名稱會不會造成後續管理上的問題？
+ 將文化層面與技術層面結合，這思路很有趣。期待看到更多關於如何將「共享遺產」具體融入程式碼的討論。
#系統管理 #歷史紀念 #程式設計

🌘 探索 Wayland 的碎片化：一次 xdotool 的冒險
➤ 從 X11 到 Wayland 的過渡，xdotool 的生存考驗與碎片化困境
✤ https://www.semicomplete.com/blog/xdotool-and-exploring-wayland-fragmentation/
本文回顧了 UI 自動化工具 xdotool 的發展歷程，並深入探討了其在 Linux 顯示伺服器 Wayland 環境下面臨的嚴峻挑戰。作者指出，Wayland 取代 X11 的過程中，許多 X11 原有的穩定功能（如視窗搜尋、滑鼠鍵盤操作、視窗管理）被移除或改變，以「安全」為名但實則造成功能缺失。這種設計導致了嚴重的碎片化問題：不同桌面環境（GNOME、KDE）和 compositor（基於 wlroots）需要各自獨立的解決方案來恢復這些功能，且實作方式五花八門，缺乏統一標準。例如，在 Wayland 上執行類似 xdotool 的操作，需要藉助 Xwayland、XDG Portal、libei、DBus，
#Wayland #xdotool #UI自動化 #系統管理

🌘 Intel N150 上的靜態網站託管：FreeBSD、SmartOS、NetBSD、OpenBSD 與 Linux 效能比較
➤ 深入探討不同類Unix系統在迷你伺服器上託管靜態網站的實際效能
✤ https://it-notes.dragas.net/2025/11/19/static-web-hosting-intel-n150-freebsd-smartos-netbsd-openbsd-linux/
本文在 Intel N150 這款迷你電腦上，針對 FreeBSD、SmartOS、NetBSD、OpenBSD 和 Linux 等多種作業系統進行了靜態網站託管的效能比較。作者使用了預設的 Nginx 設定，並在相同的硬體環境和伺服器設定下，測試了 HTTP 和 HTTPS 協定下的請求處理能力。測試結果顯示，對於純 HTTP 流量，各作業系統間的效能差異並不大，大多能達到每秒 63,000 至 64,000 次請求；然而，
#伺服器託管 #系統管理 #靜態網站 #效能比較 #FreeBSD #SmartOS #NetBSD #OpenBSD #Linux #Nginx

🌘 Systemd cgroup 驅動程式：containerd 與 runc 間的 CPU 配額計算不符導致容器建立失敗
➤ 揭開 containerd CPU 配額計算的迷霧：一次影響容器建立的間歇性錯誤
✤ https://github.com/opencontainers/runc/issues/4982
此問題報告指出，在使用 systemd cgroup 驅動程式時，當為容器設定 CPU 限制為 4096m 時，會間歇性地發生容器建立失敗。問題根源在於 containerd 在計算 CPU 配額時存在不確定性，有時會將 4096m 轉換為 409600 微秒，有時則為 410000 微秒；而 runc 則始終將其計算為 410000 微秒。當 containerd 計算出的父 cgroup 配額（409600）小於 runc 計算出的子 cgroup 配額（410000）時，Linux 核心會因為違反 cgroup v1 的父子配額限制而拒絕建立子 cgroup，導致容器建立失敗。此不確定性行為解釋了為何問題似乎僅出現在「曾使用過的節
#容器技術 #系統管理 #軟體錯誤

🌗 自五月起實施嚴格的 Rust 依賴要求
➤ Debian APT 系統將於 2026 年 5 月強制引入 Rust 依賴，以提升安全與效率
✤ https://lists.debian.org/debian-devel/2025/10/msg00285.html
Debian 開發者 Julian Andres Klode 宣佈，計畫自 2026 年 5 月起，在 APT 套件管理系統中引入嚴格的 Rust 語言依賴，首先會涵蓋 Rust 編譯器、標準函式庫以及 Sequoia 生態系。此舉旨在提升程式碼的記憶體安全性與單元測試的嚴謹性，特別是針對處理 .deb、.ar、.tar 檔案解析和 HTTP 簽章驗證等功能。Klode 強調，若維護的硬體架構（port）在六個月內無法建立可用的 Rust 工具鏈，將面臨淘汰該架構的可能，目的是讓專案能採用現代化技術，不受舊有硬體限制。
+ 這個決定很有遠見，Rust 的記憶體安全特性對於像 APT 這樣關鍵的系統至關重要。希望各個架構都能順利跟上。
+ 對一些較舊的架構來
#軟體開發 #系統管理 #Debian #Rust #依賴管理

🌘 為什麼 /dev/null 是一個 ACID 資料庫
➤ 解構 /dev/null 的 ACID 資料庫傳奇
✤ https://jyu.dev/blog/why-dev-null-is-an-acid-compliant-database/
本文以幽默且具技術性的角度，闡述了 Linux 系統中的特殊檔案 /dev/null 如何巧妙地滿足 ACID 資料庫的所有四大特性：原子性 (Atomicity)、一致性 (Consistency)、隔離性 (Isolation) 和持久性 (Durability)。作者解釋了 /dev/null 的操作本質上是「全有或全無」，它總是保持空無一物的「一致」狀態，多個寫入操作互不幹擾，並且數據「持久」地儲存為虛無。文章最後點出其唯一的限制是儲存空間僅為 0 bytes，並以詼諧的方式提及企業級銷售。
+ 太有創意了！從沒想過 /dev/null 竟然符合 ACID，這解釋真是讓人拍案叫絕。
+ 這篇文章讓我想起了過去管理系統的日子，/dev/null 確實是個神奇的存在。
#資料庫 #系統管理 #ACID

🌘 Sutra | 2025 年個人 VPS 設定與資安強化終極指南
➤ 從零開始打造安全、可部署的個人 VPS 環境
✤ https://bhargav.dev/blog/VPS_Setup_and_Security_Checklist_A_Complete_Self_Hosting_Guide
這份詳盡的指南提供從頭開始設定及強化個人虛擬私人伺服器（VPS）的全面性步驟。作者分享了選擇 Hetzner 作為 VPS 供應商的理由，並詳細介紹了 Coolify 的部署過程。內容涵蓋了初始系統設定、SSH 安全強化（包括金鑰認證及禁用密碼登入）、防火牆（UFW）的配置、自動更新設定、Node.js 應用程式的生產環境部署（利用 PM2 管理）、Nginx 反向代理的設置，以及使用 Let's Encrypt 啟用 SSL/TLS 加密。此外，還包含基本的系統監控與維護建議，以及資料備份策略，旨在建立一個安全、穩定且可重複部署的自我託管環境。
+ 寫得太詳細了！Hetzner 真的 CP 值很高，這份指南對新手來說非常有幫助，尤其是 SSH
#VPS #自我託管 #資安 #系統管理

🌗 留心加密根目錄：如何拯救 ZFS 崩潰時的資料
➤ 一次驚心動魄的 ZFS 加密根目錄資料救援實錄
✤ https://sambowman.tech/blog/posts/mind-the-encryptionroot-how-to-save-your-data-when-zfs-loses-its-mind/
本文記錄作者在處理 OpenZFS 原生加密時遇到的嚴峻挑戰。作者在一次例行的資料遷移過程中，意外導致一個包含 8.5 TB 資料的資料集無法解密。文章詳細闡述了 ZFS 的運作原理，特別是其加密機制的細節，並分享了偵錯、重現問題以及最終透過修改 ZFS 程式碼來修復損壞狀態、成功救回資料的過程。作者強調了持續備份測試的重要性，並分享了從這次慘痛經驗中學到的教訓。
+ 這篇文章太實用了！正好在考慮使用 ZFS 加密，看完這篇後，我會更加謹慎地規劃和測試。作者的勇氣和技術力令人佩服。
+ 感謝作者分享如此深入的技術細節。我曾經也遇過類似的資料遺失情況，當時真是束手無策。這篇文章提供了一個非常寶貴的參考。
#ZFS #資料救援 #系統管理 #數據備份

🌘 使用 Make 管理點檔案（Dotfiles）
➤ 讓經典建置工具 Make 賦予點檔案管理新生命
✤ https://www.matheusmoreira.com/articles/managing-dotfiles-with-make
本文介紹如何利用老牌的建置工具 Make 來管理使用者個人設定檔（dotfiles）。作者認為 Make 的普及性使其成為一個無需額外安裝的理想選擇。透過鏡像使用者的家目錄結構，並利用 Make 的符號連結功能，可以簡潔有效地實現點檔案的自動化部署。文章進一步探討瞭如何透過 Make 的巨集編譯能力，將連結規則通用化，並利用偽目標（phony targets）來簡化日常操作，使得管理大量點檔案變得更加便利。
+ 以前都沒想過 Make 還能這樣用！真是簡單又實用。
+ 這方法確實解決了額外安裝工具的麻煩，而且程式碼寫得很精煉。
#軟體開發 #系統管理 #工具

🌘 Bazel 與 glibc 版本不符：揭露建構再現性中的隱藏陷阱
➤ 當快取機制遇上系統 ABI 差異：一個關於再現性的警示
✤ https://blogsystem5.substack.com/p/glibc-versions-bazel
本文深入探討了 Bazel 的快取機制、遠端執行與不同 Linux 發行版上 glibc 版本差異所引發的建構再現性問題。作者透過一個實際案例，說明瞭開發者工作站、CI 系統與生產環境間 glibc 版本不一致，如何導致在開發時測試通過、但上線後服務卻因缺少特定 glibc 版本符號而崩潰。文章分析了這個問題的根本原因——C/C++ 建構過程中對系統依賴（特別是 glibc 版本）的隱性連結，而 Bazel 的預設快取鍵卻無法辨識這些差異。最後，作者提出了一種「手動分割 ACL」的臨時解決方案，透過捕獲並將 glibc 版本納入工具鏈，使其成為快取鍵的一部分，以防止這類災難性錯誤。
+ 這個問題很常見，但很少有人能深入分析其根源。感謝作者提出的解決方案！
+ 『The
#建構系統 #C++ #glibc #Bazel #CICD #系統管理

🌗 我只想一個 80×25 的主控臺，但這已不再可能
➤ 現代系統已難以重現經典的 80×25 文字主控臺體驗
✤ https://changelog.complete.org/archives/10881-i-just-want-an-80x25-console-but-thats-no-longer-possible
作者感嘆，曾經普及且橫跨多種作業系統的 80×25 文字主控臺模式，在現代電腦環境中已難以實現。由於現代系統（特別是 UEFI 啟動或非 x86 架構）不再原生支援此模式，導致文字模式的解析度、字體尺寸和長寬比在不同啟動階段和顯示器上表現不一致，甚至無法正常顯示為 80×25 的傳統格式。作者嘗試了多種方法，包括舊的 `vga=` 選項、GRUB 設定、`nomodeset` 以及 `kmscon`，但均因系統架構（UEFI、ARM）、不支援的模式或工具本身的功能限制而失敗，最終作者認為只能尋找舊式硬體來達成目標。
+ 這篇文章真是道出了不少資深用戶的心聲！懷念以前那個簡單直接的命令列介面。
+ 雖然理解作
#系統管理 #主控臺 #Linux #UEFI #VGA

🌘 重現美國時區設定的混亂狀況
➤ 一個系統管理員的時區除錯記
✤ https://rachelbythebay.com/w/2025/09/12/tz/
作者分享了在 Debian 12 安裝過程中，系統自動選擇看似過時的美國時區（US/Pacific）的經歷，並深入探討了這個設定如何影響 PostgreSQL 的時區處理。透過重現安裝過程，作者發現 Debian 預設會根據國家選擇提供時區選項，而 PostgreSQL 則會自動繼承系統的時區設定。作者也提及了其他因時區設定錯誤導致的生產環境問題，並反思了在測試環境中發現並解決問題的權衡。
+ 這篇文章讓我對 Debian 的時區處理有了更深的理解，也提醒了我，即使是看似簡單的設定，背後也可能隱藏著複雜的邏輯。
+ 感謝作者的詳細分享，讓我瞭解了 PostgreSQL 如何處理時區，以及在系統升級時需要注意的事項。
#系統管理 #Debian #時區 #PostgreSQL

🌘 tz 資料庫運作機制解析
➤ 從安裝到自訂，一次搞懂 tz 資料庫的核心技術
✤ https://yatsushi.com/blog/tz-database/
本文深入探討了 tz 資料庫（timezone database）的運作原理。作者透過實際操作，介紹瞭如何安裝 tzdata 套件、利用 `zic` 編譯器建立自訂時區，以及 `zdump` 工具如何讀取和驗證時區資訊。文章詳細解釋了 tz 資料庫的來源檔案結構，包含規則（rules）、區域（zones）和連結（links）的定義，並透過一個虛構的「木葉村」時區範例，展示瞭如何定義夏令時間（DST）的生效與結束，以及如何將自訂時區設定為系統預設值。這篇文章為讀者提供了一個理解時區轉換背後複雜機制的入門指南。
+ 這篇文章解釋得非常清楚，我以前都不知道 tz 資料庫原來是這樣運作的！實際操作的範例很有幫助。
+ 作者的技術細節剖析很到位，特別是關於規則和區域的定義，讓我對夏令時間的變更有了更深的理解。
#時區 #tz database #系統管理 #軟體工程

🌘 萬物皆無：TCP 用戶端自我連線
➤ 一個關於 TCP 同步開啟的意外應用
✤ http://sgros.blogspot.com/2013/08/tcp-client-self-connect.html
本文深入探討了在特定條件下，TCP 用戶端如何能與自身建立連線，即便沒有伺服器在監聽。作者透過實際操作和對 Linux 核心程式碼的分析，揭示了 TCP 同步開啟 (simultaneous open) 機制在 localhost 環境下的意外應用，以及這個現象背後的運作原理，並提醒開發者應避免使用臨時埠作為伺服器監聽埠。
+ 這篇文章實在太精彩了！我一直對 TCP 的細節感到好奇，這篇深入剖析了連線建立的底層機制，尤其是 localhost 自我連線的部分，顛覆了我對網路連線的認知。
+ 感謝作者的詳細解釋！我最近在除錯一個網路應用時遇到了類似的問題，這篇文章提供的核心思路和技術細節，幫助我釐清了問題的根源。對於從事網路開發或系統管理的人來說，這絕對是一篇必讀的好文。
#網路 #TCP/IP #Linux 核心 #系統管理

🌘 為何我一年後離開 NixOS？
➤ 一年的 NixOS 體驗：掙扎於抽象與效率之間
✤ https://www.rugu.dev/en/blog/leaving-nixos/
作者分享了他在使用 NixOS 一年後決定轉回 Arch Linux 的經驗。儘管認同 NixOS 的聲稱的優勢，如可重現性，但作者發現實際應用中，為了讓程式運作而投入的時間成本過高，且與傳統 Linux 發行版相比，學習曲線陡峭，除錯也更複雜。他認為 NixOS 的抽象層與底層系統的差異，以及對預編譯程式的限制，是造成這些問題的主要原因。最終，作者認為 NixOS 的嚴格要求並不符合他個人的工作流程與需求，尤其是在追求效率和簡便性時。
+ 我也有類似的經驗，NixOS 的學習曲線確實讓人望而卻步，但它在多機同步方面的優勢也是不可否認的。
+ 這篇文章很真實，確實有時候為了「完美」而付出的代價太大了，效率纔是王道。
#Linux #NixOS #系統管理 #軟體開發

🌘 撰寫 GNU Guix 的基本服務
➤ 從零開始為 GNU Guix 打造專屬的 kmonad 守護程式服務
✤ https://tannerhoelzel.com/gnu-shepherd-simple-service.html
本文詳細介紹如何為 GNU Guix 系統撰寫一個自訂服務，使其能夠在系統啟動時自動運行 kmonad，並在系統關機時停止。作者從閱讀官方文件和現有原始碼著手，逐步學習 Guix 的服務架構，並模仿現有範例（如 Wesnoth 伺服器服務）來定義自己的 `kmonad-service-type`。這個過程包含定義服務名稱、描述、擴展現有服務（帳號服務和 Shepherd 初始化服務），以及處理使用者帳號的創建。
+ 寫得真清楚！對於想深入瞭解 Guix 系統服務的開發者來說，這是一篇非常實用的指南。
+ 感謝作者分享實際操作的經驗，從閱讀文件到實際撰寫程式碼，一步步展示了 Guix 服務的開發流程。
#GNU Guix #服務 #系統管理 #Scheme

🌘 打造您專屬的 FreeBSD 備份堡壘：系統設定與安全強化
➤ FreeBSD 系統配置與資料加密實戰指南
✤ https://it-notes.dragas.net/2025/07/29/make-your-own-backup-system-part-2-forging-the-freebsd-backup-stronghold/
本文為「打造您專屬的備份系統」系列的第二部分，深入探討如何建置一個以 FreeBSD 為基礎的強固備份伺服器。作者強調 FreeBSD 在備份領域的優勢，包括其分割服務的能力、ZFS 檔案系統的靈活性，以及搭配 jail 或 bhyve 虛擬機進行隔離。文章進一步闡述了網路設定，特別是 IPv4 和 IPv6 的配置，以及資料儲存的安全考量，包括磁碟冗餘（如 RAIDZ）與資料加密（GELI、ZFS 原生加密）。作者透過實際操作指令，展示瞭如何使用 GELI 加密磁碟並在其上建立 ZFS 儲存池，以確保備份資料的機密性與完整性。
+ 這篇文章提供了非常實用的技術細節，尤其是 GE
#FreeBSD #備份 #系統管理 #資料安全 #ZFS #加密

🌘 PKGBASE 移除 FreeBSD 基本系統功能
➤ PKGBASE 潛藏危機：`pkg delete -af` 指令如何「摧毀」FreeBSD 基本系統？
✤ https://lists.freebsd.org/archives/freebsd-pkgbase/2025-July/000590.html
這篇文章揭露了 FreeBSD 導入 PKGBASE 後，對於傳統上「不可觸碰」的基本系統所造成的重大影響。作者 vermaden 透過實際操作指出，原本用於移除第三方套件的 `pkg delete -af` 指令，在 PKGBASE 環境下會誤刪除大部分 FreeBSD 的基本系統元件，僅留下兩個核心套件，嚴重破壞了系統的穩定性和可預測性，與 FreeBSD 過去的原則背道而馳。
+ 這真是令人震驚的發現！原本以為套件管理工具只會處理第三方軟體，沒想到它竟然會觸碰到系統最核心的部分，而且影響如此劇烈。
+ 作者的擔憂非常有道理。FreeBSD 的魅力之一就是其穩定的基本系統，如果這個基石被輕易破壞，將會動搖整個系
#FreeBSD #PKGBASE #系統管理 #套件管理