امید محمدی



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


خب به نظر من کتاب خیلی خوبی بود البته این کتاب برای افرادی که اهل کامپیوتر و بیشتر دوستار لینوکس و متن باز ن برای من که کتاب خیلی جالبی بود. البته یه چیز دیگه اسم اول لینوکس, لینوکس نبوده و بهتره خودتون بخونید ترجمه ی رایگان کتاب توی نت هست و البته نسخه ی چاپی کتاب هم هست که من وبلاگ جادی رو چک می کردن دیدم که گفته بود تمام سود کتاب به مردم زله زده کرمانشاه میرسه ولی فک کنم این و دیگه بده به سیل زده ها نمیدونم از خودش بپرسید و یه ترجمه ی دیگه از جادی هست به اسم اسنوکرش یه رمان با ژانر سایبرپانک که . نمیگم چی به چیه به زودی ازش یه نقد میزارم برای خودم کتاب و ترجمه انقدر جذاب بود که یه شبی ۲۰ فصلشو خوندم و بزودی این کتاب رو با هم برسی می کنیم.


سوالی بود کامنت کنید در خدمتم.

شاد باشید و کتاب بخونید


سلام. امروز تصمیم گرفتم که برای خودم یه چالش بزارم که طی این تابستون با اینکه برای خرید مانیتور دوم برای کامپیوترم کارم میکنم تصمیم حداقل ۱۰ تا ۱۵ جلد کتاب بخونم و این رو به همه توصیه می کنم و بعد از خوندن هر کتاب طی فرصتی درباره ی کتاب در بلاگ پستی میزارم و در باره ی کتابی که خوندم یه چیز هایی میزارم که شاید یه نفر اون کتاب از نظرش جالب باشه و تصمیم بگیره اون کتاب رو بخونه.

خب تا الان لیست کتاب های زیر رو تهیه کردم و قراره که اون هارو بخونم:

فقط برای تفریح            از لینوس توروا (خالق لینوکس)

تاریخ مردوخ                  از آیت الله مردوخ کردستانی

پدر پول دار پدر بی پول   از رابرت کیوساکی

بازی های جنگی             از دیوید بیشاف

عقاید یک دلقک             از هاینریش بل

بیشعوری                    از خاویر کرمنت

نظریه ی بیگانگی         از مارکس

اسنوکرش                    از نیل استفنسون


خب این لیست کتاب هایی بود که میخوام بخونم اگه شما کتابی خوندین و ازش خوشتون اومده ممنون میشم زیر کامنت کنید که به لیست اضافه کنم .

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


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


همه می دونیم که خوندن کتباب خیلی مفیده. برای اینکه میتونیم اطلاعات مفیدی از شون دریافت می کنیم. تکنولوژی در حال گسترش و بزرگ شدن ـه. و خوندن کتاب میتونه بیشتر درک رو آسون تر کنه. میتونیم که کتاب‌ها رو توی دیوایس هایی مثل گوشی های موبایل , تبلت ها و لبتاب ها و یا کیندل ها و… بخونیم. تعداد زیادی کتاب توی فرمت PDF وجود داره که میتونیم از اون ها استفاده کنیم و از مطالب خوب کتاب‌ها بهره ببریم. در ادامه تعدادی از وبسایت های خوب و مفید که کتاب‌های PDF برای دانلود گذاشته و یکی از اون وبسایت ها کارش در حوضه ی کامپیوتره.


وبسایت های دانلود کتاب با فرمت PDF

  • Library Genesis

  • Bookboon.com

  • Free-Ebooks.net

  • Free Computer Books

  • ManyBooks

  • CALAMEO PDF DOWNLOADER

  • Internet Archive


Library Genesis

Library Genesis جایی ـه برای پیدا کردن و جستوجو در بین میلیون‌ها کتاب و مقاله . توی این وبسایت اکثر فایل‌ها یا همون کتاب‌ها با فرمت PDF ـه و در برخی از کتاب‌ها فرمتePUB هم به چشم میخوره. برای دانلود کتاب کافیه فقط اسم کتاب یا مقاله ی مورد نظرتون رو جستوجو کنید و بعد بر روی کتاب یا مقاله ی مورد نظرتون کلیک می‌کنید که صحفه ی مشخصات کتاب برای شما باز میشه و اگه از کتاب خوشتون اومد یه بار دیگه کلیک می‌کنید و بعد کتاب مورد نظرتون دانلود میشه.


Bookboon.com

یه سایت دیگه برای دانلود کتاب الکرونیک Bookboon هستش. این سایت بیش از ۵۰ میلیون کتاب الکترونیکی داره و در بخش‌های مختلفی هم کتاب الکترونیکی وجود داره. می تونیم از بخش‌های مختلف این سایت به فناوری اطلاعات,ادبیات,کتاب های مهندسی و… اشاره کرد.


Free-Ebooks

این وبسایت تعداد فرمت های بیشتری رو پشتیبانی میکنه و برای دانلود در دسترس قرار میده. فرمت هایی نظیر PDF , Epub , Kindle ,TXT. این سایت بیشتر تمرکزش رو روی فرمتPDF گذاشته اما همون طور که گفتم فرمت های دیگه رو هم داره اما روی فرمت PDF حساب ویژه ای باز کرده. و میتونید بین موضوعات مختلف موضوع مورد نظرتون رو انتخاب کنید و بعد از دانلود میتونید از خوندن کتاب لذت ببرید و یا اگه بخوایید میتونید از کتاب داخل وبسایت پیش نمایشش رو ببینید.


Free Computer Books

این سایت رو با فونت درشت تر و رنگ متفاوت نوشتم برای اینکه تمرکز اصلی این سایت روی مباحث مربوط به کامپیوتر,برنامه نویسی,ریاضیات و خلاصه تمامی مباحث مربوط به کامپیوتر که میتونید با کلیک کردن روی عنواین کتاب‌ها اطلاعاتشون رو ببینید و یا درصورت نیاز پیش نمایشش و یا اگر خواستید میتونید فایل رو دانلود کنید.


Many books

همون طور که از اسمش معلومه مجموعه‌ای بزرگ از کتاب‌هایی با فرمت های ePUB, pkg, mobi, pdb, PDF رو داره و میتونید کتاب هارو دانلود کنید و روی دیوایس هایی نظیر ایپد,کیندل,لبتاب,موبایل و یا تبلت هاتون بخونید و لذت ببرید .


CALAMEO PDF DOWNLOADER

همچنین در لیست سایت‌های دانلود رایگان PDF سایتCALAMEO PDF DOWNLOADER رو براتون قرار دادیم. شاید شما نخوایید کتاب بخونید شاید بخوایید رومه های معروف البته انگلیسی و یا مقالات نشریات رو بخونید. خب پس باید بگم که CALAMEO PDF DOWNLOADER جایی که میتونید از خوندن مجله های آنلاین لذت ببرید. مجله های با عناوینی مانندآشپزی , سفر , مد و ورزش , بازی‌های ویدیویی , و موسیقی.



Internet Archive

میتونم بگم از بهترین وبسایت های دانلود کتاب با فرمت های مخلف مثل کتاب الکترونیک , کتاب صوتی و حتی فیلم. کتاب‌های مختلف برای پلتفورم های مختلف با فرمت های مختلف. میتونید اسم کتاب مورد نظرتون رو سرچ کنید و بعد میتونید مشخصات رو ببینید و درصورت نیاز به رایگان دانلودش کنید.



توجه داشته باشید تمامی سایت‌هایی که در بالا معرفی کردیم سایت‌های انگلیسی زبان هستند و منابع بزرگ و عالی هستند و میتونن برای افزایش آگاهی هاتون در زمینه‌های مختلف و یا بالا بردن مهارت های زبان انگلیسی تون باشن.

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

قابل توجه ی دوستان خودم که حدود ۱۵ یا ۱۶ سالشونه و میگن دیره یکی از اقواممون تازه شروع کرده ۳۱ سالشه و خیلی هم داره پیش روفت میکنه اگه سؤالی هم براش پیش میاد من کمکش می کنم.

(خب شاید در آینده‌ای نه چندان دور آموزش زبان انگلیسی هم ساختم اما اگه کلاس زبان نمیتونید برید میتونید از منابع فارسی آموزش انگلیسی استفاده کنید )



خب وراجی زیاد کردیم منبع اصلی این ترجمه : lightpdf.com


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


همین اول کار لپ کلام و میگم و تفاوت اصلی و اساسی بین تبلت و کتاب خوان (e-book) رو میگم. تفاوت اصلی این دو که بیشتر به چشم میاد صفحه نمایش ها هستن. خب, باید بگم که تبلت ها از صفحه نمایش های Backlite LCD استفاده می کنن اما در کتابخوان ها از صفحه نمایش E Ink استفاده میشه.

صفحه نمایش های E Ink بیشتر شبیه به کاغذ هستند. این صحفه نمایش ها طوری طراحی شده اند که نوشته های جوهر دیجیتال آن ها شبیه به جوهر واقعی باشن. این نوع صفحه نمایش ها Backlit نیستند و از خودشون مانند صحفه نمایش های LCD نور رو ساتع نمی کنن. بخاطر اینکه این نوع صفحه نمایش ها طوری مهیا شده اند که بیشتر با چشم سازگاری داشته باشن و تجربه ی خواندن خوب و بدون خسته کردن چشم رو به کاربر بده.

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


تکنولوژی ها و دیگر قابلیت های کتابخوان ها

صفحه نمایش های E Ink نور رو ساتع نمیکنن, باطری کتابخوان ها عمر و دوام طولانی تری نسبت به تبلت ها دارند. و بعضی از صحفه نمایش های مدل E Ink از نور پس زمینه (frontlights) بهره می برند. این نور در صفحه نمایش است و نور زمینه رو بدون ساتع کردن نور به محیط اطراف افزایش میده و این متفاوت از نور تبلت هاست و در ضمن انرژی باطری کمتری رو مصرف میکنه.

و یک کتاب خوان با روشن بودن این قابلیت حدود ۱۰ هفته با استفاده ی مداوم کار میکنه اما تبلت ها حدود ۱۰ ساعت میتونن کار کنن.

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

یک تبلت می تونه کار یک کتابخوان دیجیتال رو بکنه البته تبلت ها ویژگی های دیگه ای مثل وبگردی , پخش ویدیو , عکس انداختن و. رو دارن.

مزیت قابل توجه در استفاده ی تبلت به عنوان کتابخوان اینه که می تونید از نرم افزار های اجرای کتاب های الکترونیک مختلفی استفاده کرد. شما  می تونید از یکی از استور ها به دلخواه یکی از برنامه های اجرا کتاب رو نصب و استفاده می کنید.

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



منبع : blog.the-ebook-reader.com

مترجم : امید

یک لینک مفید از وبلاگ جادی (متاسفانه وبلاگش فیلتره) که پستی درباره ی اینکه -ما ایرانی ها بیشعوریم که کتاب نمیخوانیم؟یاچی؟- رو گذاشته که میتونه مفید باشه.

برای دیدن این پستی که گفتم روی این لینک کلیک کنید.


هکر (hacker) چیست؟

پرونده اصطلاحات(Jargon File) شامل تعاریفی‌از’ هکر’ است که عموما در ارتباط با تعریف تکنیکی‌آن همراه با وصف سرخوشی‌حل مشکلات و مرتفع کردن محدودیت هاست. اگر شما می‌خواهید بدانید چگونه هکر شوید تنها دو تعریف به دردتان می‌خورد.

یک اجتماع ، یک فرهنگ مشترک ، از برنامه نویسان خبره و جادوگران شبکه که پیشینه آن از میان دهه ها به مینی‌کامپیوترهای‌اشتراک زمانی (time-sharing) و اولین تجریه های ‌ARPAnet می‌رسد. اعضای این فرهنگ اصطلاح ‘ هکر’  را ساختند . هکرها اینترنت را ایجاد کردند. آنان سیستم عاملUnix را آنچنان که امروز هست ایجاد کردند. هکرها usenet را اجرا کردند. آنان باعث شدند شبکه جهانی (World wide web) کار کند. اگر شما دارای این فرهنگ هستید و دیگران می‌دانند که شما چه کسی‌هستید و هکر می‌نامندتان؛ پس شما هکر هستید!

نگرش هکر محدود به ‘هکرنرم‌افزار’ نمی‌شود ، مردمانی‌هستند که منش هکر را به سایر زمینه ها مانند الکترونیک یا موسیقی‌سرایت می‌دهند. در حقیقت شما می‌توانید این فرهنگ را در بالاترین سطوح هر علم و هنری بیابید. هکرهای نرم‌افزار این هم روحان را در هر جا می‌شناسند، آنان را ‘هکر ‘ می‌نامند و برخی‌معتقدند که طبیعت هکر واقعا مستقل از زمینه ایست که او در آن کار می‌کند. اما در تمام این مقاله ما بطور خاص بر مهارت ها و منش های‌هکر نرم‌افزار، و فرهنگ های مشترکی که واژه ی ‘هکر’ را بوجود آورد تمرکز خواهیم کرد.

