欢迎来到 Hacker News 每日播报，今天我们将一同探索从创新的 BitTorrent Tracker 到复古的 Mac OS X 模拟器，从前沿的 AI 开发环境到深邃的天文观测，以及那些关于操作系统内核、古老乐器和开源协作的精彩故事。
Show HN: 我用 Elixir 编写了一个新的 BitTorrent Tracker
GitHub 用户 Dahrkael 近期展示了他的开源项目 ExTracker，这是一个用 Elixir 语言编写的 BitTorrent Tracker。作者表示，这个项目是他为了深入学习 Elixir 和 Go 而开发的，他认为 Elixir 这种基于 Erlang VM (BEAM) 的函数式编程语言，非常适合构建高并发的 BitTorrent Tracker。尽管 DHT 和 PEX 等技术日益普及，Tracker 似乎被一些人视为“过时”，但作者坚信它们在公共网络中仍有其独特价值，尤其是在公共 Tracker 领域。他注意到目前新的 Tracker 实现不多，因此决定自己动手，并计划持续开发，加入更多独特功能。
ExTracker 的核心亮点包括：技术栈选择 Elixir，旨在利用 BEAM 虚拟机的高并发和容错能力；性能目标是高吞吐量和低内存占用，声称每百万 Peer 仅需约 200MB 内存，数据存储在内存中的 ETS 表里；强调“零配置”启动，支持多种部署方式，包括 Docker 镜像；实现了多个重要的 BitTorrent Enhancement Proposals (BEPs)，如 UDP Tracker 协议、紧凑 Peer 列表、IPv6 扩展等，并计划加入 Infohash 白名单/黑名单、Peer 管理和 Metrics 监控等功能。
围绕这个项目，大家展开了热烈的讨论。许多人认为 BEAM 虚拟机天生就非常适合处理 BitTorrent Tracker 这种需要大量并发连接和低延迟响应的应用场景。关于 Elixir 的编程风格和 OTP 的使用也引发了一些探讨，有人认为代码“几乎是过程式的”，直接操作 ETS 而非采用更典型的 OTP 模式，但作者解释说，在将 Tracker 视为高速数据库的特定场景下，直接使用 ETS 能获得更好的扩展性。这场讨论也引出了对 Elixir/Erlang 核心理念的探讨，比如“Let it crash”哲学以及模式匹配在网络协议处理中的优势。此外，关于 BitTorrent Tracker 在现代 P2P 网络中的地位也备受关注。大家解释说，尽管 DHT 和 PEX 允许客户端在没有中心 Tracker 的情况下发现 Peer，但 Tracker 在需要控制访问、统计数据或强制规则的私有场景下仍然不可或缺。还有一些关于项目具体实现的反馈和问题，例如 HTTPS 配置和性能对比，作者也一一进行了回应。
Hurl: 使用纯文本运行和测试 HTTP 请求
Hurl 是一个命令行工具，它允许开发者使用简洁的纯文本格式来运行和测试 HTTP 请求。它的核心理念是将 HTTP 请求和测试定义在一个易于阅读和编写的文本文件中，旨在成为开发者和运维人员都能轻松使用的工具。
Hurl 的主要功能和亮点在于其简洁的纯文本格式以及强大的 HTTP 测试能力。你可以在一个 .hurl 文件中像写脚本一样定义一系列 HTTP 请求，格式直观，非常适合版本控制和代码审查。它支持在一个文件中定义多个请求，并通过 [Captures] 部分从一个请求的响应中捕获特定值，然后在后续请求中使用这些值作为变量，这对于测试需要多步操作的 API 流程非常有用。Hurl 也是一个强大的 HTTP 测试工具，你可以在每个请求后定义响应断言（[Asserts]），检查 HTTP 状态码、响应头，甚至响应体的内容，支持 JSONPath 和 XPath。它还支持发送各种类型的请求体，包括 HTML 表单、Multipart 表单、JSON、XML，甚至可以直接引用本地文件。Hurl 底层依赖于成熟可靠的 libcurl 库，这意味着它继承了 curl 的许多优点，如速度快、效率高，并支持 HTTP/1.0, 1.1, 2, 3 以及 IPv4/IPv6 等。作为一个用 Rust 编写的轻量级单二进制文件，Hurl 安装简单，没有额外的运行时依赖，非常适合集成到 CI/CD 流水线中，并支持生成多种报告格式。
（抱歉，您提供的输入中不包含 Hacker News 上关于 Hurl 的讨论内容。因此，我无法总结相关观点。）
无限 Mac OS X
Mihai Parparita 在他的 Infinite Mac 项目中取得了新进展，成功地在网页浏览器中模拟运行早期版本的 Mac OS X。目前，Mac OS X 10.1 和 10.3 的兼容性最好。作者坦承，模拟器的运行速度并不快，但这在某种程度上也反映了当年这些操作系统在真实硬件上的体验。同时，项目配套的“Infinite HD”虚拟硬盘也进行了重建，加入了那个时代许多知名的独立软件。
文章深入探讨了实现这一目标的具体技术细节。作者最初尝试使用 DingusPPC 模拟器，但遇到了问题，转而研究 PearPC，一个诞生于本世纪初、专门用于在 x86 架构上模拟 PowerPC Mac 的老项目。他成功地将 PearPC 移植到了 WebAssembly/Emscripten 环境，使其能在浏览器中运行。在优化过程中，作者发现并修复了 PowerPC 处理器浮点单元（FPU）状态寄存器（MSR）中的 FP 位处理问题，这一发现不仅解决了 PearPC 的图形故障，也意外地修复了 DingusPPC 中的类似问题，显著提高了其稳定性，使其能够可靠地运行 PearPC 无法支持的 10.1 版本。最终，通过结合使用这两个模拟器，Infinite Mac 能够支持更广泛的早期 Mac OS X 版本。为了提供更完整的体验，作者重建了“Infinite HD”虚拟硬盘，收录了大量 Mac OS X 时代的软件，并加入了开发者工具 CD。此外，Infinite Mac 网站的界面也新增了“Aqua”主题，复刻了早期 Mac OS X 标志性的水滴状 UI 风格。
这项工作获得了高度赞扬，许多人表达了对早期 Mac OS X 的怀旧之情。一个反复出现的主题是对早期 Mac OS X UI 的讨论，特别是 Aqua。许多人认为那个时代的界面（如 Aqua、Panther 的拉丝金属、Tiger）比现代 macOS 更清晰、更有条理、更易用，尽管审美是主观的。有人回忆起 Aqua 刚推出时带来的视觉震撼，以及它对性能的影响。也有人怀念旧版 Mac OS 的一些 UI 特性，比如“抽屉”（Drawers）和绿色按钮的“缩放”（zoom to fit content）而非全屏行为。讨论中也提到了 PearPC 项目早期一位共同作者不幸去世的悲伤故事，以及这如何影响了项目的势头。一些人对文章中提到的技术细节感兴趣，比如精简的 PowerPC 模拟器代码和 PowerPC 指令集的一些特性。还有一些用户对 Infinite Mac 项目本身表示赞赏，特别是它能够在浏览器中直接运行旧系统的便利性，无需下载或安装额外软件。
Asterinas: 一个新的 Linux 兼容内核项目
LWN.net 近期报道了一个名为 Asterinas 的全新操作系统内核项目。Asterinas 是一个用 Rust 语言编写的、旨在实现 Linux ABI 兼容性的新内核项目，其核心是一个被称为“framekernel”的架构。
Framekernel 试图结合单体内核和微内核的优点：它将所有需要使用 Rust unsafe 特性的代码封装在一个小的核心库（称为“框架”）中，而内核的其他部分（“服务”，包括驱动程序等）则使用 safe Rust 编写，并依赖框架提供的安全 API。所有这些代码仍然运行在内核地址空间内，但通过 Rust 的类型和内存安全特性在逻辑上实现了隔离。这种设计旨在提高系统安全性，同时避免微内核的 IPC 性能损失。Asterinas 的一个重要目标是实现形式化验证，通过缩小需要 unsafe 代码的核心框架，他们希望能够对这个小的可信计算基（TCB）进行形式化验证。项目不仅开发了 Asterinas 内核本身，还产生了两个重要的辅助工具和库：OSTD（一个 Rust OS 开发框架）和 OSDK（一个 Cargo 插件，用于辅助内核开发、构建和测试）。Asterinas 于 2024 年初发布，目前处于早期快速开发阶段，支持 x86 和 RISC-V 架构，已实现 206 个 Linux 系统调用。项目主要由中国高校（南方科技大学、北京大学、复旦大学）的研究人员和赞助商蚂蚁集团推动。
围绕文章，大家展开了多方面的讨论。关于 Framekernel 架构和安全性，有人将 Asterinas 的设计与微软的 Singularity OS（使用 C#）和华盛顿大学的 SPIN OS（使用 Modula-3）进行了比较，这些项目也尝试使用语言层面的安全特性来构建内核。关于“privileged”和“de-privileged”的术语引起了一些困惑，大家澄清这指的是在内核空间内，允许使用 unsafe Rust 的核心框架是“privileged”，而只能使用 safe Rust 的服务模块是“de-privileged”。许多人聚焦于实现 Linux ABI 兼容性的巨大挑战，特别是设备驱动程序。Linus Torvalds 早期关于驱动程序是 Linux“护城河”的言论被多次引用。大家普遍认为，编写和维护大量硬件的驱动程序是新内核项目面临的最大障碍。关于微内核与单体内核的辩论也再次出现，一些人认为，在 2025 年设计一个单体内核是“可笑的”，微内核才是现代安全设计的方向；反对者则认为，现代硬件的复杂性使得微内核的优势不再明显，而且许多微内核的优点也可以在单体内核中实现。
Phoenix.new – Phoenix 的远程 AI 运行时
Fly.io 博客上，Elixir Phoenix 框架的创建者 Chris McCord 撰文介绍了 Phoenix.new，这是一个集成了 AI 代理的远程开发环境，专门为 Elixir 和 Phoenix 应用量身打造。Chris McCord 提到，这个项目最初只是他为了探索如何让 LLM 代理更好地与 Elixir 协作而启动的一个周末小项目，但很快就发展成了一个严肃的、功能强大的工具。他认为 Phoenix.new 将成为构建协作式、实时应用的最快方式。
Phoenix.new 提供了一个完全在线的开发体验，用户和 AI 代理都在一个临时的、隔离的虚拟机（Fly Machine）中拥有 root 权限。这意味着代理可以自由地安装软件、运行命令，而不会对用户的本地机器造成任何风险。用户通过一个基于浏览器的 VSCode 界面与这个环境交互。这个 AI 代理系统是为 Phoenix 的实时协作特性而设计的，内置了一个完整的无头浏览器，代理可以用它来像真实用户一样与正在开发的应用程序互动，检查前端变化、JavaScript 状态和服务器日志。拥有完整的环境控制权让代理能够处理很多繁琐的任务，它可以修改项目依赖、运行测试，甚至安装操作系统级别的软件包。
这篇文章引发了热烈讨论。许多人对 Chris McCord 的工作表示赞赏，并对 Phoenix.new 感到兴奋，特别是 Elixir 社区的用户。他们认为这是一个积极的信号，有助于解决人们对 LLM 在 Elixir 方面表现不如 Python/JS 的担忧。关于 Phoenix.new 的核心创新点，一些人认为关键在于其提供的隔离式远程代理环境，允许代理“放飞自我”而无风险。另一些人则强调其与 Fly.io 平台的深度集成，简化了部署和预览流程。关于用户体验和工作流程，一些开发者表达了对基于浏览器 IDE 的不适应，更倾向于使用本地工具。Chris McCord 回应说，计划增加 SSH 访问功能，允许用户使用本地 VSCode 等工具连接到远程环境。关于 AI 对 Elixir 的支持能力，尽管有人担心 Elixir 的训练数据较少，但许多实际使用过的用户表示，当前的 LLM（特别是 Claude 的最新模型）在编写 Elixir、Phoenix 和 LiveView 代码方面表现相当不错。
巨型“全视”望远镜即将彻底改变天文学
天文学界即将迎来一场变革，这得益于一台即将投入使用的巨型望远镜——薇拉·C·鲁宾天文台（Vera C. Rubin Observatory）。其核心目标是进行一项为期十年的大规模天空巡天，名为“时空遗产巡天”（Legacy Survey of Space and Time, LSST）。它的特别之处在于其巨大的视野和快速扫描能力，能够在短短几个夜晚内扫描整个可见天空，并在十年内反复观测同一区域。它配备了世界上最大的数字相机之一，拥有惊人的32亿像素，能够以前所未有的速度和广度收集数据。
大家对这台望远镜的潜力表现出极大的热情，同时也深入探讨了它带来的技术挑战和一些现实问题。一位在天文学领域工作的博士生分享了他的专业见解，特别强调了鲁宾天文台对小行星研究的巨大影响，预计将使已知小行星的数量增加两倍以上。他还提到鲁宾对时间域天文学（研究随时间变化的宇宙现象）的贡献将是巨大的。关于数据量，大家纷纷表示惊叹。文章提到鲁宾天文台每晚将产生约20TB的原始图像数据，整个十年巡天预计将产生73到100PB的数据。这引发了关于数据存储和处理的讨论，有人计算了这需要多少硬盘和机架空间，认为以现代存储密度来看，虽然数据量巨大，但物理存储空间并非天文数字。然而，并非所有讨论都是关于技术和科学前景。一个反复出现的担忧是卫星星座，特别是星链（Starlink）造成的条纹问题。大家形象地将其比作“蚊子”干扰照片。尽管鲁宾天文台的快速重复曝光策略可能有助于减轻影响，但卫星条纹仍然会遮挡部分视野，导致数据丢失或统计精度下降，尤其影响对瞬时现象的观测深度。
ELIZA Reanimated: 恢复所有聊天机器人的母亲
computer.org 近期刊登了一篇文章，讲述了一个历史性的技术复原项目：将世界上第一个聊天机器人 ELIZA 的原始代码重新运行起来。ELIZA 是由 Joseph Weizenbaum 在 20 世纪 60 年代中期于 MIT 开发的，被认为是聊天机器人的鼻祖。它最初运行在 MIT 的 Compatible Time-Sharing System (CTSS) 分时系统上，使用了一种名为 MAD-SLIP 的语言编写。尽管 ELIZA 很快就有了 Lisp 和 BASIC 等语言的克隆版本并广为流传，但原始的 MAD-SLIP 版本逐渐被遗忘。
项目的契机出现在 2021 年，研究人员在 Weizenbaum 教授位于 MIT 的档案中，意外发现了似乎是原始 ELIZA 代码的完整打印件，以及 MAD-SLIP 的关键支持代码。这激发了团队将这个历史性的程序重新“复活”的念头。复原过程充满挑战，团队需要将这些打印件手动转录成机器可读的格式，并在一个模拟的 IBM 7094 和 CTSS 系统上进行编译和调试。经过大量的代码清理、补全和调试，团队最终在模拟环境中成功运行了原始的 ELIZA。文章特别提到，尽管付出了巨大努力，但最终运行的 ELIZA 代码中，有 96% 是直接来自档案中的原始代码。他们成功地使用 1966 年论文中的 DOCTOR 脚本重现了著名的“Men are all alike”对话。复活原始代码也让他们发现了一个之前未知的显著 bug：这个版本的 ELIZA 无法正确处理数字输入，遇到数字时会崩溃。团队讨论了是否修复这个 bug，最终决定保留它，认为保持原始代码的真实性（包括 bug）对于历史研究更为重要。
大家围绕文章展开了活跃的讨论，主要围绕 ELIZA 的历史影响、用户对早期聊天机器人的感知以及与当前 LLM 时代的对比展开。不少人分享了自己与 ELIZA 或其克隆版本的个人经历。有人回忆起高中时在 BASIC 上实现的 ELIZA-like 程序，并对同学们对待程序如同有“能动性”（agency）的态度感到惊讶甚至恐惧，认为这与当前人们对待 LLM 的方式有相似之处，并引发了对现代 AI 公司伦理的担忧。讨论中也探讨了在 LLM 出现之前，聊天机器人技术的发展状况。除了 ELIZA 衍生的规则系统（如 Personality Forge），还提到了基于传统 NLP/NLU 技术的方法（如 Rasa）以及 AIML。Loebner Prize 这个基于图灵测试的年度竞赛也被提及，作为衡量前 LLM 时代聊天机器人水平的一个历史性指标。
Octobass
Atlas Obscura 近期介绍了一种体型巨大、音域极低的弦乐器——Octobass。这种乐器由19世纪法国制琴师 Jean-Baptiste Vuillaume 制造，比普通低音提琴大得多，高度超过三米，需要演奏者站在凳子或平台上才能操作。它的弦也异常粗壮，发出的声音频率极低，有些音符甚至低于人类的听觉范围，只能通过身体感受其振动。这种乐器最初是为了在大型管弦乐队中提供更深沉、更强大的低音基础而设计的，但由于其体积庞大、演奏困难且造价昂贵，并未得到广泛普及。文章提到，目前世界上仅存少数几把 Octobass，其中一把收藏在美国亚利桑那州凤凰城的乐器博物馆（Musical Instrument Museum, MIM）。
围绕 Octobass，大家展开了热烈讨论，提供了许多文章之外的精彩细节和多角度的看法。关于 Octobass 的稀有性，有人指出文章中“蒙特利尔交响乐团是唯一拥有这种不寻常乐器的乐团”的说法并不准确。实际上，蒙特利尔交响乐团拥有三把 Octobass，其中一把是原始乐器的复制品并有小幅升级，另外两把甚至采用了电机驱动来辅助演奏。更令人惊喜的是，一位自称参与了蒙特利尔最后两把 Octobass 建造的用户现身，证实了这一信息，并指出文章中展示的凤凰城那把 Octobass 缺少了原始设计中的踏板，这些踏板对于实现连奏（legato）非常重要。关于 Octobass 的声音和演奏，大家也分享了一些视频链接，让大家能“听”到（或感受到）它的声音。有人提到，由于音域极低，YouTube 的音频压缩可能会影响体验，但也有人反驳说低频声音的信息量较少，理论上应该更容易压缩。关于低于人类听觉范围的音符，讨论引发了关于次声波的讨论。有人觉得无法想象只有振动而没有声音的感觉，而另一些人则科普了次声波的应用，比如在航天领域的声场测试以及在艺术和电影中用于制造不安或恐惧感。
Sunsonic 986-II – 一台内置键盘和迷你 CRT 的泰国 Famicom 克隆机
复古游戏世界中，Sunsonic 986-II 是一台神奇的设备。这台机器是一台泰国的 Famicom 克隆机，但它不仅仅是一台游戏机，还内置了键盘和一个迷你的 CRT 显示器。
文章的重点在于展示这款 Sunsonic 986-II 的独特设计。它将任天堂 Famicom 的游戏功能与一个看起来相当完整的键盘和一个小巧的彩色 CRT 屏幕整合在一个米色的机身里。这种一体机的形态在当时的 Famicom 克隆市场中显得非常特别，尤其是在东南亚地区。图片展示了机器本身、插槽中的游戏卡带、桌上的其他卡带以及一个手柄，整体外观复古且功能繁多。
大家对这款设备表现出了极大的兴趣和赞叹。许多人直呼它“太酷了”、“太棒了”、“令人垂涎”，认为它是他们见过的最酷的 Famicom 克隆机之一。关于键盘的功能，讨论中展开了一些探讨。有人好奇 Famicom 上的键盘能做什么，其他人则指出，Famicom 确实有 Basic 语言卡带，可以进行编程，而且据称比 Atari 2600 的 Basic 更强大。这款设备的起源和市场定位也是讨论的焦点。有人认为，这可能是中国大陆原始产品的本地化版本，这类机器在当时常被包装成“教育电脑”，以规避对游戏硬件的限制。它们通常会捆绑语言或数学的学习卡带，尽管实际上很少有人用它们来学习。从设计美学上看，Sunsonic 986-II 被描述为一种“最大化”的风格，与现代极简设计形成鲜明对比，仿佛来自一个“反史蒂夫·乔布斯”主导的平行宇宙。有人欣赏泰国在设计上的“过度”美学，认为这与日本的风格形成有趣的对比。
开源无法协调吗？
matklad 在他的博客上提出了一个引人深思的问题：“开源无法协调吗？”文章开篇，作者从自己的日常经历说起，比如在使用 NixOS 时遇到特定 KDE 应用（Hotspot profiler）的版本问题，发现无法像在传统系统那样简单下载最新发布版。他认为，Linux 桌面环境就像一座摇摇欲坠的塔，充满了相互竞争的库、协议和标准，缺乏一个统一的、由单一实体协调的基线 API，这与 Windows 和 macOS 形成了鲜明对比。
接着，作者提出了一个反论：既然如此，Linux 是如何存在并成功的？“永不破坏用户空间”的原则又是如何实现的？他以自己熟悉的领域——语言服务器协议（LSP）为例。他指出，LSP 的出现极大地推动了交互式静态分析成为软件开发的常态，但这个转变来得太晚了。尽管 LSP 本身实现平庸、治理糟糕，但它最大的价值在于“它存在”。作者认为，开源社区本有十年的机会来协调并推出一个 IDE 协议，但由于“开源不擅长协调”而未能实现，最终由微软填补了这个空白。回到 Linux 的问题，作者认为 Linux 内核的成功部分归功于其集中的治理结构和对公共接口的承诺，但更重要的因素是 POSIX 标准。他提出，POSIX 是一个“从外部定义”的基线 API，它为 Linux、BSDs 和 XNU 等系统“预先解决了”协调问题，剩下的只是实现。而 Linux 桌面缺乏这样一个外部定义的、预先解决协调问题的基线。
大家对作者的观点展开了热烈讨论，呈现了多样的视角。不少人直接挑战了作者关于 POSIX 的论断。他们认为 POSIX 并非“从外部定义”并预先解决问题，而更多是标准化了 现有、成功的实践和“公分母”。例如，strlcpy/strlcat 函数先出现在 OpenBSD，被其他系统采用后才被 POSIX 标准化。然而，这个 strlcpy/strlcat 的例子本身又被用来支持作者关于“开源无法协调”的观点。有人指出，尽管这些函数在 1998 年就出现了，但由于 glibc 维护者的反对，它们花了 25 年才进入 glibc。这引发了关于开源项目中维护者个性和“守门人”角色的讨论。一些人认为，这些“情绪化”的维护者虽然有时令人沮丧，但他们的严格（甚至粗暴）可能也阻止了许多糟糕的想法，是项目保持健壮的原因之一。讨论进一步扩展到这是否是开源独有的问题。许多人认为，缺乏协调和内部摩擦并非开源特有。专有软件公司内部也常有部门墙、重复造轮子和 UI 不一致。他们指出，专有软件的协调更多是自上而下的，优化的是公司利润和用户锁定，而非技术上的最优解或社区的广泛需求。相比之下，开源虽然看起来碎片化，但其“分叉”（forking）机制被一些人视为一种重要的“逃生舱”和解决冲突的方式。