Hacker News

Linux 内核漏洞利用：Vsock 的攻击

作者: todsacerdoti | 发布时间: 2025-04-30 15:03:04

内容摘要

Linux Kernel Vsock Use After Free (CVE-2025-21756) 漏洞利用分析

本文详细记录了作者将一个针对 Linux 内核 Vsock 模块的简单补丁（CVE-2025-21756）转化为成功获取 root shell 的漏洞利用过程。漏洞的核心在于 Vsock 在解除绑定时的引用计数错误，导致对象被过早释放，产生 Use After Free (UAF) 问题。

作者首先搭建了 QEMU 和 gef-kernel 的调试环境，并在 WSL 中进行开发。通过分析补丁代码，确认了问题在于 vsock_remove_sock 在特定情况下会错误地减少引用计数，导致未绑定或已解绑的 vsock 对象被释放。

利用 UAF 漏洞的初步想法是使用 cross-cache 攻击，通过 msg_msg 对象重新占位被释放的 vsock 对象，然后篡改函数指针实现代码执行。但实际操作中遇到了 AppArmor 和 LSM 机制的阻碍，几乎所有关键的 socket 函数都被保护，在尝试访问被释放对象的 sk->sk_security 指针时会触发内核崩溃。

为了绕过 AppArmor 和 LSM 的限制，作者寻找未受保护的函数。最终发现了 vsock_diag_dump 函数，该函数能够泄漏套接字信息，但需要通过 sk->sk_state 和 sk_net 的检查。sk->sk_state 容易满足，但 sk_net 在尚未绕过 kASLR 的情况下是个难题。

在社区的帮助下，作者采用了管道（pipe）作为内存暂用对象，利用 vsock_diag_dump 作为侧信道，通过向管道缓冲区逐个字节写入数据并观察 vsock_diag_dump 是否仍然找到被释放的 vsock 对象，来判断 sk_net 指针是否被成功覆盖。这种方法成功实现了 kASLR 绕过，并获得了 init_net 的地址，同时也控制了 vsock 对象中的已知偏移位置。

控制 RIP 的策略是利用 vsock_release 函数中对 sk->sk_prot->close(sk, 0) 的调用。通过将 sk->sk_prot 指向 raw_proto 结构体，其 .close 成员指向 raw_abort 函数。raw_abort 函数会调用 sk_error_report(sk)，因此可以覆盖 sk->sk_error_report 字段为一个栈跳转（stack pivot）gadget，进而跳转到构造好的 ROP 链。

ROP 链的目标是调用 commit_creds(init_cred) 函数来提升权限，并最终通过 swapgs_restore_regs_and_return_to_usermode 返回用户空间执行 shellcode。经过多次调试和对 sk_lock 等成员的精确伪造，最终成功获得了 root shell。

整个过程突显了内核漏洞利用的复杂性，以及在面对如 LSM 等安全机制时所需的创新性绕过技术，同时也体现了社区协作在解决技术难题中的重要作用。

讨论焦点

阅读原文

兆芯KX-7000

作者: ryandotsmith | 发布时间: 2025-04-30 16:23:33

内容摘要

兆芯KX-7000处理器核心技术分析与性能评估

本文深入分析了兆芯最新的KX-7000处理器的架构特点和性能表现。KX-7000采用了代号为“世纪大道”的新架构，这是一款4发射、支持AVX2指令集、乱序执行窗口可与2010年初英特尔CPU媲美的处理器。它继承了威盛电子的x86-64授权，并在政府支持下旨在服务国内市场，以替代西方芯片。

相对于前代性能不足的陆家嘴架构，世纪大道架构在单核性能上取得了显著进步。其前端采用传统的取指和解码设计，拥有64KB一级指令缓存和4096项分支目标缓冲区，但L1缓存外的指令带宽和分支预测延迟表现一般。乱序执行方面，借助192项的ROB（重排序缓冲区），理论上前瞻能力大幅提升。后端的执行单元，特别是浮点/向量执行单元表现强大，支持256位AVX2指令的执行吞吐量可与Haswell媲美。然而，许多256位向量操作被拆分成两个128位微操作处理，且缓存带宽较低，限制了其AVX2的实际性能发挥。

内存子系统进行了重新设计，引入了三级缓存体系结构，L3缓存容量大幅增加到32MB。然而，L3缓存延迟较高，带宽不足。DRAM访问方面，尽管理论带宽尚可，但实测读取带宽远低于预期，且在多核高负载下，线程间的延迟和带宽分配存在不公平现象。

单线程性能方面，KX-7000在SPEC CPU2017测试中较前代有巨大提升，大致与AMD Bulldozer处理器的水平相当。但在某些对内存子系统和分支预测要求较高的测试中仍落后于 Bulldozer。

多线程性能方面，尽管拥有8个核心，但在x264视频编码和7-Zip压缩等测试中表现不及Bulldozer和Core i5-6600K。仅在部分充分利用AVX2的测试中展现了一定优势。

总体而言，兆芯KX-7000 represents中国在国产x86处理器领域迈出的重要一步。世纪大道架构在核心性能和乱序执行能力上取得了显著突破，达到了约十年前西方主流处理器的性能水平。尽管在前端效率、缓存带宽、内存延迟以及多核负载下的均衡性等方面仍存在不足，并且与现代高性能CPU仍有差距，但对于满足国内市场对不依赖西方技术的x86芯片需求，KX-7000提供了比前代更佳的实用性。

讨论焦点

围绕兆芯KX-7000帖子展开的讨论主要聚焦于中国政府在芯片产业中的角色、中国对国外芯片（如英特尔和AMD）的依赖程度及其未来趋势、兆芯芯片目前的性能水平以及与国外同类产品的差距，以及麒麟操作系统对用户体验的影响。IncreasePosts对地方政府参与兆芯项目的性质提出疑问，fspeech认为政府薪酬可能难以吸引顶尖芯片人才，wmf则反驳称中国政府曾“回购”海外人才，并猜测地方政府参与可能与投资过剩和设立当地的主权财富基金有关，jenny91确认政府参与此类项目在中国非常普遍。daniel_iversen关注中国在非AI领域对海外芯片的依赖情况，包括过去、现在和未来预测，并引用ChatGPT的回答，指出政府倾向于本地CPU，但消费级市场仍依赖英特尔和AMD。vessenes对兆芯KX-7000的性能进行详细分析，认为其与2010-2011年的AMD和英特尔竞品相当，仍需架构改进和工艺提升才能追赶国外先进水平。Merrill则询问使用麒麟操作系统而非Win11如何影响用户性能感知。整体来看，讨论存在对中国政府在芯片产业中作用理解的分歧，以及对中国国产芯片技术发展速度和未来走向的不同看法。

阅读原文

利用机械连杆和转轴实现可逆计算

作者: tennysont | 发布时间: 2025-04-30 13:35:08

内容摘要

机械计算：探索超摩尔定律时代的可能

随着对摩尔定律终结的担忧日益加剧，人们开始重新关注非传统计算模式，其中包括量子计算、模拟计算和可逆计算。尤其是在追求能源效率方面，可逆计算被认为是理论上效率最高的计算形式，因为根据朗道尔原理，只有不可逆的计算操作才会消耗能量。

文章指出，当前的计算硬件，即便是在效率持续提升的情况下，距离理论上的最大效率仍然有九个数量级的差距。这使得探索不同的计算范式既有趣也很有必要。

文章重点介绍了一种基于“链接”和“旋转关节”（铰链）构建图灵完备机械计算系统的方法，这来源于一篇名为《仅使用链接和旋转关节构建机械计算系统》的论文。该系统的基本组成部分包括：

1. 锁（The “Lock”）：由两个可滑动三角形构成，先推动的三角形会“锁死”另一个，阻止其前进。这种锁机制可以用于构建物理层的逻辑门，并且理论上可以在微纳米级别实现。
2. 平衡（The “Balance”）：结合了两个锁和一个杠杆，用于确保二进制位（1或0）的某个线路总是处于被推动状态。它通过时钟信号来强制未被输入信号占据的锁前进。
3. 曲柄（Bellcrank）：用于信号的路由和分发。

