调查空壳公司与其秘密所有者的要点摘要

调查空壳公司及其最终受益所有人是一项复杂的专业工作，但掌握正确的方法和工具至关重要。以下是在2024年NICAR数据新闻峰会上，国际调查记者联盟数据与研究副主任 Karrie Kehoe 分享的核心技巧与资源。

核心原则：追踪最终受益所有人 调查的目标是找到“最终受益所有人”，而非表面的董事或股东。空壳公司常使用“挂名人”（如出租车司机）作为董事，以隐藏真实控制者。注册文件中总会留下痕迹，如公司地址、董事真实姓名等。

关键工具与起点

1. OpenCorporates：首选的免费开放数据库，收录超过140个政府注册机构的2.2亿家公司记录，适合初步搜索。
2. 付费企业风险数据库：当开放工具无法找到信息时，可考虑订阅 Sayari、Orbis 或 Factiva。这些平台能提供详细的公司档案、关联国别及风险标记。
3. ICIJ离岸泄露数据库：免费提供经过验证的81万家离岸公司、基金和信托的信息，数据来源于巴拿马文件、潘多拉文件等重大调查项目，支持按调查项目过滤。
4. OCCRP的Aleph数据库：涵盖1.41个国家的3.4亿公共实体信息，包含值得关注的人员名单、官方公报（公司注销记录）以及许多国家的法院记录。

实用调查技巧

• 从文件与代理人入手：空壳公司必须提交注册文件，关注“公司注册代理人”的角色。他们可能无意中泄露客户的护照副本或账单地址。
• 考虑目标的心理与行为：富豪的资产配置具有可预测性（如伦敦豪宅、游艇、艺术品），搜索特定豪华地段可能缩小范围。
• 注意拼写与语言变体：尝试名称、地址的不同拼写（如“Ian”与“Iain”）。对于非英语地址，使用谷歌地图找到本地拼写后，再译回英文进行数据库搜索。
• 利用谷歌地图核实：将找到的董事地址输入地图，查看是豪宅还是简陋办公室，后者可能是虚假地址。
• 跨数据库交叉搜索：利用 Open Ownership、英国海外实体登记册和欧盟TED公共采购等免费平台，追踪跨国商业联系。
• 借助家族与制裁名单：针对俄罗斯等地区的寡头，可使用 RuPEP 数据库查询其政治关联人物、家族成员及关联企业。OpenSanctions 有助于快速核查制裁状态。
• 视觉化搜索：在社交媒体上搜索疑似挂名董事或目标人物的社交照片，与数据库中的姓名关联。

总结 调查空壳公司需要耐心和系统性。充分利用开放数据库和专业平台，结合对目标行为的分析、对文件细节的挖掘以及跨资源的交叉验证，可以逐步穿透资产隐匿网络，揭开最终受益所有人的面纱。保持持久力是关键，因为注册代理人处往往存有突破性信息。

Kobold letters: HTML 电子邮件的风险

概念与威胁 Kobold letters 指 HTML 电子邮件中利用 CSS 样式和 DOM 结构变化来显示或隐藏内容的元素。这种技术允许攻击者在邮件被转发时动态改变内容，从而实施钓鱼攻击。风险在于：收件人可能信任已验证的发送者，却不知邮件内容已被篡改，导致资金诈骗或其他恶意行为。

攻击原理 攻击者发送一封看似无害的邮件（如客户咨询），其中嵌入 CSS 规则。当收件人转发邮件时，电子邮件客户端通常会在 DOM 中包裹原始邮件，改变元素层级。CSS 选择器根据上下文（如是否被转发）应用样式，使特定元素仅在转发后显示。这利用了 HTML 电子邮件中 CSS 实现的不一致性和 DOM 变化。

客户端演示

• Thunderbird：邮件被包裹在 <div class="moz-text-html"> 中。转发时，引用的邮件被另一个 <div> 包围，移动 DOM 层级。CSS 规则如 .moz-text-html>div>.kobold-letter 可控制显示。演示中，隐藏的段落在转发后变为可见。
• Outlook on the web (OWA)：邮件包含在动态类名的 <div> 中（如 rps_78fa），OWA 会为 CSS 类添加前缀（如 x_）以避免样式冲突。转发时邮件被进一步包裹，CSS 更新，但攻击仍可实施，需适应这些调整。
• Gmail：Gmail 在转发时剥离所有样式，因此技术上不受标准 Kobold letters 影响。但攻击者可利用 CSS 隐藏内容，转发时内容自动显示（因样式在发送后移除）。这更简单但受限，允许发送者检测攻击。

报告与响应 问题于 2024 年 3 月报告给相关厂商：

• Mozilla（Thunderbird）：计划未来版本实施缓解措施。
• Microsoft（Outlook on the web）：决定不立即采取行动。
• Google（Gmail）：于 2024 年 4 月确认正在修复，建议在编辑器中移除 CSS 以提前检测。

缓解措施与前景

• 用户缓解：禁用 HTML 邮件或使用受限查看模式（如纯文本）。
• 客户端缓解：较困难，因禁用 <style> 会破坏现有电子邮件生态系统；类似 Gmail 的样式剥离可能是一种折中方案。
• 前景：电子邮件客户端不太可能短期内实施稳健修复，风险仍存在。Kobold letters 突出了 HTML 电子邮件的固有风险，呼吁更安全的设计和用户意识。

先前工作 类似问题已有报告，但 Kobold letters 专注于特定攻击场景（转发）和多客户端分析，以提高对 HTML 电子邮件风险的意识。

问题描述

作者孩子的MacBook Pro因存储空间完全耗尽（仅剩41K自由空间）而无法正常工作。macOS在下载Steam游戏时，未能及时停止写入，导致系统无法删除任何文件。作者推测这与Time Machine本地快照和实时文件冲突有关，存储溢出使得操作系统失去管理能力。

尝试的解决方案及失败过程

