Fastmail 自建硬件的原因与实践

Fastmail 拥有超过25年自建硬件的经验，尽管近期有“云遣返”的讨论，他们始终坚持这一策略，主要基于以下优势：

• 成本优化：公司能清晰掌握短、中、长期使用模式和增长，可提前规划硬件采购，无需云服务提供的快速动态扩展。
• 内部经验：拥有自主安装、配置和运维硬件及网络的深厚经验，相关技能持续积累。
• 长期使用：硬件使用寿命周期长（5-10年），可将成本摊销多年。

硬件演进与技术选择

1. 早期架构：IMAP服务器曾长期使用SAS硬盘（RAID1存元数据）与SATA硬盘（RAID6存邮件数据）的组合。
2. 全面转向NVMe SSD：数年前进行了重大升级，采用2U AMD平台并配备纯NVMe SSD。因当时NVMe RAID控制器不普及，经评估后选择ZFS文件系统来管理冗余。
3. ZFS的优势：
   • 启用了透明Zstandard压缩，为邮件数据节省约40%空间。测试表明128K记录大小与zstd-3压缩的默认设置已十分高效。
   • 内置静态加密，简化系统架构。
   • 性能表现出色，成功应用于邮件、数据库、日志及备份服务器。

SSD可靠性与寿命考量

• 尽管SSD有写入寿命限制，但实际监测显示磨损极慢。按当前速率，更换原因更可能是容量需求或物理规格更新（如E3.S），而非写满寿命。
• 与旧HDD相比，SSD可靠性大幅提升，故障率不足原来的十分之一。

存储成本决策分析

公司近期评估了备份存储方案，比较了三种选择：

1. 云存储：提供商价格差异大（如Backblaze B2约$72,000/年 for 1PB），但存在带宽成本、API转换复杂度和长期成本不确定性。
2. 升级现有HDD：可复用硬件、前期成本低，但面临超大容量硬盘重建时间过长、IO性能瓶颈等风险。
3. 采购新NVMe SSD服务器：
   • 一次性成本（约$190,000 for >1PB）低于标准云存储一年的费用。
   • IO性能高、可靠性好，无带宽与延迟问题。
   • 可统一平台，节省空间与电力，且无需开发新系统。

最终选择：基于性能、可靠性、长期成本可控性及运维简化等因素，Fastmail选择了采购新NVMe SSD服务器的方案。实际使用中，其性能（如网络链路饱和）和效率（压缩写入）均达到预期。

结论

自建硬件需要经验和规模，且并非适合所有企业。但对Fastmail而言，凭借深厚的运维知识、可预测的增长模式以及对总拥有成本的精确控制，自建硬件带来了显著且持续的经济与性能优势。

文章标题解析：平克·弗洛伊德《The Wall》中的电话信令解码

核心内容总结： 本文记录了作者对1982年电影《The Wall》中一个电话场景音频的技术分析过程。主要目标是解码主角从洛杉矶拨打伦敦电话时听到的电话网络信令音。

关键分析与发现：

1. 音频特征：音频片段包含拨号音、快速组合音调、铃声、弹出声和接通音。最具特征的是编码电话号码的快速音调组合。
2. 信令系统对比：1980年前后，全球使用多种基于音调的信令系统。作者通过频谱分析，发现音频中的音调频率集中在700、900、1100、1300、1500和1700 Hz附近。
3. 排除其他系统：
   • DTMF：其使用的“高/低”音调频率对与音频不符。
   • CAS R2：其频率方案（如1380-1980 Hz或1140-540 Hz）不匹配，且美国未使用该系统。
   • SS7：全数字化系统，信令不可闻。
4. 确认SS5系统：音频中的频率组合与SS5信令系统（使用700-1700 Hz的六频二取二方案）高度匹配。作者通过电信硬件解码，确认拨号数字序列为“044 1831”，并验证了该序列符合SS5规则（以KP1信号开始，ST信号结束，最后有约2400 Hz的应答音）。
5. 音频制作推测：作者推测，当时美国运营商辅助呼叫的用户可能听到局间信令，音效师可能录制了真实的长途呼叫声音。号码本身可能是虚构的。
6. 后续发现：
   • 同一电话场景的扩展版本出现在专辑曲目《Young Lust》中。
   • 后续分析指出号码“044 1831”可能是伦敦真实号码的缩短版，且音频在数字“1”和“8”之间存在一个明显的剪接点（表现为缺乏数字间停顿）。
   • 作者检视了该剪接点的波形图，证实了拼接痕迹。

结论：通过频谱分析和硬件解码，确定电影《The Wall》中电话场景的信令音属于SS5系统，用于传输号码“044 1831”。该音频可能基于真实呼叫录音，并经过剪辑处理。

Karakeep（原Hoarder） 是一款面向数据囤积者的自托管书签管理应用，融入了AI功能，旨在帮助用户收藏和整理各类网络内容。

核心功能：

