فلسفه یونیکس و systemd!

انگیزه اصلی نوشتن من، ادعای مشهوریه که در مورد systemd میشه اونم این که systemd بده چون با فلسفه یونیکس سازگار نیست. گاهی هم این موضوع به صورت‌های دیگه‌ای بیان میشه مثل این که systemd بزرگه یا این که تو هر موضوعی دخالت کرده و ... که همه تقریبا دارن یک چیز رو بیان می‌کنن. اما حداقل یک عده، تصور درستی از چیزی که بیان می‌کنند ندارند. برای همین بد ندیدم چیزهایی رو بگم که لااقل اگه کسی مخالف هم هست، بهتر مخالف باشه! ولی قبل از شروع یه خلاصه‌ای از کلیات چیزی که می‌خوام میگذارم که از قضاوت عجولانه شاید تا حدی جلوگیری کنه. البته بسته به شرایط شاید صحبت‌ها گسترده‌تر هم شد. اما اساس حرف‌های من:
۱. «فلسفه یونیکس» چیز خوبیه؟
۲. اصلا چی هست؟ و گفتن این که برنامه‌ای رعایتش می‌کنه یا نه راحته؟
۳. آیا systemd خلاف این فلسفه ست؟ و اگه هست، چیز بدیه؟ یا اگه نیست چرا نیست؟

مورد ۳ می‌تونه خلاصه یا مفصل باشه؛ ببینیم اوضاع چطور پیش میره! شاید یکمی بیشتر پروژه systemd رو باز کردیم و در موردش نوشتم.

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

پس من بدون سند حرف می‌زنم، کسی خواست رو حرفم حرف بزنه سند بیاره ؛) به نظر خودم که عادلانه‌ست!

 

یک سری هستند که تعصب خاصی روی چیزهایی مثل «فلسفه یونیکس» دارند انگار که قطعا این چیز خوبیه و هر چیزی باهاش ناسازگار باشه چیز بدیه. اما این که این مسئله خوبه یا نه، مثل خیلی مسائل دیگه تو این رشته، قطعی و بدیهی نیست. و شخصا عادت ندارم این جور چیزها رو همین‌طوری بپذیرم. یا باید بشه درست بودن چیزی رو اثبات کرد، یا این که باید توجیهات و مزایا معایب رو شنید و براساس اون تصمیم گیری کرد. مثلا، برنامه‌نویسی شیءگرا بهترین روش برنامه‌نویسیه؟ آدم‌های بزرگی در موردش نوشتند، ولی عده‌ای هم هستند که مخالفن و میگن نه مثلا برنامه‌نویسی تابعی بهتره و شیء گرا چیز بدیه! یا در مورد روش‌های برنامه‌نویسی مثل آبشاری و چابک و همچنین روش‌های مختلف چابک. این‌ها هیچ کدوم «آیه» نیستند و چه بسا بعدا کسایی بیان و راه‌های متفاوتی رو به عنوان گزینه برتر معرفی کنند. شخصا، هیچ کدوم از این دست مسائل رو به صورت خشک و بدون تحلیل نمی‌پذیرم و برای تفکر خودم هم احترام قائلم! صرف این که فلان آدم شناخته شده گفته باشه چیزی خوبه به نظر من اون رو به یک حقیقت جامع و غیر قابل انکار تبدیل نمی‌کنه! مگر این که کسی بتونه اون رو به صورت منطقی و غیرقابل بحث اثبات کنه. آیا طراحی نرم‌افزار طبق «فلسفه یونیکس» واقعا خوبه؟ به نظر میاد جاهایی خوب بوده اما معنیش این نیست که لزوما همه‌جا خوبه یا اصلا راه بهتری براش وجود نداره. به نظرم این جور جاها باید بحث بشه که مثلا به فلان دلایل این کار خوب یا بده که احتمالا خیلی جاها در نهایت باید بین چند چیز سبک سنگین کرد؛ نه این که به صرف استناد به یک جمله حکم صادر کنیم.

 فلسفه یونیکس

