2025 12 28 HackerNews

2025-12-28 Hacker News Top Stories #

  1. uv 之所以比 pip 快一个数量级,主要靠现代打包标准允许静态解析依赖、放弃历史兼容、并行下载与全局缓存、以及更简化的策略与 PubGrub 解析,Rust 只是辅因。
  2. Floor796 是由一位创作者独立开发的交互像素动画网站,充满俄苏文化符号与大量彩蛋,兼具2000年代互联网怀旧感与社会隐喻。
  3. FFmpeg 指控 Rockchip 在其 MPP 驱动中大规模复制并擅自改许可为 Apache 2.0,违反 LGPL,因此向 GitHub 发起 DMCA 下架并呼吁合规。
  4. 一名 1 型糖尿病患者发现其胰岛素泵控制器运行过时 Linux 且厂商未按 GPL 提供源码,既违反许可也带来安全隐患。
  5. 报道介绍云南“见手青”蘑菇会引发“小人幻觉”,且因无法人工栽培和市场上有毒替代品而导致中毒事件频发,需加强监管与检测。
  6. 文章提出用重复性、游戏时长与清理便捷性评估玩具,认为多用途且易收纳(如木质积木或磁力模块)是最佳选择。
  7. exe.dev 提供一行 SSH 快速登录的极简远程开发环境,便于快速调试与临时运行但因首页信息稀少与潜在安全问题引发争议。
  8. 苹果开源的 SHARP 模型能在不到一秒的前向传递中将单张 2D 照片回归为可实时渲染的 3D Gaussian Splatting 表示,且以 MIT 许可发布。
  9. Ez FFmpeg 允许用自然语言生成 ffmpeg 命令,方便偶尔用户构建常见操作,但需警惕可能导致不必要重编码等细节问题。
  10. 作者主张在多数场景下优先使用文本,因为文本最可靠、持久、经济且便于检索与协作,长期价值最高。

uv 为何如此之快 (How uv got so fast) #

https://nesbitt.io/2025/12/26/how-uv-got-so-fast.html

uv 能够比 pip 快一个数量级,主要原因并非仅仅因为它是用 Rust 编写的,而在于一系列关键的设计决策和生态系统标准的演进。

首先,现代 Python 包管理标准的建立为 uv 的高效提供了基础。过去,由于 setup.py 需要执行代码才能获取依赖信息,pip 必须反复下载、执行、失败、再安装构建依赖,形成复杂的循环。PEP 518 引入 pyproject.toml,使构建依赖可声明;PEP 517 分离构建前后端;PEP 621 标准化 project 表,使依赖可直接解析 TOML;PEP 658 将包元数据直接暴露在 PyPI 的 Simple API 中,使解析依赖无需下载 wheel。这些标准让 uv 能在不执行任何代码的前提下完成依赖分析,这是其速度飞跃的前提。

其次,uv 主动放弃了许多 pip 支持的旧特性,从而大幅减少运行路径。它不支持 .egg 格式、pip.conf 配置文件、默认的字节码编译、系统 Python 安装,也不容忍格式错误的包。它还忽略 requires-python 的上限版本(如 python<4.0),因为这类限制多为防御性声明而非实际限制,此举显著减少解析回溯。在多个源中,uv 默认只使用第一个有包的源,避免网络请求和依赖混淆攻击。

此外,许多性能优化并不依赖 Rust。uv 支持并行下载、使用全局缓存配合硬链接(节省磁盘空间)、通过 HTTP 范围请求快速获取 wheel 中心目录信息、优先使用 PEP 658 元数据。它还采用 PubGrub 解析算法,利用冲突驱动的回溯学习机制,比 pip 的传统回溯更高效,且能更好解释错误。

Rust 的优势体现在更底层的优化:零拷贝反序列化(rkyv)、线程级并行(绕过 GIL)、无解释器启动开销、紧凑的版本表示(90% 以上版本可压缩为 u64)。这些提升了性能,但远不如架构层面的取舍重要。

总结:uv 的快,源于“不做什么”——放弃历史包袱、依赖现代标准、拒绝执行任意代码。pip 因需兼容十五年来的复杂边缘情况,难以实现这些优化。真正的关键在于设计:静态元数据、无需代码执行、提前解析依赖。这正是 Cargo 和 npm 长期领先的原因。


HN 热度 1206 points | 评论 418 comments | 作者:zdw | 1 day ago #

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

  • uv 的速度提升主要源于将 Python 包管理视为一个明确的系统问题,而非历史遗留的混乱状态,而非单纯因为使用了 Rust。
  • 一个商业驱动的项目能更高效地推进,因为它可以支付报酬让开发者专注于实现目标,而不受开源社区中常见的政治、许可和意见分歧的拖累。
  • 开源项目常因需要达成共识而陷入停滞,而像 systemd 和 uv 这样的项目之所以成功,是因为由单一决策者主导,避免了集体决策的低效。
  • 尽管“良善独裁者”模式在许多开源项目中仍然普遍存在,但近年来越来越多项目倾向于转向委员会治理,这反而可能导致项目进展缓慢甚至失败。
  • 项目规模越大,越容易陷入治理纠纷,但“良善独裁者”模式的可持续性依赖于领导者持续的投入与善意,一旦失去,项目可能迅速衰落。
  • 过度强调“治理”“指导委员会”等机制,实际上会阻碍项目发展,许多项目应坚持“这是我的项目”的立场,拒绝不必要的权力分散。
  • 项目治理问题并非开源与闭源的本质差异,而是设计由集体还是个人主导的权衡,集体决策容易导致效率低下和内部冲突。

Floor796(Floor796) #

https://floor796.com/

网页展示的动画艺术作品,大量文化符号,该动画的创作始于 2018 年,作者独自完成了编辑器、渲染引擎和网站的开发,初期绘制一个区块耗时超过 8 个月,现在约需 1-1.5 个月。


