2024-09-04

40 篇热帖

1. ReMarkable Paper Pro (remarkable.com)

reMarkable Paper Pro 产品介绍

核心产品:

  • reMarkable Paper Pro Move: 最便携的纸屏平板。
  • reMarkable Paper Pro: 最先进的纸屏平板。

关键功能与服务:

  • 基础功能: 所有平板均内置手写转换屏幕共享和有限云存储。
  • Connect 订阅服务: 连接常用工具,解锁更多新功能,已有超过100万订阅用户。

“纸屏平板”是什么?它为何而生? 它是一个专注于思考与创意的数字设备,主要服务于以下场景:

  1. 用于起步创意: 提供空白页面或模板,让各种思维风格的想法都能在此成形。
  2. 用于审阅文档: 使用手写笔对上传的文档进行标记、高亮或圈注,放慢节奏,深入思考阅读内容。AI功能还可为笔记生成摘要和行动项。
  3. 用于会议记录: 通过“会议笔记”工具一键导入Google或Outlook日程详情至单页,便于在会议进行中实时记录,并标记待回顾的想法。
  4. 用于协作分享: 轻松将想法发送至其他数字工作工具、通过电子邮件发送或生成链接分享。后台AI能将手写内容和草图转换为打字文本。

用户体验与保障:

  • 媒体报道: 被《The Verge》评为“用过的最佳数字记事本”,《Independent》称使用reMarkable Paper Pure是“愉快的体验”。
  • 试用政策: 提供50天试用期,如不满意可全额退款。
  • 隐私与订阅: 用户可订阅以获取资讯,注册即同意reMarkable处理数据,可随时取消订阅。
3. Intel Honesty (stratechery.com)

英特尔的诚实

硅谷与英特尔的崛起 文章从硅谷的起源开始,指出“硅”(Silicon)部分源于仙童半导体(Fairchild Semiconductor)。仙童的衍生公司塑造了整个地区,其中最重要的是英特尔。英特尔定义了技术行业的创新节奏:摩尔定律不仅是一项技术预测,更是一个经济引擎,推动了整个科技界对计算能力提升和成本下降的期望。英特尔通过主导PC和早期云计算处理器市场,成为了硅谷精神的象征。

英特尔的长期衰落 然而,英特尔陷入了长期衰退。其集成设备制造商(IDM)模式曾是护城河,如今却成为枷锁。在制造工艺上,英特尔在2010年代后期卡在10纳米节点,未能及时采用极紫外光刻(EUV)技术,将性能桂冠拱手让给台积电(TSMC)。在芯片设计上,由于依赖自家先进制程,其团队变得“臃肿和懒惰”,逐渐落后于使用台积电更先进工艺的AMD。在数据中心市场,AMD的份额不断增长,超级云服务商(如亚马逊)也开发基于ARM架构的芯片。更关键的是,英特尔错过了人工智能和移动两大浪潮。其错失iPhone订单并非因为不愿让利,而是其x86架构芯片在能效和软件生态上无法与ARM竞争;其在图形处理器(GPU)上的尝试也以失败告终,而GPU正是当前AI热潮的基石。

IDM 2.0战略与当前困境 2021年,帕特·基辛格(Pat Gelsinger)回归担任CEO后,提出了IDM 2.0战略,旨在将制造部门分离出来为外部客户服务,但仍维持公司整体架构,以避免重蹈AMD拆分Global Foundries后的困境。然而,文章指出该战略正面临严峻挑战:

  1. 制造问题:其承诺的“四年五个制程节点”进展存疑。最新的Intel 3工艺在尝试量产时摧毁了利润率,表明其尚未真正掌握规模化量产新技术的能力。
  2. 设计问题:其有竞争力的最新架构Lunar Lake的芯片(包括CPU)实际上由台积电代工,这不仅尴尬,更损害利润。
  3. 代工业务无客户:英特尔尚未为其关键的18A制程找到具有规模承诺的第三方大客户。公司自身反而更多地依赖台积电,这削弱了其代工业务的可信度。

核心矛盾与未来的残酷诚实 文章最终进行了一次“残酷诚实”的分析:从纯粹的市场角度看,英特尔代工业务(Intel Foundry)没有存在的理由。全球顶尖的无晶圆厂芯片设计公司(如苹果、英伟达、AMD)信赖台积电,因为其技术领先、服务可靠且持续投资。甚至英特尔自己的芯片部门,为了产品竞争力和成本考量,也应选择台积电。

基辛格和英特尔此前一直强调地缘政治风险(台湾的不稳定性)作为维持英特尔先进制造能力的理由。然而,文章指出,如果美国真的希望拥有一个非台湾的、领先的芯片制造选项,就必须直接支付高昂代价。

结论:国家购买保证是唯一出路 文章摒弃了直接补贴的方式,认为美国政府应实施“购买保证”:承诺在未来以特定价格购买一定数量的在美国本土生产的先进制程芯片(如5纳米、3纳米等)。这不仅能为拆分出来的英特尔制造部门提供明确的市场需求和生存动力,也能激励其他公司(如格芯或台积电)增加在美国的投资。

最终,文章总结道:科技世界已经抛弃了英特尔;美国维持领先芯片制造能力的唯一机会,是同样抛弃旧有的英特尔模式。 通过大手笔的购买保证(可能高达数千亿美元),美国可以创造一个脱离x86架构包袱、精简高效的新制造实体,使其有机会在市场中独立生存,而这或许是确保国家供应链安全的唯一可行路径。

4. The Engineering of Landfills (practical.engineering)

文章摘要:垃圾填埋场的工程学

本文通过美国加州普恩特山填埋场的案例,阐述了现代垃圾填埋场从简单弃置点发展为高度工程化设施的过程。

1. 核心目标与选址的复杂性 垃圾填埋场的核心目标是最大化存储容量、最小化成本与环境影响。这使其选址成为复杂的几何与多学科问题:需避免挖掘过深(成本高、地下水问题)而主要向上堆筑,同时需稳定斜坡、控制底部压力。此外,还需避开机场、居民区、洪泛区,并配套建设地磅、设备间及交通道路,涉及地质、环境、工程、公共关系等多方面考量。

2. 关键防渗与渗滤液处理系统 原始填埋方式会导致垃圾渗滤液污染土壤与地下水。现代填埋场采用复杂的底部防渗衬层系统,通常由焊接严密的塑料膜和/或压实粘土层等多层不透水材料构成。同时,建有精密的渗滤液收集系统(如穿孔管道、排水层和集水坑),在保证衬层完整性的前提下,将渗滤液导出并处理,防止垃圾堆积体变成“沼泽”。渗滤液管理(如送往处理厂或现场处理)是填埋场运营的主要成本之一。

3. 日常运营与封场管理

  • 压缩与覆盖:为最大化利用空间,使用大型压实机压缩垃圾。每日工作面需进行“每日覆盖”以控制害虫、气味、火灾和碎片飞散,材料可为土壤、织物或惰性废弃物。
  • 分区与监测:填埋场通常分区建造和运营,并持续进行地下水、空气质量等环境监测。
  • 封场与最终覆盖:填埋场达到容量后进行封场。最终覆盖系统(包含土壤、膜和织物)旨在长期阻止水分进入、锁住废弃物及气味,并需在表面种植植被以防水土流失。
  • 气体收集与利用:封场后,废弃物内部生物反应会产生甲烷等气体,需通过垂直井持续抽吸收集,以防爆炸或环境危害。收集的气体可直接燃烧,或转化为热能和电能(如普恩特山填埋场的气体发电设施)。

4. 后期管理与再利用 填埋场关闭后需进行至少30年的长期监测、维护与修复。其高昂的后期成本需提前纳入运营预算。许多废弃填埋场在妥善维护下,正被改造成公园、步道等公共空间,体现了土地再利用的可能性。

5. 总体评价 尽管看似是“环境伤疤”,但设计良好的现代垃圾填埋场是有效管理固体废物、防止其污染环境的关键手段。它以相对较低的成本(以用户支付的处理费为例)提供了长久的废弃物处置服务,是现阶段不可或缺的废物管理方式。

6. The Insecurity of Debian (unix.foo)

文章摘要:《Debian的不安全性》

背景与争议

2023年6月,Red Hat更改了Red Hat Enterprise Linux (RHEL)源代码的分发方式,引发开源社区广泛争议,尤其影响了Rocky Linux、AlmaLinux等下游重建版本。此举促使部分用户计划迁移至Debian,以规避他们所认为的企业贪婪影响。然而,作者指出这种迁移忽视了一个关键问题:安全性

核心论点:Red Hat与Debian的安全实践差异

作者认为,Red Hat在安全性方面投入了大量资源,而Debian的默认安全配置存在不足。

Red Hat的SELinux实现

  • 深度集成与默认启用:Red Hat在RHEL中默认启用SELinux,并为其编写了全面的默认策略,覆盖了Apache、nginx、MariaDB、PostgreSQL、OpenSSH等常用服务。
  • 容器安全强化:Red Hat不仅支持无守护进程的容器工具Podman,还为容器应用了严格的SELinux策略,将容器与主机系统及其他容器隔离,有效缓解容器逃逸风险。
  • 透明的用户体验:尽管SELinux本身配置复杂,但Red Hat的默认策略使其对用户几乎透明,提供了“开箱即用”的安全保护。

Debian的AppArmor实现

  • 默认启用但配置薄弱:Debian从版本10开始默认启用AppArmor,但其默认配置存在缺陷:
    • 配置文件有限:仅提供少量AppArmor配置文件,许多关键服务未受保护。
    • 被动安全模型:依赖用户手动实施更严格策略,缺乏“默认安全”的设计。
    • 应用不一致:AppArmor策略的覆盖不系统,存在安全缺口。
  • 容器防护不足:Docker在Debian上自动生成的默认AppArmor配置过于宽松,允许广泛的网络、文件访问和权限,攻击面较大。

SELinux与AppArmor的根本区别

  • 访问控制模型
    • SELinux:采用基于类型的强制访问控制,为系统中的每个对象(文件、进程、端口等)分配标签(如容器的container_t类型),并结合多类别安全进行更精细的隔离。
    • AppArmor:基于路径的访问控制,通过配置文件限制特定程序的能力,模型更简单但粒度较粗。
  • 隔离强度:SELinux通过类型强制和MCS标签提供了更强大的隔离,能有效限制容器逃逸后的影响;AppArmor在默认配置下保护能力较弱。

