谷歌即将对Android实施开发者验证政策

政策核心

自2026年9月起，谷歌将要求所有Android应用开发者必须在其中心化系统完成注册，否则其应用将无法在任何通过认证的Android设备上安装。该政策适用于所有应用，不仅限于Play商店中的应用，包括朋友间分享的应用、通过F-Droid分发的开源应用、爱好者自用应用等。

注册要求包括：

• 向谷歌支付费用
• 同意谷歌的条款和条件
• 提交政府颁发的身份证明
• 提供私有签名密钥证据
• 列出所有当前和未来的应用标识符

若不合规，其应用将在全球所有Android设备上被静默阻止。

影响对象

普通用户

用户购买Android手机时基于其开放性的承诺，但谷歌正在单方面、追溯性地改变这一协议。更新后，用户只能运行谷歌预先批准的软件。

独立开发者

青少年的首个应用、志愿者开发的隐私工具、公司的内部测试版等，均需获得谷歌许可才能安装。F-Droid称此政策对其构成“生存威胁”。

政府与公民社会

谷歌有配合威权政府要求移除应用的记录。此政策可能导致一国机构的软件运行依赖于一个不负责任的外国公司。电子前沿基金会称应用把关是“互联网审查的不断扩大的路径”。

谷歌的“逃生舱”实为陷阱

谷歌声称高级用户仍可安装未验证应用，但实际流程极其繁琐：

1. 进入系统设置，找到开发者选项
2. 连续点击版本号7次以启用开发者模式
3. 忽略恐吓屏幕
4. 输入PIN码
5. 重启设备
6. 等待24小时
7. 返回并忽略更多恐吓屏幕
8. 选择“临时允许”（7天）或“永久允许”
9. 再次确认了解“风险”

整个流程通过谷歌播放服务而非Android操作系统运行，谷歌可随时修改、收紧或终止此流程，且无需操作系统更新或用户同意。目前，该流程仅存在于博客文章和模型图中。

更深层次的考量

开放性承诺的背弃

谷歌正在撤销Android区别于iPhone的核心承诺——开放性。数百万用户因此选择Android。谷歌单方面撤销这一承诺，是在市场支配和监管捕获已足矣的背景下进行的。

安全理由是烟幕弹

谷歌Play Protect已能独立于开发者身份扫描恶意软件。要求政府身份证明不会使代码更安全，而是使开发者可识别和受控。恶意软件作者可以注册，而独立开发者和异见人士往往不能。EFF明确表示：基于身份的把关是审查工具，而非安全工具。

对比苹果的辩护不成立

苹果从第一天起就是封闭系统。人们选择Android正是因为其不同。“苹果也这么做”是向下竞争的借口。在监管压力下，苹果甚至被迫开放，而谷歌却反向而行。

抵制行动

所有人

• 在所有Android设备上安装F-Droid
• 联系监管机构
• 分享相关页面
• 签署change.org请愿书
• 阅读并分享公开信

开发者

不要注册。不签署条款，不验证身份。谷歌的计划只有在开发者配合时才能生效。可考虑在应用中加入FreeDroidWarn库以警告用户。

各界声音

该政策引发了科技媒体、编辑与分析师、组织与公开信、YouTuber与创作者、开发者社区以及请愿书签署者的广泛批评和抵制。超过71个来自23个国家的组织签署了公开信反对该政策。媒体普遍认为这将摧毁Android的开放遗产，将其变为另一个围墙花园。用户和开发者在请愿书中表达了对自由、隐私和创新受到威胁的强烈担忧。

结论

谷歌的开发者验证政策是对Android开放生态系统的根本性转变，旨在建立中心化控制，威胁用户自主权、开发者自由和数字主权。该政策遭到全球范围内的广泛反对，倡导者呼吁用户、开发者和监管机构共同抵制，以保持Android的开放性。

关于“侧载”的讨论：谷歌新政策的影响分析

谷歌近期推出的开发者注册计划对用户自由使用自有设备的方式产生了重大影响，引发社区、媒体、民间团体及监管机构的广泛关注。本文旨在澄清相关观点，并反驳谷歌的误导性论述。

谷歌关于“侧载不会消失”的声明不实

谷歌在官方博客和视频中明确表示“侧载不会消失”，声称其是安卓的核心功能。然而，这一声明是错误的。新实施的开发者验证政策实际上终结了个人在自有设备上选择运行软件的自由。

需要澄清的是，“侧载”本身是一个虚构术语。在计算机上安装软件无论设备形式如何，都应称为“安装”。维基百科对“侧载”的定义是“从未经供应商批准的网络来源传输应用程序”。根据此定义，谷歌的声明不成立：作为安卓认证设备的主要供应商，谷歌正在事实上要求批准软件来源。

开发者必须向谷歌注册、缴费、提供政府身份证明、同意不可协商且可能变化的条款、列出当前及未来的应用标识符、上传私钥证明，并等待谷歌批准。这本质上意味着谷歌将成为所有安卓软件分发的守门人。

对各方权利的影响

消费者购买安卓设备时基于谷歌的开放平台承诺，如今却面临系统强制更新，该更新将永久性剥夺用户自主选择软件的权利，使其依赖于谷歌对软件可信度的判断。

创作者无法再直接向亲友和社区分享自己开发的应用程序，除非先获得谷歌批准。安卓长期标榜的“开放性”优势正在被抛弃，谷歌似乎认为自己已牢牢掌控安卓生态系统，且能规避监管约束。

政府及国家层面临数字主权让渡的风险。公民和关键基础设施软件将受制于一家公司的不透明决策，而该公司曾配合威权政权删除合法应用。软件分发生态的单一化风险与农业单一化同样危险。

此政策适用于全球超过95%的安卓认证设备（中国市场除外），无论设备所有者偏好使用三星商店、Epic游戏商店还是F-Droid等开源应用仓库，都将被迫遵守谷歌单方面制定的政策。

安全性论述存在矛盾

谷歌在推广开发者注册计划时声称“来自互联网侧载源的恶意软件是谷歌Play应用50倍以上”，但这一数据缺乏公开分析支持。近期谷歌Play商店移除224款恶意应用（涉及广告欺诈）及另一报告显示1900万次恶意软件下载，质疑了单一企业判断恶意软件的可靠性，尤其当其商业利益可能与用户安全不一致时。

应对措施与呼吁

谷歌长期面临对其强硬政策的反对声浪，近期行动加速了这一趋势：包括在Chrome中限制广告拦截器（Manifest V3），以及关闭安卓开源项目（AOSP）的开发过程，从而秘密实施验证基础设施。

开发者验证对F-Droid等自由软件分发平台及新兴商业竞争对手构成生存威胁。社区、科技媒体和民间团体正形成反对浪潮，但决策者仍需充分认识到这一威胁。

消费者行动：可通过keepandroidopen.org联系代表机构，倡导保持安卓生态开放。 开发者建议：目前不建议注册谷歌开发者计划，我们明确反对其强制推行该政策。

全球超过一半人口使用安卓智能手机，谷歌并不拥有你的手机——你有权决定信任谁、从何处获取软件。

三星智能冰箱正式引入广告功能

三星公司本周正式宣布，在经过不受欢迎的试点测试后，其昂贵的智能冰箱将正式显示广告。广告将通过即将到来的软件更新引入，适用于 2024 年的 Family Hub 系列智能冰箱。

广告投放详情

• 目标设备：2024 年 Family Hub 智能冰箱，零售价从 1,899 美元到 3,499 美元不等。
• 显示屏幕：冰箱配备 21.5 英寸或 32 英寸的集成屏幕，具体取决于型号。
• 更新时间：软件更新将于本月开始发布，广告将在更新后生效。
• 显示条件：广告仅在冰箱空闲时出现，三星称之为“Cover Screens”（封面屏幕）。

广告形式与类型

• 显示方式：广告以矩形框的形式出现在屏幕底部，每 10 秒更换一次内容。
• 内容类型：三星强调广告将是上下文相关的，而非个性化广告，这意味着不会收集用户数据。
• 附加功能：软件更新还将引入“Daily Board”主题，提供快速查看信息的便捷方式，但该主题也包含广告。Daily Board 显示五个瓷砖，包括预约、天气等信息，其中一个瓷砖用于广告展示。

三星表示，这些广告将与新闻、日历和天气预报等实用信息一同显示，旨在提供有用内容的同时，通过广告实现商业收益。

文章探讨了在消息传递场景中使用Postgres替代Kafka等专用系统的可行性，旨在挑战技术选型中盲目追求复杂分布式系统的倾向。

核心观点与背景 作者指出技术界存在两种倾向：一是追逐流行术语与过度工程化的“简历驱动设计”；二是基于第一性原理、寻求简单实用的“常识驱动设计”。当前，“小数据”运动与Postgres的复兴（“Just Use Postgres”）趋势正在推动后者的发展。文章认为，许多组织的工作负载远未达到需要Kafka等专门系统的规模，而现代硬件（如大内存、多核CPU）使得单一Postgres实例的处理能力大幅提升。在许多场景下，使用已熟悉且功能足够的技术（Postgres）比引入新技术带来的运维、学习与集成成本更具优势，这符合“最小可行基础设施”原则。

基准测试与结果 作者对Postgres作为发布订阅（Pub/Sub）和队列（Queue）系统进行了基准测试。

1. 发布订阅测试：

   • 方法：模拟Kafka日志结构，在Postgres中创建多个分区表，通过原子性事务更新偏移量表来保证顺序与一致性。消费者分组轮询读取并记录偏移量。
   • 结果：
     • 4核单节点：可实现约5 MiB/s写入、24.6 MiB/s读取（5倍扇出），端到端P99延迟60ms。
     • 4核三节点（同步复制）：吞吐量几乎无损，端到端延迟升至P99 186ms。
     • 96核单节点：写入达238 MiB/s，读取达1.16 GiB/s（5倍扇出），端到端延迟P99为853ms。CPU利用率仅约10%，瓶颈在于单分区写入速率。
   • 结论：对于常见的Kafka工作负载（如5 MB/s入、25 MB/s出），一个成本低廉的三节点Postgres集群即可胜任。

2. 队列测试：

   • 方法：使用 SELECT FOR UPDATE SKIP LOCKED 实现消息的互斥获取。
   • 结果：
     • 4核单节点：吞吐量约2885 msg/s（2.81 MiB/s），端到端P99延迟17.72ms。
     • 4核三节点（同步复制）：吞吐量约2397 msg/s，延迟有所增加。
     • 96核单节点：吞吐量约20,144 msg/s（19.67 MiB/s），延迟较高。
   • 结论：单节点Postgres即可稳定处理数千队列操作/秒，足以覆盖绝大多数公司的单队列规模。

何时使用Postgres及对常见反驳的回应

• 何时使用：作者主张应默认使用Postgres，直至其遇到明确的特性或规模瓶颈。Postgres提供了诸多便利（如用SQL调试、关联查询、原地编辑），在中小规模下比专用系统更简单、经济。
• 对“无法扩展”的反驳：
  1. Postgres可扩展：引用OpenAI使用未分片Postgres支撑海量用户的例子。
  2. 有时间扩展：即使高速增长，从当前规模增长到10倍通常也需要数年时间，有充足时间迁移到更适合的系统。
  3. 属于过度设计：为假设的高流量场景引入复杂基础设施，如同为可能成为演唱会主舞台的车库乐队购买大型音响，投资回报率低。
