ZLUDA 是讓未修改的 CUDA（Compute Unified Device Architecture，NVIDIA 的 GPU 平行運算平台與 API）應用程式在非 NVIDIA GPU（圖形處理器）上執行的相容層。這次 ZLUDA 6 版更新代表專案已有足夠累積進展，值得使用者重新嘗試；作者也說明，ZLUDA 採連續開發模式，主要版本號不代表單一重大功能或相容性斷裂，而是階段性里程碑，6 版內容與最新預覽版 6-preview.79 相同。

本次最受矚目的新進展包括 32 位元 PhysX（NVIDIA 的物理模擬技術）預備支援、基本材質貼圖支援，以及 Blender 可在 ZLUDA 上使用。PhysX 部分尚未完成，但已可讓部分依賴舊版 PhysX 的經典遊戲在 AMD GPU 上取得更高畫面更新率，並可能首次開啟碎片、火焰等額外視覺效果；作者以 2010 年版 Mafia II 內建效能測試為例，展示在最高設定且啟用 PhysX 時的效果。不過目前流體模擬仍可能出現異常，Steam 遊戲載入 ZLUDA 的方式也不理想，因此一般使用者較適合等待相關 PR（pull request，合併請求）正式合併到預覽版後再試用。作者也提醒，PCGamingWiki 的 PhysX 遊戲清單同時混有 32 位元 PhysX 與 64 位元 GameWorks（NVIDIA 遊戲中介軟體套件），兩者是不同技術。

Windows 支援也有明顯改善。過去 ZLUDA 在 Windows 上落後 Linux，主要問題在 cuBLAS、cuDNN 等效能函式庫；Linux 版 ROCm（Radeon Open Compute，AMD 的 GPU 運算平台）通常會一次安裝相容版本的驅動與函式庫，但 Windows 使用者多半只會隨 Adrenalin 驅動取得執行階段驅動，其餘 ROCm 元件必須自行尋找。新版 ZLUDA 雖未替使用者解決整個 ROCm 生態問題，但會更清楚提示缺少哪些函式庫與安裝方式，Windows 載入器 zluda.exe 也更穩定，能自動處理效能函式庫載入。機器學習方面，作者根據 PyTorch（常見機器學習框架）使用者提供的追蹤記錄，陸續補上新指令、編譯器修正與效能函式庫改善。

專案方向也出現轉變：ZLUDA 已不再有商業資金贊助，回到作者週末興趣專案的狀態，因此未來優先考量不再是商業價值，而是作者覺得有趣的方向；這也解釋了為何材質貼圖、PhysX 與 Windows 改善突然成為重點。作者表示開發仍會持續，但投入時間會比過去少，更新頻率也可能低於每季一次。討論中不少人對這種「以樂趣為主」的取向表示認同，並認為 ZLUDA 對社群的真正價值可能在較小眾、商業誘因不足的應用場景，而非已有人投入解法的熱門工作負載。

Hacker News 討論則延伸到 CUDA 生態與替代技術。一些留言者關心 ZLUDA 用於大型語言模型（LLM, Large Language Model）時相較 Vulkan（跨平台圖形與運算 API）的表現；回覆者指出，隨著 Mac 使用者增加、核心與框架更趨可攜，以及 Unsloth 等工具出現，CUDA 在 LLM 領域的「護城河」正在變弱。不過也有人認為 ZLUDA 聚焦 ROCm API 有其技術理由，因為 ROCm 提供較接近 CUDA 的能力，可能讓核心模擬更可行；至於 Vulkan 或 OpenCL（跨平台平行運算標準）是否足以支撐視覺語言模型（VLM, Vision-Language Model）、擴散模型（Diffusion Model）等工作負載，討論中仍未有明確結論。另有留言指出，32 位元 PhysX 特別有意思，因為 NVIDIA 曾短暫考慮在 5000 系列顯示卡移除相關支援，後來因反彈而恢復；也有人提出授權疑慮，質疑在非 NVIDIA 硬體上執行 CUDA 是否違反 NVIDIA 授權條款。

Xsnow 是一款在 X11（Unix/Linux 圖形視窗系統）桌面上顯示飄雪、樹木、北極熊、聖誕老人等裝飾效果的老牌小程式。LWN 報導指出，這個看似無害的視覺玩具被發現內建一個政治彩蛋：當程式語言設定為俄文 `ru` 時，畫面出現烏克蘭國旗圖樣的機率會大幅提高。相關程式碼把該圖樣命名為 `EXTRATREE`，一般語系約有 2% 機率出現，但俄文語系下機率提高到 30%。文章作者實測 Debian 13「trixie」上的 xsnow，英文設定下未明顯看到國旗，改成俄文後則很快在桌面上出現多面烏克蘭國旗。

提出問題的 Alexander Ivanov 認為，這種針對俄文語系使用者的隱藏行為違反 Debian Free Software Guidelines（DFSG，Debian 自由軟體準則）中不得歧視個人、群體或用途領域的原則。不過 Debian 開發者回應指出，DFSG 管的是授權條款是否歧視，而不是軟體本身的行為；xsnow 主要採用 GPLv3（GNU General Public License 第 3 版）等 Debian 接受的自由軟體授權，因此不構成 DFSG 違規。Russ Allbery 也同意 DFSG 並非重點，但提醒以使用者名稱、語系或本機設定觸發使用者不預期的隱藏行為，可能具有欺瞞性，未必適合放在 Debian 官方套件庫中，且容易引發大量爭議卻帶來很少實質效益。