گروه دیگری‌از مردم هستند که متکبرانه خود را هکر می‌نامند اما نیستند! این مردمان (که بیشتر نرهای نابالغند) کسانی‌هستند که سیستمهای‌کامپیوتری و مخابراتی را ‘تخریب’ می‌کنند. هکرهای واقعی‌اینان را ‘شکننده (Cracker) ‘ می‌نامند و هیچ کاری‌به آنان ندارند. هکرهای واقعی اعتقاد دارند که اینان تنبل، بی‌مسئولیت و نه چندان باهوشند و می‌دانند که توانایی نفوذ به سیستمهای امنیتی‌شما را هکر نمی‌کند. همانگونه که ان اتومبیل را هیچگاه نمی‌توان مکانیک نامید. متأسفانه بسیاری از رومه نگاران و نویسندگان ناآگاهانه وا‌ژه ی’ هکر ‘ را برای‌توصیف شکننده ها (Crackers) بکار می‌برند و هکرها را تا سرحد مرگ عصبانی می‌کنند.

تفاوت اصلی این است: هکرها می‌سازند اما شکننده‌ها ویران میکنند.

اگر می‌خواهید هکر باشید (همواره ) مطالعه کنید. اما اگر می‌خواهید شکننده شوید گروه خبری‌alt.2600 را بخوانید و آماده باشید که ۵ تا ۱۰ سال را در زندان بگذرانید، پس از اینکه فهمیدید به اندازه‌ای که فکر می‌کردید زرنگ نیستید. این تمام چیزی است که درباره ی‌شکننده ها (Crackers) خواهم گفت.

منش هکر

منش هکر، هکر می‌آفریند و یاری‌می‌کند. او به آزادی و یاری متقابل معتقد است؛ برای آن که هکر نامیده شوید باید چنان رفتار کنید که گویا چنین منشی‌دارید و برای‌اینکه اینگونه رفتار کنید باید واقعا آن را داشته باشید. اگر به پروراندن منش هکر تنها برای پذیرفته شدن در این فرهنگ می‌اندیشید در اشتباه هستید! چنین منشی داشتن همواره کمکتان میکند یادگیرید و با انگیزه باشید. مانند تمام هنرها بهترین راه استاد شدن، نگاه کردن به استاد و تقلید از اوست – نه فقط در باب تفکر که حتی‌در احساس!

همانگونه که در شعر ذن زیر آمده است:

تا که راه یابی:    :  To follow the path

به استاد بنگر ،    ,look to the master

به دنبالش باش ،  , follow the master

با او برو ،    ,walk with the master

از نگاه او بنگر ،   , see through the master,

استاد شو!     . become the master

پس اگر میخواهید استاد شوید، آن قدر ذکرهای‌زیر را بگویید(افکار زیر را با خود مرور کنید) تا باورشان کنید:

۱– جهان پر از مشکلات جذابی‌است که میباید حل گردند.
هکر بودن هیجان دارد، اما هیجانی که نیازمند تلاش فراوان است و تلاش کردن نیازمند انگیزه. ورزشکاران موفق انگیزه خود را از لذتی که در جسمشان احساس میکنند، می‌گیرند؛ در گذر از حدود جسمانیشان. شما نیز باید از حل مشکلاتتان مشعوف شوید. از پیشرفت مهارتتان و زورآزمایی اندیشه‌ی‌تان.

اگر شما به طور ذاتی‌چنین شخصی‌نیستید باید این‌گونه گردید و گرنه انرژیتان با شهوت، پول، شهرت و … به هدر خواهید داد.
(همچنین باید به توانایی یادگیریتان ایمان آورید – باور به اینکه: گر چه تمام آن چه را لازم دارید نمی‌دانید اما اگر تنها بخشی از آنرا کشف کنید توانایی حل باقی را بدست می‌آورید)

۲هیچ مشکلی‌نباید دوبار حل گردد اندیشه های‌خلاق گرانبها و محدودند.
ذهن های خلاق باارزش هستند، منابعی محدود. آنان نباید با دوباره کشف کردن چرخ، به هدر بروند در حالی که هزاران معمای حل نشده جذاب باقی است. برای آن که کرداری مانند یک هکر داشته باشید باید باور کنید که وقت هکرها گرانبهاست – آنچنان که گویی یک وظیفه است که اطلاعتان را مبادله کنید، مشکلات را حل کنیدو راه حل‌ها را به دیگر هکرها بدهید تا آنان مشکلات جدیدتر را مرتفع کنند. بجای آنکه دائما حول همان‌ها بگردند.

(مجبور نیستید باور داشته باشید که تمام آنچه را خلق می‌کنید باید ببخشید- گرچه هکرهایی که چنین می‌کنند محترم‌ترین آنان هستند – با ارزش های‌هکر سازگار است که مقداری‌از آن را بفروشید تا برای خود خورد و خوراک و کامپیوتر تهیه کنید. چه خوب است اگر استعداد هکری خود را برای حمایت از خانواده و حتی‌ثروتمند شدن بکار گیرید، تا هنگامی‌که شرافت هنرتان و رفیقان هکرتان را فراموش نکنید.)

۳ کسالت و بیکاری‌شیاطینند.
هکرها (و عموما انسانهای خلاق) هرگز نباید کسل شوند یا مجبور به بیگاری‌شوند چرا که در این صورت آنها از انجام کاری که تنها آنان قادر به انجام آنند باز می‌مانند. این هرز رفتن همه را آزار می‌دهد. بنابراین کسالت و بیگاری نه تنها ناخوشایند بلکه واقعا شیاطینند.

برای اینکه مانند یک هکر رفتار کنید باید باور کنید که می‌خواهید تمام کسالت آوران را کنار بزنید نه تنها برای خودتان بلکه برای همه (خاصه سایر هکرها).

(یک استثناء بارز وجود دارد. هکرها گاهی کارهایی انجام می‌دهند که به نظر تکراری و خسته کننده می‌رسند، تنها برای پاکسازی ذهن شان یا برای بدست آوردن تجربه‌ای خاص. اما به اختیار ،هیچ فرد اندیشمندی نباید مجبور به پذیرفتن موقعیت کسل کننده‌ای‌گردد.)

۴آزادی‌خوب است.
هکرها ذاتا ضد استبدادند. هر که به شمادستور دهد، شما را از پرداختن به آنچه عاشق کشف آنید باز می‌دارد؛ گر چه آنان همواره برای دستوراتشان دلایل ابلهانه‌ی خود را دارند. با منش استبدادی باید مبارزه شود هر جا که پیدا شود چرا که شما و تمام هکرها را تحت فشار می‌گذارد .
(این به مفهوم مخالفت کلی‌با اتورتیه نیست. کودکان باید راهنمایی شوند و جنایتکاران مراقبت. هکر ممکن است نوعی از اتورتیه را قبول کند تا بیشتر از زمانی که برای‌اجرای دستورات از دست می‌دهد، بدست آورد. اما این تنها یک معادله آگاهانه است. یک قدرت فردی که مستبدان می‌خواهند قابل قبول نیست.)

مستبدان تنها با سانسور و پنهان کاری رشد می‌کنند و به همکاری داوطلبانه اعتمادی ندارند. آنها فقط نوعی از همکاری را دوست دارند که در کنترل آنان باشد، بنابراین برای اینکه یک هکر باشید باید دشمنی ذاتی با سانسور و رازداری‌، اعمال قدرت و ت برای مجبور ساختن افراد متعهد را در خود بپرورانید و باید که براین باور عمل کنید.

۵ منش جایگزین مهارت نیست.
برای آنکه هکر شوید مجبور به پروراندن مواردی از این منش‌هایید. اما تنها تقلید از این منشها شما را هکر نمی‌سازد همانگونه که شما را قهرمان یا خواننده نمی‌کند. هکر شدن احتیاج به تیزهوشی‌، تمرین، تمرکز و کار سخت دارد.

بنابراین شما باید یاد بگیرید که به منش مشکوک و به مهارت احترام بگذارید. هکرها نمی‌گذارند فضولان وقت شان را هدر دهند و به مهارت ایمان دارند به خصوص مهارت در درک کردن گرچه مهارت در هر زمینه ای‌دلپذیر است. مهارت در زمینه های مورد نیاز که متخصصان کمتری دارد بهتر است و تخصص در زمینه های مورد نیاز که به فکر متبحر، استادی و تمرکز نیاز دارند، بهترین.

اگر شیفته مهارت باشید از پروراندن آن در خود لذت خواهید برد . کار سخت و تمرکز بجای‌کاری‌کسالت بار به بازی‌سخت شبیه می‌گردد و این برای‌هکر شدن حیاتی‌است .

مهارت‌های پایه‌ای برای هکر شدن

منش هکر حیاتی‌است اما مهارت او حیاتی‌تر است. منش جایگزین مهارت نمی‌گردد و مجموعه مهارت های پایه ای خاصی وجود دارند که باید در خود بپرورانید تا هکرها شما را هکر بنامند.
این ابزار به آرامی تغییر میکند با گذشت زمان تکنولوژی مهارت های جدیدی ایجادمی‌کند و قدیمی‌‌ها را بی‌مصرف میکند. مثلا در گذشته زبان ماشین شامل این مجموعه بود، در حالیکه HTML اخیرا به این مجموعه اضافه شده است. اما این مجموعه در حال حاضر مشخصأ شامل موارد زیر است:

۱ – بیاموزید که چگونه برنامه بنویسید.
این مسلما پایه ای‌ترین مهارت هکر است. اگر شما هیچ زبان برنامه نویسی‌بلد نیستید، پیشنهاد می‌کنم با پیتون شروع کنید. پتیون تمیز طراحی‌شده است. به خوبی‌مستند سازی‌شده و تقریبأ ابتدایی‌است. با آنکه پتیون زبان اولیه خوبی‌است، یک اسباب بازی‌نیست. بلکه بسیار قدرتمند و قابل انعطاف است و مناسب پروژه های بزرگ. من یک مقاله مفصل تر در مورد انقلاب پیتون نوشته‌ام. خودآموزهای خوبی می‌توانید در وب سایتپیتون پیدا کنید.

جاوا زبان بسیار خوبی‌است البته بسیار مشکل تر از پیتون است، اما برنامه سریع تری ایجاد می‌کند و فکر می‌کنم انتخاب فوق العاده ای‌برای‌زبان دوم است .
البته شما نمی‌توانید با دانستن تنها دو زبان به مهارتهای یک هکر و یا حتی یک برنامه نوبس خوب برسید. شما باید بدانید چگونه در مورد مشکلات برنامه نویسی‌، جدای از زبان برنامه نویسی‌فکر کنید. برای آنکه یک هکر واقعی شوید، باید به جایی برسید که بتوانید یک زبان جدید را در دو، سه روز یاد بگیرید. این نیازمند آن است که چندین زبان کاملأ متفاوت را یاد بگیرید.

اگر به صورت جدی به برنامه نویسی روی آورید، باید C زبان پایه‌ایUnix را یاد بگیرید. ++C بسیار شبیه C است؛ اگر شما یکی از آنها را یاد بگیرید، یادگرفتن دیگری مشکل نخواهد بود. اما هیچ کدام به عنوان زبان اول قابل یادگیری نیستند. در واقع، هر چقدر از برنامه نویسی به زبان C پرهیز کنید، بازده‌تان بیشتر خواهد بود.

C بسیار کاراست و منابع کامپیوتر را کمتر مصرف می‌کند. متأسفانه C این کارایی را با تلاش بسیار شما برای مدیریت سطح پائین منابع (مانند حافظه) بدست می‌آورد. این نوع برنامه نویسی سطح پائین بسیار پیچیده و باگ -دوست است و زمان بسیاری برای رفع اشکال (Debug) لازم دارد. با قدرت و سرعتی که کامپیوترهای امروز دارند این معامله خوبی نیست. تیز هوشانه‌تر است که از زبانی استفاده کنیم که زمان کامپیوتر را بیشترمی‌گیرد و زمان برنامه نویس را کمتر. مانند ، پیتون.