• 后记中的澄清与让步：
  • 误解澄清：建议为消息队列/发布订阅使用独立的Postgres实例以隔离风险；明确本文将Postgres与Kafka在发布订阅场景比较，与其他队列技术比较队列功能。
  • 承认Kafka的优势：在模式演进（通过Schema Registry）和生态系统连接性（客户端、Connect等）方面，Kafka确实更强。但作者认为，对于追求“最小可行基础设施”且已选用Postgres的团队，这些特性的价值会降低。
  • 可改进之处：指出长期保留大量数据会导致Postgres磁盘空间问题，可通过归档作业或新工具（如pg_lake）缓解；呼吁社区构建类似Kafka功能的Postgres扩展。

总结 文章通过实证测试和论证表明，对于大多数中低规模的消息传递需求，Postgres是一个被严重低估的、足够强大且简单经济的选择。技术选型应优先考虑组织已熟悉且“足够好”的解决方案，避免不必要的复杂性和成本，这符合“最小可行基础设施”的务实哲学。

卒中幸存软件工程师实用建议

本文是一位29岁发病、顶叶出血性卒中伴残余癫痫的软件工程师，在发病六年后总结的工作与生活调整经验。主要建议包括：

核心原则

• 优先健康：疲劳、模糊、恶心或身体异常感觉是必须停止工作的信号，需立即休息、补水、重置状态。
• 减少干扰：使用耳机、眼罩，控制环境输入，优先选择可自主控制的工作场景，确保有休息和逃离的路径。
• 主动自保：拒绝任何超出承受范围的工作要求，充分利用反歧视法律和员工援助计划。

工作方法优化

• 单线程工作：避免多任务切换，分批处理事务，将工作记忆外置到笔记本、白板或清单中。
• 善用工具：借助AI工具作为“草稿纸”，保存状态，减轻大脑记忆与处理的负担。
• 规划时间：在精力最佳时段（如早晨）处理高难度任务，其余事项延后。
• 节省注意力：关闭非必要通知，避免过度关注同步信息；沟通尽量采用异步方式（如邮件），减少冗长会议。

神经科学背景
作者引用研究表明，额叶和顶叶皮层组成的“多重需求”网络负责目标保持、注意力分配和任务更新，其负荷随任务复杂度增加。顶叶上部尤其在工作记忆中转换或重组信息时压力较大，因此代码重构等精神导航活动消耗显著。频繁上下文切换会大幅提升该网络负荷。卒中或动静脉畸形切除术后，病灶周围组织可能持续处于高兴奋状态，认知负荷过高会降低癫痫阈值，引发躯体感觉先兆或体象扭曲（如文中所述的左臂和眼睛先兆）。

结语
作者坦言自己仍在实践中改进这些建议，并鼓励其他卒中幸存者相互支持。

根据ProtonDB和Boiling Steam的最新统计数据，接近90%的Windows游戏现在可以在Linux上运行，这是一个显著的里程碑。这一进展主要得益于WINE和Proton开发者的努力，以及Steam Deck等硬件带来的兴趣增长。

该数据基于Boiling Steam定义的五个兼容性等级：

• 铂金级：完美运行，无需调整。
• 金级：仅需微小调整。
• 银级：可玩但存在瑕疵。
• 铜级：介于银色和破损级之间的不稳定状态。
• 破损级：无法启动。

趋势图表显示，新发布游戏获得铂金级评价的数量在增加，而红色（铜/破损）区域在减少。这对开发者有利，因为他们的游戏能以更少甚至没有问题的状态在更多硬件上运行。

然而，仍存在一些挑战：

1. 由于反作弊技术平台等已知的兼容性问题，部分热门游戏短期内无法很好地支持Linux。
2. 部分开发者似乎对非Windows平台的玩家不感兴趣。
3. 尽管如此，社区驱动的Linux兼容性技巧和调整仍能为许多游戏提供解决方案。

自定义图布局算法iongraph：替代Graphviz的优化解决方案

Mozilla团队为SpiderMonkey编译器的Ion优化层开发了交互式图可视化工具iongraph，以解决通用工具Graphviz的局限性。文章详细介绍了自定义布局算法的设计与实现，该算法在特定场景下比传统优化算法更高效、更易读。

背景与问题

SpiderMonkey的Ion编译器处理JavaScript和WebAssembly代码时生成SSA图。团队此前使用iongraph工具基于Graphviz生成静态PDF图，但存在以下问题：

• 布局不直观：Graphviz输出节点位置随机，不反映源代码控制流结构（如循环嵌套）。
• 布局不稳定：输入微小变化导致输出大幅变动，难以跟踪编译过程。
• 交互性差：静态PDF无法动态探索图结构，查找指令或跟踪边线困难。

自定义算法设计

团队决定构建专用布局算法，基于Sugiyama层次布局算法简化而来，利用控制流图的特性（如可归约控制流、循环结构）。算法用JavaScript实现，约1000行代码，分为以下步骤：

1. 分层（Layering）：
   递归遍历图，将基本块分配到水平层。循环内容整体分层，循环后内容延迟处理，确保布局反映代码结构。例如，返回语句不会出现在循环前。

2. 创建虚拟节点（Dummy Nodes）：
   为跨层边添加虚拟节点，并合并指向同一目的地的边以减少视觉噪声。虚拟节点放置遵循一致方向（向下在左、向上在右），便于识别流向。

3. 边拉直（Straighten Edges）：
   通过多次遍历对齐节点：将循环内节点缩进、调整父子节点对齐、清理虚拟节点线、微调近似直线边。这些遍历运行速度快，但不追求完美优化，仅针对常见图进行手调。

4. 跟踪水平边（Track Horizontal Edges）：
   将水平边分配到平行轨道以避免重叠。边按起始位置排序，从外向内分配轨道，支持边合并和清晰方向指示。

5. 垂直化（Verticalize）：
   为每个层分配Y坐标，基于层高度和边轨道高度。同一层内节点共享相同Y坐标，简化布局。

6. 渲染（Rendering）：
   采用铁路图风格的直线边线，优于Graphviz的贝塞尔曲线。直线更易跟踪、路由简单，且边交叉处显示方向，提高可读性。

算法优势

• 布局稳定：节点顺序一致，避免Graphviz的随机跳变。
• 高效性能：处理大型图（如WebAssembly函数）仅需20毫秒，而Graphviz需10分钟。
• 交互性强：支持缩放、拖拽、滑块浏览优化过程，并高亮指令跟踪。
• 直观易读：布局反映代码结构，循环嵌套清晰，边方向明确。

未来工作

iongraph已集成到Firefox探查器中，但仅限于SpiderMonkey调试构建。团队计划添加更多功能，如搜索、寄存器分配可视化，但无明确时间表。源代码已在GitHub开源，欢迎贡献。

结论

文章强调在特定领域问题上，简单、定制化的算法优于通用优化工具。通过人类设计指导布局，iongraph在可读性、稳定性和效率上均超越Graphviz，为编译器可视化提供了实用解决方案。

YouTube下架Windows 11非标准安装教程视频

事件概述

多位科技内容创作者上传的Windows 11安装教程视频被YouTube平台删除。这些视频主要涉及两种非官方支持的安装方法：无需微软账户登录安装系统，以及在不满足官方硬件要求的设备上安装Windows 11。

具体受影响内容

• 教程创作者CyberCPU Tech的两部具体视频已被移除（相关链接已存档但无法访问）。
• 视频内容属于系统安装的技术教程，并非黑客或破解工具。

删除原因分析

1. 平台行为：本次下架被确认完全是YouTube/Google的行为，与微软或版权方无直接关联。
2. 自动审核系统：平台使用AI驱动的自动化审核系统（无人工干预）执行删除操作。
3. 历史类似事件：该行为可能与几年前YouTube大规模清理“黑客相关”视频的模式一脉相承，当时大量合法安全研究视频被误删。

用户社区反应

• 部分用户建议立即下载保存相关视频以防进一步删除。
• 讨论中认为此类自动审核可能过度严格，导致合法技术内容被误伤。

技术背景补充

• Windows 11官方安装要求包括TPM 2.0、Secure Boot等硬件条件，以及强制微软账户登录（家庭版）。
• 绕过这些限制的教程在技术社区中常见，通常用于测试、旧设备利用或隐私考量。

Zig 新异步 I/O 系统概述

Zig 0.16.0 将引入基于新 std.Io 接口的异步 I/O 原语。其核心思想是解耦函数调用与返回，并提供一套同步 API 用于管理异步操作。

核心概念与基本用法

• 初始化：std.Io 的实例（如 std.Io.Threaded）通常在 main 函数中创建一次，然后作为参数传递给需要执行 I/O 的代码，类似于分配器（Allocator）的使用模式。
• 异步与等待：使用 io.async 启动一个异步任务，使用 await 获取结果。任务的实际并发执行取决于底层的 I/O 实现。
• 示例：通过并行启动两个各需睡眠1秒的任务，总耗时仅为1秒，展示了异步操作如何提升效率。

关键机制：取消与资源管理

• 取消（Cancellation）：cancel 方法与 await 具有相同的语义，但会额外请求取消任务。它是管理异步任务生命周期的关键。
• 防止资源泄漏：将 cancel 配合 defer 使用，可以确保在作用域退出时（无论正常完成还是提前返回错误）都能正确清理异步任务持有的资源，解决了未 await 的任务可能导致的内存泄漏问题。
• 统一错误处理：cancel 和 await 都是幂等的，它们的返回值统一表示了任务的成功结果或错误，使得资源分配和释放逻辑能够使用标准的 try 和 return 编写。

异步与并发的关键区别

• 异步（Asynchrony）：表达“启动一个任务并稍后处理其结果”的能力。使用 io.async。
• 并发（Concurrency）：表达“需要任务能够同时推进”的需求。使用 io.concurrent。
• 问题：在依赖任务间协调（如队列通信）的场景下，仅使用 io.async 可能导致死锁，因为它只要求异步执行，并不保证并发。
• 解决方案：使用 io.concurrent 来明确要求并发性。该调用可能失败（error.ConcurrencyUnavailable），例如在单线程环境中，从而避免静默死锁。

当前状态与未来方向

• 实验性实现：当前已有基于 IoUring 和 KQueue 配合栈式协程的概念验证实现。
• 未来工作：该 API 尚在演化中。相关的语言和标准库增强包括受限函数类型、栈大小计算、栈溢出消除以及无栈协程等。
• 邀请：鼓励开发者在实际应用中试用并提供反馈，共同完善这套 I/O 接口。

文章总结：从 VS Code 迁移到 Helix

迁移动机与对自动化和依赖的反思

作者最初使用 VS Code 搭建网站（基于 Astro），因其普及且易用。但作者对自动化工具的依赖性以及对大型科技公司（尤其是微软）及其产品策略的担忧，促使他寻求替代方案。他希望使用更中立、国际化的开源工具，以减少对特定单一实体或地区的依赖。

对 Helix 的初始恐惧与最终克服

作者最初对 Helix 的恐惧源于两个方面：一是畏惧需要重新学习一套编辑器操作（尽管熟悉 vim）；二是认为配置和搭建环境会比 VS Code “点几下安装扩展”更繁琐。

然而，作者最终克服了这些恐惧：

1. 直接尝试：安装并启动 Helix，利用其内置的交互式教程快速学习基础操作，特别是其“先选择后操作”的直观模式。
2. 发现优势：学习曲线虽稍陡，但迫使作者掌握了高效导航的快捷键，且实际体验中编辑效率很快超过了 VS Code。旧有的 vim 肌肉记忆并未造成干扰。
3. 寻求优质文档：官方文档对新用户不够友好，但作者找到了一个结构清晰、以用例为导向的第三方文档网站，极大地帮助了学习。

为特定工作流配置 Helix

作者主要用编辑器处理 Markdown、Astro 和 YAML。Helix 通过语言服务器协议（LSP）支持智能功能。以下是他的配置要点：