فلسفه یونیکس چیه؟ تو ویکی‌پدیا که خیلی چیزا نوشته ولی قسمتی که اکثرا روش نظر دارن اینه: «برنامه‌ای بنویسید که یک کار رو به خوبی انجام بده».
تو نگاه اول ممکنه جمله به نظر ساده بیاد، اما ۲ قسمت داره که باعث میشه خیلی هم این جمله ساده نباشه: ۱. «یک کار» و ۲. «به خوبی». این‌ها چیزایی هست که باعث میشه این معیار خیلی هم واضح و شفاف نباشه و جای بحث پیش بیاد. نه «یک کار» لزوما تعریف مشخصی داره و نه «به خوبی»‌ انجام دادن یک کار. و نه لزوما شما می‌تونید هر دو رو با هم داشته باشیم. همون‌طور که خیلی اصول دیگه که مطرح میشن تو حرف راحت اما تو عمل اما و اگرهای زیادی پیدا می‌کنند.
خوبه یک مثال بزنم. بیاین ترکیب tar و یک فرمان فشرده‌سازی مثل gzip/xz/... رو مقایسه کنیم با برنامه zip/unzip.

تو کدوم مورد فلسفه یونیکس رعایت شده؟!
۱. دستور tar فقط کارش مدیریت بایگانی‌های tarه چه ساختن چه بیرون کشیدن فایل‌ها از اون‌ها

۲. برنامه‌هایی مثل gzip/xz و ... فشرده‌سازی و غیرفشرده‌سازی با قالب‌های مربوطه رو انجام میدند. اما اگه فایلی باشه در حد یک فایل.

۳. برنامه zip صرفا فشرده‌سازی انجام میده، اما می‌تونه بایگانی از چندین فایل داشته باشه. و حتی امکان انتخاب الگوریتم هم میتونه بده و الان bzip2 هم پشتیبانی می‌کنه. برای غیرفشرده کردن باید از unzip استفاده کرد.اینجا تفاوت‌های جالبی دیده میشه. tar به نظر میاد یک کار میکنه و اون هم خوب انجام میده. البته از یک دید هم ۲کار میکنه هم ساخت بایگانی و هم استخراج فایل‌ها از اون. برنامه‌هایی مثل gzip/bzip2/... هم فقط با فشرده‌کردن و البته غیرفشرده‌کردن کار دارند که میشه یک یا دو کار حسابشون کرد. ولی میشه گفت کار خودشون رو خوب انجام میدن. هر چند اینجا هم میشه گفت چرا هم فشرده‌سازی هم غیرفشرده‌سازی رو یک برنامه انجام میده؟!

یکی دیگه از خصوصیاتی که تو فلسفه یونیکس گفته میشه بحث ترکیب ابزارها هست. tar و gzip خب با هم به صورت ترکیبی هم استفاده میشند و شما امکان ترکیب با برنامه‌های دیگه هم دارید مثل bzip2 و xz که خب انعطاف‌پذیری رو نشون میده. البته دستور tar خودش گزینه میگیره برای ترکیبش با برنامه‌های فشرده‌سازی که شاید خودش یه جور نقض فلسفه یونیکس هم محسوب بشه!

از اون طرف zip/unzip کار فشرده‌سازی و غیرفشرده‌سازی رو جداگانه انجام میدند. اما دستور zip خودش هم با بایگانی چندین فایل سر و کار داره و هم با فشرده‌سازی اون‌ها.اما! با این که tar خوبه،‌gzip هم خوبه، ترکیب اون‌ها برای کار «فشرده‌سازی چندین فایل» لزوما ترکیب خوبی نیست. چرا؟ برای مثال، شما برای استخراج یک فایل از آرشیو tar.gz مجبورین کل فایل رو غیرفشرده کنید تا بعد بتونید از آرشیو tar یک فایل رو بکشید بیرون. اما توی zip شما می‌تونید چنین کاری بکنید. به نظر می‌رسه اینجا ابزاری که کار ترکیبی رو کرده در نهایت بهتر اون کار رو انجام داده.

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

به هر حال، شاید اینجا «یک کار» بهتره هم شامل کد کردن و هم بایگانی چندین فایل باشه تا این که بایگانی «یک کار» باشه و کدکردن هم «یک کار» جدا.

