离开Rust游戏开发：三年后的反思

核心问题与结论

作者作为一名小型独立开发者（2人团队），在多年使用Rust进行游戏开发并完成多个项目后，决定放弃使用Rust开发游戏。其核心原因是Rust语言的设计理念与独立游戏开发快速迭代、灵活试错的核心需求存在根本冲突。尽管投入了大量时间（超过3年，10万行代码），但许多根本性问题并未随着经验积累而消失。

主要痛点详述

1. 语言核心：借用检查器与迭代速度

• 强制重构，打断心流：借用检查器常在最不合时宜的时候要求重构代码，阻止开发者“先写出来，以后再优化”的常见策略。在游戏开发这种需求频繁变动的领域，这严重拖慢了迭代速度。
• “写好代码”的悖论：虽然重构能让代码更“好”，但对独立游戏而言，快速验证玩法想法比代码的长期可维护性更重要。Rust迫使开发者在“测试想法”和“优化代码”之间做出选择。

2. 架构模式：ECS的过度推崇与误导

• 解决错误的问题：ECS（实体组件系统）在Rust社区被推崇，很大程度上是为了解决语言自身的借用和所有权问题，而非出于游戏设计需要。
• 不必要的复杂性：作者认为，对许多游戏而言，使用代际 arena（如 thunderdome） 管理实体就足够了，完整的ECS架构引入了不必要的复杂性和抽象成本。
• “正确方式”的迷思：Rust社区有时将ECS等特定模式上升到近乎教条的程度，忽略了其他更直接、更适合特定游戏的实现方式。

3. 生态系统与工具链

• 编译时间：虽有改善，但过程宏（proc-macros，如serde）会导致增量编译缓慢，迫使开发者进行繁琐的代码拆分以优化编译。
• 缺乏热重载：与C#/.NET或Unity相比，Rust缺乏成熟、通用的热重载能力，这极大地影响了调试、调参和UI打磨的效率，是作者选择回归Unity的首要原因。
• GUI困境：Rust缺乏适合游戏开发的GUI库。现有库要么过于通用，要么不适合制作高度定制化、富有表现力的游戏UI（如按钮动效、粒子效果）。
• 生态系统存在“炒作”倾向：许多项目因出色的宣传和文档获得关注，但实际可用性和成熟度不足。一些实用但“不够纯粹”（如使用全局状态）的优秀库（如Macroquad）反而被低估。

4. 理念冲突

• 单线程游戏与全局状态：大多数游戏逻辑本质上是单线程的。Rust对全局状态的严格限制（基于安全考虑）带来了不必要的复杂性，而简单的解决方案（如Rc<RefCell<T>>）又可能引发运行时崩溃。
• 过度工程：Rust鼓励泛化、分离关注点等“正确”的工程实践，但这有时会导致代码过于复杂和抽象，反而阻碍了快速实现和理解简单的游戏逻辑。
• 上下文对象与灵活性不足：为满足借用规则而设计的“上下文对象”模式，在添加新功能时常常需要重构，缺乏其他语言中的灵活性。

Rust的优点

尽管决定离开，作者仍肯定了Rust的几个方面：

• 编译即正确：当代码符合Rust范式时，编译通过后往往能正常工作。
• 默认高性能：Rust代码通常具有优秀的运行时性能。
• 出色的枚举和特征系统：在适合的场景下非常强大。
• 强大的工具链：rust-analyzer尽管偶有问题，但极其有用。

未来计划

作者团队将回归Unity开发，以利用其成熟的编辑器、完善的工具链（特别是热重载）和庞大的生态。他们计划将自研的2D游戏框架Comfy的渲染器从wgpu移植到Macroquad，以获得更好的平台支持和维护稳定性。

总结

本文并非对Rust语言的全面否定，而是从一名追求商业可行、快速发布的独立游戏开发者的视角出发，指出Rust当前的语言特性、生态系统和社区文化与这一具体开发目标之间存在的显著摩擦。作者的结论是：对于需要高强度迭代、玩法探索和快速交付的独立游戏开发，其他工具（如Unity）提供了更顺畅的路径。

Apple ID 大规模异常登出事件概要

事件概述
近期（具体日期为4月26日晚间），大量Apple用户报告其Apple ID被异常强制登出，且无法使用原密码登录，必须重置密码才能恢复账户访问。该问题在社交媒体上引发广泛讨论。

核心现象

1. 异常登出：用户在所有设备（如iPhone、iPad、Mac）上被同时登出Apple ID。
2. 账户锁定：尝试使用原有密码登录会导致账户被锁定。
3. 强制重置：用户必须通过重置密码流程，才能重新登录账户。

关键细节与影响

• 官方状态页面无提示：苹果的“系统状态”页面并未显示任何相关服务中断，但用户报告的问题真实存在。
• 原因不明：事件发生突然，且没有明确的触发原因或解释。
• 关联可能性：报道指出，此事件是否与近期持续的“密码重置攻击”问题相关，目前尚不明确。
• 特定功能用户受影响更大：对于启用了“被盗设备保护”功能的用户，如果在非信任位置被突然登出，将面临额外麻烦。
• 连锁反应：重置Apple ID密码会导致所有已设置的“App专用密码”同步失效，用户需要重新生成。
• 报道来源：科技媒体9to5Mac也表示其内部员工受到了直接影响，并已向苹果公司寻求回应，暂未获得官方回复。

用户反馈佐证
社交媒体上涌现大量用户投诉，具体表现为：

• 在FaceTime通话中突然被登出。
• 收到强制要求立即更改密码的警告。
• 设备上反复弹出密码输入提示。
• 密码重置过程中遇到错误。 用户普遍在Twitter、Mastodon、Threads等多个平台表达了对问题的困惑与不满。

SVG查看器是一款用于查看、编辑和优化SVG文件的工具。其核心功能包括旋转、翻转（如Y轴翻转、X轴偏移-1px）以及更改尺寸。优化方面，工具展示了文件大小的减少示例：从578字节优化至493字节，降幅15%。此外，工具提供偏好设置选项和文件上传功能，并显示100%状态可能表示操作进度或完成状态。

该程序通过遗传算法将随机双轮形状进化成汽车，每代逐步优化。

程序概述

• 基于BoxCar2D概念但完全重写，使用相同的物理引擎（Box2D）。
• 包含种子随机数库seedrandom.js。

控制功能

