Valve宣布了一项新政策，要求Steam上的游戏必须在商店页面上明确披露所使用的内核级反作弊系统。这一变更旨在提高透明度，满足开发者和玩家对反作弊信息共享的需求。开发者，无论是现有游戏还是新发布游戏，都需要遵守此规定，Valve将进行检查以确保通知的准确性。

具体来说：

• 强制披露范围：只有内核级反作弊是强制披露的；客户端或服务器端的反作弊技术则可选，但Valve建议开发者最好也披露任何反作弊技术。
• 目的：增强玩家知情权，帮助用户了解游戏的安全措施，并对使用Proton的Steam Deck或Linux用户特别有用，因为内核级反作弊游戏通常无法在Proton上运行。
• 额外细节：一些旧游戏在卸载时可能不会完全移除反作弊软件，Valve也会在商店页面上标注这一情况。
• 其他更新：文章提到Valve最近的其他Steam改进，如处理发布者横幅垃圾邮件、改进原生Linux游戏支持、在购买时明确许可证性质以及移除个别仲裁要求。

这一政策有助于玩家做出更明智的选择，并推动Steam平台的透明度。

Zed 编辑器 SSH 远程开发功能

Zed 编辑器新增 SSH 远程开发功能，允许用户通过 SSH 连接到远程服务器进行项目开发。该功能旨在解决本地开发大型代码库时的性能瓶颈（如高负载、内存不足、编译缓慢），同时保持界面操作的流畅性。

核心工作方式

• 本地界面，远程计算：图形界面在本地运行以确保高帧率（120 FPS），而语言服务器、任务执行和终端等后台操作均在远程服务器上运行，充分利用云端硬件资源。
• 灵活的连接方式：
  • 一次性项目可通过命令直接打开，例如：zed ssh://my-host/~/code/zed
  • 支持配置持久连接以适应长期开发需求。

技术实现要点

1. 连接维护：使用 SSH 的 ControlMaster 设置保持单一连接，避免频繁输入密码或重新认证。
2. 远程服务器部署：
   • 自动下载与远程系统匹配的预编译服务器（使用 musl 编译，无需动态链接），确保在旧版 Linux 发行版和类似 Nix 的无共享环境中兼容运行。
3. 稳定性保障：
   • 远程服务器作为守护进程运行，在连接中断后保持运行，重新连接时语言服务器无需重新初始化。
   • 本地会备份未保存的更改，防止工作丢失。
4. 协作功能适配：重构项目同步逻辑，支持最多四个节点（两位协作者通过 SSH 连接）的协作场景。协作过程中，项目位置（本地或远程）对协作者完全透明。

使用与反馈

该功能已正式发布，用户可立即体验。相关文档和更详细的配置说明可在官方文档中查阅。团队欢迎通过 GitHub Issues 或 Discord 提供反馈。

环保讽刺网站遭能源公司威胁，法律专家指出仿作非商标侵权

事件背景

环保组织“谦逊提案”为揭露液化天然气行业危害，创建名为“Repaer”的虚假公司网站。该网站通过黑色幽默方式，讽刺能源公司可购买“生命补偿”来抵消其活动导致的人类死亡，并宣传“血浆伙伴”计划鼓励家长为富人捐赠儿童血浆。网站还列出了三家真实液化天然气公司的标识作为“合作伙伴”。

法律威胁与应对

两家真实能源公司（道达尔能源和Equinor）发现后威胁采取法律行动，要求删除其标识。道达尔能源更向网站托管商Netlify施压，导致网站被下线。环保组织获得电子前沿基金会法律支持，随后向两家公司发出解释信，强调该网站属非商业性讽刺创作，不会造成消费者混淆，商标法旨在保护消费者而非压制批评。同时向Netlify发出反通知，要求恢复网站。

法律程序困境

尽管案件本质属商标争议而非版权问题，Netlify仍要求完成数字千年版权法案（DMCA）全套反通知程序，包括10个工作日等待期。环保组织最终选择将网站迁移至其他托管商。

行业行为模式

电子前沿基金会指出，此类案件反映了能源行业长期利用法律手段打压环保异见的模式。当权利方意识到恐吓策略无效后，通常会悄然撤退但不愿承认错误。基金会通过个案代理及支持联邦反战略诉讼立法等方式，长期应对此类行为。

当前状态

网站已在新平台恢复运行，涉事能源公司未再采取进一步行动，但受害者在面对虚假法律主张时仍缺乏足够法律确定性保障。

引力子检测新提案引发量子引力实验与理论争议

新检测方案的突破性

传统观点认为检测引力子（传递引力的假想粒子）几乎不可能。弗里曼·戴森曾估算，使用与地球同等大小的探测器围绕太阳运行，约十亿年才能捕获一个引力子。然而，一项结合引力波物理与量子技术的新提案彻底改变了这一认知。

由伊戈尔·皮科夫斯基等人提出的方案原理如下：

1. 设备核心：将一块约15公斤的铍棒冷却至接近绝对零度，使其所有原子协同作用，形成一个处于最低能量“基态”的宏观量子系统。
2. 探测机制：当LIGO探测到来自中子星合并的特定引力波时，该引力波中包含海量引力子。计算表明，约三分之一的此类事件可使铍棒获得一个量子化的能量单位（声子），产生可测量的量子跃迁。
3. 可行性：虽然仍是重大工程挑战（需将宏观物体置于基态并感知其量子跃迁），但实验规模已可控制在实验室与数十年时间尺度内。ETH苏黎世团队已在16微克蓝宝石晶体上实现量子态操控，证明了技术方向的可行性。

物理意义与解释争议

该实验若成功，可视为引力与量子力学结合的首个窗口，但其物理解读存在重大分歧：

• 支持量子引力观点：多数物理学家认为，若实验观测到能量量子化跃迁，结合能量守恒定律（铍棒获得一个量子能量，则引力波必须损失一个量子能量），强烈暗示引力波本身是量子化的。诺贝尔奖得主弗兰克·维尔切克认为，这应将引力子存在的证据提升至与1905年光子假说相当的水平。
• 质疑与替代解释：以丹尼尔·卡尼为代表的理论物理学家指出，该实验无法排除“半经典理论”——即引力波保持经典波特性，仅与量子化的物质相互作用。他们援引光子历史教训，认为仅靠此实验不足以“决定性证明”引力子的存在，可能需要更严格的检验（如测量量子叠加或纠缠）来关闭所有理论漏洞。

历史类比：从光子到引力子的论战

文章回顾了光子证实的历史脉络，以类比当前争议：

• 早期争论（1905-1920s）：爱因斯坦基于光电效应提出光量子化，但玻尔等人坚持用半经典理论（经典光场与量子化物质作用）解释，争论持续数十年。
• 决定性证据（1970s）：通过量子光学实验（如光子反聚束效应），最终排除所有半经典理论，确立光子物理实体地位。
• 当前启示：引力子检测可能处于类似“光电效应初期”，实验结果将开启长期论战，而后续实验（如验证引力量子叠加）可能成为关闭理论漏洞的关键。

实验价值与未来展望

尽管存在理论争议，该提案被广泛认为是量子引力实验时代的开端：

• 里程碑意义：首次提供引力量子效应的可检验方案，将实验状态推进至类似光子研究的1905年阶段。
• 技术催化：可能推动量子传感与宏观量子效应技术发展，为后续更精密实验（如量子引力波干涉仪）奠定基础。
• 理论推动：无论最终解释如何，实验结果必将为量子引力理论提供关键约束数据。

当前，物理学家已就两点达成共识：一是引力波触发的量子事件检测在技术上可行；二是该事件本身不等同于引力子直接探测。新提案如同抛出的首枚实验标石，标志着一场可能持续数十年的“引力子论战”正式拉开序幕。

Claude for Desktop 摘要

Claude for Desktop 是一个集成应用，提供聊天、Claude Cowork 和 Claude Code 功能，适用于桌面和移动设备。以下是主要特点和功能：

核心功能整合

• 桌面应用：整合了所有Claude功能，可处理文件和应用程序，支持快速访问和桌面扩展，连接本地工具和文件。
• 移动应用：允许用户随时随地使用Claude，可与桌面应用配对，实现任务共享和远程控制。
• Claude Cowork：功能让Claude在多个应用中工作，支持从手机分配任务到桌面环境。
• Claude Code：环境支持构建、调试和部署代码，直接在桌面应用中运行，可预览服务器、审查代码更改和监控拉取请求。

跨设备同步与协作

• 记忆同步：Claude的记忆功能跨设备同步，包括手机、桌面和网络，确保工作连续性。
• 任务分配：通过配对桌面和移动应用，用户可以从手机分享任务到桌面的Cowork，或使用Remote Control功能发送任务到Claude Code CLI。
• 工作流程：工作可在不同设备间无缝移动，例如从CLI对话到桌面应用，或从网络到手机，支持“在此处开始思考，随处完成”。