در نهایت، خود یونیکس هم بعضا فلسفه‌ش رو رعایت نکرده! یکی همین که هسته‌های اولیه و حتی هسته‌های به روز یونیکس‌هایی مثل solaris و bsdها از نوع یک‌پارچه هستند.

یک مثال شاخص هم، تابع شاخص `ioctl`ه که عملا همه کار می‌کنه... یا لااقل می‌تونه بکنه. :)

خب، تا این‌جا اول گفتم که «فلسفه یونیکس» لزوما چیز خوبی نیست، یا لزوما بهترین چیز نیست، یا اصلا شاید بسته به شرایط خوب باشه یا نباشه!

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

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

تازه یکی از اجزای این پروژه، پروژه coreutilsه. این پروژه هم شامل بالای ۱۰۰ تا فایل اجرایی مختلفه: از cp و ls گرفته تا sleep و uname و ...

کسی نمیاد بگه پروژه گنو فلسفه یونیکس رو نقض می‌کنه یا مثلا coreutils این فلسفه رو نقض می‌کنه. چون این‌ها پروژه هستند و یک «برنامه» نیستند. و درست هم هست. حتی اگه تمام برنامه‌ها پیشوند gnu یا coreutils داشتند باز هم همین بود.

پس خوبه حواسمون به تفاوت «پروژه» و «برنامه» باشه. این اولین چیزیه که توی بررسی systemd باید حواسمون باشه؛ چون systemd هم اسم یک پروژه‌ست و هم اسم یک برنامه. متاسفانه، بخش قابل توجهی از افراد به این تفاوت دقت نمی‌کنند که باعث میشه نتیجه‌گیری‌هایی بکنند که از اساس اشکال داره.آخر این قسمت، یک سوال هم مطرح کنم: آیا Sys V init با فلسفه یونیکس سازگار بود که اینقدر طرفدار داشت وقتی systemd مطرح شد؟! آیا یک کاری رو به خوبی انجام میداد؟
من فقط میگم دقت کنید که تا جایی که من می‌بینم حتی خیلی توزیع‌های مخالف استفاده از systemd هم دیگه از Sys V init استفاده نمی‌کنند!

خب، من فکر می‌کنم احتمالا کارش رو خوب انجام نمیداده که جایگزین شده. در نتیجه خودش هم با فلسفه یونیکس سازگار نبوده. اما کسی گریبان پاره نمی‌کرد که چرا Sys V init بده و اوایل مخالفین systemd دوست داشتند برگردن به اون. :)

و البته دیدم یک عده هم تفسیر خودشون رو از «فلسفه یونیکس» دارند و صرفا هر تغییر نسبت به یونیکس سابق رو تعبیر می‌کنند به نقض فلسفه یونیکس! و این افراد بیشتر مقاومت در برابر تغییر دارند تا نگرانی در مورد فلسفه یونیکس :)

systemd

خب systemd چیه؟ این کلمه به ۲تا مفهوم متفاوت می‌تونه اشاره کنه، در نتیجه وقتی کسی می‌خواد در موردش صحبت کنه باید بدونه و مشخص کنه که داره در مورد کدومش صحبت می‌کنه و این ۲تا رو قاطی نکنه!
"systemd is a suite of basic building blocks for a Linux system."
به صورت کلی، systemd یک «مجموعه نرم‌افزاری پایه‌ای برای یک سیستم لینوکس»ه. و ما داریم در مورد یک «پروژه» نرم‌افزاری صحبت می‌کنیم نه یک «برنامه».
اما، اسم شاخص‌ترین برنامه این مجموعه هم systemd هست! کار «برنامه systemd» چیه؟ طبق تعریف خودشون، «مدیریت سیستم و سرویس‌ها». که البته خیلی قسمت «مدیریت سیستم»ش گویا نیست به نظرم و میشه منظورش رو از کارهایی که می‌کنه تشخیص داد.
حالا وقتی در مورد «پروژه systemd» صحبت می‌کنیم، آیا صحبت از این که این پروژه به خاطر پوشش موارد خیلی متنوع با فلسفه یونیکس در تناقضه، درسته؟ «به هیچ عنوان». اصلا چنین صحبتی معنا نداره؛ چون فلسفه یونیکس اصلا و به درستی در مورد پروژه‌ها یا مجموعه‌های نرم‌افزاری صحبتی نمی‌کنه. یک پروژه رو میشه به چند پروژه شکست بدون این که شما هیچ تغییری توی کدهای اجرایی ایجاد کنی. پس پروژه اصالت خاصی نداره.