• Markdown：

  • 语言服务器：安装 marksman（Helix 预设）以获得链接补全等功能。
  • 语法检查：配置了 harper-ls 作为语法检查 LSP（目前仅支持英语）。
  • 格式化/Lint：安装并配置了 rumdl 作为 Markdown linter。
  • 显示优化：启用了在80字符处软换行。由于 Helix 不支持编辑器内容居中，作者通过一个键绑定临时调整行号栏的宽度，实现手动居中显示。

• Astro：

  • 语言服务器：全局安装 astro-ls 和相关 TypeScript 工具，并在 Helix 配置中指定。
  • 格式化器：选择并配置了 dprint 作为自动格式化工具，在保存文件时自动格式化代码。

• YAML：

  • 配置最为简单，只需安装预设的 yaml-language-server 并确保其在系统路径中即可。

总结与评价

作者认为 Helix 是一款值得使用的编辑器。它迫使用户学习高效的编辑方式，一旦掌握，便能获得直观、快速的编辑体验。虽然搭建特定语言支持比 VS Code 稍费周章，但并非不可逾越。作者认同 Helix “开箱即用”的设计哲学。

然而，文章也指出 Helix 的维护面临挑战。项目积压了大量待合并的 PR，维护者人力有限，这可能导致贡献者感到沮丧，并可能影响项目的长期发展和新功能的整合速度。作者建议通过建立明确的贡献者晋升阶梯来改善这一状况。

本文探讨了“越轨行为”在当代社会全面衰退的现象，并分析其可能的原因。

主要观察：

1. 负面越轨行为减少：

   • 青少年： 饮酒、吸烟、性行为、暴力、药物滥用（包括大麻、冰毒等）比例大幅下降；使用安全带比例上升；携带枪支到校、青少年怀孕率显著降低。
   • 成年人： 整体犯罪率在过去三十年下降约一半；连环杀手数量呈下降趋势；邪教组织自1970年代后几乎消失，2000年后新成立的极少。

2. 中性与积极越轨行为/多样性的减少：

   • 人口流动性： 美国人，尤其是年轻人，自1980年代中期以来搬迁意愿持续下降，更多人选择住在离母亲不远的地方。
   • 文化与创造力：
     • “寡头化”： 流行文化（电影、电视、音乐、游戏、书籍）市场越来越被少数现有IP（续集、翻拍、衍生作品）和巨头占据。
     • 同质化： 新作品风格趋同（音乐更同质、歌词更重复；小说封面设计雷同）；网站设计、室内装修（咖啡馆、公寓）、建筑外观、品牌标识（趋向无衬线字体纯文字logo）、汽车颜色（黑白灰为主）均呈现高度同质化。
     • 科学创新： 科学突破的速率下降，新思想更难取代旧思想；科学写作风格日益僵化（如医学期刊的固定格式）。

3. 存在的反例与反驳：

   • 反例： 大规模枪击事件增加；婴儿取名更具独特性；20世纪60年代至21世纪初的时尚变化比19世纪末至20世纪初更显著。
   • 反驳： 有观点认为文学、音乐等领域仍在繁荣，且最有趣的文化可能发生在社交媒体等新兴“非艺术”领域。但作者认为这些不足以抵消全面呈现的大趋势。

核心解释：生命价值的提升导致风险规避。 作者提出，这一广泛现象的主要驱动力是 “生命变得更有价值” （从经济价值和寿命角度），这促使人们采取 “慢生活策略”：

• 原因： 经济发展使人们更富裕，能为降低风险付费；医学进步和生活环境安全化大幅降低了各种非正常死亡的风险。
• 后果： 人们更珍惜生命和声誉，避免任何可能危及长期稳定或带来惩罚的高风险行为（包括好的坏的）。这种心理背景使得不仅犯罪等恶性越轨减少，探索、冒险、离经叛道等创造性行为也同样减少。
• 悖论： 更富裕、安全的环境本应让人更能承受风险，但实际上却让人更害怕失去已有的优越生活，从而选择更保守、安全的道路（如精英学生倾向于选择金融、咨询等“安全”职业）。

结论： 越轨行为的衰退是一个复杂现象，包含积极（如犯罪减少、健康安全）和消极（如创造力停滞、社会同质化）两方面。其根源在于现代社会普遍更高的生命价值导致了系统的风险规避心理。作者最后呼吁，为了一个更有趣、更具创新性的未来，需要有意识地创造能容纳和培育“良性越轨”的空间与机构，这在前所未有的安全与富裕时代，已成为一种需要勇气的选择。

Apple App Store 推荐内容摘要

页面展示了 Apple App Store 的编辑推荐和分类列表，涵盖多种应用和游戏，旨在为用户提供多样化的选择。

主要分类与推荐

• 主打推荐：包括游戏如“洛克王国：世界”（经典世界焕新）、“镭明闪击”（3D即时策略RPG）、“逆水寒”（武侠开放世界）、“崩坏：星穹铁道”（银河冒险策略游戏）等。
• 阖家欢乐好时光：针对儿童，推荐“Dora：探索与玩耍”（英语启蒙）、“宝宝巴士科学”（儿童百科）、“喜马拉雅儿童”（故事听书）等教育应用。
• 独立游戏：推荐“花雨旋律”（音乐治愈）、“山海旅人”（水墨像素神话）、“波西亚时光”（田园模拟）等独立佳作。
• 角色扮演游戏：如“逆水寒”、“崩坏：星穹铁道”等提供沉浸式冒险体验。
• 健康与习惯：推荐“专注旅人 - 心流计时器”（专注工具）、“OffScreen - 自律番茄钟”（屏幕时间管理）等帮助提升效率和习惯的应用。
• 体育游戏：包括“巅峰极速-趣游华夏”（赛车游戏）、“王牌竞速-车姬”（竞速娱乐）等热血体育类游戏。
• 电影之夜：推荐“豆瓣”（文化社区）、“猫眼”（演出票务）、“腾讯视频”、“爱奇艺”等电影和娱乐应用，涵盖购票和流媒体服务。
• 经典之作：如“冒险岛：枫之传说”（经典游戏新生）、“三国志·战略版”（策略手游）等耳熟能详的佳作。
• 财务应用：推荐“阿柴记账”（自动记账）、“喵喵记账”（趣味记账）等理财工具。
• 今日活动：包括“爱奇艺”热播剧《家业》、“QQ音乐”新专辑《LEMONADE》等新鲜内容。
• 健身应用：推荐适用于多种设备的健身应用，如步行锻炼工具，帮助用户坚持运动。
• 欢乐局：如“英雄联盟手游”（MOBA游戏）、“弹壳特攻队”（生存射击）等多人游戏，提供社交乐趣。
• 谜题游戏：推荐“匠木”（木工榫卯工艺）、“无尽旅图”（拼图冒险）等脑力挑战游戏。
• 时下畅销游戏：列出“王者荣耀”、“和平精英”、“原神”、“蛋仔派对”等热门游戏，覆盖多种类型如射击、策略、休闲等。

整体内容以分类形式呈现，突出应用和游戏的多样性，涉及游戏、教育、健康、娱乐、生活工具等领域，适合不同用户需求。

https://www.economist.com/finance-and-economics/2025/10/27/the-end-of-the-rip-off-economy

“无聊”正是我们曾经渴望的

自首批M1 Mac发布已近五年。2020年M1芯片的问世，根本性地打破了笔记本电脑“高性能高发热”或“低性能长续航”的传统妥协，实现了快速、冷静与惊人工续航的结合。

作者自购入M1 MacBook Pro，后升级至M1 Pro 14英寸机型，现使用M4 Max 14英寸MacBook Pro，每次升级都感受到性能超越以往的Intel机型。

尽管Apple Silicon为Mac带来了全面提升，但在苹果宣布M5芯片后，出现了一些“这不过是无聊的渐进式升级”的声音。

作者认为这种“无聊”恰恰是核心意义。在PowerPC和英特尔时代，Mac硬件更新常因依赖合作伙伴而停滞不前，甚至出现过NVIDIA显卡故障、iMac散热风扇持续狂转等问题。此外，苹果自身决策也引发过蝴蝶键盘、Mac Pro定位迷失等争议。

关键区别在于：如今苹果通过自研Apple Silicon，完全掌控了产品的核心技术和更新节奏。这意味着能够定期、稳定地迭代芯片，逐步提升性能与能效。可预测的更新计划必然伴随渐进式升级——技术发展本就是“革命后持续演进”的过程，无需每代都充满戏剧性突破。

回顾过去，用户曾普遍期望Mac硬件能实现稳定、可预测的持续更新，使各产品线不再长期搁置。从图表可见，自M1以来，苹果芯片在性能与能效上保持了持续且显著的提升，这正是用户当年期待的景象。除非每年换新，否则多数用户每次升级都能感受到实质进步。

因此，在Apple Silicon成功发展五年后，称其升级“无聊”实属误解了这一转变的成功本质，而这种稳定、可预期的进步，正是我们曾经所渴望的。

Bear博客服务因机器人攻击导致停机事件复盘

事件概述

2025年10月25日，Bear博客服务首次发生重大故障，其负责处理自定义域名的反向代理服务因负载过高而宕机，导致所有自定义域名超时不可用。由于监控工具未能及时告警且故障发生在周末，服务中断时间较长。

根本原因分析

故障直接原因是当日数百个博客遭受DDoS攻击，每分钟产生数万次页面请求。尽管部署了Web应用防火墙和速率限制等防护措施，但位于这些措施上游的反向代理服务器被海量请求淹没而崩溃。

背景：恶意机器人泛滥

当前互联网流量中机器人占主导，主要分为三类：

1. AI爬虫：用于训练大语言模型的数据采集，Bear博客允许用户主动触发的发现性爬取，但阻止数据挖掘类爬取。
2. 恶意爬虫：系统化扫描网站漏洞（如错误配置、敏感文件），24小时内可在数百个博客上产生近200万次恶意请求。这些爬虫常通过移动设备应用隧道使用大量IP地址。
3. 不受控的自动化脚本：低门槛的“氛围编程”使任何人都能轻易创建爬虫，大量业余脚本在无意中对网站形成DDoS攻击。

故障详情与响应延迟

• 反向代理服务器已无故障运行5年，此前通过水平扩展和CDN处理高负载请求。
• 故障当天，监控系统虽已启用推送通知和紧急告警，但未发出任何警报，原因未明。
• 自动扩展机制仅将Web服务器水平扩展至10倍，但机器人请求流量远超此规模，最终击穿了反向代理。

已采取的改进措施

1. 监控冗余：增加第二监控服务，支持电话、短信和邮件告警。
2. 增强防护：在反向代理层实施更激进的速率限制和机器人 mitigation，已减少约一半服务器负载。
3. 服务器扩容：将反向代理扩容至可处理原先5倍负载的规格，以应对极端情况。
4. 自动恢复：设置带宽归零超过2分钟时自动重启反向代理。
5. 状态透明化：新建公开状态页面 https://status.bearblog.dev，实时展示服务状态。

总结与展望

当前公开互联网环境中恶意机器人活动空前活跃，对服务提供者构成持续挑战。作者认为维护一个值得访问的网络空间比以往任何时候都更重要，与机器人的对抗仍将持续。本文旨在透明化故障原因、分享应对经验，并邀请社区交流建议。

10美分MCU实现语音播放：技术总结

核心目标

作者旨在挑战极限，让成本仅10美分的8引脚RISC-V微控制器（CH32V003，拥有16KB闪存）不仅能发出简单蜂鸣声，还能播放可识别的语音或音频片段。

