本文描述了作者在长途航班上通过利用航空公司常旅客账户的姓名字段作为数据通道，实现免费上网的实验项目PySkyWiFi。

核心原理

作者发现航班WiFi登录页面存在漏洞：未付费时仍可登录常旅客账户并编辑个人资料。通过反复读写账户的“姓名”字段，可在地面计算机与机上设备之间建立数据通道，绕过付费WiFi防火墙。

实验过程

1. 即时通讯原型：双方通过更新账户姓名字段交换消息，验证了基本数据传输可行性。作者编写了命令行工具自动化此过程。
2. 信息推送原型：在地面部署守护进程，自动响应机上设备发送的结构化指令（如查询股价、比分），并返回结果。
3. 完整HTTP访问：开发了PySkyWiFi工具，将完整的HTTP请求与响应通过常旅客账户字段分块传输。

PySkyWiFi架构

系统包含两个组件：

• 空中代理：运行在机上笔记本电脑，接收用户的HTTP请求。
• 地面守护进程：运行在联网的地面计算机，执行实际的HTTP请求并返回响应。

通信流程：

1. 空中代理将HTTP请求分割成小数据块。
2. 数据块通过两个常旅客账户的姓名字段（一个用于请求，一个用于响应）以轮询-写入-确认的机制逐块传输。
3. 地面守护进程重组完整请求，执行后，将响应以同样方式反向传输。

关键技术细节

• 传输层：定义了分块、确认、结束的通信协议（DATA、ACK、END段），确保数据完整有序传输。
• 网络层：负责实际的数据读写，与传输层解耦。通过实现简单的send和recv接口，可适配不同平台。
• 编码优化：为适应账户字段对特殊字符的限制，使用Base26编码将数据转换为纯字母字符串。
• 带宽优化：建议同时利用账户的多个字段来增加单次传输的数据量。

备注

作者明确声明此项目仅为技术实验与玩笑，不应实际使用。在开发后期，为避免触发风险，主要使用GitHub Gists等友好服务进行测试迭代。最终通过curl成功加载了作者的博客首页，完成了实验验证。

主要发现

比利时消费者组织Testaankoop发现，Linksys Velop Pro 6E和Velop Pro 7两款Mesh路由器在安装过程中，会以明文形式将Wi-Fi网络的SSID和密码发送至美国的亚马逊AWS服务器。

安全风险

1. 数据泄露：传输的数据包中包含明文Wi-Fi名称（SSID）、密码、网络标识令牌及用户会话令牌。
2. 中间人攻击风险：攻击者若拦截这些通信，可轻易窃取Wi-Fi凭证，从而可能未经授权访问用户网络。

测试与厂商回应

• 测试使用了当时最新的固件（Velop 6E：V 1.0.8；Velop 7：1.0.10）。
• Testaankoop于2023年11月首次向Linksys报告该漏洞，但截至报告发布（2024年7月9日），厂商虽发布过固件更新，并未解决此安全问题。
• Linksys未对消费者的询问和媒体的置评请求作出回应。

建议与结论

• 对现有用户的建议：立即通过路由器的网页管理界面（而非手机App）更改Wi-Fi名称和密码，以避免明文传输。
• 总体建议：Testaankoop鉴于严重的安全风险，强烈建议消费者避免购买Linksys Velop Pro WiFi 6E和Pro 7路由器。

Rye：Python开发工具介绍

重要更新

• Rye 已停止开发，维护者推荐使用其继任项目 uv（活跃维护且使用更广泛）。
• 现有 Rye 用户应参考 uv 迁移指南。Rye 仍可使用，但不再提供后续更新（包括安全更新）。

工具定位

• Rye 是一个面向 Python 的综合性项目与包管理解决方案。
• 设计目标是为所有 Python 用户提供一个一站式管理平台。

核心功能

• 统一管理体验：可无缝安装和管理 Python 版本、基于 pyproject.toml 的项目、依赖项和虚拟环境。
• 适应复杂场景：能够处理复杂项目、单仓库（monorepo），并支持全局工具安装。

目标用户

• 旨在为各级别的 Python 开发者提供无烦恼的开发体验。

文章标题：正确的固执

核心论点：
文章探讨了“坚持”与“固执”的本质区别，指出虽然两者都表现为“不放弃”，但内在机制和最终效果截然不同。

主要区别：

1. 对目标 vs. 对方法的执着：
   • 坚持者 忠于高阶目标，但对实现目标的具体路径和细节保持灵活。他们愿意在决策树的低层级根据新信息调整方法。
   • 固执者 忠于自己最初的想法或方法，即使证据表明其无效。他们拒绝改变，仿佛“舵被锁死”。
2. 对反馈的态度：
   • 坚持者 积极倾听反对意见，渴望发现潜在问题以改进方法。
   • 固执者 拒绝听取不同意见，对问题“充耳不闻”。
3. 行为本质：
   • 坚持 是一种主动的、理性的、结构复杂的行为。
   • 固执 是一种被动的、反射性的、简单的行为。

“坚持”的内在结构： 文章认为，真正的坚持由五种关键特质组合而成：

1. 精力： 持续行动和尝试的动力。
2. 想象力： 不断构思新方法的能力。
3. 韧性： 从挫折中恢复士气，而非被击垮。
4. 判断力： 理性评估进展和期望值，决定何时调整策略。
5. 目标聚焦： 能量和行动需要指向一个相对具体的目标（但不能过于狭隘）。

“固执”的局限性：

• 它是一种更原始、类似“无氧呼吸”的反应，对于非常简单的问题可能有效。
• 在复杂问题上，固执会导致对错误想法的过度坚持，从而降低成功率。
• 固执与能力不足相关，但它本身是一种人格特质，而非单纯由问题难度导致。

结论： 正确的“固执”（即坚持）因其复杂性和稀缺性而极具价值，能产生显著成果。而错误的“固执”则简单、普遍，但在解决复杂问题时往往无效。关键在于区分对目标的坚守与对最初想法的固守。

DB Browser for SQLite (DB4S) 概述

DB Browser for SQLite (DB4S) 是一款高质量、可视化的开源工具，用于创建、搜索和编辑 SQLite 或 SQLCipher 数据库文件。

核心特点

• 界面：提供类似电子表格的直观界面，同时支持完整的 SQL 查询功能。
• 平台支持：兼容 Windows、macOS 以及大多数 Linux 和 Unix 系统。
• 功能全面：能够访问底层 SQLite 数据库的所有功能。

主要功能

通过控件和向导，用户可以执行以下操作：

• 数据库管理：创建与压缩数据库文件。
• 表与索引操作：创建、定义、修改和删除表；创建、定义和删除索引。
• 数据处理：浏览、编辑、添加和删除记录；排序与搜索记录。
• 数据导入/导出：
  • 以文本形式导入/导出记录。
  • 与 CSV 文件相互导入/导出表。
  • 与 SQL 转储文件相互导入/导出数据库。
• SQL 操作：执行 SQL 查询并检查结果；查看应用发出的所有 SQL 命令日志。
• 数据可视化：基于表或查询数据绘制简单图表。
• 加密支持：添加、更改或移除数据库文件的 SQLCipher 加密。

当前状态与版本

• 最新正式版：3.13.0。
• 下载地址：官方发布版可从 https://sqlitebrowser.org/dl/ 获取。
• 夜间构建版：提供未经保证可靠性（可能无法正常工作）的每夜构建版本，位于 https://nightlies.sqlitebrowser.org/latest/。
• 代码签名：Windows 二进制文件的免费代码签名由 SignPath.io 提供，证书来自 SignPath Foundation。

文章概要

本文是Photoroom公司在租赁256个NVIDIA H100 GPU集群后总结的实践指南，重点分享了选择GPU集群时的关键决策因素和经验教训。

核心决策因素

1. 价格与成本

• 价格通常按每GPU小时美元计算，主要受三个因素影响：承诺的GPU数量、租期时长（通常1个月至3年）和预付款比例。
• 除基础租金外，还需考虑支持服务费、存储成本和数据出口费用。应避免100%预付的交易，以保持议价能力。

2. 互连网络与可靠性

• 互连是集群的“神经中枢”，其稳定性直接影响训练中断频率。
• 主要类型为InfiniBand和以太网。测试表明，InfiniBand在速度（吞吐量高出3%-10%）和稳定性上普遍优于以太网解决方案（如AWS的EFA）。
• 以太网在扩展时效率较低，且可能遇到难以调试的错误。建议在自己的工作负载上实际测试后再做决定。

3. 备用节点、位置与SLA

