2026-03-22 Hacker News Top Stories #

开源AI编程助手OpenCode虽兼容多模型但存在资源占用高和稳定性差的问题，相比之下采用Rust实现的Codex在性能和用户体验上表现更优。

微软宣布多项措施提升Windows 11质量并恢复经典功能，但用户批评其长期忽视需求且大型科技公司已普遍背离用户至上的产品理念。

主流媒体以防范AI训练为由阻止互联网档案馆爬虫，但EFF警告此举将永久抹除网络历史记录，且引发关于robots.txt适用性的广泛争议。

文章以树木生长为隐喻批判现代社会对速度的盲目崇拜，指出真正有价值的事物需要长期沉淀，而过度依赖AI工具追求效率反而可能形成恶性循环。

文章详解日本筷子使用的28种禁忌及其与佛教文化的关联，但评论指出实际遵守程度因地域、场合和社会阶层差异而并不绝对。

Ghostling是基于libghostty的极简终端演示项目，展示了将TUI应用封装为跨平台桌面应用的技术潜力，引发了关于此类工具实用性的讨论。

Ubuntu 26.04将默认显示sudo密码输入的星号反馈，终结长达46年的无声输入传统，用户仍可通过修改配置恢复旧版行为。

开发团队将Rust编写的WASM解析器重写为TypeScript后性能提升2-4倍，证明在频繁跨语言边界场景下纯JavaScript方案可能比WebAssembly更高效。

Deno项目陷入衰落危机且CEO疑似低调离职，反映了VC资本驱动下开源项目难以坚持技术初心并最终与主流生态妥协的困境。

Kimi团队提出Attention Residuals机制通过动态融合Transformer层级信息提升推理性能，其年轻作者团队引发关于中美教育体系差异的广泛讨论。

1. OpenCode – 开源 AI 编程助手 (OpenCode – Open source AI coding agent) #

https://opencode.ai/

OpenCode 是一个开源的 AI 编程助手，支持在终端、IDE 或桌面应用中使用，已获得超过 12 万 GitHub 星标，拥有 800 多名贡献者，每月被超过 500 万开发者使用。

它具备多项核心功能：支持自动加载适用于 LLM 的语言服务器协议（LSP），可并行启动多个会话处理同一项目，支持通过链接共享会话用于参考或调试。用户可登录 GitHub 使用 GitHub Copilot 账户，或通过 OpenAI 登录使用 ChatGPT Plus/Pro 服务。

OpenCode 支持超过 75 个 LLM 提供商，包括 Claude、GPT、Gemini 等，也可连接本地模型，兼容性极强。支持终端、桌面应用和 IDE 插件多种使用方式，适配性广泛。

强调隐私保护，不存储用户的代码或上下文数据，适合对数据安全要求高的环境。

此外，Zen 是 OpenCode 推出的模型服务，提供经过验证、优化的 AI 模型，专为编程任务设计，确保性能稳定、质量可靠。

用户可通过 curl、npm、bun、brew 等方式快速安装，支持 macOS、Windows 和 Linux 系统的桌面 beta 版本。官网提供详细文档、更新日志和社区支持。

HN 热度 1190 points | 评论 586 comments | 作者：rbanffy | 1 day ago #

https://news.ycombinator.com/item?id=47460525

OpenCode 虽然是首个使用的开源 AI 编码代理，但其开发节奏过快，缺乏充分测试和变更记录，导致功能频繁变动且不稳定。
OpenCode 代码库过于庞大复杂，资源消耗高，常占用 1GB 以上内存，对 TUI 工具而言效率偏低。
OpenCode 的 TUI 界面过于繁杂且存在 bug，功能冗余，使用体验不佳，难以记忆和操作。
相比之下，Codex 采用 Rust 实现，性能优越，资源占用低，响应更流畅，用户体验更佳。
Claude Code 作为 Electron 应用，存在内存占用高、CPU 占用率高、界面重绘异常等问题，影响使用体验。
claude 命令行工具使用标准屏幕缓冲区，保留聊天历史在终端滚动缓冲区，优于使用备用屏幕的方案。
claude 在终端窗口大小变化时存在重绘问题，但这一设计牺牲了性能换取了更好的历史记录保留。
Codex 支持客户端/服务器架构，可在不同机器间连接，具备良好的可扩展性和跨平台兼容性。
OpenCode 也支持类似客户端/服务器模式，但未明确说明其具体实现。
有人指出 claude 启动速度慢，但使用一段时间后体验改善，清理配置后可解决启动延迟问题。
有人反映 claude 在 zellij 中存在破坏滚动历史的问题，属于已知但未修复的 bug。
有人建议 Anthropic 将 Claude Code 重写为 Rust，以提升性能和用户体验，认为这在技术上可行且值得。
有人提出 Go 可能是更好的替代语言，因其更易上手、依赖少、可生成单个跨平台二进制文件。
Go 语言学习门槛低，一天内即可上手，而 Rust 学习曲线陡峭，对新手不够友好。
尽管 Rust 代码质量高，但其复杂性、编译器错误解释困难、构建系统复杂等因素阻碍了新贡献者参与。
有人认为当前开发者更熟悉 TypeScript，因此工具多用 TypeScript 开发，但这并非技术最优选择。
有人指出 Claude Code 已由 Claude 自身生成代码，人类编写代码已极少，体现了 AI 生成代码的现状。

2. 对 Windows 质量的承诺 (Our commitment to Windows quality) #

https://blogs.windows.com/windows-insider/2026/03/20/our-commitment-to-windows-quality/

微软 Windows Insider 团队负责人 Pavan Davuluri 在 2026 年 3 月 20 日发布博客，回应 Windows 社区的反馈，宣布一系列旨在提升 Windows 11 质量的改进措施。

首要改进包括：支持将任务栏重新定位至屏幕顶部、左侧或右侧，增强个性化体验；优化 Copilot 的集成方式，减少在 Snipping Tool、Photos、Widgets 和 Notepad 等应用中的冗余入口，聚焦于真正有用且设计精良的功能。

在系统更新方面，将提升用户对更新的控制力，支持跳过设备设置期间的更新、无需安装即可重启或关机，并可更长时间暂停更新，同时减少自动重启和通知带来的干扰。

文件资源管理器将获得显著优化，包括更快的启动速度、更少的闪烁、更流畅的导航以及更可靠的文件操作性能，尤其在大文件复制移动和搜索功能上表现提升。

Widgets 和发现频道将调整为更安静的默认设置，提供更精细的控制选项，增强个性化，避免信息过载。

Windows Insider 计划将简化流程，明确各频道定义，提升构建质量，增强反馈对产品演进的可见性，并提供更多与团队直接互动的机会。

反馈中心（Feedback Hub）已推出全新设计，支持更快速、便捷地提交反馈，并加强社区互动。

长期计划聚焦于性能、可靠性和体验设计三大核心领域：提升系统整体响应速度，降低内存占用，改善高负载下的稳定性；推进核心界面迁移至 WinUI3 框架，减少交互延迟；优化文件资源管理器的搜索、导航与文件操作效率；提升 Windows Sub 系统 for Linux（WSL）的性能、网络兼容性与企业级管理能力。

团队还计划在全球多个城市举办线下活动，与 Windows 社区面对面交流，持续倾听用户声音。

微软强调，Windows 是属于用户的共同产品，将持续夯实系统基础，推动真正有价值的创新。欢迎持续提供反馈，共同塑造 Windows 的未来。

HN 热度 609 points | 评论 1141 comments | 作者：hadrien01 | 1 day ago #

https://news.ycombinator.com/item?id=47459296