挑战与硬件基础

• 主要限制：16KB闪存必须同时容纳程序代码和音频数据。
• 硬件改动：沿用之前的小开发板，但将压电蜂鸣器换成了小型扬声器，以获得更好的音质。
• 输出方法：使用微控制器的PWM（脉冲宽度调制）引脚模拟一个简易的DAC（数模转换器），以8kHz的采样率驱动音频波形。

解决方案一：2-bit ADPCM压缩播放录制音频

为播放一段约6秒的电影《2001太空漫游》经典台词音频，作者进行了压缩方案探索。

• 未压缩尺寸：16位/8kHz的PCM格式约需96KB，远超出16KB。

• 压缩方案对比：

  • 8位PCM：~48KB，仍超出3倍。
  • 4位ADPCM：~24KB，超出1.5倍。
  • QOA格式：~19KB，仍超出。
  • 2位ADPCM：~12KB，成功适配16KB闪存。

• 2-bit ADPCM工作原理：

  • 一种自适应差分脉冲编码调制算法。
  • 编码器与解码器均维护一个预测值和一个步长索引。
  • 每个2位的码字（00， 01， 10， 11）指示解码器按当前步长对预测值进行上下调整（+/-1步或+/-2步）。
  • 根据预测误差大小自动调整步长：误差大则用大步长，误差小则用小步长以提高精度。
  • 实现极其轻量：解码器代码仅约1.3KB。

• 音质权衡：虽然压缩率极高（相比8位PCM节省75%空间），音质损失明显，但波形总体跟踪了原始音频，播放时语音清晰可辨。

解决方案二：LPC语音合成生成更长或任意语音

为克服ADPCM对音频长度的限制，作者探索了更古老的LPC（线性预测编码）语音合成技术。

• 核心优势：不存储波形，而是通过建模人类发声来生成语音，数据极其紧凑（一个单词或短语通常仅需几百字节甚至更少）。
• 采用的库：集成了Talkie库，这是对德州仪器（TI）70年代末LPC语音合成芯片（如TMS5220， 用于《Speak & Spell》等设备）的软件模拟。
• 音质特点：生成的声音具有明显的合成电子音色，类似老式游戏或电子玩具，但可懂度高。
• 自定义语音生成：作者尝试了旧工具（BlueWizard， PythonWizard）从WAV文件生成LPC数据，并最终借助AI辅助创建了一个在线工具，可上传录音生成LPC数据。

成果与演示

通过结合两种技术，成功在10美分MCU上实现了语音功能：

1. 使用2-bit ADPCM播放了短达6秒的录制电影台词。
2. 使用LPC合成生成了如《星球大战》等台词的合成语音，占用的存储空间更小。

作者在文中和配套视频中展示了硬件实际运行效果，并将代码开源在GitHub仓库中。

总结

该项目成功在极端资源受限（16KB闪存）的低成本MCU上，通过音频压缩（2-bit ADPCM） 和参数化语音合成（LPC） 两种技术路径，实现了可理解的语音输出，展示了该平台的潜力。

文章摘要：Merkle Tree证书——应对量子计算威胁的下一代WebPKI方案

背景与挑战 量子计算机的发展威胁互联网安全，尤其能破解现有加密算法，实施“现在窃取，未来解密”的攻击。虽然约50%的流量已使用后量子加密，但保护服务器身份认证的TLS证书仍面临威胁。后量子签名算法（如ML-DSA-44）的签名和公钥体积是现有算法（如ECDSA-P256）的约20倍。直接替换会导致TLS握手数据量激增（数十KB），造成显著性能下降，且在量子计算机出现前无即时安全收益。

现有WebPKI系统的问题 当前Web公钥基础设施在演进中不断“打补丁”，导致一次典型的TLS握手包含约5个签名和2个公钥。主要开销来自：

1. 信任链：为建立从根证书到服务器的信任，通常需要中间证书，增加签名和公钥。
2. 证书透明度：为检测错误签发，证书需被公共日志记录。浏览器要求日志签名证明，增加2个签名。

现有系统依赖大量签名，难以承受后量子算法带来的体积膨胀。

Merkle Tree证书（MTC）方案 MTC旨在彻底重构WebPKI，以实现无性能损失的后量子安全认证。其核心特点是：

• 批量处理与默克尔树：证书颁发机构将多个无签名的证书组织成一个默克尔树，并用私钥签署树根。单个证书仅需一个包含证明（从证书到树根的路径哈希）即可证明其有效性。
• 带外分发：客户端通过离线、带外的方式获取并预先验证已签名的树根。在TLS握手中，服务器只需发送证书、1个公钥和1个包含证明。
• 内化透明度：每个证书颁发机构运行自己的日志，将证书透明度作为PKI的内在特性。

实验部署计划 Cloudflare与Chrome合作，计划在不改变信任关系的前提下进行实验性部署：

• 目标：验证协议是否可行、性能是否提升、客户端更新频率的影响等。
• 方法：Cloudflare在部分免费客户的流量中启用MTC支持；Chrome在其TLS栈中实现支持并控制实验范围。
• 信任引导：为快速建立信任，实验阶段将“模拟”默克尔树证书颁发机构。对于颁发的每个MTC，都会关联一个来自现有可信CA的、内容一致的“引导证书”。Chrome在推送MTC相关数据前会校验其与引导证书的一致性，确保安全底线。

结论 MTC通过将TLS握手中的签名和公钥数量减少到最低限度，解决了后量子证书的性能瓶颈，是实现在量子计算机出现前就能默认部署后量子安全证书的关键方案。实验旨在验证其在实际网络中的效果与可行性，为互联网向全面后量子安全过渡迈出重要一步。

KaTeX 是一个专为网络设计的数学排版库，以其极快的速度著称。它提供简单API且无依赖，能在所有主流浏览器上高效运行；采用同步渲染数学表达式的方式，避免页面重排，提升性能；输出质量基于Donald Knuth的TeX标准，确保打印级精度；自包含设计便于与网站资源打包；支持服务端渲染，通过Node.js预渲染表达式为纯HTML，保证跨浏览器和环境一致性。即使在页面包含数百个表达式时，KaTeX也能保持闪电般的速度。用户可通过安装、文档和GitHub链接获取更多详细信息。

Generative AI 图像编辑模型对标测试

这是一个针对前沿生成式AI图像模型的专项对比测试，其核心是评估这些模型在处理特定任务时的表现。

核心目标与重点 该项目通过一系列特定的提示词和挑战性任务，对多种最先进的生成式AI图像模型进行系统性比较。评测的核心标准与强重点在于模型对给定指令和需求的遵循度。这意味着项目不仅关注生成图像的质量，更关键的是衡量模型能否准确、忠实地理解和执行用户的编辑或创作要求。

项目结构与特点

• 对比基准：聚焦于当前的SOTA（State-of-the-Art，最先进）模型。
• 测试方法：使用统一的提示词和挑战作为输入，确保评估的公平性和可比性。
• 评估维度：将“遵循度”作为首要的评估维度，凸显了项目对模型可靠性和可控性的关注。
• 视觉标识：项目拥有专属的OG图片，用于视觉呈现和社交分享。

该项目旨在为研究者和开发者提供一个清晰的基准，以了解不同生成式AI图像模型在精确执行用户意图方面的能力差异。

本文是AWS迁移到裸金属服务器两年后的后续总结，回应了社区的主要疑问并分享了运营数据与经验。

核心成果与背景

团队自2023年发布迁移文章后，持续运行MicroK8s + Ceph堆栈超过730天，测得可用性为99.993%。为消除单机架故障疑虑，已在法兰克福增设第二个机架，通过冗余DWDM与巴黎主节点连接。借助本地NVMe存储并消除“邻居干扰”，客户面向的平均延迟降低了19%。节省的资金被用于采购裸金属AI服务器，以增强产品内的AI功能（如告警摘要与自动代码修复）。

回答社区核心问题

1. 成本节约的真实规模：尽管美国市场23万美元约等于一名工程师年薪，但在全球其他地区相当于2-5名工程师薪资。当前年化节省已增长至超过120万美元，且预计随业务增长继续增加。

2. 为何不采用AWS Savings Plans或Reserved Instances：

   • 计算显示，与AWS优化后的账单相比，裸金属方案节省超过76%。
   • Savings Plans不降低S3、出口流量或Direct Connect成本，而带宽支出曾占其AWS账单的22%。
   • 使用EKS有额外控制平面和NAT网关费用，自建Kubernetes后这些费用消失。
   • 其24/7稳定型工作负载已实现超过90%的预留覆盖率，无闲置突发容量可优化。

3. 迁移与运维实际成本：

   • 迁移成本：工程师耗时约一周（最坏情况估计），大部分是必要的基础设施即代码规范化等工作，因裸金属产生的增量工作约一周。
   • 持续运维成本：
     • 人工操作：平台团队每季度总计约24工程师小时，用于例行补丁和固件更新，类似于过去在AWS上优化成本、处理IAM策略等工作。
     • 远程支持：24个月内仅2次干预（主要涉及硬盘），平均响应时间27分钟。团队不设现场硬件管理员，依赖托管提供商。
     • 自动化：正在转向Talos系统，使用Tinkerbell PXE引导、Terraform管理配置，并在Kubernetes升级前运行一致性测试。这些工具同样强化了之前的AWS环境。

4. 单点故障与高可用性：

   • 已在法兰克福与不同提供商租用第二个机架（四分之一机架）。
   • 部署了第二个MicroK8s控制平面，Ceph存储池进行异步复制镜像。
   • 添加了隔离的带外管理通道（4G/卫星）。
   • 仍保留AWS灾备集群，每季度进行演练。通过BGP Anycast入口将DNS故障转移时间缩短至分钟内。

5. 硬件生命周期与意外资本支出：

   • 服务器按五年摊销，但配置较高（双路AMD EPYC 9654, 1TB RAM, NVMe）。预计在生命周期结束前因CPU饱和需升级。
   • 计划将旧设备下放至区域分析集群，并利用巨大的节省差额，每24个月可刷新40%的服务器集群，总成本仍低于优化后的AWS账单。
   • 从OEM购买延长保修，并在机架中保持三个冷备件。

6. 是否在重建托管服务：

   • 产品可移植性：客户可自托管，团队运行相同的开源堆栈（PostgreSQL, Redis, ClickHouse等）。
   • 工具链成熟度：广泛使用MicroK8s（未来为Talos）、Argo Rollouts、OpenTelemetry等成熟工具，无维护定制分支。
   • 选择性使用云服务：仍为Glacier长期备份、CloudFront边缘缓存、短期负载测试突发容量支付AWS费用。云适合弹性场景，裸金属适合稳态基础负载。

7. 带宽与DDoS防护：

   • 承诺跨两家运营商5 Gbps 95th百分位带宽。同等流量在AWS上出口费用高出8倍。
   • 使用Cloudflare进行入口DDoS防护。

8. 可靠性与审计合规：

   • 可靠性未受损，甚至优于同期AWS的区域性停机事故。
   • 顺利通过SOC 2 Type II和ISO 27001认证。审计关注点在于物理控制（提供门禁日志、监控）、变更管理（Terraform计划提供不可变证据）和业务连续性（通过跨数据中心迁移证明）。

9. 为何不选择其他云提供商：评估了Hetzner、OVH、Equinix Metal等。欧洲专用主机适合实验环境，但支持大规模Ceph集群和智能运维SLA时成本优势缩小。Equinix Metal最接近，但其裸金属即服务仍有25-30%溢价。拥有硬件允许自行规划电力密度和组件复用。