به جز «برنامه systemd» برنامه‌های مختلفی توی این مجموعه وجود داره مثل مدیریت: لاگ‌ها، نشست کاربران، اتصالات شبکه، ساناد یا DNS، راه‌اندازی سیستم (بوت)، زمان سیستم، همگام‌سازی زمان با NTP، فایل‌های موقت و دستگاه‌های متصل به سیستم.

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

البته ممکنه یکی با استدلال بگه به صورت کلی توی کل این پروژه، رویکرد متفاوتی نسبت به «فلسفه یونیکس» پیش گرفته شده و از این نظر بگه این پروژه با اون فلسفه سازگار نیست؛ اما من تا الان چنین چیزی رو ندیدم و خیلی افراد واقعا نه شناخت کافی نسبت به systemd دارند و نه حتی خود فلسفه یونیکس!

حالا «برنامه systemd» چی؟ این برنامه مطابق با فلسفه یونیکس هست یا اون رو نقض می‌کنه؟
جواب این سوال سخته و من جوابی که بتونه همه رو قانع کنه به ذهنم نمی‌رسه. همون‌طور که اوایل گفتم، «فلسفه یونیکس» یک سنجه دقیق نیست که بگذاریم و راحت بگیم این برنامه کاملا سازگاره و این برنامه هم متناقض. یک سری برنامه‌ها ممکنه به اندازه کافی به یکی از این دو سمت نزدیک باشند که بشه نسبتا راحت در موردشون نظر داد. اما یک سری برنامه‌ها هم ممکنه بیفتند توی طیفی بین این ۲ سمت که دلیلش هم قبلا گفتم: کلماتی مثل «یک کار» و انجام آن «به خوبی» کلماتی نیستند که تعریف دقیق و روشنی داشته باشند. در نتیجه، هر کس بسته به معیارها و تعریف خودش ممکنه قضاوت متفاوتی داشته باشه؛ و من هم قصد ندارم برای دیگران در موردش قضاوتی بکنم. اما صرفا سعی می‌کنم تا حدی توصیف کنم برخی خصوصیات systemd رو و نظرم رو هم بگم.
برنامه systemd کارش مدیریت سیستم و سرویس‌های سیستمه. این برنامه به جز journald، که اونم می‌تونه صرفا کارش ارسال لاگ‌ها به syslog باشه، تا جایی که من میدونم به هیچ‌کدوم از برنامه‌های مجموعه پروژه systemd وابستگی نداره. شاید بشه گفت مهم‌ترین کار این برنامه، مدیریت و اجرای سرویس‌های سیستم یا کاربره. حالا من اینجا بیشتر حالتی که systemd به عنوان اولین پردازه سیستم با PIDه شماره یک کار می‌کنه صحبت می‌کنم.
اما، systemd کاری فراتر از اجرا و اتمام سرویس‌ها انجام میده. توی systemd شما با «واحدها» یا unitها سر و کار دارین. اما این unitها صرفا سرویس‌ها نیستند، بلکه می‌تونن نماینده دستگاه‌ها، نقاط سوار شدن (mount pointها)، سوکت‌ها، زمان‌سنج‌ها و چند مدل واحد دیگه باشند. حالا اینجا جاییه که واقعا می‌تونه سوال برانگیز باشه. چون عملا systemd بخشی از کاری رو که قبلا سرویس‌هایی مثل crond، atd و inetd انجام می‌دادند رو هم انجام میده و خودش رو درگیر دستگاه‌های سخت‌افزاری و مدیریت فایل‌سیستم‌ها هم کرده. و این موارد مواردی هستند که می‌تونن به درستی مطرح بشند از این نظر که سازگاری با فلسفه یونیکس وجود داره یا نه (و نه تیترهای زردی مثل این که systemd بوت لودر هم هست...).

