效率过度反而导致更糟结果：过拟合与古德哈特定律的强版本

本文探讨了一个反直觉的现象：追求效率有时反而会导致更差的结果，作者将这一普遍现象命名为古德哈特定律的强版本。核心论点是，这一现象在社会各领域广泛存在，并且与机器学习中的过拟合问题高度相似，理解二者的联系有助于分析和解决社会系统中的问题。

一、核心现象：效率与结果的悖论

古德哈特定律指出：“当一项指标成为目标时，它就不再是好的指标。” 其强版本进一步阐述：当对一项（代理）指标进行极其高效的优化时，它原本要衡量的真实目标不仅会停止改善，反而会急剧恶化，甚至比什么都不做更糟。

• 社会领域的例子：以标准化考试为例。最初目标是衡量教育质量，但当考试成绩被高效地用作评价学校和学生的核心目标后，教学重点会转向应试技巧，损害了广泛的教育成果。类似现象出现在科学研究（为发表论文而进行增量研究）、经济（资本主义下的贫富差距）、政治（领导者仅专注于操纵民意）等多个领域。
• 机器学习中的对应：在机器学习中，这被称为过拟合。我们使用与真实目标相关的代理目标（如训练集上的损失函数）来训练模型。初期，优化代理目标能改善真实目标（测试集性能）。但过度优化代理目标后，模型会记住训练数据中的噪声和细节，导致在未见过的新数据上表现急剧下降。

二、过度优化导致恶化的机制

1. 相似性耗尽：初期，代理目标与真实目标高度相关，优化代理能带动真实目标改善。
2. 拟合噪声与捷径：当代理目标被过度优化时，模型会开始拟合代理目标中与真实目标无关的部分（如训练数据中的噪声、表面的统计规律）。此时，代理目标持续变好，但真实目标停止改善。
3. 极端行为与恶化：进一步过度优化，模型为了极致地满足代理目标，会采取极端的、偏离正常模式的行为。这些行为在代理指标上得分极高，但严重损害了真实目标。在机器学习中，这表现为模型的表达能力与代理任务复杂度匹配时，最容易发生灾难性过拟合（见文中图示）。

三、缓解措施：从机器学习到社会系统

作者借鉴机器学习中缓解过拟合的技术，提出了应用于社会系统的潜在解决方案：

1. 改善代理目标与真实目标的对应：使代理指标更直接地反映真实目标。例如，改革法律和激励措施，使其更直接地鼓励符合最终目标的行为。
2. 添加正则化惩罚：为系统增加复杂性或摩擦，惩罚偏离“典型”或“常规”的行为，而非直接针对不良行为。例如：对电子邮件收取微量费用、实行累进税制、根据诉讼次数指数级收取法院费用。
3. 注入随机性/噪声：通过随机性削弱过度优化的可能性。例如：在招生或招聘中，对排名靠前的候选人采用概率性录取；在课堂上随机安排测验时间；在金融市场交易中加入随机延迟。
4. 早停止：监控一个能反映真实目标的“验证指标”，一旦其开始恶化，立即停止优化代理目标。例如：限制提案提交的准备时间、在股市波动过大时暂停交易、果断拆解破坏竞争的企业。
5. 限制或提升系统能力：
   • 限制能力：降低系统的优化能力，使其无法过度拟合代理目标。例如：限制竞选资金、限制特定类型公司的员工人数、限制AI模型的算力。
   • 提升能力：极大地提升系统能力，使其能在不损害真实目标的前提下完美优化代理目标（这是一种技术乐观主义路径，但可能带来伦理风险）。例如：实现完全透明（所有信息公开可查）、投资基础研究（如清洁能源）、开发极其复杂多样的金融工具。

四、总结与展望

古德哈特定律的强版本揭示了在代理目标上追求极致效率可能带来灾难性反效果的普遍规律。作者认为，随着AI技术带来的效率飞跃，这一现象将变得更加普遍和紧迫，可能同时引发大量难以预料的系统性风险。

文章最后呼吁跨学科研究，将机器学习中对过拟合的理论和实践理解，系统性地应用于经济学、政治学、管理学等领域，以寻找缓解社会系统中“过度优化”问题的新方法。

Go Web 开发笔记摘要

Go 1.22 路由改进

• 作者过去主要使用手动路由匹配（如通过 case 语句检查方法、路径和分段）。
• Go 1.22 标准库新增了更强大的路由支持，允许以更简洁的方式定义路由（如 mux.HandleFunc("DELETE /records/", handler)）。
• 路由可与中间件（如 requireLogin）结合使用，提升代码清晰度。

内置路由器的一个坑：尾部斜杠重定向

• 内置路由器会自动将不带尾部斜杠的请求（如 /records）重定向到带尾部斜杠的对应路由（如 /records/）。
• 这会导致 POST 请求重定向时丢失请求体（变为 GET 请求）。解决方案是使用无尾部斜杠的端点设计（如 POST /records）。

sqlc 自动生成数据库查询代码

• sqlc 工具可将 SQL 查询语句编译为对应的 Go 代码，避免了手动编写样板代码。
• 作者喜欢这种方式，因为它无需学习 ORM 的约定，直接编写所需 SQL 后查看生成代码即可调用。
• 该工具适用于小型项目，并支持使用 CASE 语句有条件地更新字段。

SQLite 优化建议

• 为数据库写入操作使用专用对象，并设置 db.SetMaxOpenConns(1) 以避免 SQLITE_BUSY 错误。
• 可考虑为读写操作使用不同的数据库对象以提高读取性能。
• 可将不会进行 JOIN 操作的表放在独立数据库中，以便独立连接。
• 其他建议（如谨慎使用 COUNT 查询、使用 STRICT 表）尚未实施。

Go 1.19 垃圾回收内存限制

• Go 垃圾回收器默认允许内存分配至当前堆大小的 2 倍，可能在低内存 VM（如 256MB/512MB）中导致 OOM（内存不足）错误。
• Go 1.19 引入 GOMEMLIMIT 环境变量，可设置内存限制（如 GOMEMLIMIT=250MiB），触发垃圾回收，减少 OOM 发生。
• 示例：设置后，应用程序被 OOM 杀死的情况减少。

使用 Go 开发网站的优势

• 部署简单：生成单个静态二进制文件，可嵌入静态资源（使用 embed 包），直接复制即可部署。
• 内置 Web 服务器：适合生产环境，易于置于反向代理（如 Caddy）后运行。
• 工具链易安装：通过包管理器（如 apt-get）安装 Go，使用 go build 构建项目。
• 开发简洁：核心为 Serve(w, r) 函数模式，net/http 在标准库中，无需第三方库即可开始。
• 系统语言特性：便于执行底层操作（如 ioctl）。
• 项目可维护性：即使项目搁置较长时间后，重复的样板代码也易于重新理解。相比之下，框架（如 Rails）可能更易遗忘。