HN 热度 574 points | 评论 75 comments | 作者:krtkush | 13 hours ago #

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

  • 作品中的角色多为俄罗斯及苏联时期的文化符号,可能反映作者具有俄语文化背景,但未必是“流亡者”。
  • 艺术风格独特,令人联想到 Moebius、90 年代游戏《Flashback》以及《Alien Syndrome》等经典作品。
  • 与 eBoy 的风格相似,但并非同一团队所创,而是由一位技术与艺术兼备的独立创作者完成。
  • 作品中隐藏大量彩蛋,包括寻找“Wally”、触发“黑手党宝藏”任务、与电话亭互动、在医院用合成器创作旋律等。
  • 有互动元素如“改变我的想法”人物、像素动画创作屏、真实运行的 Racer796 游戏等,增强了沉浸感。
  • 画面中存在对教育体制的隐喻,如“砖石人”场景,影射社会对个体的规训与异化。
  • “人类”常被说成“人类 beings”,强调人的精神与灵魂,而非单纯生物性存在,这种表达具有修辞上的强调作用。
  • 作品整体风格唤起了 2000 年代互联网文化的怀旧感,充满互动与细节,令人沉浸其中。

FFmpeg 对 GitHub 发起 DMCA 下架通知 (FFmpeg has issued a DMCA takedown on GitHub) #

https://twitter.com/FFmpeg/status/2004599109559496984

FFmpeg 官方账号于 2024 年 2 月 23 日发布推文,指出 Rockchip 公司(@IloveRockchip)在其 MPP 驱动代码中大量复制了 FFmpeg 的源码,涉及数千行代码,并擅自更改了许可证,违反了 LGPL 开源协议。

该行为始于 2022 年底,FFmpeg 开发者团队在等待近两年后,终于采取行动公开曝光。推文中附上 GitHub 链接,指向 Rockchip 项目中被复制的 AV1 解码器文件 av1d_cbs.c,明确指出其代码与 FFmpeg 原始代码高度相似,且未遵循 LGPL 的要求进行开源披露。

FFmpeg 强调,这种直接复制并修改许可证的行为不仅不合规,也损害了开源社区的信任与协作精神。

该推文发布后引发广泛关注,获得超过 420 万次浏览,5.6 万次转发和 5.1 万次点赞,成为开源社区热议话题。


HN 热度 524 points | 评论 181 comments | 作者:merlindru | 1 day ago #

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

  • 复制粘贴 FFmpeg 代码并移除许可证头和署名,属于未经授权的重新许可行为,违反了 LGPL 协议。
  • LGPL 允许复制代码,但前提是必须遵守原许可证条款,且不能将 LGPL 代码与不兼容许可证(如 Apache 2.0)的代码混合使用。
  • Rockchip 无权将 FFmpeg 代码重新许可为 Apache 2.0,因为其不拥有 FFmpeg 的版权,只能按 LGPL 协议发布。
  • 正确做法是将修改后的 FFmpeg 代码放入独立的 LGPL 许可的分支项目中,并通过动态链接方式使用,以确保合规。
  • 分发包含 Apache 2.0 代码和 LGPL FFmpeg 代码的可构建源码包,只要不修改 FFmpeg 本身的许可证,是符合 LGPL 要求的。
  • FFmpeg 团队在发现问题后已给予 Rockchip 长达一年半的整改时间,但对方未回应,因此采取 DMCA 通知是合理且合法的手段。
  • 在对方长期无视警告的情况下,FFmpeg 团队采取法律手段是正当的,不应被指责为“过度反应”或“欺负小公司”。
  • 有观点认为,FFmpeg 团队应更早采取行动,但另一方指出,给予足够时间是负责任的做法,不能因对方拖延就免除其责任。
  • Rockchip 作为商业公司,有义务主动解决开源许可证合规问题,不能以“不知道”或“没注意到”为借口。
  • 该事件暴露了部分企业对开源许可证的轻视,也反映出开源社区在维权方面的困境与挑战。
  • 有人质疑 FFmpeg 团队为何未公开提醒,但也有观点认为,私下的沟通和警告已足够,公开并非强制义务。
  • 该事件可能损害 Rockchip 在开源社区中的声誉,也影响其与 FFmpeg 等项目的潜在合作机会。

我的胰岛素泵控制器使用了 Linux 内核,同时也违反了 GPL 协议 (My insulin pump controller uses the Linux kernel. It also violates the GPL) #

https://old.reddit.com/r/linux/comments/1puojsr/the_device_that_controls_my_insulin_pump_uses_the/

一位 1 型糖尿病患者发现,自己赖以生存的胰岛素泵控制器(Insulet OmniPod Dash PDM)运行的是 Android 系统,内核为已停止维护 8 年之久的 Linux 3.18.19。根据 GPLv2 协议,厂商必须应用户要求公开内核源码,但两年来他多次向设备制造商 Insulet(美国)及其硬件代工厂 Nuu(中国)索要源码,均被拒绝或敷衍。设备本身毫无安全验证,可被轻易刷机 root,存在巨大安全隐患。作者呼吁公众关注 Insulet 的 GPL 违规与医疗安全漠视。