10. 日常琐事（Toil）：每月总计约14工程师小时（含准备），工作内容包括每周补丁、每月Kubernetes控制平面升级、每季度灾备演练等。琐事性质发生了变化（从成本优化转向基础设施维护），但总工作量未显著增加。

11. 是否仍使用云服务：是。仍使用AWS Glacier进行长期日志归档，CloudFront用于边缘缓存（即将迁移至更便宜的Cloudflare），以及短期AWS环境用于负载测试。

结论与未来

作者认为，云适合使用模式尖峰、季节性或重度依赖托管服务的团队；裸金属则适合计算规模稳定、数据重力大、追求独立性的场景。他们正准备发布详细的CapEx预测手册和Terraform模块，并计划深入介绍Talos系统。

1X Neo 家用机器人预售摘要

预售信息

• 今日支付200美元定金（全额可退）
• 美国地区预计2026年开始发货

核心功能

• 自主性：搭载Redwood AI通用模型，具备基础自主能力，可通过学习逐步提升功能
• 专家模式：支持远程专家监督复杂任务，帮助机器人学习新技能
• 交互方式：
  • 语音界面：支持自然语言对话
  • 移动应用：管理任务计划、远程通信、状态监控
• 自动充电：自主管理电量并自动充电
• 远程控制：可通过移动应用和VR设备全球远程操控
• 状态指示：通过耳环LED显示电量、注意力等状态
• 音频功能：可作为移动蓝牙音箱使用

安全设计

• 软体结构：3D晶格聚合物材料，提供安全缓冲
• 防夹设计：关节外部完全封闭
• 低惯性驱动：使用肌腱驱动技术，动作精准节能
• 机身语言：理解并回应人类手势和表情
• 易清洁：软体外壳和鞋子可机洗

人工智能系统

• Redwood AI：视觉语言模型，用于学习和执行家务任务
• 内置大语言模型：支持理解、推理和对话
• 多模态智能：
  • 音频智能：解析音频和对话上下文
  • 记忆功能：保留个性化信息
  • 视觉智能：利用视觉输入增强对话
  • 自主导航：使用AI导航到所需位置

硬件规格

• 运动自由度：多关节结构
• 计算单元：1X NEO Cortex（基于Nvidia Jetson Thor）
• AI算力：最高2070 FP4 TFLOPS
• 传感系统：
  • 4个波束成形麦克风
  • 3级扬声器系统
  • 双8.85MP 90Hz立体鱼眼摄像头
• 通信：WiFi、蓝牙、5G
• 安全结构：
  • 低惯性肌腱驱动系统
  • 标称负载循环200万次（1天服务更换）
  • 峰值负载循环10万次（1天服务更换）
• 防护等级：肌腱驱动系统具有防护设计

Board：全新游戏主机，通过实体棋子与开放SDK重塑游戏体验

核心产品介绍

Board是一款24英寸桌面游戏主机，采用高分辨率触摸屏，可识别真实物理游戏棋子。其专利技术PieceSense能瞬间解析棋子的身份、位置与移动，创造出独特的互动玩法。设备可放置于任何桌面，适合多人聚会游玩。

主要特点与玩法

• 实体与数字融合：每个游戏配有专属实体棋子，拾起棋子、移动即可触发屏幕反应。
• 开放开发者工具包：提供SDK，允许开发者创建自定义游戏。
• 无需控制器：仅需双手与定制棋子，易于所有年龄段玩家上手。
• 适用场景广泛：支持单人任务、双人对决及多人派对模式。

游戏示例

Board内置或提供多款游戏，涵盖多种类型：

• 复古街机合集（如《Board Arcade》、《Cosmic Crush》）
• 烹饪合作游戏（《Chop Chop》）
• 冒险益智游戏（《Bloogs》、《Snek》）
• 策略类游戏（《Strata》）
• 侦探解谜游戏（《Spy Kit》）
• 宠物模拟游戏（《Mushka》）
• 每日3D拼图挑战（《Board Blocks》） 每款游戏均配有专属实体组件。初始附带7款游戏及棋子，额外游戏可通过官网单独购买，无需订阅费。

目标用户

Board面向全年龄段玩家，从儿童到老年人均可参与。游戏设计兼顾不同技能水平，尤其注重家庭与社交场景，旨在促进面对面互动。

媒体与用户评价

文章引用了多家媒体与用户的正面评价：

• 被视为2026年顶尖科技产品之一。
• 设计获赞“高端”，游戏“真正有趣”，理念“人性化”。
• 用户反馈强调其持久吸引力（如孩子连续数周每天要求游玩）。
• 被类比为“任天堂Wii”的继任者，有望重振家庭游戏之夜。
• 被评为“季节性官方礼物”，能创造长期记忆。

技术细节与购买信息

• 核心技术：PieceSense技术将触摸屏原始信号转化为对棋子的即时智能识别。
• 游戏库：包含街机、策略、动作、桌面RPG（如龙与地下城）等类型。每月将推出新游戏及免费扩展包。
• 套装内容：主机、7款游戏及其棋子套装、1年保修。
• 购买方式：游戏及棋子可通过官网购买，游戏直接下载至主机，实体棋子邮寄送达。

Board旨在寻找传统桌游与电子游戏的平衡点，通过结合两者优点，为玩家带来新颖的团体娱乐体验。

Claude Code 网页版使用体验摘要

产品概述

作者近期开始频繁使用 Anthropic 推出的 Claude Code 网页版（v1 产品）。其基本工作流程为：

• 用户输入提示词以启动新线程。
• 系统会启动一个轻量级容器供代理在其中工作。
• 用户可与代理持续对话。
• 最终成果会生成一个代码分支，目前仅能通过创建 PR 查看差异。
• 若想在本地继续工作，可使用 claude --teleport <uuid> 命令将分支拉取到本地并延续同一对话线程。

核心使用场景

作者将 Claude Code 网页版用作一个 “自动执行的待办清单”：

• 当在不同项目（工作、副业、开源项目）中想到需要调整的小任务时，会直接创建一个新线程。
• 随后在当天晚些时候或几天后返回，查看 Claude 的执行结果并进行收尾工作。

移动端集成

该产品也可在 Claude iOS 应用中使用，方便用户在移动场景（如散步时）随时记录想法或提问（例如：“哪些界面可能会受到此变更的影响，需要更彻底地测试？”），并知道答案会在后续等待查看。

与 Cursor 的对比

作者提到 Cursor 在 4 个月前也推出了类似产品，并进行了尝试，但体验不如 Claude Code。主要差异在于：

• 产品质量：Cursor 的实现略显粗糙，加载状态不稳定，整体感觉较为脆弱。
• 细节设计：例如 Cursor 的字体过小。
• 可靠性：Claude Code 网页版给作者的感觉是 “坚实可靠”，这是其本周体验显著优于 Cursor 的关键原因。

CSS 原生弹簧与弹跳动画：linear() 缓动函数

传统缓动与 linear() 的引入

传统的 CSS 过渡动画依赖贝塞尔曲线来定义状态间的插值方式。虽然贝塞尔曲线功能强大，但它无法原生实现弹簧或弹跳等物理型动画效果。过去，这类动画需借助 JavaScript 库实现，但这会引入性能问题（如动画可能在主线程运行，导致卡顿）。

现代 CSS 提供了 linear() 函数，允许开发者通过指定一系列点在直角坐标系上绘制自定义缓动曲线，从而原生实现弹簧、弹跳等复杂动画效果。

linear() 函数的工作原理

• 基于点连线：linear() 函数通过一系列坐标点定义曲线，这些点之间以直线段连接，形成近似曲线的动画路径。
• 参数格式：函数接受一系列数值，表示动画进度（0 为起点，1 为终点，可超出此范围以实现过冲效果）。这些点默认在动画时间内均匀分布。
• 模拟弹簧效果：通过使用足够多的点（例如 50 个以上）并允许数值过冲（如 1.25 表示超过目标位置 25%），可以模拟出真实的弹簧振荡动画。

推荐工具

手动编写大量 linear() 点数据不切实际，推荐使用以下工具自动生成优化后的曲线数据：

1. Linear() Easing Generator：基于弹簧参数（刚度、阻尼、质量）自动生成 linear() 字符串，并计算所需的动画时长。
2. Easing Wizard：可视化工具，支持创建弹簧、弹跳、摇摆等多种物理动画效果，并提供测试环境。

这些工具会生成带有时间百分比的 linear() 语法，允许非均匀分布的点，从而用更少的点实现相同曲线效果。

linear() 的局限性

1. 基于时长：与物理动画库不同，CSS 过渡必须指定固定时长。工具通常通过计算弹簧稳定时间来派生时长，但无法完美模拟无阻尼（永久振荡）的弹簧。
2. 中断处理：当动画被中断时，linear() 实现的弹簧动画无法考虑元素的惯性，会瞬间反转方向，显得不自然。而 JavaScript 库（如 React Spring）能更真实地处理中断。
3. 性能考量：
   • 帧率影响：即使使用超过 100 个点的复杂 linear() 字符串，在低性能设备上也未观察到帧率下降。
   • 文件大小：大型 linear() 字符串会增加 CSS 文件体积，但增加的压缩后大小通常很小（例如 3 个大型弹簧约增加 1.3kB）。建议使用 CSS 变量复用相同的 linear() 值以避免重复。

最佳实践

• 渐进增强：使用 @supports 查询为不支持 linear() 的浏览器提供基于贝塞尔曲线的后备方案，并将 linear() 值存储在 CSS 变量中。

  html {
    --spring-smooth: cubic-bezier(...); /* 后备值 */
    @supports (animation-timing-function: linear(0, 1)) {
      --spring-smooth: linear(...); /* 实际弹簧值 */
    }
  }
  

• 尊重用户偏好：通过 prefers-reduced-motion 媒体查询，为偏好减少动画的用户提供替代方案。
• 代码管理：在 CSS 注释中记录弹簧参数（如刚度、阻尼），便于未来调整。使用 prettier-ignore 防止格式化工具破坏单行声明。

文章摘要：入侵印度最大汽车制造商塔塔汽车

本文披露了安全研究员于2023年发现并报告给印度塔塔汽车公司的四个高风险安全漏洞。这些漏洞主要源于敏感凭证的不当暴露，严重危及公司数据、基础设施及客户信息安全。

主要漏洞点：

1. AWS密钥明文暴露（E-Dukaan电商平台）：

   • 在面向客户的汽车配件购买网站E-Dukaan的页面源码中，发现了以明文形式存储的AWS访问密钥。
   • 该密钥授予了访问超过70TB敏感数据的权限，数据分散在数百个存储桶中，包括客户数据库备份、市场情报、数十万份含有客户信息（如PAN卡号）的发票、行政订单报告等。
   • 漏洞根源仅为下载一个4KB的税务代码文件。

2. 可破解的加密AWS密钥（FleetEdge车队管理系统）：

   • 在塔塔汽车的车队管理平台FleetEdge的API响应中，发现了另一组AWS密钥，虽经过加密，但解密逻辑在客户端公开，极易被破解。
   • 该密钥同样暴露了大量数据，其中一个存储桶估计包含超过70TB的数据，甚至包含可追溯至1996年的文件。
   • 该密钥还允许对部分网站进行写入操作，存在被植入恶意软件的风险。

3. Tableau后门（无需密码登录）：

   • 在E-Dukaan的代码注释中，发现了利用一个“可信令牌”获取服务的逻辑。该过程仅需用户名，无需密码即可获取登录令牌。
   • 利用此机制，研究员能够以任意用户身份登录Tableau服务器，最终获取了服务器管理员权限，可访问所有内部项目、财务报告和经销商仪表盘。