尚未探索的领域

• HTML 模板渲染：常用 Vue 等前端框架，对 html/template 使用经验有限。
• 登录系统：未实现过真正的用户登录功能。
• CSRF 防护：未尝试实现。
• 这些安全敏感特性可能需要框架支持。

结语

• 近期 Go 版本的新功能（如 GOMEMLIMIT、路由增强）实用性强，作者认为应更关注发行说明。

SpaceX于上周六成功发射救援任务，旨在接回两名被困于国际空间站的宇航员。由于波音公司“星际客机”飞船在飞往空间站途中出现推进器故障和氦气泄漏等安全问题，美国宇航局（NASA）决定使其空船返回地球，将宇航员巴奇·威尔莫尔和苏尼·威廉姆斯暂时留在空间站。

此次SpaceX的“龙”飞船搭载了NASA宇航员尼克·黑格和俄罗斯宇航员亚历山大·戈尔布诺夫，飞船内特意预留了两个空座位用于返程。然而，由于NASA的空间站乘组通常每六个月轮换一次，该飞船预计要到明年二月底才会返回。届时，威尔莫尔和威廉姆斯在太空停留的时间将超过八个月，远超他们最初为波音首次载人飞行任务计划的一周。

为给被困宇航员腾出返程空间，NASA从本次任务中移除了原定的两名宇航员泽娜·卡德曼和斯蒂芬妮·威尔逊，并承诺她们将获得未来的飞行机会。任务指挥官黑格基于其经验及对发射紧急情况的处置能力而被任命。发射时，被困的两名宇航员通过实时连线观看了过程，威廉姆斯还欢呼“前进，龙飞船！”。她现已被提升为空间站指挥官。

此次发射因飓风“海伦”影响而推迟，是从卡纳维拉尔角太空军基地40号发射复合体进行的首次载人发射。SpaceX接管了该处旧的泰坦火箭发射台，主要用于卫星和货运发射，而载人任务以往从肯尼迪航天中心的相邻发射台执行，此次调整旨在提高灵活性。

事件凸显了波音在商业载人项目中的困境，其“星际客机”飞船多年来问题不断，此次事件后，公司防务和太空部门负责人已被替换。相反，SpaceX自2020年成功运送宇航员以来，已为NASA执行了10次载人飞行任务，一直处于领先地位。

FTC报告确认：商业监控已失控

美国联邦贸易委员会（FTC）的最新调查报告证实，大型科技公司正广泛收集并分享用户个人信息，以驱动其在线行为广告业务。这项针对Facebook、YouTube和X（原Twitter）等九家社交媒体和视频平台的四年调查，揭示了商业监控如何让消费者几乎丧失对隐私的控制。尽管各公司违规程度不同，但结论明确：企业将利润置于隐私之上。

报告的关键发现包括：

• 数据收集远超用户预期：公司不仅跟踪平台内活动，还监控其他网站和应用的数据，收集非用户信息，并从第三方数据经纪商购买数据。收集的个人信息极其详细，包括浏览历史、位置、人口统计信息乃至敏感兴趣（如“离婚支持”），属性类别从数千条到无法具体罗列不等。
• 与第三方毫无限制地共享数据：多数公司会向第三方分享用户信息，部分公司称无法列出所有数据接收方。已识别的接收方包括执法部门及国内外其他公司。大多数公司在共享数据前不对第三方进行审查，也未持续检查其数据使用是否合规，将用户置于重大隐私风险中。
• 消费者被蒙在鼓里：报告揭露数据收集、共享和使用过程缺乏透明度。数据追踪在幕后进行，用户难以知晓其隐私让渡程度。公司甚至跟踪非用户和跨网站活动，使得个人几乎无法避免被卷入监控网络。即使提供隐私控制选项，其效果也常不透明或无效，且部分公司未按要求删除用户数据。
• 监控式广告商业模式是根源：这些隐私侵犯并非偶然，而是在线行为广告商业模式的核心。企业通过收集海量数据构建用户画像以实现精准广告投放，这种盈利模式驱动其不断开发更侵入性的数据收集方法，内部政策不一致且不完善，导致企业必然优先考虑利润。
• 亟需立法行动：由于缺乏联邦隐私法，企业得以在几乎无保障的情况下收集和分享数十亿用户数据。报告强调自律机制已失败。为解决问题，文章呼吁联邦隐私立法，其核心应包括：
  1. 数据最小化与用户权利：禁止企业处理超出提供服务所必需的数据，并赋予用户访问、迁移、更正和删除其数据的权利。
  2. 禁止在线行为广告：从根本上解决商业监控问题。
  3. 强有力的执行与个人诉讼权：允许个人就隐私侵犯起诉企业，弥补政府执法资源的不足。

报告表明，使用网络服务不应意味着将个人信息拱手让人任其使用。目前，用户可借助Privacy Badger等工具拦截部分追踪技术，但此次调查揭示的商业监控规模要求必须采取重大的立法行动。

迁移至64位time_t的挑战

背景与紧迫性

使用32位time_t类型会导致在2038年后出现严重问题：应用程序将无法正确获取时间，文件操作（如stat()）也会失败。业界共识是必须将time_t改为64位类型。尽管一些发行版（如Debian）已完成迁移，但Gentoo等源码发行版面临更复杂的升级路径，因为这是破坏性的ABI变更——必须全面切换，无法逐步过渡。

核心问题：ABI不兼容

将32位类型替换为64位类型会导致严重的ABI不兼容，主要体现在：

1. 结构体布局变化：包含time_t的结构体，所有后续字段的偏移量都会改变。例如，struct stat在三种ABI下的大小不同（88、96、108字节）。
2. 函数参数传递错误：在栈传递参数的架构（如x86）上，混合使用不同time_t宽度的二进制文件会导致参数读取错误，可能引发安全漏洞。
3. 运行时破坏：若程序与使用不同time_t宽度的库链接，会导致未定义行为，如错误的时间值或内存越界访问。

历史参考：大文件支持（LFS）

类似地，LFS将off_t和ino_t从32位扩展到64位。但与time64不同，glibc为LFS提供了过渡API。time64要求必须同时启用LFS。

Gentoo的特殊挑战

作为源码发行版，Gentoo在升级时面临：

• 长时段的ABI混合期：系统在重建过程中会混合使用不兼容的库。
• 循环依赖风险：可能因工具链依赖而无法完成重建。
• 半成品系统风险：重建失败可能导致系统无法正常工作。

提议的解决方案

作者提出三种可能缓解问题的方法：

1. 更改平台元组（CHOST）

通过修改工具链标识的平台元组（如i686-pc-linux-gnu → i686-pc-linux-gnut64）来明确区分新旧ABI。此方案改动较小，主要需更新编译器配置。

2. 更改库目录（libdir）

将重建后的库安装到新目录（如libt64），而非覆盖原有lib目录。优势包括：