• 清空废纸篓：通过Finder操作失败，系统报告磁盘已满。
• 终端命令：使用rm等命令尝试删除文件，均返回“设备无空间”错误。
• 磁盘工具：试图删除Time Machine快照，同样因空间不足失败。
• 重启：Mac无法启动，进度条中途卡住。
• 恢复模式：在recoveryOS中运行终端命令，仍失败。
• 共享磁盘：通过SMB协议挂载驱动器到另一台Mac，无法强制删除文件。

恢复备份的障碍

作者决定擦除驱动器并重新安装macOS（原为Ventura）。恢复备份时遇到新问题：

• 使用迁移助手从Time Machine备份恢复时，因macOS版本不匹配（14.3.1与14.4）而失败。
• 升级到Sonoma后，迁移助手无法通过SMB挂载网络Time Machine备份卷，这是已知的macOS 14.4系统问题。

最终解决方案

由于恢复失败，作者采用手动方法：

1. 从网络Time Machine备份中复制孩子的备份磁盘映像到一台Mac。
2. 将该映像复制到外部1TB SSD。
3. 连接SSD到孩子的MacBook Pro，手动复制必要文件（如用户目录内容），排除大型下载和无用文件。
4. 提供外部驱动器供孩子后续恢复缺失数据。

反思与补充

作者提到两种可能更简便的方法：

• 直接连接备份驱动器到孩子的Mac，作为迁移助手源。
• 创建外观类似Mac源卷的外部驱动器，尝试直接恢复。 但由于时间投入和孩子的低需求，这些方法未尝试。文章最后，作者感叹缺乏Mac经验的用户面对此类系统级故障时的无助感，凸显了macOS存储管理和备份恢复中的潜在问题。

文章总结了作者从零开始构建一个6 GHz脉冲压缩雷达的全过程。主要内容涵盖设计动机、硬件选择、系统架构、关键电路设计、校准、软件处理以及实际测试结果。

设计动机与架构 作者之前制作过FMCW雷达，但脉冲压缩雷达具有单天线、高发射功率和更好的高速目标速度测量等优势，因此决定尝试。系统架构类似软件定义无线电，采用零中频架构以节省成本，但会引入镜像信号和LO泄漏等非理想性，需要通过数字预失真进行补偿。

硬件选择与成本优化

• 核心器件：选用ADS4229 (250 MSPS, 12位) ADC 和 DAC3174 (500 MSPS, 14位) DAC，以在预算内获得高采样率。
• FPGA：采用Xilinx Zynq 7020 (集成ARM CPU)，从中国采购，单价仅17美元，远低于官方渠道。
• 射频部分：工作频率选择6 GHz（利用廉价消费类器件）。关键器件包括IQ调制/解调器、功率放大器( SE5004L, ~2W输出)和收发开关( MASW-007588)。

关键设计挑战与解决方案

1. 高速接口：使用LVDS连接ADC/DAC以降低FPGA成本。对DDR3内存走线进行了阻抗匹配和仿真，最终采用60Ω线宽和50Ω端接电阻以平衡信号完整性与PCB布线密度。
2. 信号完整性：为收发开关的控制信号设计了RC端接以消除传输线反射。
3. 电源噪声：采用开关稳压器加线性稳压器(LDO)及铁氧体磁珠滤波的组合，为模拟电路提供低噪声电源。
4. 时钟系统：使用CDCM6208时钟发生器为ADC、DAC和FPGA逻辑提供同步、低抖动的时钟。
5. PCB制造：委托中国厂商完成6层PCB制造和部分组装，成本较低。

校准与性能改善

• 通过测量并补偿ADC直流偏移和发射机LO泄漏，将脉冲压缩的旁瓣电平从-21 dBc改善至-36 dBc。
• 对发射脉冲应用Tukey窗，进一步抑制旁瓣。
• 测试发现，将线性调频信号偏移到非零中频可以避免交流耦合引起的直流偏移问题。

信号处理与软件

• FPGA：负责精确的脉冲时序控制、高速数据接口管理以及通过SPI配置各芯片。
• PC端处理：执行脉冲压缩、距离-多普勒处理、CFAR目标检测和基于StoneSoup库的卡尔曼滤波目标跟踪。

实测结果

• 在路边测试中，该雷达能够检测并跟踪约450米范围内的车辆，分辨率约为1米。
• 当使用单天线时，最小检测距离可缩短至约40米（以距离分辨率为代价）。
• 存在的一些问题包括：静态物体（如地面、树木）的大旁瓣会干扰近距离运动小目标的检测；PA的噪声泄漏会略微提高接收机噪底。

总结与成本 整套雷达的物料和制造总成本约为570美元。作者指出，该设计本质上与大型现代雷达类似，支持任意波形和数字处理，但受限于功率和天线尺寸，最大作用距离较短。原理图已公开，但固件和软件尚未发布。

V8 沙盒：技术总结

概述

V8 沙盒是一个轻量级的进程内隔离机制，旨在将 V8 引擎中的内存损坏限制在隔离区域内，防止其影响宿主进程的其他内存。经过近三年的开发，该功能已从实验性安全特性发展为包含在 Chrome 漏洞奖励计划（VRP）中的成熟组件。Chrome 123 可视为其“测试版”。

动机与背景

• 现实威胁：2021-2023年所有野外利用的 Chrome 漏洞均始于渲染进程中的内存损坏，其中 60% 的漏洞源头在 V8。
• 漏洞本质：V8 漏洞多为“二阶逻辑错误”（如示例中数组缩容导致的越界写），而非传统的内存安全问题（如释放后重用、越界访问）。
• 现有方案局限：
  • 内存安全语言（如 Rust）：能防止解释器/运行时代码中的漏洞，但无法防止 JIT 编译器自身的逻辑错误导致的生成代码漏洞。
  • 禁用 JIT：虽可解决部分问题，但会大幅降低性能（最高可达10倍以上）。
  • 硬件内存标记：易受侧信道攻击，且受 V8 指针压缩技术限制，无法有效标记对象间损坏。