• 多格式收藏：支持收藏链接、简单笔记、图片和PDF文件。
• 自动化处理：自动抓取链接的标题、描述和图片；支持从RSS源自动囤积内容；使用yt-dlp自动归档视频。
• 智能管理：利用LLM（支持本地模型如Ollama）进行自动标签和摘要；提供OCR功能以从图片中提取文字；支持基于规则的自定义管理引擎。
• 组织与协作：可将书签分类至列表；支持多人在同一列表上协作；支持批量操作。
• 强大搜索：基于Meilisearch实现所有存储内容的全文搜索。
• 存档与备份：使用Monolith进行整页存档以防链接失效（链接腐坏）；支持标记和存储收藏内容中的高亮部分。
• 广泛访问：提供Chrome、Firefox、Safari扩展，以及iOS和Android移动端应用；拥有REST API和多种客户端；支持多语言和暗黑模式。
• 数据管理：支持从Chrome、Pocket、Linkwarden等多种来源导入书签；可通过Floccus与浏览器书签自动同步。
• 集成与友好性：对LLM智能体（如OpenClaw、Hermes）友好，提供强大CLI和官方技能；支持单点登录（SSO）。

技术栈与构建原因： 该应用采用Next.js、Drizzle、NextAuth、tRPC、Puppeteer、OpenAI和Meilisearch等技术构建。开发者出于个人需求（寻找Pocket的自托管替代品，并希望应用具备链接预览和自动标签功能）以及保持Web开发技能的目的创建了Karakeep。

与其他应用的区别： 相较于纯笔记应用（如memos）或不开源的商业产品（如mymind），Karakeep强调自托管优先，并整合了书签、笔记、图片、PDF的全面管理以及AI自动处理功能。它不同于仅专注于链接收藏的传统书签管理器。

当前状态与支持： 该应用正处于积极开发中。提供在线演示（只读模式）。项目使用Weblate进行翻译管理。同时提供托管云服务（Karakeep Cloud）供不愿自托管的用户选择。项目采用AGPL-3.0许可证，并拥有Discord和Twitter等社区渠道。

SQLite是一款基于B树磁盘存储、行式存储的通用数据库，以其跨平台和嵌入式特性著称，特别适合OLTP工作负载。然而，面对分析型（OLAP）查询时，其性能远不及专门优化过的OLAP数据库。例如，在标准OLAP基准测试SSB（星型模式基准）中，单线程模式下的DuckDB比SQLite快30-50倍。

性能瓶颈分析 研究者利用SQLite的VDBE分析功能，发现性能瓶颈主要集中在两个虚拟机操作码：SeekRowID和Column。这两个操作码分别用于通过行ID在B树中探测行和从记录中提取列。由于分析查询主要涉及多表连接，而SQLite采用最简单的嵌套循环连接算法，导致了大量昂贵的B树探测操作。

连接操作与查询顺序 嵌套循环连接的性能取决于表连接的顺序。例如，先连接匹配行数较少的维度表可以显著减少操作次数（如从400万次降至100万次）。然而，生成最优连接顺序是一个NP难问题。

优化方案：引入布隆过滤器 研究者没有采用内存开销较大的哈希连接或复杂的排序归并连接，而是在现有嵌套循环连接的基础上引入了布隆过滤器作为缓存。具体优化如下：

1. 新增操作码：添加了Filter和FilterAdd两个操作码。
2. 构建过滤器：在连接操作开始时，遍历维度表中所有满足查询谓词的行，并使用FilterAdd将这些行对应的键值设置到位布隆过滤器中。
3. 应用过滤器：在嵌套循环的内层循环前，先使用Filter操作码检查当前行是否可能存在于布隆过滤器中。只有当布隆过滤器指示可能存在匹配时，才继续执行后续昂贵的B树探测（SeekRowID）。

优势与效果 布隆过滤器具有空间效率高（可完全放入CPU缓存）、易于实现的特点，且与SQLite现有的查询引擎架构兼容。 优化后，B树探测操作大幅减少，CPU周期分析显示主要耗时操作被消除。最终，SQLite在分析查询上的性能提升了7到10倍。该优化已集成到SQLite的v3.38.0版本中。

总结 通过巧妙地利用布隆过滤器作为前置缓存，SQLite在保持其原有简单架构和低内存占用的前提下，显著提升了分析查询的性能，使其更好地适应了混合工作负载的趋势。

摘要：
文章探讨了美索不达米亚古代泥板中的数据表格，展示了其与现代电子表格的相似性，并反思了文明发展的非线性特征。

核心内容：

1. 历史背景

   • 在伊拉克拉尔萨古城遗址发现的泥板（约3600–4000年前，旧巴比伦时期）记录了古代会计数据。
   • 泥板表面有凹线划分行列，呈现结构化数据表特征。

2. 数据表解析

   • 由伦敦大学学院的埃莉诺·罗布森教授转录和翻译，内容可能是一个建筑项目的工资摘要。
   • 表格包含列表头（如基础工资率、数量、总额等），各行对应个人或团体信息，末尾有列总计。
   • 数据间存在计算逻辑（如D列是B列数量乘以基础工资率），显示古代会计已具备分类汇总与运算能力。

