Google Illuminate：将书籍和论文转化为音频

工具概述
Google Illuminate 是一个生成式人工智能（Gen AI）工具，专门设计用于将研究论文和书籍转换为 AI 生成的音频摘要。该工具旨在通过音频格式帮助用户更快速、更便捷地理解复杂内容。

主要功能

• 内容转换：自动将文本形式的研究论文或书籍转化为音频摘要。
• AI 生成：利用人工智能技术创建音频内容，确保信息准确且易于吸收。
• 学习辅助：专注于提升学习效率，使用户能够通过听觉方式快速掌握核心概念。

目标与好处

• 加速理解：针对复杂学术材料，提供音频摘要以减少阅读时间，增强学习体验。
• 用户友好：通过音频格式，方便用户在移动或通勤等场景下学习。
• 免费工具：作为 Google 产品的一部分，可能提供免费访问或试用版本。

访问方式
用户可通过官方网站 illuminate.google.com 访问该工具，并获取更多信息或开始使用。

技术背景

• 基于生成式 AI 技术，实现文本到音频的自动化转换。
• 作为 Google 应用的一部分，整合了先进的自然语言处理和音频生成能力。

总结
Google Illuminate 是一个创新的 AI 工具，专注于将学术文献转化为音频格式，旨在简化学习过程，帮助用户更高效地处理复杂信息。

文章概述 本文介绍了一种利用Apple Watch（Series 5及更新型号）内置的磁力计来测量直流电的方法。该方法通过在手表外缠绕一个线圈，将待测电流产生的磁场转化为手表可感知的磁场变化，从而间接测量电流。

核心原理与方法

1. 硬件基础：Apple Watch的指南针功能依赖于磁力计，该传感器能感知周围的磁场，包括电流通过导线时产生的磁场。
2. 测量装置：在手表外壳上缠绕一个已知圈数（N）和直径（D）的导线线圈。根据公式 B = (u₀ * I) / D （其中 u₀ = 4π×10⁻⁷），流经线圈的直流电（I）会在手表内部产生一个额外的、垂直于表盘（Z轴方向）的磁场。
3. 灵敏度估算：对于直径约48毫米的Apple Watch，一个5匝的线圈，每1安培电流理论上可产生约131微特斯拉（μT）的磁场。考虑到磁力计传感器通常位于表盘右下角而非中心，实际灵敏度略低，文章建议采用100 μT/A作为合理近似值，并可通过校准改进。
4. 应用与操作：
   • 可以使用任何能显示原始磁力计数据的免费应用（如文中提到的“Sensor-App”）来读取Z轴的磁场值。
   • 专用应用可以实现校准、消除零点偏移并直接以安培为单位显示电流。
   • 此方法仅适用于直流电（DC），因为磁力计的采样速率不足以响应交流电（AC）的快速变化。

性能与注意事项

• 分辨率：使用一个5匝线圈，通过数据平均过滤噪声，可以检测到约10毫安（mA）的电流变化，这对应于Z轴约1微特斯拉（μT）的磁场变化。
• 线性关系：Z轴磁场读数与电流变化呈极佳的线性关系。文中图表显示，对于5匝线圈，测得的灵敏度为113 μT/A。
• 干扰因素：
  • 地球自身的背景磁场（约60 μT）是主要干扰源，其方向不限于南北。
  • 测量时应保持手表和周围环境中的磁性物体静止，因为它们的移动也会改变磁场读数。

本文探讨了高质量字体（付费或免费）所提供的丰富功能，强调不应浪费字体设计师的成果。超越基本的字重和斜体，现代OpenType字体通过单个文件集成了大量高级特性。

核心概念：可变字体轴

OpenType可变字体包含一个或多个“轴”，通过调整其值可动态改变字体外观。最常见的标准轴包括：

• wght：控制字重。
• wdth：控制宽度。
• slnt：控制倾斜。
• ital：控制斜体。
• opsz：控制视觉大小。 设计师还可创建自定义轴，进一步扩展创作空间。

CSS操作方式：

1. 使用专用属性（优先选择）：如 font-weight、font-stretch、font-style 等。
2. 使用 font-variation-settings：用于操作自定义轴或复杂情况。
   • 缺点：该属性不支持级联继承，子元素会完全覆盖父元素的值。
   • 解决方案：使用 CSS变量 来管理需要继承的值。

主要OpenType特性

1. 替代字形

提供字符的替代样式。

• 样式替代 (salt)：全局启用替代样式（如更改 'a' 和 'g' 的样式）。
• 样式集 (ss01, ss02...)：针对特定子集字符进行替换（如为易混淆字符 'I' 和 'l' 设置明确区分样式）。
• 字符变体 (cv01, cv02...)：仅替换单个字符。

CSS操作方式：

• 直接使用 font-feature-settings：如 font-feature-settings: "salt" on。存在与级联相关的同样问题。
• 使用 font-variant-alternates（更新方法）：更易读，但需先通过 @font-feature-values 为字体定义映射值。同样存在级联覆盖问题。

2. 花体字

可用于为标题等添加装饰性笔画。

• 启用方式：font-feature-settings: "swsh" on 或通过 font-variant-alternates: swash()。

3. 数字字体

一个字体可包含多种数字样式组合。

