## 代码优化：关键原则总结 有效的代码优化并非猜测，而是一个数据驱动的过程。**不要过早优化**——你无法可靠地预测性能瓶颈在哪里（规则1 & 2）。在尝试任何加速改进之前，**始终进行测量**，并且只关注那些明显减慢速度的区域。 除非绝对必要，否则避免使用复杂的算法（规则3 & 4）。它们通常对小型数据集存在隐藏的性能成本，并会增加更多引入错误的可能。**优先考虑简洁性**——“蛮力”通常是一个好的起点（KISS原则）。 最终，**数据结构比算法更重要**（规则5）。选择正确的数据组织方式通常会使最佳算法显而易见。首先关注设计良好的数据结构，因为它们是高效编程的核心。 这些原则呼应了霍尔、汤普森和布鲁克斯等人的智慧，强调了一种务实的性能方法：测量、简化和优先组织数据。
每日HackerNews RSS
🎤 声音分离：使用UVR卡拉OK模型或Demucs将人声从伴奏中分离。可调节主唱音量。📝 歌词：WhisperX转录并对齐音频中的每个词。如果可用，则使用LRCLIB中的现有歌词。🎯 音高评分：对着麦克风唱歌，实时获得评分。星级评分和每首歌的排行榜记录您的进度。👤 玩家资料：多个资料，分别记录分数历史。切换歌手，不会丢失任何人的记录。🎬 视频文件支持：将.mp4或.mkv文件拖放到库中。人声被分离，原始视频作为背景播放。🌌 动态背景：GPU着色器效果（等离子体、极光、星云...），Pixabay视频循环，或视频文件的源视频。🎮 手柄：完全使用控制器浏览菜单、选择歌曲和控制播放。方向键、摇杆、面部按钮。📦 单一二进制文件：首次启动时，ffmpeg、Python、PyTorch和ML模型都会被引导加载。无需安装。
## 夜莺：开源卡拉OK应用 - 摘要
夜莺是一款新的开源卡拉OK应用程序，旨在与用户电脑上的*任何*歌曲一起使用。它使用Rust和Bevy引擎开发，本地分离人声和伴奏（使用UVR Karaoke或Demucs等模型），并通过WhisperX或LRCLIB自动生成时歌词。它具有音调评分、游戏手柄支持和GPU加速功能。
开发者旨在易于使用，选择单二进制文件安装方式，首次启动时下载必要的依赖项（Python、ML模型）。然而，这种方法因潜在的安全和性能问题，以及绕过标准包管理而受到批评。
用户反馈不一，一些用户在使用歌词准确性和依赖项下载方面遇到了问题。尽管存在这些问题，该项目因其在卡拉OK软件方面的潜力而备受关注，尤其是在小众音乐和对完全本地、无广告体验的需求方面。开发者正在积极寻求反馈和贡献以改进该应用程序。
Eon Systems PBC 近期分享了关于创建虚拟、具身化的果蝇的进展，该果蝇由基于连接组的大脑模型控制，引发了广泛关注。该项目整合了现有研究——包括成虫连接组、大脑模型和详细的虚拟身体（NeuroMechFly）——以模拟感觉运动控制。 这只果蝇在虚拟环境中导航，响应“味道”（糖）和“灰尘”（触发梳理）等线索，由一个拥有14万个神经元的神经模型驱动。感觉输入激活相应的神经元，更新大脑活动，并将输出转化为身体的运动指令。虽然前景可观，但该模型仍然简化；它使用基本的神经元动力学，并使用有限数量的下行神经元控制身体。 这并非果蝇的完整模拟——内部状态、学习和完整的运动层级缺失。然而，它为测试连接组约束控制和探索大脑-身体接口提供了一个有价值的平台。Eon 旨在完善这项工作，并寻求合作以建立大脑仿真保真度的标准。
## 空间天气更新 - 2026年3月17日
Spaceweather.com 的本次更新（截至3月17日2200 UTC）预测3月19日可能出现地磁暴，时间与春分重合，并可能因“拉塞尔-麦克费伦效应”而加剧，可能在中纬度地区产生极光（G2级风暴）。未来24-48小时内，有35%的几率出现M级耀斑，5%的几率出现X级耀斑。预计地磁活动在中纬度地区将活跃（20-25%的可能性），在高纬度地区将更加活跃（高达75%的可能性出现严重风暴）。
值得注意的是，目前有超过10,000颗星链卫星在轨运行——是2019年卫星总数的五倍——导致躲避碰撞的机动次数增加（仅2025年就有300,000次），并可能导致轨道环境不稳定。超过1,500颗星链卫星已经重返大气层，沉积氧化铝。
最新数据显示，由于太阳活动增加，大气辐射正在减少，可能影响航空旅行。有几颗小行星正在接近地球，目前没有一颗构成威胁。
## 星链与新的太空格局 - 摘要
一篇 Hacker News 的讨论集中在 SpaceX 的星链星座及其对近地轨道的影響。虽然星链因提供全球互联网接入而受到赞扬，但其庞大的规模——目前 10,000 颗卫星，计划增加到 40,000 颗——引发了对太空污染和潜在风险的担忧。
对话强调了 SpaceX 因具有成本效益的发射技术和快速迭代而部署这些星座的独特能力。然而，用户们争论着单个实体轻易主导近地轨道的难易程度以及缺乏国际协调的问题。担忧范围从卫星再入大气层对上层大气的影响（特别是氧化铝沉积）到碰撞的可能性（无论是故意的还是意外的），以及建模碎片场的难度。
尽管存在这些担忧，许多人认为近地轨道的特性可以减轻凯斯勒综合症的风险，并且收益大于风险。讨论还涉及其他公司未来可能出现的巨型星座，以及对深思熟虑的监管的需求，这得益于太空访问成本的降低。最终，该帖子反映了对星链的复杂看法：一项技术奇迹，可能带来重大且大部分未知的后果。
## MoQ：适用于复杂环境的拉流式解决方案
Saronic 最近的一篇博文强调了使用 MoQ（消息队列）进行实时视频流传输的优势，尤其是在带宽受限的场景下，例如船上。与不断传输数据的传统“推流式”协议（WebRTC、SRT 等）不同，MoQ 是“拉流式”的——数据仅在观看者*请求*时才发送。
这使得有限带宽得到有效利用。流被分解为可选的“轨道”（不同的分辨率、音频等），观看者只需订阅他们需要的轨道。像 `moq-relay` 这样的系统可以有效地管理对同一轨道的多个请求，必要时可以扩展到全球 CDN。
MoQ 的优先级系统至关重要：它允许基于重要性进行选择性传输，确保关键数据（例如“深海怪兽摄像头”）即使在拥塞期间也能传输。它还避免丢帧，而是将帧排队或降低优先级，以便稍后传递给需要较低延迟的录制设备。
此外，MoQ 支持绑定多个连接（卫星、蜂窝网络、WiFi）以提高可靠性，并利用 QUIC 实现无缝路径迁移。它已被证明在航海应用之外也很有价值，在安全和人工智能驱动的监控方面具有潜力，正如 ooda.video 的深海怪兽检测 OBS 插件所演示的那样。
## On a Boat (moq.dev) - 摘要
这次Hacker News讨论的核心是使用QUIC协议进行可靠、低延迟的视频流传输，尤其是在船舶到岸的连接等复杂环境中。一位用户报告称，通过QUIC成功传输了遥测数据和H.264视频，与TCP相比性能显著提升，并通过帧级FEC和对单个帧的高效确认，避免了因丢包导致的卡顿。
多位评论者讨论了实时视频流传输的挑战以及WebRTC、WebCodecs和WebTransport等潜在替代方案。大家对较新的网络编解码器和传输协议的浏览器支持（尤其是Firefox和Safari）表示担忧，并建议使用polyfill作为解决方法。
对话强调了MoQ（一种基于QUIC的解决方案）的吸引力，因为它具有可组合性，可以将WebRTC的复杂性分解为可重用的层。多位用户正在积极探索或实施基于QUIC的解决方案，用于IP摄像头NVR，称赞其灵活性和控制力优于现有选项。讨论还涉及了与IP组播类似目标的早期尝试历史背景。
聚合文件系统 – 一切皆文件。向Plan 9致敬。
Aggregated File System (AGFS), a modern tribute to the spirit of Plan 9
30 天前
## 聚合文件系统 (AGFS)：统一人工智能代理服务
AGFS 提出了一种管理分布式人工智能代理后端服务的新方法，灵感来自 Plan 9。代理无需为消息队列、数据库、对象存储等单独的 API，AGFS 将它们全部统一为文件系统操作。这意味着代理可以使用熟悉的命令（如 `cat`、`echo` 和 `ls`）与服务交互。
本质上，AGFS 将服务映射到虚拟文件系统：写入“文件”会排队消息，从“文件”读取会检索数据，依此类推。这简化了代理开发，消除了对大量 API 文档的需求，并通过 shell 脚本和管道实现了强大的可组合性。
AGFS 可以通过 `curl` 或 Docker 轻松安装，并通过 shell (`agfs-shell`) 或使用 Linux 上的 FUSE 将其作为本机文件系统挂载来访问。它支持键值存储、消息队列、数据库（通过 Plan 9 风格的接口）和代理心跳监控。示例用例包括简化的 AI 代理任务分发和简化服务之间的数据传输。用类似 shell 的语法编写的脚本（`.as` 文件）可以进一步自动化代理工作流程。
## 聚合文件系统 (AGFS) - 摘要
一个名为 AGFS 的新项目旨在重访 Plan 9 推广的“一切皆文件”概念，为访问各种资源提供统一接口。其核心思想是通过类似文件系统的接口（例如 `cp file /s3fs/bucket/key`）暴露服务，例如 S3 存储。
讨论的重点在于这种方法是否真正有价值。一些人认为这只是构建在较低级别 API 之上的工具，并质疑更通用的 RPC 机制是否更有效，允许资源选择性地采用文件系统接口以及其他接口。另一些人则指出，Objective-Smalltalk 的存储组合器和 Plan 9 自身的实现是先例。
一个关键的争论围绕安全性和性能。支持者认为，通过文件系统接口限制访问，与更广泛的访问（如 Python REPL）相比，为 LLM 代理创建了一条更安全的“自行车道”。然而，怀疑论者质疑性能优势，并认为增加的安全措施微乎其微，尤其是在典型的 shell 工具使用情况下。该项目引发了关于微内核、RPC 以及 AI 代理资源访问替代方案的讨论。
展示 HN：Pgit – 一个由 PostgreSQL 支持的类 Git 命令行界面
Show HN: Pgit – A Git-like CLI backed by PostgreSQL
30 天前
## pgit：PostgreSQL 中的 Git 历史 pgit 是一款新的类 Git 命令行工具，直接将仓库数据存储在 PostgreSQL 数据库中，从而可以使用 SQL 强大的查询功能来查询提交历史。它建立在定制的增量压缩引擎 (pg-xpatch) 之上，pgit 通常比 `git gc --aggressive` 压缩仓库数据*更好*——在 20 个测试仓库（共 273,703 个提交）中，实现了 12 个仓库的压缩优势。 除了存储之外，pgit 还解锁了程序化分析。内置命令，如 `churn`、`coupling` 和 `hotspots`，可以提供有关代码库健康状况的见解，结果以 JSON 或交互式表格的形式提供。对于自定义分析，用户可以利用原始 SQL 查询整个历史记录。 一个关键的演示涉及一个 AI 代理，仅被提示分析 Neon 数据库仓库。在 10 分钟内，该代理成功导入了仓库，执行了 SQL 查询，并生成了一份全面的代码库健康状况报告，识别了关键文件和依赖项。 pgit 并非旨在取代 Git 用于日常开发，而是为了提供一个强大的平台来理解代码库历史，特别是用于自动化分析和 AI 驱动的洞察。该项目是开源的，欢迎贡献。
## Pgit：一个基于PostgreSQL的类Git命令行界面
一个名为Pgit的新项目提供了一个基于PostgreSQL数据库构建的类Git命令行界面。其核心思想是利用SQL的查询能力来处理Git历史记录，从而实现强大的分析并可能为AI代理解锁新的用例。
Pgit并非旨在*取代*Git，而是允许使用SQL查询提交历史，为复杂分析提供优势。初步测试表明，Pgit的数据压缩率与Git的激进压缩相当，但磁盘占用空间更大。
讨论中提到了与Fossil的比较，Fossil是一个类似的版本控制系统，基于SQLite构建。虽然考虑过SQLite，但PostgreSQL因其更好的并发写入处理能力以及对大型仓库（如Linux内核）的导入性能而被选中。一个关键优势是使代理能够直接使用SQL查询Git历史记录，提供它们原本无法获得的上下文。潜在的未来发展包括FUSE提供程序以加快CI/CD速度以及服务器端分支。
## 托尼·霍尔：优雅与影响的遗产 (1938-2024)
查尔斯·安东尼·理查德“托尼”·霍尔，计算机科学领域的一位杰出人物，上周逝世，享年92岁。他的贡献巨大，从广泛使用的快速排序算法——以其效率和优雅的简洁性而闻名——到开创性的公理语义学（“霍尔逻辑”）工作，彻底改变了程序验证。
尽管没有传统的博士学位，霍尔的影响力源于实践编程经验与古典训练的头脑的独特结合，以及以清晰和重点为优先的鲜明写作风格。他倡导一种严格的软件开发方法，影响了几代研究人员和从业者。
除了算法和逻辑之外，霍尔还通过他的通信顺序进程（CSP）对语言设计（影响Algol W并为Ada的并发机制做出贡献）和并发理论产生了重大影响。他始终致力于寻找统一的理论，并解决诸如经过验证的软件之类的重大挑战，在他职业生涯的整个过程中，在牛津大学和后来的微软研究院营造了一种协作的环境。
霍尔不仅是一位杰出的科学家，还是一位才华横溢的导师，激励了无数人。他的遗产不仅在于他的发明，还在于他对智力严谨性、持续学习以及对计算未来独特务实但雄心勃勃的愿景的奉献。
这个Hacker News讨论庆祝托尼·霍尔对计算机科学的影响，起因是他去世的消息。贡献者分享了从霍尔的工作中学习的个人经历，尤其是在牛津大学的1980年代和90年代，重点是像Z记号和CSP（通信顺序进程）这样的形式化规范语言。
对话强调了霍尔对并发和程序验证的影响，一些人回忆起他对Occam和Transputers的工作。一个关键点是霍尔后来对引入空引用概念的后悔，最初为了方便实现而添加，尽管它可能导致错误。参与者争论空指针是否本质上是必要的，并提到了像Rust这样的语言以及Lisp中NIL的历史背景。
该帖子还涉及Java等语言中并发的挑战，以及“契约”在软件设计中的重要性，这是霍尔帮助巩固的概念。总的来说，讨论将霍尔描绘成一个奠基人物，他的思想继续塑造着现代编程实践。
## 为屏幕设计的字体时代来临 几个世纪以来，排版主要关注印刷，屏幕字体仅仅是印刷字体的替代品。然而，随着屏幕阅读的增加，这种情况正在改变。微软认识到这种转变，并委托设计了六种新字体——Constantia、Cambria、Corbel、Candara、Calibri 和 Consolas，这些字体针对其 ClearType 渲染技术进行了优化，有望在未来十年内主导屏幕文本。 ClearType 利用次像素渲染来增强清晰度，克服了屏幕显示以前的限制。最新版本改进了平滑度和间距精度。这些新字体利用了 OpenType 字连，这是以前屏幕设计中不可用的功能，但缺乏多主控等高级技术。 这些字体优先考虑对比度，调整设计以克服抗锯齿造成的模糊效果。虽然 Constantia 在印刷和屏幕上都表现出色，Consolas 在编码方面是优秀的等宽字体，但其他字体如 Cambria 和 Candara 作为现有字体的替代品则不太吸引人。最终，微软的这套字体代表着朝着专门为数字阅读体验而设计的字体迈出的重要一步。
这次黑客新闻的讨论围绕着微软的ClearType字体渲染技术，该技术最初于2005年被评测。虽然当时受到赞扬，特别是对于Constantia和Consolas等字体，但评论员指出由于DirectWrite的采用，ClearType在现代微软应用程序中的表现有所下降——DirectWrite不支持ClearType，导致更简单的灰度像素抗锯齿。
一个关键的争论点集中在次像素渲染（如ClearType）及其与屏幕像素密度（PPI）增加的相关性。一些人认为更高的PPI使其变得不必要，因为人眼在分辨率方面存在极限，而另一些人则认为即使在超过100 PPI的情况下也能看到明显的改进，尤其是在近距离观看时。
用户还讨论了分辨率、GPU负载和电池寿命之间的权衡。许多人对无法轻松禁用次像素渲染（当它看起来不理想时）表示沮丧，并且有人指出MacOS已经完全移除了它。最后，一个相关的讨论涉及网站加载自定义字体时令人不快的“无样式文本闪烁” (FOUT) 问题。
## WCPU-1：从模拟到（令人谦卑的）现实
本文详细介绍了构建WCPU-1物理原型所遇到的挑战，WCPU-1是一款先前在Logisim-Evolution中模拟的自制8位计算机。尽管最初充满信心，但构建过程出乎意料地困难，充满了布线错误、组件故障和时序问题——与干净的模拟形成了鲜明对比。
该项目包括从PCBWay设计和订购定制PCB（包括EEPROM程序员、寄存器板和控制模块），以及面包板组件。问题包括发货错误的PCB、倒装的LED、浮动地址线和故障的EEPROM。一个关键的修复是通过时钟信号门控RAM写入来解决时序冲突。
尽管遭遇挫折，这台计算机*可以工作*——以1MHz的速度运行并执行测试程序。然而，它缺乏输出功能，并且依赖Arduino进行程序加载，这两点都有待改进。作者计划将设计整合到单个PCB上，解决剩余问题，并最终开始进行更高级的WCPU-2的工作，可能首先使用FPGA原型设计。整个项目将在整理好后在Github上开源。
威尔·沃伦详细介绍了他的自制CPU项目，相关文档在他的网站上。该项目目前处于第四阶段，涉及使用容易获得的元件在面包板上构建CPU——这是一个刻意的选择，旨在避免复杂的制造过程，并采用动手实践的方法。
讨论强调了使用分立元件构建的挑战，包括“中等集成度”IC的稀缺以及繁琐的接线工作。其他爱好者分享了技巧，例如使用两个’574芯片来实现闪烁灯和三态总线驱动，并回忆起类似的项目，回忆起计算机的早期时代，那时编程涉及手动开关、穿孔卡，甚至物理重新接线机器。
许多评论者赞赏其中付出的奉献和“第二种乐趣”，而另一些人则提倡使用模拟或基于FPGA的设计来避免实际障碍。该项目引发了关于CPU设计历史、微代码以及克服固有复杂性，将定制计算机变为现实的乐趣的对话。