WebAssembly 並非純粹的堆疊機：從規格細節重新理解 Wasm 語意
purplesyringa.moe · 2026-04-27
WebAssembly 規格文件和普遍的技術介紹文章都將其描述為「堆疊機」（stack machine），但從指令集的實際能力來看，Wasm 更接近「運算元可以構成複合表達式的暫存器機器」。
缺失的堆疊操作指令
傳統堆疊機（如 JVM）具備 dup、dup_x1、pop、swap 等堆疊重排指令，允許在不引入變數的情況下對運算元進行複製與重排。Wasm 提供了大量「接收引數並將回傳值壓入堆疊」的指令，但幾乎沒有任何可以重排堆疊的指令。
對最佳化的影響
缺少堆疊重排原語，純粹的 Wasm 無法在不引入區域變數（local variables）的情況下執行公共子表達式消除（CSE）。例如計算 expr² 時必須寫成 local.set; local.get; local.get; i32.mul，而非某種能從堆疊中複製的操作。這使得區域變數（屬暫存器機器語意）成為任何超過單純表達式求值的必要工具。
控制流限制
在 multi-value 擴充加入之前，if 區塊入口前壓入堆疊的值無法在 if 主體內存取，且區塊只能回傳單一值——這在語意上嚴重限制了純粹的堆疊行為。
編碼 vs. 語意
Wasm 的二進位格式以 RPN（逆波蘭表示法）編碼，可用堆疊求值；但文字格式（WAT）採用類 LISP 的巢狀語法而非堆疊語法。這一矛盾表明堆疊是實作細節，而非語意基礎。正確的理解是：Wasm 是一種以複合表達式為運算單元的暫存器機器，其二進位編碼恰好可被堆疊機器直譯。
原始來源：purplesyringa.moe
以 eBPF sockops 繞過 DPI：誘餌 TLS ClientHello 注入技術剖析
bora.sh · 2026-04-28
深層封包檢測（DPI）通常在 TCP 握手完成後、應用資料傳送前，透過 TLS ClientHello 的 SNI 欄位識別並封鎖連線。此文提出一種以 eBPF sockops 程式注入誘餌封包以繞過 DPI 的實作方案，無需 VPN 或代理基礎設施。
核心原理
方案在真實 ClientHello 送出前注入一個誘餌 TLS ClientHello，誘餌封包攜帶無害的 SNI（如 www.google.com）並設定極低的 TTL——足以到達中間箱（middlebox）但在到達伺服器前即過期。DPI 記錄並放行無害域名後，真實的 ClientHello 得以不受阻礙地通過。
eBPF 程式架構
程式類型為 sockops，掛接於 cgroup，在 BPF_SOCK_OPS_ACTIVE_ESTABLISHED_CB 回呼中（TCP 三次握手完成後、應用資料傳送前）觸發。關鍵操作包含：
- MSS 限制：以
bpf_setsockopt將TCP_MAXSEG降至 88 位元組，使真實 ClientHello 跨越多個 segment 傳輸。部分 DPI 實作僅檢查第一個 segment，SNI 欄位因此消失 - 事件通知：透過 perf event 輸出源/目的 IP、埠號、以及
snd_nxt和rcv_nxt序號，供使用者空間精確構造誘餌封包 - 排除清單：透過 BPF map 允許對特定目的 IP 跳過繞過
使用者空間協調
Go routine 讀取 perf event，以相同五元組（five-tuple）、匹配的 seq/ack 值、TTL=8（可透過 traceroute 調整）透過 raw socket（IP_HDRINCL）注入誘餌封包。
平台差異
Linux 的 sock_ops 提供同步核心鉤子，握手後的批量流量開銷接近零。macOS 與 Windows 缺乏 eBPF 支援，需改用 TUN 設備搭配 gVisor 使用者空間 TCP 棧，所有流量跨越核心—使用者邊界，開銷顯著增大。
原始來源：bora.sh
非法狀態 vs. 不期望狀態：形式方法中系統設計的關鍵區分
Hillel Wayne Newsletter · 2026-04-28
在類型系統與形式驗證的討論中，常有一個混淆：「讓非法狀態無法表示」（make illegal states unrepresentable）的設計原則適用於所有應避免的狀態嗎？Hillel Wayne 透過幾個具體範例區分兩個本質不同的概念。
定義
- 非法狀態（Illegal State）：系統絕對不應進入的狀態，以形式語言表達為
[]!Illegal（必須始終為假）。一旦進入即為程式錯誤。 - 不期望狀態（Unwanted State）：系統可以暫時進入但應盡快離開的狀態，安全屬性為
[]<>!Unwanted（最終必然離開）。P 語言稱之為「熱狀態（hot state）」。
具體範例
行事曆衝突：兩個重疊活動同時預訂某人是「不期望」但非「非法」——衝突在現實中確實發生，且解決衝突的工作流需要系統先能表示衝突狀態。若以 {user: {time: optional event}} 的資料結構強制防止衝突，反而過於限制而不切實際。
航空超賣：乘客數超過座位數是不期望（可管理的），但實際上飛機上的乘客多於座位則是非法（必須在登機前阻止）。
網路分割：網路分割是不期望的（不造成資料損毀），但永久保持分割是不可接受的，形式化為 []<>!Partition（必須最終癒合）。
設計含義
不期望狀態不應從類型系統或資料模型中抹去，因為外部輸入可能強制系統進入這些狀態，某些工作流程甚至刻意需要它們（如超賣預期有旅客取消）。正確做法是保持可表示性，並建立偵測與轉換機制。
Asahi Linux 進度報告：Linux 7.0 帶來 M3 支援與 20% 閒置功耗降低
Asahi Linux · 2026-04-27
Asahi Linux 對應 Linux 7.0 核心的進度報告，包含驅動程式上游提交、電源管理改善與 M3 裝置初步支援。
電源管理處理器（PMP）整合
M1 Pro 裝置的 PMP 驅動整合帶來約 20% 的閒置功耗降低（約節省 0.5 瓦）。M1 基礎型號的支援仍在開發中。
環境光感測器（ALS）驅動
新驅動支援透過 Always-On Processor 實現 True Tone 顯示功能。校準韌體從 macOS 中取得並存儲於 EFI 系統分區，需要韌體更新時，重新啟動到 macOS 並執行 Asahi 安裝程式即可完成。
藍牙共存
Broadcom 廠商專用 HCI 擴充現處理 2.4 GHz 的 WiFi/Bluetooth 干擾。透過 BlueZ 整合，音訊串流自動獲得優先傳輸，消除過去的音訊中斷問題。
M3 裝置支援
M3 機器已取得 PCIe、鍵盤/觸控板、RTC、重啟控制器與 NVMe 支援，達到與初始 M1 Alpha 版本相當的功能水準。
可變更新率（VRR）
透過韌體參數分析發現 VRR 支援。實作需使用 modesetting，雖然違反 VESA 規格，但符合 DCP（Display Controller Processor）的實際行為。
音訊進展
CS42L84 驅動已上游，支援的取樣率擴展至 44.1、88.2、176.4、192 kHz。通用匯流排保持器 API（generic bus keeper API）用於喇叭功放設定，計畫於 7.1 合併。Fedora Asahi Remix 44（含 Plasma 6.6）於同期釋出。
原始來源：Asahi Linux Blog
標準 C++ 能否取代 CUDA？execution policies 的 GPU 可攜式程式設計實驗
isocpp.org (CppCon 2025) · 2026-04-23
CppCon 2025 的演講探討以 C++ 標準平行演算法（parallel algorithms）搭配 execution policies，在 GPU 上達成接近 CUDA 的效能，同時保持程式碼可移植性。
技術路徑
C++17 引入的 std::execution::par_unseq 策略允許向量化且不考慮執行順序的並行，實作（如 NVIDIA 的 NVCPP）可將此映射到 CUDA kernel。C++26 的 sender/receiver 框架（std::execution，P2300）進一步提供非同步任務圖，使複雜的 GPU 流水線調度可在不觸及 CUDA API 的情況下表達。
效能比較
演講呈現計算密集型分析工作負載中標準 C++ 與 CUDA 手寫程式碼相當的效能數字，但強調記憶體傳輸（host↔device）的調度仍是標準化不足之處，需要廠商擴充或封裝層處理。
限制
CUDA 特定功能——如 warp-level primitives、共享記憶體分配、texture memory——在標準 C++ 中無對應抽象，要求最大 GPU 利用率的場景仍難以完全放棄 CUDA。
原始來源：isocpp.org