• 衬线 vs. 等宽：等宽数字宽度一致，适用于表格数据；比例数字宽度各异，更适用于正文文本。
• 旧式 vs. 衬线：旧式数字高度较小且有升降部，与正文融合更好；衬线数字高度一致，视觉更突出。
• CSS控制：使用 font-variant-numeric 属性，如 tabular-nums、oldstyle-nums。

4. 小大写字母

用大写字母高度的小写字母样式替代小写字母，避免全大写在正文中过于醒目。

• CSS控制：
  • font-variant-caps: small-caps;：将小写字母转为小大写。
  • font-variant-caps: all-small-caps;：将所有字母转为小大写。
• 如果字体没有小大写字母，浏览器会尝试合成。可通过 font-synthesis: none; 禁用合成。

5. 上下文替代字形

根据字符周围的上下文自动替换字形，例如将 -> 替换为箭头，或调整 @ 在大小写字母间的位置。

• 此功能通常默认启用。
• 如需禁用，可使用 font-variant-ligatures: no-contextual;。

总结

文章指出以上仅触及OpenType功能的表面，还有许多其他特性（如装饰、序数、分数、连字等）可供探索。作者鼓励开发者充分利用高质量字体的这些丰富功能来提升排版质量。

该教程旨在探讨扩散模型这一生成工具背后的核心思想。近年来，以文本到图像和文本到视频生成任务为代表的生成式工具取得了惊人的发展，其基础原理正是扩散这一特定的采样机制，它克服了以往方法中一些被视为困难的缺陷。本教程的目标是阐述扩散模型的基本理念，主要面向对研究扩散模型或应用这些模型解决其他问题感兴趣的本科生和研究生。

该教程由Stanley Chan撰写，最新版本（v3）于2025年1月8日提交，最初版本于2024年3月26日提交。

彩票模拟器（2023）摘要

这是一个名为“PerThirtySix彩票模拟器”的交互式工具，旨在帮助用户直观地理解中奖概率，并模拟购买大量彩票的结果。

工具结构

该工具主要分为两个部分：

1. 设置：用于配置彩票规则。
2. 模拟：用于实际运行模拟并查看结果。

功能详解

1. 设置部分

在此部分，用户可以选择一个现有的美国彩票规则，或自定义彩票的规则。

• 规则示例：文中展示了一种彩票规则——从1到70中选择5个号码，并从1到25中选择1个特别号码（奖金球）。
• 关键数据：
  • 单张票价：$2。
  • 各种中奖组合的概率与赔付：详细列出了从匹配全部号码（头奖）到部分号码匹配的不同奖项的中奖概率（例如头奖概率约为3.026亿分之一）和对应的现金奖励。
  • 盈亏平衡概率：约为4.2%。
  • 自定义功能：用户可以选择“Custom”选项来设置自己想要的赔付金额。

2. 模拟部分

完成规则设置和号码选择后，用户可以启动模拟。

• 功能：允许用户选择号码，并以每秒数千张彩票的速度模拟购买过程。
• 结果展示：工具会可视化地展示投资回报情况。
• 注意：为简化模型，模拟做出了一些假设，例如假设只有一个大奖得主，并且忽略税收影响。

总结

PerThirtySix彩票模拟器是一个教育性工具，通过可配置的规则和快速的模拟运行，让用户体验彩票的数学概率和随机性，而不是一个用于购买彩票的实用工具。

David Chang论“漫长、艰难、愚蠢的方式”

核心理念

David Chang 认为，即使经营的是休闲餐厅，也应以高级餐饮的标准要求自己。做正确的事往往意味着选择“漫长、艰难、愚蠢的方式”，而非走捷径。

背后的深层动机

• 培养员工正直品格：在无人监督的厨房环境中，员工可能为节省时间而选择捷径（例如作弊节省30分钟，结果无人察觉）。Chang 强调通过坚持“愚蠢的长方式”，激励员工依靠个人正直做出正确选择。
• 自我提升：厨师行业缺乏高薪或股权等物质激励，Chang 将此视为通过个人品格教导员工实现自我完善的机会。

具体案例：Majordomo 餐厅的“整只煮鸡”

• 菜品设计：这道菜需在餐桌旁展示整只煮鸡，送回厨房切块后，再搭配米饭和酱汁上桌，最后用鸡骨熬汤。整个过程要求前厅与后厨紧密协作。
• 团队的改进建议：团队成员为提升效率，提出使用“展示鸡”进行表演，实际供应另一只已烹制的鸡。此举可加快出餐速度，且顾客无法察觉差异。
• Chang 的回应：他否决了该方案，并非因欺骗顾客，而是担心：
  1. 设定不良先例：团队可能养成“走捷径”的心态。
  2. 侵蚀餐厅文化：该菜品的价值在于前后厅的协调挑战，简化流程会失去其精髓。
  3. 影响员工心态：服务员需展示“道具鸡”，可能扭曲服务的本质。

理念的价值

• 品质与文化的坚持：Momofuku 品牌的成功部分源于这种对高标准的执着，即使过程低效。
• 联系到写作实践：作者类比自身写作博客的经历——在2024年仍选择耗时写作，看似“愚蠢”，但有助于提升品味、提炼见解并找到合适的表达场景。

总结

Chang 的理念核心在于：通过坚持“艰难但正确”的方式，培养团队的正直、维持文化活力，并真正实现自我提升与长期价值。 效率并非唯一目标，过程本身对塑造人与文化至关重要。