زبانهای دیگری هستند که ارزش خاصی برای هکرها دارند. Perl به جهت دلایل کاربردی آن با ارزش است، به طور گسترده ای در طراحی صفحات فعال وب و مدیریت سیستم به کار گرفته شده است و حتی اگر شما هرگز با Perl برنامه ننوبسید، باید قادر به خواندن آن باشید. بسیاری از مردم از Perl در جایی استفاده می‌کنند که من پیتون را پیشنهاد کردم. برای اجتناب از برنامه نویسی C در جاهایی که نیاز به کارایی C ندارید. شما به فهمیدن کدهای ‌Perl احتیاج خواهید داشت.

لیسپ (LISP)به دلایل دیگری ارزشمند است – برای روشن نگری عینی که پس از یادگیری آن بدست خواهید آورد . حتی اگر هیچگاه از لیسپ به طور جدی استفاده نکنید، مسلما یادگیری آن شما را برنامه نویس بهتری خواهد کرد. (شما می‌توانید مهارت های اولیه ی‌LISP را به راحتی بانوشتن و تغییر دادن Modها برای ویرایشگر متن Emacs کسب کنید)

حقیقتا بهتر است هر پنج زبان ( پیتون ، جاوا ، C/++C ، پرل و LISP) را یاد بگیرید. جدا از ارزشی که این زبانها برای هکرها دارند، آنان رویکردهای کاملا متفاوتی برای برنامه نویسی دارند که مسا ئل با ارزشی به شما یاد می‌دهند.

نمی‌توانم دستورالعمل خاصی برای یادگرفتن برنامه نویسی بدهم (کار پیچیده ای‌است)، اما می‌توانم بگویم که کتاب‌ها و کلاسها به شما کمک نخواهند کرد (اکثر هکرها خودشان یاد گرفته‌اند) شما می‌توانید روشهایی را از کتاب فراگیرید اما ساختار فکری که این روشها را به مهارت واقعی تبدیل می‌کند، تنها با تمرین و شاگردی کردن بدست می‌آید. وظایف شما شامل ۱) خواندن کد و ۲) نوشتن کد خواهد بود.

یادگیری زبان برنامه نویسی مانند یادگیری نوشتن یک زبان واقعی است. بهترین راه خواندن چیزهایی است که استادان امر نوشته اند و سپس نوشتن برنامه ای از خودتان است؛ بسیار بیشتر مطالعه کنید، کمی‌بیشتر بنویسید، بیشتر مطالعه کنید، بیشتر بنویسید…. و تا آنجا ادامه دهید که نوشته هایتان قدرت و صلابت کارهای استادتان را پیدا کند.

سابقا پیدا کردن کد خوب مشکل بود، برنامه های بزرگی که متن آنها در دسترس بود تا هکرها بخوانند و آزمایش کنند، بسیار محدود بود. اکنون این مسئله به طور قابل ملاحظه‌ای تغییر کرده است؛ اکنون نرم‌افزارها ابزارهای‌برنامه نوبسی و سیستمهای‌عامل بازمتن (که تماما بوسیله هکرها نوشته شده است) بسادگی قابل دسترس است – که مرا به نوشتن بخش بعد ترغیب می‌کند…

۲ – یکی‌از یونیکس های‌بازمتن را بگیرید و استفاده و اجرا کردن آن را بیاموزید.
فرض می‌کنیم یک کامپیوتر شخصی دارید یا لااقل به آن دسترسی دارید (بچه های امروزی خیلی راحت به آن دسترسی دارند:-)). مهمترین قدم اولیه ای که هر مبتدی برای هکر شدن می‌تواند بردارد، گرفتن یک کپی از لینوکس (Linux) یا بی‌اس دی-یونیکس (BSD-Unix)؛ نصب کردن آن روی‌کامپیوتر شخصی و اجرای آن است.

بله ، سیستم عاملهای فراوانی در کنار یونیکس وجود دارد. اما تمام آنها به صورت باینری توزیع می‌شوند و شما قادر به خواندن و تغییر کد آن نیستید. تلاش برای ایجاد تغییر بر روی یک کامپیوتر داس یا ویندوز یا MacOS مانند این است که بخواهید در لباس شوالیه رقص بیاموزید.

تحت OS/X این کار ممکن است ، اما فقط بخشی از این سیستم بازمتن است. شما به موانع بسیاری برخورد خواهید کرد و باید مواظب باشید تا عادت بد تکیه بر کد اختصاصی اپل را در خود توسعه ندهید. در صورتی که بر روی یونیکس‌ها تمرکز کنید، چیزهای مفیدتری فراخواهید گرفت.

یونیکس سیستم عامل اینترنت است. اگر اینترنت را بدون یونیکس یاد می‌گیرید، هیچ وقت نمی‌توانید یک هکر اینترنت باشید. به این خاطر فرهنگ هکر امروز کاملأ یونیکس-محور است. (این مطلب همیشه صادق نبوده است . بسیاری از هکرهای با سابقه از این موضوع رضایت ندارند اما پیوند محکم یونیکس و اینترنت آنچنان قوی است که حتی قدرت شیطانی مایکروسافت نیز نتوانسته است خلل چندانی در آن ایجادکند.)

پس یک یونیکس نصب کنید. من به شخصه لینوکس را دوست دارم اما راههای دیگری هم وجود دارد ( بله! شمامی‌توانید مایکروسافت ویندوز و Linux رابا هم داشته باشید). یاد بگیرید، اجرا کنید، ور بروید، کدهایش را بخوانید و تغییرشان دهید. ابزار برنامه نویسی بهتری در اختیار خواهید داشت، مانند C , LISP , Python و Perl که در سیستم عامل ویندوز خواب داشتن آن ها را می‌بیند. بسیار جذاب و سرگرم کننده خواهد بود و آنچنان در دانش غرق میشوید که حتی متوجه آن نمی‌شوید تا هنگامیکه به مانند یک استاد هکر به پشت سرتان بنگرید!

برای اطلاعات بیشتر درباره ی یادگیری‌Unix به The Loginataka نگاه کنید. همین طور شمامی‌توانید نگاهی بهThe Art Of Unix Programing (هنر برنامه نویسی در یونیکس) بیاندازید.

برای آن که چیز هایی از لینوکس دست گیرتان شود به سایت Linux Online بروید؛ شما می‌توانید از آن جا دانلود کنید یا (ایده ی‌بهتر) یک گروه کاربران لینوکس محلی پیدا کنید تا به شما در نصب لینوکس کمک کنند. از دیدگاه یک کاربر تازه کار تمام توزیع های لینوکس بسیار شبیه یکدیگرند.

شما می‌توانید راهنما و منابعBSD Unix را در سایت www.bsd.org پیدا کنید.

من نیز مقالاتی مبتدی درباره ی پایه های‌یونیکس و لینوکس نوشته ام.

(توجه : من در حقیقت نصب کردن هیچ کدام از Linux یا BSDها را به طور خاص به شما توصیه کنم ، برای هر تازه کاری هر کدام از این ها یک پروژه ی انفرادی است. برای لینوکس، یک گروه کاربران لینوکس در محل خود پیدا کنید و از آنها برای کمک سوال کنید.)

۳ استفاده از وب و نوشتن HTML را یاد بگیرید.
بسیاری از چیزهایی که فرهنگ هک ساخته است خارج از افق دید شماست، کمک به کارخانه‌ها، دفاتر و دانشگاه‌ها بدون اینکه تأثیر مشخصی در زندگی غیر هکرها نداشته باشد. در این میان اینترنت یک استثناء عمده است، سرگرمی درخشان هکری که حتی به اعتراف ت مداران در حال تغییر دادن جهان است . تنها به همین خاطر (و همچنین بسیاری‌از دلایل مشابه دیگر) یاد گرفتن کار در اینترنت احتیاج دارید.
این فقط به این معنی نیست که چگونه از یک مرورگر استفاده کنید(!) بلکه به معنی یادگیری‌HTML است . اگرهنوز برنامه نویسی یاد نگرفته‌اید، نوشتن HTML عادت های ذهنی‌ را برایتان فراهم می‌کند که به یادگیری برنامه نویسی کمک می‌کند. پس برای خودتان یک Homepage درست کنید. سعی کنید از XHTML استفاده کنید که نسبت به HTML سنتی تمیزتر است.(منابع بسیار خوبی برروی وب برای تازه کارها وجوددارد؛ این یکی از آن هاست!)

اما نوشتن یک Homepage به هرحال آنقدر خوب نیست که شما را هکر کند. وب پر از Homepage است. بیشترشان بی‌ارزشند. لجن های بی‌محتوا، فضولات شیک، اما مطمئن باشید که لجن همیشه لجن است. (برای اطلاعات بیشتر صفحه یTheHTML Hell را ببینید.)

برای با ارزش بودن؛ Homepage تان باید محتوا داشته باشد و برای هکرهای دیگر جذاب و یا آموزنده باشد. تمام اینها شمارا به بخش بعد هدایت می‌کند…

۴ اگر انگلیسی‌بلد نیستید آن رایاد بگیرید.
به عنوان یک آمریکایی بخاطر آنکه زبان مادریم انگلیسی است قبلأ از ذکر این موضوع ناراحت بودم. حداقل این می‌تواند یک امپریالیسم فرهنگی‌تلقی‌گردد. ولی تعدادی از غیر انگلیسی زبانان از من خواستند که این موضوع را متذکر شوم که انگلیسی زبان فرهنگ هکر و اینترنت محسوب می‌گردد و شما احتیاج خواهید داشت که این زبان را یادبگیرید تا در جامعه هکرها فعال شوید.

این موضوع واقعیت دارد. حدود سال ۱۹۹۱ متوجه شدم که بسیاری از هکرها که انگلیسی‌زبان دومشان بود آن را برای بحث های تکنیکی‌شان بهره می‌گرفتند، حتی اگر زبان مادریشان یکی بود. به من اطلاع دادند که انگلیسی بعلت غنی‌تر بودن به لحاظ لغات فنی برای این کار مناسب‌تر است . به همین دلیل ترجمه متن‌های فنی که در زبان انگلیسی هستند، غالبا رضایت بخش نیست. لینوس توروالدز که یک فنلاندی است، کد خود را به زبان انگلیسی تشریح کرده است (و هرگز غیر از این روش، روش دیگری را پیش نگرفته است) تسلط بر انگلیسی، عامل مهمی در جمع کردن جامعه جهانی برنامه نویسان لینوکس بوده است. این مورد نمونه قابل ذکری در مورد نقش زبان انگلیسی است.

موقعیت فرهنگ هکر

مانند بسیاری از فرهنگ‌های برپایه ی روابط غیر اقتصادی، هکرگری نیز با شهرت اداره می گردد، شما سعی می‌کنید که مسئله جالبی را حل کنید اما اینکه آن مسئله چقدر قابل تأمل است یا راه حل شما واقعا چقدر خوب است، چیزی است که تنها استادان شما صلاحیت تأیید آن را دارند.
به همین ترتیب، وقتی وارد بازی هکر ها شدید، مدارجتان را با آنچه سایرین در مورد شما فکر می کنند بدست خواهید آورد (به این علت است که تا هنگامی که دیگران شما را هکر نمی دانند واقعأ هکر نیستید). این حقیقت بوسیله پنداری که هک را یک کار منزوی گرایانه می‌داند، محو شده است؛ هم چنین با وجود این تابوی فرهنگ هکری (که در حال از میان رفتن ولی فعلا همچنان نیرومند است) در برابر پذیرش اینکه تصدیق خود یا دیگری، تنها در گیر انگیزه یک شخص باشد.

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

پنج چیز وجود دارد که با انجام آن مورد احترام هکرها قرار می‌گیرید:

۱ – برنامه‌های باز– متن بنویسد
اولین (محوری ترین و سنتی ترین) روش، نوشتن برنامه‌هایی است که هکرهای دیگر آن را جالب و مفید می‌دانند و سپس دادن کد منبع برنامه‌ها به دیگران.
(ما قبلا این را "نرم افزار آزاد" می‌نامیدیم ، اما این اصطلاح موجب اشتباه بسیاری از مردم شد که نمی‌دانستند منظور از آزاد دقیقا چیست، امروزه بسیاری از ما حداقل به نسبت ۲ به۱ اصطلاح "بازمتن" (open-source) را ترجیح می دهیم.)
محترم ترین هکر ها [1] افرادی هستند که برنامه‌های بزرگی نوشته اند – برنامه‌های پرقدرتی که احتیاجات گسترده ای را مرتفع می سازد – و آنان را در دسترس همگان قرار داده اند.

