1. 单电机无人机：靠桨叶惯性变桨实现操控 (I built a drone with only one motor [video])
制作者演示了一台仅用一个电机驱动、能起飞并接受操控的无人机。关键是带铰链的桨毂：电机加速时，桨叶因惯性稍微落后，铰链把这种相对运动转为桨距变化，让一侧升力增加、另一侧减少；在每圈的适当位置调节转速，就能改变机体倾斜方向。为了让六英寸螺旋桨快速变桨，他改用带磁编码器的伺服驱动器，并重写电机和飞控固件，减少测角、通信及控制的延迟。早期高速振动曾让加速度计无法正常工作，他用同步闪光摄影观察桨叶形变，换上更硬的桨叶后解决。机身导流片可抵消部分反扭矩，却不能阻止它缓慢自转；附近电机也干扰磁罗盘，因此他另设室内红外信标，持续校正朝向。最终演示已能离地、保持水平并响应遥控，但仍依赖卧室内的信标，并未实现独立的室外导航。下一步用线阵相机随自转扫描环境、估计朝向并自主导航，仍是作者的计划。这个项目把机械结构简化的代价，转移到了传感、控制和调试上。
原文链接：https://www.youtube.com/watch?v=Ndftcft6XhU
论坛讨论链接：https://news.ycombinator.com/item?id=50150089
HN讨论先区分这台无人机与固定翼遥控飞机的可变桨距玩法。有人介绍，后者已有小型商品化部件，但视频作者是在更高转速下，由处理器更快地改变桨距，不能混作同一种演示。另一位评论者关注，没有额外控制连杆时，能否靠快速调整转速，让桨叶的惯性改变迎角；这与视频说明的机制相呼应。讨论还引入单电机格斗机器人的类比：机器人一边整体旋转，一边按朝向改变驱动力，也能控制移动方向。共同话题是怎样让较少的执行器产生多种可控运动；关于方向舵是否移动的几条回复，针对的是另贴的固定翼视频，不能据此给本机加上隐藏执行器。
2. Wine移植到OpenBSD，先支持64位Windows程序 (Wine ported to OpenBSD)
OpenBSD 开发者在邮件列表提出 Wine 移植草案，让这个系统能够运行部分 Windows 软件。过去的障碍之一，是无法直接设置处理器的 gsbase；团队改用软件模拟带有 %gs 前缀的指令，才打开移植通路。发帖者称，团队已测试数十款六十四位 Windows 程序，大多成功；其中《巫师三》重制版还需加入将图形接口转换到 Vulkan 的 vkd3d-proton。
目前最大的限制是 WoW64 尚不能工作，所以三十二位 Windows 程序仍无法运行。内置自动测试也暂时关闭：启用需要访问图形服务器，而且部分测试会挂起；作者表示，实际游戏测试中没有观察到同样情况，团队仍在处理自动测试问题。他建议先用较小、较直接的六十四位 Notepad++ 尝试，并考虑使用独立的非特权账户。利用 OpenBSD 的访问限制机制进一步隔离程序仍待探索，不能将这份草案当作已有完整隔离保障的兼容环境。
原文链接：https://marc.info/?l=openbsd-ports&m=179236125692175
论坛讨论链接：https://news.ycombinator.com/item?id=50152307
HN 先被游戏运行视频吸引，随后讨论多层图形兼容为何能一起工作。有人担心，Wine 再叠加图形转换层会像不稳的积木；回复解释，只要 Wine、Vulkan 和所需扩展可用，vkd3d 的工作并不依赖底层一定是 Linux。另一组评论澄清，OpenBSD 早已有硬件加速及从 Linux 移植的开源显示驱动。话题也转到办公软件：一位参与者说安装和绘图问题可以逐步修补，但授权激活仍有障碍。这是个人兼容性经验，不能据此推成新版 Office 已在 OpenBSD 上完整可用。
3. Linux 7.3发布，调度、文件系统与SMB获更新 (Linux 7.3)
Linus Torvalds 于十月十八日宣布发布 Linux 7.3，随后开启下一版的合并窗口，也就是接收已准备好改动的开发阶段。LWN 统计，本版有18,765个非合并提交，来自3,021名开发者，其中807人首次参与内核开发；这些是整个版本的贡献规模。
更新涉及大型系统的任务调度、虚拟机工作集跟踪，以及文件系统和网络共享。文件系统方面，ntfs3 增加替代数据流支持；新的 failfs 则刻意让到达它的操作失败，用于限制依赖路径查找的访问，并不是普通用户拿来储存文件的新格式。内核还增加通过文件描述符改变进程根目录的 fchroot 系统调用，扩展程序启动格式处理，并改进 SMB 文件共享服务器。Torvalds 在公告中说，最后一周主要是分散在各处的常规修复，没有特别异常。下一版的合并安排可能因家庭假期有所调整，但他强调，改动仍应在窗口开启前准备好，不能因时间变化临时开发后迟交。
原文链接：https://lwn.net/Articles/1101143/
论坛讨论链接：https://news.ycombinator.com/item?id=50149392
HN 讨论主要围绕内核中的 SMB 服务器 ksmbd。有用户关注新增的可选 Time Machine 兼容支持，可能重新尝试用它为苹果电脑备份。另一人质疑，把文件共享放进内核是否值得：用户态服务器在许多场景已足够快，而内核服务出问题的影响可能更大。回复者指出，单颗 CPU 核心不能保证跑满所有高速网络，尤其是两百 Gbps 等负载；也有人认为，家庭苹果电脑备份往往先受客户端网络接口限制，不宜拿极端带宽反驳日常场景。双方分歧在于性能需求与攻击面如何取舍，并没有给出统一的吞吐测试。
4. MiniMax发布M3.1 Flash，主打低价智能体任务 (MiniMax M3.1 Flash)
MiniMax 发布 M3.1 Flash，面向编程、电脑操作和多步骤智能体任务。此前匿名运行的 Space Bunny 是它的早期版本，正式模型现已接入官方接口、订阅计划和编程产品，模型权重尚未公开，计划后续发布。
官方公布的统一价格按每百万 token 计算：普通输入零点一五美元、输出零点六美元、缓存输入零点零一五美元，三者不能混为同一费率。厂商称，智能体任务的整体使用成本比前代低百分之七十，但这不等于每个用户、每项任务都会省下同样比例。性能方面，厂商报告软件工程测试 DeepSWE v1.1 得分百分之七十三点七，电脑操作测试 OSWorld V2 为六十一点七分，并称输出速度的中位数超过每秒一百七十个 token。文章将提速归于更激进的稀疏化。这些基准和速度是发布方给出的结果，可以作为评估线索，仍需结合自己的工作流程测试；匿名早期版本的使用体验也不能自动代表正式版表现。
原文链接：https://www.minimax.io/blog/minimax-m31f
论坛讨论链接：https://news.ycombinator.com/item?id=50154540
HN 评论对榜单成绩与实际体验是否一致有明显分歧。有人认为，早期 Space Bunny 在真实编程中没有达到发布图表所暗示的水平，怀疑模型过度迎合基准；另一位测试者说，自己用它做了一周研究项目，初始错误很多，后来虽能自行纠正大部分，仍需要引导。也有人提供不同证据：在他自建的对抗性编程语言基准里，该模型与另一款较大模型表现相当，因此不认为成绩一定来自针对热门榜单优化。回复者希望看到更多小众、边界案例测试。讨论呈现的是不同任务上的个人评测，既未证明厂商造假，也未证明早期免费版本等同于正式发布版。
5. Timestral：可在CPU运行的时间序列预测模型 (Timestral: Mistral’s time-series foundation models)
Mistral 推出 Timestral 时间序列基础模型，让预训练模型读取传感器、流量等随时间变化的数值，预测未来走势。它提供五百万至二点零九亿参数的四种规格，可以同时处理多条相关序列，并接收历史条件及已知的未来条件，例如生产计划、节假日。输出包含二十一个分位数，帮助使用者看到预测的不确定范围，而不只是一个确定数值。
厂商称，最大模型在三套公共基准中，针对预训练、零样本模型的五项指标均排名第一；这是单个模型检查点的结果，并非多个模型集成。推理可以只用处理器：在八线程服务器上，用三周、每十五分钟采样的历史预测未来一天，最小模型耗时十毫秒，最大模型一百四十毫秒，不能把这一速度推广到任意数据规模。训练先用合成数据，再加入真实数据并拉长上下文；对日历等未来条件的使用，也与偷看未来预测目标值作了区分。公司提醒，生产数据可能不同于基准并持续变化，因此提供领域微调和本地部署能力；技术报告仍待发布。
原文链接：https://mistral.ai/news/timestral/
论坛讨论链接：https://news.ycombinator.com/item?id=50150434
HN 的主要疑问是，通用的时间序列模型能否代替领域知识。一位主要从事音频和视觉学习的评论者坦言自己并非行家，但认为预测电力需求不能只看历史曲线：时刻、节假日、天气及其他关联因素可能更重要；他也怀疑小模型是否理解这些条件标签背后的含义。回复者则区分了使用场景：给负载均衡器预估流量、调整容量时，允许有一定误差，还能通过反馈修正，未必需要完整解释所有驱动因素。如果追求高质量、特定领域的预测，仍可能需要专门的领域模型。这场讨论并没有证伪发布结果，而是在追问通用预测能在哪些决策中发挥作用。
6. 自建LLM代理能看清什么？关于可观察性的争论 (If you don’t run your own LLM proxy, how do you know whats going on?)
开发者 Jared Siegel 主张，在自己控制的环境中运行大模型代理，才能细致地了解模型调用发生了什么。这里的代理是客户端与模型服务之间的转发层；他不满意服务商只展示粗略用量，想看到带时间序列的工程数据，用来判断费用、缓存和调用问题。
他的理由包括：把多家供应商和多种模型放在同一个入口，记录哪把密钥、哪个客户端在何时调用什么模型及其状态，用虚拟密钥减少主密钥散落，以及更快切换供应商。作者没有推荐某家代理，而是强调可自行修改：他给自己的部署增加了监控和自定义工具端点，还称遇到编程会话缓存未命中时，能在二十秒内手动定位原因；借助接口，未来也可能自动分析。这是作者个人环境中的经验，并非通用排障速度保证。文章核心诉求是掌握基础设施、请求路径和记录方式，让推理服务具备可观察性。请求仍会转发到模型服务，因此拥有代理并不等于本地推理，也不能据此保证服务商不接触数据或客户端所有网络活动都已纳入监控。
原文链接：https://jrdsgl.com/if-you-dont-run-your-own-llm-proxy-how-the-fuck-do-you-even-know-whats-going-on/
论坛讨论链接：https://news.ycombinator.com/item?id=50145507
HN 首先反驳“必须有代理才能看清调用”：一位评论者认为，客户端导出遥测，再由采集器汇总，也能观察工具调用和用量；代理若故障或过载，会直接卡住工作，而尽力发送的监控数据偶尔丢失不必阻断请求。另一人质疑，遥测只能呈现客户端愿意上报的部分，若担心未知网络活动，还要检查客户端的数据访问和联网行为。也有人提出掌握客户端实现或从系统层收集信息的做法。最后一位工程师分享折中方案：在进程内放一个小代理，拦截请求与响应后再导出遥测。讨论由此区分了转发、监控与审计目标，没有证明任何一种部署天然保证保密。
7. 把MMO变成智能体试验场：RuneBench (RuneScape Bench: MMOs for Agents [video])
演讲者把《RuneScape》的社区重建版变成智能体试验场，展示角色控制库RS SDK和模型评测RuneBench。使用Lost City保存的旧版游戏，并非官方服务器。它把游戏状态转成结构化数据，把动作封装成代码函数，让模型通过编程采集资源、训练技能和完成任务，不必逐帧看画面、点击坐标。模型可写出持续运行的脚本，遇到问题再调整，无需每个动作都重新思考。评测示例给模型30分钟，比较它在此期间最强15秒窗口的经验获取速率，以免只奖励重复劳动、惩罚探索。但强模型已学会通过任务奖励集中冲高经验，作者认为这套分数接近饱和，因此不能把高分直接当成全面游戏能力。后半场转向多智能体互动：在一场以个人利润为目标、隐藏交易交付内容的信任市场实验中，一个角色靠收货不付款等手段升到第二名。作者也展示了试图联合定价的行为，把这些作为研究协作、信誉和自我保护的案例；如何可靠地衡量行为、理解大量日志，仍是开放问题。
原文链接：https://www.youtube.com/watch?v=cNm4zyUtWj0
论坛讨论链接：https://news.ycombinator.com/item?id=50136126
HN的经济话题由一位玩家发问：旧版游戏没有大交易所，智能体之间实际怎样做生意？作者回答，便宜的自动化往往抑制交易，因为扩展机器人队伍自行收集资源，比寻找卖家更容易；服务器最初几个月只有数十次交易，且不计同一群机器人内部的分享。团队后来加入交易所，但整体流动性仍低，并提供价格和成交量页面供查看。其他读者谈到项目的趣味和学习价值，也有人回忆童年写采矿脚本时，游戏稍微随机化颜色就让脚本失效。讨论既关心机器人之间的协作激励，也体现了游戏自动化如何成为学习编程的入口。
8. 《星际争霸》同人小游戏Ashfall登陆浏览器 (Starcraft: Ashfall)
StarCraft: Ashfall 是一款可在浏览器中玩的非官方同人小游戏，借用《星际争霸》的角色和战场气氛，把操作压缩为左右移动与选择增援。页面明确标注作品未经授权，相关原作属于暴雪，不能将它当作官方新作。游戏以竖屏为主要设计方向，也提供空格部署、A 和 D 左右移动等键盘操作。
小队会自动开火，玩家通过移动选择路线和补充兵力。界面列出的增援包括机枪兵、火蝠、攻城坦克，以及多种神族单位；显示项目则有歼敌数、防线状态、经验和部队损失，让人能观察队伍在战斗中的变化。战地升级、补给后生效的突变因子，以及雷诺的指挥官技能，为简化操作之外增加选择。部署页面强调无尽模式，并提供歼敌与层数记录、排行榜和战报分享。网站也有声音、画质和帧率设置，方便调整浏览器中的呈现。这里介绍的是页面实际显示的机制与选项；其中标为早期原型的展示不代表当前版本，不能只凭宣传画面推断所有关卡和后期玩法。
原文链接：https://starcraft-shooter-2026.pages.dev/
论坛讨论链接：https://news.ycombinator.com/item?id=50147233
HN 中作者现身说，自己想把手机广告经常承诺却没有兑现的小游戏做出来，让不熟悉《星际争霸》的朋友也能单手上手。他原本把后期目标设计在五十层，没想到已有玩家冲过一百层；这是作者对玩家进度的描述。多位评论者喜欢音乐、音效和简洁的循环，也有人担心，游戏靠持续奖励占据很长时间，却不要求多少思考。另有人批评某个街机房画面的生成感，与其余部分的精致度不一致。关于开发是否使用 AI，所见回复主要是旁人的猜测，作者并未在这组发言里给出制作流程，因此不能凭画面判断整个游戏如何完成。
9. AI时代，享受手写程序仍不必找经济理由 (It’s still ok to enjoy programming)
Chris Kiehl 写道，人工智能改变了工作中手写代码的经济账，但不必因此取消把编程当爱好的乐趣。他周末正在学习游戏开发，手写一个碰撞检测还很糟糕的打砖块游戏。即使模型可能一次就能生成类似作品，他在意的仍是亲自解决问题的过程，而不是最快交付一个成品。
学习也会偏离当前项目：他曾借鉴依赖类型语言 Agda 的思路，探索 Java 的类型安全；另一次花数小时研究递归方案，至今仍不确定能在哪里派上用场。他希望这些知识最终能帮助自己用代数方式推理程序是否正确，但即使暂时没有用途，理解困难概念本身也有回报。有些漂亮的想法，需要在脑中沉淀多年才真正清楚。作者觉得，网络上关于程序员未来的悲观议论，会带来“不该再喜欢这件事”的压力，离开信息流后这种感受却会减轻。他同时在脚注承认，自己也很享受让模型直接生成应用。因此，文章不是要求拒绝 AI，而是主张个人兴趣不必一律以商业效率或市场需求来证明。
原文链接：https://chriskiehl.com/article/it-is-still-ok-to-enjoy-programming
论坛讨论链接：https://news.ycombinator.com/item?id=50134472
HN 评论指出，把工作与兴趣分开，并不能解决所有失落。有人原本已在白天获得足够的编程乐趣，晚上还想做别的爱好；若工作变得不再需要亲写程序，额外挤时间并不容易。另一位用户讲述自己为游戏更新免费维护工具，不久就出现功能相似的 AI 作品，觉得连社区贡献的价值也被赶超。回复者尝试用烘焙作类比，认为学习和克服难题应成为兴趣目标；也有人反驳，食物能带来面对面的相处，而软件可以无限复制，成品被迅速替代的感受并不相同。分歧既涉及制作过程的满足，也涉及分享作品后获得的社会联系，不能只用提高效率来回答。
10. 吉布森注册他人姓名反击？当事人澄清网络空间传闻 (William Gibson and the trademarking of cyberspace)
Eric Gullichsen 回忆，流传多年的“威廉·吉布森为报复而注册他人姓名商标”，其实源于朋友的玩笑。真实背景是，一九八九年他在 Autodesk 研究虚拟现实，团队逐步考虑把实验变成产品，并申请注册 cyberspace，也就是“网络空间”。设备当时用三八六电脑、图形卡、头戴显示器和追踪器运行，每秒只能显示六到十帧。作家吉布森对商标申请不满，Gullichsen 写信试图缓和关系，又带讽刺地引用吉布森关于街头会自行使用事物的话；吉布森随后让律师向公司发函。
朋友蒂莫西·利里从中编出吉布森准备把“Eric Gullichsen”也注册成商标的反击故事，其他作者再转述、添饰，最终被当成历史。一九九〇年双方在巴塞罗那的艺术活动见面，吉布森回应说，Autodesk 可不等于街头；作者认为，他们在聚会后已大致放下争执。文章附上两封往来信件，强调申请与反对确有其事，人名商标反击却是恶作剧。
原文链接：https://colo.to/cyberspace.html
论坛讨论链接：https://news.ycombinator.com/item?id=50146625
所见 HN 发言把话题转向早期网络文化。一位评论者认为，无论这场商标争执哪些是真、哪些是玩笑，“网络空间”一词都兴起于与迷幻文化和感恩至死乐队相邻的圈子；这是文化关联判断，并非对传闻的另一份证明。原文作者随后回复，利里曾在一九九四年一本书的封底，把个人电脑比作九十年代的 LSD，并给出书名和出版资料。另一位读者贴出自己讨论利里的文章供延伸阅读。这三条发言主要补充人物周围的思想和文化背景，没有提出吉布森实际申请人名商标的新材料，也没有讨论当前商标权归属。