HN 热度 478 points | 评论 240 comments | 作者:davisr | 1 day ago #

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

  • GPL 要求公司必须向用户发出书面源代码提供承诺,用户需基于此承诺索取源代码,否则无权直接要求获取,但公司未发出承诺即构成 GPL 违规。
  • 消费者是否有权依据 GPL 起诉公司尚未有明确法律定论,但 Conservancy 诉 Vizio 案可能改变这一现状。
  • 有人质疑该用户获取内核源代码的真实目的,认为其无法推动中国开发者贡献代码,且修改医疗设备可能危及生命安全。
  • 开源胰岛素泵项目在技术上已远超商业产品,参与者多为有强烈动机保障安全的开发者,其代码质量与审查机制优于商业公司。
  • 尽管自行改装医疗设备存在风险,但开源社区通过严格同行评审和透明协作,已实现长期安全运行,未出现因开源系统导致的死亡案例。
  • 商业医疗设备公司因利润驱动可能忽视安全细节,而开源开发者则因自身健康需求而更具责任感,因此开源方案更值得信赖。
  • 任何自行改装设备的行为都存在风险,但只要附带明确免责声明,就不应因潜在风险而完全否定开源行为的正当性。
  • 与商业飞机相比,自制飞机的安全性取决于开发者动机与技术能力,开源项目在动机一致性和透明度方面具有优势。
  • 企业雇佣的工程师同样可能引入缺陷,开源社区的协作审查机制反而能更有效地发现并修复问题。

专家探索新蘑菇:引发童话般幻觉 (Experts explore new mushroom which causes fairytale-like hallucinations) #

https://nhmu.utah.edu/articles/experts-explore-new-mushroom-which-causes-fairytale-hallucinations

、 本文介绍了一种名为“ Jian shou qing”(中文意为“见手青”)的野生食用蘑菇,其在云南昆明等地的市场中广泛出售。这种蘑菇因其独特的心理效应而闻名——食用后会引发“小人幻觉”,即患者看到成群结队、约 2 厘米高的卡通化小人,它们在现实环境中行走、跳舞或列队行进,甚至能“从桌布下爬出”或“头颅脱落仍继续移动”。

该现象最早在 1934 年被西方探险者记录于巴布亚新几内亚,当时当地人食用一种名为“nonda”的蘑菇后出现类似精神错乱的行为,被称为“蘑菇疯狂”。这一现象与“小人症”(Lilliputian hallucinations)相符,是一种罕见的精神病学症状,源自《格列佛游记》中的小人国设定。

尽管自 20 世纪 60 年代起科学家便试图研究其成分和物种身份,但长期未果。直到 2014 年,中国云南省的真菌学家通过对昆明街头市场售卖的“见手青”进行 DNA 测序,才首次确认其科学分类:正式命名为 Lanmaoa asiatica。它属于与常见牛肝菌(如犹他州州菌)亲缘关系较近的类群,而非传统意义上的“迷幻蘑菇”。

值得注意的是,由于该蘑菇无法人工栽培,市场上大量干制产品存在严重风险——许多标称“见手青”的包装中实际混入了有毒替代品,导致中毒事件频发。研究团队通过基因检测发现,部分商品中并无真正的 Lanmaoa asiatica,却含有剧毒种类。

此外,文献显示,这种蘑菇的文化认知可能已有千年历史。公元 3 世纪的道教典籍《抱朴子》中提及“肉灵芝”,称其生食可“见小人”并“即刻超脱”,暗示古人早已知晓其致幻特性。

目前,云南已成为全球最大的野生蘑菇出口地之一,但监管缺失使消费者面临巨大健康风险。该研究不仅揭示了一个新物种,也提醒公众警惕野生真菌的潜在危险。


HN 热度 465 points | 评论 301 comments | 作者:astronads | 1 day ago #

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

  • 毒蘑菇比例低可能是因为部分蘑菇通过吸引动物传播孢子,而毒性只是副产品,而非主要目的。
  • 毒蘑菇的毒性并非为了警告,而是为了防御昆虫等小型捕食者,对人类的影响是进化中的意外结果。
  • 一些毒素如鹅膏蕈氨酸通过水平基因转移获得,说明其对特定生存压力至关重要,可能用于抑制竞争者或病原体。
  • 毒蘑菇产生的精神活性物质如裸盖菇素,可能并非为影响人类而演化,而是对昆虫或微生物起作用的副产物。
  • 植物和真菌中的许多生物碱(如尼古丁、咖啡因、THC、茶碱)最初是作为天然杀虫剂演化而来,用于抵御昆虫。
  • 人类对这些物质的“滥用”是偶然的,因为它们恰好与哺乳动物神经系统有相似作用,而这是进化中无目的的副作用。
  • 某些植物的花蜜含微量咖啡因,能增强蜜蜂的记忆力,使它们更愿意访问这些花,这可能是植物利用昆虫的“奖励机制”。
  • 大麻中的 THC 在未加热时也具有生物活性,且部分天然大麻品种的 THC 含量已超过法律阈值,表明其对动物有直接影响。
  • 大麻中的 THCa 和 CBDa 在自然状态下不稳定,会随时间、光照和温度逐渐转化为活性物质,无需加热即可产生影响。
  • 人类对大麻等植物的利用可能与自然选择无关,而是文化发展和人类偏好驱动的。
  • 植物和真菌的化学物质常源于相似的生物合成路径,因此与动物神经递质结构相似,导致对人类产生影响。
  • 真菌的菌丝网络与动物大脑的神经网络在结构和功能上存在相似性,可能共享部分基因和信号通路。
  • 动物与真菌在进化上关系密切,共享许多基本生物分子和代谢途径,使得真菌代谢产物能影响动物神经系统。

玩时最长、收拾时间最短的玩具 (Toys with the highest play-time and lowest clean-up-time) #

https://joannabregan.substack.com/p/toys-with-the-highest-play-time-and

这篇文章探讨了家长在选择玩具时最看重的几个因素,特别是玩具的游戏时间和清理时间的比例。作者乔安娜・布雷根指出,最糟糕的玩具是那些拥有许多零件的玩具,它们往往会让孩子们在短短两分钟内就玩完,而清理却需要十分钟,造成 “游戏时间” 与 “清理时间” 的不成比例,从而耗费了父母的精力和时间。

