OpenAI员工离职风波：为何前员工保持沉默？

2024年5月，OpenAI发布了新产品ChatGPT 4o，但此举被公司联合创始人兼首席科学家伊利亚·苏茨克韦尔以及超对齐团队联合负责人简·莱克的离职事件所掩盖。他们的离职引发了广泛猜测，但最引人关注的是前员工的集体沉默。

离职与沉默 苏茨克韦尔的离职声明较为常规，而莱克最初仅表示“我辞职了”。几天后，他才补充解释称，担忧OpenAI已偏离安全导向的文化。外界对离职原因众说纷纭，包括是否与公司内部项目、去年的CEO罢免风波有关，但缺乏当事人的直接回应。

严格的离职协议 据报道，沉默的主要原因在于OpenAI前员工签署的极其严格的离职协议。该协议包含终身保密和不贬低条款，禁止前员工批评公司，甚至禁止承认协议的存在。若拒绝签署或违反协议，员工可能会失去已归属的股权，这些股权价值可能高达数百万美元。前员工丹尼尔·科科塔伊洛证实，他为了在未签署协议的情况下离职，放弃了可能价值不菲的股权。

公司回应与政策变更 OpenAI最初未回应置评请求。发布后，公司发言人声明“从未取消任何当前或前员工的已归属股权”，并称这反映了“现实”。消息人士认为这代表了政策转变。随后，CEO萨姆·奥特曼在推文中承认，离职文件中曾存在关于“潜在股权取消”的条款，但表示公司正在修改相关措辞。

理想与现实的矛盾 这一情况与OpenAI最初宣扬的开放、透明和负责任的使命形成讽刺对比。公司早已放弃开源模型，如今又失去了安全团队的核心成员，这让人对其“安全”理由的可信度产生怀疑。

OpenAI的使命是确保通用人工智能（AGI）造福全人类，并曾强调外部监督和减速发展的可能性。其独特的非营利控股结构也被设计为增强问责制。然而，超对齐团队领导人的离职强烈暗示公司对安全工作的兴趣可能已减弱，且未明确继任者。

结论 OpenAI声称致力于以透明方式变革世界并欢迎全球参与，但通过限制性离职协议使知情最多的前员工无法发声，这表明其对外部监督的承诺可能并不彻底。公司的网站宣扬高尚理念，但离职协议充满强硬法律条款。当涉及巨大利益时，这种矛盾显得尤为突出。

文章摘要

根据提供的信息，文章标题为《前OpenAI员工必须签署终身不批评协议，否则将失去全部股权》。然而，在尝试获取文章正文内容时，系统显示错误信息，提示“出现问题，请重试”，并指出某些隐私相关扩展可能导致在x.com上出现问题，建议禁用扩展后重试。

因此，目前无法获取该文章的完整内容，只能确认其标题所暗示的主题：OpenAI似乎要求其离职员工签署一项终身不得批评公司的协议，否则将面临丧失所有股权（可能是公司期权或股份）的后果。

由于正文内容因技术原因未能成功加载，无法提供关于该政策具体细节、生效时间、涉及范围、法律背景或相关各方回应的进一步信息。

Gio UI – Go 语言的跨平台 GUI 库

项目概述

Gio 是一个用于在 Go 语言中编写跨平台即时模式图形用户界面的库。它支持所有主流平台，包括 Linux、macOS、Windows、Android、iOS、FreeBSD、OpenBSD 以及 WebAssembly。

核心特点与优势

Gio 旨在帮助 Go 开发者构建高效、流畅且可移植的 GUI 应用程序。

• 跨平台一致性：结合了前沿的 2D 图形技术与即时模式图形范式的灵活性，为应用开发提供强大且一致的基础。
• 高效矢量渲染：包含一个基于 Pathfinder 项目的高效矢量渲染器，并正迁移至基于 piet-gpu 的更高效计算着色器渲染器。文本和形状仅通过轮廓渲染，无需烘焙为纹理图像，从而支持高效动画、变换绘制和像素分辨率独立性。

平台与依赖

Gio 设计为依赖极少，仅依赖各平台用于窗口管理、输入和 GPU 绘图的原生库。项目提供了详细的安装依赖说明。

快速开始

1. 安装：按照官方指南安装必要依赖。
2. 学习：前往 “Learn” 部分获取入门资源。
3. 示例：项目提供了一个 WebAssembly 演示（需支持 WebAssembly 的浏览器）以及 “Kitchen” 项目的源码作为参考。

资金支持

Gio 的开发由赞助支持。项目方呼吁，如果用户觉得 Gio 有用，可以考虑通过 OpenCollective 或直接赞助其开发者。

Experts.js：使用OpenAI助手API构建多AI智能体系统

Experts.js是一个JavaScript框架，旨在简化OpenAI新推出的Assistants API的使用，并允许将多个助手链接为工具，从而构建具备扩展记忆和精细注意力的“专家小组”多智能体系统。

核心概念与功能

1. 核心组件

• Assistant（助手）：代表一个AI智能体。可以通过ES6类继承或静态create()方法创建，支持配置指令、模型（默认为gpt-4o-mini）、工具等。
• Tool（工具）：本质上是Assistant的子类，可作为其他助手或工具的专用能力模块。这是构建分层、协作的多智能体系统的核心。
• Thread（线程）：代表一个受管理的上下文窗口（记忆），用于存储对话消息和文件。