核心原理与设计

沙盒通过将 V8 堆内存与其他进程内存隔离，防止堆内损坏“蔓延”。其设计借鉴了操作系统中用户空间与内核空间的隔离模型。

• 实现方式：纯软件实现（因缺乏合适硬件支持）。
• 关键改造：
  • 将所有可能访问沙盒外内存的指针和64位大小替换为“沙盒兼容”类型：
    • sandbox_ptr_t：基于沙盒基地址的40位偏移（适用于1TB沙盒）。
    • sandbox_size_t：限制为32GB的沙盒内大小。
    • external_ptr_t：通过指针表间接引用沙盒外缓冲区，提供安全保证。
  • 确保所有操作（如属性访问）均进行边界检查（如使用 SBXCHECK），防止利用不一致的元数据导致越界访问。
• 攻击阻断：攻击者无法直接利用 V8 堆内的损坏构造任意内存读写原语，因为无法“触及”沙盒外的内存。实现远程代码执行（RCE）需要额外的“沙盒绕过”漏洞。

性能与开销

• 主要开销来自指针表间接寻址（额外一次内存加载）和偏移量计算（移位加法）。
• 在 Speedometer 和 JetStream 基准测试中，典型工作负载的性能开销约为 1% 或更低。
• 因此，沙盒已在兼容的64位平台（x64和arm64）上默认启用超过两年。

测试与验证

沙盒设计具备可测试性：

1. 攻击者模型：假设攻击者可在沙盒内进行任意读写，目标为防止损坏扩散至沙盒外。
2. 攻击模拟：通过构建选项 v8_enable_memory_corruption_api=true 提供“内存损坏 API”，模拟典型 V8 漏洞的原语。
3. 违规检测：提供沙盒测试模式（--sandbox-testing 或 --sandbox-fuzzing），通过信号处理器检测如 SIGSEGV 等信号是否代表沙盒安全保证被突破。

使用与现状

• 需在构建时通过 v8_enable_sandbox 标志启用/禁用，不支持运行时切换。
• 要求64位系统以预留大量虚拟地址空间（当前为1TB）。
• 已在 Android、ChromeOS、Linux、macOS 和 Windows 的64位版 Chrome 上默认启用。虽然功能尚未完全成熟，但已用于收集稳定性和性能数据，并已迫使近期 V8 漏洞利用必须尝试绕过沙盒。

结论

V8 沙盒是应对 V8 引擎中复杂逻辑漏洞的关键一步。由于现有通用内存安全技术对 V8 效果有限，沙盒通过创建一个更易防御的隔离边界，实现了将内存损坏影响限制在可控范围内的目标，是迈向更全面内存安全的必要环节。

Terraform实现碳中性天然气生产

2024年3月27日，Terraform公司成功启用其集成式“电转气”示范系统，标志着该公司在利用阳光和空气合成无化石天然气技术上取得重大里程碑。该系统整合了三项自主研发的核心子系统：氢电解系统、直接空气捕获系统和甲烷化反应器，将电力和空气转化为管道级天然气（甲烷含量>97%）。

核心技术突破与成本优势

Terraform的核心创新在于将成熟工业流程整合进设计创新、成本效益高的专有系统中，以适应可再生能源电力的日常波动，从而实现低成本可持续天然气生产：

1. 绿色氢气生产：创新电解槽将廉价太阳能转化为氢气，当前生产成本低于每公斤2.50美元。其电解槽资本支出低于每千瓦100美元，基准太阳能光伏发电成本为每兆瓦时20美元。
2. 直接空气捕获二氧化碳：专有DAC系统当前捕获大气二氧化碳的成本低于每吨250美元，资本支出低于每吨年二氧化碳600美元。
3. 甲烷化反应：内部多级Sabatier化学反应器消耗氢气和二氧化碳，稳定生产管道级天然气，无需昂贵或稀有催化剂。

生产模式与团队特点

公司全部三个子系统均在其位于加利福尼亚州伯班克的总部内部研发与制造，实现了更快的迭代、更低的供应链风险，并完整验证了生产经济有效的无化石天然气的技术经济模型。

市场意义与未来规划

Terraform的成就为人类摆脱对传统化石燃料的依赖提供了工业规模的可再生碳氢化合物来源。目前，公司已开始接受首批生产型“Terraformer”的预订，并正逐步提升产能以满足需求。

Jpegli：一种新型JPEG编码库

Jpegli 是Google推出的一种新型高级JPEG编码库，旨在提升网页加载速度与图像质量。它在保持对传统JPEG格式高度向后兼容的同时，实现了显著的压缩效率提升——在高质量压缩设置下，相比传统方案可提升35%的压缩率。该库提供了完全符合原始JPEG标准（8位形式）的编码器和解码器，并具备与libjpeg-turbo及MozJPEG的API/ABI兼容性。

主要特点：

• 高质量输出：采用更精确和符合心理视觉模型的计算，使图像更清晰、伪影更少。
• 编码速度快：在提升质量/压缩率比的同时，编码速度与libjpeg-turbo、MozJPEG相当，便于开发者无缝集成。
• 10+位编码支持：通过API扩展支持10位以上色深编码，能减少缓变区域的色带现象，且生成的图像仍可由8位查看器正常显示。
• 更高压缩密度：比传统JPEG编码器更高效地压缩图像，节省带宽和存储空间，加速网页加载。

工作原理： Jpegli 运用了一系列新技术来降低噪声、提升图像质量，同时坚持使用传统的8位JPEG形式以确保广泛兼容性。核心方法包括：

1. 自适应量化启发法：源自JPEG XL参考实现，基于心理视觉建模对量化死区进行空间调制，可在提升画质的同时减小文件体积，且速度优于Guetzli的类似方法。
2. 改进的量化矩阵选择：采用针对混合心理视觉质量指标优化的量化矩阵。
3. 精确的中间结果计算：提升编码与解码质量。
4. 高级色彩空间支持：可选用JPEG XL的XYB色彩空间，进一步提升质量和压缩效率。