文章也指出，目前 Ivanov 尚未正式提出 bug 回報，討論大致停在郵件論壇。xsnow 的 Debian 套件維護者 Willem Vermin 同時也是上游專案維護者，LWN 詢問他是否願意回退這項顯示行為，但截至發稿未收到回覆。Debian 過去曾因冒犯性內容移除 fortune 相關套件，也曾因 systemd 上游變更造成相容性問題而要求回退；這顯示即使維護者不同意，Debian 專案在少數情況下仍可能介入。不過文章強調，若要讓 Debian 採取行動，正式提出 bug、說服專案成員與完成程序比單純在郵件論壇抱怨更有可能產生結果。

Hacker News 討論分成幾個主要立場。一派認為這只是作者在自由軟體中表達政治立場，且 xsnow 本來就有低機率顯示烏克蘭國旗，俄文語系只是提高機率；它又是非常小眾、非預設安裝的桌面裝飾程式，使用者不想要可以移除、修改圖檔或使用分支版本。也有人主張，烏克蘭國旗本身不是仇恨訊息，將其視為歧視反而反映了對烏克蘭存在的敵意；並指出俄文使用者不只在俄羅斯，也包括烏克蘭、喬治亞、中亞與海外社群，不能簡化為單一政治身分。

另一派則強調問題不在是否贊成烏克蘭，而在於隱藏、未揭露且依語系差別對待使用者。多位留言者指出，在俄羅斯或被占領地區，螢幕上突然出現烏克蘭國旗可能造成失業、法律麻煩、暴力威脅，甚至被政府或周遭人士視為政治表態；把這種風險加到一個使用者以為只是飄雪動畫的程式裡，會侵蝕對發行版與套件維護流程的信任。有人建議至少應在文件中明確揭露，讓使用者在安裝或執行前知道會出現哪些圖樣；也有人提到 Slackware-current 已採用 ALT Linux 的修補，移除此類抗議軟體行為。

討論也延伸到 Debian 是否需要政策來處理「抗議軟體」（protestware，軟體作者在程式中加入政治抗議訊息或特殊行為）。反對者擔心若允許依語系、地區或身分觸發政治訊息，未來可能出現以巴、伊朗、俄烏或兩岸等議題的「套件戰」，讓官方套件庫看似替特定政治表態背書；也有人拿 faker、colors.js 等曾因作者抗議而破壞供應鏈信任的事件作比較。支持保留者則認為自由軟體本來就允許作者表達價值觀，問題應由使用者修改、分支或發行版取捨解決。整體來看，爭議核心已不只是 xsnow 的幾面旗子，而是自由軟體專案在政治表達、使用者安全、透明度與發行版責任之間該如何劃線。

Godot 基金會宣布將更新開放原始碼遊戲引擎 Godot 的貢獻規範，不再接受由 AI 撰寫的程式碼、由 AI 代理程式送出的 pull request（PR，程式碼合併請求），也會拒收在人與人溝通中使用 AI 產製的文字。Godot 是支撐 Slay the Spire 2、The Case of the Golden Idol 等遊戲的開放原始碼引擎；基金會表示，近月大量「AI slop」（粗製濫造的 AI 產物）湧入，讓本已繁瑣的程式碼審查工作變得更消耗心力。

基金會的核心理由不是單純反對 AI 工具，而是維護者無法把審查時間有效轉化為培養新貢獻者的過程。若審查意見只是被機器吸收、再轉成下一輪修改，維護者就難以判斷對方是否真的理解程式碼，也無法期待對方未來能負責修補問題。Godot 將要求所有貢獻都來自能對程式碼負責的人；AI 可用於瑣碎工作，但必須揭露使用情況。機器翻譯仍可接受，前提是原文由人撰寫。基金會也表示，AI 工具變化很快，政策會採保守態度並持續重新評估。

Hacker News 討論中，多數高分留言聚焦在維護者負擔與責任歸屬。有開發者認為，PR 審查不只是驗證程式是否可執行，更是開放原始碼專案培養未來維護者的方式；若投稿者只是把 AI 輸出轉交給他人審查，等於把工作往下游丟。也有人形容冗長的 AI 說明與大包修改像是對人類注意力的「阻斷服務攻擊」（DoS，Denial of Service），讓志工維護者在下班後的有限時間被耗盡。另一個常見觀點是，政策雖難完全偵測 AI 使用，卻能讓維護者在懷疑為低品質 AI 投稿時更快關閉 PR，減少逐案辯論成本。

討論也提出法律與治理層面的疑慮。有留言指出，大型語言模型（LLM, Large Language Model）可能訓練自 GPL（GNU General Public License，自由軟體授權條款）或外洩的專有程式碼，若 AI 輸出牽涉授權汙染，專案可能面臨著作權風險；對 Wine、ReactOS 這類需要維持「潔淨室逆向工程」（clean-room reverse engineering）的專案尤其敏感。也有人提到 DCO（Developer Certificate of Origin，開發者原產地憑證）要求貢獻者聲明自己有權提交作品，AI 產物可能讓這項聲明變得模糊。

反方與保留意見則認為，應該審查貢獻者是否真正理解並願意維護自己的修改，而不是只看工具來源；若一個人能逐行解釋、負責修補，AI 是否參與或許不該是唯一判準。部分留言也預期，隨著 AI 輔助程式設計工具進步，全面禁止可能只是短期緩衝，長期更可行的做法或許是要求小型、清楚、可驗證的提交與明確責任制。不過也有支持者回應：若有人相信 AI 能更好維護 Godot，大可分支專案自行證明；這也凸顯此次爭議的核心並非效率，而是開放原始碼協作中信任、學習與長期維護責任的分配。

這篇文章把 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 產生，作者表示正式推出前會重寫。