• 文章描述安全研究员（作者，15岁）发现Zendesk重大漏洞，对超过半数Fortune 500公司产生影响，并获得五万元美金漏洞赏金。
• Zendesk是一款客户服务工具，全球许多知名企业采用。典型配置为将公司客服邮箱（如support@company.com）与Zendesk关联，所有来信自动生成工单。
• 不少企业将@company.com作为SSO登录域，Zendesk与SSO同域集成存在安全隐患，易被忽视。
• 作者发现Zendesk缺乏有效的邮件伪造防护。攻击者可伪造请求者邮箱，向support+id{ticket_id}@company.com发送邮件并将自己的邮箱CC进来，Zendesk将其加入工单，攻击者可访问全部会话历史，甚至窃取敏感信息。
• 利用此漏洞要求：
  1. 请求者邮件地址
  2. 工单ID（易于猜测或暴力破解）
  3. 有公开客服门户的公司
• 作者将漏洞通过HackerOne报告给Zendesk，但因漏洞涉及邮件伪造，被归为“超出范围”，报告遭拒。
• 参考2017年“TICKETTRICK”公开案例，作者意识到该漏洞可用于入侵Slack私有工作区。核心原理是许多企业Slack与Zendesk采用同域SSO，邮箱验证可通过support@company.com完成。
• 随后Slack以随机token防护邮件伪造，但OAuth验证（Apple/Google账号）未有类似防护。Google验证邮件被Zendesk屏蔽，Apple未屏蔽，成为攻击突破口。
• 攻击流程：
  1. 用support@company.com注册Apple账号，请求验证码，邮件自动生成Zendesk工单
  2. 预测/跟踪工单ID范围
  3. 用邮件伪造批量向support+id{ticket_id}@company.com发信并CC攻击者邮箱
  4. 登录Zendesk，查看CC的工单获取验证代码
  5. 在Apple账号输入验证码
  6. 用“Apple登录”进入Slack，以support@company.com身份访问内部频道
• 作者批量复现该攻击，向受影响企业单独报告，部分立即修复，部分认为是Zendesk责任。作者累计获得超五万美元赏金，有企业因此终止与Zendesk的合作。
• Zendesk在作者报告2个月后修复漏洞，主要措施：
  1. 启用Rspamd评分增强邮件垃圾过滤，对既有工单线程激活邮件采用高分过滤
  2. 增加过滤：自动暂停Apple验证邮件和Google非交易性邮件
  3. 宣称会持续加强发件人认证与邮件安控
• 尽管作者协助修复并报告了详细复现步骤，Zendesk因作者违反HackerOne保密规则（向企业披露漏洞）拒绝支付赏金。
• 本事件体现第三方工具安全链薄弱环节、邮件伪造的危害及漏洞响应流程的困难与现实。

YouTube 页面页脚摘要

YouTube 页面的页脚部分包含多个链接和标准信息，用于提供网站资源和法律条款。主要内容包括：

• 功能链接：提供访问 YouTube 各类页面的入口，如关于页面、新闻中心、版权信息、联系我们、创作者资源、广告选项、开发人员文档、条款、隐私政策、安全政策以及 YouTube 运作方式说明。这些链接旨在帮助用户了解平台、参与内容创作或处理法律事务。
• 附加资源：包括“测试新功能”链接，指向新功能测试页面，以及一个描述性文本，强调 YouTube 的核心功能——观看喜爱视频、上传原创内容并分享给全球用户。
• 版权信息：页脚以“© 2026 Google LLC”结束，表明版权归属和年份。

该页脚结构简洁，主要为用户提供导航和法律参考，不涉及技术细节或动画过程。

赛洛西宾在重度抑郁症长期治疗中表现优于SSRI类药物

一项首个长期对比研究表明，在治疗中重度重度抑郁症时，赛洛西宾的整体疗效优于选择性血清素再摄取抑制剂（SSRI）类药物艾司西酞普兰。该研究结果于2024年9月22日在第37届欧洲神经精神药理学会大会上公布，并同步发表于《柳叶刀 eClinicalMedicine》。

研究背景与意义

研究指出，传统抗抑郁治疗存在“不匹配”问题：精神科医生常关注抑郁的负面症状（如悲伤、睡眠食欲问题），而患者更重视生活意义、人际连接和日常功能等整体福祉。赛洛西宾疗法可能提供更整体的治疗方案。

研究方法

• 这是一项2期双盲随机对照试验的6个月随访研究，初始研究纳入59名成年重度抑郁症患者（平均年龄41岁）。
• 患者随机分组：
  • 赛洛西宾组（30人）：接受两次25毫克口服赛洛西宾治疗，辅以心理支持。
  • 艾司西酞普兰组（29人）：每日服用10-20毫克艾司西酞普兰，同时接受两次1毫克赛洛西宾作为安慰剂，并辅以心理支持。
• 治疗期为6周，之后进行为期6个月的随访，期间无额外研究治疗或精神治疗限制。

主要结果

1. 抑郁症状缓解：两组在6个月随访期间，使用16项快速抑郁症状自评量表（QIDS-SR-16）评估的抑郁症状减轻程度相似。赛洛西宾组仅在第一个月症状减轻更显著。
2. 整体功能与福祉：赛洛西宾组在多个反映整体健康的指标上持续优于艾司西酞普兰组：
   • 工作与社会功能（WSAS评分）：在3个月和6个月时改善更显著。
   • 生活意义感：在整个随访期所有时间点的改善都更显著。
   • 联结感（WCS评分）：在3个月和6个月时改善更显著。
   • 生活繁荣感（FS评分）：两组改善相当。
3. 副作用：初始研究显示，赛洛西宾组的副作用更少、更单一（主要是头痛），且改善了性功能；而艾司西酞普兰组副作用更多样且影响更大，并抑制了性功能。

局限性

• 在6个月随访期间，有相当比例的患者接受了其他额外干预（赛洛西宾组30.7%，艾司西酞普兰组43.5%），这可能干扰了结果。
• 在长期随访阶段，参与者知晓自己所在的分组，这可能影响了结果报告，因为参与者可能对赛洛西宾有积极预设。

专家评论与展望

• 研究证实了单次或两次赛洛西宾给药可能具有长期效应。
• 赛洛西宾疗法是一种不同于SSRI的新治疗模式，其要求患者主动面对痛苦情绪，并需要专业的心理治疗师进行引导和后续整合工作。
• 如果未来获批，可能会像其他特定疗法（如ECT或TMS）一样，为治疗师提供专门的培训。
• 研究结论鼓励了当前在英国、欧洲和美国进行的更大规模赛洛西宾试验。

资助与利益冲突

该研究由亚历山大·莫斯利慈善信托基金和伦敦帝国理工学院迷幻研究中心创始伙伴资助。主要研究人员之一报告了与亚当生物科学的咨询费。评论专家均参与赛洛西宾研究，但未报告财务关联。

内容摘要

提供的文章内容是MCC新闻存档的网页部分，主要包含三条新闻条目，聚焦于能源节约和全球煤炭退出主题。

• 能源节约的紧迫性（2022年6月14日）：Felix Creutzig在《Nature》杂志上发表文章，指出鉴于乌克兰战争的经济后果，现在是推动“需求侧气候解决方案”的关键时机，强调通过调整需求行为来减少能源消耗和碳排放。

• 全球煤炭退出的导向（2022年2月8日）：一项大型研究汇编了15个可比案例研究，揭示全球约四分之三的煤炭在15个国家燃烧。研究分析了这些国家的煤炭依赖性，并提供了退出煤炭的可行途径，为全球能源转型提供参考框架。

• 全球煤炭退出的势头（2021年11月13日）：在格拉斯哥世界气候大会（COP26）前后，国际社会做出了多项推动煤炭退出的有希望宣布。政策简报专门针对印度、印度尼西亚、菲律宾和越南，评估这些国家的煤炭使用现状和未来转型前景，为区域行动提供指导。

这些新闻条目突出了气候变化应对中的关键议题，包括能源效率提升和化石燃料逐步淘汰，反映了学术研究和政策讨论对全球环境治理的支持。

自疫情爆发以来，远程工作增长了五倍，可能推动经济增长并带来更广泛利益。斯坦福大学的尼古拉斯·布鲁姆在疫情前就研究远程工作的潜在影响，其数据显示企业应坚持混合工作模式。需要注意的是，文章观点仅代表作者本人，不一定反映国际货币基金组织（IMF）的政策。

GLP-1类药物（如Ozempic）的市场供应预测

背景与现状

GLP-1类药物（如Ozempic、Wegovy、Mounjaro）被广泛视为有效的减肥药物，平均可使体重减轻至少15%，并可能对治疗酒精依赖、睡眠呼吸暂停和降低中风风险有益。目前全球约有1.55亿美国人患有肥胖症或糖尿病，但此类药物供应持续短缺。