3. 现代类比与思考

   • 尽管泥板数据组织方式与现代电子表格高度相似，作者认为文明发展并非线性传承——发明可能失传后被重新创造。
   • 对比保存持久的泥板与可能快速消失的现代数字文件，强调物理载体在长期存档中的优势。

关键启示：

• 数据表格的使用可追溯至数千年前，说明人类对结构化信息处理的需求是跨越时代的。
• 技术发展存在断裂与重启，古代智慧未必持续影响后世，但其原理常被重新发现。

这首诗歌描绘了一个雪夜驻马树林的场景。叙述者认出树林属于村中某位屋主，但对方不会察觉他在此停留观赏雪景。马匹对陌生地点感到困惑，晃动颈铃询问主人是否误入歧途。周遭只有微风与雪花的声音。诗歌最后转向沉思：树林虽幽深迷人，但叙述者仍有承诺待履行，且“安睡前还有很长的路要走”——这句重复收尾，暗示人生责任与旅程的漫长。作品通过简洁的意象和反复的韵律，探讨自然诱惑与人生义务之间的张力。该诗歌已进入公共领域。

本文总结了Rust借用检查器的四个具体限制，这些限制可能导致开发者不得不采用非理想的解决方案。

1. 借用检查器不考虑匹配与返回的控制流 当在函数中先进行不可变借用查询，根据结果返回或继续执行可变借用查询时，即使第一次借用在返回后不再使用，借用检查器仍会认为可变借用被多次获取。例如在HashMap中双重查找时，编译器会错误地报告“无法多次可变借用”。变通方案是使用contains_key进行重复检查，但这会导致不必要的额外查找。

2. 异步回调函数的类型签名限制 尝试定义一个接受闭包并异步调用其返回的Future的方法时，无法在类型签名中表达Future的生命周期依赖于闭包参数的引用生命周期。这导致无法编写如async_for_all(|v| async move { ... })这样的异步迭代器。目前Rust的语法和类型系统（包括use<'a>和GAT）尚不支持这种参数化类型。

3. FnMut闭包不支持捕获变量的重借用 当闭包捕获一个可变引用，并试图在返回的Future中重新借用该引用时，会遇到移动错误。这是因为FnMut特性的call_mut方法签名要求返回类型独立于self的生命周期，无法表达“返回基于self生命周期的重借用”。而&mut引用涉及重借用，这成为独特问题；共享引用因实现Copy而无此问题。

4. Send检查器缺乏控制流感知 在异步函数中，即使可变锁保护（MutexGuard）在某些执行路径上未跨越await点，编译器仍可能错误地判定Future不是Send。例如，先加锁处理快速路径，再在需要时释放锁执行异步操作。变通方案是将锁的作用域显式限制在不包含await的代码块内，并将后续异步逻辑移到外部，以消除编译器的误报。

作者指出，这些问题体现了类型系统的静态限制，并非无法绕过（例如使用unsafe或运行时检查），但无法以Rust惯用的安全方式解决。其中第1和第4项限制的修复价值较高且成本较低，而第2和第3项涉及语法和类型系统的复杂性。

HyperEssays项目摘要

项目概述

HyperEssays是一个旨在创建现代、可访问的蒙田《随笔集》在线版本的项目，提供多个历史版本和工具，帮助读者理解蒙田的作品。项目于2020年1月17日启动，预计持续多年。

提供的版本

HyperEssays.net托管四个版本的《随笔集》：

• 1598年版本：中世纪法语，由Marie de Gournay编辑，是1595年原版的修订版。
• 1603年翻译版：John Florio的完整可搜索翻译，使用早期现代英语。
• 1685年翻译版：Charles Cotton的翻译，仅部分章节已编辑发布。
• 1877年现代版：基于W. Carew Hazlitt更新的版本，正在逐步替换为当代翻译并添加新注释。

项目目标与工作内容

• 目标：为首次读者提供上下文和工具，设计持久资源，确保免费和可访问。
• 工作内容：编辑、更新和注释文本；标记用于索引和搜索；格式化便于智能手机、桌面和平板阅读；提供免费章节PDF供离线阅读。

《随笔集》简介

• 内容：非单一书籍，而是蒙田在20多年间撰写的短文和长文集合，主题涵盖宗教、马、友谊、睡眠、法律、自杀等。
• 出版历史：
  • 1580年第一版：包含两卷书。
  • 1588年更新版：增加数百修订和第三卷。
  • 1595年后世版：蒙田去世后（1592年）出版，纳入其计划的修订。
• 阅读建议：可从头到尾读，或从任何地方开始；推荐章节包括《哲学是学习死亡》、《论儿童教育》、《论友谊》、《论食人族》等。

蒙田简介

• Michel de Montaigne是16世纪法国作家，常被描述为哲学家，但内容质疑其哲学家身份及隐居写作的常见说法。
• 项目中有专门部分（On Montaigne）和时间线提供传记背景，推荐四部传记和两个现代翻译以深入了解。

项目状态与更新

• 项目持续进行，工作日志显示近期编辑章节，如2026年1月的《论小加图》、《论残忍》等。
• 支持该项目可通过贡献帮助其成长和保持免费。