۲ – به آزمایش ورفع اشکال کردن برنامه‌های بازمتن کمک کنید
هکرها به کسانی که نرم افزارهای بازمتن را آزمایش و رفع اشکال می‌کنند، یاری میرسانند. در این دنیای ناقص ناگزیر به صرف دقت بسیاری برای رفع اشکال برنامه‌ها هستم، به این علت است که مولفان بازمتن میگویند یک آزمایشگر خوب ( تعریف کردنش دشوار است؛ مشکلات در ضمن انتشار، کسی که بتواند اشتباهات یک انتشار عجله ‌ای را تحمل کند و مشکلات نرم‌افزار را گزارش کنند) سزاوار یاقوت به اندازه ی وزنشان هستند. حتی یک نفر از آنان میتواند رفع اشکال کردن را از یک کابوس طولانی به یک دردسر عبرت آموز تبدیل کند. اگر مبتدی هستید یک نرم افزار در حال برنامه نویسی پیدا کنید و یک آزمایشگر خوب باشید. یک پیشرفت طبیعی از کمک به آزمایش برنامه تا کمک به رفع اشکال کردن آن و بهتر کردن آن است. از این راه چیزهای بسیاری یاد می‌گیرید و روابط خوبی با افرادی که بعدا شما را کمک خواهند کرد بر قرار خواهید کرد.

۳ اطلاعات خوب را منتشر کنید 
کار خوب دیگری که می‌توانید بکنید جمع آوری و دستچین کردن مطالب جالب و مفید در برگه‌های وب یا پرونده‌هایی مانند سؤالات متداول ( FAQ ) و منتشر کردن آن است. گردآورندگان مجموعه سؤالات متداول (FAQ) به اندازه برنامه نویسندگان بازمتن مورد احترام هستند.

۴ به پایداری شالوده ی کار کمک کنید
فرهنگ هکر (و مهندسی اینترنت بعنوان شاخه‌ای از آن) با داوطلبان به پیش می رود. بسیاری از کارهای کوچک ولی ضروری وجود دارند که باید انجام شوند. مدیریت لیست‌های پستی و گروههای خبری، مرتب کردن آرشیو نرم افزارهای بزرگ، گسترش RFCها و سایر استانداردهای فنی.
مردمی که این کارها را انجام می دهند مورد احترام فراوان هستند. چرا که همه می دانند این نوع مسئولیت چقدر زمانبر است در حالیکه جذابیت زیادی مانند بازی کردن با کد هم ندارد. انجام آنها نشاندهنده ی ایثارگریست.

۵ – به خود فرهنگ هکر کمک کنید
در انتها می توانید به خود فرهنگ کمک کنید و آن را منتشر کنید (مثلأ با نوشتن مقاله ای در مورد اینکه چگونه هکر شویم :-) ). گرچه این کاری نیست که در همان ابتدا انجام دهید تا وقتی که شهرت خوبی در بین هکرها بدست آورید.
فرهنگ هکر، رهبر به معنی دقیق آن ندارد. اما قهرمانان، پیران ، مورخان و سخنگویان زیادی دارد. بعد از این که به اندازه ی کافی در سنگرها مدت زیادی را سپری کنید، می‌توانید یکی از آنها شوید. باید بدانید که هکرها به منیت آشکار پیران خود بدبینند؛ رسیدن به این درجه از شهرت آشکارا خطرناک است. به جای تلاش برای رسیدن به آن موقعیتتان را چنان بسازید که در مسیرشما افتد. سپس در مقامتان فروتن و مهربان باشید.

رابطه هکر / نرد (Nerd)

ارتباط هکر و نرد بر خلاف افسانه مشهور، برای هکر بودن اجباری بر نرد بودن نیست (نرد به شخصی گفته می‌شود که تمام زندگی او بر کامپیوتر/تکنولوژی استوار است -مترجم -). اما به هرحال نرد بودن کمکتان می‌کند و بسیاری از هکرها اینگونه‌اند. نرد بودن کمکتان می‌کند که بر مهمترین مسائل مانند فکر کردن و هک کردن تمرکز داشته باشید.
به همین خاطر بسیاری از هکرها صفت نرد بودن و حتی سرسختانه‌تر ‘geek’ را به عنوان شعار برگزیده‌اند. روشی برای بیان جداییشان از انتظارات عوامانه اجتماع – برای بحث بیشتر به صفحه‌ی geek مراجعه کنید.

اگر شما بتوانید به اندازه کافی روی هک کردن تمرکز کنید در حالیکه به زندگیتان هم برسید، بسیار عالیست. امروزه انجام این کار از ۱۹۷۰ که من تازه کار بودم بسیار ساده تر است؛ جریان غالب فرهنگی با تکنو- نردها بسیار مهربانتر است و تعداد کسانی که می فهمند هکرها عاشقان و همسران بلند مرتبه‌ای هستند هر روز زیادتر می شود.

اگر شما بخاطر نرد بودنتان به هکر بودن علاقه‌مند شده‌اید هم خوب است! حداقل برای متمرکز شدن مشکلی نخواهید داشت. شاید هم در آینده از انزوا درآمدی!

نکاتی در باب طریقت

نکاتی در باب طریقت باز می‌گویم که شما برای هکر شدن باید ساختار فکری هکری بدست آورید. چیزهایی هست که هنگامیکه کامپیوتر ندارید می‌توانید انجام دهید. آنها جایگزین هک کردن نمی شوند (هیچ چیز نمی‌شود) اما بسیاری از هکرها انجامشان را دوست دارند و احساس می کنند با انجام آنها به نوعی به روح هک کردن نزدیک می شوند.


-بیاموزید که زبان مادریتان را خوب بنویسید. گرچه معروف است که برنامه نویس ها نمی‌توانند بنویسند، یک تعداد غافلگیر کننده‌ای از هکرها (تمام بهترین هکرهایی که من می‌شناسم) نویسندگان توانایی هستند.
-داستانهای علمی – تخیلی بخوانید. به جلسات داستانهای علمی بروید. (جای خوبی که می توانید هکرها و هکر دوستان را ببینید.)
-ذن تمرین کنید و/ یا به هنرهای رزمی بپردازید (انظباط روحی در جهات بسیاری شبیه‌اند)
-گوش تان را به موسیقی حساس کنید. بیاموزید که به نوع خاصی از موسیقی را درک کنید. نواختن برخی آلات موسیقی را به خوبی فرابگیرید یا آواز خواندن یاد بگیرید.
-کار با جملات قصار و بازی با کلمات را به خوبی بیاموزید.

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

به همان میزان که بازی می‌کنید، کارکنید و همان قدر که کار می‌کنید، بازی کنید. برای هکر‌های واقعی مرزی میان ” بازی ، ” فعالیت ، ”دانش و ”هنر وجود ندارد و این با پدیدار شدن سطح بالایی از سرزندگی سازنده همراه خواهد بود. به هیچ وجه به اطلاعات مهارت‌های محدود اکتفا نکنید. برخلاف آن که بسیاری از هکرها خود را یک برنامه نویس معرفی می کنند، دارای مهارت‌های بسیاری هستند – مدیریت سیستم، طراحی وب و رفع اشکال‌های سخت‌افزاری PC یکی از معمول ترین آن هاست. هکری که مدیر سیستم است، اغلب، یک برنامه نویس حرفه‌ای و یک طراح وب است. هکر هرگز کاری را نیمه انجام شده رها نمی‌کند، اگر به موضوعی بپردازد در رابطه با این موضوع مهارت‌هایش را به اوج کمال می‌رساند.
در پایان چیزهایی هستند که نباید انجام دهید:

-از اسامی ابلهانه و بزرگ نما (قلمبه!) استفاده نکنید.
-در آتش افروزیهای گروه‌های خبری و یا هر بحث بی فایده ی دیگر شرکت نکنید.
-خودتان را "ولگرد سایبر" خطاب نکنید، وقت خود را با چنین افرادی هدر نکنید.
-نامه‌های الکترونیکی پر از غلط املایی و دستور زبانی نفرستید.

تنها چیزی که از این ها عایدتان می شود شهرت یک دلقک است. هکرها حافظه خوبی دارند – سالها طول می کشد تا دسته گلی که به آب داده‌اید فراموش شود و مورد قبول واقع شوید.

بر مشکل نام‌های کاربری یا اسامی مستعار باید تاکید کنم. پنهان کردن نام واقعی پشت رموز، کار ابلهانه و بچه گانه کرکر ها(crackers) و warez d00dz ویا دیگر فرم‌های پیش پا افتاده ی زندگیست. اگر نام مستعاری دارید آن را دور بیاندازید. در میان هکرها این حقیقتا باعث می‌شود تا شما را به فراموشی بسپارند. هکران از آنچه که انجام می‌دهند مغرورند و آن را وابسته به نام حقیقی خود می‌خواهند.

منابع دیگر

پیتر سیباج (Peter Seebach) برای مدیران سیستمی که نمی دانند چطور با هکرها سر کنند، یک FAQ مکمل نوشته است که Hacker FAQ نام دارد. اگر سایت Peter پاسخ دهی نمی‌کند، این جستجوی سایت Exciteمی‌تواند یک کپی خوب برای شما پیدا کند.


این جا یک سند وجود دارد که How To Be A Programmer (چگونه یک برنامه نویس شویم) نام دارد این یکی از بهترین و کامل ترین هاست. ارزش این مستند فقط مربوط به آموزش کد نویسی نیست، در این سند درباره ی کد نویسی به صورت گروهی و چالش‌های یک کد نویسی گروهی صحبت شده است.

من مقاله ای به نام تاریخ اجمالی هکرگری : "A Brief History Of Hackerdom" نیز نوشته‌ام.

برای آشنایی با فرهنگ لینوکس و بازمتن مقاله‌ای با نام "کلیسای فقید و بازار" یا "The Catedral and the Bazaar" نوشته‌ام. ادامه ی این مقاله در مقاله ای به نام Homesteading Noosphere آمده است.

Rick Moen، مقاله‌ای به نام How to Run A Linux User Group نوشته است. (یک گروه کاربران لینوکس چطور به کار می‌افتد؟)

باز هم از Rick Moen و من (اریک ریموند) مقاله‌ای به نام چگونه یک سوال هوشمندانه بپرسیم، How to Ask Smart Questions وجود دارد.

اگر شما به اطلاعات پیش‌نیاز برای کامپیوتر‌های شخصی و شبکه ی اینترنت احتیاج دارید، به مقاله ی The Unix and Internet Fundamentals HOWTO (پایه‌های یونیکس و اینترنت) مراجعه کنید.

اگر شما برنامه‌ای منتشر می‌کنید و یا وصله‌ای برای برنامه‌ای می نویسید، به Software Release Practice HOWTO (راهنمای تمرین انتشار برنامه‌ها) سر بزنید.

اگر شما به اشعار ذن علاقه مند هستید، احتمالا باید از این خوشتان بیاید: Rooties Root: The Unix Koans of Master Foo

سؤالاتی که زیاد پرسیده شده اند

س به من یاد می دهید چطور هک کنم ؟
ج: از اولین روز انتشار این برگ هر هفته (گاهی هر روز) چندین درخواست از مردم بدستم می‌رسد که: همه چیز هک کردن را به من یاد بدهید! متأسفانه وقت و انرژی کافی برای این کار ندارم. پروژه‌های هکری من و مسافرتهایم بعنوان مدافع بازمتن روزی ۱۱۰٪ وقتم را می‌گیرد.
حتی اگر هم می‌توانستم؛ هک کردن هنر و منشی است که شما خود باید یاد بگیرید. بعدا متوجه خواهید شد که با آنکه هکرها دوست دارند به شما کمک کنند، اما اگر بخواهید همه چیز را حاضر و آماده در دهان شما بگذارند، تحویلتان نمی‌گیرند.
اول خودتان چیزهایی یاد بگیرید. نشان دهید که دارید سعی می کنید، که توانایی یاد گرفتن دارید سپس به سراغ هکرها بروید و پرسشهایتان را مطرح کنید.
اگر می‌خواهید به هکری نامه ی الکترونیکی بفرستید باید از قبل دو چیز را بدانید. اولین چیز این که ما متوجه شدیم که کسانی که در نوشته‌هایشان بی دقت‌اند معمولا تنبل‌تر از آنند که هکرهای خوبی بشوند. بنابراین مواظب غلط‌های املایی و انشایی خودتان باشید و گرنه شما را نادیده می‌گیرند. دوم این که هرگز جواب نامه‌ی الکترونیکی خود را در آدرسی غیر از آدرسی که از آن نامه می‌فرستید نخواهید. ما می‌دانیم که کسانی که این کار را می کنند انی اند که از حساب ی استفاده می کنند و هیچ علاقه ای به کمک کردن به ها نداریم.

س خوب پس از کجا شروع کنم ؟ 
ج‌ : بهترین راه برای شروع رفتن به جلسه یک لاگ (گروه کاربران لینوکس"Linux user group LUG" ) است. این گروهها را می توانید در سایت LDP بیابید. به احتمال قوی می‌توانید یکی از آنها را در حوالی خود بیابید که احتمالأ وابسته به یک دانشگاه یا مؤسسه است. اعضای لاگ احتمالأ به شما یک نسخه از لینوکس می‌دهند و حتمأ کمکتان می‌کنند که آنرا نصب کنید.

