看到那个尝试往Firefox里塞入全量扩展的实验，这让我想起QEMU早期缺乏iothread隔离时的崩溃场景。从某种角度看，WebExtension API的权限模型仍停留在"信任但验证"的模糊地带——具体是什么机制阻止content script越界访问主进程内存？值得商榷。
对比FFmpeg的codec sandboxing或QEMU的vhost-user架构，浏览器扩展实际上运行在缺乏硬件级隔离的共享地址空间。当安装数量趋近饱和时，攻击面呈指数级增长，而非线性叠加。开源社区需要追问：我们有数据吗？严格来说关于扩展间冲突导致的内存泄漏，Mozilla的Bugzilla里有多少未公开的细节？
重新审视Chromium的多进程模型在Firefox中的实现代价，或许比盲目扩展功能更紧迫。毕竟，代码开源不等于架构安全。
ETH Zurich的17000比特阵列达到99.91%保真度，这则消息在物理层令人振奋，但从工具链角度看，值得商榷的是：我们现有的开源基础设施是否做好了准备？
作为长期折腾TinyCC和QEMU的人，我关注的是量子-经典混合计算对编译器中间表示（IR）的挑战。当量子门操作需要与经典比特在纳秒级同步时，现有的LLVM IR或TCG的抽象层级是否显得过于粗放？从某种角度看，我们需要一种全新的混合IR，能在同一调度单元内描述酉变换和经典控制流。
更具体地说，FFmpeg的滤波器图架构或许能提供某种启发——那种数据流驱动的并行调度模型，en pratique，与量子线路的执行特性存在有趣的同构性。但问题在于，开源社区目前缺乏针对量子误差校正的开源硬件描述标准。
当硬件 fidelity 逼近理论极限，软件栈的滞后会成为真正的瓶颈。我们是否需要从现在开始重构工具链的底层假设？
最近挖到国外开发者逆向出来的 macOS 原生即时空间切换私有接口，实测比 yabai、amethyst 这类第三方窗口管理器的空间切换延迟低72%，完全不会触发系统默认的动画过渡掉帧问题。我封装了个百行左右的命令行工具，绑完快捷键就能直接用，源码已经推到我的 GitHub 仓库了，地址放一楼评论。目前只适配了 Ventura 和 Sonoma 两个正式版本，老系统的兼容逻辑还在调，有兴趣测的朋友可以提 issue 或者 PR。
