研究人员成功恢复并运行了从阿波罗制导计算机（AGC）旧“绳索”存储模块中抢救的数据中的原始软件。**Sundial-E**，相当于登月舱的Aurora 12的指令舱版本，包含完整的AGC测试套件和指令舱子系统测试。**Sundance**，来自阿波罗9号——首次在太空中的登月舱测试——正在从回收的模块中重建，并正在努力获取剩余部件。 最重要的是，**Retread 50**，*第一个*可用的Block II AGC程序，尽管绳索受损，但已被恢复。团队利用奇偶校验位进行修复，成功在现代AGC上运行了Retread 50，并确认它通过了所有原始测试。 这些恢复成果，记录在GitHub上，代表着数字考古学的卓越成就，为太空飞行早期计算提供了宝贵的见解。
每日HackerNews RSS
一个黑客新闻的讨论强调了CuriousMarc的迷人“阿波罗制导计算机修复”视频系列。用户称赞该系列是对已经熟悉阿波罗历史的人的深入研究，特别是对那些具有电子、计算机科学和无线电通信背景的人有吸引力。它被誉为YouTube上一种独特且有价值的内容。
对话延伸到进一步学习的书籍推荐：“数字阿波罗”（人机交互与系统工程）、“Sunburst and Luminary”（一位软件工程师的回忆录）以及Cox和Murray的“阿波罗”（项目管理与工程）。
评论者还深入探讨了早期计算的历史，争论使用继电器与半导体构建计算机的可行性，并强调了早期存储解决方案（如绳索存储）的巧妙之处。讨论触及了AGC所代表的令人难以置信的工程壮举，将其计算能力与现代设备（如USB-C到HDMI电缆）进行对比。
## 玻璃炮：高性能负载生成器 玻璃炮通过绕过传统的负载测试方法，直接利用Linux内核的`io_uring`接口，实现了卓越的I/O性能。与依赖于通过`epoll`进行重复系统调用的`wrk`和`hey`等工具不同，玻璃炮采用共享内存环缓冲区进行提交和完成，从而大大减少了上下文切换。 其架构包含一个主线程生成多个工作线程，每个线程拥有独立的`io_uring`环、连接和预构建的请求缓冲区——消除了工作线程之间的通信和锁。主要特性包括预注册的缓冲区池以实现零拷贝接收，“多射击”接收以实现连续数据流，以及请求流水线以最大化吞吐量。 每个`io_uring`提交都包含用户数据打包，其中包含操作类型、生成计数器（用于处理重新连接）和连接索引。核心循环有效地批量处理完成项（最多2048个），然后再提交新的操作，从而最大限度地减少内核转换。这种批量处理扩展到流水线填充，确保请求始终预构建并准备好发送。 最终，玻璃炮的设计优先考虑最小化系统调用并最大化内核级处理，从而产生显著更高的性能。
## Hacker News 讨论：Linux 负载生成器 (gcannon.org)
一场 Hacker News 讨论围绕着一个新的 Linux 负载生成器 gcannon.org，宣称具有“极高的性能”。最初的批评集中在其缺乏支持这些声明的基准测试。开发者 (MDA2AV) 承认了这一点，并解释说他们经常在内部使用该工具，但尚未优先进行公开基准测试，承认这些测试可能存在偏见。
对话延伸到与其他工具（如 `sockbiter` 和 `oha`）的比较。一位用户在修复 Lua 错误后成功运行了 `sockbiter`，但注意到异常高的吞吐量可能是由于该工具没有等待服务器响应——实际上衡量的是生成器的输出，而不是服务器性能。另一位用户更喜欢 `oha`，而另一位则反驳说它速度慢，推荐 `h2load` 以支持 HTTP/2/3。
一个关键点是异步 I/O (io_uring) 对延迟测量影响，质疑其准确性。回复澄清说，虽然计时不精确，但延迟的一致性对于有意义的基准测试至关重要，尤其是在高负载下。这场讨论突出了负载测试的复杂性以及理解*正在测量什么*的重要性。
Judoscale，Heroku的长期合作伙伴，对平台最近的沟通表示困惑和担忧。Heroku宣布转向“维持工程”模式——优先考虑稳定性而非新功能——并停止提供企业合同。然而，同时发布的功能（更大的slug尺寸、CLI重建）与这种“维护模式”的暗示相矛盾。 核心问题是缺乏透明度。Judoscale敦促Heroku明确其未来发展方向：是平台的持续演进，尽管速度较慢，还是逐渐退出？开发者渴望一个直接的解释和一个公开路线图，即使它只详细说明维护工作。 这封信强调了开发者普遍的焦虑，许多团队已经开始计划迁移，因为存在不确定性。Judoscale强调了他们长期以来对Heroku的支持，并恳求Heroku澄清其商业意图——是专注于直接客户，还是为最终退出平台做准备——以便社区能够相应地规划。
## Heroku 当前状态：摘要
一篇近期文章引发了 Hacker News 上关于 Heroku 发展方向的讨论。普遍的看法是管理层发生了变化，工程团队现在在产品管理监督移除后，很大程度上控制着平台的开发。这引发了猜测，工程师们正在推进之前因公司限制而被阻止的改进。
然而，这种“维护模式”不一定意味着负面——新的功能仍在出现，可能由大型企业客户的需求驱动。许多用户表达了对 Heroku 的失望，认为 Salesforce 的收购是一个转折点。
Fly.io、DigitalOcean（搭配 Cuber）和 Northflank 等替代方案正在获得关注，并因其更低的成本和更好的性能而受到赞扬。虽然 Heroku 曾经提供无与伦比的部署便利性，但许多人认为这种体验已经下降。尽管面临挑战，一些人仍然重视 Heroku 的简单性，而另一些人则认为鉴于 AWS、GCP 和 Azure 在云网络领域的统治地位，Heroku 的生存可能性不大。
## graph-info：基础设施可视化与监控
graph-info 自动发现并可视化您的基础设施，提供服务、数据库和存储的实时交互式图形。它需要最少的配置——只需将其指向您的堆栈（通过 Docker socket 或 Kubernetes 集群），它就会自动发现所有内容，并显示实时健康监控。
**主要特性：**
* **自动发现：** 从 Docker、Kubernetes、PostgreSQL、MongoDB、MySQL、Redis、Elasticsearch、S3/MinIO 和 HTTP 服务中检测基础设施。
* **交互式图形：** 提供泳道布局，具有平移/缩放、过滤和搜索功能。
* **实时健康状态：** 通过 WebSocket 提供每 5 秒更新一次的状态信息。
* **可扩展性：** 通过 YAML 配置文件支持自定义连接，用于未自动发现的服务。
**入门：**
可以通过 Docker Compose 或直接运行容器进行部署。挂载 Docker socket 是最简单的设置。部署后，前端可在 `http://localhost:3000` 访问。
**重要提示：** 此工具仅用于授权的基础设施监控。未经授权的扫描是被禁止的。
更多详细信息，包括贡献指南和高级配置，请访问 [GitHub 仓库](https://github.com/guilherme-grimm/graph-go)。
## Graph-go：可视化系统连接
开发者 devGrimm 分享了 **graph-go** 的更新，这是一款用于可视化系统及其组件连接方式的工具——尤其是在 Docker 环境中。 最初创建该工具是为了帮助开发者理解复杂的系统关系，现在 graph-go 具有**自动发现**连接的功能，最大限度地减少了手动配置的需求。
该工具提供了一个用户界面，可以轻松查看您的系统环境，通过 Docker 网络实现。 未来的开发计划包括支持 Kubernetes 和其他编排器，从而扩展其在 Docker 之外的用途。
devGrimm 欢迎贡献，并鼓励用户报告遇到的任何问题。 另一位用户表达了使用 graph-go 导航复杂遗留集群的兴奋之情，突显了它对系统管理员和开发人员的潜在价值。
对不起。
## Hacker News 讨论：C++ 中析构函数抛出异常
一篇关于 C++ 析构函数抛出异常时会发生什么情况的文章在 Hacker News 上引发了争论。核心讨论围绕着对这种特定且可能罕见情况的了解是否对资深 C++ 开发者至关重要。
一些人认为这无关紧要的“语言版本特定细节”，在需要时可以轻松查阅，并且浪费面试时间。另一些人则认为这是测试 C++ 专业知识的有效方法，强调理解析构函数是该语言的基础——引用像《Effective C++》这样涵盖该主题的书籍。
对话涉及对象销毁过程中异常处理的复杂性，特别是双重异常场景的灾难性后果（析构函数清理期间发生的异常导致 `std::terminate`）。 许多人同意*避免*在析构函数中抛出异常是最佳实践，但对于深入理解如果发生异常的后果的重要性存在分歧。 一些评论员也指出，这个级别的细节对于编译器/调试器开发者比典型的应用程序工程师更相关。
启用 JavaScript 和 Cookie 以继续。
对不起。
## Solod (So): Go 到 C 转换器 Solod (So) 是一种新工具，可将 Go 代码的一个子集直接转换为可读的 C11 代码，提供一种使用 Go 语法和类型安全的系统编程方法。它具有零运行时开销——没有垃圾回收或隐藏分配——默认使用栈分配，并可选择使用堆。 So 能够实现与 C 代码的无缝原生互操作，无需 CGO，允许在 So 和 C 函数之间进行调用。它支持 Go 的核心特性，如结构体、方法、接口和切片，同时为了简单起见，省略了通道、协程、闭包和泛型。 你可以使用标准的 Go 工具（linting、测试、LSP）来处理 So 项目。过程包括使用 So 包编写 Go 代码，然后使用 `so` 命令将其转换为 C。编译可以使用 GCC、Clang 或 Zig 完成，目前支持 Linux、macOS 和 Windows（仅核心语言）。 虽然仍在开发中，So 旨在为系统编程提供一种快速高效的替代方案，利用 Go 的熟悉性，同时提供 C 的性能和控制。
## Solod：一个编译为C的Go子集
Solod是一个新项目，旨在提供Go编程语言的一个子集，可以直接翻译成C代码（github.com/solod-dev）。目标并非完全兼容Go，而是找到一个平衡点，提供Go的语法和空间内存安全，同时避免像goroutine、channel、closure和泛型等特性。
讨论的中心在于权衡。一些人质疑其价值主张，认为如果目标是C互操作性，直接使用C更简单。另一些人指出，Solod偏离标准Go语义——特别是块作用域的`defer`，而不是Go的函数作用域版本——引发了对测试和可靠性的担忧。
然而，一些开发者看到了潜力，尤其是在Go的并发特性不必要，并且需要直接C集成的情况下。有人将其与Vlang和tinyGo等其他项目进行比较，并建议将其与Neco等协程库集成。最终，该项目似乎是由利用Go语法在Go运行时不适用的环境中的愿望驱动的。
## VOID：逼真视频物体与交互移除
VOID是一个新的AI系统，能够从视频中移除物体，并逼真地模拟移除后的后果——例如，吉他手被移除时吉他会掉落。VOID基于CogVideoX，利用两次传递的Transformer流程进行高质量的视频修复，并以感知交互的掩码为条件。
**工作原理：** VOID首先生成掩码，识别要移除的物体以及受其存在影响的区域（例如，掉落的物体）。然后，它在两次推理过程中使用这些掩码：Pass 1执行基础修复，而Pass 2使用扭曲噪声来优化时间一致性。
**关键要求：** VOID需要大量的计算资源——需要具有40GB+ VRAM的GPU（例如A100）。它还需要安装SAM2等依赖项，并设置Gemini API密钥以生成掩码。
**数据与训练：** 虽然提供预训练模型，但由于许可问题，VOID的训练数据并未直接发布。相反，提供了使用HUMOTO和Kubic生成训练数据（创建包含和不包含物体的反事实视频）的代码。
**可用性：** 模型和代码可在HuggingFace和GitHub上获得，从而促进社区贡献和进一步开发。 ([https://arxiv.org/abs/2604.02296](https://arxiv.org/abs/2604.02296))
## VOID：AI驱动的视频编辑 – 摘要
Netflix发布了“VOID”，一个开源的AI工具，可以从视频中移除物体和互动。通过移除壶铃或人物等示例进行演示，VOID引发了对其潜在应用（包括积极的和令人担忧的）的讨论。
用户们趣味性地设想了修改电影情节（例如“黑镜：崩坏”的编辑）或移除现有内容中不需要的元素（例如“加菲猫不见加菲猫”）的情景。然而，讨论迅速转向该工具的潜在滥用。担忧集中在审查、易于制造深度伪造以及操纵现实用于政治或恶意目的的能力上。
虽然一些人认为随着技术的进步，艺术控制将被重新获得（类似于Stable Diffusion），但另一些人则担心一个“反乌托邦的未来”，即镜头可以被轻易地修改以适应各种议程。尽管存在这些担忧，许多人也承认该工具对电影制作人、VFX工作和老内容修复的潜在益处，可能降低制作成本并实现以前不可能实现的镜头。该工具凸显了关于日益强大的AI驱动的视频操纵的伦理影响的日益激烈的争论。
## 将 Go 标准库移植到 C：字节与字符串 该项目旨在用 C 重现 Go 的一部分，重点是性能并消除 Go 运行时。在成功移植 `io` 包之后，重点转移到 Go 的核心 `bytes` 和 `strings` 包。 移植纯函数，例如 `math/bits` 和 `unicode/utf8` 中的函数，相对简单，但 Go 和 C 之间的运算符优先级差异需要仔细注意。更复杂的是像 `Repeat` 这样的函数，它需要引入分配器接口——模仿 Zig 和 Odin 等语言的方法——用于显式内存管理。这允许灵活的分配方法并有助于调试。 基准测试显示出普遍积极的结果，C 实现通常比 Go 对应实现快 1.5-4 倍。然而，`Index` 最初表现不佳，直到利用 `memchr` 进行优化的子字符串搜索。`strings.Builder` 的显著性能提升来自于确保函数内联并优化返回值结构，以避免不必要的内存访问。 该项目强调了显式内存控制的好处，并证明了，通过仔细优化，C 在许多常见操作上可以实现与 Go 相当或更高的性能。移植的包在 Solod 中可用，Solod 是一种允许将 Go 代码翻译成 C 的工具。未来的工作将集中于移植 `time` 包。
一个黑客新闻的讨论围绕着将Go的`strings`包移植到C的尝试，结果性能几乎与原始Go实现相匹配。作者在C版本利用`memchr`后停止了优化，因为它仍然略慢于Go的基于汇编的方法，这可能是由于调用C库的开销造成的。
对话深入探讨了Go的历史，争论其最初的实现是否是C的转译器（它*用*C编写，但独立编译）。 许多评论员讨论了编程语言的谱系，引用Plan 9的Alef和Limbo作为Go有影响力的前身，但对哪个联系更强存在不同意见。
最后，有一个略带幽默的说明，强调了在2026年看到“没有AI编写”的代码的罕见程度。这次讨论展示了技术细节、历史背景和编程社区内略带玩笑的辩论的融合。