Accountability Sinks 总结

概念定义
在《The Unaccountability Machine》一书中，Dan Davies 提出“accountability sinks”（责任沉没池）的概念，指组织中形成的结构，这些结构吸收或模糊决策的后果，导致无人能直接为决策负责。例如，酒店高层为改善财务报表而减少清洁人员，致使客户无法按时入住且投诉无门，责任被永久吞没。

运作机制
Davies 指出，accountability sinks 必须打破一个链接：阻止受决策影响者的反馈影响系统运作。这导致决策者与后果承受者之间的沟通断裂，使责任无法追溯。常见场景包括健康保险拒赔、航班取消、政府福利资格不符等。

决策的级联与模糊性
有时，决策并非由单人明确做出，而是通过隐含指标（如观众数量）级联产生。例如，Fox News 传播虚假选举信息，无人明确决定撒谎，但为了保持收视率，后续决策自然形成。这进一步模糊了责任归属。

责任的理论框架
Davies 提出责任基本法则：个人改变决策的能力与承担责任的程度成正比。Sidney Dekker 则将责任视为一种叙述，需解释事件发生的过程、条件和参与人员。结合两者，负责任需具备改变决策的权力及理解决策目的的故事。

AI 与组织的角色
将决策委托给算法是构建 accountability sink 的便捷方式，但大型组织（如企业或政府）早已擅长此类结构。AI 并非创新，而是对现有责任模糊机制的升级。然而，这加剧了责任追究的困难。

挑战与启示
追究组织责任的既有努力通常失败，对算法更难奏效。未来需探索新方法，以应对责任沉没问题。

互联网档案馆再遭入侵：攻击者利用窃取的访问令牌

互联网档案馆（Internet Archive）再次遭到入侵，这次是其Zendesk电子邮件支持平台，起因是威胁行为者窃取了暴露的GitLab认证令牌。

事件概述

• 入侵方式：攻击者利用了互联网档案馆开发服务器上暴露了近两年的GitLab配置文件中的认证令牌。
• 影响范围：攻击者通过该令牌访问了互联网档案馆的Zendesk系统，获取了自2018年以来发送至info@archive.org的超过80万张支持工单。
• 泄露数据：工单内容可能包括用户的查询、网站删除请求，甚至用户为从Wayback Machine删除页面而上传的个人身份证明文件。
• 再次发生：这是互联网档案馆在近期遭遇的第二次安全事件，此前曾发生过用户数据泄露和DDoS攻击。

技术细节与攻击链

1. 初始入口：威胁行为者发现互联网档案馆开发服务器services-hls.dev.archive.org上的GitLab配置文件。
2. 令牌利用：该配置文件包含的GitLab认证令牌（自2022年12月起暴露）允许攻击者下载互联网档案馆的源代码。
3. 凭证收集：源代码中包含更多凭据和认证令牌，包括数据库管理系统的凭据。
4. 数据窃取：攻击者声称窃取了7TB数据，包括用户数据库、源代码以及Zendesk API访问令牌。
5. Zendesk入侵：利用窃取的Zendesk令牌，攻击者访问了支持工单，并以互联网档案馆的名义向部分用户发送了警告邮件。

攻击动机与背景

• 动机：攻击并非出于政治或金钱目的，而是为了在数据泄露社区中获取网络声誉（cyber street cred）。
• 社区背景：存在一个交易被盗数据的威胁行为者社区，他们通过泄露数据来提升自己在社区中的声誉。
• 事件现状：被盗数据库可能正在该社区中交易，未来可能会在黑客论坛上免费泄露。

时间线与响应

• 2024年10月9日：互联网档案馆同时遭受数据泄露（影响3100万用户）和亲巴勒斯坦组织的DDoS攻击。
• 后续：BleepingComputer多次尝试警告互联网档案馆关于暴露的GitLab令牌问题，但未收到回应。
• 最新进展：10月20日更新显示，部分用户在请求删除页面时需上传个人身份证明，这些信息可能已被泄露。

安全启示

• 令牌管理：组织必须及时轮换暴露的认证令牌和API密钥。
• 代码安全：开发服务器和源代码中应避免硬编码敏感凭据。
• 持续监控：对长期存在的配置问题需要定期审查和更新。

Syncthing Android 应用停止维护

Syncthing 的 Android 应用（syncthing-android）已被官方宣布停止开发与维护。

• 决定：开发者正式宣布退役该 Android 应用。
• 最后版本：最后一个版本将与 2024年12月 的 Syncthing 主程序同步发布，届时也会在 Github 和 F-Droid 上架。
• 主要原因：此决定是多重因素导致的结果，主要包括 Google 平台政策变化带来的挑战，以及开发者自身维护负担过重。
• 影响：此公告意味着现有用户需要开始寻找替代的同步方案，该应用在最后一个版本发布后将不再获得更新或支持。

在使用x.com时遇到错误提示，建议禁用隐私相关扩展程序后重试。文章标题以反讽语气表达了对频繁弹出的用户协议接受请求的不满。

PostgreSQL 多版本并发控制（MVCC）实现缺陷分析

尽管 PostgreSQL 是极受欢迎的数据库，但其多版本并发控制（MVCC）实现被认为是主流关系型数据库中最差的。MVCC 旨在通过维护数据行的多个物理版本实现读写不冲突。PostgreSQL 采用“仅追加”存储，更新时复制整行，使用从旧到新（O2N）的版本链，并在索引中为每个物理版本添加条目以加速查找。同时，它依赖自动清理（autovacuum）机制回收死元组（过期版本）。

这种源于 20 世纪 80 年代的设计导致了以下四大核心问题：

1. 版本复制开销大

PostgreSQL 在更新时复制整行数据，即使只修改单个字段。这导致严重的数据重复，增加了存储和内存成本。相比之下，MySQL 和 Oracle 采用增量（delta）存储，仅记录修改部分。

2. 表膨胀（Table Bloat）

死元组与活元组混合存储。在写密集型负载下，死元组的积累会导致表体积持续膨胀，增加查询时的 I/O 和内存消耗。更严重的是，常规的 VACUUM 操作无法将未使用的空间归还给操作系统，必须使用极其消耗资源的 VACUUM FULL 或第三方工具才能回收物理空间。

3. 二级索引写放大

由于 PostgreSQL 的索引存储数据版本的物理地址，每次非 HOT（Heap-Only Tuple）更新都需要更新该表的所有相关索引。这引发了严重的写放大、额外的 I/O 开销以及锁竞争。而 Oracle 和 MySQL 的二级索引存储逻辑标识符，避免了此问题。

4. Autovacuum 管理复杂且易受阻

PostgreSQL 的性能高度依赖 autovacuum，但其默认配置（如大表需更新 20% 才触发）往往不够理想。此外，长时间运行的事务会阻塞 autovacuum，导致死元组堆积和统计信息过期，进而引发更多慢查询，形成需要人工干预的恶性循环。

总结

尽管 PostgreSQL 的 MVCC 设计存在历史遗留缺陷，但它依然是一款功能强大的数据库。针对上述问题，除了耗费精力进行手动调优外，还可以借助如 OtterTune 等自动化工具来管理和优化云环境下的 MVCC 性能问题。

计算机术语“Daemon”的起源

本文核心探讨了计算机术语“daemon”的起源。根据项目MAC成员、教授Fernando J. Corbato的澄清：