Infinigen是一个使用程序化生成技术创建无限逼真世界的开源工具，主要包含室内、自然和铰接式资产三个模块。项目提供快速开始指南，用户可通过对应说明文件生成首个场景。该项目在计算机视觉与模式识别顶级会议CVPR上有多篇论文发表，分别介绍了整体框架（CVPR 2023）、室内场景生成（CVPR 2024）以及铰接式模拟资产生成的方法。

文档涵盖安装配置、相机设置、预生成数据下载、单独资产生成、导出外部格式（如OBJ、OpenUSD）、添加自定义资产、实现新材料、生成流体模拟及导出到物理模拟等详细指南。项目欢迎社区贡献，包括代码开发、程序化生成器贡献以及预生成数据共享。遇到问题可通过GitHub Issues页面寻求帮助，并需提供详细的系统环境、代码版本、运行命令及日志信息。

项目感谢Blender基金会及多个开源项目的支持，并承认从在线教程中获得灵感。自CVPR论文版本以来，项目已加入部分基于CC-0许可证的网络程序化代码。

# PostgreSQL中只读查询导致写入的机制解析

文章探讨了PostgreSQL中一个反直觉的现象：为何简单的`SELECT`查询会导致数据写入。这通过检查`pg_stat_statements`视图中`shared_blks_dirtied`和`shared_blks_written`列为非零值时发现。文章深入剖析了导致此行为的两种主要机制，并介绍了其底层原理。

## 背景：多版本并发控制（MVCC）

PostgreSQL使用**MVCC**来支持并发读写。更新操作不会原地修改行，而是创建新的行版本（tuple）。旧版本通过`t_xmax`字段标记为“已删除”，新版本通过`t_xmin`字段标记为“由当前事务插入”。要确定一个行版本对当前事务是否可见，不仅需要检查这些事务ID，还需要确认其所属事务是否已提交。

## 机制一：提示位（Hint Bits）更新

当一个新的行版本被创建时，其头部的事务状态标志（如`t_infomask`中的提交状态位）并未立即设置，因为当时插入或删除它的事务结果（提交或中止）未知。事务的提交状态单独记录在提交日志（`pg_xact`）中。

当后续的查询（即使是只读`SELECT`）访问这些处于“模糊状态”的行时，它必须查询提交日志以确定可见性。**关键步骤是**：一旦获得答案，该查询就会**立即更新**这些行头部的提示位，将确定的事务状态（如`HEAP_XMIN_COMMITTED`）直接写入页面。这个写入操作使得页面变“脏”（`dirtied`），最终需要刷写到磁盘。此过程旨在为后续访问提供快速路径，避免重复查询提交日志。

## 机制二：页面修剪（Page Pruning）

当行被更新或删除后，旧的行版本（死元组）会保留在页面中。**页面修剪**是一个轻量级的清理过程，专门回收单个堆页面内的死元组所占空间，避免页面空间碎片化。

与`VACUUM`不同，修剪可以由任何访问堆页面的语句触发，但仅在以下条件满足时才会执行：
1.  页面剩余空闲空间很少（通常少于10%）。
2.  页面头部的`prune_xid`提示字段非零，表明页面内存在需要清理的旧事务。

当一个只读查询访问这样一个“满载”的页面时，它会触发页面修剪过程。这会导致：清除死元组、压缩剩余的活动行版本、回收空闲空间，并**将修改后的页面写回缓冲区**。同样，这也会使页面变脏，造成写入。修剪过程的一个重要特点是：如果原始行版本被索引引用，其行指针会被设置为“重定向”（redirect）到最新版本，以保持索引指针有效，但索引本身不被修改。

## HOT更新与总结

文章最后介绍了**堆内元组（HOT）** 更新优化。当更新不改变索引列且页面有足够空间时，新旧版本都保留在同一页面，且新版本不会立即添加到索引中。所有相关版本通过链式`t_ctid`连接，并标记为`HEAP_ONLY_TUPLE`。这进一步减少了索引更新开销，但索引引用的原始行指针仍需通过重定向机制来保持。

总之，PostgreSQL中`SELECT`导致写入是其并发控制和空间管理机制的**正常且有益**的行为。这两种机制——**为加速可见性判断而更新提示位**，以及**为回收页面空间而触发修剪**——是数据库维护自身性能与一致性的内在组成部分。

根据提供的信息，无法生成详细的文章摘要。

*   **问题原因**：您提供的“文章内容”部分显示为“Internal server error”（内部服务器错误），这是一个错误状态提示，而非实际的文章文本内容。
*   **可用信息**：目前仅有文章标题可供参考：“Show HN: Eonfall – A new third-person co-op action game built for the web”。

**基于现有标题的推测性摘要（仅供参考）**：
这篇文章很可能是向“Hacker News”社区展示一款名为 **Eonfall** 的新游戏。该游戏被描述为一款**为网络（Web）构建的第三人称合作动作游戏**。这意味着玩家可以通过网页浏览器进行游戏，而无需下载传统的客户端，这通常涉及到先进的网络技术（如WebGL、WebAssembly等）。文章的重点可能在于介绍其技术实现、游戏玩法特点以及如何在浏览器中提供接近原生游戏的体验。

