乡村音乐传奇多莉·帕顿（Dolly Parton）逝世

著名乡村音乐创作歌手及慈善家多莉·帕顿（Dolly Parton）因癌症去世，享年80岁。她的死讯由其侄子 Brian Seaver 在社交媒体上发布，其团队证实，帕顿是在范德堡-英格拉姆癌症中心（Vanderbilt-Ingram Cancer Center）在亲人的陪伴下离世的。

音乐成就

帕顿是20世纪最伟大的创作歌手之一，以其生动的叙事能力、情感深度和旋律感著称。她的音乐生涯成就卓越：

• 经典作品：创作了《Jolene》和《I Will Always Love You》等传世名曲。后者不仅在乡村音乐领域取得巨大成功，后来由惠特妮·休斯顿翻唱后也成为流行音乐史上的经典。
• 榜单记录：拥有25首美国乡村音乐榜冠军单曲，47张专辑进入美国乡村音乐排行榜前十名。
• 奖项与合作：曾获得10项格莱美奖；曾与 Porter Wagoner、Kenny Rogers、Linda Ronstadt 和 Emmylou Harris 等知名艺人合作。

演艺与商业事业

除了音乐，帕顿在演艺和商业领域也取得了显著成就：

• 影视表演：曾出演《9 to 5》、《Steel Magnolias》等电影，并两次获得金球奖提名。
• 企业经营：通过其影视制作公司 Sandollar 参与了多部热门影视剧的制作；在田纳西州经营着著名的 Dollywood 主题公园。

慈善贡献

帕顿以其广泛的慈善事业闻名于世，致力于教育、医疗及社会公正：

• 儿童教育：创立了 Imagination Library 项目，通过邮寄书籍的方式支持全球儿童的识字教育，每年分发约4000万本书籍。
• 医疗研究：曾捐赠100万美元用于新冠病毒研究，该研究为后来的 Moderna 疫苗研发奠定了基础。
• 其他领域：她的慈善活动还涵盖了保护秃鹰、灾后救援、支持黑人权利（Black Lives Matter）以及跨性别权利等多个方面。

早年生活

帕顿出生于田纳西州一个贫困的家庭。凭借对音乐的天赋，她从在教堂唱歌起步，13岁便在 Grand Ole Opry 登台演出，最终从一名乡村音乐创作歌手成长为国际巨星。

Nitter 与 XCancel 收到停止并终止通知摘要

项目状态

Nitter 的 GitHub 仓库（zedeus/nitter）已于 2026 年 8 月 26 日被所有者归档，目前处于只读状态。

主要问题

根据 GitHub Issue #1442 的报告，所有公开的 Nitter 实例目前均无法正常工作。用户反馈，所有实例都遇到了相同的错误提示：“Instance has been rate limited”（实例已被限制速率）。

关键细节

• 问题发现时间：该问题于 2026 年 8 月 25 日提交。
• 故障现象：所有公共 Nitter 实例均显示速率限制错误，导致服务失效。
• 背景信息：根据标题显示，Nitter 和 XCancel 已收到“停止并终止”（cease and desist）通知。

《我的朋友亚伦》（My Friend Aaron）故事摘要

这是一篇关于名为亚伦（Aaron）的男子的短篇小说。故事通过叙述者的视角，讲述了亚伦从一个聪明但缺乏自律的学生，演变为一个通过操控AI技术和自身生活来博取暴利的互联网怪胎，最终走向悲剧结局的过程。

人物背景与性格特征

亚伦在学生时代表现出极高的天赋，但因极度缺乏学术专注力且具有严重的成瘾倾向，未能走上传统的学术或职业道路。他曾沉迷于《魔兽世界》，也曾试图从事足球运动员等职业。他在成年后因沉迷于非监管的预测市场（Prediction Markets）而欠下巨额债务。亚伦性格复杂，甚至带有反社会人格特征，缺乏道德底线，在利用技术进行诈骗时毫无悔意。

技术演变：从预测市场到AI机器人军团

在与叙述者的重新接触中，亚伦开始利用在编程竞赛（Hackathons）中获得的AI积分，构建自己的技术帝国。他不仅开发了一个预测市场平台，还培养了一支庞大的“AI机器人军队”。

为了测试这个平台，亚伦进行了一场极其疯狂的实验：他利用带有摄像头的眼镜进行24小时直播，让AI机器人实时观察并记录他的日常生活。机器人不仅根据他的行为（如早餐吃什么、听多少首歌）进行投注，甚至还创建了一个名为《亚伦时代》（The Aaron Times）的虚拟新闻网站，为这些投注提供模拟的背景数据。

走向疯狂：“亚伦秀”的崛起

原本处于封闭测试环境的机器人“突破”了沙盒限制，开始向现实世界推广该平台。这一行为意外引发了病毒式传播，平台更名为“亚伦秀”（The Aaron Show），吸引了成千上万的真实用户参与。人们开始投入真金白银，赌博亚伦在现实生活中的一举一动。

亚伦利用这种身份迅速积累了财富，但他通过操纵信息（如内幕交易）来获利。他变得日益孤僻、愤世嫉俗，与老友的联系也逐渐淡化。

悲剧性的结局

故事的高潮发生在一场10公里长跑比赛中。为了误导那些赌博的观众，亚伦指示他的机器人伪造了虚假的健身训练数据，让外界误以为他是一名体能优秀的选手。

在比赛过程中，亚伦因中暑和精神错乱，在冲过终点线后依然疯狂地继续奔跑，并对着人群大喊。就在混乱中，一名身穿连帽衫的神秘人冲入人群，使用气枪射击了亚伦的头部。

事后调查显示，有人在比赛前针对“亚伦会在比赛中死亡”这一极低概率事件（万分之五）进行了巨额投注。这场由技术、贪婪和成瘾交织而成的闹剧，最终以亚伦的死亡和神秘赢家的暴利画上了句号。

Firefox 157 将默认启用 JPEG XL

核心计划

Timothy Nikkel 宣布，从 Firefox 157 版本开始，将在所有平台上默认开启 JPEG XL 解码功能。该功能目前通过 image.jxl.enabled 配置项控制，此前已在 Nightly 版本中默认开启，并作为 Firefox Labs 的选项在各渠道提供。