微软过去十多年一直忽视用户需求，而 Linux 在桌面体验和内核性能上持续进步，如今在游戏兼容性方面已接近 Windows，且无隐私侵犯和反用户功能，微软转型已显迟滞。
大型科技公司逐渐从“用户至上”转向“产品主导”，导致系统设计脱离用户实际需求，如 Windows 中出现多个音频控制面板、开始按钮位置异常、搜索功能失效等问题。
苹果在 Mac OS X Snow Leopard 时期曾实现优秀的产品设计，但随后在 iOS 7 之后逐渐偏离，进入 UI 混乱、交互不一致的“液态玻璃”时代，尽管硬件性能依然出色。
苹果的硬件设计成功源于工程驱动，而产品管理团队往往破坏用户体验，真正优秀的产品应由工程师主导。
有人指出，苹果研发团队中亚洲裔占比较高，但不应以国籍或种族归因于技术成就，关键在于能否写出高质量、无缺陷的代码并满足用户需求。
从长远看，苹果虽未完全继承 Sun 的 Unix 工作站传统，但成功将 Unix 普及到大众市场，其系统在 RISC 平台上表现良好。
Windows 在服务器领域早已通过 IIS、Active Directory 等技术占据主导，其 UNIX 基础虽被重视但仅限于“够用”水平。
Windows 11 将开始菜单移至屏幕中央，虽违背用户习惯，但可理解为适应超宽屏显示器的视觉范围，避免用户忽略弹出菜单。
Windows 11 移除了任务栏可移动至屏幕任意边缘的功能，这是对长期用户习惯的倒退，尽管新版本已宣布恢复该功能，但已造成用户信任损失。
将开始菜单移至屏幕中央的决策缺乏充分理由，且未提供选项让用户自主选择，反映出系统设计脱离用户实际使用场景。

3. 阻止互联网档案馆无法阻止人工智能，但会抹去网络的历史记录 (Blocking Internet Archive Won’t Stop AI, but Will Erase Web’s Historical Record) #

https://www.eff.org/deeplinks/2026/03/blocking-internet-archive-wont-stop-ai-it-will-erase-webs-historical-record

文章标题为《阻止互联网档案馆无法阻止人工智能，但会抹去网络的历史记录》，由 EFF（电子前沿基金会）的乔·穆林于 2026 年 3 月 16 日撰写。

文章指出，近期《纽约时报》等主流媒体开始通过技术手段阻止互联网档案馆（Internet Archive）对其网站的爬取，这一行为已超出传统的 robots.txt 规则范畴。互联网档案馆自 1990 年代起致力于保存网络历史，其核心项目“时光机”（Wayback Machine）已收录超过一万亿个网页，是记者、研究人员和司法系统的重要工具。

文章强调，这些被保存的网页往往是唯一可查证的原始发布记录。许多新闻文章在发布后会被修改、删除或替换，而互联网档案馆的存档为追溯这些变化提供了关键依据。若主流媒体持续屏蔽档案馆的爬虫，将导致大量历史信息永久消失。

尽管媒体以担忧人工智能公司滥用内容为由采取行动，但文章指出，互联网档案馆并非商业 AI 公司，其使命是公共历史保存。将档案馆排除在数据访问之外，是对历史记录的破坏，是用短期的 AI 争议牺牲长期的公共利益。

文章援引法律判例说明，对内容进行索引和搜索属于合理使用范畴。谷歌扫描书籍建立可搜索数据库的案例已被法院认定为合理使用，互联网档案馆的存档行为同样具有类似正当性。其服务已支撑包括维基百科在内的全球大量研究与信息获取工作。

文章最后警告，当前围绕 AI 训练的法律争议应通过司法途径解决，而非以牺牲公共历史记录为代价。若任由媒体关闭档案馆访问，未来研究者将面临大量信息空白，这种损失可能是不可逆的。

HN 热度 485 points | 评论 137 comments | 作者：pabs3 | 17 hours ago #

https://news.ycombinator.com/item?id=47464818

网站运营者担忧其反爬虫策略可能误伤互联网档案馆，尽管档案馆通常遵守 robots.txt，但实际中仍存在不尊重网站意愿的情况。
互联网档案馆和 Archiveteam 等组织明确表示不遵循 robots.txt，认为其初衷是为搜索引擎服务，而非用于网站存档。
一些人认为 robots.txt 的原始用途是防止爬虫陷入动态链接的无限循环，而如今被用于阻止静态内容的存档，这导致了混淆和争议。
Archiveteam 的激进爬取行为源于其抢救即将关闭网站内容的使命，其动机是保护文化遗产，而非恶意破坏。
有观点指出，尽管 Archiveteam 目标正当，但其行为方式仍属不当，不应以牺牲网站正常运行为代价。
有人提出应建立基于数字签名或 mTLS 的白名单机制，允许可信机构如互联网档案馆绕过反爬策略，以实现更友好的数据存档。
随着 AI 爬虫技术日益先进，未来可能难以通过技术手段阻止其访问公开网页，人类浏览器与 AI 代理的界限将逐渐模糊。
未来可能形成由可信机构主导的集中化存档体系，为 AI 模型提供结构化、低负担的数据获取渠道。
当前技术手段难以有效阻止 AI 爬虫，除非有强有力的立法与执行机制，但现实中的法律缺乏实际约束力。
个人网站运营者可能不得不放弃对内容存档的控制权，转而适应由大型机构主导的公开信息存档生态。

4. 有些事，终究要靠时间 (Some things just take time) #

https://lucumr.pocoo.org/2026/3/20/some-things-just-take-time/

文章探讨了在追求速度与效率的当下，时间的价值被严重低估。作者以树木生长为隐喻，指出真正有价值的事物——如成熟森林、历史悠久的建筑、深厚的人际关系和可靠的开源项目——都需要长期积累，无法通过捷径复制。

现代社会崇尚即时满足，从快速迭代的软件开发到 AI 驱动的代码生成，人们不断压缩流程中的“摩擦”。然而，这些看似低效的环节，恰恰是保证质量、建立信任和实现可持续发展的关键。合规审查、冷静期、人工审核等“慢步骤”并非障碍，而是防止冲动决策、确保长期可靠性的必要机制。

作者观察到，许多初创公司和开源项目在短暂活跃后迅速消失，缺乏对用户和社区的责任感。这种“快速启动、快速放弃”的模式破坏了信任，也削弱了长期建设的可能性。真正的成功不在于速度，而在于坚持与承诺。

作者反思自己身处 AI 热潮中心，尽管使用各种高效工具，却感到时间越来越少。因为节省下来的时间很快被更多任务填满，形成恶性循环。他强调，真正的价值来自长期投入：一个持续维护二十年的开源项目，一段十年的创业经历，都不是靠效率工具实现的，而是靠持续的参与和时间的沉淀。

最后，作者以亲手种下一棵树作结，表达对时间的尊重——他不急于看到结果，而是相信，唯有时间，才能让一棵树、一个项目、一段关系真正扎根、成长并庇荫他人。

HN 热度 482 points | 评论 163 comments | 作者：vaylian | 10 hours ago #

https://news.ycombinator.com/item?id=47467537

速度只有在方向正确时才有意义，否则加速反而会延长到达目标的时间。
使用 AI 进行研究或快速原型开发有助于明确方向，而多阶段的代理工作流则能有效防止 AI 偏离轨道。
直接让 AI 根据简单需求实现功能或修复 bug，容易因误解或错误假设而陷入死胡同。
产品方向若缺乏用户真实反馈，盲目快速迭代可能导致错误方向的持续放大。
快速发布新功能虽能加速试错，但用户反馈周期长，难以及时调整，可能引发用户不满。
有效的实验框架可控制新功能的发布范围，降低错误方向带来的负面影响。
有时快速试错是必要的，但不应成为忽视前期思考和规划的借口。
真正高效的开发依赖于对问题的深刻理解，而非单纯追求速度。
在缺乏清晰目标的情况下，快速构建反而可能浪费更多资源。
深度思考和长期积累是高质量产品诞生的基础，AI 只能作为辅助工具。
产品愿景和纪律比速度更重要，盲目追求快速开发会引入脆弱且无用的功能。
AI 生成的内容质量取决于使用者的判断力，缺乏方向感的使用只会产出更多无用信息。
用 AI 快速验证错误方向虽能加速认知，但不如一开始就构建正确方向来得高效。
产品开发中应结合“探查-测试-修正”的迭代循环，而非一味追求速度。
长期的思考和沉淀能为 AI 工具提供坚实的方向基础，使其真正发挥作用。
忽视现实世界反馈的长期闭门造车，可能导致产品与用户需求严重脱节。

