macOS沙箱逃逸漏洞研究摘要

概述

本文介绍了在macOS系统中发现的多个沙箱逃逸漏洞（CVE-2023-27944、CVE-2023-32414、CVE-2023-32404、CVE-2023-41077、CVE-2023-42961、CVE-2024-27864、CVE-2023-42977等）。这些漏洞源于一个被广泛忽视的攻击面：存在于PID域中的XPC服务。攻击者利用这些漏洞，可以从受限的沙箱环境逃逸，获得未授权的系统访问权限。

macOS沙箱类型

• 应用沙箱：Mac App Store应用强制使用，限制严格。进程被容器化，所有文件操作限于其数据容器。由沙箱创建的文件默认带有com.apple.quarantine扩展属性，且沙箱内应用无法移除该属性。
• 服务沙箱：苹果守护进程服务使用，限制相对宽松。文件默认不被标记为隔离。

核心攻击面：PID域的XPC服务

• 被忽视的攻击面：传统研究关注系统/用户域的XPC服务。作者发现，存在于PID域的XPC服务（其“Service Type”为“Application”）是一个重大攻击面。
• 关键特性：
  1. 这些服务通常随应用框架加载而自动注册到应用的PID域。
  2. 它们通常没有对传入的XPC客户端进行充分的权限或沙箱检查。
• 利用方法：通过加载特定的私有框架（例如 [[NSBundle bundleWithPath:@“/path/to/framework”] load]），可以将XPC服务注册到当前进程的PID域，随后即可与之通信。

漏洞详情与利用

1. Beta-No-CVE-1 (storagekitfsrunner.xpc)

   • 问题：该XPC服务接受所有客户端，并暴露一个可执行任意系统命令的方法。
   • 利用：加载StorageKit.framework，通过XPC方法runTask:arguments:withReply:执行如touch /tmp/sbx的命令。
   • 修复：macOS Sonoma 14.0前，苹果完全移除了该XPC服务。

2. CVE-2023-32414 (ArchiveService.xpc)

   • 问题：该XPC服务在解压文件时，未将隔离属性传递到解压后的内容。
   • 利用：加载DesktopServicesPriv.framework，通过XPC方法unarchiveItemWithURLWrapper:...解压一个载荷应用（.app）到指定目录，解压出的应用不会带隔离标记，可直接启动。
   • 修复：macOS Ventura 13.4中，增加了对XPC客户端的权限检查。

3. CVE-2023-32404 (ShortcutsFileAccessHelper.xpc)

   • 问题：该XPC服务无沙箱限制，且拥有完全磁盘访问（FDA） 的TCC权限。它允许客户端为任意URL获取读写权限的沙箱扩展令牌。
   • 利用：加载WorkflowKit.framework，通过XPC方法extendAccessToURL:completion:获取目标文件的访问令牌，从而突破沙箱和TCC限制读取任意文件。
   • 修复：macOS Ventura 13.4中，增加了对XPC客户端的权限检查。

4. CVE-2023-41077 (mscamerad-xpc.xpc)

   • 问题：该XPC服务无沙箱限制，并拥有访问照片和可移动卷的TCC权限。通过模拟一个摄像头设备，可以读取任意文件。
   • 利用：加载ImageCaptureCore.framework，挂载一个按特定规则命名的DMG镜像以模拟相机设备，随后通过XPC方法requestReadDataFromObjectHandle:options:withReply:读取任意文件。
   • 修复与绕过：苹果进行了多次修复。
     • 补丁1：允许平台二进制文件连接，但被轻易绕过（通过DYLD_INSERT_LIBRARIES注入）。
     • 补丁2：要求平台二进制文件具有CS_REQUIRE_LV等代码签名标志，但仍可通过运行时API csops设置标志来绕过。
     • 最终修复 (macOS Sequoia 15)：仅允许具有特定私有权限（com.apple.private.imagecapturecore.authorization_bypass）的客户端连接。

5. CVE-2023-42961 (intents_helper.xpc)

   • 问题：存在路径遍历漏洞。XPC方法purgeImageWithIdentifier:completion:和retrieveImageWithIdentifier:completion:中的文件名参数未经充分过滤。
   • 利用：加载Intents.framework，通过purgeImageWithIdentifier:方法传入如“../../../../../../etc/hosts”的路径，可删除或读取任意文件（限.png扩展名）。
   • 修复：macOS Sonoma 14.0中，对输入字符串进行了清理，移除了路径遍历字符。

6. CVE-2024-27864 (diskimagescontroller.xpc)

   • 问题：XPC服务在挂载DMG镜像时，权限检查函数checkAttachEntitlementWithError总是返回TRUE，且客户端代码中的隔离检查可被绕过。
   • 利用：加载DiskImages2.framework，自定义XPC客户端，调用attachWithParams:reply:方法挂载一个被隔离的DMG镜像，但挂载后的卷不会被标记为隔离，从而可以执行其中未受隔离保护的恶意应用。
   • 修复：macOS Sonoma 14.4中，将验证逻辑从客户端移至服务端，由服务端直接对被隔离的文件对应的设备进行隔离标记。

7. CVE-2023-42977 (PerfPowerServicesSignpostReader.xpc)

   • 问题：XPC方法submitSignpostDataWithConfig:withReply:中的TagUUID参数存在路径遍历漏洞，可用于创建任意目录或删除任意路径。
   • 利用：加载PowerlogCore.framework，通过XPC方法创建一个不带隔离属性的.app目录结构，并利用符号链接和环境变量技术启动恶意载荷，实现完全沙箱逃逸。
   • 修复：macOS Sonoma 14.0中，对UUID字符串进行了验证，确保其格式有效。

总结与要点

1. 关键攻击面：系统私有框架中，注册在PID域的XPC服务是一个被严重忽视的攻击面，它们通常缺乏适当的客户端验证。
2. 核心逃逸原理：能够创建不带隔离属性的文件或文件夹，等同于完全的沙箱逃逸。攻击者利用此类漏洞（如解压漏洞、目录创建漏洞）来放置并启动一个不受沙箱限制的恶意应用。
3. 影响：这些漏洞允许攻击者在已获得应用远程代码执行权限后，突破沙箱限制，访问用户数据和系统资源。部分漏洞（如CVE-2023-32404， CVE-2023-41077）还能直接绕过TCC保护。
4. 修复模式：苹果主要通过两种方式修复：a) 为XPC服务添加严格的客户端权限/权限检查；b) 直接移除存在风险的XPC服务或框架。
5. 持续风险：作者指出仍有多个报告在处理中，并暗示该攻击面存在更多潜在漏洞。

文章摘要：QNX非商业使用免费政策及资源介绍

核心政策 QNX推出“QNX Everywhere”计划，面向学生、爱好者及原型开发者免费提供非商业用途的QNX软件。该计划包括完整的QNX® SDP 8.0（软件开发平台）系统、工具及实时能力，旨在降低嵌入式系统开发的门槛，促进创新与学习。

关键数据

• 许可证下载量超过15,000次。
• 在线培训注册学习者超过6,000人。
• 已与100多所学术机构建立合作。

主要特点与资源

1. 简化访问：开发者可免费获取QNX SDP 8.0，无需复杂流程。
2. 社区支持：提供活跃的开发者社区（如Discord）供交流协作。
3. 开源支持：QNX符合POSIX标准，能轻松移植多数开源项目，并在GitHub上维护开源代码库。
4. 硬件支持：提供Raspberry Pi（树莓派）镜像，方便开发者快速入门。
5. 教育与培训：提供免费的在线课程、技术文档、快速入门指南等资源。

产品核心：QNX SDP 8.0

• 这是面向下一代多核SoC（系统级芯片）的开发平台。
• 旨在提供高性能、实时、安全可靠的嵌入式操作系统环境。
• 包含升级的工具链及调试分析工具。

许可证条款（重要）

• 严格限于非商业用途，包括个人项目、教育学习等不涉及收入产生或商业运营的活动。
• 不适用于商业评估或商业开发（商业评估可申请30天试用许可）。
• 用户需创建myQNX账户以获取许可证并下载软件。

如何开始 用户可通过官网注册myQNX账户，获取非商业许可证，然后通过QNX Software Center下载安装。同时，可下载Raspberry Pi启动镜像，并参考快速入门指南进行学习与开发。

摘要：Cloudflare 验证页面

该内容为一个 Cloudflare 安全验证页面，标题为“Just a moment...”，旨在限制对论坛帖子（主题ID:40832，消息ID:1363742）的直接访问。页面结构如下：

• 目的：作为反爬虫或安全检查措施，要求用户通过 Cloudflare 挑战才能继续访问目标内容。
• 关键元素：
  • 使用 HTML5 和 CSS 样式，以系统字体显示简洁界面。
  • 包含 <noscript> 标签，提示用户启用 JavaScript 和 cookies。
  • 通过 content-security-policy 元标签限制资源加载，仅允许必要脚本（来自 challenges.cloudflare.com）和样式。
  • 嵌入 JavaScript 脚本以处理 Cloudflare 挑战，包括重定向逻辑和错误处理。
