從 Proxmox 出走：用 NixOS + Incus 重建家庭伺服器基礎設施
nijho.lt · 2026-06-26（更新）
工程師 Bas Nijholt 在 2026 年 6 月將自家 9 台機器的虛擬化環境，從 Proxmox 完整遷移至 NixOS 搭配 Incus 的組合，並把所有配置收進單一 Git 儲存庫管理。
他在文章中坦言，這次動手的最直接導火線是 Proxmox 的「狀態漂移（state drift）」問題——每次手動除錯都會讓實際執行狀態悄悄偏離 Infrastructure as Code 的定義，日積月累後幾乎無法重現乾淨環境。
文章在社群引發廣泛討論，讓許多有相同痛點的家庭實驗室玩家開始認真考慮類似方案。
原本的問題
Proxmox 以圖形介面作為主要操作入口，底層狀態儲存在不透明的資料庫與設定檔中，很難單憑文字描述重現整套環境。
Nijholt 舉了兩個典型案例：Intel I219-LM 網卡在特定核心版本下會無故掛起，每次都要靠記憶中的隱晦指令才能解決；NVIDIA 驅動升級後也常需要執行一系列「偏方指令」才能恢復正常。
這類知識無法被版本控制，只存在工程師的腦袋或散落在各個論壇貼文裡。
相比之下，NixOS 的宣告式設定讓每一個修復都變成一段帶有說明注釋、可重複套用的程式碼。
網卡掛起問題現在被定義為一個附有論壇參考連結的 systemd 服務，下次重裝時自動生效，無需任何人工記憶。
採用的方法
遷移分為 LXC 容器與 VM 虛擬機兩條路徑，均透過自製腳本處理。
LXC 容器部分，先在 Proxmox 端用 vzdump 產生壓縮備份，再於 NixOS 端以自訂腳本修正 UID mapping 與 machine-id 後匯入 Incus：
# Proxmox 端：建立壓縮備份
vzdump 101 --dumpdir /var/lib/vz/dump --mode suspend --compress zstd
# NixOS 端：修正 UID mapping 後匯入
./migrate-lxc.sh vzdump-lxc-101-*.tar.zst ubuntu-containerVM 虛擬機則先將 ZFS volume 轉換為 QCOW2 格式，再匯入 Incus 並建立對應的 NixOS VM 定義：
# Proxmox 端：ZFS volume → QCOW2
qemu-img convert -p -O qcow2 /dev/zvol/rpool/data/vm-100-disk-0 vm-100.qcow2
# NixOS 端：匯入磁碟並建立 VM
./migrate-vm.sh vm-100.qcow2 home-assistant Incus 是 LXD 的社群分叉版本，在 Canonical 縮減 LXD 開放程度後，由原本的社群貢獻者接手維護，功能與 API 相容，但治理更開放。
Nijholt 選擇 Incus 而非直接使用 LXD，正是看中其長期維護的可預期性。
實際效果
遷移完成後，原本需要獨立跑 Kodi 的 NUC 小主機現在同時承載 HTPC 與容器工作負載，實現了硬體的雙重用途。
全部 9 台機器的設定都收進同一個 Git 儲存庫，任何變更都有歷史紀錄可查。
文章中另一個值得注意的觀察是 AI 代理的角色：宣告式、純文字的基礎設施設定讓 AI 能夠可靠地閱讀、理解並修改配置，這在 Proxmox 的 GUI 與不透明資料庫驅動的工作流程下根本無法實現。
Nijholt 表示，9 台機器的設定大部分都由 AI 在重構過程中生成，他自己主要負責審查與調整邏輯。
NixOS 原子性升級的特性也解決了 NVIDIA 驅動問題的整個類別：由於每次升級都是獨立的世代切換而非原地覆蓋，驅動版本與核心版本之間的不一致性幾乎消失了。
這讓過去需要靠偏方指令救火的情境，從根本上被消除。
GE-Proton11-1 發布：影片播放架構翻新，四個月工程換掉 GStreamer
GitHub — GloriousEggroll/proton-ge-custom · 2026-06-26
由 GloriousEggroll 維護的 Linux 遊戲相容層社群版本 GE-Proton11-1 於 2026 年 6 月 26 日正式發布，這是 GE-Proton 首個基於 Proton 11 bleeding-edge 的版本。
本次最大亮點是歷時四個月的影片播放底層重構：將原有的 quartz→gstreamer 路徑改為 quartz→winedmo→ffmpeg，並從建置系統中移除所有 GStreamer 函式庫。
超過 150 款遊戲的過場動畫與影片因此無需任何手動設定即可正常播放。
背景
GE-Proton 是 Valve 官方 Proton 的社群分叉，主要目的是納入尚未合併進官方的修補程式、額外的媒體解碼器支援，以及針對特定遊戲的相容性補丁。
由於 Steam 官方 Proton 受到 Valve 的版本管控與測試週期限制，GE-Proton 長期扮演「先行實驗場」的角色，讓急需特定遊戲能運行的 Linux 玩家有更即時的選擇。
GStreamer 是一套模組化的多媒體框架，過去被用作 Wine/Proton 的影片解碼後端。
然而 GStreamer 的相依性複雜，版本相容問題在不同 Linux 發行版上常造成影片無法播放的困擾，這也是社群多年來的老問題。
核心改動
影片播放路徑改為 quartz→winedmo→ffmpeg，完全繞過 GStreamer 的相依性鏈。
winedmo 是 Wine 內建的 DirectShow 相容層，搭配 FFmpeg 作為實際解碼後端，讓整個解碼流程完全在 Wine 的沙盒環境內完成，不再依賴宿主系統安裝的 GStreamer 版本。
這意味著無論使用者的 Linux 發行版是否安裝、或安裝了哪個版本的 GStreamer，遊戲影片都能一致地正確播放。
本次版本同時新增多項功能，均預設關閉，需要透過環境變數手動啟用：
PROTON_USE_D7VK=1：啟用 D7VK，DirectX 7 轉 Vulkan 的實作PROTON_DISCORD_BRIDGE=1：啟用 Discord 橋接，讓 Windows 遊戲能顯示 Discord Rich PresencePROTON_USE_OPTISCALER=1：啟用 OptiScaler，支援 FSR/DLSS/XeSS 超解析技術
Wine ALSA 音效方面也加入了聲道數量覆寫（channel count override）與空間音效向下混音（spatial downmix）選項，以及針對 Wine-Wayland 的 XRandR 整合，改善多螢幕環境下的螢幕偵測。
Wine-native RSX3D 函式庫的加入則是為了支援一些依賴舊版 DirectX 渲染路徑的老舊遊戲。
影響範圍
在具體遊戲相容性方面，《Final Fantasy XIV》受益於 .exe 動態重定址（dynamic relocation）處理的改進：過去在位址空間耗盡時，外掛 hook 會失敗，這個問題現在已被修正。
《Star Citizen》修補程式也隨之更新，《VRChat》獲得了網路攝影機臉部追蹤支援。
目前已知的小問題是：部分較老的 WMV 影片在播放初期可能出現短暫畫面失真，但幾秒內會自動修正；《WRC 4》的片頭動畫存在畫面分裂現象。
整體而言，移除 GStreamer 相依性對大多數使用者來說是明確的正向改變，特別是在 Arch Linux、Fedora 等不預設安裝完整 GStreamer 外掛集的發行版上效果更為明顯。
Google 將快取問題套入「滑雪租借模型」：Spanner 靠彈性 TTL 節省 15% 記憶體
Google Research Blog · 2026-06-25
Google Research 的 Todd Lipcon 與 Manish Purohit 在 2026 年 6 月 25 日發布研究成果，說明他們如何將快取管理問題重新建模為「滑雪租借問題（ski rental problem）」，並在 Spanner 生產環境中實現記憶體用量下降 15.5%、快取失效率僅上升 5.5%、總擁有成本降低約 5% 的成績。
這套技術稱為 線性彈性快取（linear elastic caching），核心思想是讓每一筆快取資料動態決定自己的存活時間，而非沿用傳統的固定大小快取加 LRU 淘汰策略。
文章作者之一 Todd Lipcon 的頭銜是 Google Cloud 傑出工程師（Distinguished Engineer），另一位 Manish Purohit 為 Google Research 研究科學家。
原本的問題
雲端服務的記憶體成本極高，文章以無伺服器環境為例：1 GiB 記憶體的費用可高達每天 3 美元。
傳統快取策略面臨兩難：固定分配過多記憶體會在低流量時期造成浪費，分配過少則在高峰期頻繁發生快取失效，拖慢回應速度。
現有的快取策略（如 LRU）只考慮存取順序，無法根據不同資料的「重新取得成本」動態調整保留優先順序。
例如，從資料庫讀取一筆大型資料列的成本遠高於讀取一筆索引項目，但傳統 LRU 對這兩者一視同仁，純粹依賴最近存取時間決定淘汰順序。
這種設計忽略了不同資料的經濟價值差異，在費用敏感的雲端環境中代價尤其明顯。
採用的方法
研究者將問題抽象化：快取中的每一筆資料都面對「繼續付記憶體租金」或「逐出並承擔未來重新載入的延遲/I/O 成本」的持續選擇。
這恰好符合滑雪租借問題的結構——租借裝備（繼續佔用記憶體）每天產生費用，而購買裝備（接受一次性逐出成本）則消除未來租金，最佳策略取決於未來存取機率的預測。
實作上採用淺層決策樹（shallow decision tree）作為預測模型，輸入特徵包含資料大小、快取失效成本、資料庫操作類型等，輸出是每筆快取資料的建議 TTL 值。
選擇決策樹而非深度神經網路，是為了能直接翻譯成 C++ 程式碼，將預測開銷降至最低。
論文同時給出理論證明：逐出策略（何時逐出）與租借時長（TTL 設多長）這兩個子問題可以獨立最佳化，不會相互干擾。
# 特徵向量示意（非實際程式碼，僅供說明）
features:
- data_size_bytes
- cache_miss_cost_ms # 快取失效時重新載入的延遲成本
- db_operation_type # 例如 point_read / range_scan / index_lookup
output:
- ttl_seconds # 預測此筆資料應保留的時間 當快取容量達到上限時，系統回退至傳統 LRU 作為後備機制，確保在極端流量下不會因為 TTL 預測失準而造成全面失效。
彈性 TTL 與固定容量 LRU 形成互補：前者處理正常操作下的成本最佳化，後者作為安全網。
實際效果
在 Spanner 生產環境的測量結果如下：
- 記憶體用量：相較固定大小快取降低 15.5%
- 快取失效率：僅上升 5.5%（遠低於記憶體節省比例）
- 總擁有成本（TCO）：降低約 5%
- I/O 成本影響：僅 0.5%，幾乎可忽略
在公開追蹤資料集（public trace）上的評估也顯示，彈性策略在各種不同工作負載下均能維持顯著低於基準方法的快取失效率。
這套方案的獨特之處在於不需要大量標記資料或複雜的訓練流程——決策樹的訓練特徵都是快取系統本身已經具備的元資料，部署障礙相對低。
研究者指出，這套方法不僅適用於 Spanner，理論上可推廣到任何「保留成本為線性、逐出成本為一次性」的快取場景，例如 CDN 邊緣節點、資料庫 buffer pool、或應用層的 in-process 快取。
滑雪租借問題的視角讓成本建模更加精確，每筆資料的留存決策都有了可量化的經濟依據，而非僅憑直覺調整快取大小。
原始來源：Google Research — Optimizing cloud economics with linear elastic caching