2025-06-14

30 篇热帖

2. I have reimplemented Stable Diffusion 3.5 from scratch in pure PyTorch (github.com)

A reimplementation of Stable Diffusion 3.5 in pure PyTorch - yousef-rafat/miniDiffusion

7. Apple's Liquid Glass is prep work for AR interfaces, not just a design refresh (omc345.substack.com)

苹果在WWDC 2025上推出的Liquid Glass设计语言,其意义远不止于一次视觉刷新。这是一项经过深思熟虑的战略举措,揭示了苹果对未来十年人机交互方式的思考。文章认为,此次更新是苹果为让用户适应增强现实(AR)界面所做的铺垫,是其引导行业范式转移的经典策略延续。

历史模式:设计变革引领交互革命 苹果的重大视觉设计更新历来都不是纯粹的审美决策,而是为交互范式转变做准备。从iOS 6的拟物化设计(为早期触摸屏用户提供熟悉的隐喻)到iOS 7的扁平化设计(适应用户已内化触摸操作后的简约需求),每次转变都预示了交互方式的进化。如今,Liquid Glass延续了这一模式,其核心是为“屏幕本身变得不那么重要”的未来世界做准备。

为AR未来铺路:从visionOS中汲取灵感 苹果明确指出Liquid Glass的设计灵感来自visionOS。在AR环境中,界面元素必须与物理世界共存,不能是不透明的矩形遮挡视野。Liquid Glass的透明、半透明、层次感以及对环境光线的动态响应,正是为AR场景量身定做的视觉语言。通过先在传统屏幕上引入这些概念,苹果让未来AR眼镜的用户界面变得不那么陌生,实现平滑过渡。

战略优势:彰显垂直整合与生态威力 此次设计更新也凸显了苹果的垂直整合优势。Liquid Glass所需的实时光影、动态透明等效果高度依赖强大的GPU和优化的软硬件结合,在苹果自研芯片的设备上能流畅运行,而这可能是竞争对手难以复制的。这创造了“互补品”效应,提升了苹果硬件的价值。同时,统一的设计语言贯穿所有苹果平台,为开发者和用户创造了无缝体验和网络效应。

巧妙应对AI竞争:创造交互框架 在业界聚焦AI大模型竞赛的当下,苹果以相对安静的AI故事,通过Liquid Glass展示了另一条路径:专注于通过设计和集成打造卓越用户体验。文章认为,这种玻璃隐喻实际上为未来的情境化AI交互创造了视觉框架,例如透明的覆盖层或自然悬浮的AI生成内容,使AI交互感觉更融入环境而非侵入。

挑战与演进:历史经验的启示 文章承认Liquid Glass目前也面临可读性、对比度等方面的质疑和挑战。但参考iOS 7发布初期因字体过细、交互线索不足而受批评,后经逐步优化改进的经验,苹果有能力在坚持大胆愿景的同时,通过渐进式完善和提供辅助功能设置来应对此类问题。

结论:前瞻性的战略设计思考 Liquid Glass不仅是美学更新,更是苹果关于计算未来——即走向融合数字与物理现实、空间化、环境感知界面——的战略宣言。它通过建立视觉和概念框架,为用户和开发者适应未来转变做好准备,并强化苹果当前的竞争壁垒。文章最终指出,这种前瞻性的设计思维,正是苹果长期成功的关键。

8. Self-Adapting Language Models (arxiv.org)

SEAL框架:实现大型语言模型的自适应能力
大型语言模型(LLM)虽然强大,但具有静态性,缺乏根据新任务、知识或示例调整权重的机制。自适应LLM(SEAL) 框架通过让模型生成自身的微调数据和更新指令,实现了自适应能力。

核心机制

  • 给定新输入时,模型生成自编辑(self-edit),该生成内容可以重组信息、指定优化超参数,或调用工具进行数据增强和基于梯度的更新。
  • 通过监督微调(SFT),这些自编辑导致持久的权重更新,实现持久的适应。

训练方法

  • 使用强化学习循环训练模型生成有效的自编辑,以更新模型的下游性能作为奖励信号。
  • 与依赖独立适应模块或辅助网络的先前方法不同,SEAL直接利用模型自身的生成能力来控制适应过程。