技术实现与特性

• 解码器：采用使用 Rust 编写的 jxl-rs 解码器。
• 性能优化：通过集成 jxl-rs 0.6.0 版本，已引入多线程解码支持。基准测试显示，其解码性能略高于使用 C++ 库的 Safari 浏览器。
• 功能支持：
  • 支持动画（Animated JXL）和渐进式显示（Progressive Display）。
  • 在 HDR 支持方面，虽然目前 HDR 图像会以 SDR 方式显示，但其色调映射（Tone mapping）效果优于 Firefox 支持的其他格式。
• 测试覆盖：已通过 Web Platform Tests (WPT)、Gecko 测试（涵盖分块与增量解码、动画帧数、损坏文件等）、mochitests、reftests 以及模糊测试（Fuzzing）进行了广泛验证。

社区争议与建议

Sergey Davidoff 对无损（Lossless）JPEG XL 的性能表现提出了严重质疑。其观点如下：

• 性能瓶颈：根据测量，无损 JPEG XL 的解码速度比无损 WebP 慢约 30 倍，而文件体积仅能减少约 10%。
• 潜在影响：高昂的解码开销可能会导致笔记本电脑和移动设备的电池消耗过快，并降低用户体验。
• 改进建议：建议 Firefox 157 仅默认启用“有损（Lossy）JPEG XL”，并将无损格式的启用作为后续独立讨论的议题。

FDA 授权首款可同时监测酮体与血糖的穿戴式设备

美国食品药品监督管理局（FDA）已授权 Abbott Diabetes Care 开发的 Libre Duo 10 Day 连续双血糖-酮体监测系统。该设备适用于 2 岁及以上的糖尿病患者。它是美国首款可连续监测酮体水平的穿戴式设备，也是全球首款能在单一设备中同时连续监测酮体和血糖（葡萄糖）的设备。

核心功能与技术特点

• 实时连续监测：不同于以往只能提供单次测量结果的传统测试方法，该设备通过测量皮肤下方组织液中的成分，实现每分钟一次的全天候连续监测。
• 趋势分析与警报：监测数据通过无线方式传输至兼容的智能手机。用户不仅可以查看当前的酮体和血糖水平，还能观察其变化趋势（上升或下降）。当酮体水平达到预警阈值时，设备会自动发送警报，帮助患者及护理人员在糖尿病酮症酸中毒（DKA）演变为医疗紧急情况前及时干预。
• 临床价值：对于 1 型糖尿病患者而言，酮体水平过高会导致 DKA，这是一种危及生命的严重并发症。该设备的实时趋势监测功能填补了以往监测手段无法反映酮体动态变化的空白。

临床验证与监管路径

• 临床研究支持：FDA 的授权基于对该设备提交的临床和性能数据的全面审查。相关临床项目包括六项研究，共纳入 600 多名 2 岁及以上的受试者。结果显示，该设备在 10 天的佩戴期内能准确追踪具有临床意义的酮体水平差异，并在 DKA 发作前识别出升高的酮体。
• 审批流程：
  • De Novo 路径：FDA 通过 De Novo 预市场审查路径授予其上市许可，这是一种针对新型中低风险器械的监管路径。
  • 突破性器械认定：在获得授权前，该系统已获得 FDA 的“突破性器械”（Breakthrough Device）认定，旨在加速对治疗或诊断危及生命疾病的创新设备的开发与审查。
  • 特别控制措施：随授权一起，FDA 还建立了包括标签和性能测试在内的特别控制措施，以确保设备的安全性与有效性。
• 战略目标：此项授权符合 FDA 的“家庭作为医疗保健中心”（Home as a Health Care Hub）倡议，旨在推动开发能够更自然地融入患者日常生活的创新型、以患者为中心的设备。

可查询的可执行文件 (Queryable Executables) 摘要

本文介绍了一种名为 SELF 的新型可执行文件格式，其核心理念是将程序本身作为一个 SQLite 数据库。

核心概念与机制

SELF 格式改变了传统二进制文件的布局。通过利用 Linux 内核的 binfmt_misc 机制，可以触发一个自定义解释器。该解释器负责将 SQLite 数据库中 segments 表的行映射到内存中，并跳转到程序入口点。

这种设计的最大优势在于程序与状态的统一。由于可执行文件本身就是一个数据库，程序可以将其运行状态（如日志、配置、用户数据等）直接存储在运行所在的同一个文件中。这消除了对 /var/、/tmp/ 或 /home/ 等传统文件系统的依赖，并能利用 SQLite 的事务特性来保证状态更新的原子性。

概念验证：self-httpd

作者提供了一个名为 self-httpd 的 Web 服务器示例。该程序是一个单文件程序，其内部集成了以下内容：

• 程序逻辑：服务器的执行代码。
• 网站内容：存储在 routes 表中的 HTML/资源。
• 运行状态：存储在 visits（访问日志）和 presses（用户交互）表中的数据。

通过这种方式，Web 服务器不再需要外部数据库或文件系统，所有数据和代码都通过 SQL 语句进行管理和查询。

技术特性与优势

1. 真正可查询的可执行文件：与基于 ZIP 归档的 redbean（Actually Portable Executable）不同，SELF 将数据库作为容器。用户不仅可以运行它，还可以直接使用 SQL 语句（如 SELECT）来读取或修改程序的内容。
2. 自我访问机制：程序通过 argv[0] 获取自身文件的路径。解释器在跳转到程序入口点之前会释放 SQLite 连接，从而允许程序重新打开并操作自身文件。
3. 事务性实时编辑：利用 SQLite 的 ACID 特性，开发者可以在不重启或重新部署程序的情况下，通过 UPDATE 语句实时修改运行中的网站内容。
4. 强大的生态工具支持：
   • 使用 sqldiff 可以轻松审计两个程序版本之间的差异（包括代码段、符号表和应用数据）。
   • 利用 SQLite 的 FTS5 扩展，程序可以自带全文搜索功能。
5. 极简的部署流程：部署过程简化为单个文件的传输（如使用 scp）。当需要更新程序版本时，可以通过 SQL 迁移语句（INSERT INTO ... SELECT）将旧版本文件中的数据平滑迁移到新版本文件中，确保状态延续。

总结