• 功能：页面自动刷新（每360秒），脚本执行后可能重定向用户到验证流程。如果脚本未运行，则显示错误信息，要求启用 JavaScript 和 cookies。
• 技术细节：
  • 使用 window._cf_chl_opt 对象存储挑战参数，如 Ray ID、模板版本和令牌。
  • 脚本动态加载挑战平台，并可能通过历史 API 更新 URL 以避免干扰用户导航。
  • 设计为响应式，适应不同屏幕尺寸。

该页面不包含实际文章内容“Stabilizing the Obra Dinn 1-bit dithering process (2017)”的任何信息，仅作为访问控制机制。

美国食品药品监督管理局（FDA）已正式启动程序，拟将常见非处方减充血剂中的口服苯肾上腺素移除。FDA在去年审查后认定，该成分作为鼻塞缓解剂无效。

具体措施是，FDA发布了一项拟议命令，计划将口服苯肾上腺素从非处方药专论（OTC monograph）中删除。该专论列出了药厂可在非处方产品中使用的药物。一旦移除，药厂将无法在用于暂时缓解鼻塞的产品中添加苯肾上腺素。

FDA药物评价与研究中心主任帕特里齐亚·卡瓦佐尼在声明中表示：“FDA的职责是确保药物安全有效。基于我们对现有数据的审查，并遵循咨询委员会的建议，我们正在推进这一程序，提议移除口服苯肾上腺素，因为它作为鼻减充血剂无效。”

目前，该命令仅为提议。FDA将开启公众评议期，若无评论能推翻此前关于该药无效的结论，该命令将正式生效。生产商将获得一段宽限期来调整其产品配方。

苯肾上腺素的缓慢退出酝酿多年。该成分最初于1976年获FDA批准，但在2006年后才成为主流。当年《2005年打击甲基苯丙胺流行法案》生效后，速达菲的主要成分伪麻黄碱被移至药房柜台后方，以防被用于制造甲基苯丙胺。随着伪麻黄碱在药店不易获得，苯肾上腺素成为主流的非处方减充血剂，但研究人员对此产生了疑问。

2007年，一个FDA小组重新评估了这种据称通过收缩鼻腔血管、开放气道来起效的药物。尽管小组当时维持了批准，但认为需要更多研究进行全面评估。随后进行了三项大型、精心设计的研究——两项由默克公司进行，用于治疗季节性过敏；一项由强生公司进行，用于治疗普通感冒。所有三项研究均未发现苯肾上腺素与安慰剂之间存在显著差异。

FDA提议将口服苯肾上腺素从非处方（OTC）鼻减充血剂中移除

美国食品药品监督管理局（FDA）于2024年11月7日宣布，基于对现有数据的全面审查，提议取消口服苯肾上腺素作为可用于OTC专论药品中临时缓解鼻塞的活性成分。FDA的审查结论认为，口服苯肾上腺素用于此目的无效。目前，含有该成分的产品仍可继续销售，因为这只是拟议命令，只有最终命令才会影响市场。

核心信息：

• 提议原因： 基于有效性担忧，而非安全性问题。FDA和咨询委员会一致认为，现有科学数据不支持口服苯肾上腺素推荐剂量作为鼻减充血剂有效。
• 影响范围： 仅针对口服剂型的苯肾上腺素。含有该成分的OTC产品很常见，有些是单一成分，有些与其他成分（如对乙酰氨基酚）复方配伍。FDA指出，移除苯肾上腺素不影响复方产品中其他活性成分的效果。鼻喷雾剂形式的苯肾上腺素不受此提案影响。
• 审查过程： FDA综合审查了所有数据，包括支持30年前有效性认定的历史数据以及新出现的临床数据。此外，FDA于2023年秋季召开的非处方药咨询委员会会议也对此进行了讨论，并得出了相同结论。
• 消费者提示： FDA提醒消费者，存在多种其他安全有效的药物可用于暂时缓解鼻塞症状。应仔细阅读药品“药物事实”标签以了解具体成分、警告和用法。
• 后续步骤： 该拟议命令正在公开征求意见。若FDA在评估意见后确认其无效，将发布最终命令，正式从OTC专论中移除口服苯肾上腺素，并给予生产商适当时间进行产品重新配方或下架。

文章标题：展示 HN：我的科幻 roguelike 游戏《Asterogue》现已可在网页上游玩

核心内容： 这是一篇关于科幻 roguelike 游戏《Asterogue》的公告，重点介绍了游戏的背景故事和当前可玩的网页版本。

游戏背景故事：

• 设定：银河系经历了千年的和平与繁荣，如今已终结。
• 主角：一位失去一切的“光剑士”。
• 起始事件：在“黑暗时代”的一个夜晚，主角在酒吧借酒消愁时，一位老人讲述了一个神秘传说。
• 传说：古老的外星种族已经回归，他们使用黑暗技艺和奇异野心，试图吸取银河系中所有的美好事物，并将其储存在“诅咒之球”中。
• 使命：这个“古老者之球”是一切苦难的根源，找到它的人将能带来和平。
• 转折：老人在餐巾纸背面画了一幅太空地图，随后突然消失。主角在朦胧中看着地图，意识到这是自己的命运。
• 行动：数日后，主角驾驶飞船在旋臂外缘航行时，坠落在一颗小行星上。
• 决策：这颗小行星是否就是地图上的那一颗？主角发现了一个疑似入口。面对表面必死的命运和内部未知的寒冷，选择是明确的——深入小行星的核心。
• 状态：故事在此结束，引出游戏进程。

关键信息：

• 游戏名称：《Asterogue》
• 类型：科幻 roguelike
• 可玩平台：现已可在网页上游玩
• 核心元素：包含寻找“诅咒之球”的主线任务、外星传说、小行星探索以及经典的“坠落与进入”式冒险开端。

Kagi Translate 摘要

服务概述 Kagi Translate 是一款结合了先进语言模型与精确输出选择的翻译服务，旨在提供超越现有主流翻译工具（如谷歌翻译和 DeepL）的质量。该服务支持 244 种语言（截至 2024 年 11 月），强调在隐私保护下提供高质量翻译。

主要优势

• 高质量翻译：通过内部测试与用户反馈，其翻译质量被评定为优于竞争对手。
• 隐私保护：零追踪，不收集用户数据。
• 免费访问：对所有用户免费。非 Kagi 会员需完成简单的验证码以防止滥用；Kagi 会员则可直接使用。
• 使用便捷：
  • 可直接访问 translate.kagi.com 进行翻译。
  • 在任何网址前添加 translate.kagi.com/ 即可即时翻译整个网页。
  • 提供浏览器书签工具以便快速访问。
  • 计划未来集成到 Kagi 搜索中，作为搜索结果内的即时翻译小组件。

技术原理与局限性 该服务采用多种大语言模型（LLMs），为特定任务选择并优化最佳输出。尽管功能强大，但偶尔可能产生一些不准确之处，团队正在积极解决。 目前的限制包括：

• 不支持翻译动态生成的内容（例如通过 JavaScript 加载的页面）。
• 不支持翻译付费墙后的页面内容。

未来展望 Kagi Translate 是 Kagi 工具套件（“Treats”）的一部分，与 Small Web、Universal Summarizer、FastGPT 以及 Kagi Search、Orion 浏览器并列。该服务的目标不仅是提供更好的翻译，更是提升日常工具的标准，坚信隐私与质量可以共存，最好的技术应该无需为用户妥协。公司鼓励用户提供反馈，并邀请用户成为 Kagi 会员，以支持一个致力于为用户服务而非广告商利益的数字未来。

Google Voice账号被封禁事件摘要

背景

• 用户自高中起使用Google Voice，长达15年。
• 该号码是用户唯一公开的号码，用于日常短信和通话。
• 用户仅在无法接收VoIP验证码时使用运营商号码。
• 主要依赖Google Voice的跨设备文本和通话功能。

被封禁经过

• 2024年10月4日：用户手机和笔记本电脑同时被登出Google账号。
• 安全日志显示账号在12:55被禁用，14:38恢复，但未说明原因。
• 随后尝试通过Google Voice发送第二张图片时出现错误，发送纯文本也失败。
• 浏览器访问Google Voice时被重定向至“访问已被暂停”的支持页面。

申诉过程

• 第一次申诉（10月4日）：提交表单，说明刚被登出账号且发送图片后被封。
• 10月6日收到回复：无法恢复服务，因违反Google Voice政策。
• 第二次申诉（10月7日）：详细说明未违规，发送的图片内容正常（婴儿车旁成人）。
• 10月8日收到相同驳回回复。
• 用户尝试通过Google One联系人工客服，但客服无法查看工单。

号码迁移

• 用户决定将号码迁出Google Voice。
• 10月9日：在Verizon添加新线路，发起号码转移请求。
• 无需向FCC投诉，号码转移在几天内成功完成。
• 10月23日：收到Google Voice确认邮件，号码已转出。

用户反思