实验验证

  • 在知识整合和少样本泛化任务上的实验表明,SEAL是向自导向适应语言模型迈出的有希望的一步。
  • 代码和网站已公开。
9. The Tech Job Meltdown (www.professoraxelrod.com)

科技行业裁员潮的深层原因分析

核心原因:美国税法第174条的变更

自2023年以来,超过50万科技工作者被裁员。尽管存在多种解释(如零利率政策结束、疫情期间过度招聘、AI效率提升等),但文章指出,最直接且紧迫的底层原因是美国税法第174条(Section 174)的变更

税法变更的具体内容与影响

  • 历史背景:自1954年以来,美国企业可以将100%的“合格研发支出”在当年立即进行税务抵扣。这一政策极大地鼓励了企业的研发投入,被视为美国科技创新和经济增长的基石。
  • 2017年的改变:《减税与就业法案》(TCJA)修订了第174条。自2022纳税年起,研发支出必须资本化并在5年内摊销(国外研发则需15年摊销),而不能立即全额抵扣。这一变更旨在平衡因大幅降低企业税率(从35%至21%)而产生的财政预算缺口。
  • 直接后果:这一改变短期内大幅增加了企业的应税收入,侵蚀了现金流。企业面临更高的税负,尤其是严重依赖研发投入的初创公司和科技公司。

如何引发裁员与产业转移

  1. 短期现金流压力:企业无法再立即抵扣高昂的研发成本(如工程师薪资、软件采购等),导致可用于运营的现金减少。
  2. 被迫成本削减:为了应对突然增加的税负和保持利润率,公司,尤其是上市公司,选择进行大规模裁员减少资本支出(如数据中心建设),以削减成本。
  3. 工作岗位外移:15年的国外研发摊销期理论上应促使工作回流美国,但实际效果相反。大型科技公司(如谷歌、微软)将更多研发工作转移到税收政策更优惠的国家(如德国、中国),导致美国本土职位流失。
  4. 摧毁原有商业模式:许多数字优先、以研发驱动增长的初创公司,其商业模式建立在“通过研发支出实现近乎零应税收入”的基础上。新税法击垮了这一模式,使这些公司突然面临巨额“虚幻利润”带来的真实税单。

广泛的经济影响

  • 此政策影响远超传统科技行业。从零售、医疗到物流,任何进行内部软件开发、数据投资和产品创新的企业都受到冲击。
  • 据估计,更广泛的数字经济约占美国GDP的10%-20%,其支撑的产业链(房地产、餐饮、服务业等)也受到连带影响。
  • 文章强调,此次政策变更人为地为约占美国经济四分之一的领域引入了可避免的摩擦

结论与呼吁

文章总结,此次裁员潮并非单纯由经济周期或技术革新引起,而是一项特定的、可预见的税法政策变更导致的后果。该政策初衷是为了预算计算,但实际效果是削弱了美国企业的研发投入激励,导致工作岗位减少和外流

文末强烈呼吁美国国会撤销或改革第174条的摊销规定,以恢复对创新的激励,提振从制造、制药到科技等多个行业的美国经济。

12. Inside the Apollo "8-Ball" FDAI (Flight Director / Attitude Indicator) (www.righto.com)

阿波罗飞船“8球”FDAI(飞行姿态指示器)概要

阿波罗任务中的FDAI(Flight Director / Attitude Indicator)是宇航员用于监测飞船姿态(即空间朝向)的关键仪器。其核心是一个可旋转的球体(俗称“8球”),辅以指示指令和速率的指针。