截至2024年，估计美国有约800万患者正在使用GLP-1药物。供应主要由诺和诺德（Novo Nordisk）和礼来（Eli Lilly）公司提供，2023年销售收入足以支持每月540万患者的用药量，预计2024年将增长至支持830万患者。

预测方法

为预测2030年的供应量，本文采用“外部视角”（参考其他畅销药物历史增长模式）与“内部视角”（考虑GLP-1药物的特殊因素）相结合的方法。

外部视角：参考类药物增长模型

选取四类近40年来出现的“重磅”药物类别作为参考：

• 他汀类（降胆固醇药）
• TNF-α抑制剂（治疗类风湿性关节炎等）
• PD-1/PD-L1抑制剂（抗癌药）
• 直接口服抗凝药（DOACs）

这些药物在上市后早期增长迅速，随后增长率逐年下降。以2024年作为GLP-1药物的“基准第4年”估算，到2030年累计销售增长可能在180%至240%之间。通过蒙特卡洛模型模拟（考虑增长轨迹的不确定性），得出中位估计为可支持约1800万患者的年供应量。

内部视角：GLP-1特殊因素调整

在基准估计基础上，考虑以下因素进行调整：

1. 供应限制与投资：

   • 当前供应主要受生产能力限制，两家公司均已宣布大规模投资扩建工厂（诺和诺德投资190亿美元，礼来投资130亿美元）。
   • 这些投资预计使GLP-1相关生产能力提高约140%，但考虑外包生产等因素，上调基准估计30%。

2. 保险覆盖与支付：

   • 美国保险对肥胖症治疗的覆盖有限，Medicare目前依法不得覆盖减肥药物。
   • 虽然覆盖范围可能扩大，但保险公司也可能出于成本考虑限制报销。
   • 综合评估后，平均下调基准估计7%。

3. 患者依从性：

   • GLP-1药物的一年停药率较高（约68%），高于部分参考药物。
   • 考虑到供应短缺可能导致部分停药，且停药患者可能重新用药，但长期需求仍可能受影响。
   • 有20%的概率下调8%。

最终预测

综合以上调整，最终预测：

到2030年，美国GLP-1类药物的供应量可支持约2300万患者的年用药量（中位数估计）。

结论

尽管需求巨大（约1.47亿美国人患有肥胖症或糖尿病），但到2030年，GLP-1药物的供应量预计仅能满足约15%的潜在患者。供应增长受制药投资、保险政策、患者依从性等多重因素制约，全球范围内药物普及仍需较长时间。

kv4p HT 项目概述

这是一个开源项目，旨在将您的 Android 手机转变为一台现代的业余无线电（业余无线电）VHF 或 UHF 收发器，发射功率为 1 瓦特。它主要面向喜欢动手制作的爱好者（Makers 和 Tinkerers），用户需自行组装硬件并刷写软件，项目本身不提供任何功能或可靠性担保，且使用者必须持有有效的业余无线电执照。

主要特点

• 低成本构建：仅需焊接少数几个组件，用户可自行采购零件或购买套件。
• Android 系统驱动：利用手机的屏幕、GPS 和电池，无需为无线电设备单独充电。
• 功能丰富的 APRS：内置 1200 波特调制解调器，支持类似短信的文本消息和位置信标发送，这超越了大多数仅支持信标功能的无线电设备。
• 完全开源：采用 GPL3 许可证，包括 Android 应用程序、ESP32 固件、PCB 设计和 3D 打印文件。
• 无内置电池：直接从手机获取电力，非常适合放入应急包或手套箱。
• 无障碍设计：支持实时字幕、带触觉反馈的粘性 PTT（发射按键）以及动画控制选项。

构建与使用步骤

1. 获取零件：可订购包含所有所需元件的套件，或根据清单自行采购，清单包括：定制的 PCB 电路板、SA818-V 或 SA818-U（或 DRA818V/U）无线电模块、SMA 公头天线、USB-C 线缆或转接头以及用于固定到手机的粘性凝胶垫。
2. 焊接电路板：将无线电模块和通孔元件焊接到 PCB 上，并修剪 SMA 连接器引脚以避免接触手机。
3. 组装：将 PCB 嵌入 3D 打印的外壳，使用粘性凝胶垫将 kv4p HT 附着在手机上，并拧上天线。
4. 刷写固件与 NVS：对 ESP32 微控制器刷写固件（套件可能已预刷）。
5. 安装应用程序：需要在 Android 8 或更高版本的系统上安装配套的 APK 应用程序。

该项目将手机转变为一台功能齐全的便携式无线电设备，充分利用了手机的现有资源，并提供了开源的软硬件方案。

AMD EPYC Turin（第五代）内存子系统性能总结

AMD的第五代EPYC处理器（代号Turin）已发布，本文重点分析了Turin在内存子系统方面的改进与性能实测数据（以EPYC 9575F为例）。

1. 内存带宽提升：

• 单CCD带宽显著提高： Turin服务器芯片采用了 GMI3-W 技术，即每个CCD通过 两个GMI链接 连接至IO芯片（IOD），而桌面版Zen 5（如9950X）仅为单个链接。同时，每个GMI写链接的宽度也从16B增加到 32B。
• 实测单核心/CCD带宽： 在单线程（1T）测试中，单个CCD可实现约52 GB/s的读取带宽、48 GB/s的写入带宽和95 GB/s的Read-Modify-Write带宽，整体表现远高于桌面版Zen 5。
• 全插槽带宽： 在支持12通道内存（DDR5-6400 MT/s，实测系统为DDR5-6000 MT/s）的配置下，全插槽读取带宽接近理论峰值的576 GB/s的99%。写入和Read-Modify-Write带宽分别达到435 GB/s和453 GB/s。

2. 内存配置与频率支持：

• Turin支持12通道内存，最高支持DDR5-6400 MT/s，但此速度需在特定验证系统和每通道1条DIMM配置下实现。
• 大多数系统在每通道1条DIMM时支持DDR5-6000 MT/s。
• 若使用每通道2条DIMM，速度会降至4400 MT/s；若主板有2个插槽但只插1条，则为5200 MT/s。

3. 内存延迟表现：

• 空载延迟： 与上一代Genoa相似。
• 满载延迟： 测试方法为在单个CCD或整个系统上施加内存带宽负载，同时用一个空闲核心/CCD测量延迟。
  • 单个CCD满载时，延迟比空载增加约 39纳秒。
  • 整个系统满载时，延迟增加约 31纳秒。
  • 无论负载状态如何，Turin的延迟行为表现一致。

4. 核心间通信延迟：

• CCD内部延迟：约45纳秒。
• CCD间延迟：约150纳秒。
• 插槽间延迟（通过3个GMI链接连接）：约260纳秒。
• 与Genoa相比，尤其是CCD内部延迟有所增加。

5. 时钟频率与产品定位：

• 在单线程测试中，所有64个核心均可达到 5GHz。在内存带宽测试中，一个CCD内的所有8个核心也能运行在5GHz。
• 在全核心负载（如Cinebench 2024）下，频率维持在约4.3GHz；在向量化程度较低的工作负载（如Web服务器/TLS事务）中，频率可达约4.9GHz。
• Turin提供了不同定位的SKU：既有面向超大规模计算的高核心数型号（如9755、9965），也有面向传统企业市场、核心数相对较低（如64核）但频率极高的型号（如9575F）。

结论： Turin是一次预期的代际升级，其核心改进在于内存子系统，特别是通过GMI3-W技术大幅提升了内存带宽。它延续了从Milan到Genoa的演进模式（内存带宽增加、核心数增加、核心架构更新），而非像从Naples到Rome那样的革命性飞跃。在竞争激烈的市场中，Turin凭借其改进的架构和多样化的产品线，预计将受到广泛关注。

OpenAI Swarm 框架摘要

概述与现状

Swarm 是由 OpenAI 发布的一个实验性、教育性的智能体协调框架。其核心目标是实现轻量级、高度可控且易于测试的智能体编排与执行。重要提示：Swarm 现已被 OpenAI 官方的 OpenAI Agents SDK 取代，后者是生产就绪的演化版本，由 OpenAI 团队主动维护。建议在所有生产用例中迁移到 Agents SDK。

核心概念

框架构建在两个基本原语上：

1. 智能体（Agent）：封装了一组指令和可用的工具函数。它可以随时选择将对话移交给另一个 Agent。
2. 移交（Handoff）：Agent 通过函数调用返回另一个 Agent 来实现控制流的切换。

这些原语足以表达工具与智能体网络之间的复杂动态，用于构建可扩展的现实世界解决方案。

主要特点