集成与扩展

• 连接器：允许Claude与外部工具集成，如Google Drive和Slack等Web应用，以及移动特定应用如Maps和iMessage。
• 桌面扩展：本地安装的扩展，提供对本地文件系统、浏览器和原生应用的访问，包括Claude in Chrome功能，可在浏览器中导航、点击和填写表单。

使用场景与限制

• 运行要求：Claude Cowork仅在桌面应用中运行，但可从手机分配任务；桌面应用必须运行才能完成任务，若计算机休眠则无法工作。
• 企业支持：桌面应用支持企业部署，提供MSIX（Windows）和PKG（Mac）安装器，允许版本控制、SSO认证和扩展预批准。

计划兼容性

• Claude应用适用于所有计划类型，包括Free、Pro、Max、Team和Enterprise，但某些高级功能（如特定扩展或集成）仅限于付费计划。

谷歌网络创作者活动摘要

活动背景

• 时间地点：2024年10月29日，谷歌加州山景城总部。
• 参与者：20名受谷歌近年来“残酷更新”影响、遭到“影子封禁”的独立网站所有者，以及谷歌工程师、管理层（包括首席搜索科学家）。
• 活动氛围：作者以“葬礼”隐喻整体基调——谷歌园区空旷冷清，建筑内人员稀少，会场布置简陋（折叠桌椅），全程氛围压抑且缺乏实质性对话。

关键环节与冲突

1. 开场与安抚：主持人丹尼·沙利文（作者称其为谷歌内仍热心但无实权的员工）保证受邀者网站“无问题”，但未说明活动具体目的。
2. 信息榨取：上午谷歌通过提问收集创作者意见以改进搜索引擎，但对创作者提出的核心问题（如大品牌特权、网站整体降权）避而不答。
3. 小组讨论受阻：在分组讨论中，创作者反复提出“搜索结果多样性”问题，但谷歌代表刻意回避，甚至用白板写字暗示转移话题。部分谷歌员工甚至不了解YouTube等基础产品。
4. 高层回应引发矛盾：
   • 谷歌首席搜索科学家否认存在“网站整体降权”，坚称仅对“单个页面”进行调整，与创作者实际遭遇的整站流量暴跌直接矛盾。
   • 当被问及恢复方法时，对方冷漠回应“会有更新但不知何时”，并称“不是你们的问题，是我们的问题”。
5. 内容矛盾：谷歌季度财报电话会中大肆宣传用AI抓取网站内容，但活动中的谷歌代表却淡化AI对搜索结果的影响。

活动本质与结论

• 单向索取：谷歌主要目的是收集数据以优化自身产品，而非解决创作者困境。
• 漠视问题：对创作者生存危机缺乏同理心，关键问题均被回避或否认。
• 隐喻转变：作者最终意识到，这场活动并非为创作者举行的“葬礼”，而是象征谷歌自身衰落与空洞的“葬礼”——园区人迹罕至、员工敷衍、与创作者脱节。
• 个人感慨：作者对主持人丹尼·沙利文表示同情，担忧其将孤独留守在“空荡腐朽的谷歌棺材”中。

整体评价

活动揭露了谷歌与独立创作者之间的深刻矛盾：谷歌在搜索领域占据主导地位，但其更新机制对小站点造成毁灭性打击，且缺乏透明沟通。活动形式化严重，未解决任何实质问题，反而加深了创作者对谷歌的失望与不信任。

概率生成函数是一种将离散概率分布表示为多项式函数的方法，其核心概念源于在向量理论出现前处理数字序列的需求。

核心概念与起源

• 历史背景：在向量被发明之前（18世纪），数学家如德·莫维尔需要将一组数字（如概率序列）作为一个整体处理。他们采用多项式函数，以数字作为系数来编码序列。
• 生成函数：序列 ([a_0, a_1, a_2, \dots]) 可被表示为生成函数 (f(x) = a_0 + a_1x + a_2x^2 + \dots)。通过微积分操作（求导与在零点取值），可从函数中提取任一系数。
• 概率生成函数：当生成函数的系数是概率时，该函数即为概率生成函数。它用于编码离散随机变量的概率分布。

表示与示例

• 一般形式：对于取非负整数值的随机变量 (X)，其概率生成函数为 (G(t) = \sum_{k=0}^{\infty} P(X=k) t^k)。变量 (t) 通常不赋予具体数值，仅为保持多项式结构。
• 公平硬币：(G(t) = 0.5t^0 + 0.5t^1)。
• 有偏硬币（正面概率 (p)）：(G(t) = (1-p)t^0 + p t^1 = (1-p) + p t)。
• 几何分布（首次成功前的失败次数，成功概率 (p)）：其概率序列为 ([p, (1-p)p, (1-p)^2p, \dots])，对应的概率生成函数为 (G(t) = \frac{p}{1 - (1-p)t})，这是一个通过幂级数求和得到的紧凑闭式表达。

重要性质

概率生成函数 (G(t)) 具有以下实用性质：

1. 归一化：(G(1) = \sum P(X=k) = 1)。
2. 期望：(G'(1) = E[X])。
3. 与方差相关：(G''(1) = E[X(X-1)])，可用于计算方差 (Var(X) = G''(1) + G'(1) - [G'(1)]^2)。
4. 卷积：独立随机变量和的概率生成函数是它们各自概率生成函数的乘积。
5. 随机求和：若随机变量 (N) 的概率生成函数为 (F)，且给定 (N)，独立同分布随机变量 (X_i) 的概率生成函数为 (G)，则随机和 (S = \sum_{i=1}^N X_i) 的概率生成函数为复合函数 (F(G(t)))。此性质有助于解决如“点数问题”等实际问题。

推广至特征函数

• 将参数 (t) 替换为复数单位圆上的点 (e^{iu})（其中 (u) 为实数），概率生成函数即变为特征函数 (\phi(u) = G(e^{iu}) = E[e^{iuX}])。
• 特征函数始终存在，且对于分析独立随机变量之和、中心极限定理的证明等具有关键作用。它可被视为将概率分布“缠绕”在复平面单位圆上后，求得的质心位置。

GenAIScript 是一款用于对大型语言模型进行编程的脚本工具。其核心理念是将提示（Prompting）视为编码，允许用户使用 JavaScript 或 TypeScript 以编程方式组装提示词，从而编排 LLM、工具和数据。

核心功能与特点：

1. 脚本语法与集成：

   • 提供简化的 JavaScript 模板语法（如 $ 函数）来构建提示。
   • 拥有 VS Code 扩展和命令行界面，并深度集成 GitHub Copilot、GitHub Models、OpenAI、Azure OpenAI、Anthropic 等多种模型服务。
   • 支持本地模型（如通过 Ollama 运行的 Phi-3）。

2. 强大的数据处理能力：

   • 能够方便地读取、转换和包含多种格式的文件内容（如 PDF、DOCX、CSV、XLSX）到提示中。
   • 支持图像、视频和音频的处理，例如提取视频帧、图像裁剪调整、语音转录。
   • 内置 RAG（检索增强生成）功能，支持向量搜索（本地或 Azure AI Search）。

3. 工具与代理（Agent）系统：

   • 允许将 JavaScript 函数注册为 LLM 工具，供模型调用。
   • 支持模型上下文协议（MCP），既能作为 MCP 客户端使用外部工具，也能将自身脚本暴露为 MCP 工具。
   • 可以定义和使用内置或自定义的“代理”，这些代理能结合工具和提示来完成复杂任务（如 Git 操作、代码解释、网络搜索）。

4. 开发与运维特性：

   • 脚本即文件，便于版本控制、共享和复用。
   • 支持定义数据模式（Schema）用于结构化数据的提取、验证和修复。
   • 可以从 LLM 输出中自动提取生成的文件，并支持预览差异。
   • 内置文件搜索、网络搜索和浏览器自动化（通过 Playwright）功能。
   • 提供安全性保障，包括内置的负责任 AI 系统提示和 Azure 内容安全集成。
   • 支持使用 Zod 定义 Schema，并能运行代码解释器（Python）或在 Docker 容器中执行代码。

5. 自动化与集成：

   • 提供 CLI 工具，便于集成到 CI/CD 流水线中。
   • 支持在 Pull Request 中进行代码审查和评论。
   • 包含基于 promptfoo 的测试和评估框架，用于构建可靠的提示。

实际应用与资源： 文章列举了多个真实世界的应用案例，例如为 Azure Bicep 文件实施最佳实践、自动化生成 SEO 前置信息、多语言文档翻译、自动生成图像替代文本以及代码发布说明生成等。同时，项目提供了丰富的预置脚本、烹饪书指南和内置代理，帮助用户快速上手并扩展功能。项目文档也针对 LLM 进行了友好设计，便于爬取和索引。