اما آیا systemd از این که روی انجام یک کار متمرکز بشه دور شده یا نه؟ این رو تا حدی میشه با مثالی که قبلا در مورد مقایسه tar - gzip و zip انجام دادم مقایسه کرد. اونجا هم از یک نظر میشه گفت zip داره به جای یک کار ۲کار انجام میده. و نمیشه هم گفت این حرف درسته یا غلط.
اینجا هم، کار systemd مدیریت سرویس‌هاست. اما عملا چیزهایی مثل cron و inetd هم به نحوی توی مدیریت سرویس‌ها دخالت دارند چون هر کدوم می‌تونند از نظر مفهومی یک یا چند سرویس رو هم اجرا کنند. حالا آیا بهتر نیست این‌ها هم مثل بقیه سرویس‌ها خود systemd مدیریت کنه؟ می‌تونه باشه. در واقع، میشه به نحو دیگه‌ای هم رفتار systemd رو توصیف کرد. systemd اومده یک انتزاع سطح بالاتر به نام واحد یا unit ساخته، که شما می‌تونید از همین مفهوم و به صورت یکپارچه برای مدیریت سیستم استفاده کنید. میشه این رو تا حدی با مفهوم «فایل» توی یونیکس مقایسه کرد. یکی از خصوصیات یونیکس این بوده که خیلی چیزها توی یونیکس فایل هستند: فایل‌های دیسک، سوکت‌ها، دستگاه‌های سخت‌افزاری، و ... . و این مسئله به شما قدرت میده که بتونید با مجموعه‌ای از چیزهای متفاوت رفتار مشابهی داشته باشید و این اتفاق خوبیه. «به نظر من»، کاری که systemd در مورد یک سری مفاهیم انجام داده هم مشابه همین مثاله. این که شما می‌تونید به جز سرویس‌ها، مفاهیم دیگه‌ای رو هم در قالب واحدها توصیف کنید به شما قدرت بیشتری توی مدیریت سیستم میده. این یعنی که شما میتونید از مسائلی مثل وابستگی بین واحدها و غیره برای چیزهای گسترده‌تری استفاده کنید و به صورت یکپارچه‌تری سیستم رو مدیریت کنید. از دید من، این چیز خوبیه و میشه این‌ها رو در قالب انجام یک کار به خوبی دید، اما درک می‌کنم که ممکنه کسی مخالف باشه و از نظر من اشکالی هم نداره.

آیا کارش رو خوب انجام میده؟ البته که قطعا مثل تقریبا هر برنامه دیگه‌ای این برنامه هم ایرادات خودش رو داره، اما باز به نظر من در مجموع کارش خوبه، مخصوصا نسبت به سیستم‌هایی که جایگزینشون کرد.
یک مثال دیگه هم البته، اینه که systemd سازگاری بسیار خوبی با مدل SysV init داشت و از سرویس‌های اون پشتیبانی می‌کرد. حالا کسی ممکنه این رو هم ایراد بدونه که چرا همچین ویژگی هم به systemd اضافه شده و اون رو «پیچیده» کرده! اما از اون طرف همین ویژگی انتقال به systemd رو بسیار آسان‌تر و کم ریسک تر کرده بود. از نظر من، این ویژگی چیز خوبیه، اما از دید یک نفر می‌تونه به پچیده شدن و دور شدن از «تمرکز روی یک کار» تعبیر بشه. و خب من نمی‌تونم بگم که نظر من درست‌تره!

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

journald