5. 日本筷子禁忌全指南（2022） (A Japanese glossary of chopsticks faux pas (2022)) #

https://www.nippon.com/en/japan-data/h01362/

本文是一篇关于日本筷子礼仪的详细指南，旨在帮助读者了解在日本用餐时应避免的筷子使用禁忌。文中列举了多种被称为“きらい箸”（kiraibashi）的不当行为，涵盖从基本动作到严重禁忌的各类失礼举动。

文章按日语五十音图顺序列出 28 种筷子使用禁忌，其中部分行为被标注为“严重”（!!!），如将筷子直立插入米饭中（立て箸），因其与佛教葬礼供品相似而被视为大忌。其他常见禁忌包括：用筷子传递食物（合わせ箸）、将筷子在汤中清洗（洗い箸）、将筷子交叉放在碗上（橋箸）、用筷子戳食物（刺し箸）或指向他人（指し箸）等。

此外，文中还解释了部分行为的文化背景，例如“返し箸”（翻转筷子）因涉及遗骨传递而禁忌，“透かし箸”（穿过鱼骨吃鱼）虽常见但被认为不雅。还有如“涙箸”（汤汁滴落）“ねぶり箸”（舔筷子）等细节，均体现了日本饮食文化中对整洁与尊重的重视。

文章最后强调，正确使用筷子不仅是礼貌体现，更是对食物与用餐场合的尊重。通过了解这些禁忌，游客或学习者可更自然地融入日本饮食文化。

HN 热度 456 points | 评论 351 comments | 作者：cainxinth | 1 day ago #

https://news.ycombinator.com/item?id=47460452

使用筷子时，将筷子尖端抬高过手背是不合适的，但实际用餐中难以避免，因此并非绝对禁忌。
有些日本餐桌礼仪在东京等地被频繁违反，例如将筷子并排放在桌上或用来搅拌味噌汤，说明这些“禁忌”可能并不严格。
不同地区对礼仪的重视程度不同，例如京都人对筷子使用规范极为讲究，而大阪人则相对随意，导致礼仪差异可能源于地域文化而非普遍标准。
礼仪差异更多与家庭教养、社会阶层和正式程度相关，而非单纯由地域决定，社会背景在其中扮演重要角色。
美国等国家对用餐礼仪的重视程度较低，大多数人并不在意刀叉使用方式，即使在高档餐厅也无严格要求。
刀叉使用方式存在“欧洲式”与“美国式”之分，欧洲式是将刀叉换手，而美国式则保持刀叉在同一手，后者更常见于日常用餐。
一些人认为欧洲式刀叉使用更高效，而美国式则因习惯而流行，但两者并无绝对优劣。
左撇子在使用刀叉时可能更倾向于用非惯用手切食物，再用同一手叉食，这与传统规范不符，但实际操作中更自然。
有人认为用非惯用手切食物是基本能力，若无法做到则可能因年龄、身体状况或缺乏训练所致。
用餐时将肘部放在桌上被视为不礼貌，但现实中许多人仍这样做，说明规范虽存在，但执行程度不一。
社会规范的存在不因人们忽视而消失，即使多数人不遵守，标准依然有效。
对于礼仪标准的合理性存在质疑，应思考这些标准是谁制定的，为何被奉为“标准”。
某些礼仪标准是人为建构的，如英国的“标准发音”（RP），并非自然语言，而是上层阶级用来区分身份的工具。
RP 发音在当代英国已逐渐式微，多数人使用更口语化的方言，仅在特定场合或年长群体中保留。
尽管 RP 在媒体中少见，但在部分教育背景良好的人群中仍存在，不能简单断言其已消亡。
语言和礼仪标准的形成与家庭、教育和社会环境密切相关，而非天生或自然形成。

6. Ghostling：基于 libghostty 的极简终端演示项目 (Ghostling) #

https://github.com/ghostty-org/ghostling

Ghostling 是一个基于 libghostty C API 的极简终端演示项目，用单个 C 文件实现，旨在展示 libghostty 的核心功能。项目使用 Raylib 进行窗口管理和图形渲染，采用单线程架构，适合展示 libghostty 在不同环境下的灵活性。

libghostty 是从 Ghostty 终端中提取的嵌入式库，提供 C 和 Zig 接口，支持高性能、准确的终端仿真。其核心组件 libghostty-vt 是零依赖库（甚至不依赖 libc），负责处理 VT 控制序列解析、终端状态管理（如光标位置、样式、文本换行、滚动历史等），但不包含渲染或窗口逻辑，由使用者自行实现。

该演示项目已支持多项现代终端功能，包括：窗口大小调整与文本自动换行、24 位颜色与 256 色调色板、粗体、斜体、反显等文本样式、Unicode 多字符组合支持（无字形布局）、键盘输入及修饰键（Shift、Ctrl、Alt、Super）支持、Kitty 键盘协议、多种鼠标追踪模式（X10、普通、按钮、任意事件）、多种鼠标报告格式（SGR、URxvt、UTF8、X10）、滚轮滚动（支持视口回滚或传递给应用）、可拖拽滚动条、焦点报告（CSI I / CSI O）等。

未来计划支持的功能包括：Kitty 图形协议、OSC 剪贴板与标题设置。目前不支持 Windows 平台，主要受限于上游 Raylib 输入系统的不完善，导致 Kitty 键盘协议部分输入异常。

该项目不提供标签页、多窗口、分屏、会话管理、配置文件或搜索界面等 GUI 层功能，这些由使用者自行实现。其目标是保持极简，突出终端仿真核心能力。

构建要求包括 CMake 3.19+、Ninja、C 编译器、Zig 0.15.x，支持 macOS（需命令行工具或 Xcode）。建议使用 Release 模式构建以获得良好性能，Debug 模式因包含大量安全检查而极慢。

项目强调：libghostty 专注核心终端仿真，不提供 GUI 功能，适合嵌入到各类应用中。

HN 热度 316 points | 评论 64 comments | 作者：bjornroberg | 1 day ago #

https://news.ycombinator.com/item?id=47461378

Trolley 使用 libghostty 将 TUI 应用打包为桌面应用，效果出色，支持 Windows，开发体验良好。
项目 README 缺少截图，建议展示其界面外观，以明确其仅提供终端外壳（chrome）而非额外功能。
Ghostty 的界面类似于终端模拟器，与 Electron 类似，本质是将 TUI 包裹在 GUI 框架中。
项目具备跨平台潜力，未来可支持 Android 和 iOS，有望实现 CLI 工具的图形化封装，提升用户普及度。
有开发者希望将 Wordgrinder 等 TUI 工具转为 Mac 应用，表明其在桌面化 TUI 工具方面有实际需求。
在嵌入 Ghostty 时，关于 PTY 的所有权问题存在争议：由嵌入方或 Ghostty 自身管理各有优劣，需权衡接口简洁性与可观测性。
建议使用终端复用器（如 tmux）来解决多终端管理问题，提升架构清晰度。
项目通过 CMake 脚本将二进制资源（如图片）嵌入 C 代码，生成静态数组，实现跨平台资源嵌入。
C23 的 #embed 指令是更理想的解决方案，但当前部分环境（如 Nixpkgs 的 GCC）尚未支持。
xxd 是生成二进制头文件的常用工具，但对大文件效率低，不适合大型资源。
使用 objcopy 生成符号化的二进制对象文件，是另一种成熟的嵌入方式，适用于大型资源。
LIEF 项目可修改 PE、Mach-O、ELF 二进制文件并添加资源，支持跨平台资源管理，适合大体积资源场景。
XPM 格式设计初衷就是可直接包含在 C 代码中，是早期嵌入资源的典型方案。
有开发者提供 Lua 实现的 xxd 替代函数，可生成 C 风格的二进制数组，适用于小资源嵌入，且开源可复用。