• 常见误解：有人认为“daemon”是“Disk And Executive MONitor”的缩写，并与1963年使用IBM 7094计算机时进行磁带备份的程序相关。Corbato教授表示这个缩写解释他闻所未闻。
• 正确起源：该术语的使用灵感来源于物理学和热力学中的概念“麦克斯韦妖”。麦克斯韦妖是一个想象中的、不知疲倦地在后台工作的智能体，用于分类不同速度的分子。他的团队借用此概念，来形象地描述那些在后台不知疲倦执行系统任务的“后台进程”。Jerome H. Saltzer教授也证实了这一解释。
• 词源背景：在语言学上，“daemon”与“demon”曾可互换使用，但后来“demon”衍生出“邪恶灵魂”的含义，而“daemon”则保留了“超自然存在”或“守护灵”的较中性含义，这与“麦克斯韦妖”中“智能助手”的意象相符。

文章后半部分还涉及其他语言相关的讨论，包括：

• 法语短语“au jus”（原意为“带汁”）在英语中的使用和语法争论。
• “RSVP”、“ATM machine”等缩写或短语中存在冗余的“请重复”现象。
• 词源探索，如威尔士语、西班牙语及拉丁语中“兔子”一词的关联，以及斯瓦希里语“pilipili”（辣椒）与波斯语、梵语的关系。
• 对“高尔夫”（golf）是“仅限绅士，女士禁入”首字母缩写这一民间词源说法的明确驳斥，并强调绝大多数英语单词并非源自缩写。

总结：文章主要澄清了计算机术语“daemon”的真正灵感来源是“麦克斯韦妖”这一科学概念，旨在描述后台工作的系统进程，而非某个特定技术的缩写。同时，文章也收录了若干关于短语用法、缩写冗余和词源的有趣讨论。

Martin Kleppmann 于2016年发表的文章对Redis网站上声称可实现容错分布式锁的Redlock算法提出了质疑。作者在研究中发现该算法存在根本性问题，不适合用于对正确性要求严格的场景。

锁的用途分类

分布式锁主要有两种用途：

1. 效率优化：避免重复执行昂贵操作。若锁失效，仅导致成本轻微增加或轻微不便。
2. 正确性保证：防止并发操作破坏系统状态（如数据损坏、永久不一致）。锁失效会导致严重后果。

作者认为，若仅为效率优化，使用单Redis实例（非集群）已足够，更简单、清晰且能表明锁的非关键性。Redlock的复杂架构（5节点、多数派投票）对于此目的过于臃肿。若为正确性保证，Redlock则不适用。

Redlock算法的核心问题

1. 缺乏围栏令牌机制

使用分布式锁时，即使获取锁，操作仍可能因进程暂停（如垃圾回收）或网络延迟而超时。正确的做法是使用围栏令牌——一个随锁授予而严格单调递增的数字，并在资源访问时验证。存储服务应拒绝令牌值低于已见最高值的请求，从而保证操作安全。

Redlock无法生成此类令牌，其使用的随机值不具备所需的单调递增特性。这是该算法在正确性关键场景中致命缺陷。

2. 过度依赖不安全的时间假设

Redlock的安全性建立在一系列时间假设上：

• 网络延迟有界且小于锁的TTL（生存时间）。
• 进程暂停时间小于锁的TTL。
• 系统时钟误差有界且稳定。

这些假设对应同步系统模型。然而，现实分布式系统通常是异步或部分同步的：网络延迟可能无限大（如GitHub曾出现90秒数据包延迟），进程可能被任意暂停，时钟可能跳跃（如NTP校时或手动调整）。文章举例说明，在这些常见异常下（如节点时钟跳跃、进程暂停期间锁过期、网络延迟），Redlock可能违反安全保证，导致多个客户端同时认为自己持有锁。

3. 不适用于异步系统模型

在学术界更实用的异步系统模型（带不可靠故障检测器）中，算法不应依赖时间假设来保证安全性（仅在活性上可用）。Redlock的安全性违反了这一原则，使其在真实分布式环境中风险极高。

作者结论与建议

Redlock算法“非驴非马”：对于效率优化过于复杂，对于正确性保证又不够安全。

• 仅需效率优化锁：使用单个Redis实例，明确文档说明锁仅为近似、非关键。
• 需要正确性保证锁：不要使用Redlock。应采用为部分同步/异步模型设计的共识系统，如ZooKeeper（可通过Curator等库使用），或具有合理事务保证的数据库。必须强制使用围栏令牌保护锁下的资源访问。

作者强调，Redis本身在其设计目的（存储易变、近似、快速变化的数据）上非常优秀，但分布式锁属于其设计之外的强一致性、持久性领域，使用时需认识到其局限性。

（注：文章提及作者Salvatore Sanfilippo后续发表了反驳文章，但本文作者仍坚持其结论。）

Bitwarden不再是自由软件

根据Pull request #10974的内容，Bitwarden桌面客户端的构建引入了@bitwarden/sdk-internal这一依赖项。该依赖项的许可证条款中包含以下限制：

您不得使用此SDK开发用于Bitwarden以外的软件（包括非兼容的Bitwarden实现）的应用程序，也不得开发另一个SDK。

此条款违反了自由软件定义中的“自由0”（即自由运行程序用于任何目的）。目前，构建桌面版v2024.10.0或当前主分支版本均无法绕过此依赖项。

BitEnergy AI工程师开发了一种名为线性复杂度乘法（L-Mul）的新AI处理算法，该算法用整数加法替代传统浮点乘法，在保持高精度的同时，有望将AI系统功耗降低高达95%。目前市面硬件（如英伟达Blackwell GPU）尚未适配此算法，需等待专用集成电路开发。由于AI算力需求激增导致能耗压力巨大——2023年数据中心GPU耗电量已超百万家庭年用量，甚至影响谷歌等公司的碳中和目标，该技术若得以应用，将大幅减轻电网负担并降低对气候的影响，可能推动AI能效领域的突破性进展。

HN Update 项目概述

这是一个名为 HN Update 的实时新闻广播服务。其核心功能是自动化抓取并播报 Hacker News 首页上排名前5的热门故事。

主要功能与更新机制：

• 更新频率：服务在每小时开始时自动更新内容。
• 内容来源：直接来源于 Hacker News 网站的实时首页。
• 播放功能：提供音量调节和1倍速播放的控制选项。
• 存档与回顾：当一个故事跌出前5名时，它会被自动移入存档区。当存档中积累了10个故事后，这些故事会被拼接、整合，生成一个“回顾（Recap）”剧集进行集中播报。

最后更新时间：内容显示最后一次更新发生在 2026年6月8日 凌晨 2点05分。

本文是一份关于分布式系统的精选阅读清单，旨在通过关键文章帮助读者转变系统设计思维。清单按主题分类，涵盖了从基础理论到具体实现的多个方面。

发人深省的观点

这些文章挑战了传统的设计思路，强调不能仅依赖大型服务器、数据库和事务。内容涉及现实世界中的CAP应用、大规模互联网服务设计、抽象接口的难度，以及分布式系统固有的无序和并行特性。Pat Helland和Jim Waldo等人的文章深入探讨了数据一致性、分布式计算的本质等核心问题。

延迟问题

延迟是分布式系统中必须应对的现实。相关文章讨论了延迟的架构影响、其作为新兴网络性能瓶颈的地位，以及大规模系统中处理延迟尾部的挑战。

企业实践案例

