تولد یک غول به نام لینوکس جنتو (بخش دوم)

این بخش دوم از مقاله ساخت یک توزیع جدید به قلم دنیل روبینز است که می توانید سه گانه این مقالات را به زبان اصلی در پایگاه اصلی بخوانید. شیوه داستان گونه ایی از خاطرات بوجود آورنده توزیع جنتو لینوکس است که تجربیات جالبی در آن وجود دارد. برگردان آن به فارسی اگرچه درخورد پارسی زبانان نیست و شیوایی لازم را ندارد ٬ اما هدف رساندن پیام درون آن با برگردانی بهتر از برگردان های ماشینی است.  به هر تقدیر من هم از نظر زمان با مذیقه روبرو هستم و این اندک تنها علاقه من به شماست. تا چه قبول افتد و چه در نظر آید.  

ساخت یک توزیع ٬ بخش ۲
۱.  از ای ناچ تا جنتو ٬ با اندکی پس رفت و اجراهای مشترک 

اولین گام های ای ناچ
در نوشتار پیشین ٬ کمینه ایی از روزهایی را که در تیم گسترش استمپد بودم را بازگو کردم و دلیل ترک آنرا (به خاطر تلاش های بوالهوس ها در کنترل پروژه و جنگ های روانی که آنها راه انداختند). بدلیل این مداخله ها ٬ من به این نتیجه رسیدم که ساده تر است که توزیع خودم را درست نمایم تا به گسترش استمپد در چنان شرایط کثیفی ادامه دهم! متاسفانه من مقدار شایان توجهی تجربه (می توان به آن درخود گفت؟) از کارم در استمپد بدست آوردم که شامل گسترش چندین بسته از آن ٬ طراحی کدهای اجرایی٬ و هدایت SLPV6  (پروژه مدیریت بسته توزیع بعدی) بود. 
توزیعی که شروع به کار بروی آن کردم ٬ با نام کد ائی ناچ ٬ بزودی بسیار درخشان شد چراکه ایجاد بسته ها و ارتقاء آنها در آن کاملا خودکار انجام می گرفت. اعتراف می کنم که این بخش بزرگی بود چراکه من یک تیم یک نفره بودم و نمی توانستم وقتم را صرف کارهای تکراری که جعبه گسترش من آنها را بشکل خودکار برای من انجام می داد بنمایم. و از آنجا که من یک توزیع کامل را از پایه طراحی کرده بودم (بیشتر از اسپین کردن مانند ردهت) ٬ به میانبر زدن زمان و صرفه جوئی شدید در زمان نیاز داشتم.
پس از اینکه دستگاه اولیه ائی ناچ فراهم آمد و راه اندازی شد ٬ من به کانال   irc.openprojects.net  بازگشتم و کانال خودم را با نام  #enoch آغاز کردم. در آنجا من موفق شدم تیمی از تقریبا ده نفر را گردآوری نمایم. در آن روزهای اولیه ما در IRC بودیم و در وقت های اضافه خود بروی توزیع کار می کردیم. از آنجا که ما عموما و شراکتا بروی آن کار می کردیم ٬ ایرادات جدیدی را در آن یافته و برطرف کردیم٬ ائی ناچ هر روز بیشتر کاراتر و حرفه ائی تر می شد.  