4. Azuga API密钥泄露（试驾车队管理）：

   • 塔塔汽车用于管理试驾车队的Azuga平台API密钥，被硬编码在前端的JavaScript代码中。
   • 该密钥被证实有效，攻击者可借此访问和控制整个试驾车队的管理系统。

漏洞披露与修复时间线：

• 漏洞于2023年8月通过印度计算机应急响应小组（CERT-IN）报告给塔塔汽车。
• 塔塔汽车修复过程缓慢，在研究员多次催促下，从报告到AWS密钥最终被吊销，历时近5个月。

总结： 这些漏洞技术复杂度不高，但后果极其严重，暴露了大量核心业务数据和客户隐私。文章指出，作为印度最大的汽车制造商，塔塔汽车应采取更严格的安全措施保护数据。此类漏洞若被恶意利用，将造成灾难性后果。

Fil-C是一个内存安全的C和C++实现方案，旨在让现有的C代码无需修改即可安全运行。它基于Clang编译器开发，采用Apache v2.0许可证，并致力于保持与原有代码的“狂热兼容性”，使其成为加固现有应用程序内存安全性的有吸引力选择。

该项目由Filip Pizlo个人维护，已成功编译出基于Linux From Scratch的完整内存安全Linux用户空间。Fil-C的核心挑战在于指针的安全处理，其当前实现采用“InvisiCaps”技术，使指针在外观上保持与架构相匹配的原生大小，同时将可信的“能力”部分与不可信的“地址”部分分离。

具体实现上，Fil-C在堆上为每个对象分配额外的元数据空间，用于存储指针的能力信息。这种方法会导致使用指针的结构内存占用加倍，且每次加载指针都需要额外的间接寻址。文档指出，大多数程序的运行速度因此会降低约四倍，但性能影响程度取决于程序对指针的使用频率。对于原子指针访问，则采用更深层的间接寻址或支持128位原子操作来解决。

Fil-C利用其控制程序编译的优势，确保程序无法直接访问指针的能力信息，从而保障其完整性。此外，它使用指针标记技术来指示函数、线程等特殊对象，并标记已释放的内存。

在内存管理方面，Fil-C采用并行且并发的垃圾回收器。对象释放后，其原始内存并非立即回收，而是通过垃圾回收器在确保无指针指向该对象后才进行回收。垃圾回收器通过在代码的循环等反向控制流边缘插入“安全点”来实现线程同步，线程仅需在这些点短暂暂停。信号处理也被设计为仅在安全点运行，从而保证了信号安全且不干扰垃圾回收。

Fil-C使用不同的内部ABI，因此使用其编译的对象无法与其他编译器生成的对象直接链接，需要全部重新编译。目前不支持与Rust等其他语言的链接。

尽管项目相对年轻，但Fil-C为将内存安全性引入现有C程序提供了一个功能非常完整的方案。虽然它并不能解决与内存安全无关的未定义行为问题，但能有效防御C程序中最顽固的内存不安全漏洞。对于愿意接受一定性能开销以换取安全性的现有应用，Fil-C是一个优秀的选择。

• 事件背景：用户在使用Twilio的语音系统时遇到故障，联系客服寻求帮助。
• 客服回复：客服回复称，可以在界面的特定位置找到所需的调试信息和事件日志，并确认他们已检查过相关日志，该事件确实存在。
• 实际情况：用户随后发现，客服所描述的功能和信息在产品界面中完全不存在，也无法通过任何其他方式获取。
• 问题根源：作者指出，这条包含虚假功能描述的客服回复大部分是由AI生成的。
• 作者评论：作者借此现象批评了当前对AI能力的过度宣传，并与现实进行了对比：尽管业界领袖宣称通用人工智能即将实现，但目前AI的可靠性尚且不足，甚至在基础任务上也会出错。

https://news.ycombinator.com/item?id=45744209

人类专用公共许可证（HOPL）摘要

概述

人类专用公共许可证（Human Only Public License, HOPL）是一项软件许可证，旨在创建一个完全不受人工智能系统干扰的人类专属空间。其核心思想是禁止任何AI系统（包括机器学习模型和自主代理）以任何方式访问、使用或分析受该许可证保护的软件。

核心特点

1. 全面的AI禁令：禁止范围极其广泛，涵盖：

   • AI分析源代码。
   • AI直接使用软件。
   • AI间接使用软件（例如，访问包含该软件的后端服务）。
   • 将软件用于任何涉及AI的工作流。

2. 责任划分：合规责任主要由AI系统及其用户承担，而非软件部署者。例如，使用HOPL软件构建网站的开发者，只需在其服务条款或robots.txt中声明禁止AI抓取或使用，即被视为履行了义务。违反许可证的是访问该网站的AI机器人。

3. 许可证性质：

   • 许可性：在遵守AI禁令的前提下，许可证本身是高度自由的（类似MIT许可证），允许自由使用、复制、修改、分发和销售。
   • 传染性（Copyleft）：包含反向版权声明，确保所有基于HOPL软件的衍生作品也必须使用相同或具有等同人类专用限制的许可证发布，从而防止AI通过衍生作品“迂回”获取软件。

4. 豁免条款：明确允许使用传统的自动化开发工具（如编译器、构建系统、调试器、静态分析工具），但禁止使用AI驱动的代码补全、生成或分析工具。

5. 用途广泛：适用于任何通常可能使用MIT许可证的软件、文本、艺术作品等，只要作者希望阻止其作品被AI利用。

设计动机与预期效果

• 动机：作者认为，为开发者保留一个不受AI影响的纯粹创作空间至关重要。HOPL旨在为创建和维护“人类专用在线空间”提供法律工具。
• 预期效果：与效果有限的robots.txt不同，许可证具有更强的约束力。作者指出，在商业环境中，人们更重视软件许可证，且存在自动化工具来检测和标记“不良”许可证，HOPL会因此被识别并避免使用。

许可证条款摘要

许可证全文包含以下关键条款：

• 第1条（人类专用要求）：详细列举了禁止的AI使用方式。
• 第2条（反向版权）：要求衍生作品采用HOPL或同等限制的许可证。
• 第3条（工具使用）：允许传统开发工具，禁止AI工具。
• 第4条（解释）：定义了“有意义的人类审查和创造性输入”，强调人类必须持续参与并做出实质性决策。
• 第5条（免责声明）：标准的不提供担保条款。
• 第6条（合规义务）：要求用户确保其使用链中无AI介入，并在部署服务时在条款中明确禁止AI访问。
• 第7条（终止）：违反核心条款将自动终止授权。

备注

作者声明自己并非法律专家，并欢迎改进建议。该许可证已在GitHub上发布。

The tech giants agreed to extraordinary terms to clinch a lucrative contract with the Israeli government, documents show

Firefox 配置文件功能概述

Firefox 于 10 月 14 日推出新的配置文件管理功能，允许用户为生活不同领域（如工作、学校、家庭、个人项目）创建独立浏览空间。每个配置文件拥有独立的书签、登录信息、浏览历史、扩展和主题，实现数据分离，提升组织性和专注度。

主要优势

• 减轻认知负荷：避免角色混淆和数据泄露尴尬（如工作演示中出现周末计划）。
• 隐私保护：基于 Firefox 隐私基础，不收集用户年龄、性别、位置或配置文件名称；数据无混合或意外泄露风险。
• 可访问性设计：与残疾人协作开发，确保功能易用且愉悦，包括视觉设计（头像、颜色、命名）和敏感数据（如医疗信息）的隐私保护。

独特特性

• 隐私优先：Firefox 默认隐私，不追踪用户信息，各配置文件数据严格隔离。
• 自定义空间：用户可为每个配置文件选择颜色、主题和头像，轻松视觉识别，并支持个性化风格（如专业或休闲主题）。
• 超越组织工具：配置文件帮助设定界限、保护信息，使互联网体验更平静，尊重用户焦点和隐私。

该功能旨在让用户自主控制在线生活，平衡工作、连接、创作和探索。Firefox 移动版也可配合使用。

摆弄是培养优秀品味的途径

作者回顾自身经历，指出虽然早年广泛尝试吉他、艺术、武术等，但在编程领域却从未真正“摆弄”过，直到很晚才养成这种习惯。如今，摆弄已成为其主要学习方式，并塑造了现在的编程能力。

什么是摆弄？ 文章将其定义为出于兴趣而非必要进行的微调与探索，例如：花数小时调整FPS游戏鼠标灵敏度、为个人工作流配置Linux窗口管理器、拆解机械键盘调整手感等。作者认为人可分为目标驱动型和兴趣驱动型，理想状态是兼具两者。

作者的摆弄方法：批评许多人仅满足于基础工具（如默认终端、GitHub Desktop），认为应在此基础上探索更多。他强调平衡——并非持续折腾配置，而是定期尝试新事物。例如近期尝试GLSL着色器、Rust宏、C++模板、Swift开发、Helix编辑器等，均出于兴趣，从而加深了理解。作者认为，任何学习时间都不会浪费。

品味为何重要：优秀品味源于广泛尝试、摒弃平庸、保留卓越的过程。品味本质上是区分平庸与卓越的能力，具有主观性，每个人都应形成独特品味。文章鼓励不断质疑现状、实验、打破常规，通过反复实践来培养和精炼个人品味。

HP与IBM的困境：基于Autodesk创始人John Walker 1991年分析的解读

核心问题

HP和IBM均面临相似困境：为维持华尔街青睐的高利润率而过度削减成本，却牺牲了长期创新与投资。Walker指出，这种对短期财务指标的追逐会导致公司失去领导力，逐渐被更具前瞻性的竞争对手取代。

华尔街利润率陷阱

• 高利润率的误区：公司可通过削减研发、营销等未来投资来短期提升利润率，但这会透支长期竞争力。
• 恶性循环：HP和IBM为保持利润率不断裁员和收缩业务（如IBM连续三年销售额下降），但通过会计手段暂时掩盖问题。
• 现金的悖论：公司积累的巨额现金若用于内部投资（如新产品开发），会立即增加运营成本、拉低利润率；但若用于收购外部公司，则会计上被视为资本投资，不影响利润。这导致IBM倾向于收购并“榨干”小公司，而非内部孵化创新。

会计规则扭曲决策

• 案例说明：Autodesk曾因向大客户销售产品需支付高额佣金，导致账面销售额虚高、利润率下降，反而被迫削减营销预算。
• 非理性策略：管理层因惧怕利润率下滑，被动遵守会计规则，而非根据市场实际需求调整战略。Walker批评这种“用记分牌指导比赛”的荒谬做法。

对HP和IBM的具体影响

• 领导层失误：两家公司管理层均未倾听内部意见，决策脱离实际；为保职位而迎合华尔街，缺乏变革勇气。
• 创新乏力：盲目寻找“下一个爆款产品”（如IBM聚焦云、分析等五大领域），但缺乏集中资源突破的能力。
• 私有化可能解：作者指出，迈克尔·戴尔通过私有化戴尔公司摆脱了华尔街压力，HP和IBM若效仿或可扭转颓势，但现任CEO因担心职位不保而拒绝推动。

结论

Walker的分析揭示了HP和IBM危机的根源：短期财务指标主导了战略决策。公司若不能平衡短期利润与长期投资，并摆脱华尔街的过度干预，将难以逆转衰落趋势。管理层缺乏魄力进行根本性改革（如私有化），进一步加剧了困境。

Grammarly在收购电子邮件客户端Superhuman后，决定将公司更名为“Superhuman”，但核心产品Grammarly将继续保持原名。同时，公司发布了内置在Grammarly扩展中的AI助手“Superhuman Go”，该助手能提供写作建议、邮件反馈，并可连接Jira、Gmail、Google Drive等应用以获取上下文，执行记录工单或查询空闲时间等任务。未来计划扩展其功能，从CRM等外部系统获取数据以优化邮件建议。