• 保存/恢复种群：本地存储当前种群或恢复已保存种群。
• 惊喜开关：切换绘图模式，加快模拟速度。
• 新种群：保留赛道，重启汽车种群。
• 种子创建世界：相同种子生成相同赛道，便于多人竞赛。
• 突变率：新一代中每个基因随机变异的概率。
• 突变大小：基因变异范围，数值越小变异越接近原值。
• 精英克隆：直接复制到下一代的前N名汽车。
• 查看顶尖回放：暂停模拟并展示最优汽车，再次点击恢复。

图表显示

• 红色：每代最高分。
• 绿色：每代前十名平均分。
• 蓝色：每代整体平均分。

基因组组成

• 形状（8个基因，每个顶点1个）
• 车轮大小（2个基因，每个车轮1个）
• 车轮位置（2个基因，每个车轮1个）
• 车轮密度（2个基因，颜色越深密度越大）
• 底盘密度（1个基因，颜色越深密度越大）

备注

• 程序非完全确定性，最优汽车性能可能波动。
• 赛道复杂度随距离增加。
• 若脚本加载异常需刷新页面。

项目信息

• 源码已发布于GitHub仓库，欢迎贡献。
• 最初由原作者编写，后经GitHub用户协作完善。

Moviecart 是一个软硬件结合的项目，旨在为原版 Atari 2600 游戏机制作可播放完整长度彩色电影与音频的卡带。

主要功能与特性：

• 通过卡带形式，在 Atari 2600 上播放全长度影片。
• 视频分辨率为 80×192，支持 7 位色彩，音频为 4 位单声道。
• 用户可通过操纵杆控制亮度、音量和播放进度；利用游戏机本体开关切换黑白模式、10 秒后退或完全后退。

技术规格：

• 视频以每秒 60 帧交替输出两个场，每场由 10×262 个单元格的棋盘图案构成。
• 每个单元格可显示 128 种颜色之一，尺寸为 8 像素宽 × 1 像素高，因此有效分辨率相当于 80×262 @ 30fps，且每行可显示 10 种颜色。
• 音频采样率为 15.720 KHz，4 位单声道。
• 每场需要 2.5KB 数据，每秒数据量约相当于 75.5 个 Combat 卡带，一部 2 小时电影所需数据量相当于超过 50 万个卡带。

获取与制作：

• 项目提供软件与硬件工具，供用户自行编码和制作影片卡带。
• 套件可在 Tindie 平台预购。
• 项目依据美国版权法第 107 条（公平使用条款），适用于评论、新闻报道、学术研究等非营利、教育或个人用途。

联系方式： lodef.mode@gmail.com

大语言模型的能力边界与局限性

本文深入探讨了大语言模型（LLM）的能力限制，指出尽管LLM在许多复杂任务上表现出色，却无法完成一些看似简单的推理与序列计算任务。文章通过多个具体案例，分析了其根本原因，并展望了未来的发展方向。

一、LLM无法完成的任务示例

作者通过实验发现，当前最先进的LLM（包括GPT-4和Opus）在以下任务中普遍失败：

1. 序列游戏与谜题：无法独立完成Wordle、数独或简单的填词游戏（如wordgrids）。即使给予迭代机会或提供历史答案，它们也难以在网格中逐单元格进行正确的递进计算。
2. 关系泛化（逆转诅咒）：如果模型在训练数据中学习了“A是B”的句子，它并不能自动泛化出“B是A”的反向知识。例如，知道“瓦莲京娜·捷列什科娃是第一位进入太空的女性”，却无法可靠回答“谁是第一位进入太空的女性”。
3. 元胞自动机预测：模型难以准确预测康威生命游戏（Conway's Game of Life）等元胞自动机的后续状态。即使通过微调专门训练，模型也仅能记忆示例模式，而无法泛化到更大的网格或学习到底层规则。这表明LLM无法真正模拟需要迭代计算的确定性过程。

二、失败的根本原因：结构性局限

文章指出，这些失败主要源于LLM的构建方式，而非单纯的训练数据不足：

1. 单次前向传播与缺乏迭代计算：LLM是自回归模型，通过单次前向传播生成每个token。它们缺乏“停下、收集状态、推理、回溯或预测”的迭代计算能力。其注意力机制是静态的，无法动态重置上下文或有选择性地聚焦。
2. 目标漂移：在长序列推理中，模型容易“忘记”最初的目标和关注重点。随着上下文增长，推理的可靠性下降，注意力机制无法在多步任务中保持精确性。
3. 无法进行真正的泛化：LLM通过模仿训练数据中的模式来工作，但难以学习并泛化背后的明确规则。它们擅长的是基于海量数据关联的“直觉式”反应，而非执行需要严密逻辑和状态跟踪的计算。其输出对提示词的措辞高度敏感。

三、部分解决方案与现状

目前，可以通过外部手段部分缓解这些局限：

• 链式思维与中间步骤：将复杂问题分解，要求模型展示中间推理步骤（如使用草稿本）。
• 提示工程与多轮交互：精心设计提示，并可能使用多个LLM进行相互检查与修正。
• 工具与记忆：为模型提供访问外部计算工具、代码执行环境和记忆存储的能力。

这些方法能将“推理任务”转化为模型更擅长的“模式匹配”任务，但需要大量人力设计，且仍无法从根本上解决目标漂移问题。

四、结论与展望

1. 能力本质：LLM是强大的“模糊处理器”，它们通过学习海量数据中的模式，展现出惊人的直觉和知识整合能力，能在训练数据分布内模拟智能行为。然而，它们本质上是概率模型，并非通用推理机。
2. 可靠性瓶颈：其主要弱点在于需要多步、状态依赖推理的任务，可靠性随步骤增加而下降。这构成了当前开发自主智能体（Agent）的主要障碍。
3. 未来方向：要实现更接近通用人工智能的突破，可能需要超越当前Transformer架构的根本性创新。未来方向可能包括：
   • 为模型添加可动态访问的持久化记忆和计算模块。
   • 构建具备层级规划能力的多智能体系统，其中专门化的子智能体负责特定任务。
   • 探索能够更灵活、动态调整注意力的新型架构。

总结而言，LLM的失败比其成功更能揭示其本质。它们在模仿和关联方面成就非凡，但距离真正的、可泛化的“思考”仍有结构性鸿沟。当前的技术路径可通过巧妙的工程手段极大扩展其应用范围，但要突破其根本局限，仍需在模型架构上寻求革新。

Bun 新型崩溃报告器

背景与动机