• 长期使用Android设备，订阅Google One、YouTube Premium和Google Workspace。
• 重视多平台服务，但担心账号被无故封禁。
• 已采取措施减少风险：将重要邮箱迁移至自定义域名（通过Google Workspace），以便随时切换至其他服务。
• 避免在Google Photos中存储敏感照片，以防账号被封。
• 理解Google自动化系统的必要性，但质疑其不透明性（不告知具体违规原因）。
• 最终对Google生态的信任度下降，考虑进一步迁移服务。

每天五分钟运动可能有助于降低血压

研究核心 一项发表于《循环》期刊的新研究表明，每天增加少量体力活动——如爬坡步行或爬楼梯——可能有助于降低血压。研究由悉尼大学和伦敦大学学院（UCL）领导的ProPASS国际学术联盟完成。

关键发现

• 每天仅进行5分钟额外运动，就可能与可测量的血压降低相关。
• 用每天20-27分钟的运动（包括爬坡步行、爬楼梯、跑步和骑自行车）替代久坐行为，可能带来具有临床意义的血压降低。
• 在人群层面，这种替代可使心血管疾病风险最多降低28%。

研究背景 高血压（持续升高的血压水平）是全球早逝的最大原因之一，影响全球12.8亿成年人，可导致中风、心脏病发作、心力衰竭、肾脏损伤等，常被称为“无声杀手”。

研究方法

• 分析了5个国家14,761名志愿者的健康数据。
• 参与者使用可穿戴加速计设备测量全天活动与血压。
• 将每日活动分为六类：睡眠、久坐行为、慢走、快走、站立以及更剧烈的运动（如跑步、骑车或爬楼梯）。
• 通过统计模型估算，用一种行为替代另一种行为对血压的影响。

专家观点

• Emmanuel Stamatakis教授（ProPASS联盟主任）：除了药物，可能还有相对容易的方法解决高血压问题。每天额外进行短时间高强度运动对血压管理非常有效。
• Jo Blodgett博士（第一作者）：对大多数人来说，运动是降低血压的关键，而不仅仅是低强度活动如步行。好消息是，无论体能如何，不需要很长时间就能对血压产生积极影响。运动（如追赶公交车、短途骑行）可融入日常生活。
• Mark Hamer教授（ProPASS副主任）：研究展示了ProPASS等平台如何识别具有重要临床和公共卫生意义的运动、睡眠和久坐行为的细微模式。

利益声明 Emmanuel Stamatakis教授是一家美国初创公司的有偿顾问并持有股权，该公司业务与本文内容相关。其他作者声明无利益冲突。

Rust在SQL分词与解析中的优势：sqleibniz项目实践

项目概述

作者正在开发名为sqleibniz的SQL静态分析工具，专注于SQLite方言。目标是对SQL输入执行静态分析，包括语法检查、验证表/列/函数是否存在，并结合嵌入式SQLite运行时进行条件断言。工具旨在提供高质量的错误信息、解释和诊断静音功能。项目包含词法分析/分词、根据SQLite文档的SQL解析，以及结果结构的分析阶段。未来计划开发SQL语言服务器协议(LSP)。

Rust语言特性优势

1. 宏减少代码重复

Rust宏显著减少了AST节点定义的重复代码。通过自定义宏node!，可以一次性定义结构体、文档注释和Node trait实现：

• 自动添加必需的Token字段t
• 实现Node trait的token()方法
• 支持可变数量的额外字段

宏利用元变量$node_name:ident、$documentation:literal和$($field_name:ident:$field_type:ty),*来灵活生成不同结构的节点定义。

2. 测试宏实现表驱动测试

作者创建了类似Go表驱动测试的宏：

• test_group_pass_assert!：用于有效输入测试，验证词法/语法分析结果
• test_group_fail!：用于无效输入测试，验证错误处理

这些宏自动生成测试模块和函数，每个测试用例独立运行并显示结果，提高了测试的可读性和维护性。

3. 模式匹配的高效应用

match语句和matches!宏在词法分析和语法解析中极为有用：

• 词法分析中轻松匹配数字字符（包括十六进制、浮点数等）
• 语法解析中根据token类型构建AST，如处理EXPLAIN语句的不同路径

4. 错误处理的便利性

Rust的Option类型和相关方法简化了错误处理：

• is_some_and：简洁地检查条件并处理None
• map：直接转换Option内部值
• map_or：提供默认值处理

5. 迭代器的函数式编程

迭代器提供了简洁的数据处理方式：

• 过滤字符（如移除数字中的下划线）
• 检查十六进制数据的有效性
• 链式操作代替传统的循环构建

语法解析示例

sql_stmt_prefix方法展示了如何解析SQLite的EXPLAIN语句：

• 使用match检查当前token类型
• 处理EXPLAIN关键字后的两种可能路径：直接语句或QUERY PLAN后接语句
• 通过token消费和推进实现语法分析

错误显示机制

工具提供友好的错误显示，如缺少分号的SQL语句会生成包含位置和上下文的错误信息。

开发中的挑战

尽管Rust提供了强大功能，但宏开发中存在一些工具链限制：

• rust-analyzer在宏内部的智能感知支持有限
• 代码格式化工具无法格式化宏内部代码
• 语法高亮有时不准确
• 文档相对稀疏

结论

Rust的宏系统、模式匹配、Option处理和迭代器等特性使得开发SQL分词器和解析器更加高效和愉悦，显著减少了样板代码，提高了代码可读性和可维护性。

感知无损的说话人头像视频压缩

这篇文章探讨了利用 LivePortrait 等2D头像动画生成模型，实现极低码率（约22kbit/s）且主观质量可接受的视频压缩技术，特别适用于视频会议等“说话人头像”场景。

核心原理

该方法基于“预测即压缩”的思想。压缩的核心在于，发送端与接收端共享一张源图像（如视频的第一帧）。需要传输的不再是每一帧的像素信息，而是一组极其稀疏的运动参数，用于描述表情、姿态和面部关键点的变化。接收端利用这些参数，通过模型将源图像动画化，从而重建后续帧。

关键技术与公式

以LivePortrait为例，其驱动模型通过以下变换方程来生成新的面部关键点： x_d = s_d × (x_c,s * R_d + δ_d) + t_d 其中：

• x_c,s 是源图像的规范3D关键点。
• R_d 是3D旋转矩阵。
• δ_d 是表情变形量。
• t_d 是平移向量。
• s_d 是缩放系数。 发送端只需传输 s_d, R_d, δ_d, t_d 这75个数值（假设关键点数K=21）。结合简单的熵编码，即可将30FPS视频的码率降至约 22 kbit/s。

压缩效果与优缺点

优点：

• 极高的压缩效率：在22kbit/s的码率下，能够产生主观质量尚可的重建视频。传统编码器（如H.264）在此码率下会产生严重的块效应等伪影。
• 较好的主观质量：在只观看生成输出而非与原始视频并排对比时，效果通常令人满意。

缺点与挑战：

1. 缺乏灵活的码率-质量权衡：不像H.264有CRF参数，难以在码率和质量间进行精细调节。
2. 最坏情况不可控：作为生成模型，可能在极端情况下产生质量极差的输出（如面部扭曲）。
3. 计算成本高：模型（如LivePortrait）需要强大的GPU（如RTX 4090）才能实时处理，部署在边缘设备（如Apple Neural Engine）上仍面临挑战。
4. 存在视觉瑕疵：实验中观察到头部抖动、眼睛注视方向错误、牙齿细节幻觉等问题，尤其在肩部运动和困难头角度下更明显。

技术背景与模型对比

• 创新点：LivePortrait的前身facevid2vid的核心创新是将帧动画问题建模为3D旋转问题，让模型自监督地学习有意义的面部关键点。LivePortrait在此基础上，通过海量高质量数据集和局部GAN损失进行改进。
• 与SOTA学习型压缩模型对比：与DCVC等专注于像素对齐失真（如MSE）的模型不同，LivePortrait这类生成模型旨在产生符合人类感知的合理输出。因此，它在压缩效率上更高，但以更大的模型规模（130M参数 vs. 20M参数）和更高的计算复杂度为代价。

潜在应用与展望

该技术为视频通信提供了新的可能性：

• 在带宽受限时维持可用视频质量。
• 从低质量摄像头驱动一个高清、正式的虚拟形象。
• 实现更具沉浸感的虚拟会议，或将虚拟形象作为“数字分身”自动参会和回复消息。 尽管如此，作者也指出，这些应用场景的实际可行性和社会接受度仍有待观察。未来，随着模型和硬件的进步，针对特定场景（如视频会议）优化的更小、更快模型有望出现。

Jamcorder：数字钢琴自动录音设备
Jamcorder是一款专为数字钢琴设计的小型硬件设备，通过自动录制用户的演奏，将其转化为可回顾、分享的MIDI格式数字档案。它连接钢琴的USB或5针MIDI端口，无需手动操作即可持续记录所有演奏，帮助用户捕捉即兴灵感、追踪练习进度并构建个人音乐库。

核心功能与特点