文章提出了评估玩具质量的三个主要指标:

  1. ** 重复性 **:玩具能否被反复使用,分值从 1 到 5 不等,5 代表每天可以玩几年。
  2. ** 游戏时长 **:每次玩耍的时间长短,最高分 5 代表 30 分钟以上的游戏。
  3. ** 清理的简便性 **:清理起来的难易程度,最高分 5 代表非常容易清理。

通过对比不同玩具的得分,作者总结出高分玩具的几个特点:

  • 高分玩具可以变成多种不同的物体,激发孩子们的想象力和创造力。例如,巨型和小型磁性拼块可以变成房子、火箭或其他角色,而与之相比,Minecraft 玩具的零件功能单一,限制了孩子们的创造空间,导致他们容易感到厌倦。
  • 高分玩具的零件之间存在有趣的关系,选择时不需要过多思考,增加了游戏的乐趣。相反,某些玩具的设计较为复杂,选择时需考虑更多因素,使得游戏体验变得不那么有趣。
  • 清理容易的玩具往往具有强磁性,清理时会有点击连接的满足感,清理过程也变得像是一种游戏。

作者还提到了一款名为 Clixo 的玩具,认为其灵活的玩法、优雅的形状和磁性特点可能使其成为高评分玩具。总的来说,文章强调了玩具在提供娱乐价值的同时,也要考虑清理的便捷性,以提高家庭的生活质量。


HN 热度 452 points | 评论 265 comments | 作者:surprisetalk | 1 day ago #

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

  • 木质积木因其高度的可塑性和耐用性,能激发孩子无限的创造力,适合不同年龄段的人长期玩耍,且易于清洁和收纳。
  • 木质积木无电池、无电子元件,不易损坏,即使表面有磨损仍能正常使用,具有代际传承的价值。
  • 成年人同样可以从玩木质积木中获得放松和启发,有助于突破思维瓶颈或单纯享受无目的的玩耍。
  • 类似 Cuboro 的木质弹珠轨道系统虽价格昂贵,但设计精良,能激发复杂的结构搭建和逻辑思考,是高质量的玩具。
  • 塑料替代品如 Gravitrax 或磁力积木(Magnetile)在性价比和趣味性上表现良好,适合家庭使用,尤其适合亲子互动。
  • 自制或手工制作的大型积木(如 Jenga 式大块)在户外或社交场合中能促进多人协作和持续互动。
  • 木质积木可与其他玩具结合,如用于搭建斜坡、轨道、弹珠迷宫或模拟游戏场景,极大拓展玩法。
  • 木质积木的简单性使其成为跨年龄群体的共同玩具,能促进家庭成员或朋友间的互动与合作。
  • 一些人怀念童年时用木板和积木搭建复杂结构(如斜坡、弹珠台、翻板机)的时光,认为这种自由创造极具价值。
  • 木质积木的持久性和低维护成本使其成为比电子玩具更可持续的选择,且对环境友好。
  • 一些人建议支持本地小商家,通过正规渠道购买高品质的木质玩具,以支持可持续消费。

exe.dev:轻量快速的 SSH 开发工具 (Exe.dev) #

https://exe.dev/

该网页是名为 exe.dev 的开发者工具网站,主打一个轻量级、快速的 SSH 登录体验。用户可通过输入 ssh exe.dev _ 命令直接连接到远程服务器,无需复杂配置。页面强调“磁盘持久化”,意味着用户在使用过程中数据会保留,适合长期开发或测试任务。同时提供 sudo 权限,方便进行系统级操作。

网站设计简洁,仅包含核心功能入口和少量信息:关于页面、博客更新动态以及 Discord 社区链接。整体风格偏向极简主义,专注于提供高效的命令行访问体验。适用于开发者快速部署、调试或临时运行代码环境。


HN 热度 414 points | 评论 269 comments | 作者:achairapart | 1 day ago #

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

  • 网站首页信息匮乏,移动端和桌面端均无法直观了解服务内容,导致用户误判为游戏或实验项目。
  • 首页仅展示“ssh exe.dev”命令,缺乏解释,用户难以理解其用途,即使知道 SSH 命令也无从下手。
  • 用户认为应直接在首页展示核心功能说明,而非引导用户点击“关于”页面才能获取基本信息。
  • “关于”页面内容简略,仅说明服务是订阅制虚拟机,提供持久化磁盘和 SSH 访问,但未充分解释价值和使用场景。
  • 有人认为网站设计是“门禁机制”,筛选出真正有技术背景的用户,非目标用户无需关注。
  • 部分用户指出,网站设计过于晦涩,对普通用户不友好,缺乏基本的用户体验考量。
  • 有观点认为,网站的简洁设计是故意为之,旨在吸引技术背景强的用户,而非大众市场。
  • 有人质疑网站的“SSH 命令”提示存在安全隐患,若无注册流程,可能被恶意利用。
  • 有评论指出,用户不点击“关于”页面是正常行为,不能因此归咎于用户缺乏技术理解力。
  • 网站未提供清晰的使用流程或引导,导致用户无法快速判断是否值得尝试。
  • 有人认为,网站的“ssh exe.dev”提示是核心卖点,但缺少上下文,容易引发误解。
  • 有用户强调,网站的交互设计不完整,无法在手机端正常操作,影响整体体验。
  • 评论认为,网站的“为什么”比“如何”更重要,用户更关心服务的价值而非操作方式。
  • 有人指出,网站设计缺乏可访问性,如文字对比度不足,不符合无障碍标准。
  • 有观点认为,网站的极简风格是其特色,但牺牲了信息传达效率,不利于推广。

苹果发布开源模型,可瞬间将 2D 照片转为 3D 视图 (Apple releases open-source model that instantly turns 2D photos into 3D views) #

https://github.com/apple/ml-sharp

这是一个由苹果公司发布的开源项目,名为 SHARP(Sharp Monocular View Synthesis),旨在实现从单张图像快速生成高质量、可交互的 3D 视图。该项目基于一篇发表于 2025 年的 arXiv 论文,提出了一种全新的单目视图合成方法。