2. 简化工作流

• ask() 接口：向助手提问的核心方法，只需提供消息和线程ID，框架自动管理Run对象及其生命周期，极大简化开发。
• 助手即工具：通过addAssistantTool()方法，可将一个Assistant实例添加为另一个助手的工具，实现能力组合与任务委派。

3. 线程管理 框架自动为每个Tool创建和管理独立的线程，避免父级助手线程被锁定的问题。助手通过线程元数据维护父子线程关系。

4. 流式与事件 默认使用流式事件（如textDelta, toolCallDone等）实现实时输出。支持同步和异步事件监听器，以便在运行周期的不同阶段执行自定义逻辑。

5. 工具（Tool）的进阶用法

• 非LLM工具：设置llm: false并实现自定义ask()函数，用于集成传统代码逻辑。
• 输出控制：通过answered()钩子函数，可以截获LLM输出并执行额外操作（如执行数据库查询）后再返回最终结果。也可配置outputs: "tools"将子工具的输出作为父级工具的输出。

6. 高级特性

• 生命周期钩子：beforeInit()和afterInit()用于在助手创建前后执行自定义逻辑。
• 运行配置：可在构造函数中通过run_options全局配置，或在单次ask()调用中通过选项局部配置运行参数。
• 向量存储：通过tool_resources配置，可轻松集成OpenAI的向量存储进行文件搜索。

部署与开发

• 生产部署：推荐在构造函数中传入固定助手ID（id: "asst_..."），确保环境一致性。本地配置会覆盖远程配置。
• 环境变量：支持通过EXPERTS_DEFAULT_MODEL全局设置默认模型，DEBUG=1开启详细日志。
• 开发容器：项目支持Dev Containers，便于快速搭建开发环境。
• 示例：文章提供了产品目录查询、Express流式传输、图像消息处理等具体示例代码。

总结

Experts.js通过封装OpenAI Assistants API的复杂性，并引入“助手即工具”的范式，为开发者提供了一个简洁、强大的框架来构建模块化、可扩展的多AI智能体应用，支持流式交互、复杂编排和生产就绪的部署。

Sierra On-Line 被会计欺诈“谋杀”的始末

一、公司创立与辉煌

Sierra On-Line 由 肯·威廉姆斯 于1979年创立，最初是一家电信咨询公司。其妻子 罗伯塔·威廉姆斯 创作的《神秘屋》和《国王密使》系列游戏，定义了公司作为冒险游戏先驱的地位。公司陆续推出了《太空冒险》、《警察故事》、《幻想空间》等成功系列，成为20世纪80-90年代最具影响力的游戏开发商之一。肯是一位具有远见的商人，积极推动技术革新（如声卡、光驱）和业务扩张（如尝试建立在线社交网络），并视微软和迪士尼为主要竞争对手。

二、被CUC收购的交易

1990年代初，沃尔特·福布斯 作为Sierra董事会成员，提议由他领导的优惠券公司 CUC 收购Sierra。尽管公司内部（包括罗伯塔和高管团队）强烈反对，但肯出于以下原因最终同意：

• 股东压力与财务利益：交易条件（1.225股CUC股换1股Sierra股）为股东和员工（包括威廉姆斯夫妇）提供了巨额溢价。
• 公司发展需求：CUC承诺提供资金和资源，助力Sierra在线业务的扩张。
• 个人疲惫与信任：肯在长期经营压力下感到疲倦，且被福布斯描绘的互联网未来愿景和其个人魅力所吸引。
• 受托责任：董事会认为有义务接受这份对股东极其有利的报价。

1996年7月，交易完成，Sierra成为CUC软件部门的一部分。

三、合并后的冲突与欺诈暴露

收购完成后，问题迅速出现：

1. 管理权争夺：福布斯未兑现关于成立联合管理机构的承诺，导致 鲍勃·戴维森（CUC已收购的教育软件公司负责人）获得绝对控制权，肯被边缘化，最终离开核心管理岗位。
2. 文化冲突：Sierra的创意文化与CUC/戴维森的激进销售导向格格不入。
3. 会计欺诈曝光：1998年4月，CUC在与HFS公司合并后成立的 Cendant 集团发现，CUC在福布斯领导下多年系统性地虚报收入，金额高达5亿美元。股价暴跌，公司陷入危机。调查显示这是由CUC高管（包括福布斯）授意的欺诈行为。

四、Sierra的衰落与终结

• 资产剥离：Cendant认为软件业务非核心资产，于1998年将包括Sierra在内的软件部门以10亿美元现金出售给法国哈瓦斯公司（威望迪子公司）。
• 业务重组与关闭：新东家大规模裁员并关闭工作室，试图将Sierra转型为在线平台。但资源被集中到更成功的暴雪娱乐手中。2004年，Sierra品牌被正式关闭。
• 对员工的打击：许多员工因持有Cendant股票期权而遭受巨大财务损失，部分人因此破产。

五、肯·威廉姆斯的反思与结局

肯将Sierra的灭亡视为一次“谋杀”，并深感自责，认为自己的决定连累了员工。尽管对福布斯的欺诈行为感到震惊，但他仍难以完全相信这位曾被他视为“有远见的华尔街英雄”的人是故意的罪犯。然而，福布斯和另一位高管柯克·谢尔顿最终因证券欺诈罪被判入狱。