اولین سد راه
اولین روز فراخوان ٬ ائی ناچ اولین سد راه را ایجاد نمود پس از اضافه کردن Xfree86 و glib و gtk+ من تصمیم گرفتم xmms (یک نرم افزار سی دی و ام پی تری خوان بر مبنای X11/gtk+ ) را راه اندازی کنم. به این نتیجه رسیدم که زمان آن است که با کمی موسیقی جشن بگیریم! اما پس از نصب xmms تلاش کردم تا آنرا اجرا کنم اما X قفل نمود! در ابتدا فکر کردم که ایراد از xmms باشد چرا که من از کامپایلر بسیار بهینه سازی شده (-O6 mpentiumpro) استفاده می کردم که ممکن است از آن تعجب کنید. اولین نظرم مبنی بر کامپایل xmms با بهینه سازی استاندارد ٬ مشکل را حل نکرد. پس شروع به نگاه کردن به هر سمتی کردم. پس از صرف یک هفته کامل کاری گسترش برای یافتن ایراد ٬ رایانامه ایی از یک کاربر ائی ناچ ٬ Omeganda ٬ دریافت کردم که او هم چنین تجربه ایی با xmms داشت.
ما میزان زیادی زمان صرف کردیم و بعد از مقدار زیادی آزمایش تشخیص دادیم که ایراد در نتیجه ارتباطات POSIX است. به دلیلی یک فراخوانی pthread_mutex_trylock() چیزی را باز نمی گرداند. به عنوان ایجاد کننده توزیع ٬ این از ایراداتی بود که من واقعا نمی خواستم آنها را ببینم. من به گسترش دهندگان گفتم تا همه کد را بشکل کامل بررسی کنند تا خودم بتوانم بروی تجربه های لینوکسی بیشتر از کارکردن کدهای ایراد دار کار کنم. البته بزودی من آموختم که این یک توقع غیر واقعی بود ٬ و آن ایرادات همیشه هر از چندگاهی بوجود می آمدند.
چنانکه کاشف به عمل آمد ایراد از xmms یا gtk+ یا glib نبود. همچنین این نتیجه کارکرد نا مناسب Xfree86 هم نبود. بطور شگفت آوری ٬ ما یافتیم که ایراد از مکالمات درونی POSIX است ٬ بخشی از کتابخانه نسخه ۲.۱.۱ گنو سی (glibc) . من از اینکه چنان بخش حساسی از لینوکس چنین ایراد بزرگی داشت شوکه شدم. (و ما از یک نسخه تهیه شده glibc برای ائی ناچ استفاده می کردیم ٬ نه یک نسخه از پیش تهیه شده!).
بنابر این ما چگونه مشکل را برطرف نمودیم؟ در واقع ٬ ما هرگز قادر به رفع این ایراد نبودیم٬ اما من متوجه تعداد زیادی رایانامه در فهرست پستی گسترش دهندگان glibc شدم که از طرف اشخاص دیگری بود که چنین مشکلی را پیدا کرده بودند. گسترش دهندگان glibc پچی برای حل این اشکال برای ما ارسال نمودند. اما من در این فکر بودم که چرا ردهت ۶ (که آن هم از glibc با همین نسخه استفاده می کرد) با چنین مشکلی روبرو نشده بود در حالیکه از انتشار نسخه آن مدتی بود که می گذشت. برای فهمیدن این مطلب من glib SRPM (کد منبع RPM( را پایین گذاری کردم و نگاهی به پچ های آن انداختم.
ردهت پچ مخصوص به خودش را داشت که این ایراد را برطرف کرده بود. ظاهرا آنها هم چنین مشکلی را تجربه کرده بودند و تعمیرات اختصاصی خودشان را انجام داده بودند. همچنین بشکل بدی آنها از ارسال این پچ برای گسترش دهندگان glibc خودداری کرده بودند بنابر این این پچ نمی توانست توسط بخش های دیگر جهان مورد استفاده قرار گیرد. اما چه کسی می داند ٬ شاید ردهت این پچ را فرستاده بود و گسترش دهندگان glibc آنرا تایید نکرده بودند. یا شاید ایراد در یک تداخل خاص بین نسخه ها و کامپایلرها رخ می داد و ردهت هرگز با آن برخورد نکرده بود. گمان می کنم هرگز نخواهیم فهمید که واقعا چه چیزی رخ داده بود. اما من آموختم که بسته های ردهت حاوی مقدار زیادی از رفع ایرادها هستند که هرگز برای گسترش دهندگان اصلی فرستاده نمی شوند. درباره این بازهم مقداری رجزخوانی دیگر در جلوتر خواهم کرد.  

رجز
هنگامیکه شما با هم یک توزیع لینوکس را اداره می کنید این مطلب مهمی است که رفع ایرادات خود را برای گسترش دهندگان اصلی ارسال نمایید. چنانکه من آنرا دیدم ٬ راه های زیادی برای ایجاد گران توزیع ها وجود دارد که به لینوکس هدیه بدهند. ما کسانی که واقعا این برنامه های مختلف را بکار می اندازیم همگی یکی هستیم. ما باید رفع ایرادات خود را برای همه ارسال نماییم تا دیگر کاربران و توزیع ها هم از اکتشافات ما بهره مند شوند. اگر تصمیم گرفتید رفع ایرادات را برای خودتان نگه دارید ٬ شما به کسی کمک نمی کنید ٬ شما فقط باعث می شوید که افراد زیادی وقت خود را برای رفع ایراد مشابهی تلف نمایند. این گونه از مراقبت در مقابل روح متن باز قرار دارد و مانع رشد لینوکس. شاید باید بگوییم این ایراد همه ما است.
متاسفانه برخی از توزیع ها در این زمینه خوب عمل نمی کنند هرچند برخی مانند دبیان بخوبی کارهای خود را به جمعیت کاربران اهدا می کنند.  

کابوس کامپایلر
در هنگامیکه ما تلاش می کردیم تا ایراد glibc را برطرف کنیم٬ من رایانامه ایی از اولریخ درپر (یکی از کسانی که بشدت با گسترش دهندگان glib کار می کند) دریافت کردم. باید یادآوری کنم که اشکال POSIX  داشتیم ٬ و ائی ناچ برای کاربری بهتر از pgcc استفاده می کرد. و وی پاسخی داده بود شبیه این (من آنرا اینجا تفسیر کرده ام): کامپایلرهای خود ما با محصولات کدفوژن همراه اند که بازخورد خوبی در x86 دارد که بسیار سریعتر از چیزی که با pgcc کامپایل می شود کار می کنند. بدیهی است که  من بسیار به آزمایش این کامپایلر توربوئی که این بچه ها از آن استفاده می کردند علاقه مند شدم.
پس من یک نسخه آزمایشی از این کدفوژن درخواست کردم تا بتوانم آنرا آزمایش کنم ٬ و من و Omegadan تعجب کردیم که دریافتیم این کامپایلر دقیقا همان چیزی بود که اولریخ کلایمد گفته بود. پیامد x86 کارائی برخی سی پی یو ها را در فایل های اجرا ئی (مانند bzip2 ) تا ۹۰ درصد افزایش می داد! به نظر می رسید که همه برنامه ها از ده درصد ظرفیت کارائی استفاده می کردند و همه کاری که ما انجام میدادیم نگاه داشتن آن برای کامپایلرها بود. ائی ناچ ۳۰ تا ۴۰ درصد سریعتر راه اندازی می شد. کارائی بسیار بیشتر شد٬ بیشتر از آنچه ما از مهاجرت از gcc به pgcc بدست آورده بودیم. طبیعی بود که پس از تجربه آن برای خودمان ٬ ما می خواستیم که این کامپایلر برای ائی ناچ استفاده شود. متاسفانه کد در سی دی کدفوژن قرار داشت و تحت مجوز GPL انتشار می یافت و ما کاملا مجوز داشتیم از آن استفاده کنیم ... یا فقط اینطور فکر می کردیم.  

اجازه دهیم بوالهوسی ها آغاز شوند
من رایانامه ایی برای مدیر بازاریابی Cygnus ارسال کردم تا توجه ما را بداند ٬ توقع داشتم یک جواب : بله! استفاده کنید٬ ممنونیم که از کامپایلر ما استفاده می کنید دریافت کنم. بجای آن پاسخ این بود که هرچند بشکل تکنیکی ما اجازه داشتیم از آن استفاده کنیم اما قویا این اجازه را نداشتیم تا آنرا در کد منبع ائی ناچ قرار دهیم. من پاسخ دادم اگر مطلب اینگونه است چرا آنرا زیر مجوز GPL انتشار داده اند. حدث من این است که اگر آنها انتخابی داشتند٬ از GPL استفاده نمی کردند اما از آنجا که آنها کامپایلرشان را از egcs (که با مجوز GPL انتشار می یافت) اقتباس کرده بودند ٬ چاره دیگری نداشتند.
این مثال خوبی است از موقعیتی که GPL شرکت ها را از ایجاد حق مالکیت در چیزهایی که بر اساس متن باز هستند باز می دارد. حدث تجربی من این است که Cygnus از این می ترسید که ما کامپایلر آنها را در بسته هائی برای فروش استفاده کنیم ٬ که خصوصا قوی تر از موادی بود که در بازاریابی خود از آن استفاده می کردند و بروی استفاده از آن در محصول خودمان تبلیغ کنیم. کدفوژن به عنوان یک گسترش دهنده IDE بازاریابی شده بود و نه یک کامپایلر.
در پاسخ به این پارانویای آنها من یک لینک خرید به وب سایت آنها برای کمک به فروش کدفوژن آنها در وب سایت خودمان قرار دادم. شخصا فکر نمی کردم که توربو ائی ناچ تاثیر منفی بروی فروش آنها یا وجه آنها به عنوان IDE بگذار. اما من هرگز برای شاد کردن آنها تلاش نکردم. کامپوننت های IDE آنها محصولات تجاری بود٬ و ما نه می خواستیم و نه می توانستیم آنرا با ائی ناچ همراه کنیم.
من هدیه خودم را برای آنها ائی میل کردم و پاسخ قوی دیگری از آنها دریافت کردم. آنها اختیار همه مواد بازاریابی ما را می خواستند (ظاهرا مفاد وب سایت ما را هم شامل میشد!) شوکی دیگر. به نظر می رسید تیم بازاریابی Cygnus هیچ ایده ایی درباره نحوه کارکرد جمعیت لینوکس و GPL نداشت٬ بنابر این من تصمیم گرفتم ارتباطاط آینده را با ایشان قطع کنم. در این زمان ما یک نسخه توربو و یک نسخه غیر توربو از ائی ناچ ایجاد کرده بودیم که توضیح آنرا برای بعد خواهم گذاشت.
اما پس از چند ماه آنها کدفوژن را به gcc دادند. اکنون هرکسی می توانست از مزیت های این پشتیبان زیبا بهره مند شود ٬ نه فقط کسانی که در باره راز کامپایلر GPL داخل سی دی کد فوژن اطلاع داشتند. اما ما تصمیم گرفتیم تا مستقیم برویم و از gcc بجای کدفوژن استفاده کنیم. در افزودن به ثبات بیشتر ٬ gcc همچنین به ما اجازه داد تا از Cugnus استفاده نکنیم ٬ که در این زمان بوسیله ردهت خریده شده بود در ازای مبلغی پول. (نکته: پشتیبان x86 از gcc به توزیع های جدیدتر لینوکس همان چیزی را ارائه داد که اکنون آنرا تجربه می کنیم. همچنین gcc به FreeBSD نسخه ۴ هم سرعت بخشید. تفاوت آنرا احساس کردید؟)  

در جعبه صابون
از تجربه هایی که از شرکت های منافع گرای متن باز آموختم ممنونم. قطعا هیچ چیز بدی درباره شرکت های منافع گرای متن باز وجود ندارد. چیزی به بدی محصولات نرم افزاری متن بسته وجود ندارد٬ اگر دوست دارید آنگونه باشید. اما این هیچ احساسی برای شرکت های من باز ایجاد نمی کند که محصولات خود را از دسترس دنیای آزاد منع کنند ٬ همچنین بدون پشتیبانی GPL یا با هر معنی دیگری. این که نکته تمرینی است که احساس بازاری را تداعی می کند.
شرکت های متن باز باید این را دریابند که آنچه که از آن منتفع می شوند تعویض رایگان کدها و ایده هاست. با تفاوت ایجاد کردن بین چیزها شبیه روال استاندارد GPL ٬ ایشان با اتکا به رشد و شکوفایی خودشان محیط را سست می نمایند. اگر متن باز خاکی است که موجب شکوفا شدن کسب و کار شما می شود ٬ این مهم است که خاک را سالم نگه دارید.
من فهمیدم که وسوسه ایی برای کمینه نگاه داشتن اندکی از اطلاعات به شکل محرمانه برای منافع اقتصادی کوتاه مدت وجود دارد. کدهای پیشرفته یا تکنیک های خاص امتیاز رقابت آزمندانه ایی را بوجود می آورد ٬ که می توانست بالقوه در افزایش فروش و منافع تاثیر داشته باشد. اما اگر هدف فراهم آوردن فروش بیشتر برای یک محصول باشد ٬ محصول باید بیشتر تجاری باشد تا متن باز.  متن باز اجازه دسترسی انحصاری بروی هیچ بخشی از کار را نمی دهد. این آن چیزی است که معنی می دهد.  

برگشت به ائی ناچ
اکنون من جعبه صابونم را زمین می گذارم و داستانم را ادامه می دهم.
هرچه ائی ناچ بیشتر پالایش می شد ٬ ما بیشتر به این نتیجه می رسیدیم که نام آن باید تغییر کند و لینوکس جنتو متولد شد. در این زمان ما نسخه های زیادی از ائی ناچ (اکنون جنتو) را انتشار داده بودیم٬ و به نسخه اول جنتو لینوکس رسیدیم. در این زمان من همچنین تصمیم گرفتم جعبه سلرون ۳۰۰ قدیمی را (با ساعت های کارکرد بالا و ۴۵۰ مگاهرتز در راک سولید) به یک برند جدید Abit BP6 (یک برد سلرون دوال که در بازار فراوان بود) ارتقاء دهم. من جعبه قدیمی را فروختم و با دستگاه سلرون ۳۶۶  دوال درهم کردم. پس از افزایش پردازشگر به چیزی با درخواست ۵۰۰ مگاهرتز ٬ من  عملیاتی شدم. اما متوجه شدم که ماشین جدی من پایدار نبود.
بدیهی بود که اولین عکس العمل من بازگشت به یک ۲x۳۶۶ باشد. اما اکنون من با مشکلات قوی تری تجربه دست و پنجه نرم کردن داشتم. از آنجا که ماشین من سی پی یو را در حالت کاری نگه می داشت ٬ ماشین قفل نمی شد. اما اگر من ماشین را در طول شب رها می کردم ٬ احتمال بسیار بالایی وجود داشت که ماشین کاملا قفل کند. بله٬ و ایراد idle ... اخ! پس از مقداری جستجو٬ من تعدادی کاربر دیگر لینوکس را هم پیدا کردم که مشکل مشابهی را با این بردهای مادر چند بخشی پیدا کرده بودند. یک چیپ در BP6 (آیا در کنترل گر PCI بود؟) به نظر می رسید که غیر منطقی کار می کند یا دست کم غیر قابل انتظار٬ که موجب قفل نمودن idle توسط لینوکس می شد.
من مقدار زیادی کد نوشته بودم ٬ و به این دلیل که توانایی سفارش که بخش دیگر PC را نداشتم ٬ گسترش جنتو متوقف شد. من بیشتر و بیشتر درباره لینوکس بدبین می شدم و تصمیم گرفتم به FreeBSD نقل مکان کنم. بله ٬ فری بی اس دی و اینجا جائی است که من این بخش را به پایان می برم -- شما را در بخش سوم خواهم دید. :)