Servo 0.7.0 收进 9 月的 527 个提交
Servo 0.7.0 是 Servo 浏览器引擎的一个版本，官方博客写它包含 2026 年 9 月合入的全部改动，一共 527 个提交。博客发布日期是 2026-11-05。HimikoTogaFromUSSR 2026 年 11 月 6 日把 Phoronix 的报道发到 r/rust，采集时 187 分、18 条评论。GitHub release 写，v0.7.0 已经就绪，内容是 9 月的改动。crates.io 上的 servo crate 版本是 0.7.0，最低 Rust 版本 1.88.0，许可证 MPL-2.0。
新合入的网页平台功能包括 :checked 伪类、user-select、<progress>、CSS typed arithmetic、alpha() 和 font-width。DOM 侧有 Selection 的 getComposedRanges() 和 direction，CSS modules 和 text modules，Canvas 的 roundRect()，VTTCue 的 getCueAsHTML()，以及 WebCrypto 的 MLKEM768-X25519。开发者工具控制台会提前求值 JS 输入。安全更新把 SpiderMonkey 升到 v153.3，mozangle 升到 v0.7，两边都带了上游报过的安全修复。
兼容性例子写了两条。egui.rs 的 demo 在 --pref dom._webegpu_enabled 下按预期工作。一个 Candy Crush 游戏现在可以玩。Control+A，macOS 上是 Command+A，会选中文档里的全部内容。密码输入框里的文本不能再被复制。
嵌入 API 有几处调整。无障碍工具产生的事件走 Servo::forward_accessibility_action。WebView::clear_session_history 可以清掉会话历史。WebView::set_throttled 被去掉，WebView 隐藏时自动节流，显示时停止。webgl 进入 default_web_features，不想带 WebGL 的嵌入方需要关掉默认 feature。多进程模式在构建时打开，博客写去掉这项支持大约少 2MB。Linux 上打开了线程亲和性提升。Android 的 JVM 兼容目标升到 11。Windows 主机可以交叉编译 OpenHarmony 构建。OpenHarmony SDK 更新到 API 23。
release 附件里的 servo-aarch64-linux-ohos.hap 签给 OpenHarmony，不是 HarmonyOS。HarmonyOS 目前需要自行签名，说明指向 ArkTS Servo Demo 仓库。
捐款数字写在文末。经常性捐款是每月 8144 美元，比 8 月高 1%。thanks.dev 上有 37 个依赖 Servo 的 GitHub 用户在赞助，比 8 月多 1 个。博客列出 10 位这个月第一次给 Servo 合入补丁的贡献者。
Bassfaceapollo 的评论有 58 分，希望 Servo 至少成为 Gecko 的替代。noobjaish 的评论有 19 分，提到 Ladybird 计划在接下来几个月放出二进制。r2vcap 的评论有 0 分，写 Servo 由 Linux Foundation Europe 支持，并提到华为通过 OpenHarmony 参与。barsoap 的评论有 2 分，问这怎么构成对中国的依赖，并写 545400 欧元的资助相对很小。
原文链接：https://servo.org/blog/2026/11/05/september-in-servo/
tokio-tun 0.23.0 补上 Linux offload
tokio-tun 是用 Tokio 异步创建 TUN/TAP 设备的 Rust 库。仓库在 https://github.com/yaa110/tokio-tun 。n47id 2026 年 11 月 7 日发到 r/rust，采集时 0 分、0 条评论。采集时仓库 95 星、35 个 fork、58 个 tag。最新版本是 v0.23.0。
README 写，支持的平台上，包 I/O 都通过 AsyncFd 注册到 Tokio。没有单独的轮询循环，没有阻塞回退，也不自己抽出文件描述符。Tun::builder() 可以设名字、地址、前缀、对端和 up。名字留空时由内核分配。一次 recv 返回一个 IP 包。写回 TUN 的数据必须是合法的 IPv4 或 IPv6 包。
v0.23.0 的 Linux 部分加了 virtio-net offload。TunBuilder::offload() 打开 TSO/GSO/GRO。新增 VirtioNetHeader、VIRTIO_NET_HDR_LEN 和 GSO 常量。每个收到的包前面有 10 字节的 virtio_net_hdr，发出去的包也要带这个头。offload() 配置 checksum、TSO4、TSO6 和基于 NAPI 的 GRO，并且不能和 packet_info() 一起用。NAPI GRO 作用在从用户态写进内核的包上，不会合并交给用户态的包。打开 offload 后，接收缓冲区至少要 VIRTIO_NET_HDR_LEN + 65_536 字节，因为 GSO 包可以超过接口 MTU。多队列附加时，每个队列都要调用 .offload()，状态不一致会被拒绝。
FreeBSD 这一版补了 TAP 的 MAC 地址，TunBuilder::persist()，以及 TAP 的 broadcast。persistence 保留接口身份。FreeBSD 在最后一个描述符关闭时会清掉地址和 up 状态。分配改用 SIOCIFCREATE2，避免误接管或拆掉已经存在的 persistent 或改过名的设备。
平台表写的是：Linux 有 TUN、TAP、多队列和 offload。macOS 只有 TUN，走 utun。Android 和 iOS 只有 TunQueue，分别接 VpnService 和 NetworkExtension 的 fd。FreeBSD 有 TUN 和 TAP，没有多队列，也没有 offload。macOS 和 FreeBSD 上，TUN 的 IPv6 destination 需要 /128 前缀。
原文链接：https://github.com/yaa110/tokio-tun
业余开发者问能不能给 rustc 提补丁
这是 Motor_Alternative944 发在 r/rust 的一篇提问。作者写自己没有计算机专业背景，最近在自学计算机科学和编译器，想知道学习期间能不能给 rustc 或类似的编译器项目做贡献，以及维护者会不会因为水平不够而不收。采集时 22 分、30 条评论。帖子时间是 2026-11-06 15:32 UTC。
Ok-Zookeepergame4391 的评论有 38 分，写除了能力以外没有门槛。Crouton4035 的评论有 67 分，写理论上谁都可以提议代码，实际要有专业水平的知识和经验，补丁才比较有机会通过。评论还写，维护者普遍报酬低、已经超负荷，不确定自己在做什么的时候不要增加他们的工作量。评论建议先把 Rust 代码库下载下来读，先不要指望马上贡献。
Anthony356 的评论有 1 分。作者写自己是业余开发者，大约 4 年前开始学，大约一年半前给 rustc 提了自己最早的一批 PR 之一，最近加入了编译器团队。评论写，业余作者如果愿意听审阅意见，维护者一般不介意一份出于好意的 PR。评论把自己被邀请进编译器团队的原因写成：有时间去处理大家都认为状态不好、但因为复杂而没人愿意碰的部分，并把它记下来。评论写，审阅者到目前为止比较友好，不熟悉的 git 命令也可以问。建议是不要为了改而改。
Kivooeo1 的评论有 12 分，写自己有一篇讲这个话题的文章，以及两篇从 issue 到合并的后续，里面有审阅过程。评论写可以帮忙看，前提是自己做，不要让 LLM 把整个 PR 做完再一直点继续。评论写，维护者现在要花很多时间和精力处理这类自动提交。Equivalent_Head_4803 的评论有 6 分，写 issue 经常在自己动手之前就被机器人占掉，维护者的时间被指向 GitHub 的自动提交占掉了。
QuasiRandomName 的评论有 11 分，写自己最早的开源贡献是给 rust-lang 的两个小 PR，和 fmt::UpperHex / LowerHex 里的检查有关。Eh2406 的评论有 5 分，写时间够的话，靠持续做会变成熟悉这块的人。在那之前，碰到不懂的缩写或术语就去查。查得到就学会了。解释难找，可以建议把链接补上，并记下自己找过但没有答案的地方。找不到解释，就告诉维护者。MilkEnvironmental106 的评论有 7 分，建议从 GitHub 上相对简单的 issue 开始提 PR。
原文链接：https://www.reddit.com/r/rust/comments/1xpfpc5/is_it_possible_for_me_to_contribute_to_the_rust/
目录扫描先看 ignore，再谈 Rayon
这是 weaztoven 发在 r/rust 的一篇提问。作者在写一个 Rust CLI，扫描目录并对文件做清理。现在是单线程，准备用 Rayon 把遍历和处理并行起来。问题是普通 SSD 和网络挂载上，线程池打满时有什么坑，Rayon 是不是还合适，有没有限制并发的写法。采集时 10 分、8 条评论。帖子时间是 2026-11-06 16:49 UTC。
tylerlarson 的评论有 23 分。评论写，Rayon 更偏 CPU 并行。只做目录遍历时，评论把 BurntSushi 为 ripgrep 写的 ignore crate 称为现成做法。它自带多线程池，并行遍历，自动遵守 .gitignore，并处理线程边界。作者回复会去看，因为手写 gitignore 规则比较麻烦。
layla4you2 的评论有 3 分。评论写，Rayon 的池子是每个核一个线程，适合 CPU 工作。文件 I/O 大部分时间在等。本地 SSD 用默认值可以。网络挂载上每次 stat 或 unlink 都是一次往返，在途请求要比核数多，但不能把服务器打满。并发数做成 -j 参数，不要猜。遍历可以用 ignore 的 WalkParallel，也就是 ripgrep 用的那条，或者 jwalk。限制并发的写法是：walker 进一个有界的 crossbeam channel，再由 N 个工作线程消费，背压由 channel 给出。清理时先删子项再删目录，不要跟随符号链接，把 NotFound 当成正常情况。
The_8472 的评论有 1 分，建议先用 strace 看实际系统调用和时间花在哪里。如果要 stat 几百万个文件，可以考虑用 io_uring 把这些调用收成一次系统调用。fiedzia 的评论有 1 分，写瓶颈多半在操作系统或硬件，除非先证明不是这样。
原文链接：https://www.reddit.com/r/rust/comments/1xphogg/best_practices_for_parallelizing_filesystem/
From Rust中文社区 Mike
社区学习交流平台订阅：
评论区
写评论还没有评论