核心主题：Sierra的故事是一个关于 愿景、贪婪、信任与欺诈 的商业悲剧。一家创新公司在追求增长和财富的过程中，因一个建立在虚假数字之上的收购案而最终走向毁灭，其影响波及了无数员工和玩家。

本文介绍了一个名为“可信的、自由开源的、支持Linux的自托管64位RISC-V计算机”的项目，由Gabriel L. Somlo主导。该项目的核心目标是从零开始构建一个完全自由开源的硬件和软件系统，确保其行为完全可由公开的硬件描述语言（HDL）和软件源代码解释，从而实现最高程度的信任。

项目动机源于对系统完全可控和可审计的需求。作者无法拥有硅芯片制造厂，因此选择在FPGA上实现硬件部分，并坚持所有用于构建系统的工具链（包括编译器、FPGA开发工具）都必须是自由开源的，并且该工具链本身能在所构建的计算机上自托管运行。

选择FPGA而非定制ASIC（专用集成电路）主要基于安全性和信任方面的权衡。作者阐述了其优势：

1. 降低硬件后门风险：芯片制造厂不知晓FPGA的具体用途，这有助于缓解特权升级类硬件后门的风险。FPGA制造阶段的主要威胁被限制为服务拒绝攻击，即计算机可能完全停止工作，但不会在正常运行时暗中出卖其所有者。
2. 更易进行物理检查：FPGA由规则的、相同的组件网格构成，相比视觉规律性较差的定制ASIC，对其进行破坏性视觉检查（如化学蚀刻和透射电子显微镜成像）更为可行。

通过约束制造阶段的攻击面，并坚持所有源代码的可构建性，该项目旨在实现一个硬件+软件计算机产品，其可信度与其可供公开审计的HDL和软件源代码相当。

文中列出了多项相关资源，包括在CReSCT 2020（IEEE S&P 2020）和CMU/SEI研究评审会的论文与演示，以及作者早期在CERT/SEI关于可信计算的工作。项目参考了lowRISC项目，该项目是一个重要的学习资源，但当时依赖闭源的HDL工具链和专有IP模块。作者还提到了其先前的yoloRISC项目，这是一个基于Rocket-Chip的RV64IMAC演示系统，使用开源的yosys/trellis/nextpnr工具链为Lattice ECP5开发板构建。

DB-19连接器：复活一个过时接口（2016）

背景与问题 DB-19是一种用于连接复古计算机（如Apple II、Macintosh，以及部分NeXT和Atari计算机）磁盘驱动器的D-SUB接口。该连接器已停产数十年，导致库存耗尽。作者开发了名为“Floppy Emu”的磁盘仿真器产品，其正常生产严重依赖该连接器，但供应已近乎枯竭。

寻找解决方案

• 作者曾耗时近两年在全球搜寻剩余库存，但最终确认已无新库存。
• 尝试设计替代方案（如使用PCB和排针），但效果不理想。
• 约15个月前，开始探索定制生产。通过阿里巴巴等平台联系数十家中国D-SUB连接器制造商，仅两家表示具备生产能力。
• 生产成本高昂：需定制模具，最低订购量为10000件，总费用达五位数（美元）。作者的小型业务难以独立承担。

转折与合作

• 尽管作者对成本犹豫，但其他复古计算机社区（如NeXT和Atari用户）及电子零件供应商同样面临DB-19短缺。
• 在其他需求方的参与下，作者在一周内成功组织了“团体采购”，共同分担成本，使项目在经济上可行。

生产与实现

• 制造商需要详细规格。作者通过修改旧版DB-25的机械图纸，提供了DB-19的生产参数。
• 支付流程复杂，需通过香港银行进行大额转账，耗时较长。
• 经过两个月的原型制造与迭代，首批10000个DB-19连接器于2016年5月底运抵美国，并通过海关。

结果与展望

• 作者暂时持有全球几乎所有现存DB-19连接器库存。
• 大部分连接器将分配给参与团购的各方，并计划在几周内通过电子零件供应商少量发售。
• 作者预计，若Floppy Emu销量稳定，投资可在数年内收回；即便未能盈利，此经历本身也极具意义。
• 该成功案例被视为复古硬件社区协作的典范，确保了相关老旧设备的可持续维护。

在线股票财务估值模型网站

该项目是一个专为普通投资者设计的在线工具，旨在帮助用户创建、保存和分享上市公司的财务估值模型，从而辅助投资决策，打造一站式投资研究平台。

核心功能与特点

• 高度可定制模型：支持对现金流折现（DCF）模型的所有输入参数进行编辑，用户可根据自身的具体假设精确微调估值。
• 精准数据支持：提供任意上市公司最新、最准确的财务数据，以增强投资研究的可靠性。
• 模型仪表盘：提供集中管理面板，允许用户随时保存、查看和调整已创建的估值模型。
• 热门股票测试：支持用户直接使用当前最受欢迎的股票来试用和体验模型功能。

文章摘要：

本文讨论了Hephaistos项目在搜寻戴森球候选天体方面的最新进展。研究人员通过分析盖亚（Gaia DR3）、2MASS和WISE的测光数据，从约500万个天体中筛选出七个显示中红外波段辐射过剩的候选源。

关键发现与特征：