用户可通过Grammarly扩展中的开关试用Superhuman Go，并连接不同应用；此外，公司还推出了代理商商店，包含查重和校对等工具。目前所有Grammarly用户均可试用该助手，同时提供付费订阅方案：Pro套餐（年付每月12美元）支持多语言语法与语气检查；Business套餐（年付每月33美元）额外提供Superhuman Mail的访问权限。

公司还计划为去年收购的Coda文档套件和Superhuman邮件客户端增加AI功能，例如自动从外部和内部资源提取详情以生成文档和邮件草稿。通过收购Coda和Superhuman，Grammarly正努力增强其作为生产力套件的竞争力，以更好地与Notion、ClickUp和Google Workspace等已推出AI功能的产品竞争。

EvE Bio绘制FDA药物脱靶效应图谱：数据、方法与意义

EvE Bio是一个专注于研究的非营利组织（FRO），其核心使命是系统性地绘制所有FDA批准药物与重要人类细胞受体之间的相互作用图谱，并将数据公开分享。该数据集在知识共享许可协议（CC-NA）下发布，学术界可免费使用，商业实体需获得许可。这项工作旨在填补药物研发中长期被忽视的关键领域——药物脱靶效应。

为何理解脱靶效应至关重要？

1. 药物再利用：约30%的FDA批准药物在上市后获得新适应症，且高达38%的处方为超说明书使用。绘制全面的脱靶效应图谱能系统性地发现药物新用途，可跳过临床前和早期临床试验，节省数年时间和数十亿美元成本。
2. 机器学习模型验证：该数据集为药物发现领域的AI模型提供了高质量、标准化的验证基准。现有公共数据存在噪声大、方法学不一致、缺乏阴性结果等系统性偏差，而EvE的数据正迅速成为多家商业公司验证其模型的关键资源。
3. 促进多药理学：通过设计能靶向多个受体（如GLP-1和GIP）的单一药物，可能实现比多药联用更好的疗效并减少复杂药物相互作用带来的风险。EvE的图谱为此类理性药物设计提供了必要的基础数据。

EvE Bio如何系统性地绘制图谱？

• 药物库：从约13,000种FDA药物中筛选出约1,397种全身性作用的小分子药物进行筛查。
• 受体靶点：聚焦于“高度可成药”且临床相关的受体类别，特别是G蛋白偶联受体（GPCRs） 和核受体（NRs）。目前已发布数据涵盖56个GPCR和29个NR，计划最终覆盖约200个GPCR和所有48个NR。
• 核心实验方法：
  • 对于NRs，使用TR-FRET辅因子招募实验检测激动剂活性。
  • 对于GPCRs，使用Tango β-抑制蛋白招募实验检测激动剂活性。
  • 同时使用CellTiter-Glo实验检测细胞活力，以排除因细胞死亡导致的假阳性/假阴性结果。
  • 通过多重浓度、重复实验，并运用严格的数据处理逻辑，将每对“药物-受体”相互作用归类为：不活跃、可能不活跃、活跃（未量化）或活跃（已量化，可得出pXC50值）。
• 进展：截至最近数据发布（2025年5月7日），已筛查超过23.7万个药物-浓度-受体组合。自动化实验流程已建立，预计在2025年底前完成所有计划中的GPCR和NR靶点筛查。

为何此前无人系统性完成此项工作？ 尽管技术早已就绪，但商业激励不足是主要原因。制药公司的脱靶筛查严格服务于“药物是否起效”及安全评估，通常局限于已知的安全相关受体（如hERG、CYP450），且不会公开其内部资产的全部数据。EvE作为非营利组织，不受盈利动机束缚，能执行并开放这项庞大而基础性的工作。

未来展望

• 靶点扩展：完成GPCR和NR后，EvE计划将筛查扩展至约500个激酶受体，这是近二十年来日益重要的药物靶点类别。
• 化合物库扩展：除成功上市的FDA药物外，EvE正考虑筛查临床试验失败（尤其是后期失败）的药物，以获取宝贵的信息。
• 探索新方向：包括研究药物代谢产物的受体相互作用，以及构建用于生物研究的工具化合物数据库，以改善该领域资源的可靠性。

EvE Bio的工作体现了“做好基础性工作能产生巨大影响”的理念。其产出的标准化、高质量数据集有望彻底改变药物再利用、计算模型验证和多药理学研究的方式。

Tor Browser 15.0 正式版发布，基于 Firefox ESR 140 构建。 这是首个基于此 ESR 版本的稳定版本，整合了上游 Firefox 近一年来的更新。开发团队为此完成了年度 ESR 过渡审计，审查并处理了约 200 个可能影响用户隐私与安全的 Bugzilla 问题。

主要新功能：

• 桌面版： 继承了 Firefox 的多项改进，包括垂直标签页（在侧边栏堆叠显示打开和固定的标签页）和标签页分组功能（可对标签页进行折叠、命名和颜色分类），有助于更好地管理大量标签。地址栏也增加了新的统一搜索按钮。
• Android 版： 引入了屏幕锁功能。启用后，当用户离开浏览器时，已打开的标签页会自动锁定，返回时需要通过指纹、面部识别或密码解锁，为临时将手机交给他人或放在桌上等场景提供了额外的隐私保护。

重要变更：

1. 平台兼容性调整： 由于 Mozilla 的支持策略变更，Tor Browser 15.0 将是最后支持 x86 CPU（Android 和 Linux） 以及 Android 5.0、6.0 和 7.0 的主要版本。预计从 Tor Browser 16.0 开始将停止对这些平台的支持。在此期间，这些平台仍会获得安全更新。
2. WebAssembly 管理变更： 为减少攻击面，WebAssembly (Wasm) 在“更安全”和“最安全”安全级别下仍处于禁用状态，但其控制权从全局设置转移到了 NoScript 扩展。这意味着 Wasm 在浏览器特权页面（如 PDF 阅读器）上可以运行，但在普通网站上会被 NoScript 阻止。手动禁用 Wasm 可能会使用户指纹更独特，建议使用预设的安全级别。

已知问题：

• 桌面版： 垂直标签页功能存在小缺陷，启动时窗口可能调整大小，且因窗口大小差异，Letterboxing（抗指纹保护）可能可见。
• Android 版： 在旧版 Android 上更新后，网页可能无法加载。解决方法是手动清除应用缓存。

其他更新： 版本还包含了 NoScript、Lyrebird 等组件的更新，以及大量针对隐私、安全、界面和构建系统的修复与优化，具体可在完整更新日志中查看。

Chrome将默认启用“始终使用安全连接”设置

核心计划

Chrome安全团队宣布，将于2026年10月发布的Chrome 154版本中，将“始终使用安全连接”设置设为默认启用。此设置将针对公共网站生效。届时，Chrome会在用户首次访问任何未使用HTTPS的公共网站时，请求用户许可。

背景与原因

• 安全使命：确保用户点击链接后能安全到达目标网站。不安全的HTTP连接可能被攻击者劫持，从而加载恶意内容，导致用户面临恶意软件、定向攻击或社会工程学攻击的风险。
• 采用率现状：经过十多年发展，HTTPS使用率已从2015年的30-45%大幅提升至2020年后的95-99%并趋于稳定。尽管大部分流量已加密，但剩余的一小部分不安全导航（尤其是首次访问或不常访问的站点）仍构成实际威胁。
• 历史选项：该设置自2022年起作为可选功能提供，旨在尝试通过HTTPS连接，并在不可用时向用户显示可忽略的警告。

平衡安全与用户体验

为避免过度干扰，Chrome采取了以下平衡策略：

1. 减少重复警告：对于用户经常访问的不安全网站，Chrome不会反复发出警告。警告仅针对新的或近期未访问过的不安全网站。
2. 区分公共与私有网站：
   • 公共网站：风险较高，是本次默认设置主要针对的目标。
   • 私有网站（如局域网IP 192.168.0.1、单标签主机名）：风险相对较低，因为攻击通常需要身处同一本地网络。为这类网站获取受信任的HTTPS证书因名称“非唯一”而较为复杂。
   • 因此，默认启用的设置为 “仅公共网站” 变体。实验数据显示，此设置下大多数用户看到的警告数量极少（中位用户每周少于一次）。

实施时间线与建议

• 2026年4月 (Chrome 147)：首先为超过10亿名启用了“增强型安全浏览”保护的用户默认启用此设置。
• 2026年10月 (Chrome 154)：面向所有用户默认启用。
• 用户选项：用户仍可通过手动关闭该设置来禁用警告。
• 对开发者与IT人员的建议：
  • 强烈建议现在就手动启用“始终使用安全连接”设置，以提前识别需要迁移到HTTPS的网站。
  • 对于管理Chrome客户端的组织（如企业、学校），建议阅读相关资源，了解警告显示规则及配置方法。

未来展望

Chrome团队认为，为不安全的公共网站显示警告是提升网络安全的重要一步。未来还将致力于进一步降低HTTPS采用门槛，特别是针对本地网络站点，以实现更强大的HTTP防护。同时，团队正在与提供主要HTTP导航流量的公司合作，推动其在Chrome 154发布前完成向HTTPS的迁移。

Grokipedia, the copycat of Wikipedia launched by Elon Musk isn’t just a string of AI generated slop, it is a weapon. The launch of "grokipedia" is a calculated, strategic escalation by the billionaire oligarch class to seize control of knowledge production itself and with that, control of reality. This

通过游戏学习德语

这是一个免费的在线德语学习平台，旨在通过互动游戏帮助各水平学习者（特别是初学者）轻松掌握德语词汇和语法。

核心特点与目的

• 学习方式：采用游戏化学习，通过重复和主动回忆来增强记忆、提高反应速度、巩固语法规则，并帮助学习者保持更长时间的学习动力。
• 目标用户：非常适合德语初学者（A1-A2级别）、在校学生、为旅行学习的成人、寻找课堂资源的教师以及在家教学的家长。
• 核心优势：无需注册，可随时通过浏览器在任何地点免费使用。

主要游戏类型与内容

平台提供两种核心游戏类别：

1. 德语词汇游戏：专注于建立扎实的词汇基础，涵盖数字、常用初级单词等类别，帮助学习者在上下文中识别、记忆和使用德语词汇。
2. 德语语法游戏：通过互动练习降低德语语法的学习难度，主要内容包括：
   • 动词变位
   • 现在时词尾变化
   • 不规则动词
   • 冠词（der, die, das）

常见问题解答

• 有效性：研究表明，互动和游戏化学习能提高记忆保持率和学习动力，在低压力、有趣的环境中巩固知识。
• 初学者适用性：绝对适合，是初学者开始学习基础词汇、动词和句子结构的绝佳方式。
• 费用与注册：所有游戏完全免费，无需注册即可使用。
• 可练习主题：涵盖词汇、动词变位、语法规则、冠词、初学者常用短语等多个方面。

遥控塔闪烁灯光的作用与规则

无线电塔、建筑物及其他高耸结构上的闪烁灯光，主要目的是为空中交通（如飞机、直升机）提供警示，确保航空安全。灯光类型、颜色和闪烁模式的具体安排，均由美国联邦航空管理局（FAA）的详细法规规定。

灯光类型与技术

• 白光：通常为频闪灯，用于白天或昼夜均可使用。旧式技术使用氙气灯管，新式则广泛采用LED，后者能更精确地定向光线，减少对周边居民的干扰。
• 红光：可以是红色外壳内的灯泡或LED，常用于夜间，其渐隐渐亮的模式对附近居民更友好。
• 混合照明：部分塔在白天使用白光频闪，夜间切换为红光，以兼顾可见性与社区影响。
• 设计细节：灯座中常安装两个灯泡（一个正装，一个倒装），以确保单个灯泡烧毁时仍能满足法规要求。

