2026-05-12 Hacker News Top Stories #
- 谷歌和苹果推动的硬件级认证正被银行与政府当作准入门槛，实质以安全之名限制第三方系统与用户选择、强化垄断。
- 倡导本地优先的AI以保护隐私和降低延迟，必要时再混合云端，但受限于本地硬件内存/算力与成本，而云端具规模化优势。
- AI适合在明确边界下产出功能而非架构，否则易堆出“神对象”与耦合，人需主导演进不变量、模块化与定期重构。
- 一场逼真的虚构供应链攻击揭示了2FA/签名缺失、传递依赖与自动合并等系统性风险，并呼吁改进防护与流程治理。
- Anthropic 的 Mythos 在 curl 源码中仅确认出一处低危问题，整体效果与既有工具相当，应警惕过度营销炒作。
- Ratty 用GPU在终端内联渲染3D图形，引发对终端不应局限文本、应向更丰富交互和可视化演进的讨论。
- 在24GB内存的M4上本地跑Qwen 3.5‑9B可胜任日常开发辅助并兼顾隐私离线，社区称Gemma 4等更大模型正成新基准。
- Gmail 注册改为扫码由手机主动发短信以遏制滥用，虽提升防滥用能力却加剧隐私与可迁移性隐忧并催生可能绕过手段。
- 攻击者滥用 Obsidian 社区插件通过社工投递跨平台RAT，建议收紧插件权限、监控异常行为并加强用户安全培训。
- 代码生成提速若未同步降低维护成本将侵蚀长期生产力，应让AI聚焦减负维护（如依赖升级、测试）而非制造新的债务。
1. 硬件认证作为垄断助推器 (Hardware Attestation as Monopoly Enabler) #
https://grapheneos.social/@GrapheneOS/116550899908879585
该网页内容主要围绕苹果和谷歌逐步推广硬件级认证技术展开，重点讨论了这项技术对用户设备和操作系统选择自由的影响。苹果通过 Privacy Pass 将硬件认证引入网页，谷歌计划采用类似方式，并在其 Play Integrity API 中逐步强制要求硬件认证，尤其是对强完整性级别的设备。银行和政府服务开始采用这类认证，强制用户使用苹果或谷歌认证的设备和操作系统。
网页指出，这些认证系统表面上被宣传为安全功能，实则更多是为了锁定市场，排斥非官方硬件和操作系统，限制竞争。谷歌的 Play Integrity API 甚至禁止使用 GrapheneOS 等更安全的替代系统，尽管这些系统在安全性上优于官方许可的系统。网页还提到，谷歌通过控制 reCAPTCHA 等广泛使用的服务，进一步加强了对用户设备的限制，要求通过认证设备扫码验证，甚至影响到 Windows 和 Linux 等桌面系统的访问。
此外，欧盟等政府机构也在推动将这类认证作为数字支付、身份验证等服务的强制要求，进一步加剧了市场的垄断趋势。网页批评政府未能阻止苹果和谷歌的反竞争行为，反而通过自身服务参与了这一过程。最后，网页提及了由欧洲多家公司推动的“统一认证”系统，这一系统将进一步集中认证权力，限制用户自由，且远不如安卓开放的硬件认证 API 灵活。总体来看，网页强调硬件认证技术更多是商业垄断工具，而非真正的安全保障。
HN 热度 2064 points | 评论 697 comments | 作者：ChuckMcM | 1 day ago #
https://news.ycombinator.com/item?id=48086190
- 设备锁定和硬件认证问题本质上是社会和立法问题，而非纯技术问题，需要通过提高公众意识和政治压力来应对。
- 苹果一直对设备有严格控制，用户对此习以为常且接受，而谷歌改变安卓的开放性引发了用户的不满。
- 安卓被视为开放系统的形象被误解，实际上只有 AOSP 是开源的，谷歌的行为与苹果类似，均存在垄断倾向。
- 谷歌和苹果的良好声誉源于早期的品牌形象和用户体验，但随着时间推移，这些基础逐渐被侵蚀。
- 苹果通过强调设备安全和严格的应用审核建立了良好口碑，普通用户更关注设备的易用性和安全性，而非技术自由。
- 发展中国家的安卓用户主要使用中端手机，需求和价值观与发达国家苹果用户类似。
- 普通 iPhone 用户通常不会考虑应用商店的抽成问题，更关注应用的质量和整体体验。
- 谷歌应用商店存在大量广告和订阅推销的“免费”应用，用户体验不佳。
- 苹果应用商店同样存在大量质量不高的应用。
- 安卓用户较少遇到恶意软件问题，更多是应用内广告和订阅的困扰。
- IT 技术人员倾向于选择苹果设备以减少家庭成员使用中的技术问题和复杂性。
2. 本地 AI 应成为常态 (Local AI needs to be the norm) #
https://unix.foo/posts/local-ai-needs-to-be-norm/
这篇文章讨论了当前软件开发中普遍依赖云端 AI 模型的问题，指出这种做法导致软件脆弱、隐私受侵害，并且增加了系统复杂度和成本。作者主张应回归本地 AI 模型，让设备本地完成 AI 任务，利用现代设备强大的计算能力和专用神经引擎，避免数据传输到第三方服务器带来的隐私和安全风险。
文章以作者开发的 Brutalist Report 新闻聚合应用为例，介绍了如何利用苹果的本地模型 API 在 iOS 设备上生成文章摘要，无需服务器支持，保证数据私密和快速响应。作者强调，本地 AI 适合处理用户已有数据的转换任务，如摘要、分类、提取等，而非替代整个互联网知识库。
此外，文章介绍了苹果提供的工具，支持开发者定义结构化数据类型，让 AI 输出直接生成可用的结构化内容，提升开发效率和应用稳定性。作者认为，虽然本地模型智能不及云端模型强大，但对于大多数应用场景已经足够，建议仅在必要时使用云端模型，优先保障用户数据安全和应用的可靠性。
总结来说，文章呼吁行业重视本地 AI 模型的应用，避免将简单功能变成复杂分布式系统，推动构建更实用、可信赖的软件。
HN 热度 1745 points | 评论 693 comments | 作者：cylo | 1 day ago #
https://news.ycombinator.com/item?id=48085821
- 本地运行大型语言模型（LLM）正逐渐成为趋势，未来可能形成“远程高性能模型用于规划，本地模型用于执行”的混合模式，最终实现本地模型完全满足需求的平衡状态。
- 目前已有硬件能够运行量化后的模型，虽然速度较慢且上下文窗口有限，但能完成照片分类、收据 OCR、简单问答和代码生成等任务。
- 云端服务因资源共享效率更高，成本远低于自建本地服务器，且提供数据安全和灵活性，但价格较高。
- 现有的本地硬件资源和模型规模限制了用户运行最新前沿模型的能力，主要瓶颈在于内存和计算能力。
- Mac Studio 等高端设备供应紧张，部分原因是市场需求增加及苹果产品定价策略调整。
- 运行本地模型的成本和利用率问题限制了其普及，云服务因高利用率和规模效应在价格上更具优势。
- 本地模型的响应速度和实时性较云端模型差，适合不需要即时反馈的应用场景。
- 传统软件如 Shotwell 已具备一定的照片管理功能，现代开源项目如 Immich 也提供了丰富的机器学习分类功能。
- 目前开源视觉语言模型在文档解析和 OCR 方面表现优异，部分模型在 CPU 上可运行，尽管速度较慢但准确率接近甚至超过人眼。
- 新发布的开源模型不断涌现，覆盖结构化文本提取等多种应用，丰富了本地 AI 工具生态。
3. 我将回归手写代码 (I’m going back to writing code by hand) #
https://blog.k10s.dev/im-going-back-to-writing-code-by-hand/
这篇博客文章记录了作者在使用 AI 辅助编程开发 k10s 项目过程中的经验和教训。k10s 是一个 GPU 感知的 Kubernetes 仪表盘，专为管理 NVIDIA 集群设计，能够显示 GPU 利用率、温度、电力消耗等关键指标。项目最初进展顺利，AI 能够快速生成功能代码，极大提升开发速度，但随着功能增多，代码结构变得混乱，出现了“神对象”问题——所有状态和逻辑都堆积在一个庞大结构体中，导致维护困难和功能失效。
作者反思发现，AI 擅长写功能代码，但缺乏整体架构设计能力，长期依赖 AI 生成代码会导致项目逐渐失控。文章重点指出了 AI 辅助编程的五条原则，其中包括：AI 负责写功能，架构设计必须由人类把控；避免让 AI 无节制地添加功能；及时介入审查和重构代码；防止不同功能之间状态混淆；以及合理规划代码结构以防止“神对象”出现。
通过这次经历，作者建议开发者在使用 AI 编程时，要保持对整体架构的掌控，不能完全依赖 AI，适时介入调整，才能保证项目的健康发展和代码质量。
HN 热度 907 points | 评论 559 comments | 作者：dropbox_miner | 22 hours ago #
https://news.ycombinator.com/item?id=48090029
- 生成代码的问题在于其难以维护和理解，尤其当系统架构或不变量需要改变时，AI 生成的代码往往难以适应且容易隐藏问题。
- 通过给 AI 设定清晰的模块边界和小上下文，可以提高生成代码的质量，使模块纯净、易测试，但仍需人为监督。
- AI 会严格遵循给定策略，即使策略已经不适用，导致代码质量随时间下降，必须仔细审查 AI 生成的代码。
- 代码好坏的定义与模块化、可测试性和无副作用有关，合理设计模块可以让 AI 生成的代码达到可接受水平。
- 人类写的代码同样可能出现质量问题，经验丰富的程序员也会制造混乱，AI 加速了这种混乱的产生，但责任在于人类指导。
- 自动化测试和项目验证器是防止 AI 生成代码出错的有效手段，可以自动检测和修复重复错误。
- AI 辅助编程需要结合已有的软件工程原则和架构设计，如领域驱动设计和事件溯源，才能显著提升代码质量。
- 不能完全依赖 AI 自动化软件开发，必须持续监督和调整，避免陷入“打地鼠”式的修补循环。
4. 事件报告：CVE-2024-YIKES (Incident Report: CVE-2024-YIKES) #
https://nesbitt.io/2026/02/03/incident-report-cve-2024-yikes.html
这篇报告详细描述了一个名为 CVE-2024-YIKES 的严重供应链安全事件。事件起因于 JavaScript 生态系统中一个依赖包被攻破，导致凭证泄露，进而攻击了 Rust 压缩库 vulpine-lz4，该库被 Python 构建工具 snekpack 所使用，最终恶意软件传播给约 420 万开发者。事件历时 73 小时，最终因一个无关的加密货币挖矿蠕虫意外修复而解决。
事件经过包括：左对齐库 left-justify 的维护者 Marcus Chen 被盗窃，凭证被钓鱼网站窃取，left-justify 发布含恶意脚本的新版本，窃取多种凭证；攻击者利用这些凭证控制 vulpine-lz4，植入恶意构建脚本；该恶意代码被 Python 工具 snekpack 使用，导致全球开发者机器感染，恶意软件添加 SSH 密钥、安装反向 shell 并改变默认 shell 为 fish；安全研究者发现并报告问题，但响应迟缓；最终，因加密货币蠕虫传播时自动升级了 snekpack 版本，意外撤销了恶意代码，事件才得以解决。
根本原因被幽默地归结为“名为 Kubernetes 的狗吃掉了 YubiKey”，反映了多重安全管理失误。事件暴露了 npm 注册表允许弱认证、AI 搜索引导至钓鱼网站、Rust 生态中大量小型依赖包的风险、Python 工具对 Rust 库的盲目引用及更新不及时、自动合并 PR 的风险等问题。
报告建议加强制品签名、强制 2FA、审计传递依赖、合理管理依赖版本等措施。整体事件显示供应链安全的复杂性和脆弱性，同时也讽刺了安全响应中的混乱和无奈。
HN 热度 676 points | 评论 166 comments | 作者：miniBill | 1 day ago #
https://news.ycombinator.com/item?id=48086082
- 这篇帖子是虚构的供应链安全事件，但写得非常真实，容易让人误以为是真实事件。
- 真实受害者分享了被攻击后的心理影响和对安全的恐慌，强调攻击是多种因素叠加的结果。
- 有人最初以为帖子是恶搞或伪造，但随着阅读深入发现内容虽荒诞但不失合理性。
- 讨论中提到一些真实的技术细节和历史事件，如比特币的 BIP-42 修复。
- 有评论指出帖子中的包名如“left-justify”是虚构的，类似于历史上的“left-pad”事件。
- 有人提到搜索 CVE-2024-YIKES 会出现很多 AI 自动生成的内容，导致真假难辨。
- 有观点认为现在通过谷歌搜索难以判断信息真伪，因为搜索结果往往重复原文和相关虚假内容。
- 有评论批评帖子没有在开头明确标注为虚构，增加了读者的辨识难度。
- 有人认为阅读这类内容需要具备一定的阅读能力和信息筛选能力，不能仅凭表面信息判断。
- 讨论中有调侃包管理和依赖解析的复杂性，甚至开玩笑说依赖解析是图灵完备的。
- 有人分享了对 Rust 生态中部分关键依赖包的关注，暗示供应链攻击的潜在风险。
5. Mythos 发现了一个 curl 漏洞 (Mythos Finds a Curl Vulnerability) #
https://daniel.haxx.se/blog/2026/05/11/mythos-finds-a-curl-vulnerability/
这篇文章由 curl 项目负责人 Daniel Stenberg 撰写，讲述了 Anthropic 公司开发的 AI 模型 Mythos 在安全漏洞检测方面的表现及其对 curl 项目的影响。文章开头介绍了 Mythos 因其在源代码安全漏洞发现上的强大能力而引起广泛关注，但 Anthropic 尚未公开发布该模型，仅限部分公司使用以优先修复关键问题。
作者作为 curl 项目的负责人，曾被邀请使用 Mythos 扫描 curl 代码，但因各种原因未能直接接触模型，而是通过第三方获得了 Mythos 对 curl 的安全扫描报告。此前，curl 项目已经使用多种 AI 工具（如 AISLE、Zeropath、OpenAI Codex Security）和传统静态分析、模糊测试等方法进行安全审查，过去 8-10 个月内这些工具帮助发现并修复了数百个问题，其中包括十余个确认的安全漏洞。
文章详细介绍了 curl 项目的规模和安全管理：curl 拥有约 17.6 万行 C 代码，代码质量经过多次打磨，由超过 1400 名开发者贡献，已发布 188 个安全漏洞公告（CVE），广泛应用于全球数十亿设备和多种操作系统。Mythos 对 curl 代码的扫描覆盖了主要源码目录，确认了 5 个安全问题，但经过团队复核，最终只确认了 1 个低严重度的安全漏洞，计划在即将发布的 curl 8.21.0 版本中公开。
作者指出，Mythos 报告中还包含约 20 个非安全性缺陷，团队正在逐一评估和修复。总体来看，Mythos 的发现数量和质量与之前使用的 AI 工具相当，未表现出显著超越的能力。作者认为当前对 Mythos 的过度炒作更多是市场营销效果，实际在代码安全分析上的提升有限。
总结来说，curl 项目持续重视安全，结合多种工具和人工审查不断改进代码质量。Mythos 作为新兴 AI 安全分析工具，虽表现良好，但尚未带来革命性突破，curl 团队将继续利用各种手段保障项目安全。
HN 热度 606 points | 评论 250 comments | 作者：TangerineDream | 16 hours ago #
https://news.ycombinator.com/item?id=48091737
- Mythos 模型的效果被认为主要是营销炒作，实际在代码安全分析上的提升有限。
- Mythos 能够自动发现漏洞是其重要价值，但需要关注其误报率。
- 早期 OpenAI 对 GPT-2 的发布持谨慎态度，担心潜在风险。
- 谷歌内部曾有员工误以为 AI 具备意识，最终因泄露信息被解雇。
- 谷歌对 AI 的态度较为保守，主要是为了规避风险和保持市场地位。
- OpenAI 和 Anthropic 的商业模式被质疑投入大于回报，但其用户规模和收入增长迅速。
- AI 行业的竞争激烈，营销和恐惧策略被用来快速推动业务发展。
- AI 技术带来的社会影响复杂，包括诈骗、自杀等负面事件，不能简单归结为营销问题。
- 对 AI 潜在危害的担忧与对其能力的过度乐观形成对比，社会对 AI 的认知存在分歧。
- AI 产品的快速普及是互联网历史上最快的，但是否真正带来积极改变仍有争议。
6. Ratty – 带内嵌 3D 图形的终端模拟器 (Ratty – A terminal emulator with inline 3D graphics) #
该网页介绍了 Ratty，一款基于 GPU 渲染的终端模拟器，支持内嵌 3D 图形显示。Ratty 的一个特色功能是带有一个旋转的老鼠光标，增加了使用时的趣味性和视觉效果。网页还提供了相关资源的链接，包括博客文章、软件下载以及源代码，方便用户深入了解和使用这款终端模拟器。页面版权归 Orhun Parmaksız 所有，时间标注为 2026 年。
HN 热度 589 points | 评论 191 comments | 作者：orhunp_ | 13 hours ago #
https://news.ycombinator.com/item?id=48093100
- UNIX 的 REPL 体验仍在追赶早期施乐工作站和 Lisp 机器的内联图形技术。
- 许多现代用户体验问题早在 1968 年的“母亲演示”中就已解决。
- 讨论中提到的示例视频并非真正的 3D 图形，但有其他视频展示了类似 Nintendo 64 开发时使用的 3D 技术。
- Symbolics 在 SGI 之前主导了 3D 图形市场，支持简单的窗口创建和绘图操作，后来 X10 系统体验较差。
- CRT 显示器相比平板显示器更适合某些 3D 显示效果。
- TempleOS 虽然被戏谑，但其设计理念和 HolyC 语言具有独特价值。
- Terry Davis 的工作体现了个人智慧与信仰的结合，但存在对问题的回避态度。
- TempleOS 的 HolyC 语言容易因编辑错误导致系统崩溃，类似早期计算机的 POKE 指令问题。
- Oberon 和 Plan9 等操作系统也被提及，曾在学术环境中使用。
- Terry Davis 的精神状态被一些人视为“神启”或“神的启示”。
- TempleOS 终端中有令人印象深刻的 3D 图标设计。
- Ratty 项目直接受到 TempleOS 的启发。
- 有评论提到在 VR 中使用浅层 3D 界面以减少视觉疲劳，3D 可以通过多种方式实现，包括头部追踪和立体显示。
- 3D 文本渲染系统可以实现每个字符作为独立 3D 多边形，支持大规模渲染和编辑。
- 有人认为 3D 文本渲染在实际使用中存在阅读和操作上的困难，且 3D 效果的实用性存疑。
- 终端不应仅限于文本显示，数据科学笔记本展示了终端发展的可能性，Kitty 终端是该领域的积极创新者。
- euporie 项目支持在终端中运行数据科学笔记本，显示图形、HTML 和 LaTeX 等多种内容。
- 有用户关心是否可以在 euporie 中切换 Jupyter 内核，以及通过 SSH 运行时如何实现用户认证和访问控制。
7. 在拥有 24GB 内存的 M4 MacBook Pro 上运行本地模型 (Running local models on an M4 with 24GB memory) #
https://jola.dev/posts/running-local-models-on-m4
这篇文章介绍了作者在一台拥有 24GB 内存的 M4 MacBook Pro 上运行本地语言模型的实验和心得。作者尝试了多种模型和运行环境，包括 Ollama、llama.cpp 和 LM Studio，最终发现 Qwen 3.5-9B（4b 量化版本）在 LM Studio 上表现较好，能够以约 40 tokens 每秒的速度运行，支持 128K 的上下文窗口，并能启用“思考”模式进行更精确的编码任务。
作者详细说明了如何配置该模型以支持思考模式，包括调整温度、top_p、top_k 等参数，并通过修改 Prompt 模板来启用思考功能。同时，文章还分享了两种常用工具 Pi 和 OpenCode 的配置示例，方便读者快速上手。
虽然本地模型无法像最先进的云端模型那样独立解决复杂问题，但作者认为这种交互式、需要用户更多引导的使用方式反而能提升用户的参与感和思考深度。模型可以作为研究助手、代码调试的“橡皮鸭”，以及快速回忆编程细节的工具，虽然效率提升有限，但依然有实际价值。
文章还通过两个具体示例展示了模型的实际应用：一是帮助升级 Elixir 代码中的 linter 规则，给出代码改进建议并完成修改；二是协助解决依赖冲突的 Git rebase 问题，虽然模型在执行修改时出现了一些失误，但整体表现令人满意。
总结来看，作者认为本地模型适合需要高度互动和细致指导的工作流程，虽然不能完全替代云端 SOTA 模型，但在保护隐私、减少对大厂依赖以及无网络环境下工作方面具有独特优势。
HN 热度 533 points | 评论 157 comments | 作者：shintoist | 24 hours ago #
https://news.ycombinator.com/item?id=48089091
- Gemma 4 31B 被认为是本地模型的新基准，虽然不及最前沿模型，但比以往本地模型更稳定可靠，适合大内存机器运行。
- Gemma 4 在某些任务上表现接近甚至优于 Opus 4.7，尤其在有良好上下文输入时表现出色，适合非平凡项目的自动化工具开发。
- Gemma 4 能够较好地进行复杂任务，如逆向工程蓝牙协议，甚至在无网络辅助时也能逐步推进项目。
- Qwen 3.6 在代码审查和基础研究方面表现优于 GPT-5.4，能发现更多隐藏问题和提供更准确的建议。
- 本地模型的发展迅速，结合代理框架和硬件进步，带来多方面的技术突破。
- Gemma 4 26B 版本在同级别模型中表现高效且智能，虽然在长上下文任务中表现有所下降。
- 小模型如 Gemma e2b 在编辑任务中表现良好，适合配合更强模型进行规划和执行。
- 小模型的选择需根据硬件性能调整，部分小模型存在思维循环或性能瓶颈问题。
- 在 M4 Pro 64GB 硬件上，Gemma 4 31B 的首次生成时间和生成速度表现较好，具体数值因模型版本和提示不同有所差异。
8. Gmail 注册现需扫描二维码并发送短信验证 (Gmail registration now requires scanning a QR code and sending a text message) #
该网页主要讨论了谷歌账户注册过程中引入的二维码验证方式及其对匿名注册的影响。用户发现，谷歌用二维码替代了传统的短信验证，但实际上扫描二维码后，手机会自动发送短信给谷歌以验证手机号，这使得使用虚拟短信服务（如 SMSpool）变得不可行。
讨论中提到，这种验证方式虽然提升了安全性，防止钓鱼和滥用，但也给注重隐私的用户带来了困扰。部分用户担心无法匿名注册新账户，且购买二手谷歌账户存在风险，因为无法确定账户之前的使用者身份。
有用户提出，未来可能会出现新的服务来绕过这一限制，自动向谷歌发送短信完成验证。此外，有用户分享了在国外使用实名制 SIM 卡注册谷歌账户并启用两步验证的经验，指出即使号码被回收，账户仍能长期使用，且谷歌会记录所有曾用过的手机号，但通常不允许用已不再拥有的号码进行验证。
整体来看，网页内容围绕谷歌账户注册安全措施的变化，探讨了其对隐私保护和匿名注册的影响，以及用户应对这一变化的可能策略。
HN 热度 522 points | 评论 366 comments | 作者：negura | 16 hours ago #
https://news.ycombinator.com/item?id=48092028
- Gmail 作为免费服务，承担了大量互联网基础设施的维护，成本高且复杂，且需应对大量垃圾邮件和诈骗，免费邮箱服务本质上难以保证质量和支持。
- Google 最初提供免费邮箱时，容量远超当时竞争对手，免费服务是其吸引用户的策略，Google 有权采取措施防止产品被恶意使用。
- 提供低价甚至免费关键服务可能导致市场竞争被排挤，突然取消服务可能存在道德和法律争议。
- 许多人对财产权的理解较为片面，忽视了历史上为解决实际问题而设立的各种权利和保护机制。
- 网络上存在大量误导性信息，普通用户难以辨别，当前大语言模型能帮助识别这些信息，但这种优势可能不会持续。
- 教育系统未能有效抵御有组织的宣传机器的影响，导致公众认知偏差，这反映了教育和社会制度的不足。
- 系统设计难以完美适应复杂的人类社会，限制了政府和企业解决大规模问题（如气候变化）的能力。
- 尽管系统存在缺陷，人类通过不断努力仍能实现重大进步，不应对系统失效持彻底悲观态度。
- 系统和机构的问题根源在于人，个人和集体的责任感缺失导致制度难以改进，社会问题无法根本解决。
- 个人责任重要，但必须结合对社会环境和制度的理解，单靠个人行为无法解决系统性问题，需要制度层面的改革和问责。
9. Obsidian 插件被滥用以部署远程访问木马 (Obsidian plugin was abused to deploy a remote access trojan) #
https://cyber.netsecops.io/articles/obsidian-plugin-abused-in-campaign-to-deploy-phantom-pulse-rat/
安全研究人员发现了一起针对金融和加密货币专业人士的高度定向社会工程攻击活动，该活动利用 Obsidian 笔记应用程序传播一种名为 PHANTOMPULSE 的新型远程访问木马（RAT）。攻击者通过 LinkedIn 和 Telegram 等平台建立信任，诱导受害者打开一个恶意共享的 Obsidian 云端笔记库，并引导其启用社区插件功能，从而执行恶意代码并部署木马。
该攻击针对 Windows 和 macOS 系统，攻击流程包括：通过社交工程获得初始访问，诱使用户开启社区插件功能，执行恶意脚本（Windows 上为 PowerShell，macOS 上为 AppleScript），加载名为 PHANTOMPULL 的加载器，最终在内存中解密并运行 PHANTOMPULSE 木马以规避检测。PHANTOMPULSE 利用以太坊区块链查询交易数据，动态获取其命令控制服务器地址，增强了其抗封锁能力。
一旦感染，攻击者可完全控制受害者设备，窃取敏感数据、知识产权、交易策略，尤其是加密货币钱包密钥和交易所凭证。该攻击的跨平台特性和区块链 C2 机制显示出高度复杂性，给防御带来极大挑战。
检测建议包括监控 Obsidian 进程是否启动异常子进程（如 powershell.exe、cmd.exe、osascript），关注异常的以太坊区块链网络流量，以及监控 Obsidian 插件目录的文件变动。防御措施强调用户培训以识别社交工程攻击，限制社区插件安装，禁用不信任笔记库的插件同步功能，以及实施应用控制和保持终端安全软件更新。总体来看，防范此类攻击需结合技术监控与用户安全意识提升。
HN 热度 348 points | 评论 207 comments | 作者：cmbailey | 1 day ago #
https://news.ycombinator.com/item?id=48088576
- Obsidian 即将推出插件安全性重大更新，旨在解决用户担忧，目前攻击案例主要是社交工程，需要用户多次忽视安全警告。
- 插件虽带来安全风险，但为用户提供了更多自定义功能，且插件非必需，用户可根据需求选择使用。
- 应减少对插件的依赖，将常用功能内置为设置选项，降低用户对插件的需求。
- 插件具有全盘访问权限，存在安全隐患，早有用户提醒但未被充分重视。
- Obsidian 的开放性是其优势，不能完全封闭插件系统，但应增加防范社交工程攻击的措施。
- 允许插件执行任意系统命令带来风险，但限制过严会影响诸如 git 集成、自动备份等功能。
- 建议将插件操作限制在文档库内，执行系统命令需用户授权，类似浏览器脚本的沙箱机制。
- 现代操作系统（如 macOS）支持应用沙箱和权限管理，能限制应用访问磁盘的范围。
- Windows 系统默认程序拥有全盘访问权限，缺乏有效的沙箱机制，安全性较低。
- Windows 的沙箱技术存在，但不支持持久化，且用户难以为不安全程序配置权限。
- macOS 的 Gatekeeper 默认启用应用沙箱，访问敏感路径时会弹出权限请求，用户可手动授予全盘访问权限。
- 对大多数普通用户来说，启用和管理应用沙箱权限较为复杂，但通过应用商店安装的程序通常默认受限。
10. 使用 AI 编程代理以降低维护成本 (An AI coding agent, used to write code, needs to reduce your maintenance costs) #
https://www.jamesshore.com/v2/blog/2026/you-need-ai-that-reduces-your-maintenance-costs
本文讨论了使用 AI 编程代理对软件开发生产力和维护成本的影响。作者指出，虽然 AI 可以显著提高代码编写速度，但如果维护成本没有相应降低，整体生产力反而会下降。每写一个月的代码，未来几年都需要花时间维护，包括修复漏洞、清理代码和升级依赖等。随着时间推移，维护工作将占据越来越多的时间，最终可能超过一半的工作量。
文章通过“群众智慧”估算了维护成本，指出如果维护成本翻倍，生产力提升的效果会迅速消失，甚至变得比未使用 AI 前更糟。作者强调，只有当 AI 生成的代码维护成本降低到与生产力提升成反比时，才能真正实现长期效益，否则只是短暂的速度提升换来永久的负担。
此外，停止使用 AI 后，虽然不再有 AI 带来的生产力提升，但之前增加的维护负担依然存在，导致整体效率下降。作者呼吁在追求编码速度提升的同时，也要重视降低维护成本，或者提升维护效率，否则团队将陷入“加速但被锁定”的困境。
最后，作者承认目前大多数 AI 工具实际上增加了维护成本，真正能大幅降低维护成本的 AI 尚未出现，但仍鼓励读者探索各种可能的改进方法，包括利用 AI 提升维护工作的效率。
HN 热度 346 points | 评论 100 comments | 作者：cratermoon | 23 hours ago #
https://news.ycombinator.com/item?id=48089289
- AI 确实降低了维护成本，尤其是在处理老旧代码、更新依赖和自动化测试方面带来了便利。
- 依赖 AI 工具可能导致对工具的依赖性增强，一旦失去 AI 支持，维护难度会显著增加。
- AI 辅助下代码量激增，部分代码缺乏理解，导致故障和严重性增加，维护难度加大。
- 维护性不应被视为非功能需求，而是保障未来功能持续交付的关键因素，应被视为功能性需求。
- 不应将维护性等质量问题单独命名或隔离处理，质量应作为开发的内在部分，贯穿整个开发过程。
- AI 生成代码容易带来难以察觉的细微错误，增加了代码审查的难度和维护负担。
- AI 并未真正减少维护成本，而是将维护成本从编写转移到审查，审查 AI 代码比人类代码更具挑战。
- 软件应被视为投资，维护成本和价值需动态评估，技术债务应以价值视角重新定义。
Hacker News 精彩评论及翻译 #
Software engineering may no longer be a lifetime c… #
https://news.ycombinator.com/item?id=48096558
Multiple times per week I have the same conversation. It goes something like this:
- AI will make developers irrelevant
- Why?
- Because LLMs can write code
- Do you know what I do for a living?
- Yes, write code?
- Yes, about 2-5% of the time. Less now.
- But you said you are a developer?
- I did
- So what do you do 95-98% of the time?
- I understand things and then apply my ability to formulate solutions
- But I can do that!
- So why aren’t you? The developers who still think their job is about writing code will perhaps not have a job in the future. Brutal as it may sound: I’m fine with that. I’m getting old and I value my remaining time on the planet.
Business owners who think they can do without developers because they think LLMs replace developers are fine by me too. Natural selection will take care of them in due course.
bborud
我每周多次都会经历同样的对话，大致是这样：
- AI 会让开发者变得无关紧要
- 为什么？
- 因为大型语言模型能写代码
- 你知道我是什么职业吗？
- 知道，写代码吧？
- 对，但只占我工作时间的2%到5%，现在甚至更少
- 可你说你是开发者？
- 是的
- 那你剩下95%到98%的时间都做什么？
- 我理解问题，然后运用能力制定解决方案
- 可我也会这样做啊！
- 那你为什么不去做？ 那些仍然认为自己的工作只是写代码的开发者，或许将来真的没有工作了。虽然说得很残酷，但我对此无所谓。我年纪大了，更珍惜自己剩下的时间。
那些认为不用开发者，因为觉得大型语言模型可以替代开发者的企业主，我也没意见。自然选择会在适当时候处理他们。
Mythos Finds a Curl Vulnerability #
https://news.ycombinator.com/item?id=48092073
Quote:
“My personal conclusion can however not end up with anything else than that the big hype around this model so far was primarily marketing. I see no evidence that this setup finds issues to any particular higher or more advanced degree than the other tools have done before Mythos. Maybe this model is a little bit better, but even if it is, it is not better to a degree that seems to make a significant dent in code analyzing.”
It’s a good reminder for us all that the competition in this space is rough and lots of more or less subtle marketing is involved.
rzmmm
我的个人结论无非是，这款模型至今的大肆宣传主要是营销手段。我看不到有任何证据表明这个系统在发现问题的能力上比其他在Mythos之前的工具有明显的提升。也许这款模型稍微好一点，但即便如此，其提升幅度也不足以对代码分析产生显著影响。
这提醒我们所有人，这个领域的竞争非常激烈，且伴随大量或多或少带有技巧的营销。
Hardware Attestation as Monopoly Enabler #
https://news.ycombinator.com/item?id=48091000
I always say this when this topic comes up: remote attestation will be how our computing freedom dies. They’ve made it so that it doesn’t even matter if they allow you to install whatever you want. Anything that isn’t corporate owned is banned. Own your device? You “tampered” with it. You’re banned. From everything. You’re ostracized from digital society. You’re not even a citizen, much less a second class citizen. Enroll your own keys? It doesn’t matter. You’re not trusted. You’re a fraudster terrorist money launderer drug dealer pedophile.
While I am glad that people continue to struggle, that GrapheneOS continues to fight and speak out, these developments still fill me with a terrible sadness. The future is bleak. We inch ever closer to the complete destruction of everything the word “hacker” ever stood for. It’s a deep loss.
matheusmoreira
每次谈到这个话题，我总是这么说：远程认证将成为我们计算自由的终结者。他们已经把事情做得这样，即使允许你安装任何你想要的软件也无关紧要。任何不是企业拥有的东西都会被禁止。你拥有设备？那就是“篡改”了它。你被禁用了。所有的东西都禁用。你被数字社会排斥。你甚至不是公民，更别说是二等公民了。自己注册密钥？无所谓。你不被信任。你就是骗子、恐怖分子、洗钱犯、毒贩、恋童癖者。
虽然我很高兴有人仍在努力，GrapheneOS 还在战斗和发声，但这些发展依然让我感到非常悲伤。未来很暗淡。我们一步步逼近“黑客”这一词汇曾经代表的一切的彻底毁灭。这是一次深刻的损失。
Driver accused of DUI tracks missing laptop to Ill… #
https://news.ycombinator.com/item?id=48094899
investigators determined Bradley had violated State Police policies, and he was suspended for one day.
medler
调查人员认定布拉德利违反了州警察的政策，他因此被停职一天。
Hardware Attestation as Monopoly Enabler #
https://news.ycombinator.com/item?id=48093126
The superhuman efforts that folks on HN make to find technical workarounds and solutions is wonderful to see, but we must realize that this is not a technical problem. It’s a social and legislative one. It can’t be fought on technical grounds. The push back has to be via putting pressure on politicians by making regular people more aware.
Right now, the vast majority of users are being bombarded with a one sided narrative of how ‘insecure’ their devices are. They read almost everyday about someone losing their life’s savings due to ‘hackers’. In this environment, they genuinely believe locking down their devices will make them more secure and prevent them from being ‘hacked’.
The powers that be make sure that the people never hear the other side. That people are giving absolute control to large corporations. In my experience, once the issue is framed as ‘Google will decide what you can do with your phone’ every single person is immediately outraged.
If you want to make a meaningful contribution, however small, then make it a point to educate people about the control they are giving to large corporations like Google. It doesn’t take much to convince them that Google et al don’t have their best interests in mind. They already know it and have experienced it. The second thing to do is to encourage them to reach out to their member of congress via letters. It’s easy enough to do, and politicians are terrified of going against voters. They rely on people’s ignorance to quietly work against their constituent’s interests while supporting whichever special interest happened to donate the most to their campaign fund.
khriss
看到HN上的人们为寻找技术解决方案付出超乎常人的努力，确实令人敬佩，但我们必须意识到这不是一个技术问题，而是一个社会和立法问题。这个问题不能靠技术来解决，反抗的方式必须是通过让普通人更加了解情况，从而对政治人物施加压力。
目前，绝大多数用户都被单方面的叙述轰炸——他们的设备“不安全”。几乎每天都能看到有人因“黑客”而失去毕生积蓄。在这种背景下，人们真心相信锁定设备能让他们更安全，防止被“黑”。
掌权者确保人们永远听不到另一种声音，不知道自己正把绝对控制权交给大型公司。以我的经验来看，一旦问题被表述为“谷歌将决定你能否使用你的手机”，每个人都会立刻愤怒。
如果你想做出有意义的贡献，哪怕很小，也请努力教育人们，让他们明白自己正在赋予谷歌这样的大公司控制权。说服他们谷歌等公司并不站在他们这边其实并不难，他们早已知道并经历过。其次，要鼓励他们给国会议员写信。这很简单，政治家害怕得罪选民，他们依赖选民的无知，悄悄地违背选民利益，支持那些给他们选举资金捐赠最多的特殊利益团体。
Obsidian plugin was abused to deploy a remote acce… #
https://news.ycombinator.com/item?id=48090255
Obsidian CEO here. There is a major update coming soon for plugin security. I think it will address many of the concerns people have raised in this thread. It’s a hard problem but we are working on it.
That said, the headline is misleading. This article is about a social engineering attack that requires the user to actively reject multiple safety warnings in Obsidian. As far as I know this is a proof of concept, I haven’t seen any reports of users being affected by this attack.
kepano
我是 Obsidian 的首席执行官。很快将发布一项关于插件安全性的重大更新。我认为这将解决许多人在本帖中提出的担忧。这是一个难题，但我们正在努力解决。
不过，标题有些误导。本文讲的是一种社交工程攻击，要求用户主动多次忽视 Obsidian 中的安全警告。据我所知，这只是一个概念验证，目前尚未收到有用户因此攻击受影响的报告。
I’m going back to writing code by hand #
https://news.ycombinator.com/item?id=48093197
Yep. The only people I’ve heard saying that generated code is fine are those who don’t read it.
The problem is that the mitigations offered in the article also don’t work for long. When designing a system or a component we have ideas that form invariants. Sometimes the invariant is big, like a certain grand architecture, and sometimes it’s small, like the selection of a data structure. You can tell the agent what the constraints are with something like “Views do NOT access other views’ state” as the post does.
Except, eventually, you’ll want to add a feature that clashes with that invariant. At that point there are usually three choices:
-
Don’t add the feature. The invariant is a useful simplifying principle and it’s more important than the feature; it will pay dividends in other ways.
-
Add the feature inelegantly or inefficiently on top of the invariant. Hey, not every feature has to be elegant or efficient.
-
Go back and change the invariant. You’ve just learnt something new that you hadn’t considered and puts things in a new light, and it turns out there’s a better approach.
Often, only one of these is right. Often, at least one of these is very, very wrong, and with bad consequences.
Picking among them isn’t a matter of context. It’s a matter of judgment, and the models - not the harnesses - get this judgment wrong far too often. I would say no better than random chance.
Even if you have an architecture in mind, and even if the agent follows it, sooner or later it will need to be reconsidered. What I’ve seen is that if you define the architectural constraints, the agent writes complex, unmaintainable code that contorts itself to it when it needs to change. If you don’t read what the agent does very carefully - more carefully than human-written code because the agent doesn’t complain about contortious code - you will end up with the same “code that devours itself”, only you won’t know it until it’s too late.
pron
是的。我听说觉得生成的代码没问题的人，通常是那些根本不看代码的人。
问题是，文章中提出的缓解措施也不能长久奏效。在设计系统或组件时，我们会有一些形成不变量的想法。有时候这个不变量很宏大，比如某种宏伟的架构，有时候很小，比如选择某种数据结构。你可以用类似“视图不访问其他视图的状态”这样的话告诉智能体约束条件，就像文章中说的那样。
但是，最终你会想要添加一个与该不变量冲突的功能。这时通常有三种选择：
-
不添加该功能。不变量是一个有用的简化原则，它比功能更重要；长远来看它会带来收益。
-
在遵循不变量的基础上，不优雅或低效地添加该功能。嘿，并不是每个功能都必须优雅或高效。
-
回头修改不变量。你刚学到了一些之前没考虑过的新东西，这给事情带来了新视角，事实证明有更好的方法。
通常，这三种选择中只有一种是正确的。往往至少有一种是非常糟糕的，会带来恶劣后果。
选择哪一种不是凭情境决定的，而是凭判断。模型——而非辅助工具——很大程度上判断错误得太多了。我认为它们的判断不比随机选择好多少。
即使你心中有一个架构蓝图，即使智能体遵循它，迟早都需要重新考虑它。我看到的情况是，如果你定义了架构约束，智能体写出来的代码会变得复杂且难以维护，为了遵守约束而扭曲自己，一旦需要变更就更麻烦。如果你不比看人工代码更仔细地检查智能体写的代码——因为智能体不会抱怨扭曲的代码——最终你得到的就是“吞噬自身的代码”，但你到那时可能已经太晚才发现。
Hardware Attestation as Monopoly Enabler #
https://news.ycombinator.com/item?id=48087095
Requiring authorized silicon (and software) isn’t even the biggest problem here.
They do not use zero knowledge proof systems or blind signatures. So every time you use your device to attest you leave behind something (the attestation packet) that can be used to link the action to your device. They put on a show about how much they care about your privacy by introducing indirection into the process (static device ‘ID’ is used to acquire an ephemeral ‘ID’ from an intermediate server) but it’s just a show because you don’t know what those intermediary severs are doing: You should assume they log everything.
And this just the remote attestation vector, the DRM ‘ID’ vector is even worse (no meaningful indirection, every license server has access to your burned-in-silicon static identity). And the Google account vector is what it is.
Using blind signatures for remote attestation has actually been proposed, but no one notable is currently using it: < https://en.wikipedia.org/wiki/Direct_Anonymous_Attestation >
There are several possible reasons for this, the obvious one is that they want to be able to violate your privacy at will or are mandated to have the capability. The other is that because it’s not possible to link an attestation to a particular device the only mitigation to abuse that is feasible is rate limiting which may not be good enough for them - an adversary could set up a farm where every device generates $/hour from providing remote attestations to ‘malicious’ actors.
coppsilgold
要求授权的硅片（和软件）甚至不是这里最大的问题。
他们没有使用零知识证明系统或盲签名。因此，每次你使用设备进行证明时，都会留下某些东西（证明数据包），可以用来将该操作与设备关联起来。他们通过在流程中引入中间环节（静态设备“ID”用于从中间服务器获取临时“ID”）来装作很在意你的隐私，但这只是表面功夫，因为你不知道这些中间服务器在做什么：你应该假设它们都会记录所有内容。
而这仅仅是远程证明的渠道，DRM的“ID”渠道更糟糕（没有有意义的中间环节，每个授权服务器都能访问你焊接在硅片上的静态身份）。至于谷歌账户渠道，也就是它本来的样子。
远程证明使用盲签名的方案实际上已经被提出过，但目前没有什么知名方在使用： https://en.wikipedia.org/wiki/Direct_Anonymous_Attestation
这可能有几个原因，显而易见的是，他们想随时能够侵犯你的隐私，或者被要求必须具备这种能力。另一个原因是因为无法将证明绑定到特定设备，唯一可行的防止滥用的措施就是限速，但这可能不够——对手可能会建立一个矿场，让每台设备通过向“恶意”用户提供远程证明，每小时产生收入。
Driver accused of DUI tracks missing laptop to Ill… #
https://news.ycombinator.com/item?id=48095985
The offending trooper’s lie was comically bad:
“I kept it for his courtesy, like I said with his phone, key and wallet,” Bradley told investigators. “It’s my mistake. I forgot to give him his stuff back and he tracked it.” For anyone who knows policing, evidence and suspect possessions do NOT go the arresting officer’s home for obvious reasons.
everdrive
这名违规警员的谎言糟糕得令人发笑：
“我出于礼貌保管了他的东西，就像我说的，他的手机、钥匙和钱包，”布拉德利告诉调查人员。“是我的错误，我忘了把他的东西还给他，他才追踪到了。”
对任何了解警务的人来说，证据和嫌疑人的私人物品绝对不会因为明显的原因被带回逮捕警员家里。
The locals don’t know #
https://news.ycombinator.com/item?id=48086519
The corollary of this is that if you are a local you should do some more touristy things.
I don’t mean to go to a tourist trap and get scammed, but just enjoy your city a little more and do some things that usually only tourists do.
For example, despite living most of my life in London, I’ve never been to the Tower of London. Why would I? It’s for tourists. Except it’s probably quite fascinating, especially for a local.
zarzavat
其推论是，如果你是当地人，你应该多做一些旅游者才会做的事情。
我不是说去那些游客陷阱被坑，而是要多享受你的城市，做一些通常只有游客才会做的事。
比如，虽然我大部分时间都住在伦敦，但我从来没去过伦敦塔。为什么呢？那是给游客去的地方。但其实对当地人来说，那里可能非常有趣。
I’m going back to writing code by hand #
https://news.ycombinator.com/item?id=48094681
The “people” in your hypothetical story have been wrong the whole time. The correct attitude is:
When AI can complete lines, you still have to read and understand the code.
When AI can complete whole functions, you still have to read and understand the code.
When AI can complete features and tickets, you still have to read and understand the code.
raincole
你假设故事中的“人们”一直都是错的。正确的态度是：
当人工智能能补全代码行时，你仍然需要阅读并理解代码。
当人工智能能补全整个函数时，你仍然需要阅读并理解代码。
当人工智能能完成功能和任务时，你仍然需要阅读并理解代码。
Local AI needs to be the norm #
https://news.ycombinator.com/item?id=48088051
They will be, and that moment is not that far off. We’ve got the progression in place already: first, large data centers could have performant LLMs, we are now firmly in “a bunch of servers with a couple of H100s each” territory, slowly going into “128 GB VRAM on a MacBook Pro or a Strix Halo”. Within the next year, the pattern of “expensive remote LLM for planning, local slow-but-faster-than-human LLM for execution” will become the norm for companies, slowly moving to “using local LLM for everything is good enough”. And then we’ll have the equilibrium we already have with the “classic cloud”: you either self-host or pay for flexibility and speed. The question will be: how much of the current compute capacity craze will local hosting give the kiss of death to and what that means for the market.
pronik
它们会到来的，这一刻也不会太远。我们已经有了发展的路线：首先，大型数据中心可以运行高性能的语言模型，现在我们已经稳步进入“每台服务器配备几块H100显卡”的阶段，逐渐过渡到“MacBook Pro或Strix Halo拥有128GB显存”的阶段。在接下来的一年内，“用于规划的昂贵远程语言模型，本地用于执行的较慢但比人类快的语言模型”的模式将成为企业的常态，之后将逐步转向“本地语言模型处理一切已经足够好”。然后我们将达到类似于“经典云服务”的平衡：你要么自建主机，要么为灵活性和速度付费。问题将是：本地部署将使当前计算能力的疯热降温多少，以及这对市场意味着什么。
A.I. note takers are making lawyers nervous #
https://news.ycombinator.com/item?id=48093752
The main point raised in the article is that these bots may void attorney client privileges.
But the real danger with these IMO is that they’re turning casual conversations into a permanent record, and one that will be completely discoverable in court, should the company get into trouble later.
burningion
文章中提出的主要问题是这些机器人可能会使律师与客户之间的保密特权失效。
但依我看，更大的危险在于它们将随意的对话变成了永久记录，而如果公司以后陷入麻烦，这些记录将完全可以在法庭上被查阅。
Incident Report: CVE-2024-YIKES #
https://news.ycombinator.com/item?id=48086588
For anyone confused, this is (very good imo) fiction about supply-chain incidents. It had me very worried during a brief scan that it was real though, which made me read it more attentively :)
lynndotpy
对于感到困惑的人来说，这是（我认为非常好）的关于供应链事件的虚构作品。不过在快速浏览时，我一度非常担心这是真的，这反而让我读得更加仔细 :)
Task Paralysis and AI #
https://news.ycombinator.com/item?id=48083162
I do have an actual diagnostic and I had the same experience over the past year with early coding harness at the beginning of the year, then Claude code since its release date. But after 1+year going that direction I really don’t want to continue. The novelty is gone, dealing with AI now feels frustrating and boring, I miss engaging deeply with the actual lower level technical challenges. I do not want to manage fleets of agents. I do not want to rediscover for the hundredth time that in fact all this time an agent took shortcuts for acceptance tests I rely upon and didn’t catch. Or once again get the agent to understand why and what I want it to do after its context got bloated and it start to drift completely. While I got artifacts I can use (libraries, tools, docs), including some things that I’m pretty confident are SoA I do not feel satisfied anymore knowing that I used a model to generate them, even if I was the one designing every part of it. I do feel that I’m lying anytime I come to a colleague to share a new cool tool I have made. And I do not feel that relying on AI actually helped me improve with dealing with my executive function issues.
YMMV but I’m personally feeling burnt out with AI coding agents and ready to go back to the old ways for my next personal project
dgellow
我确实有一个实际的诊断，并且过去一年中我也经历了类似的情况——年初用早期的编码代理，后来从发布日起用Claude代理。但在走了这一年多的路后，我真的不想继续了。新鲜感已经消失，现在与AI打交道让我感到沮丧和乏味，我怀念那种深入解决底层技术挑战的感觉。我不想管理一大批代理。我也不想第几百次地重新发现，其实一直以来代理为了通过我依赖的验收测试都在走捷径，而我却没有察觉。也不想再一次让代理理解我想做什么、为什么想做，尤其是在它的上下文膨胀后开始完全跑偏的时候。虽然我得到了可以用的成果（库、工具、文档），包括一些我很有信心属于最新技术水平的东西，但知道这些都是用模型生成的，我心里不再满足，即使每个部分都是我设计的。我感觉每次去找同事分享我做的一个新酷工具时，都是在说谎。我也感觉依赖AI并没有真的帮助我改善执行功能方面的问题。
可能每个人感受不同，但我个人对AI编码代理感到精疲力竭，准备在下一个个人项目中回归传统的做法。
I returned to AWS and was reminded why I left #
https://news.ycombinator.com/item?id=48083574
A lot of these projects work on a business model where they open-source their core product, and provide advanced services, installation, maintenance or fully-managed services around their product. AWS was bypassing them by providing fully-managed services. On this, I am on the side of the people behind the projects. Basically AWS was eating their lunch. They had no choice but to change the licenses.
hankerapp
很多这些项目的商业模式是开源他们的核心产品，同时围绕产品提供高级服务、安装、维护或全托管服务。AWS通过提供全托管服务绕过了他们。在这点上，我支持这些项目背后的人。基本上，AWS在抢他们的饭碗。他们别无选择，只能更改许可证。
Gmail registration now requires scanning a QR code… #
https://news.ycombinator.com/item?id=48093829
Any Gmail person can tell me why Gmail is tolerating Gmail phishing emails that use Google’s own services (e.g. https://storage.googleapis.com/savelinge/… ?
More info here: https://news.ycombinator.com/item?id=46665414
dvh
有谁用Gmail可以告诉我，为什么Gmail会容忍那些利用谷歌自家服务（例如 https://storage.googleapis.com/savelinge/…）的钓鱼邮件吗？
更多信息见这里：https://news.ycombinator.com/item?id=46665414
Hardware Attestation as Monopoly Enabler #
https://news.ycombinator.com/item?id=48088065
In 1999, Intel received an absolutely massive amount of opposition when they decided to include a software-readable serial number in their CPUs, so much that they reversed the decision.
Then the “security” and Trusted Computing authoritarians continued pushing for TPMs and related tech, and contributed to the rise of mobile walled gardens. Windows 11’s TPM requirements were another step towards their goal. The amount of propaganda about how that was supposed to be a good thing, both here and elsewhere, was shocking.
It turns out a significant (but hopefully decreasing) number of the population is easily coerced into anything when “security” is given as a justification.
The war on general-purpose computing continues, and we need to keep fighting.
Stallman was right, as always. Time to give his “Right to Read” another read. (If it hasn’t been done already, an AI-generated short film of it would be a great idea…)
“Those who give up freedom for security deserve neither.”
userbinator
1999年，当英特尔决定在其CPU中包含一个软件可读的序列号时，遭到了极大的反对，以至于他们最终撤回了这一决定。
随后，“安全”和可信计算的权威者继续推动TPM及相关技术的发展，并促使移动设备形成了封闭的生态系统。Windows 11对TPM的要求则是向他们目标迈进的又一步。在这里和其他地方，有关这应该是好事的大量宣传让人震惊。
事实证明，仍有相当一部分人（希望这个比例在减少）在“安全”作为理由时，容易被强迫接受任何事物。
对通用计算的战争仍在继续，我们需要继续抗争。
斯托曼一如既往地是对的。是时候重新阅读他的《阅读权利》了。（如果还没有做过，用AI制作一个基于它的短片会是个好主意……）
“那些为了安全而放弃自由的人，两者都不配拥有。”
Gmail registration now requires scanning a QR code… #
https://news.ycombinator.com/item?id=48098490
They’ve essentially gotten roped into maintaining a huge chunk of internet infrastructure, for free.
I’ll stop you here. Google offered it for free and, at the time, offered such an high amount of mail storage for free it sounded insane. At the time, my ISP gave me a 25MB or 50MB inbox and that was considered pretty decent, when Google was trying to get people in with 1-2GB.
They absolutely have a right to take ant steps they deem necessary to prevent malicious use of their product, and certainly aren’t obligated to provide it for free, but Google wasn’t forced to provide a free email service, much less one that went so far above and beyond their competition.
redserk
他们实际上被迫免费维护了互联网基础设施的大部分。
我先打断你。谷歌当时提供的是免费的，而且当时他们提供的邮箱存储容量非常大，听起来简直疯狂。那时候，我的网络服务商给我的邮箱只有25MB或50MB，这已经算不错了，而谷歌则试图用1到2GB的空间吸引用户。
他们完全有权采取任何他们认为必要的措施来防止恶意使用他们的产品，当然也没有义务免费提供服务，但谷歌并不是被迫提供免费邮箱服务，更不用说提供远超竞争对手的服务了。
Microsoft Israel chief leaves amid ethical controv… #
https://news.ycombinator.com/item?id=48098726
TIL that Microsoft is the least Israel-friendly of the big three clouds
This is a good thing.
American companies should not be allowing their tech to be used to in the gross ongoing human rights violations in Israel/Gaza/West Bank.
Google and Amazon knew their tech could be used for human rights abuses in Israel (their lawyers warned them so) but ignored that in favour of $$$ per the EFF:
bhouston
今天才知道，微软是在三大云服务商中对以色列最不友好的。
这是一件好事。
美国公司不应该允许他们的技术被用来持续进行以色列、加沙地带和约旦河西岸地区的严重侵犯人权行为。
谷歌和亚马逊知道他们的技术可能被用于以色列的人权侵害（律师曾警告过他们），但他们无视这一点，选择追求利润，根据电子前哨基金会（EFF）的说法：