به عنوان آخرین صحبت قبل از خلاصه نهایی، یه نیم نگاهی هم به journald داشته باشیم بد نیست چون بخشی از انتقادات هم متوجه این سرویسه.اول که همون‌طور که گفته شد، شما مجبور نیستین از journald برای مدیریت رخدادنماها (logها) استفاده کنید و می‌تونه صرفا اون‌ها رو ارسال کنه برای syslog و خودش چیزی نگه نداره.
دوم این که از نظر من این برنامه صرفا یک کار انجام میده و اون هم مدیریت رخدادنماهاست و فکر نمی‌کنم از این نظر خیلی اختلاف نظری توش وجود داشته باشه. اما جایی که بیشتر روش صحبت هست، نحوه ذخیره‌سازی رخدادنماهاست، چون journald اون‌ها رو به صورت دودویی ذخیره می‌کنه و نه متنی. بعضی از اساس با این قضیه مخالفن و برای مثال میگن باعث میشه شما نتونید لاگ‌های ذخیره‌شده رو با ابزارهای معمول (مثلا grep) بررسی کنی. یا دلایل دیگه. و بعضی هم میگن این هم با فلسفه یونیکس ناسازگاره.
حقیقتا یک سری از دلایل رو خیلی صحبتی نمیشه روش کرد. مثلا من می‌تونم بگم شخصا موافق نیستم ولی فکر نمی‌کنم خیلی قابل بحث باشه. از نظر من این که شما می‌تونید با journalctl لاگ‌ها رو در قالب متنی دریافت کنید و پردازش دلخواه خودتون رو روش انجام بدید (به جز این که خود journalctl هم قابلیت‌هایی داره برای انتخاب رخدادنماهایی که دنبالش هستیم). و از نظر من دودویی بودن لزوما چیز بدی نیست همون‌طور که خیلی برنامه‌ها چنین کاری می‌کنند.
در مورد فلسفه یونیکس هم، طبق چیزی که من توی ویکی‌پدیا می‌بینم توی بعضی روایت‌ها گفتند که داده‌ها رو متنی نگه دارین ولی توی بعضی روایت‌های دیگه هم بیشتر تاکید روی ورودی و خروجی برنامه‌هاست که متنی باشه و تو بعضی روایت‌ها هم اصلا صحبتی از این قضیه نشده! در نتیجه، به نظرم اصلا این که این جزء فلسفه یونیکس هست یا نه خودش جای بحث داره. و دوم هم، به فرض هم اگر باشه شخصا موافقش نیستم، و البته ما با برنامه‌های زیادی سر و کار داریم که چنین کاری نمی‌کنن! مثلا بسیاری از پایگاه‌های داده اون رو در قالب دودویی ذخیره می‌کنند. یا مثلا شما تصویر رو در قالب متنی ذخیره نمی‌کنید... (البته قالب xpm هم قالب بامزه‌ایه :) ). جدای از این که «متن» هم دیگه لزوما فقط متن ASCII نیست. و حتی توی ارتباط برنامه‌ها می‌بینیم که زمانی بخشی از ارتباطات دودویی بود؛ بعدا ارتباطات متنی مثل xml و json مد شد، و بعد دوباره قالب‌ها و ارتباطاتی باینری مثل protocol buffers باب شد در بخشی از ارتباطات.

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

خلاصه 

• فلسفه یونیکس لزوما و همه‌جا خوب نیست
• فلسفه یونیکس یک معیار کیفی و قابل تفسیره، و سازگاری با اون لزوما صفر و یک نیست. و ممکنه برآورده کردن معیارهای مختلف اون به صورت همزمان ممکن نباشه
• لزوما هر چی در یونیکس بوده کاملا مطابق با فلسفه یونیکس نیست
• فلسفه یونیکس در مورد «برنامه»ها صحبت می‌کنه و نه «پروژه‌»ها یا مجموعه برنامه‌ها
• سیستم SysV init لزوما مطابق با این فلسفه نیست
• «پروژه systemd» شامل مجموعه‌ای از ابزارها یا برنامه‌هاست که زمینه‌های مختلفی رو پوشش میدن (بوت، مدیریت لاگ، ترجمه فایل fstab، مدیریت شبکه، ترجمه dns، مدیریت سیستم و سرویس‌ها و ...)
• گسترده بودن محدوده پروژه systemd تناقضی با فلسفه یونیکس ندارد (چون یک برنامه نیست)
• «برنامه systemd» وظایف مختلفی رو زیر چتر مدیریت سیستم و سرویس‌ها انجام میده که قبلا توسط چندین برنامه انجام میشده (مثل init، cron، inetd، اسکریپت‌های مدیریتی و ...)
• با این وجود، لزوما «برنامه systemd» در تناقض با فلسفه یونیکس نیست، چون می‌توان گفت تمامی این کارها در راستای انجام کار اصلی آن به خوبی ست.
• میزان رعایت فلسفه یونیکس در «برنامه systemd» بستگی به تفسیر شما متفاوت است.
• با نگاه سخت‌گیرانه، بسیاری از برنامه‌های مرسوم ممکن است سازگار با فلسفه یونیکس محسوب نشوند. این معیار، به تنهایی برای قضاوت کافی نیست
• برای برخی، فلسفه یونیکس صرفا بهانه برای مقاومت در برابر تغییر است، و ممکن است حتی خود فلسفه را هم دقیق ندانند.

 

