تولد یک سیستمعامل، بخش ششم
شبیهساز ترمینال من داشت دست و پا درمی آورد و کاملتر میشد. از آن به طور مرتب برای ورود به کامپیوتر دانشکده و خواندن ایمیلها یا بحث در گروه پستی مینیکس استفاده میکردم. مشکل این بود که لازم بود فایلهایی را آپلود و دانلود کنم. به عبارت دیگر، باید فایلها را روی دیسک ذخیره میکردم. برای این کار باید برای شبیهساز ترمینالم یک درایور دیسک هم مینوشتم. همچنین به یک ساختار فایل نیاز داشتم تا بتوانم فایلها را روی دیسک طبقهبندی کنم و بتوانم فایلهای مختلف را در بخشهای مربوط به خودشان ذخیره کنم.
اینجا بود که احساس کردم ادامه پروژه کار زیادی میبرد که ارزشش را ندارد و تقریبا کل پروژه را متوقف کردم. ولی مساله این بود که کار دیگری برای انجام نداشتم. بهار آن سال به کلاسهایم میرفتم که چالش خاصی در آنها نبود. تنها فعالیت هفتگی من، دیدارهای (یعنی پارتیهای) چهارشنبه شب در باشگاه اسپکتروم بود. با توجه به اینکه جزو دسته غیرحیوانات اجتماعی بودم، این تنها فعالیت من به جز درسخواندن و برنامهنویسی بود. در بهار آن سال، بدون آن دیدارها (پارتیها) که کمک میکردند یک کم-گوشه-گیر باشم، به یک گوشهگیر کامل تبدیل میشدم. اسپکتروم ساختار درونیای داشت که زندگی اجتماعی را تسهیل میکرد و فکر نمیکنم برنامههای چندانی را در آنجا از دست داده باشم. آن برنامهها برای من بسیار مهم بودند. در واقع، گاهی حتی به خاطر هیجان آن برنامهها، نمیتوانستم بخوابم. من قبل از بعضی از برنامهها، شب را با این تلاش میگذراندم که فردا با کمبود تواناییهای اجتماعیام چه کنم؛ چگونه دماغ بزرگم را مخفی کنم و در مورد نداشتن دوستدختر چه توضیحی بدهم. فکر کنم این یک مشکل همیشگی گیکها است.
چیزی که سعی میکنم بگویم این است که آن بهار، کار چندان جالبی برای انجام نداشتم. در این میان فکر کردن به پروژه دیسکدرایو/سیستم فایل پذیرفتی بود. پس با خودم گفتم که به سراغش خواهم رفت. یک دیسک درایو نوشتم و چون میخواستم از فایلهایم در سیستمعامل مینیکس هم استفاده کنم -و همچنین به این دلیل که فایل سیستم مینیکس به خوبی مستند شده بود- سیستم فایل خودم را سازگار با سیستمفایل مینیکس طراحی کردم. با این کار میتوانستم فایلهایی که در مینیکس داشتم را بخوانم و همچنین فایلهایی که توسط شبیه ساز ترمینال خودم ساختهام را هم بتوانم در مینیکس استفاده کنم.
این جریان، کار خیلی زیادی برد. یک برنامه روزانه به شکل برنامه نویسی، خواب، برنامهنویسی، خواب، برنامهنویسی، غذا (هلههوله)، برنامهنویسی، خواب، برنامهنویسی، دوش (سریع)، برنامهنویسی. از همان موقع معلوم بود که این پروژه دارد به سمت یک سیستمعامل پیش میرود. پس من هم ذهنیتم از این پروژه را از یک شبیهساز ترمینال به سمت یک سیستمعامل تغییر دادم. فکر میکنم این گذار در یکی از آن ماراتنهای برنامهنویسی حاصل شد. شب یا روز؟ یادم نیست. یک لحظه در کت حولهای سوراخسوراخم پشت کامپیوتر نشسته بودم و مشغول تغییر دادن شبیهساز ترمینالم بودم تا قابلیتهای جدیدی به آن اضافه کنم. لحظهای بعد متوجه شدم که آن قدر قابلیتهای این شبیهساز ترمینال زیاد شده است که باعث شده به یک سیستمعامل جدید تغییر چهره بدهد.
من آن را گنو-ایمکس شبیه سازهای ترمینال خودم نامیدم. گنو-ایمکس به عنوان یک ادیتور شروع به کار کرد؛ ولی کسانی که مشغول توسعهاش بودند، آن را به میزبانی برای انواع و اقسام قابلیتها تبدیل کردند. آنها میخواستند ادیتوری بنویسند که بتواند برنامهنویسی شود ولی جنبه قابل برنامهنویسی بودن، زیادی پیشرفت کرد و ادیتور به مخلوقی جهنمی تبدیل شد. این ادیتور همه چیز دارد به جز یک ظرفشویی آشپزخانه؛ و احتمالا به همین دلیل است که گاهی شکلک این برنامه را ظرفشویی آشپزخانه انتخاب میکنند. میگویند این یک پروژه بسیار بزرگ برنامهنویسی است که قابلیتهایی بیش از هر چیزی دارد که برای یک ادیتور لازم است. شبیهساز ترمینال من هم مشغول طی کردن مسیری مشابه بود. رشد شبیه ساز ترمینال من، داشت به چیز جدیدی منجر میشد.
به: گروه خبری comp.os.minix
موضوع: Gcc-1.40 و یک سوال مربوط به پوسیکس
شناسه پیام: <1991Jul13,[email protected]>
تاریخ: ۳ جولای ۹۱ ساعت۱۰:۰۰:۵۰ جی.ام.تی.
سلام شبکهایها،
به خاطر پروژهای که مشغول آن هستم (در مینیکس)، علاقهمندم تعاریف استاندارد پوسیکس را داشته باشم. ممکن است یک نفر من را به یک نسخه (ترجیحا) قابلخواندن توسط ماشین از جدیدترین نسخه راهنمایی کند؟ سایتهای اف.تی.پی. خیلی خوب خواهند بود.
بله. این اولین شاهد از یک گیک در فنلاند است که دارد محدوده تواناییهای کامپیوتریاش را میآزماید. استانداردهای پوسیکس قوانین دور و درازی هستند که صدها فراخوانی سیستمی یونیکس را تشریح میکنند. این دستورها تمام فعالیتهای کامپیوتر را کنترل میکنند و با فراخوانیهای اساسی مثل خواندن و نوشتن و باز کردن و بستن شروع میشوند. پوسیکس، بدنه استاندارد یونیکس است. سازمانی متشکل از تمام کسانی که میخواهند با هم در مورد استانداردهای یونیکس توافق کنند. برای برنامهنویسها، استانداردها بسیار مهم هستند. چون از طریق آنها میتوانند برنامههایی بنویسند که روی بیش از یک کامپیوتر اجرا شوند. فراخوانیهای سیستمی -به خصوص مهمهایش- فهرستی از توابع مختلف را در اختیار من میگذاشت که زیرساختهای یک سیستمعامل را تشکیل میدهند. من برنامههایی مینوشتم که توابع مورد نظر را به شیوهای که خودم تصمیم گرفته بودم، اجرا کنند. در عین حال با پیگیری پوسیکس، برنامههای من برای دیگران نیز قابل استفاده میشدند.
آن موقع نمیدانستم که این امکان هست که کپی سخت (نسخه کاغذی) پوسیکس را از خود آن سازمان سفارش دهم. البته ارزشی هم نداشت. حتی اگر میتوانستم پولش را بدهم، رسیدن نسخهها به فنلاند از طریق پست زمان زیادی میگرفت. این بود که میخواستم نسخه نرمی پیدا کنم که از طریق سایتهای اف.تی.پی. قابل دریافت باشد.
هیچکس جوابی حاوی پیوندی به فایلهای پوسیکس نداد. پس مجبور شدم به سراغ نقشه ب بروم. شروع بررسی استانداردها از راهنمای نسخه یونیکس دانشگاه که از سرویسدهنده سان میکروسیستمز استفاده میکرد. این راهنماها حاوی نسخهای ابتدایی از فراخوانیهای اساسی بودند و میشد از طریق آنها کار را شروع کرد. میشد به راهنماها نگاه کرد و دید که هر فراخوانی قرار است چه کاری را انجام دهد و بعد پشت کامپیوتر نشست و تابعی برای انجام آن کار نوشت. صفحات راهنما نمیگفتند که چطور باید وظایف را انجام داد و تنها به نتیجه نهایی اشاره میکردند. تازه بعضی از فراخوانیها را هم از کتاب آندرو تاننباوم و بعضی کتابهای دیگر برداشتم. در نهایت، یک نفر جلدهای قطور حاوی استانداردهای پوسیکس را فرستاد.
البته ایمیل من بدون جواب هم نماند. هر آدم مطلعی (و فقط هم آدمهای مطلع گروه خبری مینیکس را میخواندند) میتوانست بگوید که پروژه من نوشتن یک سیستمعامل است. مگر قوانین پوسیکس به چه درد دیگری میخوردند؟ پیام من کنجکاوی آری لمکه، استاد حل تمرین دانشگاه تکنولوژی هلسینکی (که اگر اینقدر علاقهمند به تئوریها نبودم، آنجا درس میخواندم) را برانگیخت. «آری» با فرستادن یک جواب دلگرمکننده، نوشت که بر روی اف.تی.پی. دانشگاه، یک زیرشاخه برایم ساخته است تا هر وقت احساس کردم سیستمعامل آماده شده، آن را در اختیار کسان دیگری بگذارم که ممکن است علاقهمند باشند آن را آزمایش کنند.