• Bun 面临超过 2600 个开放 GitHub issue，部分问题难以重现和调试。
• 传统 CLI 工具崩溃报告（如上传核心转储）存在隐私、性能和可执行文件体积的权衡问题。
• 操作系统自带的崩溃报告通常需要附带调试符号（如 Linux 约 30 MB，Windows 超 250 MB），导致安装包体积膨胀。

核心解决方案

• 在 Bun v1.1.5 中引入了新型崩溃报告格式，生成约 150 字节的 URL，不包含任何个人敏感信息。
• URL 结构包含：平台标识、子命令、提交 SHA、特性标志、栈跟踪地址、崩溃类型和消息。

技术实现要点

地址处理

• 通过从二进制基地址中减去原始地址来获取相对地址，解决地址空间布局随机化（ASLR）导致的地址无意义问题。
• 不同操作系统获取模块基地址的方式不同：
  • Windows：使用 GetModuleHandleExW。
  • Linux：使用 dl_iterate_phdr 迭代。
  • macOS：使用 _dyld_image_count 和 _dyld_get_image_header 等函数。

URL 编码

• 采用 Base64 变长数量（VLQ） 编码栈跟踪地址，压缩 URL 长度。
• 特性标志 编码为 64 位整数，每位对应 Bun 的一个功能（如 bunfig、http_server 等），使用 Zig 的编译时元编程实现位图结构。

工作流程

• 崩溃时生成包含编码信息的 bun.report URL。
• 服务器端解码 URL，下载对应提交版本的调试符号，使用 llvm-symbolizer 将相对地址映射为可读的函数名。
• URL 重定向至预填充的 GitHub issue 表单，便于用户提交报告。

优势与对比

• 相比核心转储，体积大幅减小，避免泄露敏感信息（如源代码、环境变量）。
• 专注于捕获 Zig/C++ 栈跟踪等关键诊断信息，必要时可向用户索取更多细节。
• 配套工具 bun.report 可解码 URL 并提供友好的崩溃报告查看界面。

技术亮点

• Zig 编译时元编程简化了特性标志的位图管理。
• 通过 inline for 动态构建打包结构体，实现编译时遍历、运行时填充。
• 服务器端集中处理符号解析，平衡了隐私保护与调试效率。

本文探讨了大规模网络爬虫技术及其规避反爬虫检测的方法。作者基于自身运营爬虫服务的经验，指出使用商业代理服务存在信任和成本问题，并介绍了利用AWS Lambda配合无头浏览器实现每周数百万次Google搜索结果页面爬取的方案。该方法依赖数据中心IP，虽能应对Google等允许一定程度爬取的网站，但对于部署了先进反爬虫系统的网站（如DataDome、Akamai）则难以生效。

文章详细列举了反爬虫公司使用的多种检测技术，包括浏览器指纹识别、TCP/IP指纹、WebGL指纹、WebRTC真实IP检测、行为分类等，强调这些方法使得检测机器人变得非常复杂，而创建不被检测的机器人则更具挑战。机器人易被检测的主要原因在于其基础设施（如Docker容器、云服务器托管）与人类行为模式不符。

为规避检测，作者提出一种基于真实设备或模拟器的爬虫架构建议：

1. 使用真实Android设备：购买大量不同制造商的廉价Android设备，在多个主要城市部署，利用移动网络IP（4G/5G）的不可封锁特性，通过定期切换飞行模式获取新IP，并用DeviceFarmer等工具集中控制。此方案成本高、维护复杂。
2. 改进方案：模拟Android设备：使用Android模拟器（如Android-x86、Bluestacks）结合4G网卡，在强大服务器上运行多个模拟实例，并置于不同地理位置。该方案减少了硬件依赖，但可能面临模拟器指纹被检测的风险。

最终，作者勾勒出一个理想化的爬虫基础设施：在5个主要城市各设立一个爬取站，每站配置一台服务器及50个4G网卡，运行50-100个模拟Android设备，通过一个简单的中央控制服务器进行协调，以实现高效、难以检测的大规模数据爬取。

不列颠哥伦比亚省政府宣布，将重新将公共场所的毒品使用定为刑事犯罪，这是对该省旨在应对有毒药物危机的试点计划做出的重大调整。此举是在医院、公园和公交站等地出现大量问题性街头吸毒报道数周后采取的。

背景与政策转变 BC省于2023年1月启动了毒品去刑事化试点项目，该试点依赖于加拿大卫生部根据《受管制药物和物质法》给予的豁免，允许成年人为个人使用持有最多2.5克的阿片类药物、可卡因、甲基苯丙胺和摇头丸，且在一些公共场所可以公开使用。然而，一系列关于医院走廊内吸毒和非法交易的报道、来自医护人员的投诉以及温哥华警察局副局长菲奥娜·威尔逊关于警方应对公共场所吸毒相关骚乱所遇困难的证词，促使省政府改变方向。

省长戴维·伊比表示，政府仍然“对那些与成瘾作斗争的人富有爱心和同情心”，但对无序行为的容忍是有限的，保障公众安全是最高优先事项。他强调，政府正在采取行动，在扩大治疗选择以帮助人们存活并康复的同时，确保警察拥有保障社区安全的工具。

具体措施 省政府正与加拿大卫生部合作，紧急修改去刑事化政策，要求修正其豁免条款，将“所有公共场所”排除在外。当警察接到举报，前往存在非法及危险吸毒行为的现场时，他们将有权强制涉事人员离开该区域，必要时没收毒品或逮捕人员。 但此变化不会将私人住宅、合法庇护所或过量预防及药物检测场所的毒品持有重新定为刑事犯罪。

卫生部长阿德里安·迪克斯宣布了专门针对医疗机构的措施，包括禁止在医疗设施内持有或使用街头毒品，并将通过加强安保、公开沟通和员工支持来严格执行政策。该省正与警方合作制定指引，以确保仅持有毒品且未威胁公共安全或引发骚乱的人员不会被逮捕。

原因与背景 去刑事化试点是政府对2016年因有毒非法药物导致死亡人数激增而宣布的公共卫生紧急状态的回应措施之一。自该紧急状态宣布以来，BC省已有超过14000人死亡，主要与芬太尼有关。最初的政策旨在通过减少与吸毒相关的污名化，帮助人们更好地获得挽救生命的护理和更安全的供应。

然而，政策也因其缺乏足够约束而受到批评。警察官员指出，在去刑事化政策下，他们在应对许多公共场所（包括医院和公交站）的问题性吸毒时权限受到限制。