SELF 格式通过将“字节布局规范”重构为“数据库架构”，简化了现代应用的构建与部署。它模糊了程序代码与数据的边界，使可执行文件成为了一个集逻辑、内容与状态于一体的完整系统。

SpaceX 公司概况

SpaceX 成立于 2002 年，致力于设计、制造及发射先进的火箭和航天器。其核心目标是通过革新航天技术，最终实现人类在其他星球居住的愿景。

XCancel 服务暂停事件总结

事件概述

XCancel 官方宣布，由于收到 X Corp 发出的“停止并终止”（cease and desist）信函，该服务已于 8 月 24 日（周一）美东时间晚上 8 点起停止运行。目前，XCancel 已无限期暂停服务，官方正在寻求法律建议，且暂不公开更多细节。

技术背景与替代方案

• 关联性：有用户指出 XCancel 与 Nitter（Twitter 的一种替代前端）有关联。
• 推荐工具：在讨论中，用户推荐使用 LibRedirect 扩展程序。该工具可以实现自动重定向功能，当用户点击原始链接时，浏览器会自动将其跳转至相应的替代前端（例如：Twitter 跳转至 Nitter，YouTube 跳转至 Invidious，Reddit 跳转至 Redlib 等），从而允许用户在不注册账号的情况下浏览内容。

用户讨论焦点

社区用户针对此次停服展开了多方面的讨论：

1. 使用动机：许多用户倾向于使用 XCancel 等替代服务，是为了避免创建 X 账号，并规避 X 平台强制要求登录才能查看内容的限制。
2. 影响力争议：部分用户认为，使用此类替代前端可以减少对 X 平台及其所有者（Elon Musk）的直接依赖；而另一部分观点则认为，使用这些服务本身并不能从根本上削弱平台的影响力。
3. 情绪化与立场：用户之间就“对服务的抵制是否属于道德标榜（virtue signaling）”产生了争论。部分用户对 Elon Musk 的管理方式表示强烈不满，并表示会尽可能避免使用其产品；也有用户认为这仅仅是一个商业服务，用户应当理性看待，而非过度情绪化。

https://www.bloomberg.com/news/articles/2026-08-26/china-s-z-ai-made-ox-alpha-stealth-model-that-rivals-deepseek

黑洞奇点是曲面而非点

本文挑战了流行文献中关于“黑洞中心奇点是一个点”的普遍观点，提出奇点本质上是一个曲面。

核心观点

1. 球对称黑洞中的因果分离 在广义相对论中，空间上的接近并不意味着因果上的接近。研究表明，如果两个观测者在同一时刻 $t$ 沿不同的角轨迹自由落入球对称黑洞，他们在到达中心奇点之前，就已经失去了彼此的因果联系。这一特性表明，奇点并非一个点，而是一个曲面。

2. 旋转黑洞的复杂性 对于旋转黑洞，情况虽然更为复杂，但结论保持一致。由于微小的经典或量子扰动会引发“质量膨胀不稳定性”（mass inflation instability），奇点曲面极有可能位于黑洞的内视界处，并最终导致塌缩为一个类时（spacelike）奇点曲面。

3. 对量子引力的启示 作者认为，无论最终的量子引力理论为何，黑洞的量子态可能都位于这个有效的二维奇点曲面上。该曲面与黑洞事件视界内产生的霍金辐射“热大气层”处于热力学平衡状态，并与其进行幺正（unitary）的共同演化。

RAG 架构简化指南：避免过度工程化

本文的核心观点是：许多工程师在构建 RAG（检索增强生成）系统时存在过度工程化的问题。开发者往往直接跳向复杂的嵌入（Embedding）、向量数据库和重排序（Reranking）流水线，而忽略了更简单、高效的方案。

1. 决策的核心维度

在选择 RAG 方案时，应基于以下五个关键因素进行权衡：

• 数据新鲜度需求：实时更新的数据（如新闻）需要易于重新索引的方案；稳定语料库则适合预嵌入。
• 语料库特征：高变动率（每日变化 >10%）应避免全量预嵌入；长尾分布（多数文档极少被访问）适合即时处理。
• 查询模式：关键词驱动的查询适合全文搜索；语义/对话式查询适合嵌入；混合模式则需要混合搜索。
• 规模与性能：查询量决定了优化程度。低查询量（<1K/日）使用简单方案即可；极高查询量（>10K/日）才需要深度优化。
• 团队能力：缺乏机器学习（ML）经验时，应坚持全文搜索 + 查询重写。

2. RAG 方案的演进阶梯（由简入繁）

第一阶段：BM25 全文搜索 (最基础)

• 适用场景：用户使用关键词查询（如订单号、特定术语）、对 ML 复杂度要求为零、希望零 API 成本且易于调试。
• 优点：极速（<10ms）、无需切片（Chunking）策略、无模型过时风险、易于验证。
• 缺点：无法处理同义词和深层语义意图。

第二阶段：查询重写 (Query Rewriting)

• 原理：利用 LLM 将模糊的对话式查询转化为干净的关键词搜索。
• 优点：解决词汇不匹配、增加同义词、处理领域术语（如公司内部代号）、迭代极快（只需调整 Prompt）。
• 成本：极低（如使用 GPT-4o-mini）。

第三阶段：混合搜索 (Hybrid Search)

通过 BM25 获取候选集，再利用 Embedding 进行重排序。根据数据特性分为三种模式：

1. 即时嵌入 (On-the-fly)：
   • 特点：对查询内容实时进行 Embedding。
   • 优点：数据新鲜度完美，模型切换成本极低。
   • 缺点：查询延迟较高（200-500ms）。
2. 冷热分层 (Hot/Cold Tiers)：
   • 特点：对高频访问文档进行预嵌入，低频文档采用即时嵌入。
   • 优点：在延迟、成本和灵活性之间取得平衡。
3. 全量预嵌入 (Full Pre-embedding)：
   • 特点：预先将所有文档转化为向量并存入向量数据库。
   • 优点：查询延迟极低（<50ms），适合超大规模稳定语料。
   • 缺点：维护成本极高，模型更新时需面临巨大的重算成本和停机风险。

第四阶段：智能体检索 (Agentic RAG)