测试与评估： 研究团队使用众包评分员，对比了Jpegli、libjpeg-turbo和MozJPEG在不同比特率下对Cloudinary Image Dataset '22的编码质量（解码统一使用libjpeg-turbo）。采用基于国际象棋排名的ELO评分系统聚合评价。测试在不使用XYB ICC配置文件的条件下进行，模拟大多数用户的初始使用场景。

结果表明：在2.8比特每像素（BPP）的Jpegli编码，其ELO评分高于比特率高出32%（3.7 BPP）的libjpeg-turbo编码，证实了Jpegli在同等质量下可实现更低比特率，或在相同比特率下获得更优画质。总体验证了Jpegli具备将高质量图像压缩率提升35%以上的潜力，有望使互联网速度更快、视觉体验更好。

HTTP/2 CONTINUATION Flood 漏洞技术分析

核心漏洞原理

HTTP/2 协议允许通过 HEADERS 帧和 CONTINUATION 帧分片传输大量头部信息。正常流程中，最后一个帧需设置 END_HEADERS 标志以标识头部传输结束。漏洞源于恶意客户端发送 HEADERS 帧后，持续发送未设置 END_HEADERS 标志的 CONTINUATION 帧，形成无限头部流，迫使服务器持续解析并存储数据，从而导致资源耗尽。

与 HTTP/1.1 不同，许多 HTTP/2 实现未正确设置头部大小限制或超时机制，导致该漏洞可被利用。

主要影响类别

漏洞的后果因实现差异可分为四类：

1. CPU 耗尽：即使服务器限制了头部大小，解码过程仍会持续消耗 CPU。

   • 案例（Golang）：readMetaFrame 函数中的 HPACK 解码器在达到大小限制后虽停止“发射”头部，但仍会继续解码后续帧，直至收到 END_HEADERS 标志或出错。攻击者可无限期占用解码循环。

2. 内存溢出崩溃（多连接）：服务器为每个连接分配的头部列表内存未设超时，攻击者可通过多个连接将内存占用至极限。

3. 内存溢出崩溃（单连接）：部分实现无条件将头部存入内存直至耗尽。

   • 案例（Firefox 客户端）：浏览器端同样存在此问题，修复方案是检查聚合头部大小是否超过限制。

4. 断言失败崩溃：极少数实现因连接在 CONTINUATION 流中断开时引发的数据竞争导致崩溃。

   • 案例（Node.js）：当客户端断开连接与 nghttp2 回调解析 CONTINUATION 帧同时发生时，可能导致内存计数器 current_nghttp2_memory_ 值异常（例如变为负数），触发析构函数中的断言失败。

与已有漏洞对比

与 2019 年发现的 CVE-2019-9516（0 长度头部泄漏）和 CVE-2019-9518（空帧洪泛）不同，CONTINUATION Flood 使用最大可能尺寸的帧进行解码和内存占用。 与 2023 年的 Rapid Reset 攻击相比，CONTINUATION Flood 的威胁被认为更大：

• 隐蔽性：攻击请求因未设置 END_HEADERS，不会被记录在 HTTP 访问日志中，难以调试。
• 效率：在多种实现中，仅需单个 TCP 连接即可导致服务器崩溃或严重性能下降，而 Rapid Reset 通常需要大量请求。
• 可见性：管理员无法在日志中看到任何异常请求。

影响范围与协调披露

该漏洞影响众多主流 HTTP/2 实现（如 Apache httpd、Envoy 等），鉴于 HTTP/2 流量占全球人类 HTTP 流量的约 60%，漏洞波及范围广泛。攻击可能导致重要网站、API 服务中断，造成重大损失。

研究人员于 2024 年 1 月向 CERT/CC 报告此问题。CERT/CC 随后开启了供应商协调案例，并发布了罕见的漏洞说明（VU#605641），协同众多技术厂商和开源项目进行了负责任的披露。

这篇文章是一篇对盲人软件开发者的访谈，介绍了他的工作方式、使用的工具以及面临的挑战。

作者基本情况 作者是一名在Vincit公司工作的全栈Web开发者，主要专注于后端，同时也担任无障碍顾问。他完全失明，仅能感知强光。

工作设备与核心工具 他使用一台运行Windows 10的普通笔记本电脑，关键工具是屏幕阅读器NVDA（开源、活跃维护）。他没有使用鼠标，完全依赖键盘操作。他的工作环境高度依赖命令行，很少使用图形界面应用程序。

屏幕阅读器的工作原理 屏幕阅读器以线性、分块（如一行、一个词）的方式将屏幕信息通过盲文显示器或合成语音输出。他使用芬兰语合成器朗读英语文本，语速高达每分钟约450词。这导致他无法像视觉用户那样快速扫描屏幕布局，必须逐块阅读或跳过，获取的信息类似于一个没有视觉格式的纯文本文件。

编程工作方式

• 阅读代码：像阅读小说一样逐行听取，或进行抽象理解。依赖代码缩进来构建代码结构的心理地图，认为清晰的编码风格至关重要。
• 代码审查：偏好查看原始的diff输出，认为并排差异对比无效。+/-符号比背景颜色更高效。
• 前端开发：可以处理逻辑层（如Angular、React应用中的功能实现），但基本不做视觉原型设计。利用Bootstrap等框架的栅格系统进行布局，但所有界面更改必须经视觉正常的同事确认。

工具选择的关键：无障碍性 工具的选择首要标准是无障碍性。

• 编辑器：曾长期使用Notepad++（轻量、可访问）。后因大型Java项目需要，转而使用IntelliJ IDEA（IDE通常对键盘操作不友好，但该IDE可用）。其他流行编辑器（如Sublime Text、Atom）以及终端编辑器（如Vim）对他而言要么不可访问，要么支持不佳。
• 操作系统：选择Windows是因为NVDA的卓越支持和活跃维护。相比之下，macOS的VoiceOver维护滞后，Linux上的屏幕阅读器仍有不足。他使用Git Bash来弥补Windows命令行工具的先天不足。