SHARP 的核心思想是通过一个神经网络,仅用一次前向传播,在不到一秒的时间内,从一张照片中回归出场景的 3D 高斯表示(3D Gaussian Splatting, 3DGS)。该方法具有以下特点:

  • 支持实时渲染:生成的 3DGS 模型可在标准 GPU 上实时渲染,生成高分辨率、逼真的新视角图像。
  • 保持真实尺度:输出的 3D 表示具有绝对尺度,支持精确的相机运动。
  • 零样本泛化能力强:在多个数据集上均表现出色,无需微调即可适应新场景。
  • 性能显著领先:相比现有最佳模型,LPIPS 降低 25%-34%,DISTS 降低 21%-43%,同时推理速度提升三个数量级。

项目提供完整的命令行工具(CLI),用户可通过简单命令完成预测和渲染:

  • 使用 sharp predict 对输入图像进行 3DGS 重建。
  • 使用 sharp render 生成带相机轨迹的视频(需 CUDA GPU 支持)。
  • 模型自动下载并缓存,也可手动下载预训练权重文件。

输出结果为标准的.ply 格式 3DGS 文件,兼容主流 3DGS 渲染器。坐标系遵循 OpenCV 规范(x 向右,y 向下,z 向前),场景中心大致位于(0, 0, +z)。

项目采用 MIT 许可证,模型使用独立的 LICENSE_MODEL 授权。代码基于多个开源项目构建,详细信息见 ACKNOWLEDGEMENTS 文件。

该工作为单目 3D 重建与视图合成领域树立了新标杆,适用于 AR/VR、数字孪生、内容创作等场景。


HN 热度 363 points | 评论 186 comments | 作者:SG- | 14 hours ago #

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

  • 苹果开源的 SHARP 模型能将 2D 照片瞬间转换为 3D 视图,相关论文和示例已在 GitHub 和 arXiv 发布。
  • 该技术的演示视频在 X 平台(原 Twitter)上比官方项目页面更具说服力。
  • GitHub 上 AI 相关项目的安装说明往往无法直接运行,通常假设用户已配置好开发环境。
  • 有用户指出该仓库的安装说明实际是可操作的,与普遍情况不同。
  • 该论文的作者多为非美国出生,反映了当前全球科研中外国出生研究人员占主导的现象。
  • 美国人口仅占全球约 5%,因此研究人员中美国出生者比例自然偏低,这并不奇怪。
  • 不能仅凭姓名判断一个人的出生地,且美国出生研究人员比例本就不高。
  • 美国高校科研人员中外国出生者占多数,部分原因是美国大学为应对财政危机而依赖国际学生学费。
  • 中国和印度在 2000 年代初扩大高等教育规模,导致大量 STEM 毕业生涌入美国攻读博士,形成人才外溢。
  • 美国高校在 2009-2015 年间大量招收国际博士生,为后来 AI 研究爆发提供了人才储备。
  • 美国本土 STEM 人才培养体系存在缺陷,教育文化鼓励平庸,抑制了顶尖人才的涌现。
  • 国际学生因家庭背景和文化压力,普遍努力学习以获得赴美机会,形成显著的竞争优势。
  • 美国本土难以培养足够数量的博士生来满足科技产业需求,导致长期依赖海外人才。
  • 中国和印度等国通过高考和经济改革,系统性地培养大量 STEM 人才,且多数人才留在本国。
  • 美国高校的博士生制度在 2012 年之前并非为产业需求而设,而是为应对财政和招生压力。
  • 2012 年深度学习兴起后,产业才开始大规模招聘研究人才,而此时人才池已由国际学生构成。
  • 美国若想实现本土人才自给,需将 CS 博士培养规模扩大 2.7 倍,这在现实中难以实现。

Show HN: Ez FFmpeg – 用自然语言进行视频编辑 (Show HN: Ez FFmpeg – Video editing in plain English) #

http://npmjs.com/package/ezff

ezff 是一个基于命令行的 ffmpeg 工具,旨在简化视频和音频处理操作。用户无需记忆复杂的 ffmpeg 命令,只需使用自然语言描述操作即可完成常见任务。

主要功能包括:

  • 转换格式:如将视频转为 GIF 或 MP3
  • 压缩视频至指定大小(如 10MB)
  • 裁剪视频片段(如从 0:30 到 1:00)
  • 提取音频
  • 调整分辨率(如 1280x720 或 720p)
  • 改变播放速度(加速或减速)
  • 反转、静音、旋转、翻转视频
  • 生成缩略图
  • 合并多个视频或添加音频
  • 转为灰度、稳定画面、降噪等

支持交互模式和直接命令两种使用方式。交互模式通过提问引导用户完成操作,直接命令则可直接输入指令。所有操作前可使用 –dry-run 预览生成的 ffmpeg 命令。

工具基于 Node.js 开发,需系统安装 ffmpeg 并加入 PATH。支持 macOS、Ubuntu/Debian 和 Windows。

项目采用 MIT 开源协议,代码开源,欢迎贡献。整体设计简洁、离线运行、无需网络或 AI 支持,依赖模式匹配实现指令解析。