文章总结：思维链可能损害特定任务中的性能

核心观点

思维链（Chain-of-Thought, CoT）提示技术已被广泛用于提升大语言模型和多模态模型的性能，但在某些特定场景下，CoT会系统性地降低模型表现。

研究背景与方法

• 研究目的：识别CoT降低性能的任务特征。
• 研究方法：从认知心理学中汲取灵感，聚焦于六类有代表性的、已知人类思考后表现会变差的心理学任务。研究人员将这些任务应用于最先进的AI模型，以测试CoT的影响。

主要发现

1. 显著性能下降：在六类任务中的三类上，使用CoT会导致模型性能显著下降。
   • 一个突出的案例是，OpenAI o1-preview模型在应用CoT时，与GPT-4o相比，准确率绝对下降高达36.3%。
2. 混合效果：在其余任务中，CoT的效果是混合的，包括产生积极、中性或消极的变化。
3. 人机认知的启示：虽然模型与人类的认知过程并非完全平行，但借鉴人类思考可能产生负面影响的案例，有助于识别出对模型同样产生负面影响的情境。

结论与贡献

• 本研究将关于人类言语思考和审慎推理的文献与对CoT的评估联系起来。
• 这为理解推理时思考（inference-time reasoning）的影响提供了一个新的视角，明确了CoT并非万能，其效果高度依赖于任务类型。

关于谷歌搜索正在摧毁独立网络的控诉

独立图书平台Shepherd的创始人Ben Fox发文痛斥谷歌搜索对独立网站造成的毁灭性打击。文章核心内容如下：

核心问题：谷歌搜索质量严重下滑

作者指出，大约16个月前，谷歌搜索引擎开始出现严重问题，导致大量提供优质内容、用户体验良好的独立网站流量断崖式下跌。网站所有者对具体原因感到困惑，猜测可能是谷歌对AI排名系统失控，或是管理层为提升广告收入而故意为之（美国司法部泄露的文件暗示了后者）。谷歌违背了其核心承诺：创造优质内容就能获得良好排名。

铁证如山：以Shepherd网站为例

作者以数据展示了谷歌的“失职”：

1. 流量暴跌：过去16个月，谷歌导向Shepherd网站最受欢迎板块的流量暴跌了86%。
2. 内容本身优质且受欢迎：
   • 用户参与度极高：60%的用户阅读了该板块75%以上的内容；平均页面停留时间超过5分钟；12%的用户会点击深入了解书籍。
   • 典型案例：凯文·米勒的“中途岛战役最佳书籍”页面。凯文是该战役书籍作者、海军航空博物馆前执行副总裁、前海军战斗机飞行员，是真正的专家。该页面曾长居谷歌相关搜索前3名，但现已降至第3页甚至消失。
   • 该页面用户数据依然出色：平均停留时间7分16秒，55%的用户阅读至75%以上，15%的用户会点击探索书籍。
3. 排名被劣质内容取代：谷歌现在将凯文的优质页面降权，取而代之的是大量低价值、无专家见解的内容：
   • 一个作者自己创建的仅含4本书的测试列表（无深度信息）。
   • Goodreads上未经筛选的100本书单。
   • 一个仅有1条推荐的3年前Reddit帖子。
   • 博物馆售卖单一书籍的电商页面。
   • 一个已有14年历史、无专业性的桌游论坛帖子。
   • 谷歌自己的“书籍小部件”（无筛选，无实用性）。
   • 仅展示单本书籍的亚马逊链接。

结论：谷歌系统性地埋没了像Shepherd这样遵循其指南、提供优质内容的独立网站，反而提升了大量对用户无帮助的结果。这相当于对独立网站进行了“影子禁令”。

广泛的影响与灾难性后果

这种问题不仅发生在Shepherd身上。文章引用了多个其他独立网站的悲惨遭遇：

• HouseFresh：独立评测网站被垃圾内容超越。
• RetroDodo：优秀的复古游戏网站被谷歌“扼杀”。
• Healthy Framework：详细解释了谷歌如何破坏网络生态，预言最终只剩垃圾和Reddit。
• 多个其他网站：如Ready Steady Cut、拥有17年历史的户外网站等，都因谷歌更新而遭受毁灭性流量损失。

许多独立网站因此破产或关闭。谷歌拒绝承认问题，其搜索联络员（如John Mueller和Danny Sullivan）的回应被批评为缺乏实质信息，只是重复“创造优质内容”的空话。

作者的呼吁与建议

作者强烈要求谷歌修复搜索，使其恢复正常。他个人和家庭已因体验恶化而转向使用Kagi搜索和ChatGPT。他提出两点建议：

1. 建立合作伙伴计划：让网站主嵌入代码，提供匿名用户参与度数据，帮助谷歌更好地识别和奖励优质网站。
2. 提供真正有用的工具：在Google Search Console中明确告知网站主需要改进的具体原因，而非黑箱操作。

文章最后强调，独立网络正处于危险之中，而谷歌是破坏的主要推动者。作者呼吁谷歌正视问题并采取行动。

作者从8岁开始编程，回顾了在业余和专业生涯中，那些深刻改变他对编程乃至思考方式的几种语言。这些语言按发现顺序排列，重点在于它们带来的关键新概念。

• Basic：作为第一门语言，让他能够自己编写游戏，并首次接触到数组、GOTO和GOSUB。
• Turbo Pascal：影响最深的语言。它带来了集成开发环境（IDE）、有用的调试器、模块（Units）、动态内存分配和开发者社区。作者认为它奠定了许多现代工具的基础。
• x86汇编语言：为突破图形限制而学习，让他理解了内存寻址、寄存器、中断以及与硬件直接交互。
• HyperCard：一门面向非程序员的语言，看起来像绘图软件。它带来了环境定制、接近自然语言的编程、用户界面抽象（Stack、模板）和垃圾回收概念。作者认为它是许多可视化工具和Web的灵感来源。
• (O)Caml：函数式语言，带来了参数化多态（泛型）、类型推断、模式匹配、REPL、高阶编程、单子、并发消息传递等众多高级概念。它是Rust、F#等现代语言的直接祖先。
• Java：带来了感觉“应有尽有”的标准库、优秀的文档、Java虚拟机（JVM）、即时编译（JIT）和简单的GUI工具包。虽然语言本身冗长，但成为了当时的基准语言。
• Prolog：一种逻辑编程语言，核心概念是“教程序如何思考”，而非编写算法。它的遗产存在于SQL、C++模板系统以及Rust的类型系统中。
• Coq：一种证明辅助语言，核心是“类型即规范，程序即证明”。程序员通过求解类型相关的子目标来编写代码，最终得到数学上已验证正确的程序。
• Erlang：专为分布式系统设计的语言，其核心概念是轻松实现分布式、通过发送闭包进行热代码部署以及“任其失败”的容错设计。其并发和actor模型影响了Scala、Go等。
• π-演算：一种用于推理并发系统的数学模型，它让作者重新审视了竞态条件，并展示了仅用并发运算即可实现图灵完备。
• Opalang：作者曾参与设计的语言，旨在用单一代码库编写应用，编译器自动将其拆分为客户端（JS/HTML/CSS）、服务器端（原生）和数据库端代码，从而自动处理安全、分布式等问题。
• Rust：结合了函数式语言（如OCaml）的表达力和安全性与系统语言（如C++）的性能与控制力。关键创新包括利用仿射类型保证内存安全和并发安全、高效的async/await模型、清晰的错误信息、强大的工具链（Cargo）和友好的社区。

作者说明，未列出的其他语言（如Haskell、Python、Go等）虽然优秀，但并未因其概念（或因学习顺序而更早被其他语言普及）而让他产生同样的“头脑爆炸”感。

OpenZFS去重功能改进与使用建议总结

核心结论

OpenZFS 2.3.0引入了“快速去重”（Fast Dedup）功能，虽显著改善了传统去重的性能与资源消耗，但对于绝大多数用户（尤其是通用工作负载），仍不建议启用去重。推荐使用更高效的块克隆（Block Cloning）技术替代。

去重原理

• 定义：写入数据时，若检测到磁盘上已存在相同数据，则不写入新副本，仅增加指向现有副本的引用。
• 关键挑战：判断数据是否已存在并定位其磁盘位置需查询额外的元数据（去重表），此过程引入IO和内存开销。

传统去重的主要问题

1. 去重表开销大：

   • 使用通用ZAP对象存储，结构不够优化。
   • 更新单条目需读写整个数据块（32KB），导致严重的IO放大。
   • 需大量内存缓存表以减少磁盘IO。

2. 实时条目列表内存占用高：

   • 为保持事务一致性，维护一个内存中的活跃条目列表。
   • 每个条目高达424字节，且无法被系统回收，峰值时消耗巨大内存。