NeurIPS 2024 见闻：AI领域的焦虑与转变

深度学习革命与人才供需失衡（2010-2015年）

• 技术突破期：深度学习在语音识别、图像识别、机器翻译等领域取得显著进展，引发行业关注。
• 人才稀缺：深度学习非本科主流课程，顶尖实验室少，企业激烈争夺少数具备神经网络经验的博士生和教授。
• 薪酬与自由：企业为抢占先机，提供高薪（远超学术界）和研究自由，形成“类学术”的产业研究职位，吸引了许多学生攻读AI博士。

人才管道的建立与扩张（2016年后）

• 申请热潮：高待遇和研究自由吸引大量学生申请AI博士项目。
• 培养规模扩大：许多教授转向深度学习，扩大博士生招生。
• 预期路径形成：学生期望通过攻读博士，获得高薪研究职位，并认为这一路径将持续稳定。

产业化带来的根本转变

• 产品化导向：大规模语言模型等技术成熟并转化为产品，企业需求从探索性研究转向稳定产品迭代和标准化流程。
• 博士价值下降：产品开发需要稳定改进而非颠覆性创新，本科生和硕士生经培训后能更快适应标准化工作，博士的研究优势减弱。
• 研究自由受限：企业更关注直接产品贡献，纯研究职位减少，博士生的研究方向需与商业化产品（如大模型）更紧密对接。

博士生与博士后的困境（NeurIPS 2024观察）

• 市场期望落差：高年级博士生和博士后发现就业市场与五年前入学时预期大相径庭，感到“被背叛”。
• 技能错配焦虑：他们擅长的研究领域可能非当前热门的大模型方向，而掌握大模型实践技能的本科生/硕士生显得更具竞争力。
• 机会收窄：非大模型相关的研究职位快速减少，导致深度挫败感和未来职业发展的不确定性。

反思与现状

• 供需逆转：AI人才从极度短缺变为相对过剩，大学已培养出大量具备实用技能的本科/硕士生。
• 领域多样性被忽视：尽管大模型受关注，其他AI子领域（如不确定性量化、几何深度学习）仍有价值，但机会集中在大模型相关的窄方向。
• 系统性问题：产业需求快速转变，博士培养周期与市场需求不匹配，导致后期博士生面临严峻的就业压力。

JEP 483 提案旨在通过提前（AOT）加载和链接类来改善 Java 应用程序的启动时间。其核心思想是在一次“训练运行”期间监控应用程序的启动过程，将所有类的已加载和已链接状态缓存到一个文件中。在后续运行中，HotSpot JVM 可以直接使用此缓存，从而跳过耗时的类读取、解析、加载和链接步骤，使类即刻可用。

该技术的目标是利用大多数应用程序启动方式相似的特点来提升启动速度，且无需修改应用代码或标准启动命令，也不依赖 jlink 或 jpackage 工具。它主要处理通过内置类加载器（来自类路径、模块路径和 JDK 本身）加载的类，暂不支持用户自定义类加载器。

实现此功能分为两步：

1. 训练运行：使用 -XX:AOTMode=record 选项运行应用程序一次，以生成 AOT 配置文件（例如 app.aotconf）。
2. 创建缓存：使用该配置文件，通过 -XX:AOTMode=create 选项生成 AOT 缓存文件（例如 app.aot）。此步骤不运行应用程序。 后续运行时，使用 -XX:AOTCache=app.aot 选项即可利用缓存。例如，使用 Stream API 的 HelloStream 程序在使用缓存后启动时间缩短了 42%；Spring PetClinic 应用也获得了同样的启动时间提升。

为有效利用此功能，训练运行应尽可能模拟生产环境，并加载生产时使用的类。同时，训练运行与后续生产运行必须满足一系列一致性要求，包括：使用相同的 JDK 版本、硬件架构和操作系统；类路径（仅支持 JAR 文件）和模块配置必须一致；不能使用会重写字节码或修改类加载器搜索路径的 JVMTI 代理等。违反这些约束通常会导致 JVM 忽略缓存。但允许训练和后续运行使用不同的垃圾收集器或主类。

该提案是 HotSpot JVM 中现有类数据共享（CDS）技术的自然演进。CDS 主要通过提前读取和解析类文件来改善启动和内存占用，而 AOT 缓存进一步实现了提前加载和链接，带来了额外的性能提升。

未来的改进计划包括：简化为一步式的缓存创建工作流程；探索更灵活的训练运行定义方式；增加对 ZGC 的支持；尝试支持更多类型的类加载场景；并最终利用此基础进一步提升应用的预热（warmup）时间。

视频总结：《揭露Honey网红骗局》

基本信息

• 标题：Exposing the Honey Influencer Scam
• 频道：MegaLag（约97.9万订阅者，已认证）
• 发布日期：2024年12月21日
• 观看次数：约1,898万次
• 点赞数：约125万
• 评论数：约7万

视频描述