• 亚马逊：重点在于其转向服务导向架构（SOA）的文化与组织变革，而不仅仅是技术本身。
• 谷歌：展示了当时分布式系统的前沿技术，包括MapReduce、Chubby锁管理器、GFS、BigTable等，以及Spanner、Megastore等在全球分布式事务与一致性方面创新的系统。

一致性模型

此部分聚焦于在一致性与可用性之间寻找合适权衡。文章阐释了CAP定理的演变、最终一致性、避免两阶段提交的方法，以及放松一致性要求的乐观复制等策略。强调在实践中，“足够好”的一致性往往是可行的选择。

基础理论

包含了分布式系统设计中的关键理论要素，如分布式计算的经济学、经验法则、分布式计算谬误，以及FLP不可能定理、Lamport时钟、拜占庭将军问题等经典难题和解决方案。

语言、工具与基础设施

探讨了使用特定技术（如Erlang/OTP）构建分布式系统的陷阱。强调了稳健的时钟管理作为基础设施基础的重要性。

存储系统

介绍了数据分片的核心算法——一致性哈希，以及亚马逊Dynamo存储服务的设计。

共识算法（Paxos）

理解Paxos算法是一大挑战。清单建议从《Paxos Made Simple》入手，并列举了Paxos的原始论文、工程实践、变体以及实现容错服务的教程。同时，也介绍了像Mencius（适用于广域网）和Raft（作为Paxos的可理解替代方案）等其他共识算法。

其他协议与范式

• Gossip协议：探讨了基于流行病的通信模型的健壮性及其在监控、成员管理等方面的应用。
• P2P系统：列出了Chord、Kademlia、Pastry等经典的可扩展对等查找协议及其上构建的存储和消息系统。

在超低价8位微控制器上实现神经网络

该项目探索了在极端资源受限的Padauk PMS150C 8位微控制器上实现手写数字识别（MNIST）的可能性。该芯片成本极低（约3美分），仅拥有1024个13位字的一次性编程内存和64字节RAM，架构为简单的累加器式8位CPU，性能远低于常见的RISC-V架构。

核心挑战与数据处理： 由于存储空间极其有限，无法使用标准的28x28像素输入图像。作者将数据集大幅缩小至8x8像素，尽管损失了大量信息，但仍可辨认大部分数字。实验证明，在此分辨率下仍可训练出具有不错准确率的机器学习模型。

模型压缩与精度权衡： 作者进行了一系列超参数实验，探索权重量化级别（1-4位）与输入分辨率（8x8和16x16）对模型大小和测试准确率的影响。研究发现：

• 模型大小与测试准确率之间存在明确的正相关关系，直至达到某个精度上限。
• 对于8x8输入，可达到约98.5%的测试准确率，表现令人印象深刻。
• 对于极小的模型，8x8输入有时比16x16输入表现更好，因为第一层的参数量大幅减少。

适应硬件极限的模型设计： 为满足64字节RAM的硬性限制，必须极大优化模型结构：

1. 减少中间参数：使用极窄的网络层（宽度为16），将推理过程中的缓冲区需求降低至仅32字节（16字节输入缓冲区+16字节输出缓冲区）。
2. 量化与简化：采用2位不规则量化权重（取值为-2, -1, 1, 2），并跳过层归一化，改用常数缩放，以简化计算。
3. 最终模型：通过上述调整，最终获得了一个包含1696个权重、总计3392位（约0.414KB）、测试准确率为90.07%的微型模型。

嵌入式实现与优化：

1. 原型验证：先在资源稍多的PFS154芯片上使用C语言实现了验证代码，成功输出了推理结果。
2. 极致优化：针对PMS150C，由于C语言函数调用会消耗宝贵的RAM用于栈和参数，作者将推理代码“展平”（消除函数调用），并用汇编语言重写了核心内循环。该循环利用了芯片强大的位操作指令，高效地实现了2位权重与4位激活值的乘加运算。
3. 最终成果：成功将整个推理代码装入1千个字的内存中，SRAM使用量降至59字节，实现了完整的神经网络推理功能。

结论： 该项目证明，即使在最廉价、最简单的8位微控制器上，通过激进的模型压缩、量化以及针对硬件特性的底层代码优化，也能够实现具有一定实用精度的机器学习推理。它展示了边缘人工智能在极限低端硬件上实现的可能性，打破了其固有的硬件限制观念。尽管在此级别实现复杂应用仍具挑战，但该实验为超低成本智能设备的潜力提供了有力验证。

本文系统评估了QUIC协议在高速网络环境下的性能表现。研究发现，在快速互联网条件下，基于UDP+QUIC+HTTP/3协议栈的数据传输速率相较于TCP+TLS+HTTP/2最多下降45.2%，且性能差距随底层带宽增加而扩大。

该问题在多种场景中得到验证，包括轻量级数据传输客户端及主流浏览器（Chrome、Edge、Firefox、Opera），在不同主机（桌面端、移动端）和多样网络（有线宽带、蜂窝网络）中均存在。性能下降不仅影响文件传输，还对视频流媒体（码率最高降低9.8%）和网页浏览等应用产生负面影响。

通过详细的包追踪分析及内核与用户空间性能剖析，研究确认根本原因为接收端处理开销过高，主要表现为数据包数量过多以及QUIC在用户空间中确认（ACK）机制带来的负担。论文最后提出了具体的性能优化建议。

本文主要围绕WP Fusion公司向Automattic发送停止侵权信函的事件展开，概述了WordPress生态系统内的冲突、各方关系及事件的前因后果。

核心事件：WP Fusion的商标保护行动

• WP Fusion发现，商业平台WordPress.com（由Automattic运营）未经许可复制了其免费插件“WP Fusion Lite”，并将其置于WordPress.com的私有插件目录中，用于推广付费托管计划。
• 此举导致用户混淆，部分用户误以为向WordPress.com付费即购买了WP Fusion的高级服务，从而向WP Fusion的付费客户支持寻求帮助。
• 在近期WordPress社区动荡（如Matt Mullenweg强制接管竞争对手WP Engine的“Advanced Custom Fields”插件并改名“Secure Custom Fields”）的背景下，WP Fusion决定采取行动。
• 2024年10月12日，WP Fusion向Automattic发送停止侵权信函，要求移除WordPress.com上的“WP Fusion Lite”副本，以避免商标和品牌归属混淆。

核心冲突：Matt Mullenweg的角色与利益冲突

• Matt Mullenweg同时担任多个关键角色：WordPress开源项目的领导者、WordPress基金会（持有“WordPress”商标）的管理者、以及营利性公司Automattic（运营WordPress.com，估值75亿美元）的创始人兼CEO。
• 这种重叠引发了关于利益冲突的广泛质疑，尤其是当他利用其影响力（如控制WordPress.org代码库和插件目录）做出可能有利于Automattic的决定时。
• WP Fusion认为，Matt近期的行为（如强制接管ACF插件）削弱了社区的信任，并显示出其决策可能优先考虑商业利益而非开源社区的最佳利益。

事件发展与结果

• Automattic的法律总顾问于10月18日回复，同意从WordPress.com上撤下“WP Fusion Lite”的列表。
• 纠纷得以解决，WP Fusion的免费插件在WordPress.org上的列表恢复正常，消除了用户混淆。
• WP Fusion在采取行动前已做好准备，评估了可能遭到报复的风险（如从WordPress.org移除、被禁止参与社区活动等），并制定了通过自有服务器分发插件更新的应急方案。

背景与观点

