這篇文章把 Ubuntu Server 16.04 上 htop 畫面中的欄位逐一拆解，核心觀念是：htop/top 顯示的數字大多來自 Linux 的 procfs（掛載在 /proc 的虛擬檔案系統），而不是神祕的即時魔法。uptime 讀取 /proc/uptime，第一個值是系統已開機秒數，第二個值是閒置時間；多核心機器上閒置時間會把各核心相加。load average（平均負載）則來自 /proc/loadavg，三個數字代表約 1、5、15 分鐘的指數衰減移動平均，計算對象是正在執行、等待 CPU（中央處理器）執行，以及不可中斷等待的行程；因此 load 1.0 不等於所有情境下的 50% CPU 使用率，必須拿核心數、I/O（輸入／輸出）等待一起判讀，高負載也可能不是 CPU 忙，而是磁碟或網路等待。

文章接著說明 Tasks、PID、行程樹、使用者與行程狀態等欄位。Tasks 是 Linux 核心對行程的稱呼，htop 也可切換顯示使用者執行緒與核心執行緒；PID（Process ID，行程識別碼）可用來在 /proc/<pid>/ 讀取命令列、工作目錄、執行檔與狀態。行程樹反映父子關係，例如 shell 透過 fork/exec/wait 產生並等待子行程。狀態欄中的 R、S、D、Z、T、t 分別代表可執行、可中斷睡眠、不可中斷睡眠、殭屍行程、被工作控制停止、被除錯器追蹤停止；作者也用 SIGINT、SIGTERM、SIGKILL 等 signal（訊號，核心用來通知或控制行程的機制）解釋為何有些行程能優雅結束，有些只能強制終止。

在排程與記憶體部分，文章說明 Linux 以分時方式讓多個行程輪流使用 CPU；nice 值是使用者空間可調整的優先權提示，範圍從 -20 到 19，數字越小越不「客氣」、越容易取得 CPU 時間，而 PRI 則是核心實際使用的優先權。記憶體欄位也不能只看單一數字：VIRT/VSZ 是虛擬記憶體總量，可能包含尚未真正使用的配置與記憶體對應檔案；RES/RSS 是目前留在實體記憶體中的部分；SHR 是可能與其他行程共享的記憶體；MEM% 則是 RES 相對於總 RAM（隨機存取記憶體）的比例。作者也提醒 htop 的顏色有意義，例如 CPU 色條區分一般、低優先權與核心執行緒，記憶體色條則區分已用、緩衝區與快取。

文章後半段把一台新 DigitalOcean Ubuntu 主機開機後常見的服務逐一查明用途，包括 systemd-journald、udevd、timesyncd、cron、rsyslogd、sshd、agetty，以及 LVM（Logical Volume Management，邏輯磁碟區管理）、D-Bus（行程間通訊機制）、ACPI（進階組態與電源介面）、LXC（Linux Containers，Linux 容器）、RAID（磁碟陣列）、iSCSI（透過 IP 連接儲存設備的協定）相關服務。作者嘗試移除部分不需要的套件，並記錄副作用：移除 D-Bus 會讓 timedatectl 失效，移除 acpid 可能影響主機關機狀態判定，移除 getty 會讓雲端主機的主控台無法登入。整體上，這篇文章不是單純列 htop 欄位定義，而是示範如何用 strace（系統呼叫追蹤工具）、/proc、套件來源與小型 C 程式，追到每個數字與行程背後的系統行為。

Hacker News 留言多半肯定這篇文章的實用性，不少人表示多年來常拿它當參考；也有人說自己平常只用 htop 找 PID 或 CPU 異常行程，讀完才理解更多欄位意義。有留言補充，若只是找 PID，pgrep 往往比在 htop 內搜尋更適合；也有人提到 top 可用 > 依記憶體使用量排序，協助排查主機變慢的原因。另一個常見建議是調整 htop 預設習慣：關閉使用者執行緒以減少雜訊，並開啟行程樹，因為行程來源與父子關係常比單一資源數字更能幫助除錯。