7. Ubuntu 26.04 将终结长达 46 年的 sudo 密码输入无声传统 (Ubuntu 26.04 Ends 46 Years of Silent sudo Passwords) #

https://pbxscience.com/ubuntu-26-04-ends-46-years-of-silent-sudo-passwords/

Ubuntu 26.04 LTS 将终结长达 46 年的 sudo 密码输入无声传统，首次在终端输入 sudo 密码时显示 asterisks（星号），每输入一个字符即显示一个 *，以提升用户体验。

这一改变源于 sudo-rs 项目——一个用 Rust 语言重写的 sudo 实现。该版本自 Ubuntu 25.10 起作为默认 sudo 工具引入，功能与旧版一致，用户无感。但在 2026 年 2 月，上游 sudo-rs 项目默认开启 pwfeedback 功能，导致 Ubuntu 26.04 正式版将此行为设为默认。

开发者认为，隐藏密码长度的“安全”优势在现实中几乎无效，因为能够观察屏幕的人通常也能听到敲击声或直接看到输入。此外，大多数用户的 sudo 密码与图形登录密码相同，而登录界面已显示为点状，终端却保持沉默，造成不一致，属于“安全表演”。

反对者则担忧，此举暴露了密码长度，可能被“肩窥”攻击利用。但 Ubuntu 和 sudo-rs 团队均认为，这种风险极低，且用户体验的提升远超潜在风险。

用户若希望恢复传统无声输入，可通过 sudo visudo 编辑 sudoers 文件，添加 Defaults !pwfeedback 行即可，无需重启。

Ubuntu 26.04 还将带来其他重大更新：搭载 GNOME 50（仅 Wayland）、Linux 内核 7.0，以及更多基于 Rust 的核心工具，如 uutils/coreutils，标志着系统向内存安全和现代 UX 的全面演进。

HN 热度 307 points | 评论 307 comments | 作者：akersten | 19 hours ago #

https://news.ycombinator.com/item?id=47464134

为密码输入提示添加无视觉回显功能，可通过修改 KDE、sudo 或 GNOME 的配置文件实现，需重启生效。
在 GNOME 系统中，可通过修改 unlockDialog.js 文件将密码字符替换为 emoji，但仅限 GNOME 系统。
高延迟 SSH 连接下无法确认密码输入是否成功，容易因误操作导致认证失败，影响使用体验。
早期 Unix 系统因密码仅使用前 8 个字符，且加密算法存在缺陷，隐藏密码长度具有实际安全意义。
由于缺乏视觉反馈，用户常误以为输入未生效，导致频繁使用退格键或重新输入，影响效率。
有人因早期 Linux 安装时密码输入无反馈而放弃使用 Linux，直到多年后才重新尝试。
有人建议在远程管理时使用密钥认证而非密码，避免输入风险，提升安全性。
通过配置 sudo 的 nopasswd 选项，可实现免密码执行特定命令，提高操作便利性。
在 macOS 终端中，Ctrl+ 方向键等光标移动快捷键与 Linux 不一致，影响跨平台使用体验。
使用 Ctrl+U 可快速清除整行输入，是解决误输入问题的有效方法。
有人建议在密码中加入特殊符号（如斜杠）以避免误发到聊天工具，提高安全性。
有人建议将密码设计为看似合理的聊天消息，以防止在误粘贴时暴露敏感信息。

8. 我们用 TypeScript 重写 Rust WASM 解析器后，性能反而更快 (We rewrote our Rust WASM parser in TypeScript and it got faster) #

https://www.openui.com/blog/rust-wasm-parser

本文讲述了作者团队在开发 OpenUI-Lang 解析器时，从使用 Rust 编写的 WASM 解析器转向纯 TypeScript 实现的性能优化历程。

最初，团队采用 Rust 编写解析器并编译为 WASM，期望获得高性能。然而实际运行中发现，WASM 与 JavaScript 之间的边界开销（如字符串拷贝、JSON 序列化/反序列化）远超解析本身的时间，成为性能瓶颈。

尝试通过 serde-wasm-bindgen 直接返回 JsValue 以跳过 JSON 序列化，结果反而更慢。原因在于：JS 无法直接读取 WASM 内存中的 Rust 数据结构，serde-wasm-bindgen 需递归构建 JS 对象，产生大量细粒度的跨边界操作，效率低下。

最终解决方案是将整个解析流程完全重写为 TypeScript，彻底消除 WASM 边界开销。实测显示，单次解析性能提升 2.2 到 4.6 倍。

更关键的是，团队发现原始流式解析存在 O(N²) 的算法问题：每次新 chunk 都重新解析全部历史内容。为此引入“语句级增量缓存”机制：已完整解析的语句（以换行结束）被缓存，仅对未完成的末尾语句重新解析，实现 O(N) 的流式处理。

在真实流式场景下，总解析耗时从数百微秒降至不足 300 微秒，性能提升 2.6 到 3.3 倍。

总结：WASM 并非万能，当存在频繁跨边界交互时，纯 JS 实现反而更高效。WASM 更适合计算密集型、低交互的场景，如图像处理、视频编码等。

HN 热度 280 points | 评论 184 comments | 作者：zahlekhan | 1 day ago #

https://news.ycombinator.com/item?id=47461094

从 C++ 迁移到 Python 后，因意外修复了一个隐藏的性能瓶颈，导致程序运行速度提升 10 倍，最终决定将后端系统全面转向 Python。
Python 在某些场景下性能极差，例如监控服务中 Python 进程消耗了低配服务器 30%-40% 的 CPU 资源，最终项目因性能问题被终止。
Rust 编写的后端内存占用极低，甚至在监控中显示为 0MB，远优于 Python 和 Ruby 等语言。
选择开发语言时应优先考虑快速交付，即使性能不佳，只要能尽早让产品上线并获得用户反馈，比追求极致性能更重要。
项目失败的原因可能是性能不足，如果软件太慢，用户不会使用，因此性能问题可能直接导致产品失败。
Go 语言虽然被宣传为高性能，但实际使用中若缺乏良好设计，也可能写出效率极低的代码，问题不在于语言本身。
Python 代码在长期维护后容易变得难以理解，缺乏类型安全，而 TypeScript 或 Java 等静态类型语言在长期项目中更易保持代码质量。
对于需要高性能的场景，可选择在 Python 中仅用 C 或 Rust 实现关键性能模块，而非重写整个系统。
C++ 中某些难以察觉的底层错误（如意外调用拷贝构造函数）可能导致严重性能问题，而 Python 的抽象机制反而避免了这类问题。
一些现代 Python 框架（如 FastAPI）结合良好设计，可以在保持开发效率的同时实现高性能，值得借鉴。
20 年前的软件性能可能更优，但当时缺乏足够快的开发语言来探索新领域，现代语言让快速构建可用产品成为可能。

9. 404：Deno 首席执行官已找不到 (404 Deno CEO not found) #

https://dbushell.com/2026/03/20/denos-decline-and-layoffs/

作者在一篇博客文章中表达了对 Deno 项目现状的深切忧虑与反思。文章发布于 2026 年 3 月 20 日，标题为《404 Deno CEO not found》，以一种讽刺而沉重的语气，揭示了 Deno 项目的衰落。