• 所有七个候选天体均为M型矮星，在中红外波段表现出无法用已知天体物理过程（如尘埃盘、年轻恒星）完全解释的辐射过剩。
• 研究团队运用了超过600万个模型进行匹配，考虑了部分戴森球（即未完全包裹恒星的巨型结构或星群）的遮挡效应及其在中红外波段的热辐射特征（有效温度范围100–700K，遮蔽因子0.1–0.9）。
• 为排除干扰，研究特别关注了Hα发射（可能暗示恒星年轻或活跃）以及背景污染，并进行了时变性检查，结果表明这些候选体不太可能是年轻恒星。

候选体的疑点与后续研究：

• 文章指出，这些红外辐射过剩的来源“性质未定”，需进一步通过光学和中红外光谱观测来确认：
  • 验证是否为单黑体辐射（符合戴森球模型预期）。
  • 确定真实光谱型，排除被误判的M型矮星碎片盘（这类情况极少）。
  • 分析恒星自转、年龄与磁活动，以评估其他可能性。

结论与意义：

• 这七个候选体并非确凿的戴森球证据，但代表了当前搜寻中的最佳匹配案例。若戴森球存在，其数量应极为稀少。
• 研究强调，后续观测数据（尤其是光谱数据）对最终判定至关重要。无论结果如何，此项工作都将推动我们对M型矮星异常红外辐射的理解，或为地外高级文明搜寻提供新线索。

参考文献：

• 关键前期研究：Wright et al. (2014) 提出了红外搜寻戴森球的框架。
• 项目论文：Suazo et al. (2022, 2024) 详细介绍了Hephaistos项目的方法与候选体筛选。

ILGPU 是一个基于 .NET 语言（如 C# 和 F#）编写高性能 GPU 程序的即时（JIT）编译器。它完全用 C# 编写，无原生依赖，兼具 C++ AMP 的灵活性便利性以及 CUDA 程序的高性能。内核函数无需特殊注解（默认 C# 函数），并支持操作值类型。所有内核（包括共享内存、原子操作等硬件特性）均可通过集成的多线程 CPU 加速器在 CPU 上执行和调试。

ILGPU.Algorithms 库提供了一组辅助函数和高级算法（如排序、前缀和），满足实际应用对标准库的需求。所有算法均可在支持的加速器类型上运行，CPU 加速器支持尤其便于内核调试。

社区通过 Discord 提供即时帮助、反馈和建议，并设有每周开发者交流会议。

构建与测试

• 需要 Visual Studio 2022 或更高版本，以及 .NET 6.0 SDK 工具链。
• 使用提供的 Visual Studio 解决方案构建 ILGPU 库（支持 Debug/Release 配置）。
• 测试时若使用 XUnit 测试运行器并行执行可能导致意外停止，这是已知的 XUnit/Visual Studio 问题，重新运行即可。可卸载无需的测试项目（如无 CUDA 设备时卸载 ILGPU.Tests.Cuda）。

预览版本与调试支持

• 预览/每日构建通过 feedz.io 分发，需在 NuGet.config 中指定源。
• 支持在 VS2022 中加载符号，并提供 Source Link 支持以改善调试体验。

贡献指南

• 需遵守编码风格规范。
• 确保 ILGPU 在所有构建模式（Debug、DebugVerification、Release）下无警告编译。

许可与依赖

• ILGPU 使用 University of Illinois/NCSA 开源许可证。
• 依赖包括 System.Collections.Immutable、System.Memory 等 NuGet 包，其版权信息详见 LICENSE-3RD-PARTY.txt。

反对双轴图表的论据及替代方案

本文明确反对使用双轴图表（即带有两个不同Y轴的图表），认为它对大多数人而言难以直观地对两个数据系列做出正确判断。作者推荐使用并排图表或索引图作为首选替代方案。

人们使用双轴图表的常见原因

• 展示具有相同度量单位但数量级差异巨大的两个数据系列（如全球GDP与德国GDP）。
• 展示同一事物的相对值与绝对值（如人均GDP与总GDP）。
• 展示两个完全不同的指标（如一国GDP与预期寿命）。
• 为同一数据系列显示不同的刻度（如华氏度与摄氏度）。

双轴图表的主要问题

1. 任意刻度易误导：图表的两个Y轴范围可以随意设置，从而可能刻意或无意地误导读者对数据系列之间关系的理解。即使将零基准线对齐，读者仍可能错误地比较两条接近的线，认为它们数值相近或趋势相关，而实际上它们代表完全不同的数量级或指标。
2. 违背阅读直觉：读者习惯于单一刻度图表。在双轴图表中，他们会本能地像阅读普通折线图一样比较两条线的位置，这需要额外的认知努力来提醒自己两条线具有不同的刻度，从而造成混淆。
3. 可读性差：研究表明，双轴图表在准确性、阅读速度和用户评价上均表现不佳，常被评为最令人困惑的图表类型之一。

推荐的替代方案

1. 并排图表：将两个数据系列分别绘制在两个独立的图表中。优点是每个图表可使用独立且合理的刻度，避免了误导。缺点是需要更多展示空间。
2. 索引图：不显示绝对值，而是将所有数据系列的起始值设为100%，显示其随时间变化的百分比变化。这能在同一图表中直观比较不同量级数据的相对趋势。可通过标签或工具提示补充绝对值信息。注意：当两个系列的变化率差异极大时，此方法可能失效。
3. 优先标注法：仅绘制更重要的那条数据系列，并用图表注释（如文字说明）补充另一条系列的关键信息。适用于需要强调一个主要系列且另一系列为次要参考的情况。
4. 连接散点图：将时间从X轴移除，用其中一个数据系列作为X轴，另一个作为Y轴，用连接线表示时间序列。这种方式能直观显示两个变量之间的关系路径，但不如时间序列图直观，可作为一种进阶的、用于探索特定洞察的替代方案。