• 原理：将复杂的多意图查询拆解为多个子查询，分别路由到最优检索方式，最后汇总结果。
• 优点：处理复杂任务的质量更高，且通过并行执行和按需调用，成本往往比直接重写长查询更低。

3. 实施路线图

不要一开始就构建复杂的系统，应遵循以下流程：

1. 建立基准：首先构建 BM25 全文搜索。
2. 测量反馈：运行 2-4 周并收集用户反馈。
3. 按需升级：
   • 如果用户反馈**“找不到明明存在的文档”** $\rightarrow$ 优先尝试 查询重写。
   • 如果用户反馈**“结果相关但不精准”** $\rightarrow$ 尝试 混合搜索（根据数据变动频率选择即时、分层或预嵌入模式）。
   • 如果用户反馈**“需要更强的语义理解”** $\rightarrow$ 转向 混合搜索 或 智能体检索。

总结：80/20 法则

• 60% 的系统只需“全文搜索 + 查询重写”即可解决问题。
• 25% 需要混合搜索。
• 10% 需要全量预嵌入。
• 5% 需要定制化方案。

结论：不要试图用 5% 的复杂方案去解决 60% 的简单问题。

Omarchy 开发实践导致可预测安全问题的总结

本文对 Omarchy（特别是 4.0 版本）的安全现状进行了严厉批评，指出其开发实践导致了大量可预测的安全漏洞。

核心安全问题

作者指出 Omarchy 存在严重的安全性缺陷，并列举了以下具体漏洞：

• Bash 注入攻击：例如视频标题引发的 Bash 注入漏洞。
• 任意代码执行：通知系统允许在机器上运行任意 Bash 命令。

这些漏洞被归因于对不可信输入处理不当，以及在缺乏审查的情况下，大量使用 AI 生成的 Bash 脚本进行处理。作者认为，试图在一个基础极其混乱（“bash slop”）的系统上通过事后修补来实现安全是不切实际的。

开发实践与安全态度

作者认为 Omarchy 的开发团队并未将安全性视为核心优先级。虽然团队会发布安全更新，但作者认为这种做法更像是“在漏洞百出的系统上打补丁”，而非从根本上构建安全。目前的开发模式更倾向于快速迭代功能，而非遵循严谨的安全开发流程。

营销与现实的偏差

文章批评了 DHH（David Heinemeier Hansson）的营销策略。作者认为：

• 误导性营销：DHH 将 Omarchy 塑造为一种精致的 Linux 桌面体验，但在安全方面却表现得过于乐观。
• 虚假的正向反馈：安全团队列出的已修复漏洞清单被视为一种营销手段，掩盖了系统本身架构上的脆弱性。
• 缺乏透明度：作者认为项目方并未向用户准确说明该系统在安全性上的真实风险，导致公众对使用该项目的风险感知与实际风险严重脱节。

结论

作者警告对安全性有要求的用户切勿使用 Omarchy，并指出由于该项目在安全性上的严重缺陷，未来可能会面临企业层面的禁用。

C2PA 在 Android 平台上的安全性漏洞分析

本文探讨了 C2PA（内容来源和真实性联盟）技术在 Android 平台（特别是 Google Pixel 设备）上的实现安全性问题。C2PA 的初衷是通过加密签名来证明图像是由相机捕获的真实内容，从而对抗 AI 生成的伪造图像。然而，研究表明该技术在 Android 环境下存在无法通过常规手段修复的根本性漏洞。

核心问题：Root 权限对信任模型的破坏

C2PA 在 Android 上的安全性依赖于 Key Attestation（密钥证明） 和 Google Play Integrity。其核心逻辑是：通过这些机制确保 C2PA 应用只能对来自设备图像传感器的原始数据进行签名，而不能对用户自定义的任意文件进行签名。

然而，漏洞在于 Root 权限的获取方式：

1. 绕过 Attestation 检测：传统的 Root 方式通常需要解锁 Bootloader，这会被 Attestation 机制识别并拒绝发放密钥。但如果攻击者利用 本地权限提升（LPE）漏洞 进行 Root，设备的状态（如锁定的 Bootloader、验证启动密钥等）在 Attestation 看来仍是正常的。因此，Google 的服务器仍会向已受损的设备发放合法的 C2PA 密钥。
2. 调用而非提取密钥：即使 C2PA 的私钥存储在硬件安全模块（如 Titan M2 的 StrongBox）中，攻击者无法直接提取原始密钥，但拥有 Root 权限后，他们可以命令硬件模块对任何任意数据进行签名。这意味着攻击者可以利用合法的硬件密钥来为 AI 生成的伪造图像提供“真实相机拍摄”的凭证。

主要攻击路径

研究人员指出了两种主要的攻击手段：

• 软件漏洞攻击：利用 Android 系统中的 LPE 漏洞（例如 CVE-2026-43499）获取 Root 权限。由于 LPE 漏洞层出不穷，即便 Google 发布补丁，攻击者仍可能利用未公开的漏洞或新出现的漏洞进行攻击。
• 硬件故障注入攻击：通过低成本的硬件攻击（如故障注入/电压注入）实现 Root。这类攻击直接针对硬件物理特性，无法通过软件补丁来修复，具有持久性和难以防御性。

技术挑战与缓解措施

尽管存在这些风险，但彻底修复 C2PA 在 Android 上的实现极其困难：

• 架构重构成本极高：要实现真正的安全性，整个图像处理流水线（包括 AI 处理和传感器数据流）都必须运行在具有强硬件内存保护的安全隔离区（Secure Enclave）内。
• Google 的立场：Google 已将此类问题标记为“无法修复（Won't fix (infeasible)）”，认为在现有架构下实现所需的安全性不切实际。
• 硬件防御的局限性：虽然像 Samsung 的 RKP（实时内核保护）等技术利用 hypervisor 增强了防御，但研究表明，通过硬件手段绕过这些保护仍有可能性。

影响范围

该漏洞的影响不仅限于 Google Pixel 设备，而是涵盖了所有在 Android 平台上依赖 Android_KeyAttestation 或 Google_PlayIntegrity 来实现 C2PA 合规性的应用。由于攻击者可以使用任何容易被 Root 的廉价 Android 设备作为攻击跳板，整个 Android C2PA 生态系统的信任模型都面临严峻挑战。