Felafax 框架总结

项目简介

Felafax 是一个基于 XLA 运行时的开源大语言模型（LLM）持续训练与微调框架。其核心目标是简化在非 NVIDIA 硬件（如 TPU、AWS Trainium、AMD 和 Intel GPU）上运行 AI 工作负载的流程。该框架具备易用、易配置和高扩展性特点，支持将训练规模从单台 8 核 TPU VM 无缝扩展至 6000 核的 TPU Pod，并可降低约 30% 的成本。用户还可通过 Google Colab 免费使用 TPU 资源微调 Llama 3.1 (1B, 3B) 模型。

支持的模型与实现

• LLaMa-3.1 JAX 实现（新增）：从 PyTorch 转换以提升性能，支持 1B 至 405B 规模的全精度和 LoRA 训练。依托 JAX 的 XLA 后端跨硬件高效运行，并通过多加速器分片处理大规模上下文与数据集。
• LLaMa-3/3.1 PyTorch XLA：支持 LoRA 和全精度训练。

Felafax CLI 核心功能与流程

Felafax 提供命令行工具（CLI）简化微调，包含 tune（任务管理）、model（模型交互）和 files（文件管理）三大命令组：

1. 安装与认证：通过 pipx 安装，使用官网获取的 Token 进行登录认证。
2. 配置参数：使用 tune init-config 生成 config.yml，可配置 HuggingFace 凭证、数据集管道（如 batch_size、max_seq_length）及训练超参数（如 learning_rate、lora_rank）。
3. 启动与监控：通过 tune start 指定模型和数据集启动任务。CLI 自动调度 TPU、执行训练并上传模型至 HuggingFace。支持使用 tune logs 实时查看日志。
4. 模型交互：训练后可通过 model list 查看模型，并使用 model chat 在 TPU 上启动终端与模型进行交互式对话。

AMD 405B 微调实践案例

团队在 8 张 AMD MI300x GPU 上使用 JAX 对 Llama 3.1 405B 进行了 LoRA 微调（bfloat16 精度）：

• 显存占用：模型权重约 800GB，LoRA 与优化器状态约 400GB，总 VRAM 使用率约 77%（1200GB）。
• 训练表现：受模型体积限制，批次大小设为 16，序列长度 64。训练速度约 35 tokens/秒，内存效率约 70%，在 8 张 GPU 上实现近线性扩展。
• 优化潜力：受限于硬件与显存，本次训练在 JAX eager 模式下运行，未启用 JIT 编译，未来具备显著的性能提升空间。

SuperHTML：首个报告语法错误的HTML语言服务器

核心概述

SuperHTML是首个能够报告HTML语法错误的语言服务器（LSP）。在此之前，包括VSCode、Neovim、Helix、Zed在内的许多编辑器默认使用的HTML语言服务器（来自微软）不会报告如未闭合标签等明显的语法错误。SuperHTML的出现填补了这一空白，它既是一个LSP服务器，也是一个独立的命令行工具。

主要特点

1. 智能的语法错误检测：

   • 基于官方HTML活规范构建，但在实际编辑场景中，若严格遵循规范会隐藏明显错误时，会主动偏离规范以提供更有用的诊断。例如，<li>item<li> 在规范中可能合法，但SuperHTML会将其标记为错误，因为它显然是一个未闭合标签的笔误。

2. “Zig fmt”风格的自动格式化：

   • 提供独特的自动格式化功能。用户可以通过调整元素起始标签前或属性与>之间的空格，来在水平排列和垂直排列之间快速切换整个元素或其属性的布局方式。

技术实现与发布

• 双模使用：既可作为LSP服务器集成到编辑器中，也可作为独立的CLI工具从命令行使用。
• 首个WASM WASI VSCode扩展：随着微软为VSCode添加WASI支持（经Zig核心团队成员Matthew Lugg推动），SuperHTML的最新VSCode扩展版本已能将服务器以WASM形式直接打包，用户无需再单独下载和配置CLI工具，实现了开箱即用。
• 生态系统：项目在VSCode的OpenVSX和官方市场发布，源代码和预构建二进制文件在GitHub上提供，并附有其他编辑器的配置指南。

当前状态与未来展望

• 功能范围：目前SuperHTML专注于提供准确的诊断（语法错误检查）和自动格式化功能。代码补全、错误修复建议等更高级的LSP功能尚未实现，但已列入未来开发计划，并欢迎社区贡献。
• 作者体验：作者在日常使用中（特别是配合其静态网站生成器的严格语法错误构建策略）认为SuperHTML提供的即时反馈体验极佳。
• 未来分享：作者计划就SuperHTML的开发经验发表更多内容，并将出席于2024年10月在波士顿举行的SquiggleConf会议并进行相关演讲。

Radicle 1.0概述

Radicle 1.0是一个基于点对点（P2P）网络的代码协作工具，旨在为开发者提供一个本地优先、去中心化的替代方案，以取代像GitHub这样的中心化平台。

核心特性与设计哲学