討論也延伸到現代監控工具的需求。有讀者批評 htop/top 看得到平均負載，卻看不到整機耗電功率；也有人認為在 GPU（圖形處理器）工作負載越來越常見的情境下，傳統工具若不演進會顯得不足。不少留言推薦 btop，認為它提供更現代的介面，並整合網路、GPU、磁碟與耗電功率等資訊。不過反方也指出 GPU 並不會取代 CPU，兩者負責不同工作；因此 htop/top 仍是理解 Linux 行程、排程與資源使用狀態的基礎工具，而 btop 等新工具則補足更廣的硬體監控需求。

PCBJam 是一個早期 alpha 測試版，主打在瀏覽器中編輯 KiCad（開源 PCB EDA 套件；PCB 為印刷電路板，EDA 為電子設計自動化）檔案。它提供 Demo Board 範例，也能開啟使用者自己的本機資料夾；檔案不會上傳到伺服器，而是將副本匯入瀏覽器中編輯，原始檔不會被改動。編輯內容可留在瀏覽器端，並可隨時下載成 .zip 匯出到自己的電腦，產品目前也開放早期邀請等候名單。

功能上，PCBJam 已呈現 KiCad 常見工作區，包括電路圖編輯器、符號編輯器、PCB 編輯器、封裝編輯器、Gerber 檢視器、PCB 計算器與圖框編輯器。頁面也展示龐大的 KiCad 元件庫：符號庫有 222 個分類、封裝庫有 155 個分類，涵蓋連接器、電源、微控制器、射頻、感測器與各式封裝。儲存區說明元件庫資料會在瀏覽器快取、需要時重新下載；3D 模型按板子取得，因此最值得清理其快取。頁面同時提供 pcbjam v0.1.6.2 的 GPL（GNU General Public License，自由軟體授權條款）對應原始碼與 GitHub 專案。

開發者在 Hacker News 補充，這不是單純檢視器，而是把 KiCad PCB EDA suite 移植到瀏覽器中；Firefox 表現最佳，Chrome 可用，Safari 則勉強可用。PCBJam 由匈牙利 Emergence Engineering 製作，團隊背景包含富文字編輯器與 CRDT（Conflict-free Replicated Data Type，無衝突複製資料型態，常用於多人協作）。技術上，他們改寫出可銜接 KiCad Graphics Abstraction Layer 的 WebGL（瀏覽器繪圖技術）路徑，而不是硬模擬 OpenGL（跨平台圖形介面）；也擴充舊有 wxWidgets Web 移植版本，並用 Emscripten、Pthreads（C/C++ 常用的多執行緒介面）與 WASM（WebAssembly，讓瀏覽器執行接近原生效能程式的格式）支撐 DRC（Design Rule Check，設計規則檢查）和 3D 軟體算圖。

開發者表示，為了降低體積，他們處理 Asyncify（讓 WASM 暫停後呼叫 JavaScript 的機制）與原生例外處理不相容的問題，替 Binaryen（WebAssembly 工具組）補了一段編譯流程，讓打包體積縮小 30% 到 40%，載入時間從約 10 秒降到 1 秒；Open CASCADE（3D 幾何函式庫）也被拆成延後載入的 WASM 模組，從 180 MB 降到 130 MB、壓縮後約 24 MB。未來規劃是在 KiCad 之上加入協作、AI（Artificial Intelligence，人工智慧）整合、分享與製造流程整合，提供免費方案，較大或封閉專案約每月 30 美元，另有自架、企業功能、原生 App 與行動版；團隊也希望盡量貼近 KiCad 主線，並回饋 Binaryen、KiCad 與 wxWidgets。

討論中的實務回饋集中在產品化方向。有人建議整合 LCSC（立創商城，電子零件通路）零件編號，以符合 JLCPCB（PCB 製造與組裝服務）代工組裝需求；Viktor 回應目前沒有移植 KiCad 的 Python 外掛系統，未來可能以 Figma 式外掛或介面覆蓋層實作。也有人要求首次載入時顯示下載大小，作者表示大型應用程式約 30 MB；iOS Safari（Apple 行動裝置上的 Safari）目前因記憶體問題不穩，行動版尚未最佳化。另有教育工作者認為瀏覽器版 KiCad 能大幅降低學生電腦安裝門檻，並期待 Git（常見版本控制工具）整合；也有人看好 PCB 製造商導入客製設計規則與下單按鈕。整體反應偏正面，尤其是完整工作流程與 3D 檢視器可用令人印象深刻，但也有人批評產品頁文字像 AI 產生，作者表示正式推出前會重寫。