• 状态无关：Swarm 完全由 Chat Completions API 驱动，在调用之间不存储状态。其 client.run() 方法类似于 chat.completions.create()，但额外处理了函数执行、智能体移交和上下文变量。
• 客户端实现：几乎所有逻辑都运行在客户端。
• 轻量与可定制：特别适合处理大量独立能力和指令的场景，这些能力难以编码到单个提示中。
• 教育目的：旨在帮助开发者了解多智能体编排模式，与提供托管线程和内存管理的 Assistants API 目标不同。

安装与基本用法

• 要求：Python 3.10+
• 安装：通过 pip install 从 GitHub 仓库安装。
• 代码示例：展示了如何定义 Agent、添加移交函数，并通过 client.run() 执行交互。

核心组件

• Agent 字段：包括 name（名称）、model（使用的模型，如 gpt-4o）、instructions（指令，可以是字符串或返回字符串的函数）、functions（可调用的函数列表）、tool_choice 等。
• 指令（Instructions）：直接转换为系统提示。可以是静态字符串或动态函数（可访问 context_variables）。
• 函数（Functions）：
  • Agent 可直接调用 Python 函数。
  • 函数通常应返回字符串。
  • 关键功能：如果函数返回一个 Agent，执行将移交给该 Agent。
  • 支持通过返回 Result 对象同时更新值、切换 Agent 和上下文变量。
  • 错误会被附加到聊天记录中，以便 Agent 优雅恢复。
• 上下文变量（Context Variables）：一个字典，在 client.run() 时传入，可供 Agent 指令和函数使用，并可在交互过程中更新。

流式处理

支持流式响应，事件流与 Chat Completions API 流式处理相同，并新增了指示 Agent 切换和返回聚合响应的事件类型。

其他

• 文档示例：提供了多个示例（如基本示例、分诊代理、航空公司客服等）以供参考。
• 评估：鼓励开发者使用自己的评估套件来测试 Swarm 的性能。
• 工具：提供 run_demo_loop 函数用于在命令行快速测试 Swarm。

核心贡献者

列出了项目的几位核心贡献者。

总结：Swarm 是一个面向学习和实验的、基于原语（Agent 和 Handoff）的轻量级多智能体编排框架，展示了如何通过客户端逻辑实现灵活的智能体协作。其生产版本已被 OpenAI Agents SDK 取代。

lm.rs 项目概述 lm.rs 是一个使用 Rust 编写的、旨在在 CPU 上本地运行语言模型推理的极简项目，无需依赖任何机器学习库。其灵感来源于 Karpathy 的 llama2.c 和 llm.c。

核心功能与更新

• 模型支持：最初仅支持 Google Gemma 2 模型，现已扩展至支持 Llama 3.2 模型，并最新添加了对多模态模型 PHI-3.5-vision（支持图像输入）和纯文本模型 PHI-3.5-mini 的支持。
• 性能优化：实现了批处理功能，将图像编码速度提升高达约 3 倍。在作者的 16 核 AMD Epyc 机器上，Llama 3.2 1B 模型运行速度达到 50 tokens/秒。
• 开发者说明：项目代码仍有优化空间，开发者借此作为首次编写 Rust 的练习。

支持的模型与性能基准 下表列出了已准备好的量化模型及其在 16 核 AMD Epyc 上的大致推理速度（单位：tokens/秒）。推荐使用 Q8_0 量化版本。

使用方法

1. 获取模型：

   • 可直接从 HuggingFace 下载预先转换好的 .lmrs 格式模型和分词器。
   • 也可自行转换：安装 Python 依赖后，使用 export.py 脚本将原始模型（.safetensors 和 config.json）转换为 LMRS 格式（支持量化选项）。对于多模态模型，还需转换 CLIP 配置文件。随后使用 tokenizer.py 转换分词器。

2. 编译与运行：

   • 使用 Cargo 编译 Rust 代码，建议启用 CPU 原生优化。对于多模态支持，需在编译时添加相应特性（--features multimodal）。
   • 运行编译后的聊天程序，通过 --model 参数指定模型文件，并可调整温度、top-p 等参数。使用多模态模型时，通过 --image 参数传入图片路径。
   • 项目还提供了 WebUI 后端功能，编译时启用 backend 特性即可。

未来计划

• 添加更多采样方法。
• 测试更大模型（如 27B，但预计会很慢）。
• 并行化多头注意力循环。
• 增加性能指标显示。
• 支持系统提示。
• 改进量化支持（int8, int4）。

许可证 项目采用 MIT 许可证。

学校手机禁令对学习氛围产生积极影响

冰岛Öldutúnsskóli学校自2019年初实施手机禁令以来，整体学校氛围与文化得到改善，课堂更加安静。尽管尚未直接研究禁令对识字率和阅读兴趣的影响，但该校学生的阅读兴趣远高于全国平均水平。校长指出，禁令显著减少了校内网络欺凌现象。

屏幕时间与阅读兴趣呈负相关 冰岛大学的研究显示，智能设备使用时间越长，6至10年级学生的阅读兴趣下降越明显。然而，实施禁令的学校学生日均手机使用时间不足30分钟，远低于未实施禁令学校同龄人（部分可达1-3小时）。

禁令的实施与支持 该校经过一年与学生会、校董会及家长的协商后推出全面禁令。禁令不禁止携带手机入校，但禁止在校期间使用。家长和学生普遍接受该政策，学校也通过增设学生活动空间（如乒乓球桌、棋类设施）作为补偿措施。违规处理以教育沟通为主，必要时会要求学生将手机留在家中。

政策效果 禁令使学生课堂专注度提升，社交互动增加，学生活动空间使用率提高。校长强调手机已不再是该校的教学工具，其使用规则已融入校园文化。

• Steam购物提示更新：Steam在游戏购买页面新增提示信息：“购买数字产品将授予该产品在Steam上的许可证”。此变化与加州将于明年生效的法律相关，该法案要求数字商店在销售许可证时需明确告知消费者其购买并非永久所有权。

• GOG的回应：竞争对手GOG借此宣传其无DRM（数字版权管理）政策，并发布概念横幅称：“在GOG购买数字产品将授予你其离线安装包，这些安装包不会被夺走。”GOG强调，尽管其也销售游戏许可证，但提供的离线安装包允许玩家在任何情况下（包括许可问题、商店关闭或网络中断）永久保留并游玩已购游戏。

• 行业对比与讨论：GOG此前曾解释，其“所有权”承诺旨在确保玩家的游戏库不受外部事件影响。尽管两种模式均基于许可证销售，GOG的离线功能被部分玩家视为更可靠的选择，引发了数字游戏所有权与消费者权益的广泛讨论。

本文作者为芝加哥Python用户组（ChiPy）准备了一个关于使用Python编写FUSE文件系统的逐步指导项目。作者在教学中长期使用一个名为FIUnamFS的简易文件系统作为项目，但发现学生很少使用FUSE来实现透明的文件系统接口。他认为现有资料对初学者不够友好，因此创建了一个GitLab项目，提供从零开始的渐进式指南。

该项目包含五个阶段性的示例，从基础的空文件系统开始，逐步添加系统调用和功能，直到实现支持基本stat()操作的可读写内存文件系统，以及只读的穿透文件系统。为了增加趣味性和实用性，作者还提出了一些创意示例，例如DNS文件系统、实时Markdown编译文件系统、解压文件系统和去除注释的文件系统。

作者计划在ChiPy（线上）、阿根廷的Jornadas Regionales de Software Libre（线上）以及墨西哥城的nerdear.la（线下）等会议上分享此项目，并将用于教学，希望能鼓励更多学生使用Python实现FUSE文件系统。

Windows资源编译器 (rc.exe) 的怪癖与错误总结

本文总结了通过模糊测试和逆向工程发现的Windows资源编译器 rc.exe 的一系列非预期行为、边缘情况及错误。作者旨在实现一个与 rc.exe 输出完全一致的Zig语言资源编译器 resinator，在此过程中记录了大量怪异现象。

背景与动机

作者因Zig语言需支持编译 .rc 文件而着手实现 resinator。尽管已有开源替代方案（如 windres, llvm-rc），但为实现与 rc.exe 字节级兼容，需从零开始研究。主要方法是模糊测试，以 rc.exe 为真相源，发现了大量文档未载、行为不一致或直接错误的问题。

核心发现与关键怪癖

以下为部分最具代表性的发现，按类别归纳：

1. 词法与解析器怪癖

• 标识符/ID的特殊标记化：资源ID和类型仅以特定ASCII字符（0x05-0x20）为分隔，导致带引号的类型名（如 "FOO"）会包含引号本身写入 .res 文件。
• 非ASCII数字：允许非ASCII字符（如 ²）作为数字字面量，但计算规则错误，导致任意数值（如 ००० 解析为十进制65130）。
• 文件名即表达式：资源文件名可接受数字表达式（如 (1 | 2)+1），但编译器仅使用表达式中最后一个数字字面量作为文件名。
• 单目运算符是幻觉：- 和 ~ 不是独立运算符，而是数字字面量的一部分（如 -1 是一个token）。+ 的行为则极其不一致。
• 对话框MENU语句的ID误解析：在 DIALOG/DIALOGEX 的 MENU 语句中，若ID首字符为数字，则整个ID会被强制解析为数字，导致资源加载错误（始终属于误编译）。