总结 这篇文章展示了一位盲人开发者如何利用特定的屏幕阅读器技术和键盘操作，在高度视觉化的软件开发领域有效工作。其工作方式的核心在于将视觉信息转化为线性听觉/触觉信息，并极度依赖无障碍的工具、清晰的代码结构以及命令行环境。同时，也反映了当前软件开发工具在无障碍支持方面的现状与差距。

美国政府资助热砂储能试点项目

项目概况 美国能源部将提供400万美元资金，资助一个热砂储能技术的试点示范项目，旨在验证该技术的商业化可行性。该项目计划明年在国家可再生能源实验室（NREL）位于科罗拉多州博尔德市附近的Flatiron园区破土动工。

技术性能与规模

• 试点系统：放电容量为100千瓦，持续时间为10小时。
• 商业规模潜力：根据NREL的报告，当砂被充分加热并储存在五个储存仓中时，该技术可产生135兆瓦的电力，并持续供电长达五天。
• 热保持效率：计算机模型显示，商业规模系统的热量保持率超过95%，至少可维持五天。
• 成本目标：在多种情景下，其平准化储能成本可达到5美分/千瓦时。

商业化进程

• NREL已为该热储能（TES）系统制定了技术到市场的转型计划，但因商业敏感性未公开。
• 合作伙伴Babcock & Wilcox在2021年已与NREL签署协议，获得了“仅限现场”的独家谈判许可权，以协商可能的技术市场化许可协议。

行业对比 文章指出，该技术属于长时储能领域，与典型的4小时电池储能相比，其持续时间更长。文中列举了其他几种长时储能技术示例：

• 压缩空气储能：Hydrostor在加州开发一个500兆瓦/4,000兆瓦时的项目。
• 抽水蓄能：蒙大拿州一个在建项目容量为400兆瓦，年发电量估计为1,300吉瓦时。
• 液流电池：2023年全球市场规模估计为2.89亿美元。
• 氢储能：作为季节性储能的选择，犹他州的一个项目预计将具备150吉瓦时的储能容量，并配套840兆瓦氢燃料燃气轮机联合循环电厂。

Chisel：基于HTTP的快速TCP/UDP隧道

Chisel是一款基于HTTP传输的快速TCP/UDP隧道工具，通过SSH协议进行加密，由Go语言编写。它是一个单一的可执行文件，包含客户端和服务器端。其主要用途是帮助网络流量穿越防火墙，同时也可以为网络提供一个安全端点。

核心功能特点

• 易于使用：提供单文件包含客户端和服务器。
• 高性能：设计注重性能。
• 加密与认证：使用SSH协议（通过crypto/ssh库）确保连接加密。支持基于配置文件的客户端用户认证，以及基于指纹匹配的服务器连接认证。
• 自动重连：客户端支持指数退避的自动重连机制。
• 多隧道复用：客户端可以通过一个TCP连接创建多个隧道端点。
• 代理穿透：客户端可选通过SOCKS或HTTP CONNECT代理进行连接。
• 反向端口转发：允许连接从服务器端发起，通过客户端向外转发。
• 多功能服务器：服务器可选作为反向代理，并可选提供SOCKS5连接支持。
• 灵活连接：客户端支持通过标准输入输出（stdio）建立连接，这可以配合SSH的ProxyCommand选项实现SSH over HTTP。

安装方式 Chisel提供多种安装方式：

• 二进制文件：从最新发布页面下载，或使用curl命令一键安装。
• Docker：直接通过Docker镜像运行。
• Fedora：可通过系统包管理器（dnf）安装。
• 源码编译：使用go install命令从Go源码安装。

快速演示 文档提供了一个基于Heroku的演示：

1. 服务器启动命令（将web请求代理到指定地址）：chisel server --port $PORT --proxy http://example.com
2. 客户端连接命令（将本地3000端口隧道到服务器的3000端口）：chisel client https://chisel-demo.herokuapp.com 3000 连接后，访问本地3000端口即可看到服务器上运行的文件服务内容。

使用指南 工具通过chisel server和chisel client子命令运行，各自拥有大量配置选项。

• 服务器端选项：包括监听主机/端口、密钥管理（--keygen生成、--keyfile指定）、用户认证文件（--authfile）、连接保活（--keepalive）、后端代理（--backend）、启用SOCKS5（--socks5）、允许反向转发（--reverse）以及TLS配置等。
• 客户端选项：包括指定服务器地址、定义转发规则（如本地端口:远程主机:远程端口或R:本地端口:远程主机:远程端口表示反向转发）、服务器指纹验证（--fingerprint）、客户端认证（--auth）、代理设置（--proxy）、自定义HTTP头等。
• 转发规则格式：
  • 正向转发：[本地主机:]本地端口[:远程主机:]远程端口[/协议]
  • 反向转发：R:[本地接口:]本地端口:[远程主机:]远程端口[/协议]
  • 支持SOCKS5简写（如socks）和标准IO模式（stdio）。

安全机制

• 加密：始终启用。服务器启动时会生成ECDSA公私钥对，公钥指纹（SHA256的Base64编码）将显示。客户端可通过--fingerprint选项强制要求特定指纹以防止中间人攻击。
• 认证：服务器可通过--authfile指定一个users.json文件来定义允许的用户及其权限（可限制访问的远程地址）。客户端使用--auth选项进行认证。此机制基于SSH的密码认证方法实现。

SOCKS5代理设置指南 文档描述了通过Docker快速搭建加密SOCKS5代理的步骤：生成密钥、启动带--socks5选项的服务器、客户端使用socks作为远程规则连接，最后将SOCKS5客户端（如浏览器）指向本地监听端口。

注意事项 由于依赖WebSockets支持，不同平台兼容性不同：大多数IaaS提供商支持，PaaS提供商中Heroku和Openshift支持，而Google App Engine不支持。