通过这些基本元件，文章进一步展示了如何构建一个NAND门。NAND门是一个通用门，意味着仅用NAND门就可以实现任何布尔函数。通过精心设计的链接和锁的组合，输入信号（真或假）控制相应的路径是否被锁定，未被锁定的路径则在时钟信号到来时被推动，从而实现NAND逻辑功能。

总而言之，这篇文章深入浅出地介绍了基于机械结构实现计算的可能性，特别是在可逆计算和能源效率方面展现出潜在优势。通过“锁”、“平衡”和“曲柄”这几个核心元件，构建了一个通用的NAND门，展示了机械计算作为未来超摩尔定律时代的一种有趣且有价值的探索方向。

讨论焦点

围绕着机械计算的可行性、限制、与电子计算的对比以及可逆计算的实际应用展开。主要在于机械纳米技术的尺度限制、功耗、摩擦问题、模拟计算的精度与稳定性以及可逆计算对初始状态的要求和 Landauer 原理的应用。评论者就这些技术挑战和概念理解进行了辩论和阐述。

阅读原文

NotebookLM 音频概述功能现已支持 50 多种语言

作者: saikatsg | 发布时间: 2025-04-30 13:28:38

内容摘要

NotebookLM音频概述功能新增支持50余种语言

这篇文章主要介绍了Google NotebookLM的音频概述功能迎来了重大更新——现已支持超过50种语言。该功能最初于去年年底推出，可以将用户上传的资料转化为类似播客的音频形式的总结。得益于Gemini原生的音频处理能力，现在全球的用户都能以自己偏好的语言使用这项功能，支持的语言范围广泛，包括南非荷兰语、印地语、土耳其语等。

文章强调，此更新是该功能早期发展阶段的一部分，未来还会根据用户反馈进行持续改进。用户可以在NotebookLM的设置中选择“输出语言”，音频概述和聊天回复都会根据此设置生成。这意味着用户可以轻松创建多语言的内容或学习材料。

文章举例说明了这一功能的实用性：一位老师可以通过上传不同语言（如葡萄牙语的纪录片、西班牙语的研究论文和英语的学习报告）的关于亚马逊雨林的资料，让学生们上传这些资料后，以他们自己偏好的语言生成音频概述来获取关键信息。这极大地消除了语言障碍，提高了信息的可及性。

最后，文章鼓励用户访问notebooklm.google尝试这项新功能，并用多种语言（英文、中文、法文）邀请用户“听一听”，凸显了功能的普适性。

讨论焦点

NotebookLM音频概览的热门评论主要围绕其实用性、音频风格、多语言支持以及潜在的应用场景展开讨论。用户对该功能的总结准确性、音频播客的风格及自然度持有不同看法，同时也探讨了其在特定领域的价值（如学习、研究、文档处理）。讨论中存在NotebookLM是否真正有用的核心分歧，以及对其音频风格的普遍抱怨。

讨论分支1（发起者ipsum2，与jszymborski, harryf, pottertheotter, jcims, jsnell, alphabetting, dobladov, bradly, HanClinto, da_chicken及多层嵌套回复之间的互动）：核心讨论焦点为NotebookLM的整体实用性及其音频概览功能对内容理解的有效性。ipsum2认为其音频概览过于泛化，且有过多冗余。jszymborski通过自身经验确认了其准确性问题，认为音频概览基本无用，尽管TTS效果很好。harryf认为对概览YouTube视频有用，但也批评Google将其做成封闭花园，并提及了非官方API的存在。energy123在回复harryf时提出直接复制YouTube转录并粘贴到LLM更便捷。pottertheotter指出许多人误将音频播客视为NotebookLM的全部功能。bongodongobob在回复pottertheotter时反驳说音频播客似乎是其唯一独特功能，其他功能LLM也能做到。其他用户则分享了各自的积极用例：jcims认为对主观内容有用；jsnell建议通过自定义提示词改善输出；alphabetting分享了一个用于生成深度技术摘要的有效提示词；dobladov认为其作为阅读伴侣很有用且引用准确无幻觉；bradly分享了在企业环境中使用其处理政策文件的成功经验；HanClinto认为其有助于对技术论文进行可理解的介绍，尽管有时会遗漏细节；da_chicken认为其对处理大量混乱文档非常有用，并提及了在桌面角色扮演游戏中查询规则的应用，但表示对音频功能不感兴趣。主要分歧在于用户对其在不同类型内容上的准确性和实用性体验差异巨大，以及对其作为独立工具相对于通用LLM的价值判断不同。

讨论分支2（发起者anyfactor，与riffic, behnamoh, jszymborski, myth_drannon, FlyingSnake, crazygringo之间的互动）：主要关注点在于NotebookLM现在支持的超过50种语言列表。riffic对冗长的列表表示惊讶，jszymborski则回复指出了Reddit的折叠功能可隐藏长列表。behnamoh表示很高兴列表中使用了“Persian”而非可能被一些伊朗人视为冒犯的“Farsi”，并解释了两种语言名称的词源区别及文化敏感性。其观点引发了myth_drannon关于阿拉伯语和阿拉姆语、希伯来语之间关系的细致订正，以及FlyingSnake对其朋友并未对“Farsi”反感的困惑。crazygringo则对因语言名称而感到受冒犯的合理性提出了质疑，认为语言名称的变迁是自然的，并类比了其他语言名称的例子。核心争议点集中在“Farsi”这一名称的文化敏感性及其使用是否合理。

讨论分支3（发起者TekMol，与crawsome, sega_sai, kleiba, threeducks, shreezus之间的互动）：讨论聚焦 NotebookLM 生成的音频概览（播客风格）令人 annoyance 的风格。TekMol觉得这种播客风格令人烦躁，希望只有简单的文本朗读。crawsome和sega_sai也表示同感，认为过度热情且试图制造“兴奋感”的风格很烦人，尤其对于技术内容。kleiba回复crawsome建议尝试听德语音频，风格不同，可能没那么“山谷女孩”腔调。threeducks类比了美剧《硅谷》中的场景，认为这种增加虚假人类语气的做法是“解决不存在的问题”，并戏称希望有“吉尔福伊尔模式”来获得冷冰冰的精确回答。shreezus认为这种风格起初令人印象深刻，但很快就变得公式化。核心争议点是NotebookLM的播客式音频风格是否可取或令人反感，用户普遍倾向于更简洁、直接的文本朗读或更自然真实的风格。

讨论分支4（发起者ljoshua，与SecretDreams, suddenlybananas, bbatsell之间的互动）：讨论重点在于NotebookLM音频概览作为学习工具和对不同用户的适用性。ljoshua分享了将其用于家庭教育的积极经验，通过将扫描的书籍内容转换为文本并送入NotebookLM生成音频，孩子们喜欢通过听的方式学习。SecretDreams认为这种音频概览新颖实用，但指出它们只覆盖高层内容，缺乏深度，适合already knowledgeable或初学者在深入阅读前的概览使用。bbatsell回应SecretDreams，确认了这种概览非常适合作为深入学习前的支架，帮助建立高层理解。suddenlybananas询问ljoshua是否鼓励孩子们同时进行阅读，ljoshua确认孩子们也大量使用图书馆卡进行阅读。主要观点是强调了音频概览作为学习辅助工具的价值，尤其是在提供初步了解和概览方面，但公认为其深度不足。

讨论分支5（发起者mikeocool，与latentsea, gervwyk, Jolter之间的互动）：讨论聚焦于NotebookLM生成的播客风格过于夸张和程式化。mikeocool认为这种播客像是真实播客的漫画式模仿，过度使用语言技巧。latentsea对此表示赞同。gervwyk虽然同意风格夸张，但认为这种形式仍有其价值和应用场景，特别是非技术受众，并分享了用于案例研究的积极反馈，认为随着听习惯了cringe感会降低，甚至有人分不清是否AI生成，同时也提到了Descript故意使AI形象非真实化的做法。Jolter回复gervwyk，称赞了其分享的“着火！”示例非常自然。核心争议点在于这种夸张风格是否完全是负面的，以及其在特定商业场景下的可接受度和有效性。

阅读原文

小米MiMo推理模型

作者: thm | 发布时间: 2025-04-30 04:48:20

内容摘要

