我的征尘是星辰大海。。。
The dirt and dust from my pilgrimage forms oceans of stars...
-------当记忆的篇章变得零碎，当追忆的图片变得模糊，我们只能求助于数字存储的永恒的回忆
作者:黄教授
手机视频列表
无事不要生非
视频
音频
原始脚本
Curl 四年 Rust 重构半途而废，工程人该懂的不折腾法则。 知名网络工具 Curl 几乎是所有 Linux 开发者、运维人员日常离不开的基础库。 二十多年基于 C 语言打磨，稳定适配海量操作系统、嵌入式设备与各类老旧网络协议，常年极少爆发高危内存漏洞。 此前，在 ISRG 的资助下，一批同时精通 c REST 全栈网络协议的顶尖开发者投入重构工作，整整耗时四年，项目进度走到95%。 只差最后落地阶段，却被克罗核心维护团队全盘叫停，直接放弃完整 rust 重写方案，回归原有 c 代码主线维护。 这一件事在外行人看来十分费解。 投入数年人力，有专项资金扶持，开发进度近乎完工，为何说停就停？核心根源只有一个，整套重构。 自始至终不存在真实刚性的用户需求，完全是出于 Rust 内存安全更完美的技术执念开战，属于典型无意义折腾，大量顶尖人力与资金被白白消耗。 参与重构的都是行业稀缺复合型人才，既要吃透 CORO 堆积二十余年的历史兼容逻辑、各种冷门协议边界处理，又要熟练驾驭 Rust 所有权模型。 还要处理 c 与 Rust 交互的 FFI 兼容难题。 这类人才本可以投入到有实际业务价值、能解决真实痛点的项目中，4年时间足以产出大量落地成果。 可如今近乎全部付出，付诸东流，投入与回报严重失衡，堪称开源领域成本极高的反面教材。 站在一线工程落地视角，有一条所有人都该恪守的底线。 只要一套系统稳定可靠，线上长期无致命故障，用户没有明确升级诉求，就绝不主动大刀阔斧推倒重写。 成熟开发者日常工作永远有清晰优先级，优先修复线上真实故障，处理业务迭代需求，优化影响用户体验的核心短板。 剩余时间也都用于技术学习、个人休整，不会凭空消耗资源去改造一套运转正常的工具。 很多推动本次重构的 Rust 拥护者带有强烈的代码洁癖与完美主义，单纯认定 C 语言存在原生内存风险，并默认所有底层工具都应当替换为 Rust。 却忽略最关键的现实问题。 Corel 运营二十余年，使用者从未大规模反馈内存安全隐患，也没有大量用户呼吁重构。 团队复盘后也得出结论，想要解决少量现存内存隐患，低成本方案比比皆是。 常态化模糊测试、 s 二内存检测、静态代码扫描。 局部高危模块小范围迭代补丁，全部比全盘重写省时省力，风险更低。 同时也要客观区分岗位视角差异，专职安全审计。 安全合规岗的核心工作就是主动挖掘潜在漏洞，职责要求他们不断排查各类底层组件风险。 但普通开发运维的评判标准完全不同，不会为了理论上更安全，主动推翻经过长期验证的稳定架构。 二者立场不同，不能用安全感的标准要求所有工程项目盲目追求极致的技术完美。 即便有 ISRG 提供资金支持，看似不用项目组承担人力成本，也改变不了强扭的瓜不甜的本质。 资金只能覆盖短期开发。 却解决不了长期维护难题。 这套 REST 的重构版本上线后，需要持续同时掌握两门底层语言，全套网络协议的开发者长期跟进兼容。 修复跨语言交互新 bug 这类稀缺人力不可能长期稳定供给，Chrome 核心维护者最终否决该方案，正是预判到后续几十年维护成本将成为无法填补的无底洞。 整件事给所有工程从业者留下深刻教训。 技术先进不等于改造合理，脱离真实需求的重构，本质就是无意义内耗。 耗费四年顶尖人力，专项资助资金，项目走到95%仍被迫废弃，充分证明一个朴素道理。 当一套工具系统能够稳定正常工作时。 克制住技术完美主义的折腾欲，才是最务实、最节约资源的工程选择。
修正脚本
Curl 四年 Rust 重构半途而废，工程人该懂的不折腾法则。 知名网络工具 Curl 几乎是所有 Linux 开发者、运维人员日常离不开的基础库。 二十多年基于 C 语言打磨，稳定适配海量操作系统、嵌入式设备与各类老旧网络协议，常年极少爆发高危内存漏洞。 此前，在 ISRG 的资助下，一批同时精通 c Rust 全栈网络协议的顶尖开发者投入重构工作，整整耗时四年，项目进度走到95%。 只差最后落地阶段，却被Curl核心维护团队全盘叫停，直接放弃完整 rust 重写方案，回归原有 c 代码主线维护。 这一件事在外行人看来十分费解。 投入数年人力，有专项资金扶持，开发进度近乎完工，为何说停就停？核心根源只有一个，整套重构自始至终不存在真实刚性的用户需求，完全是出于 Rust 内存安全更完美的技术执念开战，属于典型无意义折腾，大量顶尖人力与资金被白白消耗。 参与重构的都是行业稀缺复合型人才，既要吃透 Curl 堆积二十余年的历史兼容逻辑、各种冷门协议边界处理，又要熟练驾驭 Rust 所有权模型。 还要处理 c 与 Rust 交互的 FFI 兼容难题。 这类人才本可以投入到有实际业务价值、能解决真实痛点的项目中，4年时间足以产出大量落地成果。 可如今近乎全部付出，付诸东流，投入与回报严重失衡，堪称开源领域成本极高的反面教材。 站在一线工程落地视角，有一条所有人都该恪守的底线。 只要一套系统稳定可靠，线上长期无致命故障，用户没有明确升级诉求，就绝不主动大刀阔斧推倒重写。 成熟开发者日常工作永远有清晰优先级，优先修复线上真实故障，处理业务迭代需求，优化影响用户体验的核心短板。 剩余时间也都用于技术学习、个人休整，不会凭空消耗资源去改造一套运转正常的工具。 很多推动本次重构的 Rust 拥护者带有强烈的代码洁癖与完美主义，单纯认定 C 语言存在原生内存风险，并默认所有底层工具都应当替换为 Rust。 却忽略最关键的现实问题。 Curl 运营二十余年，使用者从未大规模反馈内存安全隐患，也没有大量用户呼吁重构。 团队复盘后也得出结论，想要解决少量现存内存隐患，低成本方案比比皆是。 常态化模糊测试、 s 二内存检测、静态代码扫描。 局部高危模块小范围迭代补丁，全部比全盘重写省时省力，风险更低。 同时也要客观区分岗位视角差异，专职安全审计、安全合规岗的核心工作就是主动挖掘潜在漏洞，职责要求他们不断排查各类底层组件风险。 但普通开发运维的评判标准完全不同，不会为了理论上更安全，主动推翻经过长期验证的稳定架构。 二者立场不同，不能用安全感的标准要求所有工程项目盲目追求极致的技术完美。 即便有 ISRG 提供资金支持，看似不用项目组承担人力成本，也改变不了强扭的瓜不甜的本质。 资金只能覆盖短期开发。 却解决不了长期维护难题。 这套 Rust 的重构版本上线后，需要持续同时掌握两门底层语言，全套网络协议的开发者长期跟进兼容。 修复跨语言交互新 bug 这类稀缺人力不可能长期稳定供给，Chrome 核心维护者最终否决该方案，正是预判到后续几十年维护成本将成为无法填补的无底洞。 整件事给所有工程从业者留下深刻教训。 技术先进不等于改造合理，脱离真实需求的重构，本质就是无意义内耗。 耗费四年顶尖人力，专项资助资金，项目走到95%仍被迫废弃，充分证明一个朴素道理。 当一套工具系统能够稳定正常工作时，克制住技术完美主义的折腾欲，才是最务实、最节约资源的工程选择。
英文翻译
back to top