在大多数情况下，并排图表和索引图是最实用且不易产生误解的解决方案。

项目概述

Liikennematto 是一款使用 Elm 语言开发的交通垫模拟游戏，玩家通过修建道路来引导自动生成的建筑、车辆和居民。本文总结了该游戏自 2021 年中以来近三年的核心开发进展与技术重构。

核心功能与技术更新

• 视觉与音效：全面重制美术资源，采用明亮活泼的调色板。使用 Figma 绘制矢量图形，在视觉上区分几何人造物与手绘自然物。利用 Ableton Live 制作了与画面风格匹配的马林巴琴音效，以增强操作反馈。
• UI 与触控交互：重构用户界面，采用自定义图标和三级缩放控制。深度优化触控设备体验，支持平滑平移与缩放，并引入带进度条的长按操作以安全删除道路，有效防止滑动误触。
• 停车系统：新增完整的停车机制。地块配备停车位及连接道路网络的路径，通过“停车锁”确保狭小空间内每次仅允许一辆车进出。系统支持为居民或特定车辆（如消防车）预留专属车位。
• A 寻路算法：摒弃原有的随机路线生成，采用标准 A 算法。优化后的 Elm 实现单线程每秒可生成约 18,000 条路线，支持在地图改变时进行毫秒级的动态重新寻路。

游戏架构与数据流

代码库被重构为四个核心命名空间：Tilemap（瓦片地图）、Simulation（模拟）、Render（渲染）和 UI，通过 Elm 事件循环和包含游戏状态的 World 模块进行交互。

• 自定义事件队列：为精细控制数据流引入事件队列，用于处理延迟事件（如车辆生成、路径更新）、重试机制以及失败时的实体回收策略。
• 有限状态机（FSM）：构建了 FSM 库以规范车辆、交通灯、地块及游戏阶段的状态转换。这不仅消除了隐藏的状态 Bug，还确保了动画与音效的精准同步。

发布状况与未来规划

• 早期发布：游戏于 2022 年 11 月在 itch.io 发布浏览器抢先体验版，获得积极反馈，并于 2023 年 3 月推出内容与模拟优化补丁。
• 程序化生成（WFC）：下一步计划是将波函数坍缩（WFC）算法集成到游戏中。目前正在开发“driven WFC”机制，使地图的程序化生成由玩家铺设道路的决策来驱动。
• 后续更新：受作者个人生活变动影响，开发进度放缓且无明确时间表。未来的开发日志和更新通知将全面转移至 itch.io 和 Mastodon 平台。

YARA-X：新时代的恶意软件检测规则引擎

核心概述 YARA 是一个拥有超过15年历史的恶意软件分析关键工具。近日，其作者宣布了该项目历史上最大的变更：使用 Rust 语言进行完全重写，并命名为 YARA-X。此次重写旨在全面超越旧版 YARA，在用户体验、性能、安全性和开发友好性等多个维度实现提升。

重写的主要目标 YARA-X 的重写工作围绕以下几个核心目标展开：

1. 改善用户体验：提供更现代、色彩更丰富的命令行界面，错误报告更具解释性。
2. 规则级兼容：力争与 YARA 达到 99% 的规则兼容，任何不兼容之处都将被最小化并详细记录。
3. 提升性能：在处理正则表达式或复杂循环等使旧版 YARA 变慢的规则时，YARA-X 表现更优，最终目标是实现全面性能超越。
4. 增强可靠性与安全性：通过使用 Rust 语言编写，解决原 C 语言代码可能带来的 bug 和安全漏洞，提供更强的保障。
5. 开发者友好：简化集成与维护，提供 Python、Golang 和 C 的官方 API，并解决了旧版 YARA 中一些影响维护和扩展的设计缺陷。

为何选择彻底重写？ 作者指出，彻底重写（而非渐进式迁移）是基于以下考量：

• 代码结构：YARA 是一个中型项目，各部分代码高度耦合，无法独立迁移，用 Rust 进行渐进式改造不切实际。
• 设计变更：设想的改进需要根本性的设计变更，在旧 C 代码库上实施这些变更的风险与收益，等同于从头用 Rust 重写。
• 维护优势：作者在一年的开发后认为，Rust 比 C 更易于维护，提供了更强的可靠性保证，并简化了跨平台第三方代码的集成。

YARA 的现状与未来

• 旧版 YARA 并未消亡：考虑到大量用户和组织的依赖，YARA 本身仍会继续维护，未来版本会包含 bug 修复和小幅功能改进。
• 开发重心转移：所有重大的新功能、新模块开发将完全集中于 YARA-X。不会为旧版 YARA 增加大型新特性。

YARA-X 当前状态与测试

• 版本与成熟度：YARA-X 目前处于 Beta 测试阶段，但已足够成熟稳定，适用于命令行界面或一次性 Python 脚本。其 API 底层架构已基本定型。
• 实战检验：在 VirusTotal，YARA-X 已与旧版 YARA 并行运行，用数万条规则扫描数百万文件，用以对比并修复差异。这一过程甚至发现了旧版 YARA 自身的 bug，证明了 YARA-X 的“实战可靠性”。