3. 唯一条目浪费资源：

   • 表中大量条目仅引用一次（唯一），不产生去重收益，却持续占用存储和内存。
   • 通用工作负载中真正重复的数据块比例极低。

“快速去重”的改进

为解决上述问题，新功能做出以下优化：

1. 缩小实时条目内存占用：通过优化数据结构，将条目大小从424字节减至216字节。
2. 引入去重日志：
   • 将对去重表的更新先记录到内存和磁盘日志中，而非立即写入去重表。
   • 减少了单次事务的IO开销，并将更改批量处理。
3. 管理唯一条目：
   • 新增 zpool ddtprune 命令，可按年龄或百分比删除唯一条目，释放空间。
   • 支持 dedup_table_quota 属性限制去重表总大小。
4. 其他改进：包括更优的统计信息、可调参数、以及针对现有表的部分功能兼容。

为何仍不建议普遍使用

1. 通用工作负载收益极低：模拟测试显示，绝大多数数据块是唯一的，启用去重带来的空间节省微乎其微，却持续产生IO和内存开销。
2. 存在更优替代方案——块克隆：
   • 基于明确的“复制”信号（如 copy_file_range() 系统调用），直接复制块指针并增加引用计数。
   • 无去重表，内存开销极小（每条目仅16字节），几乎无IO开销。
   • 对于支持拷贝卸载（Copy Offloading）的程序（如 cp、编译缓存等），块克隆能提供大部分去重收益，且效率远高于去重。
3. 去重仍有局限性：快速去重降低了门槛，但仍要求工作负载具有极高且持久的数据重复率，并无法利用块克隆等更高效机制，才能抵消其开销。

适用场景

仅在以下非常特殊的情况下，可考虑使用快速去重：

• 数据量庞大，且重复率极高。
• 客户端无法或不会发出明确的拷贝卸载指令。
• 无法利用快照克隆或块克隆等特性。

总结

快速去重是对OpenZFS去重功能的重大改进，大幅降低了其资源消耗和对工作负载的敏感性，使其在技术层面更加可行。然而，对于大多数用户，块克隆技术以其几乎零开销的优势，成为实现空间节省的首选方案。因此，除非处于高度特化的场景，否则不应启用去重功能。

对ZBar条码扫描库的模糊测试实践

本文介绍了对开源条码扫描库ZBar进行模糊测试（Fuzzing） 的过程，重点描述了如何在有限时间内发现严重安全漏洞。

1. 项目背景与评估

• ZBar是一个用C语言编写的、支持多种条码格式（包括QR码）的库。
• 通过检查代码仓库和OSS-Fuzz项目，发现ZBar基本未经模糊测试或测试已停滞，因此决定自行开展模糊测试活动。

2. 构建与插桩

• 使用Nix包管理系统快速修改构建配置，以集成模糊测试所需的插桩。
• 关键修改包括：切换编译器至Clang、添加OpenMP依赖、禁用剥离（strip）和测试，并加入AddressSanitizer和libFuzzer的编译链接标志。

3. 测试目标与初始 harness

• 测试目标明确为解码图像中条码数据的核心函数。
• 创建了初始的测试 harness，模拟一个16x16像素的Y800格式图像作为输入。
• 运行后，首先发现了内存泄漏崩溃（通过LeakSanitizer）。为继续寻找更严重漏洞，暂时禁用了泄漏检测（-detect_leaks=0）。

4. 模糊测试过程与发现

• 在覆盖率增长停滞后，将输入图像尺寸扩大至32x32像素（1024字节）。fuzzer自动发现输入长度困难，通过手动提供合适大小的种子文件解决了启动问题。
• 随后，AddressSanitizer迅速报告了一个栈缓冲区溢出（stack buffer overflow） 漏洞。
• 最终，通过模糊测试共发现两个严重漏洞：
  1. 栈缓冲区越界写入（CVE-2023-40890）：漏洞位于lookup_sequence函数，可能导致任意代码执行。该漏洞由其他研究者同时期独立发现并已修复。
  2. 内存泄漏：漏洞位于_zbar_sq_decode函数，在特定错误路径下未能释放内存，可被用于拒绝服务攻击（DoS），因为泄漏内存大小与输入图像相关。

5. 漏洞根源与修复

• 内存泄漏的根本原因是错误处理路径中缺少内存清理代码（未跳转至free_borders标签）。
• 研究者提交了修复补丁（将错误路径的return改为goto free_borders），并向上游ZBar仓库发起了Pull Request。

6. 关键经验与建议

• 对不安全代码进行模糊测试：即使时间有限，也应进行基础模糊测试，后续研究者可在此基础上扩展。
• 限制攻击面：仅启用必要的解码功能（例如，若只需解码QR码，则禁用其他条码类型的扫描）。
• 在构建中集成 sanitizer：至少应使用AddressSanitizer。这不仅能捕获内存安全漏洞，也是模糊测试C/C++代码的必要前提步骤。文章指出，如果ZBar的测试在构建时启用了sanitizer，本应能更早发现关键漏洞。
• 提供了完整的可复现资源，包括测试 harness 代码和Nix 构建文件，方便他人验证和扩展研究。

Chrome Web Store 中的 Karma 关联事件总结

事件背景与核心发现

作者通过调查发现，名为 Hide YouTube Shorts 的 Chrome 扩展在更换所有者后变为恶意扩展。其包含两个未公开的组件：一个是执行联盟营销欺诈，另一个是将用户的所有浏览活动发送到某个亚马逊云服务器。进一步调查后，作者发现由同一开发人员编写的另外 11 个扩展也存在类似问题，部分仅包含欺诈组件，部分仅包含用户追踪组件，部分则两者兼有。

关键关联方：Karma 购物助手

在所有相关扩展中，Karma 购物助手 扩展自 2020 年起上架于 Chrome 商店，其背后的公司 Karma Shopping Ltd.（前身为 Shoptagr Ltd.）成立于 2013 年，拥有超过 50 名员工并获得大量风险投资。然而，调查发现该扩展与上述恶意扩展存在紧密联系：

1. 共享基础设施与代码：Karma 扩展与恶意扩展共享后端基础设施和大量代码。
2. 数据收集政策：Karma Shopping Ltd. 在其隐私政策中承认会收集用户的浏览数据，并会以聚合、匿名的方式与商业伙伴分享，用于市场研究和商业用途。
3. 跨平台一致性：一个由 Karma Shopping Ltd. 开发的移动应用与一个由神秘开发者发布的 Chrome 扩展完全相同，该扩展被证实含有恶意功能。

受影响扩展列表与恶意功能

文章列出共 12 个相关扩展，其中大部分在 2023 年夏天之后更改了所有权，并在所有权转移后立即添加了恶意代码。以下表格列出了部分扩展及其恶意功能：

注：截至文章更新时，部分扩展已被下架，但仍有三个（包括最流行的两个）保持活跃。

恶意功能的技术实现方式

恶意代码并未经过混淆处理，而是精心设计使其与扩展的合法功能融为一体，以避免审查。

1. 联盟欺诈功能：
   • 与域名 kra18.com 相关联。
   • 扩展会从该服务器下载一个包含 6553 个主机名的列表。
   • 当用户访问列表中的特定网站时，扩展会请求一个包含当前页面完整地址的指令。
   • 服务器返回一个用于设置联盟营销 Cookie 的 URL，扩展随后会通过一个看似“打开PDF标签页”的操作（该标签页会在 9 秒后关闭）来访问此 URL，从而赚取佣金。
   • 此功能还会替换 amazon.com 上的某些产品链接，通过 jdoqocy.com 域名进行联盟佣金赚取。
2. 浏览资料收集功能：
   • 将用户的每一次页面访问都发送到 https://7ng6v3lu3c.execute-api.us-east-1.amazonaws.com 服务器。
   • 传输的数据包含：user_id（用户标识符）、distinct_id、current_url、referrer、navigator_language、local_time 等详细信息。
   • 对于 Karma 扩展本身，数据中包含 user_id（个人标识符）和 tab_id（标签页标识符），使得用户行为更易被追踪和区分。

Karma 公司与恶意扩展的关联证据

1. 代码与基础设施共享：所有 12 个扩展明显由同一团队开发。
2. 共享追踪后端：包括 Karma 在内的五个扩展使用相同的追踪后端和访问令牌。其他扩展发送数据时带有 external: true 标志，表明 Karma 扩展被视为第一方。
3. 用户ID系统一致：恶意扩展在与 kra18.com 服务器通信时使用的 user_id，与其发送到追踪后端的数据中的标识符相同。
4. 联盟链接明确指向 Karma：部分由 kra18.com 服务器生成的联盟链接中，明确包含 karmanow.com（Karma 公司域名）作为联盟合作伙伴。
5. 跨应用与扩展的一致性：由 Karma Shopping Ltd. 开发的“Sudoku on the Rocks”移动应用，与一个名为 Karen Shilop 开发的、包含隐藏欺诈功能的 Chrome 扩展完全相同。
6. 扩展收购意图：有证据显示，Karma Shopping Ltd. 的高管曾多次使用公司官方邮箱联系其他扩展开发者，意图收购其扩展，并报价为每 0.2 至 1 美元每个周活跃用户。