HN 热度 343 points | 评论 164 comments | 作者:josharsh | 18 hours ago #

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

  • 使用 ffmpeg 命令行工具虽然看似复杂,但其背后的原因是多媒体处理本身具有高度复杂性,过度简化可能带来质量损失和误导用户对媒体处理的理解。
  • 一些旨在简化 ffmpeg 操作的工具(如 Ez FFmpeg)隐藏了关键选项(如是否重新编码),可能导致不必要的重编码,从而浪费时间和降低质量。
  • 对于不常使用 ffmpeg 的用户而言,记忆命令语法确实困难,尤其当任务不完全相同时,需要更友好的交互式引导工具来帮助构建命令。
  • 利用 LLM 可以高效生成并解释 ffmpeg 命令,是一种实用且有效的替代方案,尤其适合偶尔使用者。
  • 理想的解决方案应是提供一个交互式脚本,通过提问方式引导用户完成操作,并解释每个参数的作用,同时优先选择不重新编码的处理方式。
  • 存在过时的可视化图形化工具(如基于节点连接的 ffmpeg GUI),能有效降低学习门槛,但因商业化失败而关闭,未开源,令人遗憾。
  • 通用型命令行工具构建器(支持选项选择、自动补全、参数提示与模板保存)有巨大潜力,但目前尚无成熟实现,值得开发。

Always bet on text (2014) (Always bet on text (2014)) #

https://graydon2.dreamwidth.org/193447.html

作者立场鲜明:在任何“动态”多媒体(视频、3D、游戏)面前,文本永远是首选、最强、最万能的沟通技术。

  1. 最古老也最耐用:五千年前的文字今天仍能阅读,可刻进花岗岩。
  2. 最灵活:任何抽象概念、精确逻辑、诗意暗示,只有文字能拿捏得准;图片做不到。
  3. 最高效:同样信息量,文本占用的存储与带宽远低于图片/音视频;通信史就是“先文字,后富媒体”。
  4. 最社会:可检索、翻译、 diff、分支、引用、批注、异步、多人协作……图书馆与互联网的知识生态皆建立在文本之上。

结论:能写字就别犹豫,永远押注文本,它几乎不会辜负你。


HN 热度 338 points | 评论 167 comments | 作者:jesseduffield | 1 day ago #

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

  • 文本具有无限的灵活性、可索引性和持久性,是知识传递的可靠载体。
  • 通过学习钢琴的经历,意识到实时反馈和互动教学对技能掌握的重要性,这超越了纯文本学习的局限。
  • 布雷特·维克托的工作展示了通过直观交互提升知识传递效率的潜力,尤其适合那些缺乏符号直觉的学习者。
  • 丰富于文本的交互式系统需要大量工程投入,实现难度高,难以快速复制其效果。
  • 尽管布雷特·维克托的演示令人鼓舞,但其背后的技术实现极为复杂,普通开发者难以轻易复现。
  • Folk Computer 项目试图在动态土地理念基础上进一步发展,支持多线程任务调度和原子查询,提升系统性能。
  • Folk Computer 采用 Tcl 作为主要脚本语言,融合 HTML、正则表达式、JavaScript、C 和 Haskell 等多种技术,强调工具集成与实用性。
  • 项目目前仍处于预 Alpha 阶段,文档和主页信息不足,需改进对项目的清晰描述。
  • 音乐记谱法虽为一种文本形式,但其二维布局、全局状态影响和跨距离关联等特性,使其在表达音乐信息上优于线性文本。
  • 对于复杂音乐,传统五线谱优于纯文本;但对简单民谣,如 ABC 记谱法,可能更便于视奏。
  • 音乐记谱法无法完全捕捉演奏中的细微表现力,如爵士乐中的“摇摆感”,这与文字无法完全传达口语的语调类似。
  • 将音乐记谱法视为文本并不矛盾,其符号系统虽不同于普通文字,但本质上仍是一种符号化表达方式。
  • 若将所有计算机可表示的内容都视为文本,则“文本”一词将失去其特定意义,变得泛化而无区分度。

Hacker News 精彩评论及翻译 #

How uv got so fast #

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

The most surprising part of uv’s success to me isn’t Rust at all, it’s how much speed we “unlocked” just by finally treating Python packaging as a well-specified systems problem instead of a pile of historical accidents. If uv had been written in Go or even highly optimized CPython, but with the same design decisions (PEP 517/518/621/658 focus, HTTP range tricks, aggressive wheel-first strategy, ignoring obviously defensive upper bounds, etc.), I strongly suspect we’d be debating a 1.3× vs 1.5× speedup instead of a 10× headline — but the conversation here keeps collapsing back to “Rust rewrite good/bad.” That feels like cargo-culting the toolchain instead of asking the uncomfortable question: why did it take a greenfield project to give Python the package manager behavior people clearly wanted for the last decade?

orliesaurus

在我看来,uv成功的最惊人之处根本不是Rust,而是我们仅仅通过最终将Python包管理视为一个规范良好的系统工程问题,而不是一堆历史偶然形成的产物,就“解锁”了如此多的速度。如果uv是用Go甚至高度优化的CPython编写的,但遵循相同的设计决策(重点遵循PEP 517/518/621/658等规范,运用HTTP范围请求技巧,采用激进的优先使用wheel策略,忽略明显带有防御性的版本上限等),我强烈怀疑我们现在争论的会是1.3倍还是1.5倍的速度提升,而不是一个10倍的惊人数据——但这里的讨论却总是退回到“用Rust重写是好是坏”的争论中。这感觉像是在对工具链进行盲目崇拜,而不是去问那个令人不舒服的问题:为什么需要一个新的从零开始的项目,才能让Python拥有过去十年来人们一直明确想要的包管理器行为?


Exe.dev #

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

That must be worst website ever made.

Zero information available on mobile.

I thought it is some kind of portfolio site that does not work on mobile.

sccxy

这一定是史上最烂的网站。手机上看不到任何信息。我原以为这是个在手机上无法浏览的作品集网站。


Experts explore new mushroom which causes fairytal… #

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