未来展望 作者的最终目标是让 YARA-X 在各个方面都显著优于 YARA，凭借其无可争议的优势吸引用户主动迁移。发布 Beta 版只是第一步，后续将持续改进并分享进展。YARA-X 的发展旅程才刚刚开始。

500年历史数学问题在咖啡与钟表中的应用

文章标题点明一个存在500年的数学问题，如今被发现与咖啡杯和时钟密切相关。这内容摘自《新科学家》的“Lost in Space-Time”月度新闻通讯，由作者Sarah Hart探讨数学与日常生活的交汇点。

• 数学问题背景：数学家们五百年来持续研究圆和其他曲线的行为，但该问题具体细节未在提供的内容中完整展开。
• 实际应用示例：以咖啡杯为例，当光线从其圆形边缘反射时，会形成一个数学上重要的形状，这直观展示了古老数学问题在现实中的体现。
• 艺术与数学的联系：文章引用艺术家Paul Klee的名言“绘画是‘带一条线散步’”，以此引入数学中对曲线探索的创意视角。
• 跨领域启示：该数学问题不仅限于理论，还应用于咖啡杯和时钟等日常物品，突显了数学在理解物理世界中的普适性。

整体而言，这篇文章通过生动的例子和跨学科引用，说明了古老数学研究如何持续影响现代科技和日常生活。

该文章详细规定了NetBSD项目的代码提交规范，核心要点如下：

1. LLM生成代码的强制规定：明确指出由大型语言模型或类似技术生成的代码被视为有版权问题的代码。此类代码必须获得核心团队的书面事先批准后，才可提交。

2. 提交代码的基本准则：

   • 熟悉代码：只能提交自己熟悉且了解的代码。
   • 代码来源：必须确保提交的代码拥有合法的、允许自由分发的许可证，且提交者是原作者或已获得授权。禁止从NetBSD官方仓库（cvs.NetBSD.org）以外的外部代码库提交代码。

3. 提交前必须测试：提交前需在相关系统环境下编译并运行代码以确保其正常工作。对于主干提交，需在-current分支上测试；若需合并到发布分支，则必须在对应分支上预先测试。

4. 提交内容的组织与清晰度：

   • 分组相关改动：同一修复或功能的一系列改动应合并为一次提交。
   • 单一提交原则：每个提交应专注于一个独立的修复、功能或改进。
   • 分离改动：功能/缺陷修复应与格式调整等无关改动分开提交。

5. 详尽的提交日志：

   • 日志必须清晰说明改动的原因和内容，重点是“为什么”改。
   • 若改动修复了问题报告，需在日志中注明。
   • 需记录代码是否经过他人审查。

6. 正确标注归属：

   • 若代码来自问题报告或其他开源项目，必须在提交日志中给予致谢，但通常应避免在公开列表中包含提交者的电子邮件地址。

7. 处理提交冲突：开发者不应直接回退其他开发者的提交。如有异议，应首先沟通，若无法解决则联系核心团队进行调解。

8. 不同改动的审批级别：

   • “明显”的修复可直接提交。
   • 其他修复需经审查。
   • 重要新功能需在技术邮件列表讨论。
   • 添加全新软件包则需邮件列表讨论并获得核心团队批准。

OpenProject 开源项目管理软件概览

核心优势：数据安全与隐私保护

• 数据主权：确保用户在安全环境中完全控制数据，符合最高安全标准。
• 本地部署：支持在企业自有基础设施上安装，实现100%数据自主管理。
• 安全措施：提供HTTPS加密、密码安全、双因素认证、会话时间管理等功能。
• 透明性：作为自由开源软件（FOSS），遵循GNU GPL v3协议，源代码公开可审查。
• 托管选项：企业云版数据存储在欧盟（或德国）的安全服务器，满足高安全需求。

项目管理功能

• 多模式支持：适用于传统、敏捷或混合项目管理，提升团队协作效率。
• 项目规划：通过甘特图协作制定计划，细化任务并可视化项目进度。
• 敏捷方法：支持Scrum和Kanban看板，优化团队组织和任务跟踪。
• 团队规划器：以周/双周日历视图分配任务，直观管理工作量。

开源生态与版本选择

• 社区版：免费提供完整功能与插件，适合个人或小型团队。
• 企业本地版：面向自托管用户，提供专业支持、企业级插件和增强安全功能（需Linux/Mac技术基础）。
• 企业云版：托管服务，无需技术配置，包含专业托管、企业功能及支持。

用户反馈
多个案例显示OpenProject帮助用户：

• 提升项目成员生产力（如科堡大学）。
• 快速规划项目并维持截止日期（如go~mus公司）。
• 集中管理项目信息，减少协调成本（如恩茨县行政部门）。
• 灵活适配需求并保障数据安全（如绿色和平北欧）。
• 简化任务分配与流程透明化（如fLotte柏林公益项目）。

市场定位
作为领先的开源项目管理工具，OpenProject强调可替代Atlassian产品（如Jira），尤其适合注重数据自主权、灵活部署（本地或云）及开源自由的企业团队。

Tegelwippen 活动概述

活动名称与时间
NK Tegelwippen（国家撬瓷砖比赛）是一项从每年3月19日持续至10月31日的社区活动，鼓励个人和家庭通过撬起自家前院、后院或绿墙的瓷砖来参与。各市之间展开竞争，比较谁撬起的瓷砖数量最多。

