## 十年断连：我为何离开流媒体并重回拥有音乐 十年前，一次与Spotify的糟糕体验——因为在“未授权”设备上无法播放个人MP3文件——促使我彻底改变了音乐消费方式。我离开了流媒体，转而*购买*专辑，这个决定我从未后悔。 虽然在流媒体主导的世界里有些不便，但拥有数字音乐库提供的自由是流媒体无法比拟的：对访问的控制、对政策变化的保护以及可移植性。尽管iTunes Store笨重，以及Apple Music等应用中个人音乐库支持的衰落带来了挑战，但iTunes Match和Plex等工具仍在维持着这种方式。 除了自由之外，直接购买音乐比流媒体版税更能有效地支持艺术家，并且可以轻松接触到经常在主流平台上缺席的独立音乐人。虽然缺乏流媒体的算法推荐，但这种方式培养了一种更精选、更用心的聆听体验——鼓励专辑欣赏和通过人际连接而非算法进行发现。这是一种正在消失的习惯，但对于一位忠实的音乐爱好者来说，拥有音乐的好处是值得的。
每日HackerNews RSS
## 维护音乐库：十年之后
这次Hacker News讨论的核心是，尽管流媒体服务普及，但拥有个人音乐库仍然具有持久的吸引力。许多用户，其中一些自2000年初就开始维护音乐库（达到数万首曲目），热烈捍卫这种做法。
主要原因包括：保留对流媒体平台无法获取的音乐的访问权，享受策展的乐趣，以及避免内容从服务中消失的风险。一些用户使用Apple Music/iTunes Match进行同步和云访问，而另一些用户则更喜欢Jellyfin等自托管解决方案或简单的NFS共享。
Bandcamp经常被推荐为购买无DRM音乐的来源。虽然承认流媒体的便利性，但许多人更看重拥有音乐所带来的控制权和持久性，通常会将收藏备份到多个驱动器和服务上。这次对话凸显了一个致力于维护和享受个人精选音乐库的社区，即使在流媒体时代。
Guideline 已加入 Gusto！关于我们最近收购的常见问题 | Guideline 帮助中心版权所有 © 2023, Intercom, Inc. ([email protected])，保留字体名称“Montserrat”。此字体软件根据 SIL Open Font License 版本 1.1 许可。版权所有 © 2023, Intercom, Inc. ([email protected])，保留字体名称“Inter”。此字体软件根据 SIL Open Font License 版本 1.1 许可。
## Gusto 收购 Guideline：摘要
Guideline，一家401k服务提供商，已被Gusto收购。这引起了一些用户的担忧，特别是那些之前雇主使用Guideline但*不*使用Gusto进行工资发放的用户。这些用户现在正被转移到名为Accrue 401k的独立实体，这个名称对很多人来说很陌生，并且由于未经请求的电子邮件将他们引导到一个新的登录门户，引发了钓鱼方面的担忧。
讨论强调了更广泛的401k管理问题，包括资金转出的困难（特别是使用“后门罗斯”策略时），过时的转账流程，以及不同提供商之间的费用差异。一些用户建议转到Vanguard或Fidelity，而另一些用户则指出，保留提供特定低成本基金的计划可能具有潜在好处。
人们也对Guideline过去的运营方式和Gusto的客户支持提出了担忧。此次收购的沟通方式因缺乏关于Accrue 401k的透明度而受到批评。总而言之，这种情况凸显了驾驭401k环境的复杂性和潜在陷阱。
启用 JavaScript 和 Cookie 以继续。
黑客新闻 新的 | 过去的 | 评论 | 提问 | 展示 | 招聘 | 提交 登录
开源游戏逻辑、美术和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 将无限期地保持支持，并提供扩展来简化过渡。