• 文章指出，WordPress的GPL许可证允许自由复制和修改代码，但商标保护品牌的商业身份和声誉，防止消费者误解。
• 作者表示，经历此次事件后，不再信任Matt Mullenweg能在个人商业利益与开源社区福祉之间做出公正权衡。
• 文章还提及Matt曾采取法律威胁删除批评其行为的网站（如bullenweg.com），进一步引发了对其控制社区言论的担忧。

使用欧元硬币作为标准砝码（2004年）

本文介绍了如何利用国家流通货币（特别是欧元）的硬币，作为一种低成本、快速获得标准砝码的方法，用于测量重量不超过约100克的物体，精度可达约0.5克。其原理基于硬币在批量生产中具有恒定且准确的重量。

方法与工具

• 自制天平：使用一根直杆（如铝材）在中间点悬挂，两端悬挂托盘，构成简易平衡秤。
• 制作砝码组合：将不同面值的欧元硬币用窄纸条和胶水固定在一起，形成特定重量的组合。纸条和胶水的重量可忽略不计。

欧元硬币重量

各面值欧元硬币的重量并非整数克，这给直接使用带来不便。主要重量数据如下：

实用的硬币组合

通过组合少量硬币，可以获得一系列整克数或半整克数的实用重量。以下为部分示例：

• 15克和20克组合是核心，使用它们可实现5克的测量分辨率。
• 加入17.5克组合可将分辨率提升至2.5克。
• 表中其他组合（如9.96克、10.04克等）可用于实现1.0克或0.5克的更高分辨率。

构建更大重量与成本考虑

• 30克及以上的整5倍数重量（如30克、50克、100克），可以通过组合已有的15克和20克砝码来实现。例如，50克 = 2个15克 + 1个20克。
• 成本优化：硬币的面值越小，其单位货币的重量（克/欧元）越大。因此，为尽可能降低成本，文章中的组合优先选用小面值硬币（如1分、2分、5分、10分、20分、50分），且避免使用1欧元及以上的硬币。
• 组合多样性：对于目标重量，通常存在多种硬币组合方式，但重量越大（所需硬币数量越多），可能的组合方式也越多。10.5克以下的半整克数组合无法实现。

文章总结：最佳网格着色器（2023）

背景与目标

作者长期追求开发一个“完美”的网格着色器，旨在超越基于纹理的传统方法。纹理网格虽能实现透视正确的线条粗细，但在远距离仍存在锯齿、摩尔纹和线条突然消失等问题。常见教程中的着色器通常使用屏幕空间固定宽度线条，同样存在锯齿和摩尔纹，且线条在远距离无法正确衰减。现有的高级方法（如过滤脉冲串和盒式过滤网格）虽然能部分解决线条亮度问题，但在抗锯齿方面仍有缺陷。

作者的目标是创建一个满足以下所有要求的着色器：

1. 用户可配置线条宽度。
2. 线条具有透视粗细（非固定像素宽度）。
3. 在任何距离和视角下均无锯齿。
4. 线条宽度为0.0时完全隐藏，为1.0时完全填充。
5. 限制摩尔纹干扰图案。
6. 远距离融合至与纹理网格相同的亮度值。
7. 适用于实时渲染。

技术演进与关键创新

作者从基础着色器入手，逐步引入关键技术：

1. 基础网格：使用 smoothstep 和 fwidth 生成UV空间固定宽度线条，但远距离锯齿严重。
2. Phone-wire AA技术：借鉴Emil Persson的思想，限制线条在屏幕空间的最小宽度为1像素，并根据期望宽度与实际绘制宽度的比例进行淡出，以保持透视感并减少锯齿。
3. 宽度限制与融合：将绘制宽度限制在 uvDeriv（偏导数）和0.5之间，并使用相同的比值进行淡出。关键发现是，将绘制宽度限制在0.5（而非1.0）可确保平均亮度正确，从而使远距离融合值正确。
4. 摩尔纹抑制：基于UV偏导数（反映网格单元在屏幕上的大小）进行淡出，当网格单元小于约0.5像素时开始淡出至纯色，以避免出现明显的摩尔纹。
5. 线条反转：为实现线条宽度在0.0到1.0之间的完整范围，当宽度超过0.5时，通过反转线条和背景（绘制黑底白线并偏移半格）来等效实现，避免数学计算失真。
6. 偏导数计算优化：使用 length(float2(ddx, ddy)) 计算UV偏导数的模长，而非近似的 fwidth，以获得更准确的屏幕空间尺寸度量，尤其在斜对角方向。

最终方案与效果

经过这些步骤，作者实现了最终的着色器代码。该方案：

• 通过结合透视线条、动态宽度限制、比例淡出和基于尺寸的摩尔纹抑制，满足了所有预设目标。
• 在视觉效果上，作者认为其比基于纹理的网格、过滤脉冲串和盒式过滤网格更加平滑、无锯齿，且摩尔纹更少。
• 最后的细微调整在于使用更精确的偏导数长度计算方法，以在不同方向获得一致的视觉质量。

结论

作者认为该方案代表了当前网格着色器在抗锯齿和视觉质量上的一个顶点，直到有人提出更好的方法。

根据提供的网页内容，其主要展示了GitHub平台为开发者和企业提供的各类工具与服务。核心内容概括如下：

1. AI与代码创建：以GitHub Copilot为代表，旨在通过AI辅助开发者编写更优质的代码，并支持从问题跟踪到代码合并的全流程代理。

2. 开发者工作流：包括一系列自动化与协作工具，例如：

   • GitHub Actions：用于自动化各种软件开发工作流。
   • Codespaces：提供即时可用的云端开发环境。
   • GitHub Issues：用于项目规划与任务追踪。
   • 代码审查：管理代码变更流程。

3. 应用安全：强调在开发过程中内嵌安全能力，包括GitHub Advanced Security（用于发现并修复漏洞）、代码安全扫描以及机密信息保护等功能，以防止敏感数据泄露。

4. 解决方案与定位：平台针对不同规模的公司（企业、中小型团队、初创公司、非营利组织）和多种用途（应用现代化、DevSecOps、DevOps、CI/CD）以及不同行业（医疗、金融、制造、政府）提供定制化的解决方案。

5. 探索与资源：用户可以通过主题（如AI、软件开发、DevOps、安全）、类型（客户案例、活动、电子书等）来探索相关内容，并可访问文档、博客、社区论坛等支持资源。

6. 企业级服务：提供企业平台，包含高级功能如Copilot for Business（企业级AI功能）、高级安全特性和高级支持服务，并公开了定价信息。

总体而言，该页面描绘了GitHub作为一个集成了AI能力、自动化开发流程、安全保障及丰富生态的综合性开发者平台与企业解决方案的定位。

AI投资热潮

AI的快速发展正驱动美国固定资产投资的快速增长，以满足不断膨胀的计算需求，涉及高端计算机、数据中心设施、发电厂等，投入达数千亿美元。

核心投资现状

• 数据中心建设创新高：美国数据中心建设年化投资达286亿美元，同比上涨57%，两年内增长114%，规模约等于餐饮零售建设总和。
• 硬件进口激增：过去一年，美国大型计算机及零部件净进口总额超650亿美元，其中来自台湾的芯片、计算机及相关组件进口额超380亿美元，同比增长超140%。
• 科技公司资本支出飙升：信息技术公司（如亚马逊、谷歌、微软）过去一年固定资产净值增加超950亿美元，创历史新高，以大规模部署AI系统。

投资驱动与模式转变

