JavaScript™ 商标更新
6月18日，商标审判与上诉委员会（TTAB）驳回了我们针对甲骨文的欺诈指控。我们对这一决定表示反对。Node.js 从来都不是甲骨文的产品或品牌。
6月18日，商标审判与上诉委员会（TTAB）驳回了我们针对甲骨文的欺诈指控。我们对这一决定表示反对。
该指控称，甲骨文在2019年商标续展过程中，故意向美国专利商标局（USPTO）提交了Node.js网站的截图，以证明其对“JavaScript”商标的使用。作为Node.js的创建者，我对此感到特别冒犯。Node.js 从来都不是甲骨文的产品或品牌。甲骨文没有创建它，没有运营它，也没有被授权使用它来支撑其商标。他们 resort to a third-party open source site 表明他们没有更好的证据——而且他们知道这一点。
但欺诈从来都不是本案的核心。
我们不会修改欺诈指控。这样做会使案件拖延数月，而我们的重点在于最关键的指控：通用性和放弃。每个人都使用“JavaScript”来描述一种语言——而不是一个品牌。不是甲骨文的产品。只是世界上最受欢迎的编程语言。
案件现在将迅速推进。
8月7日，甲骨文必须对我们撤销申请的每一项内容作出回应——承认或否认我们关于通用性和放弃的主张。我迫切想知道他们会挑战哪些内容。
取证程序将于9月6日开始。
所有人都知道JavaScript不是甲骨文的产品——而19,550名javascript.tm用户也认同这一点（截至撰写本文时）。这个商标既不服务于公众，也不服务于行业，更不符合商标法的目的。它就是错误的。
如果我们赢得这次撤销——或者甲骨文做正确的事并释放商标——JavaScript将获得自由。不再有™符号。不再有许可担忧。它只是驱动网络的编程语言的名称，属于所有使用它的人。
本文由 TecHug 分享，英文原文及文中图片来自 JavaScript™ Trademark Update。
共有{335}条精彩评论
说句认真的，我们干脆把它改名为“WebScript”吧。WebAssembly、WebGPU、WebRTC、WebWorkers，这些都符合。而且似乎目前还没有活跃的商标注册(虽然我承认自己没有做过特别深入的搜索)。
“Java”这个前缀仍然会让新用户感到困惑，更不用说“bizdev”相关人员了，而且可能还会引发超越商标范围的法律问题。“JavaScript”这个名字一直都很糟糕，我们只是已经习惯了。我们为何要如此坚持？不如借此机会为它起一个真正有意义的名字。这或许会在未来几年带来些许不便，但我确信有一天我们会回首往事，难以置信我们曾称它为“JAVA Script”。
在 GitHub.com 上通过此 PR 进行重命名：
https://github.com/github-linguist/linguist/pull/7475
我突然意识到，“WebScript”实际上解决了另一个棘手的问题：描述人们在说JavaScript时所指的事物，与JavaScript在技术上实际是什么之间的区别。你看，从技术上讲，JS并不具备你习惯的半数功能，比如WebSockets、TextEncoder、fetch，甚至像URL类这样简单的东西。事实上，JS在技术上甚至不“完全”支持ESM模块，因为该标准的大部分内容已委托给其他Web平台API。
当然，这一切都有其合理性，但从最终用户的角度来看，URL不是JS的一部分，而encodeURIComponent却是，这确实令人困惑。而 Uint8Array 是 JavaScript 的一部分，但 TextEncoder 不是。但令人欣慰的是，随着非浏览器 JavaScript 运行时逐渐达成共识，它们应实现 Web 平台 API，因此作为开发者，你可以直接将 WebSockets 视为 JavaScript 的一部分。
但目前还没有一个好的名称来指代这组被普遍接受为“JavaScript”的标准集合。没有人会说“包含浏览器兼容模块和 WebWorker 扩展的 JavaScript”，甚至说“包含 Web 平台扩展的 ECMAScript”也显得过于冗长。但你知道什么能准确传达“你习惯在浏览器中使用的 ECMAScript”吗？WebScript。
这充分说明了不应使用ECMAScript，因为ECMAScript仍有其独立的含义。它是纯粹的语言规范。对于规范撰写者而言，这是一个有用的术语，但在其他场合则显得过于刻板。与此同时，“WebScript”正式化了人们过去有时(但并非总是)将“JavaScript”用于某些场景的做法，因此实际上确实为术语体系增添了“新实用性”，而非仅仅作为避免法律问题的同义词替代。
WebScript是苹果公司的注册商标[1]，但目前尚不清楚其可执行性如何。
[1]: https://www.apple.com/legal/intellectual-property/trademark/…
在USPTO上显示为无效：https://tsdr.uspto.gov/#caseNumber=75300777&caseSearchType=U…
我们应该直接使用ECMAScript。生态系统中很大一部分都使用esm、es5、es6、esnext等术语。
说清楚一点，我对这个没意见，但我觉得它不会流行起来。这个名字听起来有点别扭，它之所以存在，是因为同样的商标原因，因此从未被期望承担“营销”职责(有点像把WebWorkers改名为W3CWorkers)。
当然这只是猜测，但我认为人们会将我们试图切换到“ECMAScript”解读为一种不情愿的妥协：“所以我们就要让甲骨文独占JavaScript，只使用这个没有灵魂的规范名称？不行，我们应该为JavaScript而战！” 这感觉就像我们在“妥协”使用 SKU 编号，因为我们失去了名称(再次，由于规范名称的独特怪异，但在上下文中可以理解)。
换句话说，除了 WebScript 提供的“一致性”(如 WebWorkers、WebGPU 等)，它带来的另一件事就是仅仅是“某种新颖且不同的东西”。“嘿！让我们摆脱这场闹剧，这里有一个象征性的东西，代表着一个新的篇章，没有任何相关的包袱。”我主要是基于“html5”的经验，它在某种程度上解决了类似的非技术性闹剧，即W3C/WHATWG的戏剧。令人惊讶的是，一个新名称在为事情增添积极色彩方面有多么有效。
再次强调，我个人对ECMAScript并无异议，我只是认为让人们转向该标准的时机已过，如果我们要转向任何标准，目标应该是确保所有人都能接受。
tl'dr WebScript不错，易于记忆/识别，
我的补充：Oracle/JavaTM应该一如既往地消失并滚蛋
这会让招聘经理和招聘人员感到困惑。
“你的简历上写着你使用JavaScript/WebScript。你觉得你最常使用的是哪一个？”
你把它当作一个缺陷而不是一个功能来考虑。当HTML5发布时，每个人都期望它出现在你的简历上，就像其他流行术语一样。WebScript应该这样推广：热门新事物。经理们不会感到困惑(或者说，不会比平时更困惑)，他们会感到兴奋。而且，在科技史上第一次，人们将真正拥有五年使用今年发布的技术的经验。
哦，我最近主要使用ECMAScript。
这让我想起那位招聘人员：
- 我需要对你的技术进行快速调查，可以吗？
- 但你已经看过我的简历，应该很明显我是否适合吧。哎呀。随它去吧。
- 完美。你使用JavaScript有多少年经验？
- 老兄，真的？……我不知道，我从99年就开始用了。
- 完美。超过3年就行。接下来问题！
这是一个有趣的想法，但你认为这真的会发生吗？任何招聘程序员的人都应该知道这一点。
据我所知，现代招聘流程中，自动化系统会匹配确切的关键词，如果WebScript不在系统中，你就不会被匹配，而且没有任何人类会看到你的简历。
你肯定从未读过程序员职位的招聘描述
天啊，你上次找工作是什么时候？9个月前我还在面试时听到招聘人员说“这个职位需要Java，所以你很适合”，尽管我的简历上写的是JavaScript。
哇，这可不鼓舞人心
哦不！不过……
我本来想建议直接恢复它原来的名字LiveScript，但看起来它已经被CoffeeScript的创建者开发的一种语言所取代。真没礼貌。
在我职业生涯早期，2000年代初，我被指派现代化一个拥有大量
我刚才的谷歌搜索显示，可能只有一个Netscape的公开测试版曾使用过这个名称。真奇怪。
我认为CoffeeScript的创建者(Jeremy Ashkenas)从未直接参与过LiveScript。LiveScript是从Coco分支出来的，而Coco又是从CoffeeScript分支出来的。
维基百科声称Ashkenas参与过[1]，但LiveScript官网并未列出他[2]。
[1] https://en.m.wikipedia.org/wiki/LiveScript_(programming_lang…) [2] http://livescript.net/#thanks
就像 WebAssembly 在 Cloudflare 上运行，或 WebGPU 在 Bevy 上运行，与网页浏览器有何关联。
我的意思是……甲骨文公司是否曾就使用“Java”这一术语咨询过雅加达政府？那里有超过1亿人，我们却在争论一个编程语言名称的含义，而这个名称又与另一个编程语言的名称有关，后者的名称又与某人的岛屿有关，而这个岛屿实际上与一些程序员喝的咖啡有关，他们觉得Jolt Cola太微软了，不如新鲜烘焙的咖啡豆酷(……在1996年)。
但WebScript我倒是可以支持！(如果案件失败的话)
我同意甲骨文的案件毫无依据，原因多种多样。但时间投入是不对称的。他们可以拖延时间，可以让几乎肯定对这种语言离奇命名历史一无所知的法官感到困惑，而且他们没什么更好的事情可做。甲骨文可以派出100名可互换的律师来处理此事。与此同时，这正在消耗像瑞安·达尔这样的独特个人的时间。他的注意力被此事分散，这真是一场悲剧。
但这尤其如此，因为JavaScript 甚至不是一个好名字。如果这个名字很棒，那么基于原则反对它还说得过去，但它不是。事实上，这个名称最初就是因为其容易引起混淆的特性而被刻意选择的——不幸的是，JavaScript 正是利用了当时正火的新技术 Java 的热度而被选中的。从一开始，这便是一个糟糕的主意。如今，没有人会建议我将一种与之无关的新编程语言命名为“SwiftScript”或“RustScript”以借用这些语言的 popularity。这既俗气又短视。如果只是单独改变，是否足够俗气？不，这只是科技文化中又一个不幸的例子，就像“referer”只有3个r而不是4个r一样。但如果我们面临一个针对某位在法庭上以固执闻名的被告的重大案件，这绝对足够俗气到值得放弃。甲骨文公司没有人会为此思考超过5分钟，而这正给瑞安和半数JavaScript社区带来巨大困扰。为何要让他们得逞？让甲骨文公司拥有所有与Java相关的糟糕商标吧。我们甚至没有让他们赢得任何胜利。一旦我们都切换到WebScript，JavaScript商标将变得一文不值，而且作为额外福利，它甚至不会意外地为他们的其他技术(如JavaScript今天可能做到的)提供任何免费的营销。他们的奖励可以是进一步走向 obscurity，自行从他们目前在网络历史中不应有的出现中剔除自己，每当提到JavaScript时。
完全同意！大约20年前，当我刚开始接触JS时，就无法理解这个可悲的名字。为什么要在里面加上Java？
我个人非常讨厌这些奇怪的、书呆子气、愚蠢的名字。Gimp，有人用过吗？像GNU这样的递归首字母缩写，有人真的觉得这很有趣吗？
我支持，我喜欢Web Script。
> 说正经的，我们干脆把它改名为“WebScrip…
这成功的几率大概和Twitter的重新品牌化一样高
所以你是说有机会
据我所知，甲骨文公司并未从JavaScript的名称或品牌中获利。我看不出来为什么要为这场诉讼辩护。他们有机会在这里创造一些善意，召开一场新闻发布会，说“我们将JavaScript商标赠送给开发者社区！”但他们却在为一件他们根本没有从中获利的事情辩护。这太荒谬了。
> 他们有机会在这里创造一些善意
根据布莱恩·坎特里尔的说法，你不需要对甲骨文保持开放态度。这会浪费你开放的心态。他说你对甲骨文的看法甚至比你想象的更真实。他认为人类历史上没有哪个实体比甲骨文更缺乏复杂性和细微差别。
布莱恩警告说，“不要陷入将拉里·埃里森拟人化的陷阱。你需要像看待割草机一样看待拉里·埃里森。你不会拟人化你的割草机，割草机只是割草。你把手伸进去，它就会切断你的手，就这样。你不会想‘哦，割草机讨厌我’——割草机不在乎你，割草机无法讨厌你。不要把割草机拟人化。不要陷入关于甲骨文的那个陷阱。”
https://www.youtube.com/watch?v=-zRN7XLCRhc&t=1981s
这太对了。根据我的经验，甲骨文的主要业务似乎是让公司签署复杂的合同，等待一两年，然后以某种违规行为为由起诉他们，以便从他们那里勒索另一份合同。我还没有遇到过甲骨文的产品，不能被自由软件或一家不太喜欢打官司的公司做得更好。
我个人得出结论，每一个重大的开源或免费软件成功故事背后，都存在一个完全失灵的市场。没有这种情况，就不可能找到足够多的人愿意说：“去他妈的，我们自己重新编写这个。”
有这么多人有动力去编写甲骨文产品的替代品，这充分说明了甲骨文的商业行为。
我所知道的唯一一款优秀的SQL工具，在编译器、调试器、集成开发环境(IDE)方面表现出色，就是MS SQL Server。
像分布式事务、数据库的原始磁盘访问等功能，那些转向Postgres或MySQL的人可能从未听说过，但许多《财富》500强企业都在使用，即使只是为了在 RFP 中勾选项目。
Postgres排在第二位，在整合所有功能模块后，其中部分模块也需要商业授权。
我们从Azure上的MSSQL迁移到了Oracle。如果Azure是硬性限制，我们应该选择什么替代方案？
例如Postgres或MySQL。
我们的用例主要用于分析。我们已经使用Postgres处理其他工作负载。
那可能是DuckDB吧？
博通已加入讨论。
令人震惊的是，停止令和审计通知正成为惩罚他人不续签合同的常见手段。
前Twitter公司正在起诉那些在平台上广告支出不足的客户。
科技公司和寡头们真是目中无人。
这是极端的夸张。我与甲骨文毫无关联。
我最乐此不疲的事就是听 bcantrill 贬低甲骨文。每当他在演讲或播客中提到甲骨文，我就知道有精彩内容可听。
血液病原体？
https://news.ycombinator.com/item?id=35908391
GP从纯粹机械、非人类的角度指出，甲骨文的行为毫无逻辑可言。
Oracle会保护自己的财产，无论是否合理。这就是机器的运作方式。
割草机割手也不“合理”，毕竟它不是绞肉机。然而它是一把刀片连接在电机上，从纯粹的机械角度、非人类的视角来看，它会切割任何进入其范围内的物体。
它们确实会这样做，如果割草机认为“更多商标更好”(而哪家公司不这么认为呢？)，并且商标必须被积极使用和维护才能保留。
就像现实世界中的所有机器一样，甲骨文的机器智能是有限的——它无法对每一件事都进行无限细节的处理。“更多商标更好”和“商标必须积极使用和维护才能保留”是经验法则，如果在前者加上“平均而言”，就能很好地解释这一点。
这是我最喜欢的演讲之一！太棒了。感谢布莱恩·坎特里尔！
显然并非所有人都收到了《割草机备忘录》，因此感谢你再次发布，作为提醒那些像sprash这样认为我应该“真诚地询问是否允许发布[NeWS源]代码”的人。仿佛真诚能有所帮助，而我自1986年以来一直都在真诚地询问。
我也会真诚地问：甲骨文公司有人知道如何联系他们的HR部门，以了解我的Sun 401k计划究竟发生了什么吗？因为没有人接我的电话，而那是一大笔我的钱加上33年的利息，他们欠我的，他们从Sun继承了这笔钱，然后从所有已知记录中消失了(除了一个记录显示它曾经存在且Oracle拥有它，但没有其他信息)，他们不会接电话或回复我的邮件，无论我多么“真诚” 我请求或等待多长时间。
https://news.ycombinator.com/item?id=44370636
sprash 4天前 | 父级 | 上下文 | 标记 | 收藏 | 主题：古老的X11缩放技术
> 1994
显然，你已经批评X11超过三十年了。既然你似乎很了解这方面，能否请你提供一个链接，指向你个人开发的显示服务器仓库，该仓库解决了所有问题？
DonHopkins 4天前 | 上一页 | 下一页 [–]
自甲骨文收购太阳微系统公司后，甲骨文现已拥有NeWS源代码的版权，因此我无法在GitHub页面上发布NeWS服务器源代码，尽管我多年来一直努力争取让NeWS开源并向任何愿意倾听的人推广它，比如RMS以及我在太阳微系统公司的同事和客户：
https://www.donhopkins.com/home/archive/NeWS/rms.news.txt
https://www.donhopkins.com/home/archive/NeWS/news-ooo-review…
https://www.donhopkins.com/home/archive/NeWS/questionaire.tx…
https://www.donhopkins.com/home/archive/NeWS/grasshopper.msg…
https://www.donhopkins.com/home/archive/NeWS/sevans.txt
https://www.donhopkins.com/home/archive/NeWS/Explanation.txt
[…]
sprash 4天前 | 父级 | 下一条 [–]
> Oracle拥有NeWS源代码的版权，所以我不能把它发布到我的Github页面上。
他们现在肯定没有从中赚钱。所有专利都应该已经过期了。你有没有认真问过是否可以发布代码？[…]
DonHopkins 4天前 | 根目录 | 父级 | 上一页 | 下一页 [–]
[…] 哈哈！祝你好运，小伙子。你试过向割草机寻求帮助吗？你真的认为“诚意”会有所帮助吗？
https://news.ycombinator.com/item?id=15886728
https://youtu.be/-zRN7XLCRhc?t=33m1s
[…]
哈哈哈哈哈
他们只需将CDDL更新为允许将ZFS与GPL集成，就能一举修复90%的品牌损害，据我所知这也不会让他们付出任何成本，但我们都在犯将割草机拟人化的错误。
忽略Sun/Oracle在ZFS上的操作几乎无法解释“90%的品牌损害”……
> 只需更新CDDL以允许将ZFS与GPL集成
目前这已无法实现。由于2016年在HN上的一次讨论中做出的决定，ZFS维护者采纳了一项政策，对新源文件放弃CDDL内置的“任何后续版本”条款：
~/scratch/zfs$ grep --exclude-dir=.git -Ire “Common Development and Distribution License” -A 2 | grep -ie “(Version 1.0 only|<only>.*<version>)” | wc -l
821
(CDDL 是一种基于文件的许可证。在做出该决定时，源代码树中已有大约一百个 CDDL 许可证的文件被指定为仅在“版本 1.0”下可用。)
> 他们可以逆转 90% 的品牌损害
他们的股价比一年前高出 50%。
不确定这是否对他们造成损害。
在未被迫的情况下做出让步可能被视为软弱。从这个意义上说，展现一丝人性可能反而会损害他们的股价。
我的猜测是，那些有权打破协议的人太忙了，无暇处理打破协议的请求。忙得连想都不想。
而任何对请求表示同情的人都清楚，为打破协议而游说需要扰乱他们之上两到三个管理层级，迫使有权势的人处理他们不关心的事务。这会被解读为浪费重要人物的时间。
因此，作为决策实体的组织，根本无法识别，更不用说考虑，对默认行为的例外请求。
我曾与一家长期采用这种运作方式的企业合作。即便存在压倒性的理由需要打破流程，那颗火花与引火物也从未接近过。
在火花与引火物之间，每个人都表示同情，与“某人”沟通以证明自己“努力过”，并为接下来不可避免的“拒绝”回应制造借口，同时暗中竭力扼杀那颗火花，以免被其烧伤。
感谢你如此生动地描述这一现象，我认为这是大型企业普遍存在功能失调的根本原因。
萨蒂亚通过努力支持开源项目来重塑微软的人性化形象，这确实提升了微软的公众形象
微软的“核心DNA”仍然牢固存在。
他们成功地将开源武器化，通过免费提供某些东西，然后一步步收回(例如关闭开源的VSCode插件)，同时留下那些最有效地淹没竞争对手的部分保持开放。
他们还声称他们的开源代码是“免费的”。他们牢牢控制着它，却装作不控制。
在我看来，微软的形象丝毫未见改善。
> 他们还假装自己的开源代码是“免费的”。他们牢牢控制着它，却装作不控制。
他们对社区的反馈很积极，并合并社区的PR。这已经比SQLite等项目更“开放”了。
当然，他们不授予合并权限，并保留对上游代码的独家控制权。但有多少“开源”项目有第二个维护者？我的意思是，除了原始作者之外，还有其他人拥有合并权限。
代码是免费的。你可以随时分叉它并按需使用。这始终是开源项目的基本原则。
当然，如果上游维护者始终只做你喜欢的事情，你无需分叉，那当然很好。但这是一种独立的品质，与代码本身是否“免费”或“开放”无关。
> 他们通过免费提供某些内容并逐步收回(例如关闭开源的 VSCode 插件)，成功将开源武器化，同时保留那些最有效地压制竞争对手的部分。
这就是为什么人们应该推动自由软件，而非开源软件。
在这一领域浸淫 20 年后，我最终认同了史蒂夫·鲍尔默的观点：开源是癌症。
看看ElasticSearch和Redis的境遇有多糟糕，再看看Grafana(其软件是自由软件——而且非常出色)的现状。
这一点如此真实，以至于Redis并未回归“开源”，而是成为了自由软件(AGPL)。
是的，但微软在那里的做法也是两步前进，三步后退。比如在锁屏界面强行推送产品广告，以及预装《糖果粉碎传奇》等行为，这些举措让微软失去的用户好感远超任何面向开发者的努力所带来的收益。
这一举措尤其伤害了那些身处Windows生态系统内部的人。对于像我这样的人来说，微软只是某个产品的友好作者。我指的是VS Code。
越来越多的VS Code不再是开源的。微软自家的语言扩展已经锁定功能有一段时间了，而每次这样做，许可证也会禁止在任何VS Code分支上运行它。
以及其底层的Monaco编辑器。
由于 Oracle 不涉及 B2C 业务，公开成为净负面租金寻求者不会造成品牌损害。租金寻求正是股东所渴望的。它能让利润曲线上升，具有电解质效应。
这仅在短期内让利润曲线上升。长期来看，企业将避开 Oracle，销售额将下降。但股东并不关心长期影响。
甲骨文已证明其长期价值，其股价从未如此之高。其销售额终于再次回升。作为软件行业最古老的公司之一，即将迎来50周年纪念。在该行业中，还有什么比他们取得的成就更具长期性？
目前，他们的市场地位比过去10-15年中的任何时候都更有利。
公平地说，也许他们确实开发了优秀的企业数据库软件。他们的成功一定有其他原因，而不仅仅是锁定效应。
只要确保不要进行基准测试。与竞争对手比较是严重违反合同的行为。
甲骨文并非一段虐待关系，只是你不应另寻他处，违规行为将受到惩罚。他们对审计非常重视。
这听起来绝对荒谬，但你让我去查证，结果似乎有点道理 😀
这是关于此案的HN帖子快捷链接，供像我这样未听说过此案的人参考(假设这就是你所指的)：
https://news.ycombinator.com/item?id=15886333
也许他们会将部分租金投入到垄断策略和微小改进中，以保持甲骨文对高风险客户的吸引力。
不过我希望我是错的。
> 他们的股价比一年前高出50%。
特斯拉股价比一年前高出63%，这是否证明了他们领导层的每一项决策都对利润有帮助？
这表明，那些本应重要的事情，并不总是重要的。
我相当确定购买甲骨文股票的人正是看中了它作为一家公司的真实面目。
> 只需更新CDDL
有没有更简单的解决方案，直接将所有内容重新授权为BSD/MIT许可证？
目前，除了越来越少的甲骨文Solaris客户外，所有人都使用的ZFS版本——OpenZFS——自2010年甲骨文关闭OpenSolaris以来，一直完全独立于甲骨文进行维护。这意味着甲骨文重新授权ZFS并不会有助于将其集成到Linux内核中，因为自那时以来，已有数百名独立贡献者参与了ZFS的开发，且他们各自拥有自己的版权。由于ZFS采用CDDL许可证，该许可证包含自动升级条款，因此如果甲骨文希望使ZFS能够被纳入Linux，他们只需复制粘贴GPLv2许可证文本并将其命名为“CDDL v2”即可。
别急。
https://news.ycombinator.com/item?id=44409160
哎呀 🙁
完全更换许可证而非在现有许可证中添加一句内容，无论是从语言学角度还是获得其庞大律师团队的批准，都并非更简单。
这同样不更困难。两者都需要获得所有过去贡献者的同意。
我认为有些项目过去确实做过类似操作，但可能没有哪个项目是由大型公司拥有大部分代码版权的。
> 他们只需将CDDL更新为允许将ZFS与GPL集成，就能一举修复90%的品牌损害
ZFS可在Linux下运行——将Linux内核与ZFS结合是两项独立作品的集合(集体作品)。
然而，重新分发这种组合是不合法的。这意味着Linux发行版无法预装OpenZFS：每位用户必须自行整合两者。
(这并不一定阻止人们这样做，但Debian将其视为“足够非法”以至于在安装OpenZFS时会显示一个提示屏幕，告知用户将失去重新分发的权利。)
谁会提起诉讼，又会在这种情况下证明哪些损害？Linux 和 ZFS 的源代码均可获取，且您被允许并鼓励自行构建和使用它们。重新分发二进制文件可以视为缓存预编译的构建成果，仅仅是加速了您本可以手动完成的操作(且通过可重复构建，结果应完全一致)。没有人会因此蒙受损失。
假设我开发了一款神奇的编译器，能够在毫秒内编译出 Linux+ZFS 内核。我将其置于一个网页界面后端，该界面接受 Linux 压缩包和 ZFS 压缩包，并输出编译后的内核。由于某个我仍在尝试解决的神秘 bug，仅特定的 Linux 和 ZFS 压缩包能正常工作，因此我添加了验证机制，通过哈希上传的压缩包，仅放行已知可用的版本。
让我们揭开面纱：实际上并不存在神奇的编译器，整个过程只是对输入的内核和ZFS源代码tarball进行哈希计算，将其作为预编译二进制文件缓存的查找表，然后输出匹配的二进制文件，而目前这种做法是不被允许的。但假设编译器确实存在，那么这种做法是可行的，尽管系统的功能与之前并无差异。
如果其中一个许可证明确限制了分发现成二进制文件的权利，以建立护城河确保作者是唯一能这样做的人(从而收取费用)，我还能理解。但这里并非如此，无论我手动构建还是复用他人之前的构建成果，对任何人都没有优劣之分。
这将由自由软件基金会(FSF)提起诉讼，因违反GPL许可协议构成版权侵权。(严格来说应由Linux内核基金会提起，因其是版权持有者，但FSF通常会参与此类诉讼以保护GPL。)无需证明侵权损害，此类侵权行为存在法定(推定)损害赔偿。
他们会这样做吗？这取决于对GPL违规行为实施可信威胁的重要性。但风险并非零，且这显然构成违规。这足以吓退大多数主要发行版——若收到停止侵权通知，他们将不得不回溯性地推送重大变更。风险不值得承担。
他们是否有起诉的动机——即这如何促进软件自由？
这似乎只会让Linux+ZFS的使用更加麻烦，最终 everyone 都会受损。
许可证在技术上不兼容，但这并不意味着双方通过起诉能获得任何好处？
ZFS在Linux的HPC环境中广泛使用(https://computing.llnl.gov/projects/openzfs)。要求用户单独安装ZFS对ZFS的目标受众来说真的那么麻烦吗？
脱离内核树意味着内核重构会破坏ZFS，且其可用于修复需要内部设计更改(而非临时补丁)的漏洞的开发资源和审查力量大大减少。
大多数人不会盲目使用最新内核。我认为在稳定发行版上从未遇到过内核外模块的问题。
要求单独安装文件系统是个大问题。这会严重限制文件系统的使用方式。
为什么他们要这样做，而不是保持现状，这对于他们的律师来说是一个未来的礼物？
我不会将甲骨文与善意联系起来，我也不认为他们会在乎。
甲骨文的官方立场是CDDL与GPL兼容，无需进行任何更改。
当他们在法庭上作证并确立了法律先例时，我才会考虑这种可能性。
不，他们做不到。甲骨文此时采取的任何措施都无法挽回其品牌造成的损害，否则你就是个傻瓜。
如今，它是一家律师公司，而非科技/软件公司。其存在的唯一目的是尽可能长时间地继续出售其拥有的软件许可，因此他们紧紧抓住任何能抓住的东西(无论实际价值如何)是再自然不过的。
这是一家拥有多个部门的大型公司。
甲骨文是即时编译器、垃圾回收器和语言解释器领域的领先研究者。
我的一部分认为，这只是甲骨文版的清洁工和餐饮服务人员，是那些需要留下来确保公司利润创造者(销售人员和律师)能高效工作的员工。
是的，与其他公司不同，甲骨文不会将技术人员视为可有可无的附庸。因为在行业中，从技术工作中获利是不可想象的。
我真的看不出来这两者有什么关联。
我绝不会雇佣简历上写着Oracle的人。在那里工作所需的完全缺乏道德感，足以让人立即失去资格。
我觉得你持有这种观点有点可悲。在OpenJDK上工作的工程师们真的完全缺乏道德感吗？
在Oracle工作与在Facebook或Google工作相比如何，后者拥有所有侵犯隐私的技术？
甲骨文曾试图通过主张Java的ABI受版权保护来使清洁室逆向工程非法化，尽管整个行业都依赖于这种情况不成立，这一切都是为了让拉里·埃里森能再买一艘游艇。所以，有人在Java被地球上最邪恶的公司之一收购后继续参与Java开发，显然是在有意识地选择让世界变得更糟，因此不应再被雇佣。
Facebook也在我的个人黑名单上，没错。我对谷歌的看法没有那么强烈，但如果招聘团队的其他人认为这是 disqualifying 的，我也不会反对。
严厉，但可以理解。对于刚毕业的应届生，我会破例。他们可能还不知道更好。但如果有人在加入拉里(指甲骨公司创始人)之前曾为甲骨文的客户工作过，我会认为他们就是魔鬼的化身。
我憎恨甲骨文，我认为没有多少公司能像他们一样邪恶。如果他们倒闭，我一定会感到欣喜，当然这是比喻的说法。
但话说回来，我认为仅凭简历上有甲骨文的工作经历就草率下结论是愚蠢的。你至少应该问他们为什么在那里工作，以及为什么离开。说不定他们刚开始时并不知道甲骨文有多糟糕，后来看到他们的邪恶本质才离开。这种人正是我想要聘用的
当年甲骨文收购太阳微系统时，他们告诉我们“太阳微系统的律师人数比我们多”
对这一事实和指标的解读以及为何需要说明这一点，我留给你自行判断
他们有律师需要证明自己的薪资合理性。此外，他们为何要无偿放弃某些东西？这就是“市场力量”在起作用。
我认为这是关键。当你雇佣人们去做工作时，他们会找到事情来做，即使这些事情并不真正必要或对公司长期有利。
我最喜欢的另一个例子是，当我看到一个用户界面重新设计，实际上并没有给任何人带来好处，更多的是风格上的改变，有时甚至会主动降低可用性(咳嗽 Liquid Glass 咳嗽)。在这种情况下，我总是想“嗯，一些内部设计师需要证明他们的薪水是合理的”。
这些都是代理问题导致的结果
https://www.investopedia.com/terms/p/principal-agent-problem…
我认为这实际上与代理问题略有不同，至少与通常描述和设想的代理问题不同。
例如，当人们思考委托代理问题时，常常会想象这样的情景：一位经理做出决策，导致股价短期内上涨(并为经理带来奖金)，却损害了公司的长期健康。然而，在我所考虑的案例中，更常见的情况是，人们很少能什么都不做，即使有时这可能是最好的选择。例如，大型公司需要雇佣律师和设计师，原因有很多。但有时这些人的工作量不足(即使他们需要保持“待命”状态以应对重要工作)。如果没有足够的工作可做，这些人就会自行寻找工作。
这也是为什么我认为，尽管裁员令人痛苦，但让员工在没有明确方向和目标的情况下“无所事事”对所有人来说都是最糟糕的。这些人会安排会议、插手不必要的事务等，只是为了显得自己有事可做。
这可以被视为“委托代理问题”的一种变体，但我认为这种“闲置的双手是魔鬼的玩物”的现象与“标准”委托代理问题差异足够大，因此不应将两者混为一谈。
> 但有时这些人的工作量确实不足(即使他们需要保持“待命”状态以应对重要工作)。如果工作量不足，这些人就会自行寻找工作。
在公司内部，可以在不同领域为这类过渡期找到工作。
例如在我工作的公司，一位(非常能干)的秘书，其原有角色已不再需要，但未来存在一个非常适合她的角色，因此在过渡期被安排协助其他部门向监管机构提交报告。
并非所有员工都愿意制造麻烦，四处打听并冒着被视为多余的风险。始终表现得——或告诉自己——每项落在你桌上的任务都需要全力以赴，这样风险更小。
我认为这在大型企业中尤为真实，这些企业中真正有意义的工作寥寥无几，而那些真正关心做有意义工作的人早已离开很久。
这甚至无法证明他们的薪水是合理的。律师的唯一职责就是尽可能热忱地为客户的法律立场辩护。一位真正优秀的首席法律顾问会去找CEO，权衡“输掉”此案在营销上的利弊。一个只会机械执行任务的律师，会不顾一切地提交任何必要的(甚至不必要的)文件来打官司，即使这完全没有意义。例如，因偷了一片披萨而判处某人25年监禁。
> 他们为什么要放弃一些东西却一无所获。
因为这毫无价值，而且维持它需要成本。
善意并非“一无是处”，但要向律师解释这一点可就难了。
他们聘请了外部律师代理此案。
割草机无法关心善意。
引用布莱恩·坎特里尔？https://www.youtube.com/watch?v=-zRN7XLCRhc&t=2302s
所有在网上热衷于维护大型公司声誉的人都应该看看并理解这一点！公司不是有感情和同理心的人类。它们都是割草机。它们恰好由人组成并不改变它们的本质。
我不是来嘲讽布莱恩或Oxide的，但你的同一条“规则”不也适用于Oxide吗？
如果你之前没看过，从34:05开始看值得一试。
关于Java许可证状况的混淆就是另一个例子。
我认为割草机比喻从未准确过，也从未帮助理解过。
甲骨文是一只鳄鱼或一条蛇。一种爬行动物。如果你移动，它很可能会活活吃掉你。它想吃掉你，或者你的一部分。
它也生活在水坑里，囤积一种必需资源。不是守护或开发它，只是坐在那里。
它古老而永恒，永远不会改变。
鳄鱼作为捕食者并非它的错。这是它的本性
我能想到的唯一合乎逻辑的理由是，他们刻意不想要任何善意，而是想维持自己作为无情诉讼者的声誉。
从商业角度看，这是错误的观点。他们并未直接从授权或支持中获利，但他们获得了免费广告。
他们交出名称和品牌毫无收益——事实上会失去宝贵的品牌认知度。
显然业内大多数人对他们深恶痛绝(见本帖为证)，但许多人认为这种关联至少表明他们对该产品线具备一定专业性。我当然不认同他们的立场，但从商业角度看确实有道理。
品牌认知度针对的是什么？
没有人会想到Oracle与JavaScript有关。
事实上，对我来说，今天是我第一次知道Oracle与JavaScript有任何关联。
Oracle收购了Sun，而Sun收购了Netscape。我不得不查证。
编辑：更完整的历史 https://news.ycombinator.com/item?id=44408760
他们如何会失去品牌认知度，当大多数人并不将JavaScript与甲骨文联系在一起？我唯一与甲骨文关联的语言是Java。
甲骨文是一家出售知识产权的律师事务所。他们宁愿控制并扼杀JavaScript这个名称，也不愿让人们在没有他们控制的情况下使用它。
甲骨文在做一些琐碎而荒谬的事情？你确定吗？
你说什么！
“撕得粉碎，你说？”
据我所知，甲骨文并未从JavaScript名称或品牌中获利。
目前虽是如此，但其所有权和过往行为表明，若Deno或其他方尝试推出付费服务，甲骨文有非零概率会来觊觎这笔轻松钱。
这可能是一种条件反射。我猜这已经深入他们剩下的灵魂之中。
如果被问及，法律团队可能会简单回答“这是既定政策”。
“灵魂”？甲骨文从一开始就没有灵魂。
无需“赠送”它。最好是没有人拥有该商标。将其置于公共领域。
不过我也不确定这在美国法律下是否可行。
难道整个原因不是因为他们资助了JavaScript，为了保护Java的商标，他们才继续维护它以防万一吗？我认为这就是最简单的答案。如果有人知道不同情况，请随时指教。
他们通过与Java的混淆来获利。
> 他们有机会在这里建立一些良好声誉
据我所知，这是此类事件的首次发生。我编程已有20年，从未听过有人对甲骨文说好话，除了他们免费的托管层 _是免费的_。迟到总比不到好，我想！
甲骨文为何能声称拥有这个商标？他们从未创造过它，是网景公司创造的。甲骨文收购了太阳微系统公司，本可以因将JavaScript命名为Java而挑战网景公司，但我认为他们从未这样做过。
“企业善意”是个矛盾修饰法。
这是“避免声誉受损”的委婉说法。
你刚才在同一句中用了“甲骨文”和“JavaScript”，看来对他们来说强化品牌是有用的。
认为押注于一家巨型无面公司的人性是明智之举的人，真是愚蠢。
“甲骨文”和商誉不是一回事。
几乎就像他们不是很聪明的人！
我明白对甲骨文的憎恨，但别忘了伟大的太阳微系统公司在90年代末至21世纪初针对微软在Java问题上使出了浑身解数。
那么，“X滥用知识产权法”的憎恨是出于原则，还是因为人们似乎对太阳和谷歌情有独钟，而憎恨甲骨文和微软？
因为微软试图接管并改变Java，而太阳公司实际上创造了Java。这与当前情况有何相似之处？
具体来说，这就是为什么Internet Explorer有“JScript”。微软对Java做了坏事，失去了商标许可。
不要拟人化割草机。
甲骨文并未从中获利，但对JavaScript商标的使用也基本保持中立。
“开发者社区”往往无中生有地制造问题，而我对此并不喜欢。
在此情况下，我支持甲骨文。
> 在这种情况下，我支持甲骨文。
仅仅是因为你不了解商标。商标不是版权。
商标的存在是为了保护消费者，以免他们将名称或品牌过于相似的公司和产品混淆。因此，有人不能以$600的价格发布名为iPhona的产品，寄希望于有人会忽略拼写错误并订购它而不是$600的iPhone。
如果一家公司没有基于商标提供产品，该商标应主动移除。甲骨文并未使用JavaScript商标。
将甲骨文与“商誉”放在同一句中令人发笑。
律师们需要找点事做。
有很多有用的事情可以做。可惜他们没有因此获得报酬。
是的，他们可以起诉孤儿院或促进原始雨林中露天矿的开发。
说实话，甲骨文公司是有效利用优秀法律人才的容器。
我感觉很多大公司以这种方式有效地充当了优秀劳动力的容器。这感觉像是一种阴谋，但对我来说这并不合理。
甲骨文是一家律师公司[0]. 商标和专利是律师的武器。你不会把核弹头捐给敌人。
[0] https://www.globalnerdy.com/wp-content/uploads/2011/07/oracl… (找不到原版XKCD，抱歉)
感谢所有参与这项工作的人。几十年前，甲骨文曾为科技生态系统增添价值。如今，它已成为一个庞大的租金提取巨头。我讨厌2025年我们无法拥有美好事物，仅仅因为甲骨文拥有知识产权。甲骨文就是当企业变得懒惰，仅仅因为“没有人会因为购买/雇佣_____而被解雇”就将品牌名称的控制权交给他人时所发生的事情。我希望那些日子已经过去。
太阳微系统公司确实增添了价值，而且是大量的价值。
甲骨文的贡献则不那么明确，尤其是如果你不计算所有收购的“成就”。
太阳微系统公司做工程，甲骨文做生意。
我敢肯定甲骨文不会轻易放弃商标权。他们有自己的一套方法来摧毁开源项目。
甲骨文的工程技术做得很好，而且他们至今仍屹立不倒……或许太阳微系统做错了什么
工程质量与生产该工程产品的公司存续时间毫无关联。
从对整个社会有用性的角度来看，许多企业本不应永远存在——甚至不应存在太久。施乐帕克研究中心(Xerox PARC)、柯达(Kodak)和网景(Netscape)就是例子，这些公司(或在帕克研究中心的情况下，是一家公司的一个部门)在各自领域做出了重大贡献，随后却走向衰落。这些贡献并未因创造它们的公司消失而变得糟糕或低劣。
一家公司是否仍在运营，仅仅表明它是否擅长维持自身生存。随着时间的推移，这种能力与公司是否生产有价值的商品或服务之间的关联性越来越弱。
只有当工程能力与赚钱能力之间存在一一对应关系时，这种关联才成立，而你肯定已经知道这种情况并不存在。
甲骨文公司的工程质量参差不齐，甚至整个部门都可能生产出垃圾产品，因为资历完全压倒了才能。甲骨文云(Oracle Cloud)拥有优秀的工程团队(尽管我认为如今它们正受到官僚主义和错误的节俭政策的严重阻碍)，但除了OCI和少数几个精选部门外，情况堪忧。
在我所在的部门曾有几次招聘紧缺，领导层的短期解决方案是从其他部门寻找可以“借调”给我们的员工。这些员工的质量普遍低得令人震惊。我不得不进行代码审查，他们会做一些初级开发人员毫无标准的荒谬操作，导致他们的代码提交被反复拒绝，因为他们不仅做出愚蠢的决策，甚至不理解这些决策为何愚蠢的解释。这令人愤怒且浪费时间，第二次尝试时，我们试图表示不希望这种帮助，但领导层坚持认为免费人力并非可选项。
这种借调人力并非免费，尽管管理层仍抱有这种幻想。借调人员有成本，包括前期成本(入职培训、指导、评估等)和持续成本(团队中缺乏对新代码的有机专业知识、维护次优或不一致的代码等)。但这些成本在资产负债表上并不明显，所以想说服别人它们存在可就难了。
谁负责Java API的更新？
真怀念Sun Microsystems的产品。
没有一家公司愿意收购Sun，尽管Google用Android(即Google的J++和.NET)将其击垮。
若非Oracle，Java将在版本6时消亡，而其他任何情况会如何发展尚不可知。
但太阳公司是否在JavaScript方面做过任何贡献？
这个名字，最初打算命名为Livescript。
那些日子可能永远不会过去，因为公司内部的激励机制让员工变得保守。
甲骨文公司何时曾为技术生态系统增添过任何价值？
如果这是个诚恳的问题而非仇恨言论的开端，让我们思考一下……
无论是Java语言还是OpenJDK(主要运行时及开发工具包)，在甲骨文公司接手后投入的资金和人力都远超以往。两者在甲骨文收购前几乎濒临死亡，但收购后仍保持快速发展。
MySQL 8(2018年发布)是一个重大版本，为数据库带来了许多备受期待的功能(如CTE)，尽管过去几年MySQL的开发进展缓慢。
甲骨文雇佣了多位 Linux 内核开发者，并是主要贡献者(尤其在 XFS 和 btrfs 文件系统方面)：https://lwn.net/Articles/1022414
虽未进入前三大或前十名，但已优于大多数企业。
这就是我能回忆起的全部内容。
编辑：再思考了几分钟后，他们还是GraalVM的主要开发者——这是唯一一个高质量的开源AOT编译器(Java)，(也如其他评论所提)，并且正在开发Spring的主要轻量级现代替代方案之一(另外两个是Micronaut和Quarkus)：https://helidon.io
还有VirtualBox(继承自Sun)。可能还有其他一些东西。不过据我所知，如果你被怀疑使用了专有“扩展包”功能，可能会遭到甲骨文销售人员的猛烈推销。这种情况正是我为何会慎重考虑使用甲骨文任何产品的原因。
我曾经犯过一次使用VirtualBox的错误——再也不用了。我不知怎么地运行了专有版本，它会“回传数据”，大约30或60天后公司接到电话。涉及Oracle时，我遵循南希·里根的建议[0]。
[0] https://en.wikipedia.org/wiki/Just_Say_No
LMS/GLAS
>尽管MySQL的开发在过去几年中陷入停滞。
9.0版本终于发布，目前已更新至9.3。虽然每次发布都没有重大或令人兴奋的更新，但开发进展稳定。MySQL 8.0将于2026年4月达到生命周期结束(EOL)，因此建议尽快迁移至8.4 LTS版本，届时9.7x版本也应成为LTS版本。我知道 HN 上大多讨论的是 Postgres，但现代 MySQL 表现尚可。我认为很多人仍在使用 5.0 时代的 MySQL。这一点在 Java 领域也同样适用。
我认为 Oracle 确实贡献了大量开源代码，只是他们并未因此获得认可或大肆宣扬。
关于Java，值得一提的是，IBM自Java早期阶段就与Sun合作，包括在网络计算机项目中，为基于Java的瘦客户端提供支持。
> MySQL 8(2018年发布)
许多人已转向MariaDB，因为Oracle收购Sun(后者收购了MySQL)后，MySQL的开发进展停滞。
MariaDB 的采用率还算不错，但仍远低于 MySQL。
我认为 PostgreSQL 的流行也受益于 Oracle 收购 MySQL
我好奇其中有多少是因为诅咒的发行版仓库。
我可能永远不会忘记发现我的脚本在 Debian 版本之间出现问题的原因时感到的愤怒，因为 “apt-get install mysql” 开始默默地安装 MariaDB 而不是 MySQL，虽然两者相似但有微妙的差异。(我真的感到惊讶，考虑到涉及 Oracle 的商标，却没有因此提起诉讼。)
人们就是喜欢讨厌成功公司，这是 HN 的特色。我通常会忽略这个网站上此类帖子，因为它们毫无价值
我认为对甲骨文的憎恨已超出对成功公司(无论是微软、FAANG等)的泛泛憎恨。
人们曾经确实喜欢过让这些公司迅速崛起的產品。Windows 2000很酷；Facebook很酷；Google很酷。只要它们暂时停止成为纯粹的邪恶存在，很快就会有很多人愿意原谅它们并欢迎它们重新回到主流社会。
但只要大多数极客还能记得，甲骨文从未酷过。在其鼎盛时期，该公司助长了一个傲慢的BOFH数据库管理员的世界，向那些油头滑脑的中层管理者出售价格过高的产品。随后，他们开始“收购挤压”相关产品，勒索自己的客户，并起诉所有可见的目标。即使他们明天就能治愈癌症，并将所有相关知识产权赠予世界，大多数极客仍会视他们为试图粉饰形象的败类——而他们很可能没错。甲骨文中不乏优秀工程师，但其管理层正是资本主义一切问题的根源。
从1979年到大约2000年，甲骨文的RDBMS软件可能是世界上最好的，而且肯定比像Postgres这样的开源软件更好。(记住，MariaDB，当时名为MySQL，直到2000年才成为开源软件，而且直到更晚才支持事务。) 此后数年间，它仍适用于某些特定场景。即便从一开始就存在“地狱般的数据库操作员”，这一事实依然成立。
SQL本身确实不够完善，但关系型数据库模型如此卓越，足以弥补其不足。在实体组件系统、SQLite、PostgreSQL和MariaDB兴起之前，所有可靠的实现版本均为专有软件。此外，尽管SQL对事务的实现比对关系模型的实现更糟糕，但事务并发性也足够出色，足以弥补SQL的不足，而且，同样地，所有可用的实现曾经都是专有软件。
这可能是个陷阱，但我还是得问……为什么 01979 和 02000 前面都有个 0？
显然是为了避免 Y2K 问题。
我认为这只是在推迟Y100K漏洞。
不了解你的背景：这是长现在基金会(Long Now Foundation)的文化符号。
> 从1979年到大约2000年，甲骨文的RDBMS软件可能是世界上最好的，而且肯定比像Postgres这样的开源软件更好。[…] 在那之后的几年里，它仍然是某些用途的最佳数据库。
在那之后，哪款RDBMS软件成为了世界上最好的？
我不知道。Oracle 是为在 VAXCluster 上运行而设计的，该系统配备了共享磁盘，磁盘寻道时间在数十毫秒级别，而像 Postgres 这样的系统在架构上也适合这种环境。世界已经发生了巨大变化。如今，任何在 2000 年代可以存放在磁盘上的数据，现在都可以存放在内存中。我们的可编程计算能力主要集中在 GPU 而不是 CPU 上，网站工作负载极度偏重读取(更倾向于使用物化视图和读取从属服务器集群)， SSD 可以在 0.1 毫秒内持久化事务，支持随机读取，但对非顺序写入施加了严厉的惩罚，而启动一万个 AWS Lambda 函数并行处理一个查询现在是一件合理的事情。
我认为你可以为SQLite、Postgres、MariaDB、Impala、Hive、HSQLDB、SPARK、Drill，甚至Numpy、TensorFlow或Unity的ECS提出合理的论点，尽管最后几个缺乏Codd概念中至关重要的“内部表示独立性”(“数据独立性”)。
你的看法如何？
如果你想要高可用性和可扩展性(不管成本多高)，那么Oracle可能仍然是首选。尤其是在写入密集型工作负载下。但并非所有人都能承担得起烧钱。
MS SQL Server，但这显然不是许多HN用户共同持有的观点。
Postgres 应该
据我所知(我可能错了，或者过去几年情况发生了变化)，Postgres 在水平扩展方面仍不如 Oracle 和 Microsoft SQL Server(以及可能的 DB2)。
也许吧，但我认为 MariaDB 在这方面胜过它们。
此外，与 20 或 30 年前相比，水平扩展现在的重要性要小得多。https://www.servethehome.com/2025-server-starting-point-inte… 指出 AMD 每插槽拥有 192 个核心，且可使用双插槽主板，因此总计 384 个核心。并且可以安装12个128GiB DDR5-6000内存条，因此总内存容量为1.5 tebibytes，单个SSD容量为30 terabytes，SSD通常可在0.1毫秒内持久化事务组。这384个核心(EPYC 9005，即Zen 5c架构，https://www.servethehome.com/amd-epyc-9005-turin-turns-trans…)的频率为2.25GHz，通常每时钟周期执行约2.2条指令(https://chipsandcheese.com/p/zen-5-variants-and-more-clock-f…)，并且支持 AVX512。
作为一个粗略估算，2.25GHz 搭配 AVX512(1 IPC)意味着每个核心每秒可执行 360 亿次列式 32 位整数运算，而 384 个核心则意味着每个核心每秒可执行 13 万亿次 32 位整数运算。在一台服务器上。因此，如果有一个查询需要对一个包含1300万行表的列进行线性扫描，该查询可能需要300微秒，但你应该能够每秒执行一百万次这样的查询。但通常你会对表进行索引，以便大多数查询不需要进行如此低效的操作，因此你应该能够每秒处理比这多得多的查询！
(每个插槽有12个DDR5通道，每个插槽到DRAM的总带宽为576千兆字节每秒，两个插槽总计1.13太字节每秒，因此如果缓存不足，性能会下降。而且据说可以使用512GiB内存条，获得6太字节的内存！)
因此，如果您需要多台服务器来运行数据库，可能是因为数据库大小达到数十或数百 TB，或者您每秒处理数千万个查询，或者您的数据库软件是为旋转式硬盘设计的。旋转式硬盘仍然是存储大型数据库的最佳方式，但现在“大型”的界限已接近 PB 级。
我认为，那些容量低于十太字节且每秒查询量低于一千万次的数据库，其范围已经足够涵盖大多数人想到的“数据库”概念。
> 因此，如果您需要为数据库部署多台服务器
服务器会故障，任何严肃的业务显然需要多台服务器。许多业务甚至需要多个数据中心，仅为实现冗余。现代的Oracle集群与RAID阵列类似，通过在物理服务器集群中复制虚拟数据库，确保单台物理服务器故障不会对虚拟数据库造成任何影响。
大多数数据库并不直接支撑业务运行。现在已经不是1973年了。我手机上的网页浏览器就内置了多个SQL数据库。
我刚才说的是水平扩展，不是故障转移。故障转移并不需要水平扩展，也不需要任何特殊的软件功能。(不过PITR确实不错，尤其是当你的数据库确实支撑着业务运行时。)使用云计算服务商时，你甚至可能不需要备用服务器来进行故障转移；当故障发生时，你可以随时启动它，并按小时付费。
你提到的这些功能在30年前甚至20年前都很有意义。如果需要处理每秒数亿次查询或拥有数百TB数据，这些功能依然很有意义。但对于其他场景，垂直扩展就足够了，而且工作量小得多。与备份或重构数据库不同，这简直就是一款可以直接购买的产品。
(我列出的许多开源关系型数据库也支持集群功能，用于高可用性和可扩展性；我只是认为，当你可以购买一台配备太字节内存的现成服务器时，这些功能就没那么重要了。)
> 但对于其他场景，垂直扩展就足够了
我不是在反驳这一点，我只是指出为什么大型组织仍然使用Oracle。
那不是原因。
那些一旦数据库出现问题就会导致业务停摆的数据库是OLTP数据库(通常指金融意义上的交易数据库)，而这类数据库的规模通常不会达到数百TB或每秒数千万笔交易的级别。Oracle本身并不支持在2025年仍需运行在单台服务器上的如此庞大或交易量极高的数据库。(它确实能扩展到如此庞大的数据库或如此高的交易率，以至于Oracle无法在2025年的一台服务器上运行它们，但这只是因为Oracle的VAXCluster优化设计在当前硬件上效率低下。)
人们使用Oracle是因为他们已经来不及切换了。
这是一个精彩的评论，谢谢。
不客气！很高兴你喜欢。
我并不喜欢Oracle，但GraalVM相当酷。而且原生JVM也在不断更新。
他们在Java领域做了大量工作，包括将其完全开源。
我认为你低估了他们的数据库对世界的影响。他们在该领域曾是巨大的技术创新者(实际上至今仍是)。
每个人都用“JavaScript”来描述一种语言。
Oracle是寄生虫。
说实话，我完全不知道JavaScript是个注册商标。我一直以为这是编程语言的名称，完全不知道它与甲骨文公司有任何关联。
不过我并不觉得不知道这件事有什么不好，因为这门语言确实与该公司毫无关联，他们居然还持有它的商标权，这简直荒谬。
JavaScript最初是作为Java小程序的封装而创建的。甲骨文在收购Sun时获得了两者。该语言的官方名称是ECMA脚本，但人们坚持使用商标名称，因为ECMA让人联想到一种令人不快的皮肤病。
难道没有相关法律规定吗？就像“Kleenex”这个词已经普遍被用作纸巾的代称一样。
我敢肯定这就是整个诉讼的焦点。
Animal Well有一个名为“飞盘”或类似名称的物品，因为Frisbee是注册商标。
对千禧一代来说，用谷歌搜索某物几十年来的意思就是以任何方式在线搜索。
商标法愚蠢且不方便。只有商标所有者反对。
但许多其他法律也是如此。我们都必须遵守它们。
商标法让我作为消费者可以购买可口可乐并确信会得到可口可乐。
我认为这很方便，尽管我没有拥有任何商标。
这些好处很容易被视为生活中的正常部分。
就像我们理所当然地认为食品标签不会欺骗你，食品中不会含有危险成分，因为有适当的检查等。
这是一个讽刺的例子，因为我曾去过几个地方，那里“可乐”是通用名称，如果你说“汽水”或“软饮料”之类的话，人们会感到困惑。我曾直接要了一瓶可乐，结果被问“什么牌子？”，并指向菜单上列出的雪碧等(他们不是在问“零度可乐”)。
但这会阻止你从其他商家购买同等可乐，即使你可能想这样做(因为可能更便宜)。你假设每个人都像你一样重视“可乐”必须来自特定制造商，无论产品实际是什么或含有什么。
对于可乐，你可能对大多数人(尽管不是我)是正确的，但有很多产品品牌忠诚度并不是一个问题。人们只是想要一些不错的纸巾，没有人关心它是否由真正的 Kleenex 制造。
如果我愿意，我今天就可以轻松地从其他几家公司购买可乐，而商标法目前就是这样。我只能从一家公司购买可口可乐。
你是在说，如果任何公司都能卖给我“等同于”可口可乐、丰田凯美瑞或iPhone的产品，我会更好吗？
不。
你可能在想“通用化”。这并不是你所理解的法律意义上的规定，没有相关法律条文，没有立法机构制定，也没有人签署过任何文件。相反，“通用化”是商标法中与核心理念相关的法律原则，即我们不能对描述性标志享有专有使用权。
假设你制造了一款“大汽车”，并试图将“大汽车”作为该新产品的专有商标。这只是对汽车的描述，属于通用名称，因此你不能这么做。你可以注册“巨型汽车”或“水陆两用汽车”等商标，因为人们可以用“大汽车”来描述类似产品，但如果你被允许独占“大汽车”这个名称，他们就不能这么做了。
通用化理论指出，如果你的产品如此成功，以至于现在所有人都知道“Waterluvian”是什么，而且大多数人看到福特推出一款新的大型汽车时，比如 “Waterluvian”，以至于福特的销售人员都难以教导展厅的工作人员不要称这款车为“Waterluvian”——这时“Waterluvian”已经成为通用术语，你无法阻止福特声称他们正在生产“Waterluvian”。
通用化仅适用于极度知名的事物。Kleenex就是一个例子，因为你的妈妈知道什么是Kleenex，割草的工人知道，埃隆·马斯克知道，每个人都知道，这确实很著名。JavaScript可能不符合这个要求。我的母亲不知道什么是JavaScript，我的老板知道，因为他是一名软件工程师，也许平均水平的毕业生知道，但我不会为此押太多钱。
稀释是一个相关概念，也适用于非常著名的事物。稀释原则指出，对于这些著名事物，即使与之无关，也不允许将著名标志用于其他任何目的。因此，迪士尼卫生纸不行，可口可乐品牌振动器也不行，等等。没有人会认为振动器是饮料，但可口可乐太著名了，这并不重要。这在这里也不适用。
使用JavaScript来指代甲骨文提供的JavaScript的人数为零，过去10多年中能够指代甲骨文提供的JavaScript的人数也为零。因为这根本不是一个东西。我敢肯定这违反了商标法规。
通用化的评估是否存在相对性？例如，如果只有卡车司机知道“Waterluvian”这个术语，但绝大多数人以通用方式使用它，那么它就是通用的？因为这将是对该法律的相關更新，并适用于此。
由于没有实际的书面立法，你可以尝试在法庭上提出这一论点，但此前法院一直坚持“人人皆知”的标准，因此卡车司机的认知不足以构成依据。也许“纽约的每个人”在纽约法院能成立，当然我认为“尼日利亚人不知道这个词”在美国任何法院都不会对你不利——但你所考虑的相对性肯定不在他们的考虑范围内。
如果甲骨文胜诉，我们就将该语言更名为JS。JS代表无意义。
我们可以直接用它的全名来称呼它，Eczemascript
那不如用OS，其中“S”现在代表“糟糕”，而“O”的含义则留给读者自行推敲。
这会与“开源”(Open Source)的OS造成混淆。
还有“操作系统”(Operating System)。这是特性，不是 bug。
我想我们可以使用爪哇附近岛屿的名字。比如BaliScript、MaduraScript、KarimunScript等等。
或者JoeScript，用另一个俚语词替换“咖啡”的含义。
TypeScript现在被称为DecafScript。
DFCOCScript。“Dee-ef-coc-script” 绝佳咖啡脚本
顺口
不，我们把JavaScript改名为Typelessscript。
.Net编译为其中间语言(IL)，而且现在还有谁会直接编写原始JavaScript呢，所以干脆叫它JSIL。
Typescript–
不如叫“douche-named-Larry-script”。效仿苹果公司的做法，他们曾使用过代号“Butthead Astronomer”。
https://www.engadget.com/2014-02-26-when-carl-sagan-sued-app…
Deno应该发起一场宣传活动，口号是“你知道JavaScript和Java毫无关系吗？(除了法庭诉讼)”
我会捐款。
我不是想吹毛求疵，但除了刻意模仿的语法外，JavaScript 和 Java 是首批采用(不兼容的！)面向对象数据模型并由运行时强制执行的语言，从而实现了广泛采用和长期发展(抱歉，Smalltalk！)
Python 早些时候就被发明出来了，但直到后来才得到广泛应用。
而它们都因早期万维网(WWW)的热潮而得到极大推动，这一点毋庸置疑。除了 Perl 之外，没有其他通用编程语言能如此说，而 Perl 后来逐渐衰落。
嗯，这些模型在一定程度上是兼容的，因为 JavaScript 可以从 applet 中访问它们。这就是为什么他们选择了这个名字……
> 这就是为什么他们选择了这个名字……
这真的正确吗？据我所知，JavaScript 主要是因为当时 Java 流行而被采用的。JavaScript 最初以 LiveScript 的名称发布，后来才改名为 JavaScript。以下是Brendan Eich对此的精彩评论：
“JavaScript这个名字是在Java风头正劲时选定的，当时我们正在开发LiveConnect以将JS与Java小程序连接起来。”
以下是David Flanagan的评论：
“JavaScript最初是以Mocha这个名字开发的……后来在Netscape和Sun Microsystems的联合营销协议下更名为JavaScript。”
我们还可以对那些与该商标历史相关并支持 Oracle 的公司进行处罚。例如本案中的 Mozilla 和 Brave。
如果它们因 Oracle 而用户减少，将对 Oracle 施压要求其释放商标。
有趣的观点，但我无法判断其真实性。
因此，JVM 具有基于类的名义类型系统(及对象模型)，并在运行时强制执行。
但据我所知，JS 仅在运行时强制执行基本类型，且没有名义类系统，除非你自行实现？
嗯，编辑：也许我明白你的意思了，它确实以某种方式具备。但原型身份和“instanceof”在实际中很少使用。
也许我没抓住你的重点。回答时已是当地时间较晚。
如果浏览器能拥有一个命名类型系统就太棒了。
许多 JavaScript 库都有自己的版本，与 TypeScript 结合时会带来难以忍受的麻烦。
比如，它们会使用复杂的 hack 确保库对象不是结构化/鸭子类型。
类 ≠ 对象
是的，类型和语义模型差异巨大。关键在于，它们以一种原始方式存在，而另一种广泛使用的替代方案 C++ 并未从其 Cfront 遗产中继承这一特性。
> 类 ≠ 对象
这就是我想要表达的，可能表达得不太好。
有很多库使用某种运行时可观察的实例属性作为标签，以模拟 JavaScript 中的名义类型。
同样的事情也可以通过原型身份来实现，如果你使用ES5引入的类关键字语法糖(？)，或者如果你手动使用原型进行面向对象编程。但后者非常罕见。
似乎更常见的是添加一个属性，如
$_$_$____superlib__$-inst_WALRUS
并将其用作标签。
解释 Oracle 组织结构的卡通图似乎很贴切：
https://newsletter.pragmaticengineer.com/p/code-review-on-pr…
Oracle就是“遗留系统”的代名词。如果你还在使用它，那你在市场和竞争中都已经落后了。
我这边被拥抱得喘不过气来
我们把master改名为main，结果搞砸了一切。尽管如此，公司和人们对此仍感到自豪(笑)。
为什么我们不直接在对话中使用EcmaScript，并将其作为趋势，这样问题就解决了。对我来说，这只是个笑话。
它对你造成了什么影响？这只是一个相对简单的重命名过程。
我发现由于名称更改，过去一年中子模块和构建管道出现了问题。更糟糕的是，有些人迟迟未跟上步伐，现在还在继续更改。但至少我已经尽了自己的一份力来反对奴隶制 /s
名字真是件有趣的事。当同性婚姻还存在争议时，我主张直接从法律中删除“婚姻”一词。我的国家自2000年起就向所有人开放民事伴侣关系，这在实质上就是同性婚姻，只是没有那个名字。十年后人们还在为名字争论不休。我搞不懂，但语言是强大的工具，对某些人来说意义重大。
至于“master”改为“main”，那只是那些急于参与某事却又不愿付出实际努力去说服他人的人的虚假 activism。说服人们放弃“JavaScript”这个名称将非常困难，因为人们对它有着深厚的情感，且认为放弃它意味着失去对一家邪恶公司的控制。
甲骨文难道不代表“一个名为拉里·埃里森的狂妄自大的人”吗？
我可以发明一种名为拉里·埃里森脚本的语言并注册商标吗？
我不是律师。但我想我们可以。
祝你好运，应对那些停止使用通知书。
我提议将JavaScript更名为“UntypedScript”。
你拥有我的剑。
我猜他们认为将JavaScript商标释放给Java商标存在风险。
这是让我相信人类已经走到了尽头的事情之一。
甲骨文是历史上唯一一家为了“应对”许可证审计而建立庞大咨询网络的公司。
谷歌搜索结果：
甲骨文许可证审计生存指南(面向首席信息官)
应对甲骨文的“友好”许可证审查
如何准备甲骨文许可证审计
如何准备并应对甲骨文许可证审计
甲骨文审计的7大触发因素(及如何避免)
甲骨文许可证咨询公司的前5名
与甲骨文审计防御合作时需询问的7个问题
感谢分享。我最终阅读了其中一篇——https://atonementlicensing.com/surviving-your-first-oracle-l…——它确实令人惊叹/恐惧，情况竟如此糟糕。
很难想象一家公司还能比这更榨取利益。
Nashorn(JDK中的JS引擎)是甲骨文唯一的优势，但他们移除了它，那么他们还能真正声称拥有什么来支持他们正在开发JavaScript的事实？
Nashorn仍在积极开发中。
GraalJS？
那不是甲骨文，我以为那是IBM？但如果是甲骨文，为什么他们要提交Node.js作为示例？他们并不拥有Node.js(至少目前没有)，所以这很奇怪。
Graal是甲骨文实验室。他们的研究部门。
该版权申请早于GraalJs。
> Node.js官网的截图，展示了“JavaScript”商标的使用。作为Node.js的创建者，我对此感到特别冒犯。
Ryan 在他的帖子中没有承认 Node.js 自己的商标，这其中有些讽刺意味，因为他正是宣布 Node.js 商标的人。
https://nodejs.org/en/blog/uncategorized/trademark
所以他希望 Node.js 商标得到承认，但他自己却不承认。
甲骨文希望JavaScript商标得到承认，而他也不愿承认这一点。
这一切在我看来都非常荒谬。
“不承认”是因为他在每篇提及Node.js的博客文章中都没有加上愚蠢的TM标志，这有点牵强。
Deno.com上没有承认Node.js商标……而着陆页主要讲述Deno比Node.js优越之处。
在所有可能放置商标承认的地方，它本应在那里——但它缺失了。
Ryan解释决定注册Node商标的帖子在我看来相当合理。Oracle维持JavaScript商标的理由是否同样具有说服力？
据我所知，Sun公司免费授权Netscape使用JavaScript商标，纯粹是为了在浏览器战争、语言战争等领域与微软对抗。我认为这与最初的协议仍有关联。
看起来JScript仍由微软持有商标，为何不直接询问他们是否愿意按照社区对ECMAScript名称的共识行事，这样我们就能更快速地使用该语言？
我感觉这是对社区的无端指责。
JavaScript已发展为如此普遍的术语，其版权地位正日益脆弱。相比之下，Node.js目前尚未面临此类问题。行业内大多数人支持这一倡议，而对那些愿意投入时间和金钱来一次性解决问题的人进行无端指责，显得有些小题大做。
商标权与版权不同。
查看理由[0]:
> 要提出欺诈索赔，申请人必须主张： (1) 被申请人向美国专利商标局(USPTO)作出了虚假陈述； (2) 被申请人明知该陈述为虚假； (3) 该虚假陈述对商标的继续注册具有实质性影响；以及 (4) 被申请人作出该陈述时意图欺骗USPTO。
> 欺诈主张必须以更高的具体程度陈述所有主张要素[...] 事实上，“诉状必须包含构成欺诈的具体情形的明确表述，而非暗示性表述。”此外，欺骗USPTO的意图是欺诈主张的特定要素，必须充分陈述
> 基本上，请求人关于欺诈的理论是基于以下指控：被请求人提交的维护文件中所附的使用样本并未显示由适当方使用。已确立的法律原则是，撤销商标的正当理由在于商标是否在商业中实际使用，而非使用样本的充分性[...] 使用样本本身的不充分性并不构成撤销理由；撤销的正当理由在于该标识未被作为商标使用
据我所知，TTAB认为，仅仅证明甲骨文公司不当提交Node.js作为商标使用证据并不构成欺诈，因为欺骗意图并未明确表达。这令人沮丧，因为如果这不是_欺诈_，我只能认为他们是_疏忽_。
申请商标或商标续展时，声称拥有自己不拥有的东西是疯狂的。这可不是个五秒钟就能完成的流程，而且其中涉及大量资金——这种事情极其严肃且至关重要！你是在告诉我，甲骨文公司或其法律顾问在提交申请前审查时，没有人能发现这个问题？据我所知，在商标续展申请[1]中，Node.js是唯一作为商标使用例证提供的样本！这太离谱了……
EDIT：抱歉，更正，续展申请中附有三份样本，其中两份似乎相同。显然这需要大量工作且过于复杂以至于无法验证。
[0]: https://ttabvue.uspto.gov/ttabvue/v?pno=92086835&pty=CAN&eno…
[1]: https://tsdr.uspto.gov/documentviewer?caseId=sn75026640&docI…
我不是律师，但我认为你的分析并不完全正确。
我认为关键在于
> 根据既定原则，撤销商标的正当理由在于商标是否在商业中实际使用，而非样本的充分性
如果我理解正确(而我可能理解错误)，这意味着无论提供的样本中是否存在欺诈行为，要撤销商标，证明责任在于证明整个商标主张存在欺诈，如果没有欺诈行为，那么商标就不会被授予。
Deno公司若能证明若无该样本USPTO本会驳回申请，或另一样本亦无效，或许能提出更强有力的欺诈主张，但这将拖延程序并增加其工作量。
祝你好运，Ryan！
这似乎是Deno公司的转移视线之举。
众所周知，像甲骨文这样的公司拥有强大实力，因此他们不会轻易放弃，除非法院如此裁决。
或许Deno公司应专注于构建实际商业案例，解释为何选择Deno而非使用节点？
这对Deno品牌而言是个明智之举。他们将被视为JavaScript的救世主。
或许在某些人看来，Node.js市场份额的收购进展不如预期，因此才有了此类活动。
>为什么选择Deno
选择Deno？我从未这样做过，我做错了什么？
你没有使用他们的SaaS平台，就像Vercel与Next.js一样，这是推动开发进展的关键。
许多人犯的错误是没有像其他行业一样为工具付费，然后在资金枯竭时，作者决定转向其他领域时感到惊讶。
甲骨文公司是否会永远合法拥有JavaScript商标？还是说它最终会有一个到期日，届时它将变成“公共领域”等？
专利和版权会过期。商标可以无限期续展。
哎呀。
也许是时候恢复JavaScript的原始名称：LiveScript。
把它改回Lisp吧
JavaScript不是Lisp。
它本该如此
如果甲骨文杀死JavaScript，那将是一件憾事。
一个叫拉里·埃里森的富翁
甲骨文持有JavaScript只是冻结了它，没有人能触碰它，他们没有对它做任何事情，但正是这种无为才让它保持稳定，没有争斗、没有重新品牌化，也没有人工智能公司试图为它申请商标。后来，这可能为任何人接手铺平道路，而下一个持有者可能不会这么安静。甲骨文什么都不做，反而保护了它，我认为这是好事。
想象一下，花了这么多年让J*产品可用，结果却被拉里·埃里森横插一脚。
尽管 JavaScript 显然已经成为通用术语，为什么人们还要费心将其正式化？有人因为说“JavaScript”而惹上麻烦吗？
如果不是现在，也许未来会
我可能因此不受欢迎，但 JavaScript 确实是 Oracle 目前合法拥有的商标。这是公平竞争。
然而，我认为这个词已经稀释并通用化，希望美国专利商标局(USPTO)选择释放它。
避免因通用化而失去商标权的一个好理由是，证明存在一个与商标重叠的通用术语，但商标本身并非该通用术语。
例子：
任天堂 → 电子游戏主机
便签纸 → 粘性便签
施乐 → 复印
等等 …
在 JavaScript 的情况下，没有通用术语可以指代；JavaScript 本身就是通用术语，这可能支持通用化的论点。
> JavaScript确实是甲骨文公司目前合法拥有的商标
嗯，这绝非不言自明。这正是诉讼试图证明的。他们并非该商标的合法持有人。他们未能证明在商业中的使用，且其中一个使用示例属于他人。
但它是甲骨文的商标，[1].
这里有一个(虽然简单，但有效的)使用案例[2].
我相信埃里森的律师可以列举出成千上万个 JavaScript 在甲骨文商业活动中的使用案例。
解决办法是争取通用化(或开始称其为 ECMAScript，哈哈)。
1: https://tsdr.uspto.gov/#caseNumber=75026640&caseSearchType=U…
2: https://docs.oracle.com/en/database/oracle/oracle-database/2…
第二个例子是JavaScript被用作Oracle商标的一个相当糟糕的例子。
我认为恰恰相反。该表述并未提及Oracle对JavaScript产品或名称的所有权。而ECMA被称为该标准的“制定者”。
如果说有什么不同，这恰恰是Oracle自身在通用语境下使用该商标的例子。
这就像可口可乐自称“芬达的生产商”，并引用食品药品监督管理局来定义其含义。
我怀疑该文档的撰写者并不知晓甲骨文拥有JavaScript商标权。
甲骨文开发、维护并销售两种不同的JavaScript运行时环境。他们显然在使用该商标。
许多其他实体也是如此。
甲骨文并不控制该语言的规范(ECMA负责)，也不拥有原始实现的权利(我认为Mozilla拥有)。
我认为这在JavaScript商标的语境下并不重要。在商标的语境下，甲骨文确实从事开发和销售JavaScript的业务。
他们还从事开发和销售多种SQL实现的业务，这是否意味着他们应该获得SQL名称的商标权？
没错，而且它现在作为支持语言出现在他们最新数据库版本中。这可能是他们继续保护商标的另一个原因。
哇，他们早在1995年就申请了商标？那可是在Node.js或Dahl出现之前，甚至在该语言尚未引起广泛关注之前。
是的。
尽管有人可能不喜欢，但该商标确实属于甲骨文公司。
再次强调，这就是诉讼的重点。它很可能不属于甲骨文。
这些(以及 Kleenex)是通用化的常见例子，但我认为，由于这些品牌的努力，我听到和看到实际通用术语的使用频率要高得多。例如，我从未听过70岁以下的人(截至目前)用“任天堂”来指代任何视频游戏主机。“便签纸”、“复印件”和“纸巾”是我个人听到使用频率远高于“Post-it”、“Xerox”或“Kleenex”的术语。
但对于“JavaScript”呢？还有什么其他说法？“JS”？
编辑：我想还有“ECMAScript”，但除了在法律上需要使用时，谁会真的这么说？
我一生中只听过一次有人这样使用“施乐”。我当时很困惑，一家发明了鼠标的公司和对方谈论的内容有什么关系。
难道通用术语不应该是ECMAScript吗？我明白这是一个愚蠢的名字，没人愿意使用。
唉，真是占用。
这似乎是一场令人头疼的斗争。为什么不干脆改名呢？反正大多数人已经放弃JS，转用TS了。
顺便说一下，这门语言叫ECMAScript
除了正式文件和可能的吹毛求疵者外，没人会用这个糟糕的名字。
不，那不是，那只是官僚主义的繁文缛节。
如果你要更改名称，就改成js。但不要更改语言的名称，尤其是不要改成ECMAScript。
它已经被称为ECMAScript；他们不需要更改它。它也被称为JavaScript。(我不知道ECMA是否也存在商标问题)
然而，“JavaScript”(和“ECMAScript”)这个名称已经足够广泛使用(如文章中所描述的)，因此甲骨文不应限制他人以这种方式使用它。
其他人也把这个读作“eczema script”吗？
不，我认识的人都直接读作ecma script。
“EnemaScript”
我的意思是，我并不认为这是对JavaScript的批评。我只是觉得这是这串字母最自然的发音方式。我真的无法用其他方式读它。
我希望大多数人已经转用TS，但在我看到数据之前不会确定，而我现在太懒得去查了。
“我们现在已经牢牢进入了TypeScript时代。67%的受访者表示他们编写的TypeScript代码比JavaScript代码更多——而最大的群体是那些只编写TypeScript的人。”
https://2024.stateofjs.com/en-US/usage/
听到这个消息很高兴，谢谢。
>每个人都用“JavaScript”来描述一种语言——而不是一个品牌。
它可以两者兼具。
>每个人都知道JavaScript不是甲骨文的产品
但年长的人应该知道它曾是太阳微系统公司的产品，而甲骨文收购了太阳微系统公司。
编辑：Sun实际上只是授权了该名称。但在续约时，它指向了甲骨文的一款名为“Oracle JavaScript Extension Toolkit”的产品。
https://tsdr.uspto.gov/documentviewer?caseId=sn75026640&docI…
但它从来都不是 Sun 的产品？Java 是 Sun 的产品，给 JavaScript 起一个包含“Java”的名字是导致整个混乱的错误。
这次改名为 GoScript。
最初的名字是Livescript。
Java是Sun的产品，但Java与JavaScript除了名称混淆外毫无关联。
JavaScript是在Netscape开发的。
JavaScript 的名称源于 Netscape 与 Sun 之间的一项交叉授权协议，根据该协议，Netscape 将随浏览器捆绑一份 JVM 拷贝。Sun 需要一种方式将 JVM 安装到大多数 Windows 用户电脑上，以促使开发者编写 Java 软件而非 Windows 软件。他们清楚微软不会推出可能威胁 Windows 平台主导地位的产品，因此认为与 Netscape 捆绑是最佳选择。如果你阅读最初的 JavaScript 新闻稿(https://www.tech-insider.org/java/research/1995/1204.html)， 它主要被宣传为一种编写胶水代码的方式，使Java小程序(其中包含真正的应用程序逻辑)能够与HTML页面进行交互：
> 借助 JavaScript，HTML 页面可能包含一个智能表单，能够根据用户输入在客户端实时执行贷款还款或货币兑换计算。一个用 Java 编写的多媒体天气预报小程序可以通过 JavaScript 脚本根据某一地区的实时天气数据显示相应的图像和声音。一个服务器端 JavaScript 脚本可能从关系型数据库中提取数据，并在客户端实时将其格式化为 HTML。一个页面可能包含在客户端和服务器端均运行的 JavaScript 脚本。在服务器端，脚本可能根据存储在关系型数据库中的用户偏好动态生成并格式化 HTML 内容；在客户端，脚本则将各种 Java 小程序和 HTML 表单元素整合成一个实时交互式用户界面，用于指定跨网络的信息搜索。
> Java程序和JavaScript脚本均设计为可在客户端和服务器端运行，其中JavaScript脚本用于修改Java对象的属性和行为，因此通过企业网络或互联网动态呈现信息并与用户交互的实时在线应用程序范围几乎无限。网景公司将在客户端和服务器端产品以及编程工具和应用程序中支持Java和JavaScript，以实现这一愿景。
> “程序员对Java表现出极大的热情，因为它从头开始就是为互联网设计的。JavaScript是自然的选择，因为它也为互联网和基于Unicode的全球使用而设计，”Sun的联合创始人兼研究副总裁Bill Joy表示。“JavaScript将是将基于HTML的内容与Java小程序连接的最有效方法。”
这一切都已实现，Java小程序与JavaScript实现了完全的互操作性。小程序可以调用JavaScript函数，而JavaScript函数也可以调用小程序方法。当然，随着时间的推移，人们逐渐放弃了Java小程序，而JavaScript也发展成为一种足够强大的语言，可以直接用它来编写真正的应用程序逻辑。虽然现在JavaScript几乎与Java毫无关联，但最初并非如此，而这个名称至少有一些逻辑依据。
啊，很好的背景信息。
我刚了解到一个小细节：围绕这个名称曾有过 Netscape 和 Sun 的合作协议，因此该注册商标具有一定的法律历史。并非 Sun(随后是 Oracle)只是声称对 Netscape 创建的东西拥有权利。
不。我当时在场，没有人认为 JS 是 Sun 的产品。
我正在想象一个替代历史，即詹姆斯·戈斯林(James Gosling)被赋予数天时间开发一种可行的浏览器内脚本语言，而非布兰登·艾克(Brendan Eich)。
Node.js即将变得无关紧要。一旦微软发布TypeScript 7。
为什么TypeScript 7会让Node.js变得无关紧要？
在TypeScript 7中，编译器将用Go语言而非TS语言编写。但编译器仍会输出JS代码，因此Node.js仍可用于运行该JS代码。
还是说TypeScript 7的其他特性会让Node.js变得无关紧要？
一个速度提升 10 倍的 TypeScript 到 JavaScript 编译器如何让 JavaScript 运行时变得无关紧要？
TypeScript 7 并非 Node.js 的替代品，它是一种语言规范和编译器，但 Bun 可能成为使用 JavaScript 运行时的开发者的首选。
Bun 并不比 Node.js 快，为什么人们一直这么认为，真是笑死。V8 运行时比 Bun 使用的 SpiderMonkey 运行时快 4 倍。
Bun 使用的是苹果的 JSC，而不是 SpiderMonkey。
你能详细说明吗？你是不是把 Node 和 JavaScript 混为一谈了？
你自己都搞糊涂了。
Unauthorized Broadcast Causes Neurological Failures in Viewers
Medical Agencies Issue
“Do Not Observe”
Order After Fatal Incidents
Following last night’s appearance of an unregistered channel
designated XR–9.
Emergency rooms in three countries reported clusters of patients exhibiting identical symptoms: convulsions, memory compression, and catastrophic neural overload.
The broadcast itself contained only a rotating sigil
and a voice repeating:
“This is not for you.”
Neuroscientists have confirmed that prolonged exposure—even 15 seconds—causes the brain to attempt to reconcile multiple incompatible timelines
simultaneously.
Nine fatalities have been recorded.
The Global Health Directorate issued a rare Level-0 advisory:
“Do not seek or observe XR-series transmissions.
Observation poses a verified mortally lethal risk.”
发表回复