MiMo：解锁语言模型的推理潜力——从预训练到后训练

本文档介绍了由小米团队开发的 MiMo-7B 系列模型。MiMo 系列模型的重点在于提升语言模型的推理能力，并挑战了在小型模型上同时实现数学和代码推理能力突破的传统观点。团队认为，要充分发挥语言模型的推理潜力，不仅需要后训练，还需要从预训练阶段就针对推理任务进行优化。

核心亮点：

1. 专注于推理的预训练： MiMo-7B-Base 模型在预训练阶段就进行了优化。通过改进数据处理流程、增强文本提取工具以及应用多维度数据过滤，提高了预训练数据中推理模式的密度。同时，生成了大量多样化的合成推理数据。预训练采用了三阶段数据混合策略，总共使用了约25万亿个 token。此外，引入了多 token 预测（Multiple-Token Prediction, MTP）作为辅助训练目标，以提升模型性能并加速推理。

2. 开创性的后训练方案： 构建了包含13万条数学和代码问题的强化学习训练数据集，这些问题均可通过基于规则的验证器进行验证。数据经过仔细清洗并评估难度。后训练仅使用基于规则的准确率奖励，避免了潜在的奖励作弊问题。针对挑战性代码问题的稀疏奖励问题，引入了基于测试难度驱动的代码奖励机制，为不同难度的测试用例分配细粒度分数，通过更密集的奖励信号优化策略。还采用了对简单问题进行数据重采样的策略，以提高 rollout 采样效率并稳定策略更新。

3. 高效的强化学习基础设施： 开发了无缝 Rollout 引擎，通过整合连续 Rollout、异步奖励计算和早期终止等方式，加速 RL 训练和验证，显著减少 GPU 空闲时间。支持在 vLLM 中使用 MTP 并增强了 RL 系统中推理引擎的鲁棒性。

模型系列：

• MiMo-7B-Base：具有出色推理潜力的基础模型。
• MiMo-7B-RL-Zero：从基础模型训练而来的 RL 模型。
• MiMo-7B-SFT：从基础模型训练而来的 SFT 模型。
• MiMo-7B-RL：从 SFT 模型训练而来的 RL 模型，在性能上可与 OpenAI o1-mini 媲美。

文档提供了各模型在通用、数学和代码基准测试上的评估结果，显示 MiMo-7B-RL 在数学和代码任务上表现出色。还提供了 MiMo 系列模型在 HuggingFace 上的下载地址，并提供了使用 vLLM 和 HuggingFace 进行模型推理的示例代码和推荐环境。

MiMo 项目遵循 Apache-2.0 许可证开源。

讨论焦点

热门评论主要聚焦于三个方面：首先是对中国AI模型倾向于英语的讨论，涉及英语作为科研和训练数据的优势、训练资料的获取难度以及语言学习和使用习惯的影响；其次是对小米MiMo模型性能基准的质疑，引发了关于小模型能力提升、基准测试本身有效性以及过拟合的争议；最后是关于Ollama使用GGUF文件格式和ModelFile的讨论，涉及用户使用体验以及与GGUF原始设计理念的冲突。

阅读原文

自去年年初以来，Google Play 应用减少了 47%

作者: GeekyBear | 发布时间: 2025-04-30 15:03:49

内容摘要

Google Play 商店 App 数量大幅下降近半

根据应用分析提供商 Appfigures 的最新分析，Google Play 商店的应用数量从 2024 年初的约 340 万个大幅下降至目前的约 180 万个，降幅高达 47%。与此同时，Apple 的 App Store 应用数量略有增加，表明 Google Play 的应用数量下降并非普遍的市场趋势。

这一显著下降被认为是 Google 对 Play 商店进行的一次重大“清理”行动。多年来，Google Play 相对宽松的应用审核机制导致其应用市场充斥着质量低下、存在欺诈或滥用行为的应用。与 Apple 严格的人工审核不同，Google 通常更多依赖自动化检测和恶意软件扫描。

为了提升应用质量，Google 从 2024 年 7 月起提高了应用的最低质量要求。除了禁止崩溃、无法安装或正常运行的应用外，Google 开始禁止功能和内容有限的应用，例如只有文本或单个壁纸的静态应用，以及那些没有实际功能的废弃应用。Google 证实，这些新政策是导致应用数量下降的关键因素之一，其中包括加强的开发者验证要求、针对新个人开发者账户的应用测试要求以及增加人工审核，以识别试图欺骗用户的应用。

Google 还指出，2024 年在人工智能威胁检测、更严格的隐私政策和改进的开发者工具等方面也进行了投资。这些努力使得 Google 在 2024 年阻止了 236 万个违反政策的应用发布到 Play 商店，并封禁了超过 15.8 万个试图发布有害应用的开发者账户。

尽管应用总量大幅下降，但 Appfigures 注意到，即使在官方清理行动开始之前，Google Play 的应用数量就已经出现下降趋势，具体原因尚不明确。不过，今年截至 4 月，Google Play 的新应用发布量达到 10,400 个，同比增长 7.1%。

总体而言，Google Play 应用数量的大幅减少反映了 Google 在改善应用生态系统质量、打击低质量和有害应用方面的努力。这对用户而言可能意味着更容易找到优质应用，对开发者而言则可能减轻部分竞争压力。

讨论焦点

讨论焦点主要围绕 Google Play 平台应用数量下降 47% 的原因，特别是新的开发者政策，如要求提供 DUNS 号码和公开个人信息，对独立开发者和小型企业的影响。此外，讨论也延伸到了应用商店的垄断地位、政府监管的影响、技术官僚化以及低质量应用的清理等议题。

Lammy 指出应用数量下降主要是因为 Google 要求独立开发者提供 DUNS 号码，并提供了自身的经历和收到的 Google 邮件截图作为证据，邮件中 Google 将其视为“公司”而非个人，表明对个人开发者的不友好态度。 cyral 和 Lammy 讨论了获取和验证 DUNS 号码的困难，即使对于有子公司的公司也面临流程复杂、支持不足、系统错误等问题，认为这是灾难性的。cyral 进一步抱怨 Google 和 Apple 的支持流程混乱，无法有效解决问题。arghwhat 和 cyral 讨论了在母公司管理下子公司验证问题的通用性，以及 EV 证书验证的类似难题。jll29 和 cyral 讨论了 Google 只将用户视为匿名数据点，缺乏重视客户的文化，与 Apple 相比，尽管 Apple 对硬件客户和高价值员工较好，但同样忽略开发者。jll29 认为独立开发者为平台带来间接收益，但缺乏力量，建议联合起来。827a 和 cyral 讨论了 Apple App Store 和 D&B 系统不同步导致的地址验证问题，极端情况下甚至需要新注册公司。echelon 和 cyral 讨论了 Apple 和 Google 在分发、默认设置、支付等方面的垄断，认为它们需要被监管，呼吁推广 Web 分发应用。yieldcrv 和 cyral 讨论了应用商店在管理只有一个Holding company for the app 的情况下的困难。 arghwhat 和 Lammy 讨论了获取 DUNS 号码是否简单的问题，arghwhat 认为对于个人开发者只是填写表格，不算难事，Lammy 反驳说要求做任何事都是一种障碍，认为 solo 开发者不再被需要。 sneak 抱怨加入 Apple Developer Program 的审批流程漫长（五周），导致创业公司无法及时部署 MDM。sneak 认为这些公司通过广告和应用内购牟取暴利，缺乏改进其他服务的动力，利用垄断地位进行“寻租”。 streptomycin 和 Lammy 讨论了要求公开个人地址的问题，这不仅仅是 DUNS 号码，还包括家庭地址，并需要公开在 DUNS 网站和 Google Play 页面上。streptomycin 猜测这可能与政府监管有关。 cyberax 和 streptomycin 讨论了地址要求，cyberax 遇到的要求是商业区地址。bcye 和 streptomycin 讨论了如果应用不收费，是否就不需要公开地址，bcye 认为收费才需要，这相对合理。jonas21 和 streptomycin 确认这是为了遵守欧盟的《数字服务法案》(DSA)，需要公开地址和电话号码。 odo1242 补充了对个人开发者的其他要求，包括 10 个（实际是 12 个，由 bugfix 修正）beta 测试用户和公开家庭地址，认为 Google 不欢迎个人开发者。bugfix 和 odo1242 确认了测试用户数量为 12 个，政策是从去年的 20 个降下来的。 moffkalast 质疑 Google 要求开发者注册 Dun & Bradstreet (D&B) 的行为，认为是腐败的表现，认为欧盟的监管还不够严厉。jodrellblank 和 moffkalast 质疑 moffkalast 的腐败指控。pkaye 和 moffkalast 询问这是否是欧盟的要求。cowsandmilk 和 moffkalast 反驳了腐败指控，并指出 DUNS 号码是欧盟委员会的商业标识标准，D&B 是欧盟要求的，恰恰是欧盟监管的结果。 bcye 和 Lammy 质疑 Lammy 声称的 DUNS 要求适用于个人开发者，指出链接的 Google 来源只提及组织账户，并且自己成功创建了个人账户而没有 DUNS。 greatgib 和 Lammy 描述了自己因不想遵守新的公开信息义务而导致长期应用被下架的经历。 mattmaroon 认为 DUNS 不是唯一或主要原因，更多是因为 Google 清理了大量低质量应用。

