yip：低延迟 P2P Mesh VPN，把 FEC、打洞和抗 DPI 一起塞进 Rust 数据面

这个叫 yip 的项目，瞄准的不是“再做一个 VPN”这么简单，而是把 低延迟直连、抗丢包、抗 DPI、去中心化发现 这些平时往往分散在不同系统里的能力，尽量压进同一套 Rust 架构里。项目定位很明确：优先追求点对点链路上的实时性，适合游戏、流媒体和对 p99 延迟敏感的场景，而不是只把吞吐量堆上去。它的数据面已经能跑通加密的 L2/L3 隧道，控制面也已经补上了多对等路由、自认证地址、NAT 打洞与盲中继等关键能力。

比较有辨识度的一点，是它把 前向纠错（FEC） 当成一等公民来做，而不是把丢包恢复完全交给重传。作者给出的方向是：实时流量尽量不为冗余付出额外时延，而高丢包或大吞吐场景则按需增加冗余，让链路在不回头“重问一次”的情况下把包补回来。配合 TUN/TAP 双数据面、epoll 默认驱动、可选 io_uring、sendmmsg / UDP_SEGMENT / GSO / GRO 这一整套 I/O 和内核侧优化，这个项目的目标很明显是在真实网络条件下压住时延尾部，而不是只看实验室里最漂亮的单点指标。

更吸引眼球的是它在 DPI 对抗 上的工程路线。项目强调没有固定 magic bytes、没有固定头部偏移，还支持带密钥的头部保护、随机 padding 和控制面 jitter；README 里甚至明确拿 nDPI / nDPId 当测试对手。加上后续还计划继续推进 TLS/QUIC 拟态、诱饵包和流量分析防护，这个项目已经不是“会用 Rust 写网络程序”这么普通，而是在认真拿 Rust 去做一套相当激进的隐蔽型网络栈。

原文链接：https://github.com/femboyisp/yip

Veryl 更新：硬件验证组件现在可以直接用 Rust 编写，并挂进内置模拟器

Veryl 这次带来的更新，对硬件方向的 Rust 用户其实很有吸引力：作者把 验证组件（verification components） 直接接进了 Veryl 自带的 RTL 模拟器。以前写 HDL 语言时，简单 testbench 可以自己消化，但一旦走到复杂总线模型、协议检查器、golden model 这类场景，大家很容易又回到 SystemVerilog 生态或者手写 DPI 胶水。现在 Veryl 的思路是，让这些验证组件本身就成为普通 Rust 代码，并在模拟运行时通过 $comp 命名空间挂进去。

这件事的价值不只在“能用 Rust 写”，而在于验证逻辑终于能直接借用 Rust 现成的语言能力和库生态。文章举的例子里，一个 ReqAckChecker 这样的组件本质上就是普通 struct + impl，靠派生宏和 on_clock 钩子接上模拟器；而更接近真实项目的例子，则是作者维护的 AXI verification component 集合 vip，已经覆盖 AXI4-Lite、AXI4-Stream、AXI4 和 AXI3 的 master、memory model 与 checker。

另外一个很现实的点是分发方式。Veryl 没要求所有用户都必须本地装好 Rust 工具链，验证组件既可以源码形式随包分发，也可以在受限场景下打成预编译 wasm 供消费方直接使用。对硬件开发链路来说，这种“Rust 参与验证，但不强迫全员先配置完整 Rust 编译环境”的折中其实很重要。它让 Rust 在 HDL 工具链里的角色，从外围辅助脚本更进一步走向了真正的验证执行层。

原文链接：https://veryl-lang.org/blog/verification-components/

Zenith：Rust 核心配上 Metal 渲染，原生 macOS 终端把 AI 面板和幽灵补全也一起做了

这个 Zenith 项目挺有意思：它没有走“跨平台优先”的老路，而是直接瞄准 原生 macOS 终端 体验。整体结构是 Rust workspace 负责终端状态机、PTY、VTE/OSC 解析、历史频率统计和字形栅格化，再通过一层 C FFI 把渲染数据送给 Swift/AppKit 外壳，由 Metal 做 instanced rendering。也就是说，终端最核心、最容易吃性能和状态复杂度的部分交给 Rust，而窗口、输入法、原生标签页这些贴近平台体验的外壳则交给 Swift。

从作者给出的设计来看，Zenith 的亮点不只是“Rust + Metal”这两个关键词，而是它确实在把一套现代终端该有的体验往完整了拼。比如只在需要时 redraw，以减少静态界面的 CPU 占用；支持 OSC 133 shell integration，为后续智能特性提供命令边界；还有 native tabs、ghost-text autosuggest，以及一个可以通过 ⌘K 打开的内联 AI 面板。相比很多项目只展示 benchmark 或一段 demo，这个仓库已经明显在朝“日常可用的桌面终端”方向收敛。

作者在帖子里还提到了一些很工程化的坑：SwiftPM 对通过 unsafeFlags 链接的静态库变更不敏感，Rust 侧重编译后并不会自动反映进 App；setVertexBytes 有 4KB 限制，大帧必须换成 MTLBuffer；双宽字符的字形渲染也会跟真实 cell 宽度打架。这类细节反而说明它不是停留在概念图阶段，而是已经进入真正做终端产品时会遇到的“脏活累活”阶段。

原文链接：https://github.com/Gkyohd/zenith

OpenJTD 0.0.1 开发者预览：Rust 开始认真接管一太郎文档解析、导出和 Web Viewer

OpenJTD 0.0.1 的切入点相当少见：它想做的是 一太郎（Ichitaro）文档格式的开源渲染引擎和编辑器工程，当前阶段先围绕 rjtd Rust workspace，把容器检查、文本提取、文档建模、导出和 viewer 集成这些基础部件搭起来。对中文 Rust 社区来说，这类项目平时不算高频，但从格式兼容、数字保存和老文档可访问性角度看，它的价值非常扎实。

这一版开发者预览已经能处理不少有分量的东西：包括 CFB/OLE 容器检查、对观察到的 /DocumentText 流进行文本提取、对 .jttc 的 JustCompressedDocument / -lh5- 负载做支持，以及把内容导出成 Markdown、JSON 和面向文本的 PDF。项目还提供了早期的浏览器端 viewer，用来在本地直接打开 JTD 家族文件。虽然它还远谈不上“完整还原排版”的终态，但把可检查、可导出、可继续研究的 Rust 组件先铺出来，本身就是很对路的工程策略。

仓库里也能看出这个项目对安全边界比较谨慎。README 明确把未知结构保留、把异常资源消耗和解析器崩溃当成安全问题来对待，并强调当前输出仍应视为保守型、文本导向的 fallback，而不是原生版式复现。对逆向工程和兼容性项目来说，这种“先把边界写清楚，再慢慢扩能力”的姿态，往往比一开始就喊“完全兼容”更靠谱。

原文链接：https://github.com/KimEJ/OpenJTD