巨人的败笔：TSS/360如何以“失败”孕育了Unix的传奇

# 巨人的败笔：TSS/360如何以“失败”孕育了Unix的传奇 1964年，IBM的实验室里弥漫着一种混合着野心与焦虑的气息。一群天才工程师正试图创造一种前所未有的操作系统——TSS/360，它承诺让数十个用户同时通过键盘与庞大的System/360主机对话，仿佛每一人都独占整台机器。然而，这个被寄予厚望的“分时共享”梦想，很快变成了一个吞噬金钱、人力和时间的无底洞。它最终被IBM放弃，沦为商业史上最著名的失败之一。但正是这场惨败，如同一颗被砸碎的种子，在废墟中催生了Multics，并最终孕育了统治半个世纪的Unix。TSS/360的故事，是关于技术野心如何撞上现实壁垒，以及失败如何以另一种方式改变了世界。 ## 硅谷的“登月计划”：与时间赛跑的疯狂构想 20世纪60年代初，计算机的世界还是一片蛮荒。大型主机以批处理模式运行——程序员将穿孔卡片交给操作员，等待数小时甚至数天后才能拿到结果。这种“排队等候”的方式让IBM的工程师们既愤怒又兴奋：愤怒于效率的低下，兴奋于他们看到了改变一切的契机。 1964年，IBM发布了革命性的System/360——一个兼容不同型号的计算机系列，被称作“计算工业的第一次统一”。就在同年，IBM启动了TSS/360（Time Sharing System/360）项目。它的目标是打破批处理的桎梏：让纽约的银行家、加州的物理学家、东京的工程师，同时通过电传打字终端登录同一台大型机，共享CPU时间片，仿佛每个人都拥有独立的计算机。这在当时几乎是科幻小说般的设想。 项目的核心是一群年轻的、充满理想主义的技术极客。他们设计了一个宏大的架构：引入虚拟内存——将程序使用的地址空间与物理内存分离，让每个进程认为自己拥有无限内存；实现动态链接——程序运行时才加载所需库，节省宝贵的内存；采用多级调度算法——精细控制CPU时间片的分配。这些概念在今天看来司空见惯，但在1964年，它们如同在沙漠中建造一座空中楼阁。 “我们以为可以造出一台永不停机的机器，”一位后来的IBM工程师回忆道，“TSS/360被设计得过于完美，以至于它忽略了现实世界的物理限制。”项目启动后，IBM投入了超过200名工程师，资金消耗如同流水。但很快，噩梦开始了：虚拟内存的页面置换算法导致系统频繁“抖动”，CPU将90%的时间花在交换内存页面上，而非执行用户程序；动态链接引发了灾难性的内存碎片；时间片调度在不同负载下完全失控。1967年，当第一个测试版本在System/360 Model 67上运行时，系统响应时间长达数分钟——用户敲击一个键，要等一杯咖啡喝完才能看到回显。 ## 崩溃与反叛：从IBM实验室到贝尔实验室的蝴蝶效应 1968年，TSS/360项目走到了悬崖边缘。IBM管理层召开了一场决定命运的会议。会议室里，项目负责人面色苍白地汇报：“我们无法在可预见的未来交付一个可用的系统。虚拟内存的缺陷是根本性的，除非重新设计整个内核。”台下，一位高级副总裁冷冷地问：“你还需要多少时间？多少预算？”负责人沉默许久，吐出一个数字：两年，再加三千万美元。会议室内爆发出愤怒的争吵。最终，IBM做出了一个痛苦的决定：放弃TSS/360，将资源转向更稳妥的OS/360。消息传出后，整个项目组陷入绝望。 但正是在这堆“废墟”中，一个转折点悄然出现。贝尔实验室、麻省理工学院和通用电气正在合作开发Multics——一个受TSS/360启发的下一代分时系统。IBM的失败让Multics团队吸取了惨痛教训：他们意识到，过度复杂的设计会导致性能灾难，必须追求简洁和模块化。然而，Multics自身也因过于庞大而步履蹒跚。 真正的主角在此时登场。一位名叫Ken Thompson的年轻工程师，曾参与IBM TSS/360的某些前期研究，后来加入贝尔实验室的Multics团队。当Multics项目于1969年陷入困境并最终被AT&T放弃时，Thompson感到一种熟悉的挫败感。但他没有选择放弃，而是从TSS/360和Multics的双重失败中提炼出一条黄金法则：**“保持简单，保持愚蠢。”** 1970年，Thompson和同事Dennis Ritchie在一台废弃的PDP-7小型机上，用汇编语言编写了一个“玩具”操作系统——Unix。他们刻意回避了TSS/360的宏大设计：没有复杂的虚拟内存（早期Unix直接管理物理内存），没有动态链接（所有程序静态编译），没有复杂的调度算法（采用简单的优先级轮转）。Unix的理念是“小即是美”，每一个工具只做一件事，但做到极致。这正是TSS/360那场“技术过度设计”的悲剧所赋予的启示——有时候，最伟大的创新恰恰来自于对失败的深刻反思。 ## 失败的遗产：虚拟内存与分时系统的黎明 尽管TSS/360在商业上一败涂地，但它的技术遗产却如同暗夜中的灯塔，照亮了后来者。首先，它证明了虚拟内存的可行性——尽管性能糟糕，但概念本身被证明是未来操作系统的基石。1968年，英国曼彻斯特大学的Atlas计算机和IBM的后续研究团队，从TSS/360的错误中学会了如何设计高效的页面置换算法（如LRU），这让虚拟内存在十年后成为标准。其次，动态链接的概念被Multics继承，并在Unix中以共享库的形式复活，最终成为Linux和Windows的标配。 更重要的是，TSS/360的失败直接催生了Unix的哲学。Ken Thompson曾公开表示：“如果TSS/360成功了，我们可能永远不会想到去创造Unix。它的失败告诉我们，操作系统不是设计出来的，而是进化出来的。”Unix的简洁并非天生，而是对TSS/360那种“大教堂式”设计的反抗。它像一把手术刀，精准地切除了复杂性，留下了最本质的功能。 在商业史上，TSS/360是一个典型的“先驱陷阱”。IBM投入了数亿美元和数千人年，最终只换来了一个技术演示原型。但它为整个行业支付了“学费”：后来的DEC VAX/VMS、BSD、Linux，都是在TSS/360的尸骸上建造的。它证明了，技术创新不能脱离物理现实——1960年代的硬件（慢如蜗牛的磁盘、稀缺的内存）无法支撑过于激进的软件架构。TSS/360的失败，本质上是“雄心超越了时代”。 ## 评论 TSS/360的故事揭示了软件工程中一个永恒的悖论：最深刻的突破往往诞生于最惨烈的失败。IBM试图用“大教堂”式的完美设计征服分时系统，却因过度复杂而崩塌；而Unix则用“集市”式的迭代进化，从废墟中长成参天大树。TSS/360的教训远超技术范畴：它提醒我们，在商业创新中，“时机”与“克制”同样重要。一味追求超前，可能成为倒在黎明前的烈士；而懂得从失败中提炼原则，才是真正的智慧。今天，当我们使用Linux、macOS或Windows时，键盘下的每一次击键，都暗含着TSS/360那场失败的回响——它教会了世界，如何用最简单的解决方案，解决最复杂的问题。 ## 参考资料 - [IBM TSS/360 项目历史](https://en.wikipedia.org/wiki/IBM_TSS/360) — 维基百科页面，详细记录了项目起源、技术细节和失败原因。 - [The Multics System: A Retrospective](https://multicians.org/history.html) — Multics官方历史站点，包含与TSS/360的对比及Unix起源。 - [Ken Thompson谈Unix的起源](https://www.bell-labs.com/usr/dmr/www/chist.html) — Dennis Ritchie撰写的Unix历史，提及TSS/360对Unix设计哲学的影响。 - [System/360: The Computer That Changed Everything](https://www.ibm.com/ibm/history/ibm100/us/en/icons/system360/) — IBM官方对System/360的回顾，包含TSS/360的定位与挑战。