• 本地优先：所有代码仓库和数据都默认存储在开发者本地的机器上。这确保了用户对其数据拥有完全的控制权，并能在离线状态下继续工作。
• 点对点（P2P）网络：开发者之间直接进行数据同步和协作，无需通过中央服务器中转。这消除了单点故障的风险，并增强了系统的抗审查性和韧性。
• 去中心化身份与托管：用户身份通过加密密钥对管理，不依赖于任何中心化的身份提供商。代码仓库的托管也是分布式的，由参与节点共同维护。

技术实现

Radicle建立在成熟的Git协议之上，并对其进行了扩展以支持去中心化的工作流。它使用了一个名为“Heartwood”的协议栈，负责节点发现、数据同步和链接。开发者可以通过Radicle的命令行界面（CLI）或图形用户界面（GUI）客户端与网络交互，进行代码推送、拉取、议题跟踪和代码审查等操作。

与GitHub的主要区别

• 架构：GitHub是中心化服务，由单一公司控制；Radicle是去中心化P2P网络，由用户群体共同运行。
• 数据所有权：在GitHub上，代码和元数据存储在公司的服务器上；在Radicle中，数据首先存在于用户本地，然后选择性同步到网络中的其他节点。
• 基础设施依赖：使用GitHub依赖于该公司持续的运营和可用性；使用Radicle仅依赖于运行网络节点的对等方。

版本意义

Radicle 1.0的发布标志着该项目达到了一个重要的稳定性里程碑，其核心协议和功能已可供日常开发使用。它提供了一个经过验证的、真正分布式的代码协作替代方案，对于重视数据主权、隐私和系统抗故障能力的开发者社区具有重要意义。

OpenSSH 按键混淆旁路漏洞披露

概述：本文披露了一个影响 OpenSSH 9.4 之后版本的按键混淆旁路漏洞。OpenSSH 9.5 引入了按键时序混淆功能，旨在通过固定时间间隔发送数据包和添加伪装数据包来隐藏交互式会话中的击键时序，以抵御基于流量分析的时序攻击。然而，研究发现该混淆机制存在缺陷，使得真实的击键数据包仍能被识别，攻击者可借此推断用户的输入。

漏洞背景与现有问题

• OpenSSH 的防御措施：自9.5版起，OpenSSH 客户端在仅有少量数据交互时，会以大约20ms的固定间隔发送数据包，并在最后一次真实击键后发送伪装数据包（chaff packets）。
• 伪装机制：伪装数据包使用 SSH2_MSG_PING 和 SSH2_MSG_PONG 消息，其大小与真实击键数据包相同。
• 潜在风险：尽管 SSH 流量完全加密，但每个击键都会独立封装、加密和发送，导致可被观察到的时间戳元数据泄露，可能被用于时序分析攻击以推断用户输入。

漏洞发现与旁路原理

• 发现过程：在评估混淆有效性时，作者使用自定义工具 SSHniff 分析流量捕获文件，发现在大量伪装数据包（间隔约20ms）中，仍存在明显的、间隔更大的数据包"尖峰"。
• 根本原因：观察发现，当混淆被触发后，真实的击键数据包会与一个 SSH2_MSG_PING 数据包合并，形成一个大小约为普通数据包两倍的"胖数据包"。这些胖数据包与伪装数据包在大小上存在差异，因此可以被识别。
  • 初始击键：会话开始时的第一个击键按正常大小发送，随后触发伪装流。
  • 后续击键：在伪装流中，后续的真实击键数据包会与一个PING数据包合并，产生一个72字节的加密缓冲区（而非通常的36字节），导致服务器端会产生两次回显（一个PONG和一个按键回显）。
• 调试验证：使用 -DPACKET_DEBUG 标志编译 OpenSSH v9.7 进行观察，确认了数据包合并的详细过程。第一个击键后，第二个击键（如'h'）的数据包构建时，会先构造一个PING数据包，然后将击键数据包与之结合，最终发送一个72字节的加密数据包。
• 影响范围：此漏洞影响 OpenSSH 9.4 之后的版本，直至披露时的最新版本。

漏洞利用与验证

• 工具演示：作者修改了 SSHniff 工具，当检测到使用混淆的 SSH 版本（9.4之后）时，启用旁路检测逻辑。该工具能成功从包含混淆的会话捕获文件（PCAP）中提取出完整的击键序列。
• 时序分析攻击：作者进一步演示了如何利用泄露的元数据（击键时间间隔和数据包类型）来推断用户运行的命令。通过动态时间规整（DTW）等算法，将捕获的击键序列与已知命令的"节奏"模式进行比对，能够高概率地识别出用户输入的命令（例如 iptables -S, whoami, exit 等）。

信息披露时间线

• 作者于 2024年4月24日 向 OpenSSH 开发者通报了此漏洞。
• 收到了来自开发者 Damien Miller 的初始回应，但随后的进一步沟通未获回复。
• 因沟通中断，作者决定公开披露此漏洞。

结论：当前 OpenSSH 的按键混淆机制由于存在可被识别的"胖数据包"而未能完全达到其设计目标。攻击者仍可能通过分析这些异常数据包来提取击键信息，并进一步结合时序分析技术推断用户的命令输入，从而威胁会话的机密性。

本文作者为评估是否应迁移到现代Web框架，使用FastAPI、FastHTML、Next.js 和 SvelteKit 分别构建了同一个名为“Look at Your Data”的CRUD应用。该应用允许用户上传CSV文件初始化数据库、在浏览器中查看/编辑/删除表格数据，并下载修改后的CSV文件。通过实践对比，作者记录了各框架的开发体验、代码结构和独特优势。