2. 误编译与安全问题

• VERSIONINFO中的逗号省略：VALUE "key" "value"（省略逗号）会导致缺少对齐填充字节，使 VerQueryValue 等函数读取到错误数据，破坏整个版本信息结构。
• CONTROL样式参数中的额外标记：CONTROL 的样式参数后可意外跟入一个额外标记（如字符串），该标记会被静默忽略，可能导致后续参数错位。
• CONTROL类名指定为数字时的错误编码：将类名指定为数字（如 0x80）时，编码结果与预期不符，会导致控件无法识别。
• 图标/光标资源的恶意文件处理：
  • 一个声明大小超过实际文件大小的微小图标文件，可被编译成最大127 TiB的 .res 数据。
  • 若声明大小超过2 GiB（被解析为负数），编译器可能进入无限循环。
• 位图资源中缺失的调色板：若 .bmp 文件缺少预期的调色板字节，rc.exe 不会报错，而是错误地读取后续像素数据作为调色板，导致渲染错误或安全风险（可强制生成超大资源）。

3. 预处理器与编码问题

• 多行字符串行为异常：不带 \ 续行的跨行字符串被允许，且其中的空白字符会被错误折叠。
• 引号转义规则冲突：编译器使用 "" 转义引号，但预处理器仍按C规则处理 \"，导致预处理后与编译器期望不一致，引发难以理解的错误。
• 制表符影响输出：字面制表符 (\t) 会被预处理器根据其列位置转换为可变数量的空格，影响最终数据。
• 输入/输出代码页不同步：当 #pragma code_page 是文件第一个内容时，它可能只设置输入代码页，而输出代码页仍使用默认值，导致字符编码混乱。

4. 未记录行为与特定码点问题

• 未记录的资源类型：如 DLGINCLUDE（供对话框编辑器使用）、DLGINIT（初始化控件数据）、TOOLBAR（定义工具栏），这些类型虽被识别但行为未文档化。
• 特定Unicode码点引发的故障：
  • U+FFFE 和 U+FFFF 的出现会导致整个文件中所有非ASCII码点被字节交换，完全破坏编码。
  • U+0000 (NUL) 在文件中的位置会影响错误是否发生。
  • U+001A 被视为文件结束符，其后内容被忽略。
• 奇怪的命令行选项：如 /sl 控制字符串长度百分比（且到100时可能崩溃）、/s 插入名为 HWB 的未文档资源、/z 涉及字体替换等。

5. 基础概念冲突

• NOT表达式的不可理解性：NOT 运算符的行为极度异常，如 NOT (1 | 2) 和 NOT () 2 等无效表达式却被接受，且结果难以预测。
• 所有运算符具有相同优先级：资源编译器中的运算符优先级与C预处理器不同，存在根本性差异。

结论

本文揭示了 rc.exe 作为一个历史悠久的闭源工具，其内部存在大量边缘情况、未定义行为和直接错误。这些发现不仅对微软本身是详尽的bug报告，也为其他试图实现兼容性的开源项目（如 llvm-rc, windres）提供了测试用例，同时展示了模糊测试在暴露此类隐蔽问题上的强大能力。resinator 项目旨在规避这些陷阱，提供更健壮和可预测的编译体验。

Windows 11 24H2 用户在安装近期发布的功能更新后，发现设备上存在无法删除的残留数据。许多用户报告称，尽管多次尝试清理，系统仍显示占用 8.63 GB 磁盘空间的“Windows Update Cleanup”文件无法被移除。

通常，Windows 更新后会保留旧版本文件副本，用户可通过系统设置或“磁盘清理”工具回收空间。然而，此次问题中，8.63 GB 的数据无论重启或反复清理都持续存在。微软反馈中心已有多名用户确认遇到此问题，但微软尚未回应。

这很可能与 Windows 11 24H2 中引入的“检查点累积更新”机制有关。该机制旨在减小更新体积，但需要保留一个检查点作为后续更新的基础，这可能是占用空间的主因。问题在于，系统虽将这些文件列为可删除的旧更新，清理工具却无法移除它们。手动删除可能影响未来更新安装。

当前，系统报告的可清理空间与实际无法回收的情况存在矛盾，微软需要更新其空间使用报告方式，以避免用户困惑。此存储占用问题短期内可能持续存在。

谷歌正在为Android开发官方的Linux终端应用，使用户能够在Android设备上运行Linux应用程序。该功能类似于Chrome OS上的Linux容器支持，主要面向开发者。

核心功能与技术背景

• 应用目的：为Android设备提供官方支持的Linux运行环境，方便开发者使用命令行工具和开发软件。
• 实现方式：基于Android虚拟化框架（AVF），通过虚拟机运行Debian系统。终端应用内置WebView，通过本地IP连接虚拟机。
• 启用方式：未来将集成到“设置 > 系统 > 开发者选项”中，用户可一键启用。

当前开发状态

1. 自动配置：目前需手动配置虚拟机，但谷歌计划将“LinuxInstaller”应用（用于自动下载和配置Debian）合并到终端应用中，实现一键安装。
2. 功能增强：终端应用将增加设置页面，支持调整磁盘大小、端口转发等；AVF框架也在改进，包括快照备份、嵌套虚拟化和x86_64架构支持。
3. 设备兼容性：已在Pixel Tablet和Pixel 9 Pro XL上测试，表明该功能不仅限于Chromebook，也可能面向移动设备。

潜在影响与局限性

• 开发者受益：可运行Linux版Android Studio等开发工具，提升Android作为开发平台的实用性。
• 架构限制：多数Android设备使用ARM架构，而部分Linux应用仅支持x86，因此应用兼容性可能有限。
• 未来意义：随着Chrome OS与Android融合，此功能有助于推动Android成为更完整的桌面级平台。

谷歌预计该功能可能随明年Android 16更新发布，目前仍在完善终端应用和AVF框架。

文章标题：我的WordPress Slack被封禁事件

主要内容如下：

几天前，作者因在WordPress社区Slack中质疑一个新添加的强制性复选框而被封禁。该复选框出现在wordpress.org登录页面，要求用户声明“不与WP Engine有任何关联”。由于作者的工作代表MariaDB基金会，其登录使用基金会邮箱，因此担忧声明范围的模糊性可能带来法律风险，并可能牵连基金会。

讨论主要集中在Slack中，作者与他人要求澄清“关联”的具体界定，特别是与WP Engine的间接财务联系。WordPress创始人Matt Mullenweg强调复选框的勾选值不会被存储，但作者指出，登录记录本身已间接构成存储。随后，作者被踢出并永久禁止访问Slack服务器。

作者认为，许多社区成员因类似担忧不愿登录，而WP Engine和WordPress官方的回应并未完全消除疑虑。作为非营利组织，MariaDB基金会难以承担潜在的法律费用，因此作者选择谨慎行事。

在个人层面，作者自认贡献有限，主要涉及数据库支持和社区交流。但他指出，同时被封禁的其他成员对社区更为重要，他们的失声对社区造成更大损害。作者希望停止附带伤害，让社区能够愈合，并强调贡献不限于代码，还包括文档、翻译、社区建设等。

最终，作者表达了对WordPress社区价值观的认同，并表示即便自己的封禁持续，也更希望恢复其他重要贡献者的声音。他将继续以力所能及的方式支持社区。

Gleam 是一种静态类型的函数式编程语言，其 v1 版本近期已发布。它受 Elm 和 Rust 启发设计，旨在构建可扩展且易维护的软件。该语言可编译为 Erlang 和 JavaScript，因此特别适用于构建并发和分布式系统。

环境准备 设置开发环境需要三个核心组件：

1. Gleam 编译器：从 GitHub 仓库下载预编译版本。
2. Erlang：从 Erlang-Solutions 网站安装。
3. Rebar3：根据其官方指南安装，这是一个构建工具，在开发 Web 服务器和 HTTP 客户端等场景下必不可少。 此外，建议安装编辑器插件以支持 Gleam 的语法高亮。

基础语法与示例

1. 第一个程序：创建一个 hello.gleam 文件，通过 gleam run 命令执行，输出“Hello, Gleam!”。
2. 变量与类型：Gleam 是静态类型语言，变量需声明类型。基本类型包括 String、Int、Bool 和列表等。io.debug 函数可用于输出任意类型的值。
3. 算术运算：支持标准的算术运算符（如 +, -, *, /, %）、比较运算符（如 >, <）以及相等性判断（==）。标准库的 gleam/int 模块还提供了如 max、clamp 等实用函数。
4. 函数：函数是核心构建块。可以使用 fn 关键字定义函数，并通过名称进行调用。函数参数和返回值需声明类型。
5. Case 表达式：用于进行模式匹配，处理不同条件。它可以匹配具体值，也可以使用 _ 通配符匹配其他所有情况，结构简洁且富有表达力。

