Lore Harp McGovern：从郊区家庭建立微电脑帝国

核心故事

Lore Harp McGovern（原名Lore Lange-Hegermann）是1970年代硅谷最重要的个人计算机先驱之一。作为一名家庭主妇，她与朋友Carole Ely从加利福尼亚州郊区的家中起步，共同创立了Vector Graphic公司，将其发展成为一家重要的微型计算机制造商，并带领公司上市。她的故事挑战了当时科技行业的性别偏见。

背景与动机

• 早年经历：Lore在二战后的德国长大，深受祖父影响，坚信“你可以做任何你想做的事”。她于1964年作为交换生来到美国，后因签证问题与计算机研究员Bob Harp结婚并定居加州。
• 困境：婚后，她被迫扮演传统的家庭主妇角色，参加妇女团体活动，这让她感到孤立和挫败。她曾尝试攻读法律但因家庭责任被迫放弃，对未来的不确定感日益加剧。
• 创业契机：1975年，她与同样感到被困的家庭主妇Carole Ely相识。她们最初想创办旅行社，但因行业壁垒和性别限制而受阻。

创立Vector Graphic

1. 发现机会：丈夫Bob痴迷于Altair 8800微型计算机并自制了8K内存扩展板。Lore通过阅读家中的技术资料和与丈夫的交流，敏锐地认识到其中的商业潜力。
2. 公司成立：1976年8月23日，Vector Graphic正式成立。Lore Harp担任CEO，Carole Ely负责营销。她们计划将Bob设计的内存板作为套件在家中组装并销售。
3. 关键挑战与突破：为采购芯片，她们面临供应商的怀疑（因她们是女性且在家办公）。在遭遇AMD拒绝后，Fairchild Semiconductor的代表同意提供帮助，并同意了她们提出的30天付款账期（因为她们无力预付），这为公司提供了关键的启动支持。

成就与意义

• 商业成功：Vector Graphic从销售内存板起步，成长为一家制造完整微型计算机的公司，并成功上市。
• 打破偏见：Lore的故事是女性在男性主导的科技行业取得成功的典范。文中描写的她在公司上市路演时，被一位投资者误认为是服务员的轶事，生动体现了当时业界对女性领导者的偏见。
• 历史地位：她被认为是硅谷最后一位在世的原始创始人之一，其贡献曾被历史书写所忽视。她从郊区家庭出发，利用新兴的技术“开放架构”浪潮，抓住了个人计算机革命的机遇。

本文以C语言编写的“Hello World”程序为例，深入剖析了从源代码执行到文本最终显示在屏幕上所经历的一系列抽象层和复杂步骤。

程序编译与可执行文件

• 一个简单的C语言printf("Hello World!\n");程序，需要通过编译器编译成机器码才能直接在CPU上执行。
• 编译生成的文件是一个ELF可执行文件，专为x86-64指令集架构设计。
• 程序的入口点地址（例如0x1060）由ELF头指定，这是CPU开始执行指令的地方。

启动过程与库依赖

• 入口点处的代码（_start）并非用户所写，而是编译器/链接器自动添加的初始化代码，其主要任务之一是调用C标准库（如libc.so.6）的__libc_start_main函数。
• C标准库负责完成运行环境的初始化（如获取命令行参数、环境变量），然后调用用户编写的main函数。

用户代码的执行

• main函数被编译成机器指令后，其核心操作是调用puts函数来输出字符串。编译器进行了优化，将printf替换为更简单的puts。
• 待输出的字符串“Hello World!”以字节序列的形式存储在程序的只读数据段（.rodata），并以NULL（0x00）字节结尾。由于使用puts，编译器移除了源码中的换行符\n，因为puts会自动添加一个换行。

从库函数到系统调用

• puts函数通过一系列调用链（如fputs -> fwrite -> __fwritex），最终会触发一个系统调用。
• 系统调用是用户程序请求操作系统内核执行特权操作（如硬件访问）的唯一途径。对于输出文本，通常使用write或writev系统调用。
• C库中通过内联汇编代码（例如syscall指令）来执行系统调用，将参数放入指定的CPU寄存器，并触发从用户态到内核态的切换。

内核执行与输出显示

• 操作系统内核接管后，会处理write系统调用，将文本数据写入与程序标准输出关联的文件描述符（如/dev/pts/0，一个伪终端）。
• 最终，文本如何显示取决于运行环境。例如，在图形终端模拟器中，内核将数据存入缓冲区，终端程序读取并渲染文本；这个过程可能涉及图形合成器、GPU等多个组件的协作。

总结 一个看似简单的“Hello World”程序，其执行过程横跨了用户源代码、编译器、可执行文件格式、C运行时库、系统调用接口、操作系统内核以及最终的硬件输出等多个层次。现代计算系统的高度抽象和模块化使得这一过程既复杂又高效，也揭示了软件栈中各个部分紧密协作的图景。

Vala 编程语言概述

Vala 是一种面向对象的编程语言，主要用于 GNOME 生态系统。它提供高级抽象，同时与 GObject、GTK 等 GNOME 技术深度集成。以下是其核心特性和相关信息：

主要特性

• 高生产力：以面向对象方式编写代码，支持高级抽象，便于开发。
• 高性能：编译为原生二进制文件，运行速度快；可重用现有 C 代码或生成 C 代码。
• 开源：自由开源软件，拥有活跃的社区和丰富的工具链。

代码示例

以下是一个简单的 GTK4 应用示例，展示 Vala 语法和结构：