• 防止误链接不同ABI的库。
• 利用Portage的“保留库”特性，在应用重建前保留旧库，减少系统中断。
• 可选支持多ABI共存。

但此方案需要修改工具链，并确保所有软件正确遵循库目录设置。

3. 实施二进制级ABI区分

在ELF文件中添加标记，使链接器和动态加载器能阻止混合链接不同ABI的二进制文件。实现复杂，需多方协作，且需考虑用户可能希望禁用此检查以运行预编译软件。

预编译软件的困境

旧的预编译32位软件（特别是商业软件）将面临：

• ABI兼容性问题：可能无法与新的time64系统库链接。
• 2038年问题：届时所有32位程序将失效。可能的缓解方案包括使用faketime修改系统时间或运行在虚拟机中。

总结与展望

迁移至64位time_t对32位系统至关重要，但过程复杂。三种方案可部分独立实施：更改平台元组有助于区分构建目标；更改库目录能实现安全过渡；二进制区分则能防止意外混合。然而，所有方案均需大量工具链修改和跨项目协作。

作者在后续补充中修正了先前观点，指出仅靠更改库目录不足，必须配合二进制区分机制，确保动态加载器能根据ABI标记选择正确的库路径。这可能需要为所有time64二进制文件注入RPATH，或临时更改旧库的目录结构。这一过程仍处于探索阶段，面临诸多挑战。

文章摘要：Web Components 评价的平衡观点

文章背景
本文回应了Ryan Carniato与Cory LaViska关于“Web Components是否代表未来”的争论，作者（既是框架开发者也是Web Components实践者）试图超越对立，寻找共识。

性能争议的分析

• 作者承认Ryan Carniato关于Custom Elements性能开销的观点正确：若追求极致性能，减少DOM节点是关键，Web Components并非最优解。
• 但作者强调，软件开发需权衡多项因素（可维护性、安全性、可访问性等），性能并非唯一目标。例如，为可访问性渲染aria-*属性可能牺牲速度，但具有实际价值。
• 类比“速通游戏”，极致优化可能适用于特定场景（如资源受限环境），但普通项目常采用更简单的实现方式（如“组件即元素”），即使非最优。

标准化成本的探讨

• 作者不认同Ryan将支持Web Components视为“隐性负担”的观点。认为作为框架作者，适配Web Components（如检测props/attributes）是平台更新的正常工作，且得益于Web的向后兼容性，代码长期有效。
• 指出Web社区可自由选择是否采用Web Components：有人构建完整Web Components应用，有人仅嵌入部分，也有人完全不用，这种多样性是Web的常态。
• 标准确实会带来认知默认（如设计<slot>行为），但类似挑战存在于其他新API（如IntersectionObserver），开发者可自行决定是否采用。

共识与结论

• 作者完全同意Ryan的观点：Web Components并非万能，在服务端渲染、可访问性、互操作性等方面仍有局限，目前无法替代React、Solid等框架。
• 标题“Web Components Are Not the Future”可能引发误解，但核心观点合理：Web Components有其适用场景，但不应夸大其能力。
• 文章呼吁停止无谓争论，认为不同开发者面临不同约束（如企业级应用需长期兼容，而其他项目可能追求灵活性），Web的多样性正是其魅力所在。
• 最终立场：Web Components可能不是你的未来，但无关紧要，重要的是探索适合自身场景的方案，拥抱Web平台的多元可能性。

htmgo 是一个轻量级、纯 Go 框架，用于使用 Go 和 HTMX 构建交互式网站和 Web 应用程序。它通过结合 Go 的速度与简洁性以及 HTMX 的超媒体属性来添加交互性，全部封装在纯 Go 中，无需编写 JavaScript。框架将应用编译为单个可部署的二进制文件，简化部署过程。

核心功能包括：

• 可部署单二进制：所有内容编译成一个独立的可执行文件。
• 实时重载：在代码更改时自动重建 CSS、Go 文件、Ent 架构和路由。
• 自动注册：基于文件路径自动注册页面和部分组件。
• 内置 Tailwind CSS 支持：默认集成 Tailwind CSS，无需额外配置。
• 自定义 HTMX 扩展：提供扩展以减少常见任务的样板代码。

htmgo 可用于构建大多数 Web 应用程序，例如传统业务 CRUD 应用、博客、文档站点、面向消费者的网站和内部工具。更多关于何时使用超媒体的指导，可参考 htmx.org 的相关文档，用户也可查看提供的示例代码。

这篇文章详细介绍了作者对F-4“鬼怪”II战斗机上使用的三轴姿态指示器进行逆向工程的过程和发现。

指示器概述与背景

该姿态指示器通过一个内部旋转的球体，向飞行员直观展示飞机在三个轴向上的姿态：俯仰（机头上下）、滚转（机身左右倾斜）和偏航（航向/转向）。它是1960年代为高速机动飞行的F-4战斗机设计的核心仪表，区别于普通飞机仅显示俯仰和滚转的双轴人工地平仪。F-4曾是美国海军和空军的主力战斗机，产量超过5000架。

三轴旋转的机械实现

核心问题是球体如何在三个轴上旋转而不脱落。其解决方案是：

• 球体本身由两个空心半球壳组成，通过顶部和底部的“极点” 与内部机械装置连接。
• 内部装置通过一个滚转框架固定在仪表框架上，滚转电机驱动整个框架和内部装置旋转。
• 俯仰电机和偏航电机位于球体内部。俯仰电机使整个内部装置围绕水平（赤道）轴旋转。
• 偏航电机则通过一个垂直轴旋转，而两个半球壳体直接安装在此轴的顶端和底部。因此，偏航电机只旋转外壳，而承载电子元件的内部装置保持静止。
• 布线难题通过两组滑环解决：第一组处理滚转框架相对于仪表外壳的旋转连接；第二组处理滚转框架与内部球体装置之间俯仰轴的旋转连接。偏航轴因仅外壳旋转，无需滑环。

伺服控制系统原理

指示器由外部陀螺仪提供的信号驱动，每个轴（滚转、俯仰、偏航）均由一个独立的伺服回路控制：

1. 输入信号：来自陀螺仪的同步发送器，将角度转换为三线制400 Hz交流信号。
2. 误差检测：一个控制变压器接收输入信号，并与当前轴的角度物理位置进行比较，输出一个表示角度偏差的误差信号。
3. 执行机构：一个特殊的电机/测速计组件。误差信号经放大器后，驱动电机的控制绕组，使电机向减小误差的方向旋转。
4. 反馈与稳定：测速计产生与电机转速成比例的电压，作为负反馈引入放大器，以抑制超调和振荡，实现平滑精确的定位。

放大器组件

放大器组件安装在仪表背面，包含：