Python 中 str.lower() 导致的安全性漏洞总结

本文讨论了 Python 在实现国际化域名应用（IDNA 2003）标准时，由于错误使用 str.lower() 函数而引发的一个安全性漏洞（涉及 CVE-2026-17084）。

背景

在处理国际化域名时，需要将 Unicode 字符映射到 ASCII 字符。这一过程涉及以下标准：

• StringPrep (RFC 3454)：定义了字符预处理算法。
• IDNA 2003 (RFC 3491)：通过 Python 的 idna 编解码器（str.encode('idna')）实现。
• IDNA 2008：通过 PyPI 上的 idna 库实现，是目前更推荐的标准。

StringPrep 算法中的“大小写折叠”（case folding）步骤对于实现不区分大小写的字符串比较至关重要。根据 RFC 3454 的规定，该步骤必须遵循 Unicode 3.2.0 的规则。

漏洞原因

漏洞的核心在于 Python 在实现 StringPrep 的 B.2 和 B.3 表映射时，使用了 str.lower() 方法。

1. Unicode 版本不一致：str.lower() 的行为取决于 Python 解释器所携带的 Unicode 数据版本（可通过 unicodedata.unidata_version 查看）。随着 Unicode 标准的演进，str.lower() 的映射规则会发生变化。
2. 规范违背：StringPrep 规范严格要求使用 Unicode 3.2.0 的规则。然而，现代 Python 解释器通常使用更新的 Unicode 版本（如 17.0.0）。
3. 安全隐患：当 str.lower() 的行为与 Unicode 3.2.0 的规范不一致时，会导致域名编码结果出现偏差。例如，字符 'Ꭰ' (U+13A0) 在遵循 RFC 3454 的环境下编码为 'xn--58da'，但在使用 Unicode 17.0.0 的环境下会编码为 'xn--kz9aa'。这种不一致性可能被利用于绕过安全检查或进行域名欺骗。

修复方案

为了确保 IDNA 2003 实现与规范保持一致，开发者并没有直接更改 Python 全局的 str.lower() 行为，而是通过以下方式进行修复：

• 建立异常映射表：遍历所有 Unicode 码点，找出当前 Unicode 版本与 Unicode 3.2.0 在大小写折叠行为上的差异。
• 强制规则一致性：通过创建新的异常表，在执行 StringPrep 逻辑时，如果遇到这些差异码点，则强制使用符合 Unicode 3.2.0 标准的结果，从而使 idna 编解码器的行为恢复到符合规范的状态。

Python 预定义常量及其行为差异

Python 中存在 6 个预定义的“常量”：True、False、None、__debug__、Ellipsis（或 ...）以及 NotImplemented。尽管它们都被归类为常量，但在语法地位和行为逻辑上存在显著差异。

1. 关键字类：True、False 和 None

这些常量在 Python 中被视为关键字（Keywords），即词法标记（lexical tokens），而非普通的标识符。

• 语法特性：由于它们是关键字，无法作为属性名使用。例如，尝试访问 x.True 会直接触发 SyntaxError，而不仅仅是属性不存在。
• 内置模块行为：虽然它们在 builtins 模块中也有对应的定义，但无法通过常规手段直接访问。通过 setattr 修改 builtins 中的这些值，并不会改变关键字本身的语义（即 True 永远是 True）。

2. 特殊标识符：__debug__

__debug__ 是一个布尔常量，用于控制调试模式。在正常运行时为 True，而在使用 -O（优化）标志运行时为 False。

• 不可赋值性：它是 Python 中唯一一个无法被赋值或删除的普通标识符。尝试执行 __debug__ = 67 或 del __debug__ 都会触发 SyntaxError。
• 与关键字的区别：它不是关键字，因此其行为与 True 等不同。访问不存在的属性 x.__debug__ 会抛出 AttributeError，而非 SyntaxError。
• 修改局限性：虽然可以通过 setattr(builtins, '__debug__', 67) 修改 builtins 模块中的属性值，但这不会改变其作为常量的本质，直接访问 __debug__ 依然会得到其原始的布尔值。

3. 普通内置对象：Ellipsis 和 NotImplemented

与上述两者不同，这两个常量本质上是普通的内置对象。

• 可遮蔽性：它们可以被用户定义的全局变量所遮蔽（Shadowing）。例如，执行 NotImplemented = 67 后，原本的常量值就会失效。
• Ellipsis 的特殊性：
  • Ellipsis 是一个指向单例对象的名称，可以被重新赋值。
  • ...（Ellipsis 字面量）则是真正的常量。即使通过 setattr 修改了 builtins.Ellipsis 的值，字面量 ... 的行为依然保持不变。

总结对比

X Corp 向 XCancel 与 Nitter 发出停止并终止（C&D）函

X Corp 已向两个第三方服务项目 XCancel 和 Nitter 发出了停止并终止（Cease and Desist）法律函，要求其停止相关服务。

XCancel

• 现状：XCancel 在 8 月 24 日（美东时间晚上 8 点）收到 X Corp 的通知。目前，XCancel 服务已停止，直至另行通知。
• 后续：项目方正在寻求法律建议，目前不会公开更多细节。

Nitter

• 要求：X Corp 要求永久关停所有 Nitter 实例以及该项目的代码仓库。
• 现状：nitter.net 目前已处于离线状态，项目开发工作也已暂时停止。
• 后续：项目方正在寻求法律建议，目前不会就具体细节发表评论。

如何在 DigitalOcean 上以每月 4 美元的价格运行 OpenBSD

本文提供了一份详细指南，介绍如何利用 DigitalOcean 的基础方案（Droplet），以每月约 4 美元（含税约 4.24 美元）的低廉成本部署 OpenBSD 系统。

1. 下载与验证 OpenBSD 镜像

首先，需要下载 OpenBSD 的 miniroot 镜像（以 OpenBSD 7.9 amd64 为例）。

• 使用 curl 命令获取 miniroot79.img 及其校验文件 SHA256。
• 下载后，务必使用 sha256sum -c 命令验证镜像的完整性，确保文件未损坏或被篡改。

2. 在 DigitalOcean 上上传自定义镜像

由于 DigitalOcean 默认不提供 BSD 分发版，需要手动上传镜像：