• 自动录制：智能检测演奏状态，自动开始/停止记录，无需手动操作。
• 大容量存储：附带16GB Micro SD卡，可存储约25,000小时MIDI数据（约3年连续演奏）。
• MIDI格式录制：记录音符、力度、踏板、弯音等所有MIDI事件，而非音频，文件体积极小（12小时音乐仅占一张照片大小）。
• 无线同步与管理：通过蓝牙将录制数据同步至手机App（支持iOS/Android/macOS），也可直接通过SD卡或Web界面访问文件。
• 书签与整理：通过按压钢琴顶部黑键两次快速添加书签，便于标记重要演奏片段。
• 灵活回放：
  • 通过MIDI输出在钢琴原生扬声器上播放录音，保留原始音色。
  • 在App中使用内置音色或自定义SoundFont回放。
• 多场景适用：支持即兴演奏、练习复盘、作曲灵感捕捉，并提供循环叠加、MIDI导入/导出等功能。
• 独立运行：无需网络或账户，可完全脱离App使用（App为可选组件）。
• 兼容性广：适用于所有支持MIDI的键盘乐器，且一台设备可同时连接16台钢琴。

技术细节与使用说明

• 连接方式：通过USB或5针MIDI线连接钢琴，支持USB-A至USB-C转接。
• 录制逻辑：每日生成一个MIDI文件，自动过滤长时间静音段落（超过3秒暂停录制）。
• 数据导出：支持从App、SD卡或Web端导出标准MIDI文件，无缝兼容各类DAW或乐谱转换工具。
• 隐私与存储：所有数据仅存储在本地设备，用户可自由导出全部音乐库。
• 扩展性：支持更换大容量Micro SD卡（建议不超过64GB），并可选配蓝牙MIDI适配功能（延迟35ms）。

与其他方案的对比优势

• 彻解放双手，避免因手动录制中断演奏流状态。
• 相较于手机录音，Jamcorder具备自动化、数据可视化（音符轨迹）、练习统计等深度功能。
• 通过MIDI格式保留完整的音乐表达细节，便于后期编辑与音色调整。

配件与支持
设备附带16GB SD卡、USB电源线、MIDI连接线及固定胶垫。提供30天免费退货政策（仅限美国），全球发货（不含关税）。开发者为前苹果软件工程师及钢琴爱好者，注重产品与音乐创作场景的深度融合。

文章标题： LoRA与全参数微调：等效性的错觉

核心研究问题： 低秩适应（LoRA）等参数高效微调方法与全参数微调所得到的模型解，是否真正等效？本文通过分析权重矩阵的谱性质（特别是奇异值分解）来探究两者对预训练模型的改变是否存在本质差异。

主要发现：

1. 结构差异： LoRA和全参数微调产生的权重矩阵在奇异值分解上表现出显著不同的结构。经过LoRA微调后的权重矩阵会引入新的、高排名的奇异向量，作者将其命名为“入侵维度”；而全参数微调则不会产生这种结构。
2. 遗忘机制： LoRA通常被认为比全参数微调的“遗忘”更少。本文进一步发现，LoRA的遗忘现象在很大程度上局限于这些入侵维度。通过因果干预实验（在微调后改变入侵维度对应的奇异值），证实了这些维度是导致遗忘的原因。缩小这些维度的数值，可以显著提升模型对预训练数据分布的建模能力，同时对下游任务性能的影响很小。
3. 持续学习的负面影响： 在需要顺序微调的持续学习场景中，入侵维度会不断累积。由于这些维度与遗忘密切相关，LoRA模型在这种设置下倾向于累积更多入侵维度，从而导致性能更差。这强调了该发现的实际意义。

结论： LoRA与全参数微调所得到的模型并非真正等效。它们在权重矩阵的谱结构上存在根本区别，特别是LoRA引入的“入侵维度”是驱动其遗忘特性的关键因素。这一发现不仅揭示了两种微调方法内在机制的差异，也指出了在持续学习等场景中应用LoRA时需要警惕的潜在问题。

Λ-2D：以绘图作为编程语言的探索

Λ-2D 是一种基于绘图的编程语言，其核心设计灵感来源于 Lambda Calculus（λ演算），旨在探索如何通过图形绘制而非传统文本进行编程。

设计目标与核心思想

作者设定了三个主要设计目标：

1. 利用绘图特性，实现文本编程语言难以实现的功能。
2. 指令数量适中，既避免过于简陋导致编程繁琐，也避免过于复杂不利于计算机视觉解析。
3. 程序本身具有视觉美感，甚至值得装裱展示。

语言的基础是 Lambda Calculus，作者认为其“求值”而非“执行”的特性，与观众观看绘画时视线流动、通过点线形成整体的体验相似。

技术架构与特点

• 网格系统：用户可在网格上绘制连续线条，但每个网格最终会被解析为一个有限的符号集，平衡了人工绘制的便利性与机器解析的可行性。
• 核心符号：为Lambda Calculus的两个基本操作设计了图形符号：
  • 函数应用：用“杯子”形状表示。
  • 函数定义：用希腊字母λ表示。
  • 基础形式仅支持单参数函数（柯里化）。
• 语法糖与扩展：为提升易用性，在纯λ演算基础上增加了数字、数学运算符等常见编程元素作为语法糖。用户仍可使用丘奇数等纯λ演算构造。
• “画框”与数据：引入“画框”功能，用户可在画布上框出区域，并在其中自由绘制（如数学函数曲线、滑块等），这些绘制内容可直接作为数据在程序中使用，实现了图形与程序的自然融合。

开发过程与挑战

• 开发方法：作者先从草图构思，随后开发了解析器和编辑器。编辑器提供网格绘图和自由绘制工具，符号尺寸为5x5像素。
• 纯函数式的挑战：语言的纯函数式、无状态特性导致无法直接实现传统的“打印”功能（因涉及状态改变）。解决方案是将打印重新定义为：向函数传递一个空画布，返回一个被绘制了文本等像素的新画布。
• 实现方式：当前解析器将Λ-2D程序转译成一个庞大的JavaScript单行表达式，虽效率不高但可运行。

应用、可视化与展望

• 编程体验：作者通过编写分形树等示例程序来学习和改进语言，过程类似于玩游戏，充满探索乐趣。
• 执行可视化与音效：作者尝试将程序解析过程动画可视化，并创新性地为不同符号添加音效，使程序运行如听歌，产生了类似8位游戏的声音效果。
• 当前局限：程序视觉效果仍偏向电路图而非绘画艺术；学习曲线可能较陡；对计算机视觉扫描的准确性存疑。
• 未来计划：作者计划继续完善Λ-2D，并基于已获得的经验，设计更多能够融入其“绘图即计算”系统的编程语言。

该项目最初是一个通过增强现实技术，将纸笔绘制与交互反馈结合的大研究的一部分，现已发展为一个独立的有趣实验。读者可以尝试其在线演示版本，源代码也将开源。

文章标题：蘑菇色彩图谱

核心概述： 该文章介绍了“蘑菇色彩图谱”——一个探索真菌色彩宇宙的互动工具，它专注于展示由染料蘑菇自然产生的色彩光谱。

主要功能与特点：

• 动态图谱浏览：用户可通过该图谱探索真菌的色彩世界。
• 多维度筛选：图谱支持按蘑菇类型、使用的染料或色素、以及使用的织物和媒染剂进行颜色筛选。
• 索引查询：图谱中所有染料蘑菇均可在索引中搜索查找。
• 学习资源：
  • “流程”部分提供蘑菇染色的方法、技术和变量信息。
  • “文章”部分提供相关资源及活动资讯。
• 配套书籍：用户可通过购买相关书籍，开启一段深入真菌王国的色彩之旅。

WSPR简介

WSPR（发音近似“whisper”）全称为“弱信号传播报告器”，是一种专为业余无线电爱好者（Ham Radio）设计的计算机协议与程序。其主要功能是用于测试中频（MF）和高频（HF）频段的电波传播路径是否开放，而非进行常规的语音或莫尔斯电码通信。

起源与发展

该协议最初由诺贝尔奖获得者、FT8协议的创造者Joe Taylor（呼号K1JT）设计编写。目前，其软件代码已开源，并由一个小型团队负责更新维护。

技术特点与工作原理

1. 特殊编码：WSPR传输的是信标式的特制编码信号，内容包含呼号、四字符的网格定位器（如“EM89”）以及发射功率等级（以dBm为单位）。
2. 高效与稳健：
   • 采用强大的前向纠错（FEC）技术，显著提高了在恶劣条件下的解码成功率，并将错误率降至极低。
   • 信号带宽极窄，仅为6赫兹。结合随机化的分时共享机制，可以在业余频段一个200赫兹的片段内容纳数十个WSPR信号。
   • 性能卓越，在信噪比低至-28 dB（在2500 Hz带宽内）的条件下仍能有效工作，这比人耳可听阈值还要低约10至15分贝。
3. 低功率运行：在多数频段上，典型的WSPR发射功率为5瓦或更低，有时甚至远低于5瓦。

协议的演进

WSPR协议在持续进化，其改进包括：