public class ExampleApp : Gtk.Application {
    public ExampleApp () {
        Object (application_id: "com.example.App");
    }
    public override void activate () {
        var win = new Gtk.ApplicationWindow (this);
        var btn = new Gtk.Button.with_label ("Hello World");
        btn.clicked.connect (win.close);
        win.child = btn;
        win.present ();
    }
    public static int main (string[] args) {
        var app = new ExampleApp ();
        return app.run (args);
    }
}

编译命令（需安装 gtk4 包）：valac --pkg gtk4 ExampleApp.vala

应用场景

• 图形界面应用：无缝集成 GTK、Libadwaita 和 Granite，适合开发轻量级应用并发布到 Flathub。
• 命令行程序：利用丰富的标准库和第三方库进行开发。
• 库开发：支持为其他语言提供绑定，并自动生成 API 文档；支持动态和静态链接。

项目示例

• Tuba：Fediverse 浏览客户端。
• Workbench：用于学习和原型设计 Vala 及其他 GNOME 技术的工具。
• Dino：注重隐私的现代桌面聊天客户端。
• Monitor：系统资源监视工具。
• TextSnatcher：通过 OCR 从图像复制文本。
• Timeshift：Linux 系统还原工具。
• Crown：跨平台游戏引擎。

社区与支持

• 论坛：GNOME Discourse 的 vala 标签。
• 即时通讯：Matrix 频道、Discord 服务器。
• 社交媒体：Mastodon、Twitter、Telegram、Reddit。
• 当前版本：稳定长期支持版为 Vala 0.56.17，开发版为 main 分支。

学习资源

• 教程：GNOME 和 elementary OS 官方入门指南。
• 文档：官方 Vala 文档。
• 博客：定期发布更新和技术文章，如 ValaBot AI 助手。
• 路线图：跟踪项目发展方向。

文章标题：GNOME 46 终端到底快了多少？

摘要： 本文通过实际硬件测量，评估了GNOME 46版本中VTE（虚拟终端库）的性能改进。VTE是GNOME终端模拟器（如Console、GNOME Terminal等）的核心库。作者使用自定义的硬件输入延迟测试器，从按键到屏幕像素变化，测量了端到端的输入延迟，排除了键盘固件的影响。

测试方法与环境：

• 测试工具： 自制硬件设备，含连接电脑USB的Teensy板与光传感器，实现约35,500次/秒的光强度读数。
• 测试平台： Fedora 40 Silverblue Beta，AMD Ryzen 7 6800H CPU + Radeon RX 6700M GPU，搭配2560×1440、144Hz显示器，运行原生Mutter 46.0合成器。
• 测试终端：
  • Alacritty（非VTE，作为性能基线）
  • Console（GTK 4，GNOME默认终端）
  • VTE测试应用（GTK 4）
  • GNOME Terminal（GTK 3）
• 测试场景：
  1. 简单场景： 运行 cat > /dev/null，测量按空格键后光标移动的延迟。
  2. 复杂场景： 在Neovim中滚动含有下划线、状态栏等复杂渲染的文本，测量Ctrl+D/U操作的延迟。
• 比较方法： 通过toolbx容器对比GNOME 45（Fedora 39）与GNOME 46（Fedora 40）下的表现。

主要测试结果：

1. 输入延迟大幅降低：
   • GNOME 46中所有基于VTE的终端，输入延迟从“较差”水平显著提升，几乎与作为基线的Alacritty持平。
   • 主要改进源于VTE将重绘机制从固定的40Hz定时器改为与显示器刷新同步的逐帧绘制。
   • 即使在复杂的Neovim场景下，VTE终端的延迟增加也与Alacritty类似，差距可忽略不计。
2. 解析性能（vtebench）提升：
   • 使用Alacritty的vtebench套件测试PTY读取和解析性能，GNOME 46的VTE也有明显改进，但仍不及在独立线程中处理解析的Alacritty。
   • VTE在应对dense_cells和unicode等重度压力测试时仍存在困难，结果离散度大。

结论： GNOME 46的VTE经历了一轮重大的性能优化，尤其在输入延迟方面提升显著，已可媲美最快终端的体验。这一改进使得基于VTE的终端在日常使用中能提供更快速、流畅的响应。如果用户曾因VTE终端的迟滞感而避免使用，现在可以重新尝试（需确保使用VTE 0.76或更高版本）。作者对VTE维护者和贡献者的工作表示了感谢与祝贺。

约翰·冯·诺依曼是20世纪最杰出的通才型数学家之一，在算子代数、集合论、量子力学基础、博弈论及经济学等多个领域作出了奠基性贡献。1943年，他以顾问身份参与曼哈顿计划，在洛斯阿拉莫斯实验室的短期工作中发挥了关键作用，其影响深远且具有双重性。

背景与才能 冯·诺依曼出身于布达佩斯的富裕犹太家庭，自幼展现出惊人天赋。他精通多国语言，拥有超强记忆力，在纯数学与应用数学领域均造诣极深。1930年代移居美国后，他加入普林斯顿高等研究院，并与经济学家奥斯卡·摩根斯坦合著《博弈论与经济行为》，奠定了博弈论基础。他的思维极为敏捷，善于快速抓住问题本质并连接不同领域的知识。

对内爆原子弹的关键贡献 早期曼哈顿计划主要关注“枪式”铀弹设计。1943年，物理学家赛斯·内德迈耶提出了“内爆法”构想——通过向心压缩裂变材料来实现链式反应，但该方案因技术复杂而备受质疑。冯·诺依曼的介入扭转了局面。