文章开篇指出，作者访问 deno.com 时遭遇 404 错误，认为这象征着 Deno 公司的“死亡”——不仅技术生态凋零，连官网都无法正常访问。这一现象与近期公司大规模裁员相呼应，暗示 Deno 已陷入严重危机。

作者回顾了 Deno 的发展轨迹：五年前获得 490 万美元种子资金，一年后又融资 2100 万美元，本应拥有五年发展周期，但实际增长远未达预期。尽管 CEO Ryan Dahl 在博客中声称用户量“翻倍”，但作者质疑这一数据缺乏具体支撑，且在开发者社区中缺乏真实反响。Deno 的主要收入来源 Deno Deploy 也因性能不稳定、反馈迟缓而被开发者冷落，即便知名开发者 Wes Bos 提出问题，才引发官方重视。

Deno 的包管理项目 JSR 也未能成功，与 NPMX 等替代品相比，缺乏吸引力。作者指出，根本原因在于开发者并不想彻底抛弃 Node 和 NPM，而是希望现有生态能“无缝升级”。Deno 在此问题上摇摆不定，先是推动 HTTP 导入，后又转向 package.json，导致文档混乱、方向不清。

作者承认自己此前对 Deno 有过过度理想化，但如今不得不面对现实：Deno 项目已失去开发者关注，生态“如鬼城”。尽管曾有热情的团队成员，但他们的离职令人惋惜。

文章最后聚焦于 Ryan Dahl 的去向——作为 CEO，他未发布任何官方声明，也未在主流社交平台发声，反而在 Bluesky 上发布离职消息，引发外界猜测。作者推测 Deno 可能正转向 AI 领域，但对此持怀疑态度。他呼吁 Ryan Dahl 给出明确方向，否则 Deno 将彻底被遗忘。

全文语气尖锐但真诚，既有对技术失败的剖析，也有对人心与团队的惋惜，是一篇关于技术理想主义破灭的沉痛反思。

HN 热度 246 points | 评论 175 comments | 作者：WhyNotHugo | 9 hours ago #

https://news.ycombinator.com/item?id=47467746

Deno CEO 的离职公告语气不当，缺乏对创业者艰难处境的理解，且对 Ryan Dahl 的批评过于苛刻，忽视了他对技术社区的贡献。
虽然 Denos 在发展过程中存在诸多问题，如部署产品不稳定、NPM 兼容性削弱了其初衷，但 Ryan Dahl 作为技术布道者仍值得尊重。
NPM 兼容性虽解决了早期使用 React 等库的困难，但也导致了生态碎片化，使开发者缺乏动力去构建全新的现代化模块。
Deno 的初衷是重启 JavaScript 服务端生态，但 VC 资助的商业模式使其难以坚持初心，最终与主流生态妥协。
与 Python 2/3 的分裂类似，Deno 的困境反映出技术革新与商业现实之间的矛盾，但长期来看，生态整合是必然趋势。
Bun 等新兴工具的成功表明，兼容 Node 生态并提升性能是当前主流选择，而 Deno 的差异化优势正在减弱。
一个真正健康的开源项目很难在 VC 资本驱动下长期保持技术纯粹性，两者目标本质上存在冲突。
有人认为 Deno 的免费功能更像是吸引用户进入其付费服务的“诱饵”，缺乏真正的开源诚意。
早期 Deno 的 ES 模块和浏览器兼容 API 设计具有前瞻性，但最终因市场压力放弃初心，令人惋惜。
技术革新需要时间，Deno 的探索值得肯定，但商业压力下难以维持长期愿景，员工的努力不应被忽视。
有人调侃自己拥有运行过早期服务器端 JavaScript 的 SGI Indigo2 电脑，暗示技术演进的漫长历程。

10. 注意力残差（AttnRes）：一种面向 Transformer 的动态深度信息融合机制 (Attention Residuals) #

https://github.com/MoonshotAI/Attention-Residuals

Attention Residuals（AttnRes）是针对 Transformer 模型中标准残差连接的一种改进方案，旨在解决深度模型中隐藏状态幅值无界增长和早期层信息被稀释的问题。传统残差连接采用固定权重对所有前序层输出进行均匀累加，随着网络加深，这种固定聚合方式导致信息稀释，且易引发 PreNorm 结构中的数值不稳定。

AttnRes 通过引入可学习的、依赖输入的注意力机制，实现对先前层输出的动态选择性聚合。具体而言，每一层通过一个可学习的伪查询向量，计算对之前所有层输出的注意力权重，从而实现内容感知的深度信息融合。该方法分为两种形式：Full AttnRes 直接对所有前序层进行注意力聚合，性能优越但内存开销为 O(Ld)；Block AttnRes 将层分组为多个块，块内使用标准残差连接，块间通过注意力聚合块级表示，将内存降至 O(Nd)，在保持接近 Full AttnRes 性能的同时具备良好的实用性。

该方法在多个基准测试中展现出显著优势。在 MMLU、GPQA-Diamond、BBH 等通用任务上，AttnRes 均优于基线模型，尤其在多步推理任务（如 GPQA-Diamond）上提升达 7.5 分。在数学与代码生成任务中，HumanEval 和 MBPP 等指标也分别提升 3.1 和 1.9 分。在中文任务如 CMMLU 和 C-Eval 上同样取得明显进步。

训练动态分析表明，AttnRes 有效缓解了 PreNorm 中梯度分布不均和输出幅值失控的问题，使隐藏状态幅值保持稳定，梯度在各层间分布更均匀。

该工作由 Kimi 团队于 2026 年发布，相关论文已上传至 arXiv（编号 2603.15031），代码与论文可在 GitHub 仓库中获取，支持 PyTorch 风格的伪代码实现，可作为标准 Transformer 的即插即用替代方案。

HN 热度 228 points | 评论 32 comments | 作者：GaggiX | 1 day ago #

https://news.ycombinator.com/item?id=47458595

高中生作为第一作者的项目令人惊叹，反映出中国年轻一代在科技领域的突出表现。
中国年轻人才的涌现是统计学上的必然结果，得益于庞大的人口基数和教育体系的高效筛选。
印度在科技人才方面发展受限，主要由于基础设施和粮食安全问题，以及领导层的不作为。
美国教育体系存在文化问题，强调非劳动性活动作为阶级象征，导致年轻人缺乏实际工作动力。
中国年轻一代在政府政策引导下专注于科技领域，而美国年轻人则倾向于金融或娱乐性职业。
中国当前的教育模式类似于 19 世纪末的美国，而美国则呈现出类似古代帝国的特征。
中国高中入学率数据可能存在夸大，但学生从初中到高中的过渡数据较为可信，说明数据造假可能并非普遍现象。
对中国统计数据的质疑应保持理性，不能因个别问题而全盘否定所有数据，尤其在经济和社会发展成果显著的背景下。
中国在统计上的激励机制确实存在夸大现象，但其他国家同样存在类似问题，不应对中国数据采取双重标准。
中国教育体系培养出大量工程师，其核心优势在于学生愿意亲自参与工作，而非依赖他人完成任务。
中国工厂高度自动化，体现其通过技术手段提升效率，而非依赖大量人力，这与西方依赖外包或替代人力的模式形成对比。

Hacker News 精彩评论及翻译 #

Our commitment to Windows quality #

https://news.ycombinator.com/item?id=47462128

Microsoft has spent over a decade swimming against their users interests at this point and during that time frame Linux has been improving its desktop and improving kernel performance. We are now at the point where Linux emulating Window’s entire API space for games with worse drivers is dangerously close on performance with none of the privacy invasion and anti user features. Its pretty late in the game for them to start trying to switch back to producing an Operating system users actually want. Users refusing to switch from Windows 10 should have been that wake up call.