س کی باید شروع کنم ؟ آیا خیلی دیر نشده است ؟
ج : در هر سنی که علاقه‌مند شدید می‌توانید یاد بگیرید. اکثر مردم در سن ۱۵ تا ۲۰ سالگی علاقه‌مند می شوند؛ من استثناها

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


کلیسای جامع و بازار

سیستم‌عامل لینوکس، ویرانگر است. حتی پنج سال پیش، چه کسی می‌توانست تصورش را بکند که یک سیستم‌عامل جهانی بتواند همچون یک معجزه از ابتکارهای پاره وقتی چندین هزار تن از برنامه‌نویسان که در سرتاسر جهان پراکنده‌اند و به وسیله‌ی اینترنت با هم در ارتباطند، شکل یابد؟

حقیقتاً، من چنین تصوری نمی‌کردم. اوائل سال ۱۹۹۳، زمانی که لینوکس به دایره ذهن من راه یافت، ده سال می‌شد که من درگیر یونیکس و جنبش باز-متن بودم. من یکی از اولین شرکت‌کنندگان پروژه GNU در اواسط دهه ۱۹۸۰ بودم و تعداد زیادی از نرم‌افزار‌های بازمتن را بر روی شبکه انتشار دادم، و در توسعه بسیاری از نرم‌افزارهـا (نظیر nethack, Emacs VC and GUD modes, xlife و …) که هنوز به طور گسترده مورد استفاده قرار می‌گیرند، نقش مستقیم یا غیر مستقیم داشتم. فکر می‌کردم که می‌دانم چه چیزی در حال رخ دادن است.

لینوکس ویرانگر‌تر از آن چیزی بود که من فکر می‌کردم. من با ابزارهایی ساده در حال وعظ با انجیل یـونیکس بودم! و سالها به شکلی تکاملی و با ساختار موجود برنامه‌نویسی می‌کردم. اما همچنین بر این باور بودم که یک نوع پیچیدگی بحرانی خـاصی در روش قبلی وجود دارد که نیازمند روش ساخت یافته‌تر و متمرکز‌تری است. من بر این عقیده بودم که نرم‌افزارهای پایه‌ای و مهم (سیستم‌عامل و ابزار‌های بزرگی همچون Emacs) می‌بایست با مهارتی خاص و به وسیله‌ی نوابغی منحصر به فرد یا گروهی از دانشمندان منزوی، همانند یک کلیسا ساخته شوند؛ بدون اینکه نسخه بتایی از آن را قبل از زمان ارائه آن توزیع کنند.

لینوکس ویرانگر‌تر از آن چیزی بود که من فکر می‌کردم. من با ابزارهایی ساده در حال وعظ با انجیل یـونیکس بودم! و سالها به شکلی تکاملی و با ساختار موجود برنامه‌نویسی می‌کردم. اما همچنین بر این باور بودم که یک نوع پیچیدگی بحرانی خـاصی در روش قبلی وجود دارد که نیازمند روش ساخت یافته‌تر و متمرکز‌تری است. من بر این عقیده بودم که نرم‌افزارهای پایه‌ای و مهم (سیستم‌عامل و ابزار‌های بزرگی همچون Emacs) می‌بایست با مهارتی خاص و به وسیله‌ی نوابغی منحصر به فرد یا گروهی از دانشمندان منزوی، همانند یک کلیسا ساخته شوند؛ بدون اینکه نسخه بتایی از آن را قبل از زمان ارائه آن توزیع کنند.

این واقعیت که این سبک بازار مانند کار می‌کرد، و البته خوب هم کار می‌کرد، یک شوک محرز بود.

زمانی که راهم را پیدا کردم، علاوه بر کار سخت در پروژه‌های مختلف، سعی می‌کردم تا بفهمم چرا دنیای لینوکس نه تنها به دلیل اغتشاش و پریشانی از هم پاشیده نشد، بلکه با قدرت و سرعتی مثال زدنی از کلیسا سازان! پیشی می‌گیرد.

در اواسط سال ۱۹۹۶ حس کردم که به نتایجی برای درک این مطلب رسیده‌ام. شانس و اقبال مرا به سمت راه درستی برای تست تئوری‌ام، راهنمایی کرد. در قالب یک پروژه بازمتن، عمداً مدل بازار را بر روی آن پیاده کردم و نتیجه آن موفقیتی پر معنی و مهم شد.

در ادامه این مقاله، به شرح داستان آن پروژه خواهم پرداخت و در میان آن، نکات مورد نیاز برای یک پروژه بازمتن موفق را بیان خواهم کرد. من تمامی این تجربیات را در ابتدا از دنیای لینوکس یاد نگرفتم، اما در ادامه خواهیم دید که چطور دنیای لینوکس به آن‌ها ارزش ویژه‌ای می‌دهد. اگر نظر من درست باشد، به شما کمک خواهد کرد که تا دقیقاً دریابید که چه چیز، جامعه لینوکس را به چنین منبع ارزشمندی از نرم‌افزار‌های خوب تبدیل کرده است – و همچنین به شما کمک خواهد کرد که خلاق‌تر و کارا‌تر شوید.


نامه باید به مقصد برسد

در سال ۱۹۹۳، من در حال کار در قسمت فنی یک ISP دسترسی-آزاد (Free Access) کوچک به نام CCIL در غرب Chester در Pennsylvania بودم. (من یکی از مؤسسان CCIL بودم و تنها نرم‌افزار تابلوی اعلانات (‌Bulletin Board) چندکاربره مان را نوشتم – شما می‌توانید به وسیله‌ی telnet به locke.ccil.org آن را آزمایش کنید که هم اکنون تقریباً سه هزار کاربر را در ۱۹ خط پشتیبانی می‌کند) این کار به من امکان دسترسی ۲۴ ساعته به اینترنت را از طریق خط 56K می‌داد. در حقیقت، دقیقا منطبق با نیازم بود!

طبیعتا، با پست الکترونیکی نیز زیاد سر و کار داشتم. بنا به دلایلی، کار کردن با پروتکل SLIP بین ماشین خانگی‌ام (snark.thyrsus.com) و CCIL خیلی سخت بود. سرانجام زمانی که موفق شدم، انجام تناوبی عمل telnet برای چک کردن نامه هایم را آزاردهنده یافتم. آنچه که می‌خواستم این بود که نامه هایم چنان بر روی سیستم خانگی‌ام دریافت شوند که زمانی که نامه‌ها می‌رسند، من متوجه شوم و بتوانم آن‌ها را به وسیله‌ی تمامی ابزارهای محلی‌ام مدیریت کنم.

سیستم ارسال ساده پست الکترونیکی (Simple Sendmail Forwarding) جواب‌گو نبود، چرا که ماشین شخصی من همواره به شبکه متصل نبود و آدرس IP ثابتی نداشت. آنچه که نیاز داشتم، برنامه‌ای بود که به کانکشن SLIP من دسترسی پیدا کرده تا نامه هایم را در اختیارم قرار دهد. می‌دانستم که چنین چیزی وجود دارد و اکثر آن‌ها از پروتکل ساده‌ای در لایه کاربرد به نام POP استفاده می‌کنند. و همانطور که مطمئن بودم، یک سرویس‌دهنده POP3 با سیستم‌عامل BSD/OS در آن زمان وجود داشت.

من نیاز به یک سرویس گیرنده POP3 داشتم. بنابراین، به شبکه مراجعه کردم و یکی پیدا کردم. در واقع، سه یا چهار تا پیدا کردم. برای مدتی از pop-perl استفاده کردم، اما آن فاقد یک ویژگی بدیهی بود؛ یعنی توانایی برای هک کردن آدرس‌های نامه‌های دریافت شده تا پاسخ نامه‌ها به درستی داده شود.

مشکل این بود: فرض کنید فردی با نام joe از locke برای من نامه‌ای فرستاده باشد. اگر من نامه را از snark دریافت کرده و بخواهم به آن پاسخ دهم، در این صورت سیستم نامه‌رسان من تلاش می‌کند تا آن را به فردی به نام joe در snark که وجود خارجی ندارد، برساند. با دست ویرایش کردن آدرس‌ها تا ccil.org@ به آن ضمیمه شود، سریعاً به کاری عذاب آور تبدیل شده بود.

حقیقتاً، این کاری بود که کامپیوتر می‌بایست برای من انجام دهد. اما هیچ‌کدام از سرویس گیرنده‌های POP نمی‌دانستند که چطور باید این کار را انجام دهند و این به ما درس اول را داد:

۱) شروع هر نرم‌افزار خوب از مشکلات شخصی برنامه‌نویسان آن است.

شاید این مسئله بدیهی به نظر برسد (این یک ضرب‌المثل قدیمی است که نیاز مادر اختراع است”) اما اکثر توسعه‌دهندگان نرم‌افزار زمان زیادی از عمرشان را به دلایل اقتصادی، صرف نوشتن برنامه‌هایی می‌کنند که نه به آن نیاز دارند و نه علاقه‌ای. اما نه در دنیای لینوکس! – توضیح خواهم داد که چرا میانگین کیفیت نرم‌افزار‌هایی که از جامعه لینوکس سرچشمه می‌گیرد، اینقدر بالا است.

خوب، آیا من به سرعت و در یک حرکت آتشی به نوشتن یک سرویس گیرنده POP3 جدید پرداختم تا با انواع موجود به رقابت بپردازد؟ خیر! من به دقت به ابزارهای POP که در اختیار داشتم نگاه کردم، و از خودم سوال کردم کدامیک به آنچه که من می‌خواهم نزدیک‌تر است؟”. به این دلیل که؛

۲) برنامه‌نویسان خوب، می‌دانند که چطور برنامه‌ بنویسند. اما برنامه‌نویسان خبره، می‌دانند که چطور برنامه‌ها را بازنویسی کنند (و دوباره به کار بگیرند).

با اینکه ادعا نمی‌کنم که یک برنامه‌نویس خبره هستم، تلاش کردم تا این کـار را تقلید کنم! یک ویژگی مهم از برنامه‌نویسان خبره، تنبلی ِ سازنده و مفید آن‌هاست. آن‌ها به خوبی می‌دانند که شما رتبه A را نه به خاطر تلاشتان، که به خاطر نتیجه کارتان دریافت می‌کنید. و همواره آسان‌تر آن است که از یک بخش خوب از راه‌حل شروع به کار کرد تا اینکه از هیچ.

برای مثال، لینوس توروالدز حقیقتاً تلاش نکرد تا سیستم‌عامل لینوکس را از ابتدا بنویسد. او با استفاده مجدد از کدها و ایده‌هایی که از MINIX، یک سیستم‌عامل کوچک شبیه یونیکس برای ماشین‌های 386، گرفته بود کار خود را شروع کرد. عاقبت، تمام کد‌های MINIX، حذف شد و یا به طور کامل از نو نوشته شد – ولی در زمانی که وجود داشت، ساختاری را برای کودکی که سرانجام لینوکس شد، تشکیل می‌داد.

با تفکری مشابه، من به دنبال یک ابزار POP گشتم که به خوبی نوشته شده باشد، تا از آن به عنوان پایه‌ای برای برنامه‌نویسی‌ام استفاده کنم.

سنت اشتراک کد در دنیای یونیکس همواره موافق استفاده مجدد از کد بوده است. (به همین دلیل است که پروژه GNU یونیکس را به عنوان پایه برای سیستم‌عامل‌اش برگزید؛ صرف نظر از شروط مهمی که در ارتباط با سیستم‌عامل وجود دارد) دنیای لینوکس این سنت را تا حد زیادی در کنار تکنولوژی‌اش نگه داشته است؛ تعداد زیادی از پروژه‌های بازمتن، هم اکنون در دسترس هستند. لذا، صرف کردن زمان برای یافتن برنامه‌های خوب در دنیای لینوکس، نتیجه بهتری را نسبت به هر جای دیگری برای شما به ارمغان خواهد داشت.

و چنین اتفاقی برای من نیز رخ داد. با مواردی که قبلا پیدا کرده بودم، جستجوی دوم من ۹ نتیجه را در بر داشت – popmail، pop-perl، pimp، gwpop، getmail، PopTart، fetchpop و upop. در ابتدا تمرکز خود را بر روی fetchpop از سونگ-هانگ (Sueng-Hong Oh) قرار دادم و طرح کلی برنامه‌ام را بر روی آن پیاده‌سازی کردم که حاصلش، پیشرفت‌های مختلفی در این نرم‌افزار بود که نویسنده برنامه‌ در نسخه 1.9 آن‌ها را ترتیب اثر داد.

