这个命令行工具提供了一种确定性的GPU PCIe链路健康诊断方法，无需依赖系统修改或假设。它直接测量PCIe链路状态（代数、宽度）、复制带宽（主机到设备 & 设备到主机）以及持续利用率，通过NVML的硬件计数器实现。 该工具根据*唯一*的可观察数据提供清晰的“正常”、“降级”或“性能不足”的结论，识别诸如意外链路协商（例如，x8而非x16）或带宽下降等问题。它不尝试修复问题，仅客观地报告问题。 主要功能包括详细报告理论和实际带宽、效率计算，以及通过PCIe高级错误报告的可选完整性检查。以CSV和JSON格式记录日志，并使用唯一的GPU UUID，可以实现可重复的基线和时间序列分析。 该工具与Linux（在Ubuntu上测试过）兼容，需要NVIDIA驱动程序和CUDA工具包。它旨在隔离PCIe链路性能与内核/工作负载的影响，提供一种可靠的方法来识别和证明与PCIe相关的瓶颈。
每日HackerNews RSS
一种新的Linux工具，在Hacker News上分享，旨在诊断GPU的PCIe链路健康状况和带宽——这些问题通常隐藏在典型软件之外。由gpu_systems（github.com/parallelarchitect）开发，它使用NVML和sysfs报告关键指标，如PCIe代数、宽度和持续传输速率。
该工具基于纯硬件数据对链路质量给出“诊断结果”，解决诸如由于Risers或分叉导致的代数降级或通道宽度缩减等问题，这些问题无法通过内核调整解决。
目前，该工具**仅适用于Nvidia**，依赖于Nvidia的管理库。用户建议增加内存块检查等功能，但开发者明确了其当前关注点。它利用了Windows上不可用的Linux特定功能。
莱塔代码
Letta Code
2 天前
## Letta Code：持久且学习的编码代理 Letta Code 是一个全新的开源编码代理框架，专为**长期使用和持续学习**设计。与每次会话都从头开始的典型代理不同，Letta Code 代理在交互之间**持久存在**，积累记忆并随着经验而改进。 这通过**代理上下文工程、长期记忆和技能学习**来实现。用户可以通过 `/init` 初始化代理，并通过 `/remember` 明确提示学习。复杂的重复性任务可以形式化为可重用的**技能**（存储为 .md 文件并使用 Git 进行版本控制），以供将来使用，从而提高性能。代理还可以通过 `/search` 和 Letta API 访问过去的对话。 重要的是，Letta Code **与模型无关**，目前在 TerminalBench 上排名第一的开源工具，性能可与 LLM 提供商（如 Claude 和 Gemini）构建的工具相媲美。这意味着即使**不**利用其学习能力，也能获得强大的性能。 Letta Code 可以通过 npm 安装，并可与 Letta 开发者平台或自托管服务器一起使用。
## Letta Code：开源、内存优先的编码代理
Letta Code (letta.com) 是一款完全开源、模型无关的编码框架，目前在Terminal-Bench上的排名很高。它以“内存优先”方法为特色，专为能够随着时间推移学习用户、代码库和组织上下文的持久代理而设计。`/init`和`/remember`等工具帮助管理这种内存，而`/clear`则在保留学习上下文的同时重置聊天缓冲区。
来自Letta的开发者最初将其构建用于内部使用——Letta Code现在共同编写了他们GitHub仓库中的大部分PR。一个关键特性是“危险模式” (`--yolo`)，用于沙盒环境，类似于Claude Code的权限设置。
讨论中强调了LLM“记忆”可能被污染或变得无用的问题，但Letta Code透明、基于文本的内存系统允许对提示进行完全控制和可见性。用户正在探索与现有工具（如Beads）的集成，以实现潜在的互补功能。该项目旨在避免重复任务并使代理能够从过去的错误中学习。
布莱恩·斯科特创建了“chat-tails”，这是一个为《我的世界》玩家设计的、刻意极简的聊天应用程序，优先考虑安全性和复古在线体验。他对现代聊天应用程序感到不满，因此构建了一个类似于旧 IRC 界面的系统——基于文本、短暂且只能通过 Tailscale（一种网络工具）的邀请访问。
Chat-tails 缺乏语音聊天、头像或图像共享等功能，而是专注于为朋友提供一个私密、安全的连接空间，就像在本地网络上一样。它在终端中运行，使用简单的命令进行聊天和基本操作。斯科特利用 tsnet 库和 bubbletea UI 构建了这个应用程序，强调易用性和令人愉悦的美感，尽管它很简单。
这个项目在约两天内完成，也作为一种学习工具，让用户接触到 VPN、SSH 和终端界面等技术。虽然目前仍处于早期开发阶段，但 chat-tails 提供了主流平台之外的独特选择，可能吸引那些寻求隐私、简洁或怀旧在线体验的人。
## Chat-tails 与在线交流的未来
一个名为“Chat-tails”的新项目，基于Tailscale构建，提供复古的终端聊天体验。Hacker News上的讨论迅速转向对日益增长的在线监管的担忧，尤其是在澳大利亚和英国。用户担心年龄验证要求会扩展到VPN，甚至可能扩展到SSH和TLS等基本的网络工具。
一些人推测，政府可能会专注于控制*终端*——访问服务的设备，而不是强制要求在每个平台中安装后门。这引发了隐私问题，一些人认为目标是加强监控，而不是安全。
Yggdrasil、I2P和Tor等替代方案被提及，作为现有解决方案，用于直接、可路由的连接，让人联想到早期的互联网。另一些人指出IRC是一个可行的选择，但它需要更多的技术设置。对话还强调了简单、短暂通信的吸引力，将其与现代消息应用程序的复杂性形成对比。最终，用户们争论了便利性、隐私性以及政府寻求控制在线活动之间的平衡。
努诺·F·戈梅斯·洛雷罗，一名47岁的麻省理工学院核科学与工程教授，周一晚上在马萨诸塞州布鲁克莱恩的家中遭到枪击身亡。他于周二上午在波士顿一家医院去世。警方正在进行积极的凶杀调查，目前尚未逮捕任何嫌疑人。 洛雷罗最初来自葡萄牙，是一位著名的理论物理学家，专攻磁化等离子体动力学和聚变研究——致力于清洁能源解决方案和理解宇宙。他于2016年加入麻省理工学院，并于2024年成为等离子科学与聚变中心主任。 同事们形容他是一位杰出的科学家、导师和富有同情心的领导者。麻省理工学院正在为社区提供支持，纪念洛雷罗对他的领域的奉献和有希望的研究。他留下家人。
## 麻省理工教授遇害 - 摘要
麻省理工学院一位教授在马萨诸塞州布鲁克林家中被枪杀，引发了对其死因的猜测。初步理论从一起抢劫案失控开始——尽管地点和情况使这种可能性看起来不大——到一起有针对性的袭击，可能与他在核聚变能源方面的研究有关。一些评论员提出可能与国际冲突、不满的投资者，甚至与最近布朗大学发生的枪击事件有关联，但当局目前认为没有关联。
讨论迅速转向政治动机的可能性，一些用户指出该教授的犹太信仰和亲以色列立场。另一些人提出了更离奇的理论，包括外国政府或边缘科学争端参与其中。许多评论员告诫不要进行猜测，并强调需要等待彻底调查。这起事件也引发了对犯罪率、安全以及悲剧事件在网上迅速政治化的讨论。
## ty：一种新型快速 Python 类型检查器 Astral 团队，Ruff 和 uv 的开发者，宣布 **ty** 进入 Beta 阶段。ty 是一种用 Rust 构建的、新型且极快的 Python 类型检查器和语言服务器。作为 mypy、Pyright 和 Pylance 的替代方案，ty 旨在更快*且*更好。 性能是关键重点：ty 的速度始终比现有工具快 10-60 倍，甚至在没有缓存的情况下。增量更新——例如在编辑期间——非常迅速（例如，PyTorch 中为 4.7 毫秒，而 Pyright 中为 386 毫秒）。 除了速度，ty 还优先考虑正确性和可用性，具有诸如交集类型、高级类型缩小以及受 Rust 编译器启发的清晰、上下文诊断等功能。它支持标准的语言服务器协议功能，以便与 VS Code 等编辑器集成。 该团队计划明年发布稳定版本，重点是稳定性、功能完善以及对 Pydantic 和 Django 等库的支持。最终，ty 将集成到 Astral 工具链中，以启用高级功能，例如死代码消除和依赖分析。 ty 现在可以通过 `uv tool install ty@latest` 和 VS Code 扩展获得。
## ty Beta 版本总结
Astral 发布了 **ty** 的 beta 版本，这是一款新的快速 Python 类型检查器和语言服务器，旨在改进现有的工具，如 mypy 和 pyright。一个关键的设计目标是最大限度地减少对显式类型注释的需求，同时仍然提供强大的检查。
讨论强调了在选择类型检查器时，除了规范一致性之外的其他重要因素——包括类型推断、诊断、配置、速度和编辑器集成。虽然 pyright 因速度而受到赞扬，但用户对 ty 的潜在改进感到兴奋，特别是它对交集类型的支持。
一些用户表达了对与现有工具（如 Django）的兼容性以及项目开源性质的担忧（ty 的代码主要在 ruff 仓库中）。Astral 团队强调他们致力于解决这些问题并欢迎反馈。此次发布引发了关于 Python 中静态类型检查的价值以及类型检查器激增的争论，一些人提倡整合。
纵观音乐史，美的和谐与不和谐的表现力之间一直存在着张力。虽然许多人寻求音乐来放松和宁静，但从巴赫和莫扎特等作曲家那里出现的“不和谐音”——一个关键元素——却带来了紧张和复杂性。
20世纪，不和谐音变得占据主导地位，尤其是在勋伯格开创的序列主义中。这导致了一种专断的“体制”，常常否定传统和易于理解的音乐，甚至审查了施雷克和柯恩戈尔德等作曲家。然而，科普兰和巴伯等作曲家在这种环境中游刃有余，拥抱现代和传统风格。
最终，一种更加自由的方法出现了，承认了各种音乐语言的有效性。霍比等作曲家即使面对批评，也坚持歌颂抒情之美，而杜克·埃灵顿则肯定“听起来好听就是好”。音乐，如同其他艺术形式一样，应该涵盖完整的人类情感范围——从喜悦和慰藉到愤怒和绝望——并利用所有可用的表现工具。
Hacker News 新闻 | 过去 | 评论 | 提问 | 展示 | 工作 | 提交 登录
不和谐之美 (plough.com)
19 分，由 tintinnabula 1 天前发布 | 隐藏 | 过去 | 收藏 | 1 条评论
wintermutestwin 1 天前 [–]
有趣的文章，但我很惊讶作者没有讨论不和谐与和谐之间相互作用的动态。和谐之所以令人满意，是因为与不和谐的并置。也许是因为他的例子没有体现这一点？我不知道，因为我听的流派与他讨论的不同。这个概念在许多形式的爵士乐中都有探讨。作为另一个现代例子，可以听听 The Mars Volta 最新巡演的现场录音，其中令人难以置信的美丽的渐进流行歌曲与非调性和非节奏的间奏交织在一起，为他们原始的录音室歌曲的简单之美带来了令人满意的对比。回复
指南 | 常见问题 | 列表 | API | 安全 | 法律 | 申请 YC | 联系
搜索：
## AI 与形式化验证的兴起 马丁·克莱普曼预测软件开发领域将迎来重大转变：形式化验证——数学上证明代码正确性——将实现主流应用，这得益于人工智能的进步。 历史上，形式化验证成本高昂且复杂，需要专业知识和巨大投入（例如，验证一个 8,700 行内核需要 20 人年）。 然而，基于 LLM 的编码助手现在能够*编写*证明脚本，从而自动化了以前手动且困难的过程。 这大大降低了成本，使验证对更多项目来说成为可能。 同时，对人工智能生成代码日益依赖，需要强大的验证方法*代替*传统的代码人工审查。 挑战将从*证明*代码转向*指定*代码应该做什么，尽管人工智能甚至可以协助完成这项工作。 虽然不能完全消除错误，但形式化验证为 LLM 的概率性本质提供了一个重要的制衡，确保可靠性。 克莱普曼认为，最大的障碍将是行业内部的文化转变，以拥抱这些现在可行的方法。
30 years of
tags 2 天前
tags 2 天前
## 网页开发三十年回顾
这个Hacker News讨论围绕着一篇详细的文章，描绘了网页开发从早期到2025年的演变历程。文章重点介绍了从使用记事本编辑简单的HTML和FTP上传，到需要CGI脚本实现动态内容（以及经常被忽视的Perl的作用），再到LAMP堆栈、Web 2.0和现代JavaScript框架的进步。
评论者普遍赞扬了文章全面而怀旧的概述。许多人分享了个人经历，并指出了被忽视的细节，例如Perl早期的统治地位、Firefox浏览器与IE竞争的重要性以及DigitalOcean出现之前的VPS格局。对于作者乐观的前景存在争论，一些人认为网络已经变得过于复杂，并且依赖于变通方法，而另一些人则看到了积极的趋势，例如更简单的方法（HTMX、HTML）的复兴以及浏览器兼容性的提高。
反复出现的主题包括不断用新的抽象层来解决问题，WordPress和Node.js等工具的影响，以及像`<br>`标签这样基础技术的持久相关性。最终，这场讨论反映了网页开发社区共同的历史和持续的演变。
## 奥丁上下文系统：摘要 奥丁经常被误解的“上下文”系统，并非关于简化代码或动态作用域；其核心目的是**拦截和修改第三方代码和库的行为**。这解决了常见问题：对外部代码的控制有限，且无法直接修改。 上下文是在每个作用域中隐式传递的指针值，包含由编译器确定的默认设置。它提供对关键资源的访问，例如分配器、断言处理、日志记录和随机数生成——所有这些都可以被覆盖。这允许开发者调整库的行为（例如，自定义内存分配），而无需更改库本身，这种功能在像C语言中，历史上曾尝试通过宏实现，但效果有限。 关键组件包括`allocator`（以及单独的`temp_allocator`）、`assertion_failure_proc`、`logger`、`random_generator`以及`user_ptr/user_index`，用于将数据传递给回调函数。上下文的固定内存布局对于跨库边界的稳定拦截至关重要。 虽然看似复杂，但上下文系统解决了与外部代码集成时对灵活性的基本需求，预见代码的演变以及不可避免地遇到设计不良的API。它优先考虑拦截能力，而不是最小化输入或提供通用的接口。
围绕一篇文章的讨论在Hacker News上展开，该文章由语言的创建者gingerBill撰写，解释了Odin的“context”特性。最初的文章因其被认为对那些难以理解该概念的用户态度傲慢而受到批评。
gingerBill澄清说，他是不情愿地写这篇文章的，原因是反复出现了一些可以通过阅读文档或寻求帮助来解决的、缺乏信息的抱怨。他认为许多用户期望无需努力就能理解复杂的系统，而`context`系统尤其容易被误解。
用户指出，文档中的示例代码本身就令人困惑，没有清楚地展示`context`的实际使用方式。gingerBill承认，该示例侧重于`context`的工作原理（作用域内的写时复制），而不是实际应用，并且有意将其保持一定程度的模糊，以防止不必要的干预。核心思想是，`new`总是利用context提供的分配器，从而提供对内存管理的控制。
## Pizlix：一种内存安全的Linux发行版
Pizlix是一个类似Linux的操作系统，基于Linux From Scratch (LFS) 12.2构建，并针对内存安全进行了增强。它通过使用Fil-C编译用户空间组件来实现这一点，Fil-C是一种旨在防止常见内存错误的编译器。然而，内核本身仍然使用传统的Yolo-C编译器编译，需要在构建环境中安装GCC。
该项目的核心挑战在于将Fil-C集成到LFS构建过程中，而LFS传统上依赖于Fil-C不支持的交叉编译技术。Pizlix通过利用Yolo-C工具链进行初始引导，然后在glibc构建期间策略性地“注入”Fil-C来克服这个问题。
构建过程分为几个阶段：Pre-LC（Yolo-C引导）、LC（Fil-C集成）和Post-LC（使用Fil-C的标准LFS构建）。Pizlix在VMware和Hyper-V (x86_64)上进行了测试，并且需要特定的分区设置才能通过`build.sh`脚本进行安装。
安装完成后，Pizlix提供一个安全的环境，具有SSH、GUI（Weston）和一个具有sudo权限的默认用户。它优先考虑内存安全，同时承认为了性能原因，内核编译器等某些组件可能需要不太安全的特性。
## Pizlix：一种内存安全的Linux发行版
Pizlix 是一种全新的Linux发行版，从零开始构建，专注于内存安全，利用 Fil-C 编译器。该项目旨在通过将 C 代码中的隐性错误转换为崩溃来消除它们，这一概念被戏称为“Yolo-C”（你只有一次生命）。
讨论围绕着将 Fil-C 与现有系统集成的复杂性。关键点包括安装期间对特定分区设置的需求（/dev/sda4 挂载在 /mnt/lfs），以及 Fil-C、Yolo-C 和标准 C 编译器（如 GCC 和 Clang）之间的相互作用。Fil-C 目前支持 glibc 和 musl，有时需要每个 libc 的多个版本。
使用 Fil-C 编译内核仍然存在挑战，需要像 l4linux 这样的解决方法来避免循环依赖。测试目前仅限于虚拟机（VMware 和 Hyper-V），对真实硬件的支持取决于正确的内核配置。该项目既因其对安全性的关注而受到欢迎，也因其使用的术语（“Yolo-C”被认为是对传统 C 开发不屑一顾）而受到批评。