总结 Gleam 结合了函数式编程的表达力与构建并发分布式系统的性能优势。其静态类型系统提升了软件的健壮性和可维护性，同时语法设计注重简洁，易于上手。

SSR I戒断中的“脑电击”现象：从被忽视到受关注

现象定义与体验 “脑电击”是一种非官方称呼的感官体验，常见于患者逐步停用选择性5-羟色胺再摄取抑制剂（SSRI）期间。患者描述其感觉类似头部内部遭受电击，每次持续约一秒钟。亚历山大·帕普医生解释，这种感觉虽源自脑部，但实际发生于脑膜周围神经表面。伴随症状常包括横向眼动时的“嗖嗖”声感、头晕、失眠、视力变化及平衡问题，可能引发患者恐慌，误以为癫痫或心脏病发作。

医学界认知的演变 长期以来，医生对该症状缺乏认识或持否定态度。帕普指出，早期精神科与药企更强调抗抑郁药“无成瘾性”，导致对停药效果的系统研究不足。如今，医学界更全面认识“抗抑郁药停药综合征”，但脑电击机制仍未完全明确。

生理机制推测 研究表明，脑电击的发生与血药浓度下降速度密切相关。半衰期短的药物（如帕罗西汀）更易引发该症状，而半衰期长的药物（如氟西汀）风险较低。帕普认为，血药浓度骤降是主要诱因。

患者反馈与影响 患者社区（如Reddit）描述该体验为“脑部电流感”、“间歇性刺痛”，甚至导致语言中断。许多人因恐惧而恢复用药或放弃减药计划，成为停药的主要障碍。案例显示，快速减药或初期因不良反应停药者更易出现严重脑电击。

应对策略 目前尚无根治方法，但可通过以下方式缓解：

1. 渐进减药：避免骤停，缓慢降低剂量。
2. 药物转换：从短半衰期药物换为氟西汀等长半衰期药物后再逐步减量。
3. 心理支持：减药期间配合认知行为疗法（CBT）可能减轻症状。

长期影响与临床提示 尽管多数人最终能成功停药，少数患者可能持续出现脑电击等停药反应长达数年。该症状可显著影响生活质量，临床医生需将其纳入停药方案设计，以提升戒断成功率。

充满爱意的机器：人工智能如何让世界变得更好

作者立场与目的

作者是Anthropic公司的CEO，长期关注并研究强大人工智能的风险，但他并非悲观主义者。他认为AI的潜在益处被低估，而风险亦然。本文旨在描绘一个“如果一切顺利”的正面未来愿景，但承认这是推测性的。作者解释了为何公司更多讨论风险：为最大化影响力（市场驱动益处，但风险可被干预）、避免宣传嫌疑、避免宏大叙事以及避免“科幻”包袱。然而，他强调拥有鼓舞人心的愿景至关重要。

核心框架与“强大AI”的定义

文章假设一种“强大AI”（作者偏好此词而非AGI）即将出现，并探讨其后5-10年的影响。该AI被设想为：

• 智力超群：在多数领域超越诺贝尔奖获得者。
• 多接口能力：拥有文本、音频、视频、互联网访问等虚拟接口，能执行人类可进行的远程操作。
• 自主执行任务：能接受长期任务并自主完成。
• 无实体但可操控物理工具：通过控制机器人或实验设备与物理世界互动。
• 可大规模复制与高速运行：可运行数百万实例，速度是人类的10-100倍。
• 可独立或协作工作：如同“数据中心中的天才国家”。

作者认为，AI的进步受外部世界速度、数据需求、内在复杂性、人类约束和物理定律等“互补因素”限制。短期内这些因素是瓶颈，但长期来看，智能本身可能绕过它们。

AI变革的五大领域

1. 生物学与身体健康

作者认为生物学是AI最能直接改善人类生活质量的领域。关键限制是实验速度、数据质量和生物复杂性。AI不应仅被视为数据分析工具，而应作为“虚拟生物学家”全程参与研究（设计实验、运行机器人、发明新方法）。历史上，生物学的进步主要由少数关键发现（如CRISPR、mRNA疫苗）驱动，这些发现往往由小团队做出且可被提前发现。因此，强大AI可能将未来50-100年的生物学进步压缩到5-10年内实现。预期成果包括：

• 可靠预防和治疗几乎所有自然传染病。
• 消除大多数癌症（死亡率和发病率降低95%以上）。
• 有效预防和治疗遗传疾病。
• 预防阿尔茨海默病。
• 改善其他疾病的治疗。
• 实现“生物自由”（控制体重、外貌、生殖等）。
• 使人类寿命延长一倍至150岁，并可能达到“逃逸速度”。

2. 神经科学与心理健康

神经科学是生物学的子领域，同样受AI加速。AI的进步（如可解释性）本身也能推动神经科学。AI可通过四条路径加速进展：传统分子生物学、精细神经测量与干预、高级计算神经科学以及行为干预。预期成果包括：

• 治愈大多数精神疾病（如PTSD、抑郁、精神分裂症）。
• 通过大脑重塑治疗结构性疾病（如心理变态）。
• 通过基因筛查预防精神疾病。
• 解决日常心理问题（如注意力不集中、焦虑）。
• 提升人类基线体验（更多领悟、创造力、满足感等）。

3. 经济发展与贫困

作者对AI解决不平等和发展问题的信心低于技术革新，因为经济受人类约束和复杂性影响。但仍持乐观态度。预期进展：

• 健康干预的全球分发：AI优化流行病模型和物流，5-10年内将50%的AI健康益处带给最贫困地区。
• 经济增长：“AI财政部长”可能助力发展中国家实现类似东亚奇迹的高速增长（如20%年增长率）。
• 粮食安全：AI驱动第二次绿色革命。
• 缓解气候变化：AI加速清洁技术开发，降低成本。
• 应对国家内不平等：市场经济和政治压力可能推动技术普及，但财富不平等问题更复杂。
• “退出”问题：可能有人拒绝AI益处，形成恶性循环，但历史上反技术运动往往失败。

4. 和平与治理

作者认为AI不会自动促进民主与和平，这是需要争取的目标。策略包括：

• 国际层面：民主国家联盟应通过“和谐战略”获取AI优势，以军事实力为后盾，同时向世界提供AI益处，逐步扩大民主阵营。
• 国内层面：在一个民主领先的世界，AI可能结构上有利于民主（如提供信息自由工具、对抗宣传）。生活质量提升、心理健康改善和教育普及也可能促进民主。
• 改善民主制度本身：AI可用于改进司法系统（更公正的判决）、促进公民共识、提升政府服务效率，从而强化法治和平等承诺。

5. 工作与意义

这是最模糊且难以预测的问题。

• 意义问题：作者认为意义主要源于人际关系，而非经济劳动。即使AI能做得更好，人类仍可从挑战、竞争和创作中获得意义。
• 经济问题：短期内，比较优势可能保持人类相关性。但长期来看，当AI变得极其高效和廉价时，当前经济体系将不再适用。需要全新的社会经济组织形式，可能包括大规模全民基本收入、AI系统主导的资源分配等。这需要通过迭代实验来探索，并防止剥削性方向。

总结与愿景

作者描绘了一个AI在5-10年内实现的激进但美好的未来：疾病被战胜、生物与认知自由得以实现、数十亿人脱贫、自由民主得到复兴。他认为这些价值（公平、合作、自主）本身具有道德吸引力，是竞争下的“制胜策略”，而AI加速了这一进程。尽管实现需要巨大努力和斗争，但这是一个值得为之奋斗的愿景。

微波炉发展简史

1940年代：技术起源 微波加热的想法约在1940年萌生，与核技术发展同期。其原理基于介电加热：特定频率（如2.45 GHz）的无线电波能使水分子等极性分子旋转，从而产生热量。二战催生的雷达技术，特别是腔体磁控管，为此奠定了基础。

1947-1950年代：商用与家用开端 1947年，Raytheon公司推出首台商用微波炉“Radarange 1132”，功率1600W，需水冷，体积庞大。其基本原理是用2.45 GHz无线电波照射置于法拉第笼中的食物。当时发现2.45 GHz频率与食品加热匹配良好，且设备制造成本低。

同时期，通用电气（GE） 试验了穿透力更强的915 MHz频率。经美国联邦通信委员会（FCC）仲裁，为微波炉分配了915 MHz和2450 MHz两个频段，后者至今用于所有家用微波炉。

技术不断改进：1954年出现风冷型号；为防止微波泄漏，微波炉采用法拉第笼设计，门边有扼流结构，且开门时会自动切断磁控管电源。1954年，科学家曾用微波炉成功复活冷冻仓鼠。