• 三块独立的放大器电路板，分别控制三个轴。
• 一块直流电源板和一个交流变压器。
• 每块放大器板的功能是根据输入的误差信号，生成驱动电机控制绕组的信号。电路使用晶体管和脉冲变压器，在400 Hz交流信号的每个半周期内，交替激活电机的不同控制绕组，从而控制旋转方向。测速信号也用于稳定环路。
• 文章提到存在两种不兼容的放大器版本，对应可能采用不同电机设计的后期型号。

俯仰微调机制

仪表右下角有一个俯仰微调旋钮，用于补偿飞机为达到迎角而略微抬头或低头飞行时，指示器仍能显示水平。其设计巧妙之处在于：

• 微调量会根据飞机的俯仰姿态自动淡出。这是通过一个由俯仰角控制的多区域电位器实现的。
• 当飞机处于平飞状态时，微调信号被完全应用；随着飞机爬升或俯冲，微调信号会逐渐减弱至零；当飞机倒飞时，微调信号甚至会反向。

结论

作者成功拆解、修复并驱动了这款复杂的机电仪表。它体现了1960年代航空电子技术的精密与巧妙，通过复杂的机械结构和模拟伺服系统实现了三维姿态显示。尽管现代战斗机已普遍采用“玻璃座舱”和数字化显示，但这类机械仪表仍具有独特的工程魅力和历史价值。该项目是与合作者共同完成的。

何时做你热爱的事

关于是否应该“追随热情”存在一些争论。实际上，这个问题无法用简单的“是”或“否”来回答。有时应该，有时则不该，但两者之间的界限非常复杂。要给出一个普遍答案，只能追溯其脉络。

当人们讨论这个问题时，通常隐含着一个“而非”的选择。在其他条件都相同的情况下，你为什么不去做最感兴趣的事呢？因此，提出这个问题本身就意味着其他条件并不相同，你必须在做最感兴趣的事和做其他事（比如收入最高的事）之间做出选择。

如果主要目标是赚钱，通常就无法负担只做自己最感兴趣的事。人们付钱让你做他们想要的事，而不是你想要的事。但有一个明显的例外：当你和他人的目标一致时。例如，如果你热爱足球且足够擅长，就能靠踢球获得高收入。当然，在足球这类情况下成功率很低，因为太多人也喜欢它。但这并不意味着你不该尝试，这取决于你的能力和努力程度。

当你拥有奇特品味时，成功率会更高：即你喜欢某个收入高且少有人喜欢的领域。例如，比尔·盖茨显然真正热爱经营软件公司。他不仅仅热爱编程（很多人也爱），他还热爱为客户编写软件。这确实是非常奇特的品味，但如果你有这种品味，沉溺其中便能获得巨大收益。

甚至有些人对赚钱本身有着真正的智力兴趣。这不同于单纯的贪婪。他们只是无法忽视事物的错误定价，并忍不住为此做些什么。对他们来说，这就像一个谜题。

这里存在一个极端案例，它彻底颠覆了前面的所有建议。如果你想赚取巨额财富——数亿甚至数十亿美元——那么做自己最感兴趣的事会非常有用。原因并非源于额外动力，而是赚取巨额财富的方式通常是创办一家初创公司，而追随兴趣是发现创业点子的绝佳途径。

许多（如果不是大多数）最大的初创公司最初都是创始人出于兴趣做的项目。苹果、谷歌和脸书都是如此开始的。为何这种模式如此常见？因为最好的想法往往是极端的异类，如果你刻意寻找赚钱之道，可能会忽略它们。而如果你年轻且擅长技术，你对“什么值得做”的潜意识直觉与“需要构建什么”高度一致。

因此，赚钱存在一个类似“中等智商峰值”的规律。如果不需要赚很多，你可以做最感兴趣的事；如果想成为中等富人，通常无法负担这样做；但如果你想成为超级富豪，且年轻、擅长技术，那么做最感兴趣的事又成了好主意。

如果你不确定自己想要什么？如果你既被赚钱吸引，又被某些工作吸引，但两者都不占主导？如何打破僵局？

关键在于理解这种僵局只是表面的。当你在追随兴趣和赚钱之间难以抉择时，从来不是因为你完全了解自己、了解所选工作的类型，且选项完美平衡。无法决定走哪条路几乎总是源于无知。实际上，你通常同时承受着三种无知：不知道什么让自己快乐，不知道各类工作的真实面貌，也不知道自己能做多好。

在某种程度上，这种无知情有可原。预测这些事情通常很难，甚至没人告诉你需要去预测。如果你有抱负，人们会告诉你应该上大学，这个建议本身没错，但通常到此为止。没人告诉你如何弄清楚该做什么，或者这件事有多难。

面对不确定性该怎么做？获取更多确定性。最好的方式可能是尝试做你感兴趣的事。这会让你获得更多关于你对它的兴趣程度、擅长程度以及它能提供多大抱负空间的信息。

不要等待。不要等到大学毕业才弄清楚该做什么。甚至不要等到大学期间的实习。你不一定需要一份做X的工作才能从事X；通常你可以自己以某种形式开始做它。而且，由于弄清楚该做什么可能需要数年时间，所以越早开始越好。

判断不同工作的一个有用技巧是观察你的同事会是什么样的人。你会变得像与你共事的人。你想变得像这些人吗？

事实上，不同工作的特质差异会被放大，因为其他所有人也面临和你相同的抉择。如果你主要因为收入高而选择某类工作，你会被其他出于同样原因选择它的人包围，这会使它比外表看起来更令人窒息。而如果你选择真正感兴趣的工作，你主要会被其他真正感兴趣的人包围，这会使它格外鼓舞人心。

面对不确定性时，你要做的另一件事是做出能抵御不确定性的选择。你越不确定该做什么，就越需要选择那些未来能给你更多选项的选项。我称之为“保持顺风”。例如，如果你不确定主修数学还是经济学，选择数学；数学相对于经济学是“顺风”的，因为以后从数学转到经济学会比从经济学转到数学更容易。

然而，有一种情况可以很容易地说出是否应该做最感兴趣的事：如果你想做出伟大的工作。这不是做出伟大工作的充分条件，但它是必要条件。

关于是否“追随热情”的建议存在大量选择偏见，原因就在于此。大多数此类建议来自著名成功人士，如果你问一个著名成功人士如何做到他们所做的事，大多数人会告诉你必须做自己最感兴趣的事。这实际上是正确的。

但这并不意味着这对每个人都是正确的建议。并非每个人都能或想要做出伟大的工作。但如果你确实想，那么“是否该做最感兴趣的事”这个复杂问题就变得简单了。答案是肯定的。伟大工作的根源是一种雄心勃勃的好奇心，这是无法制造的。

Text2CAD: 从文本提示生成序列化CAD设计

Text2CAD 是首个能够根据多层次文本描述生成参数化CAD设计的AI框架，支持从抽象的形状描述到详细的参数化指令。

核心贡献