در پایان، هدف، ارائه تصویری دقیق‌تر از systemd برای دوستانی بود که کمتر از نزدیک به آن نگاه کرده بودند. مخصوصا که حجم نسبتا زیادی مطالب نه چندان دقیق در مورد این برنامه وجود دارند که خواسته یا ناخواسته منتشر کننده ترس، ابهام و شک[۱] در مورد این مجموعه نرم‌افزار هستند. تا جایی که حتی برخی تصور می‌کنند بوت با systemd می‌تواند کندتر از بوت با sysv init باشد در صورتی که حداقل از نظر منطقی چنین نباید باشد!

 

[1] https://en.wikipedia.org/wiki/Fear,_uncertainty,_and_doubt

سال ۱۴۰۳ مبارک!

نوروز همه مبارک! :)

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

امیدوارم سال جدید برای همه سال بهتری باشه...

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

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

 

غذا برای ۴ - ۵ نفر...

۴ نفر خارجی، ۵ نفر ایرانی |:

زبان‌های برنامه‌نویسی...

دنیای زبان‌های برنامه‌نویسی هم دنیای جالبیه برا خودش! ظاهرا هیچ‌وقت ایده‌های افراد برای زبان‌های جدید تموم نمیشه :) و البته بعد از اومدن زبون‌هایی که ماشین مجازی دارند یا مفسری هستند مثل دات‌نت و ruby و این‌ها باز زبون‌هایی اومدن که به صورت بومی! (native) کامپایل میشند. زبون‌هایی مثل Vala و Go که خیلی طرفدار پیدا کرده و بعدش هم Rust که توی فدورا ۲۵ کامپایلرش اضافه شده.

ولی خب! اصلا قصدم از این پست صحبت در مورد این‌ها نبود. فقط خواستم اینو بگم: فکر می‌کنید این کد به چه زبونیه؟

void f(string_view id, unique_ptr foo) {
   if (auto [pos, inserted] = items.try_emplace(id, move(foo)); inserted){
      pos->second->launch();
   } else {
      standby.emplace_back(move(foo))->wait_for_notification();
   }
}

اگه می‌دونید که هیچ! ولی اگه نمیدونید حتما حدس زدید که شبیه سی++ هست ولی به نظر دقیقا سی++ هم نمیاد. خب حق دارید! چون سی++ هست، ولی سی++۱۷ (C++17). این کد یه نمونه کد هست از اینجا.

کلا روال جدید به روز رسانی استاندارد سی++ خیلی بهتر از قبل شده. بعد از استاندارد سی++۱۱ که در واقع قرار بود قبل از سال ۲۰۱۰ بیاد و خیلی طولانی شد (در واقع، تغییر توی سی++ بعد از ۱۳ سال بود نسبت به استاندارد ۹۸ (استاندارد ۲۰۰۳ هم بود ولی اون تغییر اساسی‌ای نسبت به ۹۸ نداشت))، تصمیم گرفتند روال استاندارد هم، مثل روالی که خیلی نرم‌افزارها برای انتشارشون در نظر گرفتند، براساس زمان و فعلا ۳ سال یک‌بار باشه. برای همین هم استاندارد سی++۱۴ و الان هم سی++۱۷ تو راهه. و بعدی هم میشه سی++۲۰.

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

هر چند این زبون‌های جدید جای سی++ رو تنگ کردند :(
؛)

تلویزیون شهری!

۲تا کتاب جالب!

یه وقتی این ۲تا کتاب رو دیدم به نظرم قابل عکس گرفتن اومد! :)

و این:

پ.ن: شاید از این به بعد بیشتر بنویسم!

واقعا؟!

جا داره از دوستان تشکر کنم که توی ۲۴ساعت تقریبا نصفش رو صرف نظافت روزانه‌ی یه نمازخونه‌ی کوچیک می‌کنند!