核心目标
该活动不仅聚焦于竞争，更旨在实现环境与社会的共同效益。通过用草坪、花坛、树木和绿墙替换硬质瓷砖，有助于增强荷兰的气候适应性，改善昆虫和动物栖息地，在炎热天气中降低温度，提升城市美观度，并促进居民幸福感。

参与意义

• 环境影响：瓷砖不透水，导致雨水无法渗透，而荷兰降雨频繁且量大，撬除瓷砖可缓解内涝问题，促进雨水自然吸收。
• 社区参与：活动鼓励个人行动，通过简单步骤如在自家花园撬瓷砖，直接贡献于环境改善。
• 示范案例：例如，四月的“撬瓷砖者”Annette来自登博斯，她和伴侣在一个周六撬除了77块瓷砖，并建设了花坛，展示了个人行动的实际成效。

呼吁行动
活动积极呼吁公众参与，强调每个人通过撬起一块瓷砖，即可为荷兰的绿色未来做出贡献。更多详情和参与方式可通过相关链接进一步了解。

道路编号错误案例分析

道路编号系统规则

英国的道路编号系统遵循明确规则：

• 分区制度：A级和B级道路的首位数字由其所在地理位置决定。高速公路分区与A/B级道路不同。
• 数字长度：通常反映道路重要性。高速公路可有1-3位数，A级道路1-4位数，B级道路仅限3-4位数。
• 序号匹配：新编号可参考附近已有编号，但不可违反分区规则。

错误编号案例

1. M41：意外产生的编号

• 预期：伦敦西十字路线本应编号为M14（符合其所在4区）。
• 错误：由于文件记录时数字顺序意外颠倒，被误标为M41。
• 结果：因后续规划取消及机构更迭，错误编号沿用至1990年代末道路降级为A级。

2. B38：被纠正的违规编号

• 事件：2011年，伯明翰为新降级道路分配了两位数的B38编号。
• 违规：违反了B级道路必须为3-4位数的规则。
• 纠正：经道路爱好者社区（SABRE）投诉及政府审查，2012年更名为B384。

3. B77：苏格兰的规则例外

• 事件：2021年，苏格兰为Maybole镇旧路分配了B77编号。
• 立场：苏格兰声称道路编号属下放事务权，其有权制定独立政策，故坚持使用该编号。
• 问题：此编号与新绕行公路A77高度相似，可能误导驾驶者，削弱了分流交通的设计初衷。

4. M876/A88：本末倒置的编号

• 背景：苏格兰要求高速公路继承其前身A级道路的编号。
• 错误：M876高速公路的前身A876被降级后，未采用任何未使用的编号（如M88），反而获得了一个重要听起来的编号A88。
• 结果：造成次要道路（A88）比主要高速（M876）编号更简短易记的矛盾局面。

结论

道路编号系统已存在超过一个世纪，是导航和路网识别的重要工具。然而，实际操作中常因忽视规则、沟通失误或官僚惰性而产生错误。这些错误可能削弱编号系统的逻辑性和实用性。尽管错误不会严重影响日常生活，但精心设计的编号能更有效地引导交通、体现路网结构。因此，在分配新编号时，应对系统规则及其目的给予基本关注。

修复视频游戏中的迭代阻尼插值问题

问题概述

文章讨论了游戏开发中常见但存在问题的阻尼插值公式：

a = lerp(a, B, delta * RATE)

该公式旨在实现平滑的动画衰减效果（如玩家速度逐渐降至零），但存在严重缺陷。

主要缺陷

1. 帧率依赖性：行为随帧率（30/60/144 FPS）变化，导致游戏物理机制不一致
2. 非确定性：因硬件、系统性能或帧率波动（如卡顿）而产生不同结果
3. 易过冲：在大延迟时（如delta=0.5秒），插值参数可能超过1，导致目标值过冲

问题分析

原公式通过递归线性插值生成指数衰减曲线，但其数学本质是离散的帧序列，无法适应可变时间间隔。

解决方案推导

作者通过数学分析得出理想的连续时间函数：

f(t) = lerp(α, β, 1 - (1 - R/F)^(tF))

其中α为初始值，β为目标值，R为速率，F为目标帧率，t为时间。

进一步推导出与时间无关的迭代公式：

