Log for Ubuntu 台灣社群
Linux 上 epoll 與 io_uring 的比較 （★ 102 分）
作者以教學專案 TinyGate 反向代理伺服器為起點，說明為何開始研究 Linux 的非同步 I/O（Input/Output，輸入／輸出）機制。第一版 TinyGate 採 worker 架構，雖然能用，但效能和 nginx、HAProxy 這類成熟工具差距很大；第二版改用 epoll 後，效能明顯提升；後來又改寫成 io_uring 架構。文章的核心主張是：epoll 是「就緒模型」，告訴程式某個 I/O 可以做了；io_uring 則是「完成模型」，讓程式提交操作後，由核心在完成時通知結果。
epoll 的主要成本來自大量系統呼叫：註冊檔案描述符後，每次事件通常還需要 `epoll_wait` 加上 `read` 或 `write`，也就是每個 I/O 事件都要多次跨越使用者態與核心態，造成情境切換開銷。io_uring 則使用應用程式與 Linux 核心共用的環狀緩衝區，分成提交佇列與完成佇列；程式把多個操作放入提交佇列，核心完成後再把結果放回完成佇列。一般情況仍需要 `io_uring_enter()` 觸發核心處理，但可以一次提交與回收多個 I/O，若啟用 SQPOLL（Submission Queue Polling，提交佇列輪詢），甚至能在穩定負載下接近零系統呼叫，不過代價是核心執行緒會持續輪詢並消耗 CPU。
文章也提醒，io_uring 不是單純替換 API 就能得到全部好處。真正的零拷貝（zero-copy）需要事先註冊緩衝區，網路傳送可利用 `IORING_OP_SEND_ZC`，但需要較新的核心版本；錯誤也不是以同步系統呼叫的回傳值出現，而是透過 CQE（Completion Queue Event，完成佇列事件）的結果欄位非同步回報。作者最後認為，在 Linux kernel 5.1 以上的現代伺服器上，從零開始的新專案多半應優先考慮 io_uring，而不是再以 epoll 作為主要架構。
Hacker News 討論中，不少人補充 io_uring 的實際採用仍有現實限制。有人指出它曾是高風險攻擊面，常被 seccomp（secure computing mode，Linux 的系統呼叫過濾機制）封鎖，且多次涉及權限提升漏洞，因此像 Go 這類語言執行環境不一定會把它當成安全預設；但也有人補充，近期 Linux 已加入 cBPF（classic Berkeley Packet Filter，可用來限制允許的 io_uring 操作）能力，Red Hat Enterprise Linux 9 與 10 也已預設支援，企業環境的阻力可能正在下降。另有實務經驗指出，某些資料庫伺服器把 Asio 的 epoll 後端換成 io_uring 後 CPU 使用率反而上升，因此評估時不應只看 CPU 百分比，而要比較吞吐量、延遲與滿載時的服務品質。
討論也修正了「io_uring 一定更快」的簡化說法。多位留言者認為，許多非同步框架仍建立在傳統 poll 模型上，若沒有重寫成能善用 io_uring 的操作串接、批次提交與零系統呼叫模式，效能優勢可能有限；也有人指出在大型零拷貝緩衝區上 io_uring 很強，但在某些 POSIX 模擬或簡單輪詢情境中未必勝出。針對 TinyGate 這類反向代理，留言者還建議除了 I/O API 外，也要做 CPU 綁定、每核心一個執行緒、監聽 socket 對齊特定 CPU、善用網卡流量導向，避免跨核心溝通造成快取失效與鎖競爭；換言之，io_uring 是重要工具，但高效能伺服器仍取決於整體架構、記憶體配置、安全政策與網路堆疊調校。
👥 29 則討論、評論 💬
https://news.ycombinator.com/item?id=48613872
作者以教學專案 TinyGate 反向代理伺服器為起點，說明為何開始研究 Linux 的非同步 I/O（Input/Output，輸入／輸出）機制。第一版 TinyGate 採 worker 架構，雖然能用，但效能和 nginx、HAProxy 這類成熟工具差距很大；第二版改用 epoll 後，效能明顯提升；後來又改寫成 io_uring 架構。文章的核心主張是：epoll 是「就緒模型」，告訴程式某個 I/O 可以做了；io_uring 則是「完成模型」，讓程式提交操作後，由核心在完成時通知結果。
epoll 的主要成本來自大量系統呼叫：註冊檔案描述符後，每次事件通常還需要 `epoll_wait` 加上 `read` 或 `write`，也就是每個 I/O 事件都要多次跨越使用者態與核心態，造成情境切換開銷。io_uring 則使用應用程式與 Linux 核心共用的環狀緩衝區，分成提交佇列與完成佇列；程式把多個操作放入提交佇列，核心完成後再把結果放回完成佇列。一般情況仍需要 `io_uring_enter()` 觸發核心處理，但可以一次提交與回收多個 I/O，若啟用 SQPOLL（Submission Queue Polling，提交佇列輪詢），甚至能在穩定負載下接近零系統呼叫，不過代價是核心執行緒會持續輪詢並消耗 CPU。
文章也提醒，io_uring 不是單純替換 API 就能得到全部好處。真正的零拷貝（zero-copy）需要事先註冊緩衝區，網路傳送可利用 `IORING_OP_SEND_ZC`，但需要較新的核心版本；錯誤也不是以同步系統呼叫的回傳值出現，而是透過 CQE（Completion Queue Event，完成佇列事件）的結果欄位非同步回報。作者最後認為，在 Linux kernel 5.1 以上的現代伺服器上，從零開始的新專案多半應優先考慮 io_uring，而不是再以 epoll 作為主要架構。
Hacker News 討論中，不少人補充 io_uring 的實際採用仍有現實限制。有人指出它曾是高風險攻擊面，常被 seccomp（secure computing mode，Linux 的系統呼叫過濾機制）封鎖，且多次涉及權限提升漏洞，因此像 Go 這類語言執行環境不一定會把它當成安全預設；但也有人補充，近期 Linux 已加入 cBPF（classic Berkeley Packet Filter，可用來限制允許的 io_uring 操作）能力，Red Hat Enterprise Linux 9 與 10 也已預設支援，企業環境的阻力可能正在下降。另有實務經驗指出，某些資料庫伺服器把 Asio 的 epoll 後端換成 io_uring 後 CPU 使用率反而上升，因此評估時不應只看 CPU 百分比，而要比較吞吐量、延遲與滿載時的服務品質。
討論也修正了「io_uring 一定更快」的簡化說法。多位留言者認為，許多非同步框架仍建立在傳統 poll 模型上，若沒有重寫成能善用 io_uring 的操作串接、批次提交與零系統呼叫模式，效能優勢可能有限；也有人指出在大型零拷貝緩衝區上 io_uring 很強，但在某些 POSIX 模擬或簡單輪詢情境中未必勝出。針對 TinyGate 這類反向代理，留言者還建議除了 I/O API 外，也要做 CPU 綁定、每核心一個執行緒、監聽 socket 對齊特定 CPU、善用網卡流量導向，避免跨核心溝通造成快取失效與鎖競爭；換言之，io_uring 是重要工具，但高效能伺服器仍取決於整體架構、記憶體配置、安全政策與網路堆疊調校。
👥 29 則討論、評論 💬
https://news.ycombinator.com/item?id=48613872
歷經六年、360 多個修補程式後，Linux 移除 strncpy API （★ 102 分）
Linux 7.2 已把 strncpy API（應用程式介面）從 Linux 核心中移除。strncpy() 是 C 語言中用來複製指定位元組數的字串函式，長期被視為不建議使用；這次在約六年、362 個提交後，核心內已不再有任何 strncpy 使用處，因此正式刪除這個介面與最後的 CPU 架構專用實作。
文章指出，strncpy 多年來一直是錯誤來源，主要問題在於它對 NUL 字元（值為 0、常用來標示 C 字串結尾）的處理很反直覺：它不一定會產生 NUL 結尾，卻又可能對目的地緩衝區進行多餘補零，造成效能浪費。Linux 核心接下來會依情境改用更明確的函式，例如 strscpy() 用於需要 NUL 結尾的目的地，strscpy_pad() 用於需要 NUL 結尾且補零的情境，strtomem_pad() 用於不以 NUL 結尾的固定寬度欄位，memcpy_and_pad() 用於有界限且明確補齊的複製，memcpy() 則用於已知長度的記憶體複製。
討論中不少開發者補充 strncpy 的歷史脈絡：它原本來自早期 UNIX 核心，用於處理目錄項目中「2 位元組 inode（檔案系統用來識別檔案的索引節點）加上 14 位元組、補零但不以 NUL 結尾的檔名欄位」，並不是為了一般安全字串複製而設計。也有人提醒，所謂 360 多個修補並不代表發現 360 多個漏洞，而是移除 360 多處使用；但多位有經驗的 C 開發者表示，在程式碼審查中看到 strncpy 往往就是高風險訊號。
討論也延伸到 C 字串設計本身。許多人認為 NUL 結尾字串是安全與效能問題的根源之一，因為只要結尾字元遺失，標準字串函式就可能一路讀到配置範圍外，引發記憶體越界與資安風險；此外，在迴圈中反覆呼叫 strlen() 也可能讓原本 O(N) 的操作變成 O(N^2)。也有留言比較 Pascal 式長度前綴字串、帶長度的緩衝區結構，以及 strlcpy；但其他人指出 Linux 核心曾經有 strlcpy，後來因介面設計考量改採 strscpy。
整體討論把這次移除視為典型的系統工程長期清理工作：不炫目，但能逐步降低核心中模糊、易誤用介面的風險。也有人提到是否可用大型語言模型（LLM, Large Language Model）自動完成這類替換；反方則提醒，C 的記憶體安全錯誤往往很細微，而模型訓練資料中也包含大量不安全寫法，因此仍需要熟悉語意與邊界條件的人類審查。
👥 76 則討論、評論 💬
https://news.ycombinator.com/item?id=48612943
Linux 7.2 已把 strncpy API（應用程式介面）從 Linux 核心中移除。strncpy() 是 C 語言中用來複製指定位元組數的字串函式，長期被視為不建議使用；這次在約六年、362 個提交後，核心內已不再有任何 strncpy 使用處，因此正式刪除這個介面與最後的 CPU 架構專用實作。
文章指出，strncpy 多年來一直是錯誤來源，主要問題在於它對 NUL 字元（值為 0、常用來標示 C 字串結尾）的處理很反直覺：它不一定會產生 NUL 結尾，卻又可能對目的地緩衝區進行多餘補零，造成效能浪費。Linux 核心接下來會依情境改用更明確的函式，例如 strscpy() 用於需要 NUL 結尾的目的地，strscpy_pad() 用於需要 NUL 結尾且補零的情境，strtomem_pad() 用於不以 NUL 結尾的固定寬度欄位，memcpy_and_pad() 用於有界限且明確補齊的複製，memcpy() 則用於已知長度的記憶體複製。
討論中不少開發者補充 strncpy 的歷史脈絡：它原本來自早期 UNIX 核心，用於處理目錄項目中「2 位元組 inode（檔案系統用來識別檔案的索引節點）加上 14 位元組、補零但不以 NUL 結尾的檔名欄位」，並不是為了一般安全字串複製而設計。也有人提醒，所謂 360 多個修補並不代表發現 360 多個漏洞，而是移除 360 多處使用；但多位有經驗的 C 開發者表示，在程式碼審查中看到 strncpy 往往就是高風險訊號。
討論也延伸到 C 字串設計本身。許多人認為 NUL 結尾字串是安全與效能問題的根源之一，因為只要結尾字元遺失，標準字串函式就可能一路讀到配置範圍外，引發記憶體越界與資安風險；此外，在迴圈中反覆呼叫 strlen() 也可能讓原本 O(N) 的操作變成 O(N^2)。也有留言比較 Pascal 式長度前綴字串、帶長度的緩衝區結構，以及 strlcpy；但其他人指出 Linux 核心曾經有 strlcpy，後來因介面設計考量改採 strscpy。
整體討論把這次移除視為典型的系統工程長期清理工作：不炫目，但能逐步降低核心中模糊、易誤用介面的風險。也有人提到是否可用大型語言模型（LLM, Large Language Model）自動完成這類替換；反方則提醒，C 的記憶體安全錯誤往往很細微，而模型訓練資料中也包含大量不安全寫法，因此仍需要熟悉語意與邊界條件的人類審查。
👥 76 則討論、評論 💬
https://news.ycombinator.com/item?id=48612943
AMD 將在 7 月透過 BIOS 更新，恢復 Ryzen 9000 處理器的記憶體加密功能 （★ 104 分）
AMD 向 Tom’s Hardware 證實，將在 7 月透過 BIOS（Basic Input/Output System，主機板韌體介面）更新，讓部分非 PRO Ryzen 9000 桌上型處理器重新提供 Memory Guard，也就是 Transparent Secure Memory Encryption（TSME，透明安全記憶體加密）的啟用選項。這項功能原本是 Ryzen PRO 產品線的安全賣點，但部分非 PRO 消費級晶片也曾可用；AMD 先前在 AGESA 1.2.7.0（AMD Generic Encapsulated Software Architecture，AMD 平台初始化韌體套件）中悄悄移除，後來在社群追問後表示，將依使用者回饋恢復。
TSME 是韌體層級的記憶體加密機制，處理器會產生金鑰，替存放在 RAM（隨機存取記憶體）中的資料加密，主要用來降低冷開機攻擊（cold boot attack；攻擊者在設備突然斷電後讀取殘留記憶體內容）的風險。Ars Technica 作者 Ben Kilpatrick 在 Ryzen 7 9700X 新機安全稽核時發現 TSME 不再可用，並與主機板廠 MSI 確認舊版韌體曾提供此功能，後來是在 AGESA 1.2.7.0 被停用。AMD 工程師在 GitHub 回報中一度未提供進一步說明，使外界推測這可能是為了區隔 Ryzen PRO 與一般 Ryzen 的市場定位。
AMD 在聲明中強調，Memory Guard 是 Ryzen PRO 桌上型與行動處理器在晶片支援時提供的硬體式記憶體加密技術，屬於基礎安全功能，未來也不會從 Ryzen PRO 產品線移除。至於部分非 PRO Ryzen 9000 桌上型處理器，AMD 承認先前 BIOS 曾有啟用 Memory Guard 的選項，近期更新中被移除，並將在 7 月的 BIOS 版本中恢復。文章也指出，TSME 對多數家用桌機未必是最迫切的防線，因為攻擊者通常需要實體接觸機器；但若硬體原本具備該能力，透過韌體更新移除仍難以令人接受。
後續討論的重點多半不在「有多少人真的使用 TSME」，而在硬體售出後不應被韌體更新倒退功能。多位留言者認為，CPU 韌體更新理應用於安全修補與效能改善，若廠商開始用它移除既有功能，會讓使用者傾向不更新韌體，反而造成更大的安全風險。也有人批評這像是為了保護 PRO 產品線而做的市場分級，與 AMD 過去相對願意讓一般使用者取得進階功能的形象不符；另有人拿 Intel 曾在 Alder Lake 上停用 AVX-512（進階向量擴充指令集）相提並論，指出兩大處理器廠都有透過產品分級限制功能的紀錄。
也有留言提醒，TSME 可能造成約 0.5% 到 1% 的記憶體速度影響，因此合理作法應是 BIOS 預設關閉，但保留讓需要者自行啟用的選項。關於威脅模型，部分人認為一般桌機遭遇冷開機攻擊的機率不高；反方則指出，桌機與筆電多半不在資料中心，失竊或短暫被他人接觸並非不可能。技術討論也延伸到 DMA（Direct Memory Access，直接記憶體存取）與 PCIe（Peripheral Component Interconnect Express，高速周邊互連匯流排）設備如何與記憶體加密共存；回覆指出若加解密在記憶體控制器完成，存取來源通常不是問題，而更複雜的可信 I/O 情境則可能涉及 IOMMU（Input-Output Memory Management Unit，輸入輸出記憶體管理單元）或 TDISP/IDE（可信設備安全協定與完整性資料加密）等伺服器級機制。
👥 28 則討論、評論 💬
https://news.ycombinator.com/item?id=48612098
AMD 向 Tom’s Hardware 證實，將在 7 月透過 BIOS（Basic Input/Output System，主機板韌體介面）更新，讓部分非 PRO Ryzen 9000 桌上型處理器重新提供 Memory Guard，也就是 Transparent Secure Memory Encryption（TSME，透明安全記憶體加密）的啟用選項。這項功能原本是 Ryzen PRO 產品線的安全賣點，但部分非 PRO 消費級晶片也曾可用；AMD 先前在 AGESA 1.2.7.0（AMD Generic Encapsulated Software Architecture，AMD 平台初始化韌體套件）中悄悄移除，後來在社群追問後表示，將依使用者回饋恢復。
TSME 是韌體層級的記憶體加密機制，處理器會產生金鑰，替存放在 RAM（隨機存取記憶體）中的資料加密，主要用來降低冷開機攻擊（cold boot attack；攻擊者在設備突然斷電後讀取殘留記憶體內容）的風險。Ars Technica 作者 Ben Kilpatrick 在 Ryzen 7 9700X 新機安全稽核時發現 TSME 不再可用，並與主機板廠 MSI 確認舊版韌體曾提供此功能，後來是在 AGESA 1.2.7.0 被停用。AMD 工程師在 GitHub 回報中一度未提供進一步說明，使外界推測這可能是為了區隔 Ryzen PRO 與一般 Ryzen 的市場定位。
AMD 在聲明中強調，Memory Guard 是 Ryzen PRO 桌上型與行動處理器在晶片支援時提供的硬體式記憶體加密技術，屬於基礎安全功能，未來也不會從 Ryzen PRO 產品線移除。至於部分非 PRO Ryzen 9000 桌上型處理器，AMD 承認先前 BIOS 曾有啟用 Memory Guard 的選項，近期更新中被移除，並將在 7 月的 BIOS 版本中恢復。文章也指出，TSME 對多數家用桌機未必是最迫切的防線，因為攻擊者通常需要實體接觸機器；但若硬體原本具備該能力，透過韌體更新移除仍難以令人接受。
後續討論的重點多半不在「有多少人真的使用 TSME」，而在硬體售出後不應被韌體更新倒退功能。多位留言者認為，CPU 韌體更新理應用於安全修補與效能改善，若廠商開始用它移除既有功能，會讓使用者傾向不更新韌體，反而造成更大的安全風險。也有人批評這像是為了保護 PRO 產品線而做的市場分級，與 AMD 過去相對願意讓一般使用者取得進階功能的形象不符；另有人拿 Intel 曾在 Alder Lake 上停用 AVX-512（進階向量擴充指令集）相提並論，指出兩大處理器廠都有透過產品分級限制功能的紀錄。
也有留言提醒，TSME 可能造成約 0.5% 到 1% 的記憶體速度影響，因此合理作法應是 BIOS 預設關閉，但保留讓需要者自行啟用的選項。關於威脅模型，部分人認為一般桌機遭遇冷開機攻擊的機率不高；反方則指出，桌機與筆電多半不在資料中心，失竊或短暫被他人接觸並非不可能。技術討論也延伸到 DMA（Direct Memory Access，直接記憶體存取）與 PCIe（Peripheral Component Interconnect Express，高速周邊互連匯流排）設備如何與記憶體加密共存；回覆指出若加解密在記憶體控制器完成，存取來源通常不是問題，而更複雜的可信 I/O 情境則可能涉及 IOMMU（Input-Output Memory Management Unit，輸入輸出記憶體管理單元）或 TDISP/IDE（可信設備安全協定與完整性資料加密）等伺服器級機制。
👥 28 則討論、評論 💬
https://news.ycombinator.com/item?id=48612098
AMD的Gorgon point (AI 400)也是很迷惑的操作，整個就是Strix point的馬甲 (AI 300)
AMD也開始懂擠牙膏了
AMD也開始懂擠牙膏了
Windows 11 新版 Media Player 的 RAM 用量約為舊版 3.5 倍，常用影片編解碼器還要付費 （★ 100 分）
Windows 11 的新版 Media Player 因資源占用與編解碼器付費問題受到批評。文章引用 Windows Latest 測試指出，新版播放器閒置時約使用 377MB RAM（隨機存取記憶體），而經典 Windows Media Player 約為 103MB，約高出 3.5 倍；開啟本機影片的啟動時間也從約 2 秒增加到約 3 秒，慢了約 50%。這款新版 Media Player 已取代 Groove Music 與經典 Windows Media Player，成為 Windows 11 多數使用情境下的預設選擇，但經典版仍可作為選用元件安裝。
爭議也延伸到格式相容性。Microsoft 將 HEVC（High Efficiency Video Coding，又稱 H.265，高效率影片壓縮標準）播放能力放在 Microsoft Store 的付費「HEVC Video Extensions」中；同時，Windows 11 24H2 移除內建 AC-3（Dolby Digital，常見環繞音訊格式）編解碼器，導致新版 Media Player 無法原生播放含 AC-3 音軌的媒體。文章因此建議不介意使用第三方工具的人，可改用 VLC（開源跨平台媒體播放器）等自帶編解碼器、不仰賴 Microsoft 付費附加元件的播放器。
Hacker News 討論中，許多留言者把焦點放在替代播放器。VLC 仍被視為一般使用者的穩健選擇，但也有人偏好 MPC-HC（Media Player Classic - Home Cinema）、MPC-BE、mpv、SMPlayer 或 PotPlayer，理由多半是介面更順手、格式支援完整，且不需要像早年 Windows XP 時代那樣另外安裝 K-Lite Codec Pack 或 CCCP（Combined Community Codec Pack）等編解碼器套件。也有留言指出，VLC 與 MPC 類播放器通常已內含 libavcodec 等解碼能力，因此現代使用情境下「拖進去就能播」已是常態。
討論區也有人修正文章脈絡，指出 HEVC 在 Windows 上付費並非新鮮事，至少從 Windows 10 時期就已存在；而所謂「新版」Media Player 其實自 2022 年起就已推出，因此文章標題容易讓人誤以為這是全新變動。不過，多數人仍認為移除 AC-3 不必要，且 Microsoft 作為收費作業系統供應商，應像 Apple 在 macOS、iOS 與 iPadOS 上一樣吸收常見影音格式授權成本，而不是把基本播放體驗拆成額外付費項目。
對於記憶體膨脹，討論呈現明顯不滿。有留言推測新版播放器可能反映 Windows 應用程式改採 JS/TS（JavaScript/TypeScript）等網頁前端技術的趨勢，讓開發更容易，卻犧牲原生 Windows 應用程式該有的輕量與流暢。少數人認為 400MB 與 100MB 在現代電腦上差異不一定明顯，但反方指出，市面上仍有 8GB RAM 的 Windows 筆電，加上系統背景程序、瀏覽器、IDE（整合開發環境）與模擬器本就吃重，這類膨脹會實際影響體驗。整體看來，社群情緒偏向批評 Microsoft：新版 Media Player 不只功能未必更好，還讓 Windows 11 的「原生體驗」顯得更笨重、更碎片化。
👥 47 則討論、評論 💬
https://news.ycombinator.com/item?id=48609343
Windows 11 的新版 Media Player 因資源占用與編解碼器付費問題受到批評。文章引用 Windows Latest 測試指出，新版播放器閒置時約使用 377MB RAM（隨機存取記憶體），而經典 Windows Media Player 約為 103MB，約高出 3.5 倍；開啟本機影片的啟動時間也從約 2 秒增加到約 3 秒，慢了約 50%。這款新版 Media Player 已取代 Groove Music 與經典 Windows Media Player，成為 Windows 11 多數使用情境下的預設選擇，但經典版仍可作為選用元件安裝。
爭議也延伸到格式相容性。Microsoft 將 HEVC（High Efficiency Video Coding，又稱 H.265，高效率影片壓縮標準）播放能力放在 Microsoft Store 的付費「HEVC Video Extensions」中；同時，Windows 11 24H2 移除內建 AC-3（Dolby Digital，常見環繞音訊格式）編解碼器，導致新版 Media Player 無法原生播放含 AC-3 音軌的媒體。文章因此建議不介意使用第三方工具的人，可改用 VLC（開源跨平台媒體播放器）等自帶編解碼器、不仰賴 Microsoft 付費附加元件的播放器。
Hacker News 討論中，許多留言者把焦點放在替代播放器。VLC 仍被視為一般使用者的穩健選擇，但也有人偏好 MPC-HC（Media Player Classic - Home Cinema）、MPC-BE、mpv、SMPlayer 或 PotPlayer，理由多半是介面更順手、格式支援完整，且不需要像早年 Windows XP 時代那樣另外安裝 K-Lite Codec Pack 或 CCCP（Combined Community Codec Pack）等編解碼器套件。也有留言指出，VLC 與 MPC 類播放器通常已內含 libavcodec 等解碼能力，因此現代使用情境下「拖進去就能播」已是常態。
討論區也有人修正文章脈絡，指出 HEVC 在 Windows 上付費並非新鮮事，至少從 Windows 10 時期就已存在；而所謂「新版」Media Player 其實自 2022 年起就已推出，因此文章標題容易讓人誤以為這是全新變動。不過，多數人仍認為移除 AC-3 不必要，且 Microsoft 作為收費作業系統供應商，應像 Apple 在 macOS、iOS 與 iPadOS 上一樣吸收常見影音格式授權成本，而不是把基本播放體驗拆成額外付費項目。
對於記憶體膨脹，討論呈現明顯不滿。有留言推測新版播放器可能反映 Windows 應用程式改採 JS/TS（JavaScript/TypeScript）等網頁前端技術的趨勢，讓開發更容易，卻犧牲原生 Windows 應用程式該有的輕量與流暢。少數人認為 400MB 與 100MB 在現代電腦上差異不一定明顯，但反方指出，市面上仍有 8GB RAM 的 Windows 筆電，加上系統背景程序、瀏覽器、IDE（整合開發環境）與模擬器本就吃重，這類膨脹會實際影響體驗。整體看來，社群情緒偏向批評 Microsoft：新版 Media Player 不只功能未必更好，還讓 Windows 11 的「原生體驗」顯得更笨重、更碎片化。
👥 47 則討論、評論 💬
https://news.ycombinator.com/item?id=48609343