先前尝试与政治反响 在宣布此次变更之前，BC省政府曾于2023年10月提出立法，试图禁止在许多公共场所使用非法药物。但该法案被BC省最高法院暂停执行，法官裁决认为其可能导致更多死亡、流离失所和吸毒者被刑事化。政府提出上诉，但上诉法院维持了暂停令。省长表示，此次通过要求联邦政府直接修改豁免来实施变更，有望解决法律障碍。

选举临近与各方反应 BC省将于10月19日举行选举，毒品政策已成为一个高度政治化的议题。温哥华市长对变更表示欢迎。反对党BC联合党批评政府试图挽救一项失败的政策，并指责其未能将吸毒者与必要的治疗和康复服务联系起来。BC保守党领袖称去刑事化在该省是“彻底的失败”。BC绿党领袖则对可能导致的逮捕率上升、特别是对原住民和少数族裔不平等影响表示担忧，并认为逮捕无法解决根本问题。

开源贡献的真谛：并非盲目参与

本文原载于Dev.to，作者以自身资深开发者的经验，探讨了开源贡献的常见误解与正确方式。

错误的开源贡献方式

许多初入行的开发者或学生被建议通过参与开源来提升职业前景，但这可能是一种误导。作者用“建学校”比喻说明：当大量缺乏经验且不了解项目情况的人盲目提交代码（如带着砖头来到工地），不仅无助于项目建设，反而可能造成混乱，甚至产出劣质结果。类似Hacktoberfest这类活动，虽立意良好，但鼓励新手随意寻找项目贡献，往往导致项目维护者不堪其扰，也让贡献者产生挫败感。

开源的核心：从需求出发，而非为贡献而贡献

开源的本质不是为了写代码而写代码。就像建学校是因为社区需要教育场所，开源贡献应源于对工具的实际需求。作者强调，真正的开源贡献始于成为开源软件的用户。当你使用开源产品时，自然会遇到问题或产生新功能需求，从而驱动有意义的贡献。

正确的贡献途径

1. 先使用，后贡献：作为用户，报告你遇到的bug、提出功能需求。如果问题无人解决，再考虑亲自修复。这确保了贡献是为了解决实际问题。
2. 承担维护责任：真正的贡献意味着承担责任，就像作者维护一个Arch Linux软件包，因为自己需要它且无人维护。这种“因为需要，所以去做”的心态，才是开源协作精神的体现。
3. 创造自己的工具：如果你需要的工具不存在、付费、侵犯隐私或质量不佳，最好的方式是自己动手开发并开源。这样，你既满足了个人需求，也为社区创造了价值。
4. 通过工作参与开源：开源贡献也可以是有偿的。作者通过为法国政府开发并开源项目，既帮助了公共事业，也提升了个人职业发展。这同样是正确且有价值的开源方式。

总结

开源贡献不应是盲目地“刷简历”或参加活动，而应源于实际使用中的需求和解决问题的内在动力。无论是修复一个bug、维护一个自己需要的软件包，还是开发并开源一个解决实际痛点的工具，关键在于贡献是为了解决真实问题、改善共同的开源生态。作者建议初学者思考“我需要什么”，并付诸行动，这才是参与开源的正道。

作者完成了编程语言著作《Crafting Interpreters》的印刷版、电子书及PDF版制作。全书共640页，尺寸为8×10英寸。作者详细回顾了从内容完成到最终成书的十五个月过程，主要包括以下阶段：

构建系统重写
原书内容完成后，作者用Dart语言重写了构建系统，替换了原有的Python脚本。新系统不仅生成网站HTML，还能提取、编译并测试书中代码，速度提升十倍，并提供了更精细的Markdown处理能力。

书籍设计与排版
由于书中包含大量代码、旁注和插图，页面设计面临挑战。为容纳较长代码行和旁注，页面宽度定为8英寸，最终选用8×10英寸尺寸以适应按需印刷平台。作者在Adobe InDesign中建立样式和模板，但发现InDesign对XML导入支持有限，且排版过程复杂。为此，他编写JavaScript脚本自动化处理旁注和位置标记的提取与锚定，但仍需大量手动调整以避免页面留白过多、插图跨页等问题。

内容编辑与校对
作者完成了全书四次文稿修订，并聘请专业编辑进行Copy Editing，发现数百处错误。排版后进行了详尽校对，为解决InDesign二进制文件版本对比困难的问题，他编写脚本将PDF导出为拼接图像，并通过Photoshop动作自动标记页面差异，实现了可验证的修改跟踪。

电子书制作与发布准备
作者调整构建系统以输出EPUB所需的XHTML格式，生成了Kindle和EPUB电子书，并优化了CSS以适应不同阅读器。最终更新书籍网站，准备上传至各销售平台。

总结与展望
作者感慨这一历时六年的项目终于完成，表示需要休息并寻找个人兴趣，暂无新写作计划。尽管过程艰辛，但读者反馈是持续完成的动力。

这篇文章记录了作者在2011年用Java编写的一个早期程序的经历。该程序用于根据给定的网格模式（可包含部分已完成内容）查找有效的英文填字游戏填充方案。作者最近通过Wayback Machine找到了这个程序，并发现其jar文件依然可以从MediaFire下载。

在2023年的MacBook Air上运行这个Java程序依然成功，作者推测它也能在其他电脑上运行。程序源代码最初并未公开，但David Walton使用Eclipse的Enhanced Class Decompiler插件和Procyon反编译器恢复了类似原始源代码的版本。

作者对程序技术细节的模糊回忆包括：它使用了束搜索算法；采用Java Swing编写用户界面；为了优化性能，程序并非每次猜测都渲染屏幕，而是每隔一定次数（少于10次）渲染一次，因为渲染过程耗时远多于搜索过程。此外，程序的界面被描述为“非常非常黄”。作者提供了下载jar文件以及编译运行反编译源代码的简要说明。

加速C++构建时间的策略

Figma团队面临C++构建时间增长过快的问题：代码库增长10%的同时，构建时间增加了50%。经过调查，他们发现构建时间主要取决于预处理后发送给编译器的字节数，而大量不必要的头文件包含是关键原因。

核心问题分析

• C++编译机制：预处理阶段会将所有#include的头文件（包括传递性依赖）合并为一个大文件。
• 字节数增长异常：代码增长幅度与编译字节数增长不成比例，表明存在大量无用头文件包含。

解决方案与工具

1. 移除无用头文件

手动移除不必要的#include后，编译字节数减少31%，冷构建时间降低25%。

