2026 年 5 月,一位rsync用户升级到 3.4.3 版,发现运行多年的任务开始频繁失败。
他降回 3.4.1,一切恢复正常。
他打开 GitHub,准备看看最近改了什么。
然后愣住了,最近的36个提交,作者几乎都是:tridge and claude
AI? rsync这么重要的基础软件,竟然让AI参与开发?!
很快,rsync 的 GitHub Issues 里多了一条标题简单粗暴的帖子:
“求求你,别用 AI 把这个软件毁了。”
无数人加入对 rsync 和作者 Andrew Tridgell 的口诛笔伐,争论异常激烈。
普通人可能不认识rsync,它是互联网界最常用的数据同步和备份工具,只要你在享受“快速、省流量、断点续传”的数据备份服务,大概率就有 rsync在背后默默立功。
![]()
作者Andrew Tridgell更是传奇,他不但发明了 rsync、还创建了Samba、Ardupilot,甚至无意间推动了 Git 的诞生。
如果把互联网基础设施比作一座城市,Andrew Tridgell 至少亲手修过三条高速公路。
![]()
那么,这样一个影响了整个互联网几十年的关键工具,为什么会陷入“AI 开发”的争议漩涡?
0 1
一个伟大算法的诞生
故事得从上世纪90年代说起。
那时候主要是拨号上网,网速只有几十K,慢得要死,还时不时掉线。
通过网络把一个大文件(比如100M)从一台电脑复制到另外一台电脑非常费劲。
更费劲的是,如果这个大文件只是发生了一点儿改变(比如1K),还得重新传整个文件(100M),这简直是一场灾难。
你可能会会想到:能不能只传输文件变动的部分?
这确实是个好想法,实现起来却很复杂,因为这个文件的改动可以发生在任何地方(开头,中间,结尾),改动可能是添加,删除,修改.....
到底该怎么做呢?
1996 年,正在澳大利亚国立大学读博的 Andrew Tridgell提出了一个叫做rsync 滚动校验算法,漂亮地解决了这个问题。
![]()
算法比较复杂,这里不再展开,只说说简单的过程:
1.接收端把文件切成固定大小的块,对每块计算两个校验码:一个微弱但计算极快的弱校验(Rolling Checksum),和一个强壮但计算慢的强校验(MD4/MD5),并将这些校验码发给发送端。
2.发送端用“滑动窗口”在自己的文件上逐字节移动,快速比对弱校验,一旦匹配成功,再比对强校验。
3.最终,发送端只把那些“无法匹配”的原始数据,以及匹配成功的块编号发送过去。接收端就能在本地把新文件“拼”出来。
这个算法最终成了Andrew博士论文《排序和同步的高效算法》的基础,这个论文也成为了分布式计算领域的经典文献。
Andrew 不仅理论功底深厚,写代码也是一流。
他只花了一周时间,就用 C 语言把算法变成了可用软件,发布了 rsync 0.1 版,定位为比 rcp 更高效的替代品,并以 GPL 协议开源。
rsync 本身足够优秀——同步快、流量省、易于脚本化,恰逢 2000 年前后互联网、Linux 和开源运动同时爆发,网站发布、服务器迁移、NAS 备份、镜像同步、灾备系统……数据备份和同步成了普遍刚需。
rsync 几乎成为唯一的选择,逐渐被集成进所有主流 Linux 发行版,成为标配工具。
0 2
意外催生Git
按理说,Andrew Tridgell 应该会一直维护 rsync。
但就在 rsync 逐渐流行起来的时候,他亲手创造的另一个项目——Samba,遇到了更大的挑战。
![]()
如果你在 Windows 上访问过 Linux 服务器的共享文件夹,背后大概率就是 Samba。
它让 Windows 和 Linux 两个原本互不兼容的世界,能够顺畅地共享文件。在互联网早期,这是一个影响力丝毫不亚于 rsync 的明星项目。
然而,随着微软不断升级企业网络技术,Samba 要兼容的东西越来越多,原有架构已经难以支撑未来的发展。
Andrew 意识到,与其不断修修补补,不如推倒重来。
于是,从 2002 年前后开始,他启动了 Samba 4 项目,从底层重新设计整个系统。
此后的十年里,Andrew 的主要精力都投入到了这场艰巨的重构工程中,而他亲手创造的另一个项目——rsync,则逐渐交给了 Wayne Davison 维护。
![]()
在此期间,Andrew 还无意间做了一件大事,间接促成了 Git 的诞生。
当时,Linux 内核团队使用一款名为 BitKeeper 的商业版本管理工具。它功能强大,但毕竟是闭源软件,这让很多开源开发者始终觉得别扭。
Andrew 也希望研究 BitKeeper 的协议,开发一个兼容客户端。
没想到,这一下触碰了 BitKeeper 作者 Larry McVoy 的底线。他认为 Andrew 违反了承诺,直接撤销了 Linux 社区的免费授权。
Linux 内核团队一夜之间失去了版本管理工具。
没有办法,Linus Torvalds 只能亲自下场。
于是,一个叫 Git 的新工具诞生了。
![]()
后来很多人开玩笑说:
Andrew Tridgell 虽然没有写 Git,却在 Git 的诞生过程中,推倒了第一块多米诺骨牌。
0 3
你竟然用AI 写代码??
如果说 Andrew 发明了 rsync,那么 Wayne Davison 就是把 rsync 养大的人。
从 2002 年接手项目开始,Wayne 不断完善跨平台兼容性、网络同步能力和大规模目录处理,让 rsync 真正成为生产环境里的标准工具。
二十多年过去,他几乎把所有业余时间都投入到了这个项目。
但随着精力越来越有限,他想起了 Andrew 当年的一句话:
"如果有一天需要帮忙,就告诉我。"
2024 年 4 月,Wayne 联系了 Andrew,而 Andrew 也兑现了承诺,重新回到了 rsync 项目。
然而,迎接他的不是鲜花,而是 AI 带来的新挑战。
过去,一个月可能收到一份漏洞报告;如今,大模型可以批量扫描代码,生成海量安全报告。其中不少写得头头是道,却根本不存在漏洞。你不能全信,也不能不看。
与此同时,rsync 已经发展了近 30 年,测试体系却十分陈旧,自动化测试、代码覆盖率、持续集成等基础设施都需要重建。
于是,Andrew 选择借助 Claude。
不过,他后来专门回应了外界的质疑:Claude 写的绝大多数都是测试框架、测试用例和辅助代码,而核心设计、架构决策、代码审核和最终提交,始终由自己负责。
他说,自己会先完成整体设计,再把那些重复、繁琐的工作交给 AI。
最终发布的 rsync 3.4.3 中,确实出现了数百个带着 "tridge and claude" 签名的提交。
可当用户遇到 Bug,再打开 GitHub,发现是“tridge and claude”,这么重要的软件,Andrew竟然用AI写代码,竟然Vibe Coding,是可忍,孰不可忍!
于是,就出现了文章开头那一幕。
0 4
到底在害怕什么?
如今各大公司都在高调宣传“我们 xx% 的代码由 AI 生成”,而 Andrew 仅仅用 AI 辅助编写了测试,就招致如此猛烈的声讨。我想,原因无非两点:
1.Andrew的身份太特殊了。
rsync 是他写的,Samba 也是他写的。他是那种“活着的传奇工程师”,被视作传统工程精神的化身。
大家突然发现,连这样的人都开始用 Claude,心理落差可想而知。
2.Andrew 触碰了开源世界最敏感的那根神经。
很多开源开发者认为:编程不不仅仅是写代码,而是理解系统;
而 LLM 最大的问题恰恰是:它能写代码,但未必真正理解系统。
所以很多人天然反感用概率模型参与关键软件开发。
但是最深层的原因,我觉得大家其实在害怕未来。
那些大厂宣传“50%代码由 AI 生成”,我们反而没什么感觉,因为大家本来就把它当营销。
而Andrew不一样,现在很多人表面是在骂他,实际上是在表达一种焦虑:如果连 Andrew 这样的人都开始依赖 AI,那未来的软件工程会变成什么样?
特别声明:以上内容(如有图片或视频亦包括在内)为自媒体平台“网易号”用户上传并发布,本平台仅提供信息存储服务。
Notice: The content above (including the pictures and videos if any) is uploaded and posted by a user of NetEase Hao, which is a social media platform and only provides information storage services.