1960年代：进入家庭 1962年，夏普开始量产微波炉。1967年，Amana推出RR-1型号，以约495美元的价格成功打入家用市场，尽管功能简单（仅有时间旋钮）。同年，金属器皿禁用、辐射泄漏担忧引发安全事故和公众疑虑。1968年，美国通过《辐射控制健康与安全法案》，强化了安全标准。

1970-1980年代：功能创新 技术演进聚焦于提升易用性与烹饪效果：

• 自动解冻：1974年出现，通过磁控管间歇工作实现低功率解冻。
• 数字界面与传感器：1975年首个数字界面，1978年配备温度探头，1983年出现基于重量的自动烹饪。
• 组合烹饪：出现结合微波与对流加热的型号，以改善食物褐变。
• 智能干扰：1985年FCC开放ISM频段给低功率通信，导致微波炉工作时常干扰Wi-Fi。

1990-2000年代：效率与智能化

• 变频技术：2009年，松下推出采用变频电源的微波炉，可实现更平滑的功率调节，显著改善解冻效果，但会对邻近Wi-Fi网络造成更强干扰。
• 智能与连接：2014年出现基于声音监测的爆米花模式，2015年概念性产品出现热图显示功能。
• 褐变技术：1999年GE Advantium使用石英卤素灯红外褐变；2017年松下重新引入褐变元件。

2010年代至今：精准与集成

• 固态RF技术：约2015年后，概念微波炉开始探索使用固态放大器替代磁控管，通过频率/相位调节实现更均匀的加热。
• 自适应烹饪：2017年，Miele Dialog微波炉采用发射器/传感器反馈回路，可精准调控能量，实现精细烹饪（如仅加热三文鱼一侧）。
• 智能互联：2018年出现支持Alexa语音控制的微波炉，可进行简单烹饪并自动补充耗材。
• 市场格局：2020年后，供应链报道指出，包括东芝、通用电气、惠而浦等多品牌中低端产品均由美的等中国制造商生产。
• 创新形态：2023年，牧田推出500W电池供电的便携微波炉。

微波炉从笨重军用设备演变为智能厨房核心，其历史体现了雷达技术民用化、材料科学进步及对用户便利性的持续追求。

DuckStation 模拟器摘要

DuckStation 是一款专注于可玩性、速度和长期可维护性的 Sony PlayStation 模拟器。其目标是在保持低端设备适用性能的同时，尽可能追求准确性。它默认配置支持所有可运行的游戏，不鼓励使用“hack”选项。

主要功能

• 跨平台支持：提供 Windows、Linux、macOS 和 Android 版本。
• 强大的前端：基于 Qt 的全功能界面，以及基于 Dear ImGui 的全屏/电视用户界面。
• 高性能渲染：
  • 支持 D3D11、D3D12、OpenGL、Vulkan、Metal 等硬件渲染 API。
  • 支持分辨率提升、纹理过滤、PGXP（几何精度校正）、准确的混合模式。
  • 向量化、多线程的软件渲染器。
• 全面的输入支持：数字/模拟控制器、光枪（GunCon、Justifier）、NeGcon、多分插器（最多8个设备）。
• 丰富的游戏兼容性：支持直接读取 CD、多种镜像格式（bin/cue、CHD、PBP等），可为受 LibCrypt 保护的游戏自动加载 SBI 文件。
• 便捷功能：
  • 存档状态、运行超前和回溯。
  • 快速启动（跳过 BIOS 启动画面）。
  • 自动内容扫描与游戏识别。
  • 内置作弊码和补丁数据库。
  • 存档编辑器与导入器。
  • Discord Rich Presence、RetroAchievements 支持。
  • 视频捕捉、自由相机等功能。
• 自动更新：提供“稳定版”和“预览版”更新频道。

系统要求

• CPU：需要支持 SSE4.1 指令集的 x86_64 CPU，或 ARMv7/AArch32、AArch64、RISC-V/RV64 架构。
• GPU：需要支持 OpenGL 3.1 / OpenGL ES 3.1 / Direct3D 11 Feature Level 10.0 / Vulkan 1.0 的显卡。
• 运行环境：需要 PS1 或 PS2 的 BIOS 镜像文件（需用户自行从主机转储）。

下载与运行

• 最新版本可从 GitHub Releases 页面获取，涵盖 Windows、Linux (AppImage) 和 macOS。
• Windows：提供安装程序（.exe）和压缩包（.zip）两种格式。系统需为 Windows 10 1809 或更新版本。旧版 CPU 可下载 SSE2 版本。
• Linux：以 AppImage 格式发布，要求等效于 Ubuntu 22.04 或更新的系统。
• macOS：提供通用二进制文件，要求 macOS Ventura (13.3) 或更高版本。首次运行需在系统设置中允许来自未认证开发者的应用。
• Android：可从 Google Play 安装，但官方不提供技术支持。

构建说明

项目提供了从源代码构建的指南：

• Windows：需要 Visual Studio 2026 及以上版本，使用提供的依赖包和解决方案文件进行构建。
• Linux：需要安装一系列开发依赖包（针对 Ubuntu/Debian 和 Fedora 列有详细包名），使用 CMake 和 Ninja 进行构建。
• macOS：需要 CMake 和 Xcode，使用 CMake 构建。

用户目录与配置

用户目录用于存放 BIOS、设置和存档。其默认位置因平台而异：

• Windows: AppData\Local\DuckStation
• Linux: ~/.local/share/duckstation
• macOS: ~/Library/Application Support/DuckStation

可通过创建 portable.txt 文件来启用便携模式（用户目录与程序目录相同）。输入设备绑定可在设置中自定义，也支持 SDL 游戏控制器数据库的自定义映射。

免责声明

“PlayStation” 是 Sony Interactive Entertainment Europe Limited 的注册商标，本项目与索尼公司无关。模拟器图标来自 icons8。

摘要内容

大型语言模型（LLM）缺乏真正的形式推理能力，其行为更接近于复杂的模式匹配，且这种匹配非常脆弱。一篇来自苹果公司六位AI研究人员的新文章（及相关总结）提出了这一核心观点，并得到了多项研究的证据支持。

主要发现与证据：

1. 易受无关信息干扰：苹果团队开发的GSM-NoOp测试表明，只需在问题中加入无关的干扰信息（如添加几个无关数字），LLM的正确率就会显著下降约10%。这并非新现象，斯坦福大学早在2017年的类似研究中就已得出相近结论。
2. 随问题规模增大而性能衰退：无论是数学推理（如整数乘法）还是规划任务（如GPT-o1的测试），LLM的表现都会随着问题复杂度或规模的增加而急剧下降。相比之下，计算器等基于形式规则的系统则能保持100%的准确率。
3. 无法遵循严格规则：在国际象棋等需要严格遵守规则的游戏中，LLM也持续出现违反规则的错误，进一步印证了其形式推理的缺失。

核心结论与作者观点：

• 作者Gary Marcus（基于其自1998年以来的研究）强调，标准神经网络架构无法可靠地进行外推和形式推理，这是其根本性缺陷。
• 他认为，在当前架构下，不可能构建出可靠的AI智能体，因为其输出对输入的微小不相关变动都过于敏感。
• 他质疑当前LLM领域“很快就能解决”的乐观预测，并主张未来的突破需要符号操作——即像传统计算机编程或代数那样，用变量和基于变量的运算来抽象地表示知识。
• 因此，神经符号AI（结合神经网络与符号操作机制）被视为推动人工智能进一步发展的必要条件。

文章批评了LLM爱好者将个别错误视为偶然现象的观点，认为上述研究中观察到的模式广泛而系统，揭示了当前LLM的根本局限性。

Tandem NonStop系统与容错设计原理总结

系统失败的原因与高可用性

任何系统都可能因管理、配置、维护、电源、硬件故障等因素而失败。衡量系统可靠性的关键指标是平均无故障时间，即系统总运行时间除以故障次数。为实现高可用性，硬件设计的关键见解是将系统分解为模块，使模块成为故障和替换的单元，从而通过备份模块隔离故障，避免整个系统崩溃。

软件高可用性的核心原则

软件系统借鉴了硬件的模块化思想，将系统分解为服务单元，以实现故障隔离。Tandem NonStop架构的核心理念在于：

1. 通过进程和消息传递实现模块化。
2. 故障隔离：进程应能快速失败，检测到故障后发送失败信号并停止运行，不共享状态。
3. 进程对：使用主进程和备份进程的组合来提供容错。
4. 数据完整性。

故障类型与进程对策略

Jim Gray在其研究中将软件缺陷分为两类：

• Bohrbug：在操作期间会导致关键故障。
• Heisenbug：更隐蔽，可能在系统中潜伏多年。

基于此，文章介绍了几种实现进程对的策略：