版本与许可 项目遵循语义化版本，文档列出了从1.0到1.11的主要更新日志。采用MIT许可证。

阻止Apple数据共享比预期更困难

研究发现

研究人员发现，在实际操作中，保护Apple设备上的隐私需要用户对每个应用进行持续且专业的设置调整，但Apple提供的帮助不足。实验表明，参与者无法在任何应用中成功阻止数据共享。

指令问题

• 复杂混乱：Aalto大学的博士研究员Amel Bourdoucen指出，在线隐私限制指令非常复杂且令人困惑，步骤分散在不同位置，缺乏清晰指引（例如，用户不确定应进入应用设置还是中心设置，或两者兼顾）。
• 不完整：指令未列出所有必要步骤，也未解释收集的数据如何处理。

实验结果

• 用户尝试更改设置时，无法阻止应用与第三方或服务提供商共享数据。
• 调整隐私设置耗时过长，且过程中缺乏反馈，导致用户迷失方向、随机滚动，不确定是否已完成足够步骤。
• 参与者最多只能完成一两个正确步骤，但无人能遵循完整流程保护隐私。

数据用途

• Apple可能将收集的数据用于训练Siri的AI系统、提供个性化用户体验等，但公开文件未明确说明具体用途。
• 用户习惯于无缝的多设备交互，这使得减少数据共享变得困难，但Apple应更清晰地告知用户数据使用情况。

改进建议

研究列出详细建议以澄清隐私设置和改进指南，包括：

• 优化指令的清晰度和完整性。
• 提供更透明的数据使用说明。

替代方案

• 对于个别应用，用户可通过选择第三方服务来部分解决问题（例如，一些参与者从Safari切换到Firefox）。
• 对于Google的Android平台，尚无类似研究，但过去第三方应用研究表明，Google在隐私保护方面并不优于Apple。

总体结论

• 用户面临保护隐私的几乎不可能任务，凸显了当前隐私设置的系统性缺陷。

通过自建数据库节省云成本

面临的挑战

Hivekit 运营一个实时追踪数万人员和车辆的云平台，需存储每个位置更新并通过历史API提供查询。业务场景对数据粒度要求差异极大，因此必须存储所有原始数据。每月数据量高达35亿条，并持续增长。原先使用AWS Aurora（PostGIS扩展）的成本已超过每月1万美元，且在客户端本地部署时，数据库集群易被高更新负载压垮。

市场现有方案的局限

尽管存在支持空间数据类型的数据库（如MongoDB、Redis）及空间扩展（如PostGIS、GeoMesa），但均无法满足其核心需求：极高的写入性能（每秒数万次更新）、无限并行写入能力以及极小的磁盘占用。他们更关注写入性能与存储效率，可适当放宽读取性能与数据一致性要求。

自建存储引擎的设计

团队构建了一个进程内专用存储引擎，采用二进制格式并基于增量存储：

• 每条更新仅存储变化字段，结合时间戳和ID，单条记录平均仅34字节。
• 每200条记录存储一次完整状态快照，便于历史查询与恢复。
• 维护独立的索引文件，将字符串ID映射为4字节标识符，加速特定对象的历史检索。
• 实时查询基于内存架构，磁盘读取仅发生在服务器重启、历史查询等低频场景。

取得的成果

1. 成本大幅降低：用每月200美元的EBS卷（Provisioned IOPS SSD）替代了Aurora，实现98%的云存储成本削减。将30GB以上的历史数据迁移至AWS Glacier进一步节省开支。
2. 性能显著提升：写入延迟降低，查询速度大幅提高（例如历史时间点重建从约2秒降至13毫秒）。
3. 可靠性与功能无损失：利用EBS内置的备份与高可用保障，并未牺牲原有数据可靠性，同时满足了所有业务需求。

该实践表明，在特定高性能、高吞吐、存储敏感的场景下，自建专用存储引擎可能成为兼顾成本与性能的有效解决方案。

文章标题：美国伟大铁路步道（The Great American Rail-Trail）

核心内容摘要：

• 路线概况： 美国伟大铁路步道是一条规划中的、连接华盛顿特区与华盛顿州、横跨美国的连续步行和骑行路线。总长度超过3,700英里，由150多个现有的铁路步道、绿色通道及其他多用途路径组成。目前，已有超过55%的路线建成。
• 路线标准： 为确保高质量体验，该步道的首选路线需满足多项标准：尽可能直接、连续；至少80%的路段（最终目标是100%）与机动车辆交通分离；优先利用现有步道；考虑地形、地理及地方政策可行性；并能带动当地经济发展，为长途旅行者提供服务。
• 途经州份与关键步道： 路线穿越马里兰、宾夕法尼亚、西弗吉尼亚、俄亥俄、印第安纳、伊利诺伊、爱荷华、内布拉斯加、怀俄明、蒙大拿、爱达荷和华盛顿州。文章列举了各州沿途的部分关键步道，例如马里兰/华盛顿特区的C&O运河纤道、俄亥俄的Ohio to Erie Trail、爱达荷的Coeur d’Alenes步道以及华盛顿州的Palouse to Cascades State Park Trail等。
• 临时绕行路线： 针对内布拉斯加州查德隆到蒙大拿州圣瑞吉斯之间约960英里的缺口，RTC与Adventure Cycling Association合作开发了一条临时绕行路线。
• 参与与支持： 文章呼吁通过倡导、志愿服务和捐赠来保护这些步道，并介绍了支持该愿景的方式，例如购买主题装备或向RTC捐款。

LLocalSearch 项目摘要

项目状态与定位 LLocalSearch 是一个本地运行的 Perplexity 克隆项目，当前版本已超过一年未更新，作者正在私下进行重写和重新发布，以收集反馈。该项目是一个围绕本地大型语言模型（类似 ChatGTP 但更小、更轻量）的包装器，旨在让用户在不依赖外部 API 的情况下获得联网搜索能力。