2. 自研工具DIWYDU

• 开发**Don’t Include What You Don’t Use (DIWYDU)**工具，基于libclang解析代码的AST（抽象语法树），识别未直接使用的头文件。
• 采用比Google的IWYU更宽松的策略，便于在大型代码库中部署。
• 局限性：无法处理标准模板库（STL）的私有头文件，且依赖Python绑定的AST访问权限有限。

3. 持续监控工具includes.py

• 测量每个源文件的传递性依赖字节数（不计算标准库头文件），在CI中检测回归。
• 若PR导致字节数显著增加，会发出警告以防止合并。

4. 前向声明优化

• 推荐使用前向声明减少头文件依赖，但可能影响代码可读性。
• 每个目录创建统一的Fwd.h文件，集中管理该目录的所有前向声明，并包含在目录内的所有头文件中。源文件不应包含Fwd.h。

5. 缓存策略

• 使用Bazel远程缓存，当输入相同时重用构建输出，本地构建时间减少约两分钟。

成果与效果

• 整体构建时间减少50%。
• 每天自动防止50-100次潜在的构建性能下降。
• 工具链（DIWYDU、includes.py、Fwd.h）与缓存机制结合，系统性提升了构建效率与开发者生产力。

文章总结

本文记录了作者及大量用户近期遇到的苹果ID账户意外被锁事件，揭示了苹果安全机制存在的缺陷及糟糕的用户体验。

事件经过：

1. 作者在家中使用iPhone时，苹果ID突然被锁定。账户被锁的原因为启用了“失窃设备保护”，且系统认为用户不在“熟悉地点”。
2. 系统提示需要等待1小时安全延迟才能解锁。作者检查“重要地点”列表，发现其常驻的家/办公室未被收录，仅记录了一家不常去的杂货店。
3. 尝试在Mac上解锁时，遭遇界面卡顿、按钮失灵等技术问题，多次尝试后才成功。解锁过程中被强制要求更改密码。
4. iPhone在Mac端解锁后自动恢复，但整个过程令人对安全机制产生怀疑。

核心问题：

1. “重要地点”识别失效： 系统未能可靠识别用户最常处的“家”或“办公室”，导致基于位置的“失窃设备保护”功能判断错误，在用户居家时错误触发安全延迟。
2. “失窃设备保护”与界面缺陷： 该功能旨在防止设备被盗后的未授权访问，但其依赖的位置判断不准确。此外，相关的系统设置界面存在布局异常、按钮无响应等严重bug，极易让用户误以为遭遇钓鱼攻击。
3. 大规模、无预警的账户锁定： 文章更新及评论区显示，此事件并非个案。众多用户在同一时间段（2024年4月底）报告其苹果ID被意外锁定，需要重置密码，并连带导致应用专用密码失效、iMessage同步中断、苹果钱包验证失效、家庭共享设置异常等一系列问题。
4. 苹果缺乏沟通与透明度： 尽管问题影响范围广泛，苹果的“系统状态”页面始终显示服务正常。苹果客服无法提供具体解释，公司也未发布任何官方声明说明事件原因或解决方案，令用户感到被忽视和不满。

用户影响与担忧：

• 用户被迫花费大量时间处理账户解锁、重置密码，并在所有设备上重新登录。
• 安全机制的不透明和不可靠，反而降低了用户对苹果ID体系的信任。
• 有用户因此考虑关闭“失窃设备保护”功能，或担忧过度依赖苹果生态（iCloud、iMessage等）所带来的单点故障风险。

结论： 该事件暴露了苹果ID安全系统在关键功能（地点识别）上的重大缺陷，以及在发生大规模故障时，公司缺乏有效沟通渠道和透明应对态度的严重问题。技术故障与糟糕的售后支持相结合，严重损害了用户体验和对苹果安全承诺的信心。

万维网（W3）项目摘要

万维网（W3）项目于1991年启动，是一个广域超媒体信息检索倡议，旨在为大量文档提供普遍访问。该项目通过一个中心文档链接了所有在线W3相关资料，内容组织涵盖多个关键部分：

• 项目概述：包括执行摘要、邮件列表、政策、新闻和常见问题等。
• 信息访问：提供指针到世界在线信息、主题和W3服务器。
• 用户帮助：针对所用浏览器的帮助指南。
• 软件产品：列出W3项目组件及其当前状态，如Line Mode、X11 Viola、NeXTStep、服务器、工具、邮件机器人和库。
• 技术细节：详述协议、格式和程序内部等信息。
• 参考文献：包含纸质文档和W3相关引用。
• 人员参与：列出项目涉及的部分人员。
• 历史发展：概述项目历史。
• 社区贡献：说明如何支持Web发展。
• 代码获取：通过匿名FTP等方式获取代码。

W3项目的核心是促进超媒体信息的全球检索与访问，推动文档共享和互联。

本文介绍了三维空间中平面的核心概念与常用计算方法。

平面描述

平面可用多种方式描述：

1. 点-法线式：由一个点 ( P ) 和一个垂直于平面的单位法线向量 ( n ) 定义。
2. 三点式：由三个不共线的点 ( A, B, C ) 定义一个隐式平面。可通过计算两向量 ( \overrightarrow{AB} ) 和 ( \overrightarrow{AC} ) 的叉积并归一化得到法线，再转为点-法线式。
3. 常数-法线式：由法线 ( n ) 和标量距离 ( d ) 定义。( d ) 表示从原点到平面的有符号距离，且 ( d = n \cdot P )。这种形式简化了许多计算。

基本操作

• 点到平面的距离：给定点 ( Q ) 和常数-法线式平面 ( (n, d) )，距离为 ( D = n \cdot Q - d )。结果符号表示点位于平面的哪一侧。
• 点向平面投影：将点 ( Q ) 沿平面法线 ( n ) 投影到平面上，投影点 ( Q’ = Q - (n \cdot Q - d) n )。

几何相交计算

1. 线与平面相交

• 定义：线由点 ( P ) 和方向向量 ( l )（不必单位化）表示。
• 交点计算：求解沿方向 ( l ) 从 ( P ) 出发到达平面的距离标量 ( t )： [ t = \frac{d - (n \cdot P)}{n \cdot l} ] 交点为 ( P + t l )。
• 特殊情况：
  • 若 ( |n \cdot l| ) 近似为零（小于一个很小的 ( \epsilon )），则线与平面平行，可能无交点。
  • 对于射线（仅沿方向 ( l ) 延伸），需额外判断 ( t \geq 0 ) 以确保交点在射线方向上。