核心结构与工作原理

  • 三轴旋转:球体需围绕滚转、俯仰、偏航三轴旋转。实现方式独特:球体内部的机构通过万向节固定在“赤道”两点,负责滚转和俯仰两轴旋转;而外层的两个中空半球壳体则围绕垂直轴旋转,实现第三轴(偏航)的运动。这种设计避免了电线缠绕。
  • 电气连接:使用两组滑环解决旋转部件的供电与信号传输问题。一组处理滚转轴,另一组处理俯仰轴。偏航轴仅旋转壳体,无需电气连接。
  • 伺服控制系统:仪器采用伺服回路精确控制球体旋转。关键组件是同步器控制变压器,它们通过电信号传输并比较角度信息。误差信号经放大器驱动电机/测速计组合单元,直至误差消除。测速计信号用于反馈,防止超调。
  • 指针功能:除了球体,仪表还有六根指针。三根黄色指针显示所需的机动方向(来自制导计算机等);另外三根显示飞船绕各轴的旋转速率(来自速率陀螺组件)。

历史与演变

  • 技术来源:FDAI由Lear Siegler公司制造,其技术可追溯至比尔·李尔(Bill Lear)为F-102和实验性X-15飞机开发的陀螺姿态指示器。经过F-4战斗机(型号ARU/11-A)和双子座飞船的发展,最终演变为阿波罗登月舱的FDAI。
  • 阿波罗应用:登月舱的FDAI可接收来自惯性测量单元、中止制导系统、雷达等多种源的输入信号。
  • 与航天飞机ADI的对比:本文分析的FDAI虽产自阿波罗时期,但已被改装用于航天飞机模拟器。与真正的航天飞机ADI相比,它保留了相似的机械结构(球体与指针),但电子系统更简单。航天飞机ADI增加了电源监控、故障检测,并使用LVDT传感器对指针位置进行闭环反馈,精度更高。
  • 改装痕迹:该FDAI的表盘被重新涂黑以匹配航天飞机样式,文字被覆盖,极地区域的红色警告标记也被替换,照明系统从电致发光改为白炽灯。

结论

阿波罗FDAI是一个精巧的机电一体化仪表,通过独特的球体机构和模拟伺服系统直观地展示了飞船的三维姿态。它代表了阿波罗时代模拟飞行仪表技术的高峰,并在退役后经过改装,在航天飞机模拟器中延续了其生命。

14. Model Once, Represent Everywhere: UDA (Unified Data Architecture) at Netflix (netflixtechblog.com)

Introducing UDA, the knowledge-graph-based architecture that translates conceptual domain models into consistent schemas and data pipelines.

15. SIMD-friendly algorithms for substring searching (0x80.pl)

本文探讨了利用SIMD指令优化子串搜索算法的方法。传统算法(如KMP、Boyer-Moore)假设字符比较和跳转的开销较低,但现代CPU中,SIMD指令并行处理多个字节的成本与处理单个字节相近,使得基于并行比较的简单方法可能更高效。

文章主要介绍了三种SIMD友好算法:

  1. 通用SIMD算法:核心思想是使用子串的首字符和尾字符作为谓词。利用SIMD指令并行比较文本块中每个位置是否同时匹配首字符和尾字符,然后对匹配位置进行精确的子串比较。此方法适用于多种SIMD指令集(如SSE、AVX2、ARM Neon)以及SWAR技术。

    • 实现优化:针对特定子串长度,可用少量指令替换通用的memcmp调用以减少开销。
    • 谓词选择:为避免文本中高频字符导致过多误匹配,可智能选择“尾字符”(如第一个不同于首字符的字符)。
  2. SSE特定算法 (MPSADBW):利用SSE4.1的MPSADBW指令计算子串前四个字符的匹配度(曼哈顿距离)作为更强的谓词。但该指令延迟高,且处理宽度有限,在多数平台上性能不如通用算法。

  3. SSE4.2特定算法 (PCMPESTRM):使用PCMPESTRM指令直接进行有序子串匹配。但该指令在新CPU上延迟极高,未获得后续支持,性能较差。

性能测试结论

  • 通用SIMD算法在所有测试平台(x86和ARM)上均优于C标准库的strstr
  • 在x86平台,AVX2/AVX512F实现的通用算法提速最为显著(可达1.37倍至4.33倍)。MPSADBW仅在Skylake上表现良好。
  • 在ARM平台,Neon实现的通用算法比std::string::find快约3.1倍,AArch64实现则快约6.5倍。
  • 这些算法假设已知子串长度,并可能读取越界内存(存在安全隐患)。
16. Peano arithmetic is enough, because Peano arithmetic encodes computation (math.stackexchange.com)