• 硬件密集型：当前AI热潮的硬件密集程度超过以往任何科技浪潮。例如，Meta在2024年上半年资本支出已达152亿美元，主要用于AI模型所需计算基础设施。
• 投资结构性变化：2023年数据显示，软件开发商在知识产权（含AI模型及研发）上的实际投资自2021年增长40%，在设备（如计算机）上的实际投资更是猛增96%。
• 投资地域集中：数据中心建设仍主要集中于美国南部传统集群，但中西部和西海岸增长更快，东北部受影响较小。

能源需求与影响

• 电力需求显著增长：美国能源信息署因数据中心需求上调商业用电预测，预计今年商业用电增长3%，明年增长1%。
• 局部影响巨大：弗吉尼亚州因全球最大计算集群，商业用电自2019年增长30%；德克萨斯州增长10%，并成为可再生能源投资领先州。
• 驱动清洁能源：科技公司直接投资发电基础设施的趋势上升，如微软重启核电站以满足数据中心需求，德克萨斯电网（ERCOT）和弗吉尼亚电网（PJM）的可再生能源增长预计领先全国。

就业与行业收入

• 就业增长乏力：尽管投资热潮，传统信息技术领域就业增长疲软，过去一年仅增加3.2万个科技岗位，软件和计算基础设施行业就业基本停滞。
• 相关领域受益：半导体制造业总薪酬同比增长25%（受股票期权推动），商业建筑就业增加（部分源于数据中心建设），以及芯片制造和电力基础设施领域的就业增长。
• 收入反弹：信息技术领域收入从2022-2023年的放缓中回升，过去一年增长12-15%。

地缘政治与未来展望

• 投资竞争加剧：AI开发者竞相投入，预期随着模型进步和商业化扩展（如自动驾驶），投资将进一步增加。
• 依赖与竞争：美国高端半导体需求剧增，加剧对台湾进口的依赖（尽管《芯片法案》旨在减少依赖），且在多种组件上依赖中国供应链。美国限制中国获取高端芯片，中国则致力于提升自主产能。
• 政策关注：AI发展和数据中心容量被视为美国未来经济的关键，当前热潮使美国投资受益多于他国，但硬件产能的地缘政治竞争预计会加剧，围绕芯片的“战争”将继续升温。

SQL采样技术摘要

本文介绍了如何利用SQL实现高效、灵活的加权采样算法，重点解决了传统数据库内置采样功能（如TABLESAMPLE）在复杂场景下的局限性。

核心问题与目标

作者提出了需要支持多种现实场景：

1. 支持有放回和无放回采样。
2. 支持加权采样，即选择概率与权重成比例。
3. 处理极端权重值，范围从极小（如10^-20）到极大（如10^20）。
4. 支持确定性采样，以实现可重复的结果并可能优化查询。

关键算法：A-ES算法（无放回加权采样）

文章重点介绍了Efraimidis和Spirakis在2006年提出的单遍算法（A-ES算法）的SQL实现。

• 基本思路：为每一行生成一个随机数u_i，计算键值k_i = u_i^(1/w_i)（其中w_i为权重），然后选取键值最大的m行。
• SQL实现优化：直接使用幂函数在大/小权重下存在数值稳定性问题（键值会坍缩到1.0或0.0）。因此，采用等价的对数变换：ORDER BY -LN(1.0 - RANDOM()) / weight。这种形式更稳定，并且揭示了算法与泊松过程理论的联系。
• 泊松过程证明：将每一行视为一个以w_i为速率的泊松过程，算法计算的键值k_i等价于该过程下一次“到达”的时间。对键值排序取前m个，等价于让所有行的竞争过程进行比赛。利用泊松过程的无记忆性、可合并性和按速率比例赢得竞争的性质，可以证明该算法实现了按权重公平的逐次无放回抽样。

采样性能优化

针对存储在列式存储格式（如Parquet）中的大型数据集：

• 问题：基本SQL查询会强制读取所有列，效率低下。
• 解决方案：采用两阶段查询。第一阶段仅读取用于确定采样行的列（如主键pk和weight），利用算法找出样本的主键。第二阶段再根据这些主键获取完整的所需列。这充分利用了列式存储“只读所需列”和“过滤下推”的优势。

确定性采样

将算法中的RANDOM()函数替换为确定性伪随机函数（如基于主键、种子和索引的哈希函数）。这使得采样结果可重复，并为实现有放回采样奠定了基础。

有放回加权采样

文章进一步提出了一种高效的SQL有放回采样算法：

1. 首先利用A-ES算法快速获得一个无放回样本S（大小为m）。
2. 对于样本S中的每一行，为其生成多个（但远少于m个）“到达时间”（伪随机数）。
3. 将所有这些到达时间进行全局排序，选取前m个作为最终的有放回样本。 通过理论分析，只需为每行生成约c * (m * 该行权重/总权重)个到达时间（c为略大于2的常数），即可以极高的概率得到正确结果，从而将时间复杂度从O(m^2)优化到接近O(m)。

总结

文章通过连接泊松过程理论与SQL实践，提供了一套完整、高效且灵活的加权采样解决方案，覆盖了无放回、有放回、加权、确定性以及极端权重值等关键需求，并给出了在列式存储上的性能优化技巧。

Dwarf Fortress – Boatmurdered 序章

游戏记录概述

本文是一篇基于游戏《矮人要塞》的续写式（Let's Play）记录。内容记录了史诗般的矮人堡垒“Boatmurdered”的兴衰历程（实际上主要是衰落）。游戏规则为：每位“统治者”拥有一个游戏年份的时间管理堡垒，之后交由下一位玩家接管。原文作者仅添加少量编者注进行说明，大部分内容直接展现堡垒本身的混乱。

参与的“统治者”名单

以下为轮流管理Boatmurdered的玩家名单：

• TouretteDog
• mariguana（又名 megor grendel）
• Keyboard Fox（又名 Furry, Kalo）
• Locus
• StarkRavingMad
• Bremen
• Sankis
• Astronautonomicon
• Unknowing
• Cross Quantum
• Major Failure
• Mystic Mongol
• Doctor Zero
• Guerilla Medic

堡垒历史关键转折

堡垒历史的所有时期都值得关注。事情从最初相对日常的大象死亡，迅速发展到退休统治者狂暴杀人（同时自身着火）。历史学家普遍认为，堡垒的疯狂程度在StarkRavingMad统治时期开始几乎呈指数级增长，其标志是史诗性的**“大象战争”**。

《矮人要塞》游戏简介

为方便不熟悉游戏的读者，原文提供了一个速成指南。

核心概念

• 游戏类型：一款以建造基地为核心的2D游戏，主题类似《地下城守护者》。
• 核心特点：游戏概念和画面简单，但拥有惊人的深度（由单人公司开发）。
• 矮人行为：你控制的矮人具有一定自主性。他们有好恶和需求，虽然可以分配任务和下达基本命令，但他们会根据自身心情行动。所有生物（包括矮人和动物）的伤害都会追踪至具体器官和身体部位。
• 情绪与事件：矮人情绪受环境影响，可能举办派对，也可能在压力下突然互杀。女性矮人可能怀孕，若遭受创伤（如哥布林围攻）可能导致流产，由此产生的悲伤可能引发暴动甚至自杀。
• 初始目标：游戏开始时，你拥有7个矮人和少量物资，位于山体表面。唯一目标是在不可避免地死亡之前，抵御自然因素，建造尽可能酷的堡垒。
• 显示方式：游戏以伪ASCII风格显示，使用字母代表游戏内物体（类似《NetHack》）。

