gpu-video - 硬件视频编解码库 v0.5.0 在 Vulkan 上接近厂商接口速度，并支持 macOS
对这类硬件编解码库，性能是首要问题。这一版在 Vulkan Video 上，解码提速 68% 到 164%，编码提速 13% 到 69%，具体取决于显卡与场景的组合，速度进入 GPU 厂商自带 API 的同一水平。
库把工作按批提交给 GPU，单次操作可以是复制图像的一部分，或把一帧图像压缩进视频。触及同一块内存的操作必须显式排序；Vulkan 默认会同时执行彼此独立的操作。典型的单帧编码是：把含原始帧字节的 buffer 复制到 GPU 上的图像，再编码该图像。这两步有内存依赖，必须等复制写完才能开始编码，否则可能竞态，输出无效。编码还有一层依赖：后续帧常参考前面的帧，因此下一帧必须等上一帧完成。
上一版的同步可以工作，但不够快：编码引擎大部分时间空闲；提交任务的线程会阻塞到该任务结束才提交下一个，CPU 与 GPU 的同步开销也不小。阻塞直到 GPU 任务完成，是早期为了降低开发难度而故意保留的。开发已经基本过了早期阶段，可以不再在这里阻塞，而这个改动需要新的 API。
https://smelter.dev/blog/gv-v05
GPUI - 评论文章认为它和 egui 的状态模型撑不起复杂桌面应用
近期用原生 Rust GUI 框架做桌面应用的趋势更明显：Discord 宣布用 GPUI 重写客户端，不少 LLM 仿制品则选择 egui。一篇评论文章认为，这两者的状态模型对复杂桌面应用都是死胡同。项目本身并不差，Zed 用起来确实快，作者自己也在 bevy 游戏里用 egui 做调试界面，但它们不该成为原生桌面应用的默认选择。
文章把问题收成一句：一个值变了，到底会跑哪些代码。它引用 Raph Levien 转述 Ron Minsky 的话：每个 UI 框架里面都藏着某种增量计算。文中对比了五种模型：immediate（egui）下一帧跑完全部 UI，没人找变化；Elm（Iced）重跑整个 view 再做 diff；Views（GPUI）由你调用 notify，没有缓存的 view 都会重跑；signals 重跑（Freya、Compose）由框架重跑读过该值的组件；signals 只跑一次（Floem、Solid、zgui）则只跑读过该值的闭包。前三种的吸引力在于状态不用同步、渲染就是普通 Rust、没有宏或另一套编译器，但作者认为它们扩不上去；框架说不清“什么变了、谁依赖它”，就得由应用手工补上，而这会牺牲当初让 API 好用的那些语义。一旦承认需要这种精度，只运行一次、带 signals 和 reactive holes 的组件才是最简单的写法。
GPUI 自称 hybrid immediate and retained mode：状态留在 entity 里，界面写在 render 里，改状态必须触发重跑。Render for Sidebar 这种实现就是普通 Rust，可以用 if、for 和局部变量。但更新要显式写 cx.notify()，而 notify 只带上 entity id。Rust 的 &mut 没有写屏障，框架看不出哪个字段变了，也看不出究竟有没有变化。这和 Angular 团队 2023 年对 zone.js 的评价同类：它只能通知“也许发生了什么”，而且这种做法扩展性不好。notify 比 zone 精确，因为它点名了 entity，可在这个 id 之下 GPUI 一无所知，于是会重绘所有不在有效 .cached() 后面的 view。实际里 .cached() 很少被用到，还会限制布局语义，所以常常是每个 view 都重绘。
作者用基准专门测大界面里一次稀疏变化的成本。3000 个存活行、每行一个 cached view 时，改一个标签要 8.4 ms；悬停、按键、写入与旧值相同的数据代价差不多，因为开销跟着树走，不跟着变化走，大约每 1000 个存活行增加 3 ms。若这些行写成普通 element，同一次改标签要 92 ms。GPUI 有“快”的名声，常数也许不高，渐近上仍留了不少余地。作者说明：自己把 GPUI 当前的 Linux 渲染器移植到了 wgpu，下文的基准工具是自己做的，并且在做图表里出现的、基于 signal 的框架 zgui。
https://blog.zortax.de/posts/a-critique-of-gpui
crate_ask - 征求无堆分配、可用于大数据集的 no_std 众数计算 crate
有人在 r/rust 发帖，想找适合 no_std 的 crate：把一组数据传进去（引用或其他形式都可以），返回其中出现次数最多的数字。
要求是计算过程中不做内存分配，不使用 Vec，也不依赖任何堆上的结构，并且最好能处理较大的数据集。帖子目前是在征求这类 crate。
https://www.reddit.com/r/rust/comments/1xu2zm3/crate_ask/
upki - Ubuntu 26.10 的 curl 开始内置证书吊销检查
Ubuntu 26.10 Stonking Stingray 随附的 curl 已带上 upki 吊销检查，这是把接近浏览器水平的证书校验推广到整个操作系统的第一步。对比演示里，测试服务器先换成续签证书、再换成已吊销证书，同一条 curl 命令在 Ubuntu 26.04 Resolute Raccoon 上仍会接受吊销证书，在 26.10 上则会拒绝。测试 CA 和吊销数据用 Mozilla 的 CRLite 工具生成；curl、OpenSSL 和 upki 都是未经改动的 Ubuntu 软件包。
curl 通过 OpenSSL 验证证书链，而 OpenSSL 默认不检查证书是否已被吊销。26.10 中，curl 用 upki-openssl 把服务器证书与本地吊销数据集对照，采用与 Firefox 相同的技术，且不会为此再发网络请求，因此较快，也不把这次检查暴露到网上。作为推荐依赖的 upki 提供 systemd 定时器，每 6 小时在后台更新吊销数据；第一次更新之前，curl 仍按原来的方式工作。安装后可运行 sudo systemctl start upki-fetch.service 完成首次拉取。已吊销的站点会拒绝连接，例如 curl https://revoked.badssl.com/ 会得到 certificate revoked (23)；也可以把 curl -sw '%{certs}' 的输出交给 upki revocation check，查看任意站点的吊销状态。未吊销的站点行为与以前相同。
这套机制要解决的是吊销信息难以及时覆盖整个系统的问题。2026 年 10 月 17 日，研究者发现 eMudhra 八张中间 CA 证书的私钥在密码学上过弱，其中一把就是数字 4。持有这样的密钥可以为任意网站制作证书。Firefox 和 Chrome 当天就屏蔽了这些中间证书，多数其他应用则要等发行版更新 ca-certificates。
Foundations 团队计划在 Ubuntu 27.04 把 upki 接进系统自带的 OpenSSL，让常规证书校验也读取这份吊销数据。这样，直接使用 OpenSSL 的一千多个软件包里的大多数，不用各自修改就能用上该机制。curl 集成由 rustls 的 Joe 编写；Dirkjan 与 Joe（rustls）、@juliank 以及其他贡献者参与了这项工作。这次说明承接 @jnsgruk 二月的 upki 更新，以及七月的 26.04 预览。
https://discourse.ubuntu.com/t/introducing-initial-upki-support/91540
eMudhra - 八张中间 CA 证书私钥确认泄露
2026 年 10 月，eMudhra 的八张中间 CA 证书私钥被确认泄露。这些中间证书链接到 Mozilla、Microsoft、Apple 和 Chrome 根项目所信任的根；操作系统、浏览器、语言运行时、库和应用使用的信任库，很多也基于这些根项目的列表。报告人 Wayne 于 10 月 17 日用每张中间 CA 的私钥对一条消息签名，并报告给各根项目团队。页面列出的名称包括 EM DV、EM OV、EM EV TLS CA 的 G3B 与 G3C，主体分别为荷兰的 eMudhra BV 和美国的 eMudhra Inc，并链接到 emSign Root TLS CA - G3 与 AAA Certificate Services。
Firefox 和 Chrome 自 10 月 17 日起屏蔽这些证书，Microsoft 平台自 10 月 20 日起、Apple 产品自 10 月 22 日起屏蔽。该问题于 10 月 19 日向下游信任库作了负责任披露，不少信任库已发布或正在发布更新。CA 已吊销这些中间证书；Mozilla、Microsoft、Apple 和 Chrome 已通过 OneCRL、CRLite、CRLSets 等机制向各自用户分发吊销信息。11 月 10 日的更新称，Apple 已在 macOS 27.2.1、26.7.3 和 15.8.3 中修复 macOS 开发者工具的相关问题。
持有其中任一私钥的攻击者可以冒充任意网站或服务。不少客户端不使用吊销信息，需要软件更新才会不再信任这些中间证书，包括自带 CA 捆绑包的应用和库，以及 Slack、Discord 等基于 Electron 的应用。Electron 应用要更新到基于已修复 Electron 版本构建的发行版才会带上修复；只更新操作系统或浏览器不一定够。
10 月 22 日又增加了两条标记为 No CT 的链，其叶子证书从未记入 Certificate Transparency。强制执行 CT 的客户端即使仍信任对应中间证书也会拒绝它们；若能成功连上这些主机，则说明客户端信任已泄露的中间证书且不强制执行 CT，这类客户端可能在无人察觉的情况下被攻击。页面上的连通性检查目前对这些链标为尚未检查。连接失败只表示连不上，网络故障和证书被拒绝在浏览器中表现相同；若经会拦截 TLS 的代理访问，结果反映的是代理的信任库，代理未更新或未停用时，其后的客户端仍然暴露。
https://emudhra.we-have-a-problem.com/
AI 移植的 Rust 游戏模拟引擎 - 回放哈希全部一致
有开发者审计了一份由 Claude 从 TypeScript 移植到 Rust 的即时战略游戏确定性模拟，它用于一个类似 fxtwitter 的 Discord MP4 回放渲染器。原引擎超过 12,000 行，Rust 版集中在一个 12,349 行的 game.rs 中。代码可以编译，并在 30,000 多个 tick 上与原实现逐位一致：3,091/3,091 个检查点的 FNV-1a 状态哈希全部相同。运行开销却很大：4 vCPU 的 VPS 生成一段视频约需 31 秒，4.7 GHz 的 Ryzen 6800H 上每个 tick 约消耗 400 万 CPU 周期，每次渲染还会分配约 5.9 GB 帧缓冲。
这些开销来自为了满足借用检查器而保留的结构。TypeScript 中的单位和动作是 19 个类，例如 AttackExecution、WarshipExecution 和 PortExecution，各自持有指向 Game 的可变回指。安全 Rust 不能让大量对象同时可变借用同一个 Game。移植没有使用 Rc 和 RefCell，也没有把状态拆成互不重叠的子结构，而是取消这些类，在同一文件里写成 19 个 impl Game。tick 热循环中还有 175 处 clone 或 collect，在循环前复制 vector，使对 self 的不可变借用先结束。需要修改 self 里的集合、同时又把可变的 self 传给辅助方法时，则用 std::mem::take 把 vector 的所有权取到局部变量，再调用辅助方法。这种复制不能随意添加：如果修改落在临时副本上，模拟会从第一个 tick 起失去同步。
帖子指出，这种移植可以同时满足编译器和确定性哈希，却用克隆、临时取出所有权和单文件中的巨型 impl 绕开借用检查，而不是重组数据所有权。文中对照的常见改法，是把状态拆成 GameMap、WorldState、NavState、TraversalScratch 等互不重叠的部分，或改用 arena 索引。作者已将这份实现重构成一个 3-crate 的 fork，并记录了遥测。
https://www.reddit.com/r/rust/comments/1xryklf/we_designed_rust_to_fix_40_years_of_c_tech_debt/
--
From 日报小组 Mike
社区学习交流平台订阅：
友情赞助：
评论区
写评论还没有评论