• 解码器灵敏度的升级。
• 在拥挤的子频段中处理大量信号的能力得到改善。
• 错误解码检测能力的增强。

使用方法与设备

要使用WSPR功能，你需要：

1. 一部无线电设备（优选支持USB音频接口的型号）。
2. 一台连接互联网的电脑。

• 重要提示：用户并非必须发射信号。系统可以仅作为接收器，报告其听到的WSPR信号，从而为全球传播路径研究提供数据。

标准消息格式

一个标准的WSPR消息格式示例为：KE8FMJ EM89 37

• KE8FMJ：电台呼号。
• EM89：表示电台位置的四位网格定位器。
• 37：发射功率，37 dBm，约等于5.0瓦。

总而言之，WSPR是一个用于探测和报告弱信号无线电传播路径的强大而高效的工具，是业余无线电爱好者进行传播研究和低功率通信实验的重要资源。

底特律警方在数字取证中发现，运行iOS 18系统的iPhone在脱离蜂窝网络后可能自动重启，这给司法解锁设备带来了新的困难。

现象与影响

• 处于“首次解锁后”（AFU）状态的iPhone在被断开蜂窝网络后，约24小时内会自发重启。
• 重启后设备会返回“首次解锁前”（BFU）状态，加密强度更高，使执法部门使用的暴力破解工具（如Cellebrite）更难破解。
• 法拉第笼（能隔绝所有电子信号）中的iPhone也出现了重启现象，表明重启可能并非仅由外部通信触发。

执法部门的推测与行动

• 底特律警方认为这是iOS 18新增的安全功能，旨在保护数据。
• 警方已向其他部门发布警报，建议将运行iOS 18的设备与其他AFU状态的iPhone隔离存放，以避免可能的相互影响。
• 具体触发重启的条件尚不明确，需要进一步研究。

专家观点与官方信息

• 密码学家马修·格林认为警方的假设“非常可疑”，但他认为“手机在长时间无网络后自动重启”是一个出色的设计概念。
• 苹果在iOS 18.1更新中添加了“不活跃重启”功能，但根据说明，该功能与网络状态无关。
• 目前没有证据表明运行iOS 18的iPhone会主动导致其他系统的iPhone重启。

该发现可能改变执法机构对电子设备的保管流程，并突显了持续更新的移动操作系统对数字取证领域带来的挑战。

KDE Plasma 桌面图标定位系统重构总结

问题背景

作者花费三周时间重构并修复了 Plasma 桌面图标定位的遗留代码（部分源于2013年），涉及图标位置数据的保存与加载逻辑。原有代码存在竞态条件、前后端代码混合等问题，且长期多作者修改导致代码纠缠混乱。

核心挑战与解决方案

1. 代码可读性差

• 问题：旧代码缺乏注释，理解图标位置更新时序和数据流需耗费大量时间。
• 解决：重命名方法使其更描述性，将保存图标位置等后端代码从界面代码中剥离。

2. 屏幕状态处理

• 问题：部分显示器在省电模式下会向系统报告“已断开”，导致系统误认为屏幕消失并删除桌面图标。
• 解决：增加屏幕使用状态检查。若屏幕未在使用中，则跳过对图标的操作，避免错误移除。

3. 分辨率与缩放因子变化

• 问题：图标采用“条带区域”算法排列，每屏分辨率决定条带数量和每条带图标容量。当屏幕报告断开时，条带数量可能错误重置为1×1，导致所有图标被压缩至单点，恢复后丢失原有布局。
• 解决：在屏幕非使用状态下保持条带数据，防止意外重置；仅当分辨率变更时重新计算条带。

4. 保存逻辑优化

• 问题：旧代码在图标位置变化时即保存，包括系统自动调整的情况，导致保存错误状态。
• 解决：严格区分用户操作与系统操作。仅当用户执行以下操作时保存：
  • 添加/删除桌面图标
  • 手动移动图标位置
  • 变更屏幕分辨率
    每种分辨率独立保存布局，避免相互覆盖。

5. 边距计算时序问题

• 问题：桌面可用区域（扣除面板）在面板加载前确定，后续面板显示会导致区域频繁调整，引发图标重排并错误保存。
• 解决：避免在系统自动调整时保存位置；计划在后续更新中延迟加载图标区域计算，确保边距稳定后再定位图标。

改进效果

• 可靠性提升：减少因屏幕状态、分辨率变化导致的布局丢失。
• 性能优化：降低不必要的保存频率。
• 代码质量：前后端分离，逻辑更清晰，但仍需更多行内注释辅助维护。

总结

此次重构主要解决了桌面图标因外部状态变化和内部时序问题导致的布局错乱。作者强调代码注释的重要性，并建议通过KDE缺陷报告平台反馈后续问题。尽管用户本人不使用桌面图标，但改进旨在提升普通用户体验。

Draw.Audio 是一款基于 Web Audio API 构建的交互式音乐创作工具，允许用户通过可视化绘制的方式生成和编辑音乐。其核心是一个音乐素描板，提供了音序器、波形回放、音符长度调整以及“人性化”律动等功能，使创作过程更直观。

工具包含多个功能模块：

• 效果器：提供侧链、磁带/黑胶模拟、混响、延迟、失真、立体声扩展、合唱、环形调制等多种效果。
• 音轨配置：支持振荡器、包络、多声部、频率调制、振幅包络、音高包络、滤波器、调制、低频振荡器等参数设置。
• 自动化：允许用户选取参数并在网格上绘制其变化轨迹。
• 工具与预设：包括编辑、均衡器编辑、音符生成、随机化现有音符等功能。
• 均衡器模式：用户可通过在网格上拖动频段来塑造音轨的频率响应。

整体设计面向快速音乐原型制作，将复杂的音频参数通过图形化界面简化，适合音乐爱好者和创作者进行实验性创作。

BemiDB 是一个开源项目，将 Snowflake 和 Fivetran 的功能结合在一起。它能无缝连接不同数据源，以压缩的列式格式将数据同步到 S3，并通过其兼容 PostgreSQL 的分析查询引擎运行复杂查询。

主要亮点

• 查询引擎：搭载比常规 PostgreSQL 快 2000 倍的分析查询引擎。
• 可扩展存储：将数据以列式格式存储在对象存储中，计算与存储分离。
• 内置连接器：可自动从不同数据源同步数据。
• 数据压缩：使用开放表格式，实现 4 倍数据压缩。
• 易于部署：打包在单个 Docker 镜像中，进程无状态。
• PostgreSQL 兼容：可与 PostgreSQL 生态系统中的服务和工具集成。
• 开源：在 OSI 批准的许可证下发布。

使用场景

• 集中数据，无需复杂管道（无需 CDC 或 ETL）。
• 与 PostgreSQL 工具和服务集成，用于查询。
• 高速运行复杂分析查询，无需担心性能影响或索引。
• 持续从数据库归档数据。

快速开始

1. 配置前提条件：
   • 设置一个 PostgreSQL 数据库作为数据目录。
   • 创建一个 S3 存储桶和拥有访问权限的 IAM 用户。
   • 导出环境变量（如目录数据库 URL、AWS S3 凭证）。
2. 从源 PostgreSQL 数据库同步数据：运行 syncer-postgres Docker 容器。
3. 启动 BemiDB 数据库服务器：运行 server Docker 容器。
4. 使用 PostgreSQL 客户端查询 BemiDB：通过 psql 连接并查询。

数据同步

• 从 Amplitude 同步：需要 API 密钥和密钥，指定开始日期。
• 从 Attio 同步：需要 API 访问令牌。
• 从 Dialpad 同步：需要创建 webhook 端点，订阅 SMS 事件，并通过一个小型服务将事件发布到 NATS JetStream，然后运行同步器。
• 从 PostgreSQL 同步：默认同步所有表，可通过环境变量指定要包含或排除的表。

配置 通过环境变量进行配置，包括：

• 各同步器命令选项（如 syncer-amplitude, syncer-postgres 等）。
• 服务器命令选项（主机、端口、数据库名、用户密码）。
• 通用选项（目录数据库 URL、AWS S3 凭证、日志级别等）。

架构 BemiDB 由以下主要组件组成，封装在单个 Docker 镜像中：

• 数据库服务器：实现 PostgreSQL 协议以保证兼容性。
• 查询引擎：嵌入 DuckDB 查询引擎以运行分析查询。
• 存储层：使用 Iceberg 开放表格式将数据存储为列式压缩的 Parquet 文件。
• 数据同步器：连接不同数据源并将数据同步到存储层。

基准测试 优化了分析工作负载，复杂查询速度比常规 PostgreSQL 快最多 2000 倍。在 TPC-H 基准测试中，无论是否有索引，性能均显著优于 PostgreSQL。

数据类型映射 提供了 PostgreSQL 数据类型到 Parquet 和 Iceberg 数据类型的映射关系。例如，PostgreSQL 的 json/jsonb 类型作为字符串存储，并支持使用标准运算符进行查询。

路线图 包括：完成 PostgreSQL 协议支持、Iceberg 写入操作、选择性数据同步、兼容更多工具（Metabase, DBeaver 等）、从更多数据源同步（HubSpot, Stripe 等）、Iceberg 表压缩、物化视图、dbt 转换、分区表支持等。