1. 确认内爆可行性：他运用自己在冲击波与流体动力学方面的知识，论证了通过环绕裂变材料布设球形“聚能装药”（基于门罗效应），可以产生精确的向心冲击波，将铀或钚压缩至超临界状态。
2. 提出关键改进：他建议提高炸药与裂变材料的质量比，以加速内爆过程，防止提前引爆，并减少珍贵裂变材料的用量。
3. 设计爆炸透镜：为实现对称冲击波，他与詹姆斯·塔克合作，利用不同燃速的炸药层构成“爆炸透镜”，将发散冲击波转化为汇聚波，解决了均匀压缩的核心难题。
4. 简化武器效应计算：他提出了估算核爆压力与最佳爆炸高度的简化模型，为“小男孩”铀弹（轰炸广岛）提供了理论支持。

他的权威性与精准计算，使内爆法从受争议的方案变为优先项目，并最终解决了钚弹因含钚-240而无法采用枪式设计的致命难题。1945年7月“三位一体”核试验的成功，验证了内爆设计的有效性。

对计算机发展的催化作用 内爆设计涉及极其复杂的非线性偏微分方程计算，远超人力所能及。在洛斯阿拉莫斯，冯·诺依曼首次深度接触IBM制表机等早期计算设备，用于求解冲击波方程。这段经历让他深刻认识到通用计算机对科学与工程的革命性潜力。

战争结束前，他已开始关注计算机的设计问题。洛斯阿拉莫斯的计算需求，促使他后续投身于存储程序计算机（冯·诺依曼架构）的理论构建与实际研制，为现代计算机科学奠定了基础。

复杂遗产 冯·诺依曼的工作直接推动了原子弹与氢弹的发展，并在冷战时期持续为美国核武库建设提供咨询，其立场颇具争议。然而，他在洛斯阿拉莫斯的经历意外催生了对计算机的投入，其影响远超武器领域。他的故事凸显了一个规律：一项重大技术的最深远影响，往往是催生另一项意想不到的新技术。尽管核武器的阴影至今仍在，但冯·诺依曼所倡导的计算革命，已成为塑造现代社会的根本力量。

提供的文章内容为重定向消息“Redirecting to ...”，表示内容已自动重定向至最新版本，因此当前未提供关于主题的具体细节。标题“Blocky – a DNS proxy and ad-blocker for the local network”表明文章主题是关于Blocky，一个用于本地网络的DNS代理和广告拦截工具，但基于现有内容无法获取更多详细信息。

Open Parse: 面向LLM的增强型文档解析库

Open Parse 是一个旨在改进大语言模型（LLM）输入质量的文档解析与分块库。它通过可视化分析文档布局，超越传统的文本分割方法，能更智能地处理复杂文档。

解决的问题与对比优势

传统文档处理方法存在局限：

• 文本分割：仅将文件转为原始文本并切片，会丢失原始PDF的映射能力，忽略标题、章节、列表等语义结构，且不支持表格、图像或Markdown。
• ML布局解析器（如layout-parser）：虽能识别文本块、图像、表格等元素，但不擅长对相关内容进行有效分组，通常需要额外模型来处理图像中的Markdown、解析表格、聚类节点等，且计算开销大。
• 商业解决方案：成本高（约10美元/1000页），且需要与供应商共享数据。

Open Parse 主要特点

• 视觉驱动：通过视觉分析文档，为LLM提供优于朴素文本分割的输入。
• Markdown支持：解析标题、粗体和斜体等基础Markdown格式。
• 高精度表格支持：将表格提取为简洁的Markdown格式，精度超越传统工具。
• 可扩展性：易于实现自定义后处理步骤。
• 易用性：设计直观，编辑器支持良好，开发调试效率高。

安装与依赖

• 要求：Python 3.8+
• 核心依赖：pdfminer.six（开源PDF解析）。
• 可选ML表格检测：安装 pip install "openparse[ml]" 后下载模型权重。底层使用table-transformers进行表格检测，目前性能可能受限。
• OCR支持：需额外安装Tesseract-OCR并配置其语言数据路径（环境变量 TESSDATA_PREFIX）。

使用示例

基本解析：

import openparse
parser = openparse.DocumentParser()
parsed_doc = parser.parse("document.pdf")
for node in parsed_doc.nodes:
    print(node)

语义处理（基于嵌入聚类）：

from openparse import processing, DocumentParser
semantic_pipeline = processing.SemanticIngestionPipeline(
    openai_api_key="YOUR_KEY",
    model="text-embedding-3-large",
    min_tokens=64,
    max_tokens=1024,
)
parser = DocumentParser(processing_pipeline=semantic_pipeline)
parsed_content = parser.parse("document.pdf")

结果序列化：

parsed_content.dict()  # 转为字典
parsed_content.json()  # 转为JSON

资源与文档

• 示例代码：提供基本解析和语义处理的Jupyter Notebook。
• Cookbooks：包含更多应用场景。
• 文档：详细文档可在项目网站查阅。

Open Parse 通过结合视觉分析、语义理解和现代ML技术，为构建高质量RAG系统提供了更强大、易用的文档预处理工具。

Groq公司CEO Jonathan Ross宣布，公司不再销售硬件，已转型为AI云服务提供商。这一转变源于初创企业销售芯片的挑战：最小采购量要求高、成本高昂，且客户不愿承担购买大量硬件的风险。Groq的目标客户现在是AI开发者，其GroqCloud实时大语言模型推理云服务已注册70,000名开发者，运行着19,000个新应用。

对于需要大规模芯片的客户，Groq建议合作部署数据中心，而非直接销售硬件。例如，公司与沙特阿美公司（Aramco）签署了涉及大规模LPU部署的协议。Ross表示，仅愿意向美国政府及其盟友销售硬件，其他客户通过商业云合作。这种模式虽不常见，但类似AI芯片初创公司Cerebras与G42的合作。