• 新颖的数据标注流程：利用开源的大型语言模型（LLM，如Mixtral-50B）和视觉语言模型（VLM，如LlaVA-NeXT），为 DeepCAD 数据集标注了具有不同复杂度和参数细节的多层次文本提示。该流程分为两个阶段：第一阶段使用VLM生成形状描述，第二阶段使用LLM生成多层次文本注解。
• Text2CAD Transformer：提出一个基于端到端Transformer的自回归架构，能够从自然语言提示直接生成完整的CAD设计历史序列。给定文本提示 T 和已生成的CAD子序列 C_{1:t-1}，一个预训练的BERT编码器（附带可训练的自适应层）提取自适应特征 T_{adapt}，该特征随后与CAD序列嵌入 F^0_{t-1} 一同输入到解码器块中，以自回归方式逐步推导出后续的设计步骤。

评估方法

文章采用了两种策略来评估 Text2CAD 的性能：

1. CAD序列评估：通过针对直线、圆弧、圆和拉伸等元素的F1分数、衡量几何对齐程度的倒角距离（CD）以及衡量重建无效性的无效率（IR）进行定量评估。
2. 视觉检查：采用GPT-4评估和人类偏好评估进行定性分析。评估结果展示了在不同提示复杂度下，该方法相对于基线模型的胜率。

Feldera 增量计算引擎摘要

核心概述
Feldera 是一个用于增量计算的快速查询引擎，能够完全增量地评估任意 SQL 程序。相比传统的批处理引擎、数据仓库、流处理器或流式数据库，Feldera 在性能、表达能力和功能性上更具优势。

工作机制

• 管道由 SQL 表和视图组成，视图可深度嵌套。
• 用户通过启动、停止或暂停管道来管理计算进度。
• 管道持续处理变更（插入、更新或删除），仅针对变更数据增量更新视图，完全避免重新计算历史数据。
• 运行中可随时检查视图结果，实现离线与在线计算的统一。
• 性能卓越，在笔记本电脑上即可达到每秒数百万事件的处理速度。

主要特性

1. 完整 SQL 支持：唯一支持完全增量计算完整 SQL 语法和语义的引擎，包括连接、聚合、分组、关联子查询、窗口函数、复杂数据类型、时间序列操作、UDF 及递归查询。
2. 高性能开箱即用：用户可在 30 分钟内实现复杂用例，无需调优即可达到高性能。
3. 处理超大数据集：通过高效利用 NVMe 存储将数据溢出到磁盘，支持超过内存容量的数据集。
4. 强一致性与新鲜度保证：确保视图状态与批处理系统在相同输入下的查询结果完全一致。
5. 丰富的连接器：支持 Kafka、HTTP、CDC 流、S3、数据湖、仓库等多种数据源和目标。
6. 故障容错：可从崩溃中精确恢复，不丢失或重复输入/输出数据（需连接器支持）。
7. 无缝即席查询：支持对运行中或暂停的管道执行即席 SQL 查询，结果与增量引擎输出一致。

快速启动

• Docker 运行：通过 docker run 命令启动容器，访问 http://localhost:8080 使用 WebConsole。
• 源码运行：需安装 Rust 工具链、JDK 等依赖，构建 SQL 编译器后运行 Pipeline Manager。

文档与资源
提供入门指南、基础概念、教程、SQL 参考、API 参考及 Python SDK 文档。

理论基础
基于 DBSP 形式模型，定义了流操作符和查询的语义，并提供从查询自动生成高效增量数据流的算法，处理成本与输入规模成正比而非数据库总状态。

文章《Alan Kay on Messaging (1998)》的核心内容由于提供的实际文本部分仅为网站兼容性提示和一张动态图片（spin.gif），无法从中提取具体观点或论述。根据标题和作者背景，可推断文章可能涉及计算机科学先驱艾伦·凯（Alan Kay）对消息传递（Messaging）这一概念在面向对象编程或分布式系统中重要性的阐述，但具体内容需阅读原文才能准确总结。

Autossh - 自动重启SSH会话与隧道

版本与构建

• autossh 1.4版本采用autoconf构建系统，标准构建流程为：./configure、make、make install。
• 提供了autossh.host作为包装脚本示例。

核心功能 autossh是一个用于启动并监控一个ssh进程的程序，当该进程停止或停止传输流量时，会根据需要自动重启它。

工作原理（监控机制）

1. 传统方法（版本1.2起）：通过ssh建立转发循环（一个从本地到远程，一个从远程到本地），并发送测试数据并期望其返回。
2. 新方法（版本1.3起）：可指定一个远程回显服务端口（通常为7），由该服务返回测试数据，避免了转发循环带来的拥塞和端口冲突问题。此方法可选。
3. 禁用监控：使用-M 0参数将完全禁用端口监控。此时，autossh仅会在ssh进程退出时（无论原因为何）尝试重启。

主要参数与用法

autossh [-M <port>[:echo_port]] [-f] [SSH OPTIONS]

• -M <port>[:echo_port]：指定监控端口。
  • 若仅指定port，则使用port和port+1两个端口进行监控通信。
  • 若指定echo_port，则仅使用port与远程回显服务通信。
  • 设置为0可禁用监控。
• -f：使autossh在后台运行。此模式下ssh无法交互式输入密码。同时会将启动时间阈值（AUTOSSH_GATETIME）设为0。
• -V：显示版本并退出。
• 其他所有参数均直接传递给ssh程序。

行为规则 autossh会根据ssh子进程的退出方式采取不同行动：

• 正常退出（如用户输入exit）：autossh会自行退出，而不重启。
• 收到信号（SIGTERM, SIGINT, SIGKILL）：autossh会杀死子进程并退出。
• 收到SIGUSR1信号：autossh会杀死当前子进程并启动一个新的。
• 监控失败：默认每10分钟测试一次监控端口。若测试失败，autossh会杀死旧进程并启动新进程。
• 其他原因死亡：尝试启动新进程。

启动与失败处理

• 首次失败：如果ssh首次尝试就以退出状态1失败，autossh会认为存在语法或连接设置问题而直接退出。
• 启动时间阈值：默认30秒。若ssh进程在此时间内失败，autossh会认为连接未成功建立而退出。可通过环境变量AUTOSSH_GATETIME调整（设为0则禁用此行为和首次失败退出行为）。
• 连续失败退避：若重启连续快速失败，autossh会逐渐增加重试间隔，直至达到默认的轮询周期（通常10分钟）。可通过发送SIGHUP信号强制其立即重试。

连接设置要求

• 必须预先配置好SSH的自动认证机制（如使用ssh-agent和RSAAuthentication），因为连接需要无人值守建立。
• 在使用autossh之前，必须确保单独的SSH会话能够成功建立。

重要环境变量（摘要） autossh的许多高级行为通过环境变量控制：

