اگر تا حالا برای کمک گرفتن راجع به پارچ لینوکس سوال پرسیدی و جامعه‌اش رو "غیردوستانه" و "غیرمفید" دیدی که فقط بهت می‌گن "راهنما رو بخون"، شاید این مقاله برات مفید باشه.
پس از دیدن اسکرین‌شات‌های جالب داخل تلگرام یا به توصیه دوستان، علاقه‌مند به پارچ شدی؟ خوش اومدی! پارچ توزیع مناسبی واسه کنترل کامل روی سیستمت و شخصی‌سازیش درست طبق نیازت هست.
اولین باره که لینوکس استفاده می‌کنی؟ اگه آره، توزیع فوق‌العاده‌ای انتخاب کردی که بهت کمک می‌کنه پایه قوی از دانش و تجربه بسازی. خودم هم همین‌طوری شروع کردم.
اگه قبلاً لینوکس استفاده کردی، اوبونتو یا مشتق‌هاش بوده؟ اگه آره، آماده باش که از اول یاد بگیری کامپیوتر تو محیط لینوکس چطور کار می‌کنه.
ولی قبل از اینکه شروع کنی سیستمت رو شخصی‌سازی کنی، چند تا چیز هست که باید بدونی.
درحالی‌که خیلی از توزیع‌های گنو/لینوکس سعی می‌کنن "کاربرپسند" باشن، پارچ لینوکس همیشه "کاربرمحور" بوده و باقی هم خواهد موند. این توزیع نه صرفاً برای جذب بیشترین تعداد کاربر، بلکه برای پاسخ‌گویی به نیازهای جامعه‌ای ساخته شده که در شکل‌گیری و توسعه‌اش مشارکت می‌کنن.
پارچ یه پروژه اجتماعیه که وجودش مرهون نگهدارندگان بسته‌ها، کادر پشتیبانی و بقیه کسانی که تو پروژه مشارکت می‌کنن هست.
توسعه‌دهندگان پارچ داوطلب هستن و مشارکت‌کنندگان فعال اغلب خودشون عضو این تیم می‌شن. کاربران پارچ می‌تونن آزادانه بسته‌هایی رو به مخزن کاربری پارچ اضافه کنن، مستندات ویکی پارچ رو بهبود بدن، کمک فنی به دیگران ارائه بدن یا صرفاً نظراتشون رو تو انجمن‌ها یا اتاق‌های ماتریکس مبادله کنن.
اگه شرکت تو چنین جامعه‌ای و پذیرش اصول پارچ لینوکس چیزی هست که بهش علاقه‌ای، پس پارچ توزیع درستی واست هست. وگرنه تعجب نکن اگه اعضای جامعه باعث بشن احساس ناخوشایندی داشته باشی.
فعالانه سعی کن از خودت بدی و فقط فایده برای همکاران و جامعه‌ات به همراه داشته باشی.
حتماً قبل از تعامل با جامعه، آیین‌نامه‌مون رو چک کن.
اگه وقتی کمک خواستی بهت گفتن "راهنما رو بخون"، لزوماً به این دلیل نیست که اون شخص نمی‌خواسته بهت کمک کنه، بلکه چون ویکی فوق‌العاده‌ای داریم و راهنماهای خوب نگهداری‌شده.
درست مثل خود پارچ، بیشتر اکوسیستم لینوکس روی نرم‌افزارهای متن‌باز بنا شده، مخصوصاً خود کرنل لینوکس. و بیشتر این نرم‌افزارها توسط داوطلب‌ها نگهداری می‌شه. چون این داوطلب‌ها این کار رو تو وقت آزادشون انجام می‌دن، انتخاب روش مستندسازی باید با این محدودیت‌ها در نظر گرفته بشه.
مستندات متنی راحت نوشته می‌شه و راحت به‌روزرسانی می‌شه. در حالت ایده‌آل باید ویدئوهای آموزشی و پست‌های وبلاگی مفصل با اسکرین‌شات برای هر ابزار تو مخازن اصلی داشته باشیم. ولی سخت نیست که ببینی چطور این کار برای توسعه‌دهندگان غیرممکن خواهد بود.
وقتی خوندن کل راهنما زیاده، از ابزار tldr استفاده کن. مثال‌های سریع در مورد نحوه استفاده از ابزار موردنظرت بهت می‌ده.
استفاده از مستندات متنی همچنین بهمون اجازه می‌ده اطلاعاتمون رو متمرکز کنیم. دادن کمک شخصی‌سازی‌شده به همه، وقتی بیشتر مشکلاتی که کاربران با یه ابزار خاص دارن معمولاً خیلی شبیه هم هست، استفاده خیلی ناکارآمدی از وقتمون خواهد بود. به جاش، مستنداتمون رو با اطلاعات مربوط به اون مسائل به‌روز نگه می‌داریم.
اگه یه روز در حین عیب‌یابی یه مسئله دیدی چیزی تو مستندات ابزار کم هست، شهروند خوبی باش و سعی کن بهبودش بدی. تغییری باش که می‌خوای تو دنیا ببینی.
پس نسبت به وقت دیگران احترام بذار و وقتی کمک می‌خوای راهنماها رو بخون. خون‌آشام کمک نباش.
اگه بعد از اون هنوز نمی‌دونی مسئله‌ات رو چطور حل کنی، قسمت بعدی بهت کمک خواهد کرد.
پس با یه برنامه خرابی تو سیستمت مواجه شدی؛ تبریک می‌گم، یه قدم به تبدیل‌شدن به یه کاربر کامل پارچ نزدیک‌تر شدی!
اینجا طرز حل مشکلت به روش پارچ رو داریم:
ابتدا از خودت بپرس: این برنامه گرافیکیه یا ترمینالی؟
اگه گرافیکیه، برنامه رو از ترمینالت اجرا کن. همه برنامه‌های لینوکس، حتی گرافیکی‌ها، جریان خروجی و خطای استاندارد دارن. یعنی اگه اون برنامه رو از ترمینال اجرا کنی، دسترسی به اطلاعات خیلی بیشتری نسبت به اجرای معمولیش از لانچر برنامه‌ها خواهی داشت.
انجام این کار منجر به اطلاعات مفیدی شد؟
اگه آره، دقیقاً همون‌طور که روی صفحه چاپ شده بودن، خطاها و هشدارها رو جستجو کن. اگه نتایج مفیدی پیدا نکردی، جستجوت رو با حذف رفرنس‌هایی که مخصوص دستگاهت هست از اون خطاها گسترده‌تر کن؛ این شامل مسیرهای مطلق، شناسه پروسه‌ها، زمان‌ها و کلی چیزهای دیگه که راحت تشخیص می‌دی می‌شه. جستجوت رو با حذف جزئیات ادامه بده تا چیزی پیدا کنی که بتونه بهت کمک کنه.
اگه اطلاعات مفیدی چاپ نشد، وقتشه راهنما رو بخونی. مخصوصاً دنبال دو کلمه خاص می‌گردیم: debug و verbose. به‌طور کلی می‌تونی فرض کنی که -v مخفف verbosity هست و تکرارهای متعدد -v، مثل -vvv، یا -v -v -v سطوح بالاتر verbosity خواهند بود. هرچی verbosity بالاتر، اطلاعات بیشتری خروجی خواهد شد.
ولی گاهی -v مترادف --version هست. پرچم -d معنی‌های مختلفی داره، مثل daemonize (اجرای برنامه در پس‌زمینه، تقریباً مثل اضافه‌کردن & به انتهای فرمان)، debug، یا حتی detach (تو tmux، -d پرچم رایجی برای شروع یه پنجره یا نشست بدون فوکوس فوری روش هست). پس برای سادگی، فقط man page رو چک کن. بعد از اون، سعی کن به روشی که بحثش رو کردیم آنلاین جستجو کنی.
هنوز گیر کردی؟
ترفند دیگه‌ای که می‌تونه بهت کمک کنه اینه که علائمی رو که داری تجربه می‌کنی و اسم برنامه رو "در گیومه" جستجو کنی، مثلاً "myapp" crash when opening text file. این کار باعث می‌شه موتور جستجوت نتایج رو فیلتر کنه که فقط اونایی رو نشون بده که شامل کلمه دقیق بین گیومه‌ها هست. از ابزارهای موتور جستجوت استفاده کن، مثل فیلتر کردن بر اساس زمان، و شاید "archlinux" یا برند GPU یا هر سخت‌افزار غیرمعمول دیگه‌ای که داری و ممکنه مرتبط باشه رو اضافه کن.
هنوز هیچ راه حلی نیست؟
حالا از خودت بپرس: این مشکل تازگی شروع شده؟ مشخص‌تر، بعد از یه به‌روزرسانی بسته/نرم‌افزار/سیستم شروع شده؟
فعلاً شروع به downgrade کردن بسته‌ها نکن!
ابتدا لاگ pacman رو با یه pager باز کن:
less /var/log/pacman.log
بعد G (حرف بزرگ g) رو بزن. بهت انتهای لاگ رو می‌ده. از j و k برای حرکت پایین و بالا استفاده کن. از / یا ? برای جستجوی یه عبارت به جلو یا عقب استفاده کن. ببین چه بسته‌هایی اخیراً ارتقا پیدا کردن و رابطه‌شون با مشکلی که داری رو تعیین کن. بعد و فقط بعد اوکیه که سعی کنی downgrade کنی.
این نوع ناوبری رو vim-motions می‌گن. زیاد توی ابزارهای رایج لینوکس می‌بینیش. از یه ادیتور فوق‌العاده می‌آد که خیلی از کاربران پارچ ازش استفاده می‌کنن: vim (و جانشینش، neovim).
برای downgrade کردن یه بسته استفاده کن:
pacman -U /var/cache/pacman/pkg/{package}-{version}.{architecture}.pkg.tar.xz
که در اینجا:
از auto complete ترمینالت برای پیدا کردن بسته‌ای که می‌خوای استفاده کن یا cd و ls کن تو اون دایرکتوری تا پیداش کنی.
اگه downgrade کردن بسته مشکل رو حل کرد، حتماً تو bugs.archlinux.org گزارشش کن.
اگه مسئله هنوز هست، و معقولاً مطمئنی که بعد از به‌روزرسانی ایجاد شده، می‌تونی سعی کنی کتابخانه‌ها یا وابستگی‌های دیگه برنامه موردنظر رو downgrade کنی و مشکل رو دقیق‌تر مشخص کنی. ولی انجام این کار اغلب تو رو وارد یه سوراخ خرگوش می‌کنه که به dependency hell ختم می‌شه.
pacman اغلب اطلاعاتی راجع به بسته‌هایی که به‌روزرسانی می‌کنی می‌ده اگه مداخله دستی مطلوب یا لازم باشه. این باید تو لاگ pacman هم باشه، ولی اگه نیست می‌تونی تابع post_install() از اسکریپت $pkg.install رو چک کنی (راحت‌ترین راه پیدا کردنش استفاده از abs هست). یا می‌تونی دوباره بسته رو نصب کنی و pacman قشنگ توی کنسولت چاپش می‌کنه. تأیید کن که قدم‌های لازم توضیح‌داده‌شده اونجا رو برداشتی.
قدم بعدی چک کردن پیکربندی‌هاته. تازگی تنظیمی عوض کردی؟ برگردونشون و ببین مشکل هنوز هست یا نه. بعد pacnewهات رو مرتب کن و دوباره برنامه رو امتحان کن.
اگه همه عیب‌یابی رو انجام دادی و هنوز راه حل پیدا نکردی، وقتشه کمک بخوای.
ولی چون این راهنما رو دنبال کردی، حالا همه اطلاعات لازم برای دنبال کردن آداب اولیه گزارش مشکل رو داری.
علائم، لاگ‌ها، سخت‌افزار، و هرچیزی که در حین عیب‌یابی کشف کردی یا مظنونشی راجع به مشکلت رو پست کن. اگه می‌خوای کسی که می‌دونه مشکلت رو چطور حل کنه وقت صرف کمک به تو کنه، تا جایی که ممکنه براش راحت کن.
جاهای خوب برای درخواست کمک:
این راهنما به‌عنوان نقطه شروع با جهت‌گیری‌های کلی در نظر گرفته شده. برای اطلاعات مشخص‌تر، اول به صفحه عیب‌یابی کلی سر بزن و صفحه مخصوص ابزاری که باهاش مشکل داری. نگاه کردن به issue ها تو مخزن برنامه هم می‌تونه بهت کمک کنه اطلاعاتی راجع به باگ‌های شناخته‌شده کنونی پیدا کنی.
خلاصه:
قدم اول: man + cat + less + grep + find رو یاد بگیر
تا جایی که مهارتت اجازه می‌ده خودت عیب‌یابی کن.
قدم دوم: config ها + لاگ‌ها + خروجی برنامه مربوطه رو چک کن
قدم سوم: از man + ویکی پارچ + گوگل + اخبار پارچ + انجمن‌های پارچ استفاده کن
درخواست کمک:
قدم چهارم: قسمت‌های مربوطه از قدم دوم رو paste کن
راه راحت برای pastebin کردن خروجی از خط فرمان pipe کردن خروجیت از طریق curl به 0x0.st هست: command | curl -F 'file=@-' 0x0.st
قدم پنجم: مشکل + مراحل تکرار + عیب‌یابی + لینک‌های قدم چهارم رو بیان کن
از "می‌تونم سوال بپرسم" نپرس.
قدم ششم: اگه پاسخ‌ها "man" یا "گوگل" هست، قدم‌های یک تا پنج رو تکرار کن
بعد از خوندن همه اینها (امیدواریم)، شاید فکر کنی "آیا همه اینها واقعاً لازمه؟". جواب آره هست.
اگه خوندن لاگ‌ها، جستجو کردن و یادگیری نحوه کارکرد (و نکردن) ابزارهات چیزی نیست که بهش علاقه داشته باشی، پس پارچ لینوکس توزیع درستی واست نیست. پس تعجب نکن اگه کسی باهات خوش‌برخورد نکنه.
یا شاید درست واست هست، ولی ممکنه نیاز داشته باشی اول اعتماد بیشتری کسب کنی. اول از توزیع کاربرپسندتری استفاده کن، با ترمینال راحت شو، و با چیزی که باهاش راحت هستی ور برو. بعد یه روز، وقتی احساس ماجراجویی بیشتری کردی، دوباره پارچ رو امتحان کن. و شاید هنوز واست مناسب نباشه، که اشکالی نداره. پارچ در مورد استفاده از کامپیوترت به روشی که برات مناسبه، و شاید پارچ برات مناسب نباشه.
همون‌طور که The Primeagen می‌گه:
نگهبانی ذاتاً اشتباه نیست، فقط باید دروازه‌های خوبی برای نگهداری داشته باشی.
خیلی از آدم‌ها رو دیدم که از اینکه کاربران پارچ غیرمفید و غیردوستانه هستن شکایت می‌کنن، و، با چند استثنای نادر، تجربه من تا الان کاملاً برعکس بوده. چون از روز اول سعی کردم تا جایی که مهارتم اجازه می‌داد خودم چیزها رو عیب‌یابی کنم و وقتی سوال می‌پرسیدم اطلاعاتی که جمع‌آوری کرده بودم رو ارائه بدم، هربار که کمک لازم داشتم، کاربران دیگه واقعاً مفید بودن.
با گذشت زمان متوجه می‌شی که انجام کارها به این روش واقعاً خیلی سریع‌تره. اگه مسئله‌ای تو سیستمم داشته باشم، نمی‌خوام مجبور باشم یه جایی برم بپرسم؛ منتظر بمونم تا کسی جواب بده؛ با اون‌ها رفت و برگشت کنم در حین عیب‌یابی و بعد بتونم مسئله‌م رو حل کنم. اگه کاری برای انجام دارم و ابزاری طبق انتظار کار نمی‌کنه، می‌خوام سریع مستندات رو بخونم، چیزی که می‌خوام رو پیدا کنم، درستش کنم، و ادامه روزم رو بدم. وقتی تجربه پیدا می‌کنی و می‌دونی دنبال چی بگردی، این روش خیلی راحت‌تر و سریع‌تر از درخواست کمک هست.
بعد از دنبال کردن این راهنما و حل اولین مشکلت، با یا بدون کمک، کاربر کامل پارچی، btw. یه مدیر پنجره tiling نصب کن، والپیپرت رو یه دختر انیمه‌ای قرار بده، neovim رو پیکربندی کن و چند تا اسکرین‌شات جالب آنلاین پست کن.
اگه این راهنما مفید و/یا آموزنده بود، به بقیه پیشنهادش کن.
اگه فکر می‌کنی چیزی کم هست که می‌تونه به مبتدی کمک کنه یا ویرایشی که این مقاله رو بهتر کنه، به جامعه پارچ درخواست بهبودش رو ارسال کن.
ممنون از خوندن!