چند هفته بعد، به طور اتفاقی به برنامه‌ popclient که کارل هریس (Carl Harris) آن را نوشته بود، برخورد کردم و دریافتم که اشتباهی مرتکب شدم. هرچند برنامه‌ fetchpop حاوی ایده‌های خوبی بود (برای مثال حالت daemon)، ولی تنها قادر به کار با POP3 بود و نسبتاً ناشیانه نیز نوشته شده بود (سونگ-هانگ فرد زیرکی بود، اما برنامه‌نویس با تجربه‌ای نبود، این دو ویژگی، به خوبی در برنامه‌اش قابل مشاهده بود). کد Carl بهتر بود و کاملاً حرفه‌ای و قدرتمند نوشته شده بود، اما برنامه‌اش فاقد برخی از ویژگی‌های مهم و زیرکانه fetchpop بود (که برخی از آن‌ها را من نوشته بودم).

با همان برنامه‌ کار می‌کردم یا برنامه‌ام را عوض می‌کردم؟ اگـــر برنامه‌ام را عوض می‌کردم، آن وقت تلاشهایی را که برای بهتر کردن برنامه‌ قبلی انجام داده بودم را بی ارزش کرده بودم.

انگیزه اصلی برای تعویض برنامه‌ام پشتیبانی از چندین پروتکل در برنامه‌ جدید بود. POP3 معمول‌ترین پروتکل در میان پروتکل‌های سرویس‌دهنده post-office بود، اما تنها گزینه موجود هم نبود. برنامه‌ fetchpop و انواع مشابه دیگر از POP2، RPOP و یا APOP پشتیبانی نمی‌کردند، و من همچنین افکاری نه چندان جدی در ارتباط با اضافه کردن احتمالی پروتکل IMAP به برنامه‌ نیز داشتم.

اما دلیل منطقی‌تری برای این نظریه که تعویض برنامه‌ می‌تواند گزینه بهتری باشد، داشتم. چیزی که مدت‌ها پیش از لینوکس یاد گرفتم.

۳) اگر بخواهی که چیزی را کنار بگذاری، در هر صورت سرانجام این کار را می‌کنی!

یا به بیانی دیگر، در اکثر موارد واقعا متوجه مشکلات نخواهی شد تا برای یک بار هم که شده به دنبال راه‌حلی بگردی. در این صورت دفعه بعد، احتمالاً اینقدر میدانی که چطور کارت را درست انجام دهی. پس اگر می‌خواهی درست عمل کنی، تلاش کن که این کار را حداقل یک بار تجربه کنی.

خوب (به خودم گفتم) تغییرات در برنامه‌ fetchpop اولین تلاش من بود. حالا برنامه‌ام را عوض می‌کنم.

بعد از اینکه اولین مجموعه از بسته‌های نرم‌افزاری popclient را برای کارل هریس در تاریخ 25 ژوئن 1996 فرستادم، فهمیدم که او دیگر اصلا به برنامه‌ popclient علاقه‌ای ندارد. کد برنامه‌ با مشکلات کوچکی که داشت، کمی قدیمی نیز شده بود. من تغییرات بسیاری را در برنامه‌ به وجود آوردم و سرانجام به این نتیجه رسیدیم که تصمیم منطقی این است که مسئولیت برنامه‌ را به دست بگیرم.

واقعیت این بود که بدون اینکه متوجه باشم، پروژه به سرعت در حال پیشرفت بود. زمان زیادی می‌شد که دیگر بسته‌های نرم‌افزاری کوچک را برای نرم‌افزار نمی‌نوشتم و به نگهداری و مدیریت کل برنامه‌ می‌پرداختم؛ و همان زمان بود که این ایده به ذهنم خطور کرد که از این به بعد احتمالاً می‌توانم به تغییرات اساسی بپردازم.

در فرهنگ نرم‌افزاری که اشتراک کد را تبلیغ می‌کند، این یک روش طبیعی برای نمو یک پروژه است. با این منطق کار می‌کردم:

۴) اگر گرایش درستی داشته باشی، به مسائل جالبی برخورد می‌کنی.

اما عقیده کارل هریس حتی ارزشمند‌تر بود. او به این نتیجه رسیده بود که:

۵) اگر علاقه‌ات را نسبت به کار بر روی برنامه‌ای از دست دادی، در این صورت آخرین وظیفه‌ات این است که آن را به فرد شایسته‌ای بدهی.

بدون اینکه هرگز خواسته باشیم در این باره حرفی بزنیم، من و کارل میدانستیم که هدفی مشترک در کسب بهترین راه‌حل برای نرم‌افزار داریم. تنها سوال باقیمانده برای هر دوی ما این بود که آیا من میتوانم از عهدی کار بر بیایم . زمانی که به این باور رسیدم، پاسخ او با بزرگواری همراه بود و نرم‌افزار را به من واگذار کرد. امیدوارم که در وظیفه خود به خوبی او عمل کرده باشم.


اهمیت وجود تعدادی کاربر

و بدین گونه من نرم‌افزار popclient را به دست گرفتم و در نتیجه، کاربران این نرم‌افزار را نیز به دست آوردم. وجود کاربران برای نرم‌افزار بسیار ارزشمند است، نه فقط به این خاطر که نشان‌دهنده این مطلب هستند که نیازی را برآورده می‌کنید، بلکه به این دلیل که آن‌ها بیانگر عمل درست شما هستند. اگر درست رفتار کنید، آن‌ها هم می‌توانند برنامه‌نویس شوند.

سنت قدرتمند دیگر یونیکس که لینوکس آن را به اوج رسانده است، این است که اکثر کاربران این سیستم‌ها، یک هکر نیز هستند. از آن‌جا که کد منبع برنامه‌ در دسترس است، این امکان برای آن‌ها وجود دارد که هکرهای ماهرتری شوند. این مسئله می‌تواند در کاهش زمان عیب‌یابی نرم‌افزار بسیار مؤثر باشد. تنها با ایجاد کمی انگیزه و دلگرمی، کاربران شما می‌توانند مشکلات موجود در نرم‌افزار را تشخیص داده، راه‌حل‌هایی را برای حل این مشکل پیشنهاد دهند و به بهبود برنامه‌نویسی خیلی سریع‌تر از حالتی که شما تنهایی به این کار می‌پرداختید، کمک کنند.

همکار پنداشتن کاربران، راحت‌ترین روش برای تسریع پیشرفت برنامه‌نویسی و کاراترین روش برای عیب‌یابی نرم‌افزار است.

قدرت کارایی این نکته، به سادگی مورد کم توجهی قرار می‌گیرد. در حقیقت، تقریباً تمامی ما که در دنیای بازمتن به فعالیت می‌پردازیم، این نکته را که کاربران تا چه حد می‌توانند در رساندن برنامه‌ به سطح بالاتری از برنامه‌نویسی نقش داشته باشند و با پیچیدگی سیستم مقابله کنند را دست کم می‌گیریم؛ تا زمانی که لینوس توروالدز این تفاوت را به ما نشان داد.

در حقیقت، من فکر می‌کنم بزرگ‌ترین و زیرکانه‌ترین ابتکار لینوس تنها ساخت هسته سیستم‌عامل لینوکس نبود، بلکه بیشتر خلق مدل برنامه‌نویسی لینوکسی بوده است. زمانی که این عقیده را در حضور او مطرح کردم، او خندید و سریعاً آن چیزی که همیشه می‌گفت را تکرار کرد:

من اصولا آدم تنبلی هستم که می‌خواهد از کارهایی که حقیقتاً دیگران انجام می‌دهند، استفاده‌ای ببرم”.

تنبل همچون روباه، یا همانطور که رابرت هینلین گاهی می‌گفت، آنقدر تنبل که ممکن است ببازی.

با نگاهی به گذشته، یک نمونه برای روش‌ها و موفقیت لینوکس را می‌توان در توسعه کتاب‌خانه GNU Emacs Lisp و آرشیو کد‌های Lisp مشاهده کرد. در قیاس با روش ساخت کلیسایی هسته Emacs C و بسیاری از ابزارهای دیگر بنیاد نرم‌افزار آزاد، تکامل کد‌های Lisp بسیار روان‌تر و کاربر محورانه‌تر بود. ایده‌ها و پیش الگوها اغلب سه یا چهار بار قبل از رسیدن به حالت پایدار نهایی بازنویسی می‌شد و همکاری‌های دورادوری که به وسیله‌ی اینترنت انجام می‌گرفت، معمول بود.

در واقع، تنها هک موفقیت‌آمیز من قبل از fetchmail، احتمالاً VC Mode Emacs بود؛ یک همکاری لینوکس مانند که به وسیله‌ی ارسال email با سه نفر دیگر انجام گرفت. تنها یکی از آن‌ها (ریچارد استالمن، پـدید آورنده Emacs و موسس بنیاد نرم‌افزار آزاد یا FSF) را تا به امروز ملاقات کرده‌ام. آن برنامه‌ مقدمه‌ای برای SCCS ، RCS و بعدها CVS از Emacs بود که ورژن عملیات کنترلی one-touch” را ارائه می‌داد. برنامه‌ مذکور از مدل کوچک و خامی به وجود آمد که فرد دیگری آن را نوشته بود. توسعه VC موفقیت‌آمیز بود؛ چرا که، برخلاف خود Emacs، این امکان برای کد Emacs Lisp وجود داشت که مراحل انتشار/تست/بهبودی را خیلی سریع طی کند.

یکی از اثرات جانبی پیش‌بینی نشده خط مشی FSF در تلاش برای قانونی همراه کردن کد برنامه‌ با GPL این است که بدین روش استفاده از مدل بازار برای FSF مشکل‌تر می‌شود؛ چرا که باید مجوزهای کپی‌رایت را برای هر همکاری در برنامه‌ که بیش از بیست خـط صورت گرفته، اجرا کنند تا برنامه‌ تحت لیسانس GPL از رویارویی با قوانین کپی‌رایت مصون بماند. کسانی که از قانون کپی‌رایت تحت لیسانس‌های کنسرسیوم MIT X و BSD استفاده می‌کنند، چنین مشکلی نخواهند داشت؛ چرا که آن‌ها تلاشی برای حفظ ارزش‌هایی که ممکن است افرادی را به مقابله تحریک کند، انجام نمی‌دهند.


زود منتشر کن، مرتب منتشر کن

زود منتشر کردن برنامه‌ و انتشار متناوب نسخه‌های بعدی آن، یک بخش مهم از مدل برنامه‌نویسی لینوکسی است. اکثر برنامه‌نویسان (از جمله خود من) معمولا فکر می‌کنند که این روش، یک ت نادرست برای پروژه‌های بزرگ است؛ تنها به این دلیل که ورژن‌های ابتدایی، نسخه‌های پر اشکالی هستند و شما نمی‌خواهید که صبر کاربرانتان به پایان برسد.

این طرز فکر، افراد را به سبک کلیسایی برنامه‌نویسی هدایت خواهد کرد. اگر هدف اصلی این باشد که کاربران کمترین خطای ممکن را مشاهده کنند، آن وقت چرا شما تنها نسخه‌های برنامه‌تان را هر شش ماه یک بار (یا حتی کمتر) انتشار می‌دهید و شدیداً برای رفع خطاها در زمان بین انتشار نسخه‌های برنامه‌تان کار می‌کنید؟ هسته Emacs C بدین روش ساخته شد. کتاب‌خانه Lisp، عملاً اینطور نبود – به این خاطر که آرشیو‌های فعالی از Lisp در خارج از کنترل FSF وجود داشت، که شما می‌توانستید نسخه‌های جدید و بهتری از برنامه‌ را که مستقل از چرخه انتشار Emacs بود، پیدا کنید.

مهم‌ترین‌شان، آرشیو Ohio State elisp بود که در بسیاری جهات از آرشیو‌های بزرگ امروز ِ لینوکسی پیشی گرفته بود. اما تنها تعداد کمی از ما واقعا درباره آنچه که انجام می‌دهیم، درست اندیشیده‌ایم؛ و یا درباره ماهیت واقعی چنان آرشیوی با درنظر گرفتن مشکلات مدل برنامه‌نویسی کلیسایی FSF، تعمق کرده‌ایم. حدوداًً سال ۱۹۹۲ بود که تلاشی جدی را در ارتباط با ادغام بسیاری از کد‌های Ohio در کتاب‌خانه رسمی Emacs Lisp، انجام دادم؛ که به مشکلات اساسی برخورد کردم و کاملاً شکست خوردم.