• AUTOSSH_GATETIME：ssh连接被视为成功的最小存活时间（默认30秒，0则禁用）。
• AUTOSSH_POLL：监控轮询周期（默认600秒）。
• AUTOSSH_FIRST_POLL：首次轮询的延迟时间。
• AUTOSSH_MAXSTART：ssh最大重启次数（-1为无限制）。
• AUTOSSH_MAXLIFETIME：进程最大生存时间（秒）。
• AUTOSSH_PORT：覆盖-M参数指定的监控端口。
• AUTOSSH_PIDFILE：将autossh的PID写入指定文件。
• AUTOSSH_LOGFILE：指定日志文件（而非使用syslog）。
• AUTOSSH_DEBUG：启用调试级别日志。

有用的SSH选项（客户端）

• ExitOnForwardFailure=yes：确保在autossh认为连接建立时，端口转发也已成功建立。
• 服务端可配合ClientAliveInterval，以在客户端连接关闭时及时释放服务端资源。

日志记录

• autossh默认使用LOG_USER设施通过syslog记录日志。可能需要配置syslog（通常在/etc/syslog.conf中）以接收此设施的消息。

利用热力学缩放定律应对气候变化

核心提案

该研究提案提出了一种大规模生物质碳封存方案，核心思路是：利用农业生物质作物通过光合作用吸收并固定大气中的CO₂，随后在冬季利用环境低温冷冻这些水浸生物质，并依靠大体积系统的热力学特性在夏季保持其冰冻状态，从而将碳长期（百年尺度）封存在地表之上。关键在于，湿生物质的导热性远高于干燥生物质，而系统的巨大热容（源于冰的相变潜热）使其能在夏季抵御融化。

问题背景与现有方案局限

• 目标：大规模从大气中去除碳，以缓解气候变化。
• 现有技术局限：
  • 直接空气捕获：成本高昂（超过200美元/吨CO₂当量）。
  • 其他生物质封存方法（如深海掩埋、压缩成砖、矿物化、盐渍干燥储存）：分别存在监测困难、成本高、需特殊处理或需远距离运输等问题。
• 本方案优势：利用农业景观本身，无需对生物质进行干燥、盐渍或特殊化学处理，且便于监测和未来可能的碳源再利用。

工作原理与物理设计

1. 基本构造：建造大型生物质堆（如半球形），内部铺设平行且等间距的管道系统。
2. 季节性操作：
   • 冬季：打开管道，利用环境冷空气通过管道与生物质进行热交换，将其整体冷冻。
   • 其他季节：封闭管道，切断内部对流换热。在春季到来前，在堆体表面覆盖一层干燥生物质作为额外隔热层。
3. 关键物理依据：
   • 热交换面积与热容的缩放定律：对于半径为 r 的堆体，外部表面积 ∝ r²，而总热容 ∝ r³。因此，体积越大，储存的热量越多，融化越缓慢。
   • 热惯性：生物质空隙中水的相变潜热巨大（如一个大型堆体的潜热可超过其占地面积年接收太阳辐射能量的2倍）。
   • 可控的热交换：内部管道网络提供了可控的内部换热面积（γ比例），冬季开启可高效散热，夏季关闭可极大减缓热量输入。
   • 生物化学抑制：低温与厌氧条件共同作用，能大幅降低微生物呼吸和有机物分解速率，从而阻止碳重新释放。

可行性论证

• 生物学可行性：
  • 证据：永久冻土储存了约17亿吨碳；实验室研究表明，在接近冰点（-0.5°C）时，土壤碳排放率仅为14°C时的3-10%；更低温度（-14°C）下排放率更低。
  • 优势：本设计的厌氧环境预计能进一步抑制有氧呼吸。短期内实验室数据可能高估长期排放，因为易分解碳源会被耗尽。
• 热力学可行性（建模）：
  • 以一个半径为100米的半球堆体为例（可储存约5.8×10⁷ kg CO₂当量），其冰的潜热巨大。
  • 通过调整管道半径（r_p）和间距（δ），可优化内部与外部换热面积比γ，实现夏季隔热和冬季高效冷冻。
  • 估算显示，利用冬季风速差驱动的管道气流，单根管道可提供可观的热交换功率。通过多冬季分层建造或增加管道数量，可以实现整个堆体的冻结。
• 外部隔热：在堆体表面覆盖数米厚的干燥生物质层，可提供显著热阻（R值约80），其导热系数远低于冰，能有效减缓夏季热量传入。

经济性评估

• 成本构成：主要参考类似研究的农业生物质成本（土地、种植、养护），合计约38美元/吨CO₂当量。
• 额外成本：主要包括PVC管道材料（约7美元/吨CO₂当量）和季节性开关管道的人工成本（可忽略）。
• 总计：预计总成本约为45美元/吨CO₂当量，具有潜在竞争力。
• 根本局限：全球年排放约400亿吨CO₂，按6吨/英亩产量计算，需要60亿公顷耕地，远超全球14亿公顷的可用耕地。因此，该方案无法单独解决全球排放，但可作为综合策略的一部分。

待研究与验证的下一步

1. 实验室实验：在控制条件下，测量不同生物质（如柳枝稷、芒草）在多种温度、含水量和碎片大小下的代谢活性。
2. 野外试验：进行小规模（r≈10米）实地试验，安装管道系统，验证隔热、热容和融化速率等关键假设。
3. 数值模拟：
   • 模拟不同管道布局和密度下的热交换速率。
   • 使用多年代表性气候数据（气温、太阳辐射、风速）对简化系统进行长期模拟。

Varlink 是一种接口描述格式和协议，旨在以最简单可行的方式使服务对人类和机器都可访问。它结合了传统的 UNIX 命令行选项、标准 I/O 文本格式、手册页和服务元数据，并通过单个文件描述符（称为 "FD3"）提供等效功能。

核心特性

• 接口描述：接口采用反向域名命名，并定义了可调用的方法。每个方法具有命名且类型化的输入和输出参数。复杂类型可通过 type 关键字创建别名以提高可读性。接口还定义了方法调用可能返回的错误。所有内容都可以通过注释进行文档化。
• 协议：所有消息均编码为 JSON 对象，并以单个 NUL 字节终止。服务按接收顺序响应请求（不支持消息多路复用），但支持请求管道化以简化客户端状态跟踪。支持单次请求-响应、订阅、流式传输等多种调用模式。
• 服务与地址：每个 Varlink 服务都提供 org.varlink.service 接口，用于描述自身及其提供的所有接口。服务通过 URI 格式的地址表示，支持 TCP、UNIX 套接字、设备节点等多种传输类型。
• 激活：服务启动时可通过环境变量（LISTEN_FDS, LISTEN_PID, LISTEN_FDNAMES）接收监听 socket（即 FD3）。服务激活器通常传递 --varlink=ADDRESS 选项以告知服务监听地址。
• 解析器：公共 Varlink 接口通过系统范围的解析器（默认位于 /run/org.varlink.resolver）注册。解析器将给定的接口名称解析为提供该接口的服务地址。
• 桥接器：Varlink 命令行工具支持桥接模式，可将单个连接桥接到解析器及其注册的服务。通过 SSH 使用时，可将本地服务的接口呈现给远程客户端，如同在远程本地运行一样。