• 新集群的GPU故障率较高，需与供应商明确故障处理流程。
• 备用节点的快速更换能力（如通过API分钟级替换）至关重要。
• 应确保所有节点物理位置邻近以避免网络延迟，并在SLA中规定节点缺少8个健康GPU即视为故障。

4. 存储与数据流

• 为充分利用GPU，需高效的数据供给。Photoroom选择了VAST存储（同一数据中心的专用SSD机器），实现了稳定的~100 Gbps数据流。
• 也可使用节点本地的物理存储（每节点27 TB）配合Ceph等分布式方案，但可能牺牲可靠性。
• 注意：若数据不在本地，高速流式传输的数据出口成本可能极高（例如，从AWS区域以100 Gbps流式传输，每月成本可达数百万美元），因此通常需提前迁移或缓存数据。

5. 支持与响应

• 能否直接通过共享Slack频道与集群管理的工程师沟通，是解决问题效率的关键。大型供应商通常不提供此服务。
• 应在合同中明确支持响应时间的SLA。

6. 部署与管理方式

• 主要选项包括：裸金属、Kubernetes (K8s)、SLURM 和虚拟机 (VMs)。
• Photoroom选择了虚拟机方式，由供应商管理底层监控，他们自行搭建SLURM，虚拟化性能损失小于1%。

其他重要建议

• 坚持测试：在承诺前，要求进行至少48小时不间断运行测试，并尽可能在实际租赁的同一集群上进行。可从小规模（如4个节点）开始调试。
• 行业利用率低：行业平均GPU利用率仅30%-50%，主要原因是企业为确保随时可用性而预订资源，而非按需服务。
• 环保考量：大规模GPU集群碳排放显著（约1000吨CO2/年）。部分供应商使用绿色电力（如水电、地热）或碳补偿。这应成为选择供应商的考量因素之一。
• 其他技巧：
  • 询问集群确切可用日期并在合同中约束。
  • 确认集群经过充分老化测试。
  • 注意租赁的是H100 SXM5版本（而非性能较低的PCIe版本）。
  • 了解GPU的所有权关系，多层中间商可能增加故障处理复杂度。
  • 有机会可考虑H200（内存更大，据称价格相似）。
  • 询问数据中心的具体名称和运营商经验。

最终选择与结论

Photoroom最终选择了德国供应商Genesis Cloud，因其提供InfiniBand互连和基于水电的无碳排放电力。文章强调，在选择GPU集群时，可靠性、性能与环境责任都应纳入权衡。

Crawlee for Python 简介

Crawlee 是一个用于 Python 和 JavaScript 的 Web 抓取和浏览器自动化库，旨在帮助用户快速构建可靠的网络爬虫。它能够自动处理反爬虫机制、爬虫管理、代理轮换以及浏览器控制等复杂任务。

核心功能与优势

1. 默认突破封锁：Crawlee 以隐身模式爬取，无需额外配置即可应对常见的网站保护措施，同时支持自定义行为。它内置了真实浏览器的指纹生成能力。

   fingerprint_generator = DefaultFingerprintGenerator(
       header_options=HeaderGeneratorOptions(
           browsers=['chromium', 'firefox'],
           devices=['mobile'],
           locales=['en-US']
       ),
   )
   

2. 与常用工具集成：无缝集成 BeautifulSoup、Cheerio、Puppeteer、Playwright 等流行的开源工具，用户可以使用熟悉的语法，无需学习新工具。
3. 统一的 API：提供一致的 API 接口，支持在 HTTP 请求和无头浏览器模式之间轻松切换，甚至可以通过自适应爬虫自动判断是否需要 JavaScript 渲染。

   crawler = AdaptivePlaywrightCrawler.with_parsel_static_parser()
   

4. 便捷的模板与CLI：可以通过命令行工具快速创建项目模板，例如使用 uvx 'crawlee[cli]' create my-crawler。

代码示例

以下示例展示了使用 PlaywrightCrawler 抓取网页、提取数据并保存到 CSV 文件的基本流程：

import asyncio
from crawlee.crawlers import PlaywrightCrawler, PlaywrightCrawlingContext

async def main() -> None:
    crawler = PlaywrightCrawler(
        max_requests_per_crawl=10,
        headless=True,
        browser_type='firefox',
    )

    @crawler.router.default_handler
    async def request_handler(context: PlaywrightCrawlingContext) -> None:
        # 提取页面数据并推送到数据集
        data = {'url': context.request.url, 'title': await context.page.title()}
        await context.push_data(data)
        # 入队页面中的所有链接
        await context.enqueue_links()

    await crawler.run(['https://crawlee.dev'])
    await crawler.export_data('results.csv')

if __name__ == '__main__':
    asyncio.run(main())

部署与云服务

Crawlee 可以部署在任何环境中，但与 Apify 平台集成时能获得最佳体验。用户可以将项目转换为 Apify Actor（一种无服务器微应用），该平台提供内置的基础设施、代理和存储支持。

总结

Crawlee 旨在简化可靠爬虫的构建和维护过程，使开发者能够专注于核心业务逻辑。它是一个免费且开源的工具，由 Apify 团队开发并提供支持。

终端文本输入的复杂性

核心问题：程序间的不一致性

在终端中输入文本的主要困难源于不同程序处理输入方式的巨大差异：

