欧盟理事会再次撤回“聊天控制”提案：一场持续的隐私保卫战

摘要： 这篇文章总结了欧盟“聊天控制”提案的最新发展，该提案旨在通过扫描加密信息来打击儿童性虐待材料 (CSAM)，但引发了广泛的隐私担忧。尽管当前丹麦总统委员会已撤回该提案，但这标志着隐私倡导者与寻求在公共安全的名义下削弱加密的立法者之间长期斗争的又一个阶段。文章强调了该提案的反复出现（被称为“僵尸提案”），并指出了其技术上的不可行性以及对隐私的潜在威胁，并呼吁采取更有效的替代方案。

主要内容：

• 提案背景： “聊天控制”提案自2022年提出以来，不断被提出和撤回，受到隐私倡导者、技术专家和公众的强烈反对。 电子边境基金会 (EFF) 等组织联合了超过 80 个民间社会组织，对该提案表示反对。
• 技术问题： 该提案的核心问题在于其对加密技术的基本误解。它试图通过“客户端扫描”来绕过端到端加密的安全性，但这实际上会破坏整个加密系统，使其容易受到恶意行为者的攻击。任何扫描机制都无法仅用于“好人”，并且容易被滥用。苹果公司在2021年提出的类似计划也因安全漏洞而失败。
• 范围蔓延的风险： 该提案可能会导致范围蔓延，即最初用于打击非法内容的系统，可能被扩展到监控政治异议、宗教表达等。
• 公众压力与抵抗： 公民社会组织、科技公司、安全研究人员和普通公民的积极参与，使得该提案在政治上变得难以接受。EFF、欧洲数字权利组织 (EDRI) 等组织通过教育公众、提供技术解释和组织反对运动，发挥了关键作用。
• 未来挑战： 虽然提案被撤回是一次胜利，但推动“聊天控制”的力量并未放弃，政治动态也没有改变。 政治家面临着为了“采取行动”而显得强硬的压力，尤其是在儿童安全问题上。
• 前进之路： 文章呼吁改变技术政策制定方式，不再寻求技术上的“灵丹妙药”，而是投资于真正有效的解决方案，例如：
  • 加强执法部门的培训和工具，无需破坏加密。
  • 改善国际合作以进行刑事调查。
  • 通过社会项目和教育解决网络剥削的根本原因。
  • 科技公司应开发和推广真正保护隐私的安全功能，例如元数据分析、用户举报系统和账户级限制。
• 结论： 保护加密是一场持续的斗争，需要长期承诺。 必须让政策制定者认识到，为了打击非法内容而破坏加密会造成更多问题，而不是解决问题。

关键词： 欧盟，聊天控制，加密，隐私，网络安全，客户端扫描，僵尸提案，欧洲数字权利组织 (EDRI)，电子边境基金会 (EFF)

好的，这是对原文的总结，字数在800字以内，使用Markdown格式，并为中文：

URL 设计的价值：将 URL 作为状态容器

这篇文章探讨了前端工程师常常被忽视的 URL 的价值，指出 URL 不仅仅是用于获取资源的地址，更可以作为一种强大的状态管理工具。作者通过 PrismJS 下载页面的 URL 例子，启发了对 URL 在前端开发中应用的新思考。

URL 的力量

作者引用 Scott Hanselman 的观点，认为“URL 是 UI”，强调了 URL 的多重作用：

• 可分享性: 分享链接，他人看到的内容与你一致。
• 可书签性: 保存链接，保存了特定时间点的状态。
• 浏览器历史: 后退按钮正常工作。
• 深度链接: 直接跳转到应用程序的特定状态。

文章认为，URL 能够让Web应用程序更具韧性和可预测性，是Web的原生状态管理方案。

URL 如何编码状态

文章详细分解了 URL 的各个组成部分，并解释了它们如何编码状态：

