Log for Ubuntu 台灣社群
WinBoat：在 Linux 上無縫執行 Windows 應用程式 （★ 84 分）
WinBoat 是一款讓 Linux 使用者能夠在幾分鐘內以無縫方式執行 Windows 應用程式的開源工具。目前屬於 Beta 階段，使用者需要先自行安裝相關前置元件，接著透過一個簡潔的圖形介面完成一鍵設定，省去繁瑐的指令列操作與設定檔調校。WinBoat 的核心在於利用 Docker 容器啟動內建 QEMU (開放原始碼虛擬機) Windows 虛擬機，再透過 FreeRDP (遠端桌面協議) 的 RemoteApps 模式將單一應用程式視窗呈現於 Linux 桌面，使使用者感受如同原生應用程式般的體驗。
在功能面上，WinBoat 對於無法正常執行於 CrossOver 或 WINE (Wine Is Not an Emulator) 的應用程式具有相當優勢，包括 Adobe 全家桶、Affinity Photo、Paint Tool Sai 等專業軟體，都能在同一個 Windows 桌面下運行；另自 0.8.0 版起加入 USB 傳遞 (passthrough) 實驗性支援，讓透過 USB 連接的周邊裝置可直接在虛擬 Windows 環境中設定使用。儘管目前尚未支援 GPU 傳遞，團隊正評估以 paravirtualized 驅動程式或 Looking Glass 間接顯示驅動器來後續強化圖形加速。遊戲層面則因反外掛 (anti-cheat) 需掛載核心級防護而難以虛擬化，暫時無法支援此類需求。
WinBoat 採用 MIT 授權並以社群共筆模式開發，官方網站與 GitHub (https://github.com/TibixDev/winboat) 均歡迎開發者、設計師與使用者貢獻程式碼、介面最佳化或測試回饋。目前也規劃支援 Podman 與 Flatpak 包裝，期望在不久的將來讓套件安裝與更新更為系統化；至於 Office 365、Adobe Acrobat 等常見辦公應用程式皆已確認可運行，提供 Linux 桌面使用者更完整的軟體生態。
從 Hacker News 討論來看，多數使用者認為 WinBoat 並非創新的子系統翻譯，而是以 Windows VM 加上 RDP 與小型後端 daemon 的整合包裝。有人指出在 rootless 模式下的 RDP 視窗偶有卡頓與斷線問題，拖放檔案支援不佳，且 Linux 底層顯示伺服器（X11、Wayland）兼容度差異造成使用體驗不一。另有討論提到 GPU 傳遞已在 dockur/windows 的 issue 底下被嘗試，但尚未成熟；也有網友呼籲提及 Proton (Steam Play) 作為遊戲取向的解決方案，與 Wine 或 Bottles 等專案共同為 Linux 獲取更多原生軟體支援。
面對實際使用情境，部分使用者反映在使用 WinBoat 或類似工具執行 Office 或 Edge 時會凍結視窗，必須反覆重啟；也有人以 VirtualBox 傳統 VM 為比較，認為 Docker 化虛擬機雖減輕體積，卻無法完全取代內建 GPU 加速下的流暢度。此外，對於 ARM64 架構尚無預先編譯版本、Flatpak 隔離機制下的資源存取、以及未來能否涵蓋更多硬體傳遞需求，社群皆抱持高度關注，期待未來版本能進一步提升穩定性與整合度。
👥 47 則討論、評論 💬
https://news.ycombinator.com/item?id=45518813
WinBoat 是一款讓 Linux 使用者能夠在幾分鐘內以無縫方式執行 Windows 應用程式的開源工具。目前屬於 Beta 階段，使用者需要先自行安裝相關前置元件，接著透過一個簡潔的圖形介面完成一鍵設定，省去繁瑐的指令列操作與設定檔調校。WinBoat 的核心在於利用 Docker 容器啟動內建 QEMU (開放原始碼虛擬機) Windows 虛擬機，再透過 FreeRDP (遠端桌面協議) 的 RemoteApps 模式將單一應用程式視窗呈現於 Linux 桌面，使使用者感受如同原生應用程式般的體驗。
在功能面上，WinBoat 對於無法正常執行於 CrossOver 或 WINE (Wine Is Not an Emulator) 的應用程式具有相當優勢，包括 Adobe 全家桶、Affinity Photo、Paint Tool Sai 等專業軟體，都能在同一個 Windows 桌面下運行；另自 0.8.0 版起加入 USB 傳遞 (passthrough) 實驗性支援，讓透過 USB 連接的周邊裝置可直接在虛擬 Windows 環境中設定使用。儘管目前尚未支援 GPU 傳遞，團隊正評估以 paravirtualized 驅動程式或 Looking Glass 間接顯示驅動器來後續強化圖形加速。遊戲層面則因反外掛 (anti-cheat) 需掛載核心級防護而難以虛擬化，暫時無法支援此類需求。
WinBoat 採用 MIT 授權並以社群共筆模式開發，官方網站與 GitHub (https://github.com/TibixDev/winboat) 均歡迎開發者、設計師與使用者貢獻程式碼、介面最佳化或測試回饋。目前也規劃支援 Podman 與 Flatpak 包裝，期望在不久的將來讓套件安裝與更新更為系統化；至於 Office 365、Adobe Acrobat 等常見辦公應用程式皆已確認可運行，提供 Linux 桌面使用者更完整的軟體生態。
從 Hacker News 討論來看，多數使用者認為 WinBoat 並非創新的子系統翻譯，而是以 Windows VM 加上 RDP 與小型後端 daemon 的整合包裝。有人指出在 rootless 模式下的 RDP 視窗偶有卡頓與斷線問題，拖放檔案支援不佳，且 Linux 底層顯示伺服器（X11、Wayland）兼容度差異造成使用體驗不一。另有討論提到 GPU 傳遞已在 dockur/windows 的 issue 底下被嘗試，但尚未成熟；也有網友呼籲提及 Proton (Steam Play) 作為遊戲取向的解決方案，與 Wine 或 Bottles 等專案共同為 Linux 獲取更多原生軟體支援。
面對實際使用情境，部分使用者反映在使用 WinBoat 或類似工具執行 Office 或 Edge 時會凍結視窗，必須反覆重啟；也有人以 VirtualBox 傳統 VM 為比較，認為 Docker 化虛擬機雖減輕體積，卻無法完全取代內建 GPU 加速下的流暢度。此外，對於 ARM64 架構尚無預先編譯版本、Flatpak 隔離機制下的資源存取、以及未來能否涵蓋更多硬體傳遞需求，社群皆抱持高度關注，期待未來版本能進一步提升穩定性與整合度。
👥 47 則討論、評論 💬
https://news.ycombinator.com/item?id=45518813
其實現在 Linux 對 windows 的支援已經算很好了
之前遇到 windows 的惡意程式，都用 Linux 環境整理，某次手抽筋在檔案上點了二下，wine 就中毒了 Orz
之前遇到 windows 的惡意程式，都用 Linux 環境整理，某次手抽筋在檔案上點了二下，wine 就中毒了 Orz
設計一個低延遲的 10G 乙太網核心（2023） （★ 102 分）
作者在這篇部落格系列的開篇文章中，介紹了自己如何以個人專案的方式開發一個低延遲 10G 乙太網路 (Ethernet) 核心，運行於 FPGA (可程式化邏輯閘陣列) 上。這個專案的目的在於探索高頻寬乙太網設計與低延遲邏輯的最佳化技術，並藉此提升作者對 FPGA 設計與高速通訊的實戰經驗。該設計在環迴 (loopback) 測試中的延遲低於 60 奈秒，已接近市售專業產品的水準。文章預告後續篇章將依序探討設計概要與驗證、降低延遲的技術手法、與市面上其他低延遲核心的比較以及潛在改進方向等內容。
文中提到，此專案除了自製乙太網核心本身外，也注重測試與驗證流程。作者採用了以 Python 為基礎的驗證框架 `cocotb` 與 `pyuvm`，讓開發者能以高階語言撰寫 FPGA 測試程式，進而更有效率地進行模擬與除錯。此外，文章也提供多個技術背景資料來源，讓讀者可補充對乙太網路第 1 層與第 2 層架構的理解，如 10G PHY (實體層) 的 64B/66B 編碼概念、IEEE 802.3 規範等，為後續篇章建立基礎。
Hacker News 討論區的留言多聚焦於延遲表現與應用場景。許多讀者注意到作者的背景來自 Jane Street，一家以高度自動化和極低延遲交易聞名的金融公司，因此推測這樣的技術開發極有可能與高頻交易 (HFT, High-Frequency Trading) 相關。部分人驚訝於延遲可低至 60 奈秒，並補充市面上有部分交換器達到約 4 奈秒的延遲，但那通常是特化硬體設計，實作難度極高。有工程師指出，像這類的低延遲設計並非以「指令週期」為核心思維，而是直接在硬體邏輯層處理信號流，因此延遲瓶頸極大程度上受到實體電氣傳輸時間的限制。
另一些留言延伸到市場應用層面。例如有人討論 24/7 全時段金融市場是否真有實際需求，或僅僅出於技術可行性而推進。部分留言認為無論市場是否全天候營運，系統穩定與可靠性都至關重要，特別是在每停機一小時可能造成數百萬美元損失的環境中。其他工程師則分享自己在 FPGA 通訊設計上的經驗，指出要兼顧速度、可維護性與功耗是一項極具挑戰的工程取捨。
整體而言，文章與討論共同呈現了低延遲乙太網設計領域的技術深度與實務挑戰。對 FPGA 和高速度網路設計有興趣的工程師而言，這系列內容不僅展示了高效能硬體設計的技術巧思，也反映出該技術在金融通信、高頻交易與高性能運算領域的實際價值與極限追求。
👥 25 則討論、評論 💬
https://news.ycombinator.com/item?id=45522406
作者在這篇部落格系列的開篇文章中，介紹了自己如何以個人專案的方式開發一個低延遲 10G 乙太網路 (Ethernet) 核心，運行於 FPGA (可程式化邏輯閘陣列) 上。這個專案的目的在於探索高頻寬乙太網設計與低延遲邏輯的最佳化技術，並藉此提升作者對 FPGA 設計與高速通訊的實戰經驗。該設計在環迴 (loopback) 測試中的延遲低於 60 奈秒，已接近市售專業產品的水準。文章預告後續篇章將依序探討設計概要與驗證、降低延遲的技術手法、與市面上其他低延遲核心的比較以及潛在改進方向等內容。
文中提到，此專案除了自製乙太網核心本身外，也注重測試與驗證流程。作者採用了以 Python 為基礎的驗證框架 `cocotb` 與 `pyuvm`，讓開發者能以高階語言撰寫 FPGA 測試程式，進而更有效率地進行模擬與除錯。此外，文章也提供多個技術背景資料來源，讓讀者可補充對乙太網路第 1 層與第 2 層架構的理解，如 10G PHY (實體層) 的 64B/66B 編碼概念、IEEE 802.3 規範等，為後續篇章建立基礎。
Hacker News 討論區的留言多聚焦於延遲表現與應用場景。許多讀者注意到作者的背景來自 Jane Street，一家以高度自動化和極低延遲交易聞名的金融公司，因此推測這樣的技術開發極有可能與高頻交易 (HFT, High-Frequency Trading) 相關。部分人驚訝於延遲可低至 60 奈秒，並補充市面上有部分交換器達到約 4 奈秒的延遲，但那通常是特化硬體設計，實作難度極高。有工程師指出，像這類的低延遲設計並非以「指令週期」為核心思維，而是直接在硬體邏輯層處理信號流，因此延遲瓶頸極大程度上受到實體電氣傳輸時間的限制。
另一些留言延伸到市場應用層面。例如有人討論 24/7 全時段金融市場是否真有實際需求，或僅僅出於技術可行性而推進。部分留言認為無論市場是否全天候營運，系統穩定與可靠性都至關重要，特別是在每停機一小時可能造成數百萬美元損失的環境中。其他工程師則分享自己在 FPGA 通訊設計上的經驗，指出要兼顧速度、可維護性與功耗是一項極具挑戰的工程取捨。
整體而言，文章與討論共同呈現了低延遲乙太網設計領域的技術深度與實務挑戰。對 FPGA 和高速度網路設計有興趣的工程師而言，這系列內容不僅展示了高效能硬體設計的技術巧思，也反映出該技術在金融通信、高頻交易與高性能運算領域的實際價值與極限追求。
👥 25 則討論、評論 💬
https://news.ycombinator.com/item?id=45522406
Ubuntu 25.10「Questing Quokka」釋出
Canonical 釋出了代號為 Questing Quokka 的 Ubuntu 25.10。這是一個短期支援版本，僅支援 9 個月，預計於明年 4 月釋出的下一個版本 Ubuntu 26.04 將會是長期支援版本。Ubuntu 25.10 的新功能包含：Linux 核心 6.17、Mesa 25.2.3、GNOME 49、Firefox 143、LibreOffice 25.8、Audacity 3.7.1、GIMP 3.0.4、BlueZ 5.83、Pipewire 1.4.7、OpenSSL 3.5.3、GCC 15.2、binutils 2.45 以及 glibc 2.42 等等。其他重要變更包含：Ubuntu 工作階段僅支援 Wayland、NVIDIA 專有驅動啟用暫停／恢復支援、新的圖片檢視器與終端機預設應用程式、TPM 支援全碟加密的復原金鑰管理，等等。
Canonical 釋出了代號為 Questing Quokka 的 Ubuntu 25.10。這是一個短期支援版本，僅支援 9 個月，預計於明年 4 月釋出的下一個版本 Ubuntu 26.04 將會是長期支援版本。Ubuntu 25.10 的新功能包含：Linux 核心 6.17、Mesa 25.2.3、GNOME 49、Firefox 143、LibreOffice 25.8、Audacity 3.7.1、GIMP 3.0.4、BlueZ 5.83、Pipewire 1.4.7、OpenSSL 3.5.3、GCC 15.2、binutils 2.45 以及 glibc 2.42 等等。其他重要變更包含：Ubuntu 工作階段僅支援 Wayland、NVIDIA 專有驅動啟用暫停／恢復支援、新的圖片檢視器與終端機預設應用程式、TPM 支援全碟加密的復原金鑰管理，等等。