结论

作者强调,选择Debian还是Red Hat不仅是社区与企业之争,更关乎安全理念:Red Hat系统倾向于预设威胁并提供防护,而Debian的默认配置更倾向于信任用户并依赖手动加固。在当今联网环境中,作者认为前一种“悲观”但主动防护的安全策略更为必要。

总结要点:文章批评Debian默认安全配置的不足,赞扬Red Hat通过深度集成和默认策略使SELinux与容器安全易用,指出两者在访问控制模型和防护实践上的根本差异,强调在网络安全威胁下“默认安全”的重要性。

7. Show HN: Using SQL's Turing completeness to build Tetris (github.com)

本文介绍了如何利用SQL的图灵完备性,通过PostgreSQL数据库完整实现俄罗斯方块游戏。其核心是运用递归通用表表达式(CTE)构建游戏主循环。

实现原理与架构

  • 游戏循环:利用递归CTE实现。非递归部分初始化状态,递归部分通过自引用在每帧读取输入、更新状态并渲染画面,同时使用 pg_sleep 控制帧率。
  • 输出渲染:由于递归CTE在执行完毕前不返回结果,项目使用 RAISE NOTICE 命令(通过一个PLpgSQL函数调用)将每一帧的游戏画面输出到psql客户端的标准输出。
  • 输入处理:SQL查询无法直接读取键盘输入。解决方案是创建一个 Input 表作为通信总线,用户通过独立的Python脚本 input.py 将按键写入该表。游戏查询利用PostgreSQL的 dblink 扩展在每轮迭代中从该表读取最新指令,解决了事务快照隔离导致无法看到新数据的问题。
  • 游戏状态:状态由一系列列维护,包括 board(用一维布尔数组表示棋盘,每行多一列用作边界碰撞检测)、pos(当前方块位置与旋转状态)、score 等。状态每帧根据重力或用户输入更新。
  • 游戏逻辑:包含碰撞检测(通过连接方块坐标与棋盘数组实现)、行消除(过滤被 true 填满的行)、硬降/影子方块计算(通过递归CTE计算最大下落行数)以及类似NES的下一方块随机生成算法。

使用与部署

  • 环境要求:PostgreSQL数据库(版本10至18)、安装了psycopg2的Python3,以及特定终端。
  • 快速部署:提供了使用Docker的完整步骤,可快速搭建包含数据库和依赖的环境。
  • 运行方式:需在两个终端分别运行 input.py(输入脚本)和通过psql执行 game.sql(游戏查询)。

资源与性能

  • 在60 FPS下CPU占用率较低(约4%单线程)。
  • 由于递归CTE会保留所有中间行,查询的内存和磁盘占用会随游戏时间持续增长,可能导致长时间游戏后内存溢出。作者指出,这可视为对原版NES俄罗斯方块也可能在长局后崩溃的一种“致敬”。
9. Interviewing Tim Sweeney and Neal Stephenson (www.matthewball.co)
# 采访蒂姆·斯威尼与尼尔·斯蒂芬森:关于元宇宙的对话

本文是对Epic Games创始人兼CEO蒂姆·斯威尼(Tim Sweeney)和畅销书作家、区块链初创公司Lamina1联合创始人尼尔·斯蒂芬森(Neal Stephenson)的采访总结。讨论围绕他们对元宇宙的定义、技术前景、行业争议及未来展望展开。

## 核心观点

### 1. 元宇宙的定义
- **尼尔·斯蒂芬森**:元宇宙是一个大规模多人在线、具有空间感的宇宙,其中体验分布在整个空间中,所有用户以相同方式感知。用户可以在其中移动、互动,且不受单一实体控制,由众多创作者共同构建。
- **蒂姆·斯威尼**:游戏长期以来正朝着斯蒂芬森所描述的方向演进,Epic Games及其产品(如《堡垒之夜》)体现了元宇宙的精神。

### 2. 硬件设备(如VR/AR眼镜)的角色
- 两人均认为,当前的屏幕设备已足以体验元宇宙的许多核心要素。硬件升级会提升体验,但并非必要条件。
- **斯蒂芬森**指出,《雪崩》出版后不久发行的游戏《毁灭战士》就在平面屏幕上创造了沉浸式3D环境体验,证明了立体视觉(如VR眼镜)并非绝对必需。大脑能通过多种线索感知三维空间。
- **斯威尼**强调,用户体验的限制并非硬件,而是当前软件和网络的能力。

### 3. “元宇宙已死”的论调
- **斯威尼**:被拒绝的是某些拙劣的元宇宙愿景(如在VR中办公),而非元宇宙理念本身。像《堡垒之夜》、Roblox等平台每月吸引约8亿用户进行社交化的实时3D体验,这实质上就是元宇宙的体现,并且正在强劲增长。
- **斯蒂芬森**:元宇宙概念并非天生反乌托邦。《雪崩》中的元宇宙只是个通讯媒介,被不同人以不同方式使用,既有低质广告内容,也有精心构建的美丽环境和知识库。

### 4. Facebook更名为Meta的反应
- **斯蒂芬森**:当时收到朋友“为你的损失感到遗憾”的短信,经搜索才明白原委。随后众多公司跟风宣称自己是元宇宙公司,他对此持幽默态度,并试图利用这股热潮创造可持续的事业(如共同创立Lamina1)。

### 5. 区块链技术
- 两人对区块链的看法均较审慎,认为其底层技术(加密、分布式共识)优秀,但被金融投机和骗局所拖累。
- **斯蒂芬森**:Lamina1旨在为开放元宇宙构建基础设施,专注于帮助创作者构建、获酬和建立可追溯的知识产权所有权。
- **斯威尼**:未来元宇宙必须建立在开放协议、标准和互操作性上。他构想了一个跨平台(如《堡垒之夜》、Roblox)的开放经济模型,通过收益分享实现互联互通,这对所有参与者都有利。

### 6. 生成式AI的伦理与影响
- 两人均强调,AI训练必须获得数据所有者的明确许可(研究机构除外),反对当前一些公司的“狂野西部”式做法。
- **斯威尼**认为,AI将大幅提高游戏开发的生产力(如快速生成定制化资产),最终将创造更大、更好的游戏,扩大就业和行业规模,但相关技术(如3D生成)的成熟需要多年研发。
- **斯蒂芬森**的Whenere项目使用公有领域资料来训练AI角色,以避免IP争议。

### 7. Epic Games对元宇宙的长期愿景
- **斯威尼**透露,Epic的元宇宙野心可追溯至1980年代的多用户地牢游戏(MUDs)。《堡垒之夜》当前形态(如分片岛屿、100人限制)是技术限制的临时方案。
- **未来目标**:
  - **Unreal Engine 6**:将改进网络模型,实现服务器间通信,支持数百万乃至十亿并发玩家的无缝大世界。
  - **互操作性**:希望不同创作者的代码、资产和经济系统能跨平台、跨游戏自由交互。
  - **开放经济**:设想一个连接《堡垒之夜》、其他游戏和平台的统一经济,用户购买的物品可在多场景使用。

### 8. 关于苹果及其诉讼
- **斯威尼**强烈批评苹果和谷歌的垄断行为,认为它们通过高额抽成和限制性规则阻碍了元宇宙的发展,阻止了Web应用的进步和全新软件类别的出现。他认为,在这些平台的控制下,真正的元宇宙无法存在。

### 9. 趣闻与未来计划
- **游戏角色选择**:斯蒂芬森选择“银影侠”是出于对漫画角色的喜爱;斯威尼选择“水母”角色,是为了在游戏中显眼,避免因击败自己公司的客户而感到内疚。
- **元宇宙的称呼**:两人均希望未来能继续使用“元宇宙”这一术语,而非被某个公司品牌所取代。
- **斯蒂芬森的新书**:将于10月出版的历史小说《Polostan》,讲述1930-1940年代科学与物理学发展的故事,是系列小说的开端。

## 总结
此次采访揭示了两位行业领袖对元宇宙的深刻见解:它是一个由开放、互操作的虚拟世界构成的、持续发展的社会空间,其成功依赖于技术进步、开放的经济模式以及对创作者与用户权利的尊重,而非任何单一公司的封闭愿景。
10. Why I self host my servers and what I've recently learned (chollinger.com)

核心主旨

本文作者分享了全面自托管个人服务器的原因、基础架构,以及近半年来在排障和探索新技术中积累的经验。作者强调,自托管不仅是对抗“万物皆订阅”商业模式、保持数字独立性的有效手段,更是软件工程师深入理解复杂分布式系统和底层技术的绝佳实践。

自托管架构与原因

  • 基础架构:作者在家运行3节点Proxmox集群(部署了PiHole、TrueNAS、Gitea、Jellyfin等服务),并结合外部VPS托管Nextcloud、个人网站等。
  • 核心动机:一是追求独立,摆脱大型科技公司的订阅制控制;二是促进技术学习,通过亲手维护基础设施,提升对网络、存储、高可用性及分布式系统的底层认知,从而反哺日常的软件开发与架构设计工作。

关键技术经验与教训

在近半年的维护中,作者总结了以下技术细节与避坑指南:

  • 硬件与电源:消费级UPS电池寿命通常仅约3年,需定期测试以防断电失效;服务器定时崩溃往往源于老旧硬盘的物理故障,更换硬盘即可解决。
  • 集群与系统优化:可通过非官方仓库在ARM架构的树莓派上运行Proxmox,以低成本凑齐3节点集群满足仲裁要求;Proxmox中ZFS默认会占用大量内存,极易导致虚拟机OOM(内存溢出),需通过修改内核参数手动限制ZFS ARC缓存大小。
  • 网络与监控:利用RouterOS和双Pi-Hole配置实现DNS冗余,消除单点故障;采用LibreNMS结合SNMPv3协议,可实现免费且深度的网络拓扑与设备监控。
  • 开发与安全工具:可通过 code-server 自托管基于浏览器的VS Code,方便在移动设备上开发;推荐使用 CrowdSec 替代传统的 fail2ban,其性能更强且支持社区共享威胁情报。
  • 云存储与VPS选择:不要盲目信任廉价VPS供应商,迁移至Hetzner后性能与稳定性显著提升;CIFS协议挂载远程存储速度较慢;对象存储(如Wasabi)虽成本低廉,但在处理大量小文件时性能极差,无法完全替代本地文件系统。