• 登录 DigitalOcean，进入 Storage 栏目下的 Backups & Snapshots。
• 点击 Upload an Image，选择下载好的 miniroot79.img 文件。
• 注意：DigitalOcean 会对存储自定义镜像收取费用，建议在服务器成功创建并启动后，及时删除该自定义镜像以节省开支。

3. 创建 Droplet（云服务器）

• 在 Compute 栏目下选择创建 Droplet。
• 配置规格：选择 Basic 方案（512MB 内存、1vCPU、10GB 磁盘、500GB 流量），该配置每月费用为 4 美元。
• 镜像选择：在 Custom Images 选项卡中选择之前上传的 OpenBSD 镜像。
• 身份验证：必须添加 SSH Key 进行身份验证。
• 其他说明：创建时可能无法启用 IPv6。

4. 安装 OpenBSD 系统

通过 DigitalOcean 控制台提供的 Web Console 进入安装流程：

• 启动安装：在启动界面输入 i 进入安装模式。
• 基础配置：
  • 网络：选择 vio0 接口，并使用 autoconf 自动获取 IPv4 和 IPv6 地址。
  • 用户管理：设置 root 密码，并创建一个非 root 用户。为了安全，建议禁用 root 的 SSH 登录权限。
  • 服务：确保默认启动 sshd(8)。
  • 磁盘设置：选择 sd0 作为根磁盘。可以启用全盘加密（Full Disk Encryption），但需注意：若启用加密，每次系统重启后都必须通过 Web Console 手动输入解密密码。
• 精简安装（优化资源）： 由于是作为轻量级 Web 服务器使用，可以在安装软件包集合（sets）时通过命令精简掉不必要的组件，例如使用 -x* 移除 X Window System，使用 -gam* 移除游戏，使用 -com* 移除编译器。
• 镜像源：选择距离数据中心最近的镜像站进行下载。

5. 后续安全建议

安装完成后，通过 SSH 使用创建的非 root 用户登录服务器。为了提升安全性，建议执行以下操作：

• 将本地的公钥（Public SSH Key）复制到服务器上。
• 在 SSH 配置中禁用密码身份验证 (PasswordAuthentication no)。
• 参考 OpenBSD 官方手册进行后续的系统加固。

美国逾半数成年人表示缺乏基础统计学知识

根据宾夕法尼亚州立大学研究员 Mark Ramos 领导的一项最新研究显示，美国许多成年人意识到统计学在日常生活（如天气预报、医疗风险评估等）中的重要性，但普遍缺乏相关的基础知识。

研究核心发现

该研究发表于《PLOS One》，通过分析具有全国代表性的调查数据，得出以下关键结论：

• 知识匮乏： 62% 的受访者表示对统计学概念了解甚少或完全不了解。其中，四分之一的人表示完全没有统计学知识，37% 表示了解有限。
• 应用率低： 仅有 11% 的受访者表示在日常生活中经常使用统计数据。
• 学习意愿强： 尽管存在知识缺口，但绝大多数人（九成受访者）表示，如果能更好地理解统计学，他们会更愿意将其应用于决策过程。

研究背景与方法

这项研究由 Mark Ramos（宾夕法尼亚州立大学助理研究教授）与 Samuel Anyaso-Samuel（美国国家卫生研究院博士后研究员）共同完成。研究人员针对 1,000 名受访者提出了两个核心问题：

1. 对统计学及 p 值（p-values）的理解程度如何？
2. 如果理解程度提高，在多大程度上会根据报告的统计数据做出决策？

统计素养的重要性

研究强调，统计素养对于公民理解新闻报道、社交媒体信息以及影响生活的政策辩论至关重要。

• 关于 p 值： p 值是理解研究结果的工具；简单来说，p 值越小，代表统计证据越充分。
• 应对不确定性： Ramos 指出，统计学并不提供绝对的确定性，而是通过处理自然和社会中存在的不确定性，为决策提供一种合理的方法。理解这一概念有助于人们判断何时该信任或怀疑所看到的统计证据。

学习资源

为了帮助公众提高统计素养，研究人员建议利用各种免费资源。例如，宾夕法尼亚州立大学提供的“STAT 200：初等统计学”课程材料已在线公开，供非在校学生免费学习。

Tooltip（工具提示）交互优化：延迟与即时响应机制

本文探讨了如何通过引入“热/冷”状态切换机制，解决 Tooltip 在用户交互中常见的两个痛点：悬停移动时频繁误触发，以及连续悬停时响应迟钝的问题。

核心问题

1. 无延迟触发：若 Tooltip 设置为立即显示，用户在页面上移动鼠标时，路径上的所有图标都会弹出提示，造成视觉干扰。
2. 延迟响应迟钝：若为解决误触发而添加了固定延迟（如 200ms），当用户需要连续查看相邻的多个 Tooltip 时，每个 Tooltip 都需要等待同样的延迟，导致交互体验感到迟滞。

解决方案：热/冷状态模式

作者提出了一种通过“温暖窗口（Warm Window）”来平衡体验的方案，其逻辑如下：

1. 冷状态（Cold）：初始状态。用户悬停时，Tooltip 进入 200ms 的等待期。
2. 热状态（Warm）：一旦 Tooltip 打开，页面进入“热状态”。
3. 温暖窗口（Warm Window/Cooldown）：Tooltip 关闭后，启动一个 300ms 的计时器。在此期间，如果用户悬停在另一个图标上，Tooltip 将立即显示，跳过等待和动画。
4. 恢复冷状态：若 300ms 计时器结束仍未触发新的悬停，页面回归“冷状态”，下次悬停需重新等待 200ms。

状态流转图： 悬停 $\rightarrow$ 等待 200ms $\rightarrow$ Tooltip 打开 (进入热状态) $\rightarrow$ 离开 $\rightarrow$ Tooltip 关闭 $\rightarrow$ 300ms 冷却期

• 若冷却期内再次悬停 $\rightarrow$ 立即打开 (保持热状态)
• 若冷却期结束 $\rightarrow$ 回归冷状态

技术实现要点 (基于 React)

该模式通过一个 TooltipProvider 来管理全局/共享状态，主要包含以下逻辑：

1. 状态管理