游戏界面符号图例（基于文中提供的图片说明）

• 1：= 符号区域代表储存区，用于存放工艺品、桶和食物。
• 2：代表用于捕捉生物的笼子。
• 3：开凿山体产生的石堆，可用于制作物品。
• 4：绿色矩阵样图案代表地面。堡垒内平滑的地面用+符号表示。不同玩家可能使用不同的图块集，但最终都能习惯。
• 5：矮人形象，不同颜色代表不同职业。图中所有矮人都是应征入伍的新兵，正愚蠢地冲向死亡。
• 6：E代表大象。它会以精彩的方式谋杀矮人。方括号[和]代表丢弃的盔甲或衣物。灰色块是未开采的岩石墙壁。带十字的块是石门。房间内密集的2符号是动物或矮人的骨头。
• 7：^符号代表陷阱。其下的平行线代表平滑的墙壁。
• 8：这是一堆死亡的矮人、一头大象以及一团瘴气。瘴气是尸体腐烂时出现的紫色斑点，会让矮人愤怒，通常导致滑稽场面。
• 9：两个绿色星号*是已从墙壁中开采出来、等待存储的宝石。
• 10：攻城器械，此处是两架瞄准死亡矮人所在走廊的弩炮。
• 11：带有类似符号的黑色空间代表尚未开采的山体区域。

其他说明

• 在其他图片中，通常会在屏幕右侧看到一个黄色的X和一个命令列表，文本内容通常描述黄色X下方的物体。
• 如需进一步了解游戏，可访问官方网站和Wiki，以及相关问答帖子。

最终邀请

所有截图基本都自带说明，欢迎读者前往阅读。最后，借用伟大的统治者StarkRavingMad的话：

“欢迎来到该死的Boatmurdered！”

根据预印本研究，尽管自闭症患者表现差异巨大，但他们可被划分为四个核心亚型。每个亚型的人群共享相似特征和生活结局，并携带影响不同生物通路的基因变异。

该研究分析了来自SPARK研究队列的5392名自闭症儿童的特征、行为和遗传数据。通过统计模型，研究团队发现将参与者分为四组时，组内相似性最为显著：

1. 轻度特征组（1976人）：核心自闭症特征挑战较轻。
2. 社交与行为问题组：主要表现为社交困难和扰乱性行为。
3. 发育迟缓与特定特征困难组。
4. 全面严重困难组（554人）：在核心特征上表现出全面且严重的困难。

该分类在独立队列（Simons Simplex Collection）中得到验证，显示了良好的一致性。同一亚型的患者常共享相同的共病诊断（如社交问题组更易伴有ADHD或焦虑症；严重困难组更易出现认知障碍）。

遗传与生物学基础：

• 每个亚型与特定的常见基因变异和罕见突变（如新生突变）相关。
• 这些变异影响不同的生物通路（如轻度组影响组蛋白甲基化，发育迟缓组影响神经元动作电位）。
• 变异在不同发育阶段影响基因表达：发育迟缓组（通常早期确诊）的变异影响胎儿和新生儿期表达；社交与行为问题组（通常较晚确诊）的变异影响出生后表达。

这些发现表明，自闭症亚型的遗传特征可能部分决定了临床发展里程碑。研究团队计划利用更多数据（包括全基因组序列）进一步完善模型，以深入探索亚型间的机制差异，并可能提供更精细的分类和预测信息。

文章总结：阻塞代码才是真正的“泄漏抽象”

本文作者作为Rust异步运行时smol的维护者，反驳了“异步代码是泄漏抽象”的常见批评，认为在Rust中，阻塞代码才是真正的泄漏抽象。核心论点如下：

1. 互操作性对比：

   • 从阻塞代码调用异步代码：相对简单直接。只需使用block_on（如futures_lite或pollster提供）阻塞等待异步函数返回的Future即可，该操作通常只涉及线程局部访问，开销小。
   • 从异步代码调用阻塞代码：更为复杂且问题更多。异步代码通常要求函数不阻塞以避免卡住事件循环，因此需要将阻塞调用通过unblock或spawn_blocking转移到专用线程执行。这会带来额外开销（如内存分配、线程池通信），且函数需满足Send和'static等限制，增加了代码设计的复杂性。

2. 阻塞代码的不可预测性：

   • 异步函数返回的Future通常遵循poll方法快速执行的约定，行为较可预测。
   • 普通阻塞函数则无法从其签名判断执行时长（可能瞬间完成、可能阻塞I/O或长时间计算），迫使异步程序开发者必须仔细审查依赖代码，或使用额外包装来隔离阻塞调用。

3. 库与语言限制：

   • 当前异步生态的问题（如库依赖特定运行时如tokio）主要源于库设计，而非异步模型本身。
   • 尝试通过文档或语言属性（如#[blocking]）标记阻塞函数面临现实困难，因为阻塞行为可能依赖运行时条件，难以静态分析。

4. 结论：

   • 异步代码的“泄漏”主要由库生态导致，可通过标准运行时启动或工具库解决。
   • 阻塞代码的“泄漏”是其固有设计缺陷：无法从接口明确行为，且侵入异步模型时需要复杂改造和额外成本。因此，作者认为异步代码更优雅，鼓励社区减少对异步的顾虑。

《2001太空漫游》中的刮痕研究摘要

本文是对斯坦利·库布里克1968年电影《2001太空漫游》中一处特定“刮痕”的详细研究。这些刮痕并非电影拷贝的偶然损伤，而是电影制作过程中固有的元素，存在于原始拍摄素材中。

刮痕的本质与位置

• 来源：这些刮痕产生于用于背投技术填充飞船上众多计算机屏幕的16毫米胶片循环上，具体发生在1965或1966年电影拍摄期间。
• 出现场景：在影片中，它们仅出现在 “EVA舱”内部的“COM”计算机显示器上，并且只在该显示器显示特定读数序列（一个波动的图表随后“COM”标识出现）时才闪现。主要出现在两个关键场景：
  1. “Pod 1”场景：宇航员弗兰克·普尔执行更换AE-35单元任务时。
  2. “Pod 2”场景：戴夫·鲍曼试图营救普尔时。
• 视觉特征：在华纳2007年蓝光版中，可以观察到刮痕带有绿色和黄色色调，这暗示它们可能发生在16毫米胶片的乳剂层（而非片基层）。

在不同版本中的存在情况

作者检查了从VHS到70毫米IMAX等十多种版本的电影，刮痕的可见性存在差异，这通常与画面裁剪或数字修复有关。

计算机读数的制作技术背景

文章后半部分详细解释了电影中逼真的计算机界面是如何在没有实际计算机的情况下制作的：

• 挑战：库布里克被建议使用平面屏幕，但当时计算机图形技术有限且分辨率低。
• 方法：由道格拉斯·特朗布尔领导的团队使用模拟技术手动制作所有动画。他们使用一台改装的35毫米米切尔摄影机，通过移动玻璃板上的图表、文字剪贴和彩色滤镜，逐帧拍摄动态图形。
• 素材来源：灵感部分来源于《科学美国人》等杂志的图表，并创造了一套由数字和字母组成的“HAL语言”。
• 投影：完成的动画从35毫米转制到16毫米胶片循环，通过隐藏在布景中的16毫米投影机背投到飞船控制台的屏幕上。
• 工程实现：为了解决旋转离心舱布景中的投影问题，布莱恩·约翰逊设计了将投影机背靠背安装的方案，并处理了噪音、散热和灯泡损耗等实际问题。
• 其他应用：部分相同的图形材料也被用于制作著名的“星门”序列的视觉效果。