So, about one mushroom species in five is poisonous. Why is the ratio so low, why are there lots of edible ones? Without hard-shelled seeds to spread, why be eaten? And the poisonous ones apparently don’t use color as a warning signal, and don’t smell all that bad, and some of the poisons have really mild effects, like “gives only some people diarrhea” or “makes a hangover worse”. Meanwhile three of the deadliest species seemed to need their toxin (amanitin) so much that they picked it up through horizontal gene transfer. Why did just those ones need to be deadly? In addition to which we have these species that don’t even make you sick, just make you trip out, a function which looks to have evolved three times over in different ways. What kind of half-assed evolutionary strategies are these? What do mushrooms want?

card_zero

那么,大约五分之一的蘑菇种类是有毒的。为什么这个比例这么低,为什么会有这么多可食用的种类呢?蘑菇又没有硬壳种子需要靠被吃来传播,为什么要被吃掉呢?而且,有毒的蘑菇似乎不用颜色作为警告信号,闻起来也不怎么难闻,有些毒素的效果相当温和,比如“只会让一些人拉肚子”或者“让宿醉变得更糟”。与此同时,致死性最强的三个物种似乎非常需要它们的毒素(鹅膏蕈氨酸),以至于是通过水平基因转移才获得的。为什么偏偏是那几种需要致命呢?除此之外,还有一些种类,它们甚至不会让你生病,只会让你产生幻觉,而这种功能看起来是以三种不同的方式独立进化出来的。这是些什么样的半吊子进化策略啊?蘑菇到底想要什么?


My insulin pump controller uses the Linux kernel. … #

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

I then decided to contact Insulet to get the kernel source code for it, being GPLv2 licensed, they’re obligated to provide it.

This is technically not true. It is an oversimplification of the common case, but what actually normally should happen is that:

  1. The GPL requires the company to send the user a written offer of source code.

  2. The user uses this offer to request the source code from the company.

  3. If the user does not receive the source code, the user can sue the company for not honoring its promises, i.e. the offer of source code. This is not a GPL violation; it is a straight contract violation; the contract in this case being the explicit offer of source code, and not the GPL.

Note that all this is completely off the rails if the user does not receive a written offer of source code in the first place. In this case, the user has no right to source code, since the user did not receive an offer for source code.

However, the copyright holders can immediately sue the company for violating the GPL, since the company did not send a written offer of source code to the user. It does not matter if the company does or does not send the source code to the user; the fact that the company did not send a written offer to the user in the first place is by itself a GPL violation.

(IANAL)

teddyh

于是我决定联系Insulet公司,获取其内核的源代码。由于它遵循GPLv2许可证,他们有义务提供。

这在技术上来说是不正确的。这只是一个对常见情况的过度简化,但实际上,通常应该发生的情况是:

  1. GPL要求公司向用户提供一份提供源代码的书面报价。
  2. 用户利用这份报价向公司请求源代码。
  3. 如果用户没有收到源代码,可以起诉该公司未履行其承诺,即提供源代码的报价。这不构成GPL违规,而是一种直接的合同违约;在这种情况下,合同指的是明确的源代码提供报价,而不是GPL本身。

请注意,如果用户一开始就没有收到提供源代码的书面报价,那么上述所有情况都不适用了。在这种情况下,用户无权要求源代码,因为他们没有收到源代码的报价。

然而,版权持有人可以立即起诉该公司违反了GPL,因为他们没有向用户提供提供源代码的书面报价。公司之后是否向用户发送了源代码都无关紧要;他们一开始就没有向用户提供书面报价这一事实本身就构成了GPL违规。

(我不是律师)


White House pushes to dismantle leading climate an… #

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

I think this sums it up pretty well.

“When I am weaker than you, I ask you for freedom because that is according to your principles; when I am stronger than you, I take away your freedom because that is according to my principles,”

Coffeewine

我觉得这总结得挺到位的:“当我弱于你时,我向你争取自由,因为那是你的原则;当我强于你时,我剥夺你的自由,因为那是我的原则。”


Ask HN: What did you read in 2025? #

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

This year:

  • I read the entire “Frog & Toad” collection. Probably about 30 times, some stories more.

  • “Little Shrew’s Day”… probably 25 times.

  • Many of the “Construction Site” series books, especially the OG “Goodnight, Goodnight, Construction Site”. The “Garbage Crew” and “Airport” books featured heavily.

  • Started to mix in some “Pete the Cat” titles.

  • “Detective Dog Nell” got a lot of air play.

Lots of others, but those are definitely the frequent fliers.

numbsafari

今年:

  • 我把《青蛙和蟾蜍》系列全读完了。大概读了30遍,有些故事读的次数更多。
  • 《小鼹鼠的一天》……大概读了25遍。
  • 读了很多《建筑工地》系列的书,特别是原版的《晚安,晚安,建筑工地》。《垃圾队》和《机场》这两本出现的频率很高。
  • 开始穿插着读一些《皮特猫》系列的书籍。
  • 《侦探狗奈尔》也读了很多遍。 还有很多其他的,但以上这些绝对是读得最多的。

Rob Pike goes nuclear over GenAI #

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

If the creators set the LLM in motion, then the creators sent the letter.

If I put my car in neutral and push it down a hill, I’m responsible for whatever happens.

nkrisc

如果创造者启动了LLM,那么创造者就发送了这封信。 如果我把车挂到空挡并推下山,那么无论发生什么我都要负责。


Apple releases open-source model that instantly tu… #

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

https://raw.githubusercontent.com/apple/ml-sharp/refs/heads/main/LICENSE_MODEL

“Exclusively for research purposes” so not actually open source.

RobotToaster

“仅用于研究目的”,所以实际上并不是开源的。


Publishing your work increases your luck #

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

Having your OSS library take off

All of the other bullet points there are pretty reasonable, but, having worked in OSS professionally, I genuinely hope none of my GH projects take off in the OSS world.

I have a few projects that are in the >50 stars range, and am both grateful for other people’s interests and very glad that none of them crossed the threshold to becoming real OSS projects. I like sharing my interesting experiments, but I absolutely do not want to be stuck with the nightmare of maintaining OSS software for years.

