工程趣聞 2026 年 8 月 3 日

2026-08-03 — 開源政策工具 Bor v0.8.0、NetBSD 11.0 首個穩定版 RISC-V,以及 Karpathy 重新定義鵜鶘騎腳踏車測試

primary=https://getbor.dev/blog/2026-08-02-bor-v080-release/ primary=https://blog.netbsd.org/tnf/entry/netbsd_11_0_released primary=https://www.netbsd.org/releases/formal-11/NetBSD-11.0.html primary=https://x.com/karpathy/status/2083749667410727319 primary=https://simonwillison.net/2024/Oct/25/pelicans-on-a-bicycle/ primary=https://news.ycombinator.com/item?id=49140998

開源 Linux 桌面政策管理工具 Bor 推出 v0.8.0:把 Thunderbird、Edge、防火牆都收進統一政策引擎

Bor Blog · 2026-08-02

背景

Bor 是一套鎖定 Linux 桌面環境的開源政策管理工具,概念類似 Windows 上的 Group Policy 或 macOS 的 Configuration Profiles,讓 IT 管理者能用一份中央定義的政策,統一推送到底下所有代理端(agent)裝置。專案採 server / agent / web UI 三件式架構,政策以 protobuf 定義後分發,agent 落地在各台機器上把政策轉譯成應用程式實際吃得下的設定檔格式。v0.8.0 於 2026-08-02 發布,是這條產品線首次把政策覆蓋範圍延伸到郵件用戶端與瀏覽器層。

新增的三種政策類型

這次最大的看點是新增三種受管政策類型。針對 Thunderbird,agent 會產生 Thunderbird 期望讀取的 policies.json,內容是所有已綁定政策的合併結果,並附帶防竄改保護與網頁後台裡的完整政策編輯器。針對 Microsoft Edge for Business,agent 改在 Edge 的受管政策目錄下寫入 bor_managed.json,前端提供樹狀結構編輯與 JSON 驗證。第三種是 firewalld 區域(zones)管理,涵蓋 services、ports、forward ports、rich rules、masquerade、interfaces、sources 以及 zone target 等完整防火牆設定面向。

權限模型與 Web UI 大改

Polkit 規則這次支援用 action.lookup() 帶入變數條件,讓授權判斷可以做到比過去更細的顆粒度。使用者與角色管理也從「單一總開關權限」改成 per-action RBAC,也就是每個管理動作都各自掛一條授權規則,而不是給了管理權限就等於什麼都能改。Web UI 同步做了現代化改版:URL 路由讓瀏覽器上下頁可以正常運作、政策編輯器改成全頁面呈現、節點列表加上伺服器端分頁,介面也達到 WCAG 2.2 AA 無障礙規範。前端同時升級到 React 19.2 與 react-router 8.3。

架構與安全性變動

政策目錄(catalogue)現在改由 protobuf annotation 自動產生,伺服器、agent、前端三端共用同一份定義來源,減少過去手動同步政策 schema 造成的落差。安全性方面本次修補不少:mTLS 憑證綁定收緊、TOTP 密鑰改用 HKDF 派生加密儲存、repository helper 加入 SSRF 阻擋,稽核紀錄匯出功能也補上對「試算表公式注入」(spreadsheet formula injection)的防護。這類問題常見於允許使用者匯出 CSV/Excel 報表卻沒過濾 =+ 開頭字串的系統。

升級須知

由於新政策型別需要 agent 端配合,官方要求所有 agent 必須升級到 v0.8.0 才能正確套用 Thunderbird、Edge、firewalld 三種新政策。外部若有自行串接 protobuf schema 的工具,也需要重新產生程式碼。前端開發環境需要的 Node.js 版本同步拉高到 22.22 以上。這次發布正好搭上 Show HN 首頁,164 點、21 則留言,討論多集中在 firewalld 與瀏覽器政策這兩塊企業 IT 常見的痛點。

原始來源:Bor v0.8.0 release notes


NetBSD 11.0 正式發布:首個穩定版 RISC-V 移植上線,MICROVM 核心 10 毫秒開機

NetBSD Foundation · 2026-08-01

背景

NetBSD 專案在 2026-08-01 由開發者 Martin Husemann 發布公告,正式釋出 NetBSD 11.0。官方公告自嘲這個版本「已經拖了不少時間」,主因是等待第三方元件就緒以及跑完整輪的候選版測試——這次開發週期共經過七個 release candidate(RC1 至 RC7),時間橫跨 2026 年 2 月到 7 月,距離上一個穩定版已超過十八個月。團隊也坦言目前仍有已知的資安問題尚未修完,但認為與其無限期延後,不如先發布再靠後續小版本補完。

首個穩定版 RISC-V 移植

本次最大亮點是 NetBSD 首度把 64 位元 RISC-V 移植列為穩定支援,而不再只是實驗性分支。支援範圍涵蓋 StarFive JH71XX 系列硬體,包括 VisionFive 2、PINE64 STAR64,以及 QEMU 模擬環境。這使 NetBSD 成為 BSD 家族中少數把 RISC-V 帶到正式穩定版等級的作業系統之一,對嵌入式與教學用途的 RISC-V 硬體使用者是直接可用的選項。

MICROVM:10 毫秒開機的虛擬機核心

另一項技術亮點是新的 MICROVM 核心,鎖定 x86 虛擬機開機速度。它結合 PVH boot、VirtIO MMIO 以及一系列核心層最佳化,官方公告的數字是在 2020 年前後等級的 x86 CPU 上,約 10ms 就能完成開機。這種等級的開機速度主要瞄準需要大量、頻繁啟停虛擬機的場景,例如函式即服務(FaaS)或短生命週期的沙箱。

Linux 相容層擴大

