شکافی که مسیر رایانش را تغییر داد
کمتر داستانی در تاریخ فناوری وجود دارد که همزمان آنقدر آموزنده باشد و هم نیشدار؛ افتخارِ شکستِ پروژهای که قرار بود آیندهٔ محاسبات را دیکته کند، اما در پیچیدگیهای اجرایی بلعیده شد. در نیمهٔ دههٔ ۱۹۶۰، سه غول فناوری یعنی مؤسسهٔ فناوری ماساچوست، آزمایشگاههای بل و جنرال الکتریک دست به دست هم دادند تا مولتیکس را روی ابررایانهٔ GE-645 پیادهسازی کنند. پروژهای که قرار بود الگوی نهایی سیستمعاملهای زمانتقسیم شود، در نهایت متورم، کند و پر از گرههای کور شد. اما همین سقوط پرصدا، جرقهٔ تولد یکی از تأثیرگذارترین سیستمعاملهای تاریخ را زد.
چشمانداز بزرگ: مولتیکس قرار بود چه باشد
مولتیکس که مخفف «سرویس اطلاعات و محاسبات چندگانه» بود، برای زمانی طراحی شد که چندین کاربر بتوانند همزمان به یک ابررایانه متصل شوند. جاهطلبی این پروژه در مقالات بنیادی آنهایی مثل «مولتیکس: هفتسال نخست» نوشتهٔ کرباتو، سالزر و کلینگن که در کنفرانس مشترک بهار ۱۹۷۲ ارائه شد، بهخوبی مستند شده است. ایدهٔ محوری، تبدیل رایانه به یک سرویس مشترک بود؛ نه یک ابزار شخصی، بلکه زیرساختی که دادهها و پردازش در آن به اشتراک گذاشته شوند.
حافظهٔ تکسطحی
یکی از جسورانهترین معماریهای مولتیکس، مدل حافظهٔ تکسطحی بود. در این سیستم، برنامهنویس نیازی نداشت کدهای صریح برای خواندن از دیسک یا نوشتن در حافظه بنویسد. دادهها انگار همیشه در رم بودند و اگر جایی کم میآمد، سیستم مدیریت حافظهٔ مجازی بهصورت شفاف و خودکار آنها را بارگذاری میکرد. این روش کار توسعهدهنده را ساده میکرد اما هزینهٔ بسیار بالاتری از نظر مدیریت منابع داشت.
محافظت لایهای و گرههای اجرایی
مولتیکس سیستم حفاظتی مبتنی بر حلقهها را پیاده کرده بود. اما پیچیدگی این لایهها گاهی به بنبست میخورد. ریاضی ساندرز، مهندس ارشد، در یکی از گزارشهایش مینویسد که مستندات سیستم صراحتاً دستور میداد نرمافزارهای سیستمی باید براکتهای حلقهای [1,5,5] داشته باشند، اما کامپایلر زبان PL/I بهصورت پیشفرض بخشهایی با [4,4,4] تولید میکرد. ساندرز سالها را صرف جستوجو برای اصلاح این سازوکار میکرد: «ابتدا پنج اصلاح در روز داشتیم، اما بعد از سه ماه این عدد به یک مورد در هفته رسید.» این رقم نشان میدهد که ظرافت معماری وقتی با پیچیدگی اجرایی همخوان نیست، چگونه توسعه را زمینگیر میکند.
چرا مولتیکس زمینگیر شد؟
با وجود آنهمه نوآوری، پروژهٔ مولتیکس بهشدت در دام حجمزدگی گرفتار شد. شکاف بین آرمانهای مهندسی و واقعیتهای اجرایی روزبهروز عمیقتر میشد. تیم آزمایشگاههای بل بهوضوح دید که تحویل یک سیستمعامل روان و کارآمد در افق نزدیک محال است. بارِ سنگین حفظ و بازیابی خطاها، کمر برنامهنویسان را شکسته بود. تام ون ویلک، توسعهدهندهٔ پروژه، مکالمهٔ سرنوشتسازی را با دنیس ریچی به یاد میآورد:
«به دنیس گفتم که نیمی از کدهایی که مینویسم، صرفاً مدیریت خطا و بازگشت به وضعیت سالم است. دنیس خندید و گفت: ما این کارها را نکردیم. اگر خطایی رخ دهد، روتین panic() را صدا میزنیم، سیستم کرش میکند و شما از اتاق کناری داد میزنید: هی، ریستش کن.»
این دیالوگ کوتاه، شکاف فلسفی عمیقی را آشکار میکند. مولتیکس میخواست همهچیز را کنترل کند، درحالی که فلسفهٔ آیندهٔ رایانش به سمت سادگیِ بیپرده حرکت میکرد.
خروج آزمایشگاههای بل و آغاز یک انقلاب کوچک
ناامیدی از حجم بالای کد و کندی شدید اجرا، نهایتاً به خروج تدریجی آزمایشگاههای بل از پروژه انجامید. تا سال ۱۹۶۹، این همکاری رسماً قطع شد و احتمالاً قرارداد استفاده از ابررایانهٔ پرهزینهٔ GE-645 هم خاتمه یافت. اما خروج به معنای پایان ایدهها نبود. کن تامپسون، دنیس ریچی، داگ مکایلروی و جو اوسّانا، آخرین پژوهشگرانی بودند که روی مولتیکس کار کرده بودند. آنها تصمیم گرفتند همان آرمانِ محاسبات گروهی را نجات دهند، اما با زبانی بسیار سادهتر و معماریای که فقط ایدههای کاربردی را حفظ کند.
ریچی سالها بعد در سال ۱۹۷۹ دربارهٔ انگیزهٔ اصلی تیم توضیح داد: «ما بهدنبال محیطی برنامهنویسی عالی نبودیم. بهدنبال سامانهای بودیم که گروهی از توسعهدهندگان بتوانند دور آن جمع شوند. تجربه نشان میداد که ارزش محاسبات گروهی، تنها تایپ کردن کد روی ترمینال نیست، بلکه ایجاد فضایی برای تعامل نزدیک و اشتراکگذاری ابزارهاست.»
مهندسیِ ضد مولتیکس
کن تامپسون که از انعطافپذیری مولتیکس لذت برده بود، بهسرعت بهسمت طراحی نسل بعدی حرکت کرد. استراتژی طراحی او ساده و قاطع بود: ایدههای خوب را حفظ کن، ایدههای پیچیده و غیرضروری را بدون حاشیه حذف کن.
تامپسون تصمیم گرفت سیستمفایل سلسلهمراتبی مولتیکس را نگه دارد، اما حافظهٔ تکسطحی را کلاً کنار بگذارد. دلیلی؟ در حافظهٔ تکسطحی، کد برنامه و داده بدون تمایز در یک فضای آدرسدهی مشترک در نظر گرفته میشدند. در عمل این دو ماهیت عملکردی متفاوتی دارند؛ مدیریت حافظهٔ فایلسیستمی سادهتر، قابلپیشبینیتر و بسیار سریعتر است. با این حذف، UNIX متولد شد. سیستمی که بهجای تلاش برای پوششدادن تمام سناریوهای احتمالی، روی هستهای حداقلی تمرکز کرد.
این تغییر رویکرد فقط یک انتخاب تکنیکال نبود؛ یک اعلام جنگ مفهومی علیه مهندسیزدگی بود. UNIX ثابت کرد که میتوان با ابزارهای کوچک، دستوری و ماژولار، قدرتمندترین زیرساختهای دیجیتال جهان را ساخت. هماکنون هم وقتی به کدهای متنباز مدرن یا معماریهای میکروسرویس و ابری نگاه میکنید، بازتاب همان فلسفهٔ «حداکثر انعطاف با حداقل پیچیدگی» را میبینید. تاریخ نشان داده است که بزرگترین جهشها در فناوری، اغلب از دل شکست پروژههای بیشازحد جاهطلبانه زاده میشوند و سادگی، در نهایت همان اوج فناوری است.
