《雷神之锤》之父约翰·卡马克 1997 年谈计算机操作系统
关于《雷神之锤2》的扩展机制，我收到了大量反馈。我确实阅读了所有收到的邮件(虽然无法逐一回复)，并从中获得了一些启发。
目前尚未定案，但动态链接库(dll)仍有望成为主要接口方案。我曾认真考虑过Java接口，但权衡利弊后发现(投入实现时间会挤占其他开发资源)并不划算。其他方案如增强QC语言或采用Perl等语言的可能性极低。
主要原因在于：功能始终可以向上扩展——在DLL基础上叠加更多功能，但向下兼容性却难以保证——例如从Java访问注册表就存在技术壁垒。
对id软件而言，开发游戏时DLL效率最高。我们拥有更强的CPU算力，调试也更便捷。当前正倾注大量精力让《雷神之锤2》成为更出色的游戏，同时打造更完善的多人虚拟世界。《雷神之锤1》在游戏性上存在诸多缺陷，我们绝不会重蹈覆辙。
我能向QC破解群体提供的，是在《雷神之锤2》发布时公开其QC接口与解释器代码。用户社区可据此整合资源，最终形成一个公开可信的DLL文件，用于执行经过更新修改的QC语言，从而实现可移植且安全的扩展功能。
我确实重视可移植性，但这只是众多需要权衡的因素之一。事情从来没有绝对的对错之分。
说到可移植性，为消除猜测空间，以下是我对各平台的最新看法：
Win32
Win32主宰着世界。若持相反观点，无异于掩耳盗铃。其优势在于当今Windows系统已非昔日不堪。Win95/NT 4.0针对其定位而言实属可靠平台。我目前主要在NT系统开发，Quake 2也几乎肯定会率先登陆Win32平台。我们的游戏在NT系统上应能实现最佳运行效果，不会依赖任何“仅限95版”的功能特性。
DOS
我们不会再开发DOS游戏。无论收到多少愤怒的邮件都改变不了我的决定(拜托别发了！)。完善的TCP/IP支持、动态链接、强大的虚拟内存、设备驱动等优势实在难以超越。虽然DOS也能通过各种方式实现这些功能，但实在得不偿失。
Linux
我认为Linux是ID公司继Win32之后最重要的平台。从商业角度看，将其与Mac或OS/2并列实属荒谬，但对于我们这类鼓励玩家破解的游戏，Linux拥有巨大优势：其黑客与用户比例远超任何操作系统。我个人虽不用Linux开发(因习惯用NEXTSTEP处理Unix相关事务)，但对其技术实力深怀敬意。
MacOS
从盈利角度看，这是除Win32外唯一重要的操作系统，但重要性有限。我们采用专业移植版本而非未经支持的破解版本，可谓福祸相依。这些移植版本虽迟到(至今仍在等待《雷神之锤》…)，但功能更完善。技术层面我对MacOS毫无敬意——他们原地踏步，任由微软从遥远后方反超。我绝不会在此平台开发。
OS/2
我们的产品原生移植到OS/2的可能性微乎其微。我们对此兴趣缺缺，且不愿为此挤占其他项目时间。
SGI
相较于NT或NEXTSTEP，我对IRIX作为开发环境并不热衷，但SGI拥有运行GL应用最酷炫的硬件。未来移植IRIX版本是大概率事件，但并非首要任务。
AIX / OSF / HPUX / SOLARIS
我不会主动移植至这些平台，但若有可信赖的第三方(如Zoid)愿意承担，我大概不会反对。
BeOS
我购买BeBox是因为坚信对称多处理(SMP)的价值，且偏爱从零构建的纯净系统。但实际体验后颇感失望。诚然它精简高效，某些功能确实优于我见过的其他操作系统，但相较于NEXTSTEP等系统，我未见其具备颠覆性优势。Lion公司(负责Mac版雷神之锤移植)已基本完成BeOS版雷神之锤移植，我全力支持他们发布该版本，但这纯属慈善行为，请勿抱有过高期待。
Plan9
我曾用数月时间运行Plan9系统。其内部架构精妙绝伦，但用户界面却仿佛沉睡了十年之久。我曾在上面运行过旧版《雷神之锤》专用服务器(别问我要——我弄丢了)，还利用碎片时间为其开发文明化的窗口管理器，可惜每月仅有的几小时闲暇最终被其他事务挤压殆尽，这个项目就这样被搁置了。
NeXTStep
我最钟爱的操作环境。NT和Linux在某些领域各有优势，但若条件相当，我绝对会毫不犹豫选择NEXTSTEP。它兼具Unix的强大功能(NT里有太多令我怀念的特性)，拥有最出色的用户界面(当然，这是我个人的观点)，而且在诸多层面都比Windows更符合逻辑。诚然，只要耗费足够时间折腾，Windows也能实现任何功能，但操作后总令人感觉如同穿越下水道般污浊不堪。
现实中两者本就不在同一水平线上，如今我的工作主要在NT系统上完成。我仍怀抱希望，这种局面或许不会持续。若苹果能在Rhapsody系统上做出正确抉择，我必将全力支持。NEXTSTEP需要完善两项游戏支持功能(视频模式切换与底层音频访问)。若苹果/NEXT能实现这些，我将亲自将现有Win32产品移植至该平台。
若能说服苹果在Rhapsody中实现优秀的硬件加速OpenGL，我极可能冷落Windows NT机器，转而在Rhapsody平台进行未来开发。(此刻实在不需要Quickdraw3D传教士对我进行说教，谢谢)
真想知道如果他今天能对现代操作系统发表更新的见解，会说些什么。这篇文章写成时我还未出生，但据我所知，如今的操作系统已截然不同。那时微软甚至还没暗示过要让NT取代经典版成为Windows主线系统。而如今的macOS与NeXTSTEP的共通点恐怕远多于经典MacOS，因此我好奇他在OS X问世后是否改变了对它的看法。
这里最经得起时间考验的，莫过于Linux始终保持着“最高黑客用户比例”。
若真要说变化，“最高黑客用户比例”反而在后来有所下降。
硬件兼容性曾是主要障碍。即便硬件支持Linux，也常无法开箱即用。当时多数家庭仅有一台联网设备，若系统崩溃，用户要么依赖懂技术的友人电话指导修复，要么得跑去别人家连网后再回来尝试操作。缺乏耐心的用户很快就被淘汰出局。
如今主流Linux用户(及“专业”商业用户)远多于当年，但其故障率在现代系统中仍居首位。此论断依然成立。
若论当前故障率，我认为BSD应居首位。坦白说接近100%。
BSD才是主流。
若真要追求黑客与用户1:1的比例，得去Haiku系统找。
若采用现实定义，此结论亦可动摇。现代PlayStation操作系统基于FreeBSD——虽非 完全 纯正，但考虑到BSD许可证，将其纳入讨论范围似乎合理。
言之有理。但若纳入该系统，则必须将Android归入Linux阵营，这将彻底拉低Linux占比。
不过Android使用的是OpenBSD的libc库。除非过去十年间它被替换了。
有意思，我此前并不知晓。原以为它基于glibc。
但我认为此处更应关注内核。因此我仍坚持Android属于Linux阵营。
> 反倒是“黑客占比最高”的现象在此后逐渐消退。
真的吗？
你觉得现在的黑客都在用什么系统？
非黑客用户比例上升了。黑客并未离开，只是系统变得更易上手了。
没错，那“最高黑客用户比例”为何会下降？你我可能都误解了什么。
若他们指的是“黑客用户比例”下降，本该直说，但这种表述方式很奇怪——既承认Linux黑客向非黑客群体销售(这本是常识)，又显得矛盾。
卡马克的观点是Linux曾是招揽黑客的沃土，因此作为商业目标很合适，但如今(2025年)或许转向Mac更明智。我不确定：我在办公室外用Mac笔记本，但主要只是上网和远程连接办公室里的Linux桌面。有时我思考是否该瞄准Mac来吸引更聪明的用户，因此我倾向于认为Mac如今拥有“最高黑客用户比例”——尽管1997年Linux无疑是如此。根据具体需求，BSD系统或许才是更值得关注的焦点。
换言之，我怀疑Linux可能已不再拥有“最高黑客用户比例”——这似乎也是我回复对象的本意。我无法确定；除了个人经验外，我没有充分理由支持这种观点，但出于好奇且愿意被说服，故提出疑问。
他在NeXTSTEP章节提及https://en.wikipedia.org/wiki/Rhapsody_(operating_system)，这是通往OS X的阶梯。
Windows始终是id软件的开发工具平台。我推测当OS X开始崭露头角时，id软件已发展壮大，所有本可受益于Interface Builder的工具链都由不同团队维护。而卡马克当时专注于挖掘各类显卡的极限性能——当时Win32驱动既是尖端技术，也是消费者能接触到的主流方案。
> 当今操作系统差异极大。
当真如此？除Windows外，其余系统皆已演变为UNIX(即便游戏主机亦然：Xbox运行Windows衍生系统，PlayStation基于BSD内核，唯任天堂仍坚持自主系统)。
90年代的操作系统多样性远超今日——AmigaOS、RiscOS、AtariTOS、BeOS和初代MacOS彼此差异显著，远比如今Linux、macOS、Android和iOS之间的差异更甚。
当前多样性的急剧萎缩，以及剩余选项普遍趋同的现象，难道不也算得上是相较90年代“截然不同”的状态吗？
了解卡马克和市场现状的人都知道，这种局面不会有太大改变。
Windows依然占据主导地位，尽管出于各种原因，如今已不再称其为Win32。考虑到Steam Deck和Proton的存在，Linux如今的重要性更胜以往；但其市场份额仍不及Windows。而macOS如今更像是第三选择——毕竟苹果对OpenGL/Vulkan的支持态度强硬，且普遍排斥非苹果优先的开发者。
若真要调整，Linux或许会跃居首位，毕竟卡马克向来是其坚定拥护者，且该平台增长势头最猛；但这种可能性依然渺茫。显然，在现代桌面操作系统演变为三巨头/三文化格局的背景下，其他平台将完全缺席这份清单。
> Windows依然占据主导地位，尽管出于各种原因，如今已不再称其为Win32。
Win32体系稳定可靠且将永久获得支持，尽管其上层技术层出不穷。它始终是操作系统的核心API。
> 随着Steam Deck和Proton的出现，Linux如今更显重要
其底层正是基于Win32运行！
业界常戏称Win32是Linux最稳定的API。
你所说的“Win32”实指WinAPI及其衍生/封装技术，包括WinRT、WinUI3、MFC等。
而作为平台代称的“Win32”早已消亡——如今x86架构下仅存“Win64”。
因此我才说他今天不太可能特指“Win32”。但若将“Win32”等同于“原生Windows API”(即便这个术语本身有争议，可按需替换为“传统API”)，那么它至今仍与当年如出一辙。
不，在游戏开发领域Win32有非常明确的含义：即游戏开发所需的Windows系统DLL子集，且该子集相当精简——仅包含创建空白窗口、DXGI交换链、D3D设备、音频输出、输入设备及可能的网络功能所需的核心组件，例如kernel32、user32、 ole32、gdi32、dxgi、d3d11/d3d12 基本涵盖全部需求。
除3D API外，自WinXP时代以来操作系统对游戏开发的要求基本未变，而Win32架构自WinXP时期起几乎未曾更迭，这恰是Windows最卓越的品质(毕竟经典Win32 API之后的任何更新都堪称灾难——DirectX堪称例外)。
Win32将永远被封存在玻璃博物馆展柜里，配上生命维持装置——就像Valve的Source引擎里，Quake物理组件(Qphysics)被当作远古遗物，仅在需要调用其力量时启用，却与“常规”的VPhysics隔绝，以免其诡异力量腐蚀整个代码库。
不过从CS2的现状来看，这套隔离措施似乎并不严密。
> Win32将永远被封存在带生命维持系统的玻璃博物馆展柜中
这反而是好事，因为游戏开发对操作系统的要求其实很低——只需能获取窗口、输入事件、音频和网络功能即可。所有有趣的功能都集中在3D API中，而这些API自2000年代初以来已发生巨大变化。
作为纯C语言API的Win32，其发展已停滞于Windows XP的世界观。
自Windows Vista起，多数新API均以COM库形式推出，例外情况包括DDK及通过新增数字或Ex后缀扩展的现有版本。
除COM外，其他API基于WinRT构建——该框架通过采用.NET元数据替代类型库，并新增反射基础接口IInspectable，实现了对COM的升级。
>Win32稳定可靠且将永久受支持，尽管其上层技术层出不穷。
我不会这么认为。随着网络逐渐成为应用交付平台，Win32的重要性正日益减弱。
> 业界有个玩笑说Win32是Linux最稳定的API。
这话千真万确。除了Linux的ABI接口，其他一切都在持续变动。我认为systemd已悄然统治世界，其地位不可撼动，但除此之外的底层架构已相当单薄。
> Windows依然称霸
Windows是款不再开发的遗留操作系统，仅为支撑Excel这头现金奶牛而存在。
为何不将Android归入Linux？
它可是迄今最大的Vulkan目标平台。
约翰·卡马克难道是编程界的贾·鲁尔？
因为Android向用户空间暴露的唯一Linux组件就是内核。
其余部分要么基于Java/Kotlin，要么属于官方NDK API集。
https://developer.android.com/ndk/guides/stable_apis
使用不稳定API能否跨设备运行纯属碰运气。
这里最经得起时间考验的，莫过于Linux始终保持着“最高的黑客与用户比例”。
比BSD更高？还是说比卡马克列出的那些操作系统更高？
1997年Linux仍属小众领域，其黑客与用户比例绝对与BSD不相上下。
老实说我压根没考虑过BSD。我个人圈子里根本没人用它，总觉得这更像是工作必备的系统。不过考虑到个人用户中的小众程度，你的说法确实有道理。不过要较真的话，若选取真正冷门的系统(比如实用价值极低的爱好者操作系统)，用户群里可能真能达到100%“黑客”比例。
Playstation、Juniper、NetApp、Netflix等都是小众用户。只要接触过这些设备，你也在使用它。
我知道许多操作系统基于FreeBSD，但原帖作者指的是使用标准发行版的用户，而非高度定制的嵌入式版本。况且，Netflix服务器运行BSD系统，用户本身并不等同于BSD用户。
别忘了macOS和iOS，Darwin同样源自BSD。
> 它拥有令人心碎的优雅内部结构，但用户界面却沉睡了整整十年。[…] 我闲暇时正为它编写一个文明的窗口管理器
残酷的现实是，窗口管理器恐怕是阻碍Plan9普及的三大因素之一(另两项是缺乏emacs/vim这类常用编辑器，以及缺少现代网页浏览器)
这里有 Lola：https://shithub.us/aap/lola/HEAD/info.html
以下是部分截图：
https://old.reddit.com/r/plan9/comments/1f9c50n/lola_screens…
太棒了，今天学到新知识。下次深入研究Plan9时我绝对要用这个(还会搭配Win 9x主题怀旧一番)。
Plan9/9Front团队应该钟爱rio、sam、acme这类视觉风格。否则早该有人为它开发更现代的桌面环境了。
史蒂夫·乔布斯重返苹果时，将NextStep系统一并带回。新版操作系统本质上是以FreeBSD核心为基础，搭载NextStep风格的桌面环境。Plan9本可以复制这种模式。
虽然界面确实不够炫酷，但我完全能接受这种风格。真正困扰我的问题在于它对三键鼠标的依赖。现代笔记本触控板虽能通过三指操作实现中键点击，但用户体验相当糟糕，实际操作仍需实体鼠标。
况且我更偏好键盘配合平铺式窗口管理器的操作模式，Plan9对鼠标的依赖完全不合我的口味。
NeXTSTEP从未成为“FreeBSD核心”，至少不是通常所指的那种核心。它本质是XNU(在Mach内核基础上嫁接FreeBSD运行环境并整合IOKit)搭配定制桌面环境。
这种描述并不准确。OS X完全基于NeXTStep，只是嫁接了部分经典Mac OS的UI元素。你不可能简单地用Plan9替换其中某些组件。
我认为阻碍Plan 9普及的最大障碍是缺乏C++编译器。这自然引出第二大问题——它不支持POSIX。诚然POSIX存在诸多缺陷，而Plan 9的核心理念正是要摆脱Unix历史包袱，建立更完善的体系。但POSIX能让各方保持统一标准，使得程序移植相对容易。而将软件移植到Plan9极其困难。虽然存在POSIX兼容层APE，但对稍复杂的程序似乎毫无助益。我认为这正是缺乏C++编译器的症结所在。
每隔几年我都会决心重试Plan 9，只因痴迷于它的理念。但每次都逐渐失去兴趣——我编程能力不足以从零构建所需组件，移植现有软件难度过高，且一切都与Unix系统迥异。于是挣扎一两天后，我总会回到我的obsd。虽然很肤浅，但我觉得有个好浏览器就能解决90%的问题。结果又回到没有C++编译器的老问题。
> 没有C++编译器
这确实像Plan 9开发者的作风。有趣的是这种“无C++编译器”的理念竟也传到了Go语言——那里没有cppgo，只有cgo集成方案 🙂
CGO支持C、C++和Fortran。
话虽如此，尽管C++与UNIX和C诞生于同一时代，但UNIX作者对其并不热衷，对ANSI/ISO C同样如此。正因如此，Plan 9的C编译器自成体系，Inferno提供的C编译器亦是如此。
硬件支持相当糟糕。它仅在x86架构上运行，配备最基础的硬件配置，仅搭载支持基本VESA模式的VGA显卡适配器。
它始终缺乏严肃感，更像是技术演示。在单台主机上也难以真正领略9pfs的精妙之处…我总觉得它需要置于贝尔实验室的网络环境中，与其他Plan 9系统协同运作才能真正绽放光彩。
记得几年前试用过Plan 9。我欣赏它的底层架构——设计师将Unix“万物皆文件”理念推向极致，通过名为9P的协议将各类服务以文件服务器形式呈现给操作系统。这确实是款充满前沿理念的酷炫研究型操作系统，但受限于软硬件支持不足，终究无法成为我的日常主力系统——尽管我正在开展一个研究项目(不过是针对传统*nix系统)，其中就运用了9P协议。
卡马克对rio图形界面的描述恰如其分：该界面深度借鉴了1980年代中期施乐帕克研究中心的Cedar环境(https://www.youtube.com/watch?v=z_dt7NG38V4)。我曾费尽周折才适应rio，最终还是掌握了它。甚至专门购置了一只老式Sun三键鼠标(无滚轮)，因为Plan 9不兼容我的滚轮鼠标。rio并未沿用苹果Lisa、苹果Macintosh和微软Windows引入的诸多交互规范，导致多数Plan 9新手初次接触时倍感陌生。存在一种误解，认为苹果和微软只是直接剽窃了施乐帕克研究中心的图形界面理念，未作任何创新。这种观点是错误的； 苹果Lisa和苹果Macintosh引入了许多施乐帕克研究中心图形界面所不具备的规范(这段对比苹果Lisa与施乐Star的视频突显了差异：https://www.youtube.com/watch?v=pBiWtJJN5zk)，而Windows则带来了更多创新。回到Plan 9系统，其图形界面包含许多施乐帕克研究中心曾探索但未被Mac或Windows采纳的规范，例如鼠标组合键操作(https://en.wikipedia.org/wiki/Mouse_chording)。因此对习惯传统GUI的用户而言存在学习曲线。
即便如此，rio背后的理念似乎很好地发挥了Plan 9架构的优势，展现了其支持工具导向设计的潜力。更值得一提的是，该理念源自施乐帕克研究中心的Cedar系统。若要为Plan 9打造一个充分利用其“万物皆文件”架构的类Mac或Windows图形界面，将需要相当大的研究投入。若仅在Plan 9上实现类Mac或Windows的GUI，可能无法充分发挥其架构优势——这正是Plan 9与其他操作系统的根本差异所在。
或许在某个平行宇宙里，苹果与AT&T于1990年代合并，苹果团队在Plan 9基础上开发经典Mac OS的继任者——当Larry Tesler、Bruce Tognazzini、Alan Kay等苹果元老与Dennis Ritchie、Ken Thompson、Rob Pike联手时…… 细想之下，这种假设颇具趣味性。不过即便“Mac OS Plan 9”再出色，若没有史蒂夫·乔布斯，苹果恐怕也难以实现1997年后的复兴。
哈！我完全忘了Quake C的存在。
1997年我桌上摆着台Windows NT 4.0机器(可能是测试版)，配着台Next Turbo Mono平板电脑。Visual Studio开发体验还算不错(是练就C++和多线程技能的好地方)，他们成功移植了所有DirectX功能。就像Windows 95，但更严肃稳定。
它取代了原先的Slackware系统和SGI Indy电脑。Indy很酷，开机时会播放一段小曲子，界面设计新颖，充满炫酷的色彩渐变效果，但除此之外问题不少(“对象服务器”经常莫名崩溃，它到底管理什么对象？我完全搞不懂)。
> Indy的启动音效确实很酷
我隐约记得那段“吉他”般的音效是通过卡普拉斯-斯特朗合成算法实时生成的。
objectserver(cadmin)是账户管理系统套件的一部分。桌面系统会通过它挂载磁盘、路由扬声器/音频、创建/管理用户、建立网络连接，以及处理各种其他事务。它会崩溃是因为代码质量太差。
啊老兄你提醒我了。那些机器的CD-ROM驱动器没有当时PC那种笨重的音频线，而是直接通过SCSI接口连接。播放音频CD时，系统会实时抓取红皮书标准的CD音频流，经SCSI总线传输至主机端，由主机重建PCM信号并写入数模转换器。
我喜欢这些机器的美学设计和键盘的触感。
这让我不禁怀疑，卡马克对NeXTSTEP的看法是否与《雷神之锤3》首个公开版本最初仅限于OS X平台发布的决定有关。
详见https://web.archive.org/web/20000229083216/http://macweek.zd…。
记得当时ATI Rage128芯片组是重磅焦点，也是Q3测试版率先登陆Mac的原因…不过现在想来，或许还与对NeXTSTEP系统的特殊情结有关。
《雷神之锤3》测试版于1999年问世——竟是在他鄙夷的经典Mac OS平台上，甚至早于最终版OS 9的发布。此举旨在最受限的硬件环境中消除重大缺陷，当时硬件加速技术尚处蛮荒时期。当时我们只能从媒体报道中了解OSX——而Q3首次正式登陆OSX平台时，竟是通过第三方(Omni Group)实现的。
不过当苹果在2001年率先推出Geforce 3显卡时，JC确实将OSX作为主要开发环境使用了一段时间，毕竟这才是能完美运行《毁灭战士3》所需的硬件世代。一年后，ATI的新旗舰显卡进一步满足了他的需求——于是又回到了Windows平台。我记不清他是否在获得该硬件前就通过.plan文件宣布过回归。
这大概是我读过的他第一篇“长文”。之前只记得他的推文和访谈
听起来他做事总是深思熟虑
卡马克在AltDevBlog上也发表过不少真知灼见的文章。最近读了他那篇关于函数式编程的论述，思路非常清晰。
这个网站重新上传了部分文章，搜索应该能找到更多
[0] http://sevangelatos.com/tag/john-carmack/
我最爱的是他那封关于代码内联的邮件：https://cbarrete.com/carmack.html
他写过大量文章，每篇都值得细读。
这里有个存档供感兴趣者查阅。最引人入胜的部分当属加速GPU进入消费级市场时，他对此领域发展的论述。据我记忆应是1997-1998年间。
* https://github.com/oliverbenns/john-carmack-plan
编辑：找到一篇…
* https://github.com/oliverbenns/john-carmack-plan/blob/master…
这些年来他对Mac的看法有改变吗？
这段话写于OSX之前，所以可以合理推测。
OSX算是面向大众的NextStep升级版，但其中差异可能正是他关注的重点。
MacOS才是真正意义上的“下一步”。
MacOS X及后续版本确实如此。但MacOS 9及更早版本完全不同，尽管部分界面元素被移植到了OS X。
我以为上下文能说明我指的是当下版本。它现在又叫macOS了。
MacOS绝对不是，但macOS是(原名OSX);)
他在苹果发布会上与史蒂夫·乔布斯同台展示过《雷神之锤3》的Mac移植版。
这没什么意义，苹果发布会每隔几年就会展示大型游戏，但这并不意味着有人会把Mac当作游戏平台(包括Mac用户，最重要的是：苹果公司本身)。
考虑到他明确表示不会为MacOS开发却为OSX开发，可以说他的立场确实发生了转变。
当时他指的是68k架构还是英特尔Mac？
我当时用的是Power Mac。
这是1997年的事，指的是PowerPPC+System 7系统，不是OS X。
可能是https://en.wikipedia.org/wiki/A/UX，但说不定又不是。
A/UX从未主流化，更无人称其为MacOS。卡马克在此语境下讨论的绝对是MacOS 7/8/9。
这与你有何干系？看着这些Mac辩护者急忙澄清“不不，但 那款 Mac完全不同”的评论，着实滑稽。仿佛现代版本就完美得多似的——两天前刚有讨论帖揭露其UI/UX设计有多糟糕，而硬件更是史上最反黑客、反消费者、DRM泛滥的存在，只要看过罗斯那小子频道的视频就明白。
> 若能说服苹果在狂想曲中实现优秀的硬件加速OpenGL
是啊，这评论真是经得起时间考验。Mac用户至今仍在等待完整的OpenGL 4.6兼容性，而该规范发布已逾十年。
编辑：尽管陈述了最基本的事实，我仍会遭到负面评价。每次戳破教条的蜂巢都会如此。
编辑编辑：我依然真心好奇，为何三十年前某人的观点对你如此重要。若你愿意回应，我希望能理解背后的心理机制。
对我而言，这纯粹是历史好奇心使然。我亲历过那个时代，却无缘真正接触过所有那些操作系统。我的系统从MS-DOS到68k版Mac，再到Win95。这些选择中，我甚至不敢说自己特别有远见。
确实如此。阅读开发者对旧时代操作系统或编程语言的看法很有趣，尤其是卡马克的观点。但GP现在似乎在Mac平台上寻求赞誉之类的东西。
我的意思是，某个网络评论者好奇约翰·卡马克对macOS的看法，这与你有何干系？
凡是抱怨被点赞的人，我都会反手点赞
站点指南里明明写着不准抱怨被点赞。
[主题偏离提示](不过上面确实加了年份！)
感觉标题该加个(1997)标注。
(1997)