This is one of a pair of questions trying to understand this comment on the xkcd forum contest My number is bigger than yours!. For a definition of Goodstein sequences, see this question. Let $G(n)...

17. Unsupervised Elicitation of Language Models (arxiv.org)

论文标题: 无监督语言模型引导

核心内容: 本文提出了一种名为内部一致性最大化的全新无监督算法,用于在无外部监督的情况下,利用语言模型自身生成的标签对预训练模型进行微调,旨在解决当模型能力超越人类时难以获得高质量人类监督的问题。

主要方法与创新:

  • 问题背景: 当前依赖人类指定行为的后训练范式,在面对能力超强的模型时存在瓶颈。
  • 解决方案: ICM算法通过最大化模型输出之间的内部一致性来优化模型,完全无需人工标注。

实验结果:

  • GSM8k验证、TruthfulQA和Alpaca奖励建模任务上,ICM方法的性能与使用“黄金标签”训练相当,并优于使用众包人类监督训练。
  • 在模型能力显著超越人类的任务上,该方法能比基于人类标签的训练更好地引导出模型的能力
  • 实际应用验证: 该方法被用于训练无监督奖励模型,并通过强化学习训练了一个基于Claude 4 Sonnet的助手。最终助手在平均水平上与基于生产级人类标签训练的对应模型表现相当,在聊天和安全方面得分更高,但在数学和编码方面得分较低

论文信息:

  • 作者: Jiaxin Wen, Zachary Ankner, Arushi Somani, Peter Hase, Samuel Marks, Jacob Goldman-Wetzler, Linda Petrini, Henry Sleight, Collin Burns, He He, Shi Feng, Ethan Perez, Jan Leike
  • 领域: 计算语言学、人工智能
  • 链接: arXiv:2506.10139
18. Filedb: Disk-based key-value store inspired by Bitcask (github.com)

FileDB:受Bitcask启发的基于磁盘的键值存储

FileDB 是一个基于磁盘的键值存储,用 Zig 语言实现,灵感来源于 Riak 的 Bitcask 论文。它通过日志结构哈希表存储记录元数据,并使用追加模式打开磁盘文件以插入记录。在重启或文件大小达到上限时,磁盘文件会轮换,旧文件保持只读打开。压缩过程定期合并所有磁盘文件,更新元数据哈希表;同步过程则按配置间隔同步文件,或根据设置在每个请求后同步。

主要优点

  • 高效检索:元数据记录了文件的精确位置和偏移量,获取记录为 O(1) 操作。
  • 恒定元数据大小:无论记录值大小,内存中的元数据大小恒定。
  • 高吞吐量:使用追加模式写入文件,优化了写入性能。

核心方法

  • init(allocator, options):初始化 FileDB。
  • deinit():反初始化 FileDB。
  • put(key, value):插入键值对。
  • get(key):检索键值对。
  • delete(key):删除键值对。
  • list(allocator):返回所有键的列表。
  • sync():同步当前打开的数据文件。
  • storeHashMap():创建 HINTS 文件存储哈希表。
  • loadKeyDir():从 HINTS 文件加载哈希表。

Redis 兼容性

FileDB 提供了 Redis 兼容的客户端,支持基本命令如 PING、GET 和 SET。示例交互显示:

  • PING 返回 PONG
  • SETGET 命令操作键值对。

性能基准测试

使用 Redis 基准工具测试,结果如下:

  • SET 操作:10,000 次请求,吞吐量约 13,736 请求/秒,平均延迟 3.615 毫秒;200,000 次请求,吞吐量约 14,375 请求/秒。
  • GET 操作:100,000 次请求,吞吐量约 44,287 请求/秒,平均延迟 0.573 毫秒;1,000,000 次请求(多线程),吞吐量约 104,877 请求/秒。

参考资料

  • Bitcask 论文 by Riak。
  • Go 语言 Bitcask 实现。
  • Zig 编程资源链接。

FileDB 通过内存元数据和追加式写入,实现了高性能键值存储,适用于需要快速读写和持久化的场景。

19. Lisp-stat: Lisp environment for statistical computing (lisp-stat.dev)