隐私政策与法律问题

• Karma 扩展：其隐私政策（第 1.3.4 条）声称会收集浏览数据并与商业伙伴分享，但法律依据部分承诺“会征求用户同意”。作者指出，在实际操作中并未获得有效同意，这使其数据收集行为在 GDPR 框架下值得质疑。此外，政策混淆了“匿名”与“假名”数据的概念，实际收集的数据是可关联特定个人的假名数据。
• 其他恶意扩展：例如 Hide YouTube Shorts 等扩展，在 Chrome 商店页面上明确声称“不会收集或使用您的数据”，这构成了直接的虚假声明。

文章针对Slack在2017年发布的复杂通知流程图提出了批评与优化方案。

原流程图展示了决定是否向用户发送消息通知的复杂逻辑，包含多个循环和重复检查（如频道/全局通知偏好、线程提及、高亮词汇等），被广泛引用作为软件复杂性的例子。

作者认为原图存在过度复杂化问题：

1. 逻辑拆分不当：将结构相似的“频道通知偏好”与“全球通知偏好”完全分开，造成重复。
2. 检查冗余：对线程提及和高亮词汇的判断在图中重复出现了半打多次。
3. 路径繁琐：存在十余条不同的“有效”判断路径，难以快速理解整体逻辑。

作者对流程图进行了概念性重构，绘制了一个更简洁的版本。其优化主要体现在：

• 合并同类检查：将逻辑上属于同一判断但被分散的操作（例如用&&和||连接的条件）整合到一个节点中。
• 减少路径：设计了一条清晰的主路径，并配有关键“分流点”，使决策流程更易追踪。
• 聚焦意图：更专注于清晰呈现决策树的高层故事，同时保持对细节的准确性（作者声称其版本比原图更符合Slack 2017年的实际行为）。

作者强调，他并非低估Slack通知系统的复杂性（员工反馈该系统是其代码库中最复杂的部分之一），也未涉及原图未涵盖的更多复杂场景（如通知撤回、紧急通知覆盖等）。核心论点在于：我们思考和描述系统的方式对其可理解性有巨大影响。将复杂问题简单化呈现，比将复杂问题复杂化呈现更有挑战。选择正确的视角，可以让棘手的问题变得清晰，如同第二张图所示。

AI OmniGen 一体化AI平台 AI OmniGen是一个集成了AI视频生成、AI图像生成、音频工具及创意编辑流程的一体化AI平台，旨在帮助用户更快地从提示词到完成视频、图像或音频资产。

解决传统内容制作痛点 传统的视频和图像制作过程通常速度慢、成本高且难以规模化。AI OmniGen通过其AI生成工具，旨在帮助创作者更快速地制作出专业级内容。

平台核心功能与优势 该平台的核心在于将尖端模型与直观的在线界面相结合，为AI视频和图像生成工作流提供支持。它提供了一个简化的统一工作流程，用户可以利用它一次性完成多种格式的内容创作。

常见问题解答 平台提供了关于其AI视频生成器、AI图像生成器及整体一体化平台的常见问题解答（FAQ）。

NandGame 是一个教育类解谜游戏，玩家通过解决一系列任务，从最简单的逻辑组件开始，逐步构建出更复杂的部件，最终组装成一台可编程的计算机。该游戏旨在通过实践引导学习者理解计算机的基础原理和构造过程。

文章摘要：揭秘用于判断素数的正则表达式

本文深入解析了一个通过正则表达式判断数字是否为素数的巧妙方法。核心思路是将数字转换为一元表示（例如，数字5表示为11111），然后使用特定正则表达式匹配非素数（合数），若匹配成功则数字为合数，否则为素数。

核心原理

• 一元表示：数字n表示为n个相同字符（如1）组成的字符串。例如，4 → 1111。
• 正则表达式：^.?$|^(..+?)\1+$（注意：Java代码中由于String.matches()自动匹配整个字符串，因此使用了简化形式.?|(..+?)\\1+）。
• 判断逻辑：若该正则表达式能匹配数字的一元表示，则数字是合数（非素数）；若无法匹配，则数字是素数。

正则表达式解析

表达式由两部分通过|（或）连接：

1. ^.?$：匹配空字符串（0个字符，对应数字0）或单个字符（对应数字1）。根据定义，0和1都不是素数。
2. ^(..+?)\1+$：核心部分，用于检测合数。
   • (..+?)：捕获组，匹配两个或更多个字符（即长度≥2的子串）。?使+成为非贪婪量词，从最短可能长度开始匹配。
   • \1+：反向引用，重复匹配捕获组1所匹配的内容至少一次。
   • 整个部分意在检查：字符串总长度是否能被某个子串长度（≥2）整除。若能整除，则说明该数字有因子，是合数。

匹配过程示例

• 数字6（一元：111111，长度6）：
  1. 第一部分^.?$不匹配。
  2. 第二部分^(..+?)\1+$尝试：
     • 捕获组(..+?)先匹配长度2的子串11（对应因子2）。
     • 反向引用\1+尝试重复11：两次（1111，长度4）不匹配，三次（111111，长度6）匹配成功。
  3. 正则匹配成功 → 6是合数。
• 数字5（一元：11111，长度5）：
  1. 第一部分不匹配。
  2. 第二部分尝试所有可能的子串长度（2,3,4）：
     • 长度2：11重复两次（1111，4）不匹配，三次（111111，6）超出长度。
     • 长度3：111重复两次（111111，6）超出长度。
     • 长度4：1111重复两次（11111111，8）超出长度。
  3. 无匹配 → 5是素数。

关键细节

• 非贪婪量词?的作用：使+从最小可能长度开始尝试匹配（即先尝试除数2，再3、4...），这比从最大长度开始尝试更高效，减少了不必要的步骤。
• 捕获组与反向引用：(..+)捕获一组字符，\1确保后续重复匹配与捕获内容完全相同的字符序列，从而实现对长度的整除判断。
• Java特殊性：String.matches()隐含匹配整个字符串，因此代码中可省略^和$。

代码示例（多种语言）

• Java：

  public static boolean isPrime(int n) {
      return !new String(new char[n]).matches(".?|(..+?)\\1+");
  }
  

• Python：

  import re
  def is_prime(n):
      return not re.match(r'^.?$|^(..+?)\1+$', '1'*n)
  

• JavaScript（ES6）：

  function isPrime(n) {
      return !/^.?$|^(..+?)\1+$/.test('1'.repeat(n));
  }
  

• Perl：

  sub is_prime {
      return !((1x$_[0]) =~ /^.?$|^(..+?)\1+$/);
  }
  

注意事项

• 效率问题：此方法趣味性强但效率低，仅适用于教学或理解目的，实际素数检测有更高效算法。
• 术语说明：文中讨论的“正则表达式”在严格计算机理论中属于“正则”范畴，但实际应用中常与“regex”术语混用。

topYappers：TikTok网红营销平台

核心功能：

• 智能数据库：提供超过4000万+已审核的创作者资源
• AI匹配系统：基于数据分析匹配已在特定领域产生收益的创作者
• 全流程管理：集成创作者发现、外联管理和合作谈判功能
• 数据智能：不仅提供数据库，更通过AI分析预测创作者与产品的匹配度

主要优势：

• 无需复杂设置，即时使用
• 灵活的订阅模式，支持随时取消
• 透明定价，适合不同规模的团队
• 帮助品牌快速定位已在相关领域推广类似产品的网红

应用场景： 该平台帮助营销团队快速找到并联系已在其细分市场产生实际销售的创作者，提升网红营销效率。

Hazel：支持类型化空洞的实时函数式编程环境

核心概述
Hazel 是一个实时函数式编程环境，能够对包含“空洞”（即程序中的未完成部分）的不完整程序进行类型检查、操作甚至执行。它确保所有可构建的编辑状态都具备形式意义，不存在无意义的编辑状态。

研究动机
在编程过程中，开发者经常需要处理未完全完成的程序文本，例如存在空白区域、类型错误或合并冲突的代码。传统编程语言定义通常无法赋予这类结构形式意义，导致开发者无法获得程序已完整部分的实时行为反馈。同时，编程编辑器和工具不得不依赖复杂的临时启发式方法来提供代码补全、类型检查等语言服务，且这些服务可能存在覆盖空白。