核心功能与原理 项目通过让本地 LLM 自主选择并调用一组预设工具（如互联网搜索）来获取实时信息。该过程是递归的，模型可根据用户输入和工具调用结果，多次灵活地使用工具以完善答案。

使用理由 作者指出，该项目旨在提供一种更尊重隐私、不受商业利益操纵的替代方案。它避免了依赖可能被最高出价者影响结果的中心化服务。

主要特性

• 完全本地化：无需 API 密钥，注重隐私。
• 硬件要求低：演示视频中使用了约 300 欧元的 GPU。
• 答案透明：提供实时日志和链接，展示信息来源，便于深入研究。
• 支持交互：允许后续提问。
• 用户友好：移动端适配，支持深色/浅色模式。

开发路线图

• 近期工作：
  • 优化对 LLama3 的支持（修复停用词处理问题）。
  • 界面重构，采用更灵活、高效的空间布局（灵感来自 Obsidian）。
  • 添加聊天历史记录功能。
• 计划中功能：
  • 用户账户系统，为未来集成私有信息（如上传个人文档、连接 Google Drive 等）奠定基础。
  • 长期记忆功能，通过向量数据库为每个用户存储个性化信息。

安装方式 项目支持通过 Docker 部署：克隆 GitHub 仓库，根据需要创建并编辑 .env 文件（通常用于配置 Ollama 连接），然后运行容器。

Runtipi 是一个基于 Docker 的家庭服务器管理工具，遵循自由和开源原则。其代码公开，采用 GPL-3.0 许可证，鼓励用户自由使用、修改和分发，并欢迎任何人浏览代码、报告问题或提交拉取请求以改进项目。

项目拥有一个活跃的社区，汇聚了数百名自托管爱好者。用户可以通过 Discord 和论坛参与讨论、分享创意、解决问题，并共同塑造 Runtipi 的未来发展。

项目欢迎各类贡献，包括但不限于：在问题跟踪器中报告错误和问题；提交包含新功能或错误修复的拉取请求；协助将项目翻译成其他语言。开发者、设计师或普通用户均可参与其中。

MOnSter 6502：经典MOS 6502微处理器的晶体管级复刻版

项目概述

MOnSter 6502是一个“去集成化”电路项目，旨在构建一个完整、可工作的经典MOS 6502微处理器的晶体管级复刻版。MOS 6502曾用于苹果II、Commodore PET、雅达利游戏机等历史性计算机系统。

主要特点与规格

• 物理尺寸：电路板为4层，尺寸为12×15英寸，厚0.1英寸，两面均有表面贴装元件。
• 组件数量：总计4769个元件，包括3218个晶体管和1019个电阻构成“功能”部分。此外还有313个LED（用于指示控制线、寄存器和状态位）、用于驱动LED的额外MOSFET和电阻、滤波电容、总线电容等。
• 工作原理：采用原始的动态NMOS逻辑设计，在单个晶体管级别实现。
• 性能：运行速度约为原版6502的1/20，最大可靠时钟频率约50 kHz。速度限制主要来自所用MOSFET的门极电容。
• 功耗：在5V下约消耗2A，总功率10W（LED耗电显著）。

项目现状与历史

• 开发历程：历时约8年，主要设计工作在2015年完成。
• 原型展示：首个全尺寸原型于2016年在旧金山Maker Faire公开展示，成功运行了汇编、BASIC和Forth程序。
• 当前进展：正朝着公开发布迈进（原计划2023年中），已将其集成到带有隐藏“主板”的影盒展示柜中，可独立运行演示程序。
• 配套开发：项目约一半工作集中在为处理器构建键盘、显示器等接口，并开发了一个可使用6502 IC或MOnSter 6502的单板计算机系统。

应用与兼容性

• 功能：可作为6502集成电路的电路内硬件模拟器，适用于能以较低时钟频率运行的电路。
• 兼容性：无法直接用于依赖高速时钟的原机系统（如苹果II）。但可与支持可变时钟速度的自制6502计算机（如RetroShield 6502、Ben Eater的6502计算机等）配合使用。

常见问题解答

• 是否为纯粹的“分立元件6502”：严格来说不是。虽然使用原始NMOS逻辑设计，但由于技术原因采用了四晶体管阵列芯片（这些芯片内部包含4个MOSFET），因此电路中存在集成电路。
• 尺寸对比：与原始6502芯片相比，面积约大7000倍。若使用通孔元件，面积将达约19平方英尺。
• 购买信息：目前无法购买，但预计将于2023年年中左右公开发布。估算成本在2000至4000美元之间，主要受大量小型元件及小批量生产组装成本影响。

设计者与致谢

由Eric Schlaepfer设计，与Evil Mad Scientist Laboratories合作开发。项目感谢Ken Shirriff、visual6502.org等个人和组织的支持。

Logik 开源 FPGA 工具链概述

Logik 是由 Zero ASIC 推出的开源 FPGA 工具链，支持从高层语言解析、综合、布局布线到比特流生成与分析的完整设计流程。用户通过简洁的 SiliconCompiler Python API 输入设计源代码、约束条件和编译选项，设置完成后只需一行运行命令即可启动自动化编译。该工具链依赖于 Logiklib 项目提供的所有架构和设备描述。

主要功能与特性

Logik 具备商业 FPGA 工具链中的大多数核心功能：

快速开始

可通过 PyPI 使用 pip 安装 Logik：

python -m pip install --upgrade logik

所有开源 FPGA 前置工具可通过 SiliconCompiler 的 sc-install 工具安装。

以下是一个基本使用示例：

import siliconcompiler
from logik.flows.logik_flow import LogikFlow
from logiklib.zeroasic.z1000 import z1000

# 创建设计对象，包含源代码和约束
design = siliconcompiler.Design('adder')
design.add_file('adder.v', fileset="rtl")
design.set_topmodule('adder', fileset="rtl")

# 创建 FPGA 项目
project = siliconcompiler.FPGA(design)

# 添加用于综合的文件集
project.add_fileset('rtl')

