启用 JavaScript 和 Cookie 以继续。
每日HackerNews RSS
黑客新闻 新的 | 过去的 | 评论 | 提问 | 展示 | 招聘 | 提交 登录
开源游戏逻辑、美术和Spine动画 – SuperWEIRD Game Kit (ludenio.itch.io)
20点 由 gamescodedogs 1天前 | 隐藏 | 过去的 | 收藏 | 2评论
gamescodedogs 1天前 | 下一个 [–]
包含6种不同的视觉风格 回复
annaglotova 1天前 | 上一个 [–]
是的！ 回复
考虑申请YC冬季2026批次！申请截止至11月10日
指南 | 常见问题 | 列表 | API | 安全 | 法律 | 申请YC | 联系
搜索：
## 杠杆点：小改变带来大结果
唐内拉·米多斯探讨了“杠杆点”的概念——复杂系统内可以产生重大变化的微小干预点。这些点并非总是显而易见的；我们常常努力的方向是*错误*的，尽管我们认识到其潜在影响。
米多斯概述了杠杆点的等级结构，按有效性排序。较低级别的干预措施，例如调整数字（税收、补贴），易于处理但效果有限。更高的杠杆作用在于改变系统目标、结构，或者，最有力的是，潜在的*范式*——塑造系统的基本信念。
真正的系统变革需要转变视角。关键在于认识到没有单一的世界观掌握所有答案，并拥抱灵活开放的心态。虽然识别杠杆点具有挑战性，并且对变革的阻力很强，但最大的影响来自于放弃固定的信念，并允许系统内的自我组织和演化。
最终，掌握系统并非关于强行操纵，而是关于策略性地放弃控制，并拥抱变革性变化的潜力。
一个黑客新闻的讨论围绕唐内拉·米多斯1999年的文章《杠杆点：干预系统的地点》。文章探讨了改进复杂系统的有效策略，认为仅仅优化组件通常不如解决系统底层设计和假设更有影响力。
评论者将这些概念与IT和云系统管理联系起来，分享了优化缺陷系统却徒劳无功的经验。他们强调了质疑基础范式，而不仅仅是调整参数的重要性。
几位用户贡献了相关的原则：为意外情况做计划，偏爱可逆的变化，采取渐进的步骤，以及增加选择/可能性。提到了詹姆斯·C·斯科特的《像国家一样看见》，和盖尔定律，强化了适应性、小规模干预的理念。作者也被指出是《增长的极限》的贡献者。
## Agent-o-rama：适用于 JVM 的可扩展 LLM 代理
Agent-o-rama 是一个全新的开源库，用于构建可扩展且具有状态的 LLM 代理，专为 Java 和 Clojure 开发人员设计。它解决了 JVM 生态系统中一个差距——目前由 Python AI 工具主导——它将类似 LangGraph 和 LangSmith 的功能（如结构化代理图、追踪和评估）直接带到这些语言中。
该库允许开发人员将代理定义为函数图，自动捕获详细的追踪信息，并提供一个 Web UI 用于实验、评估和监控（包括延迟和 token 使用量）。它支持流式传输，并与现有工具（如数据库和 API）无缝集成，同时将所有数据保留在您的基础设施中以确保隐私和控制。
Agent-o-rama 部署在“Rama”集群上，提供从单节点本地设置到数千个节点的扩展能力（需要商业许可）。提供了一个完整的示例代理（研究重点），展示了一个简单的开发流程。该项目旨在抽象 Rama 分布式编程模型的复杂性，使其力量可用于 LLM 代理开发，同时也作为 Rama 实际应用的一个示例。
可以通过邮件列表和 Slack 频道获取资源和社区支持。
Agent-o-rama 是一个由 Apache Storm 团队（Red Planet Labs）创建的用于构建、追踪、评估和监控 LLM 代理的新型 Java/Clojure 工具。它与 JetBrains 的 Koog 等工具不同，提供了具有内置部署、扩展和全面集成功能的分布式执行模型——Koog 缺乏这些功能。
具体来说，Agent-o-rama 提供持久的、高性能的存储，实验/评估工具，横向扩展能力，以及详细的可观察性（包括“首次标记时间”等指标），并能根据元数据自动拆分图表。
虽然不是开源的，但开发者强调透明度，允许用户通过 UI 和 API 检查数据和计算。支持通过 S3 等提供商进行备份，并且他们的网站（redplanetlabs.com）上有详细的文档。项目负责人正在 Hacker News 上积极回答问题。
## 人工智能：历史重演？ 1995年，新兴的互联网既引发了狂热乐观，也招致了怀疑的否定——有人预测它将变革商业，也有人认为它只是昙花一现。今天，人工智能正在引发类似的争论。就像早期的互联网预测大相径庭（谁能预测到Airbnb或在线约会？），当前对大规模失业或乌托邦式自动化的预测很可能是不完整的。 关键在于理解*需求*。人工智能，像过去的科技一样，很可能会提高生产力，最初创造需求，甚至*增加*就业——这种现象被称为杰文斯悖论。然而，随着需求的饱和，就业最终会停滞，就像纺织业的情况一样。具有持续的、未满足的需求的行业，例如汽车行业，更有可能保持增长。 当前的人工智能繁荣与互联网泡沫如出一辙：炒作、虚高估值和大量基础设施投资。虽然许多初创公司会失败，但底层基础设施——数据中心、芯片——对于未来的发展至关重要。 最终，人工智能的影响不会是简单的工作岗位增加与减少的等式。它将重塑*工作的内容*，创造我们目前无法想象的角色，就像互联网催生了网红和应用程序开发者一样。就像1995年一样，预测具体细节是不可能的，但我们的AI未来无疑正在加载。
## AI 当前阶段：大型机时代，而非拨号时代
这场 Hacker News 的讨论集中在 AI 是否正经历像早期互联网那样的革命性阶段，或者这种比较是否具有误导性。许多评论者认为“拨号”的比喻不准确；相反，AI 正处于“大型机”时期——其特点是巨大的、集中的计算能力由少数大型公司控制。目前，访问是通过像 OpenAI 和 Google 这样的服务“租赁”的，类似于大型机上的分时共享。
争论的焦点在于未来是否可能出现分布式、“个人计算”模式，拥有更小、本地的 AI 模型。一些人担心监管可能会阻止这种情况，而另一些人则认为去中心化架构能够提供弹性和创新。人们对依赖云连接以及潜在的集中控制表示担忧。
一个关键点是，虽然 AI *可能* 能够赋予个人创建定制工具的能力，但当前对大型模型和基础设施支出的关注引发了人们对长期可持续性和可访问性的质疑。这场讨论凸显了与过去技术繁荣的相似之处，例如互联网泡沫和铁路狂潮，并质疑当前的投资是否能带来持久的利益，或者只是迅速贬值。最终，这场对话反映了人们对 AI 发展轨迹及其对劳动力和社会潜在影响的不确定性。
## FreakWAN：基于LoRa的独立网络 FreakWAN是一个开源项目，正在构建一个基于LoRa的无线网络，独立于蜂窝网络和互联网基础设施。其主要目标是在连接受限或紧急情况下，为区域提供一个具有弹性的分布式聊天系统——包括明文和加密两种形式，并为传感器数据收集和家庭自动化等其他应用建立一个强大的协议，克服典型的LoRa范围限制。 该网络利用广播路由，并具有可配置的重传、消息确认以及基于密钥的聊天群组的对称AES加密等功能。节点协作中继加密消息，即使没有解密能力。设备通过“HELLO”消息发现附近节点，并通过占空比跟踪和本地消息存储来管理带宽使用。 FreakWAN目前在基于ESP32的设备（LILYGO TTGO和T-WATCH）上使用MicroPython实现，但设计上可适应其他具有SX1276/SX1262 LoRa芯片的硬件。IRC和Telegram机器人集成等功能也可使用。该项目支持通过自定义压缩格式传输图像，并包含电池管理功能。代码是免费提供的，鼓励社区开发和定制。
## S1130：一个 .NET Core IBM 1130 模拟器 S1130 是一个跨平台（.NET Core）的 IBM 1130 计算机模拟器，支持 Linux、Mac 和 Windows。它具有完整的系统模拟，包括功能齐全的 CPU 指令集、2501 卡片读取器模拟（具有完整的测试覆盖率）以及 2310 磁盘驱动器的部分实现。 该项目拥有强大的测试套件，包含 335 多个单元测试，完成时间小于 2 秒，并强调测试驱动开发、全面的文档和强大的错误处理。 S1130 包含一个后端 Web API（通过 `dotnet run` 运行）和一个可选的 React 前端（通过 `npm start` 运行）。Docker 支持也可能可用。欢迎贡献 – 请参阅 `CONTRIBUTING.md` 获取指南。该项目在 GitHub 上可用：[https://github.com/semuhphor/S1130](https://github.com/semuhphor/S1130)。
一个针对IBM 1130计算机的C#模拟器已在Hacker News上分享（github.com/semuhphor）。最初的帖子引发了对其功能性的提问——是否可以启动，是否需要操作系统，以及是否支持运行现有的IBM 1130程序。
评论者指出该项目似乎是一个正在进行中的工作，可能是一个尚未完全 intended for public viewing 的开发分支。 几位用户分享了他们与IBM 1130相关的怀旧经历，回忆起它使用穿孔卡，内存有限以及Fortran编程。
关于代码质量的讨论浮现，一位评论员认为它看起来像是大型语言模型（“LLM slop”）的输出，引发了关于区分较旧的人工编写代码与现代AI生成代码的困难的讨论。该项目有超过六年的提交历史。
## 纽约超级抽水系统：消防革命
在20世纪60年代初，纽约市面临日益严峻的火灾挑战，原因是建筑物越来越高，供水也越来越紧张。1963年斯塔滕岛发生的毁灭性“黑色星期六”大火，由于干旱条件而加剧，促使城市投资于一项突破性解决方案：麦克超级抽水系统。
这并非一辆单独的卡车，而是一个由一个巨大的、由二战时期纳皮尔-德尔塔柴油发动机提供动力的抽水单元为中心的五车编队——该发动机功率高达2400马力。该系统可以从多个水源取水，以高压输送超过8800加仑/分钟的水，并使用专用炮塔将水射至600英尺以上。
从1965年到20世纪80年代初，超级抽水系统响应了超过2200次出勤，证明了其卓越的可靠性。它为无数消防员提供水源，并扑灭了巨大的火灾，通常每分钟移动近70,000磅的水。尽管最终因技术进步而过时，但超级抽水系统仍然是创新工程的证明，也是纽约市消防历史的重要篇章，现在被保存在密歇根州的一个博物馆中。
## Mack 超级泵车与消防技术：摘要
这次黑客新闻的讨论围绕着 Mack 超级泵车展开，这是一种由纽约消防局在 1960 年代使用的、由机车发动机驱动的强大消防车。它能够每分钟泵出高达 8,800 加仑的水，是工程学的奇迹，但最终被使用多个标准消防车、更灵活的系统所取代。
对话延伸到关于现代消防技术的讨论，包括供水的重要性、泵送能力以及压力和流量之间的权衡。贡献者分享了从依赖油罐车接力的乡村消防部门到城市老旧基础设施带来的挑战等经验。
除了超级泵车之外，该帖子还探讨了相关技术，例如芝加哥使用的“炮塔车”、用于特殊危险情况的专用泵（油井火灾、化工厂）以及 Napier Deltic 等发动机的迷人工程设计。一个反复出现的主题是对过去复杂、通常视觉上引人注目的机械的怀旧，与现代系统的效率和计算机化形成对比。
## htmx 4.0：重大重建即将到来
尽管之前有其他声明，Carson Gross 宣布 htmx 4.0 正在开发中，重点是内部简化和长期稳定性。 这不是以功能为驱动的更新，而是基于 ‘fixi.js’ 项目和五年 htmx 支持经验的根本性重建。
主要变化包括用 `fetch()` 替换 XMLHttpRequest 作为核心 AJAX 功能——这将影响事件模型——并消除隐式属性继承，需要显式使用 `:inherited` 修饰符。 历史记录支持也将进行改进，将不再使用本地 DOM 快照缓存，而是使用网络请求来恢复内容（可通过扩展进行可选缓存）。
虽然这是一次重大升级，但 htmx 的核心功能，如 `hx-get`、`hx-post` 和 `hx-swap` 将基本保持不变。 新功能包括对流式响应和 SSE 的原生支持、通过 “idiomorph” 进行 DOM 形变、显式 `<partial>` 标签支持、改进的视图过渡、稳定的事件顺序以及增强的扩展能力。
团队的目标是在 2026 年初至年中发布，并在 2027 年初左右将 4.0 版本设为 ‘最新’ 版本。 htmx 2.0 将无限期地保持支持，并提供扩展来简化过渡。
维基百科就“加沙种族灭绝”页面爆发争端，吉米·威尔士介入。
Wikipedia row erupts as Jimmy Wales intervenes on 'Gaza genocide' page
8 天前
维基百科创始人吉米·威尔士介入了一篇关于“加沙种族灭绝”文章的争议，表示担忧该文章违反了平台的 neutrality（中立）政策。该文章目前以维基百科的口吻声称以色列正在加沙实施种族灭绝——威尔士认为这一说法“极具争议”，不适合维基百科明确断言。
威尔士认为该文章未能准确总结所有相关观点，而是“选边站队”于一场持续的争议中。他的介入引发了其他编辑的反弹，一些人指责他屈服于政治压力或越权，因为他只是众多编辑之一。
威尔士澄清他并非否认种族灭绝*是否*正在发生，而是维基百科不应该*决定*这个问题。目前该文章已被保护，禁止编辑，辩论仍在继续，尽管专家和组织如国际特赦组织得出结论，以色列*正在*实施种族灭绝——以色列对此断然否认。
## 维基百科编辑争议与资金问题
最近在Hacker News上出现了一场讨论，焦点是吉米·威尔士对“加沙种族灭绝”维基百科页面的干预，他倡导更中立的语气。虽然一些报道称他直接编辑或锁定了该页面，但评论澄清他只是在讨论页面上表达了他的观点。
讨论迅速扩大到对维基百科的资金和中立性的担忧。一位用户声称捐款资金并非完全用于维护网站，尽管维基百科拥有大量捐赠，这导致人们对其动机产生怀疑。
关于“种族灭绝”的定义以及维基百科是否应该在这一术语存在争议时采取明确立场，进一步的争论浮出水面，尤其是在考虑到潜在的政治压力——包括国会对维基百科编辑人员涉嫌对以色列存在偏见的调查。一些评论员指出，当前美国政府试图压制批评的模式。
最终，许多人同意维基百科的优势在于其中立性和策划方法，这与仅仅依赖LLM获取信息的潜在陷阱形成对比。这次对话凸显了在政治敏感话题上保持客观性的挑战。
受对互联网档案（Internet Archive）法律挑战的担忧驱动，一个项目被启动以全面存档MP3.com上的音乐。利用互联网档案的“mp3.com Rescue Barge”（960.6 GB）以及之前从时光机（Wayback Machine）收集的链接，共收集了1.78TB的音频数据。
该过程涉及克服存储限制，并最终在朋友的帮助下将数据整合到3TB驱动器上。一个主要障碍是整理这个庞大的音乐库——最初是一个混乱的文件夹结构，通过使用Winamp 5 (WACUP)来索引和导出包含533,046首歌曲元数据（艺术家、曲目名称、URL、日期）的详细CSV文件来解决。
现在以CSV和Excel格式提供的结果数据集，允许用户轻松搜索和浏览存档的MP3.com音乐。虽然不完美，但该项目旨在保存这段数字音乐历史，并有可能在未来将其与存档的艺术家页面集成。创建者承认潜在的改进，例如编码器识别以及为CSV提供更易于机器读取的格式。