2. 平面与平面相交

• 结果：两平面相交于一条直线，或平行无交。
• 直线方向：直线的方向向量是两平面法线的叉积：( \text{dir} = n_1 \times n_2 )。若叉积长度近似零，则平面平行。
• 直线上一点：通过求解方程组，可得到直线上一点 ( P )。一种计算公式为： [ P = \frac{(d_1 n_2 - d_2 n_1) \times \text{dir}}{|\text{dir}|^2} ] 该点是直线上离原点最近的点。

3. 三平面相交

• 可能情况：有五种配置，包括平行、交于一条线、交于一点等。
• 判断是否交于一点：计算标量 ( \Delta = n_1 \cdot (n_2 \times n_3) )。若 ( |\Delta| ) 近似零，则三个平面不相交于唯一点。
• 交点计算：若 ( \Delta \neq 0 )，交点 ( P ) 可通过以下公式高效计算： [ P = \frac{d_1 (n_2 \times n_3) + d_2 (n_3 \times n_1) + d_3 (n_1 \times n_2)}{\Delta} ] 此公式利用了向量三重积的性质进行优化。

实践要点

• Epsilon：在浮点运算中，用于判断两值是否“足够接近”（如是否平行）。选择取决于具体应用的精度要求。
• 性能：如文章末尾提到，高效实现三平面相交算法能显著提升3D建模应用的性能。
• 资源：本文的许多深入内容（尤其是优化公式）参考自《Real-Time Collision Detection》一书，推荐阅读。

Ubuntu Desktop 24.04 LTS: Noble Numbat 摘要

Ubuntu 24.04 LTS 是一个重要的长期支持版本，整合了 Linux 生态系统的最新进展，旨在赋能开源开发者，并提供长达12年的支持。此版本标志着一个里程碑，基于 Linux 6.8 内核，在性能、安全性和硬件兼容性方面均有显著提升。

主要新功能与改进

1. 安装与部署

• 统一安装技术栈：桌面安装程序的后端与 Ubuntu Server 统一使用 Subiquity，前端采用 Flutter 构建，提升了用户体验和可访问性。
• 增强的加密选项：重新引入了 ZFS 引导安装并支持 ZFS 加密。实验性地首次支持基于硬件的全盘加密（目前仅适用于通用内核且不支持固件升级，未来将扩展硬件兼容性）。
• 集成自动安装：图形安装程序现在支持直接提供自动安装配置文件（autoinstall.yaml），便于实现定制化、可重复的自动化部署，是实现“零接触配置”的重要一步。

2. 核心应用更新

• 新版 App Center：基于 Flutter 的全新应用中心，提供现代化的界面、更清晰的分类和应用管理功能。集成了用户评分系统，并默认以 Snap 应用为中心视图，同时仍可通过搜索切换查找和安装 deb 包。
• 独立的固件更新应用：从旧版 Ubuntu Software 中分离出来，提供更丰富的体验并提升了性能。

3. 桌面环境 (GNOME 46)

• 装备了最新的 GNOME 46 版本，带来了性能和可用性改进，如文件管理器搜索优化、可扩展通知和整合的设置选项。
• 基于 GNOME 进行了定制增强，包括自定义高亮颜色选择器、针对 Intel 和树莓派图形驱动的三重缓冲优化，以及集成 Tiling Assistant 扩展以支持四分之一屏幕窗口平铺。

4. 网络配置统一

• 将 Netplan 作为桌面端的默认网络配置工具（与服务器和云端统一），其 1.0 版本带来了无线网络兼容性改进和 netplan status –diff 等新功能。
• Netplan 与 NetworkManager 双向集成，任何一方的配置更改都会同步更新。

5. 企业与管理功能

• 全面的 Active Directory GPO 支持：大幅扩展了对组策略对象的支持范围，涵盖特权管理、远程脚本执行、AppArmor 配置、网络共享/代理设置、证书自动注册等，为混合 Ubuntu 与 Windows 设备的企业环境提供了强大的管理方案。未来还将支持第三方云身份提供商（如 Azure AD）。
• Windows Subsystem for Linux (WSL) 增强：支持 cloud-init 实例初始化，便于在 Windows 设备上创建标准化的 Ubuntu 开发环境。

6. 安全增强

• 改进的 PPA 管理：个人软件包归档现在以 deb822 格式分发，将签名密钥直接嵌入源文件，建立了密钥与仓库的一对一关系，移除仓库时会同时移除密钥。APT 还要求使用更强的公钥算法进行签名。
• 限制非特权用户命名空间：使用 AppArmor 按应用程序控制对非特权用户命名空间的访问，仅允许有合法需求的应用使用此功能，以减少潜在的内核攻击面。
• 改进的 proposed 仓库：降低了 proposed 仓库更新的默认 APT 优先级，使用户可以选择性地安装特定软件包进行测试，而非必须接受所有待测更新，提高了测试的灵活性和稳定性。

7. 未来展望

Ubuntu Desktop 24.04 LTS 旨在构建一个经得起时间考验的平台，为未来的开源项目奠定坚实基础。开发团队表示将继续在此版本生命周期内及后续版本中扩展和改进这些功能。

论文核心：本文提出 Searchformer，一种基于 Transformer 和搜索动态引导的规划模型，旨在超越传统 A* 算法，实现更好的规划性能。

代码库内容：该代码库是论文的官方实现，主要包含以下部分：

• 数据与模型访问：提供用于访问生成数据集和训练模型的代码。
• 结果复现：包含用于复现论文主要图表的代码。
• 实验代码：包含了论文中所有实验所使用的代码。

环境与依赖：

• Python 版本：需要 Python 3.10。
• 环境配置：可通过提供的 requirements.txt 文件创建虚拟环境并安装依赖。
• 数据库：核心功能依赖一个 MongoDB 实例（默认使用社区版，默认连接至 mongodb://localhost:27017/mongo）。可通过设置环境变量 MONGODB_URI 指向其他实例。

核心模块与功能：

• searchformer 模块：包含实验所需的所有代码，支持模型训练、评估和生成训练数据集。
• 数据操作：使用 mongorestore 命令行工具导入已发布的数据集。
• 训练管理：提供命令行工具 (python -m searchformer.train)，支持管理训练运行、导入/导出模型检查点等功能。

快速上手指南：