Groq的供应链优势在于其芯片不使用高带宽内存（HBM），而HBM供应商如SK海力士和美光的产能已售罄。这使得Groq能够实现其他竞争对手难以达到的扩展水平。公司计划今年自行部署42,000个LPU芯片用于GroqCloud，与Aramco等合作伙伴的类似数量芯片交易正在敲定。Groq的年度产能为220,000个LPU，明年计划达到150万个（包括今年的220,000个），但大部分未分配产能正快速被占用。

上个月，Groq收购了AI商业洞察公司Definitive Intelligence，其CEO Sunny Madra现领导GroqCloud团队，专注于扩展容量、提高效率、建立合作伙伴关系和完善开发者平台。通过成为自产芯片的云服务提供商，Groq正朝着类似超级大规模云提供商的模式发展。Ross声称，到明年年底，其部署的LPU计算能力将相当于所有超级大规模云提供商的总和。

在性能方面，基准测试显示GroqCloud在Mixtral 8x7B上达到467 tokens/秒，而其他基于GPU的服务不超过200 tokens/秒。演示中7B模型可达750 tokens/秒。公司正在通过推测解码等功能进一步提升速度。尽管第一代LPU芯片已有近五年历史，Groq对它仍有信心，并在Nvidia发布Blackwell GPU架构后回应“Still faster”。

Groq正在开发下一代LPU，计划今年流片，从14nm工艺跳至4nm，预计性能大幅提升。新芯片针对生成式AI优化，但保持对多种AI类型的支持，包括CNNs和LSTMs。

PumpkinOS：PalmOS的现代化重新实现

概述

PumpkinOS是一个在现代架构（x86、ARM等）上运行的PalmOS重新实现。它不是传统的PalmOS模拟器（无需PalmOS ROM），但能够运行m68K架构的PalmOS应用程序。项目采用GPL v3许可证。

核心特性

• 启动器：PumpkinOS启动时运行的主应用，用于启动其他应用。
• 偏好设置：用于配置系统的选项（开发中）。
• 命令行工具：实验性命令Shell。
• 内置PIM应用：包含AddressBook、MemoPad、ToDoList和DateBook四个个人信息管理应用，源码源自PalmOS SDK并适配至PumpkinOS。
• 兼容性：
  • AddressBook和MemoPad记录与PalmOS兼容。
  • ToDoList和DateBook记录因字长和字节序差异不兼容。
• 当前状态：应用仅经过基础测试，存在未完善功能与瑕疵，旨在展示未来潜力。

系统构建

环境要求

• Windows 64位：使用MSYS2，安装gcc、binutils、make、git。
• Linux 64位：安装上述工具及libsdl2-dev。
• Windows 10/11：可通过WSL2按Linux方式构建。
• 实验性支持：可使用Emscripten构建Web版本。

构建步骤

1. 克隆仓库：git clone https://github.com/migueletto/PumpkinOS.git
2. 进入目录并运行make：
   • 成功后将生成pumpkin可执行文件、bin目录动态库及vfs/app_install目录的PRC文件。
   • Emscripten构建：使用make OSNAME=Emscripten生成pumpkin.zip，部署至Web服务器后可通过浏览器访问。

运行与调试

• 启动方式：
  • Windows：运行pumpkin.bat。
  • Linux/WSL2：运行pumpkin.sh。
• 应用安装：
  • 自动解压vfs/app_install中的PRC文件至vfs/app_storage。
  • 支持拖放PRC文件至窗口或手动复制至vfs/app_install后重启。
• 日志与调试：
  • 运行后生成pumpkin.log，错误信息以"E"标记。
  • 支持通过GDB调试，需修改启动脚本命令。

注意事项

• 项目处于实验阶段，可能存在功能不稳定问题。
• Emscripten版本在非HTTPS环境或浏览器隐私模式下可能无法加载。
• 遇到问题可通过日志文件排查或联系开发者。

经典Win32 ListView 控件支持增量搜索功能，允许用户通过键入项目名称的一部分来快速查找项目。该功能的设计考虑了两种常见的用户期望搜索模式。

第一种模式是重复字母模式：用户按下项目首字母，系统选中以该字母开头的第一个项目；如果这不是所需项目，再次按下同一字母，系统选中下一个以该字母开头的项目，如此重复直到找到目标。第二种模式是前缀模式：用户键入项目首字母后，继续键入更多字母，系统查找以这些字母为前缀的第一个项目。

Win32 ListView 控件通过智能切换来同时支持这两种模式。如果用户连续键入相同的字母，控件会进入重复字母模式，每次按下相同字母都选中下一个匹配项。如果用户键入了不同的字母，控件则切换到前缀模式，查找以键入字母序列为前缀的第一个项目。

文章通过一个具体示例说明了这一机制。假设 ListView 包含以下项目：Cougar、Leopard、Lemur、Lion、Llama 和 Tiger。当用户键入字母 L 时，系统选中 Leopard（第一个以 L 开头的项目）。再次键入 L 时，由于是重复字母，控件进入重复字母模式，选中下一个 L 开头的项目 Lemur。接着用户键入字母 A，由于这不是重复字母，控件切换到前缀模式，查找以 "LLA" 为前缀的第一个项目，即 Llama。

总之，经典 Win32 ListView 通过检测输入模式（重复字母或不同字母），动态调整搜索行为，从而满足用户的两种常见搜索习惯，提供了灵活且高效的增量搜索体验。