NetBSD 的 Linux 系統呼叫相容層這次新增支援 epoll(透過 kqueue 實作)、POSIX 訊息佇列、statx、readahead、close_range、waitid、renameat2、clone3、sync_file_range、syncfs 以及 inotify。這批系統呼叫多半是近幾年 Linux 應用程式假設一定存在的介面,補齊後代表更多預先編譯好的 Linux 執行檔可以不經修改直接在 NetBSD 上跑。

核心與網路層變動

  • 新增 layer 2 防火牆過濾能力,npf(7) 支援以使用者/群組為條件的過濾規則
  • 新增 O_CLOFORK flag
  • 依 RFC 6298 把初始 RTO(重傳逾時)從 3 秒降到 1 秒,改善連線建立初期的網路效能
  • OpenSSH 移除 DSA 金鑰支援,仍在用舊 DSA 設定的使用者需要調整
  • ctype(3) 加入 guard pages,在執行期偵測常見的錯誤呼叫方式
  • 加強對 POSIX.1-2024 與 C23 標準的相容性,並新增符合標準要求的 c17(1) wrapper script

已知問題與後續計畫

公告中列出三個尚未修完、非預設啟用的資安問題:hdaudio 存取控制漏洞、IPfilter 的 null pointer dereference,以及 PF 在封包重組(fragment reassembly)時的 use-after-free,後兩者都需要使用者主動啟用 ipfilter 或 pf 才會受影響。團隊表示會在兩個月內推出 11.1 收斂這些已核准的 pullup 修正。安裝映像檔提供 CD-ROM(小於 700MB)、完整 DVD,以及需要先解壓縮的 USB .img 格式,ARM 裝置則有預先配置 U-Boot 的映像可用。

原始來源:NetBSD 11.0 released!(blog.netbsd.org)NetBSD 11.0 正式發布公告


從畫鵜鶘騎腳踏車到讓 AI 演算魔戒:Karpathy 說我們正在離開舊時代的 LLM 測試法

X (Andrej Karpathy) · 2026-08-02

背景:一隻鵜鶘怎麼變成 LLM 界的迷因

「畫一隻騎腳踏車的鵜鶘 SVG」這個測試,最早是開發者 Simon Willison2024-10-25 的部落格文章〈Pelicans on a bicycle〉裡提出的自娛式評測方法,當時他測的是 Alibaba 的 Qwen2.5-Coder 系列。他選鵜鶘的理由很直白:喜歡鵜鶘,而且很確定訓練資料裡不會剛好有一堆「鵜鶘騎腳踏車」的 SVG 檔案可以抄。這個怪異但好用的測試後來變成每次新模型發布,社群都會自動拿來跑一輪的非正式基準,兩年下來 Willison 自己累積測過超過 60 個模型的鵜鶘畫作,連 Google I/O 主題演講都出現過鵜鶘騎車的畫面。

Karpathy 在 8 月 2 日說了什麼

今日在 HN 首頁重新炒熱這個話題的,是 Andrej Karpathy2026-08-02 發的一則貼文。他寫道:「我們正開始離開那種用『畫一隻騎腳踏車的鵜鶘 SVG』來測試 LLM 的階段」,理由是這類靜態、單輪的視覺生成任務對目前最強的模型來說已經不構成挑戰。他隨文附上自己做的實驗:給 Opus 5 魔戒(The Lord of the Rings)開頭第一段文字,配上約 1M token 的預算(換算成本約 10 美元),要求它輸出一段 Three.js 渲染程式。

Opus 5 花兩小時寫了什麼

Karpathy 描述 Opus 5 連續運算了約兩小時,吐出大約 5500 行程式碼,以程序化生成(procedural generation)的方式把魔戒開場的場景搬進一個可以互動的 3D 世界——包括在三維座標中擺放多邊形素材、寫動畫邏輯,盡量把文字敘述轉成畫面與運鏡。他形容成果「有點笨拙但很好玩」(kind of janky but fun),並把渲染結果放上自己的個人網站供人查看。他強調的重點不是這個 demo 本身多完美,而是「沒有人會正常去做這件事」與「反正幾乎免費,何不試試看」之間的門檻已經消失。

HN 上的迴響:基準已經飽和了

這則貼文在 Hacker News 拿下 375 點、296 則留言衝上首頁,但留言區的討論方向其實跟 Karpathy 的原意有點分岔。不少人聚焦在「鵜鶘騎腳踏車測試是否已經飽和」:過去這個測試好用,是因為多數模型畫不好,一旦畫得好就代表這個模型明顯比較強;但現在幾乎所有主流模型都能交出可辨認的鵜鶘與腳踏車,測試本身的鑑別力因此下降。也有留言反駁,認為就算多數模型「看起來」畫對了,細看仍常見腳踏車力學不合理、鵜鶘比例錯亂等問題,顯示空間推理能力並沒有真的解決,只是問題被畫面風格掩蓋掉了。

從迷因到方法論的爭論

另一派討論則轉向「該用什麼取代鵜鶘測試」,Three.js 版魔戒場景被部分人視為下一階段的候選方向——因為它同時考驗長文本理解、程序化生成、以及跨越數千行程式碼的自洽性,遠比畫一張靜態 SVG 苛刻。也有評論引用先前部落格〈Are AI labs pelicanmaxxing?〉裡的觀察,質疑當一個非正式測試變成公關素材後,AI 實驗室是否會反過來針對這個特定 prompt 做過度優化,讓它逐漸脫離「衡量真實能力」的初衷,變成更像是行銷考題。

原始來源:Andrej Karpathy on XSimon Willison,「Pelicans on a bicycle」(2024)Hacker News 討論串


End of article
0
Would love your thoughts, please comment.x
()
x