视频探讨了PayPal旗下浏览器扩展工具Honey是否是一个合法的省钱工具，还是仅仅是一个由YouTube头部网红推广的联盟营销骗局。作者MegaLag呼吁拥有PayPal Honey内部信息的知情人通过megalagtips@proton.me保密联系他，以协助调查。

相关内容

页面推荐了该频道的多个续集和关联视频，包括：

• 《揭露Honey的邪恶商业模式（第二部分）》（51分钟，330万观看）
• 《Honey骗局比我想象的更严重》（43分钟，330万观看）
• 《揭露色盲眼镜骗局（第一部分）》（450万观看）

热门评论

页面展示的精选评论提到Markiplier（知名YouTuber）曾因怀疑"免费赚钱太好"而拒绝接受Honey赞助，事后证明他的判断是正确的。

技术信息

该视频页面当前处于需要登录状态，播放器返回"LOGIN_REQUIRED"状态，提示用户登录以确认不是机器人。视频ID为 vc4yL3YTwWk，属于调查类长视频，时长约26分钟。

这是一个名为 “Talk to Me Human” 的网页游戏演示项目的前端代码。该网页是一个基于 React 的单页应用，其核心概念是一个 “社会说服模拟器”，玩家需要通过对话技巧“化解危机”。

代码概要如下：

• 项目与描述：网页标题为“Talk to Me Human”，并拥有完整的 SEO 和社交分享元数据，明确将游戏描述为“The talking your way out of it simulator”。
• 技术栈：使用现代前端技术构建，包括 React、Vite（从文件名推断）以及 Tailwind CSS（从 class 名如 responsive-screen-height、flex、flex-col 等推断）。
• 页面结构：
  • <body>：应用了响应式高度（通过 CSS 变量 --vh）和背景样式，并在较大屏幕上添加了内边距，以适配不同设备。
  • <div id="root">：这是 React 应用的挂载点。它采用了 Flexbox 布局以垂直居中内容，并限制最大高度，确保内容在不同高度的屏幕上都能良好显示。
• 第三方集成：
  1. LemonSqueezy：加载了其脚本，用于处理潜在的支付或交易功能。
  2. Simple Analytics：集成了隐私优先的网站分析服务，并包含了无脚本环境的备用跟踪图片。
• 整体定位：该代码是游戏的入口文件和基础布局，定义了游戏运行的容器和环境，具体的游戏逻辑和界面渲染由编译后的 React 应用（index-b36b737f.js）和样式文件控制。

调查报告摘要：sbuild 重构导致 GCC 构建失败

本文记录了对 Debian GCC 构建在多个架构上失败问题的调查过程。该问题由 sbuild 工具的重构引发，团队通过系统性的调试定位到了根本原因。

问题出现与初步调查

• 现象：自11月下旬起，Debian 官方的 GCC 构建在多个架构上失败。构建在运行测试套件时出错，但理论上 make 命令使用了 -k 参数，测试失败不应导致构建整体失败。
• 环境差异：本地使用 sbuild 0.85.0 构建成功，而构建服务器使用了来自 bookworm-backports 的 sbuild 0.86.3~bpo12+1。切换至新版本后，本地构建也失败。
• 版本定位：在 sbuild 0.85.0 到 0.86.3~bpo12+1 之间进行版本二分查找，最终确定问题引入于 sbuild 0.86.0。通过仅构建 D 语言并跳过其他语言（DEB_BUILD_OPTIONS=nolang=...），大幅缩短了重现时间。

深入分析与根本原因

• 信号追踪：使用 bpftrace 工具追踪构建过程中的信号发送。发现一个名为 process.exe 的进程在新版本 sbuild 中会发送额外的 SIGTERM 信号。
• init 进程差异：旧版 sbuild 使用 dumb-init 作为 PID 1，而新版使用 Perl 编写的 little init。这导致进程管理行为不同。
• 关键发现：strace 分析显示，process.exe 尝试向进程组 ID 为 -2 的所有进程发送 SIGTERM 信号（即 kill(-2, SIGTERM)）。
  • 在 dumb-init 下，进程组 2 不存在，因此信号发送失败（ESRCH）。
  • 在 Perl init 下，进程组 2 存在（实际上是构建主进程 dpkg-buildpackage），因此信号被成功发送，意外终止了整个构建。
• 代码级原因：问题源于 GCC 测试中使用的 D 语言运行时库 (libphobos) 的一个单元测试 (process.d)。该测试在内部使用特殊值 -2 表示“进程已终止”。在某些执行路径下，代码错误地将此特殊值作为真实进程组 ID 传递给了 kill 系统调用，从而杀死了自身的进程组。

结论

该故障是 sbuild 工具进程初始化方式变更与 D 语言标准库单元测试中的一个缺陷 共同作用的结果。sbuild 的重构改变了 PID 1 进程的行为，暴露了测试代码中一个原本无害的错误，导致其意外终止构建进程。此案例展示了基础设施微小变动如何与应用代码缺陷相互作用，引发难以预料的失败。

Glitch的消亡与Slack的诞生：一次著名的战略转折