اما یک سال بعد، همانطور که لینوکس به طور گسترده ظاهر شد، به خوبی مشخص بود که چیزی متفاوت و البته بهتر در حال اتفاق افتادن است. ت توسعه نرم‌افزار باز لینوس کاملاً با ساختار کلیسایی در تضاد بود. آرشـیوهای sunsite و tsx-11 شــروع به رشد کردند، توزیع‌های زیادی به وجود آمدند؛ و همه این‌ها به وسیله‌ی انتشارهای متناوب و غیر معمول هسته سیستمی، به وجود آمد.

لینوس با کاربرانش تا بیشترین حد ممکن، همانند همکارانش برخورد می‌کرد:

برنامه‌ات را زود و به تناوب منتشر کن و به مشتریانت گوش بده

نوآوری لینوس در این زمینه زیاد نبود (مسائلی از این دست در دنیای یونیکس، به سنتی قدیمی تبدیل شده بود)؛ اما در ارتقاء این سنت تا حدی که بر پیچیدگی کاری که او در حال انجام آن بود، غلبه کند و با آن سازگار شود، بسیار ارزشمند بود. در روزهای نخستین (حدود سال ۱۹۹۱)، انتشار هسته‌ای جدید بیــش از یک بار در هر روز، برای او عجیب نبود. چرا که او همکاران برنامه‌نویس خود را بیش از هر فرد دیگری از طریق اینترنت به همکاری تشویق می‌کرد.

اما چطور این کار انجام شد؟ آیا می‌توانستم از آن الگو برداری کنم، و آیا این مسئله به نبوغ منحصر به فرد توروالدز بستگی داشت؟

فکر نمی‌کنم. مسلماً لینوس یک هکر خیلی ماهر است (چند نفر از ما می‌تواند یک پروژه به بزرگی و جامعیت هسته سیستم‌عامل را انجام دهد؟). اما لینوس جهش نابغه وار عظیمی از خود نشان نداد. لینوس یک نــابـغه خــلاق در طراحی، به نوعی که برای مثال ریچارد استالمن یا جیمز گوسلینگ (از NeWS و Java)، نیست (و یا حداقل، هنوز نشده است). بلکه، لینوس در نگاه من یک مهندس نابغه است؛ با حس ششمی برای اجتناب از خطا؛ و برنامه‌نویسی حرفه‌ای با مهارتی مثال زدنی برای یافتن بهترین و کوتاه‌ترین مسیرها. در واقع، ساختار کلی لینوکس بر اساس این ویژگی‌ها پایه‌ریزی شده و بازتاب ذات هوشیار لینوس و روش ساده‌سازی طراحی‌اش است.

خوب، اگر انتشارهای پی در پی و استفاده ابزاری از رسانه اینترنت تصادفی نبوده باشد، بلکه بخش‌هایی از زیرکی و نبوغ مهندسی لینوس در کوتاه کردن مسیر به سوی هدفش باشد، در این صورت او به دنبال چه بود و چه چیزی را از این سیستم طلب می‌کرد؟

با این فرض، پاسخ در خود سوال نهفته است. لینوس هکرها/کاربران خود را همواره ترغیب و از آن‌ها قدردانی می‌کرد ترغیب به وسیله‌ی نمایش دورنمایی از کاری که خودشان در آن سهیم‌اند و احساس رضایت‌مندی درونی حاصل، و قدردانی با نمایاندن (حتی روزانه) پیشرفتی که در کارشان حاصل می‌شود.

لینوس، دقیقا قصد بیشینه کردن تعداد افراد و ساعاتی را داشت که صرف برنامه‌نویسی و عیب‌یابی می‌شدند؛ حتی اگر این امر به قیمت بی‌ثباتی در برنامه‌ و خستگی ناشی از سختی حل مشکلی دشوار در برنامه‌، می‌شد. لینوس طوری رفتار می‌کرد که گویا به چنین درکی رسیده باشد:

با داشتن همکاران برنامه‌نویس و تست‌کننده‌های بتای زیاد، تقریباً هر مشکلی سریعاً پیدا شده و به وسیله‌ی فردی از افراد کاملاً برطرف می‌شوند.

یا خودمانی تر:

با وجود چندین نگاه جستجوگر، تمامی خطاها برطرف می‌شوند”.

چیزی که من آن را قانون لینوکس” نامیده‌ام.

شعار اصلی من هم در این زمینه این بود که هر مشکلی به وسیله‌ی فردی پیدا می‌شود”. لینوس تردید داشت کسی که مشکلات را درک کرده و آن‌ها را برطرف می‌کند، وماً و یا حتی معمولا همان کسی باشد که آن را پیدا کرده است. او می‌گفت: فردی مشکلات را پیدا می‌کند و فرد دیگری آن را حل می‌کند و من می‌گویم که پیدا کردن مشکل سخت‌تر است.” اما نکته در اینجاست که هر دوی این‌ها سریعاً اتفاق می‌افتد.

فکر می‌کنم هسته اصلی تفاوت بین سبک بازار و سبک کلیسایی در اینجا نهفته است. از دیدگاه برنامه‌نویسی کلیسایی، اشکالات برنامه‌ و مشکلات برنامه‌نویسی، موذی و دردسر ساز هستند. ماه‌ها بررسی تعداد کمی از افراد که وقت خود را به این کار اختصاص داده‌اند، لازم است تا اطمینان حاصل کنید که تمامی خطاها را برطرف کرده‌اید. نتیجه این روش، وقفه‌های زمانی طولانی بین انتشار نسخه‌های مختلف نرم‌افزار، و یأسی اجتناب‌ناپذیر در حالتی که که نسخه‌های دیر منتشر شده برنامه‌ شما کارایی مورد نظر را ندارند، خواهد بود.

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

و نکته در همین بود. همین و بس. اگر قانون لینوکس” اشتباه می‌بود، آن وقت هر سیستمی به پیچیدگی هسته لینوکس، که به وسیله‌ی افراد بسیاری توسعه یافته بود، می‌بایست زیر فشار عدم هماهنگی‌ها و اشکالات اساسی کشف نشده، با شکست مواجه می‌شد. از سوی دیگر، اگر این قانون دست باشد، تنها کافیست که به شرح دلایل کم خطا بودن لینوکس بپردازیم.

البته شاید دلیلی برای شگفتی هم وجود نداشته باشد، چرا که جامعه‌شناسان سال‌ها قبل کشف کرده‌اند که میانگین نظر گروهی از افراد متخصص (و یا نادان)، قابل اعتمادتر از تک تک آن‌هاست. آن‌ها چنین اصلی را اثر دلفی” نام‌گذاری کرده‌اند. پیداست که آنچه که لینوس نشان داده است این است که این مطلب حتی در عیب‌یابی نرم‌افزاری چون سیستم‌عامل نیز قابل تعمیم است – اینکه اثر دلفی می‌تواند در آسان کردن پیچیدگی برنامه‌نویسی، حتی در حد و اندازه پیچیدگی هسته یک سیستم‌عامل نیز، مؤثر باشد.

من مدیون جف داتکی هستم چرا که او قانون لینوکس را در قالب جمله عیب‌یابی می‌تواند موازی و همزمان انجام شود” به زیبایی بیان کرد. جف به این نتیجه رسیده بود که هرچند عیب‌یابی نرم‌افزار نیازمند برنامه‌نویسان عیب‌یابی است که با برنامه‌نویسان مربوطه م و رایزنی کنند، اما نیازمند هماهنگی بخصوصی بین عیب‌یاب‌ها نیست. بنابراین، به مضاعف شدن پیچیدگی و هزینه‌های مدیریتی که اضافه کردن برنامه‌نویسان را مشکل می‌کند، نخواهد انجامید.

عملاً، ضعف نظری عملکردی به علت دوباره کاری‌هایی که در عیب‌یابی نرم‌افزار ممکن است رخ دهد، تقریباً هیچ‌گاه در دنیای لینوکس، در کارایی تأثیر منفی نخواهد داشت. یکی از نتایج ت زود و به تناوب منتشر کردن برنامه‌”، کمینه کردن چنین دوباره کاری‌هایی است که به وسیله‌ی انتشار مشکلات حل شده به سرعت قابل حل است.

بروکس، حتی چنین عقیده تخمینی را با توجه به نظر جف داشت: هزینه کلی نگهداری برنامه‌ای که به طور گسترده مورد استفاده قرار می‌گیرد، حدود چهل درصد و یا بیشتر از هزینه ایجاد آن است. جالب اینجاست که این هزینه شدیداً تحت تأثیر تعداد کاربران آن نرم‌افزار قـرار دارد. کاربران بیشتر، اشکالات بیشتری را نیز پیدا می‌کنند.” (چیزی که همواره بر آن تاکید دارم).

کاربران بیشتر، اشکالات بیشتری را نیز پیدا می‌کنند، چرا که افزایش یافتن تعداد کاربران، به افزایش روش‌های مختلفی برای آزمایش نرم‌افزار خواهد انجامید. این نکته زمانی تقویت می‌شود که کاربران نرم‌افزار، برنامه‌نویسان کمکی برنامه‌ مذکور نیز باشند. هر کدام ره‌یافتی جدید برای شناسایی مشکلات را با بینشی متفاوت و تحیلی گوناگون ارائه می‌دهند، که نمایانگر زاویه‌ای جدید از مشکل خواهد بود. این تفاوت‌ها کاملاً بیانگر کارایی اثر دلفی” هستند. در حالت خاصی از عیب‌یابی، این تنوع و گوناگونی به کاهش دوباره کاری‌ها نیز خواهد انجامید.

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

لینوس زرنگی هم کرد. هر وقت که مشکلات جدی در برنامه‌ وجود داشت، ورژن هسته لینوکس به نحوی شماره گذاری شده بود تا این امکان برای کاربران وجود داشته باشد که بتوانند آخرین نسخه پایدار” برنامه‌ را انــتخاب کنند و یا اینکه ریسک کنند و با ترجیح ویژگی‌ها و امکانات نسخه جدید بر مشکلاتش، از نسخه جدید برنامه‌ استفاده کنند. این تاکتیک، هنوز به طور رسمی توسط بسیاری از هکر‌های لینوکسی استفاده نشده است، اما به نظرم باید این کار صورت گیرد؛ این حقیقت که حق انتخابی در این بین وجود دارد، هر دو را جذاب‌تر خواهد کرد.

زمانی که برنامه‌ دیگر آن برنامه‌ قبلی نبود

با درک نحوه عملکرد لینوس و خلق یک فرضیه درباره دلایل موفقیت آن، تصمیمی هوشیارانه برای تست این تئوری در پروژه جدیدم گرفتم (که در قیاس با لینوکس، مسلماً بسیار ساده‌تر و کوچک‌تر بود).

اما اولین کاری که انجام دادم، سازماندهی دوباره و ساده‌سازی نرم‌افزار popclient بود. پیاده‌سازی کارل هریس (Carl Harris) خیلی دقیق بود، اما نوعی پیچیدگی اضافی در قیاس با خیلی از برنامه‌نویسان C در برنامه‌اش به چشم می‌خورد. او با کد برنامه‌ به عنوان بخش اصلی و ساختمان داده‌ها به عنوان پشتیبان کد برخورد می‌کرد. در نتیجه، برنامه‌ بسیار زیبا سازماندهی شده بود، اما نوع طرح‌ریزی ساختمان داده برنامه‌، روشی معمول نبود و تقریباً زشت سازماندهی شده بود (حداقل در قیاس با استاندار‌های سطح بالای این هکر قدیمی LISP).

جدای این مسائل، دلیل دیگری برای بازنویسی برنامه‌ در کنار بهبود طرح برنامه‌ و ساختار ساختمان داده آن داشتم. در واقع، می‌خواستم برنامه‌ را کاملاً درک کنم. زیاد جالب نیست که مسئول درست‌کردن برنامه‌ای باشی که آن را درک نکرده‌ای!

حدوداً در ماه اول، به پیروی از ساختار پایه‌ای طرح کارل پرداختم. اولین تغییر اساسی که در برنامه‌ انجام دادم، اضافه کردن پشتیبانی از پروتکل IMAP به برنامه‌ بود. این کار را به وسیله‌ی سازماندهی مجدد پروتکل‌ها در یک درایور عمومی و سه جدول متد (برای POP2، POP3 و IMAP) انجام دادم. این تغییر و تغییرات قبلی نمایانگر یک اصل کلی هستند که خوب است برنامه‌نویسان آن را به خاطر بسپارند، به خصوص در زبان‌های برنامه‌نویسی از قبیل C که به طور پیش فرض با انواع پویا کار نمی‌کنند:

ساختمان داده‌ی خوب و برنامه‌ ضعیف بسیار بهتر از برنامه‌ خوب و ساختمان داده بی ارزش کار می‌کند.