结论与意义

这些刮痕是电影物质性的证明，它们并非数字产物，而是源自模拟时代的电影制作过程。它们的存在与否成为了辨别不同电影版本的一个有趣“法证工具”，并引发了对电影修复原则（是恢复“原貌”还是抹去岁月痕迹）以及“原版”概念的思考。文章还列举了多年来爱好者对HAL 9000界面进行数字复刻的多种尝试。

IPv6过渡现状总结

本文是Geoff Huston于2024年10月撰写的一篇关于IPv6过渡进程的分析文章。文章回顾了IPv6过渡的历史、现状及面临的挑战，并指出当前互联网架构的根本性变化可能使得完成全面过渡的紧迫性降低。

核心现状

• 采用率增长但缓慢：APNIC Labs的测量显示，截至2024年，仅约三分之一的互联网用户能够通过IPv6访问仅支持该协议的服务。自2019年以来，美国的IPv6采用率基本停滞。
• 过渡时间线漫长：若按近年线性增长趋势外推，IPv6过渡可能需持续至2045年左右才能完成，这意味着整个过渡期可能长达约30年。
• IPv4仍在支撑互联网：尽管IPv4地址在十多年前已耗尽，但互联网仍主要依靠IPv4运行。当前约有200亿设备接入互联网，却只使用约30.3亿个唯一IPv4地址，平均每个地址被约7台设备共享。

过渡缓慢的主要原因

1. 设计缺乏紧迫性：IPv6协议设计极为保守，仅是“地址更大的IPv4”，在速度、多功能性或安全性方面未带来明显提升，其主要收益（缓解地址耗尽风险）被视为未来收益，市场激励不足。
2. 分布式部署的困境：ISP、主机、应用开发者相互观望，缺乏协同推动过渡的动力。
3. 历史时机延误：在IPv4地址耗尽压力初现时，行业更关注应对爆炸性增长（如移动互联网兴起），IPv6部署被搁置。早期过渡机制（如6to4、Teredo）效果差，反而损害了IPv6声誉。
4. NAT与服务器架构的缓解作用：
   • 网络地址转换：NAT通过地址共享极大地提高了IPv4地址利用效率，显著缓解了地址稀缺压力。
   • 服务器共享与CDN：TLS的服务器名称指示和内容分发网络使得单个IP地址可以托管大量服务，域名取代地址成为关键服务标识符，降低了对唯一IP地址的需求。
5. IPv4市场趋于平衡：2024年IPv4地址交易价格在30-40美元间稳定，表明供需已平衡，稀缺性溢价消失。

互联网架构的根本性转变 文章指出，互联网的核心价值已从网络层转移到应用与服务层，这是过渡迟缓的深层原因。

• 资源廉价化：摩尔定律带来计算、存储和通信能力的指数级增长与成本下降，这些资源变得丰富且廉价。
• 经济重心上移：互联网经济的重心从网络（带宽、距离）转向了应用、内容和服务（如CDN、云平台）。网络正逐渐演变为“哑管道”。
• 基于名称的架构：域名成为服务标识、认证和路由（通过DNS引导至最佳服务节点）的核心，取代了传统上对唯一端到端地址的依赖。TLS/SNI和CDN架构使得本地化服务交付成为可能，削弱了全局唯一地址的必要性。

结论与展望

• 作者认为，当前双栈（IPv4/IPv6）共存的过渡状态可能会长期持续，既无完成过渡的强烈意愿，也无退回纯IPv4的动力。
• 随着互联网的价值越来越多地由应用和内容驱动，对底层网络协议统一性的关注可能会持续减弱。IPv6过渡问题可能逐渐变得“无关紧要”。
• 文章最后提出疑问：在全球通信能力日益丰富、服务高度本地化和基于名称的今天，传统的基于唯一地址的互联网架构概念是否已经过时？

博客正式退役公告

Ribbonfarm 博客将于 2024年11月13日（作者50岁生日）正式停止更新。此前，它已处于半退休、维持基本运营（KTLO）模式多年。域名和现有链接将继续有效，但此后该网站将转型为一个静态的“博物馆式”存档站点。

退役原因与时代背景

• 博客时代终结：作者认为博客圈（Blogosphere）的时代已经结束，这与以往的起伏不同。其鼎盛期（约2000-2020年）与互联网的“第二章节”高度重合，博客是“Web 2.0”的核心。
• 宏观叙事关联：博客的活跃期（2007-2024）恰逢一个文明阶段，以全球金融危机（GFC）和2024年美国大选为起止点。退休标志着进入一个由博客帮助开启、但博客将不再参与的新时代。
• 经济因素驱动：博客时代是低利率环境（ZIRP，零利率政策）的产物，依赖廉价托管和免费全球分发（通过RSS、Twitter）。随着利率上升和分发渠道被垄断（如Twitter被收购），公共社交媒体的黄金时代随之落幕。
• 向“舒适网”（Cozyweb）转型：2019年左右出现的“舒适网”（Discord、Slack、私密群组等）同样受高利率和付费分发模式塑造，但至少不是保护费式的垄断。作者认为这种模式可能持续至2035年左右，并已在此前通过调整写作风格（如创作“博客链”）、停止追求“病毒式传播”内容等方式，为从公共领域向私密/半私密领域的撤退做准备。

博客的历程与遗产

• 三个时代：博客历史可划分为“锈蚀时代”（2007-12）、“雪花时代”（2013-18）和“停尸房时代”（2019-24）。第二阶段以活跃的子文化社群（Refactor Camp等活动）为标志。
• 风格对比：博客时代的盛行风格是充满幽默、近乎虚无主义的“狗屎帖”（shitposting），在公共广场上演示。而当前以Substack为代表的“舒适网”写作风格更趋向于严肃、庄重的“室内乐”，针对受邀听众进行表演。
• 技术与文化影响：博客的技术遗产（如时间线信息流、RSS）依然存在，但其文化领导地位已被取代。博客时代是公共社交媒体充满活力与宏大景象的时期，尽管也带来了混乱。

未来规划

• 博客存档：博客将转为静态存档站，成为一座“博物馆”。作者计划以低成本方式托管，并添加导览、“博物馆商店”（售卖书籍）等元素。
• 内容迁移：部分非虚构写作（如关于科技趋势和连载书籍项目）将继续在作者的 Substack 上进行，但该平台风格与博客不同，作者感觉并不完全契合。
• 其他创作方向：博客中剩余的主线（叙事理论、虚构实验、对平庸的思考、实验室笔记等）需要移植到更合适的媒介。例如：
  • 实验室创作适合视频和小型协作社群（如Yak Collective Discord）。
  • 虚构作品不适合博客的逆向时间流，可能存在于Roam或中篇电子书草稿中。
  • 叙事理论、平庸论等非虚构主线最终可能整理成专著式电子书/实体书。
• 随机想法的出口：作者面临的核心难题是“去哪里放置随机的想法、2x2矩阵、涂鸦等”。这些内容具有社交性，依赖公共分发以激发互动，不适合私密笔记、严肃的Substack或付费平台。目前尚无完美解决方案，作者笑称或许会“将纸条放入塑料瓶投入太平洋”。
• 个人生活转变：作者计划从“数字居家、物理游牧”的状态，转向“数字游牧、物理定居”（希望在西雅图地区购房）。

