مدتی پیش بود که در همین وبلاگ، در مورد خودروهای خودران نوشتم (لینک) و بعدتر حتی در مطلب ایدههایی برای پروژههای بینایی ماشین، در موردش صحبت کردم. چند وقت پیش، ویدئوهای زیادی از افرادی دیدم که در سالهای گذشته، خودروی خودران خودشون رو ساختند. چیزی که نظرم رو جلب کرد، این بود که این پروژهها عمدتا تبدیل خودروهای اسباببازی به خودروی خودران بود. نتیجتا تصمیم گرفتم تا روی موضوع کمی بیشتر فکر کنم و شروع کنم به طراحی پروژه خودروی خودران خودم.
بعد از چند هفته تحقیق و تفحص، اول تصمیمم بر این بود که یک ماشین کنترلی تهیه کنم و شروع کنم روی اون کار کردن. ولی موضوعات مهمی اینجا مطرح میشدند. اولین و مهمترین موضوع – که پیشتر هم بهش برخورده بودم – این بود که ماشینهای کنترلی، عموما شاسی بزرگ و قوی ندارند و چیزی که من نیاز داشتم، یک شاسی بزرگ برای جا دادن وسایلی بود که نیاز داشتم. به همین خاطر مدتی باز تحقیق کردم که چه چیزی میتونم تهیه کنم که این مشکل رو نداشته باشه؟ بعد از اون در مورد درایور موتور نیاز بود تحقیق کنم. بعد از این موضوعات، این که چطور مدل هوش مصنوعی رو روش مستقر کنم و … . در ادامه این مطلب، قراره با هم بخش رباتیک (مکانیکی و الکترونیکی به طور خاص) رو بررسی کنیم و بعد بریم سروقت بخش نرمافزاری ماجرا 🙂
شاسی مورد نیاز
پس از این که تصمیم گرفتم حتما یک پروژه خودروی خودران داشته باشم، یکی از مواردی که بهش خیلی فکر میکردم، این بود که حتما یه شاسی مناسب تهیه کنم. اول، همونطوری که ابتدای مطلب گفتم، به ماشینهای کنترلی اسباببازی فکر میکردم. ماشین کنترلی، یک سری ویژگی خوب داره. مثل چی؟ مثل این که موتورها روش سوار شدند، احتمالا درایور مناسب موتور داره، جا باتری داره و … . اما خب این هم باید در نظر گرفت که برد کنترل ماشین پیشاپیش متناسب با همون شاسی خودش ساخته شده و نمیشه خیلی هم دستکاریش کرد.
مورد بعدی که بهش فکر میکردم، این بود که شاسی رو از بیخ و بن بسازم. حقیقت اینه که ساخت شاسی، بیش از اندازه پروسه مکانیکی و وقتگیریه. بخصوص این که تجربه زیادی در اون زمینه خاص ندارم و نیاز بود که حجم زیادی آزمون و خطا صورت بگیره. مهمترین ویژگی خودروی خودران برای من، این بود که قابلیت کنترل از راه دور داشته باشه و همچنین بتونیم روی اون، یک مدل هوش مصنوعی سوار کنیم. به همین خاطر، تصمیم گرفتم که یک شاسی آماده ربات بخرم. شاسیای که خریداری کردم، یک شاسی برای رباتهای دانشآموزی بود که از پاساژ عباسیان (واقع در خیابان جمهوری تهران) خریداری شد.
بعد از خرید شاسی، نیازمند این بودم که موتور رو به شکلی راه بندازم. راهی که خود آقای فروشنده پیشنهاد میکرد این بود که از یک ترانزیستور به همراه باتریهای معمولی استفاده بشه، اما ترجیح من این بود که از یک درایور خوب استفاده کنم که در بخش بعدی، در موردش توضیح خواهم داد.
درایور موتور
وقتی از موتورهای DC و بخصوص موتورهای Brushed استفاده میکنیم، نیازمند درایور هستیم (اگر براتون سواله که چرا، میتونید این ویدئو رو ببینید). به همین جهت، چیزی که نیاز داشتم یک درایور مناسب برای چنین موتوری بود. تصمیم من این شد که از L298N استفاده کنم. این درایور رو یادمه که در درس ریزپردازنده بهمون درس داده بودند و گزینه آشنایی برام بود. علاوه بر این، چندتایی از این درایور در وسایل الکترونیکیم داشتم. پس همه چیز تحت کنترل بود و کل مجموعه رو شروع کردم سوار کردن. اما مساله مهم دیگر چی بود؟ درسته؛ کنترل از راه دور 🙂
کنترل از راه دور
برای کنترل از راه دور، امکان این بود که از رادیو یا مادون قرمز استفاده بشه. همونطوری که در ماشینهای کنترلی اسباب بازی این اتفاق میافتاد. اما میخواستم که پروژه کمی بهتر و باحالتر بشه، به همین خاطر تصمیم گرفتم که این کنترل رو از طریق وایفای انجام بدم. به همین خاطر هم یک ماژول NodeMCU ESP8266 رو از گنجه بیرون کشیدم و شروع کردم به سیمکشی. اما نکته این بود که از گذشته در یادم مونده بود که این ماژول خاص، ولتاژ خروجی بالایی نداشت و نیازمند کمی تغییر بود. برای این که این مشکلات دوباره پیش نیان، کمی در مستندات خود ماژول چرخ زدم و آموزشهای مربوط به راهاندازی موتور رو خوندم.
بعد از این که موتور با موفقیت راهاندازی شد، چندین تابع نوشتم که عملیات جلو، عقب، چپ، راست رو داشته باشه. یک تابع دیگر هم نوشتم که همزمان موتورها رو خاموش کنه. بعد از اون، یک وبسرور کوچک روی ESP راه انداختم که اون توابع رو اجرا کنه و موتورها رو بچرخونه. بعد از این که این موارد رو تست کردم یک سری باگ ریز داشتم که رفعشون کردم. در نهایت، تصمیم گرفتم که منبع قدرت موتورها و ماژول رو جدا کنم و به همین خاطر یک پاوربانک کوچک هم به این ترکیب اضافه شد.
بعد از کنترل از راه دور، چیزی که باقی میمونه، اینه که چطور میتونیم ورودی تصویری رو تهیه کنیم. به هرحال همونطوری که قبلتر توضیح داده بودم، خودروی خودران نیازمند اینه که ورودی رو از محیط بگیره. ماژول ESP به این راحتیا به دوربین متصل نمیشه، بشه هم ران کردن یک مدل و سیستم هوش مصنوعی روش به شدت کند و سخت خواهد بود. به همین خاطر، تصمیم گرفتم که هوش مصنوعی رو جای دیگه سوار کنم و دوربین صرفا داده رو به اون سیستم ارسال کنه.
دوربین
همونطور که در بخش قبلی گفتم، به ESP8266 به این راحتیا نمیشه دوربین متصل کرد. نتیجه این شد که تصمیم گرفتم از یک گوشی اندرویدی استفاده کنم. اول کمی در فروشگاههای اینترنتی و … جست و جو کردم و دنبال گوشیهای اندرویدی ارزون قیمت گشتم. اما یادم افتاد که گوشی قبلی خودم یعنی Samsung Galaxy J7 ای که دارم، دوربین خوبی داره. گذشته از اون، میشه با استفاده از Droid Cam و نرمافزارهای مشابه، تصویر رو به کد پایتونی فرستاد و اونجا پردازشهای لازم رو روش انجام داد.
برای سوار کردن گوشی موبایل هم یک پایه دوربین قدیمی رو برداشتم، پایههاش رو جدا کردم و سپس پایه و گوشی رو همراه هم روی شاسی چسبوندم. در حال حاضر، بخش سختافزاری خودروی خودران، کاملا آمادهست!
در آینده چه خواهیم خواند؟
بخش بزرگی از پروژه خودروی خودران من، مربوط به سختافزارش بود چرا که داشتم این قسمت رو هم خودم طراحی و پیادهسازی میکردم. نتیجه این شد که این مورد خیلی طول کشید (چندین هفته مطالعه، چند ماه تهیه ابزارها و یکی دو هفته هم سوار کردن قطعات روی هم) و خب فازهای نرمافزاری – که به نظر خودم جذابترین قسمتهای این کار هستند – هنوز باقی ماندند. نخستین فاز اینه که کد پایتونی نوشته بشه که بتونه تصویر رو از Droid Cam بخونه و به ما نمایش بده.
علاوه بر اون، نیازمند فرایندی برای تصویربرداری از محیط هستیم. پس از انجام این دو مورد، نیاز داریم که یک سیستم هوش مصنوعی آموزش بدیم که درست و حسابی مسیر رو تشخیص بده. بعدش کافیه سیستم هوش مصنوعیمون رو طوری تغییر بدیم که به صورت کاملا خودکار به ESP وصل شه و درخواستهاش رو به اون بفرسته و خودروی ما رو به حرکت دربیاره!
از این که وقت گذاشتید و این مطلب رو خوندید، ازتون متشکرم. برای کسب اطلاعات بیشتر و جزییات جذابتر، لطفا منتظر قسمت دوم این مطلب باشید.
در دنیای امروز، یکی از بحثهای مهم برای هر استارتاپ و سازمانی، اینه که چطور و با چه ابزاری، محصول خودشون رو بسازند. این موضوع میتونه از لحظه تصمیمگیری برای راهاندازی استارتاپ در ذهن بنیانگذاران باشه، حین پیادهسازی محصول کمینه ارزشمند (MVP) ذهنشون رو بیشتر درگیر کنه و حتی پس از ارائه محصول نهایی هم همیشه فکر بازسازی و بازنویسی محصول یکی از مشغلههای ذهنیشون باقی بمونه. چند وقت اخیر، یکی از فازهایی که میان خیلی از برنامهنویسان – بخصوص نسل جدید و تازهنفس برنامهنویس – رایج شده، استفاده از گولنگ در ساخت MVP و … است.
در این پست، قصد من اینه که توضیح بدم چرا گولنگ انتخاب مناسبی نیست و چرا بهتره که در یک سازمان کوچک، سمتش نریم و از ابزارهای دمدستیتری مثل پایتون یا PHP استفاده کنیم. ضمنا اینجا یک سلب ادعا بکنم که «دمستی» به معنای «بد» بودن اون ابزار نیست و اتفاقا در این متن بخصوص، یک مزیت برای اون ابزار ایجاد کرده.
چطور برای پروژه خود یک زبان یا فرمورک مناسب انتخاب کنیم؟
مطلب اصلی، در واقع اینجا شروع میشه. در این قسمت یک سری ویژگی رو کنار هم میچینیم و گولنگ رو در کنار ابزارهای قدیمیتر مثل PHP یا پایتون قرار میدیم که ببینیم کدوم یکی برنده از میدان بیرون میاد و اگر قراره که یک استارتاپ راه بندازیم، محصولمون رو با کدوم یکی از این ابزارها بنویسیم. توجه هم داشته باشید که این بخش متاثر از نظرات شخصی من هم هست و طبیعتا ازتون میخوام که در نقدهایی که به این مطلب وارد میکنید، این مورد هم در نظر بگیرید.
جمعیت توسعهدهندگان
مهمترین فاکتور در انتخاب زبان و فرمورک برنامهنویسی، دقیقا جمعیت توسعهدهندگان اونه. میپرسید چرا؟ چون اگر امروز خودتون کد رو بزنید، طبیعتا وقتی بیشتر با جنبه بیزنسی کارتون مواجه شید، وقت کمتری برای کد زدن خواهید داشت و نیازمند بزرگتر کردن تیم توسعه استارتاپتون هستید. پس از این جهت نیاز دارید که این مورد رو حتما در نظر بگیرید. دقت کنید که Go از سال ۲۰۰۹ عرضه عمومی شده و چندین ساله که داره بعنوان یک ابزار توسعه وب دیده میشه (که تعداد این سالها به انگشتای دست هم نمیرسه).
حالا از طرف دیگر، شما نگاه کنید که چقدر میتونید لاراولکار پیدا کنید؟ افرادی که لاراول یا جنگو (یا حتی روبی آن ریلز!!!) کار میکنند تعدادشون به شدت بیشتر از کسانیه که با Go کار میکنند. نتیجه منطقی اینه که سمت ابزاری برید که بزرگ کردن تیم توسعهش براتون کمهزینه باشه.
تعداد کتابخانهها و ابزارهای توسعه
مورد مهمی که باید بهش توجه کنید، اینه که زبان مورد استفادهتون چقدر ابزار داره؟ چندتا ORM استخواندار داره؟ چقدر طول میکشه تا ایده اولیتون رو صرفا با «به هم چسبوندن ابزارهای موجود» بسازید؟ متاسفانه در این مورد هم باید بگم که Go بازندست. البته این رو هم باید در نظر داشت که Go زیادی جوانه و خب طبیعتا از بین این همه شرکت بزرگی که برای توسعه به سمتش رفتند، بالاخره از این جهت هم به بلوغ کافی میرسه. اما بحث ما، بحث حال حاضره. در حال حاضر، پایتون از این جهت – به نظر من – بهترین گزینه میتونه باشه. میدونید چرا؟ چون برای هر چیزی که فکرش رو بکنید یک کتابخونه ارائه کرده و واقعا شما نیاز به پیاده سازی منطقی جز منطق خالص کسب و کار خودتون ندارید.
مقیاسپذیری
خب، جایی که Go واقعا حرفی برای گفتن داره و برندهست، در مقیاسپذیریه. سرعت بالای Go باعث میشه با حداقل سختافزار روی مقدار زیادی درخواست و کاربر همزمان پاسخ خوبی بده. در صورتی که مقیاس کردن پایتون یا PHP انقدر راحت نیست. اگر مقیاسپذیری براتون امری به شدت حیاتیه و حس میکنید که میتونید تو مدت زمان کوتاهی ممکنه نیاز به مقیاس بالایی داشته باشید، سمت Go برید.
سهولت استقرار
قبلتر در همین وبلاگ در مورد مهندسین DevOps توضیح داده بودم (لینک) و خب یه حقیقت تلخ در مورد این عزیزان اینه که نیروهای گرانقیمتی هستند. وقتی شما از ابزاری مثل Go یا حتی پایتون برای توسعه محصولتون استفاده کنید، احتمالا بعد مدتی نیاز دارید که برای استقرار و … محصول، از یک مهندس DevOps کمک بگیرید. این نیاز ممکنه از لحظه استقرار MVP با شما باشه تا وقتی که محصولتون رو بازسازی و ریفکتور میکنید. در صورتی که برای مثال یک پروژه Laravel ای رو میتونید به سادگی روی یک هاست سیپنل، میزبانی کنید.
و تیر آخر: زمان توسعه محصول!
در قسمت اول به این موضوع اشاره کردم ولی لازمه که دوباره هم اشاره بشه. چرا که این بخش به بخش کدنویسی و تست (و کلا کارهای برنامهنویسانه) محدود نیست و لازمه که موارد دیگر مثل استراتژی ورود به بازار، ارائه بتاهای عمومی و … هم در نظر بگیرید. متاسفانه Go در این مورد بازندست چرا که ابزارهایی به کاملی و خوبی جنگو، ریلز یا لاراول نداره. تنها راهحلی که بتونید با Go با سرعت زیادی به این مرحله برسید؛ اینه که چند توسعهدهنده حرفهای استخدام کنید که خب هزینههاتون رو شدیدا افزایش میده.
جمعبندی
حالا که این همه مثنوی هفتاد من سرودم، جای داره که یک جمعبندی کلی ارائه بدم از مباحث بالا. اگر موارد بالا رو در نظر گرفتید و دیدید که زبانی مثل Go یا Rust در فاکتورهای بالا برای شما کارآمد و مناسب هستند و انتخاب شخصیتونن و در عین حال، منابع کافی هم براشون دارید؛ خب دیگه پرسش نداره و بهتره هرچه سریعتر کارتون رو شروع کنید. در غیر این صورت، اگر از سر جوزدگی قراره از این ابزارها استفاده کنید، چند بار با خودتون مرور کنید که کدوم یکی از اینها، نیازهای شما رو مرتفع میکنند.
در پایان جا داره بگم که زبان برنامهنویسی صرفا ابزاریه که ما بتونیم باهاش برنامه بسازیم و برنامههای کامپیوتری، پاسخهایی هستند به نیازهای ما. انتخاب ابزار مناسب، امکانسنجی خودش رو نیاز داره و امیدوارم که در این پست؛ تونسته باشم به شما کمی در این امکانسنجی، کمک کرده باشم.
با تشکر از وقتی که گذاشتید و این مطلب رو خوندید. امیدوارم این مطلب براتون مفید واقع شده باشه.
چندی پیش، در مورد پیشنیازهای یادگیری بینایی ماشین در همین وبلاگ نوشته بودم (لینک) و بعد از اون هم در مطلبی در ویرگول، در مورد این که چرا موجودیتی به اسم «جامعه بینایی ماشین» رو راه انداختم (لینک) صحبت کردم. پس از انجام چندین پروژه و تولید چندین محتوا پیرامون این موضوع، امروز در این پست قراره که ایده هایی که شما میتونید در پروژه های بینایی ماشین و پردازش تصویر خودتون به کار بگیرید رو بررسی کنیم.
توجه داشته باشید که در این پست، فرض رو بر این گذاشتیم که شما با هوش مصنوعی، پایتون، بینایی ماشین و … آشنایی لازم و کافی رو دارید و حالا قصد دارید یک پروژه جدی باهاش انجام بدید اما نمیدونید باید چی کار کنید. اگر آشنایی ندارید هم مشکلی نیست، میتونید این مطلب رو صرفا برای ایجاد علاقه و یا رفع کنجکاوی بخونید 😁
ایده های مرتبط با تشخیص چهره
تشخیص چهره، همیشه یکی از پرطرفدارترین شاخههای پردازش تصویر و بینایی ماشین بوده است. چرا که با استفاده از تشخیص چهره، میتوانیم عملیات جالبی انجام دهیم و پروسههای زیادی از یک کار بزرگتر را، خودکار کنیم. همچنین میتوانیم امنیت خانه و محل کار و … را نیز با استفاده از تشخیص چهره تامین کنیم.
در لیست زیر، تعدادی از پروژههای مرتبط با تشخیص چهره رو برای شما فهرست کردهام:
حضور و غیاب مبتنی بر چهره
دوربین امنیتی (به این شکل که وقتی شخص ناشناسی وارد حریم دوربین شد از طریق ایمیل یا SMS و … به شما اطلاع بده)
قفل هوشمند ( به شکلی که اگر شما رو دید در رو باز کنه و در غیر این صورت، یک سیستم مانند دزدگیر یا سیستم امنیت خونه رو راهاندازی کنه)
تشخیص حالت و احساسات چهره
تشخیص خوابآلودگی (مثلا در یک کلاس این پروژه میتونه کاربردی باشه).
همه ایدههای بالا، به سادگی قابل انجام هستند. فقط کافیه که کار با کتابخانهها و تئوری پردازش تصویر رو بلد باشید. شاید دو سه روزه بتونید یکی از این پروژهها رو به ثمر برسونید 😁
ایده های مرتبط با تشخیص کرکتر
تشخیص نوری نویسه یا Optical Character Recognition که به اختصار به اون OCR هم گفته میشه، یکی از شاخههای پرطرفدار دیگر در حوزه بینایی ماشین میتونه به حساب بیاد. پروژههایی که در این حوزه انجام میشن به شدت کاربردی هستند و طبیعیه که در حوزههای مختلفی کاربرد خواهند داشت. در اینجا تعدادی از ایدههایی که میتونید روش کار کنید رو اینجا فهرست کردم:
تشخیص و استخراج شماره پلاک (که پیشتر در موردش نوشتم – لینک)
تشخیص و حل مسائل ریاضی/فیزیک (که این هم پیشتر در مورد نوشتم – لینک)
تشخیص دستخط فارسی
تشخیص خط نستعلیق (و در کل خوشنویسی) فارسی
تشخیص نسخه پزشکی (نکته جالب اینه که در نسخ پزشکی، بسیاری از خطخطیهایی که میبینید در واقع روش مصرف و دوزاژ دارو هستند، که طبق کدگذاری خاصی نوشته میشن).
البته باید این نکته رو هم عرض کنم خدمتتون که دنیای OCR خیلی گستردهست. تقریبا هرجایی که شما با نوشتن سر و کار داشته باشید، میتونید از OCR هم اونجا استفاده کنید. خیلی چیزا اینجا به خلاقیت و نیازهای خودتون برمیگرده. اگر ایده دیگری داشتید، میتونید در بخش نظرات همین مطلب با من به اشتراک بذارید.
ایده های مرتبط با پزشکی
هوش مصنوعی در علم پزشکی، جایگاه خاصی در سالهای اخیر داشته. چرا که همه دانشمندان کامپیوتر و همچنین پزشکی، دریافتند که با استفاده از راهحلهای هوشمند، میتونند به حد قابل توجهی، خطاهای پزشکی رو کاهش بدند. همچنین تحقیقات دارو و واکسن هم به شدت سریعتر میتونن انجام بدند. برای مثال، همین دنیاگیری ویروس کرونا که در سال ۲۰۱۹ آغاز شد و کماکان ادامه داره رو بررسی کنیم، بارها از این که از هوش مصنوعی برای پیدا کردن ترکیبات دارویی موثر بر ویروس استفاده شده، صحبت کردند. همچنین در پروسه ساخت واکسن هم بسیاری از مراحل رو به ماشین سپردند و به هوش ماشینی اعتماد کردند. شاید یکی از دلایلی که واکسن این بیماری انقدر سریع ساخته شد، استفاده از همین راهکارهای هوشمند در تولید بوده.
بینایی ماشین هم استثناء نیست و طبیعتا میتونه خیلی به کمک افراد بیاد. در این بخش، تعداد زیادی از ایدههایی که میتونه به پزشکها در شناخت بهتر مشکلات بیمارهاشون کمک کنه رو فهرست کردم و خب بد نیست اگر شما هم سراغش برید و سعی کنید یکیش رو پیاده کنید (این بخش میتونه برای دانشجویان مهندسی پزشکی و پزشکی؛ بسیار مفید باشه)
تشخیص نوع تومور مغزی (تصویر این بخش، پروژهای که خودم انجام دادم)
تشخیص رتینوپاتی دیابتی در اشخاص مبتلا به دیابت
تشخیص MS و مراحل مختلف اون بر اساس MRI
تشخیص سلولهای سرطانی
تشخیص میزان درگیری ریه در بیماریهای تنفسی (مانند COVID-19)
تشخیص ناهنجاریهای پوستی
تشخیص آسیبهای استخوان
تشخیص آسیبدیدگیها و پوسیدگیهای دندان
طبیعتا اینها، همه کارهایی که میتونیم در حوزه پزشکی با کمک بینایی ماشین و پردازش تصویر انجام بدیم نیستن و این دامنه میتونه به شدت گستردهتر باشه. طبیعیه که گستردگی این دامنه به خلاقیت خودتون و نیازهاتون برمیگرده. همچنین طبیعتا اگر شما دانشجوی مهندسی پزشکی یا رشته پزشکی و رشتههای مرتبط باشید، احتمالا ایدههای بهتری خواهید داشت.
سایر حوزهها
چندین و چند حوزه دیگر هست که خب مثل باقی حوزههای پوشش داده شده در این مطلب، نمیشه ایدههای پروژههای بینایی ماشین و پردازش تصویرشون رو فهرست کرد. به همین خاطر، توضیح اجمالی راجع به هر کدوم میدم تا شما ببینید که کدوم حوزه رو بیشتر دوست خواهید داشت و در کدوم حوزه ممکنه بتونید ایدهپردازی بهتری داشته باشید.
تشخیص حرکت یا Action Detection
این حوزه به طور خاص، میتونه برای کارهایی مثل تشخیص و ترجمه همزمان زبان اشاره (لینک)، تشخیص حرکات ورزشی و یا تشخیص «نیت» افراد بشه. برای مثال، میتونیم سیستمی بسازیم که حرکات بعدی فرد در یک نبرد تن به تن (مثل مسابقه بوکس) رو پیشبینی کنه و به مربیها و نوآموزهای اون رشته اطلاع بده.
خودروهای خودران
خودروهای خودران یا Self-Driving که پیشتر هم ازشون در همین وبلاگ صحبت کرده بودم (لینک) میتونن با استفاده از بینایی ماشین و پردازش تصویر، تابلوهای راهنمایی، رفتار سایر رانندگان، موانع در مسیر و … رو تشخیص بدند. این حوزه البته پیچیدگی زیادی داره اما کار کردن روی بخشهای مختلفش میتونه برای یادگیری جوانب مختلف ماجرا جذاب و جالب و مفید باشه.
مصرف انرژی
حوزه انرژی هم حوزه جالبی میتونه برای پروژههای بینایی ماشین باشه. برای مثال OCR ای که بتونه دیتای کنتور گاز/برق رو به متن تبدیل کنه و اون رو با یک مرکز محاسبه قیمت، چک کنه و قیمت رو به ما اعلام کنه. همچنین میشه عکسهای حرارتی از خانهها و … تهیه کرد و با استفاده از بینایی ماشین دقیقا بررسی کرد که کجاها انرژی بیشتری داره از دست میره و … .
این پروژهها به خودی خود شاید جالب به نظر نرسن اما ترکیبشون با IoT و هوشمندسازی در سطوح دیگر، طبیعتا میتونه جذاب و حتی پولساز هم باشه.
کشاورزی
این هم گفتن نداره، شما کافیه که یک سری عکس هوایی از زمینهای کشاورزی داشته باشید. احتمالا خیلی راحت بتونید سیستمی توسعه بدید که آفات رو شناسایی کنه. همینطور میتونید نوع خاک و … هم از روی این عکسها طبقهبندی کنید و پیشنهاد بدید که چه محصولی در این زمین کشت بشه بهتره. در حوزه مصرف انرژی هم میتونید یکی از پروژهها رو بردارید بیارید اینجا و ازش بهرهبرداری کنید. چی از این بهتر؟
ضمن این که امنیت زمین کشاورزی و گلخانه، بررسی نور و رنگ و … هم میتونن اینجا کاربردی باشند.
جمعبندی مطلب
در این مطلب، ایدههایی که میتونید بعنوان یک پروژه تفریحی یا جدی پیادهسازی کنید رو بررسی کردیم. همچنین این ایدهها، به جز این که میتونن رزومه خوبی برای شما بسازند طبیعتا میتونن پایه یک کسب و کار و یا یک استارتاپ باشند که شانس خوبی برای به پول رسیدن داره. به همین خاطر هم ممنون میشم اگر هر کدوم از این ایدهها رو پیادهسازی کردید در بخش کامنت همین مطلب در موردش بنویسید و به من اطلاع بدید تا ببینم چه کردید.
همچنین لازم به ذکره که اگر دوست دارید مطالب فنی/علمی دیگری از من بخونید، میتونید به ویرگول من هم مراجعه کنید. در پایان هم بابت وقتی که گذاشتید، ازتون تشکر میکنم و امیدوارم در آینده باز هم بتونم در این وبلاگ، مطلب بنویسم.
چند ماه پیش، در قالب سه پست وبلاگی، در مورد پروژه جبیر نوشتم (+،+ و +) و از زمانی که ایده جبیر به سرم زد تا زمانی که پروژه کاملا خاموش شد رو توضیح دادم. از قضا، اون سه مطلب از پربازدیدترین مطالب وبلاگ من بودند و خب بد نیست دوباره بحث پروژه جبیر رو زنده کنم و این بار از جامعه نرمافزار ایران و رفتارش در قبال این پروژه بگم.
قبل از این که بخوام وارد اصل مطلب بشم و در مورد جامعه توضیحی بدم، به صورت کاملا خلاصه از پروژه جبیر میگم که چی بود و به کجا رسید. پروژه جبیر، جرقه ورود من به دنیای توسعه نرمافزار و همچنین دنیای نرمافزار آزاد و … بود. این پروژه به من و بعضی از دوستانم کمک بسزایی کرد در این که مسیر خودمون رو پیدا کنیم. حالا خود پروژه چه بود؟ پروژه جبیر یک تلاشی بود برای ساخت سیستمعامل دسکتاپ. همینقدر توضیح راجع بهش به نظرم کافیه اما تاریخ پروژه جبیر به این شکل بود که از سال ۹۰ استارت خورد و سال ۹۴ برای همیشه خداحافظی کرد. ابتدا بر مبنای گنو/لینوکس و دبیان/اوبونتو ساخته شد و بعدتر برمبنای FreeBSD و بعد از آن هم کاملا پروژه Discontinue شد.
در این مطلب، بیش از این که بخوام به بحث خود پروژه جبیر بپردازم، دوست دارم در مورد جامعه نرمافزار آزاد صحبت کنم و بگم که اوضاع از چه قرار بوده و چرا هنوز بعد گذشت ۱۰-۱۱ سال شاید بتونم بگم از این جامعه شاکیام. البته این هم بگم همون زمان هم نقدم به جامعه نرمافزار آزاد برپا بود و هنوز هم که هنوزه به این جامعه و رفتارهاش نقد دارم 😁
جامعه نرمافزار آزاد
جامعه نرمافزار آزاد، به طور کلی به جمعی از افراد گفته میشه که کاربر، توسعهدهنده و طرفدار نرمافزار آزاد و ایده آزادی نرمافزار هستند. این جوامع به شکلهای مختلفی خودشون رو نشون میدن. برای مثال بنیاد نرمافزار آزاد یا FSF به صورت کلی یکی از کارهایی که میکنه، ساختن جامعهست (چرا که خودش هم از دل جامعهای از توسعهدهندههای عصبانی به وجود اومده 😁). این جوامع میتونن به دو شکل باشند؛ یکی جوامعی که فقط روی نرمافزار آزاد و آزادی نرمافزار مانور میدن (مثالش: افرادی که در SFD ها شرکت میکنند) و یا میتونن جامعه کاربری یک نرمافزار خاص باشند (مثل جامعه کاربران وردپرس یا جامعه کاربران لینوکس).
حالا از بحث تعریف و اینها که بگذریم، بحثی وجود دارد به نام جامعه نرمافزار آزاد ایران که خب همین جامعه ولی در قالب کشور ایرانه. در کشور ما، شاید از چندین میلیون نفری که کاربر رایانه هستند، حدود ۹۰٪ روزانه از نرمافزارهای آزاد به صورت مستقیم (VLC, Firefox, …) و غیرمستقیم (سرورهای لینوکسی و …) استفاده میکنند اما خب بالطبع مانند سایر کشورها، افراد کمتری هم هستند که با فلسفه و چرایی این موضوع آشنان. این افراد در اشکال مختلفی مثل لاگها، گروههای تلگرامی، فروم اوبونتو، گروههای ماتریکس و …؛ گرد هم میان و انتقال تجربه و دانش صورت میگیره.
مشاهده رفتار جامعه نرمافزار آزاد ایران
خب همونطوری که در پستهای پیشین راجع بهش صحبت کردم، من از سال ۹۰ در این جوامع حضور دارم. قریب به ۱۱ سال. در این یازده سال، شاید شاخصترین چیزی که باهاش شناخته شدم همین پروژه جبیر بوده. در طی این سالها و تجربیاتی که از این پروژه داشتم، میتونم به راحتی جامعه نرمافزار آزاد ایران – یا لااقل اون بخش بزرگی که خودشون رو جامعه نرمافزار آزاد مینامند – رو یک جامعه بسته مثال بزنم.
بسته بودن جامعه، اصولا به معنای بد بودن جامعه نیست، چرا که اینطور حساب کنیم جامعه پزشکی هم یک جامعه نسبتا بسته محسوب میشه و خب دلیلش هم واضحه، منی که سررشتهای از پزشکی ندارم، چرا باید وارد جامعه پزشکی بشم؟ من در بهترین حالت مشتری جامعه پزشکی هستم. اما بحث نرمافزار آزاد، بحث متفاوتی از چیزی مثل پزشکیه. بسیاری از افرادی که شخصا هر روز میبینم در حال توسعه نرمافزار هستند، افرادی هستند که اصلا در دانشگاه و هنرستان و … کامپیوتر نخواندند. بسیاری دیگر از افراد هم هستند که صرفا کاربر نرمافزار آزاد هستند و اصلا حتی توسعهدهنده نرمافزار هم نیستند!
بنابراین این بستگی و همچنین راه دادن سخت به افراد جدید، همیشه معضل بوده و حتی هنوز هم تا حد زیادی هست. گرچه در سه چهار سال اخیر، این موضوع به شدت بهبود پیدا کرده و خوشبختانه موضوعاتی مثل قلدری برای تازهواردها، تمسخر اعضاء جدید و … به شدت کمتر داره دیده میشه.
حواشی جامعه نرمافزار آزاد ایران
متاسفانه جامعه نرمافزار آزاد ایران، هیچوقت از حاشیه مصون نبوده. حواشی بسیار زیادی در این جامعه طی این سالها مشاهده شده که به صورت کلی اگر بخوایم این حواشی رو دستهبندی کنیم، اولین و مهمترینش چندپارگی همیشگی این جامعهست، دومینش اشخاصی که شیطنت، پروندهسازی و … میکنند و آخرینش؛ حواشیای که بخاطر همکاریهای مشترک اعضا با شرکتها و افراد خاص ممکنه پیش بیاد.
شخصا معتقدم که هیچ کدوم از این موارد نباید جامعه رو به طور کلی تحتالشعاع قرار بده، اما خب واقعیت از داستان خیلی فاصله داره (ترجمهای از جمله Reality is far from fiction) و متاسفانه جامعه نرمافزار آزاد ایران، یک جامعه حاشیهدوست و حاشیهپرور بوده همیشه.
پروژه جبیر و جامعه نرمافزار آزاد ایران
در این بخش، چندین مورد از رفتارهای جامعه نرمافزار آزاد ایران در قبال پروژه جبیر رو قراره که مکتوب کنم و در موردش صحبت کنم. البته قبل از هرچیزی لازمه که سلب ادعا کنم که در این بخش اسمی از شخص نمیاد و اگر از پروژهای هم اسم میاد، بخاطر اینه که در وقایع تاریخی همان دوران، نقش خوبی ایفا کرده. پس اگر مخالف این بخشها و موارد هستید یا نقدی بهش دارید، خواهش میکنم ابتدا این بخش رو با آرامش بخوانید و سپس در بخش نظرات، به بحث بپردازید یا اصلا جوابیه بنویسید 😁
اختراع مجدد چرخ
شاید تنها نقد وارد به همه پروژهها همین باشه. بخصوص در دنیای نرمافزار آزاد. چرا که همیشه هزاران پروژه وجود دارند که پیش از پروژه ما بودند و ما شخصا دنبال این بودیم که چیزی شبیه اونها بسازیم. برای مثال نسخههای نخستین جبیر، به شدت شبیه به لینوکس مینت بود. حتی در همون دوران در ایران توزیع آریوس داشت تولید میشد (که البته بعدتر بهش میرسیم) و خیلیها نقدشون این بود که چرا به تیم آریوس ملحق نمیشی.
علیرغم این که این نقد رو، نقد واردی میدونم و عموما چیزی علیهش ندارم، فقط میخوام این موضوع رو اینجا شفاف کنم که صبر جامعه، به حد خوبی پایین بود. شاید چون آدم تازهواردی بودم و اسمی در این جامعه خاص نداشتم، افراد گارد به شدت بستهای مقابلم داشتند و صبرشون کمتر از حالت عادی بود. چیزی که اینجا میخوام بگم اینه که حتی اگر کسی در حال انجام کار تکراریه، یا بعبارتی در حال اختراع مجدد چرخه، بهش کمی فضا بدیم؛ شاید چرخی که داره اختراع میکنه از چرخ قدیمی، بهتر باشه.
قلدری مجازی و ترول کردن
البته این بحث رو من ترجیح میدم شخصا Cyber Bully یا «قلدری مجازی» ندونم و بیشتر به Trolling شبیهه (که متاسفانه واژه مناسبی در فارسی برای ترولینگ نداریم) نظراتی مشابه این بودند. خب حتی واضحا میشه دید که خودم هم حتی سر کار رفته بودم 😁 البته این رو هم باید ذکر کنم که خیلی از این دوستان، بعدها از بهترین دوستان من شدند و اینجا قصد خراب کردن چهره شخصی رو ندارم. همونطور که ابتدای مطلب عرض کردم.
خلاصه بحث این بود که از بیتجربگی، کمدانشی و خب اون شور نوجوانی من، میشد یک سکوی پرتاب خوب برای ترول کردن درست کرد و بعدتر حقیقتا (و متاسفانه) برای خودم هم جنبه تفریح پیدا کرده بود. یعنی به جایی رسیدیم که هردوطرف میدونستیم داریم مسخرهبازی درمیاریم، ولی باز هم ادامه میدادیم.
پتانسیل مسخرهبازیهایی که اینجا انجام شد، پتانسیلهای هدررفته بود. پتانسیلهایی که میتوانست جای خوبی – مثل همون پروژه جبیر – صرف بشه و پروژه جبیر رو خیلی خیلی جدی تبدیل کنه به یک پروژه موفق مثل همون لینوکس مینت! شاید در همون نقطه خاص باز چراغ پروژه جبیر خاموش میشد، اما در عوض چراغ به نیکی خاموش میشد.
دوگانه جبیر-آریوس
این بخش جاییه که خیلی حرف برای گفتن در موردش دارم. شاید به این دلیل که بیش از باقی موارد، اذیتم میکرد. یکی از بحثهایی که در جامعه نرمافزار آزاد معمولا مطرحه اینه که ما در این جامعه به اون معنایی که در میان نرمافزارهای غیرآزاد یا انحصاری وجود داره، چیزی تحت عنوان رقابت نداریم. البته این هم بگم خیلی طبیعیه که بقالها نگن ماستشون ترشه و ماستی که خودشون درست میکنن و میفروشن رو پروموت و تبلیغ کنند.
اما این وسط نقش جامعه چی بود؟ بهرحال پشت هر دو پروژه دو شخص یا دو تیم بودند که داشتند کار خودشون رو میکردند و این تناقضی با هیچ چیز نداشت. حتی افراد دخیل در پروژه آریوس هم حرفی در تاپیکها و وبسایتهای مرتبط با جبیر نمیزدند چرا که مشخص بود اگر حرفی بزنن میتونه نیتخوانی اشتباه بشه و خودش به شرایط و حواشیای که پیش آمد، دامن بزنه. اما امان از کاربران عزیز. شاید حدود یکی دو ماه از این حواشی قبلی نگذشته بود که به صورت خیلی جدی یک دوگانه یا چندگانه حتی! به وجود آمد بین کسانی که سمت جبیر بودند و کسانی که سمت آریوس بودند! این موضوع ادامهدار شد تا حدی که در تاپیک جبیر بحث آریوس بود و در تاپیک آریوس بحث جبیر 😁
البته این «جنگ توزیعها» همیشه در همه جوامع بوده و هنوز هم هست و گاهی صرفا جنبه تفریحی و بامزه داره (مثل جنگ بین اوبونتو و فدورا) اما اینجا جنگ جنگ تفریحی نبود. حداقل به من این vibe رو میداد که «توی بچه دماغو چی داری مقابل فردی که اسم و رسم و حق آب و گل در جامعه داره؟» که خب به قول معروف این بده :).
خلاصه این بخش خاص از رفتار جامعه خیلی بیشتر از سایر بخشها روی من اثر گذاشت. از سویی اثری که داشت این بود که سعی کنم آدم اسم و رسمداری بشم، تا به جایی برسم که هرکاری کنم هیچ تازهواردی حق اعتراض نداشته باشه که خب این برداشت خوبی نبود و سوی دیگر این که موقع ورود به کامیونیتیهای دیگر، کمی دستبهعصاتر باشم 🙂
سخن آخر
از آنجایی که جدیدا کمتر مینویسم، و در طی چند روز اخیر هم درگیر کرونای امیکرون بودم و امروز که حالم کمی بهبود یافت تونستم این مطلب رو قلمی کنم، حس توضیحات بیشتر نبود و یا شاید ته دلم، دلم میخواست که کمی «فرصت دوباره» به این جامعه داده باشم و به همین خاطر هم، ترجیح دادم یک بخش دیگر از رفتار جامعه رو اینجا ننویسم ولی اگر دوست دارید با اون بخش بیشتر آشنا بشید، میتونید اندر احوالات شهر هرت رو بخونید و کمی واقعیت آن زمان جامعه نرمافزار آزاد رو بیشتر درک کنید.
در پایان هم بابت وقتی که گذاشتید و این مطلب رو خوندید، ازتون تشکر میکنم. باز هم خواهشمندم اگر پاسخ درخوری برای این مطلب دارید، در قالب پست وبلاگ بنویسید (همینجا لینک میشه) یا از بخش نظرات استفاده کنید. مطمئن باشید که با حوصله خواهم خواند و پاسخ خواهم داد.
مدتها پیش، من شروع به نوشتن پیرامون بینایی ماشین و پردازش تصویر کردم (برای مثال، یکی از نتایجی که از این موضوع گرفتم راهاندازی جامعه بینایی ماشین بود) و کم کم تلاشم بر این شد که هوش مصنوعی و یادگیری عمیق و یادگیری ماشین و … هم وارد ماجرا کنم چرا که دونستن OpenCV و به طور کلی بینایی ماشین، چیز خاصی نیست و دانش خاصی به ما اضافه نمیکنه. البته اشتباه نکنید، این که شما یک ابزار خوب مثل OpenCV و کار باهاش رو بلد باشید، خیلی هم خوبه اما کافی نیست.
خلاصه پس از مدتی، شروع کردم به مطالعه الگوریتمهای مختلفی که برای تشخیص اشیا و یا مکانیابی اشیا نوشته شده بودند، اونها رو مطالعه کردم و یکی یکی این ابزارها رو سعی کردم امتحان کنم تا ببینم هرکدوم چطور دارند کار میکنند و … . در این میان با YOLO و مفهومی که داشت، آشنا شدم ولی مشکلاتی سر راه بود که در همین مطلب بهشون اشاره میشه. اما نسخه ۵ یولو، یه جورایی شد رفیق راهم (که خب توضیح دادم چرا دوستش دارم) و در بسیاری از پروژهها مثل حل مسائل ریاضی و همچنین تحلیل مدارات الکتریکی، کمک بسزایی به پیشبرد پروژه کرد.
حالا اگر نوبتی هم باشه، نوبت یک پروژه جدید و باحال دیگره که با YOLOv5 انجام بشه. در اینجا لازمه اشاره کنم که مدلهای هوش مصنوعی صرفا ابزار هستند و گاهی ما ممکنه اصلا نیازی به هوش مصنوعی برای حل مساله نداشته باشیم. مورد بعدی این که ما از ابزار چطور، کجا و چگونه استفاده کنیم خودش امر مهمیه و عموم مقالات مهندسی، پایاننامههای رشتههای مهندسی و …؛ همه در این تلاش هستند که یا این ابزارها را بهینه کنند یا این که روش مناسبی برای استفاده از این ابزارها پیدا کنند.
پروژهای که این بار انجام دادم چه بود؟ این پروژه این بار سامانه تشخیص پلاک خودرو با کمک YOLOv5 است که در نگاه اول، به نظر چیز سادهای میرسه اما در عمل خیلی ساده نیست و در حین پیادهسازی، نیاز داشتم که سادهترش کنم. اما بذارید ایده کلی رو با هم بررسی کنیم. ایده کلی ما این بود که سیستمی داشته باشیم که حضور و غیاب به کمک پلاک خودرو را ممکن کند. حالا این مورد کجاها میتونه استفاده بشه؟ خیلی جاها. پارکینگهای عمومی، جاهایی که خودروها تا ثبت نشده باشند نمیتونن وارد باشن، پلیس راهنمایی و رانندگی و … .
در این پست، با هم به تفصیل به بررسی این پروژه میپردازیم و میبینیم که این پروژه بینایی ماشین چطور انجام شده. سعی کردم که مطلب تا حد خوبی فرمتی مشابه تحقیقات و پایاننامههای دانشگاهی هم داشته باشه تا دوستانی که نیازمند نوشتن چنین مطلبی هستند هم بدون تغییرات زیاد بتونن از مطالب این پست خاص استفاده کنند.
طرح کلی مساله
مساله کلی ما در اینجا اینه که نرمافزاری توسعه بدیم که بتونه نوشته روی پلاک خودروهای ما رو بخونه و اون رو با محتوایی که در یک دیتابیس خاص داریم، تطابق بده. در اینجا ما میتونیم سناریویی فرضی داشته باشیم به این شکل که «فرض کنیم یک پارکینگ داریم که خودروها باید قبل از حضور، پلاکشون رو ثبت کنند و موقع ورود، پلاک خوانده میشه و چنانچه مطابقتی بیش از ۷۰٪ با حداقل یکی از پلاکهای درون دیتابیس پارکینگ داشت؛ مجوز ورود صادر خواهد شد». این سناریوی فرضی به ما کمک میکنه که در ادامه، بهتر پیادهسازی رو انجام بدیم.
پس مشخصا ما نیاز به سیستمی داریم که بتونه تصویر از پلاک دریافت کنه، محتوای متنی تصویر رو استخراج کنه و اون رو با متونی که پیشتر در یک دیتابیس ذخیره کردیم تطابق بده و خروجی مورد نظر ما (مجوز ورود) رو صادر کنه. برای این که بتونیم فرایندی که میخواهیم رو سادهتر کنیم، در اینجا چند مورد لحاظ شده:
محتوای متنی پلاک فقط محدود به اعدادیه که درون پلاک داریم.
برای سادگی بیشتر پروژه، بخش سختافزاری سیستم در نظر گرفته نشده.
برای سادگی باز هم بیشتر، از قسمت دیتابیس و تطابق چشمپوشی کردیم.
در واقع، پیادهسازی پیش روی شما صرفا پیادهسازی از نویسهخوان نوری (OCR) و در حقیقت قسمت مرتبط با بینایی ماشین و YOLOv5 در این پروژه بوده که خود همان هم، بخش زیادی از این پروژه رو شامل میشد.
کارهای پیش تر انجام شده
در این بخش، کارهایی که پیشتر در این زمینه انجام شدند رو با هم بررسی میکنیم. چرا که در بخش انتخاب ابزار احتمالا نیاز به این داشته باشیم که به این قسمت برگردیم و مواردی رو بررسی کنیم. به هرحال در طی جستجوهای انجام شده توسط شخص من، دو پروژه خیلی نظرم رو جلب کردند که در ادامه به معرفی اونها میپردازم.
پلاک خوان دیوار
وبسایت یا اپلیکیشن دیوار برای خیلی از ماها، نام آشناییه. خیلی از افراد هستند که از طریق این اپلیکیشن اقدام به خرید و فروش خودرو هم میکنند و برای تامین امنیت صاحبان خودرو در این پلتفرم، اقدام به طراحی و تولید مدل مشابهی کردند که بهشون کمک کنه تا بتونند پلاکها رو با قالب مناسب وبسایت دیوار، جایگزین کنند تا همه قادر به دیدن پلاک خودروها نباشند. دوستانی که در این پروژه در دیوار همکاری داشتند خوشبختانه مراحل کارشون رو خیلی دقیق و جالب در این پست ویرگولیشون، توضیح دادند و به نظرم بد نیست که همینجا توقف کوچکی کنید و پست این دوستان رو مطالعه کنید؛ سپس برگردید و ادامه این پست رو بخونید.
مراحل اولیه پروژه مورد بحث در همین پست – تلاش برای بازسازی پلاکخوان دیوار
پروژه تشخیص پلاک با پایتون (با استفاده از OpenCV و KNN)
این یکی پروژه هم یکی از پروژههای خوبی در زمینه بینایی ماشین و تشخیص پلاکه که یکی از کاربران آپارات، با پیروی از یک شخص خارجی – که در یوتوب کار مشابهی انجام داده – پیادهسازیش کرده. یک ویدئوی دو ساعت و نیمه که به نظرم ارزش دیدن و فکر کردن داره.
در بخش بعدی، اشاره خواهم کرد که چرا این روش رو اتخاذ نکردم و ترجیح دادم که از YOLOv5 استفاده کنم. برای دیدن این ویدئو، میتونید از این لینک استفاده کنید.
انتخاب ابزار و تکنولوژی
در این بخش، به تفصیل قراره تمامی ابزارهایی که پیش روی ما بود رو بررسی کنیم. در واقع این یکی از روتینهای تحقیقات علمیه که قبل از توضیح کامل ابزاری که استفاده کردیم، توضیح بدیم چرا از یک سری از ابزارها، استفاده نکردیم. این مورد به افرادی که بعد از ما قراره روی اون موضوع کار کنند کمک میکنه تا اول سراغ ابزارهایی که قدیمی شدند یا به هر دلیلی «به درد نخور» هستند نرن و دوم اگر قرار باشه ابزار متفاوتی از ما رو انتخاب کنند، بتونن یکی از همینها رو بررسی کنند (حالا ممکنه اصلا کل بررسی سر به درد نخور بودن ابزار باشه!).
استفاده از Tesseract
تسرکت یکی از نرمافزارهای آزاد مشهور در زمینه OCR محسوب میشه که امتیازات ویژه خودش رو هم داره. برای مثال شاید بشه گفت بزرگترین امتیازش اینه که بدون مشکل روی همه سیستمعاملهای مرسوم دنیا نصب و اجرا میشه و مهم نیست شما مک داشته باشید یا ویندوز یا گنو/لینوکس؛ به سادگی میتونید اجراش کنید و ازش استفاده کنید. مورد بعدی که باعث میشه افراد به سمت تسرکت برن هم اینه که کتابخونهای برای استفاده مستقیم در پایتون داره و این خودش یک امتیاز بزرگه که نرمافزاری که به صورت stand-alone اجرا میشه رو بشه با یک wrapper ساده وارد زبان برنامهنویسی مورد علاقمون کنیم.
در عین حال تسرکت مدعیه که زبانهای مختلفی – من جمله فارسی – رو پشتیبانی میکنه و اینجا میخوایم دلیل عدم استفاده از این ابزار رو دقیقا در همینجا پیدا کنیم. تسرکت، نیاز داره که با فونتهای مختلف آموزش داده بشه و پیدا کردن فونتی مشابه فونتهای مورد استفاده در پلاک خودروهای ایران، کاری تقریبا ناممکنه. البته بعضی از تایپفیسها مثل تایپفیس فونت رویا تقریبا به فونت مورد استفاده در پلاک خودروهای ایران نزدیکه و شاید بشه باهاش کاری کرد. اما این بحث آموزش تسرکت و نتیجه نگرفتن احتمالی باعث خط خوردن تسرکت از لیست شد.
استفاده از KNN
خود کتابخانه OpenCV تابعی برای آموزش یک طبقهبند KNN یا K-Nearest Neighbor ارائه میکنه که در ویدئویی که در بخش قبل لینک دادیم هم استفاده شده. این مورد هم مشکلات خاص خودش رو داشت و از لیست حذف شد. یکی از واضحترین دلایل این بود که ممکن بود این روش خاص، در اعداد شبیه به هم کمی مشکل ایجاد کنه. در کل، علیرغم این که الگوریتم K نزدیکترین همسایه، الگوریتم مورد اطمینانی در یادگیری ماشین کلاسیک محسوب میشه، ریسک خطای مدل نهایی رو هم میتونه بالا ببره.
استفاده از EasyOCR
کتابخانه EasyOCR یکی از محبوبترین کتابخانهها در میان مهندسین بینایی ماشین در دنیاست. یکی از دلایلش اینه که با سرعت خوبی (بخصوص با داشتن GPU) میتونه متون رو تشخیص بده و از همه مهمتر، دور متون مورد نظر ما Bounding Box قرار بده. این کتابخانه هم زبانهای زیادی مثل انگلیسی، آلمانی، نروژی و … رو پشتیبانی میکنه اما نقطه قوتش نسبت به Tesseract اینجاست که در زبانهای فارسی و عربی هم بدون نیاز به استفاده از فونت و …؛ میتونه تشخیص خوبی بده.
با این وجود، مدلی که EasyOCR ازش استفاده میکنه هنوز به خوبی برای زبان فارسی fine-tune نشده و پروژه حال حاضر رو نمیتونه به سرانجام برسونه. به همین دلیل، این ابزار هم از لیست ابزارهای مورد استفاده در پروژه ما، خط میخوره. البته این هم باید اشاره کرد که EasyOCR نرمافزاری آزاده که میشه بهش کمک کرد و بهبودش بخشید (روشش رو اینجا میتونید پیدا کنید).
استفاده از سیستمها و سرویسهای OCR ایرانی
در سالهای اخیر، با توجه به این که افراد زیادی به خوندن کتابها و جزوههای الکترونیکی و اسکنشده روی آوردن، خیلی از شرکتها و گروههای فعال در زمینه متنکاوی و … هم بیکار نبودند و سیستمهای OCR خوبی توسعه دادند که به صورت خاص، برای زبان فارسی کار میکنند.
اما دو مشکل بزرگ اینجا داشتیم. اولین مشکل این که اکثر این سرویسها آنلاین هستند و خیلی از کاربران نهایی این پروژه (مثل یک سازمان دولتی) احتمالا حاضر به این نمیشه که دادههای خودروهاش و کارمندانش رو به یک سرور شخص ثالث ارسال کنه. مشکل دوم هم این بود که اکثر نسخههای آفلاین گرونقیمت هستند. البته شاید بشه مشکل سومی هم اینجا لحاظ کرد و اون اینه که خیلیهاشون امکان این که در یک کد پایتونی بشه ازشون استفاده کرد هم فراهم نمیکنند. پس این گزینه هم کاملا از لیست ما خط خورد.
توسعه CNN اختصاصی
این روش همیشه برای من نقش پلن ب رو داره که اگر مدلی مثل YOLOv5 برای نیازم پاسخگو نبود، سراغش بیام. اما چرا در این پروژه سراغش نرفتم؟ چون که توسعه برای OCR میتونست به شدت زمان، هزینه و انرژی مصرف کنه و حقیقتا چون این پروژه قرار نبود پروژه پولساز باشه یا برای هدفی مثل پایاننامه و … انجام بشه، ارزش این که شبکه عصبی اختصاصی براش توسعه بدیم رو نداشت.
استفاده از YOLOv5
در نهایت، لازم بود که از مدلی مثل YOLOv5 استفاده بشه برای این که بتونیم OCR مخصوص پلاک رو توسعه بدیم. چرا YOLOv5 و چرا سایر نسخههای یولو نه؟ پیشتر این مورد رو به تفصیل توضیح دادم اما توضیح کوتاه ماجرا میشه سهلالوصول بودن نتیجه transfer learning و fine-tuning این مدل خاص. این مدل، یعنی YOLOv5 به سادگی میتونه روی سیستم شخصی من (مکبوک پرو آخر ۲۰۱۹ با سیستم عامل مک) و روی گوگل کولب اجرا بشه. همچنین انتقالش به سایر سیستمها هم راحت انجام میشه و از این نظر، خیالم میتونست راحت باشه.
گذشته از بحث سختافزار و پلتفرم، YOLOv5 به شدت سریع و با دقته، و این مورد میتونه خودش یک امتیاز مثبت بزرگ برای استفاده از این مدل خاص در کاری مثل پروژه خواندن پلاک با YOLOv5 باشه!
جمعآوری و پیشپردازش داده مورد نیاز
بعد از این که ابزارها و تکنولوژیهای مورد نیازمون رو پیدا کردیم، لازم بود تا دادههای مورد نیاز پروژه هم پیدا کنیم. اولین و سادهترین راه (مطابق این مطلب) این بود که خودمون دست به کار شیم و از پلاک خودروها، عکاسی کنیم. اما این قضیه میتونه دردسرساز بشه چرا که خیلیها خوششان نمیاد که کسی از ماشینشون عکاسی کنه. به همین دلیل، در اینترنت جستجو کردم و به دیتاست مورد استفاده در این مطلب رسیدم. در این دیتاست ۳۱۷ عکس از پلاک خودروهای ایران وجود داره که این خودش عالیه! یک حجم خوب از پلاک خودرو که میدونیم دردسری هم برای ما ایجاد نمیکنه.
پس از این که دادههای مورد نظر خریداری و دانلود شد، نوبت به لیبل زدن بود. لیبلهای ما اعداد ۰ تا ۹ بودند و گذشته از اون، برای این که داده تستی کافی داشته باشیم و مراحل پیادهسازی سریعتر پیش بره، فقط ۷۵ تا عکس رو با کمک labelImg لیبل کردیم.
پیادهسازی پروژه
پس از این که ایده کلی، ابزار و داده برچسبزدهشده رو داشتیم، نوبتی هم باشه نوبت آموزش دادن YOLOv5 برای اینه که کار ما رو به درستی انجام بده. حقیقتا، YOLOv5 و ابزارهای مشابه، خودشون یک دور آموزش دیدند و ما فقط به قولی اونها رو fine-tune میکنیم که کاری که ما بخواهیم رو انجام بدن (در نظر بگیرید که ما در دوران ابتدایی و راهنمایی خیلی چیزا رو یاد گرفتیم، در دبیرستان رفتیم سراغ ریاضی و تجربی و اختصاصی اونها رو یاد گرفتیم و بعد در دانشگاه مثلا مهندسی خوندیم که یک فرم خاصتر از ریاضیه. دقیقا مشابه همین فرایند اینجا برای آموزش YOLOv5 هم داره صورت میگیره) و الان فقط کافیه که دیتا و کدهای مورد نیازمون رو در یک سیستم مناسب پروژههای هوش مصنوعی بارگذاری کنیم و سپس مراحل آموزش رو طی کنیم.
دادههای ما روی Google Colab آپلود شدند چرا که آموزش YOLOv5 نیازمند داشتن GPU است. بعد از اون، آموزش به این صورت شکل گرفت که هفتصد و پنجاه epoch (یا نسل) طول کشید، سایز batch ما ۳۲ بود، اندازه تصویر به ۴۱۶ د ۴۱۶ پیکسل تغییر کرد (اسکریپتی که برای آموزش YOLOv5 توسط تیم Ultralytics ارائه شده خودش امکان تغییر سایز رو فراهم کرده) و مدل پایه مورد استفاده yolov5m بود که با ۲۱.۲ میلیون پارامتر آموزش داده شده. پس از حدود ۳ ساعت و ۴۰ دقیقه، مدل ما آماده بود و نیاز داشتیم که تستش کنیم.
نتایج آزمایش
نتیجه آزمایش روی دیتاست آموزش
همین عکس که در ابتدای مطلب هم ازش استفاده شده، عکسیه که در دیتاست آموزشی موجود بود و درستی کار مدل رو تایید میکرد. جدول زیر هم میزان دقت رو به درستی به ما نشون میده:
نتیجه آزمایش روی دیتاست آزمایشی
در جدول زیر هم به صورت مرتب شده میتونیم میزان دقت این مدل رو هم ببینیم. همچنین با یک تابع ساده، پلاک رو به شکل درستش (مبتنی بر ستون xmin) مرتب کردیم تا با پلاک اصلی تطبیق بدیم:
جمعبندی و نتیجهگیری
در اینجا لازمه که پروسههایی که طی شده رو یک بار دیگه بررسی کنیم تا به یک جمعبندی روی پروژه برسیم:
ابتدا تصمیم گرفتیم سیستمی طراحی کنیم که حضور و غیاب یا رفت و آمد رو بتونه مبتنی بر پلاک خودروهای حاضر در یک محل خاص، بررسی کنه.
سپس تصمیم اولیه رو با حذف پروسه دیزاین سختافزاری و همچنین حذف حروف مورد استفاده در پلاک سادهسازی کردیم.
پس از سادهسازی، ابزارهای متنوعی رو مطالعه کردیم و سپس YOLOv5 رو به عنوان ابزار اصلی خودمون انتخاب کردیم.
دیتاستی رو تهیه کردیم و برچسب زدیم.
مدل YOLOv5 رو مطابق نیاز و با دادههای خودمون آموزش دادیم.
در کل، این پروسه گرچه پروسه نسبتا وقتگیر و سختی بود، اما نتیجه به دست آمده واقعا راضیکننده و خوبه. در حال حاضر پروژه ما در حالی قرار داره که میتونه به سادگی با ارتباط با یک سیستم سختافزاری، کاری که براش در نظر گرفته شده رو انجام بده. البته هنوز ضعفهایی متوجه این پروژه هست که در بخش بعدی در موردشون بحث خواهیم کرد.
کارهای آینده
در این قسمت، کارهایی که در آینده میشه برای این پروژه انجام داد رو با هم یک بررسی اجمالی میکنیم:
توسعه سیستم برای خواندن حروف وسط پلاک (چالشهای خاصی در این زمینه وجود داره، مثلا حرف ژ در پلاک خودرو معمولا به شکل ویلچر چاپ میشه)
توسعه سیستم برای خواندن پلاکهای غیرشخصی (پلاکهای عمومی و تاکسی عموما زرد، پلاک وزارت دفاع آبی، پلاک سپاه و نیروی انتظامی سبز پررنگ، ارتش سبز خاکی، دیپلماتیک آبی آسمانی و پلاک خودروهای دولتی قرمز هستند)
توسعه سیستم برای تشخیص و خواندن پلاکهای منطقه آزاد
توسعه سیستم برای تشخیص و خواندن پلاکهای گذر موقت
توسعه سیستم سختافزاری و قرار دادن مدلهای هوش مصنوعی در سختافزار مناسب
مجوز نشر
این پست وبلاگ، تحت پروانه مستندات آزاد گنو یا GNU Free Document License منتشر شده و بازنشر و استفاده از محتویاتش کاملا آزاده. فقط توجه لازم داشته باشید که دیتاستی که برای آموزش استفاده شده آزاد نیست و این آزادی در استفاده شامل بخشهایی از این مطلب میشه که مسولیتش با منه (به طور کلی هرچی که شما در این پست خوندید)
سخن آخر
این پست برخلاف پستهای دیگر این وبلاگ به شدت طولانی شد و از بابت این که وقت زیادی برای خوندنش گذاشتید، واقعا از شما متشکرم. در پایان جا داره از شما دعوت کنم که به ویرگول من هم سر بزنید تا اونجا موارد فنی و تجربیات دیگر من رو بخونید. همچنین، اگر این مطلب برای شما مفید بود کافیه که روی تصویر زیر کلیک کنید و من رو به یک فنجان قهوه به انتخاب خودتون مهمان کنید 🙂
دقیقا دو هفته پیش، در نسخه انگلیسی وبلاگ در مورد YOLOv5 نوشتم (لینک) و توضیح دادم که چرا این مدل هوش مصنوعی برای تشخیص اشیاء رو دوست دارم (و حتی چرا شما باید دوستش داشته باشید) و خب طبیعتا دوست داشتم یک پروژه خیلی خیلی ساده و در عین حال باحال هم با این مدل انجام بدم.
ایدههای زیادی در سر داشتم. برای مثال ایده بازی Red Light – Green Light که در سریال اسکوییدگیم همه دیدیم. اما این ایده علیرغم خوب بودنش، آنچنان کاربردی نبود. پس تصمیم من برآن شد که یک نرمافزار دیگر توسعه بدم. نرمافزاری که هم چالش داشته باشه، هم در نهایت یک کاربرد درست ازش بشه درآورد.
نمیدونم شما یادتونه یا نه، اما نرمافزار سیمبولب، دروانی خیلی خاص و معروف شد. به همین خاطر، تصمیم من هم این شد که سیمبولب رو دوباره بسازم و بعد از این که نتایج مورد نظرم رو گرفتم در موردش وبلاگ بنویسم. پس این شما و این ماجرایی که من داشتم تا این نرمافزار رو بسازم.
گام اول: طرح مساله
در هر پروژهای، اولین گام اینه که مطرح کنیم چه مشکلی رو باید حل کنیم. یا به قول دنیل کوهن Look for the pain. خب دردی که ما اینجا به دنبال حل کردنش بودیم، چی بود؟ این که بسیاری از دانشآموزا و دانشجوها سر ریاضی عمومی یا Calculus مشکل دارند. این مشکل ریشهش کجاست؟ برای من شخصا مهم نیست که این ریشه رو بررسی کنم (البته به معنای این نیست که نظری در موردش ندارم، اما از حوصله این مطلب خارجه).
حالا درد این که بسیاری از دانشجوها و دانشآموزها مشکل دارند، چطور میشه براشون یک مسکن خوب تجویز کرد؟ بعنوان یک مهندس هوش مصنوعی، یا بهتر بگم مهندس بینایی ماشین در ذهنم این ایده چرخید و اون این بود که:
یک نرمافزار هوش مصنوعی وجود داشته باشه که از روی عکس مساله، پاسخ نهایی یا راهحل رو به افراد بده.
و این پروژه، در نظر پروژه بسیار بسیار بزرگی بود اما در نهایت، پروژه سادهای شد. در ادامه، در راهی که طی شد توضیح خواهم داد.
گام دوم: انتخاب ابزار
گام دوم برای من، انتخاب ابزار بود. اول از همه میخواستم برم سراغ OCR های آماده برای تشخیص مسائل پارامتری مثل x و y و … . اما بعد دیدم که اینجا علاوه بر حروف و اعداد، نشانهها هم هستند. ضمن این که به شکلی باید توان و … هم تشخیص داد. پس کمی پروژه رو نگه داشتم تا به ابزارها فکر کنم.
بعد از مدتی تحقیق و تفحص، به دارکنت رسیدم که برای ترین کردن YOLOv3 و YOLOv4 استفاده میشه و خب دارکنت مشکلات زیادی هم با خودش به همراه داره. برای مثال کاملا در سیپلاسپلاس نوشته شده و روی سیستمهای مختلف باید از نو کامپایل بشه. با CPU درست کار نمیکنه. کامپایل کردنش روی مک یا ویندوز دردسره و انتقال دادنش به Google Colab هم میتونه تا حد زیادی مشکلساز بشه.
بعد از اون الگوریتم YOLOv5 رو کشف کردم. تقریبا همه مراحل کاملا پایتونی پیش میرفت و این عالی بود. کم کم دیدم که میشه بعد از ترین کردن قضیه، از pytorch هم استفاده کرد و اشیاء رو تشخیص داد و از اون بهتر این بود که در تشخیص اشیاء، میشد خروجی pandas هم گرفت که مختصات شیء مورد نظر به همراه لیبلش در اون data frame خاص موجود بودند. پس به این شکل تشخیص این که ما با چه چیزی روبرو هستیم هم سادهتر از گذشته میشد.
وقتی این ابزار رو با چند چیز مختلف تست کردم، نوبت این رسید که در این پروژه حتما ازش استفاده کنم. اما این تمام ماجرا نیست. دقیقا وقتی که سمت OCR ماجرا هندل میشد، یک بحث خیلی مهم میموند. بحث این که چطوری باید مساله حل بشه؟ برای حل مساله هم از Wolfram Alpha گفتم کمک میگیرم.
خب حالا نوبتی هم باشه، نوبت اینه که دادههای مورد نیاز رو جمع کنیم. قبلتر در مورد راههایی که شما میتونید برای جمعآوری داده استفاده کنید، صحبت کردم و میتونید از اینجا بخونیدش.
نمونه دادههای استفاده شده در این پروژه
گام سوم: جمعآوری داده
برای جمعآوری دادهها، نیازمند این بودم که روی چند سطح مختلف (وایتبرد، کاغذ A4 و همچنین کاغذ خطدار) و با چند دستخط مختلف، مسائل ریاضی رو بنویسم. بعد از نوشتن مسائل ریاضی، از دوستانم خواهش کردم که روی صفحات مختلف و همچنین وایتبرد، مسائل ریاضی رو بنویسند.
بعد از این که مسائل ریاضی رو روی این سطوح و با دستخطهای مختلف داشتم، نوبت عکاسی ازشون بود. از هر بار نوشتن، چندین عکس از چند زاویه گرفتم. چرا که زوایای مختلف باعث میشن توزیع نور هم در تصاویر یکسان نباشه و این خودش یک مرحله data augmentation رو برای من کاهش میداد.
حالا یه حجم زیادی داده دارم، باید بعدش چی کار کنم؟ پاسخ سادهست. الان زمانیه که ما وارد مرحله پیشپردازش داده میشیم.
گام چهارم: پیشپردازش داده
بعد از این که ما دادههای مورد نیاز خودمون رو جمع کردیم، نیازمند اینیم که داده رو پیشپردازش کنیم. به طور کلی، پیشپردازش داده به پروسهای گفته میشه که در اون قراره داده ها تمیز بشن، تغییر کنند (یا به قولی data augmentation رخ بده)، برچسب زده بشن و دادههای غیرلازم (یا همون نویز) دور ریخته بشه.
اولین مرحله برای من اینجا، تکه تکه کردن عکس بود. شاید فکر کنید که برای تکه تکه کردن عکس، از ابزار خاصی استفاده کردم یا کدی زدم. باید بگم که خیر، ابزارم دقیقا ادوبی فتوشاپ و ابزار Slice بود. بعدش با قابلیت save for web آمدم و عکسهای قطعهقطعه شده رو ذخیره کردم. پس از ذخیره نهایی عکسها، نیاز بود که عکسها برچسب زده بشن.
برچسبها، در مرحله آموزش مدل، به ما کمک میکنند که اشیاء رو در تصاویر پیدا کنیم. این برچسبها در مراحل بعدتر به کمک ما میان تا بتونیم مسائل یافت شده رو به ولفرامآلفا بدیم تا برامون حلش کنه. پس لازم بود که این اتفاقات بیفته.
گام پنجم: آموزش مدل YOLOv5
و اما گام یکی مونده به آخر دقیقا این بود که مدل آموزش داده بشه. آموزش این مدل با pytorch به شدت سرراست و راحته و کلش اجرا کردن یک دستور در ترمیناله. باز با این حال، مشکلات عدیدهای داشتم. برای مثال روی لپتاپ شخصی چون GPU مناسب نداشتم، آموزش به شدت طولانی میشد. آموزش رو به Google Colab منتقل کردم و چون پلن رایگان داشتم، اونجا هم یک سری داستان جدیدتر پیش آمد. اما بهرحال هرطور که شد، مدل آموزش داده شد و نتایج خوبی هم ازش گرفتم.
در مورد آموزش مدل و نحوه کار اون به زودی محتوای آموزشی جدیدی تولید خواهد شد که به تفصیل در اون توضیح میدم چطور میتونید YOLOv5 رو خودتون آموزش بدید و باهاش کار کنید. در حال حاضر، توضیح مراحل آموزش تا حد زیادی از حوصله این پست وبلاگ خارجه.
و گام نهایی: آزمایش مدل و نوشتن رابط ولفرام آلفا
پس از این که مدل آموزش داده شد، نیاز بود چندین خط کد پایتون نوشته شه برای چند منظور. اول این که وزنهایی که لازم بود از مدل آموزشدادهشده، لود کنه. دوم این که یک عکس رو از ورودی بگیره و مراحل inference رو روش انجام بده و در نهایت، اگر کاربرخواست اون رو بفرسته به ولفرام آلفا و مرورگر رو براش باز کنه.
برای این مرحله، برخلاف باقی مراحل وقت زیادی نذاشتم ولی با این حال کدش (بدون وزنها) در گیتهاب شخصی من موجوده و میتونید نگاهی بندازید. البته که به زودی گیتهاب بروزرسانی میشه و شما قادر خواهید بود که وزنها رو هم دانلود کنید. اما فعلا وزنها در دسترس نیستند.
در نهایت هم برای این که عملکرد قضیه رو ببینید، این ویدئو کوتاه رو میتونید تماشا کنید که هم inference رو تست میکنیم هم حل مساله با ولفرام رو:
جمعبندی و مشکلات این نرمافزار
این پروژه به عنوان یک پروژه تفریحی، واقعا تفریح خوب و سالمی بود و کلی یادگیری برای من داشت. یادگیری دقیقتر و عمیقتر YOLOv5، یادگیری دقیقتر و عمیقتر PyTorch و از همه مهمتر درگیر شدن با چند مساله و به قولی، دردهای دنیای واقعی. از نتیجه کاملا راضی بودم و هستم، اما فکر نکنم در آینده این پروژه خیلی برام راضیکننده باشه.
احتمالا بعد از مدتی به این پروژه برگردم و بزرگترین مشکلش – یعنی شباهت زیاد ورودیها به هم – رو طور دیگری هندل کنم. برای این که ببینیم یه چیزی در پوزیشن توان یه چیز دیگه قرار گرفته یه چارهای بیاندیشم و … . خلاصه که راه برای بهبودش زیاده و این بهبودها رو شخصا پیگیر هستم که در این پروژه اعمال کنم. شاید هم لازم باشه داده ورودی رو افزایش داد یا حتی مدل مورد استفاده رو عوض کرد.
در نهایت، از شما بابت وقتی که برای خوندن این مطلب گذاشتید، ممنونم. امیدوارم که این مطلب مفید واقع شده باشه و به دردتون خورده باشه. ضمن این که اگر به این تیپ مسائل و مطالب علاقمند هستید، میتونید من رو در ویرگول هم دنبال کنید و اونجا هم مطالبم رو بخونید. اگرچه در ویرگول عمده مطالبم مرتبط با بیزنس، موفقیت و ایناست.
در نهایت از شما خواهش میکنم که اگر این مطلب براتون مفید بود، یک قهوه به انتخاب خودتون مهمانم کنید تا موقع نوشیدن قهوه به یادتون باشم و از این دست مطالب، بیشتر تولید کنم.
در دو پست قبلی (+، +) در مورد پروژه جبیر با شما صحبت کردم و توضیح دادم که ایدهش از کجا اومد و چی شد و چه کردیم. قسمت دوم یکم پرش قلم من زیاد بود چون موضوعات زیادی رو شامل میشد اما خب نیاز بود که گفته بشه. حالا رسیدیم به قسمت آخر. در این قسمت، میخوام از این بگم که در جشنواره خوارزمی چه گذشت و چرا جشنواره خوارزمی شروعی بود بر پایان این پروژه.
بذارید قبل از هرچیزی، یک مرور کلی داشته باشیم بر دو قسمت قبلی. در قسمت اول، توضیح دادم که من شیفته اپل شده بودم و میخواستم مثل استیو جابز، یک شخصیت مهم در دنیای تکنولوژی باشم و همون قدر شناخته بشم و همونقدر هم ثروتمند (بالاخره آرزو بر نوجوانان عیب نیست، هست؟) و تصمیمم این شد که یک سیستم عامل بسازم و بعد از کلی تحقیق و توسعه؛ نتیجه این شد که یک سیستم عامل مبتنی بر گنو/لینوکس و توزیع اوبونتو بسازم. اسم این پروژه هم گذاشتیم جبیر.
در قسمت دوم، از فراز و نشیبهای فنی این قضیه گفتم. از این گفتم که چی شد که اینطوری شد و چی شد که ساخته شد. بذارید سادهتر و مفصلتر بگم، اول گفتم که فاز تحقیقم چی بود و چه کردم و چه چیزایی خوندم. بعد گفتم که چرا تصمیم گرفتم بیام سراغ سیستمعاملهای متنباز موجود مثل لینوکس یا BSD و در نهایت گفتم چرا لینوکس رو انتخاب کردم. بعدش از عادت Distro Hopping گفتم (این عادت یعنی که شما بیایید و توزیعهای مختلفی تست کنید و همیشه روی یک توزیع ثابت نمونید) بعدش هم گفتم چی شد که مینت و اوبونتو رو به عنوان مبنا در نظر گرفتم و چطور نسخههای اولیه جبیر ساخته شد.
بعد از اون، از انتشار جبیر و اشتباهاتی که در ساخت این پروژه شد نوشتم. بعد از این موضوع، وارد بحث نسخه ۴ که نسخه جنجالی جبیر بود شدیم (نسخهای که به اینترنت متصل نمیشد، به همراه نظر جادی و تبعاتش) و بعد از اون چه شد که به سراغ BSD رفتیم و همین موضوع هم مزید بر علت شد که جبیر روز به روز به پایان خودش، نزدیکتر بشه.
جشنواره خوارزمی
جشنواره خوارزمی، یک جشنوارهست که در سطوح مختلف (چه مقطع تحصیلی و چه تقسیمات جغرافیایی) برگزار میشه و یکی از اهدافش، اینه که به مخترعین و مبدعین و محققین جوان کمک کنه تا نتایج کارهاشون دیده بشه. مقام آوردن در این جشنواره، خودش یک سری امتیاز خاص به همراه داره که این امتیازات عبارتند از دانشگاه بدون کنکور رفتن (طبیعتا در رشتهای که پروژه/اختراع ارائه کنید) و معافیت سربازی و اینها. البته اینها مال اون زمان بود و الان نمیدونم چطور شده ولی فکر نمیکنم تغییری کرده باشه.
احتمالا اگر الان این رو خوندید و دبیرستانی هستید، براتون خیلی دغدغه شده که حتما در این جشنوارهها شرکت کنید، ولی خواهش میکنم که قبلش حتما مطلبی که اول این پست لینک شده رو یه نگاه بندازید. قدیمیه ولی ارزشش رو داره. خلاصه بگذریم؛ چیزی که اینجا مهمه اینه که شما بدونید اگر طرحتون به زعم داوران جشنواره واقعا خوب بیاد، امتیازاتی دریافت میکنید که میتونه شما رو به اهداف زندگیتون نزدیک کنه.
حقیقتا من از وقتی بچهتر بودم، بچههایی که به این جشنواره راه پیدا میکردند رو از تلویزیون و روزنامه و … دنبال میکردم، دلم میخواست روزی مثل اونها باشم. مادامی که در تهران در مقطع راهنمایی تحصیل میکردم خبری از این جشنواره برای دانشآموزان راهنمایی نبود (سالی که ما شرکت کردیم ولی بود) و همین امر، باعث شده بود که من با این تیپ جشنوارهها غریبه باشم. اما در دبیرستان اوضاع فرق کرد. ما این پروژه رو شروع کرده بودیم. بخصوص سال دوم دبیرستان که بودم، رضا باقرزاده عزیز هم به من پیوست و با هم پروژه جبیر رو پیش میبردیم.
یک روز، ما از مدیر مدرسهمون خواستیم که سالن اجتماعات مدرسه رو در اختیارمون بذاره و از بچههایی که اون ساعت خاص، بیکارن دعوت کنه که بیان و پروژه ما رو ببینن. این هم خودش یکی از حرکات «استیو جابز»گونه بود 🙂 خلاصه این اتفاق افتاد و از قضا، مدیر مدرسه هم خودش اومد در اون جلسه دورهمی حضور پیدا کرد. این قضیه برای ما خیلی خوب بود چرا که حسابی در چشم مدیر مدرسه، درخشیده بودیم.
اما این تمام ماجرا نبود …
روز بعد اون کنفرانس، مدیر مدرسه از من و رضا درخواست کرد که جزییات پروژه رو براش بنویسیم. من هم یک صفحه A4 نوشتم تحویلش دادم. یک هفته بعد، ما رو از سر کلاس (که اگر اشتباه نکنم دینی بود) خواستند به دفتر. ما اول کمی ترسیده بودیم (بهرحال سیستم آموزشی ما ایجاب میکنه که از دفتر بترسیم 😂) و وقتی رفتیم، دیدیم یک آقای میانسالی هم اونجا هستند. مدیر مدرسه به ما گفت که ایشون از مسولین آموزش و پرورش استان هرمزگانن و پروژه ما در مرحله استانی خوارزمی پذیرفته شده.
ایشون گفت که روز بعدش، بریم پیشش. پرسیدیم بعد مدرسه؟ گفت نه، از مدیرتون اجازه بگیرید و دو زنگی رو ما در خدمتتون هستیم. ما هم از این بابت خوشحال شدیم. میدونید چرا؟ چون بالاخره دو زنگ پیچوندن هم خودش صفای خودش رو داشت. حالا از این حال و هوا بیاییم بیرون. ما فرداش رفتیم پیش ایشون. ایشون ما رو برد پیش مسولین خوارزمی و کلی تحویلمون گرفتند. این تحویلگیریها البته دلیل داشت! دو سه سالی بود که از استان هرمزگان در رشته کامپیوتر هیچ پروژهای معرفی نشده بود و اینها هم از این موضوع حسابی خوشحال بودند.
خلاصه که این دوستان، به ما گفتند یک A4 کافی نیست و در قالب یک پرپوزال باید در مورد پروژه بنویسیم. من و رضا هم گفتیم پس ما میریم روی این کار میکنیم و میآییم پیش شما. اون خانمی که در آموزش پرورش به ما گفت که بعدا بریم پیشش، گفت که چهارشنبه ها عصر هم حضور داره در همون دفتر و نیازی نیست کلاس رو بخاطر قرار با ایشون بپیچونیم. خلاصه کلام که ما رفتیم و یک فایل ۲۰-۳۰ صفحهای با عنوان «سیستمعامل جبیر» نوشتیم و این رو پرینت کردیم و در طلق و شیرازه قرار دادیم و چهارشنبه بردیم پیش ایشون.
بعد از کمی بررسی، غلطهای این پرپوزال رو به ما گفت و ما اون رو اصلاح کردیم. بعدش به ما گفتند که تا تیرماه حدودا صبر کنیم (و این ماجرا حدودای فروردین اتفاق افتاد اگر درست یادم باشه). ما هم به درس و مشقمون رسیدیم و امتحان دادیم. اما خب اینجا یک سری اتفاق خاص هم افتاد.اتفاقاتی که به نوبه خودشون جذاب و جالب بودند.
جشنواره خوارزمی استانی
جشنواره استانی، برخلاف کشوری، اینطوری نیست که شما بری از پروژه دفاع کنی. بر اساس همون توضیحاتی که از پروژهها ارائه شده، داوری میکنند و اونایی که حس میشه شانس خوبی برای مقام کشوری آوردن دارند انتخاب میشن. بعد از این، این مورد به صاحبان ایده و پروژه، ابلاغ میشه.
در همین حین، ما که سخت مشغول کار روی جبیر بودیم و حتی یادمه که دونفری با رضا میرفتیم پیش خدمات کامپیوتریها که مجابشون کنیم که یکی دو تا سیستم بدن دست ما که روش جبیر نصب کنیم (شاید باورتون نشه ولی یکی از پلنهای من، برای هر توزیعی که درش نقشی داشتم تولید کامپیوترهای رومیزی با همون سیستمعامل هم بوده) و معمولا اونها هم یه چراغ سبز الکی نشون میدادن، یک باره به تلفن رضا زنگ زدند. رضا گفت «آقای …؟» و بعد گوشی رو روی اسپیکر گذاشت و به ما اعلام شد که در استانی، رتبه اول شدیم (لینک خبر).
در مورد تاریخ خبر باید به شما بگم که این اخبار، بعد از برگزاری جشنواره کار شدند. یعنی ما تیر ماه خبر داشتیم از این که در استانی پذیرفته شدیم ولی ظاهرا قوانینی که روی جشنواره حاکمه، ایجاب میکرد که تا زمان شروع جشنواره سال بعد خبری ازش کار نشه. خلاصه بگذریم. ما دو تا هم خوشحال و سرخوش گفتیم که فرداش میریم آموزش پرورش.
در آموزش و پرورش، بیش از گذشته تحویلمون گرفتند! این بار به ما گفتند که نیازه تا فیلمی بگیریم که هردو توش باشیم (البته ما دو فیلم مجزا گرفتیم. چرا که رضا بیشتر روی جنبه UI و ظاهری قضیه کار میکرد و من روی بیس سیستم) و بعد یک پرپوزال دیگر بنویسیم که یک سری ملاحظات خاص رو درش رعایت کرده باشیم. این ملاحظات شامل نحوه فهرستبندی، استفاده از فونت و … بودند. خلاصه ما دوتا CD و یک کتابچه تحویل دادیم و بعدش مدت نسبتا طولانی، از هم دور شدیم.
جشنواره خوارزمی کشوری
مرداد ماه بود و من به همراه مادرم چند روزی (فکر کنم دو هفته!) آمدیم تهران. در همین روزها، یادمه که رضا به من زنگ زد. بهش گفتم چه خبر؟ چه کارا میکنی؟ و خیلی عادی حرف زد. برای من این موضوع خیلی جالب بود که چطور تونسته بود اونقدر خونسرد باشه و یهو من رو غافلگیر کنه :)) پای تلفن به من گفت که «فلانی زنگ زد و گفت که اوایل شهریور باید تهران باشیم که از پروژه دفاع کنیم.
خلاصه بعد برگشت من به بندر، قرار شد با رضا بریم و در مورد این پروسه بپرسیم. به ما گفتند که داورا اینطورین و باید چه کنید و … (که با تقریب خوبی البته درست نبود) و به ما پولی دادند که بلیت هواپیما تهیه کنیم و با هواپیما بریم تهران. همچنین بودجهای به ما دادند که لباسهای متحدالشکل تهیه کنیم و ما هم دوتا پیراهن گرفتیم که لعنت خدا هم گرونش بود، ولی سال ۹۱ بابت هر پیراهن ۶۰ هزار تومان پول دادیم 😂.
خلاصه ۵ شهریور ۹۱ شد. ما رفتیم فرودگاه بندرعباس و سوار یک عدد ایرباس A300 هواپیمایی ماهان شدیم و به سمت فرودگاه مهرآباد تهران پرواز کردیم. در تهران هم مسول آموزش و پرورش هرمزگان (همون آقای میانسالی که کارهای ما رو انجام داده بود) آمد و ما رو به خوابگاه دانشجویی دانشگاه تربیت دبیری شهید رجایی برد. حقیقتا تا حد خوبی حالمون گرفته شد، چرا که به ما گفته شده بود برای ما هتل رزرو شده و از این دست چرت و پرتا. ولی خب ایرادی نداشت، فرداش روز بزرگی بود.
فرداش رفتیم. ظهر شد و دعوت شدیم که بریم داخل اتاق. داخل اتاق، سهتا آقا نشسته بودند که علیالظاهر، اساتید کامپیوتر همون دانشگاه بودند (اینجا این رو بگم که بعدا روش بحث صورت بگیره، اگر جشنواره خوارزمی یک جشنواره کشوریه، آیا بهتر نیست که فراخوانی زده شه و از اساتید و صاحبنظران کل کشور خواسته شه که داوطلب بشن؟ چرا فقط یک دانشگاه خاص؟) و یک سری سوال پرسیدند. ما وقتی داشتیم صحبت میکردیم و …؛ من اشاره کردم که جبیر مبتنی بر گنو/لینوکس ساخته شده. یادمه یکی اونجا خندید و گفت «پس مثل همون لینوکس فارسیهست…».
حالا شما خودتون حساب کنید که این که این دوستان زده بودند تو کانال مسخرهبازی، چقدر به ما فشار آورد. خلاصه ما ارائه و دفاعمون رو تحویل دادیم و آمدیم بیرون. ناهاری بر بدن زدیم و کمی تهرانگردی کردیم و بعدش هم رفتیم سمت فرودگاه. دقیقا یادمه بعد از این که مسول آموزش پرورش ما رو ترک کرد، ما کاری نداشتیم که انجام بدیم پس با رضا نشستیم به خوندن آموزش Bash و اسکریپتنویسی 😁
خلاصه به سمت بندرعباس برگشتیم و بعد از اعلام نتایج، فهمیدیم که رتبه قابل قبولی در این جشنواره کسب نکردیم. این خودش یک شکست بسیار بسیار بزرگ برای ما محسوب میشد. گرچه کادر مدرسه تاکید داشتند سال بعدش هم شرکت کنیم ولی حقیقتا ما سال بعد تصمیم داشتیم دیگه شرکت نکنیم و همین هم شد. این دقیقا اینجا به این معنا بود که پروژه هم داره تا حد خوبی به آخرای خودش نزدیک میشه.
رفتن روی BSD، بزرگترین اشتباه
هنوز که هنوزه، من سیستمعامل FreeBSD رو به شدت دوست دارم و محاله وقتی نسخه جدید میده، نصبش نکنم و باهاش کمی بازی نکنم. اما حقیقت امر این بود که BSD ها – به جز مک – واقعا برای استفاده دسکتاپ و روزمره مناسب نیستند. حتی روی سرور و روتر و … (که BSDها حرفهای به شدت زیادی برای گفتن دارند) هم معمولا انتخاب خوب و اول نمیتونن باشند.
یکی از مهمترین دلایل، اینه که BSDها معمولا ساپورت سختافزاریشون اونقدری که باید و شاید، خوب نیست. دلیل دیگری که به ذهنم میرسه اینه که استفاده از BSDها به شدت محدوده و بین هزاران شرکت و استارتاپی که مبتنی بر لینوکس هستند، شاید فقط Netflix, WhatsApp و Sony باشند که از FreeBSD (یا نسخههای دیگر BSDها) استفاده کنند. همین امر، باعث شده که BSDها مستندات کمتر و جوامع کوچکتری داشته باشند.
و البته اشتباه دیگری که داشتم این بود که فکر میکردم اگر برم روی BSD و یه بخش خوبی از رابط کاربری هم خودم بسازم (که تاحدی این کار رو کرده بودم) و مجوز اون هم BSD قرار بدم، شاید بتونم کد رو ببندم. اما هیچ کس نبود بهم این نکته رو گوشزد کنه که بستن کد برای پروژهای که تیم کوچکی داره و ساپورت مالی نمیشه و سرمایهگذار خاصی هم نداره، سم مطلقه.
خلاصه با پیادهسازی نه چندان بد، تفکرات اشتباه و صد البته واکنشهای عجیب و غریب جوامع نرمافزار آزاد و متنباز ایران، این پروژه باز بیشتر و بیشتر روی سراشیب سقوط قرار گرفت. اما حقیقت امر اینه که یکی از بزرگترین تیرهای خلاص این قضیه رو، همین جامعه نرمافزار آزاد به این پروژه وارد کرد.
واکنشهای جامعه نرمافزار آزاد ایران و پیامدهایش
من اصلا دوست ندارم در نقش قربانی فرو برم و شکستها و عدم موفقیتم رو گردن کسی بندازم. حقیقتا از این رفتار به شدت بدم میاد و اگر ببینم کسی چنین رفتاری داره خیلی سریع، از دایره دوستی و حتی آشنایی من ممکنه حذف بشه. پس امیدوارم این بند خاص از مطلب من، این حس رو القاء نکنه که در نقش قربانی فرو رفتم.
بگذریم، جامعه نرمافزار آزاد ایران، که در حال حاضر عمدتا حول اوبونتو و در فروم اوبونتو متمرکز شده تقریبا (و این تمرکز هم خودش سم مهلکیه) رفتارهای عجیب و جالبی دارند. این جامعه عموما اینطوری بود که خیلی سخت افرادی که بیرون گود بودند رو میپذیرفت و خیلی وقتها هم نمیتونستند یک سری موضوعات خاص رو بپذیرند. به همین دلیل، رفتارها بیشتر شبیه گنگسترها و یاکوزاها میشد. حقیقتا در مقابل پروژه جبیر هم تا حد زیادی به این شکل برخورد نشان دادند.
برخوردهایی از این دست که «چرا به فلان پروژه کمک نمیکنی؟» اصلا از نظرم بد نیست. خیلی هم خوبه و خیلی راحت میتونه شما رو مجاب کنه که نیاز نیست چرخ رو از اول اختراع کنید. اما خب، گاهی برخوردها سمت ترولینگ و قلدری سایبری پیش میرفت. مثلا شخصی میومد میگفت «بیا کرنل رو بکن داروین» و بعد چند نفر ادامه میدادند. نکته جالب هم این که از سادگی من هم به عنوان یک نوجوان، تا حد خوبی بهرهکشی شده بود اینجا. من الان دانشی دارم که بهم میگه که تعویض کرنل بسیار سخته، و در بعضی موارد کاملا ناممکن. اما اون موقع من چنین آگاهیای نداشتم.
خلاصه بگم که کم کم به جایی رسید که من دیگه میفهمیدم کجاها ملت دارند دستم میندازن. حقیقتا خوشم اومده بود که خودم همراه شم با این قضیه و تا میتونم چرت و پرت ببافم. اما خب حقیقتا این به ضرر من شد چرا بعدتر، برچسب ترول به من چسبید و از جامعه کاملا پاک شد. جامعهای که تقریبا همیشه نشون داده با افراد جدید – صرفنظر از این که آدمهای خوبین یا بد – چنین برخوردی رو داشته و خب این برخوردها، نتایج خوبی هم نداشته. برای مثال، خود من از سال ۹۳ تا ۹۶ واقعا در این جامعه هیچ حضور فعالی نداشتم و ۹۶ دوباره برگشتم بهش. سال ۹۹ هم موارد مشابهی پیش آمد و دلخوریهایی ساخته شد.
خلاصه بگذریم از این موضوع، میخواستم صرفا این موضوع رو شفاف کنم که جامعه، از دور ممکنه قشنگ به نظر برسه اما خب درونش نیازمند سازگاری بالا و همرنگ جماعت شدنه. حقیقتا من هم شخصی نیستم که بخوام همرنگ جماعت باشم، به همین خاطر ممکنه در جوامع مختلف، متضرر بشم 😁
سخن آخر
اول از همه از شما ممنونم که این مطلب رو خوندید و تا اینجا اومدید. دوم، میخوام ازتون دعوت کنم که علاوه بر این وبلاگ، ویرگول هم میتونید مطالب من رو بخونید ولی در ویرگول معمولا انقدر حرافی نمیکنم 🙂 و در نهایت، میخوام یک جمعبندی کلی روی این سه قسمت بکنم و بگم که به پایان آمد این دفتر، حکایت همچنان باقیست.
حقیقتا بعد از شکست پروژه جبیر، من یک درس بزرگ گرفتم. درسی که بهم گفت «نیاز نیست استیو جابز دوم باشی، تو خود خودت باش» و این درس به نظرم بزرگترین نکته شخصیتی بود که میتونستم از انجام چنین پروژهای دریافت کنم. درس و نکته بعدی هم این بود که حرفهای اطرافیان میتونه به شدت روی روان آدم تاثیر بذاره و نباید گذاشت این حرفها، از ما یک موجود کینهای بسازه که بعدتر نیازمند انتقامگیری و پروندهسازی و فلان باشه. درسهای شخصیتی و روانی این پروژه، واقعا برای من مهم و ارزنده بودند.
از نظر فنی هم، درسهای خوبی گرفتم. برای مثال اندازه افرادی که LPIC 1, 2 میگذرونند از لینوکس یاد گرفتم. تا حد خوبی پایتون یاد گرفتم. حتی همین امر باعث شد که بعدتر، روبی یاد بگیرم و … . همچنین یاد گرفتم که نیاز نیست برای متفاوت بودن حتما به سمت BSD رفت بلکه یک رابط کاربری متفاوت هم میتونه به خودی خود، تا حد خوبی تاثیر مثبت روی ذهن افراد داشته باشه.
از منظر بیزنسی هم بخواهیم نگاه کنیم یک درس خیلی خوب گرفتم. اون این که «وقتی تیم کوچیکه یا پروژه تکنفره جلو میره نیازی نیست که کد، بسته باشه. اتفاقا باز بودن کد به نفع توئه». و همین باعث شد از اون به بعد عمده پروژههای من روی گیتهابم قرار بگیرند.
خلاصه که یک پروژه شکستخورده، میتونه پر از درس برای ما باشه. مهم اینه که ما بخواهیم همیشه در سوگ بمونیم؟ یا این که به قدری سوگواری کنیم و بعد از اون سوگواری به سمت انجام یک پروژه جدیدتر قدم برداریم. نمیدونم فیلم Whiplash رو دیدید یا نه، اما در صحنهای یکی از شخصیتها میگه «چارلی پارکر وقتی با اون صحنه مواجه شد، اول سوگواری کرد. بعد یک روز کامل استراحت کرد و بعدش اونقدر تمرین کرد که ما امروز ازش حرف بزنیم». پس باید گفت که این ماییم که انتخاب میکنیم چارلی پارکر باشیم، یا اون نوازندهای که با یک شکست، کلا ساز و نوازندگی رو میذاره کنار.
در پایان، مجددا از شما بابت وقتی که برای خوندن این مطلب گذاشتید تشکر میکنم. همچنین امیدوارم که این تجربه شکست طولانی، تونسته باشه برای شما جرقه یا کمکی باشه در هندل کردن پروژههاتون یا حداقل بهتون کمک کرده باشه که چطور با پروژههای شکست خورده کنار بیایید. امیدوارم که در آینده نزدیک، بتونم با مطالب بیشتری در خدمت شما باشم.
در مطلب پیشین (لینک) اشاره کردم که ایدهها و جرقههای ابتدایی پروژه جبیر، از کجا به ذهنم رسید و چرا مهم بود که اون ایده رو پیاده کنم و حتما به اون هدف برسم. این موضوع، باعث شد که من بیش از پیش تلاش کنم که به هدفی که برای خودم گذاشتم برسم.
در این یکی مطلب، قصدم اینه که در مورد فرایندی که جبیر برای ساخته شدن طی کرد صحبت کنم و قطع به یقین، خیلی از این مراحل قدیمیتر از اونی هستند که شما بتونید الان پیادهسازیشون کنید. پس اگر نیازمند این هستید که توزیع لینوکسی مبتنی بر دبیان یا اوبونتو بسازید، میتونید راهنمای عملی قرار دادن فیل در یخچال و همچنین چگونگی ساخت توزیع لینوکس رو بخونید. ولی اگر دوست دارید سفر طولانی یک نوجوان در مسیر پیادهسازی رویاش رو بدونید، به خوندن همین مطلب ادامه بدید.
بررسی راههای ساخت یک سیستمعامل
ابتدای راه، باید بررسی میکردم که سایرین چطور سیستمعامل ساختند و چطور شده که سیستمهای عاملشون، رشد و نمو خوبی داشته. همونطور که در قسمت اول هم اشاره کردم، یکی از idol های من در زندگی، استیو جابز بود (و کماکان هم هست) و طبیعتا اولین سیستمعاملی که به نظرم اومد که داستان موفقیتش رو مطالعه کنم، مک بود. اما مک یک مشکل بزرگ داشت. بررسی درست و حسابیش نیازمند این بود که حتما یک سیستم اپل تهیه کنم. حالا چه آیمک، چه مکبوک و … . به همین خاطر، مک رو بیخیال شدم.
داستان موفقیت ویندوز هم تقریبا اظهر من الشمسه. این سیستمعامل عمده محبوبیتش رو به این خاطر داره که روی سیستمهای سازگار با PC های IBM نصب میشد و از قضا، همون دوره IBM تصمیم گرفته بود که لایسنس تولید کامپیوترهای شخصی مشابه کامپیوترهای خودش رو به کمپانیهای دیگری مثل Dell, Compaq, HP و … هم بفروشه. پس تعداد بیشتر، مصادف شده بود با مصرف بیشتر و محبوبیت بیشتر.
نهایتا، با خودم گفتم که «خب، میرم بین محبوبیت توزیعهای لینوکس جستجو میکنم». اونجا بود که فهمیدم چندین توزیع ایرانی مثل پارسیکس (متوقف شده)، کارآمد (متوقف شده) و آریوس (متوقف شده) وجود دارند. در عین حال، فهمیدم اینها ویژگیهای مشترک زیادی دارند. خلاصه که این مورد رو گذاشتم در لیست مطالعه که بعدتر در موردش مطالعه کنم و ببینم که دنیا دست کیه.
خلاصه، مطالعه پیرامون موفقیت سیستمهای عامل تموم شد. دلم میخواست اون موقع وارد جامعهای از برنامهنویسان بشم و ازشون یاد بگیرم و انتقال تجربه انجام بشه. به همین خاطر، در وبسایت برنامهنویس، ثبتنام کردم. اونجا بود که متوجه شدم یکی از اعضا، یک سیستم عامل نوشته به اسم آراکس. برخلاف عمده پروژههای سیستمعامل که دیده بودم، این یکی توزیع لینوکس نبود بلکه سیستمعاملی بود که از بیخ و بن توسعه داده شده بود و با خودم گفتم که پسر! باید با این رفیق شم حتما. اما خب نشد، یعنی نمیدونم چی شد ولی احتمالا شلوغی سر ایشون و عدم تمایلشون باعث این شد که دوستیای شکل نگیره.
خلاصه، کمی هم به زبان انگلیسی گشتم. اون موقع مثل الان زبانم خوب نبود و در فهم بسیاری از مطالب، مشکل داشتم. با این حال با گشتن در اینترنت به ویکی توسعهدهنگان سیستمعامل رسیدم. جایی که هزاران و دهها هزاران نفر دیگر، مشغول توسعه پروژههای خودشون بودند و همین باعث شده بود که من یک بهشت برین پیدا کنم. اما اونقدری نگذشت که امیدم ناامید شد. چرا؟ چند مدخل رو که خوندم فهمیدم از صفر نوشتن یک سیستمعامل که بتونه کلی کار ریز و درشت انجام بده به این سادگیها هم نیست. که البته اگر نظر خودم رو بخواهید، خیلی خوب شد که این اتفاق افتاد. بعدا در موردش حرف خواهم زد.
به همین خاطر، یک تحقیق بزرگی در مورد سیستمعاملهای متنباز موجود کردم که ببینم کدوم بعنوان پایه سیستمعامل میتونه گزینه خوبی باشه. گنو/لینوکس، بیاسدیها، هایکو و حتی کولیبری رو چک کردم و به این نتیجه رسیدم که خب، لینوکس بهترین گزینهست! حتی در این میان داشتم به اندروید هم فکر میکردم ولی باز پس ذهنم گنو/لینوکس رو داشتم. حالا وقت این بود که ببینم از کدوم یکی میشه یک نسخه شخصیسازیشده بهتر ساخت.
پیدا کردن توزیع مناسب به عنوان مبنا
خب وقتی که فهمیدم قراره بیس سیستمعامل من لینوکس باشه، نیاز داشتم که ببینم کدوم توزیع بهتره. به همین خاطر بارها و بارها، توزیع عوض کردم (و حتی همین امر موجب این شد که هاردم به شدت کند و حتی خراب بشه. بعد از مدتی حتی مجبور به تعویض هارددیسک لپتاپی شدم که اون زمان داشتم). نخستین توزیع، اوبونتو بود. بعدش دبیان. بعد اوپن سوزه، فدورا و … . به همین سبک و سیاق هزاران توزیع رو تست کردم که ببینم کدوم بهتره. البته دروغ چرا، هزاران خیلی مبالغهست. درستترش اینه که هر توزیعی که اسم و رسمی داشت رو نصب و آزمایش کردم که ببینم قضیه چی به چیه.
اما مشکلاتی هم در این میان بودند. یکی از بزرگترین مشکلات پیش روی من، اینترنتی بود که اون زمان داشتیم. اینترنت پرسرعتی بود نسبتا اما دو مشکل اساسی داشت. اولین مشکل محدودیت حجمی بود و خب طبیعتا میدونید که بسیاری از این توزیعها حتی موقعی که نصب میشن هم نیازمند اینترنت هستند و همین یعنی باید فاتحه اون حجم رو خوند. مورد دوم هم قطعیهای زیاد اون خط خاص بود. خلاصه که با تمام این ماجراها، من تهش به چند کاندیدای قدر قدرت رسیدم.
اولین کاندیدا، خود دبیان بود. اصل کاری، پدر اوبونتو. دبیان نصب و راهاندازیش هربار من رو پیر میکرد البته. به همین خاطر ترجیح دادم که مدتی کنارش بذارم. در همین میان، باز به اوبونتو برگشتم. بعد از بازگشتم به اوبونتو، با لینوکس مینت آشنا شدم. حقیقتا از مفهومی که مینت داشت هم خوشم اومد! فهمیدم که مطابق قوانین خیلی از کشورها، یک تعداد زیادی از نرمافزارها مثل فلشپلیر، فونتهای مایکروسافت، کدکها، واین و … امکان «بازتوزیع» یا Redistribute شدن ندارند. اما مینت از این قاعده مستثناء بود. چطور؟ مینت در ایرلند جنوبی ساخته شده. کشور ایرلند هم مثل روسیه و کشور ما، از کشورهاییه که کپیرایت درش به اون شکل مطرح نیست و شما احتمالا راحتتر میتونید این تیپ بازتوزیعها رو انجام بدید.
وقتی دیدم اینطوریه، با خودم گفتم چرا پایه این قضیه مینت نباشه؟ به همین خاطر مینت نصب کردم تا ببینم چی به چیه و دروغ چرا؟ عاشقش شدم. روی مینت گنوم ۳ نصب کردم و کلی باهاش کار کردم و دیدم عجب چیز خوبیه. خلاصه اینجا بود که کاندیداهای من به مینت و اوبونتو، تقلیل پیدا کردند.
پیدا کردن راهی برای پکیج کردن مجدد توزیع شخصیسازی شده
اینجا دیگه روی لپتاپ مینت نصب کرده بودم. شخصیسازیهای مختلفی رو روش انجام داده بودم و وقتش رسیده بود که یک پکیج ازش بسازم. در واقع میخواستم یک ISO بسازم که بتونم بعدا روی لپتاپ خودم یا کامپیوترهای دیگر به طور کل، نصبش کنم. به همین خاطر از Relinux استفاده کردم (این پروژه تقریبا دو سالی میشه که از رده خارج شده، ولی اون موقع جوان اول ابزارهای ساخت توزیع بود). حالا وقت این رسیده بود که یک مینت خوش رنگ و لعاب با هزاران هزار بسته رنگارنگ، به ISO تبدیل بشه و همین تبدیل همانا و سیستمعاملساز شدن من همان!
اما اینجا یه مشکلی پیش اومد. انقدر نرمافزارها زیاد بودند که حجم ISO تولیدی توسط Relinux بالای ۴ گیگابایت رفت. اگر این پست رو تشریف ببرید بخونید، توضیح دادم که استاندارد ISO9660 یک محدودیت روی حجم داره و بیش از چهار گیگابایت رو نمیتونه در خودش جای بده. همین امر، باعث شد که پروژه رو بکوبم و از اول بسازم. به همین خاطر، دوباره DVD اوبونتو 11.10 رو برداشتم (و در همون حین نخستین بتاهای ۱۲.۰۴ هم داشتند میومدند) و روی لپتاپ نصبش کردم. پس از نصب، تغییراتی روش دادم مثل جایگزینی یونیتی با گنوم، نصب تعدادی نرمافزار و جایگزینی تعداد دیگر. این بار شد! این بار واقعا شد و خب خوشحال و خرم بودم.
عکس از توزیع کاپریس است – کاپریس در سال ۹۹ ساخته شد.
انتشار نسخه اول به صورت LTS و اولین اشتباهات
خب در فروردین سال ۱۳۹۱، نخستین نسخه جبیر آمد. یادمه که ده روز قبل از انتشارش حتی این پست رو در فروم اوبونتو ایجاد کردم که خب همونطور که میتونید بخونید؛ کم هم حاشیه نداشته. خلاصه اینجا بود که اولین اشتباهات رو متوجه شدم. در این قسمت بیش از این که بخوام پیرامون این که جبیر چه بود مانور بدم، میخوام روی اشتباهات مانور بدم.
اولین اشتباه شاید برمیگشت به جهانبینی من. اینطور بخوام بگم که این جهانبینی این طور بود که اگر در ۱۶ سالگی یک سیستمعامل مثل جبیر ساختم، دیگه ته دنیای تکنولوژی و اینام. به قول یه بندهخدایی، دچار سندرم «جلوزدگی از خود» شده بودم. خب این مورد در سنین نوجوانی طبیعیه و حتی همین الان باور دارم که نسبت به سن و سال اون زمانم، واقعا کارم خفن بوده ولی نه اونقدری که خودم همیشه فکر میکردم. بهرحال در دوران نوجوانی خیلیها دوست دارند کارهای بزرگ کنن و همونطور که در مطلب پیشین عرض کردم، این قضیه باعث شد من بشم اینی که الان هستم.
خلاصه این اشتباه، اشتباه اول بود. اشتباه دوم این بود که فکر میکردم اینجا میتونم سبک و سیاق اپل رو پیش بگیرم. یعنی چی؟ یعنی که یک سیستمعامل مبتنی بر یک سیستمعامل دیگر بسازم و بعدش، کدش رو ببندم و نهایتا سختافزارهای مبتنی بر اون سیستمعامل رو به ملت بفروشم. نه روی زیرساخت فکری داشتم، نه روی این که پروانهها چه اجازههایی میدند. خلاصه که اینجا کلی اشتباه پشت هم دیدیم. اما تلاش کردم این موارد رو در نسخه ۲ اصلاح کنم.
نسخه ۲، رابط کاربری افسانهای
توزیع آریوس، علاوه بر این که ریمستر از اوبونتو بود دو ویژگی داشت که از سایر توزیعهای ریمستر؛ متمایزش میکرد. یکیش نصاب آفلاین درایورها بود، دیگری این که یک رابط کاربری خیلی خوشگلی هم داشت که خب به شکل یک نشست روی گنوم اجرا میشد. در نسخه دوم تصمیم گرفتم چنین تغییری رو ارائه بدم. به همین خاطر، با کمک AWN, Mutter و یک سری تغییر ریز دیگر، یک رابط کاربری نسبتا کاستوم ساختم و اسمش هم گذاشتم Legendary UI یا «رابط کاربری افسانهای». همچنین در کنار اون نسخه، یک ایزو با XFCE هم ارائه کردم که خب در این مقطع، جبیر با دو میز کار داشت عرضه میشد.
حقیقتا نسخه ۲ تا حد خوبی ترکوند. به حدی که با این پروژه به جشنوارههای استانی و کشوری (منجمله خوارزمی) راه پیدا کرده بودم. این رو هم اینجا بگم چرا که واقعا نمیتونم این رفرنس رو اینجا ندم 😁 در فیلم The Social Network – که داستان ساخت و رشد فیسبوک رو به شکل سینمایی روایت میکنه – کرکتر Divya Narendra (یکی از شرکای دوقلوهای وینکلواس در پروژه Harvard Connection) در مورد مارک زاکربرگ میگه که «مارک بزرگترین شخصیت دانشگاه شده بود. اون هم دانشگاهی که نوزدهتا برنده نول و پونزدهتا برنده پولتیزر و حتی یک ستاره سینمایی داره». حقیقتا در میان دانشآموزان اون مدرسه و حتی شهر بندرعباس من چنین حسی داشتم و همینجا بود که دوباره کمی از خودم جلو زدم. اما این تمام ماجرا نبود. جزییات این بخش رو، در قسمتهای بعدی این داستان خواهیم خوند.
نسخه ۳ و ۴، مشکل اینترنت و متاع خنده؟
در نسخه ۳، تغییر خاصی نبود جز این که قبل از این که Ubuntu GNOME Remix منتشر بشه، این توزیع با میزکار گنوم عرضه شد (حقیقتا جا داشت این مورد شدیدا بهش اشاره بشه). اگر دوست دارید در مورد این نسخه بیشتر بدونید میتونید به این مصاحبه من با لینوکس سیزن مراجعه کنید و کمی با ذهنیت من در اون سال آشنا شید. نسخه ۳ خیلی حاشیه نداشت. در عین حال، خیلی هم سر و صدا و برند نساخت. یک توزیعی بود که نصب میشد و خلقالله استفاده میکردند.
نسخه ۴، برای من خیلی مهم بود. در این حد که حتی اسم نسخهش هم خواستم یک چیز باحال انتخاب کنم و از همین رو، اسم رو گذاشتم Pirates of Galaxy یا «غارتگران کهکشان». در این یکی نسخه خیلی سعی داشتم که همهچی رو مینیمال در عین حال شخصی نگه دارم. اما یک مشکل اساسی اینجا پیش آمد. مشکل چی بود؟ مشکل این که اوبونتو باگی داشت که اگر شما اون رو باز دوباره بستهبندی میکردی، نمیتونست کارت شبکه رو درست شناسایی کنه و به اینترنت متصل نمیشد. همین موضوع باعث این کامنت از جادی شد:
خب بخش اول کامنت تذکری بود به دوستی که ظاهرا ادب رو رعایت نکرده بود. بخش دوم هم از نظر من بد نیست، اما نکته مهم برخورد جامعه نرمافزار آزاد با این موضوع بود. چرا؟ چون من یادمه حتی سال ۹۶ که خودمم یادم نبود چه کرده بودم تو این سیستمعامل، در بعضی جلسات لاگ و بعضی رویدادها این موضوع شده بود متاع خنده! طبیعتا هیچکس خوشش نمیاد کاری که در نوجوانی کرده و حتی کار بدی هم نبوده (ساخت توزیع لینوکس واقعا کار بدی نیست، شاید بیهوده باشه ولی بد، نه!) سوژه خنده یک جمع باشه.
خلاصه اینجا دیگه شد آخرین جایی که جبیر بعنوان یک توزیع گنو/لینوکس عرضه شد و دفترش به پایان آمد. اما حکایتش همچنان باقی ماند.
رفتن سراغ BSD
بعد از جبیر ۴، دیگه تصمیم رو جدی گرفتم. با خودم گفتم لینوکس برای من سیستم بشو نیست :)) در این حد که هرجا بحثی از لینوکس میشد، سریعا اشاره میکردم به این که در PlayStation 4 از FreeBSD استفاده شده، واتسپ داره FreeBSD استفاده میکنه و OpenBSD ایمنترین سیستمعامل جهانه و اپل با BSD اپل شد و اینها و در عین حال لگدی هم به لینوکس میزدم و میگفتم این سیستمعامل، یک سیستمعامل مردهست.
در همین حین، ما باز به تهران برگشتیم و خب کمی سخت بود که روی توسعه جبیر کار کنم چرا که اینترنت درست و درمونی نداشتم، لپتاپم برای کامپایل کردن کدهای FreeBSD ضعیف بود و کلی داستان و مشکل از این قبیل پیش آمد. خلاصه پس از این که مدتی گذشت و کمی این مشکلات حل شد، موفق شدم که جبیر رو دوباره از نو با کرنل FreeBSD تولید کنم و بعد مدتی حتی اسم کرنل رو از FreeBSD به JabirOS تغییر دادم (که خب این خودش یک اشتباه خیلی خیلی بزرگ محسوب میشد چون عملا از پورتها نمیشد دیگه استفاده کرد) و کلا در مسیری بودم که با خودم میگفتم «دو سال دیگه به اپل رسیدم».
یکی از دلایلش، این بود که من کم کم داشتم وارد مدیای خارجی میشدم. مثلا این وبسایت، خبر انتشار جبیر جدید رو کار کرد یا این یکی، با من مصاحبهای ترتیب داد. همه این موارد دست به دست هم دادند تا من خیلی بیشتر از پیش، از خودم جلو بیفتم.
اما خب این موضوعات پشت سر هم، پیشدانشگاهی و کنکور و ورود به دانشگاه باعث شدند که کلا بیخیال پروژه جبیر بشم و این مورد باعث شد که ذهنم برای پروژههای دیگری که در این سالها انجام دادم بازتر بشه.
این داستان ادامه دارد
فکر میکردم شاید این داستان چهار یا پنج قسمت بشه، اما تا اینجا که توضیحاتم رو ارائه کردم، فکر کنم کلا یک مطلب دیگر که کلیت این دو قسمت رو جمعبندی کنه و کمی به رفتارهای اطرافیان – بخصوص جامعه نرمافزار آزاد – و داستانهایی مشابه شرکت در جشنواره خوارزمی و … اشاره کنه، کافی باشه.
خلاصه، دوست دارم ازتون تشکر کنم که تا اینجای مطلب رو خوندید و همراه من بودید. من همیشه دوست داشتم این تجربه رو مکتوب کنم و خب اتفاقات اخیر، موجب این شد که این مطالب مکتوب بشند و در وبلاگ هم به رشته تحریر دربیان.
در نهایت، برای تکتک خوانندگان این بلاگ، آرزوی موفقیت و خوشحالی میکنم.
احتمالا اگر وبلاگ یا محتوایی که من تولید میکنم رو دنبال کرده باشید، با مفاهیم و اسامی خاصی من رو به یاد خواهید آورد. چه مثل چند ماه اخیر با پروژههای بینایی ماشین ، چه روبی و ریلز که چندین ساله کم کم با اون شناخته میشم، چه لینوکس و سختافزار و این داستانها. احتمالا هم اگر از دنبالکنندگان این وبلاگ باشید، میدونید که داستان برنامهنویس شدن من (قسمت اول، قسمت دوم) چیه و چطور شد که من شدم اینی که هستم.
اما قطع به یقین، خیلی از دوستان قدیمیتر من رو با «پروژه جبیر» یا «جبیر او اس» یا «سیستمعامل جبیر» میشناسند. پروژهای که من رو با جدیت وارد دنیای توسعه نرمافزار، نرمافزار آزاد و جامعه کاربری گنو/لینوکس ایران کرد. در این پست، قصد دارم تا در مورد پروژه جبیر کمی بنویسم. در واقع، قصد من اینه که داستان این پروژه رو تعریف کنم و بگم که چی شد که اینطوری شد 🙂
چرا این مطلب نوشته شد؟
حقیقتا از سال ۹۴ به بعد که دیگه وبسایت پروژه جبیر آپدیت نشد و حتی از برند جبیر برای پروژهای استفاده نشد، دلم نخواست که راجع بهش چیزی بنویسم. چرا که این پروژه علیرغم تمام خوبیها و آموزههاش برای من، خاطرات بدی هم داشت و خب هرچیزی، لازمه که روزی کنار گذاشته بشه. در حقیقت، جایی که انسان حس میکنه باید رها کنه، باید رها کنه و برای من این زمان سال ۹۴ بود. زمانی که همهجا اعلام کردم پروژه جبیر، چه در قالب «توزیع لینوکس» و چه در قالب «نسخهای از BSD» دیگر عرضه نخواهد شد.
اما چندی پیش، پای یکی از پستهای جبیر (لینک) نظری دریافت کردم (که البته تایید نشده) و در بخش آمار وبگاه (که به کمک افزونه Jet Pack بررسی میکنم) هم متوجه شدم که افرادی هستند که در حال رصد کردن گذشته من هستند. یکی از چیزهایی که عمیقا بهش باور دارم اینه که نباید در گذشته افراد زیاد کند و کاو کرد، چرا که تهش شما یا خودت ضایع میشی یا چیزی که دنبالش میگردی چیزی در حد زیربغل مار خواهد بود. پس با این حساب، تصمیم گرفتم که در یک سلسله مطلب جامع، داستان جبیر او اس رو جمع کنم.
حالا وقت اینه که حدودا ده سال در زمان سفر کنم و برسیم به سال ۸۹-۹۰ که این پروژه رو استارت زدم، بگم چی شد که این پروژه به ذهنم رسید و چطور شد که رفتم سمت لینوکس و … .
جرقههای اولیه
بسیاری از افرادی که من رو میشناسند، از ارادتی که نسبت به استیو جابز دارم، خبر دارند. سال حدود ۸۹ بود و من در مجلاتی که اون زمان به صورت روتین از قیمت فلان گوشی و فلان کامپیوتر و فلان کارت گرافیک مینوشتند از رونمایی از محصولات جدید اپل مثل iPhone 4 یا iPad میخوندم. بعد مدتی، با استیو جابز و زندگی اون آشنا شدم و فهمیدم که این بابا، آدمی بوده که خیلی خیلی از صفر شروع کرده (تقریبا بر خلاف خیلی از ابرپولدارهای سیلیکونولی، ایشون اصلا خونواده متمول و حتی اهل فنی نداشته و خونوادهای که درش رشد کرده بوده یک خونواده خیلی معمولی بوده).
خلاصه آشنایی با استیو جابز، بعدش خریدن یک iPod Touch 3G در من جرقهای روشن کرد. جرقهای مبنی بر این که «من باید دنیا را تغییر بدم». تغییر دنیا، کار سختیه. خیلی از ما جایی از زندگی این قصد رو داشتیم ولی کار خاصی براش نکردیم. خیلیها هم حرکتایی زدیم ولی بعدا سرمون به سنگ خورده. خلاصه که خیلیامون اونقدری دیوانه بودیم که روزی بخوایم دنیا رو تغییر بدیم و به قول استیو جابز، افرادی که اونقدر دیوانن که فکر میکنن میتونن دنیا رو تغییر بدن، دقیقا همونایین که دنیا رو تغییر میدن.
در همون سالها بود که ما مهاجرتی از تهران به بندرعباس داشتیم و خب حقیقتا این مهاجرت و دوری از فضای تهران – بویژه محلهای که درش بزرگ شده بودم و طبیعتا بسیاری از همکلاسیهای دبیرستانم هم قرار بود همون بچههای راهنمایی و دبستان باشند – باعث شده بود کمی ناامید و افسرده باشم. تمام این دلایل دست به دست هم دادند که من تصمیم بگیرم که بخوام استیو جابز دوم باشم (شاید اشتباه همین بود، هوم؟).
خلاصه شبانهروز در حال ایدهپردازی بودم. اما ایدهها همین جا متوقف نشدند. ایدهها خیلی بیش از اون چه که فکر کنید پیش رفتند در ذهنم. اما نیاز داشتم یک محرک خیلی اولیه داشته باشم. نمیدونستم چه محرکی ولی بهرحال یک محرک نیاز بود.
من باید سیستمعامل بسازم
بالاخره پیداش کردم. محرکی که لازم داشتم تا باهاش دنیا رو تغییر بدم، پیدا کرده بودم. شاید باورتون نشه ولی به معنای واقعی در نقطه نقطه بدنم شور و شوق رو حس میکردم و برای انجام این کار، انگیزه بسیار بسیار زیادی داشتم. حالا که این انگیزه بود، سوال اینجاست که چرا نه؟ اما قبل از هرچیزی بهتره ببینیم که این انگیزه چی بود.
نمیدونم شما چقدر با نشریات قدیمی آشنایید ولی نشریه مورد علاقه من، یا بهتر بگم یکی از نشریات مورد علاقه من، مجله دانشمند بود. مجله دانشمند مطالب علمی و فنی جالبی داشت. در اون میشد از ژنتیک و زیستشناسی تا هوش مصنوعی و … رو خوند و یاد گرفت و لذت برد. در بسیاری از شمارههاش، کارهای عملی رو توضیح میداد که شما میتونستید در خانه انجام بدید و … . خلاصه کلام که یکی از بهترین نشریاتی بود که میخوندم.
در تابستان ۸۹ یا ۹۰ بود که درست یادم نیست؛ در یکی از شمارههای دانشمند کتاب «سیستمهای عامل: طراحی و پیادهسازی» اثر «اندرو استوارت تنن باوم» معرفی شده بود. به صورت خلاصه بگم، در این مطلب اومده بود که انگیزه تننباوم از نوشتن این کتاب چی بوده و چه فرایندی (بسته شدن کد منبع یونیکس نسخه ۷) باعث شد که سیستمعامل خودش رو از بیخ بنویسه و بعد از اون، شروع کنه به این که مراحل توسعه رو مستند کنه و در قالب یک کتاب برای دانشجویانش و همچنین علاقمندان عرضهش کنه.
اما این کل ماجرا نبود. آخر این مطلب اشاره شده بود که این کتاب و این سیستمعامل (مینیکس) باعث شدند که دانشجوی فنلاندی بیاعصاب، یعنی لینوس تروالدز؛ برای این که بتونه با مینیکس درست و حسابی کار کنه و گروههای گفتوگو رو بخونه و … یه سری ابزار توسعه بده و در همین حین یک هسته هم از بیخ و بن بنویسه. در ادامه توضیح داده شد که لینوس تروالدز یک باره هاردش رو نابود کرد (و خب شاید این نابودی یکباره هارددیسک که در میان لینوکسیها شایعه، از همین قضیه نشات بگیره 😂) و این نابودی باعث شد که سیستمعامل خودش – که ملغمهای از ابزارهای پروژه گنو و کرنلش بود – رو روی دستگاهش نصب کنه.
در ادامه کمی به تاریخچه لینوکس و دعواهای روتین تروالدز با بقیه اشاره کرده بود. این بخش کاملا من رو شیر کرد. من این بند رو که خوندم (و دقیقا یادمه که داخل یک خودرو هم بودیم که من این مطلب رو خوندم) با صدای بلند گفتم که «من باید سیستم عامل بسازم» طوری که خونواده هم نگاهشون به سمتم برگشت. خلاصه که این شد که من تصمیم گرفتم که اولین پروژه خیلی جدی زندگیم، یک سیستم عامل دسکتاپ باشه.
نخستین مطالعات، نخستین پیادهسازیها
خب من بعد از خوندن اون مطالب یادمه که کتابی به اسم «کلید لینوکس» که آموزشش بر مبنای «اوبونتو ۱۰.۰۴» بود رو خوندم و خیلی چیزا ازش یاد گرفتم. در عین حال، روی یک ماشین مجازی اوبونتو نصب کردم و کمی از آموزشهایی که از لینوکس دیده بودم بهره بردم که ببینم چه خبره و دنیاش دست کیه. بعد از اون خلاصه اینطور شد که یک روز تصمیم گرفتم اوبونتو ۱۱.۰۴ (یا دقیق یادم نیست، ۱۱.۱۰) رو روی لپتاپم نصب کنم و حین نصب کل دیتام هم پرید.
بعد از این نصب، شروع به این کردم که یاد بگیرم که چطور میتونم شخصیسازی کنم و تا حد خوبی هم موفق بودم. اما هنوز کلی علامت سوال در ذهنم بود. به همین خاطر، کاری که کردم این بود که وارد فروم اوبونتو شدم و این سوالات رو پرسیدم. اینگونه بود که ماجرای عریض و طویل جبیر، آغاز شد …
این داستان ادامه دارد …
تا همین الان، این مطلب شدیدا طولانی شده. به همین خاطر این مطلب رو اینجا قطع میکنم و اجازه میدم که شما حدس بزنید باقی ماجرا چی شد. البته دروغ چرا، باقی ماجرا رو خیلی زود (شاید حتی فردا شب) در وبلاگ منتشر میکنم و منتظر بازخوردهای شما میمونم.
امیدوارم که این مطالب، اطلاعات خوبی به شما از روند یک پروژه اوپن سورس که از قضا در جاهای مختلفی به شدت اشتباه زده؛ بده و براتون مفید واقع بشه. از این که وقت گذاشتید و این مطلب رو خوندید، ممنونم.
وبلاگ شخصی محمدرضا حقیری، برنامهنویس، گیک و یک شخص خوشحال