结论

作者强烈建议软件工程师尝试自托管。这种实践能帮助开发者掌握日常工作中难以接触到的底层基础设施知识,提升解决复杂系统问题的能力,同时获得对个人数据和数字生活的掌控权。

11. Small asteroid to hit Earth's atmosphere today (earthsky.org)

小行星2024 RW1进入地球大气层事件概述

事件详情

  • 时间:2024年9月5日凌晨约0:39(菲律宾时间),即协调世界时9月4日16:39左右。
  • 地点:菲律宾卡加延省拉尔洛上空。
  • 小行星特征:直径约3英尺(1米),国际编号2024 RW1,由亚利桑那州卡特林那巡天系统的Jacqueline Fazekas在撞击前约8小时发现,临时编号为CAQTDL2。
  • 影响:安全撞击大气层,未造成地面损害。燃烧时形成炫目的绿色火球,并可能有少量陨石到达地面。

发现与预警

  • 这是人类历史上第九次在小行星撞击前发现并追踪它。
  • 美国NASA行星防御协调办公室和欧洲航天局(ESA)均提前发布预警。ESA指出,附近热带风暴雅吉可能影响观测。
  • 此次提前发现被视为行星防御能力提升的重要标志,展示了近地天体监测的进步。

公众反应与科学价值

  • 数百名菲律宾居民目睹并拍摄了火球穿过天空、爆炸的壮观景象,相关视频在社交媒体广泛传播。
  • 国际流星组织指出,此次事件主要亮点为大型火球及潜在的陨石回收机会,具有显著科学价值,并呼吁目击者提交观测数据。

总结

小行星2024 RW1无害进入大气层,其提前发现体现了行星防御体系的有效性。事件引发广泛关注,为科学研究提供了宝贵资料。

12. Judge stops FTC from enforcing ban on non-compete agreements (www.computerworld.com)

法院阻止联邦贸易委员会执行竞业禁止协议禁令

美国联邦贸易委员会原定于9月4日生效的全面禁止竞业禁止协议的规定被达拉斯联邦地区法院法官阿达·布朗叫停。法官认为,FTC此举“超出了其法定权限”、“武断且反复无常”,并会给企业带来“不可挽回的伤害”。

禁令的预期影响与现状

该禁令若能实施,预计在未来十年内可增加工人收入至少4000亿美元,影响约3000万美国工人。然而,随着禁令被阻止,企业和员工在竞业禁止协议的命运上重新陷入不确定状态。

竞业禁止协议的争议

  • 支持禁令的理由:文章作者从个人经历出发,认为竞业禁止协议限制了员工自由流动、压低了工资。这类协议不仅困扰科技和创意行业从业者,也包括发型师、清洁工、保安和快餐工人等众多职业。
  • 反对禁令的论点:法官支持了保守派关于联邦机构权力受限的法律观点,指出应由国会或各州,而非联邦机构来规范此类协议。

更广泛的法律背景

这一裁决与2024年美国最高法院在“洛珀·布莱特”案中推翻1984年“雪佛龙原则”的判决有关。雪佛龙原则曾要求联邦法院尊重相关机构对模糊法律的合理解释。该原则被推翻后,解释模糊联邦法规的权力更多地转移到了联邦法院手中,而非像FTC这样的专业机构。

未来展望

  • FTC对此裁决不满,预计将提起上诉,但对最高法院的最终结果不乐观。
  • FTC表示将继续通过个案执法来处理竞业禁止协议问题。
  • 企业预计将继续使用竞业禁止协议,直至FTC或法院采取更强制的行动。

文章最后指出,竞业禁止协议与“随意雇佣”法律类似,将权力过度集中在雇主手中。作者认为工人应有权争取最优的劳动条件和一定的工作保障,但就目前美国的情况来看,这一愿望实现起来困难重重。

13. How does cosine similarity work? (tomhazledine.com)

核心概念:向量与嵌入

在大语言模型(LLM)中,“嵌入”(embedding)和“向量”(vector)通常互换使用。向量本质上是一个数字数组,用于表示文本的语义信息。例如,1536维的嵌入即为包含1536个数值的向量。

余弦相似度的原理

余弦相似度通过计算两个向量之间的夹角余弦值来衡量相似性,结果范围在 -1 到 1 之间:

  • 1:方向完全相同。
  • 0:相互正交(垂直)。
  • -1:方向完全相反。 该方法仅关注向量的方向(夹角),而忽略向量的长度(模长)。即使长度不同,只要方向一致,相似度仍为 1。

数学公式解析

余弦相似度公式为:$\cos(\theta) = \frac{A \cdot B}{||A|| \times ||B||}$

  • 点积($A \cdot B$):两个向量对应元素相乘后的总和。
  • 模长($||A||$ 和 $||B||$):向量各元素平方和的平方根,代表向量的几何长度。
  • 归一化作用:虽然比较时忽略长度,但公式通过除以模长的乘积来归一化点积,确保相似度度量独立于向量的绝对长度。

JavaScript 代码实现要点

在 JavaScript 中实现该公式时,结构与关键功能如下:

  1. 基础计算:使用 reduce 方法分别计算两个向量的点积以及各自的模长。
  2. 安全机制:加入除零保护逻辑(当模长乘积为 0 时直接返回 0),防止程序崩溃。
  3. 性能优化(不使用 Math.cos():代码直接通过代数公式计算余弦值,无需先使用反三角函数(如 Math.acos())求出具体角度再求余弦。这避免了不必要的计算,显著提升了执行效率。

在 LLM 嵌入中的适用性

余弦相似度是比对 LLM 嵌入的首选方法,核心原因包括:

  1. 语义由方向决定:在嵌入空间中,向量的方向代表文本的“意义”。方向一致的嵌入意味着模型认为它们具有相同的语义。
  2. 高维计算高效:算法逻辑简单且计算成本低,非常适合处理包含数千维度的复杂嵌入向量。

替代方案

除了余弦相似度,向量比较还存在欧几里得距离、曼哈顿距离和切比雪夫距离等替代方法,它们在不同的数学机制下衡量向量间的差异。

14. Physics is unreasonably good at creating new math (nautil.us)

物理学在创造新数学方面具有非凡的有效性

数学长期以来是物理学进步的基础。但近年来,趋势发生了逆转:物理学的见解和直觉正出人意料地引领数学取得突破。数学家们越来越多地从自然界的规律和模式中寻找灵感,使得长期停滞的领域取得进展。

历史渊源与分离

数学的起源与解决物理世界问题密切相关(如苏美尔人的计量系统)。历史上,物理学多次推动数学发展,例如阿基米德从力学原理中推导数学定理,牛顿在研究运动时发明了微积分。然而,20世纪中叶,两者分道扬镳:以布尔巴基学派为代表的数学家追求极致的严谨和抽象化,而物理学家(如发展标准模型)则将数学仅视为工具。

现代融合与突破

数学家迈克尔·阿蒂亚率先倡导数学与物理学的重新互动。他与数学物理学家爱德华·威滕等人的合作,开辟了新途径。弦理论成为新数学的重要来源,它并非最终的物理理论,却为抽象数学领域(如代数几何和拓扑学)带来了深刻见解。

  • 具体案例:物理学家菲利普·坎德拉斯等人利用弦理论工具,解决了枚举几何中关于“卡拉比-丘流形”上曲线计数的难题,意外连接了辛几何与复几何这两个看似无关的领域。
  • 对偶性:弦理论揭示了不同数学结构之间意外的“对偶性”关系,持续为数学家提供新结构。例如,在研究K3曲面时,发现了其同伦群与马蒂厄24群之间出人意料的联系,连接了拓扑学与群论。

为何物理学能有效推动数学?

  1. 方法论差异:物理学家更注重直观和探索,不拘泥于严格证明,能更快地勘测未知的数学领域;数学家则随后进行严格论证。
  2. “坏”物理催生“好”数学:如开尔文的“涡旋原子理论”虽被证伪,但其相关的纽结理论却成为富有成果的数学领域并有实际应用。
  3. 进化与认知:阿蒂亚认为,人类大脑为解决物理问题而进化,因此演化出欣赏和认识自然界中数学模式的能力,来自物理的数学往往更契合我们的认知直觉。
  4. 哲学探讨:哲学家丹尼耶莱·莫利尼尼提出,某些物理定律(如守恒定律)可能具有如同数学定理般的“必然性”,这解释了为何物理学能可靠地导向深刻数学。另一种观点(如马克斯·泰格马克的数学宇宙假说)认为,宇宙根本上就是由数学构成的。

未来展望

物理学与数学的合作正在加强。朗兰兹纲领(常被称为“数学的大统一理论”)的几何部分证明,就关键依赖了共形场论(物理学分支)的洞见。在攻克黎曼猜想BSD猜想等重大数学难题时,物理直觉可能至关重要。

总结而言,物理学通过提供新的视角、灵感和具体的数学结构,不断为数学注入活力。两者的界限正变得模糊,如同牛顿和高斯时代那样,未来解决重大科学问题将越来越依赖两个领域的深度融合。

15. Llms.txt (llmstxt.org)

llms.txt 规范概述

背景与目的

大型语言模型在访问网站信息时面临两大挑战:1)上下文窗口容量有限,难以一次性处理整个网站;2)将包含导航、广告和JavaScript的复杂HTML页面转换为LLM友好的纯文本既困难又不精确。网站通常同时服务于人类读者和LLM,但后者能从更简洁、专业的聚合信息中受益,尤其是在需要快速访问编程文档和API等场景中。

核心提案

我们提议在网站根目录添加一个 /llms.txt Markdown文件,为LLM提供友好内容。该文件简要介绍项目背景、提供指引并链接到详细的Markdown文档。llms.txt既可被人类和LLM阅读,也因其精确格式支持传统编程技术(如解析器、正则表达式)进行固定处理。

此外,建议网站中可能对LLM有用的页面,在原始URL后附加.md(无文件名的URL则附加index.html.md),提供该页面的干净Markdown版本。

该提案不强制规定如何处理llms.txt文件,具体取决于应用需求。例如,FastHTML项目将其自动扩展为两个适合Claude等LLM使用的XML结构Markdown文件:llms-ctx.txt(不含可选URL)和llms-ctx-full.txt(包含可选URL)。

文件格式规范