Even on these small projects, I’ve had times when I’m pressured to do a bug fix on a 5 year old project where I don’t even remember how it works or review and merge an enthusiastic PR solving a problem I don’t actually care about. It has eaten up a few weekends, and was a relatively minor annoyance, but it gave me the taste for what OSS work involved. Working professionally for an OSS company gave me even more insight.

Maintaining OSS is a royal pain in the butt and I am forever grateful for the people who choose to do this. Running a popular OSS library is not a prize. It’s at least a part time job you aren’t paid for. The benefits are slim; even the “fame” part (name your top 10 favorite OSS tools, now name the maintainers of those), and has really limited rewards outside of that. I’ve know plenty of brilliant creators of OSS libraries who struggle to find jobs in industry that are appropriate to their skill level.

In fact, it’s really hard to both run a successful OSS project and have a full time job (especially a high paying one that wants a lot of your brain and time) if you can’t some how manage to make that OSS project your full time job… and even then you will be under constant pressure to find a way to monetize your OSS project (which inevitably leads to either losing that job or making decisions not in the interest of your community of OSS users).

OSS maintainers are saints as far as I’m concerned. So much of the world’s software depends on them (even moreso in the age of LLMs) and the vast majority are compensated way less than your average FAANG engineer.

crystal_revenge

让你的开源库一飞冲天

那里的其他要点都相当合理,但是,作为一名专业的开源项目工作者,我真的希望我在 GitHub 上的项目没有一个能真正在开源世界崭露头角。

我有几个项目的星标数在50以上,我既感谢他人的关注,也很庆幸没有一个项目跨越了门槛,成为真正的开源项目。我喜欢分享我有趣的实验,但我绝对不想被噩梦般地困在维护开源软件的泥潭中好几年。

即使在这些小项目上,我也曾被压力要求修复一个五年前的项目中的错误,而我甚至都不记得它是如何工作的了,或者去审查和合并一个充满热情的 PR,它解决的是我其实并不关心的问题。这花掉了我好几个周末的时间,虽然只是个小烦恼,但它让我尝到了开源工作的滋味。在一家开源公司里工作的经历让我有了更深入的了解。

维护开源项目简直是件苦差事,我永远感激那些选择做这件事的人。运营一个流行的开源库不是什么奖品。它至少是一份你没有报酬的兼职工作。好处微乎其微;甚至所谓的“名声”也是(说出你最喜爱的10个开源工具,现在说出这些工具的维护者),除此之外,回报也确实非常有限。我认识很多优秀的开源库创作者,他们都很难找到与自身技能水平相匹配的工业界工作。

事实上,要同时运营一个成功的开源项目和拥有一份全职工作是非常困难的(尤其是那份薪水很高、需要你投入大量脑力和时间的工作),如果你无法设法让你的开源项目成为你的全职工作……即便如此,你也会持续面临找到一种方式来将你的开源项目变现的压力(这不可避免地导致要么失去那份工作,要么做出对开源用户社区不利的决定)。

在我看来,开源项目的维护者们都是圣人。世界上那么多的软件都依赖于他们(尤其是在大语言模型时代),而绝大多数人的报酬都远低于普通 FAANG 工程师的收入。


Experts explore new mushroom which causes fairytal… #

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

Could be that the mushroom just temporarily interferes with the substances the elves put in our water supply to keep us in the dark?

nospice

会不会是蘑菇只是暂时干扰了精灵们投放到我们饮用水中、用来让我们蒙在鼓里的那些物质?


White House pushes to dismantle leading climate an… #

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

“one of the largest sources of climate alarmism in the country.”

It’s amazing how fast free speech has been destroyed in the past year. Especially when it comes to censorship of science and science’s conclusions.

However, I heard many many more people complaining about a lack of free speech in 2023 and 2024 than now. I really wonder what happened to all those principles! It’s shocking.

epistasis

“该国气候危言耸听的最大来源之一。”

言论自由在过去一年里被扼杀的速度真是惊人。尤其是在科学和科学结论的审查方面。

然而,比起现在,我在2023年和2024年听到抱怨缺乏言论自由的人多得多。我真的想知道那些原则都怎么了!太令人震惊了。


Floor796 #

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

The editor that is used to draw these animations https://floor796.com/editor/l0

Author has a YouTube channel too somewhere where you can see him making a drawing start to end. (edit: https://m.youtube.com/channel/UCribkEGzOuMQ9ozb0ektMCQ )

From FAQs

The creation of Floor796 started in 2018. I spent the first year creating the animation editor, the rendering engine and the site itself. Then I started drawing the first characters. I drew slowly at first, as I had to get used to the projection and constantly improve the animation editor. I’ve been creating the first block for over 8 months. Now I draw 1 block in about 1-1.5 months.

Author made everything, including the editor, by himself.

smusamashah

用于绘制这些动画的编辑器 https://floor796.com/editor/l0

作者在YouTube上也有一个频道,你可以在那里看到他从头到尾的创作过程。(编辑:https://m.youtube.com/channel/UCribkEGzOuMQ9ozb0ektMCQ)

来自常见问题解答:

Floor796的创作始于2018年。我花了一年的时间来创建动画编辑器、渲染引擎和网站本身。然后我开始绘制第一个角色。起初我画得很慢,因为我必须习惯投影法并不断改进动画编辑器。我花了8个多月的时间来创作第一个方块。现在,我画一个方块大约需要1到1.5个月。

作者自己完成了所有工作,包括编辑器。


How uv got so fast #

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

Given the context of the article, I think “Rust specific” here means that “it couldn’t be done in python”.

For example “No interpreter startup” is not specific to Rust either.

nemothekid

根据文章的上下文,我认为这里的“Rust特有的”指的是“它无法用Python实现”。例如“无需解释器启动”也不是Rust特有的。