Hazel 旨在提供一种更系统的方法来处理不完整程序，其理论基础是上下文模态类型理论和渐进类型理论。它将不完整程序建模为“带空洞的程序”，其中空洞（1）表示程序中缺失的部分；（2）作为错误部分或协作冲突部分的隔离层。

Hazel 的特点与实现
Hazel 是一个基于 Web 的编程环境，用于一种类似 Elm/ML 的函数式编程语言，其设计围绕类型化空洞驱动的开发展开。

其独特之处在于：通过 Hazel 的编辑操作构建的每一个不完整程序都同时具备静态和动态的良好定义性——即它拥有一个（可能不完整的）类型，并且可以运行以产生一个（可能不完整的）结果。这使得 Hazel 成为一个研究未来编程及编程教育的优雅平台。

相关资源
研究愿景在相关论文中进一步阐述，同时 Hazel 的演示视频（如 Topos Institute 讲座）可在 YouTube 播放列表中获取。

SimpleQA 总结

目的：SimpleQA 是一个专注于评估语言模型事实性的基准数据集。它通过聚焦于短小的、寻求事实的查询，简化事实性测量，使其更易处理。

目标属性：

• 高正确性：问题的参考答案由两位独立的AI训练师支持，问题设计便于自动评分。
• 多样性：覆盖广泛话题，包括科学技术、电视节目和电子游戏。
• 对前沿模型的挑战性：相比旧基准（如TriviaQA和NQ），SimpleQA对前沿模型更具挑战性（例如GPT-4o得分低于40%）。
• 良好的用户体验：问题简洁，运行快速，评分高效（可通过OpenAI API等）；包含4,326个问题，确保评估方差较低。

数据集创建方法：

• 雇佣AI训练师浏览网络，创建短小的事实性问题和对应答案。
• 问题需满足严格标准：必须有单一、无可争议的答案；答案不应随时间变化；多数问题能诱导GPT-4o或GPT-3.5产生幻觉。
• 第二位独立AI训练师验证答案一致性，只有答案一致的问题被纳入数据集。

验证过程：

• 第三位AI训练师随机回答1,000个问题，与原始答案匹配率94.4%，不一致率5.6%。
• 手动检查不一致案例：2.8%源于评分错误或第三训练师的人为错误，剩余2.8%源于问题本身问题（如模糊或矛盾答案）。
• 估计数据集固有错误率约为3%。

其他信息：文章作者为Jason Wei等，致谢Adam Tauman Kalai。

A React Renderer for Gnome JavaScript

这是一个用于Gnome JavaScript的React渲染器，允许开发者使用React来构建原生的GTK应用程序。它是React Gnome项目的核心渲染部分，目前仍处于早期开发阶段，可能存在缺陷和功能缺失。

主要特性与组件

该渲染器提供了一系列GTK3组件，均已包装为JSX组件，并附带完整的TypeScript类型定义。支持的组件包括：

• 基础容器与布局: Window, Box, Grid, FlowBox, Stack, Frame, Expander, Paned, ScrollBox 等。
• 常用控件: Button, CheckButton, Label, TextEntry（SearchEntry）, TextArea（TextView）, NumberInput, Switch, RadioButton, ColorButton, Image, Icon, LinkButton, Slider, Spinner, ProgressBar, LevelBar, SearchBar, MenuBar, Toolbar 及其相关子组件。
• 交互与显示: EventBox（Pressable）, Revealer, Popover, PopoverMenu, Separator。
• 标记（Markup）组件: Big, Bold, Italic, Monospace, Small, Span, Strike, Sub, Sup, Underline。

使用方法

由于GJS环境不支持从node_modules直接导入，使用该渲染器需要将应用打包成一个单独的JavaScript文件。可以使用webpack、esbuild或rollup等工具进行打包。

esbuild示例配置:

esbuild ./App.tsx --bundle '--external:gi://*' --external:system --format=esm --outfile=./out.js

基本应用代码示例:

// App.tsx
import Gtk from "gi://Gtk?version=3.0";
import * as React from "react";
import { Box, Label, Renderer, Window } from "react-gjs-renderer";

Gtk.init(null);

const App = () => {
  return (
    <Window quitOnClose minWidth={200} minHeight={200}>
      <Box>
        <Label>Hello World</Label>
      </Box>
    </Window>
  );
};

const renderer = new Renderer({ appId: "com.example.app" });
renderer.start(<App />);

项目状态与贡献

该项目仍处于积极开发中，许多组件有待实现。开发者欢迎社区参与贡献，相关的讨论和贡献指南可通过项目指定的讨论链接查阅。

Lisp 查询记法 (LQN) 摘要

Lisp 查询记法 (LQN) 是一个查询语言、一个 Common Lisp (CL) 库以及一个终端实用程序。其设计目标是为终端中的文本文件（如 CSV）、Lisp 数据和 JSON 数据提供类似于 sed、AWK 或 .jq 的强大处理能力，同时保持语法简洁并允许直接嵌入 CL 代码。

核心概念与设计

• 函数式与链式操作：LQN 采用函数式编程风格，允许将多个操作通过管道 (||) 链接在一起，这与 .jq 等工具类似。
• 符号、字符串与关键字：LQN 中符号（如 reverse、?rec）用于表示函数名和操作符。为了方便在终端中使用，它用 :keyword 的形式来代表小写字符串。
• 数据表示：所有输入数据都会被加载到 CL 原生对象中：文本文件通常变为字符串向量，JSON 数据则根据结构转换为向量和关联列表（kvs）。内部对象的序列化输出支持多种格式。
• 终端命令：提供三个主要命令，分别处理不同输入：
  • tqn：处理文本（如 CSV）。
  • lqn：处理 Lisp 数据（如源代码）。
  • jqn：处理 JSON。 命令可以通过选项（如 -t、-l、-j）控制输出格式。

关键功能与操作

1. 操作链接：使用 || 操作符显式链接多个子表达式。默认情况下，查询中的裸函数名会对输入向量中的每个项目进行映射操作（等同于 #(..) 操作符）。
2. 过滤：支持直接使用字符串/关键字进行匹配，也提供更强大的 [] 过滤操作符。过滤器支持子串搜索 (:e!)、类型检查 (int!?)、逻辑组合 (and, not) 以及反转 (-@)。
3. 结构化数据操作（以 JSON 为例）：
   • 字段选择：使用 #{..} 操作符可以从 JSON 对象向量中选择指定字段。?@ 修饰符可确保只选择存在且非 null 的键。
   • 值转换：在字段选择中可以嵌入表达式对值进行转换（如算术运算、函数应用）。
   • 复杂查询：支持嵌套选择器和过滤，例如只选择满足特定条件（如字段存在且长度大于 10）的对象。
4. 其他高级操作符：LQN 包含一系列有用的操作符，例如：
   • ?rec：执行递归操作。
   • ?srch：在嵌套结构中进行搜索。
   • ?txpr：在嵌套数据中执行查找与替换。

应用与定位

• LQN 的编译器核心相对简洁（约 300 行代码），使得语言易于理解和扩展。
• 它是一个实验性项目，作者认为其对于终端中的常见数据处理任务可能很有用，并且可以作为未来编写其他领域特定语言（DSL）或实现 CL 宏时进行数据转换的工具。
• 文章开头提供了一个使用 LQN 计算并格式化输出前 25 个斐波那契数的复杂示例，以展示其表达能力。

创建绘画风格着色器

本文介绍了在WebGL中实现绘画风格后处理效果的完整过程，核心是通过一系列图像处理技术将3D场景转化为类似水彩或油画的艺术风格。

核心技术：Kuwahara滤波器

• 原理：通过为每个像素计算周围区域（分为4个扇区）的方差，选择方差最小扇区的平均颜色作为输出。
• 特性：在平滑纹理细节的同时保留边缘，这是实现绘画效果的关键。
• 局限性：过大的核尺寸会导致场景难以辨认。

关键改进与优化

1. Papari扩展：

   • 采用圆形核替代方形核，增加扇区数量（如8个），更好地保留复杂边缘。
   • 使用高斯权重替代均匀权重，使过渡更自然，减少明显笔触痕迹。
   • 采用多项式权重近似高斯函数，提升性能。

2. 各向异性滤波器：

   • 利用结构张量（通过Sobel算子计算）分析图像局部结构方向。
   • 从结构张量推导特征值与特征向量，计算各向异性程度。
   • 根据各向异性程度拉伸并旋转核，使其适应边缘方向，使笔触更自然。

多通道后处理管线

1. 第一通道：计算场景的结构张量。
2. 第二通道：应用改进后的各向异性Kuwahara滤波器。
3. 第三通道：最终颜色校正与增强。

最终调整与增强

• 颜色量化：减少颜色数量，模拟有限色板效果。
• 颜色插值：通过两点插值增强明暗对比。
• 饱和度调整：增加色彩鲜艳度。
• 色调映射：使用ACES Film等映射改善颜色平衡。
• 纹理叠加：添加纸张纹理，增加真实感和物理质感。