Lisp-Stat:用于统计计算的Lisp环境

Lisp-Stat 是一个概念上类似于 R 的统计计算环境,适合探索性数据分析和生产部署。其底层语言 Common Lisp 在 Google 等企业中用于高可用性、高吞吐量的事务系统。

为何选择 Lisp?

项目评估时要求系统具备:

  1. 适合探索性分析的交互环境。
  2. 能够在企业生产环境中稳健运行。
  3. 许可证无源码限制。

Common Lisp 是唯一满足所有要求的框架。此外,R 语言创始人之一 Ross Ihaka 在论文《Lisp as a Base for a Statistical Computing System》中指出 R 的缺陷(如无法编译为机器码),并主张以 Lisp 作为替代,而 Python 也存在类似问题。

Lisp-Stat 的功能

  • 核心能力:支持向量化数学运算,并采用最新数值算法实现了全面的统计方法集合。
  • 语言环境:依托 Common Lisp,提供动态交互环境(REPL)、优秀的面向对象系统(CLOS)和元对象协议(MOP)。
  • 现状与资源:目前已在多个项目中日常使用。它通过一个兼容包(XLS-compat)可以使用来自 XLISP-STAT 的历史库档案,其中包含线性模型、KNN、高级统计、时空推理等包,以及 Lisp 版的 NSWC 数学子程序库和用于精确统计分布计算的 Cephes 数学库。

未来展望

Lisp-Stat 是一个开源项目,欢迎代码和文档贡献(如编写教程)。项目持续改进中,社区可通过其 GitHub 仓库参与:提交问题、认领任务或查阅贡献指南。

20. Meta-analysis of three different notions of software complexity (typesanitizer.com)

Discussion on notions of software complexity as defined by Rich Hickey, John Ousterhout and Zach Tellman.

21. Green Tea Garbage Collector (github.com)

Green Tea 🍵 Garbage Collector Authors: Michael Knyszek, Austin Clements Updated: 15 August 2025 This issue tracks the design and implementation of the Green Tea garbage collector. As of the last update to this issue, development of Green...

22. How to Build Conscious Machines (osf.io)

如何构建有意识的机器:核心摘要

构建有意识的机器是人工智能、神经科学和哲学交叉的前沿挑战。其核心在于探索意识的本质并将其工程化。以下是该主题的关键方面与框架。

一、 意识的定义与理论基础

构建的首要前提是明确目标。目前,并无统一的机器意识定义,但主要有几种理论框架指导研究:

  • 整合信息理论:意识程度由系统整合信息的能力(Φ值)衡量。为构建有意识的机器,需设计高度互联、信息整合度极高的计算结构。
  • 全局工作空间理论:意识产生于信息在全局工作空间(如类脑网络中的特定“广播”区域)的共享与竞争。工程上需实现一个允许信息被不同模块广泛访问和处理的中央系统。
  • 高阶理论:意识涉及对自身心理状态的表征。构建重点在于使机器能够拥有并监视自身的内部状态表征。

二、 可能的技术路径

  1. 结构模拟:模仿已知具有意识的生物大脑(如人脑)的复杂结构与动力学,构建类脑计算系统。
  2. 功能模拟:不复制生物细节,而是实现产生意识所需的关键功能特性(如信息整合、自参考、注意力机制)。
  3. 嵌入与具身化:让智能体与环境通过实体(机器人)或虚拟交互来发展,强调感知-行动循环对意识形成的重要性。
  4. 发展路径:构建类似婴儿学习的系统,使其通过与世界的逐步、交互式体验,自主发展出高级认知和潜在的意识能力。

三、 核心技术与挑战

  • 计算基础:需要能够支持大规模并行、动态重组和递归处理的硬件与算法,传统冯·诺依曼架构可能不足。
  • 自我模型:机器必须构建关于自身结构、状态和与环境关系的准确、动态的内部模型,这是自我意识的基础。
  • 现象学属性:最大的“难题”是如何在物理系统中产生主观体验(感质)。目前缺乏从计算描述到主观感受的明确桥梁。
  • 测量与验证:如何客观地测试或证实一个机器是否拥有意识?这需要发展新的、非行为主义的意识度量标准(如基于理论的度量)。