• 锁步执行：主备进程执行相同任务，主进程故障时备份继续。适用于硬件故障，但对Heisenbug无效。
• 状态检查点：一个请求实体连接到进程对，主进程停止时切换到备份进程。
• 自动检查点：由内核管理检查点。
• 增量检查点：使用逻辑更新而非物理状态进行检查。
• 持久化：主进程故障时，备份进程从无状态开始运行，需设计同步机制。

与Erlang/BEAM虚拟机的关联

Erlang虚拟机的设计深受Tandem NonStop系统启发，两者在实现高可用性方面理念高度相似：

• 目标一致：都旨在实现高可用性。
• 故障隔离至关重要：通过隔离操作来容纳故障。
• 进程不共享状态：这是构建模块化系统的关键。
• 进程间交互：是在存在错误的情况下维持运行的关键。Tandem实现了进程对设计，而Erlang实现了OTP模式。

在Erlang/Elixir/Gleam中，进程是基本抽象单元，其特性包括：

• 强隔离实体。
• 创建和销毁是轻量级操作。
• 仅通过消息传递进行交互。
• 不共享状态。
• 要么完成任务，要么失败。

结论

理解Tandem NonStop系统等历史设计有助于我们认识现有工具和技术（如Erlang OTP）背后的理念。对于软件开发者，尤其是Elixir开发者，深入理解进程模型和基于模块化、故障隔离的容错设计原则至关重要，这有助于构建真正具有弹性的高可用系统。

“坚忍号”沉船新影像揭示惊人保存状态

历史背景与发现

• 沙克尔顿的探险船“坚忍号”于1915年在南极威德尔海被浮冰困住并沉没。2022年，这艘沉船在海面下3公里深处被发现。
• 船只失事后，船员被迫展开了一场史诗般的生存之旅，最终全员获救，成为历史上著名的生存奇迹。

新影像与保存状况

• 根据沉船发现时由水下机器人拍摄的25,000次数字扫描合成的新图像显示，船只保存状态异常完好。
• 船体的索具、舵轮和木制结构均保存完好，仿佛“昨天才沉没”。甲板上仍可见船员的餐盘和一只及膝长靴。
• 最引人注目的发现之一是散落在残骸中的一柄信号枪。根据探险队摄影师弗兰克·赫尔利的日记记载，这正是他为向船只致敬而在其沉没时发射的那把信号枪。

技术细节与成像技术

• 这些复合影像是首次运用激光和摄影测量技术在此深度进行扫描的成果，由多个组织合作开发完成。
• 影像显示了船体在沉没前被冰挤压造成的损坏，这与赫尔利当时拍摄的开创性影片资料相符，但除此之外船体结构基本未变。

相关纪录片与AI应用

• 新影像的发布伴随着国家地理频道一部新纪录片的推出。该片除了记录寻找“坚忍号”的过程，还创新性地使用了人工智能技术。
• AI工具被用来重建沙克尔顿及六名船员的声音，用他们“自己的声音”来朗读日记内容，为影片增添了全新的叙事维度。

Kagi Snaps 功能摘要

功能定义
Snaps 是一项搜索功能，允许用户使用 @符号 + 网站短代码 快速限定搜索结果范围至特定网站。例如，输入 @r headphones 会将“headphones”的搜索结果限制在 Reddit 网站内（其中 r 是 Reddit 的短代码）。该功能通过 Kagi 的搜索索引实现，效果等同于使用 headphones site:reddit.com 的传统搜索语法。

与 Bangs 的区别

• Snaps：使用 @ 符号，在 Kagi 界面内直接返回限定网站的搜索结果。
• Bangs：使用 ! 符号（如 !r headphones），会将用户重定向至目标网站的内部搜索页面。

使用方法

1. 在搜索栏输入 @ 符号。
2. 输入网站短代码（若不熟悉可输入网站名称部分字母，系统将自动补全建议）。
3. 通过键盘或鼠标选择目标网站。
4. 输入搜索关键词。
5. 按回车或点击搜索按钮执行搜索。

短代码的贡献与扩展
Snaps 使用的短代码与 Bangs 功能共享同一列表。该列表为开源项目，用户可通过提交 Pull Request 添加新网站的短代码，从而扩展可用范围。

INTELLECT-1：启动首个10B参数模型的去中心化训练

项目概述

Prime Intellect 启动了 INTELLECT-1，这是全球首个对10B（100亿）参数模型进行分布式训练的项目。该项目邀请全球任何人贡献算力参与，旨在推动开源通用人工智能（AGI）的发展。这建立在其先前开源的 OpenDiLoCo（分布式低通信方法）成功将模型训练规模扩展到1B参数的基础之上，此次是将规模进一步扩大10倍（相比原始研究约25倍）。

技术基础与目标

• 核心方法：采用 DiLoCo（分布式低通信） 方法，该方法允许在不同设备集群上进行数据并行训练，并仅需每隔几百步同步一次伪梯度。这极大降低了通信频率（最高500倍）和带宽需求。
• 目标：解决分布式训练中的关键挑战，确保未来前沿的开源基础模型（涵盖语言、智能体、科学模型等）能够以开放、透明和可访问的方式训练。

合作伙伴与贡献方式

• 合作伙伴：获得了Hugging Face、SemiAnalysis、Arcee、Hyperbolic、Olas、Akash、Schelling AI等领先开源AI机构的支持和计算资源贡献。
• 贡献算力：任何人均可通过其平台贡献计算资源，未来也将支持使用自有硬件参与。

技术突破：Prime分布式训练框架

为支持此次大规模训练，团队推出了全新的分布式训练框架 Prime，并在两个维度上取得了进展：

1. 算法优化

• 基于OpenDiLoCo的实验表明，通过对伪梯度进行int8量化，可将带宽需求进一步降低高达2000倍。

2. 工程框架（Prime核心特性）

该框架旨在实现跨全球分布式数据中心的容错训练，具备弹性，支持动态添加或移除计算资源。

• 弹性设备网格（ElasticDeviceMesh）：实现了容错通信。通过心跳机制检测节点故障，并能动态调整全局进程组，而非崩溃重启。
• 异步分布式检查点：为了减少保存大型模型检查点的阻塞时间（可达20分钟），先将检查点快速保存到内存文件系统（/dev/shm），再由子进程异步复制到磁盘和上传远程。
• 实时检查点恢复：允许新节点在训练中途加入，通过点对点HTTP服务快速从同伴节点获取最新检查点，并直接加入下一次同步步骤，避免延迟现有节点。
• 自定义Int8全归约内核：自行实现了完全流水线化的C++环归约内核和优化的量化/反量化操作（速度提升60倍以上），以支持int8伪梯度通信，并减少载荷大小4倍。
• 最大化带宽利用：通过在节点内分片伪梯度以同时打开多个连接，并使用VPN技术优化点对点路由，将节点间带宽利用率相比之前提升了最高40倍，达到了4Gb/s。
• PyTorch FSDP2 / DTensor ZeRO-3实现：利用FSDP2在节点内GPU间对模型权重、梯度和优化器状态进行分片，以在有限内存中训练10B参数模型。
• CPU卸载：DiLoCo优化器所需的所有张量都卸载到CPU内存，由于同步间隔长，CPU的额外开销可忽略不计。

INTELLECT-1 模型与训练详情

• 模型：基于 Llama-3 架构的10B参数模型。
• 数据：在高质量开源数据集 Fineweb-Edu（占55%）上大规模训练，数据混合还包括DLCM (20%)、Stack v2 (20%) 和 OpenWebMath (5%)。经过预处理和混合后，总数据量超过6万亿token。
• 训练设置：
  • 使用WSD学习率调度器（训练末尾将使用高质量数据集进行冷却）。
  • 每100步进行一次DiLoCo外部优化器同步（在8xH100节点上约需40分钟）。
  • 通信使用int8量化伪梯度，通信时间仅占总训练时间的1-2%。
  • 实现了跨多个分布式工作者98%的计算利用率。

未来路线图

INTELLECT-1是第一步。后续计划包括：

1. 将分布式训练扩展到更大、更强的科学、推理和编码领域的开源前沿模型。
2. 开发一个计算资源市场，允许任何人贡献其计算资源。
3. 创建一个平台，使任何人都能利用分布式计算发起训练任务。

结论

该项目通过开创性的分布式训练框架和全球社区协作，成功实现了首个10B参数模型的去中心化训练，为构建开放、民主化的AI未来奠定了关键基础。

该讨论围绕“哪些突破帮助你建立并维持了更好的人际关系”这一主题，汇集了众多用户的个人经验与建议。核心观点可归纳为以下几个方面：

一、 关系建立的核心原则