SUSE安全团队在审查KDE6版本的组件时，发现其广泛使用的D-Bus和Polkit集成存在多个安全问题。文章概述了D-Bus（进程间通信）和Polkit（授权框架）的安全关联性，并重点分析了KDE组件中的具体风险。

主要发现包括：

1. KAuth框架缺陷：

   • D-Bus配置错误：KAuth为KDE6生成的D-Bus配置文件片段过于开放，允许所有用户与所有系统总线服务通信，影响了其他如ratbagd的服务安全。
   • 数据序列化风险：框架传递序列化的QVariantMap数据，在反序列化时可能引发非预期的副作用。

2. 高危服务设计问题：

   • fontinst服务：该服务设计糟糕，通过单一D-Bus方法和单一Polkit操作暴露了近乎通用的文件系统操作（如复制、移动、删除任意文件），权限提升风险极高。
   • sddm-kcm6服务：
     • 方法接受来自非特权客户端的文件路径，以root身份操作用户控制的路径存在危险。
     • 方法直接操作sddm服务用户的主目录和配置文件，可能被该用户利用导致拒绝服务或目录遍历。

3. Polkit使用不当：

   • 开发者常误认为auth_admin（要求管理员密码）的默认设置是固定的，未考虑管理员可能调整设置（如放宽或加强）带来的安全后果。文章强调Polkit是可配置的，且认证信息应清晰明确。

4. 其他组件问题：

   • KWalletManager：其“savehelper”服务是一个执行空操作的root辅助程序，仅为提供一个auth_self认证提示以实现“伪安全”，这被认为是误导性的且不必要的。
   • DrKonqi：其新的核心转储提取服务正确使用了文件描述符来增强安全性，但在目录权限处理上仍有缺陷，可能被非特权用户利用在任意目录中写入文件。

结论与现状： 审查在KDE6发布前进行，部分问题（如错误的D-Bus配置）已及时修复。但一些复杂问题（如fontinst、sddm-kcm6的架构缺陷）因修复难度大而未能在KDE6中解决。由于这些问题在默认的严格Polkit策略下难以利用，未分配CVE。文章最终强调了理解D-Bus/Polkit复杂性、谨慎设计特权服务以及在KAuth框架中传递文件描述符的重要性。

兼容性说明： 标题兼容性状态由社区志愿者报告，基于报告者在报告时于其计算机上使用 xemu 当前版本的体验。随着项目发展，报告可能需要更新。欢迎通过提交更新的兼容性报告来帮助改进项目。可加入 Discord 服务器了解如何贡献。

免责声明： 本项目是一项独立的开源模拟工作，未经微软公司认可、直接关联、维护、授权或赞助。所有产品和公司名称均为其原始所有者的注册商标。任何商品名称或商标的使用仅用于标识和参考目的，并不意味着与商标持有者的产品品牌有任何关联。

版权声明： 版权所有 © 2020 - xemu 项目。

Reverst: 基于 QUIC 和 HTTP/3 的 Go 反向隧道服务器与客户端库

核心概述

Reverst 是一个基于 Go 语言开发的反向隧道服务器及客户端库，构建在 QUIC 和 HTTP/3 协议之上。其主要目的是允许从受限网络（如 NAT 网关后）向公网暴露内部服务。

主要特点

• Go 驱动：使用 quic-go 库编写。
• 兼容性强：客户端库基于 Go 标准库 net/http 抽象构建。
• 支持负载均衡：可在同一隧道后运行多个服务实例。
• 高性能：基于 QUIC 和 HTTP/3 协议。

使用场景

适用于在公网部署隧道服务器（reverstd），内部客户端服务器通过隧道向外注册服务。客户端被组织成 隧道组，每个隧道组是一个负载均衡的服务集合，通过隧道的 HTTP 接口对外暴露。

项目结构

• reverstd：隧道服务器（部署于公网）。
• reverst：隧道命令行客户端。
• Go 客户端包：供需要通过隧道暴露服务的 Go 代码依赖。
  • 安装：go get go.flipt.io/reverst/client
• 示例：提供使用 reverstd 和 reverst 的具体示例。

构建与测试

• 构建：可同时编译 reverstd 和 reverst。
• 测试：使用 Dagger 运行集成测试套件，包括单元测试和集成测试。

配置与使用

服务器命令行参数

通过 reverstd 命令配置，支持命令行标志和环境变量（环境变量前缀为 REVERST_）。主要参数包括：

• --tunnel-address：接受 QUIC 隧道连接的地址。
• --http-address：提供 HTTP 请求服务的地址。
• --server-name、--private-key-path、--certificate-path：TLS 相关配置。
• --tunnel-groups：指定隧道组配置来源。
• --watch-groups：监视配置源更新。

隧道组配置

配置来源于文件（file://）或 Kubernetes ConfigMap（k8s://），支持实时监视更新。配置文件为 YAML 格式，包含顶层键 groups，每个组需定义：

• hosts：用于路由 HTTP 请求的主机名数组。
• authentication：认证策略，支持：
  • basic：用户名/密码认证。
  • bearer：静态令牌认证。
  • external：委托外部服务进行认证。
  • 如未配置认证策略，则禁用认证（不推荐）。

这篇文章讲述了作者在2019年偶然发现ZeroMQ库中一个严重的栈溢出安全漏洞（CVE-2019-13132，CVSS 9.8分）的经历，并结合近期发生的XZ后门事件，对开源社区的安全、维护和生态进行了深入反思。