fidotron 认为应用数量下降主要原因是欧盟从去年二月开始执行的新的交易者身份规则，要求开发者公开姓名和地址。 Aerroon 和 fidotron 讨论了这项欧盟规则对个人和小型开发者的负面影响，他们难以承担办公室费用，公开个人信息可能导致垃圾邮件和骚扰，甚至被链接到家庭地址的街景图片。这阻碍了欧洲科技的发展。leonidasv 和 Aerroon 补充说 Apple 允许使用邮政信箱，但 Google 不允许，只能使用虚拟办公室。 sschueller 和 fidotron 描述了自己因无法验证商业号码而不得不公开个人手机号码的经历。cyral 和 sschueller 也有类似经历，验证流程困难， bahkan 无法通过自动语音系统获取验证码。 dusted 和 fidotron 表示这是他们放弃应用开发的原因。 trunch 和 fidotron 讨论了个人开发者不愿公开姓名和地址的心态，特别是对于一些与个人品牌可能不完全一致的项目。ragnese 和 trunch 认为公开信息的要求是次要问题，核心问题在于在通用计算设备上分发和安装应用依然困难。ragnese 对 Google 在 Android 上限制侧载的可能性表示担忧，并强调 F-Droid 和直接发布 APK 的重要性。 tslocum 分享了他因政策导致 FOSS 应用被 Google Play 下架的经历，并推荐 F-Droid 作为解决方案。 stringtoint 也因欧盟规定导致免费应用被下架，不愿公开个人地址和电话，认为执行层面存在严重缺陷。

mullingitover 指出 Google Play 移除低功能和内容有限的应用是清理“零价值应用”，质疑 Google 为何一开始允许这些应用存在。ozim 和 mullingitover 认为应该允许人们发布“垃圾应用”，作为学习和表达的途径，这也能帮助社区开发者，而当前的政策让这些变得困难。mullingitover 和 ozim 反驳说可以在 Play Store 之外分发这些应用，Play Store 作为官方商店应该有更高的标准，尤其 Android 支持侧载和替代商店。 bongodongobob 和 ozim 认为像 PlayStation 和 Nintendo 这样的平台也不允许随意发布内容，作为 Google 的商店，只要允许侧载，就有权设定自己的标准，无需为“垃圾软件”降低门槛。brulard 质疑如何设定“足够好”的标准，认为允许质量差的应用存在可以帮助它们通过声誉发展。

kshri24 认为技术本应减少官僚主义，实现自动化，但大型科技公司反而将技术与官僚主义结合，使其永久化，并自动化了客户服务。dmix 和 kshri24 认为大型组织应对风险的惰性反应是增加规则和流程，导致官僚文化蔓延，影响客户体验。whimsicalism 和 kshri24 认为这些政策变化是对政府压力的回应。SupremumLimit 和 kshri24 认为技术本身就会使官僚主义更加僵化和 rigid，因为它强调标准化流程，减少人为干预。

serial_dev 表达了作为独立开发者和业余项目开发者对 Google Play 的失望，认为要求过多（如 DUNS，公开个人信息），收益低，且支持差，表示“不要在 Android 上浪费时间”已成共识。serial_dev 认为 Google 正在毁掉 Android 生态系统，只剩下大公司愿意忍受这些麻烦，并因此转向 iOS。serial_dev 作为 Flutter 开发者，对 Android 生态的衰退感到担忧，认为这会影响 Flutter 的发展前景，因 Flutter 在 Web 和 iOS 上的劣势。 throwaway743 和 serial_dev 对 Play Store 和 Admob 缺乏有效支持和解决问题的途径感到绝望，特别是 Admob 的联系方式多年未修复，认为 Google 毫不关心，希望它们倒闭。shakabrah 和 serial_dev 表示认同，并也在寻找从 Flutter 工作的出路。fidotron 和 serial_dev 猜测 Google 可能会尝试一些有趣的措施，比如在欧盟地区的 iOS 上发布 Play Store 应用，通过虚拟机运行。

阅读原文

我创办了Perfect Wiki，年收入达到25万美元，且没有投资者

作者: sochix | 发布时间: 2025-04-30 03:45:51

内容摘要

Perfect Wiki：一个利用利基市场实现25万美元年收入的成功案例

本文讲述了 Perfect Wiki 产品的创始人 Ilia 如何在没有外部投资的情况下白手起家，利用 Microsoft Teams 内置 Wiki 的痛点，开发了一款简单实用的知识库工具，并在五年内实现了25万美元的年收入。

故事始于2020年疫情期间，Ilia 失业后尝试在 Zoom 和 Microsoft Teams 商店发布应用。在 Zoom 市场流量不佳后，他转向了更为活跃的 Microsoft Teams 市场。通过分析用户反馈，他发现了用户对 Teams 内置 Wiki 的强烈不满，由此萌生了开发 Perfect Wiki 的想法。凭借对 Node.js 和 React 技术的熟练运用，Ilia 仅用三周就发布了第一版产品，并迅速通过“wiki”关键词在 Teams 市场获得了首个付费用户。他意识到解决真实痛点是成功的关键。

如今，Perfect Wiki 已被全球超过500家公司采用，主要市场集中在欧美国家，年收入稳定在25万美元。Perfect Wiki 的核心竞争力在于其与 Microsoft Teams 的深度整合以及对产品简单性的坚持。相比微软自家的复杂工具或缺乏深度集成的竞争对手，Perfect Wiki 提供了更便捷高效的工作流程。

令人惊讶的是，Perfect Wiki 的核心团队仅有两人：Ilia 负责开发和产品，另一位同事负责用户支持。团队依靠用户反馈和自身的产品使用经验来迭代和改进功能，确保每项新增功能都真正解决用户需求。例如，用户对长文档内搜索的需求促成了“页面内搜索”功能的开发。

Ilia 分享了他获得的经验：不要害怕进入利基市场，专注于解决特定问题。同时，保持产品的简单性至关重要，尤其对于小型团队而言。他最初设立的目标是年收入7-8万美元，目前的成就远超预期。未来，Perfect Wiki 计划扩展与 Slack、ChatGPT 等平台的集成，并持续优化用户体验。

讨论焦点