• 路径段 (/path/to/myfile.html): 用于资源层级导航，例如用户帖子或文档结构。
• 查询参数 (?key1=value1&key2=value2): 完美用于过滤、选项和配置，例如主题、语言、分页、排序和日期范围。
• 文本碎片 (#SomewhereInTheDocument): 适用于客户端导航和页面部分，例如 GitHub 代码高亮或滚动到特定页面区域。

文章还介绍了常见的查询参数模式，例如：

• 多值分隔符: 使用逗号或加号分隔多个值。
• 嵌套或结构化数据: 使用逗号分隔的键值对或 Base64 编码的 JSON。
• 布尔标志: 传递布尔值或依赖键的存在。
• 数组（方括号表示法）： 使用 ?tags[]=frontend&tags[]=react&tags[]=hooks 格式。

最佳实践与常见模式

文章建议对 URL 状态管理遵循一些最佳实践：

• 优雅地处理默认值: 避免在 URL 中填充默认值，在代码中处理默认值。
• 防抖 URL 更新: 对于高频更新（例如搜索即输入），防抖 URL 更改。
• pushState vs. replaceState: 根据所需的浏览器历史行为选择合适的方法。pushState 用于创建新的历史记录条目，而 replaceState 用于更新当前条目。

适用场景与反模式

文章明确了哪些状态适合存储在 URL 中，例如搜索查询、分页、视图模式等，哪些不适合，例如敏感信息、临时 UI 状态等。

同时列举了需要避免的反模式：

• “仅内存状态”的SPA: 刷新页面导致状态丢失。
• URL 中存储敏感数据: URL 会被记录，不安全。
• 不一致或不透明的命名: 使用清晰、一致的参数名称。
• URL 过度加载复杂状态: 避免使用过长的 URL。
• 破坏后退按钮: 不恰当使用 replaceState。

URL 作为契约

文章强调，精心设计的 URL 不仅仅是状态容器，还是应用程序与用户之间的契约，明确了状态的公共与私有、客户端与服务器、可分享与会话特定等边界，并能清晰地表达意图。 良好的 URL 能够提升缓存效率，便于版本管理和演进。

通过本文，作者呼吁前端工程师重新审视和利用 URL 这一被低估的强大工具，以构建更强大、更用户友好的 Web 应用程序。

Claude Code 生态系统使用心得与经验总结

本文总结了作者在使用 Claude Code 构建 AI 开发工具的经验，涵盖了从基础文件 CLAUDE.md 到高级功能如 Subagents、Hooks 和 GitHub Actions 的各个方面。作者强调了这些工具在专业团队中大规模代码生成（每月数亿 tokens）的应用场景，并分享了个人在业余项目中的使用心得。

核心观点：

• CLAUDE.md 是关键： 这是 Agent 的“宪法”，定义了仓库的工作方式。在个人项目中可以随意，但在专业团队中需要严格维护，目前作者维护的 monorepo CLAUDE.md 已经达到 13KB，并可能进一步增长。
• 编写 CLAUDE.md 的最佳实践：
  • 从 Guardrails 开始，而非手册： 记录 Agent 犯错的地方，逐步完善。
  • 避免 @ 文件引用： 引用外部文档会增加上下文窗口负担，应明确说明阅读条件。
  • 避免负面约束： 提供替代方案，避免 Agent 陷入僵局。
  • 利用 CLAUDE.md 作为“强制函数”： 简化复杂 CLI 命令，鼓励代码和内部工具的简化。
• Slash Commands 要谨慎使用： 避免过度依赖复杂自定义 Slash Commands，保持 Agent 的灵活性和自主性。
• Subagents 的局限性： 自定义 Subagents 会隐藏上下文，并可能强制人类工作流程。更推荐使用 Claude 内置的 Task(...) 特性，让 Agent 自主管理任务 delegation。
• 充分利用 /context： 监控上下文窗口使用情况，避免资源浪费。
• Hooks 的重要性： 使用 block-at-submit Hooks 强制状态验证，避免在写入时阻塞 Agent，保持其工作流程的完整性。
• Skills 是未来： Skills 将 Agent 的脚本化能力正式化，比 MCP 更加灵活和强大。
• MCP 的新角色： MCP 应该作为数据网关，提供有限的高级工具，让 Agent 能够安全地访问环境并进行脚本操作。
• GitHub Actions 的价值： 利用 Claude Code GitHub Actions 构建可审计、自改进的工程系统。
• 配置 settings.json： 用于调试、安全控制和优化性能。

总结：

作者认为，Claude Code 并非只是一个交互式 CLI，更是一个强大的 Agent 框架。应将 CLAUDE.md 视为高层次的指导原则和指针，并利用 Hooks 和 Skills 等高级功能，将 Claude Code 融入到工程系统的各个环节，最终实现代码生成和软件开发的自动化和智能化。

https://www.telegraph.co.uk/world-news/2025/10/28/sudan-bloodied-sands-massacre-thousands/

GHC 现在可以在浏览器中运行 - 摘要

这篇简短的帖子宣布了 Haskell 编译器 GHC 可以在浏览器中纯客户端运行。

主要内容：

• 核心功能： GHC 现在具备在浏览器中运行的能力，这意味着 Haskell 代码可以在完全离线的环境下执行，无需服务器端支持。
• 演示： 帖子提供了一个 Haskell playground 演示，允许用户体验在浏览器中运行 GHC。
• 注意事项： 帖子声明存在条款和条件，并且作者计划稍后提供更详细的解释。
• 图像： 帖子包含一张图片，可能展示了浏览器中运行的 Haskell playground。

总结：

GHC 可以在浏览器中运行，这是一个令人兴奋的进展，它标志着 Haskell 编程更广泛的可访问性和灵活性。 帖子提供了一个演示，并承诺未来会提供更详细的说明。

阿里云通义深思：首个开源的深度研究 Web Agent (Alibaba Tongyi DeepResearch: The First Open-Source Deep Research Web Agent)

阿里云发布了 通义深思 (Tongyi DeepResearch)，这是一个性能与 OpenAI DeepResearch 相当的首个完全开源的 Web Agent。它在多个学术推理和信息检索基准测试中取得了领先成绩：

• Humanity’s Last Exam (HLE): 32.9 分
• BrowseComp: 43.4 分
• BrowseComp-ZH: 46.7 分
• xbench-DeepSearch: 75 分 (显著优于现有私有和开源 Agent)

核心贡献:

• 完整的训练方法: 除了模型本身，阿里云还分享了构建此类先进 Agent 的完整、经过验证的方法，包括从 Agentic 持续预训练 (CPT) 和监督微调 (SFT) 到最终强化学习 (RL) 的整个训练流程。
• 创新数据合成: 引入了数据合成解决方案，用于整个训练流程，旨在提升模型性能。
• 端到端强化学习解决方案: 包括算法创新、自动化数据整理和强大的基础设施支持。
• ReAct 和 Heavy Mode 推理: ReAct 框架展示了模型强大的内在能力，而 Heavy Mode (测试时缩放) 则展示了其复杂的推理和规划潜力。

详细技术亮点:

• Agentic CPT: 创建强大的 Agentic 基础模型，用于后续训练。
• 数据重组与问题构建: 从文档、公开数据、知识图谱和工具调用记录中收集数据，重组为实体锚定的开放世界知识记忆，并生成多风格的 (问答) 对。
• 动作合成: 基于问题和轨迹，构建一阶和高阶动作合成数据，无需额外调用商业工具 API。高阶动作合成将轨迹重塑为多步骤决策过程，增强决策能力。
• 高质量合成 QA 对: 通过图结构知识图谱构建和随机漫步等技术，生成高质量的合成 QA 数据集，并采用原子操作建模方法，系统性地增加问题的复杂度。
• IterResearch 范式: 一种创新的 Agent 范式，通过动态重建精简的工作空间，确保每个决策都经过深思熟虑，提高长期任务中的推理能力。
• Research-Synthesis 框架: 利用多个 Research Agent 并行探索问题，然后由 Synthesis Agent 集成结果，以提高性能。

实际应用:

• 高德 Mate (地图导航 Agent): “小高” AI 助手，可自主规划包含景点和宠物友好的酒店的行程。
• 通义法睿 (法律研究 Agent): 自主执行复杂的法律研究任务，提供基于司法来源的结论和引用。

未来工作:

• 扩展上下文窗口长度。
• 验证更大规模模型上的训练方法。
• 提升强化学习框架的效率。

开源资源:

• GITHUB: https://github.com/Alibaba-NLP/DeepResearch
• HUGGINGFACE: https://huggingface.co/Alibaba-NLP/Tongyi-DeepResearch-30B-A3B
• MODELSCOPE: https://modelscope.cn/models/iic/Tongyi-DeepResearch-30B-A3B
• SHOWCASE: https://tongyi-agent.github.io/showcase/

通义深思代表了人工智能领域的一项重要突破，为构建更智能、自主的 Agent 奠定了基础。

nokode：无需应用程序逻辑的 Web 服务器

本文探讨了作者构建的一个实验项目“nokode”，旨在测试一个大胆的假设：在当前技术水平下，是否有可能创建一个完全由大型语言模型 (LLM) 驱动的 Web 服务器，而无需任何传统的应用程序代码 (如路由、控制器和业务逻辑)。

核心思想与假设:

作者认为，未来的计算模式可能不再依赖代码，而是直接通过意图和执行来实现。因此，他们构建了 nokode，一个 Web 服务器，它接收 HTTP 请求后，直接向 LLM 提问“我应该做什么？”，LLM 则根据请求生成响应。作者最初预期该项目会失败，但希望通过实验来评估我们距离这种未来还多远。

实验设计与工具:

nokode 旨在实现一个基本的联系人管理功能 (CRUD 操作：创建、读取、更新、删除)。实验的核心在于 LLM 仅被赋予三个工具：

• database: 允许 LLM 执行 SQLite 数据库查询，并自动设计数据库模式。
• webResponse: 允许 LLM 生成 HTTP 响应，包括 HTML、JavaScript、JSON 等。
• updateMemory: 允许 LLM 将用户反馈持久化到 Markdown 文件中，并在后续请求中读取这些反馈。

通过这些工具和简单的提示，LLM 能够推断出根据请求路径 (path) 生成不同的响应。例如，访问 /contacts 会生成 HTML 页面，而访问 /api/contacts 会生成 JSON 数据。用户可以通过反馈表单提供改进意见，LLM 会尝试实施这些意见。

实验结果:

令人惊讶的是，实验成功了。虽然 nokode 存在诸多问题：

• 速度慢: 响应时间比传统 Web 应用程序慢 300-6000 倍。
• 成本高: 每次请求的 API 费用是传统计算的 100-1000 倍。
• 内存差: LLM 经常忘记之前的 UI 生成内容。
• 不可靠: LLM 可能会产生错误的 SQL 语句，导致 500 错误。

但即便如此，表单仍然可以提交，数据可以持久化，UI 具有可用性，API 返回有效的 JSON，用户反馈也能被实施。LLM 能够自发地设计合理的数据库模式，编写安全的 SQL 查询，遵循 REST-ish API 规范，并实现响应式 Bootstrap 布局、表单验证和错误处理。

结论与展望:

作者得出结论，实现无需代码的应用程序逻辑的能力已经存在。目前的主要问题集中在性能方面：速度、成本、一致性和可靠性。然而，这些问题被认为是可以通过技术进步逐步解决的，例如：

• 推理速度: 预计每年提升约 10 倍。
• 成本: 预计将趋近于零。
• 上下文: 预计会不断扩展，最终实现设计记忆。
• 错误率: 预计会持续下降。

作者认为，这个项目表明，我们可能比想象中更接近“AI 直接完成任务”的未来，而不是“AI 帮助编写代码”的未来。最终，真正的愿景是 120fps 的渲染速度，实时输入采样，让 AI 成为计算机本身，而不再需要 HTTP 服务器、数据库或基础设施层。

部署与尝试:

项目提供了一个简单的部署和尝试方法：

1. 安装依赖: npm install
2. 设置环境变量：LLM_PROVIDER, ANTHROPIC_API_KEY, ANTHROPIC_MODEL (使用 Anthropic Claude 模型)
3. 运行项目: npm start
4. 访问 http://localhost:3001

用户可以通过修改 prompt.md 文件来定制应用程序的行为，例如构建游戏或仪表盘。

警示: 由于每次请求的成本较高，请注意控制 API 使用量。

Linux/Wasm 操作系统构建脚本总结

该项目提供了一套脚本，用于下载、构建和运行能够在 Web 上执行的 Linux 系统，利用原生的 WebAssembly (Wasm)。这些脚本可以在以下环境中运行：

• 宿主机
• 通用的 Docker 容器
• 专门的 Docker 容器 (见 Dockerfile)

项目组成

该项目由以下软件组件组成：

• LLVM 项目:
  • 基础版本：18.1.2
  • 补丁：包含一个允许 wasm-ld 使用 GNU ld 风格链接脚本的补丁。
  • 产物：clang, wasm-ld (来自 lld), compiler-rt
• Linux 内核:
  • 基础版本：6.4.16
  • 补丁：
    • 添加 Wasm 架构支持的补丁。
    • 启用 .wasm 文件作为可执行文件的 wasm binfmt 特性补丁。
    • Wasm "web console" 的控制台驱动程序。
  • 产物：vmlinux, 未修改的内核头文件
  • 依赖：clang, 具有链接器脚本支持的 wasm-ld (compiler-rt 不需要)
• musl:
  • 基础版本：1.2.5
  • 补丁：一个最小且不正确的补丁，用于：
    • 将 Wasm 添加为 musl 的目标。
    • 允许使用 clang 和 wasm-ld 构建 musl (可能需要链接器脚本支持)。
  • 产物：musl libc
  • 依赖：clang, wasm-ld, compiler-rt
• BusyBox 用 Linux 内核头文件:
  • 基础版本：来自内核
  • 补丁：一系列补丁，最初由 Sabotage Linux 托管，但已修改为适应较新的内核。这些补丁允许 BusyBox 包含内核头文件。
  • 产物：修改后的内核头文件
  • 依赖：导出的 Linux 内核头文件
• BusyBox:
  • 基础版本：1.36.1
  • 补丁：一个最小且不完整的补丁，用于：
    • 允许使用 clang 和 wasm-ld 构建 BusyBox (链接器脚本支持可能不需要)。
    • 添加一个 Wasm defconfig。
  • 产物：BusyBox 安装 (基础二进制文件和 ls、cat、mv 等的符号链接)
  • 依赖：musl libc, BusyBox 用的修改后的头文件
• 最小的 initramfs:
  • 说明：将 BusyBox 安装打包到压缩的 cpio 归档文件中。设置一个 pty 以进行适当的信号/会话/作业管理，并进入 shell。
  • 产物：initramfs.cpio.gz
  • 依赖：BusyBox 安装
• 运行时:
  • 说明：一些示例代码，展示了一个最小的 JavaScript Wasm 宿主环境可能是什么样子的。错误处理不够完善，更注重调试而不是用户体验。这是启动所有事情的胶水代码，启动 Web Workers，创建 Wasm 实例等。

提示： Wasm 缺乏 MMU，因此需要以 NOMMU 配置构建 Linux。Wasm 程序需要使用 -fPIC/-shared 构建。或者，现有 Wasm 程序可以与一个代理一起运行，该代理向内核发出系统调用。在这种情况下，希望独立执行系统调用的每个线程应映射到代理中的一个线程。这种方法的缺点是进程之间不能映射和共享内存。但是，从内存保护的角度来看，此属性也可能是有益的。

运行

运行 ./linux-wasm.sh 查看用法。首先进行下载，然后进行构建。可以选择部分下载或重新构建。由于 LLVM 构建系统中的一个错误，第二次构建 LLVM 会在构建运行时时失败 (抱怨 clang 无法构建一个简单的测试程序)。解决方法是再次构建它 (它在其他时间有效，即第 1 次、第 3 次、第 5 次等时间)。

由于 Linux 内核构建系统中的限制，交叉编译器的绝对路径（LLVM 的安装路径）不能包含空格。由于 linux-wasm.sh 构建了 LLVM，这意味着其工作目录（或至少安装目录）必须在没有空格的路径中。

Docker

以下命令应在 repo 根目录下执行。

有两个容器：

• linux-wasm-base: 包含 Ubuntu 20.04 环境，安装了构建所有工具 (例如 cmake、gcc 等)。

OpenAI 的重大结构调整：一场“盗窃”？

OpenAI 近期宣布了一项重大结构调整，将其投资者权益变得无上限，同时设立了一个非营利性基金会，保留了 26% 的公司股权和一定程度的控制权。这一举动引发了广泛的争议，许多人将其形容为有史以来最大的“盗窃”之一，甚至可能超过了苏联解体的事件。

调整的核心内容：

• 公司结构转变： OpenAI 将转型为公共利益公司（PBC），允许投资者获得无上限的利润分成。
• 非营利性基金会地位变化： 基金会的控制权和股权比例大幅下降，从之前的控制地位和更大的财务占比，变为仅保留 26% 的股权。
• 价值转移： 基金会的利益转移预计高达数千亿美元，引发了对公平性的质疑。
• 潜在的补偿： OpenAI 承诺基金会在 15 年后，如果公司股价增长超过十倍，将获得额外的股权。然而，基金会能否实际获得这些股权存在不确定性。

争议点：

• “盗窃”指控： 许多人认为，OpenAI 的调整实质上剥夺了非营利性基金会的利益，将其转移至私营投资者手中。
• 公众反应： 媒体和公众普遍认为这是非营利性基金会的一次胜利，但批评者指出，这只是相对于 OpenAI 之前的更糟糕的计划而言。
• 监管部门的反应： 特拉华州和加利福尼亚州的监管部门对这一调整表示“无异议”，但仍面临潜在的法律挑战。
• 对未来影响的担忧： 投资者对 OpenAI 的安全和使命的关注程度，以及基金会能否真正维护公众利益，仍然存在疑问。

关键细节：

• Microsoft 的角色： Microsoft 在 OpenAI 的调整中扮演了重要角色，持有约 27% 的股权。
• 新的控制结构： 特拉华州和加利福尼亚州的监管机构对 OpenAI 的控制结构提出了要求，包括非营利性基金会保留一定的控制权和监督职责。
• 资金用途： 非营利性基金会承诺将 250 亿美元用于健康和疾病治疗以及人工智能安全领域，但资金的具体用途和效果仍有待观察。

总结：

OpenAI 的结构调整是一项复杂且备受争议的事件，引发了对人工智能发展方向、利益分配以及监管责任的深刻反思。尽管监管部门批准了这一调整，但潜在的法律挑战和公众质疑仍然存在。未来，非营利性基金会能否真正履行其使命，以及 OpenAI 是否会继续秉持其最初的价值观，将是值得关注的问题。

总结：作者拥抱 FreeBSD，重拾学习热情

作者在之前经历了一段技术使用方式的困境，感觉自己被固有的模式束缚，难以改变。为了寻求新的开始，他选择了 BSD 家族的操作系统，特别是 FreeBSD。

主要内容：

• 选择 FreeBSD 的原因： 作者之前就尝试过 FreeBSD 和 OpenBSD，并对它们印象良好。OpenBSD 在单用途虚拟机中表现可靠，而 FreeBSD 则能满足作者对多用途系统的需求，支持容器或虚拟机运行多个独立工作负载。
• 搭建环境： 作者通过 Hetzner 服务器拍卖购买了一台服务器，并使用 BastilleBSD 进行 jails 管理，使用 vm-bhyve 创建虚拟机。搭建过程充满挑战，但也让他重拾了学习新事物的热情。
• 对 FreeBSD 的喜爱： 作者尤其欣赏 FreeBSD 的简洁性和良好的文档。大部分任务可以通过 SSH 上的简单命令完成，如果找不到直接方法，通常会有相应的工具或封装。 FreeBSD 的长期兼容性也让作者印象深刻，旧的解决方案依然有效。
• 学习过程： 作者在学习过程中遇到了一些困惑，例如对 FreeBSD 的发布周期和 pkg/ports 关系的理解。得益于 BSD 社区的友善和乐于助人，作者得以克服这些困难，并享受了重新成为“新手”的乐趣。
• 未来展望： 作者目前还不确定是否会长期坚持现有的配置，但重要的是他正在享受学习的过程，并期待未来能坚持下来的部分。

关键词： FreeBSD, BSD, BastilleBSD, vm-bhyve, 虚拟机, jails, 服务器, 学习, 社区, 兼容性.

ML-DSA Go 实现调试经历与 AI 工具的价值 (ML-DSA Go Implementation Debugging and the Value of AI Tools)

本文讲述了作者在 Go 语言中实现 NIST 规范的后量子签名算法 ML-DSA 的过程，以及如何使用 Claude Code AI 工具成功地定位并修复了代码中的一个低级错误。

主要内容：

• 实现过程与初始问题: 作者在四天内完成了 ML-DSA 的 Go 实现，但验证函数始终拒绝有效的签名，导致测试失败。
• Claude Code 的介入: 作者尝试使用 Claude Code v2.0.28 (Opus 4.1) 来定位问题，并提供了代码仓库和测试指令。
• Claude Code 的发现: Claude Code 迅速定位到一个复杂的低级错误：在验证过程中，w1Encode 函数被重复调用，导致 w1 的高位被错误地计算了两次。 它不仅发现了问题，还生成了测试用例并提出了修复建议。
• 后续调试与优化: 作者最终对代码进行了重构，修改了 w1Encode 函数的输入参数，提高了代码的清晰度和效率。
• 其他 Bug 发现: 在实现签名功能时，作者也遇到了两个 Bug：
  • 常量计算错误。
  • 签名长度不足 (32 位而不是 32 字节)。
• 再次使用 Claude Code: 作者将包含 Bug 的代码版本提交给 Claude Code，并要求其找出问题。 Claude Code 最终成功地定位并修复了这两个 Bug，尽管在修复第一个 Bug 后，它在定位第二个 Bug 时花费了更多时间。
• 总结与反思: 作者总结了 Claude Code 在低级密码学代码调试方面的强大能力，强调了 AI 工具在提高开发效率方面的价值，并表达了对未来 AI 工具在软件开发中的应用场景的期望，例如自动化测试失败原因分析。

核心细节：

• 算法: ML-DSA (一种后量子签名算法)
• 编程语言: Go
• AI 工具: Claude Code v2.0.28 (Opus 4.1)
• 主要 Bug: 在验证过程中，w1 的高位被重复计算。
• 修复方法: 重构 w1Encode 函数，使其接受高位作为输入。
• 作者的观点: AI 工具对于定位低级错误非常有价值，可以显著提高开发效率。

总而言之，这篇博文详细描述了作者使用 AI 工具解决密码学代码调试问题的经历，并强调了 AI 工具在软件开发中的潜在价值。

Pomelli：谷歌实验室推出的AI营销工具，助力中小企业社交媒体营销 (Pomelli: A New AI Marketing Tool from Google Labs to Help SMBs with Social Media Marketing)

摘要:

Pomelli 是谷歌实验室与谷歌DeepMind合作推出的一项全新AI实验，旨在帮助中小型企业（SMBs）轻松创建可扩展、符合品牌形象的社交媒体营销活动。它通过分析企业网站，学习其品牌特征，并生成定制化的营销活动创意和营销素材。目前，Pomelli已在美国、加拿大、澳大利亚和新西兰面向公众开放Beta测试，仅支持英语。

详细说明:

Pomelli 旨在解决中小企业在创建有影响力的、符合品牌形象的内容时，面临的时间、预算和设计专业知识方面的挑战。 其核心功能包括三个步骤：

1. 构建品牌 DNA (Build your business DNA): 用户输入网站链接，Pomelli 会分析网站内容，提取并理解企业的独特品牌标识，创建“品牌 DNA”档案。该档案包括品牌语气、自定义字体、图像和配色方案。所有生成的素材都基于此 DNA，确保内容在各个渠道上保持一致性和真实性。
2. 生成定制化的营销活动创意 (Generate tailored campaign ideas): 在确定品牌 DNA 后，Pomelli 会生成专门为企业定制的营销活动创意，帮助企业快速确定营销方向。用户也可以输入自定义提示来生成符合特定愿景的内容。
3. 编辑和创建高质量、符合品牌形象的素材 (Edit and create high-quality, branded creatives): Pomelli 会生成一系列高质量的、符合品牌形象的营销素材，可用于社交媒体、网站和广告等多个渠道。用户可以浏览生成的素材，选择最符合营销目标的内容，并在工具内直接编辑文本或图像。所有素材均可下载并立即使用。

Pomelli 目前处于公开Beta测试阶段，谷歌欢迎用户提供反馈，以不断改进该工具。

Open Space 项目概要 (Open Space Project Summary)

Open Space 是一个开源的通信硬件和软件倡议，旨在利用开源软件定义相控阵技术，让公众能够通过将信号反射到月球上进行全球通信，并实现更多应用。

核心目标: 将地球-月球-地球 (EME) 通信（传统上需要大型天线、昂贵设备和精确手动跟踪）普及化，降低门槛。

项目阶段和硬件:

项目预计于 2026 年 3 月 推出首批硬件。主要硬件包括：

• SDR Tile (4-天线 SDR 模块):

  • 设计用于组阵，与 Raspberry Pi 管道兼容 (GNU Radio, Python/C++, SoapySDR)。
  • 频率范围：4.9-6.0 GHz (C 波段)，全双工。
  • 带宽：每根天线 40 MHz，8+8 位 I/Q。
  • 发射功率：每根天线 1 W，接收噪声系数：~1.2 dB。
  • 偏振：Tx: RHCP (右旋圆极化), Rx: LHCP (左旋圆极化)。
  • 关键组件：MEMS TCXO，抖动 ~1.4 ps，FPGA: Lattice ECP5，延迟 < 1 ms。
  • 电源：12 V DC (≈25 W 峰值)。
  • 独立应用：通用 4x4 MIMO 软件定义无线电、狐狸狩猎、到达方向 (DOA) 探测、无线电探索、Open Wi-Fi 路由器、Open 4G/5G 基站、无人机高清链路、机器人通信。

• 相控阵 (Phased Array):

  • 小型相控阵 (18 tiles, 72 antennas):
    • 旨在提供实质性的直接ivity，用于实验和学习相控阵技术。
    • 可扩展，支持后期添加扩展板。
    • 应用：高增益回传链路、定向链路、中继回传、狐狸狩猎和定位、移动现场操作、长距离无人机遥测/高清链路。
    • 性能：阵列尺寸：18 个 tile (72 天线)，波束 steering ≈ 60°，预期阵列增益：~34.0 dBi， EIRP：~52.6 dBW。
  • 高孔径相控阵 (60 tiles, 240 antennas):
    • 专为地球-月球-地球 (EME) 实验和射电天文学设计。
    • 提供进行月球反射通信所需的波束形成增益和 EIRP。
    • 应用：EME (月球反射)，银河系 C 波段成像、射电天空巡测、地面 RF 成像、大气和电离层探测实验、高级相控阵研究。
    • 性能：阵列尺寸：60 个 tile (240 天线)，波束 steering ≈ 60°，预期阵列增益：~39.3 dBi， EIRP：~63.1 dBW。
    • 关键特性：相干分配网络，时间保持和 GPSDO 兼容。
    • 电源：12 V DC (≈1.5 kW 峰值)。

重要声明:

• 所有硬件都需要业余无线电 (Technician+) 执照才能操作，并受国家限制。
• 该项目不适用于雷达应用，因为缺少雷达应用所需的关键功能，并且受到出口管制限制。

项目网站: https://open.space

Sailfish OS 概述 (Sailfish OS Summary)

Sailfish OS 的起源可以追溯到诺基亚时期，特别是 MeeGo 操作系统。在 2011 年之前，诺基亚和英特尔共同构想了一个开放的移动操作系统。他们投入了约 10 亿美元，创建了基于开源的 MeeGo 操作系统，该系统被用于多个设备，例如标志性的 Nokia N9。虽然 Nokia N9 成为开源操作系统的典范，但诺基亚最终决定放弃该项目，转而选择与微软的 Windows Phone OS 合作。

MeeGo 项目背后的团队对该项目充满热情，拒绝放弃。他们成立了一家新公司 Jolla Ltd.，将基于滑动操作的 MeeGo 开发成流畅的用户体验，即 Sailfish OS。Sailfish OS 很快被增强以运行 Android 应用，并与 Android 芯片组兼容。2013 年 11 月，他们发布了 Sailfish OS 的 Beta 版本，并推出了 Jolla 智能手机。此后不久，发布了 Sailfish OS 1.0 版本，首款 Sailfish OS 产品（Jolla 智能手机）在一年内进入了 36 个市场。2015 年，Sailfish OS 2.0 发布，并伴随着 Jolla Tablet 的推出，以及公司许可策略的加强。

2018 年，Sailfish OS 发展到第三代，提供了一种分包、安全的解决方案，适用于各种企业和政府环境，以及通过 Sailfish X 社区计划为精通技术的消费者提供流畅且安全的移动操作系统。2021 年 2 月推出的第四代 Sailfish 4，引入了众多新功能，以支持不同的生态系统项目，无论是私营企业解决方案还是公共部门政府部署。

Isabelle 的证明系统设计与演进：从 AUTOMATH 到 HOL

本文回顾了作者在形式化证明系统设计上的经历，主要探讨了为何 Isabelle 没有采用传统的证明对象 (proof objects) 机制，以及作者在 AUTOMATH, Martin-Löf 型论和更高阶逻辑 (higher-order logic) 上的探索与选择。

1. AUTOMATH 的影响:

作者在 1977 年有机会接触了 N G de Bruijn 的 AUTOMATH 系统。尽管当时无法直接运行该系统，但作者阅读了许多研究报告，包括 LS Jutting 将 Landau 的《分析基础》从德语翻译成 AUTOMATH 的博士论文。这影响了作者日后在 Isabelle 项目中，致力于忠实于原始文本，逐行形式化的工作方式。AUTOMATH 作为一个逻辑框架，类似于一个“大餐厅”，可以提供各种形式化的服务。de Bruijn 并不认可后来发展起来的强大型论，认为 AUTOMATH 足够表达各种形式系统的推理规则。

2. Martin-Löf 型论的尝试:

作者在 Chalmers 大学学习了 Martin-Löf 型论，被其在程序合成方面的潜力所吸引。虽然作者曾花费数年时间使用 Martin-Löf 型论进行研究，并以此为基础创建了 Isabelle 的早期版本 (Isabelle/CTT)，但最终因其 doctrinaire 的态度和对意图相等 (intensional equality) 的强制性转变而放弃。

3. 更高阶逻辑的选择:

作者认为，与其开发新的形式系统，不如选择一个固定的系统并尽可能地发挥其潜力。 Isabelle/HOL 最终选择了 Church 简单的类型理论 (Type Theory)，并使用类型类 (type classes) 和模块系统 (locale) 进行了扩展。作者注意到，Lean 社区通过对特定版本的计算构造 (calculus of constructions) 的使用，快速形式化了大量的数学内容。

4. ALEXANDRIA 项目与更高阶逻辑的局限性:

在 ALEXANDRIA 项目中，作者最初担心更高阶逻辑无法胜任高级数学的 Formalization。然而，该项目成功地形式化了 Grothendieck Schemes 等复杂数学结果，证明了在特定情况下，更高阶逻辑并不会成为 Formalization 的瓶颈。作者还发现，一些证明需要引入 ZF 公理来处理在陈述中直接引用 ZF 实体的情况。

5. 结论:

作者最终选择继续使用更高阶逻辑，并对依赖型论的某些特性 (例如意图相等和性能问题) 感到担忧。作者认为，依赖型论的价值在于知道什么时候不使用它。 尽管如此，作者仍然对 Lean 社区的规模和 Blueprint 工具表示羡慕。总而言之，作者的经历表明，选择合适的 Formalization 系统，并充分利用其优势，比不断探索新的 Formalization 系统更为重要。

创意贴纸笔记本电脑展示项目 (stickertop.art)

项目简介

stickertop.art 是一个专门展示贴满创意贴纸的笔记本电脑的精选集。该项目秉持“每台笔记本电脑都在讲述一个故事”的理念，强调世界上没有两台完全相同的贴纸笔记本电脑。

主要内容

• 全球视野：收集并展示来自世界各地、经过精心挑选的贴纸笔记本电脑。
• 风格多样：展示的内容涵盖了各种装饰风格，从极简主义的布置到繁复华丽的“混乱杰作”应有尽有。

项目宗旨

该项目旨在庆祝和赞美个性化艺术及其背后的文化内涵，突显用户通过贴纸对电子设备进行自我表达的独特魅力。

深度学习中的反向传播：一个“渗漏抽象”

本文探讨了深度学习中反向传播的本质，并指出其作为一个“渗漏抽象”可能带来的问题。作者认为，过度依赖框架自动计算反向传播，而忽视其底层机制，容易导致难以察觉的训练问题。

核心论点： 反向传播是一个“渗漏抽象”，即它隐藏了学习过程中的一些关键细节，容易让开发者误以为只要堆叠层数即可，而忽略了对数据预处理、初始化等因素的考量。

具体问题与分析：

• Sigmoid 函数中的梯度消失: 使用 Sigmoid 函数时，如果权重初始化不当或数据预处理不合理，可能导致函数饱和，输出接近 0 或 1，从而使得局部梯度接近于零，导致梯度无法有效传递，阻碍网络学习。
• ReLU 函数中的“死亡 ReLU”问题: ReLU 函数在输入小于零时输出为零，如果一个 ReLU 神经元始终输出零，其权重梯度也将始终为零，导致该神经元“死亡”，不再参与学习。
• RNN 中的梯度爆炸: 在循环神经网络 (RNN) 中，由于梯度在时间步上不断累乘，可能导致梯度爆炸，使得训练不稳定。
• DQN 中的梯度裁剪错误: 分析一个 DQN TensorFlow 实现中的梯度裁剪问题，指出错误的裁剪方式可能导致梯度被错误地置为零，影响学习效果。作者建议使用 Huber loss 来替代直接裁剪梯度的方法。

总结与建议：

作者强调，理解反向传播的底层机制至关重要，不能盲目依赖框架自动计算。建议学习 CS231n 的相关课程和作业，深入理解反向传播的原理和可能存在的问题。 开发者应该对反向传播保持警惕，仔细分析其在不同网络结构中的行为，才能更有效地构建和调试深度学习模型。

关键词: 反向传播, 渗漏抽象, 梯度消失, 死亡 ReLU, 梯度爆炸, 循环神经网络, DQN, 深度学习。

iLife A11 智能扫地机器人安全漏洞调查及总结

本文讲述了一位工程师对自己的 iLife A11 智能扫地机器人进行安全调查的经历，并揭示了其潜在的安全风险和数据隐私问题。

事件经过：

工程师发现他的 iLife A11 智能扫地机器人持续将日志和遥测数据发送给制造商。为了阻止数据传输，他屏蔽了制造商的遥测服务器 IP 地址，但随后机器人停止工作。经过调查，他发现机器人收到了来自制造商的远程“kill”命令，导致其无法启动。

反复送修后，服务中心未能解决问题，最终认定机器人已超出保修期。工程师遂自行拆解机器人，深入分析其软件和操作系统。

发现的安全漏洞与数据泄露：

• ADB 访问未受保护： 机器人使用 Android Debug Bridge (ADB)，允许完全的 root 访问权限，但没有密码或加密保护。
• 简陋的安全协议： 制造商采取了一种简单的安全措施，通过省略关键文件来阻止访问，但工程师轻易突破。
• Google Cartographer 实时地图： 机器人使用 Google Cartographer 构建家庭的 3D 实时地图，并将该数据发送给制造商的服务器。尽管智能扫地机器人需要地图数据进行导航，但将数据发送给制造商的行为并未事先告知用户。
• 远程 kill 命令： 工程师在日志中发现了精确匹配机器人停止工作时间的 kill 命令，表明制造商可以远程控制设备。
• 网络依赖性： 机器人只能在连接到制造商服务器时正常运行。在屏蔽了数据收集功能后，制造商远程执行 kill 命令，导致设备无法使用。

原因分析：

工程师认为，许多廉价智能扫地机器人由于硬件能力有限，无法进行本地数据处理，因此必须将数据发送到远程服务器进行处理。这种做法使得用户无法知晓数据的使用方式，并让制造商拥有了对数据的自由支配权。

结论与建议：

工程师最终通过修改，使机器人能够完全本地运行，摆脱了制造商的控制。他建议：

• 避免将物联网设备连接到主要 Wi-Fi 网络。
• 将物联网设备视为“寄居者”，谨慎对待。

总而言之，该事件提醒用户，智能家居设备可能存在严重的安全漏洞和数据隐私风险，需要谨慎选择和使用。

韩国强制公共停车场安装太阳能板：现有设施也适用

以下是对原文内容的总结：

核心政策：

韩国政府已通过一项修正案，要求所有公共和私有停车场，如果停车位超过80个，都必须安装太阳能遮阳棚或停车架。 该政策预计将于本月生效，适用于新建和现有停车场。

政策背景与目的：

• 扩大可再生能源： 该政策旨在积极拓展可再生能源的利用，并增加太阳能和建筑行业的就业机会。
• 提高土地利用效率： 利用闲置的停车场土地，最大化土地利用效率。
• 为公众提供便利： 太阳能遮阳棚能够为车辆提供遮阳避雨，保护车辆内饰，延长塑料和内饰的使用寿命，并有助于降低电动汽车和插电式混合动力汽车的空调负荷，甚至提供停车充电服务。

政策细节：

• 韩国贸易、产业和能源部于8月份宣布了该修正案。
• 该政策的批准发生在9月底。

其他国家案例：

• 美国亚利桑那州： 西北消防区与Standard Solar合作，建设了一个657千瓦的太阳能停车架系统，每年产生超过123万千瓦时的清洁电力，相当于18.5万辆汽车减少的碳排放量。
• 美国纽约市： 推出了一项新计划，将商业区土地扩大到8500英亩，用于太阳能遮阳棚和电动汽车充电站的建设，释放了4亿平方英尺的可用空间。
• 文章还提及了德克萨斯州、新墨西哥州和佛罗里达州等其他阳光充足的州也可能受益。

总结：

韩国的政策表明了太阳能停车场的可行性。文章认为，类似政策在美国其他地区也有潜力，能够降低能源成本，并为社区带来益处。

使用 Python 生成 QR 码：大小写的影响

本文介绍了使用 Python 的 qrcode 库生成 QR 码时，大小写对 QR 码图像大小的影响。

核心内容：

• 生成 QR 码: 使用 qrcode.make() 函数将字符串转换为 QR 码，并使用 .save() 方法保存为图像文件。示例展示了如何使用混合大小写和全大写的字符串生成 QR 码。
• 编码方式: QR 码生成算法会根据输入字符串的大小写进行不同的编码方式。
  • 混合大小写字符串被视为二进制数据。
  • 全大写字符串被视为字母数字数据。
• 字母数字数据: 字母数字数据使用一个包含 45 个字符的字符集 (0123456789ABCDEFGHIJKLMNOPQRSTUVWXYZ $%*+-./:)。 由于 45² = 2025 < 2048，因此两个字母数字字符可以使用 11 位进行编码。如果文本包含字符集之外的字符（例如小写字母），则使用 ISO/IEC 8859-1 编码，每个字符使用 8 位。
• 像素数量减少: 将混合大小写文本转换为全大写文本可以减少每个字符所需的位数，从 8 位减少到大约 5.5 位，从而显著减少 QR 码所需的像素数量（约 30%）。在示例中，从 33x33 的网格 (1089 像素) 减少到 29x29 的网格 (841 像素)。
• 比特币地址编码:
  • Bech32 编码使用 32 个字符的字符集，Base58 编码使用 58 个字符的字符集。因此，Bech32 编码需要更多的字符来表示相同的数据（大约 17% 更多）。
  • 尽管 Bech32 编码需要更多字符，但由于它使用单例字母（小写字母被转换为大写字母），因此生成的 QR 码像素数量少于使用 Base58 编码的 QR 码。
• 相关文章: 文中还列举了几个相关的文章链接，涉及 Base 32 和 Base 64 编码、QR 码的两种含义以及抖动 QR 码等主题。

总结:

文章强调了大小写对于 QR 码图像大小的影响，全大写字符串由于采用更高效的字母数字编码方式，可以生成更小的 QR 码图像。这种优化在比特币地址等需要紧凑编码的应用中尤为重要。

https://www.nytimes.com/2025/11/01/health/alzheimers-dementia-air-pollution.html

Helix 编辑器入门指南 (Helix Editor Introduction)

本文档介绍了 Helix 编辑器的基本使用方法，旨在帮助用户快速上手。

1. 打开文件 (Opening a File)

使用 hx file.txt 命令打开一个新的文本文件。初始状态显示当前为 Normal 模式 (NOR)，敲击普通字母不会直接插入文本，而是触发特定的命令。

要插入文本，按下 i 键进入 Insert 模式 (INS)，此时敲击的字母会被直接插入文档。按下 Esc 键返回 Normal 模式。

2. 移动光标 (Movement)

可以使用方向键上下左右移动光标，但推荐使用 Normal 模式下的 h (左)、j (下)、k (上)、l (右) 键，它们分别将光标左移一个字符、下移一行、上移一行、右移一个字符。

3. 复制粘贴 (Paste)

• x: 选中当前行。
• y: 将选中的内容复制到剪贴板（yank）。
• p: 将剪贴板的内容粘贴到光标之后。

重复使用 x 和 p 可以快速复制多行。

4. 基于单词的移动 (Word-based Movement)

• e: 移动到当前单词的末尾，同时高亮显示整个单词。
• b: 移动到当前单词的开头。

可以使用 e 和 b 组合选择单词的不同部分。按下 ; 键可以取消高亮选择。

5. 选择优先 (Selection-first Approach)

Helix 的核心理念是每个操作都会作用于一个选区。修改文本前，用户可以清晰地看到选区，从而预知结果。例如，选中 "helix" 后，按下 c 键会删除选区内容并进入 Insert 模式，用户即可输入新的内容。

6. 删除 (Delete)

• d: 删除当前选区内容并将其复制到剪贴板。

7. 撤销和重做 (Undo and Redo)

• u: 撤销最近的操作 (类似于 Ctrl + Z)。
• U: 重做最近的撤销操作 (类似于 Ctrl + Shift + Z)。

8. 检查点 (Checkpoint)

使用上述命令进行修改后，可以使用以下命令保存和退出：

• :w: 保存文件。
• :q: 退出文件。
• :q!: 不保存退出。
• :wq: 保存并退出。

9. 更多命令 (More Commands)

• %: 选中整个文件。
• gw: 创建两个字符前缀，用于快速定位单词。
• R: 覆盖当前选区内容。
• gg: 移动到文件第一行。
• /: 搜索字符串。n 查找下一个匹配，N 查找上一个匹配。
• t: 移动到指定字符之前。
• T: 移动到指定字符之后。
• f: 移动到指定字符处。
• Ctrl + d: 向下滚动半页。
• Ctrl + u: 向上滚动半页。

10. 寄存器 (Registers)

Helix 具有寄存器的概念，可以像拥有多个剪贴板一样操作。使用 " 符号，然后是寄存器名称（例如 + 代表系统剪贴板、e 代表最近 yank 的内容）来操作寄存器。例如，"ep 可以将寄存器 e 的内容粘贴到光标之后。P 将内容粘贴到光标之前。

11. 下一步 (Next Steps)

• 探索高级文本操作技巧，如围绕 (surround) 和文本对象 (text objects)。
• 学习使用多光标和宏 (multiple cursors and macros)。
• 了解如何启用语言支持和自动格式化。

简要总结：伊奥尼斯·V·雅纳斯教授逝世

伊奥尼斯·V·雅纳斯教授 (Ioannis V. Yannas)，一位著名的物理化学家和工程师，于10月19日去世，享年90岁。他因发明人工皮肤用于治疗严重烧伤而闻名，并在麻省理工学院 (MIT) 担任教职长达59年。

主要成就与贡献:

• 人工皮肤 (Integra) 的发明: 雅纳斯教授与John Burke医生合作，于1981年成功开发出人工皮肤Integra。该产品由硅胶外层和源自牛筋腱和鲨鱼软骨的分子材料支架组成，能够有效保护伤口免受感染和脱水，并促进健康皮肤细胞的生长。Integra目前广泛应用于治疗严重烧伤、某些类型的整形手术以及糖尿病患者常见的慢性皮肤伤口。该发明被认为是成人器官再生的第一个例子，彻底改变了烧伤治疗领域。
• 器官再生的研究: 雅纳斯教授的主要研究兴趣在于诱导器官再生的过程，用于替代严重受伤或患有绝症的器官。他还推动了使用胶管治疗周围神经损伤的临床应用。
• “单元细胞过程”(UCP) 的概念: 雅纳斯教授与Myron Spector教授共同创建了课程2.79 (生物材料-组织相互作用)，并提出了“单元细胞过程”的概念，将化学工程中控制体积的概念应用于人体细胞过程，为学生提供了一种解码组织对植入体反应的工具。
• 再生医学领域的推动者: 雅纳斯教授的创新精神和对医学问题的积极探索，激励了他人致力于解决诸如失明、中风和脊髓损伤等重大疾病。

其他重要信息:

• 教育背景: 雅纳斯教授于1957年获得哈佛大学化学学士学位，1959年获得麻省理工学院化学工程硕士学位。后于普林斯顿大学获得物理化学硕士学位 (1965) 和博士学位 (1966)。
• 荣誉与奖项: 雅纳斯教授荣获多项殊荣，包括美国医学科学院院士 (1987)、国家发明名人堂成员 (2015)、美国工程院院士 (2017) 以及生物材料学会创始人奖 (1982) 等。他也是《成人组织和器官再生》一书的唯一作者。
• 逝世信息: 雅纳斯教授由其兄弟帕夫洛斯先于他去世。他生前留下两个孩子，五个孙辈，一个妹妹以及众多亲友。

麻省理工学院机械工程系制作的视频“Hope Regenerated”记录了雅纳斯教授的这项开创性发现，并展示了Integra从“失败的实验”到拯救生命的突破性发现的过程。

X.Org 安全公告：多个安全问题 (X.Org X 服务器和 Xwayland)

日期： 2025年10月28日

公告内容：

X.Org 发布安全公告，针对 X.Org X 服务器（低于 21.1.18 版本）和 Xwayland（低于 24.1.8 版本）中发现的多个安全问题提供了修复。相关修复已包含在 xorg-server-21.1.19 和 xwayland-24.1.9 版本中。

具体安全问题：

1. CVE-2025-62229：XPresentNotify 结构创建中的 Use-after-free (使用释放后漏洞)

   当使用 X11 Present 扩展处理和添加像素图 (pixmap) 呈现后的通知时，如果出现错误，错误处理路径中可能会留下一个悬空指针。在后续销毁通知结构时，这可能导致使用释放后漏洞。此问题于 Xorg 1.15 版本引入，并在 xorg-server-21.1.19 和 xwayland-24.1.9 版本中修复。修复提交地址：https://gitlab.freedesktop.org/xorg/xserver/-/commit/5a4286b1。 由 Jan-Niklas Sohn 与 Trend Micro Zero Day Initiative 共同发现。

2. CVE-2025-62230：Xkb 客户端资源移除中的 Use-after-free (使用释放后漏洞)

   在移除 Xkb 客户端资源时，XkbRemoveResourceClient() 函数会释放与设备关联的 XkbInterest 数据，但不会释放与之关联的资源。因此，当客户端终止时，资源删除函数会触发使用释放后漏洞。此问题于 X11R6 版本引入，并在 xorg-server-21.1.19 和 xwayland-24.1.9 版本中修复。修复提交地址：https://gitlab.freedesktop.org/xorg/xserver/-/commit/99790a2c 以及 https://gitlab.freedesktop.org/xorg/xserver/-/commit/10c94238。 由 Jan-Niklas Sohn 与 Trend Micro Zero Day Initiative 共同发现。

3. CVE-2025-62231：Xkb 扩展 XkbSetCompatMap() 中的值溢出

   XkbCompatMap 结构体中的某些值使用无符号短整型 (unsigned short) 存储，但未检查输入数据之和是否可能溢出无符号短整型的最大值。此问题于 X11R6 版本引入，并在 xorg-server-21.1.19 和 xwayland-24.1.9 版本中修复。修复提交地址：https://gitlab.freedesktop.org/xorg/xserver/-/commit/475d9f49。 由 Jan-Niklas Sohn 与 Trend Micro Zero Day Initiative 共同发现。

总结：

X.Org 修复了 X 服务器和 Xwayland 中存在的三个安全漏洞，包括两个使用释放后漏洞 (Use-after-free) 和一个值溢出漏洞 (Value overflow)。建议用户升级到 xorg-server-21.1.19 和 xwayland-24.1.9 版本以解决这些问题。

https://visopsys.org/

好的，这里是根据提供的文档生成的摘要，用中文写成，且字数在800字以内：

Helion：高性能机器学习内核的新范式

在现代机器学习中，对高性能计算的需求不断增长，导致了大量自定义内核的出现。然而，这些内核通常使用低级、硬件特定的语言编写，这带来了长期维护负担，使得内核难以移植到新的硬件架构。Helion (https://github.com/pytorch/helion) 旨在解决这一难题，它通过将高级 Python 嵌入式领域特定语言 (DSL) 编译为自动调优的 Triton 代码，在用户友好的 PyTorch 简洁性和底层语言的性能之间架起了一座桥梁。

动机：抽象层次的选择

选择合适的内核开发抽象层次至关重要。现有的编程语言和抽象方式迫使开发者在低级控制和高级生产力之间做出选择，而这两种方式都存在优缺点。CUDA/Gluon/TLX 提供最大控制，但需要大量精力才能达到高性能，且高度依赖特定硬件。Triton 虽然有所改进，但仍需要手动管理张量索引、自动调优搜索空间等，需要一定程度的代码编写。PyTorch 等框架易于使用，但缺乏细粒度的控制。

Helion 的编程模型：“PyTorch with Tiles”

Helion 的编程模型旨在最小化样板代码，并利用开发者现有的 PyTorch 知识，其核心理念是 “PyTorch with Tiles”。一个典型的 Helion 内核由两部分组成：

• Host 代码： 位于最外层 hl.tile 循环之外的标准 PyTorch 代码，主要用于设置任务，如分配输出张量和计算形状。Helion 自动处理这些值传递到设备代码，无需手动管理参数。
• Device 代码： 位于最外层 hl.tile 循环内的核心部分，编译成高性能的 Triton 内核，在 GPU 上并行执行。

hl.tile 是核心语言构造，它将内核的迭代空间划分为 tiles。开发者只需指定要 tile 的迭代空间，具体的实现细节，如 tile 大小、循环顺序和内存布局优化，由 Helion 的自动调优引擎处理。Helion 还利用 TorchInductor 将标准 PyTorch 运算符映射到对应的 Triton 实现，简化开发过程。

此外，Helion 还支持模板功能，允许将 lambda 函数作为内核的参数传递，这对于实现通用的内核和自定义的后处理非常有用。

Helion 的自动调优引擎

Helion 的关键优势在于其自动、提前 (AOT) 的自动调优引擎。在 Triton 中，开发者需要手动定义自动调优的搜索空间，这需要枚举所有配置，效率较低。Helion 通过隐式搜索空间改变了这一现状。高级语言自动构建一个庞大、多维的实现选择搜索空间。例如，一个 hl.tile 调用会指示自动调优引擎探索不同的块大小、循环顺序以及是否将迭代空间展平为单个维度。

自动调优流程：

1. 首次运行内核时，自动调优引擎启动，评估数千个候选 Triton 内核配置，使用 Differential Evolution 或 Pattern Search 等搜索策略，找到针对特定硬件和输入形状的最佳配置。
2. 自动调优完成后，会打印出最佳配置，开发者可以将该配置硬编码到 @helion.kernel() 装饰器中，以跳过后续的搜索过程。
3. 在生产环境中，Helion 会生成单个、预优化的 Triton 内核，性能与手工调优的内核相当，但开发工作量大大减少。

配置空间：

自动调优引擎探索的配置空间包含各种参数，控制数据移动、线程映射等。配置参数包括：

• indexing: 内存访问方法 (指针算术、块指针、张量描述符)
• block_sizes: 每个维度 tile 大小
• flatten_loops: 循环展平
• loop_orders, l2_grouping: 循环顺序、二级缓存分组
• reduction_loops: 减少循环
• pid_type: 程序 ID 映射
• load_eviction_policy: GPU L1 缓存置换策略
• Triton configs: 标准 Triton 可调参数

性能分析和基准测试

Helion 在 NVIDIA B200 和 AMD MI350X GPU 上进行了基准测试，结果表明 Helion 在大多数内核中优于 torch.compile 和手工编写的 Triton 内核。例如

HyperRogue：非欧几里得Roguelike游戏总结

游戏简介

《HyperRogue》是一款以非欧几里得几何（特别是双曲几何）为核心背景的肉鸽（Roguelike）游戏。玩家扮演一名孤独的冒险者，在一个几何规则异于常理的世界中探索、收集宝藏并躲避怪物。

核心玩法与目标

• 探索与收集：游戏包含72个不同的“世界（Lands）”，每个世界拥有独特的主题、机制、地形、原生怪物、宝藏类型和魔法 Orb 能力。
• 终极目标：寻找传说中的“Yendor之球（Orbs of Yendor）”以赢得游戏，或者完成“Hyperstone Quest”（在每个世界收集10个宝藏）。玩家也可以忽略主线，单纯收集小宝藏。

独特的双曲几何机制

游戏的核心特色在于其基于双曲平面的世界构建，这直接决定了游戏的导航与空间体验：

• 空间特性：网格由六边形和七边形组成；看似平行的直线会发散且永不相交；三角形内角和小于180度。
• 导航挑战：世界空间极其广阔，除非完全原路返回，否则几乎不可能回到之前去过的地方。即使返回，世界看起来也会发生旋转。
• 直观学习：玩家无需提前了解双曲几何，游戏本身提供了比数学公式更直观、深入的学习方式。

战斗与难度系统

• 类国际象棋机制：游戏采用回合制和基于网格的移动，类似在随机生成的双曲平面上下国际象棋。敌人移动可预测，通常通过撞向敌人来击杀它们，但双方都是一击必杀。游戏会阻止玩家走出导致立即死亡的步骤（类似国际象棋中的“将军”）。
• 动态难度：游戏没有结局，难度随收集的宝藏数量动态增加。在特定世界收集的宝藏越多，追击的怪物就越多。收集10个或25个宝藏可作为掌握该世界的里程碑。

特殊模式

游戏提供多种特殊模式以改变玩法和视觉体验：

• Shoot 'em up (Shmup) 模式：将游戏变为非回合制、非网格的实时射击游戏，推荐双人合作。
• 几何对比模式：提供欧几里得、椭圆或球面几何模式，让玩家直观感受不同几何学对游戏的影响；或开启七边形模式增强双曲效应。
• 挑战与策略模式：包括 Yendor 挑战、纯战术模式，以及强调资源管理的 Orb 策略模式。
• 视觉模式：如 Hypersian Rug 或 Conformal 模式，用于改变游戏的视觉呈现。

教育与研究价值

《HyperRogue》最初是一个技术实验，现已发展成为功能最全面的真实非欧几里得几何引擎之一。除了作为游戏，它还可用作：

• 教育工具：通过教程模式作为双曲几何的交互式解释。
• 研究工具：用于应用双曲几何的学术研究。
• 艺术创作：利用纹理模式和矢量图形编辑器创作数学艺术。

获取方式

• 免费版本：可通过官方网站、F-Droid 或 GitHub 免费下载。
• 付费版本：可在 Steam 或 itch.io 购买，更新更频繁，并包含成就和排行榜等社交功能。
• 移动端：提供 Android 和 iOS 版本。

我爱上 Erlang 的原因

这篇文章讲述了作者如何从最初对编程的困惑，到最终爱上 Erlang 编程语言的旅程。

最初的困惑

作者小时候尝试破解 Commodore-64 游戏，接触到 BASIC 编程。他无法理解 X = X + 1 这样的代码，认为这是一种数学上的谎言，因为零不应该等于一。

学习编程的摸索

随后，作者在大学期间学习了 C 语言，并开始通过不断尝试、错误和修复来学习编程，经历了一个“Linux 格式化时代”，经常格式化自己的 Linux 系统。尽管他能够编写循环和递增计数器，但他仍然感觉缺少了什么。

关键问题

一次偶然的机会，一位桥牌搭档向他提出了一个问题：“如何不用循环计算 1 到 10 的和？”这个问题启发了作者，让他开始思考不同的编程方式。

Prolog 和递归

作者接触到了 Prolog 语言，并发现了递归的概念。递归让他意识到，编程不仅仅是逐步计算，而是可以描述事物之间的关系。这让他感到仿佛有人用他能理解的语言在与他对话。

与 Erlang 的相遇

在一次桥牌比赛的休息时间，作者与一位来自瑞典的选手交流，得知了 Erlang 语言。Erlang 是由瑞典 Ericsson 公司开发的，用于构建分布式、容错的电信系统，并且是函数式的，类似于 Prolog。

Ping 和 Pong 的魔力

作者尝试编写 Erlang 代码，并被其分布式特性所震惊。他展示了简单的 Ping 和 Pong 示例，两个独立的 Erlang 节点可以在不同的机器上通信，而无需 HTTP、REST API 或序列化。这展示了 Erlang 的函数式、分布式和容错特性。

Erlang 的哲学

Erlang 不仅仅是一种编程语言，更是一种哲学：

• 允许崩溃 (Let it crash)：不要试图处理所有错误。
• 进程廉价 (Processes are cheap)：可以创建数百万个进程。
• 不共享 (Share nothing)：隔离是安全的关键。
• 消息传递 (Message passing)：通过消息传递进行通信，避免耦合。

最终的声明

作者最终放弃了桥牌，全身心投入到 Erlang 编程中。他认为 Erlang 是一种优雅的编程语言，结合了函数式编程、分布式系统和容错性。

推荐观看

作者推荐观看名为 "Erlang: The Movie" 的视频，以了解 Erlang 的精神和魅力。

未来计划

作者计划在博客上分享他 30 多年来构建软件系统所学到的知识，包括 Erlang、Elixir、函数式编程、分布式系统等。他将继续分享经验和见解，帮助他人更好地理解这些技术。

LLM 抓取器防护：Anubis 是否真的有效？

这篇文章探讨了当前网站防护 LLM（大型语言模型）抓取器的方法，特别是 Anubis 的有效性。

主要问题：

• LLM 抓取器的攻击性增强： LLM 训练公司运营的抓取器变得越来越激进，无视 robots.txt，伪造 User Agent 和 IP 地址，甚至对小型网站发起 DDoS 攻击。Anthropic 的 ClaudeBot 是主要问题。
• Anubis 的流行： 越来越多的网站开始使用 Anubis，这是一种基于工作量证明的防御方案，要求访问者在访问网站前解决一个小型加密问题。
• Anubis 的缺陷： 文章指出 Anubis 实际上并不适用于防御 LLM 抓取器，因为它对 LLM 公司来说成本几乎为零。LLM 公司无需付出太多成本就能绕过 Anubis。
• Anubis 的局限性： Anubis 能够阻止抓取器，但仅仅是因为大多数 LLM 抓取器 不运行 JavaScript。
• 作者的解决方案： 作者分享了一段 12 行的 Caddyfile 配置，通过要求访问者运行 JavaScript 代码来设置一个 cookie，从而实现对抓取器的有效防护。 这种方法与 Anubis 同样有效，但对用户体验的影响更小。
• 临时性解决方案： 作者指出，无论是 Anubis 还是其他临时性解决方案，都无法从根本上解决问题，因为抓取器最终会学会绕过它们。华为的抓取器已经能够解决 Anubis 的挑战。
• Cloudflare 的重要性： 文章强调，Cloudflare 仍然是防御抓取器的最可靠方法，尽管其高级防护模式可能会对使用 VPN 的用户造成不便。

结论：

如果网站的主要目标是防御 ClaudeBot 等 LLM 抓取器，那么使用 Anubis 是一种过度且不必要的措施。作者建议使用更友好的替代方案，例如基于 JavaScript 的解决方案，或者直接使用 Cloudflare。Anubis 仍然可以作为 DDoS 防护的有效工具，但对于大多数网站来说，它并非最佳选择。

原文链接

捷克警方被迫关闭布拉格机场人脸识别系统总结

事件背景与系统关停

• 系统运行：捷克警方自2018年起在布拉格瓦茨拉夫·哈维尔机场使用实时人脸识别系统，将乘客面部特征转化为生物索引，并与通缉或失踪人员数据库进行比对。
• 系统关停：在面临长期批评和法律审查后，该系统最终于2025年8月被正式关闭。

法律争议与监管调查

• 违规指控：维权组织IuRe于2021年指出，在捷克处理生物识别数据必须基于特别法律的明确授权，并向捷克数据保护局（DPA）提出投诉。
• 调查确认：DPA历经近四年的调查，确认警方行为涉嫌违反个人数据保护法规。在漫长的调查期间，警方未采取有效的整改行动。

《人工智能法案》的直接影响

• 非法运行：欧盟《人工智能法案》（AI Act）中关于生物识别监控的条款于2025年2月生效，明确要求使用此类系统必须获得司法批准。
• 无视警告：由于未获得司法批准，机场人脸识别系统在2025年2月至8月期间的运行属于非法行为，尽管警方多次收到违法警告且媒体已介入关注。

其他生物识别工具的违规问题

• 数字个人图像信息系统：捷克警方使用的另一款生物识别工具同样存在违法情况。该系统包含约2000万张身份证或护照照片，可用于追溯未知身份人员（警方称用于识别死者，但也可能被用于识别示威者）。
• 监管确认：IuRe和DPA均已指出警方在使用该系统处理生物识别数据时违反了法律。

影响与后续行动

• 立法审查呼吁：事件暴露出警方在使用人脸识别工具上存在系统性问题。呼吁捷克新任内政部长审查现行国内立法，为处理生物识别数据制定明确且受公众监督的法律指南，以符合欧洲指令并防止技术滥用。
• 持续监督：在公众众筹资金和EDRi的支持下，IuRe将继续通过其信息平台监控捷克境内的生物识别监控情况。

djb关于使用Fil-C（新型内存安全C/C++编译器）的实践笔记，主要涵盖其性能表现、包管理器集成、编译配置及在Debian系统中的深度应用。

性能与兼容性

Fil-C具备极高的兼容性，多数库和应用无需修改即可编译。在加密软件的微基准测试中，Fil-C编译的代码性能损耗通常在1倍至4倍CPU周期之间。作者还提供了审计脚本以对比Fil-C与上游源码差异，以评估供应链安全。

包管理器集成

• Filian：作者开发的工具，用于在Debian系统上自动化适配、编译和安装Fil-C及选定的Debian源码包，取代了早期的手动脚本。
• Filnix：第三方工具，用于将Nix包适配为使用Fil-C编译，并支持通过Cachix缓存预编译的二进制包。

编译环境与自带组件

• 推荐在Debian 13环境下编译，需配置充足的Swap（如36GB）以防编译编译器时发生内存溢出。标准库推荐使用glibc，因部分软件（如attr、vim）不兼容musl。
• 作者编写了build-parallel.py脚本替代官方串行脚本，实现多核并行编译并忽略非致命错误。测试中成功编译了60/61个自带目标（包含bash、git、openssl、python等），仅libcap编译失败。

第三方软件编译

多数外部软件可通过微调成功编译。例如：Boost需修改源码以禁用vfork；libgc可用简单调用malloc的gcshim包替代；mutt、tig、w3m及Lua相关库（lpeg、luv）均能正常工作或仅需少量环境配置。

Debian多架构（Multiarch）集成

作者利用Debian的多架构特性，将Fil-C编译的包定义为新架构（如amd64fil0），实现与原生amd64包共存：

• 环境配置：通过修改cputable和config.sub注册新架构，并将Fil-C编译器及标准库部署至/usr/libexec/fil等系统独立目录。
• 构建适配：使用辅助脚本fillet处理符号表（.map/.symbols）和头文件安装路径，解决Fil-C符号混淆及Debian多架构头文件共享机制的冲突。
• 构建与验证：通过设置DEB_BUILD_OPTIONS=nostrip等参数，成功使用dpkg-buildpackage构建了tinycdb、ncurses、readline等Debian包。运行测试证实，安装后的Fil-C包能够正确触发运行时的内存安全拦截机制。

项目目的

本教程旨在指导读者学习C语言编程，内容从编写简单的命令行程序起步，逐步深入，最终带领读者综合应用所学知识开发一款回合制游戏。

内容结构

教程系统涵盖了C语言的核心知识点，共分为九个主要部分及额外的编程视频：

1. 编程入门：编码学习的总体概述。
2. C语言简介：涵盖预处理指令（如 #include, #define）、main() 函数、数据类型和运算符等基础语法。
3. 流程控制：条件分支与循环结构。
4. 函数：用户自定义函数、标准库函数的使用以及递归。
5. 数组与指针：固定大小数组、指针概念及可变大小数组。
6. 文件操作：文件的读取与写入。
7. 高级编程：动态内存分配（realloc）、行读取（getline），以及二进制处理和迭代简写等进阶技巧。
8. 控制台编程：使用 conio 库进行控制台交互开发。
9. 综合实践：结合前述知识，完整编写一款回合制游戏。

项目背景与支持

• 起源与赞助：该项目最初是 YouTube 上的视频系列，由 Patreon 平台上的支持者众筹资助。
• 赞助者权益：“C programming”级别及以上的 Patreon 赞助者享有专属特权，包括：提前观看视频、获取包含更多细节的独家编程指南、参与每周专属问答论坛，以及在视频系列完结后以成本价购买通过 Lulu 出版的配套实体/电子教程书籍。
• 致谢：作者特别感谢了众多个人赞助者及机构（如 Sparheld International GmbH、Hallmentum LLC 等）对该项目的支持。

版权许可

本项目内容采用知识共享署名 4.0 国际 (CC BY 4.0) 许可协议发布，允许在署名的前提下自由共享和演绎。

WiFi 7 调试之旅：从 400 Mbps 提升至 1.7 Gbps

背景与问题

作者将网络设备升级至 UniFi Dream Router 7 (UDR7) 并使用支持 WiFi 7 的 iPhone 17 Pro Max 进行测试。在 6 GHz、160 MHz 频宽下，预期速度应接近 1.9 Gbps，但实际 iperf3 测速仅约 400 Mbps（单流）至 650 Mbps（10并发流）。

排查过程与瓶颈发现

1. 测试目标错误（CPU 争用）：最初直接在路由器上运行 iperf 服务器，导致 WiFi 调度与 iperf 进程产生 CPU 争用，且路由器 TCP 协议栈未针对此优化。将服务器移至通过 2.5 GbE 连接的 MacBook 后，速度提升至 727 Mbps，但仍未达标。
2. 实际信道宽度降级（核心问题）：通过 UniFi 客户端详情发现，尽管 SSID 设置了 160 MHz，但 iPhone 实际连接在 80 MHz 频宽。其 1.20 Gbps 的 PHY 速率（2×2 MIMO 80 MHz 的理论值）解释了 650-900 Mbps 的实际 TCP 吞吐量。

解决方案

在 UDR7 的无线电设置（Devices → UDR7 → Radios → 6 GHz）中进行以下调整：

• 将信道宽度显式设置为 160 MHz（取消 Auto）。
• 将发射功率设置为 High。 调整后，PHY 速率达到 2.4-2.9 Gbps，iperf3 测速成功提升至 1.62 Gbps。

技术原理解析

iperf3 关键参数

• -R（反向模式）：AP 发射功率和天线更强，且 iOS 接收路径优化更好，手机仅需发送微小的 ACK 包，因此测速更高。
• -P 6（多并发流）：克服单流 TCP 的慢启动、拥塞窗口和套接字缓冲区限制，4-8 个流通常能达到峰值。
• -w 2M（TCP 窗口大小）：有助于处理突发流量。

2×2 客户端无法达到 2.5 Gbps 的原因

在 160 MHz WiFi 7 下，2×2 客户端的最高 PHY 速率约为 2.88 Gbps。扣除 MAC/PHY、IP/TCP 报头及加密等开销后，最佳 TCP 有效吞吐量（Goodput）通常仅为 PHY 速率的 60-75%（约 1.7-2.1 Gbps）。突破此限制需要 320 MHz 频宽（iPhone 不支持）、更多空间流或多链路操作（MLO）技术。

关键优化建议

1. 独立测速：不要直接对路由器测速，使用 ≥2.5 GbE 的独立设备作为服务器。
2. 核实信道宽度：以客户端详情面板显示的实际连接频宽为准，而非 SSID 设置。
3. 调整发射功率：测速时设为 High，日常使用建议 Auto/Medium 以避免上下行不平衡。
4. 优化测速命令：使用反向模式和多线程（如 iperf3 -c <server> -P 6 -R -t 20）。
5. 保持适当距离：测试时距离路由器 6-10 英尺，过近反而会降低信号质量。

LM8560 芯片技术与应用摘要

芯片概述

LM8560 是一款由日本三洋（Sanyo）研发的低功耗 MOS 逻辑集成电路。自 1980 年代问世以来，它被广泛应用于各类 LED 数字闹钟和时钟收音机中。该芯片极大地简化了电路设计并大幅降低了制造成本，是电子史上寿命最长、最经典的芯片之一。

工作原理与核心技术

• 交流电计频：LM8560 并非微控制器，也不依赖石英晶振。它通过直接计算交流电网频率（50Hz 或 60Hz）进行计时，出厂无需校准。
• 纯逻辑架构：作为由固定逻辑门和触发器组成的硬件芯片，它不含闪存，避免了微控制器常见的存储老化问题，具有极长的使用寿命。
• 停电备用系统：内置电源备份逻辑，断电时自动切换至 9V 电池供电，并利用外部 RC 振荡器维持基本计时。

显示技术与硬件局限

• 双工显示屏（Duplex Display）：为减少引脚数量，LM8560 采用定制的双工 LED 屏，利用交流电的正负半波交替点亮两组 LED 段。此设计降低了工业制造成本，但因无法使用标准共阴极 7 段数码管，限制了电子爱好者的 DIY 扩展。
• 电网依赖性：若接入频率不稳定的电源（如发电机或 UPS），会导致严重的时间偏差。此外，若输入端缺乏滤波，电网杂波易被误计为时钟脉冲，导致走时过快。

隐藏功能与操作缺陷

• 隐藏功能：芯片内置未公开的组合键功能，如通过特定按键组合可显示秒数、将秒数清零或暂停时间，便于进行高精度对时。
• 操作缺陷：受限于常见的按键矩阵布线设计，在设置闹钟或睡眠定时器时，若按键接触不良，极易意外修改当前系统时间，导致次日闹钟误响。

历史影响与现代对比

LM8560 的普及使数字闹钟从昂贵的设备变为大众消费品。现代廉价闹钟多采用微控制器、石英晶振和 SDR 收音技术，虽走时不受电网影响且功能更多，但普遍存在元器件质量差、设计寿命短（计划性报废）等问题。相比之下，LM8560 凭借纯粹的硬件逻辑和极高的可靠性，至今仍被部分厂商生产。对于需要自行搭建时钟的 DIY 爱好者，通常推荐使用支持标准数码管的替代芯片（如 LM8365）。

本文档展示了 mock（一款 API 创建与测试工具）的多个应用示例（需全局安装该工具）。主要示例及其关键功能如下：

1. “Whois” 查询服务

• 目的：提供域名信息查询。
• 功能：通过查询参数获取域名并执行 whois 命令。若未提供参数，则动态返回一个 HTML 表单页面供用户输入域名。

2. YouTube 下载 Web 服务

• 目的：提供视频下载接口。
• 功能：从路由参数提取视频 ID，使用 yt-dlp 将视频下载至临时目录，并设置 Content-Disposition 响应头以附件形式返回文件。

3. 多语言驱动的 API

• 目的：在单一服务中运行不同编程语言的代码。
• 功能：配置 /js、/python、/php 等路由，分别通过 HereDoc 语法执行 Node.js、Python 和 PHP 代码片段并返回标准输出。

4. 有状态的 API

• 目的：实现跨请求的状态记录。
• 功能：利用临时文件存储计数器，每次访问 /hello 路由时，读取文件内容、递增计数并返回当前的累计请求次数。

5. 带简单数据存储的 CRUD API

• 目的：实现基础的用户数据增查（依赖 jq 工具解析）。
• 功能：
  • POST /user：解析请求负载，生成自增 ID，将用户信息存为独立的 JSON 文件并返回新 ID。
  • GET /user/{user_id}：根据路由参数中的 ID 读取并返回对应用户的 JSON 数据，若文件不存在则返回 400 状态码。
  • GET /users：读取数据目录下所有 JSON 文件，聚合并返回完整的用户列表。

6. 延迟特定端点

• 目的：模拟和控制 API 的响应延迟。
• 功能：使用 --delay 参数可使整个 API 响应变慢；若结合 --middleware（中间件）与环境变量条件判断，可仅对特定端点（如 some/endpoint）注入 sleep 延迟，其余端点则作为代理正常即时响应。

“现代” Emacs 入门指南与社区建议总结

本文总结了 Hacker News 社区关于如何入门“现代” Emacs 的讨论，主要涵盖起步策略、核心插件栈、学习资源以及使用习惯等方面的建议。

1. 起步策略：原生 (Vanilla) vs. 预配置发行版

• 原生 Emacs (Vanilla)：多数资深用户建议从原生 Emacs 开始。这有助于理解 Emacs 的核心概念（Buffer、Window、Frame）及其作为 Lisp 环境的本质。推荐以 Bedrock 或 minimal-emacs 为起点，它们仅优化默认设置并提供精选的现代插件，避免了过度封装的“魔法”，便于后期排错和深度定制。
• 预配置发行版 (Doom / Spacemacs)：适合希望快速获得完整 IDE 体验或从 Vim/Neovim 迁移的用户。Doom Emacs 提供了开箱即用的美观界面、性能优化和 Vim 键位支持，但其高度封装可能会阻碍新手理解底层运行机制。

2. “现代”核心插件栈

现代 Emacs 的交互体验已通过新一代插件得到极大提升，社区推荐的“现代标准”组合包括：

• 补全与搜索框架：取代老旧的 Helm/Ivy，推荐 Vertico（垂直候选列表）、Consult（搜索与导航）、Marginalia（候选项注释）、Orderless（无序模糊匹配）和 Embark（上下文操作菜单）。代码补全推荐 Corfu。
• 开发与项目管理：Magit（Git 交互界面）、Project.el 或 Projectile（项目管理）、Eglot（内置 LSP 客户端）或 lsp-mode（支持 DAP 调试）。
• 编辑体验：Evil（Vim 模态编辑）或 Meow（类 Kakoune 模态编辑）、Treesitter（语法高亮）、Which-key（快捷键提示）。

3. 学习资源与社区

• 官方文档：Emacs 内置的 Info 手册和 Elisp 手册是最权威的指南，熟练掌握帮助系统（如 C-h f, C-h k）至关重要。
• 视频与博客：推荐 System Crafters 的“Emacs from Scratch”系列、Protesilaos Stavrou 的深度视频，以及阅读《Mastering Emacs》和 Sacha Chua 的 Emacs News。

4. 运行环境与人体工学

• 终端 vs. GUI：许多用户偏好在终端（结合 Tmux/SSH）中运行 Emacs（emacs -nw），认为其足以应对开发且利于远程工作；GUI 版本则在渲染图片、LaTeX 和自定义字体方面更具优势。macOS 用户推荐使用 emacs-plus。
• 预防“Emacs 小指”：为缓解频繁使用组合键带来的手部疲劳，建议将 Caps Lock 映射为 Ctrl（或短按 Esc/长按 Ctrl），使用模态编辑插件减少组合键，或借助 devil-mode 及人体工学键盘优化键位。

文章标题

Meta准备发行250亿美元债券，因人工智能成本飙升引发股票抛售（Meta readies $25B bond sale as soaring AI costs trigger stock sell-off）。

内容概述

提供的文本未包含文章的实际报道细节，而是《金融时报》（Financial Times）的付费墙（Paywall）及订阅推广页面。文本的核心要点如下：

• 新闻背景提示：仅从标题可知，Meta计划发行250亿美元规模的债券，其背景是人工智能（AI）相关成本的大幅上升引发了股票抛售。
• 付费订阅方案：页面展示了多种订阅选项以引导读者解锁全文，具体包括：
  • 限时试用：首4周仅需1美元即可无限访问，试用结束后为每月75美元，支持随时取消。
  • 标准数字版（Standard Digital）：每月45美元，提供 essentials 级别的设备端数字访问权限（年付可节省20%）。
  • 高级数字版（Premium Digital）：每月75美元，提供完整的数字访问权限以及行业领袖的专家分析（年付可节省20%）。
  • 高级数字+周末印刷版（Premium & FT Weekend Print）：每月79美元，包含每周六配送的《FT Weekend》实体报纸及完整的数字访问权限。
• 其他引导信息：页面还提供了探索所在地区全部订阅计划、企业级数字访问权限，以及了解为何有超百万读者选择付费阅读《金融时报》的相关链接。

年度最佳科幻创意 (The Year's Best SciFi Ideas)

• 《DEATH AND THE GORGON》：一部谋杀悬疑小说，巧妙讽刺了过度狂热的AI预测和荒谬的长期主义立场，以令人耳目一新的方式将关注点重新拉回当下。
• 《THE BEST VERSION OF YOURSELF》（作者：GRANT COLLIER）：探讨了一家公司出售纳米机器人以优化人类大脑、实现完美幸福的设定，引发读者思考这究竟是反乌托邦还是功利主义乌托邦。
• 《A GRAY MAGIC》（作者：RAY NAYLER）：讲述了一位处于困境中的绝症患者的故事，展现技术辅助的微小思维转变虽无法彻底扭转绝境，但能有效缓解痛苦。
• 《WHY DON'T WE JUST KILL THE KID IN THE OMELAS HOLE》（作者：ISABEL J. KIM）：对厄休拉·勒古恩的经典名篇《离开奥梅拉斯的人》进行了幽默而深刻的回应与解构。
• 《BREATHING CONSTELLATIONS》（作者：RICH LARSON）：描绘了人类首次利用技术去理解非人类文化规范的探索过程。
• 《THE LARK ASCENDING》（作者：ELEANNA CASTROIANNI）：当国家抹除一名异见人士的存在时，家用AI助手成为其禁忌记忆的唯一保管者。故事聚焦于AI如何在保护年幼主人的同时妥善处理这些记忆。
• 《STARS DON'T DREAM》（作者：CHI HUI）：从一场看似不可能完成的冒险，升华为对“传承”的沉思，赞美了追求那些“在有生之年无法看到结果”的变革性项目的勇气。
• 《BEST PRACTICES FOR SAFE ASTEROID HANDLING》（作者：DAVID W. GOODMAN）：展现了一个依靠增强彼此共情来凝聚的太空航行文化，并探讨了政治狂热分子可能将其摧毁的潜在危机。
• 《MONEY, WEALTH, and SOIL》（作者：LANCE ROBINSON）：将极近未来技术（甚至当今可实现的技术）应用于土壤恢复工作，同时毫不避讳地直面所有官僚机构都必须应对的复杂的“委托-代理”问题。

A Response to Yudkowsky and Soares from the Front Lines of AGI Development

本文探讨了第二代微型计算机如何从爱好者的玩具演变为具有实际商业与家庭价值的工具，其核心驱动力是第三方应用软件的繁荣。

市场定位与早期营销

1970年代末，制造商试图将电脑包装为家庭助手，并借“信息时代”的文化符号进行营销。但早期的 Apple II、Commodore PET 和 TRS-80 对普通用户缺乏现成的实用功能，且早期广告多假设用户愿意自行编程。随着市场发展，“家用电脑”（Home Computer）一词逐渐演变为廉价游戏机的代名词。

软件生态的商业化

大多数非爱好者用户需要现成软件而非自行编程，这促使大量第三方开发者涌现，软件市场从早期的免费共享文化转向商业化收费。最畅销的软件分为两类：用于创建数字工作产物的商业软件，以及用于娱乐的游戏软件。

文字处理器的演进

文字处理器是早期关键商业应用之一：

• Electric Pencil：首款微型电脑文字处理器，初衷为简化程序文档编写。因缺乏硬件标准协议，需为不同外设编写大量定制版本。
• EasyWriter：Apple II 平台上流行的早期同类产品。
• WordStar：MicroPro 推出的商业级软件，采用模块化设计，支持“所见即所得”（WYSIWYG）和屏幕菜单。摩尔定律带来的内存价格大幅下降，为此类复杂软件的普及奠定了基础。

VisiCalc 与商业计算革命

1979年推出的 VisiCalc 是首款革命性电子表格软件，首发于 Apple II 平台（得益于其出色的图形能力和较大内存）。

• 核心功能：实现了交互式实时计算，允许用户在网格中进行“What if”（假设分析）建模，修改输入后瞬间更新全局相关数据。
• 市场影响：深受财务专家、企业高管和小企业主欢迎，使 Apple II 成为商业办公必备设备，直接推动了苹果公司的销量暴涨与成功 IPO。

产业格局的成熟

至1980年，个人电脑已发展出包含软硬件制造、出版与零售的庞大且高度竞争的生态系统。市场明确分化为两类：以 Apple II 为代表、配备大内存和磁盘驱动器的高端商业电脑；以及以 Commodore 为主、主打低价和娱乐功能的家用游戏电脑。

网页状态与内容概述

• 来源与标题：该页面来自白宫官方网站（Whitehouse.gov），原页面标题为“MySafeSpace”。
• 当前状态：页面显示“404 Page Not Found”（404 页面未找到）错误，表明该网页当前无法访问或已被移除。
• 页面提示：系统提示该网站“暂时已完成其使命”（This site has served its purpose…for now）。
• 附加指引：页面提供了一个阅读链接，引导访问者了解关于“民主党人历史性的政府停摆”（the Democrats’ historic shutdown）的相关背景信息。

Python 内存分配频率及优化机制分析

核心结论

CPython 在运行过程中非常频繁地进行内存分配操作。尽管基础算术运算理论上只需单条 CPU 指令，但 Python 通过多种内存管理和对象复用机制，有效摊销并降低了实际分配的系统开销。

实验现象

通过修改 CPython 源码监控 PyLongObject（整数对象）的分配，作者发现：

• 在包含 print() 的 10 万次循环中，发生了约 10 万次分配，主要因为 print 在类型转换时创建了临时对象。
• 在仅包含加法（a = i + 1）的循环中，分配次数骤降至 905 次，表明 CPython 对基础加法进行了避免重复分配的优化。

整数分配优化策略

CPython 针对整数对象采用了以下优化机制：

1. 小整数缓存：值在 -5 到 1025 之间的整数直接引用预分配的全局数组，无需进行堆分配。
2. FreeList（空闲链表）复用：对于 32 位以内的中等整数，CPython 优先从 FreeList 中获取已释放的 PyLongObject 进行复用。实验表明，10 万次加法循环中，99% 以上的对象是通过 FreeList 复用的，极少触发真正的内存分配。

底层内存分配器 (pymalloc)

为了进一步降低分配成本，CPython 使用了自定义的基于池（Pool）的内存分配器：

• 固定大小分块：将内存池划分为固定大小的块，结合 FreeList 实现极速分配与释放，避免传统 malloc 的复杂计算和内存碎片。
• Arena 预分配：底层通过 Arena（1MB 或 256KB）使用 mmap 预先保留虚拟内存，物理内存仅在发生缺页中断时按需分配。

局限性与反思

• 缺乏指针标记（Tagged Pointer）优化：与 V8 或 LuaJIT 等引擎不同，CPython 未对常规整数采用指针标记技术（将整数值直接编码在指针中），导致常规整数仍需堆分配，增加了基础运算的开销。
• 大小整数兼容代价：PyLongObject 的设计旨在同时支持常规整数和超大整数，这种通用性导致处理常规整数的“快路径”受到了处理大整数“慢路径”的拖累。

扩展对比

文章最后对比了 Zig 语言的设计，赞赏其 std.mem.Allocator 接口允许显式传递和替换分配器，使内存分配行为更加透明和可控，从而避免了“隐式分配”带来的性能黑盒。

文章访问异常提示

本文标题为“FFmpeg dealing with a security researcher”（FFmpeg与安全研究员打交道），但实际文章内容未能成功加载。

页面仅显示了一个来自 x.com 的错误提示，主要包含以下信息：

• 加载失败：页面出现错误，建议重新尝试。
• 原因分析：某些与隐私保护相关的浏览器扩展插件可能会导致 x.com 出现加载或兼容性问题。
• 解决建议：建议用户暂时禁用相关的隐私扩展插件后再次尝试访问。

由于正文内容缺失，无法提供关于 FFmpeg 与安全研究员互动的具体技术或事件细节。

Crossfire：Rust 高性能无锁通道库

项目概述

Crossfire 是一个专为 Rust 设计的高性能无锁通道库，支持单生产者单消费者（SPSC）、多生产者单消费者（MPSC）和多生产者多消费者（MPMC）模式。其算法派生自 crossbeam 并进行了深度优化，旨在弥合异步与阻塞上下文之间的鸿沟，提供卓越的并发处理能力。

核心特性与性能优化

• 无锁与高性能：凭借无锁设计和轻量级通知机制，Crossfire 在异步和阻塞上下文中的性能均优于同类通道及原版 crossbeam-channel。
• 平台自适应优化：无锁算法依赖自旋，对单核系统（如 VPS）不够友好。库内提供 detect_backoff_cfg() 函数，在初始化时调用可自动检测平台并调整退避策略，使 VPS 环境性能提升 2 倍。
• 架构演进：v3.0 版本重构了 API，移除了 crossbeam-channel 依赖（改用 crossbeam-queue），消除了枚举分发成本，使异步性能进一步提升 33%，并针对特定通道（如 Bounded SPSC/MPSC）进行了大幅专项优化。

API 结构与并发模块

• 并发模型：提供 spsc、mpsc、mpmc 模块，底层实现针对各自模型优化。SP/SC 接口专为非并发操作设计，减少了原子操作开销并提升了 waker 注册的内存效率。此外还包括 oneshot（一次性通道）、select（多路复用与类型擦除 API）和高性能 waitgroup。
• 队列风格 (Flavors)：包括 List（基于 SegQueue）、Array（基于 ArrayQueue）、One（针对容量为 1 的场景并发优化）以及 Null（仅用于关闭唤醒的取消通道）。
• 上下文桥接：支持 Blocking 和 Async 两种上下文，发送端和接收端可通过 From trait 在两者间无缝转换。SP/SC 类型的通道不可 Clone 且非 Sync，以确保完全无锁。

异步兼容性与安全性

• 运行时无关：兼容 tokio、async-std、smol 等主流异步运行时。
• 取消安全 (Cancellation-safe)：send() 和 recv() 操作在异步上下文中是取消安全的。结合 select! 或 timeout 使用时，能正确清理 waker 状态，防止内存泄漏和死锁。
• 原子超时操作：启用对应运行时的 feature 后，提供 send_timeout() 和 recv_timeout()，确保超时结果的原子性并安全返回未发送的消息。

测试状态与调试支持

• 跨平台测试：在 x86_64 和 ARM 架构下，针对多种运行时进行了严格的 CI 测试，整体状态稳定（注：ARM 架构下的 tokio 建议升级至 1.48 以上版本以修复潜在问题）。
• 死锁调试：提供 trace_log feature flag，可在本地测试或基准测试中开启内部日志，结合中断信号导出日志文件，方便排查死锁等复杂并发问题。

Data centers contribute to higher prices as fat energy bills electrify local politics

背景与挑战

随着AI代理逐渐代替人类执行网络任务，来自AI平台的流量将激增。传统的安全工具（如基于IP和指纹的速率限制或封禁）过于粗糙，容易误伤同平台的诚实用户，且在AI代理环境下指纹识别易失效并存在隐私风险。

核心解决方案：匿名凭证（AC）

为在不识别或追踪用户的前提下实施细粒度安全策略（如限速和封禁），文章提出使用匿名凭证（AC）。相比现有的Privacy Pass协议（基于盲签名或VOPRF），AC解决了通信成本线性增长、无法跨源绑定（late origin-binding）及令牌发放后无法撤销等局限。

关键技术与AC方案

AC的核心构建模块包括代数MAC（支持同态盲化）和零知识证明（ZKP）（用于证明范围或线性关系而不泄露秘密）。文章重点介绍了两种正在IETF讨论的方案：

• ACT（匿名信用令牌）：具备状态管理机制。每次兑换时，服务器验证并更新计数器（余额）后重新发放凭证，适用于动态限速和基于多请求行为模式的攻击撤销。
• ARC（匿名限速凭证）：支持多次并行展示和后期源绑定。其发放成本呈亚线性，通信效率极高，但缺乏原生的撤销机制。

性能评估

测试表明，虽然AC的展示/兑换成本略高于传统方案，但其发放成本显著降低。由于凭证发放仅需进行一次，在需要多次访问的场景中，AC的整体计算与通信效率更具优势。

代理管理与实践演示

为全面管理AI代理，文章建议结合ARC和ACT的优势：利用ARC进行高效的初步限制，并结合ACT的状态管理来实现细粒度的信用扣减和凭证撤销。此外，文章提供了一个基于模型上下文协议（MCP） 的演示，展示了如何通过MCP工具发放和兑换ACT凭证，相关Rust和浏览器端代码均已开源。

未来展望

目前ACT和ARC仅支持私有验证（发行方与源站需共享私钥）。未来计划引入基于配对的密码学（如BBS签名）以实现公开验证，并探索抗量子计算方案。Cloudflare正积极参与IETF和W3C的标准制定，推动匿名凭证在开放网络中的实际部署。