2026-03-10
计算机科学巨匠托尼·霍尔因快速排序、ALGOL、霍尔逻辑及通信顺序进程（CSP）等贡献闻名于世。文章通过吉姆·迈尔斯的个人视角，回顾了霍尔从学习古典学与俄语到进入计算机领域的传奇经历，并证实了关于快速排序“六便士赌约”的轶事。霍尔在晚年依然保持敏锐，他曾对电影中“天才”的刻画表示质疑，并对政府掌握的尖端技术持有一种神秘且深刻的见解。
社区讨论充满了对霍尔教授的崇敬与哀悼，网友们分享了他谦逊礼貌的个人轶事，并调侃了他自称的“十亿美元错误”（空引用）。部分讨论聚焦于死讯的真实性核实，指出当时主流媒体尚未报道，但作者凭借个人联系提供了第一手确认。此外，评论区还分享了大量关于霍尔职业生涯和学术成就的珍贵文献资源。
亚马逊近期针对由生成式AI辅助代码引发的系统故障召开了工程会议。为了降低风险，公司规定未来所有涉及AI生成的代码变更都必须经过资深工程师的审核与签字。这一政策反映了在追求AI开发效率的同时，如何确保生产环境稳定性的挑战。尽管管理层在推动AI工具的使用，但此次事件迫使公司重新评估AI在核心工程流程中的角色。
社区讨论指出，管理层强推AI工具与代码审核的高难度之间存在矛盾，认为审核AI生成的“看似正确”的代码极易导致疲劳。部分评论批评将责任推给工程师是不公平的，因为这是系统性激励问题。此外，有知情人士反驳称这只是亚马逊常规的每周运维会议，认为媒体过度渲染了事件的严重性。
EVi 项目基于 2024 年 1 月发布的 Vim v9.1.0 版本，是一个明确反对 AI 介入的硬分支。该项目在 Codeberg 上托管，其核心宗旨是“anti-slop”，即完全排除 AI 生成的代码、提交信息或相关内容。维护者在贡献指南中明确表示不会接受任何 AI 参与的贡献，试图以此保留原作者 Bram Moolenaar 时代的软件开发精神。
社区对此反应不一：有人批评此类分支多为政治表态，缺乏长期维护的动力；也有人指出 Vim 现状中 AI 生成内容的质量低下（如导致崩溃的补全菜单），认为这违背了 Bram 的初衷。讨论还涉及了维护者职业倦怠问题，部分用户建议应减缓开发节奏而非求助于 AI，同时也有人推荐转向 Neovim 以获取更现代的特性。
作者在开发 CSS 压缩工具 csskit 时发现，现代 CSS 颜色属性往往存在精度过高的问题。通过 Delta-E 颜色差异公式和“最小可觉差（JND）”标准进行测试，作者证明 OKLCH 颜色保留 3 位小数、LAB 保留 1 位小数已足够。虽然 2 位小数在静态下几乎不可察觉，但 3 位小数能更好地处理颜色计算中的累积误差，是兼顾文件体积与视觉一致性的最佳平衡点。
社区讨论氛围轻松且具有技术性，用户纷纷分享自己在颜色辨识测试中的得分。讨论指出，显示器硬件（如 OLED 与 LCD）和观察角度会显著影响颜色感知的准确性。此外，有评论补充道，由于人类对不同光谱的敏感度不同，以及 OKLAB 空间相对于 sRGB 的非线性特征，保留 3 位小数对于确保颜色在不同空间转换时的精确映射具有实际意义。
Ghostty 1.3.0 是一个历时六个月开发的重大更新，由 180 位贡献者共同完成。该版本新增了用户期待已久的回滚搜索、原生滚动条以及支持 OSC 133 协议的点击移动光标功能。此外，它还引入了强大的按键表和链式按键绑定系统，支持命令完成通知，并修复了涉及粘贴文本执行命令的安全漏洞 CVE-2026-26982。
社区对该版本反响热烈，用户普遍称赞回滚搜索和点击移动光标等功能极大地提升了易用性。讨论中还肯定了作者 Mitchell 的领导力及手工编写更新日志的诚意，并探讨了 Ghostty 在现代终端协议支持（如图像协议）方面的优势，而非仅仅追求极致速度。
作者通过彼得·诺尔的经典论文指出，编程的核心在于开发者大脑中构建的“理论”，而非仅仅是代码或文档。他引入詹姆斯·斯科特的“可读性”概念，认为大型机构倾向于将复杂的本地实践标准化以便监控和管理。文章强调，企业推行的敏捷开发等方法往往是为了让开发者成为可替换的零件，而真正的专业编程需要承认并保留那些“不可读”的深层设计洞察。
社区讨论普遍认同计算本质上是一个庞大的“可读性工程”，旨在将人类的直觉和经验转化为可管理的规则。评论指出，虽然企业为了可预测性牺牲了效率和深度，但加密技术等领域仍为保留“不可读性”提供了可能。此外，有观点认为官僚机构的本质是协调的正式化，而这种对可读性的追求往往会导致结果的平庸化。
作者在为 Fedora 移植 RISC-V 过程中发现，由于硬件性能受限（核心性能仅相当于 ARM Cortex-A55），编译 binutils 等包的时间是其他架构的数倍。为了缓解速度和内存压力，目前 RISC-V 构建禁用了 LTO，且开发者常被迫使用拥有 80 个核心的 QEMU 模拟环境来加速重型包的编译。作者强调，RISC-V 若要成为 Fedora 的主要架构，必须拥有可机架化管理且性能达标的服务器级硬件。
社区讨论整体呈现出对 RISC-V 现状的审慎与怀疑，认为目前市面上缺乏能与 x86 或 ARM 竞争的高性能工作站芯片。有评论尖锐指出 RISC-V 芯片大多仍处于低端树莓派水平，而支持者则寄希望于 Tenstorrent Atlantis 等即将推出的高性能开发平台来改善 CI 和日常使用体验。
作者指出 curl 和 libcurl 作为底层 C 组件，因不属于 npm 或 Go 等特定语言生态系统，常被 SBOM 生成器和扫描工具忽略。由于 curl 通常随操作系统分发或在编译时确定依赖，现有的依赖追踪工具（如 GitHub）严重低估了其真实使用量，甚至显示仅有一个项目依赖它。这种“生态系统缺失”导致在描述 CVE 或生成软件清单时，难以准确记录 curl 及其自身的复杂依赖关系。
社区讨论呈现出技术分析与质疑并存的态度。有评论指出 GitHub 等工具忽略了 dpkg 和 RPM 等传统系统级包管理器，导致追踪数据失真；同时有读者反驳称 PURL 规范其实早已包含 curl 示例，并非无法定义。此外，讨论还涉及了 PURL 方案尚未正式注册的合规性问题，以及依赖追踪应侧重于具体发行版而非抽象项目名称的观点。
本文对112个主流源码可用项目进行了调研，旨在梳理各项目对AI生成代码的政策及其实际应用现状。研究发现，超过60%的项目（如Linux、curl、MariaDB等）已经包含了AI辅助的提交内容。相比之下，NetBSD、GIMP、Zig和qemu等项目则采取了明确的禁止立场。作者表示该调查旨在客观呈现现状，而非对AI贡献的优劣做出评判。
社区讨论呈现出客观观察的态度，重点关注了不同项目在处理AI贡献时的差异。有评论补充提到Gentoo也已禁止AI贡献，但由于代码分布广泛，统计难度较大。讨论还涉及了识别AI辅助提交的挑战，以及项目在维护代码纯洁性与接受自动化工具之间的权衡。