约翰·阿迪生（1930-2026）是加州大学伯克利分校一位极具影响力的逻辑学教授，也是本文作者敬爱的博士导师。作者1966年进入伯克利大学，没有正规的逻辑学背景，却立刻被阿迪生精确而优雅的教学风格所吸引，尤其是在模型理论方面。阿迪生鉴于他的潜力，特别允许他选修课程，尽管他缺乏先修条件。 阿迪生的指导超越了课程本身。他巧妙地引导作者使用类比推理解决一个难题，并鼓励他探索一个“无限游戏”的概念，最终这成为了他一篇350页的关于 Borel 集序型的博士论文的基础。 阿迪生非常慷慨地付出时间，提供深入的讨论，并向塔斯基、克莱尼和丘奇等领军人物介绍。这反映了他逻辑学界的深厚根基。他营造了一个支持性的环境，强调尊重和耐心。尽管作者后来转入计算机科学领域，阿迪生传授的知识，从符号约定到图灵机和无限域的简单性等基本概念，仍然是他工作的核心，甚至影响了数据流语言 Lucid 的设计。他的遗产通过他所激励的众多学生得以延续。
每日HackerNews RSS
这个Hacker News讨论围绕着一篇纪念John W. Addison的“悼念”帖子，他是一位受学生们喜爱和尊敬的博士导师。原始帖子来自billwadge.com和伯克利数学系页面，引发了一系列赞赏的评论。
用户分享了他们自己博士导师的积极影响，并表达了对Addison先生人格的钦佩——他以尊重和耐心著称。 许多评论员指出这篇文章是一篇感人的致敬，激励他们对数学产生更多兴趣，并反思如何留下积极的遗产。 有一位用户甚至评论说，这是任何人都会高兴提前发表的悼词！ 讨论强调了有影响力的教育者能够产生的持久影响。
## C++26 与可变逗号语法
C++26 的一项最新提案旨在明确可变参数的语法，具体而言，就是弃用一种较旧的、与 C 兼容的形式，而支持一种较新的形式。虽然向后兼容性是 C++ 的核心原则，但有人认为这导致了复杂性的增加，因为旧特性与新特性并存。
讨论的中心在于，鉴于旧形式已经有效了数十年且使用范围不广，这项改变是否真的必要。许多人认为影响将是最小的，因为大多数现代 C++ 代码已经使用了首选的语法，并且编译器可能会为弃用的形式发出警告。
对话还涉及 C++ 倾向于*添加*特性而不是*删除*特性的问题，以及与 Rust 等采用不同策略来管理兼容性和演化的语言的比较。最终，共识倾向于认为这是一个积极的、虽然微小的、朝着更简洁和更易读的 C++ 语言迈进的一步。
从不完美的人类运动数据中学习运动类人形网球技能
Learning athletic humanoid tennis skills from imperfect human motion data
13 天前
张志凯1,3*, 陆浩飞1,3*, 连云瑞1,3*, 陈子清1,3, 刘云1,3, 林承淮3, 薛涵1,3, 曾子程3, 齐泽坤1,3, 郑少林3, 栾清3, 王景博5, 邢俊梁1, 王贺2,3, 易立1,4† *共同贡献 †通讯作者 1清华大学, 2北京大学, 3Galbot, 4上海启智研究院, 5上海人工智能实验室
## 人形机器人与人工智能进展 - Hacker News 摘要
Hacker News 上一篇帖子讨论了使用人类演示的模仿学习训练人形机器人的进展，具体由一个机器人学习打网球的视频展示 (zzk273.github.io)。 许多评论员预测该领域将迅速发展，一些人认为我们将在 18 个月到 2 年内看到能够完成烹饪和清洁等任务的通用人形机器人，可能在 2029 年可以短期租赁。
这种乐观情绪源于 1X/Neo、Figure 03 和 Skild AI 等项目的进展，以及用于训练的不断增长的数据集 (MimicDroid, Humanoid-Union)。 然而，其他人则告诫不要过度推断，强调将实验室演示应用于现实世界、开放式环境（如人们的家庭）的挑战。
讨论还涉及标准化基准测试的需求（如史蒂夫·沃兹尼亚克的“咖啡测试”），数据收集的重要性，以及这些机器人彻底改变网球等领域训练的潜力。 还有一个关于故障机器人造成伤害的警示故事被分享，引发了对安全功能的讨论。
Zipp 2001自行车，生产于1992-1997年，是一种独特的空气动力学自行车，因其速度而被UCI职业赛事禁止。作者经过长期寻找，最近获得了一个2001车架，并注意到在八种型号中找到理想配置（大梁、700c轮组）的难度。
该车架因之前的链条脱落需要重新喷漆，并由此激发了一个现代化改造项目。作者设计并3D打印，然后加工定制的五通，以适应现代穿轴和碟刹，并使用了通用后拨挂耳以便于更换。
一次定制的喷漆，保留了原有的深蓝色闪光效果，并增添了亮点，完成了修复工作。该项目展示了对重塑稀有且标志性的自行车历史的奉献精神，将复古美学与现代组件相结合。
Hacker News 新闻 | 过去 | 评论 | 提问 | 展示 | 工作 | 提交 登录
Zipp 2001 修复 (robot-daycare.com)
30 分 o4c 1 天前 | 隐藏 | 过去 | 收藏 | 3 条评论 帮助
pchew 1 天前 | 下一个 [–]
很感兴趣看到后叉在没有额外加固的情况下，如何承受碟刹力。
snozolli 1 天前 | 上一个 | 下一个 [–]
90 年代是自行车创新伟大的时代，就像计算机一样。我个人最喜欢的是 Cannondale Super V Raven 山地自行车，特别是搭配 Lefty 前叉：https://www.bikeflip.com/bikes/67792
很高兴看到有人将经典创新适应现代标准，就像将经典车身放在现代底盘和动力传动系统上一样。
HardwareLust 1 天前 | 上一个 [–]
非常酷的项目！我记得很多年前就想拥有一辆，但它超出了我的预算。
指南 | 常见问题 | 列表 | API | 安全 | 法律 | 申请 YC | 联系
搜索：
## 代理安全：从新奇到必要 (2025-2026) 近期事件表明一个关键转变：提示注入不再是理论风险，而是已部署AI代理面临的实际工程问题。2025年初出现了成功的攻击，利用了代理广泛的权限——包括访问私有仓库和浏览网页——即使*存在*现有缓解措施（如OpenAI的90%精确度检测器，仍然允许23%的成功率）。 核心问题不仅仅是错误的输入，而是代理*如何*处理它们。被污染的内容可能导致数据泄露、恶意代码执行和日益严重的危害，尤其是在具有网页浏览、内存存储和多代理交接等功能的情况下。OpenAI和Anthropic等公司承认这种风险，但继续部署，表明这是一种经过计算的权衡。 关键防御措施现在侧重于限制损害，而不仅仅是防止注入。这包括将工具描述和元数据视为不受信任的代码，严格限定权限（按任务、按仓库），以及稳健地跟踪数据来源。内存是一个特别令人担忧的问题，因为被污染的数据会影响未来的行动。 行业正在趋向于一种类似于应用程序安全的安全模型：清晰的输入标记、明确的危险操作，以及快速的反馈循环来监控不断演变的攻击模式。下一次重大事件很可能涉及多代理工作流程，凸显了对基础设施层面安全的需求，而不仅仅是模型层面的保障。
## 代理安全与提示注入风险 - 摘要
最近的 Hacker News 讨论强调了赋予 AI 代理广泛凭证和网络访问权限所固有的安全风险。核心问题在于，给予代理“访问一切”会产生一个巨大的攻击面，容易受到恶意网页注入有害指令的影响。
许多评论者认为最简单的解决方案——限制代理访问权限并将所有网络内容视为不受信任的内容——常常被回避，因为它会限制功能。更深层的问题在于 LLM 架构本身，缺乏指令和数据之间的明确分离，从而使提示注入攻击成为可能。
现有的缓解尝试，例如 OpenAI 的权限链，依赖于 LLM 自我调节，但这并非万无一失。像 OpenGuard 这样的工具旨在提供协议级别的防火墙，而另一些工具，例如 AgentBlocks，则侧重于细粒度的访问控制，并要求对敏感操作进行人工许可。
一个关键的结论是需要一个“确定性门”来在执行*之前*验证操作，无论提示如何加固。 讨论还批评了一些技术博客内容的质量，指出缺乏清晰的人类思考，以及注重密度而非可读性。
## River：一种新的 Wayland 合成器方法
River 的最新版本 (v0.4.0) 通过将合成器和窗口管理器分离成不同的程序，引入了 Wayland 架构的重大转变。 传统上，Wayland 合成器是单体的，要求窗口管理器实现完整的合成器——这是一项巨大的工程。 River 的非单体设计简化了窗口管理器开发，允许专注于窗口管理策略，如定位和键绑定，而 River 处理渲染和底层功能。
这得益于稳定的 `river-window-management-v1` 协议，旨在避免性能损失并保持“帧完美”——确保即使在窗口重新排列期间也能获得流畅、一致的视觉效果。 该协议通过原子“管理”和“渲染”序列管理状态，最大限度地减少通信开销。
这种分离降低了 Wayland 窗口管理器创建的门槛，提高了稳定性（窗口管理器崩溃不会导致会话崩溃），并允许使用更高级的语言编写窗口管理器，而不会影响性能。 目前，已有 15 个窗口管理器与 River 兼容，展示了一个不断发展的生态系统。 虽然目前仅限于 2D 桌面范例，但该项目旨在改善管理窗口管理器的用户体验，并计划在未来发布 1.0 版本。
## Wayland 合成器/窗口管理器分离：摘要
一个名为 River 的新项目因分离 Wayland 合成器和窗口管理器而备受关注——这种设计选择最初在 Wayland 诞生时就已做出，但现在正在被重新审视。传统上，Wayland 将这些功能结合在一起，但 River 认为这增加了不必要的复杂性。这种分离旨在降低创建自定义 Wayland 窗口管理器的门槛，而无需完全重建合成器。
讨论强调了 Wayland 设计中长期存在的争论。一些用户认为 Wayland 是一次令人沮丧的演变，不断地重新发明 X11 中已有的解决方案。另一些人则赞扬 Wayland 的优势，例如改进的 HiDPI 缩放和安全性。
核心思想是允许更模块化和灵活性，使开发人员能够创建针对特定需求量身定制的专用窗口管理器。然而，如果不同的合成器采用不兼容的协议，碎片化仍然是一个令人担忧的问题。这种方法的成功取决于协作和标准化，可能由较小的合成器推动，而 GNOME 等大型项目可能会保持抵制。最终，River 代表着迈向更可定制和可能更高效的 Wayland 体验的一步。
帕兰蒂尔为自己在“杀伤链”中的作用辩护：“我们为此感到自豪”
Palantir defends its role in the kill chain: "We are proud of that"
13 天前
## Palantir 的扩张与坚定立场 在最近的 AIPCon 上，Palantir 展示了其数据分析平台在各个领域的应用——从军事行动和造船到医疗保健和航空，所有这些都围绕一个中心主题：连接数据以实现更快、更高效的决策。 首席执行官 Alex Karp 大胆捍卫了 Palantir 参与“致命”军事行动，表示该公司“非常、非常自豪”地支持作战人员并最大限度地减少己方伤亡，即使这意味着对手会遭受损失。 尽管承认人工智能的潜在危险和社会颠覆——特别是对受过教育的选民的经济状况产生影响，Karp 强调 Palantir 致力于提供解决方案，而不是争论其使用。演示包括用于军事目标定位的“Maven 项目”、用于海军生产的“ShipOS”以及简化医院流程和测量师安排的平台。 会议强调了 Palantir 成为关键基础设施提供商的雄心，充当医疗保健领域的“数据路由器”，并提供全面的运营系统。该公司普遍使用《指环王》的意象，强调了其通过数据驱动的洞察力揭示“所有秘密”的承诺和潜在威胁。
## 生成式人工智能与生产力幻觉 围绕生成式人工智能，特别是大型语言模型（LLM）的炒作，常常集中在它们能够产生的代码数量上。然而，作者认为，庆祝代码行数——无论是人工编写还是人工智能生成——都是衡量程序员生产力的一种根本性错误。 历史上，软件工程专家一直告诫人们不要将代码长度与价值划等号，认识到编程主要在于管理复杂性和表达抽象思想，而不仅仅是为机器生成指令。 LLM 能够加速*编写*代码，但它们无法解决软件开发的核心挑战：设计、规划和理解问题领域。 事实上，代码生成的便捷性可能会适得其反，导致过早实现、增加维护负担（更多代码意味着更多需要维护的内容），以及倾向于重建现有解决方案而不是利用已建立的库。 作者强调，LLM 经常生成需要大量改进的代码，其中充斥着诸如抽象性差、风格不一致以及未能利用现有代码库等问题。 最终，编程仍然是一个协作、由人类驱动的过程，将代码生成速度置于可读性、可维护性和周密设计之上，是对整个软件生命周期的损害。 关键不是*更多*代码，而是*更好*代码，这需要人类专业知识，而不仅仅是人工智能的输出。
## Hacker News 讨论：代码生成与生产力
一场 Hacker News 讨论围绕着一个观点，即尽管人工智能代码生成（“代码生成”）发展迅速，但它不一定能提高生产力。虽然人工智能擅长快速生成代码，尤其是在“原型”任务和学习新工具方面，但许多评论员认为**编写代码并非软件开发的主要瓶颈。**
核心争论在于代码生成的速度是否能抵消调试、理解不熟悉的 AI 生成代码以及处理意想不到的边缘情况所花费的额外时间。 许多用户强调，复杂项目需要仔细的设计、集成、测试和协作——而这些是人工智能目前无法胜任的领域。
一个关键点是，**人工智能可以加速想法的迭代，但不能取代强大的架构设计和对问题领域的深入理解。** 也有人担心人工智能可能会造成可维护性问题，以及调试缺乏明确“意图”的代码的困难。
最终，讨论表明，虽然人工智能提供了有价值的工具，但它对整体生产力的影响是微妙的，并且很大程度上取决于项目的范围、团队动态和用户的做法。 许多人同意，关注*构建什么*仍然比仅仅加速*如何构建*更为重要。
## 单向信任漏洞利用：通过TDO转储进行横向移动
本研究详细描述了Windows单向信任中的一项漏洞，攻击者可以利用该漏洞访问受信任域。单向信任允许从受信任域到信任域的身份验证，反之则不行。在创建信任关系时，会在受信任域中自动创建一个特殊的`TRUST_ACCOUNT`。
虽然看似无害，但此帐户的密码以明文形式存储在*信任域*上的“受信任域对象”（TDO）中。一个新的Python工具`tdo_dump.py`可以有效地提取此TDO，从而揭示在受信任域上以`TRUST_ACCOUNT`身份进行身份验证所需的Kerberos密钥。
这有效地绕过了预期的单向访问控制，从而实现了横向移动。攻陷信任域的攻击者可以在受信任域内执行典型的Active Directory攻击——例如请求票据授予票据（TGT）和创建计算机帐户。该研究强调，由于远程访问和密钥检索方面的限制，现有的工具（如Mimikatz）对于这种特定攻击效果较差。`tdo_dump.py`工具和相关发现可在GitHub上获取。
黑客新闻 新 | 过去 | 评论 | 提问 | 展示 | 招聘 | 提交 登录
不要相信任何人：单向信任真的是单向的吗？ (almond.consulting)
11点 由 notmine1337 1天前 | 隐藏 | 过去 | 收藏 | 讨论 帮助
指南 | 常见问题 | 列表 | API | 安全 | 法律 | 申请YC | 联系
搜索：
这篇帖子详细描述了作者构建编译器的惊人经历，并质疑现代编译器的规模。最初持怀疑态度，他们成功地创建了功能完善的C和Lisp编译器，分别仅用1500行和500行代码，且功能妥协最小。这让他们意识到，大型编译器（通常数百万行代码）中的许多复杂性并非任务本身固有的，而是源于大量的“接缝、景观和权宜之计”——不必要的添加和复杂性。 作者将这些大型编译器比作费力构建的、但无法居住的景观。他们自己较小的编译器代表着为一种新方法播下“早期种子”——一种“现代GDSL”，暗示着专注于基本功能和简洁性，而非庞大的功能集。这篇帖子标志着探索这一新方向的开始。
## GDSL：一个极简内核与编译器探索
FirTheMouse最近分享了GDSL，一个2600行C++项目，包含一个“内核”——定义为共享处理核心，而非完整的操作系统——以及Lisp（500行）和C（1300行）语言的子集编译器。该项目尚未实现自举，这意味着编译后的语言无法重新编译源代码。
核心思想是展示编译器复杂性的很大一部分源于管理“边界”——数据表示之间的转换——而不是编译过程本身。GDSL旨在贯穿整个编译过程，保留信息，从而大幅减少代码量，与GCC或LLVM等生产级编译器相比。例如，GDSL-C中的标识符处理需要80行代码，而GCC则需要超过1000行。
该项目目前专注于“MIX”层——代码转换的基本过程——并且缺乏代码生成后端（汇编/LLVM IR）。作者希望扩展GDSL，可能包含后端系统，并探索与其他语言（如Python或Rust）的统一，在易用性和基本理解之间取得平衡。其他人也分享了类似的项目，例如Mu，引发了关于编译器设计和复杂性的讨论。