作者回顾了自己年轻时对“伟大”文学的轻视，承认当时未能意识到艺术的价值在于其“厚度”——那种需要持续关注、并随着深入接触而逐渐展开的深度。作者借用充满宝藏的黑暗洞穴作比，指出艺术并非一目了然；它需要观者像“洞穴探险”一样去发掘复杂性，才能找到隐藏的意义。 作者以希罗尼穆斯·博斯的《人间乐园》为例，区分了肤浅的“艺术形式的产物”与真正厚重的作品。“厚度”由四个特质定义：创作过程中被舍弃的劳动、留给受众解读的空间、重读时才会显现的内在逻辑，以及人类投入的真实心血。 相比之下，作者批评了现代“垃圾内容”的兴起——即那些经不起推敲的AI生成内容和浅薄的非虚构作品。由于厚度是人类经验、时间和意图的产物，它无法被自动化。归根结底，伟大的艺术之所以能够流传，是因为其深度提供了持续且无穷尽的馈赠，这证明了创造与理解的过程本身，正是人类体验中最核心的部分。
每日HackerNews RSS
本文探讨了“厚度”这一概念——即区分经典艺术与“平庸之作”的内在深度与实质。作者回顾了自己的青年时代，那时他因缺乏相应的背景知识，将文学和艺术视为肤浅且充满表演性质的苦差事。
本文在 Hacker News 上引发了热烈讨论，主要议题包括：
* **洞穴隐喻**：伟大的艺术作品被比作“黑暗而蜿蜒的洞穴”。虽然老师常强迫学生在没有装备的情况下进入这些洞穴，但真正的欣赏需要“手摇手电筒”（即背景知识、生活阅历与耐心），才能发现其中的宝藏。
* **轻松的幻觉**：许多读者认为，“厚度”并非艺术品本身固有的属性，而是取决于读者的成熟度。真正的欣赏往往需要足够的生活阅历，才能与作品传达的主题产生共鸣。
* **人工智能的对比**：评论者指出，尽管人工智能可以生成“思想形态的物体”，但它缺乏创造深度的“人类本质”和刻意为之的努力。
* **教育的失败**：许多读者对自己的受教育经历感到失望，认为教育不应强制进行分析，而应侧重于激发好奇心，并提供使艺术变得有意义的历史背景。
**Vomit** 是一款注重隐私的本地工具，它通过本地大模型将 Claude 的标记化输出转换为可读的英语。该工具无遥测功能，也无外部依赖，专为偏好本地处理的用户打造，具有一种“随性编码（vibe-coded）”的实用风格。 由于该工具无法访问 Claude 的后端文件或操作，仅依赖 Claude 的输出内容，因此偶尔可能会出现幻觉或漏掉消息。此外，其运行速度可能较慢，且目前主要针对 macOS 进行了优化。 **主要功能：** * **本地处理：** 完全在您的机器上运行，无外部数据传输。 * **非侵入模式：** 允许用户“跟踪（tail）”会话，或在不改变原始流程的情况下与 Claude 同时运行。 * **简易设置：** 通过 `go install` 安装，使用 `vomit init` 进行配置，并通过 `vomit scrub` 或 `vomit tail` 等简单的命令行指令管理会话。 开发者建议使用如 Llama.app 运行的 GPT-OSS 20B 等本地模型以获得最佳效果。Vomit 是开源的，采用 GNU GPLv3 许可证，旨在服务于习惯实验性、本地优先工作流程的用户。
Hacker News 社区目前对较新的 Claude 模型（特别是 Opus 3.5）的沟通风格普遍感到沮丧，用户将其描述为“难以忍受”且容易出现“口水话（token vomit）”。
批评者认为，这些模型变得越来越啰嗦，插入了大量晦涩难懂的伪知识性术语和奇怪的隐喻，不仅没有阐明信息，反而造成了干扰。许多用户指出，这种“Claude 式”语体——通常以含糊其辞和重复性的元评论为特征——正在对生产力和心理健康产生负面影响，因为工程师们被迫整天“照看”人工智能的输出。
目前的共识是，这种行为源于为代理任务性能和代理间通信而优化的强化学习（RL）过程，该过程无意中奖励了这些特定的语言习惯。虽然有些人认为用户应该简单地适应或使用“简洁”的提示词，但许多开发者已诉诸于“去臃肿（deslopping）”——使用次要的、更精简的模型（或自定义脚本）将 Claude 的输出重写为平实易读的英语。
这场讨论凸显了现代大语言模型的原始技术能力与日益恶化的人机交互质量之间日益增长的矛盾，许多用户感到 Anthropic 将不透明的“代理”优化置于基础的、清晰的沟通之上。
现代 HTML 已经演进到可以处理以往需要 JavaScript 才能实现的动态功能，从而减少了对自定义脚本的需求。现在浏览器原生内置的关键功能包括：
* **UI 组件：** `popover` 属性、`<dialog>` 元素以及 `command`/`commandfor` 属性，无需 JS 即可实现轻量级模态框和交互式菜单。
* **折叠面板逻辑：** 在 `<details>` 元素上使用 `name` 属性，可以实现互斥的折叠面板，即打开一项时会自动关闭其他项。
* **浏览器原生工具：** 内置功能如输入选择器（颜色、范围、日期）、用于自动补全的 `<datalist>`，以及图片的 `loading="lazy"` 属性，简化了常见的开发任务。
* **内容管理：** `hidden="until-found"` 属性允许浏览器在用户通过搜索导航到隐藏内容时，自动将其显示出来。
虽然这些工具为传统库提供了强大且轻量的替代方案，但作者提醒，不同浏览器的实现存在差异。开发者在处理样式不一致和潜在的无障碍功能缺陷时应保持谨慎。在实现这些现代 HTML 特性时，务必优先考虑包容性设计和无障碍测试，因为其中一些特性尚未“完善”或缺乏普遍支持。
关于“HTML 能做到这一点”的 Hacker News 讨论凸显了一股日益增长的趋势：利用 `<dialog>`、`popover` 和分组 `<details>` 等原生浏览器功能来替代复杂的 JavaScript 框架。
**主要观点：**
* **支持原生的理由：** 许多开发者发现，现代 HTML/CSS 标准简化了代码，提升了性能，并能自动处理可访问性和键盘交互，从而减少了对庞大依赖库的需求。
* **持续存在的挑战：** 尽管有所改进，但开发者指出，原生元素（如 `datalist` 或日期选择器）往往缺乏复杂企业级应用所需的健壮性、样式灵活性或模糊搜索功能，这常常迫使开发者回归使用自定义 JS。
* **人工智能/工具缺口：** 一个主要的争论点在于，大语言模型和 AI 编码助手通常基于过时的“重 JS”模式进行训练，难以主动建议现代化的原生解决方案，需要特定的“技能”库或指导才能有效发挥其作用。
* **理念分歧：** 这场辩论反映了更深层的分歧：一些人主张回归简单、基于文档的网页架构；而另一些人则认为，Web 已经演变成一个应用程序平台，原生的基础组件尚不足以满足高性能、富文本或复杂交互的需求。
Slack Code
2 天前
Alan Coopersmith 发布了 **xorg-server 26.0.99.901 (RC1)**，这是即将发布的 26.1.0 版本的首个候选版本。该版本包含核心 Xorg、Xephyr、Xnest、Xvfb、Xwin 和 Xquartz 服务器。 **自 21.1 版本以来的主要变化包括：** * **构建系统：** 全面迁移至 Meson；已移除对 autoconf/automake 的支持。 * **协议与配置：** 增加了对 DPMSInfoNotify (DPMS 1.2) 和 XFixes 6.1 的支持。在 `xorg.conf` 中新增了 `AllowForceTerminate` 选项。 * **安全与默认设置：** 字节交换客户端和字体服务器连接现默认为禁用。非 root 用户的日志文件已移至 `$XDG_STATE_HOME/xorg`。 * **平台/驱动改进：** Xorg 现已包含适用于 BSD 的 DRM 平台；Xvfb 支持多个 CRTC 和最多 13 个鼠标按键。 * **常规：** 大规模的代码清理、安全加固以及大量的错误修复。 鼓励开发者测试此候选版本，并通过 [Freedesktop GitLab](https://gitlab.freedesktop.org/xorg/xserver/-/issues) 报告问题。对于 Xorg 测试，建议用户基于 `libpciaccess 0.19` 或更高版本进行构建，以利用最新的 API 修复。
Xorg-server 26.1.0 rc1 的发布在 Hacker News 上引发了关于 Linux 显示服务器未来的热烈讨论。尽管许多开发者认为 Xorg 是一个应被 Wayland 取代的老旧过时项目，但用户群体的看法依然存在分歧。
Xorg 的支持者强调其可靠性、丰富的功能，以及对特定工作流（例如复杂的窗口管理脚本和 Easystroke 等工具）的持续必要性，因为这些工具在 Wayland 上尚缺乏稳定的替代品。相反，Wayland 的拥护者则强调其卓越的安全模型、更低的延迟以及现代化的架构，尽管他们也承认过渡过程中仍面临挑战。
讨论的很大一部分集中在“XLibre”分支上，该分支的出现源于对 Xorg 停滞不前现状的不满。有趣的是，此次新发布的 Xorg 包含了此前在 XLibre 中开发的功能贡献，这展现了竞争与跨项目合作带来的益处。尽管业界在向 Wayland 靠拢，但 Xorg 的长盛不衰证明了它已深度融入类 Unix 生态系统。随着主流桌面环境逐渐放弃对 X11 的支持，社区仍分裂为两派：一方渴望现代且安全的替代方案，另一方则抵制转型，认为这种转型以牺牲功能性为代价去追求意识形态的纯粹。
Rivian OS 2
2 天前
图像验证
请忽略灰色字母——只有彩色字母才是代码的一部分。
不匹配——请重试。
获取新图像
您可以完全跳过此图像。
本网站可以自动验证您的浏览器。这需要启用 JavaScript。
如果您为本网站启用了 JavaScript 并点击“返回”，您应该会被自动验证。
← 返回（获取原始链接）
仍然有问题？请发送电子邮件至并附上您的浏览器信息和此参考 ID：no_id_generated
软件初创公司 Hatchet 将丰田制造流程中的一个核心理念——“安灯绳”（Andon cord）——采纳为公司的一项关键文化准则。在工厂环境中，安灯绳允许任何工人在发现瓶颈或缺陷时立即停止生产。
Hatchet 将这一理念应用于软件工程，即优先保证交付流水线的稳定性和可靠性，而非新功能的开发。当团队遇到关键的基础设施问题（如部署失败、可观测性差或负载测试无效）时，他们会暂停所有工作以修复根本原因。
尽管在高压的初创环境中，为了解决问题而停止生产似乎有违直觉，但该团队发现这至关重要。通过将“计划外工作”视为修复系统性问题的信号，而非陷入“初创公司救火式”的常态，他们显著减少了技术债务，并提高了长期的交付速度。最终，安灯绳强化了一种文化：交付可靠的软件是重中之重，从而防止了缺陷的常态化和员工的职业倦怠。
抱歉。
Bun 1.4 Bun 1.4
2 天前
Bun v1.4 是 JavaScript 和 TypeScript 工具包的一次重大更新，现已使用 Rust 重写。它带来了显著的性能提升，包括空闲 CPU 占用降低 5 倍、内存消耗减少高达 35%，以及 Linux 上启动速度提升 50%。
### 核心亮点：
* **Node.js 兼容性：** 新增了来自 Node.js 测试套件的 1,517 多项测试，`node:http`、`node:fs` 和 `node:events` 等主要模块的兼容性已达到 97%–100%。
* **内置工具箱：** 许多此前需要外部依赖的功能现已原生支持：`Bun.Image`（图像缩放/转码）、`Bun.WebView`（无头浏览器）、`Bun.markdown`（解析/渲染）、`Bun.cron()`（操作系统级任务）以及 `Bun.Terminal`（伪终端 PTY）。
* **性能：** 更快的 `fetch()`，原生实现的 `CompressionStream`/`TextEncoderStream`，以及改进了 `Bun.serve()` 中的背压（backpressure）处理。
* **打包与工具链：** 引入了用于自动记忆化（auto-memoization）的原生 **React Compiler**，代码分割速度提升 14 倍，并新增了 `bun --cpu-prof-md` 和 `bun --heap-prof-md` 等观测功能，支持在终端进行性能分析。
* **包管理：** `bun install` 速度更快，支持 monorepo 的“隔离”链接器，并新增了 `bun audit fix`、`bun dedupe` 和 `bun prune`。
* **测试运行器：** `bun test --parallel` 和 `--shard` 为大型测试套件带来了显著的速度提升，并全面支持 Jest 和 Vitest 兼容性。
Bun 1.4 的发布在 Hacker News 上引发了激烈讨论，焦点在于其利用 AI 智能体实现了整个代码库从 Zig 到 Rust 的迁移。
支持者认为这是一个具有历史意义的里程碑，证明了大语言模型（LLM）能够成功执行此前被认为不可能完成的大规模、复杂重构。他们主张，该项目的性能提升和新功能验证了“全功能”运行时模式的价值，有效地回击了那些曾预测该项目会因技术债务而失败或崩溃的怀疑论者。
反之，批评者则持深度怀疑态度。他们关注的重点在于 AI 生成代码的“黑箱”本质、长期可维护性问题，以及 Bun 的“一体化”架构可能通过削弱专业第三方库而导致生态碎片化的风险。部分用户对该项目激进的营销手法及其被认为“靠感觉驱动”的开发周期表示不满。
归根结底，这场讨论突显了软件行业日益扩大的分歧：一方将 AI 智能体视为提高工程效率的必备工具，而另一方则将其视为对工艺水准、架构完整性以及开源协作精神的威胁。此次发布已成为编程未来发展路径的一场象征性博弈。
此条目摘自椭圆曲线秩排行榜，展示了一条秩至少为 30 的破纪录椭圆曲线。该曲线由 "ranksunbounded" 于 2026 年 8 月 20 日提交，方程为：$y^2 + xy = x^3 - 201769035260418549083594900060734240952308696994802735114305555x + 1151107939141058565733479426024323225135665982951300586808823640527729578307228357301072889377$。 除了创下秩 $\ge 30$ 的新纪录外，该曲线还在朴素高度（442.0854）、法尔廷斯高度（34.7705）及判别式数值方面设立了基准。数据包含 30 个作为该秩证明的独立点列表，以及曲线的导体和已知的坏约化素数。本研究由美国国家科学基金会（NSF）计算机辅助数学推理研究所（ICARM）维护。
最近，一位神秘用户发布了一条秩至少为 30 的椭圆曲线，打破了 Elkies 和 Klagsbrun 于 2024 年初创下的 29 的纪录。此后，这一突破被证实是由 Levent Alpöge、Ava Howell 以及人工智能模型 Claude 共同完成的。
在数学中，椭圆曲线的“秩”用于衡量曲线的复杂程度及曲线上独立有理点的数量。寻找高秩曲线难度极大且意义深远；由于此前人们曾怀疑秩可能存在上限，这一发现挑战了既有的启发式观点，即认为高秩曲线极其罕见。
这一成就因人工智能的参与及 Alpöge 的专业贡献而引发了热议。Alpöge 是一位以善于利用 AI 工具解决复杂数学问题而闻名的数学家。虽然这一发现是一个重要的里程碑，但它也引发了关于数学研究未来、人工智能在生成复杂证明中的作用，以及椭圆曲线的秩是否能无限增加等基本问题的持续争论。