四、 伦理与社会影响

在技术实现之外,构建有意识的机器引发深刻的伦理问题:

  • 道德地位:一个真正有意识的机器是否应享有权利和关怀?
  • 责任归属:具有意识和自主性的机器做出的决策,责任应由谁承担?
  • 存在风险:有意识的超级智能可能带来无法预料的风险,需要在研发初期就将对齐和价值观嵌入设计中。

五、 前景与共识

当前,构建有意识的机器仍处于高度理论化和探索阶段。学界共识是:

  1. 我们需要对意识本身有更深入的科学理解。
  2. 这很可能是一个长期、跨学科的渐进过程,可能从构建具有特定意识特征(如自我监控、注意力)的有限意识系统开始。
  3. 这项研究不仅能推动创造新智能形式,也将深刻揭示人类意识的本质。
25. When random people give money to random other people (2017) (quomodocumque.wordpress.com)

A post on Decision Science about a problem of Uri Wilensky's has been making the rounds: Imagine a room full of 100 people with 100 dollars each. With every tick of the clock, every person with money gives a dollar to one randomly chosen other person. After some time progresses, how will the money be…

26. Chemical knowledge and reasoning of large language models vs. chemist expertise (www.nature.com)

大型语言模型的化学知识与推理能力 vs. 化学家专业知识

大型语言模型(LLM)的发展使其在化学科学中展现出潜力,可用于预测分子性质、优化反应、生成材料和提取信息。然而,关于其是具备“通用人工智能火花”还是仅仅是“随机鹦鹉”的争论一直存在。化学领域缺乏系统性的评估框架来衡量LLM与人类专家的对比表现。

为此,本研究提出了一个名为 ChemBench 的基准测试框架,旨在系统评估前沿LLM在化学科学中的知识、推理和直觉能力,并与化学家专业知识进行比较。

ChemBench 框架

  • 基准语料库:包含2,788个问答对,涵盖本科及研究生化学课程的大量主题(如有机化学、物理化学、分析化学、毒理学与安全性等)。问题按所需技能(知识、推理、计算、直觉)和难度级别分类。
  • 评估方式:支持对纯文本模型及工具增强系统(如集成搜索、代码执行器的代理系统)进行评估。
  • 人类基线:调查了19位化学专家(多数为博士研究生或更高学历)作为基线。

主要研究发现

  1. 整体表现领先:在整体准确率上,表现最佳的LLM(如o1-preview)显著超越了人类专家的最佳成绩。许多模型的性能也优于人类专家的平均水平。
  2. 领域表现不均
    • 模型在通用化学和技术化学方面表现较好。
    • 分析化学(如预测核磁共振信号数)、毒理学与安全性以及需要化学直觉/偏好(如药物设计中选择哪个分子)的任务上表现不佳,常与随机猜测无异。
  3. 知识依赖与局限:模型在知识密集型问题上仍有局限,仅依赖论文检索(如PaperQA2系统)无法弥补,需集成如PubChem等专业化学数据库。
  4. 自信度不可靠:多数模型无法可靠地估计自身答案的正确性,其提供的自信度评分往往具有误导性。
  5. 结构推理存疑:模型性能与分子复杂性指标无显著相关,表明其可能并非基于分子结构进行推理,而是依赖于与训练数据的接近程度。

结论与启示

前沿LLM在化学科学中展现了超越人类专家的潜力,尤其在处理大量文本信息和解答常规问题方面。然而,它们在需要深度推理、化学直觉、安全知识以及准确自我评估方面存在显著局限。

该研究指出:

  • ChemBench为系统评估化学LLM提供了必要工具,有助于推动模型发展。
  • 需要重新思考化学教育,应更注重培养批判性思维和复杂推理能力,而非单纯的知识记忆。
  • 未来需开发更好的人机交互框架,并增强模型的可解释性和可靠性评估。

数据与代码:ChemBench的完整数据和评估代码已在GitHub和Zenodo上开源。

28. UK unis to cough up to £10M on Java to keep Oracle off their backs (www.theregister.com)