主要框架对比与实现

1. FastAPI + Jinja + HTML/CSS/JavaScript（基准）

• 结构：main.py 处理路由，前端使用HTML、CSS和JavaScript。
• 特点：直接但前端代码分散，需手动管理客户端逻辑。

2. FastHTML（纯Python框架）

• 结构：主要逻辑集中在 main.py 和少量CSS中。
• 特点：通过 fasthtml 和 htmx 实现轻量级全栈开发，代码极度精简（如Jeremy Howard的50行示例）。学习时依赖新文档和编程配对支持。
• 开发体验：框架较新（当时发布仅一个月），LLM支持有限，但提供了针对LLM优化的文档。

3. Next.js（基于React）

• 结构：目录分层清晰（api/、pages/、components/、lib/）。
• 特点：代码量较大，但集成度高（如内置Tailwind CSS）。学习曲线平缓，教程详尽。
• 开发体验：生态成熟，LLM辅助工具支持良好。

4. SvelteKit

• 结构：包含组件、API函数、路由和页面文件。
• 特点：轻量高效，结合了编译时优化。作者简化了文件上传交互。
• 开发体验：教程完整，但当时LLM支持弱于Next.js。

5. FastAPI + Svelte（混合方案）

• 结构：FastAPI负责后端API，Svelte处理前端。
• 特点：前后端分离，需协调开发服务器运行。
• 挑战：开发时需同时启动两个服务器，生产环境可静态编译前端。

开发体验总结

• 代码量：FastHTML最精简，Next.js相对冗长。
• 学习资源：Next.js和SvelteKit资源丰富；FastHTML依赖新文档和社区支持。
• 框架特性：FastHTML主打纯Python开发；Next.js生态强大；SvelteKit轻量且性能优化。

关于编码助手的思考

作者指出，LLM编码助手（如Cursor）对主流框架（如React/Next.js）的辅助效果更佳，因为训练数据更多。新兴框架（如FastHTML、Svelte）支持较弱，但框架作者已开始提供LLM友好文档以改善此问题。

结论

作者通过实践加深了对各框架的理解，并期待进一步探索TypeScript。所有代码已公开，为开发者提供了实际参考。

使用Servo网络引擎构建浏览器

项目背景
Servo是一个专注于脚本处理和布局的网络引擎，可用于构建浏览器。Verso项目由Servo技术指导委员会成员@wusyong创建，旨在探索将Servo打造为强大浏览器所需的功能。本文总结了该项目的目标、成果及未来方向。

核心功能实现

多视图支持

• 目标：在单一窗口内实现多标签页（多视图）功能，并允许使用Servo自身的引擎来渲染浏览器用户界面（如提示窗口、上下文菜单等），以验证其实际可用性。
• 进展：基础的多视图支持已合并至Servo。Verso在此基础上定义了WebView类型，并通过创建两个视图进行演示：一个用于显示常规网页，另一个（称为“面板”）用于渲染浏览器UI。
• 挑战与方向：当前进程间通信（IPC）依赖于现有的频道消息机制。未来计划改进IPC，以实现对DOM元素更精细的控制（例如，在URL变化时同步更新导航栏），并探索定义自定义元素（如<webview>）以提升易用性。

多窗口支持

• 目标：支持创建多个独立的浏览器窗口。
• 实现方案：由于Servo的渲染后端WebRender（基于OpenGL）最初仅支持单个上下文，项目选择了单OpenGL上下文配合多个渲染表面的方案，旨在减少内存占用和线程数量。
• 技术挑战：
  • WebRender当前仅支持单个“文档”，需要不断更新显示列表以适配所有窗口，存在潜在的渲染错位风险。
  • 需要处理不同操作系统上OpenGL版本的配置差异。项目正在尝试使用Glutin库以更好地融入Rust生态系统并简化配置。

未来研究方向

基于已实现的多视图和多窗口基础，项目将关注以下领域：

1. 基准测试与指标：收集社区力量，跟踪Servo对按流行度排序的CSS属性和Web API的支持情况，并运行JetStream2、Speedometer3等基准测试，为新贡献者提供项目概览。
2. 脚本库维护：利用双周一次的Servo分诊会议，优先处理或修复未实现/存在缺陷的高频Web API。当前正在改进加载顺序并用Rust重新实现ReadableStream。
3. 多进程与沙盒：提升现有但默认未启用的多进程架构和沙盒功能，并将其集成到持续集成（CI）流程中。特别寻求协助，将沙盒支持扩展到Windows平台。

支持与致谢

本工作由NLNet和下一代互联网倡议赞助。

本文作者是一位18岁的年轻人，虽认可当前技术发展的优势，但对当今互联网现状深感失望，并深切怀念20世纪90至00年代的早期互联网。文章主要探讨了现代社交媒体的弊端以及早期互联网的独特魅力。

对现代社交媒体的批判

作者认为，社交媒体在追求盈利的过程中走向堕落，导致用户的数据、注意力和身份被全面商品化，互联网整体质量下降。