总结与建议

• Papari扩展结合多项式权重足以在大多数情况下实现令人满意的绘画效果，且性能较好。
• 完整的各向异性实现虽然复杂，但能产生更细腻的结果，适合需要高度风格化的场景。
• 所述的结构张量等技术可用于其他后处理效果，是着色器开发中的重要工具。

Wonder Animation – 视频转3D动画技术
Wonder Dynamics（隶属Autodesk）推出 Wonder Animation 测试版，利用创新的 “视频转3D场景”技术 加速动画电影制作。该技术可将任意视频序列转换为3D动画场景，支持多镜头剪辑与不同景别（广角、中景、特写），并通过AI在3D空间中重建场景，匹配镜头与角色/环境的位置关系。

作为 Wonder Studio 工具集的一部分，Wonder Animation 旨在帮助艺术家接近全动画电影制作，同时保留完全创意控制权，避免依赖自动化输出的“黑箱”模式。技术生成的3D场景包含所有镜头设置、角色身体与面部动画数据，并支持在 Maya、Blender、Unreal 等软件中完全编辑动画、角色、环境、灯光及摄像机跟踪数据。

Wonder Dynamics 强调，该技术是对 AI 应用的一次探索性实践，旨在通过智能工具提升创作效率，使艺术家更专注于叙事本身。测试版现已向所有 Wonder Studio 用户开放。

qBittorrent SSL验证漏洞（CVE-2024-51774）

漏洞概述
自2010年4月6日起，qBittorrent的DownloadManager类在所有平台上完全忽略SSL证书验证错误长达14年半，直至2024年10月12日的提交才默认启用验证。首个修复版本为5.0.1。该漏洞被分配CVE-2024-51774，需中间人攻击（MITM）或DNS欺骗利用。

影响范围
漏洞广泛影响程序功能，包括：

• 搜索功能
• .torrent文件下载
• RSS订阅
• 网站图标下载等

所有代码路径均接受任意证书（无论过期或自签名）。

主要攻击场景（按严重性排序）

1. 恶意可执行文件加载（RCE）

条件：Windows系统未安装合适版本的Python。
过程：

• qBittorrent启动时提示安装Python，从硬编码URL下载安装程序。
• 下载完成后直接执行并删除可执行文件（影响v3.2.1至v5.0.0）。
• 下载文件存储在临时目录（如C:\Users\用户\AppData\Local\Temp\），执行后可能存在残留进程。
  风险：攻击者可通过MITM替换下载的exe文件，实现远程代码执行。

2. 软件更新劫持（任意URL注入）

条件：已安装版本（非AppImage）启动时检查更新。
过程：

• 从硬编码RSS URL获取更新信息。
• 解析XML后直接提取并提示用户访问更新URL（无过滤或验证）。
• 用户确认后将在默认浏览器打开攻击者控制的URL。
  风险：结合开源特性，攻击者可诱导用户下载含后门的恶意更新包。

3. RSS订阅链接注入

特性：所有RSS链接通过DownloadManager获取，可被劫持。
风险：

• 双击条目即访问任意注入的URL。
• 结合历史漏洞CVE-2019-13640（通过种子名或Tracker参数实现RCE），可能无需作者配合即可远程执行命令。

4. 解压库攻击面（零点击）

过程：程序启动时自动下载并解压.gz格式的GeoIP数据库。
风险：若解压库存在漏洞（如CVE-2022-37434），攻击者可提供恶意文件（最大64MB）触发缓冲区溢出。

利用可能性

• 硬编码URL使攻击脚本可自动化部署。
• RSS请求等可作为用户识别特征，便于针对性攻击。
• 开源代码允许攻击者编译含后门的版本，降低受害者怀疑。

缓解措施

• 立即升级至v5.0.1（通过浏览器手动下载，避免应用内更新）。
• 或切换至其他客户端（如Deluge、Transmission）。

补充说明

• 该漏洞已分配CVE，但维护者未明确是否发布安全公告。
• MITM攻击在某些地区（如中国、阿联酋、哈萨克斯坦）并非理论威胁，需重视。

类型、集合与类型检查

本文基于作者构建类型检查器的经验，系统介绍了类型理论的基础知识、类型系统的特性以及类型检查的实现要点。类型的核心作用是为表达式提供结构信息，具体体现在三个方面：错误检测（在编译时或运行时发现无效操作）、程序优化（为编译器提供更多优化决策依据，如CPU寄存器分配）以及辅助程序员（通过类型注解提升代码可读性、可维护性，并支持重构和库的理解）。

类型的基本概念

类型用于对数据进行分类和推理，其本质是基于数据的属性（如“是红色”、“可以灭火”）。一个值满足某类型的属性，称为类型判定，记为 ⊢ value : Type。类型与集合概念相似，但类型基于构造而非谓词。

两个最基本的类型是：

• any：不包含任何必要属性，因此包含所有可能的值。
• never：包含所有可能的、互相矛盾的属性，因此不存在任何值属于该类型。它常用于表示永不返回的函数（如无限循环或异常抛出）。

类型的构造方式

类型可以通过二元连接进行组合，主要有两种形式：

1. 交集类型：表示同时满足左右两侧类型属性的类型，记作 A & B。例如，{ a: string } & { b: number } 表示一个同时拥有 a（字符串）和 b（数字）属性的对象。其核心性质包括：

   • 幂等性：A & A = A。
   • never吸收性：never & A = never。
   • 子类型约简：如果 A 是 B 的子类型，则 A & B = A。
   • 不相交约简：如果 A 与 B 不相交，则 A & B = never。

2. 并集类型：表示满足左侧或右侧类型属性的类型，记作 A | B。例如，Color | null 表示一个颜色值或空值。其核心性质包括：

   • 幂等性：A | A = A。
   • any吸收性：A | any = any。
   • 超类型约简：如果 A 是 B 的子类型，则 A | B = B。

此外，参数化类型（泛型）允许定义依赖于其他类型的模板，如 Array<T>。实例化时可以采用惰性求值策略（记录参数而非立即展开），以提高效率。其他重要类型构造包括元组/积类型（异构固定长度序列）、函数类型（描述输入参数到输出返回值的映射，支持默认参数、可变参数等特性）以及条件类型（其定义依赖于一个条件判断，并在条件为并集时自动分配）。

类型上的核心操作

1. 子类型关系：判断一个类型是否可以安全地用在另一个类型的上下文中。实现时需递归检查，并遵循协变与逆变原则：函数参数类型检查是逆变的（子类型关系反转），而返回类型检查是协变的。
2. 不相交关系：判断两个类型是否存在交集（即是否至少有一个值同时属于两者）。如果判定为不相交，则相关操作（如相等性比较）的结果可以静态确定（例如 number & string 恒为 never，故 number === "hello" 恒为 false）。
3. 属性读取与函数调用：对于对象类型，需要递归地访问其属性；对于函数类型，需要处理类型参数匹配、值参数子类型检查以及结果类型的替换。

类型检查的实现要点

类型检查的过程本质上是遍历程序的语法树，并应用上述操作。其实现涉及几个关键设计：

• 上下文：维护了变量名到类型和类型名到类型的映射关系，支持嵌套作用域。
• 类型推断：在缺少显式注解时推导类型，例如根据变量赋值推断其约束类型，或在函数调用时推断泛型参数。
• 表示类型：在实现语言（如Rust）中，需谨慎处理循环类型（如递归定义的类型）和内存管理。使用Arena分配器可以避免循环引用导致的内存泄漏。
• 错误恢复与稳定性：检查器不应在遇到第一个错误后停止，而应尽可能收集所有错误并继续分析，同时为错误表达式分配合理的类型（如使用带错误标记的 any 或 never），以支持部分有效的代码分析（这对编辑器中的实时检查至关重要）。
• 依赖类型与字面量类型：像 5 或 "hello" 这样的字面量可以作为类型存在，表示一个精确的值。这在描述联合类型（如带有判别属性的对象）时非常有用。

文章最后提及了类型理论中更高级的主题，如柯里-霍华德同构和Rust的生命周期类型，并鼓励读者进一步探索。

文章标题：事件驱动架构中事件的双重性质

事件在事件驱动架构中扮演核心角色，但业界对其应包含哪些内容缺乏共识。这种分歧源于事件在不同视角下承担着不同目的。

在当代事件驱动系统中，微服务通过发布和订阅事件进行协作（本文仅讨论跨服务发布的公共事件，不涉及事件溯源等内部事件）。这些事件具有双重角色：触发动作与携带数据。

从“纯触发器”到“包含完整实体属性的宽事件”，事件可处于连续谱的任何位置，且通常兼具这两种角色。携带大量数据的事件被称为“宽事件”、“胖事件”或“状态事件”等。