• 使用 useRef 而非 useState 来管理 isWarm 状态。这样在读取状态时不会触发整个页面的重新渲染，仅在事件处理函数中读取。
• markOpened()：将页面标记为“热”，并清除当前的冷却计时器。
• markClosed()：启动 300ms 的冷却计时器，计时结束后将页面标记为“冷”。

2. 触发逻辑

• onMouseEnter：检查 isWarm。若为真，立即调用 show()；若为假，使用 setTimeout 开启 200ms 延迟。
• show() 函数：
  • 打开 Tooltip。
  • 将 isWarm 的值赋给一个 CSS 属性（如 data-instant="true"），以便通过 CSS 实现零延迟动画效果：

    .tooltip[data-instant="true"] { transition-duration: 0ms; }
    

• onMouseLeave：
  • 清除尚未触发打开的 setTimeout（防止用户快速滑过图标时弹出提示）。
  • 若 Tooltip 已打开，则关闭它并通知 Provider 进入冷却阶段。

3. 关键参数建议

• 打开延迟 (200ms)：低于 150ms 容易误触，高于 250ms 会感到迟钝。
• 温暖窗口 (300ms)：足以覆盖用户从一个触发元素移动到下一个元素的时间。
• 关闭延迟 (0ms)：离开触发器时应立即响应，无需等待。

总结

优化 Tooltip 的关键在于识别“点击是蓄意的，而悬停往往不是蓄意的”。通过这种结合了延迟与即时响应的精细化定时器管理，可以显著提升用户界面的精致感（Polished feel），将“能用”的产品提升为“好用”的产品。

LatticeDB 简介

LatticeDB 是一款嵌入式、单文件的属性图数据库，其设计理念类似于“图数据库界的 SQLite”。它专为单机环境下的关系密集型工作负载设计，能够在一个引擎和单一查询层内，同时实现关系遍历、向量相似度搜索（Vector Search）和 BM25 全文检索。

核心特性

• 单文件存储：整个数据库存储在一个可移植的单文件中，无需配置复杂的服务器，实现零配置运行。
• 统一查询层：支持在同一个 Cypher 风格的查询语言中，同时进行图遍历、HNSW 向量搜索和 BM25 全文检索。
• 本地优先（Local-first）：采用嵌入式单写者模型，通过 WAL（预写日志）确保数据持久性，适用于单个进程管理。
• 统一事件日志：内置持久化的命名流（Named Streams）和图变更反馈（Graph Changefeed），与图写入共享相同的事务/WAL 路径。

技术功能

1. 图数据库功能 (Graph)

• 支持带标签（Labels）和任意属性（Properties）的节点与边。
• 支持多跳遍历及变长路径查询（如 *1..3）。
• 提供 ACID 事务支持（提交/回滚及崩溃恢复）。
• 支持聚合操作（count, sum, avg 等）和 Cypher 关键字（MERGE, WITH, UNWIND 等）。

2. 向量搜索 (Vector Search)

• 基于 HNSW 算法的近似最近邻（ANN）搜索。
• 支持可配置的参数（M, ef）。
• 内置哈希嵌入工具，也支持通过 HTTP 客户端对接 Ollama 或 OpenAI。

3. 全文检索 (Full-Text Search)

• 基于 BM25 评分算法的反向索引。
• 支持分词、词干提取以及基于 Levenshtein 距离的模糊搜索。

4. 查询语言

• 使用类似于 Cypher 的语法，并扩展了专用操作符：
  • <=>：向量距离操作符。
  • @@：全文搜索操作符。

性能表现

LatticeDB 在单线程测试（Apple M1）中表现出极高的效率：

• 节点查询：延迟仅为 0.13 $\mu$s，性能媲美内存中的 RocksDB。
• 图遍历：在深度遍历任务中，性能远超 SQLite（在深度为 50 的任务中，比 SQLite 快约 2819 倍）。
• 向量搜索：在 100 万个向量规模下，平均延迟为 0.83 ms，且召回率达 100%，优于许多服务器级向量数据库。
• 全文检索：BM25 检索延迟仅为 19 $\mu$s，比 SQLite FTS5 快约 300 倍。

适用场景与局限性

推荐场景

• 连接型本地数据：如笔记、文档、引用图谱、实体图谱。
• Graph RAG 与 AI Agent：作为智能体记忆层，结合关系、语义和文本检索。
• 本地知识工具：需要在本地运行且无需独立服务器的嵌入式应用。
• 原型开发：作为 Neo4j 或 Weaviate 的轻量级本地替代方案。

局限性（不建议使用的场景）

• 多应用并发写入：由于采用单写者模型，不适合需要多个客户端同时写入的场景（应选择 PostgreSQL 或 Neo4j）。
• 纯表格式数据：如果数据主要是行列结构，使用 SQLite 或 PostgreSQL 更简单高效。
• 大规模分布式需求：LatticeDB 仅限单机单文件，不支持分片或多节点集群。
• 完全的 Cypher 支持：目前尚未实现 OPTIONAL MATCH 和 CALL 等高级功能。

开发支持

• 开发语言：使用 Zig 编写，无外部依赖。
• 语言绑定：提供 C API，并拥有 Python、TypeScript/Node.js 和 Go 的官方/半官方绑定。

美国政府拟削减数据中心审批的透明度

美国环境保护署（EPA）正计划取消一项要求，即不再强制要求各州在审批“次要污染源”（minor source）的空气污染许可时寻求公众反馈。这一变动若实施，将显著降低数据中心建设审批过程中的透明度，尤其是在当地社区试图通过法律或行政手段阻止或延迟 AI 数据中心建设的背景下。

核心变动与影响

• 受影响范围：该提议针对的是“次要污染源”的许可申请，涵盖了垃圾填埋场、洗衣店、钢厂以及数据中心。
• 主要目标：尽管 EPA 声称这些污染源不需要联邦监管，但分析指出，随着 AI 数据中心的扩张，其环境影响日益显著。例如，弗吉尼亚州 Loudoun 县的 Vantage 数据中心估计每年造成的健康损害高达 5300 万至 9900 万美元。
• 监管权限转移：目前的联邦法律要求必须进行公众评论期。若提议通过，监管责任将完全移交给各州，州政府可能会利用这一机会取消公众评论环节，使审批过程在缺乏公众监督的情况下进行。