• 成瘾与表演性：Instagram等平台通过制造错失恐惧症（FOMO）和攀比心理使人上瘾，用户将其视为一场精心策划的表演游戏；TikTok等短视频平台则通过去个性化的内容疯狂争夺注意力，内容看完即忘，缺乏实质价值。
• 肤浅与失真：现代社交媒体无法反映用户的真实自我，仅展示其渴望塑造的公众形象和社交圈层资格。同时，Reddit和Quora等平台也将普通人的内容创作进行了商品化，取代了传统的论坛和新闻组。

对90-00年代互联网的怀念

作者向往博客和MySpace时代，认为那时的互联网更具个人色彩、创造力和真实性。

• 纯粹的创作动机：早期的网络写作多出于分享知识的纯粹好奇心，而非追求SEO优化或商业利润。内容与个人身份紧密相连，缺乏撒谎或操纵真相的利益动机。
• 自由的探索体验：怀念通过Web rings探索新网站的刺激感，那时的网络是未被科技巨头控制的“狂野西部”。
• 独特的视觉设计：怀念Geocities时代极具个性和视觉冲击力的极繁主义设计（如图案背景、明亮的图片和GIF），尽管作者自己的网站出于社会规范和简洁性考虑采用了极简设计。

小众复兴与现实困境

目前，Neocities等小众社区正在复兴这种复古的网络哲学，吸引了部分相对年轻的群体。然而在现实生活中，作者并未遇到选择这种方式的同龄人，大多数同龄人认为这类网站及其创作者“很奇怪”。

即将出版的书籍

2026年9月

• 《没有什么能将我们分离》：提醒我们，在需要行动与正直的时代，信仰要求我们做什么。

2026年10月

• 《伟大的文章之书》：一部16世纪再洗礼派论述，阐述教会关于成人洗礼、圣餐、物品共有、非暴力、参与政府、婚姻等方面的教导。
• 《论和解》：以色列人和巴勒斯坦人——以及其他人——能从南非人和卢旺达人那里学到关于结束冲突、冲突后疗愈与重建的知识。

2027年1月

• 《以剑》：尽管遭受激烈迫害，一个流亡的和平主义社群幸存了下来。

推荐书籍

• 《耶稣改变一切》：探讨如何将福音置于生活中心。
• 《继续生活》：以战后亚美尼亚乡村为背景的暖心短篇小说集，展现人们重拾希望与目标。
• 《火刑》：一部图像小说，改编自真实故事，包含腐败统治者、勇敢的抵抗者、惊险的阿尔卑斯山逃亡、难民爱情故事、不顾后果的回归、嫉妒的背叛者以及被活活烧死殉道等情节。
• 《门徒训练》：一位牧师就如何在当代生活压力下过基督般的生活提出睿智建议，观点有时发人深省，但始终鼓舞人心。
• 《可视自然诗篇》：漫画家朱利安·彼得斯对24首著名自然诗进行了视觉化诠释，为所有年龄的诗歌爱好者带来全新体验。
• 《盐与光》：阿诺德在19篇文章中呼吁我们出于爱，建立一个公正、和平的社会。
• 《安德烈·特罗克梅的回忆录》：安德烈·特罗克梅的个人回忆录，揭示了使他敢于反抗纳粹、拯救犹太人并成为国际和平缔造者的形成经历。
• 《呼召进入社群》：52篇关于在有意构建的基督徒社群中生活的读物，旨在激发小组讨论。

该网站名为 Taconomical，其主要功能是展示美国各地 Taco Bell 菜单商品的价格。所有显示的价格均基于从 Taco Bell 官方移动订餐系统获取的数据，并在获取时确保其准确性。页面底部注明了最后更新时间，并提供了通过 Twitter 联系作者的方式。

Iron Mountain警告：音乐行业硬盘存档面临数据丢失风险

Iron Mountain Media and Archive Services发布警告，指出音乐行业依赖全数字工作流创作的历史录音，其存储的硬盘驱动器存在严重可读性问题，许多早期数字会话资料正面临“死亡”风险。

背景与发现 该公司对20世纪90年代存档的数千块硬盘进行调查后发现，约20%已无法读取。这意味着1990年代初期的历史录音会话正在丢失。这引发了对数字存储资产长期保存的担忧。

工作流演变与存档挑战

• 数字工作流兴起：20世纪80年代末DAW（数字音频工作站）出现后，硬盘成为音乐制作的核心存储介质。与传统的模拟磁带不同，数字工作流从创作到混音全程数字化。
• 存档复杂化：2000年后，随着5.1环绕声和《吉他英雄》等新平台出现，行业需重新利用旧目录。但此时发现，不仅磁带会劣化或无法播放，硬盘也出现类似问题。
• 硬盘的“假安全”：许多版权所有者（唱片公司、艺术家、遗产管理机构）认为将硬盘存放在温控库房即可安全保存。但实际上，硬盘与磁带一样，易受多种因素影响，可能在数十年后变得难以读取。

主要风险与挑战

1. 技术过时：老旧硬盘格式（如Jaz、Zip）、已淘汰的接口、以及丢失的专用电源适配器等，都可能阻碍数据访问。
2. 软件兼容性：即使硬盘能启动，旧的Pro Tools会话文件可能需要更新软件和插件才能打开，延迟处理可能导致数据彻底无法使用。
3. 元数据缺失：存档硬盘外壳标注信息往往过于简略（如仅艺术家姓名缩写），难以快速识别内容类型（视频、采访或音乐）。缺乏有效的元数据使得查找特定音轨的最终版本变得困难。
4. 工作流分散：现代音乐制作常跨多个工作室甚至大洲进行，导致最终母带可能分散在不同地点。寻找整合所有内容的最终会话版本是一大挑战。
5. 预算与主动性：小型实体（独立厂牌、艺术家遗产）通常缺乏处理预算；大型唱片公司则往往只在商业再利用（如制作沉浸式混音）时才关注资产问题。缺乏主动措施，这些数字资产可能永久丢失。