漏洞发现过程 作者当时在Niantic负责为基于ZeroMQ的AR服务设计认证机制。为复用现有工具，他研究了CurveZMQ协议，并好奇其元数据字段的大小限制。通过阅读ZeroMQ源码，他发现传入数据被放入固定大小的栈缓冲区，且缺乏边界检查，存在栈溢出风险。编写测试代码后，确认了漏洞的存在，随后报告给ZeroMQ维护者，社区快速响应并发布了补丁。

对XZ后门事件的反思与见解 作者将此次经历与攻击者潜伏两年植入XZ后门的事件联系起来，并提出了几点思考：

1. 开源维护者的界限：开源工作多为自愿，维护者有权拒绝超出能力或项目范围的需求。过度索取会加重负担。
2. 功能取舍：添加新功能并非总是必要，应审慎评估需求，并考虑更简单的替代方案。
3. 保持好奇与代码阅读：主动阅读源码是发现隐藏问题和学习的关键，尤其在AI生成代码普及的今天，阅读和理解代码的能力更显重要。
4. 安全工具的作用：XZ后门攻击者试图规避Valgrind、oss-fuzz和Landlock等安全工具，这表明持续的内存检测、模糊测试和沙箱技术可以作为防御障碍。
5. 经济视角：培养一个长期潜伏的“内鬼”成本可能低于直接购买高价值零日漏洞，这意味着未来可能面临更多类似供应链攻击。

总结 作者认为开源社区因其协作精神而强大，但高价值目标必然吸引恶意行为者。社区需要集体反思，从技术（如加强代码审查、安全工具使用）和流程（如维护者支持、合理期望）两方面提升安全性，使恶意攻击更加困难。作者呼吁社区共同探讨如何防止类似事件再次发生。

复兴800年日本古茶园：宇治七名园“朝日园”的重现之路

历史背景与发现

• 宇治茶的历史：宇治（位于京都）的茶历史可追溯至镰仓时代（1185-1333），传说由僧人荣西从中国带回茶种。室町时代（1336-1573），将军足利义满下令在宇治开辟七个茶园，称为“宇治七名园”（Shichi Meien），包括森、岩上、马�的、川下、奥野山、朝日和琵琶。如今仅奥野山茶园仍在活跃运营。
• 古茶树的偶然发现：几年前，陶艺家松林俊行在兴正寺附近散步时，发现了一株古老茶树。他咨询了自然茶与中国茶研究者堀口一子后，与寺庙协商并获得许可，尝试用其叶子制茶。寺庙住持矶崎円大表示，此前无人意识到寺内仍有古茶树。

兴正寺与朝日园的潜在联系

• 寺庙历史：兴正寺由道元禅师于1233年创建，后一度衰落。1645年由永井直政重建于宇治山坡，该山坡后被称为“朝日山”。研究者推测，兴正寺及其周边区域可能正是已消失的七名园之一“朝日园”的原址。
• 证据支持：寺庙内一幅19世纪画家森一峰的挂图显示，当时寺庙门前和东侧山坡均分布着茶田。DNA分析（由京都府农林水产技术中心主导）证实，寺内茶树很可能是本地原生品种（而非常见的改良品种），且所有样本均属京都本地品种群。这暗示它们可能与荣西传入的古茶存在渊源。

复兴工作与品种价值

• 培育与种植：2021年，团队在专家指导下从古茶树进行扦插育苗；2022年尝试播种种子培育实生苗。计划将目前培育的1000株幼苗移植至寺庙后山。
• 原生品种的意义：商业种植多采用易管理的扦插克隆品种，而原生品种难以标准化管理，但实生苗培育的植株被认为更健壮、寿命更长。原生品种的多样性被视为“神的拼配”，其独特风味与单一栽培的均质化茶形成对比。
• 制茶与风味：松林俊行用古茶叶制作了乌龙茶、红茶和焙茶，形容其风味“骨架坚实且带甘甜”。参与者品尝后认为其口感“温和”，且带有松针熏烤的烟香。

复兴愿景与文化价值

• 禅与茶的联结：住持矶崎希望通过种茶、制茶、品茶，让公众更贴近禅宗思想（如“不立文字”“枯淡寂寥”），并重新连接人与自然。
• 产业与创新：茶业同仁�的村祐介（通圆茶屋第24代）与山本甚次郎（山本商店第6代）参与讨论。他们认为复兴朝日园能丰富宇茶的文化叙事，并探索原生品种的“田园混合”潜力及传统栽培法（如使用葭帘遮阴的“本�的栽培”）。
• 未来展望：团队期待通过古茶树的故事，推动公众对原生品种的兴趣，避免茶文化仅停留在抹茶甜点的层面，而是深入其历史与禅意内涵。如能进一步发现朝日园位置的文献记载，或将正式确认此地为历史茶园遗址。

Cloudflare数据中心再次大规模断电：Code Orange应对成效显著

事件概览

2024年3月26日，Cloudflare位于美国俄勒冈州波特兰的PDX01数据中心在五个月内再次发生全面断电。此次事件成为检验其此前启动的“Code Orange”危机应对计划的关键实战测试。

背景与Code Orange启动

• 首次断电（2023年11月2日）：同个PDX01数据中心因电网维护引发连锁故障导致长时间断电，暴露出服务恢复机制不足。
• 启动Code Orange：该事件后，Cloudflare宣布进入“Code Orange”状态（借鉴谷歌的危机响应机制），授权技术运营高级副总裁统一调动工程资源，全力解决高可用性问题。
• 五个月内的改进：团队将重心转向确保即使再次发生重大故障，核心服务也能持续运行。

第二次断电事件经过