llms.txt文件位于网站根路径(或可选子路径),采用Markdown格式,结构如下:

  1. H1 标题:项目或网站名称(唯一必需部分)。
  2. 引用块:项目简短摘要,包含理解文件内容的关键信息。
  3. 零或多个Markdown段落(如段落、列表等,非标题):关于项目的更详细信息及文件解读说明。
  4. 零或多个H2标题分隔的Markdown部分:包含“文件列表”,即指向更多详细信息的URL列表。

每个“文件列表”是一个Markdown列表,包含必需的[名称](URL)超链接,后可跟:和文件说明。

示例结构

# 标题
> 可选描述
可选详细信息
## 部分名称
- [链接标题](https://链接URL):可选链接说明
## Optional
- [链接标题](https://链接URL)

其中“Optional”部分具有特殊含义:若包含,其下URL在需要更短上下文时可跳过,适用于常可省略的次要信息。

与现有标准的关系

llms.txt旨在与现有Web标准共存:

  • sitemap.xml:列出所有供搜索引擎索引的人类可读页面。llms.txt则提供面向LLM的精选概览,且通常包含LLM可读版本的页面链接和可能需要的外部资源链接,其内容经过筛选以适应LLM上下文窗口。
  • robots.txt:规范自动化工具对网站的访问权限(如爬虫)。llms.txt的信息通常按需使用(如用户寻求帮助时),主要服务于推理而非训练,但未来可能用于训练。

应用与工具

  • 目录网站llmstxt.sitedirectory.llmstxt.cloud 收录了可用的llms.txt文件。
  • 集成工具与插件
    • llms_txt2ctx:用于解析llms.txt并生成LLM上下文的CLI和Python模块。
    • JavaScript实现示例。
    • vitepress-plugin-llms:为VitePress网站自动生成LLM友好文档。
    • docusaurus-plugin-llms:为Docusaurus网站生成LLM友好文档。
    • Drupal LLM Support:为Drupal 10.3+站点提供完整支持。
    • llms-txt-php:用于读写llms.txt的PHP库。
    • VS Code PagePilot扩展:作为VS Code聊天参与者,自动加载外部上下文以提供增强响应。

最佳实践与下一步

创建有效的llms.txt文件建议:使用简洁清晰的语言;链接资源时附带简明描述;避免歧义术语或未解释的行话;使用工具将文件扩展为LLM上下文并测试LLM能否基于其回答问题。

该规范现开放社区讨论,在GitHub仓库进行版本控制和公开讨论,并设有Discord频道供分享实施经验和探讨最佳实践。

16. DAGitty – draw and analyze causal diagrams (dagitty.net)

DAGitty 项目总结

项目简介

DAGitty 是一个基于浏览器的环境,专门用于创建、编辑和分析因果图(即有向无环图 DAG 或因果贝叶斯网络)。其核心目的是帮助流行病学及其他学科的实证研究利用因果图来最小化研究偏差。

核心功能与工具

  • Web 环境:提供直观的在线界面,支持绘制、编辑和分析因果图。
  • R 语言包:提供名为 dagitty 的 R 包,可通过 CRAN 和 GitHub 获取,便于在数据分析和统计中集成。
  • 高级算法:内置多种因果推断算法,涵盖调整标准、祖先图中的分离集构建以及条件工具变量的高效查找。

开发、开源与许可

  • 开发团队:由 Johannes Textor 主导开发和维护,核心算法与 Maciej Liśkiewicz 和 Benito van der Zander 合作开发。
  • 开源协议:作为自由软件,采用 GNU 通用公共许可证(GPL)发布,允许用户自由复制、分发和修改。
  • 代码与反馈:源代码托管于 GitHub,用户可通过 GitHub、Mastodon 或电子邮件提交错误报告、功能请求及参与代码贡献。
  • 赞助支持:项目曾获得利兹数据分析研究所和德国研究基金会(DFG)的资助。

学术背景与引用

在科学研究中使用 DAGitty 时,官方建议引用其 2016 年发表于《International Journal of Epidemiology》的核心论文。此外,其底层算法的详细理论支撑来源于多篇发表在 UAI、IJCAI 和 AAAI 等人工智能顶级会议上的学术论文。

相关软件生态

因果推断领域有丰富的相关工具,DAGitty 推荐了以下生态软件:

  • ggdag:基于 dagitty 且兼容 tidyverse 的 R 包,提供更优的绘图功能。
  • shinydag:用于可视化 DAG 并导出出版级格式的 GUI 工具。
  • 其他工具:包括 TETRAD、dagR、daggle(用于练习协变量选择规则的 Shiny 应用)以及用于渲染 dagitty 模型的 JupyterLab 扩展等。

关键版本演进

  • v3.1 (2023-07):新增选择变量(selection variables)功能。
  • v3.0 (2020-01):全面重构用户界面,支持移动端和触摸屏操作。
  • v2.3 (2015-08):引入工具变量(instrumental variables)功能。
  • 早期版本:陆续加入了类似结构方程模型(SEM)的绘图风格、DAG 在线分享功能,以及可嵌入网页的交互式教程(如 d-分离教程)。
  • 基础设施:2023 年 10 月,项目迁移至全新的 Web 服务器。
17. Zen, CUDA, and Tensor Cores, Part I: The Silicon (www.computerenhance.com)

本文是探讨现代计算核心设计的系列文章第一部分,主要从物理芯片层面比较CPU(以AMD Zen 4核心为例)与GPU(以NVIDIA CUDA/Tensor核心为例)的结构差异。

核心发现:

  1. 宏观布局相似:尽管尺寸差异巨大(GPU芯片面积约为CPU核心复合芯片的9倍),但两者顶层结构相似——均由重复的模块组成,中央区域用于共享缓存等资源。
  2. 核心查找过程
    • CPU (Zen 4):相对容易找到。在核心复合芯片上,每个重复的模块即为一个完整的Zen 4核心,面积约3.8mm²,包含专用L2缓存。
    • GPU (CUDA/Tensor):结构层级更复杂,需逐层剖析:
      • 顶层为图形处理集群,面积远大于Zen 4核心。
      • 其内部分解为纹理处理集群,单个TPC面积与一个Zen 4核心接近。
      • TPC进一步分为两个流式多处理器
      • 在SM内部,仅能识别出存储单元约占30%的面积,剩余70%包含调度器、加载/存储单元、特殊功能单元以及目标CUDA和Tensor核心。受制于芯片图像分辨率,无法直接看到这些核心,只能基于已知数量(每个SM含128个CUDA核心和4个Tensor核心)进行面积估算。
  3. 核心尺寸估算:通过假设合理比例估算,CUDA核心极小(约0.003mm²),Tensor核心也较小(约0.04mm²)。上界估算表明,CUDA核心必然远小于0.007mm²,Tensor核心远小于0.22mm²。结论是Tensor核心尺寸远小于一个Zen 4 CPU核心,而CUDA核心更小
  4. 物理核心数量差异:芯片上实际存在的物理核心数多于产品规格标称的启用数。
    • CPU (Ryzen 5 7600):芯片物理上有8个Zen 4核心,但因制造缺陷和良率筛选,仅启用6个。
    • GPU (RTX 4090):芯片物理上有18432个CUDA核心和576个Tensor核心,但仅分别启用16384个和512个。这是通过禁用部分流式多处理器实现的,原因可能与巨大的芯片尺寸、缺陷分布及产品策略有关。

总结: 本文通过芯片剖析直观展示了CPU与GPU“核心”的本质区别:一个CPU核心是一个功能完备、结构复杂的大型处理单元;而GPU的“核心”(CUDA/Tensor)则是高度专业化、体积极小的计算单元,被层层封装在更大的集群结构中。这种物理结构差异直接反映了两者设计哲学的根本不同,并为后续探讨其执行模型奠定了基础。

18. Mondragon as the new city-state (www.elysian.press)

蒙德拉贡:新型城市国家

概述

蒙德拉贡是全球最大的工人合作社联合体,由92家合作社组成,涵盖工业、金融、零售和教育领域,年营收达110亿欧元,拥有超过70,500名工人。这些合作社由工人民主拥有和经营,工人选举领导层并在合作社盈利时分享利润。其结构类似一个由多个“城市国家”组成的联邦国家,被科幻作家视为乌托邦社会的模型。

历史起源

  • 创始人:1941年,天主教神父何塞·玛丽亚·阿里兹门迪亚里埃塔(26岁)被派往西班牙巴斯克地区的阿拉萨特-蒙德拉贡教区,当时该地区因内战后经济萧条、失业率高企而陷入困境。
  • 发展:他通过建立员工所有的企业解决就业问题,逐步发展为包括大学(培训企业家)、银行(资助创业)、制造公司、住房公司和幼儿园在内的网络。合作社基于社区需求创立,并由工人所有。
  • 扩张:从阿尔托德巴地区扩展到七个城市,生活完全“合作社化”——工作、消费、教育、养老等均与合作社相关。

组织结构与运作

  • 联邦结构:合作社隶属于部门(如汽车零部件部),部门又隶属于蒙德拉贡集团。
  • 利润分配
    • 合作社将14-40%的毛利润上交部门,14%上交集团。
    • 净利润分配:60%再投资、30%分给员工、10%捐赠社区。
  • 民主管理
    • 工人(全体大会)每年开会审议管理、分配利润并批准账目。
    • 选举董事会(管理委员会),董事会任命总经理(总干事),总经理组建执行团队。
    • 领导任期四年,可连任;表现不佳可被免职。
  • 自给自足体系
    • 建立自有社会保障(拉贡阿罗),提供养老金、残疾服务和医疗保健。
    • 经济危机时通过内部岗位调动和再培训保障就业,避免裁员。
  • 收入平等:最高薪与最低薪比例仅为6:1,基尼系数接近瑞典等北欧国家。

经济与社会影响

  • 区域繁荣:阿尔托德巴地区人均收入高于巴斯克平均水平,且更平等。
  • 全球竞争力:产品涵盖汽车、航空航天、轨道交通、可再生能源等领域,服务覆盖150个国家。
  • 员工激励:工人通过投资(最高16,000欧元)成为会员,享受利润分红(历史年利率7.5%),并可在不同合作社间流动以追求职业发展。

挑战与复制难题

  • 文化障碍:蒙德拉贡模式强调集体主义,难以吸引崇尚个人主义和高薪的“顶尖人才”。
  • 系统复制:需要建立合作社网络而非单一企业,才能实现规模效应和社会服务功能;全球工人所有制仅占0.33%,网络化合作社更稀少。
  • 知识传播不足:相关信息缺乏系统化公开,主要依赖学术期刊和内部资料。

作为资本主义替代方案

  • 解决不平等:蒙德拉贡证明了民主管理、利润共享的模式可降低贫富差距,提供就业保障、医疗和教育。
  • 进化而非革命:不否定资本主义,而是通过扩大所有者范围、优化财富分配来完善它。
  • 全球扩展:尽管面临挑战,美国、加拿大、英国已通过政策鼓励员工所有制,南非也实现了多家企业的所有权转移。
  • 未来愿景:科幻作品和学者设想以蒙德拉贡为蓝本构建“合作社城邦”,逐步淡化传统政府职能,使其专注于基础设施和国防等核心领域。

结论

蒙德拉贡提供了一个成功的、可操作的“成熟资本主义”蓝图,通过将工人转化为所有者、民主治理和利润再投资,实现经济增长与社会公平的统一。虽然全球复制需要系统性努力,但它为应对不平等、重塑经济模式提供了切实可行的方向。

19. LSP: The Good, the Bad, and the Ugly (www.michaelpj.com)

LSP协议设计评价:优点、缺点与丑陋之处

本文作者基于开发Haskell Language Server (HLS) 的经验,对语言服务器协议(LSP)的架构与设计进行了深度剖析。尽管LSP极大地改善了开发体验,但其协议设计仍存在诸多值得探讨的问题。

优点 (The Good)

  • 解决核心痛点:LSP成功且普及,大幅降低了为各类编辑器提供IDE级语言支持的开发成本。
  • 侧重展示而非语义:优先关注编辑器中的实际UI展示效果,而非各编程语言差异巨大的底层语义结构。
  • 向后兼容:严格的向后兼容性确保了旧版客户端和语言服务器的持续可用。
  • 机器可读规范:提供机器可读的类型和方法规范,极大减少了手动实现协议和JSON序列化的工作量与错误。
  • 动态注册:支持在运行时更改配置和服务器能力,设计理念良好。

丑陋之处 (The Ugly)

  • 缺乏开放治理:LSP并非真正的开源项目,规范更新主要由微软(VSCode团队)内部驱动,缺乏开放的社区讨论与决策机制。
  • 忽视并发与因果关系:规范对并发处理语焉不详,但协议实际高度依赖并发(如请求取消、进度跟踪)。同时,异步处理导致事件因果关系丢失,客户端难以确认获取的结果是否为最新状态。
  • 状态同步机制混乱:LSP大量核心功能本质是状态同步,但各功能在推拉模型、增量更新和依赖跟踪上的实现极不一致,作者建议未来引入通用的状态同步协议。

缺点 (The Bad)

  • 规范臃肿与历史包袱:规范极其庞大(包含90个方法和407个类型),且向后兼容保留了大量旧特性,增加了理解和实现的难度。
  • 类型定义模糊:受TypeScript影响,字段常存在缺失、空列表或null等多种空状态,语义不明确。
  • 规范不精确:对UI展示细节(如Code Lens的显示位置)缺乏明确规定,导致不同编辑器(如VSCode与Emacs)实现各异。
  • 其他设计缺陷:配置模型说明不清;文本编码错误地选择了UTF-16而非Unicode码位;代码操作(Code Actions)交互模型过于简单,缺乏多步操作支持;JSON-RPC的无确认通知机制加剧了因果关系的丢失。

总结

作者认为,除非能为终端用户带来显著提升,否则不建议仅为了减轻开发者负担而推出“LSP 2.0”进行大规模重构。当前最迫切的需求是推动LSP从单一公司主导,向真正开放的社区标准治理模式转型。

20. Show HN: Repaint – a WebGL based website builder (repaint.com)

Repaint 是一款基于 WebGL 的网站构建工具,主要通过 AI 技术帮助用户快速重建和设计网站。其主要功能和特点如下:

  • 跨平台导入:能够从任意平台导入现有网站内容,利用 AI 自动提取并重构网站。
  • AI 规划与编辑:用户只需描述想要保留、修改或删除的内容,Repaint 会自动处理后续工作;支持通过聊天对话直接编辑网站,无需编程知识。
  • 专业样式库:提供可定制的专业设计风格,能自动适配不同业务需求。
  • 高效省时:旨在通过 AI 简化网站创建流程,降低专业网站制作的时间和成本门槛。

定价方案

  • 免费版:支持发布到 Repaint 子域名,带有品牌标识,适合入门使用。
  • 高级版:每月 20 美元(年付可享 20% 折扣),提供专业网站功能,并支持按需购买额外额度。
21. How the Higgs field gives mass to elementary particles (www.quantamagazine.org)

希格斯场如何赋予基本粒子质量

文章驳斥了常见的错误类比(如将希格斯场描述为粘稠液体或糖浆,通过拖拽使粒子产生质量),指出这类说法违反了运动定律和相对论原理。实际上,希格斯场与运动或减速无关,其本质在于振动

核心解释

  • 量子场论基础:现代物理学认为宇宙中充满各种场(如电磁场、引力场),每种场对应一种粒子,粒子是该场的最小涟漪。
  • 质量与振动频率:根据量子场论与相对论,一个静止的粒子本质上是一个驻波,以其所属场的共振频率振动。质量与振动频率直接相关:振动频率越高,质量越大。
  • 希格斯场的作用:它像一个“宇宙增韧剂”。它通过一个恢复效应,改变了其他基本场的性质,为它们提供了非零的共振频率。
    • 一个简单的类比是钟摆:在没有引力的空间中,球不会振动;但在引力场中,它会以特定频率摆动。引力场提供了“恢复效应”,从而赋予了钟摆振动频率。
    • 同理,希格斯场为电子场等提供了“刚性”,使得它们能够拥有静止的涟漪(即静止粒子),并以特定频率振动,从而具有质量。没有希格斯场影响的场(如电磁场),其粒子(光子)只能以光速运动,没有静止质量。

结论与验证

这一机制由彼得·希格斯等人在1960年代提出。欧洲核子研究中心(CERN)对希格斯玻色子的实验观测,与基于标准模型数学框架做出的精确预测相符,确凿地证实了希格斯场通过这种“增韧”和提供恢复效应的方式赋予其他粒子质量。

因此,更准确的叙述是:随着宇宙冷却,希格斯场“开启”并达到非零强度,它改变了其他场的振动方式,为它们赋予了共振频率,从而使相应的粒子获得了质量。宇宙由此转变成了一个具有内在“音乐性”的量子系统。

22. LÖVR – A simple Lua framework for rapidly building VR experiences (github.com)

LÖVR 是一个简洁的 Lua 框架,用于快速构建 VR(虚拟现实)体验。它具有轻量、快速、开源的特点,旨在降低 VR 开发门槛,即使编程经验不多也能轻松创建 VR 场景。

主要特点:

  • 跨平台:支持 Windows、macOS、Linux 和 Android。
  • 跨设备:兼容 HTC Vive/Index、Oculus Rift/Quest、Windows MR 等多种 VR 设备,并内置 VR 模拟器。
  • 易于上手:只需几行 Lua 代码即可创建基础的 VR 场景。
  • 高性能:核心使用 C11 编写,结合 LuaJIT 脚本,并包含优化的单通道立体渲染。
  • 丰富的功能
    • 支持导入 glTF、OBJ 等 3D 模型及骨骼动画、HDR 纹理等资源。
    • 基于 HRTF 的音频空间化。
    • 内置高效的 3D 向量、四元数和矩阵运算库。
    • 包含 3D 刚体物理引擎(7 种碰撞体、网格碰撞体、6 种关节类型)。
    • 支持计算着色器,用于粒子等高性能 GPU 任务。

快速入门: 开发非常简单。从官网下载可执行文件,编写 main.lua 脚本并拖拽到该文件上即可运行。文章提供了几个示例:

  1. Hello World:在空间中显示文字。
  2. 旋转立方体:创建一个随时间旋转的立方体。
  3. 手部追踪:显示用户双手位置。
  4. 3D 模型加载:加载并绘制 glTF 模型。

构建与测试:

  • 可通过 CMake 从源代码构建。
  • 测试代码位于 test/lovr 目录,支持命令行运行全部或单个模块的测试。

相关资源:

  • 包含详细的文档、教程、API 参考和常见问题解答。
  • 提供 Matrix 社区供讨论和支持。
  • 有 Windows 平台的每日构建版本。
  • 受 2D 游戏框架 LÖVE 启发。

许可证: MIT 开源许可证。

23. Show HN: Hestus – AI Copilot for CAD (www.hestus.co)

Hestus:CAD 的 AI 智能助手 (AI Copilot)

产品概述

Hestus 是一款专为 CAD(计算机辅助设计)环境打造的 AI 自动完成工具。其核心理念是“减少点击,专注设计”,旨在通过自动化辅助大幅提升设计师的工作效率。

核心优势

  • 效率飞跃:设计速度提升 2.5 倍。
  • 操作极简:鼠标点击次数减少 4 倍。

关键功能

  • 智能预测 (Predicts Your Next Move):能够实时理解用户的设计意图,并准确预测下一步操作。
  • 一键建议 (One-Keystroke Suggestions):提供一键式快捷建议,帮助用户瞬间完成草图绘制与 finalize。
  • 原生集成 (Natively Integrated):直接无缝嵌入 CAD 软件内部运行,摒弃了繁琐的文本提示(Text prompts)交互方式。

早期访问

  • 演示视频中展示的部分 Beta 测试功能目前仅向特定用户开放。
  • 有意向的用户可通过官方联系方式申请加入优先列表(Priority list),以获取早期访问权限(Early access)。
24. Howm: Personal Wiki for Emacs (github.com)

GitHub 平台功能与资源概览

此页面展示了 GitHub 作为开发平台的核心功能、资源和支持选项,结构清晰分类,便于用户根据需求探索。

主要功能板块

  • AI 代码创建:包括 GitHub Copilot,提供 AI 辅助编码,以及 MCP Registry 用于集成外部工具。
  • 开发者工作流程
    • GitHub Actions:自动化任何工作流程。
    • Codespaces:提供即时开发环境。
    • Issues:用于计划和跟踪工作。
    • Code Review:管理代码变更。
  • 应用安全
    • GitHub Advanced Security:检测和修复漏洞。
    • 代码安全:在构建过程中保护代码。
    • 秘密保护:防止泄露。

探索与分类选项

  • 按公司大小:企业、中小型团队、初创公司、非营利组织。
  • 按用例:应用现代化、DevSecOps、DevOps、CI/CD。
  • 按行业:医疗保健、金融服务、制造业、政府。
  • 按主题:AI、软件开发、DevOps、安全。
  • 按类型:客户故事、网络研讨会、电子书、商业洞察。

支持与服务

  • 资源:文档、博客、更新日志、市场。
  • 支持:客户支持、社区论坛、信任中心、合作伙伴。
  • 社区计划:GitHub Sponsors(资助开源开发者)、Security Lab、维护者社区、加速器、GitHub Stars、存档计划。

企业解决方案

  • 企业平台:AI 驱动的开发者平台。
  • 附加服务:GitHub Advanced Security(企业级安全)、Copilot for Business(企业级 AI 功能)、Premium Support(24/7 高级支持)。
  • 定价:提供不同层级的解决方案。

页面交互元素

  • 用户操作:登录、注册、外观设置。
  • 搜索功能:保存搜索以便快速过滤结果。
  • 反馈机制:允许用户提交反馈并包含邮箱地址以便联系。

总结:GitHub 页面全面覆盖了开发工具、安全、自动化和协作功能,通过分类浏览和资源支持,满足不同规模和行业用户的需求。

25. LibrePythonista allows running IPython code in a LibreOffice spreadsheet (github.com)

LibrePythonista:LibreOffice Calc 中运行 Python 代码的扩展

LibrePythonista 是一个 LibreOffice Calc 扩展,允许用户在电子表格中直接运行交互式 Python 代码,将 Python 的数据分析能力集成到办公软件中。该扩展免费开源,目前处于测试阶段,所有代码在本地执行以保护数据隐私。

主要功能

  • 直接运行 Python 代码:在 Calc 单元格中通过代码编辑窗口输入并执行 Python 代码。
  • 支持核心 Python 库:内置 Pandas、Matplotlib、NumPy 等库,用于数据分析和可视化。
  • 内置包管理器:可通过 PIP 安装额外的 Python 包。
  • 数据处理与自动化:支持创建数据框(DataFrame)、系列(Series)、自定义图表,并可自动化 Calc 任务和创建自定义函数。
  • 本地执行:所有计算在用户本地计算机运行,数据不外传,增强隐私保护。
  • 使用 OOO Development Tools:简化 LibreOffice API 的交互。

使用方式

  • 插入 Python 代码:选择单元格后,通过菜单栏的“LibrePy”选项中的“Insert Python”,或使用快捷键 Shift+Ctl+Alt+L,或工具栏按钮插入。
  • lp() 函数:作为 Calc 与 Python 的接口,用于引用单元格、范围或命名范围。例如:
    • lp("A1") 引用单元格 A1。
    • lp("B1:C5") 引用范围 B1:C5。
    • lp("MyRange", headers=True) 引用命名范围 MyRange,并包含表头。
    • 支持 collapse=True 参数,自动排除范围末尾的空行,便于数据更新。
  • 示例df = lp("A2:D81", headers=True, collapse=True) 创建一个数据框。

代码编辑

  • 默认编辑器:通过右键菜单选择“Pythonista -> Edit Code”编辑 Python 单元格。
  • 实验性编辑器(版本 0.6.0 起):支持语法高亮和代码补全,需在扩展选项中启用“Use Experimental Python Cell Editor”,并重启 LibreOffice。

安全设置

  • 本地执行:代码仅在本地运行,不涉及外部服务器。
  • 宏安全控制:为防范未信任来源的风险,Python 代码仅在宏启用时运行。推荐将安全级别设置为“Medium”(路径:工具 -> 选项 -> LibreOffice -> 安全 -> 宏安全)。
  • 用户打开电子表格时,LibreOffice 会提示是否启用宏;若不启用,Python 代码将不会执行。

安装与卸载

安装问题解决

  • 若安装失败(如“Failed to register package”),需安装 libreoffice-script-provider-python 包。
  • 确保系统已安装 python3-pip,否则扩展无法启动。

卸载方法

  • LibreOffice 运行时卸载
    1. 打开扩展管理器,选择 LibrePythonista 扩展。
    2. 点击“选项”按钮,导航到 LibrePythonista -> Uninstall。
    3. 选择要卸载的包并点击“Uninstall”。
    4. 若卸载扩展本身,选择所有包并卸载,然后点击“Remove”移除扩展。
    • 注意:若扩展未移除,重启 LibreOffice 时可能重新安装已卸载的包。
  • LibreOffice 关闭时卸载(推荐)
    1. 通过扩展选项中的“Copy command”复制卸载命令。
    2. 卸载扩展并关闭 LibreOffice。
    3. 在终端(Windows 使用 PowerShell)中粘贴命令执行,将删除扩展安装的 Python 包。

其他资源

  • 提供 LibrePythonista 频道用于进一步支持。

该扩展通过将 Python 的强大功能融入 LibreOffice Calc,提升了电子表格的数据分析和自动化能力,同时注重本地执行和用户安全。

26. Writing a book in the age of open source (blog.incrementalforgetting.tech)

开源时代下的写作探索:工具选择与实践分享

写作动机与挑战

两位工程经理作者在撰写第一本面向有抱负工程经理的书籍时,发现写作任务远比预期更艰巨。他们希望优化写作流程,专注于内容本身,而非工具带来的障碍。

工具选择历程

  1. Microsoft Word:调研中最常见的选择,但因不符合“易用、免费、开源”标准而被放弃。
  2. Google Docs:访问方便但编辑体验不够流畅。
  3. Markdown:作为开发者熟悉的工具,满足免费、开源、易用条件,但缺乏书籍排版所需的高级功能(如索引、封面、前后辅文)。
  4. Asciidoc:最终选择。它结合了Markdown的简洁性,同时提供完整的书籍出版功能:
    • 支持自定义字体
    • 自动生成索引、封面、前后辅文
    • 通过Asciidoctor工具链实现高效出版流程
  5. LaTeX:虽然功能强大,但学习成本高、可访问性差,被排除。

写作环境配置

  • 硬件设备:强调符合人体工程学的设置:
    • ZSA Voyager分体键盘减少手指移动
    • HÅG Capisco活动座椅避免久坐僵硬
    • 合适的书桌支撑良好姿势
  • 开发环境:使用Neovim、Visual Studio Code等免费开源编辑器。

书籍结构设计

书籍通常包含三个部分:

  1. 前言部分:出版信息、献词、序言等
  2. 正文部分:按章节组织的核心内容
  3. 后记部分:作者简介、术语索引等

开源工具发布

作者将研究转化为开源项目 Letterpress

  • 提供DevContainer环境,无需本地安装
  • 包含书籍基础结构和GitHub工作流
  • 自动生成PDF和EPUB格式,适配各类自出版平台(Gumroad、Leanpub、Amazon KDP等)

写作价值总结

  1. 知识贡献:将个人智慧转化为可供他人学习的系统知识
  2. 深度学习:通过教学相长,真正掌握复杂概念
  3. 出版经济:参考Gregor Hohpe和Martin Kleppman等作者的经验,了解技术书籍出版的经济效益

结论

写作是积累人类知识的重要方式。借助合适的开源工具和系统方法,任何人都可以通过写作分享专业知识,为知识库做出贡献。

27. Solar will get too cheap to connect to the power grid (climate.benjames.io)

太阳能将便宜到无需并网:成本、饱和与未来应用

太阳能电池板成本正急速下降,将导致廉价电力涌入电网,但这仅仅是第一幕。我们不仅不会在电网接入极限处停止建设太阳能,反而会建造更多。本文将解释我们为何会持续建设,以及如何处理多余电力。

太阳能将变得极其便宜

太阳能电池板是将免费阳光转化为电力的魔法。作为一种无需活动部件的发电方式,它比其他能源更易于大规模制造。其生产类似于制造扁平硅基石(如半导体、玻璃),因此拥有极高的学习率——产量越大,成本越低。这导致太阳能部署以惊人速度增长:全球大部分太阳能发电装置是在过去30个月内安装的,仅中国2023年的新增装机量就超过美国历史总和。预计未来五年太阳能成本还将减半。

太阳能将使电网饱和

随着太阳能接入增多,电网接入将愈发困难,主要原因有二:

  1. 太阳能自我蚕食:所有太阳能电池板都在白天同时发电。大量接入会拉低阳光时段的电价,因为供给激增。最终,新增太阳能的边际收益会降低,甚至出现负电价(消费者用电反被付费,但发电商盈利困难)。这创造了将需求转移到可再生能源丰富时段的强大激励,例如电动汽车和电加热等灵活需求,这是当前整合可再生能源的首要任务。

  2. 电网容量限制:将新发电项目接入电网本身就很耗时。在英国,平均等待电网连接的时间超过5年,40%以上的排队项目连接日期在2030年之后。在美国,电网连接队列规模过去十年增长了7倍以上,其中95%是太阳能、风能和电池项目,排队容量已是现有全部发电厂装机容量的两倍多。

如何处理多余太阳能?

太阳能虽会饱和电网,但我们不会停止建设,而是转向离网应用。主要有两种方式:

1. 太阳能与储能结合

白天免费电力、随后几小时电价高企,这对锂离子电池是理想场景。太阳能装机越多,电池部署也将激增。然而,由于电网容量有限,无法将所有太阳能电力通过高压输电系统充入电池。因此,太阳能与储能必须实现本地化协同,例如:公用事业太阳能与储能共址、家庭为自家太阳能配储、在现有太阳能发电设施旁新建电池。尽管部分电力仍会流经本地配电网,但依赖新建输电线路吸收全部未来太阳能产能是不切实际的——输电线路建设昂贵且缓慢,而电池部署廉价且迅速。

2. 太阳能用于间歇性过程

更颠覆性的思路是顺应阳光节律,仅在日照期间使用能量。虽然这将利用率降至约25%,但无需配置电池,使得电力成本达到全球最低水平。间歇性太阳能如此廉价,足以改变一次能源供应格局,不仅能直接供电,更能通过操纵原子生产燃料:

  • 合成煤油(用于航空)
  • 清洁氨(用于肥料)
  • 清洁甲醇(用于航运)
  • 甚至合成天然气

这些合成燃料(如可持续航空燃料)都依赖绿氢作为基础原料。目前,生产绿氢成本极高,唯一具备成本竞争力的方式便是使用离网太阳能。同样,任何能优化为25%利用率、可承受间歇性运行的过程都将迎来机遇,例如直接空气捕获、工业加热、电化学工艺等。

离网应用还带来额外成本优势:若直接为直流应用供电,可省略逆变为交流电的效率损失;去除大部分平衡系统、电力电子设备和电网接入手续,能实现更快、更廉价的部署。

结论

“能否构建仅使用四分之一时间免费能源的工艺”是能源未来最重要且未被充分探索的问题之一。传统化学工程思维优化的是昂贵输入、连续输出和高效率。然而,针对低利用率、免费能源的设计空间正待开拓。尽管这具有挑战性(因为利用率低会严重影响资本密集型工艺的回报周期),但我们尚未真正尝试。一个不争的事实是:很少有人为间歇性太阳能优化,而间歇性太阳能将改变世界。

28. Boom Supersonic's XB-1 prototype aces 2nd test flight (www.space.com)

Boom Supersonic的XB-1原型机完成第二次试飞

飞行基本情况

2024年8月26日,Boom Supersonic公司的XB-1超音速验证机在加利福尼亚州莫哈维航空航天港进行了第二次试飞。飞行持续约15分钟,达到10,400英尺(3,170米)高度,最高时速277英里(446公里)。

本次测试成果

此次试飞首次成功测试了起落架的收放功能,并验证了新的数字稳定性增强系统,该系统有助于改善飞行操控性能。公司表示,这次飞行成功解决了首次试飞中发现的问题,为后续实现超音速飞行奠定了基础。

公司目标与项目进展

Boom Supersonic创始人兼CEO布莱克·肖尔表示,团队对这次飞行感到满意,并计划在未来继续推进飞行测试,目标是在年内实现超音速飞行。公司计划在XB-1项目中再进行约10次测试,逐步提升飞行速度。

项目背景

XB-1是Boom Supersonic旗舰项目“Overture”超音速客机研发过程中的重要组成部分。公司旨在通过该项目推动超音速客运旅行的回归,实现更快速、高效的航空运输。

29. The Fourier Uncertainty Principles [pdf] (2021) (math.uchicago.edu)

本文系统介绍了傅里叶不确定性原理,该原理表明一个非零函数及其傅里叶变换不能同时被任意精确地局部化。论文首先建立了必要的数学基础,随后推导并证明了核心的不确定性原理。

1. 数学基础

  • Lp空间性质:介绍了Lp范数、Lp空间的完备性,以及赫尔德不等式、明可夫斯基不等式、控制收敛定理等关键分析工具。通过修正的哈代不等式为后续证明做准备。
  • 傅里叶变换性质:定义了L1空间上的傅里叶变换,证明了其关键性质,包括导数转换为乘法的性质、傅里叶逆定理、卷积定理和帕塞瓦尔/普朗歇尔定理。这些性质是傅里叶分析的核心,并在信号处理中有应用,其中傅里叶变换将卷积运算对角化。

2. 不确定性原理的阐述与证明

  • 一般不确定性原理:通过伸缩变换性质直观说明,一个函数在时域/空间域上越“窄”,其频域上的傅里叶变换就越“宽”,反之亦然,这本质上是不确定性的一种表现。
  • 海森堡不确定性原理:这是论文的核心证明。该原理在量子力学中描述了位置和动量的测量不确定性关系。论文首先通过引理将位置和动量的方差与函数的导数和乘积联系起来,利用哈代不等式和傅里叶变换的导数性质,证明了对于平方可积函数,其位置方差与动量方差的乘积存在一个正的下界(σ²ₓσ²ₚ ≥ 1/4)。论文还指出,等号成立当且仅当函数是高斯函数的平移和调制形式。

3. 主要不确定性原理与推广

  • 介绍了一种更新、更灵活的证明框架,其基于傅里叶变换作为L¹到L∞的有界算子及酉算子的性质。论文展示了如何从一个基础的“主要不确定性原理”(涉及L¹范数和L∞范数的关系)出发,推导出范数不确定性原理,并最终再次证明海森堡不确定性原理。
  • 这种证明方法不依赖于具体的分析技巧(如分部积分),因此可以推广到傅里叶变换之外的其他算子(如量子力学中的位置和动量算子)。

总结:本文从数学分析的基础工具出发,逐步构建并证明了傅里叶不确定性原理的核心内容,特别是海森堡不确定性原理。论文不仅提供了基于经典分析方法的证明,还引入了基于算子理论的现代证明思路,展示了该原理的广泛适用性和深刻的数学内涵。

30. Navy chiefs conspired to get themselves illegal warship Wi-Fi (www.navytimes.com)

美国海军濒海战斗舰“曼彻斯特”号(金组)的高级士官们,在2023年部署期间,违反规定私下安装并使用了星链(Starlink)卫星Wi-Fi网络。这一行为由当时的指挥高级军士长格里塞尔·马雷罗牵头,整个军士长群体参与,构成了“犯罪阴谋”。

事件概述

  • 背景:海军舰艇在部署期间通常会因作战安全和带宽限制而严格限制互联网接入。
  • 违规行为:2023年4月舰艇部署前,马雷罗与同谋私自购买了一套星链高性能设备(花费2800美元),并在舰艇O-5甲板隐蔽安装了卫星天线。
  • 网络使用:他们建立了一个名为“STINKY”的Wi-Fi网络,仅限军士长群体使用,用于查看体育比分、发送短信和流媒体播放。普通水兵和军官均无法接入。
  • 费用分摊:使用者需支付月费62.5美元或一次性费用375美元,费用通过军士长协会的账户和借记卡支付星链账单。

安全风险与调查

  • 重大隐患:调查指出,未经授权的网络系统对任务、作战安全和信息安全构成严重风险,尤其是在中美关系紧张的西太平洋部署期间。
  • 保密与欺骗:马雷罗负责网络管理与密码分配。当舰长和执行官多次询问时,她多次否认网络存在,甚至伪造数据使用记录,将网络名称改为类似无线打印机的名称以作掩护。
  • 败露过程:2023年8月,海军信息战中心一名文职人员在舰上安装其他授权系统时,发现了秘密的星链天线。最终,马雷罗于8月26日向舰长承认并道歉。

责任认定与处分

  • 主要责任人:马雷罗因故意玩忽职守、提供虚假陈述及妨碍司法公正等罪名在军事法庭受审,被定罪并降级至E-7(上士)。她在2023年底已被解除职务。
  • 集体责任:调查认定整个军士长群体均知情或参与,或未举报违规行为,均需承担责任。超过15名涉案军士长和高级军士长受到了指挥官非司法处罚(上校审讯)。
  • 调查结论:调查强调,马雷罗的“恶劣不当行为”不可低估,尤其是在前任执行官被解职后舰长高度依赖她稳定指挥环境的情况下,她却蓄意隐瞒违规系统。
31. Firefox will consider a Rust implementation of JPEG-XL (github.com)

Firefox考虑使用Rust实现JPEG-XL解码器

Firefox团队与Google Research的JPEG-XL团队就该格式在Firefox中的未来进行了讨论。Firefox的主要顾虑是现有参考解码器(基于10万余行多线程C++代码)带来的攻击面扩大风险。

为解决此问题,Google团队同意运用其专业知识,用Rust语言构建一个安全、高效、轻量且兼容的JPEG-XL解码器,并将其集成到Firefox中。若该实现能满足性能要求并符合生产标准,Firefox将会搭载该解码器。

文章指出,若JPEG-XL未来成为通用的JPEG替代格式,其广泛应用可能导致内存安全漏洞。一个由原始团队开发、经过实战检验的Rust解码器将能显著降低此风险。因此,Firefox选择投入资源推动此方案实现。

32. OpenAI Pleads It Can't Make Money Without Using Copyrighted Materials for Free (futurism.com)

核心诉求与理由

OpenAI向英国议会上议院小组委员会提交文件,请求允许其使用受版权保护的作品训练人工智能模型。OpenAI主张,现代版权几乎涵盖所有人类表达形式(如博客、照片、代码等),仅依赖百年前的公共领域资料无法训练出满足当前需求的大型语言模型(LLM)。若不使用版权材料,其模型训练和数十亿美元的业务发展将“不可能”实现。

法律立场

OpenAI在文件中坚称其遵守版权法,并认为在法律层面上,现行版权法并不禁止使用受保护内容进行AI模型训练。

面临的诉讼与反对

OpenAI的立场遭到多方强烈反对,并面临多起重大侵权诉讼:

  • 《纽约时报》:近期起诉OpenAI及其主要投资者微软,指控其通过大规模侵犯版权、商业剥削和盗用知识产权来牟利。
  • 美国作家协会:代表多位知名作家(如乔治·R·R·马丁等)起诉OpenAI,反对其使用作家作品训练ChatGPT。原告律师指出,未经同意和补偿的复制行为严重威胁了作家的生计,且若不依赖版权作品,OpenAI的商业产品将大不相同。

合作前景与挑战

OpenAI表示正寻求与出版商建立新的合作关系。然而,外界普遍认为,要求所有新闻媒体、网站、出版社以及依赖版权谋生的独立作家全面接受其合作条款是不切实际的。

34. Show HN: Retronews – TUI for HN and Lobsters emulating classical Usenet readers (github.com)

Retronews 是一个用 Python 编写的文本用户界面工具,用于浏览 Hacker News 和 Lobsters 的讨论。其界面设计模仿了经典的 Usenet 和邮件阅读器(如 slrn 和 mutt),旨在提供怀旧的阅读体验,并通过单次显示一条消息的方式促进更专注、更慢速的阅读。

主要功能与特点:

  • 核心目的:方便用户高亮有趣的讨论线程,并跟踪已读/未读消息状态。
  • 依赖性:在类 Unix 系统上仅需 Python 3.9;在 Windows 上可能需要额外安装 windows-curses
  • 运行方式:无需安装,可通过 curl 下载脚本后直接使用 python3 运行。按下 ? 键可查看可用的快捷键绑定。

定制化: 用户可通过在 ~/.retronewsrc.py(或使用 --rcfile 指定路径)中编写有效的 Python 代码来自定义设置。示例包括:

  • 修改键绑定(如将 az 键分别绑定为“上一条”和“下一条”命令)。
  • 自定义颜色方案(如设置作者名称显示为红色)。

已知问题与限制

  • 该工具为只读,不支持投票或发帖功能。
  • 消息格式的显示偶尔不够完美,但通常能满足基本需求。
  • 检测线程中是否有未读回复的机制依赖回复计数,如果存在删除的回复则不够准确。

设计考量(为什么不做成 NNTP 网关): 作者指出,NNTP 协议不支持按标题浏览线程(或分页浏览),客户端需要预先获取所有可用消息的元数据。鉴于 HN 消息量巨大,将其同步到网关不切实际,且部分客户端难以处理单个新闻组中的海量消息。

相关项目

  • HN Search @ Algolia:用于检索消息的底层 API。
  • nntpit:面向 Reddit 的 NNTP 网关。
  • circumflex:另一个功能更丰富的 HN 文本用户界面工具。
36. Vue 3.5 released (blog.vuejs.org)

Vue 3.5 "Tengen Toppa Gurren Lagann" 发布

Vue 3.5 是一个次要版本,无破坏性变更,主要包含内部优化和实用新功能。

主要亮点

1. 反应性系统优化

  • 重大重构:实现了更好的性能和显著降低的内存占用(-56%),行为不变。
  • 解决问题:修复了 SSR 中计算值陈旧和内存泄漏问题。
  • 大型数组优化:对深度响应式大型数组的追踪速度提升最高可达 10 倍。

2. 响应式 Props 解构 (稳定)

  • 现已默认启用,<script setup> 中从 defineProps 解构的变量现在是响应式的。
  • 简化语法:可直接使用 JavaScript 原生默认值语法。
    • 之前:需使用 withDefaults 辅助函数。
    • 之后const { count = 0 } = defineProps<...>()
  • 注意:解构变量会被编译为 props.xxx,访问时自动追踪。但在 watch 或组合式函数中使用时,需包装为 getter(如 () => count)。

3. SSR 改进

  • 懒加载水合:异步组件可通过 defineAsyncComponenthydrate 选项控制水合时机(如 hydrateOnVisible())。
  • useId():生成在服务器端和客户端渲染间保持稳定的唯一 ID,用于表单和可访问性属性,避免水合不匹配。
  • data-allow-mismatch:属性,用于抑制客户端与服务端值不可避免的差异(如日期)导致的水合警告。

4. 自定义元素改进

  • 修复了 defineCustomElement() 的诸多问题,并增加了新功能:
    • 通过 configureApp 选项为自定义元素配置应用。
    • 新增 useHost()useShadowRoot()this.$host API。
    • 支持通过 shadowRoot: false 不使用 Shadow DOM 挂载。
    • 支持提供 nonce 选项,用于注入的 <style> 标签。

5. 其他重要功能

  • useTemplateRef():一种新的获取模板引用的方式,通过运行时字符串 ID 匹配,支持动态 ref 绑定。
  • 延迟传送门 (defer prop)<Teleport> 新增 defer 属性,使其在当前渲染循环后挂载,解决了目标元素须提前存在的限制。
  • onWatcherCleanup():全局 API,用于在侦听器中注册清理回调,例如用于中止陈旧的网络请求。

更完整的变更列表请查阅 GitHub 上的官方更新日志。

37. Goja: A Golang JavaScript Runtime (jtarchie.com)

Goja: Golang JavaScript 运行时

Goja 是一个 Go 生态系统中的 JavaScript 运行时库,专为在 Go 应用中嵌入 JavaScript 而设计。它在处理数据和暴露无需 Go 构建步骤的 SDK 方面具有独特优势,通过无缝集成 Go 结构体和方法,简化了 Go 与 JavaScript 之间的交互。

背景需求

作者在处理大型数据集和复杂 JSON 响应时,发现纯 Go 代码过于冗长。因此,寻求嵌入式脚本语言以简化任务。在评估 Lua、Expr、V8 和 Starlark 等选项后,Goja 因其优秀的集成能力脱颖而出。

核心优势

  • 无缝集成:Goja 自动推断 Go 结构体的字段和方法,使其在 JavaScript 中可直接访问,无需额外桥接层。它利用 Go 的反射机制,实现透明的交互。
  • 类型处理:Goja 能自动推断数据类型(如数组),但返回结果时需在 Go 中进行类型断言(例如,整数表示为 int64)。
  • 命名约定:通过 FieldNameMapper,支持 Go 驼峰命名与 JavaScript 驼峰命名的自动转换,例如将 GetAge 方法映射为 JavaScript 中的 getAge

关键功能示例

  1. 值操作:演示了将 Go 整数数组传递到 JavaScript,过滤偶数并返回结果。Goja 自动处理类型推断,但 Go 端需要类型断言来提取值。
  2. 结构体交互:展示 Go 结构体(包括未导出字段和方法)在 JavaScript 中的访问。例如,通过 person.GetAge() 调用未导出字段的 getter 方法。
  3. 异常处理:JavaScript 异常(如除零错误)通过 Go 错误处理管理,使用 *goja.Exception 等类型提供详细信息。支持多种异常类型,如 *goja.StackOverflowError*goja.CompilerSyntaxError
  4. VM 池与沙盒化:初始化 VM 耗时较长,使用 sync.Pool 重用 VM 以提高性能。但存在全局命名空间污染问题(如变量重复声明)。解决方案是将用户代码包装在匿名函数中执行(例如 (function() { userCode })()),避免全局冲突,并依赖垃圾回收清理。

总结

Goja 是一个强大的工具,适用于在 Go 应用中嵌入 JavaScript,特别适合数据操作和 SDK 暴露。通过示例和经验分享,作者展示了如何利用其特性高效处理任务,并解决集成中的挑战。

38. Show HN: Graphiti – LLM-Powered Temporal Knowledge Graphs (github.com)

Graphiti:基于LLM的时序知识图谱框架

Graphiti 是一个专为 AI 代理构建和查询时序上下文图的开源框架。它区别于静态知识图谱,能跟踪事实如何随时间演变,维护数据来源溯源,并支持预定义与学习型本体,使其适用于处理不断变化的真实世界数据。

核心概念:上下文图

上下文图是一个包含实体、关系和事实的时序图。每个事实(如“Kendra喜欢阿迪达斯鞋(截至2026年3月)”)都有一个有效期:它何时变为真,以及何时被取代。实体随时间演变并更新摘要。所有信息都可追溯到剧集——产生它的原始数据。

主要组成部分

  • 实体:随时间更新摘要的人、产品、政策、概念等。
  • 事实/关系:带有有效期的三元组(实体 → 关系 → 实体)。
  • 剧集:摄入的原始数据流,是所有衍生事实的溯源依据。
  • 自定义类型:通过 Pydantic 模型定义的实体和关系类型。

核心优势与对比

Graphiti 旨在解决传统 RAG(检索增强生成)方法在处理动态数据时的不足。

与传统 RAG 相比

  • 时序事实管理:事实被失效而非删除,可查询当前或历史任一时间点的真相。
  • 增量图构建:新数据实时集成,无需批量重新计算。
  • 混合检索:结合语义嵌入、关键词(BM25)和图遍历,实现低延迟、高精度查询。
  • 溯源性:每个事实都追溯到产生它的原始剧集。

与 GraphRAG 对比: Graphiti 专注于动态演化上下文,而非静态文档摘要。

  • 数据处理:支持持续、增量更新(GraphRAG 为批处理)。
  • 知识结构:构建带有时效性窗口和溯源的时序上下文图。
  • 检索方法:采用混合搜索,而非依赖 LLM 的顺序摘要。
  • 性能:通常支持亚秒级查询延迟。
  • 可扩展性:针对大数据集优化,扩展性高。

与 Zep 的关系

Graphiti 是 Zep 用于 AI 代理的上下文基础设施的核心开源时序上下文图引擎。

  • Graphiti:开源框架,用于构建和查询单个上下文图。
  • Zep:托管的上下文图基础设施,提供大规模治理、低延迟检索、开发者工具和企业级功能。适用于希望开箱即用、有企业支持的用户;Graphiti 则适合希望拥有灵活核心并自行构建外围系统的开发者。

安装与使用

基本要求:Python 3.10+,兼容的数据库(Neo4j 5.26、FalkorDB 1.1.2、Kuzu 0.11.2 或 Amazon Neptune),以及 OpenAI API 密钥(默认用于 LLM 推理和嵌入)。

安装

# 核心安装
pip install graphiti-core

# 按数据库支持安装(例如 FalkorDB)
pip install graphiti-core[falkordb]

# 按 LLM 提供商安装(例如 Anthropic)
pip install graphiti-core[anthropic]

数据库配置: 支持多种数据库后端,可通过自定义驱动程序实例化数据库连接,并传递给 Graphiti 构造函数。

# Neo4j 自定义数据库示例
from graphiti_core.driver.neo4j_driver import Neo4jDriver
driver = Neo4jDriver(uri="bolt://localhost:7687", user="neo4j", password="password", database="my_custom_database")
graphiti = Graphiti(graph_driver=driver)

支持其他 LLM 提供商

  • Azure OpenAI:使用 AsyncOpenAI 客户端配合 Azure v1 API 端点。
  • Google Gemini:配置 GeminiClientGeminiEmbedderGeminiRerankerClient
  • Ollama(本地 LLM):使用 OpenAIGenericClient 和本地模型。

其他信息

  • 遥测:收集匿名使用统计数据以改进框架,绝不收集个人信息、API 密钥或用户数据。可通过环境变量 GRAPHITI_TELEMETRY_ENABLED=false 禁用。
  • 快速开始:提供示例展示如何连接数据库、添加剧集、执行混合搜索等。
  • 部署:支持通过 Docker Compose 快速启动数据库服务。提供 MCP 服务器和 REST API 服务以便集成。
  • 贡献与支持:欢迎通过代码、文档等方式贡献,可在 Discord 的 #Graphiti 频道获取支持。
39. Layoffs at Fly.io (twitter.com)

用户在访问 x.com 时遇到错误。系统提示无需担心,并建议重试。原因是隐私相关扩展可能导致问题,用户应禁用这些扩展后再次尝试访问。