行业行动呼吁 Iron Mountain基于其庞大的数据存储经验（服务对象包括财富500强及娱乐业巨头），向音乐行业发出行动呼吁。其技术团队可处理绝大多数存储介质，但前提是磁盘盘片未物理损坏。公司强调，这不是销售宣传，而是对潜在行业性损失的警示。

总结而言，文章指出，音乐行业在关注模拟磁带存档问题的同时，必须同等重视数字硬盘存档的脆弱性。随着时间推移，不采取主动的检查、迁移和规范化存档措施，许多重要的历史数字录音将面临不可逆转的丢失。

文章主要讨论了代码审查工具与流程，重点对比了GitHub的“diff soup”模式与更理想的“interdiff”（增量差异）审查模式。

代码审查工具背景

• Gerrit、GitHub、Phabricator等工具均可用于代码审查，其中Gerrit适用于Git仓库，支持补丁提交、评审、评论和合并。
• Linux内核使用邮件流程，而多数项目采用GitHub，因其简便且无启动成本。

理想补丁系列

• 一个理想的补丁系列应逻辑分离、可逐步阅读，体现代码演变的清晰步骤（如重构、新API、迁移旧API）。

GitHub的“diff soup”问题

• GitHub鼓励通过新增提交来回应评审意见，导致提交历史混乱（“diff soup”）。
• 缺点：
  • 提交间隐含关系不清晰，丧失“溯源性”。
  • 命名冲突使审查复杂化。
  • git blame和git bisect效果变差，难以定位问题根源。
  • 多次评审时问题加剧。
• 原因：GitHub的UX设计默认显示整个差异，难以查看增量变化，且强制推送后难以比较分支版本。

“interdiff”审查模式

• 作者发布新版本的提交系列（如v1、v2），而非在顶部添加修复提交。
• 审查者可用git range-diff比较版本间差异，实现增量审查。
• 优点：
  • 提交历史清晰，git blame和git bisect更可靠。
  • 审查者只需阅读增量改动，无需反复审阅大段代码。
  • 鼓励更小、更频繁的提交合并。

补充说明

• git rebase在公共分支上需谨慎使用，但在私有分支中可用于优化补丁系列。
• 该模式适合快速迭代的项目，减少长期分支依赖。
• Linux内核等项目仍用git rebase优化补丁，但避免强制推送公共分支。

总结：文章倡导采用“interdiff”审查模式，通过版本化提交和增量比较提升代码审查效率与历史清晰度，避免“diff soup”带来的问题。

Visual DB 是一个基于 Web 的数据库前端工具，旨在通过可视化拖拽方式快速构建数据库应用，无需编写代码。其主要功能和特点如下：

• 核心功能：

  • 表单构建：提供 AI 辅助的表单构建器，能根据描述自动生成表单布局，并支持手动调整、数据验证和条件逻辑。特别支持主从表单，便于处理一对多关系（如客户与订单）。
  • 电子表格：提供类似 Excel 的界面，但数据存储在中央关系数据库中，解决了版本控制、数据覆盖和一致性问题。
  • 报告生成：内置交互式报告工具，用户可自主进行数据分组、筛选、排序和应用查询参数，无需 IT 支持即可获得业务洞察。
  • 数据库管理：可直接在工具内可视化创建和管理数据库表结构、关系，并支持 CSV 导入导出。

• 技术特点与优势：

  • AI 集成：支持用自然语言查询生成 SQL，并能从简单描述自动生成数据库表结构。
  • 数据完整性：基于 ACID 原则，确保整个记录的原子更新、事务处理、输入验证和冲突合并，适用于对数据准确性要求高的关键业务场景。
  • 灵活部署与集成：支持自带数据库（兼容 MySQL、PostgreSQL、Oracle、SQL Server、SQLite 等主流数据库），并可与 Neon、Azure SQL、Amazon RDS 等云服务无缝集成。支持自托管以满足严格的数据安全和隐私要求（如 HIPAA）。
  • 竞争对比：与强调实时协作的 Airtable 等工具不同，Visual DB 优先保证数据一致性和完整性，更适合医疗、金融、政府、制造等关键领域。

• 定价与版本：

  • 免费版：不限用户和表单/报告数量，支持角色访问控制，记录限制为 1000 条（自托管无此限制）。
  • 商业版：每用户每月 5 美元起（最少 5 用户），提供优先支持，一次显示 10 万条记录，数据库记录总量无限制。提供 14 天免费试用。

• 用户评价：有用户反馈其为非技术用户提供了易用且功能完备的 Web 界面，无需开发即可快速部署。

Git Bash 作为首选 Windows Shell 的特性与用法

主要特点