许可证 根据 AGPL-3.0 许可证分发。如需修改和分发代码，请开源以回馈社区。

根据您提供的内容，我仅能看到一个 HTTP 403 错误，而无法获取到任何关于“福特在堪萨斯城洞穴存车”的实际文章信息。

错误信息显示如下：

• 错误类型：请求被阻止。
• 可能原因：服务器目前无法连接，可能是由于流量过大或配置错误。
• 建议操作：稍后重试，或联系网站所有者。如果您通过 CloudFront 提供内容，可参考其文档进行故障排除。
• 其他信息：错误由 CloudFront 生成，并附带了一个请求ID。

由于无法访问原文内容，我无法为您生成所要求的摘要。请确保提供可访问的文章内容，以便进行总结。

项目背景与原理

作者受传统电子卡尺启发，尝试利用电容耦合原理，以低成本电路板、微控制器和固件，构建一个每秒500次更新、毫米级精度的线性位置传感系统。传统卡尺通过滑动显示器上的PCB与固定尺身中的被动PCB“标尺”之间的电容耦合工作。作者旨在创建一个开源的、适合创客的定位方案。

硬件与信号处理实现

1. 硬件结构：合作开发者Mitko设计了PCB，核心为STM32F103微控制器。系统包括：

   • 滑动部分：有8个钢琴键状的发射垫片和一个接收垫片。
   • 固定部分：有带“T”形反射板的被动PCB标尺。
   • 反射板通过电容耦合，将其下方多个发射垫片信号求和后反馈给接收垫片。

2. 信号发射：微控制器发射8路频率相同、相位均匀偏移的正弦波。因无DAC，采用脉冲密度调制实现正弦波。通过编译时计算生成PDM位模式数组，并利用DMA将数据高速写入GPIO的BSRR寄存器，确保信号同步且无抖动。

3. 相位测量与计算：

   • ADC通过DMA同步采样反射信号。
   • 利用相关运算和反正切函数计算反射信号相对于参考信号的相位偏移。相关运算所需的正弦/余弦值也在编译时生成查找表。
   • 相位偏移直接对应滑动位置的变化（每2π弧度相位变化对应8个发射垫片宽度的距离）。

参数优化与精度结果

作者通过流式传输原始ADC数据到电脑，在Python中进行参数扫描实验，寻找最佳配置。关键发现：

• ADC采样频率与信号频率需匹配。
• 增加相关窗口大小通常能提升精度。
• 最终选择参数：PDM频率222 kHz、ADC采样频率222.2 kHz、窗口大小128。
• 在该配置下，静态测量的相位标准差为0.039弧度，对应约0.6毫米的位置精度。系统更新率约为0.6 kHz。

工作流程与经验

• 采用流式数据采集+Python笔记本分析的工作流，便于远程调试和探索。
• 利用LLM辅助编写数据处理和可视化代码。
• 在嵌入式开发中，倾向于将逻辑集中在main()函数中以避免复杂的类型签名。

未来展望

作者建议了潜在的改进方向，如：

• 设计参数化的卡尺发射器/反射器PCB。
• 专为铝型材运动系统优化设计。
• 与磁条或SteamVR追踪器等现成系统对比。
• 设计更完善的外壳，制作成实用卡尺。

Hyperlight项目概述

Hyperlight 是由微软Azure核心上游团队推出的一个开源Rust库。它旨在通过基于虚拟机（虚拟机监控程序）的保护，以极快的速度安全地执行小规模的嵌入式函数，使得为每次函数调用都启用独立的虚拟机保护在性能上成为可能。

核心动机与挑战

在云环境中，安全性与速度的兼顾至关重要但极具挑战。传统的虚拟机（如Hyper-V、KVM）安全性高，但冷启动时间长、资源占用大。这迫使云服务商需要保持大量预热的虚拟机待命，以执行对延迟敏感的事件驱动型小段代码，导致资源浪费和成本增加。

Hyperlight的创新与优势

Hyperlight通过大幅简化虚拟机创建过程解决了这一矛盾。它不创建完整的通用计算环境，而是仅分配一块线性内存并关联一个虚拟CPU，省去了虚拟设备映射、内核引导等繁琐步骤。它运行的是特殊的“VM访客程序”，将专用内核与应用程序运行时合并为一个可加载的单元。

这种设计带来了革命性的性能提升：

• 冷启动时间：1-2毫秒。这比传统优化虚拟机（>120毫秒）快两个数量级，虽然比Wasmtime等沙箱运行时（<0.03毫秒）稍慢，但提供了虚拟机级的强隔离保护。
• 资源效率：允许按需创建虚拟机，实现了“缩容至零”，无需保持闲置虚拟机。
• 安全增强：可将WebAssembly等沙箱运行时置于Hyperlight虚拟机内部，在发生沙箱逃逸时提供额外一层保护。

工作流程示例（Rust）

文章提供了一个基础代码示例，展示了在Rust中如何使用Hyperlight：

1. 初始化：创建一个未初始化的沙箱，并加载一个预先定义的“访客程序”。
2. 注册函数：可以从主机向访客注册函数（例如，一个可被访客调用的“Sleep5Secs”系统调用）。
3. 状态快照：调用 evolve 方法初始化沙箱并创建状态快照，以便摊薄未来实例的初始化成本。
4. 调用函数：通过沙箱调用访客程序中定义的函数（如“PrintOutput”），实现与虚拟机内部的交互。

发展方向与社区

微软计划将Hyperlight提交给云原生计算基金会（CNCF） 作为沙箱项目，旨在利用CNCF社区的资源推动其发展。该项目采用Apache 2.0许可证开源，鼓励开发者、架构师和IT专业人士参与构建和改进。

总结

Hyperlight是一个专注于为可扩展的函数调用提供虚拟机级安全隔离的库，它通过创新的轻量级虚拟机创建机制，实现了超低延迟的冷启动，特别适用于需要在保证安全性的前提下对事件做出快速响应的服务器无状态化嵌入、物联网网关、工业自动化及高吞吐量云服务等场景。

Guild Builds

文章介绍了针对线上口号管理的一个系统，特别是用于跟踪罢工口号。内容描述了人们使用扩音器和标语牌喊口号的场景，并指出由于线上口号众多，因此建立了该系统以便更好地记录和管理它们。

Bluesky AT Protocol：开发者视角的利弊分析

AT Protocol 基本原理

Bluesky 的 AT Protocol 旨在建立一个类似早期 Web 的用户控制层。核心思想是：用户通过域名（如 @cybercultural.com）拥有自己的数字身份和内容（存储在个人数据服务器 PDS 上），可以自由迁移服务商（类似更换网站托管商），而不被困在某个平台的“围墙花园”内。该协议使用 W3C 标准的去中心化标识符（DID），技术架构上类似 URL 的 at:// 协议。

对开发者的优势

1. 统一身份与内容复用：用户使用域名/DID 作为跨应用的唯一身份。开发者可直接利用 Bluesky 庞大的现有用户基础（1300 万）和其已发布的内容，用户无需为新应用创建新账号，显著降低用户获取门槛。
2. 数据可移植性：用户可将内容（如帖子）迁移至不同的 PDS，且内容与身份绑定，这比 ActivityPub（迁移后内容仍留旧实例）更彻底。
3. Web 原生体验：协议基于 Web 标准，开发体验更贴近传统 Web 开发。
4. 新兴生态机会：已有 WhiteWind（博客工具）、frontpage.fyi（类 Reddit）等实验性应用出现，生态处于早期增长阶段。

对开发者的劣势与风险

1. 中心化现实：目前超过 99% 的用户数据存储在 Bluesky 公司控制的基础设施上，协议开发也由该公司主导。这引发了对“去中心化”实质性的质疑，存在公司控制或投资者决策影响整个网络的风险（类似 Twitter 的演变）。
2. 商业模式不确定性：Bluesky 已获得风险投资，未来盈利需求或投资者意志可能影响协议开放性，与去中心化初衷存在潜在冲突。
3. 生态成熟度：除 Bluesky 应用外，其他应用仍在早期，网络效应和工具链尚不完善。

与 ActivityPub（Fediverse）对比

• 身份模型：AT Protocol 是用户拥有跨应用统一身份；ActivityPub 需要用户为每个应用/实例创建独立身份。
• 架构理念：AT Protocol 类似 Web（独立站点发布数据，索引器聚合）；ActivityPub 类似电子邮件（独立服务器间通信）。
• 数据迁移：AT Protocol 可迁移身份及关联内容；ActivityPub 可迁移关注关系但内容留原实例。

结论

AT Protocol 为开发者提供了利用现有庞大用户群和简化用户 onboarding 的诱人机会。然而，当前高度中心化的基础设施和 Bluesky 公司的主导地位构成了实质性风险。开发者需权衡：是选择快速接入增长中的用户生态，还是坚持更去中心化但可能增长较慢的 ActivityPub 模式，取决于其对风险和控制权的考量。协议的未来取决于其能否真正实现基础设施的广泛分布式部署。