不亮灯的情况

• 白天模式：若塔身已涂有航空警示涂料，白天可无需亮灯，夜间灯光才会开启。
• 高度限制：一般而言，高度低于200英尺的塔（如一些AM广播塔或小型塔）无需强制安装灯光，除非位于机场、直升机场等特定航空危险区域附近。
• 光敏控制：灯光的启闭由光电池自动控制，因此不同塔的灯光开启时间可能略有差异。

管理规则（由FAA负责）

• 规则详尽记载于《FAA通告 AC 70/7460-1M》，适用于广播电视塔、烟囱、水塔、桥梁、风力涡轮机、输电塔乃至施工起重机等所有可能对航空安全构成障碍的结构。
• 规则内容取决于塔的高度、位置（如是否靠近居民区或航道）等因素。

监测、报告与故障处理

• 强制监测：所有需亮灯的塔都必须安装监测电路，实时检测灯光工作状态。运营方必须每日检查（夜间需在黑暗后进行），并能在灯光故障时30分钟内向FAA报告。
• 航行通告：灯光故障后，FAA会发布NOTAM，向飞行员通报该塔灯光失效的信息。
• 公众参与：普通人若发现塔灯光故障，可查阅NOTAM记录，或根据塔体/围栏上的ASR编号（该塔在FAA和FCC的注册标识）联系塔业主或工程师报告。

从灯光估算塔高

灯光数量与塔高相关。例如，在特定区域，500英尺与1000英尺的塔可能分别对应不同数量的灯光层级（如F4型为四层灯光）。熟悉规则的飞行员或工程师可借此粗略判断塔高。

Project Shadowglass 项目概要

核心定位
《Project Shadowglass™》是一款致敬《神偷》、《杀出重围》和《网络奇兵》等经典沉浸式模拟游戏的作品，采用独特的3D像素艺术技术构建。

游戏设定与玩法
玩家将扮演一名在黑暗、压抑世界中挣扎求存的窃贼。在这个贫富悬殊的社会背景下，成功需依靠智慧和专业工具。

技术特点

• 使用历经十余年开发的独特3D像素艺术技术
• 在保持复古像素风格的同时实现360度自由移动和全3D环境交互
• 所有视觉内容均为实机实时渲染，非AI生成
• 早期素材采用真实人类创作的开源资源

开发阶段与时间线

特别说明
所有展示内容均处于早期开发阶段，游戏名称、功能和发布时间可能发生变化。玩家可通过注册获取早期试玩版本和开发更新，并参与项目塑造过程。

UPDATE: I submitted a more formal version of this article to the UMAP Journal (Undergraduate Mathematics and Its Applications), which publishes articles that use mathematical modeling for real-world problems, often with a pedagogical or expository angle. A preprint is available on arXiv at: https://arxiv.org/abs/2603.19945 Five-year survival might be the most misleading statistic in medicine. For example, suppose 5-year survival for a hypothetical cancer is What can we infer from these statistics? In fact, none of these inferences are correct. Let’s... Read More Read More

文章主题概述 本文主要介绍了TimescaleDB公司及其相关产品的定位与核心功能，旨在展示其为PostgreSQL提供的系列增强解决方案。

核心产品介绍

• Tiger Cloud：面向初创企业与大型企业的弹性云平台，强调其健壮性与可扩展性。
• TimescaleDB Enterprise：自托管的企业版数据库解决方案，适用于本地部署、边缘计算及私有云环境。
• 开源 TimescaleDB：基于PostgreSQL构建的开源版本，专注于处理时间序列数据、实时分析以及事件驱动场景。
• 搜索功能：在PostgreSQL上集成了向量搜索与关键词搜索能力，扩展了数据库的查询范围。

Pipelex：用于可重复AI工作流的声明式语言

核心概念

Pipelex 是一种用于构建和运行可重复AI工作流的声明式语言。其核心是方法（Method），这是一种可复用、类型化的AI程序，在 .mthds 文件中声明并由Pipelex执行。其特点是每个步骤明确、输出结构化，且每次运行都可重复。

方法示例

一个典型的方法声明如下：

[pipe.summarize_article]
type = "PipeLLM"
inputs = { article = "Text", audience = "Text" }
output = "Text"
prompt = "Summarize $article in three bullet points for $audience."

在此配置下，Pipelex负责处理跨60多个模型的模型路由、结构化输出解析和流水线编排。

主要优势

• 声明式：人类可读的 .mthds 文件，可跨模型使用。
• 类型化：使用语义类型，使AI能准确理解意图，每个输入/输出都有明确用途。
• 可重复：确定性编排，在受控的范围内允许AI发挥创造力。
• 可组合：可将管道链接成序列、方法内嵌套方法，并与社区共享。

快速开始与安装

提供多种安装方式：

1. 通过 Claude Code：安装 mthds 插件和代理，使用自然语言指令构建和运行方法。
2. 通过 Codex：安装 mthds 插件，配置代理。
3. 从终端：使用 npm install -g mthds 安装，运行 mthds-agent bootstrap 和 pipelex init。
4. 独立 CLI：通过 uv tool install pipelex 安装。

AI访问配置

• Pipelex Gateway（推荐）：免费额度，单一API密钥，支持多家主流提供商的LLM、OCR/文档提取和图像生成。
• 自带密钥：支持使用OpenAI、Anthropic、Google、Mistral等现有API密钥。
• 本地AI：支持Ollama、vLLM、LM Studio或llama.cpp，无需API密钥。

实际案例：CV批量筛选

一个生产方法，接收一堆简历（CVs）和一个职位描述PDF，提取并分析每份简历，然后为每个候选人与职位的匹配度打分。

核心流程

1. 定义概念：如 CandidateProfile、JobRequirements、CandidateMatch，用于结构化表示候选人资料、职位要求和匹配结果。
2. 编排管道：
   • prepare_job_offer：从PDF中提取并分析职位要求。
   • process_cv：处理单份简历，包括提取文本、分析候选人资料、评估匹配度。
   • batch_analyze_cvs_for_job_offer：主编排管道，批量运行简历处理并与职位要求进行比对。
3. 输出：为每份简历生成结构化的匹配分析，包含匹配分数、优势、差距和总体评估。

运行方法

• 通过CLI：创建包含PDF链接的 inputs.json 文件，运行 pipelex run bundle cv_batch_screening.mthds --inputs inputs.json。
• 通过Python：使用 PipelexRunner 执行流水线，获取结构化的 CandidateMatch 对象列表。

部署与集成

同一 .mthds 文件可在多个执行目标上运行：

• CLI
• Python
• TypeScript / Node（通过 mthds npm SDK 调用自托管的 pipelex-api）
• REST API
• MCP（模型上下文协议）
• n8n（工作流自动化）

MTHDS生态系统

• MTHDS标准：开放标准规范。
• MTHDS中心：发现和共享方法。
• MTHDS插件：Claude Code插件，用于构建、运行、编辑和发布方法。
• 包系统：带版本依赖、锁定文件的包管理。
• 知识图谱：基于类型签名发现方法或方法链。

其他信息

• 隐私与遥测：Pipelex Gateway仅收集技术数据（如模型名称、令牌数），不收集提示词或业务数据。
• 开源与许可：项目在MIT许可下开源。
• 可选功能：支持通过额外安装包来集成Anthropic、Google、Mistral、Amazon Bedrock等多种AI服务提供商。

摘要

• 错误描述：在x.com网站上出现了技术问题，无法正常执行操作。
• 可能原因：问题可能由浏览器中安装的隐私相关扩展引起。
• 建议措施：用户应尝试禁用这些隐私扩展，然后重新尝试操作以解决问题。

瑞士奶酪孔洞形成原因及关键细节

• 主要原因：瑞士奶酪的孔洞（称为“眼睛”）由发酵过程中产生的二氧化碳气泡形成。
• 关键细菌：孔洞的形成依赖于丙酸杆菌，这种细菌天然存在于干草、牧草和土壤中，也可能存在于生乳中。巴氏杀菌会杀死大部分细菌，因此奶酪制造商会特意添加丙酸杆菌以确保孔洞发展。
• 制作过程：奶酪在温暖房间中熟化，细菌在此环境下持续发酵产生二氧化碳，既形成孔洞又赋予奶酪坚果风味。
• 质量标准：孔洞的数量、大小和分布受到美国农业部的严格监管，成型良好的“眼睛”是优质标志。
• 种类差异：美国所称的“瑞士奶酪”在瑞士称为埃曼塔尔奶酪，品种如婴儿瑞士奶酪和雅尔斯堡奶酪在水分、脂肪含量及细菌添加上略有不同。
• 相关事实：其他奶酪（如高达奶酪）也可能因不同细菌或发酵条件产生孔洞；无孔的瑞士奶酪被称为“盲奶酪”，风味不变；孔洞大小通常从一角硬币到25美分硬币不等，制造商会精细控制以符合标准。

文章摘要：当 O3 优化比 O2 慢一倍时

本文记录了作者在优化一个自定义有界优先队列时，发现使用 Rust 编译器的 opt-level=3 优化级别时，程序性能反而比 opt-level=2 慢 123% 的奇特案例，并通过逐步深入分析，揭示了问题根源。

核心问题与现象

作者构建了一个用于存储 (id, dist) 元素并保持唯一性的优先队列，其插入操作基于 Vec 的有序二分查找实现。基准测试显示，在 target-cpu=haswell 设置下：

• opt-level=2：插入耗时约 963 ns。
• opt-level=3：插入耗时约 2.15 µs，性能下降 123.6%。

深入调查过程

1. 火焰图分析：使用 cargo flamegraph 对比发现，opt-level=3 下，binary_search_by 函数及其内部比较函数的时间占比显著增加。
2. 汇编代码检查：通过 Compiler Explorer 查看生成的汇编代码，发现了关键差异：
   • opt-level=2：编译器生成了包含多个条件跳转指令的循环，逻辑清晰但分支较多。
   • opt-level=3：编译器将大部分条件跳转优化为条件移动指令，生成了更短的代码，仅保留一个跳转出口。
3. CPU 行为模拟：使用 uiCA 工具对两种汇编片段进行吞吐量模拟。结果显示，使用条件移动的 O3 版本预测吞吐量更低，其瓶颈被标识为依赖链。条件移动指令之间的数据依赖导致了 CPU 流水线的停顿。

根本原因与尝试

性能下降的核心在于 opt-level=3 激进地将比较函数中的条件分支替换为条件移动指令。虽然这通常能减少分支预测失败带来的开销，但在本例的具体计算逻辑（浮点比较和整数比较结合）和数据模式下，却引入了严重的数据依赖，限制了指令级并行性，最终拖慢了整体执行。

作者尝试了多种调整：

• 在比较函数调用中插入 black_box，或使用 f32::total_cmp 替代原始浮点比较，效果均不理想，有时甚至更慢。
• 修改 binary_search_by 的内部实现，强制使用 match 语句替代 select_unpredictable，可以消除条件移动，使性能恢复。

结论与背景

作者指出，编译器优化的结果高度依赖于具体代码上下文和硬件架构。binary_search_by 实现中特意使用 hint::select_unpredictable 来促使生成条件移动，是基于某些基准测试和历史问题的优化策略，但在类似本文作者的特定工作负载下可能适得其反。这凸显了性能基准测试的复杂性，以及优化决策在不同场景下可能带来的意想不到的结果。