• 示例笔记本：notebook/ 文件夹中包含多个 Jupyter Notebook，演示如何：
  • 加载并提示一个经过搜索增强的模型（例如10x10迷宫导航任务）。
  • 加载包含生成响应序列的轨迹数据集。
  • 加载用于训练的令牌数据集。
  • 生成论文中相关的各类图表和性能表格。
• 文档：doc/ 文件夹包含详细文档，涵盖训练运行、生成轨迹数据集、生成训练数据、Sokoban 交互示例、数据集概述及检查点索引等。

许可与引用：代码在特定许可下提供，详情见 LICENSE 文件。论文引用格式已提供。

纽约州法院维持了一项要求互联网服务提供商（ISP）向低收入家庭提供每月15美元宽带服务的法律。法院的判决与2019年联邦法院拒绝联邦通信委员会（FCC）试图抢先废除各州网络中立法的逻辑一致，即当联邦机构缺乏监管权力时，同样没有权力预先阻止州法律。

起诉纽约州的贸易团体此前曾积极游说FCC将宽带归类为“Title I信息服务”，以避免FCC的直接监管。法院指出，这些团体现在要求法院推翻州法，是试图逃避其自身战略决策可预见的法律后果，法院不能扭曲既定的行政法和联邦制原则。法官建议ISP可以通过向纽约州议会申诉、要求国会修改法律或请FCC重新评估分类决定等途径寻求救济。

该判决发布的时间点恰逢现任FCC领导层为恢复网络中立规则而重新对宽带进行分类的次日。这可能为ISP未来试图挑战纽约州法律提供了新的依据，因为FCC的网络中立令明确拒绝联邦层面的费率监管。

斯坦福大学法律教授认为，此判决为各州提供了重要保护，特别是在FCC未来再次放松宽带监管时，各州有充分的法律先例可以实施或重启自身的保护措施。该判决被视为其他各州可效仿的路径，以弥补联邦政府的行动缺失。

然而，持异议的法官认为，该州法应被联邦法律抢先取代，因为《通信法》预先占据了对所有州际通信服务的费率监管领域，仅将州内通信的监管权留给各州。

阿尔贝·加缪（Albert Camus）虽从未正式加入无政府主义组织，但终其一生都与无政府主义运动保持着密切联系并深表同情。他的个人经历与性格——早年贫困、母亲不识字、团队精神（源于足球运动）、避免怨恨、追求团结——塑造了他亲近无政府主义倾向的思想基础。

与无政府主义的思想与行动联系 加缪从不掩饰对无政府主义的吸引，其作品如《鼠疫》、《戒严》和《正义者》均渗透着无政府主义理念。早在1938年担任记者期间，他就表达了对无政府主义者及反叛者的钦佩。1948年，他被安德烈·普吕多姆介绍为无政府主义学生圈的同情者。

《反抗者》及其引发的思想决裂 1951年出版的《反抗者》是加缪与斯大林主义左派决裂的标志。该书明确区分了威权社会主义与自由意志社会主义，主张革命不应依赖恐怖和专制手段，并呼吁复兴无政府主义传统。无政府主义者如加斯东·勒瓦尔、乔治·丰特尼虽对书中关于巴枯宁的某些描述提出温和批评，但总体肯定其价值。相比之下，萨特等共产党同情者和超现实主义者则进行了激烈抨击，导致加缪与萨特彻底决裂。加缪反驳批评者忽视了无政府主义和工团主义传统。

对无政府主义者的实际支持 加缪持续以实际行动支持无政府主义事业：

• 声援政治犯与社会运动：1952年为被佛朗哥政权判处死刑的西班牙无政府主义工人发声；支持1953年东德工人起义、1956年波兹南起义和匈牙利革命；1955年支持首位因反殖民立场入狱的法国人。
• 为运动辩护：1954年为制作反军国主义海报而受审的无政府主义者莫里斯·莱桑出庭作证，赞扬其行动符合全人类利益。
• 利用影响力：常以自身声望介入，为受迫害的无政府主义活动家发声，或警醒公众。
• 参与出版与社群：为无政府主义报刊《自由人》、《无产阶级革命》及《工人团结报》撰稿；参与自由意志派刊物《见证1956》的编辑工作；结识众多无政府主义者，包括乔万娜·贝尔内里、里蕾特·迈特让、莫里斯·儒瓦等。

晚年与遗风 加缪晚年在普罗旺斯定居期间，与自学成才的无政府主义者弗兰克·克里亚克结为友人并雇其为园丁，得以进行思想交流。他最后的活动之一是支持无政府主义者路易·勒科安为争取拒服兵役者地位进行的斗争。加缪于1960年去世，但其思想遗产影响深远，例如莫里斯·儒瓦后来指出《反抗者》是1968年五月风暴中学生与工人愿望的最佳诠释之一。

总结 加缪以其文学作品和持续行动，始终与无政府主义运动站在一起，成为该运动在知识界的重要同情者与捍卫者。

莱姆病夏季预防要点

流行趋势与风险因素

• 莱姆病是最常见的媒介传播疾病，其流行范围正在从传统的高风险地区（美国东北部和中西部上游）向南部和西部扩展，这主要与气候变化导致蜱虫活动季节延长和地理分布扩大有关。
• 高风险区域通常指林木茂密、植被丰富的郊区或乡村环境，高尔夫球场的灌木丛也是潜在风险点。白尾鹿、白足鼠等动物是重要的宿主指示。
• 莱姆病由鹿蜱（黑腿蜱） 传播，其他蜱虫（如狗蜱）可传播其他疾病，但不传播莱姆病。
• 感染高危人群以5-9岁儿童为主，且男性感染率高于女性。宠物（如狗） 可在户外活动时将蜱虫带入家中，增加人的感染风险，狗本身也可感染莱姆病。

预防措施

• 环境意识：在户外活动时，尽量走在小径上，避免进入茂密的灌木丛。
• 个人防护：使用含有DEET的驱虫剂（天然驱虫剂如柠檬油、桉树油效果较差）；穿着浅色长袖衣物，并将裤脚塞入袜子中，以便发现蜱虫。
• 定期检查：每次在潜在风险区域活动后，务必进行全身性蜱虫检查，特别注意皮肤褶皱处（如肘部、膝盖后、颈部）。由于蜱虫通常需要附着36小时以上才会传播病原体，及时检查并移除可有效预防感染。
• 正确除蜱：使用尖头镊子，尽可能贴近皮肤夹住蜱虫，然后垂直向上将其拉出。

症状与治疗