# Bluesky 自托管指南（AppView 除外）

## 组件概览
本文介绍了如何自托管 Bluesky 的大部分基础设施，包括 PDS、Relay、Jetstream、plc.directory 镜像以及社交应用前端。AppView 目前仍无法完全自托管。

## 各组件部署详情

### 1. PDS（个人数据服务器）
- **用途**：托管用户数据，实现数据自主。
- **部署方式**：参考官方 GitHub 仓库，可使用 GOAT 工具迁移现有账户。

### 2. Relay（中继服务器）
- **功能**：处理并转发用户数据。
- **注意事项**：存储需求至少约 4.5 TB，需使用 `--disk-persister-dir` 参数并启用压缩功能。

### 3. Jetstream
- **特点**：带宽和存储需求较低，提供 JSON 格式数据。
- **部署**：通过 Docker Compose 或直接构建，支持配置数据保留期限（默认 24 小时）和回填历史数据（最多 3 天）。

### 4. plc.directory 镜像
- **方法**：使用 str4d 的工具克隆并构建镜像数据库，同步 Bluesky 用户目录。
- **耗时**：约 5-10 小时，完成后通过 SQLite3 监控状态。

### 5. 社交应用前端
- **部署**：克隆仓库后通过 `yarn && yarn web` 快速构建网页版，移动端部署较复杂，需参考专门文档。

## AppView 现状
AppView（应用视图层）尚未开放自托管，作者组织工作组推进相关工作，有兴趣者可通过 Bluesky 私信参与。

W3C宣布成立可持续网络兴趣小组，旨在提升数字可持续性，使网络更好地服务全人类与地球。当前数字产业占全球碳排放2%-5%，超过航空业，若视互联网为一个国家，其污染量将位居全球前五，且每年消耗的水、能源和矿产资源持续增长，常给发展中经济体带来负担。

该小组将发布《网络可持续性指南》，该指南由可持续网络设计社区小组起草，基于可衡量、循证的研究提出最佳实践，指导数字产品与服务的设计与实施，优先考虑人类与地球福祉。指南面向终端用户、网络工作者、利益相关者、工具开发者、教育工作者及政策制定者，与《可持续网络宣言》对齐，并符合GRI标准及联合国可持续发展目标，协助组织将数字产品纳入更广泛的可持续发展报告。此外，小组还将与监管机构合作以改善合规目标。

小组由MightyBytes的Tim Frick、StoryBlok的受邀专家Ines Akrap及CivicActions的受邀专家Mike Gifford共同主持，Alexander Dawson担任编辑，W3C的Tzviya Siegman作为团队联络人。未来小组将致力于提升可持续性衡量标准，开发更多教育材料，推动《网络可持续性指南》的实施。

文章摘要

一辆救护车在事故中撞倒了一名骑自行车的人，随后将其送往医院接受治疗。然而，事后这名伤者却收到了一张高达1800美元的救护车服务账单。这一事件引发了对急救医疗服务收费合理性和责任归属的争议。

直觉的本质与科学基础 直觉并非神秘魔法，而是一种无意识智能。它源于大脑的非语言区域（如基底前脑和前扣带皮层），通过“启发式规则”高效处理复杂情境，是基于长期经验形成的认知模式识别。将直觉语言化往往会导致理性化解释，而非真实反映直觉过程。

直觉与专业能力的关联 直觉的可靠性高度依赖于决策者在特定领域的专业能力水平：

• 在无意识能力阶段（技能已内化为本能），直觉的准确性极高，领导者可信任其模式识别能力。
• 在有意识能力阶段（需刻意思考决策），直觉可靠性较低，此时应优先依赖分析框架和心智模型，但直觉可作为最终检验。

正确运用直觉的方法 与传统“用分析验证直觉”相反，文章主张将直觉作为分析决策后的最后检验。当经过周密分析后仍感“不对劲”时，这种不适感可能提示潜意识识别到模式错误，尤其在不确定或动态环境中。但对这种直觉信号的回应应基于对自身专业水平的准确认知。

领导者的关键：自我认知 有效运用直觉的核心是自我觉察。领导者需客观评估自己在不同决策领域的专业层次，从而平衡直觉与分析的权重，避免在能力不足的领域过度依赖直觉。

总结：直觉作为安静的向导 直觉在领导力中更像一个“轻拍肩膀的安静向导”，而非明确的路标。它在自然空间中最有效，领导者需明确何时、以及在多大程度上信任直觉。卓越的领导者善于平衡三者：依靠经验直觉引领方向、借助谨慎分析做出判断、并重视直觉发出的警示信号进行二次审视。

主要参考依据

• Gigerenzer 的启发式智能理论
• Klein 的自然决策与模式识别研究
• Netflix 转型案例（体现了基于经验的直觉价值）

文章摘要：不寻常的 Google 键盘 Bug

问题描述
在 Android 设备上使用 Gboard（Google 键盘）时，于某些网站（如 Guardian 填字游戏和 Typescript playground）出现退格键工作异常。例如，输入单词“test”后，需按退格键4次才开始删除字符。此问题在普通 HTML 输入字段中正常，且 iOS 键盘或 Gboard 在 iOS 上无此现象，表明是 Android 特有。

根本原因
Gboard 在生成自动更正建议时，退格键的浏览器事件（keydown/keypress/keyup）中 keyCode 始终为 229（Unidentified）。当自动更正建议清除后，keyCode 变为正确的 8（退格键）。这导致依赖特定 keyCode（如 keyCode 8）的代码失效，造成退格键需多次按压才响应。

平台与浏览器影响
此问题在 Chrome 和 Firefox 的 Android 版本上均出现，但表现形式不同：Chrome 中所有字母的 keyCode 均为 229；Firefox 中字母有正确 keyCode，但退格键 keyCode 为 229 且带 keyname“Process”。共同点是 Gboard，故作者认为问题源于 Gboard，具体原因未知。

解决方案
若需监听退格键，建议使用 beforeinput 事件并检查 inputType 是否为 deleteContentBackward。示例代码如下：

let input = document.querySelector("input");
input.addEventListener("beforeinput", (event) => {
  if (event.inputType === "deleteContentBackward") {
    // 处理退格操作
  }
});

对于 React 开发者，需注意 onBeforeInput 合成事件不包含 inputType 属性，应使用 addEventListener 手动订阅：

const ref = useRef<HTMLInputElement>(null);
useEffect(() => {
  const listener = (event: InputEvent) => {
    if (event.inputType === "deleteContentBackward") {
      // 处理退格操作
    }
  };
  ref.current?.addEventListener("beforeinput", listener);
  return () => ref.current?.removeEventListener("beforeinput", listener);
}, []);
return <input ref={ref} />;

监听特定字母时，可尝试使用 beforeinput 事件中的 data 属性。

Brendan Carr作为特朗普政府下任联邦通信委员会（FCC）主席的潜在人选，在保守派传统基金会的“2025项目”中撰写了章节，详细阐述了他的施政计划。

核心政策主张：

1. 放松对互联网服务提供商（ISP）的监管：Carr反对网络中立性规则等宽带管制，主张FCC进行“自上而下的审查”，废除“过于繁琐或过时”的法规，创建一个“市场友好型”的监管环境，促进有线、宽带和卫星互联网提供商的竞争与创新。
2. 加强对大型科技公司的监管：
   • 重新解释《通信规范法》第230条：旨在限制社交媒体平台的内容审核权力和法律保护，以打击所谓的“反保守派偏见”。
   • 要求科技公司为宽带基金付费：提议强制大型科技公司向FCC约90亿美元的“通用服务基金”缴纳费用，以补贴ISP的宽带网络建设。他批评科技公司“搭乘便车”却未分担成本。
3. 影响具体项目与分配：
   • 支持SpaceX星链：Carr强烈反对FCC拒绝向SpaceX的星链项目发放8.855亿美元政府资助的决定，指控这是对埃隆·马斯克的“监管骚扰”。
   • 可能放弃消费者保护倡议：例如，他很可能搁置现任主席发起的针对“数据上限”对消费者影响的调查，认为这会导致“费率管制”，并声称数据上限本身可以为用户提供更经济的选择。
4. 涉及广播执照与内容监管：
   • 在选举前夕，Carr指控NBC让民主党候选人卡玛拉·哈里斯上《周六夜现场》节目违反了“平等时间规则”，并暗示可能采取包括吊销执照在内的处罚。尽管NBC后来为特朗普竞选团队提供了同等的免费电视时间，Carr仍坚持其指控。
5. 国家安全：点名TikTok对美国国家安全构成威胁，认为其为中国提供“影响力活动”的机会。

权力与制衡： 文章指出，FCC主席拥有设定议程、决定投票事项和协调工作的显著权力，且可由总统直接任命现任委员担任，无需参议院投票。然而，其权力并非无限，国会可通过立法扩大或限制其权限，FCC的决定也常受法院挑战，近期最高法院的裁决已限制了联邦机构的监管权力。