I don’t think Microsoft can pull this off, I think as mindshare is shifting it will continue to do so and its going to take Microsoft a long time to row back and right now its only talking about doing some minor things. Now Nvidia is developing the drivers on Linux seriously there is every chance this transition snowballs and nothing Microsoft does will be enough.

PaulKeeble

微软在这方面已经逆用户利益而行了十年多，而在这期间 Linux 一直在改进桌面体验和内核性能。我们现在正处于这样一个阶段：Linux 模仿了 Windows 的整个游戏 API 空间，虽然驱动程序更差，但在性能上与 Windows 危险地接近，且没有任何隐私入侵和反用户特性。对微软来说，现在试图转回生产用户真正想要的操作系统已经太晚了。拒绝从 Windows 10 切换的用户本该是一个警钟。

我认为微软无法达成这一目标，随着用户心智份额的转移，这一趋势将持续下去，微软需要很长时间才能撤回步伐，而目前它只是在进行一些微小的调整。现在 Nvidia 正在认真开发 Linux 驱动，这种转变极有可能形成滚雪球效应，而微软做的任何努力都不足以改变这一局面。

404 Deno CEO not found #

https://news.ycombinator.com/item?id=47468333

I didn’t like the tone of this. Building a company is hard. Building an VC-backed open source product is really, really hard.

I know on HN we don’t always love CEOs, and that’s okay… the ethos of startups has changed over the past 10 years, and tech has shifted away from tinkerers and more toward Wall Street. But Ryan Dahl isn’t doing that; he’s a tinkerer and a builder.

I dunno, I just don’t like this vibe of “what have you done for me recently” in this post, especially given he skipped over the company and is calling out Ryan directly for some reason. Ryan is responsible for many of our careers; Node is the first language I really felt at home with.

Comparing him to Nero is gross.

gkoberger

我不喜欢这篇文章的语气。创业是很艰难的。做风投支持的开源产品真的非常非常难。

我知道在 HN 上，大家不一定都喜欢 CEO，但这也没关系……过去十年，创业者的精神内核发生了变化，科技界也从以前的“动手党”时代更多地转向了华尔街。但 Ryan Dahl 不是那样的人；他是一个爱折腾的匠人和构建者。

说实话，我就是不喜欢这篇文章里那种“最近带来了什么价值”的语境，特别是考虑到文章跳过了公司本身，莫名其妙地直接点名批评 Ryan。Ryan 成就了无数人的职业生涯；Node 是我真正感到亲切的第一门语言。

把他和尼禄相提并论简直粗俗不堪。

OpenCode – Open source AI coding agent #

https://news.ycombinator.com/item?id=47462013

OpenCode was the first open source agent I used, and my main workhorse after experimenting briefly with Claude Code and realizing the potential of agentic coding. Due to that, and because it’s a popular an open source alternative, I want to be able to recommend it and be enthusiastic about it. The problem for me is that the development practices of the people that are working on it are suboptimal at best; they’re constantly releasing at an extremely high cadence, where they don’t even spend the time to test or fix things (or even build a proper list of changes for each release), and they add, remove, refine, change, fix, and break features constantly at that accelerated pace.

More than that, it’s an extremely large and complex TypeScript code base — probably larger and more complex than it needs to be — and (partly as a result) it’s fairly resource inefficient (often uses 1GB of RAM or more. For a TUI).

On top of that , at least I personally find the TUI to be overbearing and a little bit buggy, and the agent to be so full of features that I don’t really need — also mildly buggy — that it sort of becomes hard to use and remember how everything is supposed to work and interact.

logicprog

OpenCode 是我最早使用的开源智能体，在短暂尝试过 Claude Code 并意识到智能代理编程的潜力后，它便成了我的主力工具。正因如此，而且因为它是一个流行的开源替代品，我希望能向别人推荐它，并对它保持热情。但对我来说，问题在于它的开发人员的开发实践最多也只是勉强凑合；他们持续以极高的频率发布更新，以至于甚至没时间去测试或修复问题（甚至没有为每个版本构建清晰的变更列表），而且就在那个加速的节奏下，他们不断添加、移除、优化、更改、修复，同时又引入各种 bug。

不仅如此，它的代码库极其庞大且复杂——可能规模和复杂度都超出了实际需求——而且（部分原因也在于此），它的资源利用率相当低（经常使用 1GB 或更多的内存。对于 TUI 来说）。

此外，至少我个人觉得这个 TUI 界面过于繁杂且有些小 bug，而且“智能体”功能多得完全用不上——也轻度 buggy——以至于使用起来很困难，而且我记不住所有东西原本应该怎么运作和交互。

Our commitment to Windows quality #

https://news.ycombinator.com/item?id=47460955

If you want to know how serious to take this, just look at this gem:

Enhancing Search: […] Clearer and more trustworthy results, with results from content on your device easy to understand and clearly distinct from web results

So yeah, you still get web results in your search bar, a feature absolutely zero people want and which is just there to fake Bing success, just with a little divider now next to the applications the search failed to find.

deng

如果你想知道这事有多严重，就看看这个“宝贝”：

增强搜索： […] 更清晰、更可信的结果，其中的设备内容结果易于理解，且与网页结果明显区分

所以说，你的搜索栏里依然会出现网页结果，这完全是一个零人想要的功能，存在的目的纯粹是为了伪造 Bing 的成功，只不过现在在那些搜索失败的应用旁边多了一个小小的分隔符。

We rewrote our Rust WASM parser in TypeScript and … #

https://news.ycombinator.com/item?id=47462536

Something not unlike this happened to me when moving some batch processing code from C++ to Python 1.4 (this was 1997). The batch started finishing about 10x faster. We refused to believe it at first and started looking to make sure the work was actually being done. It was.

The port had been done in a weekend just to see if we could use Python in production. The C++ code had taken a few months to write. The port was pretty direct, function for function. It was even line for line where language and library differences didn’t offer an easier way.

A couple of us worked together for a day to find the reason for the speedup. Just looking at the code didn’t give us any clues, so we started profiling both versions. We found out that the port had accidentally fixed a previously unknown bug in some code that built and compared cache keys. After identifying the small misbehaving function, we had to study the C++ code pretty hard to even understand what the problem was. I don’t remember the exact nature of the bug, but I do remember thinking that particular type of bug would be hard to express in Python, and that’s exactly why it was accidentally fixed.

We immediately started moving the rest of our back end to Python. Most things were slower, but not by much because most of our back end was i/o bound. We soon found out that we could make algorithmic improvements so much more quickly, so a lot of the slowest things got a lot faster than they had ever been. And, most importantly, we (the software developers) got quite a bit faster.

rented_mule

我在1997年将一些批处理代码从C++移植到Python 1.4时，经历了一件几乎一模一样的事情。批处理任务的运行速度竟然快了大约10倍。起初我们不敢相信，于是开始检查以确保工作确实被执行了。确实如此。

移植工作只在一个周末内就完成了，只是为了看看能否在产品环境中使用Python。原来的C++代码花了数月才编写完成。移植工作非常直接，基本上是一对一地进行（函数对函数）。在语言和库机制没有提供更简便方法的某些地方，甚至是逐行进行移植的。

我们几个人一起花了一整天的时间来寻找加速的原因。仅凭肉眼查看代码并没有发现任何线索，所以我们开始对两个版本进行性能分析。结果我们发现，这次移植意外地修复了某些用于构建和比较缓存键的代码中一个先前未知的bug。在识别出那个行为异常的小函数后，我们必须认真钻研C++代码才能弄清楚问题究竟出在哪里。我记不清这个bug的具体性质了，但我记得我当时在想，那种特定类型的bug是很难在Python中表达的，而这恰好就是它被意外修复的原因。