软件工程师（DDD背景）视角

• 关注点：将业务流程实现为事件流，事件视为业务动作的触发器。
• 偏好：为不同业务动作设计不同类型的事件（如SeatSelected、PaymentReceived），以清晰叙述业务故事，并应用通用语言。
• 数据内容：通常仅包含与事件动作直接相关的数据（即发生变化的数据）。
• 技术实现（以Kafka为例）：同一实体的不同事件类型发布到同一Topic，并采用RecordNameStrategy等策略管理模式。

数据工程师视角

• 关注点：事件本质上是数据，代表实体状态。
• 偏好：事件数据单元应足够大，以减少数据团队整合状态的工作量；倾向于同一Topic中事件共享相同模式（即单一事件类型），实现“流表对偶性”。
• 技术实现（以Kafka为例）：同一Topic仅包含一种事件类型，采用TopicNameStrategy。

平衡与建议

仅关注一种视角可能导致后续问题：

• 若仅重视数据：会丢失事件背后的业务原因，将事件协作简化为数据复制。
• 若仅重视触发：当未来需要数据复制场景（如填充数据仓库、引导新服务、更新本地数据投影）时，可能需额外引入宽事件，增加工作量。

作者推荐的做法（平衡双重需求）：

1. 必须包含事件原因：明确代表的业务事件。
2. 必须包含已变更的数据。
3. 可包含额外数据快照：若实体可序列化为足够小的事件，包含完整状态快照可简化消费者处理。但需谨慎设计：
   • 技术层面：事件应保持较小以保证高效复制。
   • 业务层面：事件流本质是API，需像设计REST API一样精心设计事件载荷，避免内部模型变更轻易影响事件结构。

• 实施方式：使用精心设计的宽事件，将事件原因（如SeatSelected）编码在事件类型或头部，序列为BookingUpdated(Reason: SeatSelected)等。

此方法兼顾了事件的叙事性（通过原因）与数据完整性，实现了“两全其美”。

Monokai配色方案的历史

起源与发展 Monokai配色方案由荷兰设计师兼开发者Wimer Hazenberg于2006年创造。其初衷是打造一个既美观又实用的代码编辑器主题，注重可读性与视觉舒适度。该方案最初在macOS的TextMate编辑器上实现，采用深色背景搭配精心挑选的明亮色彩（如关键词用粉色、字符串用香草黄），并降低注释等次要元素的视觉干扰。

名称由来 "Monokai"是Wimer早年（约2003年）使用的网名和公司名，并无特定含义，仅凭感觉选定。其中"Mono"代表个人专注的项目，"kai"取自他人工智能（AI）背景的灵感。

传播与影响 该主题在TextMate社区分享后迅速获得开发者青睐。由于TextMate主题的开放性，众多开发者为其编辑器创建了非官方的"Monokai风格"版本。2013年，Monokai成为Sublime Text的默认主题，进一步巩固了其流行地位。

现代演变：Monokai Pro 为适应现代开发需求，Wimer于2017年推出Monokai Pro。它不仅是更新，更是一次全面升级：

• 提供多种配色滤镜（如"Spectrum"、"Ristretto"及经典"Monokai Classic"）
• 包含超过70个定制图标，实现界面与语法高亮的视觉统一
• 强调一致性设计，所有界面元素（包括语法高亮与UI）都保持协调

跨平台扩展

• Visual Studio Code：同年推出Monokai Pro扩展，为VS Code带来完整的Monokai体验。
• JetBrains IDEs：2025年正式发布适用于IntelliJ IDEA、PyCharm等IDE的版本，支持深色与浅色主题，并针对JetBrains引擎进行了优化。

浅色主题与持续发展 经过多年用户请求，Monokai Pro于2024年推出浅色主题（Light Theme）及"Sun"滤镜。该主题并非简单调亮颜色，而是重新调整了色彩对比度，使其在明亮环境下保持清晰易读。

设计理念与挑战 文章指出，为文本编辑器选择配色是一门"艺术"而非严格的科学。目标是让所有代码颜色具有相同的亮度以便阅读，但人对颜色亮度的感知复杂且主观，目前尚无完美的数学模型能完全匹配人的感知。因此，设计师依赖直觉、经验和反馈来创造和谐的配色。

文化影响 Monokai的影响力已超出开发者工具，出现在《硅谷》、《黑客军团》等影视剧中，并被插画师和生成艺术家广泛使用。

总结 从2006年一个TextMate主题，Monokai已发展为一个标志性的开发工具。Monokai Pro作为其现代演进版本，持续适应新需求，同时坚守清晰与简洁的设计根源，展现了精心设计如何能持久提升开发者的工作环境。

LlamaPReview：AI代码审查工具总结

核心定位

一款基于证据、低噪声的AI代码审查工具，支持一键安装且零配置，旨在通过自动审查GitHub Pull Requests来节省人工审查时间。

主要特点

零配置即时生效

• 安装后立即开始审查新PR，无需YAML配置或规则维护。

免费使用政策

• 公共仓库：完全免费且功能完整。
• 私有仓库：免费提供社区级分析，团队可选用付费高级功能。

上下文感知与证据支持

• 与仅分析差异的普通工具不同，它会检索相关但未修改的代码以理解连锁影响。
• 每个问题都基于真实代码变更行，避免幻觉性评级（如P0/P1）。
• 通过严重性和置信度门控降低噪声，并可生成结构化摘要（表格或序列图）。

关键功能

1. 上下文检索引擎：搜索差异区域外的相关调用点与依赖。
2. 基于证据的发现：高优先级问题包含具体代码片段。
3. 确定性严重性门控：仅在有代码片段支持时升级，推测性问题明确标注。
4. 低噪声优先级排序：次要建议被聚合，维护者可聚焦重要问题。
5. 多语言支持：跨主要生态系统，语言无关推理。
6. 原生GitHub集成：提供行内评论与结构化摘要（表格和可选图表）。

适用场景

为维护者设计，用于减少审查疲劳、提前发现破坏性变更，并通过一致的高信号反馈加速贡献者入职。

安装与使用

• 支持一键安装，开箱即用。
• 开源项目免费，私有仓库提供灵活选项。

如何实现React、Vue和Angular的核心原理——一个文件演示

本文通过一个HTML文件中的原生JavaScript代码，演示了现代前端框架（如React、Vue和Angular）的核心工作原理，包括状态管理、虚拟DOM、差异比较和DOM更新机制。

核心实现概述

代码旨在在一个文件中模拟前端框架的基础架构，主要分为以下几个部分：

1. 状态管理（Hooks模拟）：实现了类似React的useState hook。通过currentComponent跟踪当前组件，使用stateIndex管理状态数组。useState函数返回状态值和更新函数，更新时触发组件重新渲染。

2. 组件系统：createComponent函数创建组件实例，每个组件包含状态数组、渲染函数和渲染方法。渲染时重置状态索引，调用渲染函数生成虚拟节点，并通过差异比较更新DOM。

3. 虚拟DOM（vNode）：h函数（类似React的createElement）创建虚拟节点对象，包含标签（tag）、属性（props）和子节点（children）。虚拟节点用于表示UI结构，便于比较和更新。

4. 差异算法（Diff）：diff函数比较新旧虚拟节点，生成补丁对象。补丁类型包括：

   • CREATE：新节点创建。
   • REMOVE：节点移除。
   • REPLACE：节点替换。
   • TEXT：文本更新。
   • UPDATE：属性和子节点更新，通过diffProps和diffChildren辅助函数详细比较。

5. 补丁应用（Patch）：patch函数将补丁应用到真实DOM。根据补丁类型（如CREATE、REMOVE、UPDATE等），操作DOM元素，如添加、删除或替换节点，更新属性。

6. 示例组件：MyComponent组件使用useState管理计数状态，提供增加和减少功能。通过h函数构建UI结构，包括显示计数的段落和按钮。

7. CSS样式：添加内联样式，为组件（如.my-component）提供美化，包括字体、布局和交互效果（如按钮悬停状态）。

关键功能总结

• 状态更新：调用setCount时更新状态并触发重新渲染，模拟React的响应式行为。
• 高效更新：通过虚拟DOM和差异算法，仅更新变化部分，避免全量DOM操作。
• 组件隔离：每个组件独立管理状态和渲染，支持简单组件化。
• 真实DOM操作：补丁系统将差异应用到DOM，实现UI更新。

如何体现框架原理

• React原理：通过hooks（如useState）和虚拟DOM差异比较，实现声明式UI和高效更新。
• Vue/ Angular原理：相似的状态管理和渲染优化机制，但代码简化聚焦于核心逻辑。

整个代码展示了前端框架如何将组件状态、虚拟DOM和DOM更新结合，以构建动态用户界面。