• 发生时间：2024年3月26日14:58 UTC，PDX01因设施方（Flexential）四个开关柜同时故障导致全部电力丧失（主备电源均中断）。
• 根本原因：Flexential的断路器协调设置错误（整定值过低），导致级联跳闸。
• 恢复过程：Flexential工程师发现并修正设置后，Cloudflare团队在约10小时内完成了大规模数据中心的冷启动（此前首次断电耗时约72小时）。

改进效果对比

首次断电（2023年11月）：

• 多项核心服务（API、Dashboard、零信任、SSL等）停机超过6小时，部分功能持续多日降级。
• 分析（Analytics）和日志推送（Logpush）等服务长时间不可用。

第二次断电（2024年3月）：

• 控制面快速恢复：API和Dashboard在断电后7分钟内自动恢复（无需人工干预）。
• 服务影响最小化：绝大多数核心服务（零信任、Magic Transit、Workers KV等）在故障转移期间无感知或快速恢复。
• 数据面未受影响：全球300多个城市的流量处理网络正常运行。
• 仍存在的问题：分析平台因架构依赖仍受影响，需后续优化。

关键技术改进措施

1. 数据库高可用改造：20多个数据库集群、100多个数据库实现自动故障转移。
2. 日志推送（Logpush）冗余：在波特兰实现高可用，并于阿姆斯特丹建立活跃备份。
3. 服务架构优化：
   • Stream：通过阿姆斯特丹设施无缝接管视频转码任务。
   • 零信任：将大部分功能移至全球边缘网络，避免单点依赖。
4. 持续测试：通过定期切断测试（如2024年2月）验证系统韧性。

后续计划

1. 完成分析平台高可用改造：消除对单个数据中心的依赖。
2. 完善手动干预流程：确保所有服务均能自动恢复。
3. 加强供应商协作：与Flexential深入审查运营流程，并将审查机制扩展到所有关键设施。

总结

Cloudflare通过Code Orange驱动的大规模韧性工程，在重复故障中显著提升了服务稳定性，实现了从“长时间中断”到“分钟级自动恢复”的跨越，验证了分布式高可用架构的有效性，同时暴露了仍需优化的环节（如分析平台）。

文章摘要

2022年，一支研究团队在南极威德尔海海床约3000米深处，成功发现了欧内斯特·沙克尔顿探险船“坚忍号”的残骸，解决了长达一个世纪的海事谜团。此次发现由“坚忍22”探险队完成，并由福克兰群岛海洋遗产信托基金宣布。

发现细节 研究团队乘坐南非破冰研究船“S.A. Agulhas II”号，在依据船长弗兰克·沃斯利的笔记所标注的150平方英里区域内，使用两艘潜水器进行搜索。最终，残骸在沃斯利预测位置以南约6.4公里处被发现。南极冰冷的海水使得这艘长44米的三桅木船保存状态异常完好，船名大写字母仍清晰可见，且船体直立、完整。团队强调，沉船作为历史遗迹受到保护，不会被打扰。

历史背景 “坚忍号”原属帝国南极横穿探险队，旨在穿越未被测绘的南极东部地形。1914年，沙克尔顿与27名船员从南乔治亚岛出发，无视捕鲸人关于威德尔海冰况恶劣的警告。1915年，船只被浮冰围困长达十个月，随后冰层挤压船体，导致其于1915年11月21日沉没。沙克尔顿随后领导了一次传奇的求生之旅：乘救生艇到达象岛，再与五名船员划小船航行约1287公里至南乔治亚岛求援，最终所有船员于1917年获救。

技术应用与团队反应 现代技术与沃斯利的历史记录相结合，使此次搜索成为可能。探险期间，潜水器拍摄的高清图像和视频显示了船体细节，并记录了周边深海生物，如巨型海葵和海鞘。研究人员对发现感到震惊与激动，称其为所见“最精美的木船残骸”。此次发现被认为极地研究史上的重要成就，由匿名私人资金资助的1000万美元项目支持完成。

视频概述

• 主题：介绍并重新创建迪士尼的钠蒸汽工艺（sodium vapor process），这是一种电影制作技术。
• 核心信息：该工艺曾为迪士尼带来巨额收入，但后来因故失落，视频探讨其历史和影响。
• 制作者：由 Corridor Crew（CorridorDigital）制作，视频制作得到 Squarespace 的支持。
• 技术背景：钠蒸汽工艺用于电影特效，可能涉及特殊拍摄或后期处理；视频中用户评论提到“修复绿屏”，暗示技术讨论。
• 发布时间：2024年4月7日。
• 关键细节：视频标题强调该发明的兴衰，内容可能涵盖技术原理、商业成功、丢失原因及现代应用尝试。

摘要：水稻与小麦种植的心理影响

生产方式（如水稻与小麦种植）对文化、社会和心理过程具有深远影响。水稻种植依赖于复杂的灌溉系统和协调劳动，因此倾向于培养集体主义思维，强调群体和谐和相互依存。相反，小麦种植所需劳动和协调较少，与个人主义文化相关，重视独立和个人自主。这种理论得到跨文化研究支持，例如世界各地水稻文化普遍表现出较低的自我关注、更注重关系或整体思维，以及更强的群体内偏好。中国水稻和小麦种植区域之间也存在类似差异。

然而，这些差异是否完全由生产方式解释，还是受其他因素（如遗传、历史或随机性）影响，仍有疑问。Talhelm 和 Dong 在《自然通讯》上发表的研究利用中国文革的特殊背景，提供了因果证据。文革期间，年轻人被随意分配到环境相似但生产方式不同的农场：一个适合水稻种植（位于河流下方），另一个适合小麦种植（位于河流上方）。通过测量思维风格的实验（如自我膨胀圆圈测试），研究发现水稻农场的人更倾向于集体主义思维，而小麦农场的人更倾向于个人主义思维。差异在短期内（几代人）出现，但随着文化嵌入时间延长而增强。