帖子热门评论主要围绕三个焦点：1. 对微软Teams的负面评价及开发者选择该平台的原因。评论者karel-3d表达了对Teams引发的恐惧和厌恶情绪，egecant将其描述为DaaS（Dread as a Service），daheza、seethishat、ctkhn、dowager_dan99和silisili等人详细列举了Teams在通信效率、功能集成、稳定性和用户体验方面的不足，认为其严重影响工作效率和公司文化。与之相对，DontchaKnowit和andyjohnson0对此表示困惑，认为Teams作为简单的日历和聊天工具尚可接受，bdangubic和aners_xyz、bongodongobob则认为负面评价可能源于使用习惯或管理不当。youniverse、sceadu、duxup、marcosdumay、probably_wrong、robocat、longitudinal93和karel-3d讨论了Teams受欢迎的原因（免费捆绑、微软的垄断地位）以及替代方案的可能性和可行性。cosiiine和duxup分享了因Teams导致的不愉快工作经历。unixhero和GoblinSlayer、karel-3d、codegeek和DontchaKnowit、jbm、bigstrat2003、barkerja则将Teams与Jira和Confluence等其他企业软件进行比较，认为Teams的体验更差，批评其功能缺陷和反人性的设计。开发者sochix则认为Teams的不足为创业者提供了改进空间。这些讨论体现了用户对Teams的普遍不满以及对其作为企业基础设施的无奈接受。2. HN网站内容投稿趋势的讨论。评论gadders怀念过去HN上更多关于个人创业成功故事的分享，认为现在AI和政治话题占据了太多版面。freetonik对此表示认同，认为AI相关内容泛滥。gadders随后补充他更乐于看到AI创业的成功故事。dmos62认为技术思考越来越多地涉及AI。catlikesshrimp则表示AI内容优于加密货币话题。-__---____-ZXyw认为HN内容要么是特朗普相关的政治话题，要么是AI话题。sochix以自己的帖子为例，认为大家仍喜爱成功故事，但gadders仍认为过去更多元化。YetAnotherNick的评论被标记，引发了关于高薪FAANG工作与个人创业自由及财务回报的讨论，bboygravity、0_____0、naughtyfinch、RandomWorker、jen729w、darkwater、gadders、cpach、apercu和maaaaattttt（引用寓言）对此展开辩论，涉及地理限制、财务自由、工作满意度等多个维度，体现了对不同职业道路价值的争议。cornholio则将成功故事视为大型平台“围墙花园”内的商品，AI则被一些人视为打破壁垒的契机，但pjc50对此表示怀疑。kryogen1c谦虚地认为自己是导致HN内容泛滥的参与者，引发了关于投稿价值的讨论，vintagedave、showerst、catlikesshrimp和kaonwarb回应鼓励其分享经验。deadbabe认为现在用专业技能谋生比过去更难，bredren通过具体的住房、票务等例子支持了这一观点。devsda和bredren认为政治和AI话题挤占了技术讨论，且认为这类成功故事投稿存在炒作和选择性偏差。3. 开发者选择Teams平台的原因及其他企业软件的比较。RandomWorker惊讶于Teams平台也能赚钱，sochix确认这是一个“隐藏的宝藏”。xyst认为任何有足够大市场的平台都可以赚钱，并提到了Slack插件。em-bee追问除了大公司平台还有哪些大的应用市场。Suppafly和mattmaroon讨论了Apple生态系统在除手机外的领域市场较小，而商业软件平台虽然市场较小但用户付费意愿更高，竞争也较少。naghing质疑帖子是否为广告，nlitened认为HN是为创造者提供的平台。Calwestjobs发表了离题的政治性评论，将产品与俄罗斯政府联系，表达了对俄罗斯的负面情绪，glowiefedposter则对其观点表示讽刺。此外，ThunderSizzle对Microsoft Teams、Windows 11、Azure DevOps、Visual Studio等微软产品表示不满，认为它们质量差且昂贵。sochix再次认为这为创业者提供了机会。doix认为Teams因捆绑在Microsoft 365中显得便宜，但隐藏成本是用户体验差，robertlagrant和wpietri则进一步指出这是微软通过捆绑形成并巩固垄断的策略。high_na_euv、ThunderSizzle和brooke2k对Visual Studio的评价出现分歧，ThunderSizzle认为Jetbrains Rider更好，brooke2k则认为Visual Studio很糟糕。

阅读原文

YouTube 的某人需要眼镜

作者: jaydenmilne | 发布时间: 2025-04-30 11:18:47

内容摘要

YouTube 新版首页设计引发不满：内容稀少与广告巨多

博主 Jayden 分享了其对 YouTube 新版首页设计的强烈不满。他在 32 英寸 1440p 显示器上打开 YouTube 后，发现首页只显示了极少的视频内容（5 个视频），却有一大块空间被巨型广告占据。他对比了 2019 年的 YouTube 首页截图，当时可以同时显示 30 个视频，且没有广告。博主认为新版设计是“令人憎恶的”，并且强烈希望这次 A/B 测试失败。

通过一个“高级分析包”进行预测，博主悲观地推测到 2026 年 5 月，YouTube 首页可能只剩一个视频，而到 9 月，首页将完全没有视频内容。他讽刺地预测届时人们可能需要通过脑机接口（如 NeuraLink）来接收算法直接注入大脑的实时生成内容和广告，以最大化多巴胺反应。博主表达了对 YouTube“把痛苦程度调到最高以换取金钱”的现状的怀念。

讨论焦点

主要讨论焦点围绕对YouTube Shorts的强烈不满以及对YouTube首页设计（特别是自动播放）的批评，并探讨了用户如何通过第三方工具和设置来改善用户体验，同时也有评论分析了YouTube做出这些改变背后的商业动机和市场竞争压力。

阅读原文

俄勒冈州立大学开源实验室未来堪忧

作者: aendruk | 发布时间: 2025-04-30 14:51:52

内容摘要

俄勒冈州立大学开源实验室OSL面临危机

俄勒冈州立大学开源实验室（OSL）正面临因企业捐款下降导致的严重财务危机，其未来岌岌可危。虽然过去俄勒冈州立大学工程学院曾弥补资金缺口，但近期大学预算调整导致学院资金大幅削减，OSL当前的资金模式已不可持续。实验室主任通知，如果不能在短时间内筹集到25万美元的承诺资金，OSL可能在今年晚些时候被迫关闭。

该25万美元主要用于支付员工工资（15万美元，占60%）、学生工资（6.5万美元，占26%）以及包括硬件、差旅和订阅服务等在内的其他日常开支（3.5万美元，占14%）。实验室主任正在积极寻求外部支持，并需要在2025年5月14日前向校方汇报资金进展。他呼吁任何能够提供帮助或联系潜在捐助者的人尽快通过 [email protected] 联系。

OSL在过去22年里，为全球超过500个免费和开源项目提供托管服务，并指导了130多名学生。其重要的历史贡献包括在早期为Mozilla Firefox提供托管服务，曾是Apache Software Foundation、Linux Foundation、Kernel.org等项目的所在地，以及提供快速可靠的软件镜像服务。目前，OSL为Drupal、Gentoo Linux、Debian、Fedora等众多项目提供基础设施托管，并为x86、aarch64和ppc64le架构提供虚拟机用于持续集成和其他托管服务。

除了眼前的资金困境，OSL还面临大学现有数据中心设施将被淘汰的长期问题。虽然OSL正积极寻找新的托管地点，但目前最迫切的需求是 securing additional funding 以确保实验室的生存。俄勒冈州立大学基金会是IRS 501(c)(3)非营利组织，捐款可能享受税收优惠。可以通过其捐款页面直接捐款。

实验室主任感谢大家一直以来的支持，并愿意回答任何疑问。同时，OSL也提供了具体的联系方式和地址。

讨论焦点

讨论焦点集中在OSU开源实验室面临资金困难的问题上，具体涵盖了预算分配的合理性（特别是对核心人员薪资的疑问）、大学捐赠基金是否能作为解决方案、以及对OSU开源实验室历史贡献和重要性的回顾与肯定。主要的争议点在于围绕核心人员15万美元年薪（占预算60%）能否在扣除福利、税费等成本后被视为过高，以及这笔资金的实际用途和人员职责是否仅限于系统管理。同时，讨论也涉及了大学捐赠基金的限制性用途和资金分配竞争。情感倾向方面，多数评论表达了对OSU开源实验室面临困境的担忧，对其在FOSS社区中的重要作用表示认可和赞赏，希望能找到解决方案使其得以延续。

阅读原文

Show HN: 使用 Google 表格创建自己的微调 AI 模型

作者: QueensGambit | 发布时间: 2025-04-30 11:53:36

内容摘要

使用 Google 表格微调 OpenAI 模型

这篇内容介绍了一个名为 Promptrepo 的工具，它使得用户能够利用存储在 Google 表格中的数据来微调（finetune）OpenAI 模型，创建自定义的 AI 模型。该工具的核心优势在于其易用性和准确性，特别强调通过 Google 表格这一熟悉且方便的平台来实现 AI 模型的构建。