我们立即开始将后端系统的其余部分都迁移到Python。大多数功能变慢了，但幅度不大，因为我们的后端大部分是I/O受限的。我们很快发现，我们在算法改进方面可以做得快得多，因此很多原本运行最慢的功能变得比以往任何时候都快。而且，最重要的是，我们（软件开发人员）的开发速度也变得快了不少。

Our commitment to Windows quality #

https://news.ycombinator.com/item?id=47460543

No one wants copilot. You can make it an app, but any OS level integration is a non-starter.

My next laptop will be a MacBook Pro.

My Surface Laptop 5 will be collecting dust in case I need it, but that’s highly unlikely.

ChicagoDave

没人想要 Copilot。你可以把它做成 App，但任何系统层面的整合都是没戏的。我下一台电脑会是 MacBook Pro。我的 Surface Laptop 5 只会在万一用得着时吃灰，不过这种可能性极小。

We rewrote our Rust WASM parser in TypeScript and … #

https://news.ycombinator.com/item?id=47461242

The real win here isn’t TS over Rust, it’s the O(N²) -> O(N) streaming fix via statement-level caching. That’s a 3.3x improvement on its own, independent of language choice. The WASM boundary elimination is 2-4x, but the algorithmic fix is what actually matters for user-perceived latency during streaming. Title undersells the more interesting engineering imo.

blundergoat

这里真正的胜利并不是 TS 超过 Rust，而是通过语句级缓存实现的 O(N²) -> O(N) 流式优化。这本身就是 3.3 倍的性能提升，与语言选择无关。WASM 边界消除能带来 2-4 倍的提升，但对于流式传输中的用户感知延迟而言，算法层面的修复才真正重要。就我个人观点来看，标题低估了这项更具趣味的工程优化。

France’s aircraft carrier located in real time by … #

https://news.ycombinator.com/item?id=47457473

I seriously doubt there is a country on earth which lacks the capability to detect an aircraft carrier’s presence in the Mediterranean sea.

We are not talking about stealth vehicles.

elif

我严重怀疑地球上是否有哪个国家缺乏在地中海发现航母的能力。我们不是在谈论隐形载具。

Our commitment to Windows quality #

https://news.ycombinator.com/item?id=47462399

Much of big tech became Product leaders running amok. Somehow It shifted from users know best to “Product” knows best.

I think this all stemmed everyone wanting to be Apple except no one actually achieved it and now we have 3 different versions of the audio control panel in Windows, the start button is somehow in the middle of the screen, and windows search no longer searches your PC.

Deleting “Product” might save windows, short of that, I am doubtful.

aeternum

许多科技巨头都沦为了任性的产品经理在胡作非为，不知怎的，这一切已经从“用户最懂行”转变成了“产品最懂行”。

我认为这一切都源于大家想成为苹果，但谁也没真正做到，结果现在 Windows 上出现了三个不同版本的音频控制面板，开始按钮莫名其妙地居中放置，Windows 搜索也不再搜索你的电脑了。

删除“产品”这个概念或许能拯救 Windows，除此之外，我表示怀疑。

I’m OK being left behind, thanks #

https://news.ycombinator.com/item?id=47455064

What I get a bit annoyed is companies forcing AI tools, getting usage metrics and actively hunting the engineers that don’t use the tool “enough”, I’ve never seen anything like it for a technically optional tool. Even in the past, aside from technical limitaions, you were not required to use enough of a tool.

It just sounds like a giant scheme to burn through tokens and give money to the AI corps, and tech directors are falling for it immediately.

augusto-moura

让我有点反感的是，公司强行推广 AI 工具，收集使用数据，甚至积极追查那些“使用得不够”的工程师；我从未见过针对一个技术上完全可选项的工具会有这种行为。即使在过去，除了技术限制外，你也不需要非得使用某工具到什么程度。这听起来简直就像是为了烧掉代币并把钱送给 AI 公司的巨大骗局，而技术总监们却立刻就上当了。

I’m OK being left behind, thanks #

https://news.ycombinator.com/item?id=47454557

Feels like a false equivalency. It’s just my experience, but I’ve completely ignored crypto and the metaverse, and I don’t get the sense I’m missing out on much. In contrast, LLMs in their current state have (for me) dramatically reduced the distance between an idea and a working implementation, which has been legitimately transformative in my software dev life. Transformative for the better? Time will tell I suppose, but I’m really enjoying it so far.

heytakeiteasy

感觉这是错误的等同关系。这只是我的个人经历，但我完全无视了加密货币和元宇宙，感觉我并没有错过太多东西。相比之下，目前的 LLM 极大地缩短了从想法到实际落地的距离，这在我的软件开发生涯中确实带来了真正的变革。是积极的变革吗？我想时间会给出答案，但目前为止我真的很享受。

BYD is seeing a flood of new EV buyers #

https://news.ycombinator.com/item?id=47459330

If one removed the country names and just looked at where investment (focus, planning, and money) was, we would see two greatly different pictures.

One country is disincentivizing or even blocking renewable energy production, rolling back climate protection measures, trying to revitalize the coal industry, slashing investment in scientific research of all kinds, demonizing higher education, and spending vast and rapidly increasing amounts of public funds to create direct, physical conflicts.

Another country is increasing their renewable energy generation capabilities dramatically each year, encouraging EV adoption, investing very heavily in scientific research, and also investing in military (although without initiating direct physical conflicts).

One of these two countries is riding on momentum, but the drag from waste and mismanagement of resources is increasingly slowing it. The other country is building momentum while reducing drag.

The difference in these approaches will be obvious in a decade, and in two decades one of the two countries will be just another chapter in a book about the rise and fall of empires.

michaelteter

如果去掉国家名称，仅关注资金投向（重心、规划和金钱），我们会看到两个截然不同的图景。

一个国家正在抑制甚至阻碍可再生能源的生产，撤销气候保护措施，试图振兴煤炭工业，大幅削减各类科学研究投资，污名化高等教育，并投入巨大且迅速增加的公共资金来制造直接的肢体冲突。

另一个国家每年都在大幅增加其可再生能源发电能力，鼓励电动汽车的普及，在科研方面投入巨资，同时也投资于军事（虽然不主动挑起直接的肢体冲突）。

这两个国家中，有一个正处于惯性中，但来自资源浪费和管理的低效产生的阻力正越来越大地拖慢它。另一个国家则在减小阻力的同时积攒动能。

这些方法的差异将在十年后变得显而易见，而在二十年里，这两个国家中的一个将成为帝国兴衰史册中的又一章节。

Wayland set the Linux Desktop back by 10 years? #

https://news.ycombinator.com/item?id=47448776

FWIW I recently switched full time to Linux and have had absolutely 0 problems with GNOME, Wayland and Fedora, though I am using an AMD GPU.

wl-copy works fine, askpass works, copy and paste works, screen sharing with Google Meet works, drag and drop works. Using an iphone as a webcam works as does recording my screen.

Most importantly using multiple monitors with fractional scaling works perfectly. AFIAK this is not possible to do well (at all?) on X11, which is a complete show stopper for me.

If anyone’s reading this and sitting on the fence, I would really give Fedora a go. I’ve found it so much more polished than Ubuntu, and loads of things which didn’t work on it work out of the box on Fedora (at least compared to 24.04 LTS).

martinald

题外话，我最近彻底转用 Linux 全职工作了，在使用 GNOME、Wayland 和 Fedora 方面完全没遇到任何问题，尽管我使用的是 AMD 显卡。

wl-copy、askpass、复制粘贴都运行正常，使用 Google Meet 进行屏幕共享、拖放也没问题。用 iPhone 当网络摄像头可以，录屏也没问题。

最重要的是多显示器分数缩放功能完美运行。据我所知，X11 上很难做到这一点（或者完全不可能），这对我是致命的阻碍。

如果有人在阅读这条评论还在犹豫，我真的建议你试一试 Fedora。我发现 Fedora 比 Ubuntu 精致太多了，很多在 Ubuntu 上不能用的功能在 Fedora 上都能开箱即用（至少对比 24.04 LTS 而言）。

