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，大可分支專案自行證明；這也凸顯此次爭議的核心並非效率，而是開放原始碼協作中信任、學習與長期維護責任的分配。