1. Ollama引擎升级：多模态AI，你的电脑也能看图说话！ (Ollama’s new engine for multimodal models)
Ollama 迎来重大升级，其全新引擎现已支持多模态模型！这意味着你的本地 Ollama 也能像科幻电影里那样，理解图像了。首批支持的模型包括 Meta Llama 4、Google Gemma 3、Qwen 2.5 VL 以及 Mistral Small 3.1 等，涵盖了视觉模型的方方面面。
通过 Ollama，你可以让 Llama 4 Scout（一个拥有 1090 亿参数的混合专家模型）“看”懂图片，比如上传一张旧金山渡轮大厦的照片，然后询问它与斯坦福大学的距离以及最佳路线。 还可以让 Gemma 3 分析多张图片，甚至能幽默地分析图像中动物搏斗的胜算。
Ollama 一直以来依赖 ggml-org/llama.cpp 项目，但为了更好地支持日益涌现的多模态模型，Ollama 打造了新引擎，将多模态模型置于核心地位，并与 GGML 团队合作，提升本地推理的可靠性和准确性，为未来支持语音、图像生成、视频生成以及更长上下文奠定基础。此外，新引擎还优化了内存管理，提升了图像缓存和KV缓存的效率，并与硬件厂商合作优化性能。
原文链接：https://ollama.com/blog/multimodal-models
论坛讨论链接：https://news.ycombinator.com/item?id=44001087
关于Ollama的多模态支持，论坛上出现了一些讨论。有人指出，llama.cpp最近才合并了稳定的视觉功能，而Ollama似乎已经开发了此功能一段时间，并摆脱了对llama.cpp的依赖，这可能使Ollama能够更好地掌控自身的发展方向。
一些人对Ollama增加多模态支持的具体差异表示疑问，因为Ollama和llama.cpp长期以来都支持LLaVA。有人认为，之前的支持可能需要特殊处理，而现在不再需要。
有人分享了关于llama.cpp历史的链接，并指出Ollama的策略和时间线尚不完全清楚。有评论员认为，Ollama对llama.cpp的贡献主要集中在询问功能何时发布，以便复制粘贴到Ollama中。
一位维护了llama.cpp集成的开发者表示，尽管llama.cpp早已具备多模态功能，但缺乏文档且难以使用。Hugging Face的员工ngxson为此做了大量工作，重构了代码库，使其更易于维护。该开发者对Ollama将llama.cpp的功能包装成自己的成果感到失望，并认为其夸大了自身的工作。他还批评Ollama将“支持思考/推理；工具调用与流式响应”等早已实现的功能作为新特性进行宣传。不过，也有人认可Ollama的用户体验，认为它能帮助人们在本地运行llama.cpp。
2. 年入1.3亿美元航天巨头，十年白嫖开源软件试用期！ (Ground control to Major Trial)
一家名为Vates的开源公司近日分享了一则令人啼笑皆非的故事。一家年收入高达1.3亿美元的半官方航天公司，竟然十年如一日地滥用Vates旗下Xen Orchestra Appliance (XOA) 软件的30天试用期，上演了一出“无限试用”的闹剧。
这家公司拥有数千台虚拟机，其IT基础设施高度依赖Vates的平台。XOA 是一款便捷的虚拟机，用户无需自行编译，即可获得稳定支持。然而，这家航天公司没有选择付费使用，而是从2015年起，先用员工的企业邮箱，后用个人邮箱，甚至不断递增邮箱后缀数字的方式，注册了至少60个账号，乐此不疲地薅着免费试用的“羊毛”。
Vates强调，他们欢迎免费用户使用开源版本，但XOA作为商业支持版本，理应付费。更令人费解的是，Vates曾真诚地为该公司提供技术支持，该公司甚至拒绝了批量购买的折扣提议。Vates表示，这种行为不仅违反了开源社区的“道德契约”，也对开源生态的可持续性造成了损害。他们计划引入更智能的试用限制，以防止类似事件再次发生，并将精力集中在真正需要支持的用户身上。Vates最后喊话这家航天公司，呼吁其停止这种“行为艺术”，尝试一下“火箭科学”之外的商业道德。
原文链接：https://virtualize.sh/blog/ground-control-to-major-trial/
论坛讨论链接：https://news.ycombinator.com/item?id=44004388
论坛上，大家主要讨论一家公司盗用楼主的开源软件问题。有人建议楼主学习拉里·埃里森的做法，强硬地向这家公司追讨损失，或者至少要求他们支付一些费用，因为他们实际上是在窃取楼主的劳动成果。 鉴于对方已经持续盗用十年之久，建议楼主发出停止侵权通知，限期对方停止侵权或购买授权，否则将追究过去十年的授权费、利息和罚款。
也有人赞同立即采取行动，认为该公司会立即选择和解，因为这种盗窃行为证据确凿，将会让他们付出巨大的代价，甚至可能面临罚款。有人建议楼主直接给他们开账单，并咨询法律意见。
还有人建议楼主采取法律行动，或者至少公开谴责这家公司，让相关负责人受到应有的惩罚。楼主也考虑直接联系CEO，但也不排除CEO对此事知情的可能性。楼主表示，目前不打算立即采取法律行动，但公开谴责这种行为是必要的，也能给其他公司敲响警钟。
3. BMaC“无声抛弃”多国创作者？关闭Payoneer通道致收款难 (BuyMeACoffee silently dropped support for many countries (2024))
广受内容创作者欢迎的资助平台Buy Me a Coffee（BMaC）近期悄然调整支付政策，停止支持Payoneer提现，仅保留Stripe作为唯一收款方式。此举对全球多国创作者造成显著影响，尤其是在Stripe服务覆盖不足的地区，大量用户面临资金滞留困境。
背景显示，BMaC此前一直支持Stripe和Payoneer两种提现途径，但用户文档在今年2月至5月间发生了无声变更，移除了Payoneer相关信息。更令人意外的是，平台并未就这一重大变动提前通知用户，无论是通过邮件、社交媒体还是更新日志，导致许多依赖Payoneer收款的创作者在尝试提现时才发现问题。
这一变化的影响广泛，Payoneer支持的国家和地区比Stripe多出近百个，意味着潜在影响范围巨大。以乌克兰为例，许多当地创作者依靠BMaC获得社群支持，包括将收入用于音乐创作、学术研究或小型企业运营等，现在他们发现无法取出资金，陷入技术性僵局。尽管BMaC客服最初回应模糊，后续在用户强烈反馈下，平台在社交媒体上低调回应，提及业务可持续性并承诺为不受Stripe支持的国家寻找替代方案，但前后信息不一，且缺乏公开透明沟通，引发用户不满。此次事件凸显了平台在处理用户资金和政策变更时信息透明度及沟通方式的重要性。
原文链接：https://zverok.space/blog/2024-08-08-bmac-snafu.html
论坛讨论链接：https://news.ycombinator.com/item?id=44002333
论坛的讨论围绕银行和金融系统日益增长的“执法监视”角色展开。有人指出，金融和支付系统已经常态化，主要服务于执法部门的监视功能，这导致小额账户被银行拒绝服务。在一些国家，即使卖淫合法，性工作者也很难开设银行账户。
一位评论者认为，银行在与权威机构合作方面投入过多精力，以至于无法有效地履行其“汇集资金并进行生产性投资”的理论目的。西方正面临资本危机，银行对此负有责任。他们通过金融危机获得政治保护，但实际上应该让破产来淘汰他们。
另一些人则认为，零售银行实际上并没有“汇集资金并进行投资”，因为这会给日常银行业务带来过高的存款风险。投资银行和零售银行是不同的。投资资金正在管理着世界的资金，银行正在减少资本管理的工作。美联储不希望看到银行转变为窄银行，但似乎可以接受银行逐渐衰落到这种状态。
4. AI写代码再进化！OpenAI发布Codex，让开发者效率起飞 (A Research Preview of Codex)
OpenAI近日推出名为Codex的云端软件工程代理，为软件开发领域注入新活力。这款工具目前已向ChatGPT Pro、Team和Enterprise用户开放研究预览，Plus和Edu用户也将很快体验到。
Codex由专为软件工程优化的codex-1模型驱动，通过强化学习在真实编码任务上训练而成，旨在生成更贴近人类风格、精准遵循指令并能通过迭代测试的代码。其核心亮点在于能以云端沙盒环境独立并行处理多项任务，如编写功能、解答代码疑问、修复错误以及提交拉取请求（PR）等，每个任务都在预加载用户代码库的隔离环境中进行，耗时通常在1至30分钟。
用户可通过ChatGPT侧边栏与Codex交互，实时监控任务进展。Codex能通过终端日志和测试输出来验证其操作，增强透明度。用户可以审查结果、请求修改，或直接整合代码。虽然模型性能强大，但OpenAI强调这仍是研究预览阶段，手动审查和验证AI生成的代码至关重要，以确保安全和准确性。Codex的推出预示着AI在软件开发中扮演更重要角色的未来，有望显著提升开发者效率。
原文链接：https://openai.com/index/introducing-codex/
论坛讨论链接：https://news.ycombinator.com/item?id=44006345
论坛中，一位工程师分享了他们团队对Codex alpha测试的积极体验，尤其是在并行任务执行方面，Codex能同时处理大量的代码编辑工作，大幅提升效率，感觉像拥有无限的初级工程师。虽然模型质量与其他模型相比没有显著优势，但在命名、风格和逻辑方面表现尚可。
其他用户则对当前初级工程师的就业环境表示担忧，认为企业更倾向于招聘高级工程师，导致初级职位稀缺，应届毕业生求职困难。一位家长提到，即使是名校计算机科学专业的毕业生，也面临着严峻的就业形势，很多学生依靠人脉关系才找到工作。另有用户指出，过去初创公司会批量招聘和培养初级工程师，但现在这种做法已经很少见，公司普遍追求有经验的资深工程师，导致简历造假现象普遍，甚至出现要求应聘者具备超过技术生态存在时间的经验年限。同时，过去的开发者更倾向于自学，在大学毕业前就已经积累了丰富的实践经验，而现在的CS毕业生则可能缺乏实际应用能力。
5. Python 解锁多核算力：自由线程元年开启！ (The first year of free-threaded Python)
Python 3.14.0b1 近期发布，同时 PyCon 2025 在匹兹堡盛大开幕，标志着 Python 拥抱自由线程的征程进入了新阶段！告别全局解释器锁（GIL）的束缚，Python 终于能充分释放多核 CPU 和 GPU 的强大算力，让并行算法不再是“花架子”。
Quansight 团队在其中扮演了关键角色，与 Meta 的 Python 运行时团队携手，为海量软件包和项目带来了自由线程的支持，例如 NumPy、SciPy、pandas 等数据科学常用库。为了确保平稳过渡，他们还修复了大量与线程安全相关的问题，并贡献了 Python 3.14 的多项重大改进，包括 warnings 模块的默认线程安全、asyncio 的显著改进以及 ctypes 模块的线程安全改造。
当然，挑战仍然存在。许多老旧的 Python 包需要进行详细的线程安全审计，Quansight 团队正在努力解决这些问题，并呼吁更多开发者参与到自由线程 Python 的生态建设中来。
原文链接：https://labs.quansight.org/blog/free-threaded-one-year-recap
论坛讨论链接：https://news.ycombinator.com/item?id=44003445
论坛中，关于多进程处理的效率问题引发了讨论。有人指出，虽然多进程常被采用，但进程创建开销大，进程间通信也需要昂贵的数据复制。共享内存（SharedMemory）机制及其ShareableList应该更频繁地被使用。
针对“进程创建通常Unix系统上小于1毫秒”的说法，有评论认为启动Python解释器可能需要30到300毫秒，具体取决于导入模块的数量，两者相差一到两个数量级。CGI在C、Rust或Go中运行良好，sqlite.org就是以每个请求对应一个进程的方式运行。
具体数据表明，fork、exit和wait操作在不同配置下耗时不同，使用dietlibc编译比glibc更快。有人分享了自己用shell脚本运行shithub.us的经验，每请求启动15到3000个进程，尽管Plan 9在进程创建方面比Linux快10倍，但3000个C进程的启动速度与一个Python解释器相近。还有人测试了Python解释器本身的启动速度，发现很快，大约21毫秒。
讨论还涉及了clone、fork和posix_spawn等系统调用，以及fork操作耗时与地址空间大小的关系。
6. 告别动态类型：Lua的静态类型方言Teal问世 (Teal – A statically-typed dialect of Lua)
告别Lua的动态类型，迎接Teal：静态类型的Lua新纪元！如果你是Lua的忠实粉丝，又渴望更强的类型安全，那么Teal绝对值得关注。Teal是Lua的一种静态类型方言，它通过引入类型注解，让你能够清晰地定义数组、映射、记录，以及接口、联合类型和泛型，就像TypeScript之于JavaScript。
Teal的核心是一个名为tl的编译器，它将.tl源码编译成标准的.lu文件。你可以通过LuaRocks轻松安装tl，或者直接下载预编译的Linux和Windows版本。对于大型项目，推荐使用专为Teal设计的构建工具Cyan。此外，还有vscode-teal等插件，为Visual Studio Code和其他编辑器提供集成支持。
Teal秉承Lua的极简主义精神，同时保证了代码的可移植性和嵌入性。无论你是想提高代码质量，还是探索Lua的更多可能性，Teal都将为你带来全新的体验。
原文链接：https://teal-language.org/
论坛讨论链接：https://news.ycombinator.com/item?id=44000759
一位用户分享了自己对Lua语言态度的转变，最初因类似JavaScript的体验而不太喜欢Lua，但后来在Neovim和Wezterm的使用中，逐渐喜欢上Lua的简洁性和易于维护的代码特性。他认为Lua的动态鸭子类型系统更接近Python，并通过typeis进行类型检查很直接。他同时指出Lua的不足之处在于标准库不完整，缺少强大的包管理器，luarocks使用起来比较麻烦。尽管如此，他认为类型注解可以通过LSP来满足，因此对新的类型注解项目兴趣不大。
另一位用户推荐了一个新的Lua包管理工具Lux，声称它很有前景。有用户表示听闻这个消息很激动，并打算尝试一下。
还有用户补充说，Lua受欢迎程度不高可能还因为数组索引从1开始，而非从0开始。但有人反驳说，Lua没有数组，只有表，表可以作为“序列”操作，索引从1开始是其特性。另有用户指出字符串索引也从1开始，这有时会带来不便。另有用户表示基于他的经验，即使是中等规模的Lua代码库，也很难写出易于维护的代码。
7. 谷歌Material 3迎来重大更新：打造更富情感化的用户体验 (Material 3 Expressive)
Google推出了一项名为Material 3 Expressive的重大设计更新，旨在为用户带来更具情感化的用户体验。这项更新并非简单地依赖数据，而是通过历时三年的深入研究、设计和工程协作完成，期间进行了46项独立研究，涉及全球超过18000名参与者，堪称Google设计系统有史以来研究投入最多的一次。
Material 3 Expressive的核心在于利用色彩、形状、大小、动态和布局等元素，让界面更易用、更引人注目。研究表明，精心设计的Expressive界面不仅更受用户喜爱（尤其是在18-24岁年龄段中，偏好度高达87%），还能提升品牌在用户心中的“潮流”、“现代”和“创新”等形象。
更令人兴奋的是，Expressive设计在改善用户体验方面也表现出色。通过眼动追踪实验，用户在M3 Expressive界面中能够更快地找到关键元素，点击操作的时间也显著缩短。此外，新设计还消除了年龄对用户体验的影响，让年长用户也能像年轻人一样轻松使用各种应用。当然，Google也强调，Expressive设计并非万能，设计师仍需在创新和用户习惯之间找到平衡，确保功能性不受影响。目前，Material 3 Design Kit for Figma已更新，供设计师们体验这一全新设计理念。
原文链接：https://design.google/library/expressive-material-design-google-research
论坛讨论链接：https://news.ycombinator.com/item?id=43975352
论坛用户们主要讨论了谷歌Material Design的设计理念和苹果的设计风格。一位UX从业者认为谷歌Material Design投入了大量工作，但其设计理念文档有时显得过于理论化，类似于百事可乐的标志设计文档，缺乏实际意义，例如，为了提高点击率而增大按钮的做法可能会牺牲屏幕空间，长期来看并不实用。
与此形成对比的是，苹果很少就其设计语言进行过度宣传，更倾向于让产品本身说话。苹果的UI更新通常不会过于激进，核心功能和布局基本保持不变。有用户指出，macOS的设置和iOS 18的照片应用是例外，苹果近来也有下滑的趋势，但至少核心操作系统尚未经历重大变革。另有用户认为照片应用的改变是因为使用Swift重写了。
还有人质疑谷歌的设计理念，认为其宣传的某些关键属性提升可能并不具有统计学意义。有人则反驳说，苹果也曾有过乔纳森·艾维的个人宣传时代，只是现在不再这样做了。最后，有用户调侃说，即使像百事可乐标志那样的设计，即使已经不再使用，仍然被人们津津乐道。
8. 德语学习“血泪控诉”：幽默作家妙笔生花吐槽德语语法 (The Awful German Language (1880))
学习德语难于上青天？幽默作家在海德堡城堡的奇遇引发了他对德语学习的“血泪控诉”。德语语法堪称语言界的“泥石流”，规则繁琐，例外更多，令人摸不着头脑。名词阴阳性分配毫无逻辑，形容词变幻莫测，动词喜欢玩“失踪”，句子冗长复杂，括号套括号简直是噩梦。一句话能横跨报纸四分之一版面，动不动就蹦出读者闻所未闻的自造复合词，简直是对耐心和智商的双重考验。
作家甚至“贴心”地给出了德语改革方案：废除令人抓狂的Dative格，把动词提到显眼位置，从英语引进一些强力脏话，重组性别分配，简化复合词，演讲完毕就利落停下，果断抛弃括号。
原文链接：https://faculty.georgetown.edu/jod/texts/twain.german.html
论坛讨论链接：https://news.ycombinator.com/item?id=44001765
论坛上有开发者讨论在德国公司将领域特定语言翻译成英语的问题。有人认为德语复合词非常精确，难以找到简短匹配的英语翻译，导致非母语开发者需要学习复杂的单词。通常的做法是技术标识符用英语，业务语言用德语，代码虽然“有趣”，但可行。
另一些人认为德语复合名词的问题被夸大了，它们与英语类似，只是没有空格。有人指出，某些德语复合词的含义并非简单地来自其组成部分，如Kindergarten和Weltschmerz。对于领域特定的术语更是如此，例如Gestaltpsychologie和Bildungsroman。
有评论回复说，这些概念通常在英语中也有表达方式。例如，Kindergarten在英式英语中是nursery。而Bildungsroman可能是“coming-of-age novel”（成长小说）。多语言用户界面面临的最大挑战不是翻译，而是动态字符串构建或UI结构不适用于另一种语言等实际问题，或者英语单词在应用程序的不同部分中使用，但其他语言版本需要不同的字符串。例如，有些语言没有常用词来表示“limb”（肢体），即手臂或腿。
关于Bildungsroman，英语术语实际上就是“bildungsroman”。“coming-of-age novel”这个翻译虽然技术上正确，但失去“roman”和法语文化的影响。 有人反驳说，英语中的书（book）来自小说（novel）中的“new”，而法语中的书（book）来自“roman vernacular”。
9. 墨西哥掀起纳瓦特尔语和玛雅语复兴浪潮 (Náhuatl and Mayan Language Renaissance Occurring in Mexico)
墨西哥正积极采取措施，复兴其丰富而独特的本土语言文化。这个国家拥有68种官方认可的土著语言，包括玛雅语和纳瓦特尔语，但由于城市化、全球化以及西班牙语和英语的主导地位，这些语言正面临消失的威胁。为了保护这些文化瑰宝，墨西哥政府启动了一系列倡议，包括提供土著语言课程，甚至在某些情况下提供双语课程。
尤卡坦半岛的学校里，玛雅语教学项目如火如荼地展开，已有来自75个自治市的35000名学生可以选择学习尤卡坦玛雅语。在墨西哥城，78所学校也将在未来几周内开设纳瓦特尔语课程。尽管纳瓦特尔语是美洲大陆使用最广泛的土著语言，但在年轻一代中，它正迅速消退。这些课程旨在教授词汇和语法，并让学生沉浸在语言的文化背景中，通过故事、传统歌曲和仪式，更深入地了解这些古老语言中蕴含的世界观。
虽然资源有限和方言差异等挑战依然存在，但学生和社区日益增长的热情预示着土著语言拥有光明的未来，确保它们成为墨西哥身份的持久组成部分。同时，消除对土著语言的歧视也至关重要，让这些语言在社会中获得应有的尊重和地位。
原文链接：https://yucatanmagazine.com/mayan-language-renaissance/
论坛讨论链接：https://news.ycombinator.com/item?id=43974461
论坛讨论围绕纳瓦特尔语及其文化影响展开。一位用户在阅读《阿兹特克：简短介绍》后，注意到家族成员的名字与纳瓦特尔语相关，引发了对墨西哥“印第安主义”运动的兴趣，以及纳瓦特尔语对墨西哥西班牙语乃至英语的影响。另一位用户推荐了一本书，探讨了天主教会和移民后裔对本土语言的影响。有人指出，“墨西哥”一词本身就来源于阿兹特克帝国中的纳瓦部落“墨西哥人”。还有人提到了巧克力（Chocolatl）的来源。
关于西班牙人是否尊重原住民文化，观点存在分歧。一方认为，西班牙人并未真正尊重原住民文化，只是未能完全消灭它。另一方则认为，西班牙在一定程度上尊重了古老文化，反而是墨西哥独立后试图消除这种文化。讨论中还提到了墨西哥人的多样性，以及西班牙殖民历史的复杂性。有人批评一种非黑即白的看待历史的倾向，指出应该避免过度美化或妖魔化历史。
10. 重返Windows 3.1：moricons.dll图标背后的MS-DOS程序回忆 (What were the MS-DOS programs that the moricons.dll icons were intended for?)
在Windows 3.1的时代，除了progman.exe中那些标志性的图标外，moricons.dll也承载了许多经典程序的记忆。近日，有研究者翻开了Windows 3.1 moricons.dll文件的旧账本，详细列出了其中包含的图标及其对应的应用程序。这份清单就像一张时光穿梭机票，带我们重温了那个年代的软件生态。
从早期的MS-DOS提示符、编译器，到各种办公软件如Microsoft Works、Lotus 1-2-3、WordPerfect，再到开发工具如Turbo Pascal、Borland C++，甚至还有飞行模拟游戏，这份名单几乎涵盖了当时个人电脑上的各种应用场景。值得一提的是，这些图标与程序的关联并非随意指定，而是通过APPS.INF文件中的信息进行映射，确保了系统能够正确地为不同程序分配对应的图标。
这些图标和程序名称，对一部分人来说或许是满满的怀旧情怀，而对另一些人来说，也许是想要尘封的遥远记忆。但无论如何，它们都共同构成了个人电脑发展史上不可磨灭的一笔，也让我们得以窥见那个充满创新与探索的软件黄金时代。
原文链接：https://devblogs.microsoft.com/oldnewthing/20250507-00/?p=111157
论坛讨论链接：https://news.ycombinator.com/item?id=43971616
论坛的讨论围绕对过去计算机时代的怀念展开。许多人认为，那时人们对计算机的未来充满乐观和掌控感，而现在更多的是在努力防止情况变得更糟。有人指出，当时的社会氛围也更加积极向上，人们对未来抱有希望。另一些人则认为，过去计算机尚未普及，对人们的生活影响较小，使用起来也更加自由。
一些评论者认为，现在机器越来越有可能控制人类，因为它们被锁定并远程控制以推送广告和虚假信息。还有人指出，如今的计算机被制造商人为设置了许多限制，用户难以逾越，这实际上是制造商试图在购买后继续控制设备。
然而，也有人指出，怀旧带有玫瑰色的滤镜。过去的计算机使用场景相对简单，风险较低，而现在的计算机需要处理复杂的任务，例如保护用户的金融信息。因此，现在的安全措施和限制是必要的，也是时代发展的必然。总的来说，讨论既有对过去美好时光的追忆，也有对当前技术发展的反思。