• 大小写不敏感：与 Unix-like Shell 不同，Git Bash 通常对命令和路径大小写不敏感（但部分命令参数如 --help 仍需区分大小写）。
• 路径表示：
  • 使用正斜杠 / 作为路径分隔符。
  • C: 驱动器挂载为 /c/。
  • 可通过 pwd -W 查看 Windows 风格路径（如 C:/Users/USERNAME）。
• 启动命令（start）：可用 start 命令在默认应用中打开文件或目录（如 start . 打开当前目录）。

环境与脚本

• 环境变量：运行 printenv 查看可用变量，包括 PATH（搜索可执行文件的目录列表）。
• 脚本编写：
  • 推荐将脚本放在 ~/bin/（通常为 /c/users/USERNAME/bin/）目录，该目录默认在 PATH 中。
  • 示例脚本 gvim-winpath 展示如何使用 cygpath 转换 Windows 风格路径以启动应用。
• 执行权限：无需使用 chmod +x 设置脚本执行权限。

Unicode 支持

• 若遇到非 ASCII 字符问题，需确保环境设置包含 UTF-8。
• 可尝试通过 chcp.com 命令将代码页切换为 65001（支持 UTF-8 编码）。

其他实用操作

• 退出 Git Bash：点击终端窗口关闭按钮或输入 exit 命令（必须全小写）。
• 查看帮助：使用 cygpath --help | less 分页查看帮助（按空格翻页，q 退出）。
• 启动其他应用：若应用（如 VS Code）在 PATH 中，可直接调用（如 code . 打开当前目录）。

为什么需要注释：论“负面信息”的不可替代性

核心主旨

在推崇“自文档化代码”（通过长命名和测试用例替代注释）的趋势下，注释依然具有不可替代的独特价值。其核心作用在于表达负面信息（Negative information），即说明系统中“不存在什么”或“为什么不采用某种方案（Why nots）”。

自文档化代码的局限性

• 标识符的单维性：函数或变量名只能传达单一维度的信息，无法同时说明“代码的实际功能”与“设计时的权衡”。使用冗长的命名来解释权衡不仅会降低代码可读性，且在后续优化时需要全局修改，反而破坏了自文档化的初衷。
• 测试的局限性：测试用例依附于已编写的代码，只能验证代码“正在做什么（What it is doing）”，无法直接测试或挂钩代码“没有做什么（What it is not doing）”。

注释表达“负面信息”的价值

文章通过一个实际案例（为保持代码简单，放弃高效但复杂的一次遍历替换算法，采用低效但简单的16次遍历）说明了“Why not”注释的关键作用：

1. 预防未来瓶颈：当系统规模扩大导致当前的“慢代码”成为性能瓶颈时，注释可作为明确的路标，指引未来的优化方向。
2. 记录权衡与决策意识：向未来的维护者（或未来的自己）证明，开发者已经意识到当前代码的性能缺陷，评估过替代方案并主动决定不进行优化。这有效避免了后人花费大量时间重新调查并得出相同的结论。

延伸思考

“Why not”注释本质上可以被视为一种反事实（Counterfactuals） 表达。这引发了一个更深层的推测：人类沟通中的抽象概念（如类比、不确定性、伦理主张等）是否从根本上都无法通过代码实现自文档化。

本文介绍了作者作为独立系统工程师在 illumos 生态系统中专注于 Rust 编程的工作。主要内容包括：

作者背景

• 专注于 OpenIndiana 发行版开发、Rust 编程和虚拟化技术。

核心项目

1. Homelab 建设
   使用 Kubernetes、Cilium 等工具构建复杂的家庭实验室环境，用于展示和实验。

2. OpenIndiana 发行版贡献
   通过包维护、系统集成帮助用户迁移到现代 Unix 环境。

3. Rust 系统开发
   使用 Rust 开发系统工具和应用程序，注重实用性和趣味性。

4. 技术直播
   直播 Rust 开发、OpenIndiana 系统管理及基础设施问题解决过程。

技术栈

• Unix 系统、虚拟化、容器技术。
• 开发语言以 Rust 为主，用于构建底层工具。

整体体现了 Rust 在 illumos/OpenIndiana 生态中用于系统级开发的实践方向。

Yaak 现已开源

背景与初始立场

• 三个月前，开发者 Greg 曾发布《为何不开源》一文，解释 Yaak 不会开源，理由包括过去维护开源项目导致的倦怠。
• 当时 Yaak 用户普遍接受闭源状态，但开源社区（Reddit、HackerNews、Lobsters 等）强烈反对该文章的观点。

社区反馈与观念转变

• 开源社区指出，开源并不等同于完全开放贡献，公开代码本身就能带来关键益处：
  • 安全性审计：代码公开可供检查。
  • 功能透明：无隐藏或可疑操作。
  • 灵活性：用户可自行修改或分支。
  • 可持续性：即使开发者停止维护，项目仍可运行。
• 一条来自 Lobste.rs 的详细评论促使 Greg 重新审视自己的决定。

最终决策：开源但限制贡献

• 受 SQLite 和 Litestream 等项目启发，Greg 选择了 “开源但限制贡献” 的模式：
  • Yaak 现已基于 MIT 许可证 开源。
  • 仅接受错误修复（bug fixes）的贡献，不鼓励广泛的新功能开发。
• 此模式允许用户自行修复问题（如 Linux 桌面用户），同时减轻开发者的维护负担。

开源链接

• GitHub 仓库已公开，代码可供审查、分叉或修改。