类似研究进一步支持这一观点。例如，Leibbrandt、Gneezy 和 List 对巴西渔村的研究显示，湖渔（个人主义）渔民更愿意竞争，而海渔（集体努力）渔民更合作；女性渔民未表现出相同差异，表明这些差异与生产方式直接相关，而非更广泛文化。

文章最后提出了一些未解问题：这些思维风格的形成需要多长时间？持续多久？在儿童或青年时期是否比后期更有效？在运动员（如划船与跑步）之间是否存在类似差异？并质疑外在言论（如“你没有建造那个”）是否能真正改变思维风格，但思考战争期间思维风格是否可能变化。总体而言，研究强调了生产方式对心理文化的塑造作用。

Diffoscope 文件深度比较工具

Diffoscope 是一款旨在深入分析文件、压缩包及目录差异的工具。它通过递归解压多种压缩包并转换各类二进制格式为可读形式来进行比较，可轻松处理 tarball、ISO 镜像、PDF 等文件。

核心功能

• 深度比较：能够分析造成文件或目录差异的根本原因。
• 广泛格式支持：支持大量文件格式，包括但不限于：APK、tar、ISO、PDF、ELF 二进制、Android 资源、Debian 软件包、Git 仓库、SQLite 数据库、各类压缩文件（gzip、bzip2、xz 等）、以及图片、文档、代码等多种格式。
• 递归解压：自动递归解压嵌套的压缩包和归档文件。
• 格式转换：将二进制数据转换为更易读的文本形式以便比较。
• 输出格式：提供命令行界面，支持文本和 HTML 格式输出。
• 高级特性：在无法使用特定格式解析器时，会回退使用 hexdump 进行比较；支持模糊匹配以处理文件重命名情况。

安装与使用

• 在线尝试：提供 try.diffoscope.org 网页版。
• Docker：可通过 Docker 快速运行。
• 包管理器：在多种操作系统上可通过包管理器安装（如 Debian/Ubuntu 的 apt、Fedora 的 dnf、Arch 的 pacman、Homebrew 等）。
• 其他方式：支持通过 pip、源码包或 Git 仓库安装。

社区与开发

• 该项目作为“可重复构建”努力的一部分而开发。
• 欢迎通过 Git 仓库提交补丁、报告问题或参与邮件列表讨论。
• 使用 GNU 通用公共许可证 v3 或更高版本授权，是自由软件。

相关工具

类似软件包括 pkgdiff 和 build-compare 中的 pkg-diff.sh。

Rpgp：纯 Rust 实现的 OpenPGP 库

Rpgp 是一个完全使用 Rust 语言编写的 OpenPGP 实现，遵循 RFC 9580 规范，并采用宽松的许可证（Apache-2.0 或 MIT 双许可）。

核心功能与特性

• 广泛的格式支持：支持常用的 v4 密钥格式、最新的 v6 密钥格式以及 AEAD 加密机制，同时兼容历史标准（如 RFC4880 和 RFC6637）中的 v3 密钥与签名。
• 低层级 API：提供灵活的低层级 API，便于开发者构建更高级别的 PGP 工具，并确保兼容性。
• 符合 Autocrypt 规范：完整支持 Autocrypt 1.1 电子邮件加密规范所需的所有功能。
• 广泛应用：已被多个知名项目采用，例如 Delta Chat（跨平台消息应用）、GpgFrontend（跨平台 OpenPGP 桌面客户端）、himalaya（命令行邮件管理工具）以及多个用于 Git 签名、包管理和密码管理的库。

使用示例

1. 验证内联签名消息：加载公钥，并验证使用该密钥签名的消息。
2. 生成与验证分离签名：使用私钥对数据生成分离签名，再用对应的公钥进行验证。

Cargo 特性

可通过 Cargo 特性启用额外功能，包括：

• bzip2：支持 bzip2 压缩。
• asm：启用基于汇编的优化。
• wasm：支持编译为 WebAssembly。
• large-rsa：允许使用超大 RSA 密钥（上限从 8192 位提升至 16384 位）。
• malformed-artifact-compat：对特定格式错误的工件保持宽容（通常无需启用）。
• draft-pqc / draft-wussler-openpgp-forwarding：支持相关的实验性草案（不稳定，不建议用于生产）。

项目状态与定位

• 实现状态：详细状态记录在 IMPL_STATUS.md 中，最后更新于 2025 年 9 月。
• 库的定位：
  • 面向开发者：旨在帮助应用开发者轻松集成 OpenPGP 功能。
  • 低层级构建块：提供处理 OpenPGP 格式与机制的底层抽象，但不确保使用方式的绝对安全性或严格符合规范，要求使用者具备扎实的 OpenPGP 和密码学知识。
  • 分层处理：库处理规范中定义的线上格式、复合对象和数据处理功能，但不处理未被规范详细定义的“OpenPGP 语义”（如证书的过期与撤销、密钥标志等）。高级语义需由应用自行实现或借助其他库（如 rpgpie）完成。
  • 支持广泛机制：支持几乎所有 OpenPGP 机制，包括现代和历史上被认为不安全的算法。

其他信息

• 最低支持 Rust 版本 (MSRV)：支持 Rust 1.88 或更高版本。
• 许可：采用 Apache-2.0 或 MIT 双许可。
• 贡献：提交的贡献默认遵循项目的双许可条款。