Glitch游戏的困境
2009年，Tiny Speck公司开始开发在线角色扮演游戏《Glitch》。该游戏以奇特世界观和社区互动为核心，由40人团队打造，吸引了众多忠实玩家。然而，游戏始终未能形成可持续的商业模式：开发与运营成本高昂，玩家数量不足；同时，游戏基于Flash技术，难以适应智能手机崛起的移动化趋势。尽管团队尝试了多次更新、优化和宣传，仍未能扭转局面。

战略转折点
2012年11月，CEO Stewart Butterfield在与作者的散步中透露了游戏将关闭的决定。但团队面临抉择：若继续运营，资金将在数月内耗尽；若及时停止，则可利用剩余资源开发新产品。Butterfield注意到团队在开发《Glitch》过程中自建的内部通信工具——基于IRC协议、整合文件分享、日志搜索和多种系统集成的协作系统。他认为这些工具可能具有商业化潜力。

内部工具的潜力
团队原本使用传统IRC协议进行实时通信，并辅以自定义脚本实现文件共享、日志存档以及与游戏运营、部署、客服等系统的集成。这套系统避免了邮件往来的繁琐，提升了团队效率，但技术粗糙且依赖自建脚本。Butterfield提议在此基础上打造一款新产品，将团队沟通、文件管理与系统集成整合到统一平台，并命名为“Slack”。

从游戏到企业软件
尽管部分成员最初感到怀疑，团队决定转向开发Slack。公司关闭《Glitch》后，采取了多项善后措施：退款玩家、发布“招聘天才”页面帮助员工再就业，并将游戏资源开源。玩家社群举办了告别活动，游戏服务器于2012年12月9日关闭。

Slack的发展
2012年底，团队开始开发Slack原型；一年后（2013年）正式发布；五年后（2018年）公司上市。值得注意的是，Butterfield此前曾有类似经历：2002年开发的游戏《Game Neverending》虽未成功，却衍生出知名照片分享平台Flickr，并于2005年被雅虎收购。《Glitch》的失败再次成为一次成功转型的契机。

关键启示

• 《Glitch》的失败源于商业模式与技术趋势的脱节，但团队在开发中积累的技术经验成为转型基础。
• Slack的诞生并非偶然，而是基于团队对自身痛点的深刻理解，并通过精简和优化现有工具实现产品化。
• Butterfield两次将失败游戏项目转化为成功软件产品，体现了识别潜在价值、灵活调整方向的能力。

这次转折展示了初创公司如何通过快速调整战略，将看似失败的项目转化为新的增长点。

阿尔罕布拉宫的液压系统

视频基本信息

• 标题：The Ancient City That Mastered Water（掌握水的古城）
• 频道：Primal Space
• 观看次数：约670万次
• 发布日期：2024年11月28日
• 频道订阅者：190万

视频内容概述

该视频探讨了西班牙格拉纳达阿尔罕布拉宫的非凡水利工程。主要内容包括：

核心主题

视频深入介绍了这座中世纪宫殿如何利用先进的液压系统实现喷泉供水、地暖系统和水钟等功能，展示了这一世界著名建筑杰作背后的创新技术。

章节结构

制作信息

• 撰稿与剪辑：Ewan Cunningham
• 3D建模：Orkun Zengin、Zac Farmer
• 赞助商：Opera浏览器

互动数据

• 点赞数：约15.8万
• 评论数：约7,300条

AI生成摘要

Primal Space探索了阿尔罕布拉宫格拉纳达的巧妙水利工程。这个中世纪系统利用水轮、复杂渠道和先进物理学原理来提供供暖、制冷和水力驱动的计时功能。

相关推荐视频

视频右侧推荐了多个主题相关的工程与历史类视频，包括：

• 《世界最重要的机器》（Veritasium）
• 《如何让威尼斯建在水上》（Engineering The Impossible）
• 《威尼斯的疯狂工程》（Primal Space）
• 《巴黎的地下时钟》（Primal Space）
• 《罗马水道桥的天才工程》（Coded Chambers）等

互动限制

由于用户未登录，点赞、点踩、订阅、保存播放列表等功能均需先登录Google账号才能使用。

本文探讨了在优化词法分析器性能时，对不同字符匹配方法的探索与实践。作者在重写《用Go编写解释器》一书的词法分析器组件时，旨在提升其处理标识符等token的性能。文中比较了几种从连续字符中识别token的方法，并给出了基准测试结果。

主要方法与对比

1. 条件分支法：

   • 最直接的方法，通过一系列if语句判断字符是否属于特定范围（如数字、大小写字母）。
   • 缺点：随着需要检查的token类型增多，性能会下降，因为每次都需要进行多次条件判断。

2. 查表法：

   • 为所有ASCII字符预先计算并存储结果，使用一个256大小的布尔数组。
   • 通过直接索引数组进行查询，避免了运行时的边界检查，性能优于分支法。

3. 位向量法：

   • 将每个ASCII字符映射到一个比特，使用4个uint64（共256比特）来表示。
   • 通过位操作（设置Set和查询Get）来标记和检查字符。
   • 优点：在压缩内存占用的同时，仍然能进行高效的查询操作。作者认为对于更大的字符集，这是一种有用的折中方案。