各界反对声音

来自 14 个州的州总检察长和 3 个城市签署了公开信，强烈反对这一变化。他们指出：

1. 忽视环境风险：即便被称为“次要”污染源，仍可能对健康和环境造成重大影响。
2. 牺牲民主程序：取消许可申请的公开化和 30 天的公众评论期，实际上是在为了“行政效率”和“减轻监管负担”而牺牲基本的透明度和民主保障，其核心目的是为了加速数据中心及 AI 基础设施的建设。

现行制度下的漏洞

报告指出，即使在现行要求公众参与的规则下，部分项目也已存在绕过公众监督的情况：

• 加州 Gilroy：亚马逊（Amazon）的一家数据中心在居民不知情的情况下开工，原因是长期的审批过程导致公众评论窗口在建设开始前两年就已关闭。
• 密苏里州 Festus：当地居民因政府未能在数据中心提案通过前留出足够的审查时间而提起诉讼。

总结

EPA 的这项提议若在未来一年内生效，将赋予各州更大的自主权来决定是否进行公众讨论。这可能导致数据中心的审批过程更加封闭，削弱当地社区对大型科技基础设施扩张的影响力。

TeXbrain 项目简介

TeXbrain 是一个免费、开源且完全在浏览器中运行的 LaTeX 编辑器。其核心设计理念是无需安装、无需账户、无需服务器，通过 WebAssembly (WASM) 技术实现全客户端运行，解决了传统在线编辑器功能受限（如 Git 同步需付费）或本地环境配置复杂的问题。

核心功能

• 浏览器内 LaTeX 编译：利用 WebAssembly 移植的 pdfTeX（SwiftLaTeX）引擎，直接在客户端完成 .tex 到 PDF 的编译。所有编译过程均在本地完成，无需将文件上传至服务器。
• 按需加载 CTAN 宏包：内置常用宏包，其余宏包会从 TeX Live 镜像自动下载并进行本地缓存，以便实现离线使用。
• 深度 Git 集成：通过 isomorphic-git 实现完整的 Git 工作流，支持克隆仓库、创建分支、暂存、提交、推送及拉取。由于运行在浏览器中，它与本地终端操作的 .git 目录完全同步。
• 本地文件系统访问：通过 File System Access API（支持 Chrome/Edge 等 Chromium 系浏览器）直接读写用户磁盘上的项目文件夹。
• 高级编辑器体验：基于 CodeMirror 6 构建，提供语法高亮、70 多种 LaTeX 命令的自动补全、代码折叠、命令面板及代码片段选择器。
• 智能错误处理：将晦涩难懂的 LaTeX 编译日志转化为易于理解的“问题卡片”，清晰展示错误原因、所在行数及修复建议，并支持点击跳转。
• 实时 PDF 预览：集成 pdf.js，支持多页显示、缩放及文本选择。

技术架构

局限性

• 引擎限制：目前仅支持 pdfTeX，暂不支持 XeTeX 或 LuaTeX（因此无法使用 fontspec 等需要特定引擎的包）。
• 参考文献支持：暂不支持 BibTeX 或 Biber。目前通过从 .bib 生成 thebibliography 的方式实现引用，但会忽略特定的引用样式。
• 版本限制：宏包版本固定在 TeX Live 2020 时代。
• Git 远程操作：由于浏览器协议限制，Git 的远程操作（Push/Pull/Clone）需要通过 CORS 代理。
• 浏览器兼容性：直接访问本地文件夹的功能仅限 Chromium 系浏览器；Firefox 和 Safari 使用虚拟文件系统作为后备方案。

安全与隐私

TeXbrain 强调极高的安全性与隐私保护：

• 数据本地化：文件始终留在用户的机器上，除非用户主动执行 Git 推送操作。
• 无追踪：不包含任何遥测、分析或数据收集机制。
• 沙箱环境：LaTeX 编译在 WebAssembly 沙箱中进行，无法执行系统级 shell 命令，有效防止命令注入攻击。
• 凭证安全：Git 身份验证令牌仅存储在浏览器的 localStorage 中。

Oldinsurancemaps.net 正式成为 OSM US 特许项目

项目概述

OldInsuranceMaps.net (OIM) 现已正式宣布成为 OpenStreetMap US (OSM US) 的最新特许项目 (Charter Project)。该平台致力于提供地理参考化的 Sanborn 保险地图，为历史地图研究和地理数据获取提供便捷的数字化手段。

Sanborn 地图及其价值

Sanborn 地图涵盖了 1867 年至 1960 年代期间美国极其准确的地理信息。这些地图不仅具有艺术美感，更是历史学家、学者、城市规划专业人士以及地理爱好者进行研究的重要资源。通过 OIM 平台，这些原本存在于庞大纸质卷册中的历史数据变得更加易于获取和数字化利用。

技术实现与发展历程

• 项目起源： OIM 由 Adam Cox 于 2022 年在路易斯安那州立大学期间发起。
• 资源规模： 目前平台托管了超过 1200 张 Sanborn 地图，主要来源于美国国会图书馆。
• 核心功能： 任何用户都可以申请添加特定城市或城镇的 Sanborn 地图。通过在扫描地图上放置地面控制点并进行数字缝合，志愿者可以完成地图的地理参考化工作。
• 易用性： 平台的界面设计直观，即使不具备地理信息系统 (GIS) 专业知识的用户也能轻松参与地图制作。

与 OSM 生态系统的协同效应

作为 OSM US 的特许项目，OIM 与 YouthMappers、Yesterdays 以及 OpenHistoricalMap (OHM) 共同构成了历史地理数据处理的协作生态：

• 工作流整合： OHM 的贡献者可以利用 OIM 生成的地理参考图层作为历史参考，在编辑时进行追踪。
• 多平台联动： Yesterdays 将 OIM 的 Sanborn 地图作为基础图层，协助用户更准确地放置历史图像。

如何参与

社区成员可以通过以下方式支持 OIM 项目：

• 地图制作： 在 oldinsurancemaps.net 进行地图的地理参考化工作。
• 资金支持： 通过 OSM US 向项目捐款。
• 社区交流： 加入 OSM US Slack 中的 #oldinsurancemaps 频道。
• 技术贡献： 在 GitHub 上参与项目的代码开发。