你不夠愛 systemd Timer：cron 的四個痛點與 Timer 的設計哲學
Tim Lange's Blog · 2026-05-31
一篇標題挑釁的技術文章在 Lobsters 引發廣泛討論，作者系統性列出 cron 的四個長期痛點，並逐一示範 systemd timer unit 如何解決它們。這篇文章的熱度反映了社群中長期存在的「cron 夠用論 vs. systemd 完整論」路線之爭。
cron 的四個結構性問題
- 不可預測的
$PATH：cron 的執行環境是精簡的 shell，與用戶互動 shell 的$PATH不同，導致「在終端機可以跑，排程跑不起來」是最常見的 cron 踩坑 - 輸出進系統郵件：cron job 的 stdout/stderr 預設發送至 system mail，在現代 Linux 上通常沒人查看，錯誤訊息靜默消失
- 無執行歷史：cron 不記錄哪次跑成功、哪次失敗、執行了多久
- 反直覺的排程語法：如
01,31 04,05 1-15 1,6 *，對複雜排程的可讀性極差
systemd Timer 的對應解法
Timer unit 與 Service unit 分離：roulette.timer 預設啟動 roulette.service，服務的執行環境由 [Service] 區塊完整定義，包括 Environment= 與 ExecStart= 的明確路徑。日誌自動進入 journald，以 journalctl -u roulette.service 即可查看完整歷史。
排程語法分為兩類：
- Calendar 事件（對應 cron 的 wallclock 時間）：
OnCalendar=daily、OnCalendar=Mon *-*-* 04:00:00 - 相對時間（cron 無法表達）：
OnBootSec=15min（開機後 15 分鐘）、OnUnitActiveSec=1h（上次執行結束後 1 小時）
進階功能：錯峰、喚醒、補跑
RandomizedDelaySec= 在排程時間前後加入隨機延遲，緩解多台機器同時執行（thundering herd）引發的尖峰負載。WakeSystem=yes 允許 timer 在系統休眠時喚醒機器。Persistent=yes 確保若系統在排程時間點關機，下次開機後立即補執行，cron 對這種場景完全沒有處理機制。
systemctl list-timers 一個命令即可查看所有 timer 的下次觸發時間與上次執行結果，這是 cron 無論如何都無法提供的運維可視性。
RGB 正規化：除以 255 還是 256？一個有趣的整數範圍邊界問題
30fps.net · 2026-06-01
這篇在 Hacker News 與 Lobsters 同時出現的短文，討論一個看似微不足道但在圖形管線中確實有影響的問題：將 8-bit RGB 值（0–255）轉換為 [0.0, 1.0] 浮點範圍時，應該除以 255 還是 256？
數學上的差異
除以 255：將整數範圍的端點 0 映射到 0.0、255 映射到 1.0，確保最大值精確達到 1.0。這是大多數圖形 API、shader 教材和顏色空間轉換公式的預設做法。
除以 256：將值域視為均勻分布的「bin 中心點」，0 映射到 0/256 ≈ 0，255 映射到 255/256 ≈ 0.996。最大值永遠達不到 1.0，但每個整數值代表一個等寬的浮點區間而非一個點。
兩者各有其正確性
除以 255 的正確性在於端點映射的直覺性：「純白（255,255,255）= (1.0, 1.0, 1.0)」。這是 OpenGL、Vulkan、Metal 等 GPU API 規格所採用的映射。
除以 256 的正確性在於均勻量化的解釋：若將 8-bit 值視為連續訊號的取樣結果，每個整數值代表一個寬度為 1/256 的區間，其中心點在 (n + 0.5)/256。這個解釋在音訊訊號處理和某些圖像壓縮演算法中更為合理。
實務影響
兩者在精度差異上極小（255/256 = 0.99609375），對視覺效果幾乎無法分辨。但在數學嚴格性要求較高的場景（如顏色空間轉換管線的誤差分析、HDR tone mapping 邊界條件）使用錯誤的假設可能導致不易偵測的累積偏差。作者的結論是：在 GPU 圖形管線中用 255，在訊號處理脈絡中用 256，並在程式碼中留下明確的型別註解說明你在做哪種映射。
原始來源：30fps.net — Should you normalize RGB values by 255 or 256?
「GitHub 毀了軟體」的工程控訴：中心化 SCM 的代價
eblog · 2026-06-01
一篇標題為「GitHub and the crime against software」的文章在 Hacker News（171 票）和 Lobsters 同時進入熱門，引發社群對軟體基礎設施中心化風險的廣泛討論。作者的核心論點是：GitHub 的壟斷性市場地位已經對開源軟體的長期健康產生了結構性傷害。
主要論點
文章指出幾個具體的工程層面問題：
- Git 本身是分散式版本控制系統，但 GitHub 創造了一個去中心化工具的中心化依賴點，Issues、Actions、Packages、Pages 等功能讓專案難以遷移
- GitHub Copilot 使用開源程式碼訓練的爭議，以及平台方對訓練資料的單方面控制
- GitHub Actions 的生態系統讓 CI/CD 與特定平台深度耦合，切換成本極高
- 小型自我託管替代方案（Forgejo、SourceHut、Gitea）難以與 GitHub 的網路效應競爭
討論串中出現了多種反駁意見，包括「分散式的不便性才是真正障礙」、「電子郵件補丁工作流程（如 Linux kernel）仍然可行」等，顯示這是一個社群中尚無共識的議題。