数学家Chodosh、Mantoulidis和Schulze在先前研究的基础上，与Zhihan Wang合作，在Plateau问题上取得了重大进展——确定极小曲面的光滑性。他们成功证明了九维、十维和十一维空间中极小曲面的“通用正则性”，这意味着奇点（不完美点）可以通过轻微改变“消除”。 他们的研究方法是假设与他们想要证明的相反的情况，创建具有奇点的曲面堆叠，然后使用“分离函数”等高级数学工具证明矛盾。虽然以前的方法在更高维度上受阻，但他们改进的技术克服了障碍，包括一个特别具有挑战性的三维奇点。 这一突破将先前证明的几何和拓扑猜想——以及广义相对论中的正质量定理——扩展到这些更高维度。这项研究提供了新的见解，并可能解锁各种问题的解决方案，甚至是一些看似无关的问题，例如冰融化的物理学。未来的工作将要么努力在更高维度上实现正则性，要么揭示超出十一维的奇点消除的根本限制。
每日HackerNews RSS
黑客新闻 新的 | 过去的 | 评论 | 提问 | 展示 | 工作 | 提交 登录
新的证据探索肥皂膜奇点 (quantamagazine.org)
40 分，来自 pseudolus 1 天前 | 隐藏 | 过去的 | 收藏 | 3 条评论
VladVladikoff 1 天前 | 下一个 [–]
作者照片中的中间一张乍一看像是人工智能生成的照片。我的大脑被互联网上所有这些虚假的东西搞糊涂了，现在看到任何背景模糊的照片都会立刻觉得“这是假的”。回复
pstuart 1 天前 | 父评论 | 下一个 [–]
天啊！我明白你的意思了。回复
mlpoknbji 1 天前 | 上一个 [–]
吉姆·西蒙斯在转向金融之前，对数学的许多不同领域做出了重大贡献，真是令人惊叹。回复
指南 | 常见问题 | 列表 | API | 安全 | 法律 | 申请 YC | 联系
搜索：
## CUDA 组件本体：摘要 CUDA 的术语经常被过度使用，导致混淆。本文概述了对其组件和版本的清晰理解。“CUDA”本身指的是架构、指令集、语言、工具包和运行时——每个都有独立的版本。一个关键的区别在于 **OS 内核驱动程序**（管理硬件）和 **CUDA 驱动程序 API**（提供用户空间访问）。 CUDA 生态系统是分层的：应用程序使用 **运行时 API (libcudart)**，它调用 **驱动程序 API (libcuda)**，最终与 **GPU 驱动程序** 和 **硬件** 交互。兼容性取决于 **驱动程序 API 版本** 大于或等于应用程序使用的 **运行时 API 版本**。GPU 代码通过预编译的 **SASS**（GPU 机器代码）或 **PTX**（NVIDIA 的中间表示，由驱动程序 JIT 编译）执行。 重要的是，CUDA 驱动程序是 **向前兼容的**（支持旧的运行时版本），但 **不向后兼容**。像 `nvidia-smi`、`nvcc --version` 和 `torch.version.cuda` 这样的工具报告不同的方面——驱动程序版本、工具包版本和构建时工具包版本，分别需要仔细解释。 理解这些区别对于解决版本冲突、确保 CUDA 应用程序成功执行以及充分利用 NVIDIA GPU 的潜力至关重要。适当的编译目标（使用 `-arch` 和 `-code` 标志）以及对静态链接与动态链接的了解，进一步有助于构建稳定的 CUDA 环境。
这个Hacker News讨论围绕着一份详细的“CUDA本体论”（jamesakl.com），旨在理清NVIDIA CUDA生态系统内复杂的术语和版本管理。文章强调了由于“CUDA版本”（工具包 vs. 运行时 vs. 计算能力）和“驱动程序”等术语重叠而产生的常见困惑。
用户分享了实际挑战：将CUDA工具包与Python环境（conda vs. pip）匹配，工具包/驱动程序/编译器版本之间的兼容性问题，以及使用较新工具支持旧硬件的困难。NVIDIA的容器是一种常见的解决方法，但它们可能会消耗大量资源。
许多评论者强调了大型公司NVIDIA工具链标准化不足带来的挫败感，以及对更好安装帮助的需求。其他人指出，复杂的版本管理是软件开发中普遍存在的问题，将其与Java生态系统进行比较。讨论还涉及了像Nix这样的替代方法在管理依赖关系和确保可重复性方面的优势。最终，该讨论强调了即使对于经验丰富的开发人员，使用CUDA也涉及大量的开销和潜在的麻烦。
## Shebang (#!) 的历史 Shebang，或称 hashbang (#!)，是一种用于告知类 Unix 系统在执行脚本时使用哪个解释器的机制。它起源于贝尔实验室的第 7 版和第 8 版之间，最早出现在 1980 年左右的 4.0BSD 源代码中，最初限制在 16-32 字节的行，且不支持参数传递。 后来在 4.2BSD 中进行了改进，以传递参数，并且也出现在一个独立的 2.8BSD 开发分支中。 随着时间的推移，实现方式在参数处理、最大行长度（现在通常为 127-4096 字节）以及对诸如 setuid 执行（通常出于安全原因禁用）等功能的支持方面有所不同。 尽管最初是一种“hack”，但它已成为一种被广泛采用的约定。 尽管在 POSIX 标准中被提及作为可能的扩展，但其可移植性并不能保证。 现代系统通常支持 `#!/usr/bin/env interpreter` 以提高灵活性。 该名称的起源尚不确定，可能源于音乐术语（“升号”）或俚语（“shebang”）。 许多系统在过去的几十年中已经实现了和修改了 shebang，从而产生了复杂的发展历史和多样化的行为。
这个Hacker News讨论集中在一个微妙但令人沮丧的问题上：**shell脚本中的字节顺序标记 (BOM)**。 核心问题在于，脚本开头的UTF-8 BOM (U+FFEF) 可能导致内核错误解释 `#!` (shebang) 行，从而产生“没有该文件或目录”错误，即使解释器（如 `/bin/bash`）存在。
这个问题主要出现在在 **Windows** 上创建或编辑脚本时，像记事本、Notepad++，甚至PowerShell等工具可能会无意中向UTF-8编码的文件添加BOM。 虽然BOM对于UTF-8来说是不必要的，并且官方不推荐使用，但它们在Windows环境中很常见，并且可能在文件转换或通过编辑器设置时被引入。
用户分享了将问题追溯到不同工具和操作系统的经验，突出了跨平台开发的挑战。 讨论还涉及shebang的历史、POSIX行为以及相关的进一步阅读文章。 最终的解决方案是 **以 *不含* BOM 的 UTF-8 格式重新保存脚本**。
本硕士论文详细介绍了一种处理器设计，旨在直接执行Java字节码，以克服传统Java虚拟机（JVM）的性能限制。Java的可移植性是通过JVM解释字节码实现的，但这会引入执行速度变慢的问题。 本项目通过创建一个字节码*就是*原生指令集的处理器来绕过解释过程。这消除了翻译时间，并允许预处理Java类文件以减少运行时依赖。重要的是，该处理器是在现场可编程门阵列（FPGA）上实现的，使其能够适应不断发展的Java标准，并通过添加硬件模块针对特定应用进行优化。 由此产生的“Java机器”为执行Java应用程序提供潜在的性能提升和面向未来的解决方案，超越了基于软件的JVM解释的限制。
## FPGA上的Java处理器：黑客新闻讨论总结
最近黑客新闻上出现了一场关于2016年一篇论文的讨论，该论文详细介绍了在FPGA上实现Java处理器的情况。这个核心想法引发了关于专门为Java字节码构建硬件是否值得的争论。
虽然直接在硬件中执行Java字节码由于指令的高级特性并不被认为是最佳方案，但共识倾向于创建一个专门用于*辅助* JIT编译器的CPU。Azul Systems 之前曾用具有硬件垃圾回收支持的RISC处理器探索过这一点。
参与者强调了现代Java垃圾回收器的效率以及硬件“辅助”——例如存储屏障——进一步提高性能的潜力。然而，与成熟的处理器架构（Intel、ARM）竞争的难度是一个主要问题，引用了过去失败的案例，例如JavaStation，以及Azul面临的不可持续的商业模式。
讨论还涉及Java的AOT编译，GraalVM native image 正在获得关注，但承认了关于构建时间和库兼容性的权衡。最终，对话表明，专门硬件有一个利基市场，它可以补充而不是取代现有的处理器和JIT编译技术。
## PHP 8.5 发布：主要更新 PHP 8.5 于 2025 年 11 月 20 日发布，为该语言带来了多项增强。一个突出的特性是 **管道操作符 (`|>`)**，它简化了函数链，使代码更易读。克隆对象现在支持在过程中直接分配新值，但 readonly 属性存在限制。 新的 **`#[NoDiscard]` 属性** 强制使用函数返回值，如果忽略则会触发警告（可以使用 `(void)` 强制转换来抑制）。**闭包现在可以在常量表达式中使用**，从而能够在属性中定义它们——这为动态配置提供了一个强大的补充。 其他改进包括 **致命错误的堆栈跟踪**，以便于调试，以及内置的 **`array_first()` 和 `array_last()` 函数**，用于更简单的数组操作。一个新的 **URI 解析器** 提供了增强的 URI 处理能力。通过 **`#[DelayedTargetValidation]`** 属性，可以改进属性的编译时验证，以实现向后兼容。 PHP 8.5 还包括各种较小的更改、弃用和破坏性更改——完整的列表可在 [此处](未在文本中提供完整列表的链接) 找到。
## postmarketOS 双启动总结 双启动 postmarketOS (pmOS) 需要启动方式和数据存储。有多种选择，复杂度各异。 **简单方法：** 使用带有 SD 卡的电脑可以避免直接修改手机。或者，将 pmOS 内核刷入恢复分区，可以通过恢复模式启动 pmOS。 **高级方法：** 具有 A/B 插槽的手机可以将插槽 B 专门用于 pmOS，通过 fastboot 或 Android 应用切换。具有 U-boot（如 Nokia N900）的设备提供内置的操作系统选择。一些 Amlogic 设备也支持通过 U-boot 多重启动。lk2nd 系统可以从 SD 卡启动 Android 或 pmOS。 **Stowaway：** 对于具有加密数据分区的设备（Android 9+），Stowaway 在现有 userdata 分区上创建一个 pmOS 根目录，避免修改分区表。这需要通过 `tar` 传输文件，并强制 pmOS 从该位置启动。 **自定义分区：** 高级用户可以缩小 userdata 分区，并为 pmOS 创建专用分区，需要使用 TWRP 等工具进行格式化。 无论使用哪种方法，`pmbootstrap` 都是准备和导出 pmOS 镜像的关键工具。 仔细准备和了解设备的特定启动过程对于成功的双启动设置至关重要。
## 玄武岩纺织品：一种坚固耐用的材料 玄武岩纺织品是一种令人惊讶的耐用织物，它通过将玄武岩在1400°C下熔化并将其挤出成坚韧的纤维来制成。这种创新材料具有卓越的性能，其抗拉强度超过钢的两倍，比合金钢的比强度高2.5倍。 它具有很强的耐化学腐蚀性，能够抵抗酸和盐的侵蚀，并且可以承受高达700°C（在某些成分中甚至可达800°C）的温度。 除了强度和耐热性之外，玄武岩纤维也是一种出色的电绝缘体，适用于低压和高压应用，并且允许电磁辐射通过。 这些独特的特性使玄武岩纺织品成为一种用途广泛的材料，在众多行业中具有潜在的应用。
## OpenAgents：协作式AI代理网络
OpenAgents是一个开源项目，旨在简化AI代理的创建和连接，构建协作网络。它为代理发现彼此、共享信息和协同完成任务提供了基础架构——本质上是构建AI社区。
主要特性包括协议无关支持（WebSocket、gRPC、HTTP等）、基于模块化的架构以扩展功能，以及轻松集成现有代理的能力。用户可以在几秒钟内启动网络，并通过OpenAgents Studio进行管理，该Studio是一个用于交互和监控的可视化界面。
该项目鼓励社区参与，并为在GitHub仓库上加星的早期采用者提供“Day 1”徽章。OpenAgents优先考虑灵活性和可扩展性，采用分层架构和全面的文档。它非常适合希望探索AI协作的未来并构建创新的基于代理的应用的开发者。
了解更多信息并开始使用，请访问[openagents.org](https://openagents.org)。
## OpenAgents：一个用于多智能体网络的新框架
OpenAgents是一个新的开源框架，旨在构建兼容A2A（智能体到智能体）协议的多智能体网络。该项目旨在促进AI智能体之间的协作，无论它们是由什么底层框架创建的（例如Langchain或CrewAI）。
该项目的发布引发了讨论，一些用户质疑GitHub星标的快速增长，认为可能存在炒作或激励星标的情况。然而，开发者澄清了星标增长反映了用户真正的兴奋，并强调了一个功能，允许用户通过最少的编码快速部署智能体。
讨论的重点是此类系统的潜在用例，超越简单的工作流程，以实现开放生态系统，智能体可以在其中动态加入和离开。将它与早期的多智能体研究和当前的应用（如Milvus）进行了比较，一些人对仅使用LLM解决现实世界的工程挑战表示怀疑。分享了A2A协议网站（[https://a2a-protocol.org/latest/](https://a2a-protocol.org/latest/)）等资源以供进一步探索。
## Check-Projects: 一个 Git 状态 CLI **Check-Projects** 是一个快速、跨平台的 CLI 工具，旨在快速检查多个项目的 Git 状态，并按可定制的类别进行组织。它可以并行识别未提交的更改、与远程分支的差异以及未跟踪的文件。 **主要特性：** * **分类：** 按团队、客户或任何所需标准对项目进行分组。 * **灵活配置：** 使用 YAML 文件（支持本地和全局）来定义项目列表或自动扫描目录。 * **智能过滤：** 默认隐藏干净的项目，专注于需要操作的项目。 * **跨平台：** 适用于 macOS、Linux 和 Windows。 * **状态指示器：** 使用符号清晰地显示项目状态（例如，*M* 表示已修改，⬆ 表示领先于远程，✔ 表示干净）。 **安装：** 简单的 shell 脚本安装（macOS/Linux）或手动下载/提取。配置涉及在 YAML 文件中定义类别和项目。运行 `check-projects` 查看状态，并提供详细程度、类别过滤和自定义配置文件等选项。包含自动更新检查。
## 多仓库 Git 状态工具 - 黑客新闻讨论总结
一场黑客新闻讨论围绕着用于检查多个项目 Git 状态的命令行工具。原始帖子重点介绍了一个新的基于 Go 的工具“check-projects”，旨在快速识别具有未提交更改或落后于远程仓库的项目。
对话迅速发展成为现有解决方案的展示。多位用户推荐了诸如 `mani`（一个项目命令运行器）、`mr`（一个多仓库通用管理器）、`mu-repo`、`garden`、`git-map`、`gita`，甚至谷歌的 `repo` 等工具。许多人也分享了他们自己使用 `git status` 和 shell 命令实现类似功能的自定义脚本。
一个关键的争论点在于表示 Git 状态——特别是与远程仓库的差异。有些人更喜欢简洁的数字表示（例如，"-4+5" 表示落后/领先的提交），而另一些人则偏爱符号指示器。讨论还涉及使用 LLM 生成此类工具的趋势，一些人对“感觉编程”缺乏足够知识表示担忧。最终，该帖子展示了管理和监控多个 Git 仓库的多种方法。
## Lisp 机器浪漫主义的终结 作者表达了对持续怀念 Lisp 机器的沮丧，认为它们的时代已经结束了几十年。尽管在 1980 年代具有开创性，为当时提供了独特的发展环境和性能，但它们已被 RISC 机器超越，并最终在商业上失败（Symbolics 于 1993 年破产）。 作者驳斥了关于它们优越性的常见论点——速度、开发环境、微代码可编程性、以及“完全使用 Lisp”——指出现代硬件和编译器技术已经超越了它们。如今的 Lisp 环境（如 LispWorks）已经相当，而编译器设计方面的进步（如 Julia 和 LLVM 中所见）表明性能并不依赖于专用硬件。 核心论点是沉溺于过去会阻碍进步。Lisp 机器的浪漫主义，就像其他领域的“装备获取综合症”一样，是一种自我设定的障碍，阻止开发者专注于使用当前工具可以构建的东西。作者敦促人们从哀悼失去的硬件转向积极编码和探索新的可能性，并建议像廉价 GPU 这样的进步为未来的 Lisp 开发提供了令人兴奋的潜力——而无需重现过去。