R' = -F × ln(1 - R/F)
u_{n+1} = lerp(u_n, β, 1 - e^(-R' × Δn))

最终推荐公式

在代码中应替换为：

a = lerp(a, B, 1.0 - exp(-delta * RATE2))

其中RATE2可通过预计算得到：

RATE2 = -FPS × log(1 - RATE/FPS)  // log为自然对数

或简化为RATE2 ≈ RATE（当R较小时近似成立）。

新公式优势

1. 帧率无关：在不同帧率下行为一致
2. 确定性：不受硬件性能波动影响
3. 抗过冲：当delta很大时，插值会直接达到目标值而不会过冲

额外优化建议

1. 使用-expm1(x)代替1 - exp(x)提高数值稳定性
2. 考虑使用时间常数T（T=1/速率）作为API参数
3. 对于小值x，可手动展开指数函数为x + x²/2以优化性能

结论

文章呼吁游戏开发者修正这一广泛存在的错误公式，使用新的帧率无关公式以确保一致的游戏体验。原有公式中的过冲限制也可以安全移除。

本文介绍了作者重建家庭实验室的个人项目，标题中的“Suffering as a service”可能暗示了此过程中遇到的挑战。当前提供的网站内容主要展示了其技术防护与托管状态：

• 网站防护：使用由Techaro开发的Anubis进行防护。
• 技术细节：运行的是Anubis v1.25.1-0.20260604200537-44d5fa3ce047版本。
• 归属信息：网站制作与吉祥物设计分别标注了地点（加拿大）和设计者（CELPHASE）。

由于未提供家庭实验室重建的具体过程、技术栈、问题描述或解决方案，无法对“重建”本身进行更深入的总结。现有内容仅聚焦于其网站当前的技术实现与防护状态。

Jan Leike 的 OpenAI 离职声明摘要

这篇内容是一份在 OpenAI 平台上发布的社交媒体帖子截图，用户 Jean Liff 以“帖子”为标题发布了离职感言与回顾。

帖子主要包含以下要点：

• 工作回顾：作者回顾了在 OpenAI 超过三年的工作历程，包括组建团队的经历，并对未来的进展表达期待。
• 致谢与认可：对同事和 OpenAI 的人才表示感谢，强调了团队的优秀。
• 对 AI 安全的关切：重点讨论了 AI 开发中安全性与控制的重要性，指出解决安全问题的困难性，并呼吁需慎重考虑 AI 对社会的影响。
• 面向未来的展望：提到需要为 AI 突破做好准备，并相信 OpenAI 有潜力在该领域发挥领导作用。
• 结语与呼吁：最后，作者鼓励读者“以与你所构建之物相称的严肃态度行动”，强调在开发强大 AI 技术时应有的责任感和庄重态度。

整体而言，该帖子融合了个人离职的感性回顾、对团队的感激，以及对 AI 安全和行业责任的理性思考与呼吁。

这篇在HN（Hacker News）上的提问帖由用户theGeatZhopa于2024年5月17日发布，获得了102点支持和67条评论。帖子标题为“Ask HN: Should we stop posting X links on HN?”（询问HN：我们是否应该停止在HN上发布X链接？）。

主要内容是作者指出，当天在HN上看到许多链接指向X（原Twitter），但X平台本身不展示内容（即链接需登录才能查看）。作者以另一个HN帖子（ID: 40392157）为例，该帖链接本应展示《波斯王子》动画的制作过程，但点击后实际无法看到任何内容。作者表示自己没有X/Twitter账户，且认为即使注册账户也可能无法解决问题，因为HN上发布的链接本身可能就不正确。这导致许多HN条目链接指向一个无法访问或内容缺失的页面。

该帖子引发了关于HN上内容链接可用性及平台政策的讨论。

Worklenz：一站式开源项目管理工具

Worklenz 是一个强大的开源项目管理平台，旨在帮助团队更智能地规划、更好地协作并更快地交付。它提供了一个集成所有必需功能的简洁解决方案。

主要功能

Worklenz 提供了全面的项目管理能力，核心功能包括：

• 项目与任务管理：支持从规划、执行到监控的项目全生命周期管理，并提供列表、看板、甘特图等多种视图。
• 资源与团队规划：可视化调度器帮助分配资源、规划团队容量并避免过度分配。
• 协作与沟通：团队和客户可以在同一共享空间中就任务进行评论、共享文件并保持沟通。
• 时间与财务跟踪：直接在任务上记录时间，并追踪项目预算与成本。
• 分析与报告：实时洞察项目健康状况、团队工作负载与项目收益。
• 效率工具：提供项目模板以快速启动新项目。

技术栈

该工具的技术架构如下：

• 前端：React + Ant Design
• 后端：TypeScript + Express.js
• 数据库：PostgreSQL
• 存储：MinIO (S3兼容) / AWS S3 / Azure Blob
• 缓存：Redis
• 代理：Nginx

安装与部署

Worklenz 提供多种部署方式：

1. Worklenz Cloud：无需自建基础设施，注册即可快速开始使用。
2. 自托管（Docker - 推荐）：
   • 快速设置：通过克隆仓库并运行 ./quick-setup.sh 脚本，可自动完成环境配置、SSL证书设置和服务启动。
   • 手动设置：通过 docker compose 命令手动启动包含所有依赖的服务。
   • 访问地址通常为 https://localhost，管理命令通过 ./manage.sh 脚本执行。
3. 手动安装（适用于开发）：
   • 前提：需要 Node.js (v18+)、PostgreSQL (v15+) 及S3兼容存储服务。
   • 步骤：包括克隆仓库、设置环境变量、安装前后端依赖、手动初始化数据库以及分别启动开发服务器。
4. 生产部署：
   • 可使用 ./quick-setup.sh 并输入生产域名进行快速部署（自动配置Let‘s Encrypt SSL）。
   • 也可手动配置环境文件、域名DNS和SSL证书后，使用Docker部署。

配置与特性

• 配置：通过 .env 文件进行详细配置，涵盖部署模式（express/advanced）、域名、数据库、安全密钥、存储、SSL、备份等。
• MinIO集成：默认使用MinIO作为S3兼容的存储服务，提供管理控制台。
• 安全性：包括非root Docker容器、网络隔离、SSL/TLS、API速率限制和安全头等措施。
• 分析：可选参与匿名使用数据收集，以改进产品。
• 社区与贡献：欢迎社区贡献，并提供Discord、GitHub等交流渠道。项目遵循AGPL v3.0许可证。