rsync 这种工具，平时像水管。没人盯着看，但一漏水，整栋楼都知道它在。
OpenBSD 这次把 openrsync 合入 base，做法很 OpenBSD：不追求把传统 rsync 的功能表全部搬过来，而是拿一个 BSD/ISC 许可证、范围更窄、权限边界更硬的实现，放进自己的基础系统。
最容易误读的地方也在这里。openrsync 不是传统 GPL rsync 的补丁，也不是全 Unix 世界的新默认项。它能和支持协议 27 的现代 rsync 交互，测试对象包括 rsync 3.1.3，但命令行参数只支持子集。
少支持一些参数，不是附带损失。对 OpenBSD 来说，这就是设计的一部分。
openrsync 到底能替谁，不能替谁
openrsync 的官方支持系统是 OpenBSD。GitHub 仓库不是一个脱离 OpenBSD 的独立商业项目，而是 OpenBSD 版本加上一些跨 Unix 的可移植胶水代码。项目贡献也应走 OpenBSD 的 tech 邮件列表。
几个边界先摆清楚：
| 问题 | openrsync 的答案 |
|---|---|
| 许可证 | BSD/ISC，区别于传统 GPL rsync |
| 系统位置 | 已合入 OpenBSD base |
| 协议兼容 | 兼容 rsync 协议 27，测试对象为 rsync 3.1.3 |
| 命令行支持 | 只支持 rsync 参数子集 |
| 官方支持 | OpenBSD；其他 Unix 主要依赖 portability glue 可编译运行 |
| 适用判断 | 常见交互可以看，复杂脚本不要直接迁 |
所以，这不是 OpenBSD 宣布替代所有 rsync。
更准确的说法是：OpenBSD 给自己系统里的关键同步能力，做了一个许可证更合适、代码更短、权限更好收束的版本。
对 OpenBSD 用户和系统管理员，直接影响很具体：常见同步任务可以优先看 base 里的 openrsync；已有大量参数组合的脚本，不能机械替换。先跑测试，再决定是否迁。尤其是依赖冷门参数、复杂 exclude/include 规则、历史兼容行为的脚本，更应该保守。
对 Linux 管理员，结论也不复杂：传统 rsync 仍是默认答案。成熟、强大、生态宽，脚本资产也厚。openrsync 目前不该被当成跨 Linux 生产环境的无痛替代品。
重要的不是多一个命令，是 OpenBSD 在收权限
openrsync 起源于 OpenBSD 的 rpki-client 项目。RPKI 属于互联网路由安全基础设施，用来验证路由声明是否可信。它离普通用户很远，但一旦出问题，影响不会只停在某台机器上。
项目资助方包括 NetNod、IIS.SE、SUNET 和 6connect。这个背景说明了它的气质：需求具体，风险明确，钱花在补基础工具上，而不是把 rsync 包成一个新产品。
安全设计也很 OpenBSD。
openrsync 使用 pledge(2) 限制进程能做什么，用 unveil(2) 限制它能触碰文件系统哪里。接收端需要写磁盘，就只给对应能力；dry-run 模式不该写，就不要让它写；daemon 客户端需要 DNS 和网络，也只应在必要范围内打开。
这不是安全口号。它是把权限一点点拧紧。
rsync 的工作天然敏感：读目录、比较文件、跨机器传输、写目标路径。越是这种基础工具，越不能靠一句大家一直这么用来维持信任。
古人说，工欲善其事，必先利其器。系统软件里还要补半句：器太利，也要有鞘。
OpenBSD 要的就是这个鞘。不是让工具什么都能干，而是让它在该干的范围内尽量少出事；真出事，也别把整个文件系统和进程能力一起赔进去。
接下来该看参数、脚本和维护成本
我不太买账那种参数不全，所以价值有限的简单判断。
参数不全当然是限制。复杂脚本不能直接迁，跨平台团队也不会因为 OpenBSD 合入 base 就马上改标准工具链。这些都是现实约束。
但基础设施工具的分水岭，从来不只是功能表。更关键的是三件事：谁能长期维护，谁能审计清楚，出错时边界能不能收住。
传统 rsync 的价值不用重讲。Andrew Tridgell 和 Paul Mackerras 当年的算法设计，是互联网基础工具史上的漂亮一笔。openrsync 没有否定它，只是在另一个问题上给出答案：如果 OpenBSD 只需要常见交互、协议兼容和清楚的安全边界，为什么要把全部历史包袱都放进 base？
这有点像早期 Unix 工具和后来的大型套件之争。不完全一样，但重复的是同一种张力：功能越多，覆盖越广；代码越厚，审计越难。天下熙熙，皆为利来。开源基础工具里，利不一定是钱，也可能是兼容性、惯性和旧脚本。
openrsync 的真正看点，不是它今天少了哪些参数，而是这几个变量：
- 参数子集能不能覆盖 OpenBSD base 里的高频场景。
- 与传统 rsync 的协议交互，会不会在边界用例里踩坑。
- pledge(2) 和 unveil(2) 的安全约束，能不能在真实使用中减少损害面，而不是只停在设计文档里。
- 可移植胶水代码会不会膨胀到反过来拖累可审计性。
这几项比喊平替或造轮子有用得多。
开发者和维护者也该据此行动。写 OpenBSD 脚本时，别默认 GNU/Linux 上的 rsync 参数都能用；维护跨 Unix 工具时，要把 openrsync 当成一个受限实现来测，而不是当成 rsync 的同名复制品。
OpenBSD 这次少见地把话说得很硬：基础系统不必讨好所有历史用法。能删的功能，就不要为了面子留下；能收的权限，就不要交给运气。
这事最后落回开头那个反常点：一个用了很多年的工具，为什么还要重写一遍？
答案不是为了多一个 rsync。答案是，关键工具不能永远靠惯性活着。惯性很好用，也最容易让风险睡着。