• 基准程序（如 cat, nc）：不支持方向键，按方向键会显示转义序列（如 ^[[D）。
• 使用 readline 的程序（如 bash, irb, psql）：提供基础编辑功能（历史记录、方向键、Ctrl+R 搜索）。
• 部分功能支持的程序（如 macOS 默认的 /usr/bin/python3）：支持方向键，但不支持 Ctrl+左/右跳词等功能。
• 自定义输入系统（如 fish, vim, ipython）：拥有完全定制化的输入处理机制，可能包含更高级的功能（如撤销、更智能的补全）。

四种输入模式详解

1. 基准模式

程序仅通过 fgets() 等基本函数接受输入，不做额外优化。

• 免费获得的功能：基本输入、退格、Ctrl+W（删除前一个单词）、Ctrl+U（删除整行）、Ctrl+C（中断进程）等。
• 诊断方法：运行 stty -a 查看终端支持的所有控制码。
• 工具增强：使用 rlwrap 可为任何程序（如 nc）添加 readline 支持，极大提升可用性。

2. 使用 readline 的程序

readline 是一个广泛使用的 GNU 库，提供丰富的编辑功能。

• 常用快捷键：
  • Ctrl+A / Home：跳至行首
  • Ctrl+E / End：跳至行尾
  • Ctrl+左/右方向键：按单词移动
  • Ctrl+R：反向搜索历史命令
• 使用范围：bash、psql、irb 等众多交互式程序。
• 未使用 readline 的可能原因：依赖项过大、许可证不兼容（readline 为 GPL）、交互部分极少（如 git add -p）。
• 诊断方法：按 Ctrl+R，若显示 (reverse-i-search) 则通常使用 readline。

3. 其他输入库（如 libedit）

libedit 是功能较少的替代库，常用于许可证不兼容（如 macOS 默认的 Python 3）或追求轻量的场景。

• 特征：支持基本编辑（如方向键），但缺少部分 readline 功能（如 Ctrl+左/右跳词 可能无效）。
• 识别：可通过检查程序文档或模块信息（如 Python 中 readline.__doc__）确认。

4. 自定义输入系统

许多程序（特别是终端编辑器、高级 Shell 和 REPL）实现了完全自定义的输入处理。

• 示例：vim、emacs、fish、ipython（使用 prompt_toolkit）、atuin。
• 特点：通常提供更优秀的上下文补全、历史管理、语法高亮和更多快捷键。
• 设计趋势：许多自定义系统受 readline 启发，以兼容用户习惯，同时扩展功能。

实用建议与技巧

• Vi 模式：bash、zsh、fish 等均支持 Vi 风格的键位绑定（通过 readline 的 Vi 模式或内置实现）。
• 诊断流程：
  1. 方向键无效 → 可能是基准模式，尝试 rlwrap 或使用 Ctrl+W/Ctrl+U。
  2. Ctrl+R 显示 reverse-i-search → 可能是 readline，可使用熟悉的标准快捷键。
  3. Ctrl+R 反应不同 → 可能是自定义库，行为通常类似 readline，必要时查阅文档。

未涵盖的复杂因素

文章提及但未深入讨论的方面包括：

• SSH、tmux 等远程/复用环境的影响。
• TERM 环境变量的作用。
• 不同终端模拟器（如 GNOME Terminal, iTerm）在复制粘贴等功能上的差异。
• Unicode 支持问题。

BitWHIP 是一个使用 Rust 编写的命令行 WebRTC Agent，主要功能包括以约 30 毫秒的超低延迟共享桌面、在本地播放器中播放流，以及从支持 WHIP/WHEP 协议的多种来源（如 Broadcast Box、Cloudflare 等）拉取 WebRTC 视频并播放。它基于开放协议构建，兼容 OBS、FFmpeg、GStreamer 等常用工具。

构建方式：项目使用 just 工具简化依赖安装和构建过程。用户需先通过 cargo install just 安装 just，然后执行 just install-deps 来安装所有依赖项。

主要使用模式：

1. Play WHIP：启动一个本地 WHIP 服务器，客户端（如 BitWHIP、OBS 或 GStreamer）可向其推送视频流。默认使用 URL http://localhost:1337/。
2. Play WHEP：连接到一个远程 WHEP 服务器并播放视频。例如，连接到指定 URL 并使用提供的 Bearer Token，即可在本地播放器中观看流。
3. Stream（目前仅支持 Windows + NVIDIA 显卡）：捕获本地桌面并通过 WHIP 协议发布到指定的服务器 URL。

未来计划（TODO）：

• 创建程序二进制文件。
• 改进构建系统。
• 支持更多的屏幕捕获方式（如 Linux 的 x11grab）。
• 支持更多的视频编码器（如 QuickSync、x264）。

项目还提及了另一个实现了 0-16ms 延迟的远程桌面方案 Selkies-GStreamer，并提供了 Discord 社区支持链接。

Z-Library 管理员在获批引渡后逃离软禁

事件背景与逮捕

2022年11月，美国司法部和FBI查封了“影子图书馆”Z-Library的域名，并指控两名俄罗斯公民 Anton Napolsky 和 Valeriia Ermakova 为该网站运营者。两人在阿根廷旅行时，因国际刑警组织红色通缉令被当地执法部门追踪，并于2022年11月3日在阿根廷被捕。2023年1月，阿根廷法官批准对两人实行软禁。

引渡抗争与法官回避

美国以刑事版权侵权、电信欺诈和洗钱罪对两人提出引渡请求。两人否认所有指控并极力反对引渡。辩护律师指出美国的引渡请求存在未明确具体侵权作品等缺陷。主审法官 Sergio Pinto 允许美方延期补充材料，辩护方据此指控法官偏袒美国，并成功申请其回避。

批准引渡与寻求难民身份

新法官 Sánchez Freytes 接手案件后，认为基于美方指控，将两人引渡至美国是适当的。为阻止引渡，两人向阿根廷最高法院上诉，寻求获得政治难民身份。

逃离软禁与下落不明

在等待裁决期间，负责监督软禁执行情况的机构在5月进行例行检查时，发现两人已不知所踪，辩护律师也表示无法联系到他们。法官接报后立即下达了国际逮捕令。尽管初期曾推测两人尚未离境，但数周过去仍无抓捕消息，两人目前下落不明。

MobileLLM：为设备端优化的亚十亿参数语言模型

本文介绍了 MobileLLM，这是一个专为在移动设备上高效运行而设计的、参数规模低于10亿的语言模型系列。其核心研究发表于ICML 2024，并提供了完整的训练代码。

核心设计与优化

MobileLLM通过综合考虑多种设计因素来提升小参数模型的质量，主要集成了四项关键技术：

1. SwiGLU 激活函数
2. 深度而窄的架构
3. 嵌入共享
4. 分组查询注意力

基于这些设计，MobileLLM-125M/350M 在零样本常识推理任务上，分别比当时的先进模型（SoTA）取得了 2.7%/4.3% 的显著准确率提升。后续版本证明，这一设计哲学能有效扩展至更大规模的模型，MobileLLM-600M/1B/1.5B 均取得了当时的最优结果。

重要更新与后续工作

• MobileLLM-R1.5（2025年11月发布）：950M参数的模型在数学和代码基准测试上全面超越了拥有1.5B参数的 DeepSeek-R1-Distill-Qwen-1.5B。
• MobileLLM-R1（2025年9月发布，2026年1月被ICLR接收）：仅使用约2T预训练 token，在MATH、GSM8K、MMLU等基准上匹配或超越了使用36T token训练的 Qwen3-0.6B。

使用方法

1. 环境要求：Python 3.9，PyTorch >= 2.0。
2. 数据处理：将数据集分词并分片到训练节点，形成指定的目录和.jsonl文件格式（每行包含 {"token_ids": [...]}）。
3. 训练：使用提供的 pretrain.sh 脚本在1x8节点上启动训练。需要根据节点数量和批次大小线性调整学习率。
4. 评估：修改 eval.sh 中的模型路径，在Wiki上进行评估。

训练成本

使用32块NVIDIA A100 80G GPU训练1T token所需时间：

评估结果

MobileLLM在不同参数规模下均展现出优异性能，尤其是在零样本常识推理任务（如ARC、HellaSwag、PIQA等）上，平均准确率大幅领先于同类基线模型（如OPT、Pythia、MobiLlama等）。

相关信息

• 代码基础：部分基于HuggingFace Transformers。
• 相关项目：SpinQuant、LLM-QAT。
• 许可证：目前采用 FAIR NC 许可证。
• 联系人：Zechun Liu，Changsheng Zhao（Meta）。

• 免费试用活动：Serif公司为其Affinity创意套件（包括Affinity Photo、Affinity Designer和Affinity Publisher）推出了为期六个月的免费试用，适用于Mac、Windows PC和iPad。
• 定价模式与优惠：Affinity采用一次性购买模式（桌面单应用69.99美元起，全套件164.99美元），目前永久许可证可享五折优惠。这种定价吸引了众多反感Adobe订阅制的创意工作者。
• 背景与意图：此活动旨在缓解用户对Affinity被Canva收购后可能改变定价模式的担忧，鼓励用户零成本尝试，且无购买义务。
• 市场竞争意义：Canva CEO Melanie Perkins指出，设计软件市场长期由Adobe主导，缺乏竞争，Affinity作为替代方案的出现对专业设计师和整个行业均有益处。

Anna's Archive是一个影子图书馆的元搜索引擎，允许用户搜索盗版书籍及相关资源。该网站于2022年秋季上线，旨在Z-Library因美国刑事打击而关闭后，继续为公众提供“免费”图书和文章。

去年年底，Anna's Archive扩展了其服务范围，将OCLC专有的WorldCat数据库信息在线公开。其运营者耗时一年多抓取了数TB数据，并发布了约7亿条唯一记录供免费使用。这次“元数据”抓取行动对网站内容存档目标是一次重大突破，但引起了OCLC的强烈不满。OCLC随后在美国俄亥俄州联邦法院提起诉讼，指控该网站及其运营者实施黑客攻击，并索赔损失。

OCLC称，为应对此次抓取攻击已花费超过100万美元，且未能阻止数据通过种子文件传播。诉讼提交后，Anna's Archive的运营者未在法庭作出回应，唯一被点名的被告否认与该网站有关联。由于被告缺席，OCLC已申请缺席判决，要求获得宣告性判决、禁令救济及金钱赔偿。

在损失方面，OCLC列出了高达530多万美元的直接损失，包括：154.8万美元用于硬件升级、60.8万美元用于为期两年的Cloudflare防护合同，以及34名全职员工的相关薪资和其他调查、安全及硬件成本。OCLC强调，损害仍在持续，实际损失仍在增加，且无法完全通过金钱赔偿弥补。

除了金钱赔偿，OCLC还寻求禁令救济，要求禁止Anna's Archive今后再抓取WorldCat数据，并要求销毁所有已抓取的数据及现有种子文件。OCLC指出，多个国家和出版商已通过网站封锁令认定其活动非法（如意大利和荷兰），并呼吁通过禁令遏制其持续违法行为。

目前，诉讼尚未提出在美国实施网站封锁的具体请求。值得注意的是，Anna's Archive近期将主域名从受美国法院管辖的.org切换至受英国监管的.gs域名，增加了执法复杂性。但据悉.gs域名已失效，网站暂时恢复使用.org域名。整体而言，尽管OCLC在法律上占据优势，但执法行动仍面临挑战。

Turbopuffer：基于对象存储的快速搜索引擎

核心问题与动机

创始人Simon在2022年帮助Readwise开发推荐功能时，发现基于向量嵌入的语义搜索成本极高：在原有关系数据库上，1亿+文档的向量搜索成本可能超过每月2万美元，远高于关系数据库的5千美元。这导致许多有价值的功能因基础设施成本过高而被搁置。现有搜索引擎不仅昂贵，在大规模下也极难运维。作者认为，随着对象存储（如S3）普及、高速NVMe SSD普及以及AI/向量需求增长，搜索引擎的设计理念需要根本性更新。

核心解决方案：对象存储优先的架构

Turbopuffer提出了一种全新的成本与性能平衡方案。其核心是将对象存储作为主要的、廉价的数据持久层，结合SSD/内存缓存来加速热数据。

• 成本对比：传统方案（内存+3倍SSD）每TB每月成本约3600美元；Turbopuffer方案（对象存储+SSD缓存）仅需约70美元，实现了高达50倍的成本降低。
• 设计哲学：搜索引擎的写入模式（高吞吐、无事务、低延迟要求）更接近数据仓库，而非传统关系数据库。因此，不需要为高性能的三副本SSD存储支付溢价。查询则通过缓存层保证低延迟（热查询<20ms），偶发的冷查询（来自对象存储）虽延迟较高（~500ms），但成本节约巨大，对大多数用例是可接受的。

架构与关键特性

1. 对象存储原生存储引擎：数据直接、持久地写入对象存储，以此为唯一真实来源（LSM）。这不同于传统的“分层存储”（冷数据最终备份到对象存储），避免了复杂的同步。
2. 极致可靠性与扩展性：
   • 无关键路径依赖：除对象存储外，无其他有状态依赖，简化了运维，保证了高可用性（自上线以来达到99.99%可用性）。
   • 原生多租户与分片：数据以命名空间（namespace）为单位隔离和分片，任何一个节点都能加载并服务任何命名空间，故障节点的数据通过一次冷查询即可恢复。
   • 水平扩展：依托对象存储，可近乎无限地扩展存储和吞吐量。
3. 性能优化：
   • 智能缓存：通过SSD和内存缓存热数据，实现低延迟查询。
   • 查询优化：精心设计查询计划器，限制访问对象存储的往返次数（如向量搜索限制在最多三次往返），以优化冷查询延迟。
   • 性能数据示例：
     • 100万768维向量（3GB）：冷查询p90延迟444ms，热查询p90延迟10ms。
     • 100万文档BM25全文检索（300MB）：冷查询p90延迟285ms，热查询p90延迟18ms。

市场验证与客户

• 典型案例：Cursor：AI代码编辑器，需为每个代码库创建向量索引。迁移至Turbopuffer后：
  • 成本降低95%。
  • 可以更自由地为每个用户创建更多向量，因为成本不再与价值脱钩。
  • 在代码检索中添加语义搜索，使自评估性能提升高达23.5%。
• 其他客户：Notion AI、Linear的问题搜索、Superhuman的邮件搜索、Telus的企业AI助手等。
• 系统规模：托管超过4万亿份文档，处理每秒1000万+写入，服务每秒2.5万+查询。

总结

Turbopuffer通过革命性地采用对象存储作为主存储，结合高效的缓存层，解决了现代搜索引擎面临的高昂成本和运维复杂性难题。它实现了成本与价值的合理映射，使得此前因昂贵而被搁置的功能（如大规模向量搜索）变得可行，特别适合处理多租户、部分数据活跃的工作负载，并已在多个领先AI产品中得到验证。

文章主张起诉波音公司高管以解决其问题，背景是2024年6月18日参议院听证会“Boeing’s Broken Safety Culture”，期间事故受害者家属展示了亲人照片。作者Joe Nocera认为，5亿美元的罚款不足以惩罚一个导致346人死亡的公司，指出波音公司因其作为美国唯一商用飞机制造商的地位而掌控政府：拥有超过170,000名员工，分布在华盛顿州、南卡罗来纳州和弗吉尼亚州，员工薪酬属中产至上中产阶级，且按美元交易量计算是美国最大的出口商，对国家经济具有关键影响。

项目概述
作者计划自制婚戒，采用失蜡铸造（使用3D打印件替代传统蜡模）工艺。核心步骤包括：3D打印戒指模型、制作石膏模具、高温烧蚀模型、熔融金属浇铸、后期打磨抛光。最初计划使用纯金，但因成本改用纯银进行试验。

设备与材料
购置了铸模石膏、铸造铁管（后改用钢管）、真空泵与腔室（用于脱泡）、电窑（烧除模型）、手持火炬（熔金属）、坩埚、硼砂、钳具及5盎司纯银。后续根据问题调整了部分设备。

试验过程与问题

1. 初次试验：使用纯银和基础流程，成品存在缺陷。发现纯银易溶解氧气，在凝固时产生气泡；且纯金属凝固速度快，难以填充模具细节。
2. 改进措施：改用90%银+10%金合金以改善流动性，并搭建真空系统辅助浇铸（抽出氧气、增强金属填充）。
3. 后续问题：真空底座的橡胶密封件受热熔化失败，改用耐高温硅胶；但因模具冷却过快、金属温度不足，铸件仍有缺陷。
4. 成功尝试：调整浇铸时机（避免模具过度冷却）、延长金属加热时间，最终获得表面光滑的铸件。后期进行锤击处理形成 facets 效果（因伴侣偏好）。

最终成品与特性

• 戒指表面保留轻微3D打印层纹，经锤击与抛光后呈独特质感。
• 结构优势：内部柔软（防摔裂）、外层经锤击加工硬化（抗划痕），且可通过再次锤击修复划痕。
• 材料选择：纯银（高反光性）与微量黄金合金的搭配避免了铜合金易氧化、反光弱的问题，同时具备抗腐蚀性（但纯银可能因硫化物 tarnish，需偶尔抛光）。

项目总结

• 耗时6个周末（跨3个月），成本约3500美元（其中黄金占2300美元，设备约1000美元，白银125美元）。
• 核心挑战：理解金属化学特性（氧气溶解、合金凝固行为）与铸造工艺细节（温度、真空度）。
• 作者认为自制戒指虽成本高于市售商品，但具有独特情感价值与叙事性，过程中积累的经验与解决问题的过程亦反映关系经营的隐喻。
• 感谢珠宝匠 James Binnion 的公开资料对项目的帮助。

附注
作者后期尝试用剩余黄金直接锤锻成型戒指，并提到黄金密度高（1.7倍于银/铅），质感与声音独特。但最终仍选择铸造工艺，因锤锻难以实现复杂设计且纯金软度过高。

背景与事件起因

漫画创作组合（war.and.peas）频繁收到AI公司的合作邀请，要求推广自动化内容生成产品。作者对当前生成式AI的炒作表示强烈反感，指出这种炒作建立在窃取创意作品的基础之上，并试图将创作过程变成自动化内容生成的噩梦。

AI公司的合作提议

一家名为Muse的公司邀请作者合作推广其AI平台。该平台声称能让用户在“无需个人内容创作”的情况下，利用AI生成剧本、角色和迷你剧等进行故事讲述，并邀请作者成为首批合作创作者以获取早期优势。

作者拒绝的核心理由

作者明确拒绝了该邀请，并列举了以下主要原因：

• 剥削创意群体：AI的发展依赖于未经同意且未获补偿地“收割”艺术家的作品来训练大型语言模型。
• 商业模式不公：社交平台依靠人类的原创内容实现增长，但创作者未能获得应有的回报。作者拒绝任何不认可创作者价值且不提供合理补偿的商业模式。
• 破坏创作的本质：艺术家热爱创作，不愿将热情外包给机器。故事讲述是作者与读者之间的个人连接，“无需个人内容创作”的理念极其可怕，失去这种个人连接将使故事讲述失去意义。
• AI工具定位错误：艺术家更需要AI来协助处理开发票、报税等繁琐的日常行政事务，以便将精力集中于创意工作，而非让AI替代创作本身。

最终立场与呼吁

作者认为，该AI平台不仅对创作者无益，反而违背了尊重和提升创意工作价值的理念。它将创意工作贬低为流水线作业，旨在为社交媒体的“注意力工厂”批量生产衍生且缺乏灵魂的“内容”。作者呼吁摒弃此类模式，转向更具包容性、真正以艺术家为中心的发展路径。

本文针对延迟关键代码优化，特别是高频交易系统，旨在弥补相关知识缺口。研究主要包含三项贡献：建立低延迟编程资源库、优化市场中性统计套利配对交易策略，以及用C++实现Disruptor模式。资源库作为实用指南，配合了严谨的统计基准测试；交易策略优化显著提升了速度与盈利能力；Disruptor模式相比传统队列方法展现出明显的性能优势。评估指标涵盖速度、缓存利用率、统计显著性等。其中，缓存预热和Constexpr技术对延迟降低效果最为显著。未来研究方向包括扩展资源库、在实际交易环境中测试优化后的交易算法，以及将Disruptor模式与交易算法集成以进行系统级基准测试。该研究面向学术界及行业从业者，旨在提升延迟敏感应用的性能。

根据英国和荷兰环保组织Feedback的报告，挪威三文鱼养殖业每年使用近200万吨野生鱼类生产饲料用鱼油，这一规模相当于全球海洋捕捞量的2.5%。报告指出，该行业在西非国家冈比亚、塞内加尔和毛里塔尼亚海域捕捞野生鱼类，导致当地社区生计受损和营养不良加剧。

西非小规模渔业是当地原住民社区的重要生存手段，但大型渔船为鱼粉和鱼油工业捕捞鱼类，威胁了这些社区的尊严与生存。报告估算，2020年从西非海域捕捞用于挪威养殖三文鱼饲料的鱼类，原本可为该地区最多400万人提供一年的鱼类供应。

挪威养殖业计划到2050年将产量增至500万吨，这意味着对野生鱼类的需求将比2020年增加三倍以上。行业四大饲料供应商——Mowi、Skretting、Cargill和Biomar——均从西北非采购鱼油。其中，Mowi在2020年从毛里塔尼亚采购了5100吨鱼油，相当于消耗了2.83万吨鱼类。

西非地区鱼类资源出现显著下降：2020至2021年间，毛里塔尼亚沙丁鱼捕捞量下降66%，塞内加尔下降86%，冈比亚下降16%。鱼粉工厂的不公平竞争导致许多从事小规模鱼类加工的妇女失业，小规模渔民收入锐减，当地人均鱼类消费量也大幅下滑（如冈比亚从2020年的15公斤降至2021年的8公斤）。

环保组织Feedback和WildFish呼吁英国连锁餐厅Wagamama停止供应养殖三文鱼，并指责该行业以“蓝色革命”为名扩张，实则进行“食物帝国主义”，加剧西非饥饿问题。

文章主要探讨了理论计算机科学中一个常见的概念误用现象，作者将其称为“僵尸误解”。核心问题是：人们经常错误地将适用于函数或无限序列的计算理论概念（如可计算性、NP难度）应用于单个整数或孤立的是非问题上。

具体表现为几个典型误解：

1. 对可计算性的误解：通过Sipser教材中的思想实验（如“若上帝存在则函数输出1，否则输出0”）说明，可计算性是针对函数整体的性质，即使函数的定义依赖于未解问题，只要其最终值为常数函数，它就是可计算的。
2. 对P vs NP问题的误解：有人提问“P vs NP问题本身是否可能是NP难题”。作者指出，NP难度适用于带输入的语言或函数，而P vs NP是一个具体的二元问题，其答案（无论为何）都对应一个简单的打印程序，因此该问题本身不存在“NP难度”的概念。
3. 对Busy Beaver函数值的误解：虽然Busy Beaver函数整体不可计算，但针对具体整数n（如BB(6)），其值是一个确定的整数，因此“打印该整数”的程序必然存在，单个值始终是可计算的。不可计算性指的是无法为所有输入统一写出计算函数值的程序。

作者进一步解释，这种误解根源在于混淆了：

• 不可计算性（针对无限对象）与个体值的不可判定性。
• 图灵机不可计算性（绝对概念）与哥德尔不完备性（相对公理系统，可讨论个体命题）。

最后，作者呼吁讨论如何纠正这种反复出现的误解，旨在通过本文提供一个可链接的澄清资源，以应对类似质疑。

Tegon：Jira与Linear的开源替代品

产品定位

Tegon是一个面向开发者的问题追踪工具，核心特点是开源、可定制、轻量级。它旨在解决现有问题追踪工具的不足：要么过于臃肿以适应各种流程，要么过于简单无法处理复杂场景。传统工具主要作为“记录系统”，而Tegon的目标是成为记录、上下文与行动三位一体的系统，通过与其他工具的深度集成提供工作上下文，并通过自动化行动提升组织生产力。

部署与访问

• 自托管：支持本地部署。
• 托管云服务：提供云版本（app.tegon.ai），用户可注册账户并开始创建问题。
• 快速入门：包含自托管指南和本地设置说明，并提供演示视频。

核心功能

1. 基础问题管理：添加、筛选、排序、编辑和追踪问题。
2. 视图支持：
   • 看板视图：可视化追踪工作进度。
   • 自定义视图：根据需求创建个性化视图。
3. Triage收件箱：集中管理所有传入请求。
4. 自动化集成：
   • 通过Slack的👀表情符号自动创建问题。
   • 未来将扩展更多自动化能力。

Tegon Actions（自动化框架）

一个用于自动化重复任务的框架，示例场景包括：

• 问题创建时自动打标签。
• PR开启时自动生成评审子问题。
• 从Slack使用表情符号直接创建问题。
• 每周在Slack发送已完成问题的摘要和变更日志。

  详细文档参见Actions文档。

开发状态与路线图

• 当前阶段：Alpha版本开发中，可能存在破坏性更新。
• 未来计划：
  • 频繁更新功能。
  • 提供自定义工作流工具，支持用户扩展和定制Tegon。
  • 鼓励用户通过创建Issue提出具体需求。

社区与参与

• 开源：仓库已公开，欢迎贡献。
• 资源：提供文档、Twitter/LinkedIn动态更新、Slack社区。
• 支持方式：Star仓库、查阅文档、加入社区讨论。

The Deadlock Empire: 交互式锁指南

核心目的：这是一个旨在通过交互式挑战来教授和理解**锁（Locks）与死锁（Deadlock）**概念的在线教育工具。

主要功能与结构：

• 界面：包含一个工具栏，用户可通过“Select level”选项选择不同的关卡或挑战。
• 交互模式：用户通过解决特定的并发编程问题或场景来推进。
• 即时反馈：系统会提供明确的结果提示，包括“You win!”（成功通过挑战）和“Challenge lost!”（挑战失败），以此引导用户学习。

教学重点：该指南的核心是通过实际操作和模拟，帮助学习者直观地理解多线程编程中锁的使用、潜在问题以及死锁产生的条件，从而提升编写并发程序的能力。

Plausible Analytics：无需Cookie同意横幅的GDPR合规分析工具

产品概述

Plausible Analytics 是一个注重隐私的网站分析工具，作为 Google Analytics 的替代方案而构建。它旨在解决 Google Analytics 使用复杂、加载缓慢且侵犯隐私的问题。该工具专注于提供简单、轻量且隐私友好的分析服务，已获得超过 18,000 名付费客户的信任。

核心优势

1. 简洁直观的数据展示

   • 提供一站式仪表盘，无需复杂菜单或多层报告。
   • 用户可在一分钟内获取网站流量和核心洞察。
   • 支持合并查看所有网站数据，并允许导入 Google Analytics 历史数据。

2. 轻量级脚本保障网站速度

   • 分析脚本比 Google Analytics 小 54 倍，为每位访客减少约 135KB 的 JavaScript 加载量。
   • 降低数据传输量，从而减少能源消耗和碳排放。以月访客量 10 万的网站为例，每年可节省约 4 公斤二氧化碳排放。

3. 隐私优先与 GDPR 合规

   • 不处理个人数据，不追踪独立用户。
   • 无需 Cookie、持久标识符，也不进行跨站点或跨设备跟踪。
   • 网站数据不用于任何其他目的。
   • 所有访客数据均在欧洲公司拥有和运营的服务器上处理，且绝不离开欧盟范围。
   • 因此，网站无需部署 Cookie 同意横幅即可符合 GDPR 等隐私法规。

团队与商业模式

• Plausible 由 Uku 和 Marko 于 2018 年联合创立，是一个完全独立、自筹资金且盈利的 10 人团队。
• 没有外部投资者，不以被收购为目标。
• 采用订阅制商业模式，拒绝“监控资本主义”。
• 代码开源，确保用户无厂商锁定风险。

CVE-2024-6409：OpenSSH特权分离子进程中可能的远程代码执行

该漏洞是一个在OpenSSH特权分离（privsep）子进程信号处理中发现的竞态条件，可导致远程代码执行（RCE）。它是在审查CVE-2024-6387时由Solar Designer发现，并由Qualys完成分析确认。

漏洞核心

在OpenSSH 8.7p1和8.8p1版本中，特权分离子进程的grace_alarm_handler()信号处理器会调用cleanup_exit()函数。cleanup_exit()并非设计用于信号处理器内部，可能调用其他异步信号不安全的函数。

• 上游版本分析：在上游代码中，当在特权分离子进程中调用时，cleanup_exit()的逻辑可能是安全的，因为它主要执行的清理操作（如do_cleanup）在子进程中实际无害。
• 关键触发点（下游补丁）：问题在于Red Hat的审计补丁 openssh-7.6p1-audit.patch。该补丁为cleanup_exit()添加了代码，使其在调用时会执行 destroy_sensitive_data() 和 packet_destroy_all() 等操作。其中 packet_destroy_all() 会调用 packet_destroy_state()，后者内部广泛使用 free()，这是异步信号不安全的函数，从而引入了竞态条件和RCE风险。

影响范围

该漏洞影响所有应用了上述特定审计补丁、且基于OpenSSH 8.7p1 或 8.8p1 的软件包。

• 主要受影响系统包括 RHEL 9 及其衍生版（如Rocky Linux）。
• Fedora的 36 和 37 版本（已停止支持）也受影响，因为它们基于这些OpenSSH版本且包含该补丁。
• 新版Fedora（38+）及使用未打该补丁的更新版本OpenSSH的系统不受影响。

与CVE-2024-6387的关键区别

1. 触发环境与权限：CVE-2024-6387的竞态条件发生在父进程中，而CVE-2024-6409发生在特权分离子进程中。子进程权限被降低，因此潜在影响较低。
2. 缓解措施差异：针对CVE-2024-6387的“-e”日志缓解措施无法完全防护CVE-2024-6409。但“LoginGraceTime 0”缓解措施对两者均有效。
3. 利用可能性：虽然CVE-2024-6409的即时影响较小，但在特定场景下可能更具可利用性。攻击者可能根据目标环境和条件选择更合适的漏洞进行利用。

修复方案

核心修复是将特权分离子进程中对cleanup_exit(255)的调用替换为直接的_exit(1)，以避免执行任何异步信号不安全的清理代码。

// 修复前
if (use_privsep && pmonitor != NULL && pmonitor->m_pid <= 0)
    cleanup_exit(255); /* don't log in privsep child */

// 修复后
if (use_privsep && pmonitor != NULL && pmonitor->m_pid <= 0)
    _exit(1); /* don't log in privsep child */

相关分析

• 审计补丁（openssh-7.6p1-audit.patch）还存在另一个问题：其用于销毁敏感数据的 audit_destroy_sensitive_data() 函数中 sshkey_is_private() 的检查存在缺陷（对于ed25519密钥检查了公钥字段而非私钥字段），导致在特权分离子进程中记录了错误的密钥销毁审计日志。这本身不是一个安全漏洞，但解释了为何在漏洞触发时会进行更多不安全函数的调用。
• 实际利用CVE-2024-6409尚未被尝试或证实，但理论上由于存在竞态条件和异步信号不安全的函数调用，存在RCE的可能。

氦气密封硬盘竞赛（2021）摘要

氦气硬盘的价值与挑战
氦气是大容量硬盘的重大突破。其密度仅为空气的七分之一，能减少盘片旋转时的阻力与湍流，实现更低运行温度和更优防潮性。这些优势直接带来存储容量大幅提升、功耗降低和可靠性增强。然而，氦气原子极小，极易从密封缝隙中泄漏，加上需符合现有硬盘规格与制造流程，数十年来实现商用氦气硬盘被视为不可能。

突破历程：从实验室到量产

1. 早期研究（IBM时期）

   • 1998年，物理学家Barry Stipe加入IBM，攻关氦气密封技术。他摒弃了传统堵漏方法，转向金属箔盖板与焊接技术。
   • 关键借鉴卫星激光焊接（热影响区小）与冰箱玻璃金属馈通器（低成本密封引线），结合镍镀层解决焊接附着力问题，最终在实验室实现理论上可密封百年的方案。

2. 工程化攻关（日立时期）

   • 2003年，日立机械工程师青柳明彦领导团队将实验室方案推向制造。
   • 解决了合金铸造气泡爆炸、激光焊接参数优化等难题，创新“边缘焊接”工艺，获得日本专利与发明奖。
   • 项目一度因制造成本高被终止，但青柳明彦坚持以单人工程师身份继续研发。

3. 商业化与爆发

   • 2009年，大数据与云计算兴起推动高容量硬盘需求激增，项目重启。
   • 2013年，西部数据（收购日立硬盘业务后）推出首款商用氦气硬盘：容量比空气硬盘高50%，功耗降低25%。
   • 该技术迅速应用于Netflix、CERN等客户，首年出货百万块，如今月产能达百万块，成为数据存储基石。

核心创新

• 密封技术：激光焊接结合硅铝合金，控制铸造气泡定向释放，实现可靠气密。
• 制造适配：工艺兼容现有产线，成本可控，满足规模化生产。

影响
氦气硬盘彻底改变了高容量存储格局，支撑了全球数据爆炸式增长，并应用于前沿科研（如首张黑洞成像）。其成功融合了跨行业技术创新与长达数十年的坚持。

Circos – 圆形可视化软件

Circos 是一款用于数据和信息可视化的软件包，采用圆形布局来展示数据。这种布局非常适合探索对象或位置之间的关系，且具有视觉吸引力。Circos 旨在创建出版级的信息图和插图，具有高数据墨水比、丰富的数据层次和优美的对称性。用户可以精细控制图中的每个元素，以针对受众定制焦点和细节。

核心特点

• 灵活性：虽然最初为基因组数据（如序列比对和结构变异）设计，但 Circos 可用于任何领域的数据可视化，包括基因组学、移民流动、数学艺术、客户流程、快递量、数据库架构甚至总统辩论。
• 自动化：通过纯文本配置文件控制，易于集成到数据获取、分析和报告的自动化流程中。
• 动态格式化：利用运行时规则，可根据数据值动态调整图中元素的格式（如颜色、显示/隐藏），无需修改数据或配置文件，非常适合视觉分析。

应用与影响

Circos 改变了科学界（尤其是生物科学界）可视化基因组变化的方式，在癌症基因组学等领域应用广泛。其图像已出现在 Nature、Science 等顶级科学期刊的封面上，以及《连线》、《纽约时报》等大众媒体中。尽管在基因组学中非常流行，但它完全适用于一般数据的关系展示。

设计与理念

Circos 的设计目标是在灵活性和易用性之间取得平衡，将科学美学带入数据可视化领域。它不对数据做假设，输入格式简单，图像创建和定制方便。圆形布局本身比线性布局更紧凑，通常能更有效地传递信息，并在页面上占用更少空间。

技术细节

• 许可：免费软件，采用 GPL 许可证。
• 实现：使用 Perl 语言编写。
• 兼容性：可在任何支持 Perl 的操作系统（如 Windows、Mac OS X、Linux）上部署。
• 输出：生成位图（PNG）和矢量（SVG）图像。

适用人群与资源

Circos 适合需要探索或沟通数据集的研究人员、分析师、数据爱好者、艺术总监、插画家和视觉艺术家。用户可以通过查看已发布图像、教程图像来了解其功能，或使用在线表格查看器快速体验。软件提供教程和课程供学习下载使用。

SLJIT：平台独立的低级JIT编译器

SLJIT 是一个低级、平台独立的 JIT（即时编译）编译器，主要用于将字节码高效翻译成机器码。它设计轻量，适用于需要高性能代码生成的场景。

主要特性

• 多架构支持：包括 x86（32/64位）、ARM（32/64位）、RISC-V（32/64位）、s390x（64位）、PowerPC（32/64位）、LoongArch（64位）和 MIPS（32/64位）。
• 丰富操作支持：涵盖自修改代码、尾调用、快速调用、字节序反转（端序切换）、未对齐内存访问、SIMD（单指令多数据）和原子操作。
• 寄存器直接访问：允许直接操作整数和浮点寄存器。
• 栈空间管理：支持为函数局部变量分配栈空间。
• 一体化编译：提供全合一编译选项，使 SLJIT 的 API 完全对外隐藏，增强封装性。
• 序列化能力：可将编译器状态序列化到字节缓冲区，适用于提前编译（AOT），且反序列化后能恢复代码生成，支持部分 AOT 编译。

文档与资源

• 主要文档：位于头文件 sljitLir.h 中。
• 额外资源：可通过 SLJIT 官方网站和项目 docs 文件夹获取更多文档。

许可证与联系

• 许可证：采用简化 BSD 许可证，允许自由使用和修改。
• 联系方式：如有问题，可通过提交 GitHub issue 或发送邮件至 hzmester@freemail.hu 联系维护者。

致谢

特别感谢所有贡献者，包括 Alexander Nasonov、Carlo Marcelo Arenas Belón、Christian Persch 等个人，他们的支持推动了项目发展（如 LoongArch 和 TileGX 架构的集成）。

Catalyst项目在WebAssembly上实现了OpenSmalltalk虚拟机，涉及三个语言层次：主语言Smalltalk、协调语言JavaScript（JS）以及作为高性能运行时的WebAssembly（WASM）。此前，项目通过将SqueakJS虚拟机的JS代码翻译为WASM作为临时方案，利用了已验证的JS代码库。然而，在针对单个Smalltalk编译方法进行即时优化时，直接从Smalltalk翻译到WASM更为合理。

项目复用了现有的InstructionStream基础设施来转录Smalltalk编译方法，该设施原本用于打印可读指令描述和在调试器中模拟执行。现在，它也被用于将方法翻译为人类可读的WebAssembly文本格式（WAT）源码，进而编译为浏览器可执行的二进制WASM代码。由于Smalltalk和WASM的指令集都是堆栈导向的，这一翻译过程相对直接。

具体实现上，创建了一个InstructionStream的子类WATCompiledMethodTranslator，它使用经典的扫描器模式驱动翻译：扫描器逐条解读Smalltalk指令，并向翻译器发送相应消息，翻译器则将每条Smalltalk指令转译为WASM指令序列，写入WAT源码流。

以经典的Smalltalk表达式 3 + 4 为例。对应的编译方法包含四条Smalltalk指令：将常量3压入栈、将常量4压入栈、发送加法消息+、返回栈顶结果。当扫描器遇到第一条指令“将字面常量0压栈”时，它会找到对应的字面量3，并向翻译器发送pushConstant: 3消息。

翻译器响应时，会执行一系列方法调用。最终，在setElementAtIndexFrom:ofArrayType:named:from:方法中，会生成一条具体的WASM指令array.set，用于将值存入数组。翻译器实现了流协议，实际将WAT文本写入输出流。其他方法如comment:、get:和getField:ofStructType:named:则负责生成WASM的注释、array.get和struct.get等指令。这些数组和结构体指令是WASM垃圾收集扩展的一部分，引入了类型系统。

为了有效使用这些带类型的WASM指令，需要在WASM模块中定义类型。例如，在pushFrom:方法中使用了类型为vm的结构体变量（存储虚拟机状态，如栈指针）和类型为pointers的数组变量（存储当前方法的对象指针栈）。通常，一个Smalltalk方法的WASM代码还需要快速访问当前Smalltalk上下文、上下文的栈、当前方法的字面量和临时变量。

文章展示了HelloWASM>>add的WASM模块可能的结构，包括定义$bytes、$words、$pointers等数组类型，定义$object结构体类型（包含类、格式、哈希等字段），以及全局变量$vm和$stack。函数$HelloWASM_add的实现展示了如何通过一系列WASM指令（如global.get、struct.get、i32.add、struct.set、i32.const、array.set）来实现将常量压栈等操作。这些底层代码虽然冗长，但为执行机制提供了快速路径。

本质上，项目通过设置上下文和方法的接口，并实现每条Smalltalk指令的逻辑，相当于在为理想化的Smalltalk处理器编写固件。文章最后提到，未来将探讨实际运行Smalltalk方法WASM代码的机制，并比较其与SqueakJS动态JS翻译的性能。目前预期WASM翻译可能不会明显更快，但随着浏览器WASM引擎的改进，未来性能有望提升。

根据DruckerChannel的报道，惠普已因消费者强烈反对，停止生产并销售其较便宜的仅在线型号（以“e”结尾）的LaserJet打印机。

停产原因：

• 强制联网与订阅要求： 这些“e系列”打印机必须永久连接互联网，并强制绑定HP+订阅。
• 原装耗材限制： HP+服务要求用户仅能使用惠普原装墨盒和硒鼓，禁止使用第三方替代品。
• 消费者不满： 尽管HP+提供云打印和延长一年保修等好处，但强制性的在线要求和耗材限制，尤其对于一款更便宜的打印机而言，引起了众多消费者的反感。

具体影响范围：

• 仅限“e”系列型号： 停产仅影响型号名称末尾带“e”的激光打印机，例如HP LaserJet M110we和M209dwe。不带“e”的型号（如HP LaserJet M110w）不受影响。
• 现有设备不受影响： 已售出的e系列打印机将按购买时的状态继续正常工作，不会通过软件更新解除限制。用户仍可使用HP+服务及其权益。

惠普的回应与后续计划：

• 惠普代表表示，此举是为了给在所有办公环境（包括无法满足云连接要求的IT管理环境）中的客户提供卓越的打印体验。
• 惠普计划将“从任何地方打印”和“智能安全”等成熟解决方案扩展到部分新款LaserJet设备中。
• 此外，惠普透露将于今年晚些时候停止营销Instant Ink墨粉订阅服务。该服务将不再对新客户开放，但现有订阅用户不受影响。停止该服务的具体原因尚不明确，推测可能是为了避免与HP+服务混淆。

实时音频编程核心指南

核心目标与基本原则

在通用操作系统上进行实时音频编程的核心目标是绝对避免音频卡顿（Glitch）。数字音频以恒定采样率播放，音频回调函数必须在极短的缓冲区周期（通常为1-5毫秒）内完成计算。“实时不等人”，因此最高原则是：如果无法预测某操作的执行时间，就绝对不要在音频回调中执行它。

音频回调中的“绝对禁忌”

在音频回调线程中，必须避免任何执行时间无界或不可预测的操作：

• 禁止阻塞操作：不要等待系统资源、信号量、其他线程、磁盘或网络I/O。
• 禁止使用互斥锁（Mutexes）：加锁会导致优先级反转（低优先级线程持锁被抢占，导致高优先级音频线程死等）、临界区代码执行时间不可控，以及触发系统调度器的不可预测行为。
• 禁止动态内存分配：避免使用 malloc、new 等。内存分配器可能内部加锁、触发操作系统缺页中断，或使用耗时不可预测的算法。
• 避免最坏情况复杂度差的算法：拒绝“平均快但偶尔极慢”的算法（如一次性清零大缓冲区），这会导致处理时间尖峰。
• 禁止文件与硬件I/O：磁盘寻道、网络传输耗时极长且不可控。禁止调用 printf 等控制台输出函数。
• 警惕隐形杀手：避免垃圾回收（GC）暂停和内存缺页中断（可通过 mlock 等系统机制将实时数据锁定在物理内存中）。
• 不信任未经验证的API：假设所有系统API和第三方库都可能分配内存或加锁，除非明确保证实时性，否则禁止调用。

推荐的最佳实践

• 优化算法复杂度：使用最坏情况时间复杂度优秀（理想为 $O(1)$）的算法。
• 分摊计算负载：将繁重的计算分散到多个音频样本或多次回调中，平滑CPU使用率。
• 预分配与预计算：在非实时线程（如UI线程）中完成所有内存分配和数据预计算。
• 数据隔离：使用音频回调专属的数据结构，消除共享、并发和加锁需求。

跨线程通信方案

由于禁止使用锁，GUI等非实时线程与音频回调之间的通信应采用以下机制：

• 无锁FIFO队列（Lock-free FIFO queues）：用于安全传递命令和数据。
• 无锁数据结构或原子操作（Atomic operations）（需谨慎设计）。
• 将耗时任务（如插件加载）交由后台线程处理，完成后通过无锁机制将结果发送给音频线程。

文档即代码（Docs as Code）

文档即代码（Docs as Code）是一种理念，主张使用与编写代码相同的工具和方法来编写文档，具体包括：

• 问题跟踪系统
• 版本控制（如 Git）
• 纯文本标记语言（如 Markdown、reStructuredText、Asciidoc）
• 代码审查
• 自动化测试

这一理念旨在让文档团队遵循与开发团队相同的工作流程，并融入产品团队。它有助于建立一种文化，使作者和开发者都对文档拥有责任感，并共同致力于提升文档质量。

主要优势

• 作者能更好地与开发团队集成
• 开发者通常会撰写文档初稿
• 可以将文档作为功能合入的必要条件，从而激励开发者在功能新鲜时及时记录

学习资源

推荐书籍：

• 《Docs Like Code》Anne Gentle
• 《Modern Technical Writing》Andrew Etter
• 《Crafting Docs for Success》Diana Lakatos

相关工具：

• docToolchain（开源工具链，展示了文档即代码方法的实现方式）

实践与传播

文档即代码理念已在软件行业广泛实践，并在写作社区中逐渐普及。Write the Docs 等社区通过历年会议（2015-2022）分享了谷歌、微软、亚马逊等公司应用该理念的案例。此外，该主题也在其他技术会议和文章中多次被介绍和讨论。

文章总结：端到端拥塞控制无法避免延迟尖峰

本文阐述了端到端拥塞控制（如TCP和QUIC）的一个固有局限：在链路容量可能快速变化的网络（如Wi-Fi和5G）中，它们无法避免延迟尖峰。

核心问题与误解

• 许多研究和工程师曾认为，通过精细调整端到端拥塞控制即可实现可靠低延迟。
• 然而，对于容量快速变化的网络，这一观点是错误的。近期两篇关于5G网络的综述也指出容量变化是主要问题，但未提及此根本限制。

背景：Bufferbloat与理想网络

• Bufferbloat（因拥塞信号不佳导致的“持续队列”）已被识别为互联网延迟的常见来源，并已取得进展（如iOS的RPM工具）。
• 消除Bufferbloat是有益的，但为实现接近光速的理想互联网，仅消除持续队列是不够的。用于提高链路利用率的“瞬时队列”也可能足够大，从而导致性能问题。

理论分析与根本限制

文章通过数学建模分析了端到端拥塞控制器的理论最佳情况：

• 当瓶颈链路容量突然降低时，即使无丢包，也会产生显著的排队延迟。
• 延迟峰值取决于容量变化因子（1/r） 和从拥塞点到源端的信号传播时间（d）（受光速限制，环绕地球一周约133毫秒）。
• 计算表明，对于互联网上常见的参数，排队延迟可能增长至数百毫秒。
• 关键结论：这是所有端到端拥塞控制算法（包括各版本TCP、QUIC、自适应比特率流以及显式拥塞通知如L4S）的理论最优下限。

可能的解决方案

文章指出，仅靠端到端拥塞控制不足以实现5G所承诺的可靠低延迟网络，并列出潜在方案：

1. 预见未来：在容量降低前作出反应（相当于减小传播时间d），适用于容量下降可预测的场景（如设备移动）。
2. 低利用率链路：仅使用链路容量的10%，则10倍的容量下降不会被感知。但建设超过需求10倍的网络成本高昂。
3. 差异化流量处理：智能地低利用率使用链路，仅对延迟敏感型流量进行限制（例如，永不使用超过容量1/10或1/20的时间敏感流量）。在容量下降时，需在拥塞点优先处理此类流量。
4. 链路多元化：将相同流量发送到多条链路。因两条链路容量同时下降的概率小，可提高可靠性（假设链路不相关）。

结论与反思

作者最后提出一个根本性问题：我们是否在试图让端到端拥塞控制去做它无法做到的事情？ 如果是，那么承认本文所述的限制是迈向可靠低延迟互联网现实的必要一步。

Bitwarden 通过集成邮件别名转发服务，为用户提供了一种保护隐私的方式。其用户名生成器支持自动生成邮件别名，该别名会将邮件转发至您的主邮箱，而不会暴露主邮箱地址，从而有效防止主邮箱被用于营销列表或泄露给第三方。

核心功能与支持的服务商 使用此功能前，您需要：

1. 一个 Bitwarden 账户。
2. 一个受支持的邮件别名服务账户。Bitwarden 目前原生集成 SimpleLogin、Addy.io、Firefox Relay、Fastmail、DuckDuckGo 和 Forward Email。此外，也支持使用如 Google Workspace 等邮件服务商创建别名。
3. 对应邮件别名服务的 API 访问令牌。
4. 一个用于接收转发邮件的主邮箱。

生成邮件别名的主要步骤（以桌面应用为例）

1. 获取 API 令牌：需从您选择的邮件别名服务账户中找到 API 密钥。例如，对于 DuckDuckGo，需通过其邮箱保护页面和浏览器开发者工具找到；对于 Firefox Relay，则可在设置页面直接找到 API 密钥。
2. 在 Bitwarden 中生成别名：
   • 新建一个登录项，点击用户名生成器图标。
   • 展开“选项”部分，选择“转发的邮件别名”，并从下拉菜单中选择您使用的服务。
   • 在“API 访问令牌”字段中粘贴复制的令牌。
   • 点击刷新图标生成新的别名邮箱地址，然后选择“使用此邮件”将其保存为用户名。
3. 完成设置：保存整个登录项。生成的别名即可用于网站或服务的注册，所有发送至该别名的邮件都会转发至您的主邮箱。

优势与应用场景 此功能允许用户为每个不同的服务创建唯一的邮件别名，所有别名均转发至同一主收件箱。这有助于维护匿名性、简化收件箱管理，并轻松隔离不同来源的邮件。该功能在 Bitwarden 的桌面应用、网页版、浏览器扩展及移动端均可用。

您可以使用免费的 Bitwarden 账户开始创建邮件别名，或通过商业计划免费试用来保障团队及组织的在线安全。

Scoped Propagators 摘要

核心概念
Scoped Propagators (SPs) 是一种编程模型，旨在将计算嵌入现有环境和用户界面。其核心思想是将计算表示为节点之间沿边的映射，而非传统的节点类型。这降低了封闭环境的需求，允许在运行时定义节点和边。

关键技术特性

1. 定义：一个作用域传播器由两部分组成：
   • 函数：接收源节点和目标节点，返回对目标节点的部分更新。
   • 作用域：定义触发传播的事件子集。
2. 设计洞察：
   • 通过边上的映射表示计算，无需在设计时确定节点类型。
   • 通过将传播限定在特定事件范围内，可以为嵌入的环境添加交互行为。
3. 事件作用域（在无限画布环境中实现）：
   • change（默认）：源节点属性变化时触发。
   • click：点击源节点时触发。
   • tick：每帧渲染时触发。
   • geo：当目标边界重叠的节点属性变化时触发。
4. 语法示例：

   click {x: from.x + 10, rotation: to.rotation + 1}
   

   当源节点被点击时，将目标节点的 x 值设置为源节点 x 值加10，并增加目标节点的 rotation。

演示与应用

• 自指箭头：通过创建从节点到自身的箭头，可以轻松实现切换器和计数器等交互模式，无需额外布局约束。
• 约束布局：可用于简单的约束布局，但默认不支持双向约束。
• 调试工具：可将一个节点的属性格式化并显示在另一个节点上，用于状态检查。
• 时间行为：使用 tick 作用域和 deltaTime 值实现动画，如线性插值。
• 任意 JavaScript：支持在函数体中执行任意 JavaScript 代码，实现更复杂的行为（如创建画笔工具）。
• 跨系统集成：能在不同系统（如 Petri 网与图表）之间建立映射，无需预先定义关系。
• 综合示例：利用九个传播器在无限画布上构建了一个简单游戏，包含摇杆控制、角色跟随、状态切换和计分系统。

与传统传播网络的区别
Scoped Propagators 与传统传播网络（Propagator Networks）有三个关键不同：

1. 计算传播沿边进行，而非在节点上。
2. 传播仅在特定作用域条件满足时触发。
3. 所有节点都可以是任意类型并具有状态，而非区分状态化单元节点和传播器节点。

开放问题与未来工作

• 函数复用、副作用建模、多输入多输出传播的处理等问题尚未解决。
• 模型尚未完全形式化，特别是作用域及其与函数的关系的表达。
• 未来工作包括模型形式化、实际应用探索以及扩展到图数据库等其他领域。

文章标题： Google Maps 测试新弹出式广告，可能导致不必要的绕行

摘要： Google Maps 正在测试一种新的广告格式，可能会在驾驶导航过程中造成分心。该功能会在导航过程中弹出通知，覆盖屏幕下半部分，建议用户进行可能不必要的绕行前往某个商家。

主要情况如下：

• 测试内容： 新广告以弹出通知形式出现在导航界面，底部卡片会显示一个“赞助”商家（例如加油站、餐厅）的推荐，即使用户并未主动搜索该类地点。卡片包含地点名称、评分和预估到达时间，并提供“添加为停靠点”或“取消”两个按钮。
• 潜在问题： 这种弹出式广告可能分散驾驶员的注意力。已有用户报告在通勤途中、未经查询的情况下收到此类广告。
• 来源与模式： 该广告形式似乎借鉴自另一款导航应用 Waze，后者长期以来一直展示类似的横幅广告。不过有报告指出，Waze 的广告有时仅在车辆静止时出现。
• 谷歌官方回应： 谷歌发言人回应称，导航中的“推广标记”并非新功能，旨在让用户看到沿途相关的商家广告。为避免驾驶分心，这些广告不会主动弹出，仅在用户点击后展开，并在短时间内自动消失。
• 未知细节： 目前尚不清楚谷歌是否会采取更安全的方式，例如仅在车辆静止时才显示此类广告。测试的具体范围和最终计划也未披露。

总结： Google Maps 正在测试一种新的导航广告，该广告因可能造成驾驶分心和建议不必要绕行而引发关注。谷歌表示其现有广告设计旨在减少干扰，但此次测试的新形式与官方描述存在差异，其最终形态和实施策略仍有待观察。