系統與容器

前言 如果你常在 Ubuntu 上刷抖音，有沒有遇過這種情況：每次重新整理（F5）網頁首頁，螢幕上就「啪」地彈出一個系統提示視窗，寫著： 「要允許 https://www.douyin.com 使用 System Handler 開啟 bitbrowser 鏈結嗎？」 或者更慘的是——連彈窗都沒有，只出現一行冷冰冰的錯誤： 「沒有可用的軟體 bitbrowser://cc/」 刪快取？清歷史？停用擴充功能？試過之後你才發現——根本沒用。 別懷疑，這不是中毒，也不是瀏覽器壞了。這背後的原因，其實跟你每天用的 Chrome 瀏覽器，以及它跟作業系統之間的「協定對接」有關。 問題出在哪？網頁自己在背景「打電話」 先來還原一下現場。 你在 Ubuntu 系統上，打開 Chrome 或 Firefox，進入抖音首頁（douyin.com）。頁面看起來一切正常——直到你按下 F5 重新整理。 這時，Chrome 會突然跳出一個系統層級的提示框，問你要不要允許這個網站用 bitbrowser:// 這個自訂協定，開啟你電腦上的「比特瀏覽器」。 - 廣告 - 如果你沒有安裝比特瀏覽器（或者你根本不想讓抖音打開它），這個彈窗就會不斷出現，煩到你想把 Chrome 卸載。 為什麼會這樣？ 很多跨境電商賣家、多帳號运营者，會使用一款叫做「比特瀏覽器（BitBrowser）」的防關聯工具。而抖音官方網頁為了方便這些商家，在前端 JavaScript 程式碼中內建了自動偵測機制。 具體來說，網頁一載入就會在背景自動發出一個 bitbrowser:// 的自訂協定（URL Scheme）請求。Linux 系統本身沒有這個軟體，Chrome 收到請求後，就會被迫跳出系統視窗，詢問使用者是否要尋找對應的應用程式。 ...

前言 如果你也是 Proxmox VE 的長期使用者，大概都有過這樣的經驗：打開 Proxmox 的 Web 管理介面，剛開始一切正常，記憶體佔用看起來很健康。但過了幾天、甚至幾個小時之後，那個分頁的記憶體使用量就像吹氣球一樣——從 200MB 慢慢膨脹到 1GB、2GB，甚至有人回報飆到 4GB 以上。 這個問題從 2013 年就被回報過，到現在 2026 年還沒被官方正式修復。今天我們就來仔細聊聊這個「長青問題」，以及目前能找到哪些解法。 - 廣告 - 問題全貌：一個從 2013 年延續至今的記憶體黑洞 原始回報（2021 年） Proxmox 官方論壇上有一個標題為「Proxmox web UI memory leak - starts at 200MB, gradually increases to gigabytes」的討論串（連結 ），由使用者 marcosscriven 於 2021 年 12 月提出。 他的回報重點如下： 瀏覽器影響範圍：在 Safari 和 Firefox 上都觀察到同樣的問題 作業系統：macOS 和 Windows 都有發生 增長幅度：從初始約 200MB，幾天內增長到超過 1GB 最嚴重的頁面：Console 和 Summary page 是重災區 使用情境：喜歡把這個分頁固定在瀏覽器上，方便隨時監控 Proxmox 的官方員工 dcsapak 回應時，詢問了具體是哪個頁面，並建議用瀏覽器的 DevTools（F12）做 memory allocation profile 來分析記憶體洩漏的具體位置。 ...

最近 AI 語音克隆技術越來越熱門，但大多數方案都需要昂貴的 GPU 來跑。如果你跟我一樣，手上只有一台 Proxmox VE（PVE）伺服器，沒有 GPU 直通，該怎麼辦？ 這篇文章要帶你在 PVE 的 LXC 容器裡，完全依靠 CPU 跑起來 MOSS-TTS-Nano——一個僅 0.1B 參數的輕量級語音合成模型。不需要 GPU、不需要複雜設定，四核心 CPU 就能流暢運行。 - 廣告 - 什麼是 MOSS-TTS-Nano？ MOSS-TTS-Nano 是一個開源的語音克隆（Voice Cloning）模型，由 OpenMOSS 團隊開發。它的 ONNX 版本特別適合 CPU 環境，因為： 零 GPU 依賴：移除了 PyTorch，改用 ONNX Runtime 進行推理 體積極小：僅 0.1B 參數，記憶體佔用極低 語音克隆：只需一段參考音檔，就能複製指定人的聲音 OpenAI 格式相容：透過 bridge.py 可以偽裝成標準 TTS API，直接給 SillyTavern 用 簡單來說，它讓你用最低的成本，體驗最完整的語音克隆功能。 ...

最近把家裡的網路架構從單純的 USB 無線網卡上網，一路進化到雙線並行 + 策略路由（PBR），踩了不少坑，也累積了不少實戰經驗。把這些筆記整理成文，方便日後重置時快速恢復，也分享給有類似需求的同好。 一、基礎架構：PVE + OpenWRT + USB Wi-Fi 網關 硬體配置 底層系統：Proxmox VE（PVE） 網關系統：OpenWRT（安裝於 PVE 的 VM 100） 對外網路（WAN）：TP-Link Archer T2U PLUS（RTL8821AU 晶片，USB 無線網卡） 關鍵硬體解法：USB 延長線的電壓災難 一開始我直接用了一條 5 米 USB 延長線把網卡接到 PVE 主機，結果 PVE 完全認不到網卡（unable to enumerate）。查了一下才發現是長距離 USB 延長線導致嚴重電壓衰減，網卡啟動電流不足。 解法：換成「帶獨立 110V 供電的 USB 擴展器（Hub）」，確保網卡啟動時供電充足。這個硬體成本不高，但解決了最大的穩定性問題。 PVE 開機啟動順序設定 因為 OpenWRT 是所有 LXC / VM 的網路源頭，而 USB 擴展器需要時間初始化，所以開機順序必須嚴格設定： VM 100（OpenWRT）：Boot order = 1 / Startup delay = 15（等待 USB 擴展器就緒） 其他 LXC / VM：Boot order = 2（或更後）/ Startup delay = 30~45（等待 OpenWRT 撥接上網） OpenWRT 自動連網腳本 USB 網卡直通載入速度比 OpenWRT 開機慢，需要延遲執行 Wi-Fi 重載指令。在 OpenWRT 的 /etc/rc.local 中，exit 0 之前加上： ...