Push events into a running session with channels #

https://news.ycombinator.com/item?id=47448810

Also, not a single one of those 300m Teams users wants to spend another minute there. Whereas people find Telegram useful and not odious.

jen729w

而且，那3亿Teams用户里，没一个愿意在那多待一分钟。而大家觉得Telegram既实用又不令人讨厌。

France’s aircraft carrier located in real time by … #

https://news.ycombinator.com/item?id=47461226

Grindr is for locating ships

inferniac

Grindr是用来找GIF的

OpenCode – Open source AI coding agent #

https://news.ycombinator.com/item?id=47463880

By default OpenCode sends all of your prompts to Grok’s free tier to come up with chat summaries for the UI.

To change that, you need to set a custom “small model” in the settings.

heavyset_go

默认情况下，OpenCode 会将您所有的提示词发送到 Grok 的免费版，以生成 UI 的聊天摘要。要更改此设置，您需要在设置中配置一个自定义的“小模型”。

Our commitment to Windows quality #

https://news.ycombinator.com/item?id=47461097

Windows is not technically inferior to Linux. To the extent it has problems, it is mainly because of top-down anti-user behaviour mandated from corporate. But anyone capable of using Linux is capable of hacking out that BS and getting a generally superior experience. I use both literally side-by-side, two laptops with a KVM switch, and I still greatly prefer Windows for many reasons.

Some reasons: Even as a low-level programmer fully capable of resolving problems, I want to spend my time working on my programs, not working on making my OS work, and Linux frequently demands that I spend hours chasing down issues. Windows does a better job of managing memory/swaps, at least out of the box. Windows has a stable userland with 30 years of backwards compatibility. Windows makes good use of both GUIs and CLIs, letting you choose whichever is faster for the task, while Linux distros and devs have some kind of bizarre ideological purity culture and generally refuse to make good GUIs. Windows has a built-in tool for easily making full system images while the system is running, without requiring the image destination be larger than the system drive including unused space. Windows developers are not so in love with dynamically linked system libraries that dependency management becomes a pain in the ass. Windows generally has a polished UX with a lot fewer papercuts.

applfanboysbgon

Windows 在技术上并不比 Linux 差。至于它存在的问题，主要是因为企业自上而下强制推行了反用户行为。但任何会用 Linux 的人都能搞定那些麻烦，从而获得整体上更优越的体验。我确实把两台笔记本电脑并排放着，通过 KVM 切换器使用，但出于许多原因，我仍然更喜欢 Windows。

原因如下：即使作为一个能解决问题的底层程序员，我也想把时间花在写程序上，而不是去折腾系统让它正常工作，而 Linux 经常让我花费数小时去排查问题。Windows 在内存/交换分区管理方面做得更好，至少开箱即用。Windows 拥有稳定的用户空间，具备 30 年的向后兼容性。Windows 很好地结合了 GUI 和 CLI，让你根据任务需要选择更快的那个，而 Linux 发行版和开发者似乎有着某种奇怪的理念洁癖，普遍拒绝制作优秀的图形界面。Windows 有内置工具，可以在系统运行时轻松制作完整系统镜像，且不需要镜像目标容量大于包含未使用空间的系统驱动器。Windows 开发者并不那么迷恋动态链接的系统库，因此依赖管理不会变得极其令人抓狂。Windows 通常具有精致的 UX，且更少的体验细节瑕疵。

Chuck Norris has died #

https://news.ycombinator.com/item?id=47454851

He finally defeated life

halcdev

他终于击败了生命

Cursor Composer 2 is just Kimi K2.5 with RL #

https://news.ycombinator.com/item?id=47452816

Cursor Composer 1 was Qwen and this is Kimi. IDE is based on VSCode. The entire company is build on packaging open source and reselling it.

Ollama is also doing this.

There is so much money to be made repackaging open source these days.

So funny to see Twitter go wild saying “a 50 person team just beat Anthropic” blah blah.

mohsen1

Cursor Composer 1 其实就是 Qwen，这个是 Kimi。IDE 是基于 VSCode 的。整个公司就是靠打包开源软件再转卖起家的。 Ollama 也是这么干的。现在靠把开源软件重新打包再转卖能赚很多钱。看到推特上跟疯了一样说“一个 50 人的团队刚干翻 Anthropic”之类的，真好笑。

France’s aircraft carrier located in real time by … #

https://news.ycombinator.com/item?id=47455098

This is a common problem across militaries. It is difficult to stop soldiers from leaking their location if they have access to mobile phones and the Internet. Individual cases are usually a combination of naïveté, ignorance, and an unwillingness to be inconvenienced.

It still happens in Ukraine, where immediate risk to life and limb is much more severe than this case.

jandrewrogers

在各国军队中，这是一个普遍存在的问题。只要士兵拥有手机和互联网，就很难阻止其泄露位置。这种个例通常往往是天真、无知以及怕麻烦的心理共同作用的结果。

这在乌克兰依然发生，那里的即时人身危险比这个案例要严重得多。

Our commitment to Windows quality #

https://news.ycombinator.com/item?id=47459700

They’re saying all the right things here.

Fixing long-standing complaints, removing Copilot from obnoxious places, improvements to Windows Update and Windows Explorer stability/microstutter/lag, etc.

I congratulate them on seeing sense, and I congratulate Apple on another victory with the Neo. Kind of frustrating that’s what it took for Microsoft to finally listen to their userbase.

Someone1234

他们这里说的都在点子上。修复了长期以来的积怨，从令人讨厌的地方移除了 Copilot，对 Windows 更新和资源管理器的稳定性、微卡顿、卡顿等方面进行了改进，等等。庆贺他们终于清醒（开窍），同时也祝贺 Apple 再次凭借 Neo 获得胜利。不得不靠这种方式才让 Microsoft 终于听取用户意见，多少让人有些沮丧。

Some things just take time #

https://news.ycombinator.com/item?id=47469310

With all the emphasis on the speed of modern AI tools, we often seem to forget that velocity is a vector quantity. Increased speed only gets us where we want to be sooner if we are also heading in the right direction. If we’re far enough off course, increasing speed becomes counterproductive and it ends up taking longer to get where we want to be.

I’ve been noticing that this simple reality explains almost all of both the good and the bad that I hear about LLM-based coding tools. Using AI for research or to spin up a quick demo or prototype is using it to help plot a course. A lot of the multi-stage agentic workflows also come down to creating guard rails before doing the main implementation so the AI can’t get too far off track. Most of the success stories I hear seem to be in these areas so far. Meanwhile, probably the most common criticism I see is that an AI that is simply given a prompt to implement some new feature or bug fix for an existing system often misunderstands or makes bad assumptions and ends up repeatedly running into dead ends. It moves fast but without knowing which direction to move in.

Chris_Newton

随着人们对现代 AI 工具速度的关注越来越高，我们似乎经常忘记速度其实是一个矢量。只有当我们朝着正确的方向前进时，增加速度才能让我们更早到达想去的地方。如果偏离航线太远，增加速度就会适得其反，结果反而要花费更长的时间才能到达想去的地方。

我注意到，这个简单的现实几乎解释了我听到的所有关于基于大语言模型的编码工具的好坏评价。利用 AI 进行研究或快速搭建演示和原型，就是在利用它来帮助规划路线。许多多阶段智能体工作流也归结为在主要实现之前创建护栏，以免 AI 偏离太远。目前我听到的绝大多数成功案例都在这些领域。与此同时，我看到的可能最常见的批评是，一个 AI 如果只是接到提示词去实现现有系统的某个新功能或修复 Bug，往往会出现误解或做出错误的假设，最终反复碰壁。它移动得很快，但不知道该往哪个方向移动。