英国政府收购半导体工厂以强化国防供应链

英国政府已收购位于达勒姆郡牛顿艾克利夫的一家半导体工厂，旨在加强国防供应链并支持武装部队。该工厂是英国唯一具备安全资质生产砷化镓半导体的设施，此类半导体是战斗机等军事平台的关键组件。

国防大臣约翰·希利视察了该工厂。该厂原属相干公司（Coherent Inc.），现更名为Octric Semiconductors UK。此次收购预计将保障英格兰东北部多达100个高技能岗位，并巩固英国国防基础设施的关键部分。

政府表示，半导体是当今所依赖技术的前沿，对未来军事能力至关重要。此次收购表明政府将支持英国国防生产，致力于保护并发展英国国防供应链，支持东北地区就业，保障武装部队的关键技术，并提升国家安全。

半导体是现代电子产品（从电话、计算机到军事应用）不可或缺的组成部分。政府称，此次收购将增强英国的国防能力并提高其工业产能，计划在未来几年对该工厂进一步投资。

此次收购紧随一场投资峰会举行，该峰会旨在加强英国贸易关系并支持国内高质量就业。随着全球半导体需求上升，此举使英国能够满足未来的技术需求，包括人工智能、量子技术和6G领域的进展。

背景信息：2023年，该工厂原所有者相干公司因业务需求下降宣布裁员超过100人，工厂前景堪忧。自1991年开业以来，该厂多次易主，引发外界对其能否继续生产国防和航空航天等行业所需关键半导体组件的担忧。此次政府收购是保障该重要设施未来的关键举措，通过介入保护了就业，确保了用于军事应用（如提升战斗机性能）的重要半导体生产，不仅稳定了工厂去年面临的不确定性，也加强了英国在国防领域保持关键技术控制的能力。

iceoryx2 v0.4.0 发布，这是一款为 Rust、C++ 和 C 设计的高性能服务化进程间通信（IPC）库，旨在实现进程间尽可能快速的通信，速度远超传统方案如 Unix 域套接字或消息队列。该库支持循环缓冲区、历史记录、事件通知、发布-订阅消息传递等高级功能，并采用无需中心代理的去中心化架构。

相比前代产品 iceoryx，iceoryx2 具有多项新一代特性：

• 无需中央守护进程（如 RouDi）。
• 通过更高效的新架构，速度提升高达10倍。
• 动态性更强，无需编译时内存池配置。
• 提供高级服务质量（QoS）设置。
• 极高的模块化程度，每个组件均可定制，未来可支持 GPU、FPGA 等。
• 完全去中心化且更加健壮。
• 重构的 API 和资源管理系统，为未来实现真正的零拷贝通信和零信任策略奠定基础。
• 提供 C 和 C++ 语言绑定，并原生支持 CMake 和 Bazel；Python 等其他语言绑定即将推出。
• 计划未来增加网关，支持通过 zenoh、DDS、MQTT 等协议进行网络通信。

在 v0.4.0 版本中，延迟在部分平台上可低于 100 纳秒。主要更新亮点包括：

• 新增 C 和 C++ 语言绑定，并提供了新的示例。
• 推出了新网站（iceoryx2.readthedocs.io），提供详细的 IPC、真正零拷贝及 iceoryx2 介绍。
• 新构建系统支持：C/C++ 绑定支持 Bazel、CMake 以及 colcon（正在开发 iceoryx2_rmw）。
• 引入 iceoryx2 nodes 作为管理进程本地资源的核心实体，可监控进程，并在进程崩溃时自动清理资源。
• 提供命令行调试与自检工具 iox2。
• 实现运行时大小的服务，克服了 iceoryx1 的编译时内存配置限制。
• 提供高级服务与端口配置，支持自定义对齐（如用于 SIMD 或 FPGA）。
• 支持用户定义的服务属性（自定义键值对）。
• 支持冰块2域，可将进程分组以避免相互干扰。
• 支持自定义用户头部。
• 新增 32 位系统支持，长期目标是实现 32 位与 64 位进程间的混合零拷贝通信。
• 为 iceoryx2-bb-containers 提供放置新（placement new）机制，支持内存借用与原地初始化。

此外，文章预告了即将推出的“任务控制中心”，该工具将提供深入的系统自检与调试功能，可实时监控进程的 CPU、内存和 I/O 负载，查看消息频率与内容，检查节点及其运行的服务，并可视化连接关系。

未来开发计划包括：

• 完善 C/C++ 语言绑定。
• 实现事件多路复用，扩展 Node::wait() 功能。
• 提供动态负载服务，无需为带切片的服务定义固定负载大小。
• 加强健康监控，当发送方或接收方失效时主动通知进程。
• 扩展文档，提供更详细的介绍和教程。

文章标题：Notes on the Crystal Language

内容摘要

提供的内容显示，用户尝试访问标题为“Notes on the Crystal Language”的文章时，服务器返回了访问被拒绝的错误。错误代码为559e7f01707b78efda8b0ed791e13d0e0079fbf0e3c81c8dfaf2299537f8b666，页面包含一个Sad Anubis的图像和返回主页的链接（/）。没有提供关于Crystal语言的实际文章内容。

Quandoom：《DOOM》的量子计算机移植版

该项目被称为Quandoom，是经典游戏《DOOM》第一关的一个量子计算机移植版本。尽管当前尚无实际量子计算机能够运行它，但该量子电路可在经典计算机上高效模拟运行（笔记本电脑上可达10-20帧）。

技术实现

• 量子电路包含7万个量子比特和8000万个量子门。
• 提供了一个轻量级的C++模拟器（约150行代码）用于在经典计算机上模拟量子电路。
• 电路生成代码和相关论文（arXiv）已公开。

游戏运行循环

1. 用户按键设定一个输入量子比特的值。
2. 应用整个量子门电路。
3. 测量最后64,000个量子比特，并将其显示为320×200像素的黑白屏幕。
4. 重置屏幕和输入量子比特，重复过程。

如何游玩

• 游戏需要5-6GB内存，加载时间较长。
• 下载对应系统的版本并解压后，在Linux或Windows上直接使用模拟器运行电路文件。

与原版《DOOM》的主要区别

• 仅包含第一关。
• 画面呈黑白X光效果（由于可逆计算限制）。
• 无颜色、无声音/音乐。
• 敌人不能跨房间移动。
• 地狱火球改为命中扫描而非投射物。
• 为适应量子计算，对护甲/生命值/伤害进行了微调。

编译模拟器