# 设置 RTL 到比特流的流程
project.set_flow(LogikFlow())

# 加载 FPGA 设备设置及关联的流程和库
project.set_fpga(z1000.z1000())

# 设置用户选项
project.option.set_quiet(True)

# 执行编译
project.run()

# 显示结果摘要
project.summary()

示例项目

• Ethernet：为 z1000 架构编译的以太网 MAC
• Adder：为 z1000 架构编译的小型加法器
• Picorv32：为 z1062 架构编译的 picorv32 RISC-V CPU

文档与资源

• Logik 文档
• SiliconCompiler 文档

安装与依赖

Logik 以 wheel 包形式发布在 PyPI 上，支持 macOS、Windows 和 Linux 平台（需 Python >= 3.10）。本地运行需安装以下前置工具：

• SiliconCompiler：硬件编译器框架
• Slang：SystemVerilog 解析器
• Yosys：逻辑综合平台
• Wildebeest：高性能 Yosys 综合插件
• VPR：FPGA 布局布线工具
• FASM：FPGA 汇编解析与生成器
• OpenSTA：生产级静态时序分析引擎

推荐使用 sc-install 工具自动安装所有依赖的正确版本。详细安装指南可参考 SiliconCompiler 安装文档。

许可证

Logik 项目基于 Apache License 2.0 开源许可证。所有依赖项的许可证信息可访问相应依赖仓库。

问题与反馈

项目使用 GitHub Issues 跟踪请求与错误报告。

Show HN: AWS 托管 GitHub Actions 运行器

本文介绍了 Depot 公司推出的一项新服务，该服务可在 AWS 云上托管并运行 GitHub Actions 作业，旨在解决原生 GitHub Actions 在性能、成本和缓存方面的痛点。

原生 GitHub Actions 的问题：

• 性能不佳：CPU 计算能力较弱。
• 网络受限：缓存及互联网访问带宽被限制在 1 Gbps。
• 缓存有限：每个仓库的缓存存储上限仅为 10 GB。
• 成本较高：对于超过 2 个 CPU 的运行器价格昂贵，且大型运行器启动作业耗时较长。

Depot 解决方案及优势： 该服务通过将作业路由到快速的 AWS EC2 实例来运行，而非使用 GitHub 的默认计算资源。其核心优势包括：

1. 性能更强：使用 AWS m7a 等实例类型，CPU 性能比替代方案高出 30% 以上。
2. 网络高速：每个实例提供高达 12.5 Gbps 的网络吞吐量，加速了与制品、缓存、容器注册表或互联网的交互。
3. 独立资源：每个实例拥有独立的公共 IPv4 地址，无需与他人共享速率限制。
4. 无限高速缓存：集成了基于 S3 和 Ceph 的分布式缓存系统，缓存读写速度可达 1 GB/s，并且突破了原生 10 GB 的仓库缓存限制。
5. 成本更低：费用仅为 GitHub Actions 运行器的一半。

工作原理与技术实现：

• 该服务为每个作业启动一个专用 EC2 实例，将其注册为用户 GitHub 组织中的自托管运行器，作业完成后立即终止实例。
• 面对同时启动大量作业的挑战（如矩阵工作流），其采用自研的“热池”（warm pool）编排系统。该系统预先准备并停止 EC2 实例，在作业请求到达时快速调整和启动，将作业排队时间控制在约 5 秒。他们认为现有的自动伸缩组或 Kubernetes 方案在速度或安全性上不足。

与现有替代方案的对比：

1. GitHub 大型运行器：虽然提供更多 CPU，但网络和缓存仍然较慢，且价格高于 Depot。
2. 自托管运行器：需要用户自行维护基础设施，且需确保运行器环境与 GitHub 一致，管理复杂。
3. 其他托管服务：常因使用廉价计算提供商而导致网络吞吐量或地理位置成为瓶颈。

试用信息： 该服务提供免费试用，需通过注册（https://depot.dev/sign-up）并安装 GitHub 应用。设置注册门槛一方面是因为集成需要，另一方面也是为了防止服务被用于加密货币挖矿。

本文介绍了自然语言处理（NLP）中的三个基础概念：词元（Tokens）、n-gram 模型和词袋模型（Bag-of-Words），旨在帮助理解现代语言模型（如 ChatGPT）的底层原理。

1. 词元（Tokens）与 n-gram

• 词元是文本处理的基本单元，不一定是单个字符。例如，“Milvus's” 可被分割为 “Milvus” 和 “'s” 两个词元，以便保留语义上下文。将文本切分为词元的过程称为分词（Tokenization），是现代语言模型处理输入的预处理步骤。
• n-gram 指由 n 个连续词元组成的序列。例如，“Milvus vector database” 是一个 3-gram（三元组）。
• n-gram 模型是一种概率语言模型，用于预测序列中下一个词元出现的概率。例如，p(database | vector) 表示在给定词元“vector”后出现“database”的概率。该概率通常通过统计语料库中 n-gram 的出现频率来计算。

2. 概率计算与代码示例

文章通过一个简短语料库演示了如何计算 bigram（2-gram）概率：

• 统计每个词元和 bigram 的出现次数。
• 通过归一化（用 bigram 次数除以前序词元次数）得到条件概率。
• 提供了 Python 代码示例，用于构建 bigram 模型并计算概率。测试结果显示，该方法可应用于真实文本（如美国国情咨文）。

3. 词袋模型（Bag-of-Words）

• 词袋模型将文档表示为词频的无序集合，忽略词序和上下文。每个文档可转换为一个稀疏向量，向量维度对应词汇表，值为词频。
• 该模型简单易用，可用于文本分类等任务，但无法捕捉语义和上下文信息，因此不适合复杂任务，已被神经网络方法取代。

总结

词元化、n-gram 和词袋模型是 NLP 的基础。其中，n-gram 的概率思想对理解现代自回归和自编码语言模型的训练方式至关重要。本文为后续讨论循环神经网络和文本嵌入等现代 NLP 技术奠定了基础。