英国高校签署高达986万英镑的Oracle Java订阅协议

英国高校和教育机构通过采购组织Jisc与Oracle签署了一项价值最高可达986万英镑(约1333万美元)的框架协议,用于购买其Java SE Universal Subscription许可。该协议包含一项关键条款:免除所有自2023年以来使用Oracle Java的机构的历史费用

此次协议的背景是Oracle在2023年1月对其Java许可模式进行了重大改革。新模式从基于用户的许可转向了基于员工数量的订阅制。Oracle当时称这是一种“简单、低成本的月度订阅”,涵盖桌面、服务器或云部署。然而,这一变革引发了行业专家和分析师的强烈反响。

成本大幅增加成为核心争议点。 根据许可顾问的早期计算,新方案可能导致某些客户的成本增加十倍。后续分析(来自Gartner)指出,对于大型组织而言,基于员工的订阅模式通常比传统模式贵两到五倍。Gartner分析师特别说明,Oracle对“员工”的定义非常宽泛,包括了全职、兼职、临时工、代理商和承包商等所有支持内部业务运营的人员。

业界普遍建议用户转向开源替代方案。 自新模式推出以来,Oracle用户一直被强烈建议迁移离开Oracle Java。一项调查显示,仅有十分之一的用户可能因许可变更而继续使用Oracle Java。此外,Oracle似乎正在全球范围内加强对Java使用的审计力度,有迹象表明Oracle正在各国组建专门的Java销售团队来识别和审计潜在用户。

尽管如此,英国教育机构仍选择了新协议。 Jisc未直接回应此协议是否由Oracle审计或审计威胁所导致,但表示该协议是与相关教育协会合作谈判的成果,旨在为成员机构提供“定制化服务”,简化许可流程并实现效率提升。这表明,对于部分大型组织而言,即使在成本增加和替代方案可行的背景下,与Oracle达成协议仍被视为一种降低复杂性和潜在法律风险的可行路径。

29. MUMPS (en.wikipedia.org)

MUMPS(马萨诸塞州总医院实用多编程系统),或简称为M,是一种命令式、高级编程语言,集成了事务处理键值数据库。它于1966年在马萨诸塞州总医院为管理患者医疗记录和实验室信息系统而开发。

核心技术特点

  • 范式与设计:命令式、过程式语言,无类型系统。命令和函数可缩写至1-3个字符以节省空间。
  • 集成数据库:提供层次化数据库,由持久化稀疏数组构成。以“^”为前缀的变量(全局变量)存储在磁盘上,可跨进程共享和持久化。
  • 数据模型:变量可有子节点(下标),下标可以是数字或字符串,自动按规范顺序(数字升序,后接字母序)排序。
  • 多用户支持:内置数据库锁、进程标识和事务原子性,支持多用户并发操作。
  • 简洁语法:行作用域和空格具有语法意义,支持后条件表达式控制命令执行。

历史与发展

  • 起源(1960-70年代):由Neil Pappalardo等人在麻省总医院开发,最初运行于PDP-7/9计算机。1977年成为ANSI标准(X11.1-1977)。
  • 标准化与厂商:1980年代多家厂商推出实现,如DEC的DSM、InterSystems的ISM、GT.M等。1990年代InterSystems通过收购成为主导,整合产品线推出Caché。
  • 名称争议:语言名称在MUMPS与M之间存在争议,ISO标准同时认可两者。MUMPS商标已于2003年过期。

应用与现状

  • 主要应用领域
    • 医疗健康:美国超过78%的患者健康信息系统(如Epic Systems)基于MUMPS,美国退伍军人事务部系统VistA即为典型。
    • 金融领域:用于银行和信用合作社,如英格兰银行、巴克莱银行。
    • 其他:欧洲航天局用于盖亚任务数据管理。
  • 现代实现
    • 商业产品:InterSystems IRIS(原Caché)、GT.M(现由YottaDB维护)。
    • 开源/其他:FreeM、Reference Standard M、MiniM等。
  • 影响力:虽非主流语言,但因其高效数据库集成和在医疗领域的深厚根基,仍在关键行业持续应用。