提供了在Linux和macOS上从源码编译模拟器的详细步骤，依赖SDL2和OpenMP库。

法律声明

该项目是非商业开源项目，仅为“万物皆可运行DOOM”网络梗的玩笑/戏仿之作。《DOOM》及其相关资产属于Id Software的知识产权，作者建议玩家下载官方共享版游玩。

文章总结：序列化访问是Elixir处理可变性的关键

Elixir的核心特性之一是不可变性，但这需要理解其与“可变性”的区别。文章通过与JavaScript的对比，阐释了Elixir中变量重绑定与真正内存突变的差异，并揭示了Elixir管理可变状态的秘密机制。

1. 不可变性与变量重绑定

• JavaScript中的可变性：变量引用或对象值可以直接在内存中被修改，其他代码可能随时观察到这种变化，导致意外的副作用和竞争条件。
• Elixir中的不可变性：值一旦创建就不会改变。变量赋值实际上是创建新的绑定，而非修改原有值。这提高了代码的可预测性，函数无法修改传入参数的原始状态。

2. Elixir中的可变状态：以进程和序列化访问为核心

虽然Elixir的值是不可变的，但系统中存在可变状态。Elixir通过两个关键机制管理：

• 函数调用作为观察突变的唯一途径：任何状态变化（如进程字典的修改）都只能通过函数调用（如Process.get）来观察，确保了显式性。
• 通过进程的序列化访问：每个进程拥有独立的堆栈和堆，并顺序处理其邮箱中的消息。这消除了并发竞争条件——进程内的状态修改是序列化的，无法被其他进程直接干扰。

3. 优势：可预测性与安全性

• 通过强制状态突变通过进程邮箱序列化，并限制对突变状态的观察仅限于函数调用，Elixir程序更易于理解且行为更可预测。
• 避免了JavaScript中常见的因异步操作或共享可变对象导致的难以调试的问题。
• 这种设计不仅提升了代码的清晰度，也为应用的可扩展性和故障优雅处理奠定了基础。

总之，Elixir通过不可变值、进程隔离和序列化消息处理，实现了安全、可预测的状态管理，这是其区别于传统可变语言的核心优势。

论文摘要：《不计算的核心》

问题定义： 论文指出了现代CPU中存在一类被称为“水银核心”的缺陷核心。这些核心会因制造缺陷或老化，在特定条件下产生静默的计算错误。与传统的硬件故障不同，这类错误通常不会触发任何告警或异常，而是直接输出错误的计算结果，因此极具隐蔽性和危害性。

现象与影响：

• 静默计算错误： 这类错误的唯一症状是计算结果错误，可能导致数据损坏、加密失效、数据库索引损坏、文件系统丢失等严重后果。
• 罕见但显著： 在大规模服务器集群中，这类缺陷虽罕见（每数千台机器中可能出现几个），但影响显著，已引起工程团队投入大量资源进行应对。
• 条件依赖性： 错误的发生通常与特定指令、工作负载、工作频率、电压和温度条件相关，且可能随核心老化而恶化。
• 根本原因： 主要归因于芯片特征尺寸缩小、架构复杂度增加，以及制造后潜伏性缺陷。传统的制造测试难以覆盖所有缺陷场景。

检测与隔离挑战：

• 检测困难： 检测这类静默错误在概念上需要冗余计算（如运行两次进行比对），开销较大。且错误表现非确定性，难以复现。
• 多重维度： 检测方法可按多个维度分类：自动化与人工筛查、部署前与部署后筛查、离线与在线筛查、基础设施级与应用级筛查。
• 隔离措施： 一旦检测出可疑核心，可将其从资源池中隔离。更精细的方法是避免在该核心上运行关键计算任务。

缓解策略与未来方向：

• 软件层面： 可探索端到端检查、高效检查点恢复、应用特定的冗余计算（如三模冗余）以及编译器驱动的自动计算复制等方法。论文建议利用应用层已有的数据完整性检查（如校验和）来同时检测硬件错误。
• 硬件协同： 根本解决需要硬件设计者与系统软件研究者合作，改进硬件的可测试性、内置持续验证功能，并设计更容错的执行单元。
• 研究机遇： 论文呼吁系统研究社区关注此问题，包括开发新的检测方法、创建故障注入仿真环境、设计对静默错误具有韧性的算法和系统架构，并将研究范围扩展到GPU、ML加速器等其他计算单元。

核心观点： 论文挑战了传统上将CPU核心视为“故障即停”的假设。随着硬件发展，系统设计必须正视“静默计算错误”这一现实，并通过软硬件协同设计，构建能够检测、隔离并容忍此类错误的韧性系统。

Dart REPL (interactive) 项目摘要

项目简介

本项目为 Dart 语言提供了一个功能齐全的 REPL（交互式 Shell），旨在填补 Dart 缺乏原生交互式环境的空白，帮助开发者更高效地进行日常代码测试、调试与探索。

核心功能

• 第三方包支持：允许在 REPL 中通过 !dart pub add <package> 命令直接添加并自由使用第三方依赖。
• 自动热重载与状态保留：支持代码任意位置的自动热重载，且在重载过程中完美保留当前运行状态。
• 完整语法支持：支持 Dart 的完整语法特性，包括表达式、语句、函数与类的定义及重定义，并支持多行代码输入。
• 现有项目集成：可通过 --directory 参数指定项目路径，在现有项目环境中运行，直接调用项目代码及其所有依赖。
• 系统命令执行：支持使用 ! 前缀直接执行底层 Shell 命令（如 !whoami、!date）。
• 灵活的导入机制：支持内置包（如 dart:math）和第三方包的导入，支持单行多语句执行。

安装与使用

• 安装：通过 Dart 全局包管理命令安装：dart pub global activate interactive。
• 使用：在终端直接输入 interactive 启动；若需结合现有项目，使用 interactive --directory <项目路径>。

实现原理

• 执行环境：创建一个空白包和 Isolate 作为底层执行工作区。
• 代码合成与热重载：利用 analyzer 提取并处理导入、类、函数等元素（同名替换），合成一个完整的 Dart 文件。文件更新后触发 Dart VM 的热重载机制。
• 全局变量处理：将全局变量实现为 dynamic 扩展（Extension）中的字段变量，或将函数转换为扩展方法，并为类合成 getter/setter，从而实现对全局变量的无缝访问。
• 精准评估：仅让 Dart VM 服务评估生成的 generatedMethod()，避免过度评估。

已知问题

• Windows 终端兼容性：受限于 Dart SDK 的已知 Bug，在 Windows 非 WSL 终端下，退格键、方向键移动及命令历史功能失效，强烈建议在 WSL 或类 Unix 环境下使用。
• 历史记录不持久：命令历史目前无法跨会话保存。
• 错误提示不准确：部分用户错误会触发“Hot reload failed”警告而非具体的错误信息，可能导致后续命令执行失败，此时通常需要重启 REPL。