Log for Ubuntu 台灣社群
URL 中的 IPv6 區域識別碼（zone）是個錯誤設計 （★ 103 分）
這篇文章說明網際網路協定第 6 版 (IPv6) 的 link-local 位址（只在同一網路鏈路內有效的位址）在統一資源定位符 (URL, Uniform Resource Locator) 中使用時，會出現相當彆扭的語法問題。IPv6 的每個網路介面都可能有 fe80:: 開頭的 link-local 位址；若同一台機器有多張網路卡，就必須用 zone 或 scope（區域識別碼）指定要走哪個介面，例如 Linux 上可能寫成 `fe80::4%eth0` ，Windows 則常用介面 ID。IPv6 位址本身使用冒號，因此放進 host:port 格式時必須加方括號，例如 ` [fe80::4]:80 ` ；若再加上 zone，就會變成 ` [fe80::4%eth0]:80 ` 。
問題出在 URL 中的百分比符號另有用途：它是百分比編碼（percent-encoding）的起始符號，用來表示 URL 語法中不能直接出現的字元。作者用 Go 語言標準函式庫 `net/url` 解析 `http://[fe80::4%eth0]:80` 時，會得到 invalid URL escape 錯誤，因為 `%et` 被視為不合法的編碼。正確寫法是把 zone 前面的 `%` 本身也編碼成 `%25`，也就是 `http://[fe80::4%25eth0]:80` ；Go 解析後會把主機名稱還原成 `fe80::4%eth0`。作者起初認為這缺乏 URL 指引，後來補充更正：RFC 6874（網際網路標準文件，定義 IPv6 zone 在 URI 中的表示方式）確實規定要使用 `%25`，只是這種使用體驗很糟。
文章也指出，這不是 Go 獨有的問題；nginx、Python requests 等工具與函式庫也曾遇到類似邊界案例。瀏覽器更複雜，因為 link-local IPv6 zone 會衝擊瀏覽器的 origin（來源，同源安全模型的基礎）判定，因此相關草案試圖定義瀏覽器可接受的 zone origin。作者最後表示，為了讓 Anubis 能指向帶 zone 的 IPv6 位址，現階段只能要求使用 `%25` 這種不直覺的寫法；由於不打算分叉 Go 標準函式庫，只能接受這個少見但惱人的限制。
Hacker News 討論中，Go `net/url` 維護者指出 Go 的行為其實符合 RFC 6874：URL 中若要放 `fe80::4%eth0`，就必須寫成 `http://[fe80::4%25eth0]/`。但其他留言也補充，RFC 9844 後來取代 RFC 6874，並移除 URI（統一資源識別符，Uniform Resource Identifier）相關指引，原因是瀏覽器實作方認為原方案不切實際；這讓標準狀態變得尷尬。維持既有 `%25` 語法會醜但相容，改成未編碼 `%` 則不符合既有標準且會破壞既有使用者，雙軌支援又可能帶來更多混亂。
討論也延伸到 IPv6 link-local 位址的實務價值與風險。有些人認為一般網頁服務不該跑在 fe80:: 位址上，私有可路由環境應使用 ULA（Unique Local Address，IPv6 的私有位址範圍）；但也有人指出 link-local 位址在無路由器設備佈署、雲端或資料中心交換器之間的 BGP（Border Gateway Protocol，邊界閘道協定）連線、以及明確指定某個網路介面時很有用。另有留言抱怨 IPv6 使用冒號與方括號造成許多工具相容性問題，例如舊版 rsync 在 macOS 上解析 IPv6 目標路徑時會出錯；也有人提醒 Python `ipaddress` 可接受含 shell 特殊字元的 zone ID，若程式把「已驗證」的輸入直接丟進 shell，仍可能造成命令注入。整體看來，社群共識不是 Go 做錯，而是 IPv6 zone、URL 編碼、瀏覽器安全模型與舊工具語法交疊後，形成了一個標準上有依據、實務上很難用的角落案例。
👥 77 則討論、評論 💬
https://news.ycombinator.com/item?id=48405019
這篇文章說明網際網路協定第 6 版 (IPv6) 的 link-local 位址（只在同一網路鏈路內有效的位址）在統一資源定位符 (URL, Uniform Resource Locator) 中使用時，會出現相當彆扭的語法問題。IPv6 的每個網路介面都可能有 fe80:: 開頭的 link-local 位址；若同一台機器有多張網路卡，就必須用 zone 或 scope（區域識別碼）指定要走哪個介面，例如 Linux 上可能寫成 `fe80::4%eth0` ，Windows 則常用介面 ID。IPv6 位址本身使用冒號，因此放進 host:port 格式時必須加方括號，例如 ` [fe80::4]:80 ` ；若再加上 zone，就會變成 ` [fe80::4%eth0]:80 ` 。
問題出在 URL 中的百分比符號另有用途：它是百分比編碼（percent-encoding）的起始符號，用來表示 URL 語法中不能直接出現的字元。作者用 Go 語言標準函式庫 `net/url` 解析 `http://[fe80::4%eth0]:80` 時，會得到 invalid URL escape 錯誤，因為 `%et` 被視為不合法的編碼。正確寫法是把 zone 前面的 `%` 本身也編碼成 `%25`，也就是 `http://[fe80::4%25eth0]:80` ；Go 解析後會把主機名稱還原成 `fe80::4%eth0`。作者起初認為這缺乏 URL 指引，後來補充更正：RFC 6874（網際網路標準文件，定義 IPv6 zone 在 URI 中的表示方式）確實規定要使用 `%25`，只是這種使用體驗很糟。
文章也指出，這不是 Go 獨有的問題；nginx、Python requests 等工具與函式庫也曾遇到類似邊界案例。瀏覽器更複雜，因為 link-local IPv6 zone 會衝擊瀏覽器的 origin（來源，同源安全模型的基礎）判定，因此相關草案試圖定義瀏覽器可接受的 zone origin。作者最後表示，為了讓 Anubis 能指向帶 zone 的 IPv6 位址，現階段只能要求使用 `%25` 這種不直覺的寫法；由於不打算分叉 Go 標準函式庫，只能接受這個少見但惱人的限制。
Hacker News 討論中，Go `net/url` 維護者指出 Go 的行為其實符合 RFC 6874：URL 中若要放 `fe80::4%eth0`，就必須寫成 `http://[fe80::4%25eth0]/`。但其他留言也補充，RFC 9844 後來取代 RFC 6874，並移除 URI（統一資源識別符，Uniform Resource Identifier）相關指引，原因是瀏覽器實作方認為原方案不切實際；這讓標準狀態變得尷尬。維持既有 `%25` 語法會醜但相容，改成未編碼 `%` 則不符合既有標準且會破壞既有使用者，雙軌支援又可能帶來更多混亂。
討論也延伸到 IPv6 link-local 位址的實務價值與風險。有些人認為一般網頁服務不該跑在 fe80:: 位址上，私有可路由環境應使用 ULA（Unique Local Address，IPv6 的私有位址範圍）；但也有人指出 link-local 位址在無路由器設備佈署、雲端或資料中心交換器之間的 BGP（Border Gateway Protocol，邊界閘道協定）連線、以及明確指定某個網路介面時很有用。另有留言抱怨 IPv6 使用冒號與方括號造成許多工具相容性問題，例如舊版 rsync 在 macOS 上解析 IPv6 目標路徑時會出錯；也有人提醒 Python `ipaddress` 可接受含 shell 特殊字元的 zone ID，若程式把「已驗證」的輸入直接丟進 shell，仍可能造成命令注入。整體看來，社群共識不是 Go 做錯，而是 IPv6 zone、URL 編碼、瀏覽器安全模型與舊工具語法交疊後，形成了一個標準上有依據、實務上很難用的角落案例。
👥 77 則討論、評論 💬
https://news.ycombinator.com/item?id=48405019
Azure Linux 4.0 是 Microsoft 首款一般用途 Linux 發行版 （★ 81 分）
Azure Linux 4.0 在 Microsoft Build 2026 進入公開預覽，這是 Microsoft 內部 Linux 發行版從 CBL-Mariner 演進後，首次被定位為可由客戶自行選用的一般用途雲端作業系統。它不再只是 AKS（Azure Kubernetes Service，Azure 的 Kubernetes 代管服務）節點底層或 Microsoft 第一方服務背後的主機作業系統，而是可從 Azure Marketplace 部署到任何 Azure VM（Virtual Machine，虛擬機器），且不收額外作業系統授權費；未來也會以 WSL（Windows Subsystem for Linux，Windows 上的 Linux 子系統）發行版形式提供，讓開發者在本機使用和 Azure 生產環境相同的 Linux。
文章回顧 Microsoft 其實打造過多個 Linux 發行版：CBL-Delridge 是 Debian 系，曾用於 Azure Cloud Shell，後來消失；CBL-Mariner 則是 RPM 系，借鑑 Photon OS、Fedora 與 Linux From Scratch，2019 年開始內部開發、2020 年在 GitHub 公開、2022 年達到 2.0，2024 年改名 Azure Linux。4.0 最大變化是改以 Fedora 43 快照為基礎，不再逐一手工維護所有 spec 檔，而是追蹤 Fedora 上游並套用宣告式覆寫；每個與上游不同之處都附有理由，產出的 spec 檔也放在 GitHub，強調供應鏈可稽核。
技術上，Azure Linux 4.0 搭載針對 Azure 調校的 Linux 6.18 LTS（Long-Term Support，長期支援）核心，整合 Hyper-V、GPU（圖形處理器）與 AI（人工智慧）加速器支援；套件管理器也從 Microsoft 自家的 tdnf 改為標準 dnf5，讓使用者能使用更完整的 dnf 生態系。其他更新包含 glibc 2.42、systemd 258、支援後量子密碼學的 OpenSSL 3.5、Python 3.14，以及簽章驗證更強的 RPM 6.0。安全面則包含 SELinux、ASLR（Address Space Layout Randomization，位址空間配置隨機化）、堆疊保護、seccomp（Linux 系統呼叫過濾機制）、systemd 服務沙箱、套件與儲存庫簽章，以及 SBOM（Software Bill of Materials，軟體物料清單）；FIPS 140-3（美國聯邦資訊處理標準的資安認證）也在認證流程中。Microsoft 表示，Databricks 已把超過 10 萬台 VM、逾 100 萬個 CPU 核心遷移到 Azure Linux，LinkedIn 也已採用，Azure SQL、Cosmos DB 與 AKS 背後同樣已有其部署經驗。
Hacker News 討論的主要分歧在於「一般用途」這個定位是否過度包裝。許多留言認為它更像是由 Microsoft 維護、針對 Azure 硬體與雲端工作負載調校的 Fedora 分支版本，而不是可在各種個人電腦、桌面環境或自有機房硬體上廣泛使用的傳統 Linux 發行版；也有人指出官方說法本來就強調雲端與伺服器工作負載，並非桌面或 GUI 應用。支持這項做法的觀點則認為，Microsoft 自行維護發行版可掌握更新節奏、預先驗證自家服務、快速推出修補，並調整 FIPS 等企業合規預設值；從 tdnf 轉向 dnf5 也被視為少見的「內部平台變得更標準化」的訊號。
討論中也出現對 Microsoft「擁抱、延伸、消滅」策略的戒心，但不少人認為 Linux 核心與關鍵元件採 GPL（GNU General Public License，自由軟體授權），而 Azure Linux 的 Microsoft 自有部分多採 MIT License（MIT 授權條款），要用傳統封閉手法壟斷並不容易。另一些留言把它視為 Microsoft 對 Windows 重要性下降的務實布局：Windows 仍有商業價值，但 Azure、Office、LinkedIn、Bing 等業務已更關鍵，Microsoft 維護自己的 Linux 發行版有助於把雲端、容器、AKS 與 WSL 的開發部署流程統一。整體來看，Azure Linux 4.0 的意義不在於挑戰桌面 Linux，而是 Microsoft 正式把多年內部使用的 Linux 平台推向 Azure 客戶可直接選用的產品。
👥 54 則討論、評論 💬
https://news.ycombinator.com/item?id=48407499
Azure Linux 4.0 在 Microsoft Build 2026 進入公開預覽，這是 Microsoft 內部 Linux 發行版從 CBL-Mariner 演進後，首次被定位為可由客戶自行選用的一般用途雲端作業系統。它不再只是 AKS（Azure Kubernetes Service，Azure 的 Kubernetes 代管服務）節點底層或 Microsoft 第一方服務背後的主機作業系統，而是可從 Azure Marketplace 部署到任何 Azure VM（Virtual Machine，虛擬機器），且不收額外作業系統授權費；未來也會以 WSL（Windows Subsystem for Linux，Windows 上的 Linux 子系統）發行版形式提供，讓開發者在本機使用和 Azure 生產環境相同的 Linux。
文章回顧 Microsoft 其實打造過多個 Linux 發行版：CBL-Delridge 是 Debian 系，曾用於 Azure Cloud Shell，後來消失；CBL-Mariner 則是 RPM 系，借鑑 Photon OS、Fedora 與 Linux From Scratch，2019 年開始內部開發、2020 年在 GitHub 公開、2022 年達到 2.0，2024 年改名 Azure Linux。4.0 最大變化是改以 Fedora 43 快照為基礎，不再逐一手工維護所有 spec 檔，而是追蹤 Fedora 上游並套用宣告式覆寫；每個與上游不同之處都附有理由，產出的 spec 檔也放在 GitHub，強調供應鏈可稽核。
技術上，Azure Linux 4.0 搭載針對 Azure 調校的 Linux 6.18 LTS（Long-Term Support，長期支援）核心，整合 Hyper-V、GPU（圖形處理器）與 AI（人工智慧）加速器支援；套件管理器也從 Microsoft 自家的 tdnf 改為標準 dnf5，讓使用者能使用更完整的 dnf 生態系。其他更新包含 glibc 2.42、systemd 258、支援後量子密碼學的 OpenSSL 3.5、Python 3.14，以及簽章驗證更強的 RPM 6.0。安全面則包含 SELinux、ASLR（Address Space Layout Randomization，位址空間配置隨機化）、堆疊保護、seccomp（Linux 系統呼叫過濾機制）、systemd 服務沙箱、套件與儲存庫簽章，以及 SBOM（Software Bill of Materials，軟體物料清單）；FIPS 140-3（美國聯邦資訊處理標準的資安認證）也在認證流程中。Microsoft 表示，Databricks 已把超過 10 萬台 VM、逾 100 萬個 CPU 核心遷移到 Azure Linux，LinkedIn 也已採用，Azure SQL、Cosmos DB 與 AKS 背後同樣已有其部署經驗。
Hacker News 討論的主要分歧在於「一般用途」這個定位是否過度包裝。許多留言認為它更像是由 Microsoft 維護、針對 Azure 硬體與雲端工作負載調校的 Fedora 分支版本，而不是可在各種個人電腦、桌面環境或自有機房硬體上廣泛使用的傳統 Linux 發行版；也有人指出官方說法本來就強調雲端與伺服器工作負載，並非桌面或 GUI 應用。支持這項做法的觀點則認為，Microsoft 自行維護發行版可掌握更新節奏、預先驗證自家服務、快速推出修補，並調整 FIPS 等企業合規預設值；從 tdnf 轉向 dnf5 也被視為少見的「內部平台變得更標準化」的訊號。
討論中也出現對 Microsoft「擁抱、延伸、消滅」策略的戒心，但不少人認為 Linux 核心與關鍵元件採 GPL（GNU General Public License，自由軟體授權），而 Azure Linux 的 Microsoft 自有部分多採 MIT License（MIT 授權條款），要用傳統封閉手法壟斷並不容易。另一些留言把它視為 Microsoft 對 Windows 重要性下降的務實布局：Windows 仍有商業價值，但 Azure、Office、LinkedIn、Bing 等業務已更關鍵，Microsoft 維護自己的 Linux 發行版有助於把雲端、容器、AKS 與 WSL 的開發部署流程統一。整體來看，Azure Linux 4.0 的意義不在於挑戰桌面 Linux，而是 Microsoft 正式把多年內部使用的 Linux 平台推向 Azure 客戶可直接選用的產品。
👥 54 則討論、評論 💬
https://news.ycombinator.com/item?id=48407499