该工具的主要功能包括：

1. 无代码 AI 模型构建：允许领域专家直接在 Google 表格中构建 AI 模型，无需编写代码。
2. 灵活的训练与部署：支持选择 OpenAI, Mistral, 或 LLaMA 等模型进行训练和部署，操作简便。
3. 便捷的模型评估：可以通过 Google 表格公式、直观的用户界面或 API 调用轻松测试模型性能。
4. 构建适用于多种任务的 AI 模型：可以创建分类、提取和生成等类型的微调模型，满足特定用例需求。
5. 集成 API：提供 API 接口，方便将 AI 模型无缝集成到应用程序、网站和工作流程中。
6. 内置版本控制：自动处理模型构建过程和版本控制，用户可以专注于提高模型准确性。

内容还提供了免费试用和安装 Google Workspace 插件的链接，并列出了 Promptrepo 旗下的其他产品，以及 Formfacade, Formesign 和 Neartail 等相关产品，展示了该提供商在 Google Forms 和相关功能扩展方面的多种解决方案，例如增强 Forms 的UI、嵌入、计分、文件上传、通知、电子签名、生成 PDF、工作流程、HIPAA 合规等等，以及用于餐饮订单和支付等领域的特定应用。

讨论焦点

讨论围绕Show HN项目展开，主要焦点包括项目本质的功能总结、与OpenAI现有功能的对比（尤其是Project和RAG的区别）、项目网站的技术连接问题、精调模型（Finetuning）与提示工程（Prompting）及RAG等方法的有效性对比及应用场景、以及项目在成本和现有生态整合方面的挑战与应对策略。

作者mogili指出该项目本质上是一个用户界面，用于自动化csv到jsonl的转换过程并对接精调服务。作者manidoraisamy（项目开发者）承认了这一点，但认为这就像Dropbox之于AWS S3，是一种有用的上层封装工具，并对其先前带有“冷嘲热讽”意味的评论表示歉意，强调希望分享一个有用的构建AI功能的工具。作者ivape评论了开发者向开发者展示项目所面临的问题，认为后者往往对技术实现过于挑剔，忽视了普通用户的需求，这种评论环境对开发者不友好。

作者labrador询问该项目与OpenAI项目（Project）的区别。作者manidoraisamy请求澄清具体指代。作者labrador解释其在OpenAI Pro中使用的Project功能，并进一步追问该项目是基于文档的精调还是RAG，以及二者的区别。这一讨论关注项目与OpenAI现有能力的差异及技术实现。

作者nbbaier报告访问项目网站链接https://promptrepo.com/finetune出现“ERR_CONNECTION_RESET”错误。作者manidoraisamy推测是来自HN的流量高峰所致，并询问是否已恢复。作者nbbaier确认问题依然存在，但认同是流量高峰原因，表示稍后再次尝试。这一分支单纯讨论了网站可用性问题。

作者Centigonal提出该项目面临的最大挑战是如何证明精调比提示工程、流程设计、RAG等更有效，认为目前许多客户通过后者就能获得显著改进，精调的应用场景相对较少。作者manidoraisamy同意这一观点，解释了Promptrepo如何从数据较少时的提示工程和固定格式生成方案过渡到随着数据积累进行精调，强调解决了“冷启动”问题，方便产品团队快速启动功能并逐步提高精度。作者polskibus询问是否有精调效果不如其他方法的具体实际案例。

作者rgbrgb认为虽然领域竞争激烈，但该项目的洞察和UI很好，指出应赋能非技术人员通过反馈改进模型。但他同时提出成本和现有生态整合是采用障碍，希望能直接使用现有平台（如OpenAI）的API Key和免费额度来分摊成本。作者manidoraisamy对此表示感谢，并指出其基础方案（Self managed plan）允许用户自带OpenAI账户，并提供了一个月免费试用。这些评论涉及项目在商业模式、用户群体和成本方面的考量和应对策略。

总的来说，讨论中存在对项目本质的定性（工具 vs 新技术）、与已有服务的对比和技术细节的探究、项目实际应用中的有效性边界和推广优先级、以及商业可行性（成本、集成）等多个维度的探讨。开发者积极参与，对质疑进行解释和回应，同时也承认了一些挑战并提供了解决方案或计划。情绪上，有肯定的评价，有技术性的质疑和探讨，也有用户层面的实际问题反馈。

阅读原文

DeepSeek-Prover-V2

作者: meetpateltech | 发布时间: 2025-04-30 12:23:28

内容摘要

DeepSeek-Prover-V2：基于强化学习的改进数学定理证明大模型

DeepSeek-Prover-V2是一个开源的大型语言模型，专注于在Lean 4形式化证明系统中进行定理证明。该模型利用了一种基于递归定理证明流程的冷启动训练方法，其中核心驱动力是DeepSeek-V3模型。通过引导DeepSeek-V3将复杂的数学问题分解为更小的子目标，并将已解决子目标的证明与DeepSeek-V3的逐步推理过程相结合，从而生成初步的训练数据。

进一步，项目专门构建了一个包含复杂问题的子集，这些问题尽管整体难以解决，但其分解后的子目标可以被一个较小的7B模型解决。将这些子目标的证明组合起来，并与DeepSeek-V3的非正式推理过程（引理分解）结合，生成了用于训练的合成冷启动数据。在这个冷启动基础上，模型通过强化学习阶段进一步优化性能，以二进制的正确/错误反馈作为奖励信号，增强了模型连接非正式推理与形式化证明的能力。

最终训练得到的DeepSeek-Prover-V2-671B模型在神经定理证明领域取得了先进的性能，在MiniF2F-test基准上达到88.9%的通过率，并在PutnamBench数据集中解决了658个问题中的49个。项目提供了DeepSeek-Prover-V2的证明解决方案压缩包供下载。

为了更全面地评估模型能力，项目还推出了ProverBench，这是一个包含325个形式化问题的基准测试集，其中包括来自AIME竞赛的数学问题以及精选的教科书和教育教程中的示例，涵盖了从高中到本科级别的多种数学领域。DeepSeek-Prover-V2提供了7B和671B两种模型大小的模型，并提供了ProverBench数据集的下载链接。用户可以使用Huggingface的Transformers库快速开始模型推理。

讨论焦点

阅读原文

Show HN: ART - 用于训练智能体的新型开源强化学习框架

作者: kcorbitt | 发布时间: 2025-04-30 11:35:00

内容摘要

ART：用于训练大型语言模型代理的强化学习库

OpenPipe ART（Agent Reinforcement Trainer）是一个开源的强化学习库，旨在提升大型语言模型（LLM）在代理工作流中的性能。ART 的核心优势在于其采用强大的 GRPO 强化学习算法，能够让模型从自身的经验中学习和改进。与许多其他强化学习库不同，ART 允许用户在其现有的代码库中执行代理运行，并将强化学习训练循环的复杂性卸载到 ART 后端，大大简化了集成和使用过程。

ART 的功能被划分为客户端和服务器两部分。客户端兼容 OpenAI API，负责 ART 与用户代码库的交互。用户可以通过客户端向 LLM 发送消息并获取补全结果，同时模型也在不断提升性能。服务器独立运行在任何配备 GPU 的机器上，它抽象处理了强化学习循环中的推理和训练过程的复杂性，同时也允许进行一些自定义配置。

整个训练循环概述如下：首先是推理阶段，用户代码通过 ART 客户端执行代理工作流（通常会并行执行多个 rollout 以加快数据收集）。补全请求会被路由到 ART 服务器，服务器使用 vLLM 运行模型的最新 LoRA。代理执行过程中产生的每条 system、user 和 assistant 消息都会被存储在 Trajectory 中。当一个 rollout 完成后，用户代码会为该 Trajectory 分配一个奖励值，用以指示 LLM 的表现。接着是训练阶段，当所有 rollout 完成后，Trajectory 会被分组发送到服务器。服务器会使用 GRPO 算法对模型进行训练，训练过程会从最新的检查点（或者第一次迭代时使用空的 LoRA）开始。训练完成后，服务器会将新训练的 LoRA 保存到本地目录并加载到 vLLM 中。此时，推理阶段会被解除阻塞，训练循环继续从第一步开始。这个循环会持续进行，直到达到指定数量的推理和训练迭代次数。