فصل نهم از کتاب بروکس:

اگر می‌خواهی مرا گیج کنی، برنامه‌ات را به من نشان بده ولی ساختمان داده برنامه‌ات را پنهان کن. اما اگر ساختمان داده برنامه‌ات را به من نشان دهی، اغلب دیگر نیازی به دیدن کد برنامه‌ات ندارم؛ همه چیز واضح و مشخص است.”

البته منظور او فلوچارت‌ها” و جداول” بود. البته با درنظر گرفتن حرکت سی ساله علمی و فنی/فرهنـگی، این دو تقریباً یکی هستند.

در این زمان (اوائل سپتامبر سال 1996، حدوداً شش هفتــه پس از شروع کار)، به این فکر افتادم که بهتر است که نام نرم‌افزار را تغییر دهم. پس از همه این تغییرات، برنامه‌ مذکور تنها یک POP client ساده نبود. اما دچار تردید شدم، چرا که تا آن زمان هیچ کار کاملاً جدیدی در ساختار برنامه‌ انجام نداده بودم. نسخه popclient من، هنوز هویت قبلی خود را داشت.

این تغییر بنیادی زمانی به وجود آمد که برنامه‌ fetchmail قادر به ارسال کردن نامه‌های دریافت شده به پورت SMTP شد. درباره‌اش خواهم گفت؛ اما قبل از آن: قبلاً گفتم که تصمیم داشتم که این پروژه را برای تست تئوری‌ام درباره آنچه که لینوس توروالدز انجام داده بود، به کار بگیرم. ممکن است بپرسید چطور این کار را کردم؟ به روش‌های زیر:

  • برنامه‌ام را زود و به تناوب منتشر می‌کردم (تکرارش تقریباً کمتر از هر ده روز یک بار نمی‌شد، اما در طی دوران اوج برنامه‌نویسی، هر روز این کار انجام می‌شد)
  • هر کس را که با من به نحوی درباره fetchmail درتماس بود را به لیست بتای خودم اضافه می‌کردم. هر زمانی که نسخه جدیدی را انتشار می‌دادم، آگهی‌های زیادی را به لیست بتای خودم ارسال می‌کردم تا آن‌ها را به مشارکت در پروژه تشویق کنم.
  • به تست‌کننده‌های نسخه بتای نرم‌افزارم گوش می‌کردم، نظر آن‌ها را درباره تصمیماتم جویا می‌شدم و هر زمان که آن‌ها بسته‌های نرم‌افزاری و یا نظراتشان را برایم ارسال می‌کردند، از آن‌ها تشکر می‌کردم.

نتیجه نهایی این کمک‌های کوچک، بسیار سریع اثر خود را نشان داد. از آغاز پروژه، با گزارش‌های با ارزشی در ارتباط با خطاهای برنامه‌ مواجه شدم که برنامه‌نویسان حاضرند به خاطرش جان بدهند! که اغلب با راه‌حل‌های خوبی نیز همراه بود. من متفکرانه مورد نقد قرار گرفتم، نامه‌های بسیاری به دستم رسید و نظرات هوشمندانه‌ای نیز دریافت کردم. که همگی مرا به این نکته هدایت کرد:

اگر شما با تست‌کننده‌های نسخه بتای برنامه‌تان، چنان که آن‌ها با ارزش‌ترین منبع شما هستند، برخورد کنید، آن‌ها به عنوان با ارزش‌ترین منبع شما به شما پاسخ خواهند داد.

یک نکته ارزشمند از موفقیت fetchmail، تعداد اعضای لیست نسخه بتای پروژه، یعنی دوستان fetchmail-friends است. در زمان نوشتن این مقاله، لیست مذکور ۲۴۹ عضو داشت که هر دو یا سه هفته یکبار به تعداد اعضای آن اضافه می‌شود.

عملاً، با اصلاح نرم‌افزار در اواخر ماه مه سال 1997، لیست مذکور از آن تعداد زیاد اعضایش که به سیصد نفر می‌رسید، به دلیل جالبی تعدادی از اعضایش را از دست داد. خیلی از افراد از من می‌خواستند تا آن‌ها را از لیست خارج کنم، چرا که برنامه‌ fetchmail به حدی خوب عمل می‌کرد، که دیگر نیازی به بودن در لیست احساس نمی‌کردند! شاید این یک بخش از چرخه حیات پروژه کاملی باشد که در سبک بازار نوشته شده است.

نرم‌افزار popclient به fetchmail تبدیل می‌شود

تحول اصلی در پروژه زمانی صورت گرفت که هری هاچیسر (Harry Hochheiser) کد برنامه‌اش را در ارتباط با ارسال نامه به پورت SMTP ماشین سرویس‌گیرنده برایم فرستاد. من سریعاً به این نتیجه رسیدم که یک پیاده‌سازی درست از این ساختار تمامی روش‌های دیگر را به کنار خواهد زد.

هفته‌های زیادی را به سرو کله زدن با fetchmail پرداختم، تا طرح واسط برنامه‌ که قابل استفاده اما بی قواره بود، را بهبود بخشم – برنامه‌ ظاهری ناهنجار داشت، با گزینه‌های زیادی که به طور نامنظم در سراسر آن پراکنده بودند. مخصوصاً گزینه‌هایی که برای کپی‌برداری نامه دریافت شده به یک فـایل در صندوق‌پستی و یا یک دستگاه خروجی استاندارد تعبیه شده بودند، خاطرم را می آزردند، اما دلیلش را نمی‌توانستم درک کنم.

آنچه که در حین فکر درباره قابلیت ارسال SMTP به ذهنم خطور کرد، این بود که نرم‌افزار popclient سعی داشت تا کارهای زیادی را با هم انجام دهــد. این برنامه‌ به نـحوی طراحی شده بود تا هم یک عامل انتقال پست الکترونیکی (MTA) و هم یک عامل تحویل موضعی (MDA) باشد. با قابلیت ارسال SMTP ، می‌توانست از حــوزه کــــاری MDA خارج شده و یک MTA محض باشد که به سادگی sendmail، نامه را به برنامه‌های دیگر برای تحویل موضعی تحویل می‌دهد.

چرا تمامی پیچیدگی‌های پیکــربندی یک MDA یا عملیات قفل و الحاق (Lock and Append) بر روی یک صندوق‌پستی در هم آمیخته شوند، در حالیکه پورت ۲۵ تقریباً در تمامی پـلتفرم‌هایی که از TCP/IP پشتیبانی می‌کنند، به این کار اختصاص داده شده است؟ بخصوص زمانی که این مسئله به معنی شباهت ساختاری نامه دریافتی با نامه معمولی یک فرستنده SMTP باشد؛ که درواقع همان چیزی است که ما می‌خواهیم.

درس‌های زیادی در این نکته وجود دارد. در ابتدا، ایده ارسال SMTP بزرگ‌ترین نتیجه‌ای بود که من از تلاش هوشیارانه‌ام برای شبیه‌سازی روش لینوس گرفتم. یکی از کاربران، این ایده فوق العاده را به من داد – تنها کاری که بایــد انجام می‌دادم این بود که مفاهیم را درک کنم.

روش کارای بعدی برای داشتن ایده‌های خوب، کسب ایده‌های خوب از کاربرانتان است. بعضی وقتها این روش دوم بهتر است.

با کمی دقت، بسرعت خواهید فهمید که اگر کاملاً با خودتان درباره آنچه که به دیگران بدهکارید صادق باشید، دنـیا با تمام بزرگی‌اش همانطور با شما رفتار کرده است که شما با هر تکه از نوآوریتان که خلقش کرده‌اید؛ و این تنها شایسته بخشی از نبوغ درونی شماست. همه ما دیدیم که این مطلب چقدر برای لینوس مؤثر افتاد.

(وقتی که این مقاله را در کنفرانس Perl در ماه اوت سال ۱۹۹۷ ارائه دادم، لری وال در ردیف اول نشسته بود. وقتی که به آخرین خط پاراگراف فوق رسیدم، او همچون مبلغ‌های مذهبی فریاد زد : بگو، بگو براد!”. تمامی حضار خندیدند، چرا که می‌دانستند که چنین چیزی برای سازنده perl نیز اتفاق افتاده بود.)

بعد از گذشت تنها چند هفته از اجرای پروژه در آن حال و هوا، تعریف و تمجیدهای مشابهی را نه از کاربرانم، بلکه از سایر افرادی که سخنانم به گوش آن‌ها رسیده بود، دریافت کردم. من هنوز تعدادی از آن نامه‌ها را دارم. هر وقت حس می‌کنم که زندگیم بی ارزش بوده، یک نگاهی به آن‌ها می اندازم 

اما دو درس پایه‌ای دیگر وجود دارد که برای هر نوع طراحی نرم‌افزار، مناسب است.

در اغلب اوقات، اکثر راه حل‌های ابداعی و برجسته از درک این نکته ناشی می‌شود که تحلیل شما از مسئله اشتباه بوده است.

زمانی من تلاش می‌کردم تا با ادامه توسعه نرم‌افزار popclient به عنوان یک MTA/MDA ترکیب شده، برنامه‌ام تمامی انواع تحویل محلی را انجام دهد؛ در واقع می‌خواستم مسئله اشتباهی را حل کنم. ساختار برنامه‌ fetchmail می‌بایست مجدداً مورد بررسی و تحلیل قرار می‌گرفت تا به یک MTA محض تبدیل شود.

زمانی که به یک بن بست در برنامه‌نویسی می‌رسید، زمانی که فکر کردن به مرحله بعدی برایتان سخت می‌شود، آن وقت به دنبال جواب درست نباشید، بلکه به فکر یافتن سوال درست باشید. احتمالاً صورت مسئله نیازمند این است که از نو بیان شود.

با این وجود، مشکلم را از نو مورد بررسی قرار دادم. به وضـوح مشخص بود که کار درست این است که:

  • قابلیت ارسال SMTP را در قالب یک درایور عمومی بگنجانم.

  • آن را حالت پیش‌فرض قرار دهم.
  • سرانجام تمامی حالات دیگر تحویل را نادیده بگیرم، به خصوص گزینه‌های ارسال به فایل و ارسال به خروجی استاندارد.

همونطور که از عنوان معلومه اومدم چند تایی میانبر یا همون شرتکات های لینوکس رو براتون گذاشتم.



TAB

یکی از مهم ترین و پرکاربرد ترین میانبر های ترمینال لینوکس به حساب میاد. کاربرد این میانبر که همان کلید ‍‍‍‍ tab » برای کامل کردن نام دایرکتوری های فایل ها و. است که برای کارهای روزمره ی کاربران میتوان با استفاده از این میانبر در صرفه جویی وقت و سرعت را بطور چشم گیری افزایش داد.



Ctrl + c

برنامه یا دستوری که در محیط کامندی لینوکس در حال اجراست رو متوقف میکند.



Ctrl + z

این میانبر برای مخفی کردن(background) دستوری که در ترمینال اجرا میشه کاربرد داره برای مثال برنامه ای درحال اجراست و نمیخوایید اون رو متوقف کنید و دم دست هم نمونه کافیه از این میانبر استفاده کنید.



Ctrl + d

برای خارج شدن از ترمینال که کاربرد این میانبر مانند همان دستور exit » است.





Ctrl + Alt + F1, (F1-F6)

یک دستور خیلی جالب و زیبا این محیط گرافیکی رو خنثی میکنه و شما رو در حالت CLI یا همون محیط کامندی قرار میده و برای برگشت Ctrl + Alt + F7 از این کلید ها استفاده کنید.



Ctrl + L

برای پاک کردن ترمینال که مثل دستور clear» کار میکنه .



Ctrl + a

این میانبر در ترمینال برای برگشتن به اون خط استفاده میشه.


Ctrl + e

مثل میانبر قبلی ولی این یکی به آخر خط بر میگرده




خب همینطور که میدونید لینوکس یک سیستم عامل فوق علاده قوی و کاربردی است که دنیا وب بدون لینوکس وجود ندارد چون ۸۰ ال ۹۰ درصد وب سرور های جهان از لینوکس استفاده میکنند.

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


خب با ما همراه باشید.

SoaS:




Edubuntu :


Doudou Linux:



خب اینم از این مطلب اگه به پیشنهاد خودم باشه گزینه ی دوم برای بجه ها ۸ ساله تا ۱۲ ساله خیلی مناسبه، برادر خودم که الان دارم لینوکس یاد میدم از نسخه ی آموزشی اوبونتو که همون گزینه ی دومه استفاده می کنم.


سوالی بود بازهم در خدمتم اگه سوالی بود.

آخرین ارسال ها

آخرین وبلاگ ها

آخرین جستجو ها