最后更新 在最终退役日前，将发布一篇最终的汇总帖，并可能在当天（11月13日）发布一篇简短的“墓志铭”帖文。作者感谢读者陪伴，并邀请关注其Substack（活跃于Notes区）以及Farcaster和Bluesky。

文章标题： 数据版本控制 (Data Version Control)

核心概念： 该内容介绍了 Data Version Control (DVC) 这一理念与工具，其核心思想是采用类似 Git 的软件工程最佳实践来管理数据、AI/ML 模型及数据科学项目，实现“像管理代码一样管理数据”。

主要产品/服务定位： DVC 提供了两种主要方案以满足不同用户需求：

1. 针对企业级团队： 提供高度可扩展的数据版本控制基础设施，专为复杂的AI操作和大数据环境设计，能够处理PB级别的多模态对象存储和数据湖。
2. 针对个人数据科学家： 提供一个轻量、易用的 Git 扩展，用于小型数据科学项目。它能以极低的开销将数据版本控制集成到现有工作流中。

项目影响与资源：

• 该项目在 GitHub 上拥有活跃的社区，声称已服务数千用户及客户，范围从初创公司到财富500强企业。
• 提供博客更新订阅和 RSS 源供用户获取最新信息。

VersaTiles：一个完整的自由/开源软件地图技术栈

VersaTiles 是一个完全基于自由/开源软件（FLOSS）的技术栈，用于基于 OpenStreetMap 数据生成、分发和使用地图切片，不涉及任何商业利益。

项目定位

VersaTiles 是一个免费且开源的替代方案，旨在替代 Google Maps 或 Mapbox 等商业地图服务。它专为需要可靠地图且避免供应商锁定的新闻编辑室、非政府组织、开发者及公共机构设计。该项目完全可自行托管，无需 API 密钥，不收取使用费，也不跟踪用户。

工作原理

1. 生成：将 OpenStreetMap 数据和卫星影像转换为优化后的地图切片，或下载现成的切片。
2. 服务：使用轻量级、高性能的切片服务器向客户端分发切片。
3. 渲染：通过 MapLibre 和专业设计的地图样式，在 Web、Android 和 iOS 上展示精美的地图。
4. 工具：提供交互式工具，用于自定义样式、设置服务器、探索地图数据以及编辑地图。

主要组件与工具

项目提供了丰富的工具和组件供探索：

• 实时演示与工具：样式生成器（如 Colorful, Satellite）、容器阅读器、Svelte 组件、SVG 渲染器、前端捆绑包、实验性的等值线管道、正射影像覆盖状态查看工具。
• 服务器与命令行工具：用于服务地图切片。
• 库：用于集成地图功能。
• 样式工具包：生成 MapLibre 地图样式。
• 规范与社区：包含 .versatiles 容器格式规范，以及 GitHub 组织、Mastodon 和 Bluesky 等社区渠道。

重要里程碑

• 2026-04-05：发布全球高程数据，支持地形阴影和 3D 地形可视化。
• 2026-01-02：versatiles-rs（Rust 编写的 CLI 工具）增加了 Node.js 绑定。
• 2025-10-08：发布全球影像数据，整合免费的卫星和航空正射影像。
• 2025-02-01：发布免费的地图编辑器。
• 2023-07-16：versatiles.org 官方网站正式上线。

路线图

• 已完成：发布文档、地图编辑器、Docker 容器、Node.js 绑定、卫星影像、样式编辑器插件、交互式服务器设置工具、SVG 导出、免费全球高程数据、简化 GeoJSON 到矢量切片的转换。
• 计划中：寻找合作伙伴和赞助商；将切片生成迁移至 Planetiler；发布 VersaTiles Studio 一体化地图创建应用；集成全球土地覆盖数据。
• 需探索资助：更新和扩展卫星影像；构建新的样式引擎；为地形阴影和等高线提供新的矢量切片。

资助来源

项目获得欧盟委员会“下一代互联网”计划通过 NLnet 的 NGI0 Commons Fund 资助，以及 MIZ-Babelsberg 对“VersaTiles 编辑工具”开发的资助。

本文探讨了在无任务情境下使用“大声思考”（Think Aloud）方法研究意识流的可靠性。研究通过两项实验，系统比较了“大声思考”与“静默思考”对思维过程的影响。

• 研究背景与目的： “大声思考”是研究主观体验的常用方法，但尚不清楚该方法本身是否会改变思维的特性（如元认知觉察、话题转换频率或思维内容）。本研究旨在检验在无特定任务约束时，该方法对自然意识流的干扰程度。
• 研究方法：
  1. 实验1：采用平衡设计，让111名参与者在15分钟的间隔内交替进行“大声思考”和“静默思考”。部分参与者还需通过自我报告和探针捕捉的方式间歇性报告话题转换。
  2. 实验2：102名参与者被分配执行“大声思考”或“静默思考”的单一任务，同时回应思维探针。
• 核心发现：
  1. 对意识流的影响极小：在两项实验中，“大声思考”条件与“静默思考”条件相比，在元认知觉察和话题转换频率这两个关键指标上均未发现显著差异。
  2. 差异范围有限：在实验1分析的21种思维特性和18个内容主题中，仅有3个特性（私密想法、头脑空白、任务难度感）和1个内容主题（伴侣、亲密关系等）在两种条件下表现出差异。
  3. 认知负荷无差别：实验2发现，两种条件下的自我报告认知负荷没有区别。
• 结论： 研究结果表明，“大声思考”流程对自然状态下的意识流干扰非常小，是一种可靠且反应性低的范式。因此，该方法为在无任务背景下研究难以口头报告的意识流提供了一个稳健的工具。

“文档即代码”（Docs-as-code）不仅指使用与开发者相同的工具（如 Git 和 Markdown）和方法来编写文档，其核心在于将技术文档视为软件基础设施的关键组成部分。

文档是至关重要的软件基础设施。移除或未能提供文档，产品将无法有效使用。文档的重要性堪比服务器、路由器等基础设施，它使用户无需深入理解代码就能使用产品。缺失文档会对企业产生直接冲击：销售工程师无法有效演示产品，客服无法提供高效解决方案，新功能的用户知晓度和增长指标也会受损。

“文档即代码”意味着技术文档工作（由文档工程师或技术作家承担）是与代码紧密相关的、影响产品成败的关键工程活动。文档不仅包括手册，也涵盖嵌入式文档，如用户界面文本、上下文帮助和错误消息。

因此，文档的发布流程必须遵循与代码和关键交付物相同的严格方法论。这意味着文档需要经历代码那样的审查、检查和合并流程，不能仓促发布。仅仅将文档纳入“完成定义”是不够的，必须建立相应的标准和规则。结构化、全面、准确且经过充分测试的文档，其本身就能像良好的基础设施一样，缓解和弥补开发中仓促带来的问题。

文档工程师的成功不应仅通过文档本身的媒体指标来衡量，而应通过文档可观测性指标，衡量其对功能乃至产品整体成功的贡献。

在现代软件开发中，文档工程师是文档工作的专家和架构师，他们协调和提升整个工程团队对文档的重视与共同责任感，而不仅仅是独立完成写作。需要将“文档即代码”视为一种产品沟通的战略方法，其真正承诺是通过使用开发者工具来缩小文档与产品之间的鸿沟，构建复杂系统与用户之间的理解之桥。