ART 支持大多数与 vLLM/HuggingFace-transformers 兼容的因果语言模型，特别是那些受 Unsloth 支持的模型。目前 Gemma 3 似乎不受支持。

ART 目前处于早期开发（alpha）阶段，已经在少量项目中进行了测试。尽管积极开发中并欢迎贡献，开发者也提示用户在使用过程中可能会遇到问题，并鼓励通过 Discord 或 GitHub 提交 issue。

项目的成功离不开许多开源项目的贡献，其中包括 Unsloth、vLLM、trl 和 SkyPilot 等。ART 的目标是提供一种高效且易于使用的方式来训练大型语言模型代理，使其能够在各种任务中表现出色。

讨论焦点

主要讨论焦点是如何区分RL训练与微调（SFT），RL相对于SFT的优势及适用场景，以及对ART框架的具体特性（如API文档）的提问。

评论分支 1中，作者someguy101010询问RL训练与微调的区别以及何时选择RL而非微调。作者kcorbitt详细解释了SFT通过提供输入/输出对进行训练，而RL则通过最大化奖励函数进行训练，通过检查模型输出是否达到预期来打分。kcorbitt以数学问题求解和邮件代理为例说明了RL的优势在于其更容易验证结果而非直接生成正确流程。someguy101010对kcorbitt的详细解释表示感谢，确认了理解。这个讨论清晰地界定了两种训练方法的根本差异和适用场景。

评论分支 2中，作者tcdent称赞ART概念，并询问/train_model端点的API文档。作者bradhilton回复称目前还没有稳定的HTTP API文档，因为接口还在变化，但他简要介绍了该端点会返回一个包含梯度步骤的流式JSON对象，客户端可以监控训练进度，并提及未来可能会提供非流式或轮询选项。这个讨论是关于ART框架的具体技术细节和文档可用性。

评论分支 3中，作者kcorbitt主动分享了使用ART训练邮件研究代理的成功案例，强调了RL的潜力。

评论分支 4中，作者bradhilton作为贡献者介绍了ART库的核心理念，即提供一个易于使用的OpenAI API兼容端点，使用户可以在推理后通过自定义奖励函数方便地微调模型，强调了其灵活性。

评论分支 5中，作者jeffchuber称赞了帖子中用于比较不同模型的表格展示方式。

总的来说，讨论围绕ART框架展开，从宏观的RL与SFT对比，到具体的API细节，再到框架优势和实际应用案例。主要的共识是ART通过RL提供了一种灵活的模型训练方式，尤其适用于结果易于验证但过程难以直接指定的场景。没有明显的争议点，更多是用户提问和开发者解答，情感倾向偏向积极和感兴趣。

阅读原文

2025年初纽约市房价上涨10%

作者: geox | 发布时间: 2025-04-30 15:43:55

内容摘要

Raven：赋予 OCaml 机器学习之翼

Raven 是一个雄心勃勃的项目，旨在为 OCaml 编程语言构建一个全面且高性能的机器学习和数据科学生态系统。项目的核心愿景是结合 OCaml 的类型安全和性能优势，提供类似 Python 生态系统中 NumPy、Matplotlib、Jupyter 和 JAX 等工具的强大功能。

该项目目前处于早期开发阶段（pre-alpha），积极寻求用户反馈。其生态系统由多个关键子项目组成：

• Ndarray： Raven 的核心，提供高性能多维数组计算，并支持 CPU 和 GPU，类似于 NumPy。
  • Ndarray-CV： 基于 Ndarray 的计算机视觉工具集。
  • Ndarray-IO： 用于读写 Ndarray 数据。
  • Ndarray-Datasets： 提供常见机器学习数据集的访问接口。
• Quill： 交互式笔记应用，类似于 Jupyter，用于数据探索和原型设计。
• Hugin： 用于生成高质量绘图和图表的可视化库。
• Rune： 自动微分和 JIT 编译库，灵感来源于 JAX。该部分仍在概念验证阶段。

Raven 正在努力对标 Python 生态系统中的流行工具，并提供了与 Python 对应库（如 NumPy 和 Matplotlib）的比较指南和示例。虽然像 Pandas（数据框处理）和 PyTorch/TensorFlow（深度学习）这样的功能尚未包含在内，但 Raven 明确表示未来会持续发展并添加更多库和工具。

项目采用 ISC 许可，允许个人和商业用途，并欢迎社区贡献，包括报告问题、提出功能请求以及提交代码改进、文档或示例。代码库主要由 OCaml、C++ 和 C 组成。

讨论焦点

阅读原文

OCaml 为机器学习插上翅膀

作者: musha68k | 发布时间: 2025-04-30 08:31:47

内容摘要

家庭洗衣机在去除纺织品上的重要病原体方面效果不佳

一项最新研究表明，医护人员在家清洗制服可能会助长医院内抗生素耐药性感染的传播。该研究由德蒙福特大学的 Katie Laird 领导，发表在《PLOS One》杂志上。

医院获得性感染是重要的公共卫生问题，部分原因在于它们常常涉及抗生素耐药细菌。许多护士和医护人员使用标准家用洗衣机清洁制服，但一些研究发现细菌可以通过衣物传播，这引发了家用洗衣机能否有效阻止危险微生物传播的疑问。

这项新研究评估了六种家用洗衣机能否成功清洁受污染的医护人员制服。研究人员在热水中使用快速或标准洗涤模式清洗了受污染的织物样本。结果显示，半数洗衣机在快速洗涤模式下未能消毒衣物，而三分之一在标准洗涤模式下也未充分清洁。

研究团队还对12台洗衣机内部的生物膜进行了采样。DNA测序发现了潜在的致病菌以及抗生素耐药基因。调查还显示，细菌可以对家用洗涤剂产生耐药性，这也增加了它们对某些抗生素的耐药性。

综合这些发现，研究表明许多家用洗衣机可能不足以清洁医护人员的制服，并可能助长医院获得性感染和抗生素耐药性的传播。研究人员建议，应对医护人员的衣物洗涤指南进行修订，以确保家用洗衣机能够有效清洁。或者，医疗机构可以考虑在院内使用工业洗衣机清洗制服，以提高患者安全并控制抗生素耐药病原体的传播。

作者补充道：“我们的研究表明，家用洗衣机通常无法完全消毒纺织品，导致抗生素耐药细菌得以存活。如果我们要认真对待通过纺织品传播传染病和解决抗菌素耐药性问题，就必须重新思考如何洗涤医护人员穿着的衣物。”

更多信息: Caroline Cayrou et al, Domestic laundering of healthcare textiles: Disinfection efficacy and risks of antibiotic resistance transmission, PLOS One (2025). DOI: 10.1371/journal.pone.0321467

讨论焦点

以下是对热门评论及其嵌套回复的分析：

讨论焦点主要集中在：

OCaml作为机器学习语言的潜力与当前挑战。 与其他语言（Haskell, Elixir, Go, F#, Python）在特定应用场景下的对比。 机器学习开发工具（特别是Notebooks）的优缺点。

讨论分支 1: 根评论作者behnamoh对OCaml表示惊讶，认为它成熟且社区热情，但个人更偏向Haskell和Elixir。 回复作者giraffe_lady比较OCaml和Go，认为OCaml像Go一样粗糙但代码库稳定且易于维护。她认为Elixir和Ocaml用于截然不同的场景，不具可比性，Elixir适合发挥BEAM的优势问题。 作者noelwelsh回复giraffe_lady，认为OCaml未流行的原因在于其语法未能普及以及多核支持的长期滞后，如果早期有多核支持，编程语言格局可能不同。这个回复确认了OCaml发展上的不足之处。