• 早期症状：包括典型的游走性红斑（环形红疹）、类似流感的症状（发烧、头痛、关节酸痛）。部分感染者可能不出现皮疹。
• 晚期并发症：若未及时治疗，可进展为面瘫、关节炎、脑膜炎或心肌炎（可导致心律异常）。
• 及时治疗：怀疑感染时应尽快就医，早期使用抗生素治疗是快速康复的关键。

研究进展与资源

• 疫苗研发：目前由辉瑞和Valneva公司研发的莱姆病疫苗已进入III期临床试验，预计2025年可能上市。马萨诸塞大学陈医学院也在研究一种预防性单克隆抗体，通过在蜱虫肠道内杀死莱姆病螺旋体来起效。
• 信息资源：建议公众参考哈佛健康莱姆病专题网站、美国疾控中心（CDC）的公众健康网站及各州卫生部门的月度报告，以获取当地的疾病风险和最新信息。

Univer 是一个用于构建电子表格、文档和演示文稿的全栈、等效 Office SDK。它提供插件架构、基于 Canvas 的渲染、公式引擎和统一的 Facade API，可在浏览器和 Node.js 中运行，用于构建可嵌入的生产力体验。

核心特点：

• 为大型界面构建： 基于 Canvas 的渲染和专用公式引擎确保复杂工作簿响应迅速。
• 插件化设计： 能力以插件形式提供，可组合、替换、延迟加载或扩展。
• 支持无头模式： 可在 Node.js 中运行工作簿和文档逻辑，用于 AI 代理、自动化和服务器端工作流。
• 产品就绪的 SDK： 提供框架适配器、Facade API、预设和无头运行时。
• 暗黑模式就绪： UI 组件和渲染引擎均支持明暗主题。
• 统一的 Facade API： 在浏览器和 Node.js 中提供一致的 API 用于操作工作簿、范围、公式和文档。

使用场景： 适用于在 SaaS 产品、内部工具、BI 工作流或 AI 应用中嵌入电子表格/文档编辑，或在服务器上以相同架构处理工作簿/文档，通过插件按需组合功能，或通过自定义插件、命令、服务等扩展行为。

快速开始：

1. 预设模式（推荐）： 使用 @univerjs/presets 和 @univerjs/preset-sheets-core 等经过整理的插件包快速集成。通过 createUniver 函数初始化并使用预设配置。
2. 插件模式： 需要更精细控制时，手动引入并注册各个核心插件（如 @univerjs/core， @univerjs/sheets， @univerjs/docs 等）。需手动合并本地化包、导入样式并按顺序注册插件。
3. 无头模式： 用于服务器端的工作簿/文档处理、公式计算或自动化，无需 UI。

兼容性：

• 浏览器： 目标为 Chrome 70，兼容 Edge >=70， Firefox >=63， Safari >=12.0， Electron >=5。依赖 Intl.Segmenter，在不支持的环境需添加 polyfill。
• 构建工具： 推荐 Vite， esbuild 或 Webpack 5。
• React： 基于 React 18 构建，支持 React 18/19，对 React 16.9+ 和 17 有基本兼容支持。
• Node.js： 无头模式支持 Node.js >=18.17.0。

可构建内容（开源能力）：

• 电子表格： 包含工作簿、工作表、范围、选择、公式、数字格式、筛选、排序、数据验证、条件格式、超链接、批注、查找替换、笔记、表格、绘图集成及可扩展 UI 插件。
• 文档： 富文档模型、编辑 UI、列表、超链接、绘图集成、批注、快速插入等。
• 演示文稿： 数据模型和 UI 包（积极开发中）。
• 运行时： 浏览器应用、Node.js 无头使用、Web Worker/RPC 模式、多实例使用和服务器端自动化。
• 集成： 支持 React、Vue、Web Components、框架模板、主题、本地化和自定义插件。

开源与 Pro 版本：

• 开源： 包含核心 SDK、插件系统、渲染引擎、公式引擎、Facade API、Sheets/Docs/Slides 包、主题、国际化及许多第一方插件。
• Univer Pro/商业版： 额外提供实时协作、导入/导出、打印、图表、数据透视表、迷你图、高级公式能力、编辑历史、Pro 服务器组件和许可证管理等企业功能。

生态系统：

• 核心 SDK 仓库 (dream-num/univer)。
• 预设包 (dream-num/univer-presets)。
• AI 代理技能包 (dream-num/univer-sdk-skills)。
• 官方文档 (docs.univer.ai)。
• API 参考。
• 示例与展示。
• AI 原生电子表格集成 (dream-num/univer-mcp)。

开发与社区：

• 仓库结构包含 packages/（核心包）、examples/（示例）、tests/（测试）等目录。
• 开发要求 Node.js >=22.18 和 pnpm >=10。常用命令包括 pnpm dev（启动示例）、pnpm build、pnpm test 等。
• 社区支持通过 GitHub Discussions、Discord 等渠道。
• 项目采用 Apache-2.0 许可证。

美国领先医疗机构Kaiser Permanente披露了一起影响约1340万会员和患者的数据泄露事件。

该泄露源于其网站和移动应用程序中嵌入的在线追踪技术，这些技术无意中向谷歌、微软必应和X（原Twitter）等第三方科技公司传输了个人数据。

Kaiser Permanente通过内部调查发现，在用户使用其服务时，其平台上的在线追踪器会传输特定类型的个人信息。可能被共享的信息包括：

• 用户的IP地址
• 用户姓名
• 用户是否已登录Kaiser账户的标识
• 用户在网站和应用程序上的互动和导航详情
• 在Kaiser健康百科中输入的搜索词

Kaiser Permanente在一份声明中强调，用户名、密码、社会安全号码和财务信息等敏感数据并未被传输给第三方。

作为应对措施，该机构已从所有平台中移除了涉事的追踪技术，并根据聘请的网络安全专家的指导，采取了额外的安全措施以防止类似事件再次发生。尽管没有证据表明已泄露数据被滥用，Kaiser Permanente仍决定采取预防性措施，通知所有1340万可能受影响的人员。

Kaiser Permanente建议其会员和患者保持警惕，监控账户报表和健康服务互动中的任何异常活动。文章还指出，美国医疗系统长期受到广泛使用在线追踪器问题的困扰，这些追踪器会从医疗门户提取敏感医疗信息并分发给广告商网络，WakeMed、GoodRx、Cerebral等多家医疗机构此前也曾报告过类似的高风险数据泄露事件。