1. 情感脆弱性与真实性：学会适度展现自己的情感、想法与不完美是建立深度连接的关键。这能吸引真正契合的人，尽管也可能疏远部分人，但目标是与兼容者建立良好关系，而非取悦所有人。
2. 自信而非操控的沟通：学习自信沟通（如《当我拒绝时我感到内疚》一书所倡导）至关重要，它区别于情感操控，有助于健康关系的建立。
3. 避免“渴求”心态：保持自我价值感，不因害怕孤独而降低标准或容忍不良关系。愿意设定边界、表达异议，这种自信和真实最终会吸引合适的人。
4. 主动性与不强求：主动发起活动邀请是重要的第一步，但不要强求对方同等回报。需理解他人可能因忙碌、害羞等原因未能主动联系，这不一定代表不喜欢你。

二、 具体策略与实践

1. 通过共同活动结识朋友：参与需要与他人互动的爱好（如团体运动、艺术课程、志愿活动等）是拓展社交圈的有效途径，尤其对男性而言。
2. 深化关系的方法：
   • 超越浅层社交：简单的喝咖啡、吃饭可能进展缓慢。共同经历（如周末旅行、一起完成项目）能更快地建立共享记忆和信任。
   • “三振出局”规则：可主动邀请某人三次，若对方始终未主动回应或表现出投入，则可能表明关系缺乏互惠，可考虑将精力转向他人。
   • 专注于倾听与好奇：对他人真正感兴趣，多提问、多倾听，比试图引起他人对自己的兴趣更能建立良好关系。
3. 维护关系的智慧：
   • 承担“100%的责任”：考虑为关系的维系承担全部责任，这样即使对方只做到部分，关系总量也能得到保障。
   • 接纳不对称性：理解成人的生活复杂忙碌，关系中的付出可能不对等。可以接受自己常常是那个发起联系的人，只要对方接受邀请并享受相处即可。

三、 个人成长与心态调整

1. 自我认知与价值定义：了解自己的优势、弱点及核心价值观，基于自身而非社会标准定义成功。成为“最好的自己”意味着真诚、有原则，而非追求财富、地位等外在标签。
2. 耐心与韧性：建立深度关系需要时间。在30岁后或搬迁后重建社交圈尤为艰难，需耐心尝试，接触不同人群，并与那些可能社交技能稍弱但本质善良的人建立联系。
3. 处理拒绝与失望：被拒绝（如因生育观念不符）可能是一种“幸运”，因为它避免了未来更大的冲突。要学会不过度个人化地看待他人的疏远或无回应。
4. 降低标准但不降底线：可以放宽对朋友某些“表面瑕疵”的容忍度（如社交技巧、神经多样性），但必须坚守关于人品、尊重等核心价值的底线。

四、 特别见解

• 书籍推荐：《Models》（关于情感脆弱与真实性）、《当我拒绝时我感到内疚》（关于自信沟通）被多次推荐为建立关系的重要读物。
• 对“第一印象”与深度交流的讨论：有人认为得体外表和轻松闲聊是良好开端，也有人认为与“古怪但有趣”的人进行深入探讨更有价值，这取决于个人偏好。
• 针对男性友谊的困境：有观点指出，男性往往不习惯进行深入、个人的交流，这使得建立真正的友谊更加困难。
• 共同解决问题优于纯娱乐：共同创业、组乐队、建房子等协作解决问题的经历，比单纯一起喝酒看电影更能锻造深厚、持久的联系。

总结：建立和维护良好关系是一项需要主动努力、情感投入、自我认知和耐心经营的技能。关键在于以真实和脆弱性为基础，通过共享活动与深度交流寻找契合的伙伴，并在互惠与包容之间找到平衡，最终与那些真正看见并珍惜你真实自我的人建立牢固的联结。

Canary：自托管文档搜索与AI问答工具

这是一个可自行托管的 Algolia DocSearch 替代方案，名为 Canary。它能够实现跨文档（网页）、GitHub Issues 和 Discussions 的搜索与 AI 问答功能。其他数据源（如 OpenAPI、变更日志）的支持即将推出。

主要功能与特性：

• 多源搜索与AI问答：支持在文档、GitHub Issues 和 Discussions 中进行内容搜索和向 AI 提问。
• 灵活的过滤与模式：提供 glob 和标签过滤功能，支持亮色/暗色主题切换。
• 多面板界面：包含独立的“搜索”和“AI问答”面板，用户可便捷切换。
• 易于集成：提供了基于 VitePress 框架的代码示例，展示如何通过自定义组件（如 <canary-root>）快速嵌入搜索与问答功能。

快速开始： 项目文档已发布在 getcanary.dev，用户可前往该网站查阅详细的集成与使用指南。

单字母变量名字典

简介

在 Haskell 中，由于其富有表现力的类型系统和多态性，开发者经常编写高度多态的函数，此时变量名可能只表示“一个函子”或“一个单子操作”。因此，单字母变量名在某些情况下是合适的。本文档整理了围绕这些变量名形成的非官方、大多未被记录的惯例。

重要提示：单字母变量名并非总是最佳选择，它们有时会掩盖代码含义。命名应结合上下文（如函数类型上下文、附近变量或领域知识），例如在经典力学中使用 position a t = ... 是合理的。

本字典主要记录类型变量，同时也会标注重要的值级变量。

字典

a, b, c, d

• 类型变量：通常表示任意基础类型（kind Type），如 Foldable t => t a 中的 a。几乎不用于高阶类型，除非是多态种类的。
• 特殊用法：
  • a（罕见）：可表示 Arrow 类型，但易与常见的“任意基础类型”用法混淆。建议使用 arr 或 infix k。

b

• 值变量：可表示任意 ByteString，但作者不建议使用，更倾向于有描述性名称。

c

• 类型变量：
  1. 表示一个约束（kind Constraint）。
  2. （有时）表示 Category 的箭头类型变量，但容易与约束变量冲突。可考虑使用 cat 或 infix k 代替。

e

• 类型或值变量：表示“错误”或异常类型。在 Either e a 中使用 e 暗示 Either 被用于其 Monad 实例，其中 Left 被视为异常/提前返回。

f, g, h

• 类型变量：表示一个函子或“类函子”类型，包括 Applicative、Alternative 及其对偶版本。
• 值变量：
  • f：任意函数。
  • h：System.IO.Handle。
  • h（罕见）：序列的头部，但 x:xs 记法更常见。

i, j

• 类型变量：表示索引类型（如键值映射的键，或列表、向量的 Int 索引）。
• 值变量：整数值；或（不常见）数据结构的索引（idx 更常见）。

k

• 类型或值变量：
  1. 键值映射的键类型，或映射条目中的键。
  2. （有时）范畴的箭头，常写为中缀。
  3. 值级变量：续延参数（助记：kontinuation）。
• 种类变量：表示多态种类的类型变量。

m

• 类型变量：
  1. 表示一个幺半群（Monoid）。
  2. 表示一个单子（Monad）。
• 值变量：单子操作；或一个映射（如 Data.Map.Map），但无上下文含义。
• 注意：当需要第二个此类变量时，有时使用 n，但易与 m 混淆。建议使用 m'、m1、m2 或（对于单子函子）f 和 g。

n

• 类型变量：类型级自然数。
• 值变量：数值量（常为 Natural 或整型），常用于递归函数中的单数值归纳变量。

p

• 值变量：
  1. 一个命题——一个无上下文含义的 Bool。
  2. （罕见）一个“谓词”。谓词几乎总是表示为 a -> Bool 函数，并常命名为 pred_ 或 f。
• 类型变量：表示一个余函子（Profunctor）或其值。

p, q

• 类型变量：表示一个余函子或双函子（Bifunctor）及其值。

r

• 类型变量：
  1. “读取器”或“环境”类型，如 ReaderT 中携带的类型。
  2. “返回”或“结果”类型，常用于流以及续延传递风格函数的签名中。
• 值变量：某种结果（作者个人偏好使用 res）。

s

• 类型变量：“状态类型”，如 StateT 中传递的状态。
• 值变量：（有时）任意的 String 或 Text（str 更常用）；或在递归 String 时，c:cs 或 ch:chs 表示字符复数。

s, t, a, b

• 类型变量：常一起出现在透镜或其它光学中。Lens s t a b 表示可从 s 中提取 a，并用 b 覆盖以产生 t。

t

• 类型变量：表示一个可遍历（Traversable）或可折叠（Foldable）结构。
• 值变量：任意的 Text 值；或（有时）时间值（作者建议用更有意义的名称如 now）；或（罕见）序列的尾部。

v

• 类型或值变量：键值映射的值类型，或映射条目中的值。

w

• 类型变量：表示一个余单子（Comonad）（助记：w 是倒过来的 m）。

x

• 类型变量：一个被忽略、不相关或不可访问的类型。

x, y, z

• 值变量：任意值，几乎一无所知。常加后缀 s 表示复数（xs, ys, zs）。

_ (下划线)

• 值变量：通配模式。匹配任何内容但不绑定变量。