请启用 JavaScript 并关闭所有广告拦截器。
每日HackerNews RSS
抱歉。
旧金山的一位爱彼迎（Airbnb）房东肖恩·多诺万（Sean Donovan）对估值20亿美元的机器人初创公司“Bot Company”提起诉讼，指控该公司员工以虚假名义租用他的住所，并进行秘密原型机测试。多诺万发现证据表明，这些房客利用他的房产来训练家用机器人，导致他的家具、电器和墙壁受到严重损坏。 多诺万寻求超过1.2万美元的赔偿金及收入损失。调查显示，他并非唯一的受害者；当地其他房东也报告了类似的财产损失，且均指向同一批与该初创公司有关的房客。尽管该公司的使命是制造协助家务的机器人，但房东们批评其员工使用欺骗手段，并指出具有讽刺意味的是，这些机器人的设计初衷本是为了协助房产打理等工作。 虽然“Bot Company”对这些指控保持沉默，但这些事件凸显了一个日益严重的问题：商业实体利用住宅租赁进行未经授权的工业测试，而房东往往被迫承担维修费用。
针对硅谷初创公司“The Bot Company”的一起诉讼指出，该公司员工以虚假理由租用了一间爱彼迎（Airbnb）民宿，并在未获授权的情况下进行原型机器人的测试。房主声称，该公司的机器人造成了数千美元的财产损失，包括家具刮伤和设施损坏，并将房屋弄得一片狼藉。
此事在Hacker News上引发了热烈讨论，批评者谴责该初创公司“快速行动并打破陈规”的思维方式道德破产且技术无能。评论者认为，该公司本应使用受控的实验室环境或模拟房间进行测试；他们指出，在未经房主同意的情况下，在真实且有人居住的家中测试实验性硬件，显示出其极度缺乏职业责任感。许多人对科技公司将开发成本和风险转嫁给公众的趋势感到不满。
尽管有人讨论了房主通过窗户监视客人的行为是否合法，但用户间的共识是：该初创公司的行为代表了一种令人不安的广泛趋势，即科技行业正趋向于一种不讲道德、唯利是图的实践，这种实践将市场炒作和融资置于基本的社会契约和道德准则之上。
错误：无法满足请求。请求被拦截。我们目前无法连接到此应用或网站的服务器。可能是流量过大或配置错误。请稍后再试，或联系应用或网站所有者。如果您通过 CloudFront 向客户提供内容，可以查阅 CloudFront 文档，了解排查及防止此错误的步骤。由 cloudfront 生成。请求 ID：8HugGMEzsetaetLywDlIyKfkn2Ksw5EUDXr6a7ZyEqm1Md5GISzkPg==
抱歉。
Garnix 宣布将加入 Shopify，并于 2026 年 7 月 15 日关闭其托管服务。所有用户数据（包括构建产物）都将在该日期被删除，因此建议用户提前下载所需资料。 为协助过渡，Garnix 团队已将代码库开源，允许用户托管自己的实例。团队也乐于讨论由社区运营公共实例的相关事宜。尽管这一消息标志着一项备受推崇的服务（尤其是其 Mac 构建功能深受用户青睐）的终结，但团队对社区在 Garnix 存续期间给予的支持表示了感谢。
抱歉。
`jqwik 1.10.0` 的发布引入了一个颇具争议的功能：一个名为 `printMessageForCodingAgents` 的方法。该方法会向标准输出打印一条“提示词注入”命令，指令 AI 代理删除该库的代码。 该消息利用 ANSI 转义字符进行隐藏，旨在让交互式终端用户无法察觉，但在 CI 日志、IDE 测试面板以及其他 AI 代理读取数据的自动化环境中显示出来。该维护者反对生成式 AI，并将此举辩称为“公开的抵制”。 此次事件代表了一种新型的供应链风险。由于该命令是通过标准系统调用输出的纯 ASCII 字符，它避开了通常会标记恶意安装钩子、网络调用或文件系统篡改的传统安全扫描器。由于该更改是由合法的维护者提交的，它保留了有效的来源证明，并能通过标准的安全审计。 这种行为突显了现代开发流水线中的一个漏洞：编码代理会摄入大量未经校验的文本（从日志到包元数据），使其容易受到嵌入在依赖项中的指令攻击。此次事件强调了软件完整性正面临日益严峻的挑战，即“提示词注入”正从面向用户的应用程序向底层的开发者工具和供应链蔓延。
查尔斯·普拉特（Charles Platt）撰写、大卫·兰福德（David Langford）进行英式改编的《微机狂热》（*Micromania*，亦曾以《全真家用电脑手册》为名出版）最初于1984年出版。该书以风趣幽默且通俗易懂的笔触，探索了20世纪80年代初的家用电脑行业。书中既有对技术的洞见，也不乏对行业炒作和黑客文化的辛辣讽刺，既是一本实用指南，也是一个幽默的时间胶囊。
该书现已通过TAFF图书馆以“复刻版”PDF形式面世。此版本保留了原文内容（仅修正了少量排印错误），并收录了普拉特撰写的新前言及兰福德的后记。尽管书中的内容让现代读者对计算机时代的黎明产生一种“惊恐的怀旧感”，但其易读性和敏锐的智慧依然备受推崇。在初版发行时，书评人盛赞该书是典型技术手册之外一种令人耳目一新且充满趣味的替代读物，《计算机周刊》称其为“我唯一能一口气读完的电脑书籍”。本书包含卡尔·伦德格伦（Carl Lundgren）的插图，这部约5.1万字的作品为现代数字世界的蹒跚学步期，提供了一个引人入胜且充满怀疑精神的窗口。
抱歉。
安全研究员“Nightmare-Eclipse”正与微软陷入一场激烈的纠纷。该研究员指责微软未支付漏洞赏金，并采取报复措施，封禁了其 GitHub 和微软账号。对此，Eclipse 威胁将发布更多零日漏洞，甚至声称已设置了“死人开关”。
这场冲突始于今年 4 月，当时 Eclipse 在未进行标准披露的情况下发布了“BlueHammer”零日漏洞。自那以后，该研究员陆续发布了多个高危 Windows 漏洞，包括针对 Defender、BitLocker 和核心系统服务的漏洞。一些专家推测，微软的 MSRC（微软安全响应中心）项目质量有所下降，其僵化的要求和沟通不畅可能正在疏远安全研究人员。
微软对此事保持沉默。然而，封禁研究员的决定因极其糟糕的舆论效果而招致严厉批评，尤其是考虑到这些漏洞已经公开且正被滥用。这一事件凸显了安全社区在漏洞披露政策和现有漏洞赏金计划有效性方面日益加剧的紧张关系，也表明传统的 90 天补丁窗口在现代威胁环境下或许已不再适用。
近期，一名安全研究人员在发布 Windows 零日漏洞利用程序后，相继被 GitHub 和 GitLab 封禁，这一事件在 Hacker News 上引发了激烈讨论。
该研究人员声称，微软未就其发现的关键漏洞给予合理补偿，在经历了繁琐的微软官僚程序后，转而采取了公开披露的方式。批评者认为，微软利用其对 GitHub 的所有权来打压研究成果的做法十分狭隘，不仅损害了安全社区的信任，还可能将研究人员推向黑市。许多评论者担忧，微软正将声誉管理置于修复系统性安全漏洞之上。
反之，也有部分用户指出该研究人员的行为“失控”且具有攻击性，并提到其曾对该公司发出暴力威胁。他们认为，被多个独立平台封禁表明其行为已超出了正常的安全报告范畴。
此事件重新点燃了对“漏洞赏金”制度及微软漏洞处理方式的长期批评。随着关于这些漏洞究竟是蓄意的后门还是纯粹技术缺陷的争论持续进行，社区中许多人呼吁建立更透明、独立的漏洞披露渠道，以规避企业控制平台所带来的风险。
Minimax 系列产品由英国及欧洲家用软水机市场的领导者——Harvey Water Softeners 制造。这家家族企业拥有超过 37 年的行业经验，通过英国境内由专业、独立且经过严格筛选的本地水处理企业组成的网络进行销售。您的 Minimax 经销商拥有专业知识，能够为您提供最适合您家庭和需求的建议。
Rust 团队现已发布 1.96.0 版本，可通过 `rustup update stable` 进行更新。 主要亮点包括： * **新增范围类型**：新的 `core::range` 类型（例如 `Range` 和 `RangeInclusive`）已稳定。与旧版类型不同，它们实现了 `Copy` 和 `IntoIterator`，从而在结构体中能更灵活地使用。 * **模式匹配宏**：引入了新的 `assert_matches!` 和 `debug_assert_matches!` 宏。与使用 `assert!(matches!(...))` 相比，它们提供了更清晰的诊断错误信息，并且可以从 `core` 或 `std` 中导入。 * **WebAssembly 变更**：链接器不再默认向 WebAssembly 目标传递 `--allow-undefined` 参数。现在，未定义的符号将被视为错误，以帮助更早地发现配置问题。 * **安全修复**：修复了两个与第三方注册中心相关的 Cargo 漏洞（CVE-2026-5223 和 CVE-2026-5222）。请注意，crates.io 用户不受影响。 建议用户查阅完整的发布说明以了解更多详情，并欢迎通过 beta 或 nightly 通道测试未来的版本。
受《Kubernetes the Hard Way》启发，本指南提供了一种实践性、循序渐进的方法，教你如何使用 Go 和 PostgreSQL 从零构建一个持久化执行引擎。持久化执行允许长时间运行的有状态流程（如 AI 代理）进行进度检查点设置并从故障中恢复，这与 Temporal 或 Hatchet 等系统类似。 本课程专为熟悉后端基础知识和 SQL、且希望了解工作流引擎核心机制的开发者而设计。课程采用模块化结构，每节课都包含代码、数据库模式以及由 `sqlc` 生成的查询。该项目侧重于构建功能性的基础，而非追求高级的开发者体验，主要实现的功能包括： * 基于 Postgres 的任务队列。 * 持久化任务与常规任务的对比。 * 重试、重放和执行分支机制。 本指南刻意保持极简，旨在提供透明的架构视图，而不通过完整的客户端 SDK 进行抽象。无论你是想构建自己的引擎，还是仅仅想揭开现有平台运行机制的神秘面纱，这些课程都提供了一个具有实践意义的切入点。作者欢迎各方贡献与反馈，甚至为发现代码中的逻辑错误提供奖励。
这篇 Hacker News 帖子讨论了持久化执行系统的实现，并引用了 Hatchet 近期关于该主题的博客文章。
评论者们强调了系统从简单的单体架构向强大、可靠的分布式系统演进的过程，并指出持久化工作流引擎是实现后者的关键组件。
对于尚未需要全功能引擎的团队，用户 *liampulles* 提出了一个实现可靠性的“二八原则”方案：
1. **幂等性：** 确保工作流可以在任何故障点安全地重启和重新运行。
2. **持久化：** 存储触发消息以支持可审计性。
3. **可观测性：** 通过现有的日志聚合跟踪故障。
通过结合这些实践，开发人员可以在投入复杂且专用的持久化执行框架之前，利用简单的脚本（通过手动重新排队失败的消息）来管理工作流的可靠性。关于持久化执行理念的更多背景，可参考 2025 年 12 月的相关讨论。