性能基准测试

在AMD Ryzen 5 3600处理器上的测试结果（每次操作耗时）显示：

• 数组索引（朴素实现）: 12510 ns/op
• 条件分支: 3767 ns/op
• 位向量（自定义）: 2910 ns/op
• 位向量（willf库）: 2597 ns/op
• 查表法: 2370 ns/op 查表法最快，位向量法次之，两者都显著快于分支法。

SIMD尝试与汇编探索

作者尝试了更进阶的SIMD优化，但发现对于x86架构而言非常困难：

• 缺少某些关键指令（如跨64位的移位）。
• 汇编代码编写和调试门槛高。
• 尽管在Go中集成汇编相对容易，但由于缺乏调试工具，作者的SIMD汇编实验未能完全成功。

在Zig语言中，由于支持任意大小的整数类型，实现位向量更为简单，但编译器生成的代码并未自动利用SIMD寄存器。

结论与参考

作者认为，像《用Go编写解释器》这样的书籍是深入低级编程的好方法。尽管SIMD优化的目标过于宏大，但这次尝试提供了宝贵的汇编编写和性能优化初体验。文中最后列出了多个关于SIMD编程的参考资源和工具，包括相关文章、GitHub仓库以及用于查看编译器输出的Godbolt网站。

城市道路可视化工具简介

核心功能

• 一次性绘制：该工具允许用户选择一座城市，然后在屏幕上一次性绘制出该城市所有的道路。
• 可视化效果：旨在提供一种直观、全面的方式，来展示整个城市道路网络的图形结构。

技术实现

• 前端技术：这是一个基于Web的HTML页面，核心是一个 <canvas> 画布元素，用于渲染道路图形。
• 资源加载：页面通过 <script> 和 <link> 标签加载了外部的JavaScript和CSS文件，这些文件包含了绘制逻辑和样式。
• 页面设置：通过viewport标签确保在移动设备上良好显示，并设置了初始背景色和字体。

开发信息

• 作者：Andrei Kashcha
• 元数据：页面包含了描述、关键词和社交分享（Open Graph）标签，便于搜索引擎优化和社交平台分享。
• 分析：集成了Google Analytics用于访问统计。

SingleFile：将完整网页保存为单个HTML文件的浏览器扩展

SingleFile 是一款浏览器扩展（兼命令行工具），可将完整的网页保存为单个HTML文件。

核心功能与兼容性

• 保存完整网页为单一HTML文件。
• 兼容多种浏览器：Chrome、Firefox（桌面与移动版）、Microsoft Edge、Safari、Vivaldi、Brave、Waterfox、Yandex Browser 和 Opera。

安装

可从各浏览器官方应用商店安装，例如：

• Firefox 及 Firefox for Android：Mozilla 附加组件网站
• Chrome：Chrome 网上应用店
• Safari (macOS & iOS)：App Store
• Microsoft Edge：Microsoft Edge 外接程序 也可下载项目压缩包进行手动安装。

使用方法

1. 基本保存：点击扩展工具栏中的 SingleFile 按钮即可保存当前页面。处理过程中可再次点击取消。
2. 上下文菜单（右键）功能：
   • 保存当前标签页、选中的内容或选中的框架。
   • 批量处理：可一次性保存多个标签页（选中的、未固定的或全部标签页）。
   • 注释与保存：允许高亮文本、添加注释、移除内容后再保存。
   • 自动保存：可对当前、未固定或所有标签页启用自动保存，页面在加载后（或卸载前）会自动保存。
3. 高级选项：
   • 云上传：启用后可将页面保存到 Google Drive 或 GitHub。
   • 区块链存证：启用“添加存在证明”选项，可通过关联页面的SHA256哈希值至区块链来证明已保存页面的存在。
   • 自定义快捷键：默认为 Ctrl+Shift+Y，可在浏览器扩展管理页面修改。
   • 保存位置默认为浏览器的下载文件夹。

文件格式对比

SingleFile 生成的单一HTML文件与其他格式（如自解压ZIP、MHTML、Safari Webarchive、HTML+文件夹）相比，特点包括：

• 将页面保存为单个文件。
• 对HTML和样式进行精简，移除未使用的部分。
• 二进制资源不采用Base64编码，但会进行压缩。
• 文件无需安装扩展即可查看，无需运行JavaScript。
• 可解压以提取页面资源。
• 包含页面文本内容，便于索引。

生态系统

• 命令行接口 (CLI)：可通过命令行将网页保存为HTML。
• 用户脚本集成：支持在页面保存前后执行用户脚本。
• 兼容项目：众多开源项目兼容或使用SingleFile，例如：ArchiveBox（自托管网页归档）、Karakeep（书签管理）、KOReader（电子书阅读器）、linkding（自托管书签管理）、Linkwarden（协作书签管理）、Zotero Connector（文献管理）等。

其他信息

• 隐私政策、贡献者列表、第三方代码来源及图标许可均在文档中有明确说明。
• 项目代码基于 AGPL 许可证，衍生自第三方项目的代码基于 MIT 许可证。