背景与争议： Carr自2017年起担任FCC委员，是网络中立性的长期反对者。其政策立场（如放松ISP管制、严管科技公司）引发了消费者权益团体的担忧。批评者认为他急于通过迎合特朗普的议程来争取主席职位，其关于“平等时间规则”的指控也被媒体倡导组织指出存在事实错误。

Rails 8.0 发布概述

Rails 8.0 正式发布，其核心目标是大幅简化现代 Web 应用的部署与运维，减少对外部平台和服务的依赖，让开发者能够以更低的成本实现快速、安全且易于更新的生产环境。

主要新特性与改进如下：

1. Kamal 2 与 Thruster：一键部署

• Kamal 2：预配置的部署工具，可通过 kamal setup 命令将全新的 Linux 服务器快速转变为应用服务器，适用于云虚拟机或自有硬件。
• Dockerfile 与 Thruster：Rails 8 升级了自带的 Dockerfile，内置 Thruster 代理（位于 Puma 前），提供 X-Sendfile 加速、资产缓存和压缩，无需额外部署 Nginx 等 Web 服务器。
• Kamal Proxy：Kamal 2 换用了专属的 Kamal Proxy，支持零停机部署、通过 Let’s Encrypt 自动配置 SSL 证书，以及单服务器运行多个应用。
• 运维改进：集成了 1Password、Bitwarden 等密码管理器来管理 secrets，并新增 kamal console 等别名命令。

2. Solid 系列适配器：减少依赖 为降低复杂性，Rails 8 引入了三个基于数据库（特别是 SQLite）的适配器，取代了对 Redis 等服务的需求，核心前提是现代高速磁盘已能满足许多曾依赖内存的任务。

• Solid Cable：替换 Redis 用于 Action Cable 的消息传递（WebSocket），使用 SQLite 实现，性能接近 Redis，并默认保存消息一天以便调试。
• Solid Cache：替换 Redis/Memcached 用于缓存（特别是 HTML 片段）。利用磁盘存储可实现更大、更便宜、保留时间更长的缓存，并支持加密和保留期限管理。
• Solid Queue：替换 Redis 及 Resque/Sidekiq 等作业队列框架。支持 SQLite 用于轻量场景，也支持使用 FOR UPDATE SKIP LOCKED 机制以实现高性能。可作为 Puma 插件或通过 bin/jobs 命令独立运行，功能完备。

3. SQLite 生产就绪 配合 Solid 适配器，Rails 8 对 SQLite 适配器和 Ruby 驱动进行了大量改进，以确保其适用于生产环境，包括采用合适的默认模式（WAL、IMMEDIATE）和修复驱动问题。

4. Propshaft 取代 Sprockets Propshaft 成为新的默认资产管道，替代了自 2009 年沿用至今的 Sprockets。在 #NOBUILD 理念下，Propshaft 专注于两个核心功能：提供资产的加载路径和附加摘要以实现长期缓存，更适应现代浏览器和 HTTP/2 环境。

5. 认证系统生成器 新增命令 bin/rails generate authentication，可生成一套完整的基础认证系统，包含用户和会话模型、密码重置邮件器、控制器及认证关注点，为基于会话、支持密码重置和元数据跟踪的认证系统提供安全起点。

其他 Rails 8.0 还包含众多错误修复和整体改进，延续了框架的快速迭代节奏，旨在为开发者提供一个更强大、更自足的全栈框架。

本文探讨了日本软件产业长期落后于全球水平的根本原因及其历史背景。文章指出，日本软件质量的普遍问题并非源于技术人才短缺，而是植根于其独特的经济结构与发展路径。

历史根源：财阀体系与经连会的延续 日本现代经济结构可追溯至明治维新后的“财阀”体系。二战后美国占领当局虽试图解散这些家族控制的巨型集团，但在冷战背景下为促进经济增长，最终允许其以“经连会”形式重组。经连会内部交叉持股、互相扶持的封闭式商业模式，在硬件制造时代（如汽车、相机、半导体）取得了巨大成功，但这种结构也为软件产业的滞后埋下了伏笔。

关键转折点：错失PC与软件标准化浪潮 在1960-70年代的大型机时代，日本软件按订单开发，只需满足合同规格，软件被视为硬件销售的附属服务。然而在1980年代个人电脑革命中，软件开始向标准化、面向大众的“套装软件”转型。此时，日本正值经济繁荣期，经连会企业更倾向于服务集团内部的稳定客户，缺乏动力和压力去开拓充满不确定性的全球软件市场。它们专注于硬件和系统集成，将软件开发视为低技能、低附加值的工作，导致本土软件产业未能跟上全球创新步伐。

后果：创新停滞与职业文化扭曲 这一选择导致了严重后果：

1. 产业落后：日本错过了建立全球竞争力软件产业的机会，企业IT系统逐渐落后。
2. 创新动力衰退：企业IT策略依赖封闭的系统集成商，抑制了整体产业的技术迭代与创新。
3. 职业生态扭曲：软件工程师职业不受尊重，薪酬低，缺乏职业发展路径，人才流失严重。与此同时，硬件工程师始终享有很高声誉。

转机与未来展望 2010年代后，云计算和智能手机生态的兴起成为转折点。这些技术大幅降低了创业门槛，使软件开发者能够绕过传统企业渠道，直接面向市场创新。日本社会对开发者的看法开始转变，创业文化逐渐兴起。尽管整体水平仍有差距，但B2B SaaS等领域的新兴企业正帮助日本企业跨越式升级其陈旧的IT系统。随着政府将创业提升为国策，经连会企业也开始积极与创业公司合作投资。

结论 日本软件产业的问题本质是其特有的经济组织形态在适应新产业范式时出现的“结构性失灵”。当前，随着外部技术环境变化和内部产业结构调整，日本软件开发者正获得前所未有的重视与发展机会，其未来走势值得持续关注。

杂草抗药性危机正严重威胁全球农业。在美国伊利诺伊州，农民在约2300万英亩土地上种植玉米和大豆，几乎每块地都喷洒除草剂。然而，自上世纪80年代以来，越来越多的杂草进化出对除草剂的免疫力，这种抗药性与抗生素耐药性类似，且日益严重。

抗药性的蔓延与影响

• 关键杂草如水麻和长芒苋（Palmer amaranth）已进化出对多种除草剂的抗性。水麻能抵抗7类除草剂，可使大豆减产44%、玉米减产15%。
• 长芒苋生长迅猛，每天可超过2英寸，能完全摧毁作物产量。在佐治亚州，其出现曾导致大规模歉收，迫使农民割除整片田地。
• 据国际数据库统计，全球已记录超过500个独特的抗药性案例，涉及273种杂草、168种除草剂和21种作用机制。

抗药性加剧的根源

• 历史转折点是上世纪90年代孟山都推广抗草甘膦（农达）转基因作物，导致草甘膦过度依赖。公司曾声称杂草产生抗性“极不可能”，但现实恰恰相反。
• 杂草通过多种方式进化抗药性，包括：基因扩增（如Palmer amaranth可复制超过150个靶标基因）、染色体外环状DNA转移、以及发展出代谢抗性（即植物能分解多种外来化学物质）。
• 农民为应对，转向使用2,4-D、麦草畏和草铵膦等替代或混合除草剂，但这只是增加了化学物质的使用，并可能带来新的环境和健康风险。

环境与健康隐忧

• 许多替代除草剂毒性更强。百草枯已被60多个国家禁止（与帕金森病相关）；2,4-D是潜在的内分泌干扰物，与多种癌症风险增加有关；草甘膦被世卫组织列为可能致癌物；阿特拉津可在地下水中残留多年，并影响动物生殖系统。
• 专家指出，用更毒的除草剂替代草甘膦是“完全错误的方向”。

寻求解决方案

• 科学家强调，单纯依赖化学品无法解决问题。必须采用多样化控制策略，包括：混合使用不同作用模式的除草剂、轮作、种植冬季覆盖作物、以及避免每年重复使用相同除草剂。
• 创新技术正在涌现，但多处于早期或小规模应用阶段：
  • 物理/机械方法：蒸汽注入（效果达90%但耗时）、激光除草机器人（利用AI识别并汽化杂草）、电击除草（需杂草高于作物）。
  • 生物/信息素方法：如以色列公司WeedOut开发的辐射灭菌花粉技术，使雌性杂草无法产生可育种子。
  • 农业实践：清洁收割设备以防种子跨州传播、作物轮作、种植覆盖作物。这些看似简单，却至关重要。

系统性困境

• 现代农业趋向大型化、单一种植，这简化了管理但削弱了生态韧性。农民面临经济压力、劳动力短缺和短期思维，往往选择最便宜快捷的化学防治，尽管他们了解并担忧抗药性问题。
• 专家一致呼吁，农业必须从根本上转变，停止“视野狭窄地聚焦于除草剂”，转而拥抱多样化的杂草管理实践。这在当前以行栽作物（如玉米、大豆）为主的大规模农业体系中，实施起来尤为困难。抗药性危机是长期问题，但农业系统受短期思维主导，亟待一场根本性的变革。