讨论分支 2: 根评论作者tools live表达对Notebook应用的不喜，偏好IPython等REPL方式进行交互式开发，认为能在喜爱编辑器中写代码更好。 回复作者neonsunset表示同感，更倾向于F#的.fsx脚本配合Plotly.NET和并行处理进行开发。作者bb1234也表达了对Notebook的不喜欢，但很难明确说出原因，他提到Notebook有时状态不稳定，需要重启内核才能得到正确结果，最后还是偏好IPython REPL。作者sahilagarwal回复bb1234，从怀旧角度解释了对REPL的喜爱，认为早期学习ipython和ipdb（调试器）的努力培养了更好的编程习惯，而Notebooks可能会减少这些学习机会，长远来看不利于程序员的成长，存在争议。作者nathan_compton表示完全不喜欢Notebook，认为它导致代码质量差，交互式开发不如REPL，不理解大家喜欢的原因。作者pletnes回复nathan_compton，认为IDE适合生产代码，而Notebooks更适合通过可视化和统计理解数据，不是“非此即彼”的关系，还提到了Linqpad等其他数据驱动环境，对nathan_compton的观点进行了部分反驳并提供了替代视角。作者patagurbon回复nathan_compton，认为Notebooks非常适合教学，但实际工作不适合，部分同意nathan_compton的观点。作者nsingh2回复nathan_compton，描述了一种将Notebooks作为轻量级前端的工作流程，探索问题和编写函数，但尽快将核心逻辑重构到单独模块，避免Notebook臃肿和状态问题，提供了一种折衷的使用方法。作者TJSomething反驳了REPL的不足，认为REPL瞬时性太强，而Notebooks可以保存状态，方便回顾和迭代中途步骤。作者abathologist列举了OCaml已有的REPL工具（utop, down, ocaml top-level），回答了根评论关于OCaml REPL的问题。

讨论分支 3: 根评论作者FrustratedMonky询问是否有人使用F#做机器学习，认为F#可能比OCaml有更好的ML生态，同时具备OCaml的功能。 回复作者greener_grass列举了F#在机器学习领域的一些项目链接（TorchSharp, DiffSharp, Furnace, Plotly.NET），确认了F#在ML生态中有一些进展。作者rybosome分享了自己用F#重写Python代理推理框架的想法，认为F#在表达同样想法时比Haskell等语言更优雅简洁，是一种积极的观点。作者nickpeterson回复rybosome，表示F#不流行很遗憾，认为它是快速高效开发的好语言/运行时组合，确认并支持了rybosome的观点。作者nextos提到F#绑定了微软研究院的Infer.NET库，该库在特定概率模型和实时推理方面非常成熟和强大，从特定领域支持角度进一步肯定了F#的ML生态。作者StopDisinfo910认为F#是.NET生态的好语言，但认为它基本是去掉了OCaml有趣特性（参数化模块）的OCaml，对F#相对于OCaml的优势提出了质疑，存在争议。

讨论分支 4: 根评论作者cube2222对OCaml在ML/DL领域取代Python表示不抱希望，但认为OCaml是可爱的语言，可惜不流行。这表达了一种略带悲观的期待。 作者lawnchair的回复“Terrateam is hiring”与帖子主题关联不大，更像是一则招聘信息，未形成有效讨论。

讨论分支 5: 根评论作者evacchi对帖子标题“ML in ML”表示欣慰，认为终于有人将机器学习（Machine Learning）应用于元语言（Meta Language）或形式化方法中，这是一种积极的看法。

阅读原文

家用洗衣机无法清除织物上的重要病原体

作者: bookmtn | 发布时间: 2025-04-30 18:04:41

内容摘要

深入理解并限制字符串长度的复杂性及最佳实践

这篇博文深入探讨了限制字符串长度这一看似简单但实则复杂的问题。作者首先指出，不同的编程语言和框架衡量字符串长度的方式差异巨大，主要有基于UTF-8字节、UTF-16代码单元、Unicode码点和字形簇（Grapheme cluster）四种计数方法。每种方法都有其优缺点，并且可能导致在不同系统或组件之间出现长度不一致的问题，进而引发 bug、用户体验差甚至安全漏洞。

文章详细解释了Unicode、码点、UTF-8、UTF-16以及字形簇等核心概念，并通过具体示例展示了不同计数方法在面对复杂字符（如汉字、表情符号、组合字符等）时的差异。作者强调，开发者需要清晰地理解所使用的语言如何处理字符串及其长度测量，并有意识地选择一种一致的计数方法应用于架构的各个层面。

在探讨如何限制字符串长度时，作者分析了各种方法的适用性：

• 基于字形簇的计数最符合人类的“字符”概念，但由于字形簇可以由无限数量的码点组成（如Zalgo文本），无法有效限制字符串的存储大小或处理成本，且实现和维护较复杂。

• 基于UTF-16代码单元的计数在某些前端环境普遍，但同样可能由于截断导致字符损坏，且在UTF-8占主导地位的序列化和存储场景下使用，增加了转换开销。

• 基于UTF-8字节的计数能够有效限制大小，但对于非英语字符，计数会变得不直观且难以预测，不适合用户可见的限制。

• 基于Unicode码点的计数被认为是目前相对最佳的实践，Google API设计指南也推荐这种方法。它在基本多文种平面（BMP）内的字符以及许多表情符号上都能得到1的计数，比UTF-16和UTF-8更具一致性。但它仍然无法完全解决多码点字形簇的问题。

文章还提出了“混合计数”的设想，即结合字形簇和码点限制，以期在用户体验和后端大小限制之间取得平衡，但这并非标准方法，实现和推广难度较大。

最后，作者总结认为，尽管没有绝对完美的解决方案，但基于Unicode码点（最好结合规范化）的计数是目前最务实和推荐的方法，尤其适用于 API 设计和用户界面限制。文章还就Unicode版本、字符规范化、编码错误处理及性能开销等相关问题进行了讨论，强调了理解底层原理的重要性，以避免潜在的问题。

讨论焦点

主要讨论焦点集中在医疗工作者是否应自行清洗制服以及家庭洗衣机对病原体的去除能力。其他评论提及了能效与除菌效果的权衡、延长洗涤周期以及高温洗涤的可能性和具体参数。

阅读原文

限制字符串长度的最佳（但并非最优）方法

作者: adam-p | 发布时间: 2025-04-30 16:37:49

内容摘要

Hacker News 数据全量下载与分析实践

这篇博文的作者分享了他如何下载 Hacker News (HN) 网站的全部历史数据，并使用 DuckDB 数据库进行分析的经验。文章首先介绍了他为构建一个 HN 相关项目而开发的 HN API 客户端，并利用该客户端实现了全量下载功能。通过简单的命令行工具，他成功获取了一个包含 HN 所有历史数据的 20 GiB JSON 文件。

接着，作者展示了如何使用 DuckDB 这个快速的嵌入式分析数据库来查询和分析这份海量数据。他导入了 JSON 文件，并利用 DuckDB 强大的 SQL 查询能力进行了初步分析，例如统计特定词语在 HN 上出现的次数。进一步地，他通过 SQL 语句计算了 HN 评论和文章中提及不同编程语言（如 Python, JavaScript, Java, Ruby, Rust）的比例随时间变化的 12 周移动平均值，展示了 DuckDB 在处理大规模数据时的便捷性和效率。

最后，作者幽默地提到了下一步的潜在方向，例如利用这些数据训练 LLM 机器人，但也表示就此项目而言已达成目的。文章的核心在于分享一个将大量公开数据进行本地化下载、存储和分析的实际案例，并推广了 DuckDB 在此类任务中的实用性。

讨论焦点

主要的讨论焦点集中在技术文章标题的准确性以及对处理字符串编码问题的个人极端化戏谑性解决方案。评论adam-p与dang之间的互动围绕着标题的修正请求和实施。adam-p指出原文标题应为“The best – but not good – way to limit string length”，dang确认并表示已修改。这展示了一个直接的、围绕事实核查和修正的讨论。neuroelectron的评论“This is why my website is going to be ASCII only.”是一种基于文章可能探讨的非ASCII字符集带来的复杂性而得出的讽刺或极端化观点，表达了对处理复杂字符编码的厌倦，并戏谑性地提出退回仅支持ASCII的简化方案，尽管这并非一个实际可行的现代网站策略。这两个讨论分支性质不同，一个关注精确性，另一个则带有幽默和对技术挑战的夸张反应。讨论中没有明显分歧或争议点，更多是直接的互动和个人观点的表达，情感倾向在前一个案例是寻求准确性，后一个案例是带有或无奈或戏谑的情绪表达。

阅读原文